On Thu, Apr 23, 2009 at 11:00:48AM -0500, Scott Wood wrote:

On Thu, Apr 23, 2009 at 05:50:05PM +0400, Anton Vorontsov wrote:

quoted

As for Freescale parts, all the reference board I've seen were
very friendly wrt upgrading their device-trees, i.e. none of
the boards were shipping with device-tree soldered into the
firmware.

But many of them have broken when a dtb that u-boot didn't like was
inserted.

Yes, I agree here. And I'm not going to contradict on this
matter. If we stick with these two rules, I think we should always
be OK:

(1) We should avoid any changes that might break compatibility with
    an officially supported firmware;
(2) Breaking "new Linux" <-> "old device tree" compatibility should
    be OK if (1) is satisfied.

Note that this applies only for targets that have no problem w/
device-tree upgrades.

quoted

And note that most developers are using up-to-date firmwares
(U-Boots), device trees, and kernels. 

So then why did we have to make cuImage?

I don't know. I've never used them. ;-) Honestly. But I believe
it's a great stuff for those who use really old and now unsupported
firmwares.

It has nothing to do with device-tree changes though. We can easily
maintain device-tree compatibility w/ firmwares, but what is the
point in maintaining Linux' compatibility for older device trees
when you can easily upgrade it?

That is, I still don't get why somebody don't want to upgrade
device tree along with Linux (assuming it won't cause breakages in
the firmware)?

[...]

quoted

Sure, there is a completely different story wrt device-tree
changes that might break firmwares. And that I believe we'd
better avoid. For example device_type = "soc", if removed,
most firmwares would not fix-up {clock,bus}-frequency properties.

Even if the given change may not break the firmware, it could force an
update in which a prior change breaks the firmware.

I'm not sure I'm following here. Could you give an example?

Thanks,

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2