[U-Boot-Users] [PATCH] Fix fdt set command to conform to dts spec

[Jerry Van Baren]

Andy Fleming wrote:
> 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 at 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 at 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 at f00 interrupts < 33 2 34 2 36 2 >
>> fdt p /ethernet at f00
> ethernet at 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 at freescale.com>
> ---

Hi Andy,

This looks like a very good improvement, fix some of my mistakes and 
misassumptions.

What I wrote originally was prior to dtc v1.0... at that time, all 
constants were hex.  Bringing our parsing/printing forward to the 
C-syntax age (dtc v1.0++) is good.

The parsing and print format that I did, I did to make the device tree 
printout reversible: I compiled source with dtc, loaded it, and printed 
it out.  I adapted the print heuristics so that the fdt print command 
matched (exactly in almost all cases) the example dtc source.  Your 
point about <> values being 32 bit cells bothers me... either I didn't 
understand the particulars of the <> notation (quite possible) or 
something has changed.  I would like to understand the genesis of this 
error/misunderstanding.

I have not had time yet to apply the patch to the u-boot-fdt tree and 
try it, I'll do that pronto.

Best regards,
gvb