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 _______________________________________________ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios