[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