On Thu, 2014-10-30 at 16:21 +0100, Wolfgang Denk wrote: > Dear Ian, > > In message <1414677435.2064.34.ca...@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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
