[SeaBIOS] [PATCH 0/5] vgabios: build variants for qemu

[Gerd Hoffmann]

On 01/24/12 01:23, Kevin O'Connor wrote:
> On Mon, Jan 23, 2012 at 12:30:29PM +0100, Gerd Hoffmann wrote:
>>   Hi,
>>
>> This patch series prepares vgabios for being used as qemu vga bios.
> 
> Are you thinking of driving an effort to replace the default vga bios
> in qemu?  (Assistance would be helpful here.)

I'd love to do that.  A vga bios largely written in C is much easier to
handle, also the lgpl vgabios upstream is very non-responsitive.

> As for current state in comparison to the existing LGPL vgabios, the
> only thing I'm aware of is the Cirrus support still lacks a few vbe
> calls (calls 05/06/07/10) and BochsVGA has similar vbe calls lacking
> (calls 04/05/06/07/0a) and BochsVGA has a 32bit mode interface not
> implemented.  The remaining calls look pretty straight forward, but
> the 32bit interface would require some build magic.
> 
> Testing is going to be the real challenge.  I don't even know what (if
> anything) actually uses some of the obscure vgabios calls.

Agree.  Didn't test vbe at all yet.  vesafb can use these calls, but
doesn't by default.  In 8bit modes (pretty out of fashion these days)
they are used to set the palette registers, but vesafb happily falls
back to direct vga port access in case they are not available.  vesafb
can also pan the display for faster scrolling, which uses these calls
too to set the first scanline to be displayed.

>> Qemu comes with multiple vga card emulations, so we need multiple
>> vgabios binaries.  All build out of the same source tree, but with
>> different config options.  Thus patch #1 revamps vgabios configuration
>> to allow building different variants in one go.  Patches #2 .. #5 enable
>> more qemu virtual hardware support on top of that.
> 
> Why does QEMU have so many different vgabios blobs?  QEMU is actively
> peaking into the blob and updating the PCI ids, so it shouldn't
> require a different blob for each BochsVGA variant.

Hmm, need to check.  The lgpl vgabios looked up the card by pci id, so
the pci id is encoded in more places than just the rom header, thus the
patching approach doesn't fly.  The seabios version uses the bdf passed
in from seabios instead if I read the code correctly, so the patching
should actually work.

> That would then
> leave just two blobs - Cirrus and Bochs.  I do wonder if it would be
> simpler to just run the build twice (updating .config between builds).

Another way would be runtime detection, so we could have a single bios
binary with both cirrus and bochs support.

cheers,
  Gerd