[coreboot] LinuxTag 2008 Status
jordan.crouse at amd.com
Tue Jun 3 22:22:23 CEST 2008
On 03/06/08 13:03 -0600, Myles Watson wrote:
> > -----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?
You are right, we don't do partial writes right now, but it is the
800 pound gorilla in the room. Everything about the design of LAR
is based around the concept of partial writes, so we really can't
One of our problems is that we have made partial writes a high
priority, but we haven't clearly defined how they are going to work.
Adding new code to an existing ROM isn't a difficult concept, but when
it comes to changing or replacing blobs, it gets very vague, and IMHO
very scary. None of our current v3 platforms support fallback, so just
one blown sector is death, even if LAR can detect it and print
a "gee, we're sorry but the ROM is corrupted message". I am having
trouble being convinced that this is any safer then writing a full ROM,
but thats off-topic for this message.
The point is that we have to always be aware that the LAR could change
from boot to boot. If we need to support a dynamic LAR, then we need
to keep the bayou related complexity to a minimum, or at least as low
as the circumstances will allow.
> > 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. :)
Indeed. But I think my main concern is that on one hand we treat
payloads like any other LAR blob, but on the other hand we put
restrictions on the name and make it the developers burden to get it
> > 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.
I like your moxie! :)
Systems Software Development Engineer
Advanced Micro Devices, Inc.
More information about the coreboot