1. 19 Jan, 2016 1 commit
  2. 24 Oct, 2015 1 commit
  3. 29 Jan, 2015 1 commit
  4. 23 Nov, 2014 2 commits
    • Suriyan Ramasami's avatar
      fs: API changes enabling extra parameter to return size of type loff_t · d455d878
      Suriyan Ramasami authored
      The sandbox/ext4/fat/generic fs commands do not gracefully deal with files
      greater than 2GB. Negative values are returned in such cases.
      
      To handle this, the fs functions have been modified to take an additional
      parameter of type "* loff_t" which is then populated. The return value
      of the fs functions are used only for error conditions.
      Signed-off-by: default avatarSuriyan Ramasami <suriyan.r@gmail.com>
      Acked-by: default avatarSimon Glass <sjg@chromium.org>
      [trini: Update board/gdsys/p1022/controlcenterd-id.c,
      drivers/fpga/zynqpl.c for changes]
      Signed-off-by: default avatarTom Rini <trini@ti.com>
      d455d878
    • Christian Gmeiner's avatar
      fs: make it possible to read the filesystem UUID · 59e890ef
      Christian Gmeiner authored
      Some filesystems have a UUID stored in its superblock. To
      allow using root=UUID=... for the kernel command line we
      need a way to read-out the filesystem UUID.
      
      changes rfc -> v1:
       - make the environment variable an option parameter. If not
         given, the UUID is printed out. If given, it is stored in the env
         variable.
       - corrected typos
       - return error codes
      
      changes v1 -> v2:
       - fix return code of do_fs_uuid(..)
       - document do_fs_uuid(..)
       - implement fs_uuid_unsuported(..) be more consistent with the
         way other optional functionality works
      
      changes v2 -> v3:
       - change ext4fs_uuid(..) to make use of #if .. #else .. #endif
         construct to get rid of unreachable code
      
      Hit any key to stop autoboot:  0
      => fsuuid
      fsuuid - Look up a filesystem UUID
      
      Usage:
      fsuuid <interface> <dev>:<part>
          - print filesystem UUID
      fsuuid <interface> <dev>:<part> <varname>
          - set environment variable to filesystem UUID
      
      => fsuuid mmc 0:1
      d9f9fc05-45ae-4a36-a616-fccce0e4f887
      => fsuuid mmc 0:2
      eb3db83c-7b28-499f-95ce-9e0bb21cda81
      => fsuuid mmc 0:1 uuid1
      => fsuuid mmc 0:2 uuid2
      => printenv uuid1
      uuid1=d9f9fc05-45ae-4a36-a616-fccce0e4f887
      => printenv uuid2
      uuid2=eb3db83c-7b28-499f-95ce-9e0bb21cda81
      =>
      Signed-off-by: default avatarChristian Gmeiner <christian.gmeiner@gmail.com>
      Acked-by: default avatarStephen Warren <swarren@nvidia.com>
      59e890ef
  5. 09 Aug, 2014 1 commit
    • Stephen Warren's avatar
      fs: implement size/fatsize/ext4size · cf659819
      Stephen Warren authored
      These commands may be used to determine the size of a file without
      actually reading the whole file content into memory. This may be used
      to determine if the file will fit into the memory buffer that will
      contain it. In particular, the DFU code will use it for this purpose
      in the next commit.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      cf659819
  6. 19 Feb, 2014 2 commits
    • Stephen Warren's avatar
      fs: implement infrastructure for an 'exists' function · 6152916a
      Stephen Warren authored
      This could be used in scripts such as:
      
      if test -e mmc 0:1 /boot/boot.scr; then
          load mmc 0:1 ${scriptaddr} /boot/boot.scr
          source ${scriptaddr}
      fi
      
      rather than:
      
      if load mmc 0:1 ${scriptaddr} /boot/boot.scr; then
          source ${scriptaddr}
      fi
      
      This prevents errors being printed by attempts to load non-existent
      files, which can be important when checking for a large set of files,
      such as /boot/boot.scr.uimg, /boot/boot.scr, /boot/extlinux.conf,
      /boot.scr.uimg, /boot.scr, /extlinux.conf.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Acked-by: default avatarSimon Glass <sjg@chromium.org>
      6152916a
    • Stephen Warren's avatar
      fs: fix generic save command implementation · bd6fb31f
      Stephen Warren authored
      Fix a few issues with the generic "save" shell command, and fs_write()
      function.
      
      1) fstypes[].write wasn't filled in for some file-systems, and isn't
         checked when used, which could cause crashes/... if executing save
         on e.g. fat/ext filesystems.
      
      2) fs_write() requires the length argument to be non-zero, since it needs
         to know exactly how many bytes to write. Adjust the comments and code
         according to this.
      
      3) fs_write() wasn't prototyped in <fs.h> like other generic functions;
         other code should be able to call this directly rather than invoking
         the "save" shell command.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Acked-by: default avatarSimon Glass <sjg@chromium.org>
      bd6fb31f
  7. 07 Oct, 2013 1 commit
    • Wolfgang Denk's avatar
      Fix number base handling of "load" command · b770e88a
      Wolfgang Denk authored
      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 045fa1e1 "fs: add filesystem switch libary,
      implement ls and fsload commands" and 3f83c87e "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/171172Acked-by: default avatarTom Rini <trini@ti.com>
      Acked-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarWolfgang Denk <wd@denx.de>
      b770e88a
  8. 01 May, 2013 1 commit
  9. 04 Mar, 2013 1 commit
  10. 04 Nov, 2012 2 commits
    • Stephen Warren's avatar
      fs: rename fsload command to load · f9b55e22
      Stephen Warren authored
      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: default avatarStephen Warren <swarren@nvidia.com>
      f9b55e22
    • Stephen Warren's avatar
      fs: fix number base behaviour change in fatload/ext*load · 3f83c87e
      Stephen Warren authored
      Commit 045fa1e1 "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: default avatarStephen Warren <swarren@nvidia.com>
      Reviewed-by: default avatarBenoît Thébaudeau <benoit.thebaudeau@advansee.com>
      3f83c87e
  11. 29 Oct, 2012 1 commit