1. 14 Mar, 2016 2 commits
  2. 19 Jan, 2016 1 commit
  3. 08 Jan, 2016 1 commit
  4. 24 Oct, 2015 1 commit
  5. 13 Aug, 2015 1 commit
  6. 18 Apr, 2015 1 commit
  7. 29 Jan, 2015 1 commit
  8. 01 Dec, 2014 1 commit
  9. 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>
    • 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
       - 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
      fsuuid <interface> <dev>:<part>
          - print filesystem UUID
      fsuuid <interface> <dev>:<part> <varname>
          - set environment variable to filesystem UUID
      => fsuuid mmc 0:1
      => fsuuid mmc 0:2
      => fsuuid mmc 0:1 uuid1
      => fsuuid mmc 0:2 uuid2
      => printenv uuid1
      => printenv uuid2
      Signed-off-by: default avatarChristian Gmeiner <christian.gmeiner@gmail.com>
      Acked-by: default avatarStephen Warren <swarren@nvidia.com>
  10. 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>
  11. 22 Jul, 2014 1 commit
  12. 19 Feb, 2014 6 commits
  13. 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
              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>
  14. 01 May, 2013 2 commits
  15. 04 Mar, 2013 6 commits
  16. 01 Mar, 2013 1 commit
  17. 14 Nov, 2012 1 commit
  18. 04 Nov, 2012 3 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>
    • 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>
    • Stephen Warren's avatar
      fs: fix do_fsload() handling of optional arguments · e9b0f99e
      Stephen Warren authored
      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: default avatarStephen Warren <swarren@nvidia.com>
      Reviewed-by: default avatarBenoît Thébaudeau <benoit.thebaudeau@advansee.com>
  19. 02 Nov, 2012 1 commit
  20. 29 Oct, 2012 1 commit