jordan.crouse at amd.com
Wed Apr 16 18:25:59 CEST 2008
On 16/04/08 10:02 -0600, Myles Watson wrote:
> > -----Original Message-----
> > From: Jordan Crouse [mailto:jordan.crouse at amd.com]
> > Sent: Wednesday, April 16, 2008 9:55 AM
> > To: Myles Watson
> > Cc: coreboot at coreboot.org
> > Subject: Re: SELF/ELF/LAR
> > On 16/04/08 07:12 -0600, Myles Watson wrote:
> > > > > That's where my confusion comes in. Bad ELF files which are parsed
> > and
> > > > > added to the LAR cause failures at build time. Bad ELF files
> > inserted
> > > > > without being parsed cause failures at boot time.
> > > > >
> > > > > I prefer Build-time failures to Boot-time failures.
> > > >
> > > > There is no doubt that some parsing has to happen. It is highly
> > unlikely
> > > > that any arbitrary ELF will be optimized for coreboot.
> > >
> > > I'm not sure everyone agrees with that statement yet.
> > Okay, let me put it another way. Its not a guarantee. We might
> > recommend that you use something like libpayload that has a clue,
> > but it it by no means mandatory. So we have to account for the worst
> > case scenario.
> > > > The question
> > > > isn't that it will be parsed, but rather what will the end result of
> > > > said parse be? The main problem I have with the current scheme is
> > that
> > > > when we move to three or four payloads, I think that managing the
> > > > segments and walking the lar will become very costly.
> > > >
> > > > I would rather see us go back to a single LAR file per payload. Thats
> > > > not to say that LAR file wouldn't be pre-processed.
> > >
> > > It's usually 3 segments per ELF, right? How many payloads are we
> > expecting
> > > each ROM file to have? How much time are we talking about?
> > Again, there is no guarantee. If we embed the name into the .notes
> > section,
> > we have at least 4 segments - possibly even more depending on the
> > complexity
> > of the payload (honestly, most of our payloads today are pretty simple).
> > I would expect that in a typical multiple payload scenario, we would would
> > have at least three payloads - the chooser (bayou), and two payloads
> > to choose from.
> Would an extra field in LAR that points to the end of that payload's
> segments, and a name field suffice? I guess that becomes a small wrapper
> quickly. What if we kept what we have and added a wrapper (containing a
> name and a size) at every path separator?
> I like the current ability to compress payload segments based on the best
> compression for that segment. It seems like we lose that if we put ELF
> files (or a simple alternative) into the LAR without parsing them.
I totaly agree - and SELF reflects that behavior without the additional
LAR segments. I'm not even sure if Segher is promoting just tossing it
into the LAR without parsing, but I don't want to put words in his mouth.
Systems Software Development Engineer
Advanced Micro Devices, Inc.
More information about the coreboot