[SeaBIOS] Moving BIOS tables from SeaBIOS to QEMU

[Laszlo Ersek]

On 02/27/13 10:19, Gerd Hoffmann wrote:
> On 02/26/13 19:30, Laszlo Ersek wrote:
>> On 02/26/13 10:03, Gerd Hoffmann wrote:
>>
>>> Can tianocore grab acpi tables from coreboot?
>>
>> Not that I know of. (... It may have been a rhetorical question.)
> 
> Wasn't rhetorical.  Generating the apci tables in both ovmf and seabios
> doesn't make that much sense, better would be to have that in one place.
> 
> Option one is to let qemu provide them, then both ovmf and seabios can
> grab them via fw_cfg.
> 
> Option two is to use coreboot underneath, then let both seabios and ovmf
> grab the tables from coreboot.  Which of course requires that ovmf can
> use the tables provided by coreboot.  Seabios can do that today.
> 
> /me looked around a bit in the coreboot source code.  Looks like they
> simply copyed over the dsdt from seabios as-is, which doesn't fly due to
> the pci _crs method referencing ssdt's BDAT.
> 
> From the quick look it seems they do *not* generate the dsdt
> dynamically, only the other tables (simliar to seabios).  So switching
> to coreboot probably doesn't help to remove the dsdt patching code we
> have in seabios.
> 
>> When running on Xen, an area is searched for the RSDP, and linked tables
>> (prepared by Xen's hvmloader I think) are installed by OVMF.
> 
> Ok, so doing something simliar when running on coreboot should be
> possible without major headache.
> 
>> When running on qemu, static tables are used. I strived to adapt them as
>> much as I could to qemu hardware. Some tables (recognized by header) are
>> copied & modified dynamically before installation: MADT, SSDT.
> 
>> Getting a precise picture of qemu hardware in the form of ACPI tables
>> (over fw_cfg) would not only allow OVMF to pass on better tables to
>> OSPM; OVMF could *maybe* use them itself.
> 
> qemu 1.4+ places the dsdt into fw_cfg.  But again, that is the one which
> references BDAT, so using it as-is in ovmf isn't going to fly ...

As far as I understood Kevin suggested to
- remove the BDAT (FWDT in OVMF) and the related DSDT logic,
- prepare the byte-code of the CRS dynamically from a template (t could
be a Name instead of a Method) and patch the ranges before installation.

Laszlo