[coreboot] Time for a new project

Segher Boessenkool segher at kernel.crashing.org
Sun Apr 13 04:15:34 CEST 2008

> I'm not going to get into the ELF or not debate.

FWIW, neither am I.  I have no stake in this ELF vs. SELF "battle";
the only thing I'm trying to do here is to make sure the final decision
is based on correct information.

> 1) We cannot depend on the payload writer to do the right thing.  All
> we can ask for is a ELF file.  If there is post processing work that 
> needs
> to be done, we need to do it ourselves.

And the "post-processor" can either write SELF, or an ELF with
restrictions (PHDRs have to come early, for example).  It's about
the same thing: you have to use the linker in the same way either
way, to arrive at the orignal ELF file.  And then you post-process
it in such a way that it will be easier/nicer to load in the coreboot

The main difference between the formats AFAICS is that ELF is an old,
well-defined, well-understood, matured format, while SELF is a hacky
new thing that looks really simple now.  My fear is that it will turn
out it needs some of the features of ELF later on, and it might not
be feasible to put those in in a nice way anymore by then.

> 2) The ELF loader needs to be simple, fast, small, and licensed with 
> BSD so
> it can be included in libpayload

Sure, it's just a tiny piece of code either way, so I don't see this
issue as an issue.

> 3) We need a equivalent solution for the NAME segment in SELF - the
> payload chooser must be able to get a human friendly name for each
> payload without decompressing the entire payload into memory.

If you want this name to be part of the binary (and we can discuss
endlessly whether that is a good idea or not -- let's just accept the
answer is "yes" :-) ), for ELF, you would do this using a PT_NOTE
normally.  It's easy to make sure that note sits at the start of the
file, too.

>> As far as I can see, SELF saves about 100 bytes over ELF, at the cost
>> of a lot of flexibility (only one code/data/bss/notes section, to 
>> start
>> with), and a bunch of important header data is missing, too 
>> (endianness,
>> word size, architecture).
> You can have as many code/data/bss/notes sections as you wish.

Oh, good.

> The only
> requirement is that there only be one ENTRY segment, which is fine,
> because thats exactly how many entry points we have.

Would it not make sense to put the entry point info in the file header,
not in a segment header, then?

> We already know what endianism, word size and architecture we're going 
> to
> run on - SELF is not intended to be portable.

It is nice to have a file header that describes the basic format of
the file.  You don't *have* to check it if you do not want to.

One important case where you actually want to *use* this info is when
you have an architecture that can execute both 32-bit and 64-bit 


More information about the coreboot mailing list