Hi kevin,
Great job! Some comments below.
I suspect the hardware detection and initialization does not have much overlap with coreboot. The most important part of this section is the IDE initialization and disk scan. (Some other code, for example keyboard init, may be redundant when used with coreboot.)
yes
The option rom scan and execution allows the bios code to call out to additional system roms. The "post" stage runs in 32bit mode, but the option roms are called in 16bit mode - the "legacybios" code simply transitions to/from 16bit mode to make these calls. The option rom code is executed natively on the processor.
I think this is redundant with coreboot, since coreboot will also run pci rom, eg. vga bios.
The "pci init" code looks to be redundant with what coreboot already provides. The code in "legacybios" seems to be intel northbride/soutbridge specific.
yes, these code could be omitted when used with coreboot.
Some old DOS programs make assumptions about specific memory locations in the first 1Meg of ram. The "legacybios" code fills in these areas to make these old programs happy - in short they are the "bios data area" at 0x00000 - 0x00500, the "extended bios data area" at 0x9fc00 - 0xa0000, and some hardcoded locations in the 0xf0000 bios segment itself. The bios working storage areas (in bda and ebda) and the 16bit interrupt vector table is also setup (part of the bda).
I think this is necessary.
It is not clear to me how much of the acpi/mptable/smbios code is reusable on real hardware. It is possible that most of the info in these tables is irrelevant, and the "legacybios" code may therefore be a good starting point. However, it may also be simpler to have coreboot just pass these tables in.
I don't think the acpi/mptable is reusable on real hardware, so have coreboot pass these tables in is better since coreboot developer should have a better understanding about the mainboard he/she is developing.
Some of the hardware accesses made by the "legacybios" code appear to be specific to hardware in the emulator. The code attempts to enable ram shadowing of the memory segment at 0xf00000 - it does this so that it can put acpi/mptable/smbios tables into that area. After it is complete, it attempts to disable writes to that region. The code sequence looks to be specific to intel north/southbridges. It isn't necessary to disable writes to 0xf0000 (though it would be nice), but it is necessary to have the ability to alter that memory.
This shadowing job should be left to coreboot, if someone is going to use legacybios, he should take care of this shadowing job in ram init code.
I've written a loader for coreboot-v2 to load legacybios, it works well when used with qemu, I've booted freebsd with it. But on real hardware, via epia-cn, it hangs with a blank screen, the debug port value is 0x31, I'll take some time to see what's going wrong.
I add a header for legacybios to become a payload, this is done by a utility createpayload. I've attached the loader and the utility. Signed-off-by: Aaron Lwe aaron.lwe@gmail.com
Thanks,