On Thu, Apr 23, 2009 at 09:02:49AM -0500, Timur Tabi wrote: > Anton Vorontsov wrote: > > > And note that most developers are using up-to-date firmwares > > (U-Boots), device trees, and kernels. > > Developers? Yes. > End-users? No.
If end-users upgraded the kernel on some FSL board, then there should be no technical problem upgrading device tree too. > Updating U-Boot itself is often unacceptable for end-users. There's > also a strong connection between U-Boot and the device tree. That > connection gets stronger with every release, as U-Boot makes more and > more changes to the device tree before passing it to the kernel. This > means that if you cannot update U-Boot, you might not be able to update > your device tree either. As I said, this case is a separate matter. Just as device_type = "soc", yes we should avoid removing it. But if we 100% sure that our device tree changes won't break compatibility with officially supported firmware, then IMO we should just go ahead with the changes. > We've run into plenty of situations where customers will update the > kernel, but insist that U-Boot That I can understand. > and the device tree remain unchanged. That I can't. I wonder what was the rationale behind this. > > And that means that old > > device-tree + new kernel combination is left untested for years. > > And untested stuff is broken stuff, by definition. > > I'm not saying that should officially support it. I'm saying we should > make an effort to minimize the problem. That doesn't work in practice. I bet if I'll try booting recent Linux with FSL-provided device-tree on, say, MPC8323E-RDB it simply won't boot. -- 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