[U-Boot-Users] RFA & Update: Using libfdt in u-boot for fdt command
Jerry Van Baren
gerald.vanbaren at smiths-aerospace.com
Thu Mar 1 15:01:24 CET 2007
This is a Request for Advice.
First off, for those on both the u-boot and linuxppc-dev lists, sorry
for cross posting. :-)
Git repo pointers...
I have a proof-of-concept (actually, somewhat more than PoC) fdt command
built using libfdt. Now I'm looking for advice on the best way to turn
the PoC into Real Code[tm].
fdt address - set the base address of the blob
fdt get <property> - get a property
fdt print <node> - print the subtree starting at <node>
fdt set <property> <value> - set a property value (do we want an
"=" as in <property> = <value>?)
fdt ?synthesize? - create the "chosen" branch and optionally the
u-boot variables branch. The OF code/calls
currently in bootm would be moved to this
command. I'm open to suggestions for a good
fdt node <name> - create a node that can then be populated with
properties (have not thought about this in any detail yet).
 If <node> is actually a <property> (which is a usage error, but I
expect will happen all the time), "fdt print" actually does a "fdt get
<property>" This makes "fdt get" redundant and likely will make it go away.
Philosophy question primarily for David Gibson and Wolfgang Denk: What
is the best way to integrate libfdt with u-boot? Currently it is in its
own git repository. Options?
1) Do we want to capture the source in the u-boot git repository? If
so, it becomes a snapshot and will require cross pushing/pulling between
the libfdt repo and the u-boot repo or they will drift apart. However,
it makes problems #1 and #2 (below) simpler to solve but causes drift.
2) Not capturing libfdt in the u-boot repo makes it more difficult for
integrating it with and maintaining it in u-boot, I'm not sure how to
actually do it in a useful/usable manner.
There are three problem areas with libfdt:
1) The official Makefile is stand-alone which doesn't work well with
u-boot. I took the expedient route for the PoC of simply replacing it
with a u-boot style Makefile from a different lib* subdirectory. There
should be a better way.
2) The official libfdt uses two header files that are not in u-boot. I
"fixed" this by substituting u-boot headers with equivalent functionality.
* I need to address this and see what the best compromise for header
a) If the u-boot headers are acceptable for the stand-alone version
of libfdt, that would be the simplest.
b) It may be more effective to add the necessary linux headers to
c) We could use #ifdefs to conditionally include the right files. (but
does u-boot have a distinctive configuration def? Probably...)
3) I added a "fdt_next_tag()" function to fdt_ro.c to allow me to step
through the blob's tags:
uint32_t fdt_next_tag(const void *fdt, int offset,
int *nextoffset, char **namep);
This is similar to "_fdt_next_tag()" (a "private" function, note the
leading underscore) in fdt.c, but with a related but different purpose -
the "_fdt_next_tag()" steps through _node_ tags (skipping property
tags) where I need to step through all tags sequentially.
Usability trivia for David: libfdt distinguishes between nodes and
properties, which makes sense since that is how the fdt is structured.
From a usability standpoint, however, it is annoying to have to
separate the property name from the node, find the node, then find the
property. I will probably create Yet Another Function:
int fdt_split(char *path, char **property);
Call it with a path string and the function will separate it into the
node portion and the property name. If the path is invalid, it will
return an error. If the path is a node, it will set **property to NULL
and return the node's offset. If the path is a property, it will return
the owning node's offset and set the **property pointer to point to the
start of the property portion of the path (i.e. the next character after
the last '/').
If you got this far, thank you for your attention. :-)
More information about the U-Boot