On Fri, May 31, 2013 at 2:32 AM, Gerd Hoffmann kraxel@redhat.com wrote:
Hi,
I guess -bios would load coreboot. Coreboot would siphon the data necessary for ACPI table building through the current (same) fw_cfg bottleneck, build the tables,
Yes.
So, this is really about making coreboot+seabios the default QEMU firmware, and making seabios depend on being a coreboot payload?
load the boot firmware (SeaBIOS or OVMF or something else -- not sure how to configure that),
It wouldn't be loading OVMF. It would be loading CorebootPkg.
OVMF is a better sample platform for EDK II since it shows a more realistic view of what an EDK II based platform looks like on real hardware.
Thus, if the ACPI tables are just being added to a new coreboot layer with coreboot becoming the default QEMU firmware, then it doesn't help OVMF (or other non-coreboot payloads).
Well, it could if the table code was BSD licensed, but only so we could then merge them into OVMF. Then again, why not just provide a set of suitably licensed ACPI source files within the QEMU tree that firmware projects could use? QEMU doesn't necessarily need to build/link them, or attempt to communicate them at runtime.
-Jordan
The coreboot rom has named sections (this is called cbfs which stands for coreboot filesystem IIRC):
rincewind kraxel ~# cbfstool /usr/share/coreboot.git/bios.bin print bios.bin: 256 kB, bootblocksize 848, romsize 262144, offset 0x0 alignment: 64 bytes
Name Offset Type Size cmos_layout.bin 0x0 cmos_layout 1160 fallback/romstage 0x4c0 stage 14419 fallback/coreboot_ram 0x3d80 stage 37333 config 0xcfc0 raw 2493 fallback/payload 0xd9c0 payload 56969 vgabios/sgabios 0x1b8c0 raw 4096 (empty) 0x1c900 null 144216
where "fallback/payload" is seabios.
and pass down the tables to the firmware (through a now unspecified interface -- perhaps the tables could even be installed at this point).
As far I know coreboot can add more stuff such as acpi tables to cbfs at runtime and seabios able to access cbfs too and pull informations from coreboot that way.
HTH, Gerd