[U-Boot-Users] RFC: flattened device tree command

[U-Boot-Users] RFC: flattened device tree command

[Jerry Van Baren]

Wolfgang, Grant, and gentle readers,

A while back I submitted a patch for a new command "oftdump".
<http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/24664>
While it was good in principle, it probably is premature and short 
sighted in implementation.

The command was hacked on top of ft_dump_blob() (common/ft_build.c) and 
required some changes to the same.   Grant objected to the changes as 
suboptimal - I contend they are locally optimal, but that ft_build.c is 
suboptimal.

The linux kernel has its own library functions for
handling flat device trees.  In addition, David Gibson has proposed 
another library (advertised as easier to use):
<http://ozlabs.org/pipermail/linuxppc-dev/2006-November/028596.html>

My RFC has two parts:
1) Peoples' opinion of the relative merits of the current u-boot support 
library vs. the kernel's library vs. David Gibson's library.  My limited 
experience with ft_build.c is that it is suboptimal.  I don't have any 
experience with the linux or David's libraries to form an opinion of them.

2) I see more commands than just dumping the tree, allowing the user to 
manipulate the tree as well.  My current thoughts are to make a new 
command "fdt" (flattened device tree - the Open Firmware genesis appears 
to be depricated) with subcommands like the existing "mii" command.

fdt read <node> - does what my "oftdump" command does
fdt write <node> <value> - allow patching the fdt
   * Writing could get pretty complex with creating nodes
   * Initial implementation would be simply to change existing values

Related to the above discussion, the current ft_build.c/"bootm" code 
takes the blob and augments it with board configuration and env stuff as 
part of the "bootm" command.  The implementation is suboptimal 
(ft_build.c again) in that it is only done as a last thing before 
"bootm" transfers to linux, making it (almost) impossible to dump and 
definitely impossible to interactively poke around in the resulting fdt. 
  I would like to see this integrated done better in u-boot rather than 
simply pasted onto the fdt at the last moment before jumping into linux.

So, in conclusion,
1) I'm not sure if this is truly a RFC or just a brain dump of my 
current thoughts.  Either way, advice is welcome.

2) Wolfgang: Please don't apply my "oftdump" command patch yet.

gvb

[U-Boot-Users] RFC: flattened device tree command

[Grant Likely]

On 11/29/06, Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com> wrote:
> The linux kernel has its own library functions for
> handling flat device trees.  In addition, David Gibson has proposed
> another library (advertised as easier to use):
> <http://ozlabs.org/pipermail/linuxppc-dev/2006-November/028596.html>
>
> My RFC has two parts:
> 1) Peoples' opinion of the relative merits of the current u-boot support
> library vs. the kernel's library vs. David Gibson's library.  My limited
> experience with ft_build.c is that it is suboptimal.  I don't have any
> experience with the linux or David's libraries to form an opinion of them.

There has already been talk about replacing ft_build w/ Greer's
library, there just hasn't been anyone to do the work.  I agree that
using a common code base between the various fdt tools is a good idea.
 Personally, I haven't looked deep into either Greer's or Gibson's
implementations yet, so I can't weigh in on which one I like best.

>
> 2) I see more commands than just dumping the tree, allowing the user to
> manipulate the tree as well.  My current thoughts are to make a new
> command "fdt" (flattened device tree - the Open Firmware genesis appears
> to be depricated) with subcommands like the existing "mii" command.

This is a good idea, and would be quite useful

> fdt read <node> - does what my "oftdump" command does
> fdt write <node> <value> - allow patching the fdt
>    * Writing could get pretty complex with creating nodes
>    * Initial implementation would be simply to change existing values

If the library API is good, adding new nodes/parameters shouldn't be
any more complex than modifying existing nodes.  The command format
would also need to be well defined.
>
> Related to the above discussion, the current ft_build.c/"bootm" code
> takes the blob and augments it with board configuration and env stuff as
> part of the "bootm" command.  The implementation is suboptimal
> (ft_build.c again) in that it is only done as a last thing before
> "bootm" transfers to linux, making it (almost) impossible to dump and
> definitely impossible to interactively poke around in the resulting fdt.
>   I would like to see this integrated done better in u-boot rather than
> simply pasted onto the fdt at the last moment before jumping into linux.

I agree

>
> So, in conclusion,
> 1) I'm not sure if this is truly a RFC or just a brain dump of my
> current thoughts.  Either way, advice is welcome.

Good thoughts, I agree

g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] RFC: flattened device tree command

[Ben Warren]

Hi Jerry,

On Wed, 2006-11-29 at 09:01 -0500, Jerry Van Baren wrote:

> 2) I see more commands than just dumping the tree, allowing the user to 
> manipulate the tree as well.  My current thoughts are to make a new 
> command "fdt" (flattened device tree - the Open Firmware genesis appears 
> to be depricated) with subcommands like the existing "mii" command.
> 
> fdt read <node> - does what my "oftdump" command does
> fdt write <node> <value> - allow patching the fdt
>    * Writing could get pretty complex with creating nodes
>    * Initial implementation would be simply to change existing values
> 

A naive question, to be sure:  Do you really forsee wanting to change
the device tree from the U-boot prompt?  I can see value in dumping the
contents and having an API that board-level boot code can use to modify
the tree.  Maybe for initial board debugging it would be useful to try
things out quickly, but modifying the quite-readable .dts files and
recompiling doesn't take long either.

Again, I don't mean to be critical - I'm just curious where you envision
this being used.

regards,
Ben

[U-Boot-Users] RFC: flattened device tree command

[Jerry Van Baren]

Ben Warren wrote:
> Hi Jerry,
> 
> On Wed, 2006-11-29 at 09:01 -0500, Jerry Van Baren wrote:
> 
>> 2) I see more commands than just dumping the tree, allowing the user to 
>> manipulate the tree as well.  My current thoughts are to make a new 
>> command "fdt" (flattened device tree - the Open Firmware genesis appears 
>> to be depricated) with subcommands like the existing "mii" command.
>>
>> fdt read <node> - does what my "oftdump" command does
>> fdt write <node> <value> - allow patching the fdt
>>    * Writing could get pretty complex with creating nodes
>>    * Initial implementation would be simply to change existing values
>>
> 
> A naive question, to be sure:  Do you really forsee wanting to change
> the device tree from the U-boot prompt?  I can see value in dumping the
> contents and having an API that board-level boot code can use to modify
> the tree.  Maybe for initial board debugging it would be useful to try
> things out quickly, but modifying the quite-readable .dts files and
> recompiling doesn't take long either.
> 
> Again, I don't mean to be critical - I'm just curious where you envision
> this being used.
> 
> regards,
> Ben

It goes with the classic unix/C philosophy of providing enough rope to 
shoot yourself in the foot. ;-)

Seriously, I don't have any concrete examples, but the current "bootm" 
command autogenerates values that are added to the tree, and also 
(optionally) adds the u-boot "env" values.  The env values can be 
changed via the env commands, but the autogenerated values currently cannot.

One autogenerated node is the "selected" node.  I would contend that 
this should _not_ be autogenerated.  (The copy of dtc that I am using 
complains because my .dtc file does not have a "selected" node.)  If you 
had multiple CPUs and wanted to boot from a different one, it would be 
really nice to be able to do that interactively or script it via hush.

Write capability would also follow the OpenFirmware example of allowing 
the user to change things interactively.  99.9998% of the time this is 
not used, but the once in a lifetime that it _is_ useful may save a 
service call are to Alaska or Siberia in the dead of winter (why is it 
never to Fiji???)

Another potential use that may not be realistic would be to implement 
the "env" storage as a fdt, which obviously would require write capability.

gvb

[U-Boot-Users] RFC: flattened device tree command

[Grant Likely]

On 11/29/06, Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com> wrote:
> Ben Warren wrote:
> > Hi Jerry,
> >
> > On Wed, 2006-11-29 at 09:01 -0500, Jerry Van Baren wrote:
> >
> >> 2) I see more commands than just dumping the tree, allowing the user to
> >> manipulate the tree as well.  My current thoughts are to make a new
> >> command "fdt" (flattened device tree - the Open Firmware genesis appears
> >> to be depricated) with subcommands like the existing "mii" command.
> >>
> >> fdt read <node> - does what my "oftdump" command does
> >> fdt write <node> <value> - allow patching the fdt
> >>    * Writing could get pretty complex with creating nodes
> >>    * Initial implementation would be simply to change existing values
> >>
> >
> > A naive question, to be sure:  Do you really forsee wanting to change
> > the device tree from the U-boot prompt?  I can see value in dumping the
> > contents and having an API that board-level boot code can use to modify
> > the tree.  Maybe for initial board debugging it would be useful to try
> > things out quickly, but modifying the quite-readable .dts files and
> > recompiling doesn't take long either.
> >
> > Again, I don't mean to be critical - I'm just curious where you envision
> > this being used.
> >
> > regards,
> > Ben
>
> It goes with the classic unix/C philosophy of providing enough rope to
> shoot yourself in the foot. ;-)

this is supposed to be a mixed-metaphor free zone.  :-P

>
> Seriously, I don't have any concrete examples, but the current "bootm"
> command autogenerates values that are added to the tree, and also
> (optionally) adds the u-boot "env" values.  The env values can be
> changed via the env commands, but the autogenerated values currently cannot.

ie. change the enumeration of serial ports (via property values).  I
have client boards where this would be useful at run time.

>
> One autogenerated node is the "selected" node.  I would contend that
> this should _not_ be autogenerated.  (The copy of dtc that I am using
> complains because my .dtc file does not have a "selected" node.)  If you
> had multiple CPUs and wanted to boot from a different one, it would be
> really nice to be able to do that interactively or script it via hush.

s/selected/chosen/

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195