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

[Laurent Gregoire]

Hi Timur,

On Tue, 2009-02-24 at 15:26 -0600, Timur Tabi wrote:
> Laurent,
> 
> I'm very interested in the work you are planning on doing.  How are
> you planning on integrating device-tree support into the kernel?  That
> is, are you going to be adding the code so that's local to your ARM
> platforms, or are you looking to make the device tree API available
> for all ARM?
> 

We would like to use the device-tree for three purposes:

1. Device-specific parameters like device ID, bluetooth mac address...
2. Platform-device activation and parametrization
3. GPIO pins configuration

We're in research phase, but the current plan is to focus first on point
1 and 2, point 2 being only used for *some* of the platform-devices. We
will use the code only in our platform-specific code for now, ie. our
specific machine_init() routine.

We plan also to stick to the use of the flattened device-tree format,
not using or building any expanded version, and once platform-device
initialization is done to forget about the device-tree data.

We ported some part of the fdt parsing routine from the ppc arch branch,
but we modified the parsing library interface to use external iterators
instead of callbacks. Once validated internally, this library could be
easily moved if needed to some more generic place like arch/arm/kernel.

The loading of the platform-device is done using a callback function,
setup via an arch_init function, with a keyword argument. This keyword
is used as a key to a specific node in the device-tree. If the keyword
is present in the device-tree, the callback is called, with the
responsibility of setting-up specific parameters (through the use of the
fdt library) and registering any needed platform-device. Thus we do not
enforce any one-to-one mapping between device-tree node and
platform-devices, even if it will be probably most of the time the case.
The platform-device initialization order is given by device-tree order.

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

HTH,

--Laurent