u-boot.git/fs/fs.c, branch master

treewide: Clean up DECLARE_GLOBAL_DATA_PTR usage

2026-02-17T19:50:22+00:00

Remove DECLARE_GLOBAL_DATA_PTR from files where gd is not used, and
drop the unnecessary inclusion of asm/global_data.h.

Headers should be included directly by the files that need them,
rather than indirectly via global_data.h.

Reviewed-by: Patrice Chotard  #STMicroelectronics boards and STM32MP1 ram test driver
Tested-by: Anshul Dalal  #TI boards
Acked-by: Yao Zi  #TH1520
Signed-off-by: Peng Fan

fs: prevent integer overflow in fs.c do_mv

2026-01-16T19:04:40+00:00

An integer overflow in size calculations could lead to
under-allocation and potential heap buffer overflow.

Signed-off-by: Timo tp Preißl 
Reviewed-by: Simon Glass 
Reviewed-by: Tom Rini

fs: Rework filesystem guards for xPL phases

2025-10-10T20:25:35+00:00

When adding filesystems to the table in fs/fs.c we need to use
CONFIG_IS_ENABLED(FS_xxx) so that we only include references to a given
filesystem when CONFIG_FS_xxx or CONFIG_SPL_FS_xxx or similar are
enabled. Update the filesystems which weren't doing this to follow that
pattern.

Signed-off-by: Tom Rini

lmb: replace lmb_reserve() and lmb_alloc_addr() API's

2025-06-25T15:50:37+00:00

There currently are multiple allocation API's in the LMB module. There
are a couple of API's for allocating memory(lmb_alloc() and
lmb_alloc_base()), and then there are two for requesting a reservation
for a particular memory region (lmb_reserve() and
lmb_alloc_addr()). Introduce a single API lmb_alloc_mem() which will
cater to all types of allocation requests and replace lmb_reserve()
and lmb_alloc_addr() with the new API.

Moreover, the lmb_reserve() API is pretty similar to the
lmb_alloc_addr() API, with the one difference being that the
lmb_reserve() API allows for reserving any address passed to it --
the address need not be part of the LMB memory map. The
lmb_alloc_addr() does check that the address being requested is
actually part of the LMB memory map.

There is no need to support reserving memory regions which are outside
the LMB memory map. Remove the lmb_reserve() API functionality and use
the functionality provided by lmb_alloc_addr() instead. The
lmb_alloc_addr() will check if the requested address is part of the
LMB memory map and return an error if not.

Signed-off-by: Sughosh Ganu 
Acked-by: Ilias Apalodimas

fs: exfat: Implement trivial 'rename' support

2025-04-21T17:07:04+00:00

Implement exfat_fs_rename() to rename or move files. This is used
by the 'mv' generic FS interface command. The rename implementation
for other filesystems was added recently and was not part of exfat
porting layer due to merge issue, which made 'mv' command crash,
fix this by adding the missing implementation.

Fixes: b86a651b646c ("fs: exfat: Add U-Boot porting layer")
Signed-off-by: Marek Vasut

Merge patch series "fs: exfat: Add exfat port based on exfat-fuse"

2025-04-03T02:01:14+00:00

Marek Vasut  says:

Import exfat-fuse libexfat, add U-Boot filesystem layer porting glue
code and wire exfat support into generic filesystem support code. This
adds exfat support to U-Boot.

Fill in generic filesystem interface for mkdir and rm commands.
Make filesystem tests test the generic interface as well as exfat,
to make sure this code does not fall apart.

Link: https://github.com/relan/exfat/commits/0b41c6d3560d ("CI: bump FreeBSD to 13.1.")
Link: https://lore.kernel.org/r/20250317031418.223019-1-marex@denx.de

fs: exfat: Add U-Boot porting layer

2025-04-03T02:00:59+00:00

Add U-Boot adjustments to the libexfat code and integrate
the result into U-Boot filesystem layer. This provides full
read-write exfat support for U-Boot available via generic
filesystem interface.

FS_DIRENT_NAME_LEN is increased to 1024 in case exfat is
enabled, because EXFAT can use UTF16 names, which do not
fit into current FS_DIRENT_NAME_LEN. To avoid affecting
every configuration, increase FS_DIRENT_NAME_LEN only in
case EXFAT is enabled.

Example usage via sandbox, assuming disk.img with one exfat partition:

Drive info:
$ ./u-boot -Tc 'host bind 0 ../disk.img ; host info 0'
dev       blocks  blksz label           path
  0       262144    512 0               ../disk.img

List files:
$ ./u-boot -Tc 'host bind 0 ../disk.img ; ls host 0:1 /api'
      475   Kconfig
      230   Makefile
     1873   README
     ...
10 file(s), 0 dir(s)

Load and checksum a file:
$ ./u-boot -Tc 'host bind 0 ../disk.img ; load host 0:1 $loadaddr .config ; \
                crc32 $loadaddr $filesize'
56724 bytes read in 1 ms (54.1 MiB/s)
crc32 for 00000000 ... 0000dd93 ==> b2e847c9

$ crc32 .config
b2e847c9

Load .config file to RAM, store the file into FS as /newconfig,
load the /newconfig into RAM and checksum the file:
$ ./u-boot -Tc 'host bind 0 ../disk.img ; load host 0:1 $loadaddr .config ; \
		save host 0:1 $loadaddr /newconfig $filesize ; \
		load host 0:1 0x10000 /newconfig ; \
		crc32 0x10000 $filesize'
56724 bytes read in 1 ms (54.1 MiB/s)
56724 bytes written in 0 ms
56724 bytes read in 0 ms
crc32 for 00010000 ... 0001dd93 ==> b2e847c9

Remove file 3.txt and create new directory /newdir:
$ ./u-boot -Tc 'host bind 0 ../disk.img ; ls host 0:1 / ; \
                rm host 0:1 3.txt ; mkdir host 0:1 /newdir ; \
		ls host 0:1 /'
...
        0   1.txt
        0   2.txt
        0   3.txt
        0   4.txt
        0   5.txt

7 file(s), 4 dir(s)
...
        0   1.txt
        0   2.txt
            newdir/
        0   4.txt
        0   5.txt

6 file(s), 5 dir(s)

Acked-by: Tom Rini 
Signed-off-by: Marek Vasut

Merge tag 'v2025.04-rc5' into next

2025-03-25T02:10:55+00:00

Prepare v2025.04-rc5

lmb: change the return code on lmb_alloc_addr()

2025-03-24T17:12:33+00:00

Ben reports a failure to boot the kernel on hardware that starts its
physical memory from 0x0.
The reason is that lmb_alloc_addr(), which is supposed to reserve a
specific address, takes the address as the first argument, but then also
returns the address for success or failure and treats 0 as a failure.

Since we already know the address change the prototype to return an int.

Reported-by: Ben Schneider 
Signed-off-by: Ilias Apalodimas 
Tested-by: Ben Schneider 
Reviewed-by: Sughosh Ganu

fs: fat: add rename

2025-03-07T17:50:22+00:00

The implementation roughly follows the POSIX specification for
rename() [1]. The ordering of operations attempting to minimize the chance
for data loss in unexpected circumstances.

The 'mv' command was implemented as a front end for the rename operation
as that is what most users are likely familiar with in terms of behavior.

The 'FAT_RENAME' Kconfig option was added to prevent code size increase on
size-oriented builds like SPL.

[1] https://pubs.opengroup.org/onlinepubs/9799919799/functions/rename.html

Signed-off-by: Gabriel Dalimonte