[Pkg-raspi-maintainers] Bug#1013632: bullseye-pu: package raspi-firmware/1.20210303+ds-3

Fri Jun 24 12:47:54 BST 2022

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian.org at packages.debian.org
Usertags: pu
X-Debbugs-Cc: raspi-firmware at packages.debian.org

Hi,

[ Reason ]

The raspi-firmware package provides support for Raspberry Pi devices,
including bootloading. Unfortunately, support for Compute Modules (CM3
and CM4) is currently broken, as the bootloader only tries to load the
DTB files under their Raspberry Pi names, which differ from the mainline
(and therefore Debian) ones. This means that CM3 devices don't boot, at
all; and that CM4 devices boot but pretend to be Pi 4 B devices, meaning
things like Ethernet or USB don't work (#1010317), which is highly
confusing.

The missing “mainline DTB” lookup was fixed in unstable/testing, but
cannot be backported to stable since bootlooader files are closed source
(Broadcom etc.); it's also unrealistic to backport the new version
wholesale as incremental uploads to unstable showed a pattern of
critical regressions.

I'm therefore proposing adding a manual copy of both DTBs (the CM3 one
and the CM4 one) under their Raspberry Pi names so that the old
bootloader finds them.

To make sure CM4 devices work fine, I'm also adding the required
detection to adjust some settings, which was merged into unstable a
while ago (#996937).


[ Side note ]

CM4 support (DTB in src:linux) is bullseye-only. CM3 support was there
in buster already, but is similarly broken (missing DTB lookup); it
turned out that my initial work on this was fine until manual DTB copies
were dropped during the buster release cycle, but that went unnoticed.
I'm not sure it makes sense to patch the buster package to fix CM3
support there, given we're close to EOL and nobody noticed until I did a
few months back.


[ Impact ]

No CM3 support, broken CM4 support.


[ Tests ]

I've tested the updated package on a number of Pi 3, Pi 4, CM3, and CM4
setups, everything looks good.


[ Risks ]

Since the DTB copy is not necessary in unstable/testing, it's not been
implemented in the unstable/testing package. That means that the last
CM3/CM4 DTB that would have been copied with this updated raspi-firmware
on bullseye would be left behind. I'm not sure about the precedence
(Raspberry Pi name with fallback to mainline names, or the other way
around), so it might make sense to have the unstable/testing package get
rid of those obsolete copies, to make sure they don't get in the way.
I'm not sure it (1) is required or (2) should be a prerequisite to
fixing the package in bullseye.

After all, DTBs might vary a little over time but since they're hardware
description, we don't expect them to change dramatically.


[ Changes ]

    raspi-firmware (1.20210303+ds-3) bullseye; urgency=medium
    
      * Factorize Pi 4 detection, used for GPU_FREQ and CMA settings. Also
        discard confusing error messages when neither /sys/firmware/devicetree
        nor /proc/device-tree exist, which is the case when building images
        (e.g. with image-specs).
      * Add support for Compute Module 4 devices: they are in the Pi 4 family
        as well, just like the Pi 4 B and Pi 400 models, need the same tweaks
        for the CMA setting, and might require adjusting GPU_FREQ to ensure
        the serial console is usable (Closes: #996937)
      * Work around missing bootloader support for Compute Modules, resulting
        in CM3 not booting and CM4 pretending to be a Pi 4 B (Closes: #1010317):
         - deploy bcm2837-rpi-cm3-io3.dtb as bcm2710-rpi-cm3.dtb as well;
         - deploy bcm2711-rpi-cm4-io.dtb as bcm2711-rpi-cm4.dtb as well;
         - ignore errors when deploying under the extra names: not all
           linux-image packages contain the Compute Module DTBS.
    
     -- Cyril Brulebois <cyril at debamax.com>  Fri, 24 Jun 2022 13:24:22 +0200


Thanks for your time!


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
-------------- next part --------------
diff -Nru raspi-firmware-1.20210303+ds/debian/changelog raspi-firmware-1.20210303+ds/debian/changelog

--- raspi-firmware-1.20210303+ds/debian/changelog	2021-04-21 07:52:21.000000000 +0200
+++ raspi-firmware-1.20210303+ds/debian/changelog	2022-06-24 13:24:22.000000000 +0200
@@ -1,3 +1,22 @@
+raspi-firmware (1.20210303+ds-3) bullseye; urgency=medium
+
+  * Factorize Pi 4 detection, used for GPU_FREQ and CMA settings. Also
+    discard confusing error messages when neither /sys/firmware/devicetree
+    nor /proc/device-tree exist, which is the case when building images
+    (e.g. with image-specs).
+  * Add support for Compute Module 4 devices: they are in the Pi 4 family
+    as well, just like the Pi 4 B and Pi 400 models, need the same tweaks
+    for the CMA setting, and might require adjusting GPU_FREQ to ensure
+    the serial console is usable (Closes: #996937)
+  * Work around missing bootloader support for Compute Modules, resulting
+    in CM3 not booting and CM4 pretending to be a Pi 4 B (Closes: #1010317):
+     - deploy bcm2837-rpi-cm3-io3.dtb as bcm2710-rpi-cm3.dtb as well;
+     - deploy bcm2711-rpi-cm4-io.dtb as bcm2711-rpi-cm4.dtb as well;
+     - ignore errors when deploying under the extra names: not all
+       linux-image packages contain the Compute Module DTBS.
+
+ -- Cyril Brulebois <cyril at debamax.com>  Fri, 24 Jun 2022 13:24:22 +0200
+
 raspi-firmware (1.20210303+ds-2) unstable; urgency=medium
 
   * Add a header to config.txt warning users it's an autogenerated file
diff -Nru raspi-firmware-1.20210303+ds/debian/kernel/postinst.d/z50-raspi-firmware raspi-firmware-1.20210303+ds/debian/kernel/postinst.d/z50-raspi-firmware
--- raspi-firmware-1.20210303+ds/debian/kernel/postinst.d/z50-raspi-firmware	2021-04-21 07:52:21.000000000 +0200
+++ raspi-firmware-1.20210303+ds/debian/kernel/postinst.d/z50-raspi-firmware	2022-05-17 23:34:25.000000000 +0200
@@ -19,6 +19,15 @@
     ;;
 esac
 
+
+pi_4_family() {
+  # This matches all RPi4 boards ("Raspberry Pi 4 Model B Rev 1.4"),
+  # Pi400 full computer systems ("Raspberry Pi 400 Rev 1.0"), and
+  # CM4 compute modules ("Raspberry Pi Compute Module 4 Rev 1.0").
+  grep -q 'Raspberry Pi \(Compute Module \)*4' /sys/firmware/devicetree/base/model 2>/dev/null
+}
+
+
 if ischroot ; then
   true # chroot detected - skip mount point check
 elif test -e /usr/bin/systemd-detect-virt && systemd-detect-virt -q ; then
@@ -83,6 +92,10 @@
       cp "${dtb}" /boot/firmware/
   done
 
+  # Workaround for missing CM3/CM4 support in pre-1.20220118 versions (#1010317):
+  cp "${dtb_path}/bcm2837-rpi-cm3-io3.dtb" /boot/firmware/bcm2710-rpi-cm3.dtb || true
+  cp "${dtb_path}/bcm2711-rpi-cm4-io.dtb"  /boot/firmware/bcm2711-rpi-cm4.dtb || true
+
   latest_kernel_basename=$(basename "$latest_kernel")
   latest_initrd_basename=$(basename "$latest_initrd")
   KERNEL=${latest_kernel_basename}
@@ -114,10 +127,8 @@
 EOF
 fi
 
-if grep -q 'Raspberry Pi 4' /sys/firmware/devicetree/base/model
+if pi_4_family
 then
-    # This matches all RPi4 boards ("Raspberry Pi 4 Model B Rev 1.4")
-    # and p400 full computer systems ("Raspberry Pi 400 Rev 1.0")
     if [ "$GPU_FREQ" != "auto" ]
     then
 	echo "core_freq=$GPU_FREQ" >> /boot/firmware/config.txt
@@ -178,7 +189,7 @@
 # specifying CMA as with earlier models renders it unbootable. Omit
 # the setting for RPi4 if it is at the default 64M (if the
 # administrator has changed it, they should know what they are doing!)
-if [ "$CMA" = "64M" ] && grep -q 'Raspberry Pi 4' /proc/device-tree/model ; then
+if [ "$CMA" = "64M" ] && pi_4_family; then
     SET_CMA=''
 else
     SET_CMA="cma=$CMA"
