removing get_immrbase()??

Anton Vorontsov avorontsov at
Fri Apr 24 02:54:30 EST 2009

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

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?


Anton Vorontsov
email: cbouatmailru at

More information about the Linuxppc-dev mailing list