removing get_immrbase()??

[Wrobel Heinz-R39252]

> > We've run into plenty of situations where customers will update the 
> > kernel, but insist that U-Boot and the device tree remain unchanged.
> 
> when?  I'm not aware of any significant # of cases that 
> customer is willing to update kernel & not dts.  Usually if 
> they are willing to update kernel they tend to be willing to 
> update everything.

I recently fried a U-Boot flash on a machine at home when upgrading and
the machine sits there and is dead of course. Luckily that machine
doesn't have to be up 24x7, so I can wait until I have time to fix the
situation ... and I can either pull the socketed flash or hook up a JTAG
debugger.

But Freescale or other eval(!) boards or isolated Power Architecture
based home use machines like my fried one should not be a reference for
this kind of discussion.

I see a very common scenario with Telecom/Networking customers. They
have a boot flash with firmware and basic startup/BIST SW which they do
not really ever want to touch at all even if they should after it
shipped. If a remote upgrade on just a few out of <n> installed systems
fails, they can send technicians to Mars to pull the board(s), and
service guarantees, and profit, are out the window then. That makes
U-Boot and/or subsequent ultra-low-level startup/BIST SW from the same
boot source *very* firm. If a device-tree is served from there for
whichever reason, then you have a *very* firm device-tree, too.

Then these customers either have a second flash with a filesystem or
more volatile images in the sense that they see that other flash as
upgradable (if they have to), or a physical link to some remote fs that
serves them the kernel and application load. They still do not like
upgrades too much as any upgrade can have service impact. But they do
them when necessary because they know they have a way to revert to
previous or fixed releases remotely as they can always depend on the
original boot loader to be there.

It would not be smart to prohibit any change ever, but we also shouldn't
cause device-tree changes a lot just because we felt like it today. Both
seems a bit extreme.

There must be some middle ground, err'ing towards the conservative side.
A change affecting "lower" levels than the kernel should be very well
thought through, and if it is necessary, we should strive to keep
compatibility to a level that makes sense and possibly eases a
transition over some time.

If a few clearly marked code lines (with a possibly marked planned max
lifetime) ease compatibility and transition, they should be considered.

Hope this helps

Heinz