On Wed, Feb 27, 2013 at 03:09:25PM +0100, Laszlo Ersek wrote:
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.
My suggestion was to replace BDAT with a dynamically generated P0S (and P[01][SLE][LH]?) in an SSDT (by updating ssdt-sups.dsl).
-Kevin