[coreboot] elf payload legacybios - boots on v3 in qemu
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:
> > Should we make an option to build just the 16-bit version of the BIOS.
> > seemed more forgiving on real hardware. It seems like there is a lot
> > 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
> * 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
More information about the coreboot