[Bug 1811216] Re: Support both armhf and arm64 raspi3 in flash-kernel

[Łukasz Zemczak]

hm, we never really officially supported the raspi3, but it is worrying
to have broken users. So it is a valid concern. One way to proceed here
would be to switch back the FDT address to 0x02008000 for armhf in
flash-kernel and only leave it bumped in arm64 (as it's needed there). I
only changed it for both because of consistency, but there are anyway
differences between both boot scripts so it really doesn't matter. I'll
look into getting that done.

As for boot.scr, well, in my first attempts I actually used uboot.env as
well, but then saw that flash-kernel advertises it instead, so I
switched (that was also what Ryan's images used IIRC). Since I had no
strong preferences, I just switched to that instead.

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

Title:
  Support both armhf and arm64 raspi3 in flash-kernel

Status in flash-kernel package in Ubuntu:
  Fix Released
Status in flash-kernel source package in Bionic:
  Fix Committed
Status in flash-kernel source package in Cosmic:
  Fix Committed

Bug description:
  [Impact]

  Currently the boot.scr provided by flash-kernel for rpi3 uses bootz for booting the kernel, an uboot command that only works for armhf kernels. This means that in case the boot.scr on a pi3 arm64 gets updated on upgrade, the system will stop booting. Easiest way is to support separate bootscripts for arm64 and armhf.
  Also, to fully support all the strange cases for arm64, the boot address parameters need to be adjusted for a bigger kernel. The arm64 kernel, in contrast to the armhf one, is not compressed and takes up much more space in memory.

  This is basically only needed for bionic as we don't intend to build
  raspi3 images on cosmic, but SRUs will be provided for all series.

  [Test Case]

   * Boot up an arm64 based image on a raspi3 and log into it
   * Run flash-kernel
   * Check for errors
   * Check if /boot/firmware/boot.scr still has booti as its boot command
   * Reboot
   * Check if system still boots correctly

  [Regression Potential]

  The only regression potential is in actually making the image not
  booting, so running the SRU test case should validate that. There's
  basically no other regression potential I can think of.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/flash-kernel/+bug/1811216/+subscriptions