From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Fri, 13 Oct 2006 10:52:27 -0400 Subject: [U-Boot-Users] CHANGELOG w/ status update: cmd_of.c, ft_build.c, vsprintf.c, long long print problem In-Reply-To: References: <20061013095221.AC2B1353C95@atlas.denx.de> <452F9380.3010505@smiths-aerospace.com> Message-ID: <452FA82B.8050300@smiths-aerospace.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Jon Loeliger wrote: > So, like, the other day Jerry Van Baren mumbled: >> OK, now for the rest of the subject line (sorry about that, but they are >> all intertwined via our respective git repositories). >> >> My git repository: >> >> >> Project for this discussion: >> > > Cool. I'll try and track down some time to look at them! > >> cmd_of.c, ft_build.c >> -------------------- >> I've created a "of" command that allows you to dump all or part of a >> flattened tree. To make the command more usable, I enhanced ft_build.c >> to do partial dumps. > > Thank you. You have saved me/Matthew from doing this. :-) Yerwelcome. Standing on the shoulders of giants and all that... One thing I didn't "fix" is that the dump is missing the leading "/" for the root node, it prints => of 300000 { model = "PQ2FADS"; compatible = "MPC8260ADS"; #address-cells = <00000001>; #size-cells = <00000001>; linux,phandle = <00000100>; : : }; instead of => of 300000 / { ^-- missing "/" model = "PQ2FADS"; compatible = "MPC8260ADS"; #address-cells = <00000001>; #size-cells = <00000001>; linux,phandle = <00000100>; : : }; This happens because the "/" is put on the end of the old node path when concatenating the new node, rather than putting in on the start of the new node when a new node is found (this is a better approach except for the root node). Since the first node has no "old" node to concatenate the "/" to, it never gets added. I presume this is an error and will fix it. >> At the moment, my copy of ft_build.c prints 8 byte entries as a double >> word "<%08x %08x>" rather than using 64 bit prints. > > Hmmm... That might be an OK stop-gap, but I don't > think we should count on that long term, of course. > >> gvb > > Thanks, > jdl gvb