SRU provide RISCV_EFI_BOOT_PROTOCOL in Focal

This debdiff solves the problem but there is a parallel SRU ongoing with which I need to coordinate.

The attachment "u-boot_2021.01+dfsg-3ubuntu0~20.04.4..3ubuntu0~20.04.5.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

In the patch, in efi_riscv_get_boot_hartid, should this:

  return EFI_INVALID_PARAMETER

have a reference to EFI_EXIT, i.e.:

  return EFI_EXIT(EFI_INVALID_PARAMETER)

It appears in other EFI implementations within u-boot that whenever EFI_ENTRY is called, EFI_EXIT is called on exit of the function (whether successful or not)? I assume this is a fairly minor note though, as presumably in this case boot is going to fail anyway.

Thank you Dave for identifying this bug in upstream U-Boot. I now have created

[PATCH 1/1] efi_loader: use EFI_EXIT in efi_riscv_get_boot_hartid
https://lists.denx.de/pipermail/u-boot/2023-January/504464.html

I will amend the debdiff.

Debdiff with additional d/p/d/p/riscv64/0001-efi_loader-use-EFI_EXIT-in-efi_riscv_get_boot_hartid.patch.

Looks good, sponsoring for focal

This bug mentions in the Impact section running 5.19 kernels on focal, but from what I see on the cdimage manifests 5.15 is the kernel that the riscv64 unmatched images use (coming from linux-riscv-5.15). Later it's also mentioned that 5.15 kernels can possibly be affected. Is my assumption correct that this might be a problem with the 5.15 kernels right now?

I'll accept it anyway, but I'd like to have some clarification before that. Do we know if the change causing potential issues is planned to go into 5.15? Should we make sure that this new u-boot version is updated before the affected kernel is upgraded on user machines?

Hello Heinrich, or anyone else affected,

Accepted u-boot into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/u-boot/2021.01+dfsg-3ubuntu0~20.04.6 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Also - I assume those patches are already in the newer Ubuntu series u-boot?

All autopkgtests for the newly accepted u-boot (2021.01+dfsg-3ubuntu0~20.04.6) for focal have finished running.
The following regressions have been reported in tests triggered by the package:

livecd-rootfs/2.664.45 (amd64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#u-boot

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

>> I assume those patches are already in the newer Ubuntu series u-boot?
Yes, they are available in kinetic and lunar.

u-boot-qemu 2021.01+dfsg-3ubuntu0~20.04.6 package tested successfully
with the following observations which are not a change from 2021.01+dfsg-3ubuntu0~20.04.5:

Booting https://cdimage.ubuntu.com/ubuntu-server/focal/daily-preinstalled/current/focal-preinstalled-server-riscv64+unmatched.img.xz (2022-10-31 07:04) on QEMU failed with

Retrieving file: /boot/initrd.img-5.15.0-1022-generic
118495394 bytes read in 15 ms (7.4 GiB/s)
Retrieving file: /boot/vmlinuz-5.15.0-1022-generic
29512704 bytes read in 4 ms (6.9 GiB/s)
append: root=LABEL=cloudimg-rootfs ro earlycon single
Retrieving file: /lib/firmware/5.15.0-1022-generic/device-tree/qemu-riscv.dtb
Failed to load '/lib/firmware/5.15.0-1022-generic/device-tree/qemu-riscv.dtb'
Skipping l0r for failure retrieving fdt
SCRIPT FAILED: continuing...
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Scanning disk virtio-blk#8...

due to this entry in /boot/extlinux/extlinux.conf:

fdtdir /lib/firmware/5.15.0-1022-generic/device-tree/

Booting manually worked with the following commands:

=> virtio scan
=> load virtio 0:1 $kernel_addr_r /boot/vmlinuz-5.15.0-1022-generic
29512704 bytes read in 3 ms (9.2 GiB/s)
=> load virtio 0:1 $ramdisk_addr_r /boot/initrd.img-5.15.0-1022-generic
118495394 bytes read in 14 ms (7.9 GiB/s)
=> setenv bootargs root=/dev/vda1
=> booti $kernel_addr_r $ramdisk_addr_r:$filesize $fdtcontroladdr

https://cdimage.ubuntu.com/releases/kinetic/release/ubuntu-22.10-preinstalled-server-riscv64+unmatched.img.xz booted in the same way:

=> load virtio 0:1 $kernel_addr_r /boot/vmlinuz-5.19.0-1004-generic
31656960 bytes read in 3 ms (9.8 GiB/s)
=> load virtio 0:1 $ramdisk_addr_r /boot/initrd.img-5.19.0-1004-generic
111792546 bytes read in 13 ms (8 GiB/s)
=> setenv bootargs root=/dev/vda1
=> booti $kernel_addr_r $ramdisk_addr_r:$filesize $fdtcontroladdr
Bad Linux RISCV Image magic!

We should consider moving images for QEMU/Unmatched to using GRUB.

u-boot-sifive 2021.01+dfsg-3ubuntu0~20.04.6 tested successfully on Unmatched board both with the Focal as well as with the Kinetic preinstalled images.

Tags haven't been updated for this upload, which is why it was not considered as verified. Please remember about setting the verification-done tags next time!

This bug was fixed in the package u-boot - 2021.01+dfsg-3ubuntu0~20.04.6

---------------
u-boot (2021.01+dfsg-3ubuntu0~20.04.6) focal; urgency=medium

  * Provide RISCV_EFI_BOOT_PROTOCOL (LP: #1998513)
    d/p/riscv64/0001-efi_loader-Enable-RISCV_EFI_BOOT_PROTOCOL-support.patch
    d/p/riscv64/0001-efi_loader-use-EFI_EXIT-in-efi_riscv_get_boot_hartid.patch
  * Add /chosen/boot-hartid to device-tree even if there is no chosen node
    (LP: #1998513)
    d/p/riscv64/0001-riscv-Fix-arch_fixup_fdt-always-failing-without-chos.patch

 -- Heinrich Schuchardt <email address hidden> Wed, 11 Jan 2023 19:29:44 +0100

The verification of the Stable Release Update for u-boot has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.