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@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