u-boot.git/fs/ext4, branch v2015.01-rc2

fs: API changes enabling extra parameter to return size of type loff_t

2014-11-23T11:49:04Z

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: Suriyan Ramasami Acked-by: Simon Glass [trini: Update board/gdsys/p1022/controlcenterd-id.c, drivers/fpga/zynqpl.c for changes] Signed-off-by: Tom Rini

ext4: Prepare API change for files greater than 2GB

2014-11-23T11:49:04Z

Change the internal EXT4 functions to use loff_t for offsets. Signed-off-by: Suriyan Ramasami Acked-by: Simon Glass [trini: Update common/spl/spl_ext.c] Signed-off-by: Tom Rini

fs: make it possible to read the filesystem UUID

2014-11-23T11:49:01Z

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 : - print filesystem UUID fsuuid : - 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: Christian Gmeiner Acked-by: Stephen Warren

linux/kernel.h: sync min, max, min3, max3 macros with Linux

2014-11-23T11:48:30Z

U-Boot has never cared about the type when we get max/min of two values, but Linux Kernel does. This commit gets min, max, min3, max3 macros synced with the kernel introducing type checks. Many of references of those macros must be fixed to suppress warnings. We have two options: - Use min, max, min3, max3 only when the arguments have the same type (or add casts to the arguments) - Use min_t/max_t instead with the appropriate type for the first argument Signed-off-by: Masahiro Yamada Acked-by: Pavel Machek Acked-by: Lukasz Majewski Tested-by: Lukasz Majewski [trini: Fixup arch/blackfin/lib/string.c] Signed-off-by: Tom Rini

ext4: Use inttypes for printf() string

2014-10-27T15:04:01Z

On 64-bit platforms (like sandbox) 64-bit integers may be 'long' rather than 'long long'. Use the inttypes header to avoid compiler warnings. Signed-off-by: Simon Glass

kconfig: add blank Kconfig files

2014-09-24T22:30:28Z

This would be useful to start moving various config options. Signed-off-by: Masahiro Yamada Acked-by: Simon Glass Tested-by: Simon Glass

fs: implement size/fatsize/ext4size

2014-08-09T15:16:57Z

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

fs: ext4: fix writing zero-length files

2014-06-19T15:18:53Z

ext4fs_allocate_blocks() always allocates at least one block for a file. If the file size is zero, this causes total_remaining_blocks to underflow, which then causes an apparent hang while 2^32 blocks are allocated. To solve this, check that total_remaining_blocks is non-zero as part of the loop condition (i.e. before each loop) rather than at the end of the loop. Signed-off-by: Stephen Warren

ext4: correctly zero filename

2014-06-11T20:27:05Z

Since ALLOC_CACHE_ALIGN_BUFFER declares a char* for filename sizeof(filename) is not the size of the buffer. Use the already known length instead. cc: Uma Shankar cc: Manjunatha C Achar cc: Marek Vasut Signed-off-by: Jeroen Hofstee Acked-by: Marek Vasut

fs:ext4:write:fix: Reinitialize global variables after updating a file

2014-05-12T20:31:50Z

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