summaryrefslogtreecommitdiffstats
path: root/test
diff options
context:
space:
mode:
authorWolfgang Denk <wd@denx.de>2013-10-05 21:07:25 +0200
committerTom Rini <trini@ti.com>2013-10-07 15:54:18 -0400
commitb770e88a6c2548727f0d57a3e9e8bb0830f977b5 (patch)
tree469c25b2cd059fe019fe87e334b8f4bf0f2134ea /test
parent010c480bbf9c3c2b4237a73242b4b3f7c9198114 (diff)
downloadtalos-obmc-uboot-b770e88a6c2548727f0d57a3e9e8bb0830f977b5.tar.gz
talos-obmc-uboot-b770e88a6c2548727f0d57a3e9e8bb0830f977b5.zip
Fix number base handling of "load" command
As documented, almost all U-Boot commands expect numbers to be entered in hexadecimal input format. (Exception: for historical reasons, the "sleep" command takes its argument in decimal input format.) This rule was broken for the "load" command; for details please see especially commits 045fa1e "fs: add filesystem switch libary, implement ls and fsload commands" and 3f83c87 "fs: fix number base behaviour change in fatload/ext*load". In the result, the load command would always require an explicit "0x" prefix for regular (i. e. base 16 formatted) input. Change this to use the standard notation of base 16 input format. While strictly speaking this is a change of the user interface, we hope that it will not cause trouble. Stephen Warren comments (see [1]): I suppose you can change the behaviour if you want; anyone writing "0x..." for their values presumably won't be affected, and if people really do assume all values in U-Boot are in hex, presumably nobody currently relies upon using non-prefixed values with the generic load command, since it doesn't work like that right now. [1] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/171172 Acked-by: Tom Rini <trini@ti.com> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Wolfgang Denk <wd@denx.de>
Diffstat (limited to 'test')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud