Bug#1010317: raspi-firmware: broken support for CM3 and CM4 devices
Cyril Brulebois
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/
Cyril Brulebois
Cyril Brulebois <ki...@debian.org> (2022-04-28):
> 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).
discovering, debugging, and trying to get a boot failure on CM4
fixed[1,2].
1. https://bugzilla.kernel.org/show_bug.cgi?id=215925
2. https://bugs.debian.org/1010365
In the meantime, I finally realized that the cm3/cm4 sections aren't
actually working as I thought they did. The model filters section[3]
of the upstream doc seemed to be lacking the [cm3] entry, but that's
actually… really not supported by the bootloader!
3. https://www.raspberrypi.com/documentation/computers/config_txt.html#model-filters
Given this configuration:
[cm3]
device_tree=bcm2837-rpi-cm3-io3.dtb
[cm4]
device_tree=bcm2711-rpi-cm4-io.dtb
further testing seems to indicate that:
1. the [cm3] line is invalid and ignored;
2. a regular Pi 3 would get device_tree=bcm2837-rpi-cm3-io3.dtb which
isn't made conditional by a (valid) filter;
3. a CM 3 would get device_tree=bcm2837-rpi-cm3-io3.dtb which isn't
made conditional by a (valid) filter;
4. a CM 4 would get device_tree=bcm2711-rpi-cm4-io.dtb via the (valid)
[cm4] filter.
I hadn't spotted this before because a Pi 3, given a CM3 DTB, would boot
fine! And this is very different from the other way around, i.e. a CM3
wouldn't boot given a Pi 3 DTB (which is the initial state, without any
configuration).
For completeness, board-type filters[4] could be used instead. Here's a
valid configuration to support CM3, CM3+, and CM4 respectively:
[board-type=0x0A]
device_tree=bcm2837-rpi-cm3-io3.dtb
[board-type=0x10]
device_tree=bcm2837-rpi-cm3-io3.dtb
[board-type=0x14]
device_tree=bcm2711-rpi-cm4-io.dtb
4. https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#new-style-revision-codes
This is using board-type everywhere for consistency, but the last entry
could also be written with the supported [cm4] filter.
In any case, instead of fiddling with configuration, I still think it
makes sense to duplicate two DTBs under their Raspberry Pi names, and
I've extensively tested the package for proposed-updates during my
repeated debugging sessions for #1010365, so I'm quite confident this
should be fine.
Diederik de Haas
> Package: raspi-firmware
> Version: 1.20210303+ds-2
> Severity: important
version 1.20220830+ds-1 and ideally also with upstream's 1.20230106.
(I really hope upstream releases another version as they've now also switched
to the 6.1 kernel series)
Cyril Brulebois
> version 1.20220830+ds-1 and ideally also with upstream's 1.20230106.
>
> (I really hope upstream releases another version as they've now also switched
> to the 6.1 kernel series)
I haven't checked lately for possible regressions since then, but I'll
be sure to file bug reports for them and come up with a plan if needed.
Next “let's play with Raspberry devices” window for me is a few weeks
from now.