Hi all,
I strongly prefer b) above over anything else. I specifically do not want coreboot to know about BIOS tables. coreboot already exports some information. If legacybios needs more information, let's add that to the coreboot tables.
What you're proposing here is that the payload build all the standard bios tables - mptable, pir, e820 map, smbios, acpi. I'm okay with this - it makes sense to me. However, I didn't get the feeling there was a general consensus that this logic should move from coreboot to the payloads.
Hmm this is difficult. ACPI is very very complex and if we ever want Suspend to RAM etc then it is inevitable. ACPI is *NOT* legacy. It contains lot of info specific to board/chipset and also about *currently* installed CPU.
So I think legacybios should create the ACPI/MPTABLE/etc when in emulation mode. Otherwise coreboot should handle PIR, MPTABLE + ACPI. The memory map shall be transfered with the coreboot tables. The legacybios can do e820 map from those tables - like FILO does imho.
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. Certainly this solution is not cleanest but I think it will work. If coreboot needs more space it can steal some other memory. E.G start with ACPI tables on 0xe0000 and mark it reserved.
There is also problem with SMM code. I think coreboot should have at least handler which returns from SMM and increases some counter. Better then for example when HW monitoring chip triggers SMI because fans runs too slow and freezes the machine because the CPU jumps to nowhere. And also C1E cannot be implemented without SMM. So coreboot should place some SMM handler to some memory too - like ACPI and other tables.
Kevin, does the legacy bios work somehow with coreboot already? Does it have support for IDE on PCI bars :) ?
Thanks, Rudolf