removing get_immrbase()??
Anton Vorontsov
avorontsov at ru.mvista.com
Fri Apr 24 00:13:47 EST 2009
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: cbouatmailru at gmail.com
irc://irc.freenode.net/bd2
More information about the Linuxppc-dev
mailing list