Re: RFC: Host-endian device tree format

On Jan 19, 2011 3:43 AM, "Dave Martin" [off-list ref] wrote:

Hi all,

Apologies if this has been discussed before--- I don't see an obvious
rebuttal in my quick searching past threads, so I'll just quickly ask
the question:

Could we use host-endianness for the device tree binary blob?

Hi David.

This has been discussed thoroughly and rejected. The dtb isn't so much
bigendian as it is network byte order. While we /could/ switch it for arm,
it creates all kinds of problems with tools and working with .dtb files on
dissimilar platforms.  Plus all the property values must remain in BE
because all the bindings are already defined that way in the OpenFirmware
specifications.

Besides, there is no real advantage to changing it: it already works as-is
on le architectures.  :-)

g.

The fdt binary format seems to lend itself strongly to a host-endian
format: it begins with a word-sized magic number, and when parsing the
device tree every elements type and size is known before that element
is read; furthermore, every element is size-aligned.  Therefore, I
(naively?) presume that a little-endian format should "just work",
simply by flipping the endianness of every element and discarding all
the __be32_to_cpu() type stuff when reading the fdt at boot time.  The
magic number ensures that there's no risk of accidentally reading the
fst in the wrong byte order.

Although it would be necessary to augment the fdt tools to cope with
this, offline tools appear to be the right place to put this
intelligence.  For the kernel to flip the byte order of everything in
the fdt blob every time the system boots just seems unnecessary when
the required endianness is statically known.

Since fdt is new on ARM we have an opportunity to change determine the
binary format now without breaking anything in the field -- we don't
necessarily have to adopt the host-endian format on any other
architectures if it's not desirable.

Any thoughts?

Cheers
---Dave

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Hi,

On Wed, Jan 19, 2011 at 1:41 PM, Grant Likely [off-list ref] wrote:

On Jan 19, 2011 3:43 AM, "Dave Martin" [off-list ref] wrote:

quoted

Hi all,

Apologies if this has been discussed before--- I don't see an obvious
rebuttal in my quick searching past threads, so I'll just quickly ask
the question:

Could we use host-endianness for the device tree binary blob?

Hi David.

This has been discussed thoroughly and rejected.

I thought this may have been the case...

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>)

However I digress... it sounds like you are familiar with the
arguments I would make, and I'm not trying to get into an endianness
war ;)

While we /could/ switch it for arm,
it creates all kinds of problems with tools and working with .dtb files on
dissimilar platforms.  Plus all the property values must remain in BE
because all the bindings are already defined that way in the OpenFirmware
specifications.

OK, agreed -- I guess I might have specified it differently :)  But
since the specs are already written and can't be supplemented without
causing disruption, I guess attempting changes may be more trouble
than it's worth.

Besides, there is no real advantage to changing it: it already works as-is
on le architectures.  :-)

I'm happy to go along with it if nobody sees a benefit in changing
it... the status quo is what it is.

Just wanted to know whether anyone cared / whether an opportunity was
being missed, given that the newness of this stuff on ARM could
present an opportunity.

If this is not the case then that's fine by me.

Cheers
---Dave