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

[Myles Watson]

> 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
> the payloads.
> 
> 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
> extract).
> 
> 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?

I don't think we want to call coreboot's lar functions.  Using libpayload
for that would be a lot cleaner.

> > > 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
> configuration items.

Is there anything that needs to be configurable after build time?

Thanks,
Myles

> > 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.
> 
> -Kevin
> 
> --
> coreboot mailing list
> coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot