[coreboot] legacy bios support and coreboot

[aaron lwe]

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 at gmail.com>

Thanks,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: legacybiosloader.patch
Type: application/octet-stream
Size: 7988 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080507/837ee010/attachment.obj>