Mainline u-boot with distro_defaults: Scanning scsi 0:1... Found /extlinux/extlinux.conf Retrieving file: /extlinux/extlinux.conf 1: Linux 6.5.7-gentoo-dist Retrieving file: /extlinux/../initramfs-6.5.7-gentoo-dist.img Retrieving file: /extlinux/../vmlinuz-6.5.7-gentoo-dist append: console=ttyMV0,115200 root=/dev/sda2 ro rootfstype=ext4 rootwait net.ifnames=0 biosdevname=0 Retrieving file: /extlinux/../dtbs/6.5.7-gentoo-dist/marvell/armada-3720-espressobin.dtb Bad Linux ARM64 Image magic! SCRIPT FAILED: continuing... MMC: no card present No EFI system partition Possibly this works with EFI but the image needs to be not stripped for normal u-boot to load it: # file /mnt/gentoo/boot/vmlinuz-6.5.6-arm64-r1 # this is good /mnt/gentoo/boot/vmlinuz-6.5.6-arm64-r1: Linux kernel ARM64 boot executable Image, little-endian, 4K pages # file /mnt/gentoo/boot/vmlinuz-6.5.7-gentoo-dist # this is bad /mnt/gentoo/boot/vmlinuz-6.5.7-gentoo-dist: PE32+ executable (EFI application) Aarch64 (stripped to external PDB), for MS Windows, 2 sections
This feels like it is the same problem as https://bugs.gentoo.org/913935. The bootloader shouldn't check for this magic number if the kernel image is an efi file.
Similar yes, but I'm not using grub at all, and it doesn't seem like u-boot has very much EFI support, as it can barely boot a debian ISO in certain cases. I'd guess *maybe* 10% of ARM64 hardware is actually EFI-capable and if it is, then it's probably not documented anyway. Feels like this needs efi-or-uboot USE flag for handling the kernel image correctly, otherwise this is unusable on all of my arm64 hardware except 1 thing that happens to be pure EFI/grub.
(In reply to Steve Arnold from comment #2) > Similar yes, but I'm not using grub at all, and it doesn't seem like u-boot > has very much EFI support, as it can barely boot a debian ISO in certain > cases. Well it looks for an EFI system partition so it should support booting .efi files right? > No EFI system partition My guess is it might work if you put the kernel on an EFI system partition, even if the firmware isn't EFI capable. > I'd guess *maybe* 10% of ARM64 hardware is actually EFI-capable and > if it is, then it's probably not documented anyway. My understanding is that CONFIG_EFI_ZBOOT makes the kernel build an image that includes its own decompressor (zboot) for use on EFI capable hardware. I might be wrong but I don't think zboot *requires* EFI capable hardware. > Feels like this needs > efi-or-uboot USE flag for handling the kernel image correctly, otherwise > this is unusable on all of my arm64 hardware except 1 thing that happens to > be pure EFI/grub. This is very impractical because it means compiling 2 different gpkg's for gentoo-kernel-bin on arm64 and riscv. If you compile your own sys-kernel/gentoo-kernel then you'll get the Image.gz you're used to (unless you enable USE=secureboot). For the prebuilt sys-kernel/gentoo-kernel-bin we enable USE=secureboot in order to distribute a signed image, this requires CONFIG_EFI_ZBOOT because we cannot sign the Image.gz but we can sign the vmlinuz.efi. I don't own any arm64 hardware so I can't boot test this, but I think the issue is that uboot doesn't support zboot yet. zboot is very new and uboot might assume we get a plain Image.gz if there is no EFI system partition. At least that is what seems to be happening in the log you shared. Could you report this issue upstream? The solution in grub was to remove this check for the magic number since we only get this in a Image.gz but not in vmlinuz.efi. Something similar might work here.
Sadly, the reality is a mish-mash of older vendor forks and some mainline u-boot with various configs and distro_defaults only if you're lucky, and the same goes for EFI support in u-boot. The reason I'm here now is the distro boot setup could not find EFI/grub so I ended up making the esp a normal boot partition instead. I can't really envision most users going that deep into upgrading and configuring u-boot, but some relatively simple/documented way to get grub loaded seems possible. I'll probably go back and poke at booting the grub efi bits but that is still a non-ideal workflow until grub-mkconfig understands what to do with a devicetree blob.
Okay, so with a teensy bit of manual help, this works with u-boot as long as it was built with distro_defaults or at least EFI support: => load usb 0:1 $kernel_addr_r /EFI/gentoo/grubaa64.efi 147456 bytes read in 7 ms (20.1 MiB/s) => bootefi $kernel_addr_r $fdtcontroladdr Booting /\EFI\gentoo\grubaa64.efi BUT it only boots if grub has the correct devicetree in the config, which must be added to grub.cfg manually after generating it. If grub has no devicetree, then kernel oops. The above can be saved to u-boot default environment or added to a simple boot script. It's not ideal but it works.
Great! Could you document this on the wiki [1] as instructions specific to >=sys-kernel/gentoo-kernel-bin-6.5 and other kernels compiled with CONFIG_EFI_ZBOOT=y? I don't think it is feasible at the moment to distribute both the vmlinuz.efi and the Image.gz, which would be the best solution. [1] https://wiki.gentoo.org/wiki/Embedded_Handbook/Bootloaders/Das_U-Boot
Silly me, default efi setup doesn't like my simple boot script with USB disk. This needs a cleaner env update to mesh with distro defaults. On the flip side the grub patches for devicetree work fine.
Aaand my distro_boot expectations are apparently stale, since the distro_bootcmd stuff has been superseded by something even more generic/less legacy: https://u-boot.readthedocs.io/en/v2022.10/develop/bootstd.html That ^^ says distributions are supposed to provide their own "boot flow" files that look a lot like extlinux.conf menu entries.
(In reply to Steve Arnold from comment #8) > https://u-boot.readthedocs.io/en/v2022.10/develop/bootstd.html > > That ^^ says distributions are supposed to provide their own "boot flow" > files that look a lot like extlinux.conf menu entries. It looks like this bootflow file also contains the kernel arguments though, that is not something we can distribute with the sys-kernel/gentoo-kernel-bin package. Perhaps there is some tool that can generate this file, similar to grub-mkconfig, then we can call this tool with kernel-install.
