-----Original Message----- From: Kevin O'Connor [mailto:kevin@koconnor.net] Sent: Monday, May 12, 2008 1:36 PM To: Myles Watson Cc: 'Coreboot' Subject: Re: [coreboot] elf payload legacybios - boots on v3 in qemu
Hi Myles,
On Mon, May 12, 2008 at 12:38:20PM -0600, Myles Watson wrote:
Note that the payload likely wont work on real hardware - see my previous email on legacybios and coreboot.
[...]
BTW, have you listed the board-specific components anywhere? I don't remember seeing one.
I was referring to the email at:
http://www.coreboot.org/pipermail/coreboot/2008-May/034254.html
[...]
Should we make an option to build just the 16-bit version of the BIOS.
It
seemed more forgiving on real hardware. It seems like there is a lot
more
that is board-specific in the 32-bit version.
Currently the "post" section is compiled in 32bit mode. This "post" stage includes initialization of the bios working storage area, so we can't entirely skip it.
Instead of moving more code to 16bit mode, I think we should just have options to leave out unwanted features. For example, disabling the call to rombios32_init() in post.c should stop the pcibios init, acpi table creation, and smbios table creation.
Sure. I wasn't suggesting that we move code to 16-bit. I was just noting that when I was trying to boot Windows XP on a real box, I got farther with the simpler BIOS because Windows didn't expect as much functionality from it.
I'm looking for feedback on exactly the above. There are several ways to support per-board info in "legacybios":
Have legacybios populate the information:
By a) compiling legacybios on a board by board basis with info for each board merged into the compile process
or b) have the info passed to legacybios from corebios in some raw format, and then have legacybios build the PC specific tables from it
or, have coreboot build the PC specific tables:
I think this option is more flexible.
- and c) put them somewhere in memory where legacybios can then copy it to the 0xf0000 segment
I like this one better. It seems more robust.
- or d) work out some arrangement where coreboot puts them into 0xf0000 in such a way that legacybios doesn't overwrite those areas when it is also loaded into that segment.
As you also mention, there are some useful configuration items (eg, boot order and floppy drive type). We can either:
a) have coreboot select and configure this and pass the info to legacybios in some way
or b) have legacybios set it in the cmos and present a menu during boot where the user can change the options (eg, "Press [DEL] to enter bios setup".
I think there is enough space in the CMOS to just reserve a portion of it for "legacybios"
Myles