mylesgw at gmail.com
Tue Apr 15 18:14:47 CEST 2008
> Code isn't interesting anyway; design / architecture is the problem
> > We are all professionals - we can come to a consensus. Right now,
> > we're trying to figure out if we can make ELF perform the way we need
> > it to perform. If we can be satisfied that it can, then we move on.
> > If we cannot be satisfied, then the core team will have to make a
> > decision to move on to another alternative, and then we can debate the
> > details of SELF or something similar.
> I agree.
> So, what exactly *do* we need here, and *why*?
I think a discussion of where we are and where we want to go would be
helpful. Feel free to correct my status summary.
1. LAR format supports inclusion of:
1. Can be copied out, but only re-used in same size ROM file
b. ELF segments (multiple segments with one entry point, from an
1. Can't be extracted without losing entry point
c. arbitrary blobs
2. Coreboot build process uses the ELF segment idea for
a. initram, stage2
I understand that there is resistance against breaking up ELF files for
payloads. Does this extend to initram and stage2? Is there another way for
the build process?
I'm personally against defining a new file format. I think if we're already
going to be parsing ELF in LAR, another format is just another place to
On extraction: It seems to me that very few end users will want to extract
payloads from a ROM. That seems like a task better suited for developers.
End users would more likely insert an ELF.
Where we want to go:
I'm unclear on this, because I don't understand the resistance to ELF
segments in the LAR.
More information about the coreboot