[U-Boot-Users] CHANGELOG w/ status update: cmd_of.c, ft_build.c, vsprintf.c, long long print problem

[Jerry Van Baren]

Wolfgang Denk wrote:
> Dear Jon,

[snip]

> (1) I will freeze the current setup and probably even release  it  as
>     U-Boot 1.1.5 (mostly to feed all those FTP-only downloaders).
> 
> (2) rename CHANGELOG into CHANGELOG.OLD, and start  a  new  CHANGELOG
>     which  gets  automatically generated using the command above or a
>     variation thereof.
> 
>     Note: nobody needs to take care of this file. It is purely for my
>     own private needs, and I will manage it on my own. Everybody else
>     can just ignore the existence of this file.

I'm sure other people use it, I read it for entertainment occasionally. 
  For instance, it is useful to sort the local commit noise from the 
"official" noise, following what is going on in the main tree.

> (3) I will merge your and Matthew McClintock's 85xx  which  (from  my
>     point  of  view)  suffer  mostly  just from the missing CHANGELOG
>     entries.

Excellent!  My git repository is a hodgepodge based off the official one 
with Jon's changes pulled in (which presumably are the same as 
Matthew's, but I haven't verified that...).  When Wolfgang pulls the 
changes into the main repository it will enable me to get my house 
cleaned up and submit my changes as well.

I'm loving git's abilities to track and merge repositories, but I'm 
developing "at risk" since my world is neither WD nor JDL and I'm 
counting on Wolfgang to do this merge to make my world OK again.  When 
this happens, I'll be able to submit some patches to create cmd_of.c and 
improve ft_build.c and vsprintf.c (maybe, see below).

> (4) Remaining issues like coding  style  cleanup  etc.  can  be  then
>     sorted out in the merged trees. If I should see bigger problems I
>     will create branches that can be used as reference.
> 
> Is this acceptable to you and everybody else?

You bet!

> Best regards,
> Wolfgang Denk

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:
<http://www.cideas.us/git>

Project for this discussion:
<http://www.cideas.us/cgi-bin/gitweb.cgi?p=u-boot/u-boot-pq2fads.git;a=summary>

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.

The "of" command syntax is:
   of <address> [<node or property>]
If you specify just the address, it dumps the whole tree (gaak!).
If you specify a property (e.g. /model) it prints out just that property.
If you specify a node (e.g. /cpus) it prints out the whole node, 
including all nested nodes.  Specifying "/" dumps the whole tree.

vsprintf.c, long long print problem
-----------------------------------
vsprintf.c was enhanced fairly recently to print 64 bit quantities using 
the "q" modifier.  Pantelis Antoniou (or Vitaly) used the modifier 
"%llx" to print 64 bit property values, which didn't work with 
vsprintf.c, so I enhanced vsprintf.c to accept "ll" and change it 
internally to "q" (I also changed ft_build.c to print as "0x%016llx" as 
well to print the leading zeros).  All was well with the world, until I 
noticed that the interrupt node "reg" was printing "0x00000000f8200004" 
when it should have been printing "0xf8200000f8200004":
     interrupt-controller at f8200000 {
         linux,phandle = <0xf8200000>;
         #address-cells = <0x00000000>;
         #interrupt-cells = <0x00000002>;
         interrupt-controller;
         reg = <0x00000000f8200004>;
         built-in;
         device_type = "pci-pic";
     };

I have *NOT* been able to figure out why long long printing is *NOT* 
working correctly.  It does *NOT* work correctly for the "%q" version 
either.  My current theory is that varargs isn't working correctly for 
long long, but I have not chased down that path (yet).

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.

gvb