It seems there is some inconsistency wrt number base between commands which set $filesize in the env and the commands which might consume them.
e.g.
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:
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.
If $filesize happens to contains digits [a-f] then:
sun7i# load scsi 0 $fdt_addr_r dtbs/sun6i-a31-app4-evb1.dtb 16563 bytes read in 478 ms (33.2 KiB/s) sun7i# printenv filesize filesize=40b3 sun7i# fdt set /chosen foo <$filesize> Sorry, I could not convert "b3>"
Obviously I can hack around this with: sun7i# fdt set /chosen foo <0x$filesize>
But that seems a bit of an odd thing to have to do (not to mention potentially fragile).
There seem to be other commands, e.g. mmc write which interpret their parameters as hex by default, although in that case it does also DTRT with an 0x prefix.
So I'm not sure if the bug is that setenv_hex doesn't include the 0x, or that fdt set interprets things as decimal by default instead of hex. Or maybe there is no bug at all?
Just changing the setenv_hex to include the 0x seemed at first glance like a good idea, but I'm not really sure.
Thanks, Ian.
PS my usecase is to implement the fdt based multiboot protocol which Xen uses in order to load boot-modules, see e.g. http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Allwinner#Bo... http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Multiboot (we use something like this on all u-boot based platforms, Allwinner is just an example).
Ian.