[U-Boot-Users] RFA & Update: Using libfdt in u-boot for fdt command

David Gibson
2007-03-02T05:36:40Z

On Fri, Mar 02, 2007 at 12:25:17AM -0500, Jerry Van Baren wrote:
> David Gibson wrote:
> >On Thu, Mar 01, 2007 at 11:08:38PM -0500, Jerry Van Baren wrote:
>
> [snip]
>
> >>to give me a pointer to the node name for node tags and property name
> >>for property tags. Now that I have it working, it would be trivial to
> >>change the calls to _fdt_next_tag() to instead call fdt_next_tag()
> >>passing NULL for the new fourth parameter **namep. ;-)
> >>
> >>The reason I need it, I'm printing an unknown tree by stepping through
> >>the tree discovering the node and property names. I need to have
> >>fdt_next_tag() return the *name* of the node/property as well as the tag
> >>so that I can print and indent for nodes or look up the property value
> >>and print the name=value combination.
> >
> >Hrm. And it returns NULL for tags without a name?
>
> I was unable to generate a tag without a name using dtc (other than the
> root node). It should/would return null, which would be a problem. :-/

I was thinking more of tag types which don't have a name, to wit,
FDT_END_NODE and FDT_NOP.

> >That might be a useful extension for the next_tag function. The one
> >thing I'm concerned about is who's responsible for verifying the name
> >pointer. I'm trying to keep libfdt robust enough that evern if
> >presented with a badly corrupt blob it will fail relatively
> >gracefully. Ideally, no matter what it's presented with, it will
> >always return at worst FDT_ERR_BADSTRUCTURE rather than crashing and
> >will under no circumstances access memory outside the given blob
> >size.
>
> [snip]
>
> >>Oh gaak! What I hear you saying... if you have node a with subnode b
> >>and property b, subnode b has a property c:
> >>/a => node
> >>/a/b => node
> >>/a/b => property (inside node a)
> >>/a/b/c => property (inside node b)
> >
> >Well, yes. Except that in OF and derived terminology, properties are
> >*never* referred to by path in this way. It's always:
> > "property 'fred' of node /foo/bar/baz"
>
> I'm coming from a human interface syntax point of view and assumed that
> the human interface is paths like linux where the last item is a
> directory or file with the computer guessing what you really meant
> (which _isn't_ ambiguous in file/dir paths). Is there a better syntax
> for distinguishing between node paths and properties?

You assumed incorrectly. Well, unless you count /proc/device-tree as
a human interface to the device tree, which isn't entirely
unreasonable. OF certainly doesn't use that approach, it uses state
instead, first "dev /foo/bar/baz" then ".properties" or "setprop ....".

--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!