mylesgw at gmail.com
Wed Apr 16 18:02:35 CEST 2008
> -----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
> > > > added to the LAR cause failures at build time. Bad ELF files
> > > > 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
> > > 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
> > > 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
> > 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
> we have at least 4 segments - possibly even more depending on the
> 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.
More information about the coreboot