Ben Warren wrote:
Hi Jerry,
On Wed, 2006-11-29 at 09:01 -0500, Jerry Van Baren wrote:
- 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