On Wed, Feb 26, 2025 at 01:02:33PM +0100, Diederik de Haas wrote: > 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?
First, we talk about riscv64, nor arm64. Second, which arm64 board can boot from nothing? > 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 riscv64 installer only supports EFI. > > - Feature parity between architectures. > > - Fullfils the interface (U)EFI and works fine in edk2. > Right. EDK2. This is a joke, right? edk2 is the reference implementation. uboot is what everything else uses. > > 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. This kernel (after unpacking) boots find on non-UEFI. So, what is the problem? > 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). u-boot can load it as zboot image, as also mentioned. grub(!) fails for some reason. Bastian -- We'll pivot at warp 2 and bring all tubes to bear, Mr. Sulu!
