[coreboot] LinuxTag 2008 Status
jordan.crouse at amd.com
Tue Jun 3 01:48:05 CEST 2008
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).
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.
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.
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.
Systems Software Development Engineer
Advanced Micro Devices, Inc.
More information about the coreboot