From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Tue, 01 Apr 2008 10:06:07 -0400 Subject: [U-Boot-Users] [PATCH] Fix fdt set command to conform to dts spec In-Reply-To: <1207014356-1663-1-git-send-email-afleming@freescale.com> References: <1207014356-1663-1-git-send-email-afleming@freescale.com> Message-ID: <47F2414F.9070001@ge.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 > --- 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