[coreboot] elf payload legacybios - boots on v3 in qemu

Myles Watson mylesgw at gmail.com
Mon May 12 22:46:44 CEST 2008

> -----Original Message-----
> From: Kevin O'Connor [mailto:kevin at 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

> 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"


More information about the coreboot mailing list