[Pkg-raspi-maintainers] Bug#1010317: raspi-firmware: broken support for CM3 and CM4 devices

[Cyril Brulebois]

Package: raspi-firmware
Version: 1.20210303+ds-2
Severity: important

Hi,

Back when I worked on CM3 support for buster[1], the postinst script was
still deploying DTB files under the Raspberry names[2], so I didn't
spot the regression until a few months ago:

- a Pi CM3, mounted on the official Compute Module IO Board V3,
  wouldn't boot at all (stuck on the rainbow);

- a Pi CM4, mounted on the official Compute Module 4 IO Board, would
  boot but would believe it's a Pi 4 B; side effects would include
  non-functional on-board Ethernet and on-board USB.

 1. https://debamax.com/blog/2019/09/09/adding-raspberry-pi-cm3-support-to-debian-buster/
 2. https://github.com/raspberrypi/linux/

Those names are slightly different compared to what got merged into
mainline (DTS files are added there by individuals, Raspberry people
don't upstream support for their own hardware…), and the bootloader we
have in bullseye only knows about the Raspberry names for the compute
modules, not the mainline ones[3].

 3. https://github.com/raspberrypi/firmware/issues/1660

Ever since we moved away from copying each file individually from the
mainline name to the Raspberry name in [4], support for compute modules
was broken. It first shipped in debian/1.20200114-2 (and only broke CM3
support at the time, CM4 hadn't been added yet).

 4. https://salsa.debian.org/debian/raspi-firmware/-/commit/165f43a6ca14d240f199e8ab8924e503ca5f427d

At some point I was hoping it might be feasible to consider backporting
the bootloader to bullseye, but it has become increasingly obvious that
the balance between bugfixes/new features and regressions isn't really
going the way we'd like. Of course, we don't have access to the source
files, and it's not even directly possible to decompile the binaries
to see what they're doing. As far as I know, one would need Ghidra plus
a pull request that hasn't been merged yet[5]. Whether this could be
used to actually patch the binaries (in a more targeted way than just
shipping some newer upstream releases wholesale), and whether this would
even be legal is anyone's guess.

 5. https://github.com/NationalSecurityAgency/ghidra/pull/1147

Since the issue has been fixed upstream and released to unstable and
testing, I'd like to suggest moving to my plan B, which would be to
restore copying files under Raspberry names, but only the 2 required
ones. Of course, the partition is FAT so we can't use symlinks, so that
means wasting a little space. But that seems to outweigh the drawbacks
outlined in introduction!

Alternatively, one can force a specific device_tree via config.txt:

    device_tree=bcm2837-rpi-cm3-io3.dtb # CM3
    device_tree=bcm2711-rpi-cm4-io.dtb  # CM4

or even try and use model filters to do that automatically:

    [cm3]
    device_tree=bcm2837-rpi-cm3-io3.dtb

    [cm4]
    device_tree=bcm2711-rpi-cm4-io.dtb

but using that would inevitably confuse users, who might need to learn
about model filters[6].

 6. https://www.raspberrypi.com/documentation/computers/config_txt.html#model-filters


I'll be working on a patch for my proposed approach (duplicating two DTB
files), combining it with a fix for #996937, and opening up a p-u
request once everything has been tested (in unstable for #996937, and in
bullseye for this issue and #996937).


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