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

Jerry Van Baren gerald.vanbaren at smiths-aerospace.com
Wed Nov 29 15:01:49 CET 2006


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




More information about the U-Boot mailing list