Wrong DTB chosen for Raspberry Pi Compute Module 4 (all.db)
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| flash-kernel (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Bug Description
When using Ubuntu on a Raspberry Pi Compute Module 4 Rev 1.0, the DTB for Model 4B is chosen. This is incorrect, as the CM4 has a dedicated DTB file to be used instead (slightly different hardware).
The incorrect section in 'all.db' is this one:
Machine: Raspberry Pi 4 Model B
Machine: Raspberry Pi 4 Model B Rev 1.1
Machine: Raspberry Pi 4 Model B Rev 1.2
Machine: Raspberry Pi 4 Model B Rev 1.4
Machine: Raspberry Pi Compute Module 4 Rev 1.0
Machine: Raspberry Pi 400 Rev 1.0
Machine: Raspberry Pi *
Kernel-Flavors: raspi
Method: pi
DTB-Id: bcm2711-rpi-4-b.dtb
U-Boot-Script-Name: bootscr.rpi
Required-Packages: u-boot-tools
which assigns the 4B DTB also to the CM4. The correct DTB assignment for the CM4 would be:
DTB-Id: bcm2711-rpi-cm4.dtb
So, I successfully fixed this issue locally by adding the following section at the start of the 'all.db' file:
Machine: Raspberry Pi Compute Module 4 Rev 1.0
Kernel-Flavors: raspi
Method: pi
DTB-Id: bcm2711-rpi-cm4.dtb
U-Boot-Script-Name: bootscr.rpi
Required-Packages: u-boot-tools
and removing the line
Machine: Raspberry Pi Compute Module 4 Rev 1.0
from the original section.
This works nicely, but I am not sure about any implications for other systems. Could someone please have a look into this.
Side note: The catch-all line
Machine: Raspberry Pi *
might make it harder to use strict alphabetic ordering of the Machine entries, as the CM4 entry must be inserted *before* the catch-all line in order to be effective.
Thank you for your consideration.
| Dave Jones (waveform) wrote | #1 |
| Dave Jones (waveform) wrote | #2 |
| Launchpad Janitor (janitor) wrote | #3 |
| Changed in flash-kernel (Ubuntu): | |
| status: | New → Confirmed |
| Launchpad Janitor (janitor) wrote | #4 |
| Changed in flash-kernel (Ubuntu): | |
| status: | Confirmed → Fix Released |
Sorry, but this is a bit of a mis-understanding. The situation on the Pi is a bit more complicated than this:
There's long been an expectation in the Raspberry Pi community (driven largely by Raspbian's upgrade strategy on the release of new Pi models) that one can move an SD card from Pi to Pi (obviously this doesn't *exactly* apply to those Compute Module models with eMMC, but it's still relevant to this issue so bear with me :).
Historically, flash-kernel had a baked in assumption that each board in its database had one dtb (and *only* one dtb) associated with it. That dtb was to be baked into the u-boot setup and copied to ... wherever it needed to be copied (typically a boot partition of some kind). However, that doesn't work for the Raspberry Pi where users expected to be able take their existing SD card working on, say, a Pi 3B, "sudo apt update; sudo apt upgrade", move that card to their shiny new Pi 4B, and boot it up (this was an explicitly supported upgrade path on Raspbian (as it then was) that we also wanted to support on Ubuntu).
Obviously in this case, it's no good just copying the dtb for the board that flash-kernel finds itself on because tomorrow, it might be expected to boot on an entirely different model. That's why, at some point in 20.10 release (I think?), I introduced the "Method: pi" clause to our flash-kernel entries for the Raspberry Pi. Firstly, this dropped u-boot from the boot chain (the u-boot binaries still get copied, but they're not expected to be used by default -- they're only there for those that still need them for some reason). Secondly, it tells flash-kernel to *ignore* the DTB-Id and just copy *all* the dtbs it finds to the boot partition.
Why is the DTB-Id entry still there if it's not used? Unfortunately, flash-kernel still has an assumption in several places that each database entry has to have some DTB-Id specified. Removing that assumption would have enlarged our delta significantly without much purpose.
In other words, you are absolutely correct that the entry lists the "wrong" dtb for the CM4, but because "Method: pi" is also in that entry, it doesn't actually matter. All the dtbs (including those for the pi 2, 3, and Zero 2) get copied in this instance.