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 /[EMAIL PROTECTED] 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 /[EMAIL PROTECTED] 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 /[EMAIL PROTECTED] interrupts < 33 2 34 2 36 2 >
>> fdt p /[EMAIL PROTECTED]
> [EMAIL PROTECTED] {
> 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 <[EMAIL PROTECTED]>
> ---
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
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
U-Boot-Users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/u-boot-users
