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

Ian Campbell ijc at hellion.org.uk
Thu Oct 30 16:32:58 CET 2014


On Thu, 2014-10-30 at 16:21 +0100, Wolfgang Denk wrote:
> Dear Ian,
> 
> In message <1414677435.2064.34.camel at 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.

Ian.



More information about the U-Boot mailing list