summaryrefslogtreecommitdiff
path: root/test
diff options
context:
space:
mode:
authorStephen Warren <swarren@nvidia.com>2012-10-30 12:04:19 +0000
committerTom Rini <trini@ti.com>2012-11-04 11:00:31 -0700
commit3f83c87ee58d86e9a9d2e50b62f38c728bfb31f6 (patch)
tree872af7c007d0f4ee399dc3531e3c88ecfac25363 /test
parentb6a30444365be7ef4d323b50573a2c591ef36d08 (diff)
downloadu-boot-imx-3f83c87ee58d86e9a9d2e50b62f38c728bfb31f6.zip
u-boot-imx-3f83c87ee58d86e9a9d2e50b62f38c728bfb31f6.tar.gz
u-boot-imx-3f83c87ee58d86e9a9d2e50b62f38c728bfb31f6.tar.bz2
fs: fix number base behaviour change in fatload/ext*load
Commit 045fa1e "fs: add filesystem switch libary, implement ls and fsload commands" unified the implementation of fatload and ext*load with the new command fsload. However, this altered the interpretation of command-line numbers from always being base-16, to requiring a "0x" prefix for base-16 numbers. Enhance do_fsload() to allow commands to specify which base to use. Use base 0, thus requiring a "0x" prefix for the new fsload command. This feels much cleaner than assuming base 16. Use base 16 for the pre-existing fatload and ext*load to prevent a change in behaviour. Use base 16 exclusively for the loadaddr environment variable, since that variable is interpreted in multiple places, so we don't want the behaviour to change. Update command help text to make it clear where numbers are assumed to be hex, and where an explicit "0x" prefix is required. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Diffstat (limited to 'test')
0 files changed, 0 insertions, 0 deletions