Re: Could the DTS experts look at this?

On Feb 12, 2008 12:45 PM, Timur Tabi [off-list ref] wrote:

Grant Likely wrote:

quoted

Then use a local version in the data; don't overload the purpose of
the dtb version.

I don't know what you mean by that.

I'm saying that the dtb version is to describe the binary format of
the dtb; not the content.  Using it to say "this dtb contains data
that needs to be massaged in a particular way" is using (overloading)
the dtb version for a different and orthogonal purpose.

quoted

And when something comes along that doesn't fit into that model?  Add
more constructs?

If necessary, yes.  What's wrong with expanding the power of the device tree
format when it solves more problems?

Nothing at all; but the flipside of that is it should only be done
when it is the appropriate place to do so.

quoted

 I say better to handle that within the existing data
format.

And the point I've been trying to make is that we have real problems today that
cannot be solved elegantly with the current device tree problem.  Having
board-specific code in U-Boot that is hard-coded to look for specific nodes in
the device tree, and making hard-coded edits on that tree, is *not* elegant.

quoted

 If we get it wrong, then we just change the affected device
trees and boot loaders.  We don't have to upgrade every platform that
uses dt blobs.

Only the platforms that need to take advantage of conditional nodes need to be
upgraded in the first place.  Most platforms are happy with just one device tree.

quoted

quoted

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.

That's not a dtb version issue.  That is a dtb content issue.

Technically, that's true, but ...

quoted

It does
not warrant changing the dtb version number.

Then how do you solve the problem of passing a device tree to a boot loader that
does not know how to parse it properly?  A device tree with these additional
nodes *must* be parsed by a boot loader that is aware of them.  Otherwise, it
will pass the device tree as-is to the kernel without warning.  This is a bad
thing, and steps should be taken to prevent that.  If you can think of a way to
make this happen without changing the version number, I'd love to hear.  All I'm
hearing from you now is denial that this is a problem.

I do not deny that it is a problem.  I assert that the proposed
solution does not at all solve the greater problem.  Changing the DTB
version solves the specific problem of a dtb that needs to be modified
being passed into to an older version of u-boot.  This is a very
narrow use case and it is not the greater problem.  The greater
problem is passing the wrong device tree either because of a
u-boot/dtb mismatch or the dtb is for an entirely different board.
Changing the dtb version is just a bandaid fix that makes things more
complex and only provides the illusion of a solution.

Your suggestion of checking for specific property values is a far more
reliable and workable solution.

quoted

Fair enough, and it is also reasonable for the boot loader to look for
a specific property name to decide how to massage the data structure.
This alone does not require a dtb version change.

Current versions of U-Boot do not know how to do this.  So again, I'm asking
you: how do you solve the problem of passing a device tree with additional nodes
to a boot loader that does not know how to parse them properly?  How do you
prevent that old U-Boot from ignoring those nodes?

We don't.  We've got no sane way to do so (except perhaps going ahead
and renaming the soc nodes from soc<chip>@addr to soc@addr.  That will
break almost all existing ports.  :-).  I do not agree that changing
the dtb version is a sane change.

For older u-boots, this is a configuration management problem.  Just
like for current platforms we need to make sure that the kernel is
compiled for the correct platform before trying to boot.  There are no
protections in u-boot to make sure the kernel image matches the arch
yet it all works just fine.

quoted

I'm not missing the point because I disagree entirely with the
addition of conditional expressions to the device tree.  Instead, I
think properties can be added to the device tree that a bootloader can
look for and decide to apply conditions against them which means the
conditions are encoded in the boot loader, not the device tree.  (the
device tree simply contains data which supports the boot loaders
decision; a rather different thing).

Then why bother passing a DTB to the boot loader at all?  Why not just have the
boot loader create the device tree from scratch?

There is absolutely no reason for the boot loader not to create the
device tree from scratch.  dtbs are just more convenient to get up and
running with.  OpenFirmware has been doing that from day one and it
works quite well.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.