[coreboot] SELF/ELF/LAR

[Myles Watson]

> -----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.

Myles