device trees.

[David Gibson]

On Mon, May 11, 2009 at 05:09:27PM -0600, Grant Likely wrote:
> On Mon, May 11, 2009 at 3:38 PM, David H. Lynch Jr. <dhlii at dlasys.net> wrote:
> > Grant Likely wrote:
> >>
> >> What do you mean by "one size fits all solution?"
> >>
> >> The kernel doesn't care where the device tree comes from.  All it
> >> cares about is that by the time the kernel is started the device tree
> >> must be fully formed and populated.  It can be completely pre-canned
> >> (like simpleImage), it can be modified by firmware (like u-boot), or
> >> it can be generated from scratch (like with real OpenFirmware).  There
> >> is lots of flexibility on how to handle it.
> >>
> >>
> > First device trees are now the ONLY means of  passing information to the
> > kernel.
> > By definition that means it is a one size fits all solution.
> > While there is nothing inherently wrong with that, solutions intended to
> > meet all circumstances need to be
> > simple, powerful, and flexible. They need to work well 100% of the time
> > not 98%.
> >
> > Not only is the device tree expected to pass static hardware
> > configuration information, but it is the sole means of passing anything.
> > As an example Command lines are to be in the device tree.
> > Everything is supposed to be in the device tree, whether that
> > information is static or dynamic, whether it is hardware information,
> > or user choices.
> 
> It is the sole means of passing anything *to the kernel*.  You can
> pass whatever you like to the bootwrapper.  :-)
> 
> >    That means that whether you are in a Sun or Apple Desktop or a
> > system with the no flash and barely enough resources to run Linux,
> > you still may have to manipulate the device tree.
> 
> ...or if you really are constrained, then define a format for the data
> you want to pass, pass it to the bootwrapper along with the device
> tree, and use the bootwrapper (which already has libfdt) to update the
> device tree.  cuImage targets do this to support older u-boots which
> don't understand device trees.  You are not forced to put device tree
> support in your firmware.
> 
> 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.

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