[coreboot] SELF/ELF/LAR

[Jordan Crouse]

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.  

Jordan
-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.