Bug#1027176: u-boot-amlogic: broken non-EFI boot on odroid-c2

[Vagrant Cascadian]

Package: u-boot-amlogic
Version: 2022.07~rc3+dfsg-1
Severity: important
X-Debbugs-Cc: vag...@debian.org
Control: block 1016963 by -1

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, or to
boot using EFI rather than boot scripts or syslinux/extlinux style
menus.

I will also want to get confirmation if other amlogic boards are
affected...


live well,
vagrant

[Vagrant Cascadian]

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, or to
> boot using EFI rather than boot scripts or syslinux/extlinux style
> menus.
>
> I will also want to get confirmation if other amlogic boards are
> affected...

The currently supported amlogic platforms are:

# Neil Armstrong <narms...@baylibre.com>
u-boot-amlogic_platforms += khadas-vim

# Neil Armstrong <narms...@baylibre.com>
u-boot-amlogic_platforms += khadas-vim2

# Frederic Danis <frederi...@collabora.com>
u-boot-amlogic_platforms += libretech-cc

# Neil Armstrong <narms...@baylibre.com>
u-boot-amlogic_platforms += nanopi-k2

# Vagrant Cascadian <vag...@debian.org>
u-boot-amlogic_platforms += odroid-c2

# Reco <bu...@enotuniq.net>
u-boot-amlogic_platforms += odroid-n2

Please test if the current versions from Debian unstable (2022.10*) and
experimental (2023.01-rc*) are affected by this issue... and if there
are other issues for Debian bookworm/testing (2022.04*).

This is part of what has been blocking u-boot from migrating to testing.


I do not see (m)any records of tests for most of these platforms at:

https://wiki.debian.org/U-boot/Status


live well,
vagrant

[Vagrant Cascadian]

Control: severity 1027176 serious

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, or to
> boot using EFI rather than boot scripts or syslinux/extlinux style
> menus.

Bumped the severity to serious, as this breaks booting.

live well,
vagrant

[Vagrant Cascadian]

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 still do not have confirmation if the other amlogic boards are
similarly affected.

live well,
vagrant

[Frédéric Danis]

Hi Vagrant,

u-boot bookworm version works fine with LePotato board (libretech-cc),
see attached lepotato-bookworm.txt.
Afaiu, the bug is not reproducible with unstable and experimental
versions, but boot crash before starting the kernel, see
lepotato-unstable.txt and lepotato-experimental.txt.

Happy new year,
Fred

--
Frédéric Danis
Senior Software Engineer

Collabora Ltd.
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, United Kingdom
Registered in England & Wales, no. 5513718

[Vagrant Cascadian]

Thanks!

> Afaiu, the bug is not reproducible with unstable and experimental
> versions, but boot crash before starting the kernel, see
> lepotato-unstable.txt and lepotato-experimental.txt.

Sounds like the bug *is* reproducible with unstable and experiemental
versions, from reading the logs; looks like the same issue with
odroid-c2.

Could you try building a "noefi" variant, like done with odroid-c2, and
test for the lepotato (libretech-cc?):

https://salsa.debian.org/debian/u-boot/-/commit/711ca985af1cab6f11e33fcf5e30dcc40dc7e64d



Could you also test EFI booting with the versions from unstable and
experimental to see if they can load a kernel? If EFI does work, that
justifies building two variants with and without EFI... it is a bit ugly
to produce two variants, but it's the easiest known workaround for
now...


Will try to test EFI on the odroid-c2 shortly...


live well,
vagrant

[Vagrant Cascadian]

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.


live well,
vagrant

[Vagrant Cascadian]

On 2023-01-03, Frédéric Danis wrote:

> On 03/01/2023 18:55, Vagrant Cascadian wrote:
>> On 2023-01-03, Frédéric Danis wrote:
>>> Afaiu, the bug is not reproducible with unstable and experimental
>>> versions, but boot crash before starting the kernel, see
>>> lepotato-unstable.txt and lepotato-experimental.txt.
>> Sounds like the bug *is* reproducible with unstable and experiemental
>> versions, from reading the logs; looks like the same issue with
>> odroid-c2.
>>
>> Could you try building a "noefi" variant, like done with odroid-c2, and
>> test for the lepotato (libretech-cc?):
>>
>> https://salsa.debian.org/debian/u-boot/-/commit/711ca985af1cab6f11e33fcf5e30dcc40dc7e64d
>

> I will try to build and test this

>
>> Could you also test EFI booting with the versions from unstable and
>> experimental to see if they can load a kernel? If EFI does work, that
>> justifies building two variants with and without EFI... it is a bit ugly
>> to produce two variants, but it's the easiest known workaround for
>> now...
>

> I will need your help on this as I don't know how to test EFI boot, for
> me EFI was specific to Intel platforms.
> Can you point me to a doc explaining how to do this on LePotato/Arm board?

What I did for the odroid-c2 was download the debian-installer mini.iso:

https://d-i.debian.org/daily-images/arm64/daily/netboot/

And dump it onto a USB stick. Then at boot, I interrupted the boot
process, and at the u-boot prompt:

setenv boot_targets usb0
boot

This of course presumes usb works for your platform.

You might be able to do a dance with microSD or whatever by booting from
microSD, yanking the microSD card, inserting a microSD card with the
mini.iso installed, rescanning the mmc bus, etc. but that is obviously a
lot tricker!

live well,
vagrant

[Heinrich Schuchardt]

Hello Vagrant,

copying initrd to high memory overwrites internal EFI structures.

setenv initrd_high 0xffffffffffffffff
setenv fdt_high 0xffffffffffffffff

solves the problem on the Odroid C2.

Best regards

Heinrich

[Vagrant Cascadian]

Control: forwarded 1027176 https://lists.denx.de/pipermail/u-boot/2023-January/503745.html

On 2023-01-06, Vagrant Cascadian wrote:
> On 2023-01-05, Vagrant Cascadian wrote:
>> There has been some recent discussion in irc.libera.chat #u-boot and
>> #linux-amlogic about this issue, so the possibility of an upstream fix
>> coming is not impossible.
>
> Hopefully we'll see a proper fix coming from upstream... :)

And we may have just that:

https://lists.denx.de/pipermail/u-boot/2023-January/503745.html

https://patchwork.ozlabs.org/project/uboot/list/?series=335240&archive=both&state=*

Will test shortly...

live well,
vagrant