[U-Boot] Inconsistency between $filesize and commands which accept numeric params

[Tom Rini <trini@ti.com>]

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?  Since <decimal
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.  <hex> is invalid but <0xhex> is what is expected.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141104/ad53b3aa/attachment.pgp>