[coreboot] LinuxTag 2008 Status

[Myles Watson]

> -----Original Message-----
> From: Jordan Crouse [mailto:jordan.crouse at amd.com]
> Sent: Monday, June 02, 2008 5:48 PM
> To: Myles Watson
> Cc: 'ron minnich'; coreboot at coreboot.org
> Subject: Re: LinuxTag 2008 Status
> 
> On 30/05/08 16:59 -0600, Myles Watson wrote:
> >
> > > But when you look closer, the number of possible modes explodes.  As
> an
> > > example:
> > >
> > >  - You may want to add a timeout to the menu, so that if somebody
> doesn't
> > >  press the hotkey, a default payload is chosen.
> > >  - When chaining, some payloads will be opt in (press F1 for setup),
> some
> > >  will be opt out (press F2 to skip), and others will always run
> > >  - Uwe expressed a desire to select a chain from the menu
> > >
> > > Everything is further complicated by the fact that we can add a new
> > > payload
> > > to the LAR at any time, which makes it very difficult to specific the
> > > configuration at bayou compile time.
> >
> > How about the name of the lar entry for the payload (since we can store
> the
> > user-friendly name in the notes.)  The default payload is the one named
> > "payload" or "normal" or "default".  Then any number of payloads with
> their
> > attributes can be added, but the default still works.
> 
> I like this, but allow me to play devil's advocate for a second.  There
> might be a few flies in the ointment.  The dynamic nature of LAR forces
> us to consider complex scenarios that otherwise wouldn't be a factor.
> What if you want to change the default payload?  If the name isn't shorter
> then payloads/default, then there will be much shifting of bytes, which
> is dangerous on the ROM (or rather, no less dangerous then writing
> a new ROM).

Right now we don't do partial writes, do we?  If we did, this isn't
dangerous as long as we rewrite the entire lar entry, is it?

> The other thing that concerns me is that the person building the LAR needs
> to make the conscious decision to name one of the payloads
> payload/default.

No matter what we choose to do, the user will have to make a conscious
decision about which payload is default.  If there isn't a default it will
still work, and they'll be more careful next time they build the ROM. :)

> Sure we could make the LAR binary handle the magic, but that would
> be just another flag in a cast of thousands.  We already experience
> a bit of this pain already.  In lieu of a magic number in the LAR header
> or in the SELF header, bayou currently checks for the name prefix
> 'payload/'
> and assumes that is a payload.  I have already forgotten to append
> 'payload/' several times (until I got the Makefile to do it for me).
> I believe that this will cause problems down the road - not everybody
> will be using buildrom.

You're right, we still have considerable evangelism to do.

> All that said, I think that this is the best suggestion so far - it is
> easy to implement, and at least gets us further down the path.

I'm looking forward to seeing the next incarnation.

Thanks,
Myles