Hi, Let me summarize the situation for external reviewers.
The kernel for riscv64 used to rely on CONFIG_EFI_STUB=y, enabling the
kernel to be used either as an EFI executable or as conventional ELF
file. Unlike x86, this requires the kernel to be uncompressed, which is
why it was shipped as vmlinux. Note that this is not the only
architecture where the kernel is uncompressed, this is also the case for
ppc64el and a many ports architectures.
Commit 16b5ae589a679 ("[arm64, riscv64] Enable EFI_ZBOOT") [1] changed
three things for riscv64:
1) Changed the kernel file that ends up in the package from the
uncompressed one (arch/riscv/boot/Image) to the compressed one
(arch/riscv/boot/vmlinuz.efi)
2) Enabled EFI_ZBOOT to compress the kernel payload and include a
decompressor in the EFI binary
3) Changed the kernel compression from GZIP to ZSTD
Note that technically changes 2 and 3 have basically no effect on the
resulting package without change 1. Please also note that change 1 was
done without renaming the kernel from vmlinux to vmlinuz to match the
(probably non-written) standard so to ship compressed kernels as vmlinuz
and uncompressed ones as vmlinux. OTOH such a change would have
probably broken many things.
This change was made without checking with the porters and without any
justification. I quickly noticed the commit and was worried about change
1, as it basically enforces UEFI booting. Although Debian Installer
defaults to a UEFI installation with the standard ISO media or UKI
image, it is technically possible to use a system booting directly from
U-Boot, which some users prefer (this is particularly useful for
switching between non-UEFI vendor kernels and debian kernels). In
addition a non-UEFI kernel is important for KVM, as it currently doesn't
support running in S-mode, therefore requiring a non-UEFI kernel to be
loaded directly without any firmware.
As a porter I requested on IRC for the riscv64 part of the code to be
reverted. I was told this is not possible, as Debian Installer does not
support non-UEFI, that this change will target forky only, and that I
can simply use a script to extract the payload from the UEFI kernel.
The situation worsened when I realized that the changes do not even work
on a real riscv64 board installed using the standard Debian installer:
| 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
|
|
| resetting ...
| reset not supported yet
| ### ERROR ### Please RESET the board ###
Sure this has been tested as mentioned in the MR [2], but it appears
that booting a kernel with QEMU + EDK2 is not comparable to booting a
kernel with a real board + U-Boot + Grub. I agree that there is an issue
in the firmware / bootloader / kernel stack (my current wild guess is
that it's a Grub issue), but still that change currently results in a
non-working kernel.
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.
- Feature parity between architectures.
- Fullfils the interface (U)EFI and works fine in edk2.
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
only" argument doesn't stand as many newer riscv64 devices are expected
during the lifetime of trixie and will require a kernel from
trixie-backports. That is why I submitted a MR [3] to revert the riscv64
specific part of the commit.
Regards
Aurelien
[1]
https://salsa.debian.org/kernel-team/linux/-/commit/16b5ae589a679acbc9e43de9cb691f42fe058068
[2] https://salsa.debian.org/kernel-team/linux/-/merge_requests/1362
[3] https://salsa.debian.org/kernel-team/linux/-/merge_requests/1384
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net
signature.asc
Description: PGP signature
