[coreboot] Time for a new project
jordan.crouse at amd.com
Sun Apr 13 03:15:52 CEST 2008
On 13/04/08 01:18 +0200, Segher Boessenkool wrote:
I'm not going to get into the ELF or not debate. Ron feels passionately
about it, and we developed the SELF idea with that in mind. I personally
don't care if we use ELF or not, but there are certain issues that we need
to make sure are covered:
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.
2) The ELF loader needs to be simple, fast, small, and licensed with BSD so
it can be included in libpayload
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.
Right now, SELF satisfies all these requirements.
> 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. The only
requirement is that there only be one ENTRY segment, which is fine,
because thats exactly how many entry points we have.
We already know what endianism, word size and architecture we're going to
run on - SELF is not intended to be portable. It is constructed when
the LAR is, and is married to that LAR and that LAR only. And before
somebody says something, yes - this is not fool-proof. Somebody will
no doubt manage to screw it up and get the wrong SELF on the wrong
architecture. But I don't like over-architecting to protect fools.
Worrying about specifying the architecture here is the computer science
equivalent of the "Caution, coffee is hot" warning.
Systems Software Development Engineer
Advanced Micro Devices, Inc.
More information about the coreboot