[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1013632: marked as done (bullseye-pu: package raspi-firmware/1.20210303+ds-3)

Your message dated Tue, 7 Feb 2023 16:07:19 +0100
with message-id <20230207150719.avlz3avto5pw4nyp@debamax.com>
and subject line Re: [Pkg-raspi-maintainers] Bug#1013632: Bug#1013632: bullseye-pu: package raspi-firmware/1.20210303+ds-3
has caused the Debian Bug report #1013632,
regarding bullseye-pu: package raspi-firmware/1.20210303+ds-3
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1013632: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013632
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian.org@packages.debian.org
Usertags: pu
X-Debbugs-Cc: raspi-firmware@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@debamax.com>  Fri, 24 Jun 2022 13:24:22 +0200


Thanks for your time!


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

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@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"

--- End Message ---
--- Begin Message --- 
Hi Adam,

Adam D. Barratt <adam@adam-barratt.org.uk> (2022-07-01):
> On Fri, 2022-06-24 at 14:56 +0200, Cyril Brulebois wrote:
> > I'll follow up with an updated patch once I've performed some more
> > testing.
> 
> Did you have chance to look at that yet? I realise that the above
> message was only a week ago, I'm just wondering if we might be looking
> at this for 11.4 still, as uploads for that close during this weekend.

Given how close we are to having bookworm released, I don't think it
makes sense to patch raspi-firmware in bullseye any more (especially
since the easy fix could have triggered problems during upgrades).

Closing accordingly, sorry for leaving that one on your radar for so
long!


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Attachment: signature.asc
Description: PGP signature


--- End Message ---
Reply to: