The compiler will help find mismatches between printf formats and
arguments if you let it.  This patch adds the necessary attributes to
declarations in include/common.h, then begins to correct the resulting
compiler warnings.  Some of these were bugs, e.g., "$d" instead of
"%d" and incorrect arguments.  Others were just annoying, like
int-long mismatches on a system where both are 32 bits.  It's worth
fixing the annoying errors to catch the real ones.

Signed-off-by: Andrew Klossner <andrew@cesa.opbu.xerox.com>

The working_fdt pointer was declared in common/fdt_support.c but was
not used there.  Move it to common/cmd_fdt.c where it is used (it is
also used in lib_ppc/bootm.c).

Signed-off-by: Gerald Van Baren <vanbaren@cideas.com>

differentiate with local variables of the same name by renaming the
global 'fdt' variable 'working_fdt'.

Signed-off-by: Kim Phillips <kim.phillips@freescale.com>

Cleaner than doing multiple conditionals on characters.

Signed-off-by: Gerald Van Baren <vanbaren@cideas.com>

It was checking just for "b", which is not unique with respect to the
"boot" command.  Change to check for "boa"[rdsetup].

Signed-off-by: Gerald Van Baren <vanbaren@cideas.com>

This commit gets rid of a huge amount of silly white-space issues.
Especially, all sequences of SPACEs followed by TAB characters get
removed (unless they appear in print statements).

Also remove all embedded "vim:" and "vi:" statements which hide
indentation problems.

Signed-off-by: Wolfgang Denk <wd@denx.de>

The fdt set command was treating properties specified as <00> and <0011>
as byte streams, rather than as an array of cells.  As we already have
syntax for expressing the desire for a stream of bytes ([ xx xx ...]),
we should use the <> syntax to describe arrays of cells, which are always
32-bits per element.  If we imagine this likely (IMHO) scenario:

> fdt set /ethernet-phy@1 reg <1>

With the old code, this would create a bad fdt, since the reg cell would be
made to be one byte in length.  But the cell must be 4 bytes, so this would
break mysteriously.

Also, the dts spec calls for constants inside the angle brackets (<>)
to conform to C constant standards as they pertain to base.
Take this scenario:

> fdt set /ethernet@f00 reg <0xe250000\ 0x1000>

The old fdt command would complain that it couldn't parse that.  Or, if you
wanted to specify that a certain clock ran at 33 MHz, you'd be required to
do this:

> fdt set /mydev clock <1f78a40>

Whereas the new code will accept decimal numbers.

While I was in there, I extended the fdt command parser to handle property
strings which are split across multiple arguments:

> fdt set /ethernet@f00 interrupts < 33 2 34 2 36 2 >
> fdt p /ethernet@f00
ethernet@f00 {
	interrupts = <0x21 0x2 0x22 0x2 0x24 0x2>;
};

Lastly, the fdt print code was rearranged slightly to print arrays of cells
if the length of the property is a multiple of 4 bytes, and to not print
leading zeros.

Signed-off-by: Andy Fleming <afleming@freescale.com>

These defines embedded the u-boot env variables and/or the bd_t structure
in the fdt blob.  The conclusion of discussion on the u-boot email list
was that embedding these in the fdt blob is not useful: there are better
ways of passing the data (in fact, the fdt blob itself replaces the
bd_t struct).

The only board that enables these is the stxxtc and they don't appear
to be used by linux.

Signed-off-by: Gerald Van Baren <vanbaren@cideas.com>
Acked-by: Kim Phillips <kim.phillips@freescale.com>

The introduciton of the 'fdt bootcpu' broke parsing for 'fdt boardsetup'.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

fdt header                          - Display header info
fdt bootcpu <id>                    - Set boot cpuid
fdt memory <addr> <size>            - Add/Update memory node
fdt rsvmem print                    - Show current mem reserves
fdt rsvmem add <addr> <size>        - Add a mem reserve
fdt rsvmem delete <index>           - Delete a mem reserves

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>