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

[Ian Campbell]

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 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.
> 
> Because this is FDT centric and not U-Boot centric, yes?

I guess?

>   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.

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.