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