RFC: Host-endian device tree format

[Dave Martin]

On Wed, Jan 19, 2011 at 3:52 PM, Grant Likely <grant.likely at secretlab.ca> wrote:
> On Wed, Jan 19, 2011 at 8:41 AM, Nicolas Pitre <nicolas.pitre at linaro.org> wrote:
>> On Wed, 19 Jan 2011, Dave Martin wrote:
>>> On Wed, Jan 19, 2011 at 1:41 PM, Grant Likely <grant.likely at secretlab.ca> wrote:
>>> > The dtb isn't so much bigendian as it is network byte order.
>>>
>>> (For me, "network byte order" is a euphemism ... <insert
>>> unconstructive rant here>)
>>
>> I concur.
>
> meh. it's all about conventions.  When talking about external data, it
> is far more important for everyone to agree on the same representation
> than it is to tailor to each platforms preferences.  That said, rant
> away!  I love a good tangent.

I guess a good example of what I mean is ELF - the endianness of an
ELF image is discoverable, and cross tools do exist -- but because ELF
images are strongly bound to their target platform, running the image
takes precedence over the simplicity of the tools: so the images are
specified in such a way that they can always be host-endian for the
machine they run on, without creating format ambiguities.

Of course, it's stretching things rather a lot to claim that fdt
parsing is performance critical ... or that ELF cross tools work well
in all host/target combinations ... rather it's a niggle.

So, I'm happy as-is.  It was just tempting to rock the boat a bit to
make sure everyone has their sea legs :)

Cheers
---Dave