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.