[Bug 2110301] Re: [SRU] Backport u-boot 2025.01-3 to Noble

[Dave Jones]

> Except on RISC-V none of the U-Boot packages has post install scripts.
Changes to the U-Boot packages affect current installations only if the
user manually updates the firmware.

One minor exception to this is the u-boot-rpi package, which was auto-
installed via flash-kernel historically, but as already noted, u-boot is
not used on rpi on noble [1].

Speaking more generally about testing:

There are no official images (that we know of) that use u-boot-amlogic
or any of the other arm64 or armhf builds. The is at least one
unofficial image using one of the arm64 builds (Ubuntu Asahi, which uses
u-boot-asahi) but given these are unsupported platforms we lack any
capacity to test these builds in a meaningful way [2]. However, there is
a proxy of sorts...

The general story with testing these binaries is:

* For officially supported hardware (read: RISC-V at the present time),
the binaries do indeed receive testing and verification.

* For unsupported hardware: we bump u-boot for a new release and ... see
if anyone complains. Anyone using these binaries on unsupported
platforms might reasonably expect dist-upgrades to be a risky prospect,
and hopefully will file a bug if they encounter a problem.

The corollary to this practice is that, if a given version has been in
service in a release for a while without incident, we have a reasonable
expectation that it is "good" [3]. Given 2025.01 has been used
throughout plucky's existence (and will also be the version in
questing), this is our proxy that the version is "okay".

It could be argued that this version is different as it'll be running in
noble's environment rather than plucky's. However, bootloaders are
fairly uniquely "disconnected" from the rest of the environment (having
effectively no presence once the kernel gets going, beyond the influence
of the artefacts they have passed to the kernel), which (at least
partially) mitigates this concern.

[1] I could test the u-boot-rpi package on my Raspberry Pis, but that
doesn't tell us much that's genuinely useful (it tells us one set of
binaries works on a board where we don't use them, but it doesn't tell
us that any other binaries will boot any another board).

[2] I could test the u-boot-asahi package as my husband uses Ubuntu on a
Mac M1 Mini.

[3] ... or "not used by anybody"

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to u-boot in Ubuntu.
https://bugs.launchpad.net/bugs/2110301

Title:
  [SRU] Backport u-boot 2025.01-3 to Noble

Status in u-boot package in Ubuntu:
  Invalid
Status in u-boot source package in Noble:
  In Progress
Status in u-boot source package in Oracular:
  Won't Fix
Status in u-boot source package in Plucky:
  Invalid

Bug description:
  [ Impact ]

  With the release of Ubuntu 25.04 (Plucky) we support new RISC-V
  hardware:

  * Pine64 Star64
  * DeepComputing FML13V01

  In the 25.10 cycle we will upgraded the ISA from RVA20 to presumably
  RVA23. This implies that hardware that is not RVA23 compliant will
  only be supported on 24.04 in the long term.

  We therefore need to backport the hardware support to 24.04. This
  includes:

  * U-Boot
  * Kernel 6.14 (already completed)

  With this SRU we will backport U-Boot 2025.01-3 to Noble.

  [ Test Plan ]

  For each $board:

  * DeepComputing FML13V01
  * Microchip Icicle Kit
  * Milk-V Mars
  * Pine64 Star64
  * StarFive VisionFive 2
  * SiFive Unmatched

  If the $board was originally supported on the affected $series:

  * Flash the pre-installed image from cdimage for the $series and $board combination
  * Boot the image
  * sudo apt install -t $series-proposed u-boot-$board (e.g. u-boot-starfive)
  * Update U-Boot on the SD-card (only u-boot-microchip, u-boot-sifive do this via postinst automatically)
  * sudo reboot
  * Interrupt the boot sequence
  * echo $fdtfile (check that u-boot's fdtfile variable shows the value matching the board)
  * Exit to allow boot to continue
  * Check boot succeeds

  See the descriptions in the Ubuntu manual tests
  (https://iso.qa.ubuntu.com/) for the respective boards.

  If $board was *not* originally supported on the affected $series:

  * Build test image incorporating proposed version (this may require PPA usage); instructions for this omitted for brevity
  * Boot the image
  * echo $fdtfile (check that u-boot's fdtfile variable shows the value matching the board)
  * Exit to allow boot to continue
  * Check boot succeeds

  Check that booting via GRUB into Ubuntu works.

  [ Where problems could occur ]

  Updating the bootloader always carries the risk of breaking boot on
  user's machines. That said, a bootloader is necessarily a standalone
  binary (when running at boot time). The particular upstream version we
  are backporting is already in successful use in plucky, giving us a
  reasonable degree of confidence that this version is fundamentally
  sound.

  The backport in plucky's case simply incorporates changes to the
  debian/ directory which occurred after plucky's release (we sync'd
  from Debian's experimental branch during plucky).

  The backport for oracular and noble is an actual upstream version
  bump; the risk here is that the build acts differently (e.g. due to
  differences in the build dependencies). To guard against that, the
  test plan covers all potentially affected boards (for which we produce
  official images), not just those on which we hope to enable boot.

  [ Other Info ]

  N/A

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/u-boot/+bug/2110301/+subscriptions