mylesgw at gmail.com
Wed Apr 16 19:36:08 CEST 2008
> -----Original Message-----
> From: Jordan Crouse [mailto:jordan.crouse at amd.com]
> Sent: Wednesday, April 16, 2008 10:26 AM
> To: Myles Watson
> Cc: coreboot at coreboot.org
> Subject: Re: SELF/ELF/LAR
> 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
> > > 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
> > > > > 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.
> > > > > 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
> > > I would expect that in a typical multiple payload scenario, we 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
> > 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
> > 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.
Here's my opinion based on the discussion so far:
I like the idea of SELF except as a file format. I think SELF should stay
internal to LAR. With the information in SELF we can create a valid ELF
file at extraction time. That way we only have one way to get a Payload
into LAR (parsing an ELF) and one way out. Coreboot code only needs to know
about the SELF format, and we have many fewer code paths to test and
My fear was that LAR was going to need to parse ELF and SELF, and so was
Coreboot. I think at least one of those pathways would bit rot quickly.
More information about the coreboot