u-boot.git/fs, branch v2024.07

Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet""

2024-05-19T14:16:36+00:00

When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.

This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.

Reported-by: Jonas Karlman 
Signed-off-by: Tom Rini

fs: Remove and add needed includes

2024-05-06T21:05:04+00:00

Remove  from all "fs/" files and when needed add
missing include files directly.

Signed-off-by: Tom Rini

fs/erofs: add DEFLATE algorithm support

2024-04-18T22:37:16+00:00

This patch adds DEFLATE compression algorithm support. It's a good choice
to trade off between compression ratios and performance compared to LZ4.
Alternatively, DEFLATE could be used for some specific files since EROFS
supports multiple compression algorithms in one image.

Signed-off-by: Jianan Huang 
Reviewed-by: Gao Xiang

fs: fat: fill creation and change date

2024-04-17T23:06:06+00:00

The FAT specification requires that the change date is set.

If a DM RTC device exists, set the creation and change date to the current
date when updating the directory entry. Otherwise use the date 2020-01-01.

Signed-off-by: Heinrich Schuchardt

fs: fat: convert change month correctly

2024-04-17T23:06:04+00:00

The month is stored in 5 - 8. We need to shift it by 5 bits.

Cf. Microsoft FAT Specification, 2005-08-30

Fixes: 13c11c665320 ("fs: fat: add file attributes to struct fs_dirent")
Signed-off-by: Heinrich Schuchardt 
Reviewed-by: Alexander Dahl 
Reviewed-by: Ilias Apalodimas

Merge patch series "zfs: Fix zfs support on aarch64"

2024-04-17T16:08:59+00:00

mwleeds@mailtundra.com  says:

This patch series is needed to get U-Boot to boot from a ZFS filesystem
on an aarch64 computer. Some of the patches are not architecture specific
and would be needed to boot ZFS on other platforms as well. The ZFS
support in U-Boot hasn't been substantively touched in several years and
to me it seems like it must have been broken for a long time on all
platforms, but I have only tested on aarch64.

Since there doesn't seem to be a mantainer for this area who I can cc,
I'm hoping these patches get seen and pulled in by a general U-Boot
maintainer.

[trini: Per Igor's comment and Phaedrus agreement, dropped his Tested-by
 on the patches themselves]

zfs: Fix zfs_read() to actually work

2024-04-17T16:08:58+00:00

Without this patch, the while loop being modified goes on infinitely,
but with the patch I am able to boot linux on zfs on a jetson tx2 nx.

It seems like this code was never tested because the logic is clearly
wrong. The function do_div(a,b) does a division that modifies the first
parameter to have a = a / b, and returns the remainder of the division.
So clearly in the usual case when file->offset = 0, the line
"blkid = do_div(blkid, blksz);" just results in blkid being set to zero
on every iteration of the loop, rather than being incremented as blocks
are read. Hence the zeroth block is read over and over and this becomes
an infinite loop.

So instead capture the remainder of the division in a "blkoff" variable,
and use that to properly calculate the memory address to move from in
memmove() below.

For example, if file->offset were 1337, on the first iteration of the
loop blkid would be 0 and blkoff would be 1337. If the blksz is 131072
(as it was for me), that amount of data would be copied into
data->file_buf. movesize would be 131072 - 1337 = 129735 so 129735 bytes
would be moved into buf. On the second iteration of the loop (assuming
there is one), red would be 129735, blkid would be 1, blkoff would be 0,
and 131072 bytes would be copied into buf. And so on...

Signed-off-by: Phaedrus Leeds

zfs: Fix return value of fs_devread()

2024-04-17T16:08:56+00:00

As evidenced by how other filesystems handle it, a return value of 0
from fs_devread() means failure; nonzero means success. The opposite
assumption was being made in zfs.c for the use of zfs_devread() so fix
the confusion by making zfs_devread() return 0 on success.

It probably doesn't make sense to change the handling of zfs_devread()
in zfs.c instead, because as it is it matches the semantics of the other
functions there.

Signed-off-by: Phaedrus Leeds

zfs: Fix unaligned read of uint64

2024-04-17T16:08:53+00:00

Without this patch, when trying to boot zfs using U-Boot on a Jetson TX2
NX (which is aarch64), I get a CPU reset error like so:

"Synchronous Abort" handler, esr 0x96000021
elr: 00000000800c9000 lr : 00000000800c8ffc (reloc)
elr: 00000000fff77000 lr : 00000000fff76ffc
x0 : 00000000ffb40f04 x1 : 0000000000000000
x2 : 000000000000000a x3 : 0000000003100000
x4 : 0000000003100000 x5 : 0000000000000034
x6 : 00000000fff9cc6e x7 : 000000000000000f
x8 : 00000000ff7f84a0 x9 : 0000000000000008
x10: 00000000ffb40f04 x11: 0000000000000006
x12: 000000000001869f x13: 0000000000000001
x14: 00000000ff7f84bc x15: 0000000000000010
x16: 0000000000002080 x17: 00000000001fffff
x18: 00000000ff7fbdd8 x19: 00000000ffb405f8
x20: 00000000ffb40dd0 x21: 00000000fffabe5e
x22: 000000ea77940000 x23: 00000000ffb42090
x24: 0000000000000000 x25: 0000000000000000
x26: 0000000000000000 x27: 0000000000000000
x28: 0000000000bab10c x29: 00000000ff7f85f0

Code: d00001a0 9103a000 94006ac6 f9401ba0 (f9400000)
Resetting CPU ...

This happens when be64_to_cpu() is called on a value that exists at a
memory address that's 4 byte aligned but not 8 byte aligned (e.g. an
address ending in 04). The call stack where that happens is:
check_pool_label() ->
zfs_nvlist_lookup_uint64(vdevnvlist, ZPOOL_CONFIG_ASHIFT,...) ->
be64_to_cpu()

Signed-off-by: Phaedrus Leeds 
Fixes: 4d3c95f5ea7c ("zfs: Add ZFS filesystem support")

zfs: Add a comment to clarify nvlist memory layout

2024-04-17T16:08:51+00:00

Signed-off-by: Phaedrus Leeds