Re: removing get_immrbase()??

[David Gibson <david@gibson.dropbear.id.au>]

On Thu, Apr 23, 2009 at 05:50:05PM +0400, Anton Vorontsov wrote:
> On Thu, Apr 23, 2009 at 08:02:20AM -0500, Timur Tabi wrote:
> > David Gibson wrote:
> > 
> > > It's not so much point of view as situation.  Putting the device tree
> > > in the firmware and putting the device tree in the kernel are both
> > > valid choices, with their own distinct advantages and drawbacks. 
> > 
> > I was under the impression that the reason we put the device trees in
> > the kernel is because we didn't have a better place to put them.
> > Keeping them in the kernel repository was just convenient.
> > 
> > So I personally don't consider the *location* of the DTS files to be a
> > basis for deciding what they really mean.
> 
> I'm not sure why are we trying to make things harder for ourselves?
> x86 has a long history fighting with bogus bioses/dmi/acpi tables,
> up to the point where they completely ignore any information that
> BIOS provides, because that information is unreliable or hard to
> deal with.
> 
> With FDT (i.e. not hard-coded OF), we have a great opportunity to
> keep both device tree and Linux code legacyjunk-free.
> 
> All we have to do is to declare one simple thing: don't put
> device-tree into the read-only memory. Upgrading device tree blob
> in the rewritable NOR/NAND flashes is safe in overwhelming cases,
> just as safe as upgrading kernel image in the NOR/NAND.
> 
> And for those who didn't listen our pleases, i.e. for those
> who put device-tree blob into some kind of ROM or dangerous-
> to-upgrade memory or region of memory, we can always provide
> boot wrappers, and thus isolate the legacy stuff. I mean isolate
> it in their small legacy world, if anyone actually cares about
> these cases.

Indeed, this is a large part of the idea for the flattened device
tree.  Which is why I don't understand why when the idea of dtbs has
been floated, everyone seems to have been in a rush to put the blobs
into the firmware.  That's certainly one approach, and a good one for
certain needs (one kernel binary on many platforms, for example), but
putting the blob in the kernel is also an entirely valid approach and
avoids some drawbacks of having the blob in the firmware.

We're never going to get away from having shitty firmwares, but at
least with fdts we can isolate the handling of them from the bulk of
the kernel.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson