On Wed, 19 Jan 2011 10:43:02 +0000 Dave Martin <[email protected]> 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? > > 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. It's simpler and faster to unconditionally swap a word as you load it, especially on instruction sets with swapping support, than it is to dynamically decide whether to swap. It would be nice if GCC would let data structures be annotated with endianness, so that it would automatically swap when needed, though. Look at the I/O accessors in drivers/dma/fsldma.h -- that complexity wouldn't have been necessary if Freescale hadn't "fixed" the endianness when sticking the DMA engine in a new chip family. What about bi-endian hardware? Is it possible you might ever want to boot a kernel in one endianness when the device tree was generated assuming the opposite choice? -Scott _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
