device trees.

[Grant Likely]

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.

Word of warning; if you do define your own format, be very very very
careful.  Otherwise you end up with something subtly broken and not
future proof.  This is one of the reasons adding FDT support to your
firmware is preferred; these issues have already been thought about.

>    Though I still have an issue. One of the problem with 98% solutions,
> is that they result in a chain of work arrounds for
>    the other 2%. Instead of one case or two cases, you end up with a
> dozen cases each handling increasingly tiny slivers.
>    And it becomes increasingly easy to claim that the problem is with
> the slivers not the broad solution.

No, it's not.  Everything you need to do can be done within the
bootwrapper if you so desire, passing data in whatever format you
like.

>    I am not sure what you are saying here ?
>    By firmware do you mean bootloader ? Or do you mean bitfiles ?

Yes, I'm using the terms "firmware" and "bootloader" interchangeably.

>> I still don't understand what you're worried about starting an arguing
>> about.  Pretty much any of the PowerPC maintainers can point at warts
>> and problems in the current handling of device trees.  I'm not
>> particularly happy with simpleImage (and I wrote it), but it takes
>> time and effort to write something more capable.
>>
>    I was not trying to start an argument, my initial question was
>
>   "Is there an example somewhere that shows building a device tree on the fly ?"
>
>   The responses have questioned why I want to do that rather than how can I do that.
>   I was not actually seeking a debate over the merit of device trees, or u-boot, or libdft, or ....

... but the questions were necessary to understand your problem set.
I cannot give good advice without understanding.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.