On 2023-01-03, Vagrant Cascadian wrote: > 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...
Another possible workaround... < Tartarus> A less dangerous work-around would be to us bootm_low or bootm_size (See https://u-boot.readthedocs.io/en/latest/usage/environment.html) to limit where relocations can be live well, vagrant
signature.asc
Description: PGP signature