Re: Could the DTS experts look at this?

Grant Likely wrote:

On Feb 12, 2008 8:44 AM, Timur Tabi [off-list ref] wrote:

quoted

Arnd Bergmann wrote:

quoted

On Tuesday 12 February 2008, David Gibson wrote:

quoted

Or to expand.  It's relatively easy now to just include multiple nodes
in the tree and either delete or nop some of them out conditionally
using libfdt.

Yes, but what better place to store the conditions than in the device tree
itself?  How would libfdt know where the conditions are?  Do you want to have
two binary blobs?

The transient state of the dts before it is handed to the kernel
proper is almost irrelevant.  It is totally reasonable to add in
whatever properties/nodes that are needed to *eventually* describe the
hardware correctly.  Heck, we already do this will all dts files that
go through u-boot is a simple sense.  We put placeholder properties
for mac addresses and bus frequencies, but u-boot fills them in.

I agree with that.

However, if a designer does write a device tree containing more nodes
than is needed, then it is also the responsibility of that designer to
make sure the boot loader can use that tree to generate a real
description of hardware.  

No problem here.

This requires coordination and
documentation, but id does not requires special formatting or
versioning of the device tree blob.

Unless the mechanism by which the designer ensures that the boot loader presents 
a proper device tree to the kernel requires special versioning.

The dtb is a data structure, not a programming language.

But we have a problem with the current device tree definition that makes it 
difficult to use in real-world situations.  The current "solution" is to have 
multiple DTBs, each one covering a different variant of the hardware.  My 
proposal is to expand the definition of the DTB to allow the boot loader to 
modify it in a standard manner.  I believe that such a change would be both 
useful and not problematic.

 >  I think it

is a slippery slope to try and encode conditionals into the structure;

Perhaps, which is why I said it should be simple conditionals - two values and a 
comparison.

but it is entirely reasonable to encode *data* into the dt that helps
make those conditional decisions.

That's okay too, except that if we just add additional nodes that describe 
conditions, then we need to make sure that whatever parses that DTB must also 
parse those additional nodes.  The only way to do that is create a new version 
number, like 18, which is marked as being incompatible with the current version 
(17).  Otherwise, a person could pass that DTB to an old version of U-Boot, and 
U-boot will just pass it on to the kernel as-is.

We've already got that issue.  If you pass the device tree for the
wrong board it will still validate correctly, but the board is not
going to boot.

There's nothing stopping U-Boot today from scanning the device tree and making 
sure the SOC's compatible node is correct.  That's not currently done, but it 
could be.

 >  The device tree must match what the bootloader

expects.  Changing the version number will do nothing to help this.
The version number ensures that the tree is parsable.  It does not
ensure that it is correct.

I think you're missing the point.  If we add conditional expressions to the 
device tree (whether attached to a node or as part of a separate node or 
whatever), we must also add a mechanism to ensure that these conditions are 
parsed by the boot loader.  As far as I know, the only mechanism that can do 
this is the version identifier.

-- 
Timur Tabi
Linux kernel developer at Freescale