[U-Boot-Users] RFC: flattened device tree command
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
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:
- 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.
- 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,
- 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.
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
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
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:
- 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/
participants (3)
-
Ben Warren -
Grant Likely -
Jerry Van Baren