device trees.

[Grant Likely]

On Mon, May 11, 2009 at 10:45 AM, David H. Lynch Jr. <dhlii at dlasys.net> wrote:
> Grant Likely wrote:
>>
>>>    We are very actively headed in the opposite direction. It is my/our
>>> intention to have a single linux executable that works accross
>>>    everyone of our cards and everyone of our bitfiles.
>>>
>>
>> That is the direction we are already going in.  U-Boot supports this.
>> In fact, I can build a single kernel image which will boot on all of
>> my MPC5200 boards, and my MPC83xx boards.  Similarly, if I have u-boot
>> running on a Virtex board, I can build a single image which will boot
>> all of them if the correct .dtb is passed to it.
>>
>    I was not aware that u-boot was currently doing that, but I was
> aware that was possible.
>    It is the most useful alternative to simple image.
>    I was not specifically trying to criticize simple image.
>    My problem is not with specific means of handling device trees.
>    It is that it is a one size fits all solution, and it is not
> sufficiently flexible for that.

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.

>> You *could* generate the device tree dynamically, but I think that is
>> a path of diminishing returns considering that generating a .dts at
>> the same time as bitstream creation time is cheap and it is small.  At
>> one time Steven Neuendorffer was playing with a scheme to preload a
>> section of BRAM with a gzipped .dtb so that the correct device tree is
>> always present.  I really liked the idea, and I'd like to try to
>> pursue it.
>>
>    I would prefer not to waste bram by filling it with a device tree.
>    The best alternative to creating the device tree dynamically would
> be to
>    append the devicetree to the bitimage in a way the boot loader could
> always find it.

That sounds like a good solution to me.

As for using up BRAM, a gzipped dtb image is smaller than 2k and it
can be reclaimed for other uses after the kernel has booted.  That may
not help your situation, but for my use cases the tradeoff works.

>    Regardless it still makes my point.  The problem with devicetrees as
> they are is that they handle probably 98% of all cases well.
>    The remaining 2% are a mess.

No it isn't.  It is expected that firmware will fixup the device tree
data with board specific values.  This is intentional.  The device
tree is simply the bearer.  It makes no determination about where the
data comes from.

>    lots of .dtb files lying arround is only a better solution than
> simpleimage.
>    I will guarantee that unless they are welded together the wrong
> device tree will get used with the wrong bit file.

I agree.

>    Inevitably I will make that mistake myself occasionally and waste
> hours or possibly days trying to debug it.
>    And if I will do it rarely clients will do it frequently.
>
>    In my expereince if you create a situation where confusion can exist
> it will.
>
>    It is also my expereince that time spend coding a solution to a
> common client problem is well spent.
>    If it takes me a week to work out dynamically creating a device
> tree, that ill likely save many weeks of
>    support headaches.

Again, it doesn't sound like you want dynamic *creation* of device
trees.  It sounds like you want a reliable way to make sure the
bitstream is welded together with the correct dtb, preferably within
the Xilinx toolchain.

>    Even if I do not end up creating the device tree dynamically, I am
> likely to end up at a minimum doing some validation on it.
>    i.e. once the bitfile is loaded scanning the device tree and probing
> to ascertain that the hardware that I am supposed to expect
>    it really present.

If you like.

>    ultimately devicetrees are supposed to be a database not a black box.

I don't understand what you mean by this statement.

>    Anyway, all I was looking for was a leg up on figuring out how to do
> what I want with them. Rather than starting from scratch.
>    I am not looking to be convinced that I am approaching this all wrong.
>    If you are happy with what you have - great. I am not.
>    While I was not looking to restart a great debate over device trees
> - I do not actually think they are a bad idea.

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.

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