[Bug 1936370] Re: u-boot-sifive does not upgrade u-boot on disk

Heinrich Schuchardt 1936370 at bugs.launchpad.net
Fri Jul 16 07:41:21 UTC 2021


> But does not check what was on the 
> partitions before, or if they were used at all or not.

This is what our impish image looks like:

Number  Start (sector)    End (sector)  Size       Code  Name
   1          235554         7339998   3.4 GiB     8300  
  12          227362          235553   4.0 MiB     8300  CIDATA
  13              34            2081   1024.0 KiB  FFFF  loader1
  14            2082           10273   4.0 MiB     FFFF  loader2
  15           10274          227361   106.0 MiB   EF00

Partitions 13 and 14 are only protective partitions. They are not needed
at all to boot via U-Boot.

The place to flash U-Boot SPL (sector 34) is hard coded in the boot ROM.
The offset of 1 MiB to main U-Boot is encoded as jump address in OpenSBI.
The total length of main U-Boot is well below 4 MiB. But those 4 MiB will be large enough to install EDK II once released.

If U-Boot was previously installed it cannot be in a different place.

What you could check is that no partition with data (type 8300, EF00,
...) collides with what you flash.

Best regards

Heinrich

-- 
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/1936370

Title:
  u-boot-sifive does not upgrade u-boot on disk

Status in u-boot package in Ubuntu:
  Fix Released
Status in u-boot source package in Focal:
  New
Status in u-boot source package in Hirsute:
  New
Status in u-boot source package in Impish:
  Fix Released

Bug description:
  [Impact]

   * u-boot-sifive package currently does not upgrade bootloader on
  loader1/loader2 partitions.

   * there have now been bugs identified, meaning that upgrading u-boot
  is required to upgrade from v5.8 kernel to v5.11 (i.e. either in-
  focal, or from focal to hirsute).

   * Add maintainer script that identifies if the machine one is running
  on is unleashed or unamtched, and appropriately upgrades the
  bootloader on loader1/loader2 partitions.

  [Test Plan]

   * Boot older unleashed or unmatched image

   * Check version strings of loader1/loader2 partitions

  $ sudo strings /dev/disk/by-partlabel/loader* | grep 202 | grep U-Boot

   * Upgrade u-boot-sifive to latest package

   * Check version strings of loader1/loader2 partitions, they should
  have changed

  $ sudo strings /dev/disk/by-partlabel/loader* | grep 202 | grep U-Boot

   * Reboot, and observe on the serial console that u-boot version
  number is incremented to the latest one.

   * Repeat the test twice, once with unleashed board, once with
  unmatched board

   * Upgrade the package under qemu VM and observe no side-effects / no
  attempts to upgrade anything.

  [Where problems could occur]

   * It is not possible to atomically upgrade loader1 and loader2 simultaniously.
   * A backup of loader1 and loader2 partitions is not stored anywhere.
   * Thus in case of errors rollback of older u-boot is not performed.
   * However if dd of one or the other partition fails, it is unlikely that one can restore the backup.

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




More information about the foundations-bugs mailing list