On 2023-01-03, Vagrant Cascadian wrote: > On 2023-01-02, Vagrant Cascadian wrote: >> On 2023-01-02, Vagrant Cascadian wrote: >>> On 2022-12-28, Vagrant Cascadian wrote: >>>> The odroid-c2 fails to boot syslinux/extlinux style menus (e.g. those >>>> produced by u-boot-menu) or boot.scr as of upstream 2022.07-rc1. The >>>> commit triggering the issue has been identified as: >>>> >>>> a9bf024b2933bba0e23038892970a18b72dfaeb4 >>>> efi_loader: disk: a helper function to create efi_disk objects from >>>> udevice >>>> >>>> Workarounds I've heard are to disable EFI support for that board >> ... >>> Obviously, it breaks EFI booting... >>> >>> Worst case, I suppose we could create two variants, one with EFI, one >>> without... >> >> I have pushed a patch to git implementing an odroid-c2-noefi variant: >> >> >> https://salsa.debian.org/debian/u-boot/-/commit/711ca985af1cab6f11e33fcf5e30dcc40dc7e64d >> >> This would not close the bug, but at least downgrade the severity... > > I can confirm that 2023.01-rc4+dfsg-1 does boot successfully with EFI on > the odroid-c2, so ... the two variant solution is a viable one if a > proper fix cannot be figured out in time for bookworm.
From irc.libera.chat #u-boot:
< xypron> Tartarus: Loading Ramdisk to 7a896000, end 7bf3eb78
overwrites internal memory structures of the EFI subsystem
which leads to the crash on the Odroid C2. Why do we copy
initrd to high memory at all?
< xypron> vagrantc: Tartarus: setenv initrd_high 0xffffffffffffffff;
setenv fdt_high 0xffffffffffffffff solves the problem on the
Odroid C2
I can confirm this works around the issue, although it may also cause
other problems and should not be the default...
live well,
vagrant
signature.asc
Description: PGP signature
