jordan.crouse at amd.com
Wed Apr 16 17:54:48 CEST 2008
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
> > 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.
Systems Software Development Engineer
Advanced Micro Devices, Inc.
More information about the coreboot