qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-stable] [SeaBIOS] problems with freeBSD


From: Michael Tokarev
Subject: Re: [Qemu-devel] [Qemu-stable] [SeaBIOS] problems with freeBSD
Date: Thu, 07 Mar 2013 11:17:31 +0400
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/17.0 Icedove/17.0

07.03.2013 10:12, Doug Goldstein wrote:
> On Wed, Mar 6, 2013 at 7:58 PM, Peter Stuge <address@hidden> wrote:

>> Yeah, it is very common. Lots of distributions patch their
>> toolchains such that they don't compile firmware code correctly.
>>
>> Firmware isn't a common target, so I understand that it happens.
>>
>> For coreboot we recommend to build a vanilla toolchain using known
>> good versions. We also have a script to do that. (The script is at
>> util/crossgcc/buildgcc in the coreboot repo.)
[]
> Not sure if you or Kevin builds the coreboot images at
> http://code.coreboot.org/p/seabios/downloads/, but would you guys
> consider building point release as well (e.g. 1.7.2.1), if yes then my
> next question...
> 
> The rest of the ML,
> 
> Would qemu consider using those blobs rather than different developers
> using their distro toolchain to build up a random commit ID. I say
> random only because often qemu releases ship with a non-release
> seabios.
> 
> In this past there's been other issues related to seabios + qemu, that
> I've solved in Gentoo by simply using the coreboot seabios images
> after some troubleshooting help from Peter. Similarly our Ubuntu
> OpenStack machines at work had quirks resolved by dropping the
> coreboot seabios images on them.

Just a note, or an "alternative opinion", so to say.  In Debian, we have
a social contract which, among other things, ensures that the binaries
you, as a user, get, comes with source which you can modify on the
system you installed.  This requires, for example, that all binaries
shipped are actually built from the corresponding source, and that
no blobs from whatever other sources are used, ever.

We don't even ship any upstream blobs in the debian qemu _source_
package: we repack upstream qemu.tar.gz by removing these blobs.

So from this PoV, it'd be better if upstream didn't ship any blobs
at all, -- we wont need to repack the upstream .tar.gz ;)

FWIW, prpbably we were lucky so far: we had almost no issues with
(mis)compiling of various ROM codes (bochsbios, seabios, vgabios,
pxe roms, various sparc/ppc firmware etc) using toolchains provided
by Debian.

Thanks,

/mjt



reply via email to

[Prev in Thread] Current Thread [Next in Thread]