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