[coreboot] Time for a new project

[Segher Boessenkool]

>>> 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.
>
> But if it was part of the binary, then we would have to decompress
> at least part of the binary to find it, no?

That depends on if and how you compress it.  If you don't compress
the headers (like in the proposed SELF format, iirc), you obviously
do not have to decompress those headers.  The same can be done for
any binary format.

Decompression is *cheap*, btw -- the slowest thing *by far* is accessing
the ROM to get the compressed bytes.  Obviously, it is stupid to 
decompress
the whole file if you only want to see the header.

>>> 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?
>
> Well - first of all, I think you are confused.  There is no SELF file -
> you won't see a .self file by itself.  It is an internal format, 
> suitable
> only for inclusion in a LAR.

Same difference.

> This is part of the simplicity.  So no
> file means no file header.

But you know very well what I mean, I hope.

> But even if there was, I would argue that
> having the load address in the segment list isn't really hurting us.

Sure.  I'm sneakily trying to show that SELF is really just the
same as ELF in every way, only different.

> It pulls double duty - it identifies the end of the segment list,
> and it gives us the load address, right when we need it, after we
> have finished loading the data and code.

While in general it is a Really Bad Idea(tm) to do these cute
"double duty" things, I can't see how this would come and bite
us later.  Then again, I've never been great at predicting the
future.  "Just Don't Do It".

>> 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
>> programs.
>
> Again - not a file format, so no file header.

Same difference.

> And I would argue that
> if we ever reach the point where we legitmately think that we want
> to start a payload in 64 bit mode,

For AMD64, ideally coreboot would run in 64-bit mode a few hundred
insns after cold boot, IMHO.  Hey, I can dream :-)

On some other architectures you don't have any choice: on PowerPC
for example, you *have* to run any supervisor/hypervisor mode code
in 64-bit mode (on 64-bit capable processors).  You might still
want 32-bit payloads though (for (data-)cache footprint savings,
for example, or to have a common payload binary between all systems).

Aaaaaanyway...  It's useful information, the current format provides
it, it would be a shame to lose it (and it would be even worse to have
to add it back in, later).

> that the architecture flag should
> probably be in the LAR header, and not in the SELF.

Now I am confused.  Are you arguing that SELF is an integral part of
LAR, or not?


Segher