From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Date: Tue, 04 Nov 2014 15:48:55 +0000 Subject: [U-Boot] Inconsistency between $filesize and commands which accept numeric params In-Reply-To: <20141104154412.GI15133@bill-the-cat> References: <1414677435.2064.34.camel@hellion.org.uk> <20141030152146.356D83809B0@gemini.denx.de> <1414683178.2064.51.camel@hellion.org.uk> <20141104154412.GI15133@bill-the-cat> Message-ID: <1415116135.11486.51.camel@hellion.org.uk> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tue, 2014-11-04 at 10:44 -0500, Tom Rini wrote: > On Thu, Oct 30, 2014 at 03:32:58PM +0000, Ian Campbell wrote: > > On Thu, 2014-10-30 at 16:21 +0100, Wolfgang Denk wrote: > > > Dear Ian, > > > > > > In message <1414677435.2064.34.camel@hellion.org.uk> you wrote: > > > > It seems there is some inconsistency wrt number base between commands > > > > which set $filesize in the env and the commands which might consume > > > > them. > > > > > > That would be bugs, then. > > > > > > > > > > > sun7i# load scsi 0 $fdt_addr_r dtbs/$fdtfile > > > > 21639 bytes read in 191 ms (110.4 KiB/s) > > > > sun7i# printenv filesize > > > > filesize=5487 > > > > > > > > So filesize is in hex, but without an 0x prefix. But: > > > > > > This is normal. U-Boot uses hex input base by default. All commands > > > should take hex input; the only inglorious exception is the "sleep" > > > command which takes decimal; numbers as arguments. > > > > > > > sun7i# fdt addr $fdt_addr_r 0x10000 > > > > sun7i# fdt set /chosen foo <$filesize> > > > > sun7i# fdt print /chosen foo > > > > foo = <0x0000156f> > > > > > > > > IOW the parameter to fdt set has been interpreted as a decimal. > > > > > > That's a bug. > > > > > > > So I'm not sure if the bug is that setenv_hex doesn't include the 0x, or > > > > > > No 0x prefix should be needed anywhere. > > > > > > > that fdt set interprets things as decimal by default instead of hex. Or > > > > maybe there is no bug at all? > > > > > > The bug is in fdt set, then. > > > > > > > > > Thanks for pointing out! > > > > Thanks for pointing me in the right direction. CCing the folks who > > get_maintainers.pl tells me might be involved with common/cmd_fdt.c > > > > Looks like the function which does this is fdt_parse_prop, which is > > documented with: > > /* > > * Parse the user's input, partially heuristic. Valid formats: > > * <0x00112233 4 05> - an array of cells. Numbers follow standard > > * C conventions. > > * [00 11 22 .. nn] - byte stream > > * "string" - If the the value doesn't start with "<" or "[", it is > > * treated as a string. Note that the quotes are > > * stripped by the parser before we get the string. > > > > which is inconsistent with the "U-Boot uses hex input base by default" > > mantra. > > Because this is FDT centric and not U-Boot centric, yes? I guess? > Since numbers> is a valid thing to do in an entry here. I think the right > answer is the more hacky sounding one of when you script using 'fdt set' > you need to be mindful of the constraints on input that are imposed upon > us by FDT. is invalid but <0xhex> is what is expected. The 0x prefix hack/trick is what I'm actually doing, but the maintainer of our test system wanted some assurances that u-boot wasn't going to change under our feet if someone fixed a bug. Sounds like you are saying this is all working as designed, and there is no bug, but I'll let Wolfgang and you thrash that out ;-). Ian.