Commit graph

16 commits

Author SHA1 Message Date
Wolfgang Denk
b770e88a6c 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>
2013-10-07 15:54:18 -04:00
Simon Glass
7eb2c8d573 sandbox: fs: Add support for saving files to host filesystem
This allows write of files from the host filesystem in sandbox. There is
currently no concept of overwriting the file and removing its existing
contents - all writing is done on top of what is there. This means that
writing 10 bytes to the start of a 1KB file will only update those 10
bytes, not truncate the file to 10 byte slong.

If the file does not exist it is created.

Signed-off-by: Simon Glass <sjg@chromium.org>
2013-05-01 11:17:21 -04:00
Simon Glass
a8f6ab5229 fs: Add support for saving data to filesystems
Add a new method for saving that filesystems can implement. This mirrors the
existing load method.

Signed-off-by: Simon Glass <sjg@chromium.org>
2013-05-01 11:17:21 -04:00
Simon Glass
92ccc96bf3 sandbox: Add host filesystem
This allows reading of files from the host filesystem in sandbox.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@ti.com>
2013-03-04 14:19:56 -05:00
Simon Glass
e6d5241534 fs: Move ls and read methods into ext4, fat
It doesn't make a lot of sense to have these methods in fs.c. They are
filesystem-specific, not generic code. Add each to the relevant
filesystem and remove the associated #ifdefs in fs.c.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@ti.com>
2013-03-04 14:19:56 -05:00
Simon Glass
117e050727 fs: Use map_sysmem() on read
This allows us to use filesystems on sandbox. It has no effect on other
architectures.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@ti.com>
2013-03-04 14:19:56 -05:00
Simon Glass
2ded0d4719 fs: Tell probe functions where to put their results
Rather than rely on global variables for the probe functions, pass in
the information that we need filled in. This allows us to potentially
keep the variables private to fs.c in the future, and the meaning of
the probe function is clearer.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@ti.com>
2013-03-04 14:19:56 -05:00
Simon Glass
c6f548d232 fs: Use filesystem methods instead of switch()
We can use the available methods and avoid using switch(). When the
filesystem is not supported, we fall through to the 'unsupported'
methods: fs_probe_unsupported() prints an error, so the others do
not need to.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@ti.com>
2013-03-04 14:19:56 -05:00
Simon Glass
436e2b7319 fs: Fully populate the filesystem method struct
There is a structure in fs.c with just a probe method. By adding methods
for other operations, we can avoid lots of #ifdefs and switch()s. As a
first step, create the structure ready for use.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@ti.com>
2013-03-04 14:19:56 -05:00
Simon Glass
49c4f0370b fs: Use new numeric setenv functions
Use setenv_ulong(), setenv_hex() and setenv_addr() in fs/

Signed-off-by: Simon Glass <sjg@chromium.org>
2013-02-28 19:09:23 -08:00
Andreas Bießmann
da1fd96ce4 fs/fs.c: do_fsload: measure throughput
This patch adds time measurement and throughput calculation for
all supported load commands.

The output of ext2load changes from

---8<---
1830666 bytes read
--->8---

to

---8<---
1830666 bytes read in 237 ms (7.4 MiB/s)
--->8---

Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
[agust: rebased and revised commit log]
Signed-off-by: Anatolij Gustschin <agust@denx.de>
2012-11-14 13:35:14 +01:00
Stephen Warren
f9b55e2285 fs: rename fsload command to load
When the generic filesystem load command "fsload" was written, I felt
that "load" was too generic of a name for it, since many other similar
commands already existed. However, it turns out that there is already
an "fsload" command, so that name cannot be used. Rename the new
"fsload" to plain "load" to avoid the conflict. At least anyone who's
used a Basic interpreter should feel familiar with the name!

Signed-off-by: Stephen Warren <swarren@nvidia.com>
2012-11-04 11:00:34 -07:00
Stephen Warren
3f83c87ee5 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>
2012-11-04 11:00:31 -07:00
Stephen Warren
e9b0f99e82 fs: fix do_fsload() handling of optional arguments
Most arguments to the shell command do_fsload() implements are optional.
Fix the minimum argc check to respect that. Cater for the situation
where argv[2] is not provided.

Enhance both do_fsload() and do_ls() to check the maximum number of
arguments too. While this check would typically be implemented via
U_BOOT_CMD()'s max_args parameter, if these functions are called
directly, then that check won't exist.

Finally, alter do_ls() to check (argc >= 4) rather than (argc == 4) so
that if the function is enhanced to allow extra arguments in the future,
this test won't need to be changed at that time.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
2012-11-04 11:00:24 -07:00
Stephen Warren
a1b231cef6 fs: handle CONFIG_NEEDS_MANUAL_RELOC
Without this, fstypes[].probe points at the wrong place, so calling the
function results in undefined behaviour.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Andreas Bießmann <andreas.devel@googlemail.com>
2012-11-02 15:13:29 -07:00
Stephen Warren
045fa1e114 fs: add filesystem switch libary, implement ls and fsload commands
Implement "ls" and "fsload" commands that act like {fat,ext2}{ls,load},
and transparently handle either file-system. This scheme could easily be
extended to other filesystem types; I only didn't do it for zfs because
I don't have any filesystems of that type to test with.

Replace the implementation of {fat,ext[24]}{ls,load} with this new code
too.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
2012-10-29 14:21:20 -07:00