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: > > 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. > > 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)? [...] > > 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: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev