[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