Re: Could the DTS experts look at this?

On Tue, Feb 12, 2008 at 01:45:39PM -0600, Timur Tabi wrote:

Grant Likely wrote:

[snip]

quoted

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.

Correct.  Just as you must give a dtb with the information to the
correct board to a bootloader or things won't work.  Changing this is
not within the reasonable scope of what dtbs will do.

 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.

quoted

quoted

quoted

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.

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?

You don't.  If your agent takes a dtb, dtb layout and agent must
match.

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?

That's a perfectly acceptable option - and it's what I'd expect if a
real OF decided to add support for flattened device trees (which might
happen with ePAPR).  libfdt's serial-write functions are designed for
exactly this use case.

In fact, in one way of looking at it that's always what happens: the
dtb format is defined for passing hardware information from the
bootloader to the kernel; nothing else.  Passing a dtb *into* the
bootloader is just a bootloader implementation convenience, because
the possible variations on an output tree are small, so it's useful to
have a skeleton tree built-in.  But in order for the bootloader to
process those variations correctly, the skeleton *must* be in the
right format.  dtb input to a bootloader must match the bootloaders
expectations.  This has always been true, and will continue to be
true.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson