1. 05 Aug, 2016 1 commit
    • Tom Rini's avatar
      ext4: Refuse to mount filesystems with 64bit feature set · 6f94ab66
      Tom Rini authored
      With e2fsprogs after 1.43 the 64bit and metadata_csum features are
      enabled by default.  The metadata_csum feature changes how
      ext4_group_desc->bg_checksum is calculated, which would break write
      support.  The 64bit feature however introduces changes such that it
      cannot be read by implementations that do not support it.  Since we do
      not support this, we must not mount it.
      Cc: Stephen Warren <swarren@nvidia.com>
      Cc: Simon Glass <sjg@chromium.org>
      Cc: Lukasz Majewski <l.majewski@samsung.com>
      Cc: Stefan Roese <sr@denx.de>
      Reported-by: default avatarAndrew Bradford <andrew.bradford@kodakalaris.com>
      Signed-off-by: default avatarTom Rini <trini@konsulko.com>
  2. 14 Mar, 2016 1 commit
  3. 23 Nov, 2014 3 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>
    • Suriyan Ramasami's avatar
      ext4: Prepare API change for files greater than 2GB · 9f12cd0e
      Suriyan Ramasami authored
      Change the internal EXT4 functions to use loff_t for offsets.
      Signed-off-by: default avatarSuriyan Ramasami <suriyan.r@gmail.com>
      Acked-by: default avatarSimon Glass <sjg@chromium.org>
      [trini: Update common/spl/spl_ext.c]
      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>
  4. 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>
  5. 12 May, 2014 1 commit
    • Łukasz Majewski's avatar
      fs:ext4:write:fix: Reinitialize global variables after updating a file · 8b454eee
      Łukasz Majewski authored
      This bug shows up when file stored on the ext4 file system is updated.
      The ext4fs_delete_file() is responsible for deleting file's (e.g. uImage)
      However some global data (especially ext4fs_indir2_block), which is used
      during file deletion are left unchanged.
      The ext4fs_indir2_block pointer stores reference to old ext4 double
      indirect allocated blocks. When it is unchanged, after file deletion,
      ext4fs_write_file() uses the same pointer (since it is already initialized
      - i.e. not NULL) to return number of blocks to write. This trunks larger
      file when previous one was smaller.
      Lets consider following scenario:
      1. Flash target with ext4 formatted boot.img (which has uImage [*] on itself)
      2. Developer wants to upload their custom uImage [**]
      	- When new uImage [**] is smaller than the [*] - everything works
      	correctly - we are able to store the whole smaller file with corrupted
      	ext4fs_indir2_block pointer
      	- When new uImage [**] is larger than the [*] - theCRC is corrupted,
      	since truncation on data stored at eMMC was done.
      3. When uImage CRC error appears, then reboot and LTHOR/DFU reflashing causes
      	proper setting of ext4fs_indir2_block() and after that uImage[**]
      	is successfully stored (correct uImage [*] metadata is stored at an
      	eMMC on the first flashing).
      Due to above the bug was very difficult to reproduce.
      This patch sets default values for all ext4fs_indir* pointers/variables.
      Signed-off-by: default avatarLukasz Majewski <l.majewski@samsung.com>
  6. 19 Feb, 2014 1 commit
  7. 15 Jul, 2013 1 commit
    • Frederic Leroy's avatar
      Fix ext2/ext4 filesystem accesses beyond 2TiB · 04735e9c
      Frederic Leroy authored
      With CONFIG_SYS_64BIT_LBA, lbaint_t gets defined as a 64-bit type,
      which is required to represent block numbers for storage devices that
      exceed 2TiB (the block size usually is 512B), e.g. recent hard drives
      We now use lbaint_t for partition offset to reflect the lbaint_t change,
      and access partitions beyond or crossing the 2.1TiB limit.
      This required changes to signature of ext4fs_devread(), and type of all
      variables relatives to block sector.
      ext2/ext4 fs uses logical block represented by a 32 bit value. Logical
      block is a multiple of device block sector. To avoid overflow problem
      when calling ext4fs_devread(), we need to cast the sector parameter.
      Signed-off-by: default avatarFrédéric Leroy <fredo@starox.org>
  8. 10 May, 2013 1 commit
  9. 04 Mar, 2013 1 commit
  10. 29 Oct, 2012 1 commit
    • Stephen Warren's avatar
      fs: separate CONFIG_FS_{FAT, EXT4} from CONFIG_CMD_{FAT, EXT*} · 03e2ecf6
      Stephen Warren authored
      This makes the FAT and ext4 filesystem implementations build if
      CONFIG_FS_{FAT,EXT4} are defined, rather than basing the build on
      whether CONFIG_CMD_{FAT,EXT*} are defined. This will allow the
      filesystems to be built separately from the filesystem-specific commands
      that use them. This paves the way for the creation of filesystem-generic
      commands that used the filesystems, without requiring the filesystem-
      specific commands.
      Minor documentation changes are made for this change.
      The new config options are automatically selected by the old config
      options to retain backwards-compatibility.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Reviewed-by: default avatarBenoît Thébaudeau <benoit.thebaudeau@advansee.com>
  11. 04 Oct, 2012 1 commit
  12. 25 Sep, 2012 2 commits
  13. 09 Aug, 2012 2 commits