Re: device trees.

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

On Mon, May 11, 2009 at 11:22:21PM -0600, Grant Likely wrote:
> On Mon, May 11, 2009 at 7:12 PM, David Gibson
> <david@gibson.dropbear.id.au> wrote:
> > On Mon, May 11, 2009 at 05:09:27PM -0600, Grant Likely wrote:
> >> In other words; having your bootloader support FDT is preferred, but
> >> not required.
> >
> > I wouldn't even go so far as to say it's preferred.  IMO, people have
> > gone a bit prematurely keen on moving devtree handling into the
> > firmware.  Putting it in the firmware has a number of advantages, but
> > it also has a number of non-trivial disadvantages.
> 
> I disagree.  The more I work with it, the more I appreciate the
> advantage of decoupling the kernel image file from the hardware
> description.  It is valuable being able to build a single image file
> that boots on a wide range of boards because the device tree passed in
> by firmware.

Heh, where all my work in the embedded space has led me to more and
more appreciate the fact that firmware is almost invariably crap, and
that it's therefore best not to trust anything it tells you.

> I'm not downplaying the disadvantages and problems, but I still hold
> the view that the striving for generic multiplatform kernel images is
> worth the effort.
> 
> ... but I do agree that hard linking the .dtb into firmware, or making
> the .dtb hard to upgrade is the way of madness.

Ah, we're talking at cross purposes a bit then.  Yeah, I'm talking
about the situation where the dtb is part of the firmware, or at least
as difficult / inconvenient to update as the firmware.  If the dtb is
separate from the kernel, but as easy to update / switch as the
kernel, that is indeed a very nice setup.

-- 
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