On Fri, May 16, 2008 at 12:16:54AM +0200, Rudolf Marek wrote:
I strongly prefer b) above over anything else.
What you're proposing here is that the payload build all the standard bios tables - mptable, pir, e820 map, smbios, acpi.
So I think legacybios should create the ACPI/MPTABLE/etc when in emulation mode. Otherwise coreboot should handle PIR, MPTABLE + ACPI.
I can see benefits and disadvantages to both sides:
Moving the logic to the payload means coreboot can have one simple unified information passing mechanism. It need not know about all the various bios standards that have been introduced over the years; it need not track new standards as they arise. Unfortunately, it means the payloads may need to dig into the hardware details and this could result in board specific logic spread between coreboot and various payloads. With the tables produced in coreboot it may be possible to build a payload that can work on any x86 target.
The trick would be to mark for legacy bios what parts of region 0xf0000-0xfffff are used with the tables already. Or lets say we can put all stuff in first 32kb. second 32kb for legacy bios.
If you read back to my original email - you seem to be in favor of option "d".
Note that coreboot doesn't need 32KiB for the bios tables - 1KiB should be more than enough. The acpi and smbios stuff only need the initial table directories to exist in the 0xf0000 area. The rest of the info can exist anywhere in ram.
Kevin, does the legacy bios work somehow with coreboot already? Does it have support for IDE on PCI bars :) ?
One can launch the latest "legacybios" elf payload with coreboot-v3 under qemu. I haven't tested it on real hardware.
I'm not sure what "IDE on PCI bars" means. The code does attempt to access the IDE controller in PIO mode via IO ports (eg, 0x1f0, 0x3f0 for the first channel).
-Kevin