[coreboot] Time for a new project

[Jordan Crouse]

On 13/04/08 15:44 +0200, Philip Schulz wrote:
> I wonder what issues with PowerPC you're expecting? Shouldn't you have
> the header members stored in the endianness of the target
> architecture? I.e. if you construct a SELF file for i386, then of
> course the header fields should be little endian, even if you chose to
> construct the file on a PowerPC machine. But not if you want to use
> the SELF file on a big endian architecture - then the headers should
> be big endian.

Thats true, they will be.  But there is a problem:

The problem is that the loader code will not change.
When the loader reads the type value, it will differ depending on
endianism.  As an example, 'CODE' will be equivalent to
0x45444F43 on a little endian machine, and 0x434F4445 on
a big endian machine.  This causes obvious issues in the code.
By dictating that all the header values should be in little endian
we avoid this problem.

> In a later email in this thread, you say this:
> 
> 2008/4/13, Jordan Crouse <jordan.crouse at amd.com>:
> [...]
> >  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.
> 
> I interpreted the above like this: When constructing a SELF file you
> will always know what architecture the SELF file will be used on and
> you therefore don't need an explicit endianness flag. You don't need
> it b/c you implicitly assume the byte order of the target
> architecture.

Thats true.  But again, like I said, what concerns us is that endianism
affects the order in which the bytes will be stored in the header 

This has nothing to do with how the actual data and code is organized
- we have to assume that is correctly formatted for the system, otherwise
the payload won't run.  Specifying that makes no sense - is somebody
really going to take up valuable ROM space with a payload for another
architecture? 

> So I may have misunderstood your emails, but please don't force the
> SELF headers to a specific endianness. I don't think it's necessary
> and doing so will cause unnecessary work as soon as you're trying to
> use the format on an architecture w/ different endianness. See EFI and
> especially TianoCore.

The endianism is specified by the processor, not the software.
A x86 is little endian, forever more.  

And since v3 only works on an x86, we could ignore it for now.  But
we know that the problem exists, and we might as well account for it
now.  By specifying it as little endian, we do put other architectures
at a disadvantage.  But none of those other architectures are in play
for a very long time.  You have to play to your strengths.

Jordan

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.