On 2025-02-24 22:32, Bastian Blank wrote: > On Sat, Feb 22, 2025 at 11:59:38AM +0100, Aurelien Jarno wrote: > > | Loading Linux 6.13-riscv64 ... > > | Loading initial ramdisk ... > > | EFI stub: Decompressing Linux Kernel... > > | Unhandled exception: Store/AMO access fault > > | EPC: 00000000fb64a6ea RA: 00000000fb64a6da TVAL: 0000000040020020 > > | EPC: 000000003b9046ea RA: 000000003b9046da reloc adjusted > > | > > | Code: 0506 9526 4783 0015 4703 0005 3583 ed84 (0e23 fef9) > > | UEFI image [0x00000000fe6aa000:0x00000000fe6d0fff] > > '/efi\boot\bootriscv64.efi' > > | UEFI image [0x00000000fb646000:0x00000000fbe933ff] pc=0x46ea > > I digged a bit. Yes, this is the file from > linux-image-6.13-riscv64_6.13.3-1~exp1_riscv64.deb. It contains the > mentioned instructions: > > | 46da: 0506 slli a0,a0,0x1 > | 46dc: 9526 add a0,a0,s1 > | 46de: 00154783 lbu a5,1(a0) > | 46e2: 00054703 lbu a4,0(a0) > | 46e6: ed843583 ld a1,-296(s0) > | 46ea: fef90e23 sb a5,-4(s2) > > I did not manage to get the crash you mentioned. The u-boot out of > u-boot-qemu_2024.01+dfsg-7_all.deb can start both the uncompressed EFI
I have not been able to reproduce the crash under QEMU. I believe it could be due to the fact that QEMU doesn't trap unaligned accesses. So far I only reproduced the issue on real hardware. It works fine when the kernel is directly started from U-Boot with bootefi. It only fails when U-Boot launches Grub and Grub launches the EFI file. > file and the zboot compressed one. Sadly it fails unrelated shortly > after that in both cases. You should use OpenSBI as the bios, and U-Boot in S-mode as the kernel. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
