[coreboot] elf payload legacybios - boots on v3 in qemu
kevin at koconnor.net
Wed May 14 02:51:43 CEST 2008
On Tue, May 13, 2008 at 02:59:46AM +0200, Peter Stuge wrote:
> On Mon, May 12, 2008 at 03:36:29PM -0400, Kevin O'Connor wrote:
> > * 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:
> > * and c) put them somewhere in memory where legacybios can then copy
> > it to the 0xf0000 segment
> > * 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.
> I strongly prefer b) above over anything else. I specifically do not
> want coreboot to know about BIOS tables. coreboot already exports
> some information. If legacybios needs more information, let's add
> that to the coreboot tables.
What you're proposing here is that the payload build all the standard
bios tables - mptable, pir, e820 map, smbios, acpi. I'm okay with
this - it makes sense to me. However, I didn't get the feeling there
was a general consensus that this logic should move from coreboot to
In any case, there is a catch with doing this - some info is unlikely
to be found in the dts (eg, the acpi aml code). This would require we
build it into the payload (or somehow get it into a segment for lar to
An alternative would be to have the payload callback into the lar
functions to extract and uncompress a segment with the info. Is this
okay for a payload to do?
> > 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'm looking for feedback from the coreboot developers on what the
> > best answers to the above questions are.
> Likewise I prefer a) here.
Okay. These are configurable items though, so it naturally means that
users need to be able to change them. This will require a payload (or
OS app) be capable of writing parts of the flash chip to change the
> On a related note I would like to request that we try hard not to
> touch NVRAM at all unless it is absolutely neccessary.
Bochs bios and "legacybios" don't really use the nvram that much.
I'll follow up in a separate email.
More information about the coreboot