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 hav
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
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 0x9621
elr: 800c9000 lr : 800c8ffc (reloc)
elr: fff77000 lr : fff76ffc
x0 : ffb40f04 x1 : 00
Signed-off-by: Phaedrus Leeds
Tested-by: Phaedrus Leeds
---
fs/zfs/zfs.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/fs/zfs/zfs.c b/fs/zfs/zfs.c
index 14779dee32..61d58fce68 100644
--- a/fs/zfs/zfs.c
+++ b/fs/zfs/zfs.c
@@ -1610,20 +1610,25 @@ zfs_nvlist_lookup_nvlist(char *nvlist, c
This code was hitting the error code path whenever malloc() succeeded
rather than when it failed, so presumably this part of the code hasn't
been tested. I had to apply this fix (and others) to get U-Boot to boot
from ZFS on an Nvidia Jetson TX2 NX SoM (an aarch64 computer).
Signed-off-by: Phaedru
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 see
On 4/6/24 10:04 PM, Janne Grunau wrote:
On Sat, Apr 06, 2024 at 08:52:17PM +0200, Marek Vasut wrote:
On 4/5/24 9:05 PM, Janne Grunau wrote:
On Fri, Apr 05, 2024 at 04:52:32PM +0200, Marek Vasut wrote:
On 4/4/24 8:25 AM, Janne Grunau via B4 Relay wrote:
Apple USB Keyboards from 2021 need quirk
On Sat, Apr 06, 2024 at 08:52:17PM +0200, Marek Vasut wrote:
> On 4/5/24 9:05 PM, Janne Grunau wrote:
> > On Fri, Apr 05, 2024 at 04:52:32PM +0200, Marek Vasut wrote:
> >> On 4/4/24 8:25 AM, Janne Grunau via B4 Relay wrote:
> >>> Apple USB Keyboards from 2021 need quirks to be useable. The boot HID
On 4/5/24 9:05 PM, Janne Grunau wrote:
On Fri, Apr 05, 2024 at 04:52:32PM +0200, Marek Vasut wrote:
On 4/4/24 8:25 AM, Janne Grunau via B4 Relay wrote:
Apple USB Keyboards from 2021 need quirks to be useable. The boot HID
keyboard protocol is unfortunately not described in the first interface
d
Hi Tim,
Thanks for the patch
I'll be away next week, I'll try to find time and take a closer look.
The pipeline [0] shows some TPM related failures
[0]
https://source.denx.de/u-boot/custodians/u-boot-tpm/-/commit/9b4be64e41454e17269a968397933eeff300c380
Cheers
/Ilias
On Fri, 5 Apr 2024 at 03:
Since we support SetVariableRT now add the relevant tests
- Search for the RTStorageVolatile and VarToFile variables after EBS
- Try to update with invalid variales (BS, RT only)
- Try to write a variable bigger than our backend storage
- Write a variable that fits and check VarToFile has been upd
Previous patches enabled SetVariableRT using a RAM backend.
Although EBBR [0] defines a variable format we can teach userspace tools
and write the altered variables, it's better if we skip the ABI
requirements completely.
So let's add a new variable, in its own namespace called "VarToFile"
which c
Previous patches enable SetVariableRT using a volatile storage backend
using EFI_RUNTIME_SERVICES_DATA allocared memory. Since there's no
recommendation from the spec on how to notify the OS, add a volatile
EFI variable that contains the filename relative to the ESP. OS'es
can use that file and upd
When EFI variables are stored on file we don't allow SetVariableRT,
since the OS doesn't know how to access or write that file. At the same
time keeping the U-Boot drivers alive in runtime sections and performing
writes from the firmware is dangerous -- if at all possible.
For GetVariableRT we c
Hi all,
This is an updated version of [0].
When EFI variables are stored on file we don't allow SetVariableRT,
since the OS doesn't know how to access or write that file. At the same
time keeping the U-Boot drivers alive in runtime sections and performing
writes from the firmware is dangerous --
Since we support SetVariableRT now add the relevant tests
- Search for the RTStorageVolatile and VarToFile variables after EBS
- Try to update with invalid variales (BS, RT only)
- Try to write a variable bigger than our backend storage
- Write a variable that fits and check VarToFile has been upd
Previous patches enabled SetVariableRT using a RAM backend.
Although EBBR [0] defines a variable format we can teach userspace tools
and write the altered variables, it's better if we skip the ABI
requirements completely.
So let's add a new variable, in its own namespace called "VarToFile"
which c
Previous patches enable SetVariableRT using a volatile storage backend
using EFI_RUNTIME_SERVICES_DATA allocared memory. Since there's no
recommendation from the spec on how to notify the OS, add a volatile
EFI variable that contains the filename relative to the ESP. OS'es
can use that file and upd
When EFI variables are stored on file we don't allow SetVariableRT,
since the OS doesn't know how to access or write that file. At the same
time keeping the U-Boot drivers alive in runtime sections and performing
writes from the firmware is dangerous -- if at all possible.
For GetVariableRT we c
Hi all,
This is an updated version of [0].
When EFI variables are stored on file we don't allow SetVariableRT,
since the OS doesn't know how to access or write that file. At the same
time keeping the U-Boot drivers alive in runtime sections and performing
writes from the firmware is dangerous --
20 matches
Mail list logo
