Eric Lee / smarc-uboot

09 Aug, 2014

1 commit

  • cf6598193   fs: implement size/fatsize/ext4size ... Browse Code »
    29

    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: Stephen Warren

    Stephen Warren
     

13 May, 2014

1 commit

  • 8b454eeee   fs:ext4:write:fix: Reinitialize global variables after updating a file ... Browse Code »

    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)
    data.
    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: Lukasz Majewski

    Łukasz Majewski
     

19 Feb, 2014

1 commit

16 Jul, 2013

1 commit

  • 04735e9c5   Fix ext2/ext4 filesystem accesses beyond 2TiB ... Browse Code »

    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: Frédéric Leroy

    Frederic Leroy
     

10 May, 2013

1 commit

05 Mar, 2013

1 commit

30 Oct, 2012

1 commit

  • 03e2ecf6b   fs: separate CONFIG_FS_{FAT, EXT4} from CONFIG_CMD_{FAT, EXT*} ... Browse Code »

    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: Stephen Warren
    Reviewed-by: Benoît Thébaudeau

    Stephen Warren
     

04 Oct, 2012

1 commit

26 Sep, 2012

2 commits

10 Aug, 2012

2 commits