Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #86153

Bug#1098661: linux: fails to boot on VisionFive 2: Unhandled exception: Store/AMO access fault

Cross-posted to 2 groups.

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

On Sat Feb 22, 2025 at 11:59 AM CET, Aurelien Jarno wrote:
> Starting with version 6.13.3-1~exp1, the riscv64 kernel is shipped as a
> EFI binary with the payload compressed with zstd (using the EFI_ZBOOT
> config option). In addition to breaking non-EFI systems, this change

Breaks non-EFI systems. Isn't that like 95+% of arm64 boards?

On Mon Feb 24, 2025 at 7:18 PM CET, Aurelien Jarno wrote:
> Let me summarize the situation for external reviewers.
> ...
> I was told ... Debian Installer does not support non-UEFI

Wrong.

> The situation worsened when I realized that the changes do not even work
> on a real riscv64 board installed using the standard Debian installer:

Testing on real hardware seems useful ...

> Sure this has been tested as mentioned in the MR [2], but it appears

The MR indicates it has been tested with QEMU.
Someone said: "arm64 build *looks* good to me" (emphasis mine)

If it was tested on real hardware it would have said so and mentioned
on which hardware. It doesn't, so it's safe to assume it was NOT tested
on real hardware.

> that booting a kernel with QEMU + EDK2 is not comparable to booting a
> kernel with a real board + U-Boot + Grub.

Indeed. You can configure QEMU to have the features you want/need. That
does not mean that all real boards support that.

> At this stage I have not seen a strong arguments for the original
> commit. The reason that have been given a posteriori are:
> - Smaller images, so often faster load times. 

That's due to compression. You can have compression without EFI.

> - Feature parity between architectures.
> - Fullfils the interface (U)EFI and works fine in edk2.

Right. EDK2. This is a joke, right?

Looking at https://github.com/edk2-porting I see the following repos:
- edk2-rk3588 ("EDK2 UEFI firmware for Rockchip RK3588 platforms")
- edk2-msm ("Broken edk2 port for Qualcomm platforms xD")

So there is *partial* support for some rk3588 based devices and broken
support for (some?) Qualcomm based devices. That's it.
Looking at the contributors for edk2-rk3588 I see there are *3* people
with more then 10 commits ... and one indicates he's inactive.
I haven't found any other indication it has some real momentum.

> I don't believe the above reasons are  enough to enforce UEFI only
> kernel and break the boot on existing boards. In addition the "forky

So I *actually* tested it on my Pine64 Quartz64 Model A board (rk3566)
by upgrading Debian's 6.13.2 kernel (which works) to the 6.13.4 kernel.
FWIW/FTR: My Q64-A board has a self-compiled U-Boot 2024.10-rc6.

Aurelien indicated he wanted this bug to be about RISC-V, so I'll just
attach my serial log in case ppl want to see that.

TL;DR: My U-Boot found out that it CAN'T load Debian's 6.13.4 kernel and
tries the next one till it finds one which it can boot ...
which was my 6.13 kernel (without EFI_ZBOOT).

On Sun Feb 23, 2025 at 10:07 PM CET, Aurelien Jarno wrote:
> On 2025-02-23 21:45, Bastian Blank wrote:
>> Please re-assign to the bootloader package.
>
> I disagree. The bootloader is u-boot and while it might be fixable at
> this level, debian should be bootable on the original firmware.

Most people use the bootloader/U-Boot that was shipped with the product
and never update it. I can understand why as the goal of the bootloader
is to boot the device, so when it does that ... why upgrade?

https://bugs.debian.org/1095745 is about broken backward compatibility
and that is a *kernel* bug.

My 0.02

> [2] https://salsa.debian.org/kernel-team/linux/-/merge_requests/1362

Back to linux.debian.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Bug#1098661: linux: fails to boot on VisionFive 2: Unhandled exception: Store/AMO access fault Aurelien Jarno <aurel32@debian.org> - 2025-02-22 12:10 +0100
  Bug#1098661: linux: fails to boot on VisionFive 2: Unhandled exception: Store/AMO access fault Bastian Blank <waldi@debian.org> - 2025-02-23 22:30 +0100
    Bug#1098661: linux: fails to boot on VisionFive 2: Unhandled exception: Store/AMO access fault Aurelien Jarno <aurel32@debian.org> - 2025-02-23 22:50 +0100
      Bug#1098661: linux: fails to boot on VisionFive 2: Unhandled exception: Store/AMO access fault Bastian Blank <waldi@debian.org> - 2025-02-24 20:30 +0100
  Bug#1098661: linux: fails to boot on VisionFive 2: Unhandled exception: Store/AMO access fault Bastian Blank <waldi@debian.org> - 2025-02-24 22:40 +0100
  Bug#1098661: linux: fails to boot on VisionFive 2: Unhandled exception: Store/AMO access fault "Diederik de Haas" <didi.debian@cknow.org> - 2025-02-26 13:20 +0100
  Processed: Re: Bug#1098661: linux: fails to boot on VisionFive 2:  Unhandled exception: Store/AMO access fault "Debian Bug Tracking System" <owner@bugs.debian.org> - 2025-02-26 21:50 +0100
  Bug#1098661: linux: fails to boot on VisionFive 2: Unhandled exception: Store/AMO access fault Bastian Blank <waldi@debian.org> - 2025-02-26 21:50 +0100
  Bug#1098661: fixed in linux 6.13.5-1~exp1 Salvatore Bonaccorso <carnil@debian.org> - 2025-02-28 21:20 +0100

csiph-web