Of the device tree binary format endianness on little-endian platform

[Laurent Gregoire]

On Thu, 2009-02-26 at 11:52 +1100, David Gibson wrote:
> If you're working exclusively with the flattened tree, then please use
> libfdt as your parsing library.  It's not used in the powerpc kernel
> proper, because that's based on an expanded tree, but it is used in
> the powerpc bootwrapper, see arch/powerpc/boot/libfdt.  That's just a
> copy of the upstream version that's part of the dtc tree.  If ARM
> starts using this as well we can move it to lib/ or some other
> non-arch-specific location.
> 
> If you need to extend libfdt, that's fine - but talk to me about
> getting your extensions upstream.  The whole idea is that it gets
> extended to be the flat tree parsing library of choice.

I fully agree with this, that's the reason why we currently work on our
specific platform for now. Concerning the change in the interface, that
shouldn't have a big influence on any eventual future merge as the
ppc/libfdt main branch is also using external iterator and is
endian-aware. We'll keep that in mind anyway.

> I don't entirely follow what you're doing here, but it sounds like it
> might not be quite correct.  The device tree should always (well,
> nearly always) describe the hardware, *not* Linux or driver specific
> information.  Generally drivers will use the "compatible" property to
> determine if a device tree node is relevant to them.

I think there is a bit of misunderstanding here. Our initial goal is not
to port the device-tree framework to ARM, even if it would be nice to do
so. We face a specific issue on our range of devices which is to
personalize them with device-specific and model-specific information,
not board-specific. We realized that the device-tree format was
well-suited for what we wanted to do, so we plan to use the device-tree
*format*, not *framework*. Taking this into account, this is an
opportunity to also parametrize some platform-devices using the same
system, but we didn't initially planned to make a whole redesign of ARM
platform-device initialization like the one which is done on PPC.

Anyhow, any feedback on porting device-tree on some other architecture
is welcomed and somehow we need to start somewhere. So even if what we
do won't be portable/ported to be the next ARM standard it could be
useful to iron-out any arch-dependencies on the system and give some
momentum on the device-tree usage.

> > The platform-device initialization order is given by device-tree order.
> 
> This is not usually a good idea.  Flattened device trees do have an
> order, but for real OF trees, the tree order is not well defined, so
> it's generally best not to use the order to control initialization,
> but instead to use explicit content to control order, if it's
> important.

Good point. but as I said above we'll probably not rely too much on this
anyway.

> > Also we noticed the lack of type information in device-tree binary
> > format (could be needed for exporting values to user-land through
> > something like sysfs, to have human-readable integer values in scripts -
> > also big-endian integers have to be converted).
> 
> Yes, the device tree structure treats property values as "bag of
> bytes".  It's assumed that you need to know the binding for a given
> node/property - which describes the format of the content - in order
> to correctly interpret it.

OK, I consider this to be a "feature" then ;). But that rules out any
automated human-readable export of device-tree properties through
something like sysfs though.

Laurent GREGOIRE
Embedded Software Engineering | TomTom | www.tomtom.com