Contents

Section	Topic
1	About this Volume
2	The Compute-Module Standard
· 2.1	Why Pi adopted the DF40 mezzanine
· 2.2	The 200-pin pinout in functional groups
· 2.3	What the uConsole mainboard actually uses
3	Raspberry Pi CM4
· 3.1	SoC and topology
· 3.2	The variant matrix
· 3.3	Lite vs eMMC: what changes for the uConsole
· 3.4	WiFi-equipped vs WiFi-less
· 3.5	Power, thermals, and the uConsole envelope
· 3.6	Boot path
· 3.7	Where to buy and what costs what
4	Raspberry Pi CM5
· 4.1	SoC and topology — what changed from CM4
· 4.2	The variant matrix (CM5)
· 4.3	Pin compatibility: same connectors, not the same module
· 4.4	Power profile and thermal implications
· 4.5	Boot path — the Pi 5 EEPROM era
· 4.6	Official support status from Clockwork
· 4.7	The community CM5 path on the uConsole
5	Radxa CM5 (RK3588S2)
· 5.1	Why anyone picks an RK3588S2 over a CM5
· 5.2	Topology and signal mapping
· 5.3	Boot path — Rockchip TPL/U-Boot
· 5.4	The software story: Armbian and Debian community images
· 5.5	Compatibility caveats on the uConsole
6	Other Pin-Compatible Modules
· 6.1	BananaPi BPI-CM4 (A311D)
· 6.2	Pine64 SOQuartz (RK3566)
· 6.3	Radxa CM3 (RK3566) and others
· 6.4	Why these aren’t first-class options
7	Decision Matrix
· 7.1	Cost vs capability table
· 7.2	The “what should I buy?” decision tree
· 7.3	Three concrete recommendations
8	Swap Procedure
· 8.1	Mechanical swap — DF40 connector handling
· 8.2	The CM adapter card and why it gets reused
· 8.3	Software side — image flash, EEPROM, kernel
· 8.4	Going CM4 → CM5: the eight-step checklist
· 8.5	Going Pi CM5 → Radxa CM5: the harder swap
9	Benchmarks and Performance Headroom
· 9.1	Single-core and multi-core
· 9.2	Memory bandwidth
· 9.3	Storage I/O
· 9.4	PCIe-attached SDR throughput
· 9.5	Real-world workloads
10	Power and Thermal Tradeoffs
· 10.1	Idle, light, and heavy
· 10.2	Battery life by module
· 10.3	Why the CM5 needs more cooling than the CM4
11	Resources
12	Footnotes
13	Index

1. About this Volume

Volume 2 walked the mainboard end-to-end and stopped at the 100-pin Hirose DF40C-100DS-0.4V mezzanine connectors that mate the carrier to the Compute Module. This volume is the story of what plugs into those connectors. It is the second-most-important hardware decision you make about a uConsole — the first is “do I buy one at all?” and the second, immediately, is “which compute module goes inside?”

The uConsole is mechanically and electrically a Raspberry Pi CM4 carrier. It works with the CM4 because the CM4 was designed first and because the V3.14 mainboard’s signal routing, power tree, and adapter card are all derived from the official CM4 carrier reference. But the DF40 mezzanine pinout is now a small ecosystem: the Raspberry Pi CM5, the Radxa CM5 (a Rockchip RK3588S2 module that re-uses the same connector and pinout), the BananaPi BPI-CM4 (Amlogic A311D), the Pine64 SOQuartz (RK3566), and the Radxa CM3 (RK3566) all fit the same 200-pin footprint and are designed to be drop-in-mostly compatible. Most of them work in the uConsole; some require a different adapter card; one or two are genuinely pin-compatible drop-ins. This volume is the reference for which is which.

The reader of this volume is assumed to have read Volume 2 (so you know what CM_VBAT, CM_5V, RUN, the DSI0 lane assignment, and the PCIe-vs-USB topology mean) and Volume 1 (so you know which compute path the rest of the series will follow for you). Volume 4 (Boot / Firmware / SD / eMMC) is the next stop after this one — the boot story is module-dependent and gets its own volume.

A note on tone: this is a hardware-procurement and hardware-substitution reference. We will not tell you the BCM2711 is “fast” or “fast enough.” We will tell you that the BCM2711’s four Cortex-A72 cores at 1.5 GHz produce ~1500 single-core / ~3500 multi-core Geekbench-6 scores, that an nmap -sV -A against a /24 takes ~6 minutes on it under battery, and that a CM5 cuts both numbers roughly in half. The reader’s job from there is to decide what those numbers mean for the workload at hand.

2. The Compute-Module Standard

The Compute Module form factor is Raspberry Pi’s “the brain on a card” answer to the SBC: take the SoC, RAM, eMMC, and a wireless chip; put them on a single small PCB; route everything that matters out two 100-pin connectors; let the carrier deal with the connectors, the power, and the I/O. The CM4 set the modern standard in 2020. Everything from the CM5 to the third-party RK3588S2 modules has retained the same connectors and most of the same pin assignments, because that compatibility is the value of the standard.

2.1 Why Pi adopted the DF40 mezzanine

The CM1 / CM3 / CM3+ used a SODIMM-style edge connector — the “DDR2-laptop-RAM-shaped” thing that plugs in flat. That worked at the cost of mechanical fragility (the edge fingers wear) and signal integrity at the speeds the CM4 wanted to run (PCIe 2.0 ×1, HDMI 2.0). The DF40C series from Hirose¹ is a Japanese-spec board-to-board mezzanine connector with 0.4 mm pitch (vs the SODIMM’s 0.5 mm), a stack height of 1.5 mm, gold plating, and a controlled-impedance differential pair routing recommendation in the datasheet. It supports the 5 GT/s PCIe 2.0 differential pairs cleanly, it tolerates more insertion cycles than an edge connector, and it fits in less PCB area. The two connectors split the CM signals into “pair 0” (J1) and “pair 1” (J2) — 100 pins each, side by side, and the module is mechanically supported at four corners by metal standoffs.

The downside is mechanical: the connectors snap rather than slot, the alignment tolerances are tight, and a misaligned module can ground a signal pin to a power pin. The uConsole has four screw-down standoffs precisely to discourage tilted-insertion.

2.2 The 200-pin pinout in functional groups

The 200-pin assignment groups roughly as below. The columns are “what fraction of the 200 pins each function gets” — useful for understanding what the mainboard can’t fan out from a single module, and what it has to drop on the floor:

Pin group	Pin count	What’s there
Power and ground	~50	VBAT, 5V, 3V3, multiple GND returns
GPIO (28 pins)	28	The standard 40-pin Pi header GPIO subset, exposed through the connector
HDMI 0 (TMDS pairs + clk)	8	Routed on the uConsole
HDMI 1 (TMDS pairs + clk)	8	Not routed on the uConsole — pads on the carrier are unconnected
DSI0 (4 lanes + clk)	10	Routed to the JD9365DA-H3 LCD driver
DSI1 (4 lanes + clk)	10	Not routed — alternative display lane, unused on the uConsole
CSI0 / CSI1 (camera)	20	Not routed — uConsole has no camera path
PCIe 2.0 ×1	4	Routed to the Mini PCIe slot
USB 2.0	4	Routed to the GL850G hub
Audio (DAC / I²S)	6	Routed to AS4729 / OCP8178 (Vol 2 §7)
Wireless antenna IPEX	1	Routed via the antenna pigtail to the case-side antenna
EEPROM I²C / control	4	Routed (EEPROM_nWP, nEXTRST, RUN, GLOBAL_EN)
Reserved / NC	rest	The remainder — manufacturing test, ID resistors, future-use

The fact that HDMI 1, DSI1, CSI0, and CSI1 are physically present on every Compute Module but not exposed on the uConsole is the recurring refrain of this series. Volume 6 shows what the kernel’s device-tree overlays do with this; Volume 7 shows what an aggressive expansion-card builder can do with the unused signal pins (you can fan an HDMI-1 out via an expansion card if you really want to).

2.3 What the uConsole mainboard actually uses

In Vol 2 §5 we noted the carrier routes the DF40 pins through to the AXP228 power tree, the JD9365DA-H3 display driver, the GL850G USB hub, the AS4729/OCP8178 audio path, the Mini PCIe slot, and the 40-pin GPIO header. Translated to the compute module’s perspective: of the 200 pins on the module, the uConsole connects to roughly ninety, exposes about sixty (40-pin header + Mini PCIe + USB-A + HDMI-A + USB-C + audio jack), and drops on the floor the remaining ~110.

If you swap modules, every signal in the “connects to” set must be present and must mean the same thing on the new module. This is the entire portability story for the family — the CM5, the Radxa CM5, the BPI-CM4, and the SOQuartz all route the same signal classes to the same DF40 pin numbers. Where they diverge is in details that the kernel handles via device-tree overlays, not in the physical wiring.

3. Raspberry Pi CM4

The CM4 is the canonical uConsole module. The mainboard was designed against it; every Clockwork-supplied OS image is a CM4 image; every footnote in Volumes 2 and 4 of this series cites the CM4 datasheet. If you bought a uConsole, this is statistically what’s inside.

3.1 SoC and topology

The Raspberry Pi CM4 is a 55 mm × 40 mm × 4.7 mm carrier-mountable module built around the BCM2711 SoC.² The BCM2711 is a 28 nm ARM SoC produced by Broadcom for the Pi 4 family in 2019; it is the same silicon that ships in the Raspberry Pi 4 Model B. Functional summary:

Block	Specification
CPU	4× ARM Cortex-A72 @ 1.5 GHz (1.8 GHz overclocked)
GPU	VideoCore VI @ 500 MHz (OpenGL ES 3.0, OpenVG 1.1, hardware-decoded H.265 4Kp60)
Memory bus	32-bit LPDDR4-3200 (12.8 GB/s peak)
L2 cache	1 MB (shared, L2)
Display	2× HDMI 2.0 (4Kp60 HDR with HDCP 2.2), 2× DSI
Camera	2× CSI (MIPI 4-lane each)
Storage	eMMC 5.1, SDIO, SD
PCIe	1× PCIe Gen 2 ×1 (5 GT/s, 500 MB/s usable)
USB	1× USB 2.0 host (the only USB port the SoC sees — everything else is downstream of an external hub)
ADC / DAC	None on-die; PWM-only audio via GPIO
Crypto	AES-128 / AES-256 at the GPU

The two architectural facts that bite uConsole users specifically:

1. There is one USB 2.0 host on the SoC. The mainboard fans this out via the GL850G external hub (Vol 2 §9). Everything you plug into a USB-A port, the internal HID keyboard, and any USB-attached add-on board all share that one port’s bandwidth. This becomes painful when you try to capture from an RTL-SDR while running Bluetooth audio while writing to a flash drive at the same time.
2. There is no on-die audio codec. PWM-driven analog audio on the BCM2711 is a 16-bit stream produced by toggling two GPIO pins at a high frequency and low-pass-filtering the result through external analog stages (Vol 2 §7). Audio quality on a CM4 is inherent to the SoC and not improvable by mainboard work alone.

3.2 The variant matrix

Raspberry Pi sells the CM4 in 32 SKUs, parametrised over four binary or near-binary axes:

Axis	Options	Effect
RAM	1 / 2 / 4 / 8 GB LPDDR4-3200	Direct RAM-class scaling. 1 GB is starvation for Linux GUI in 2026.
eMMC	None (“Lite”) / 8 / 16 / 32 GB	”Lite” + uSD card vs onboard flash. See §3.3.
Wireless	With WiFi+BT / without	CYW43455 ↔ no antenna routing. See §3.4.
(Implicit) Form	Standard / antenna-with-IPEX	Antenna pigtail routes to a U.FL connector vs PCB trace.

The SKU naming convention is CM4xxx, where xxx encodes the choices. For the uConsole bench, the relevant SKUs are:

SKU	RAM	eMMC	WiFi/BT	Notes
CM4002000	2 GB	None	No	Bare-minimum “Lite” — uSD-only, no WiFi. Cheapest path.
CM4002016	2 GB	16 GB	No	Common “no-WiFi eMMC” configuration
CM4002032	2 GB	32 GB	No	Same with bigger flash
CM4102000	2 GB	None	Yes	Lite + WiFi/BT (the typical kit ships this)
CM4102032	2 GB	32 GB	Yes	The “everything” 2 GB variant
CM4104032	4 GB	32 GB	Yes	The pre-CM5 sweet spot
CM4108032	8 GB	32 GB	Yes	Maximum CM4

The Clockwork uConsole kit ships with the CM4102000 (2 GB Lite + WiFi) as the baseline. You add a microSD card and you’re done. The base kit is roughly $140 (uConsole hardware) + $40 (CM4 Lite + WiFi) + the SD card.³

3.3 Lite vs eMMC: what changes for the uConsole

The “Lite” CM4 has no onboard eMMC — the four flash signals on the DF40 connector route to nothing on the module. The mainboard’s microSD slot is wired to the CM4’s SDIO pins (the same pin group used by an eMMC, multiplexed at boot). So the uConsole always has one boot device:

• On a non-Lite CM4 → boot from on-module eMMC, microSD slot is secondary storage.
• On a Lite CM4 → boot from microSD, eMMC pins on the DF40 are unused.

Practical consequences:

• eMMC is faster than microSD. Random 4K read on a typical eMMC 5.1 is ~50 MB/s; a class A1 microSD is 10–25 MB/s. Boot-up timing, package-update I/O, and database queries all show the difference. Sequential reads are similar (both saturate at ~100 MB/s effective bus throughput).
• eMMC is permanent. You can’t pop it out. If your CM4’s eMMC fills up or its flash translation layer wears out, you have to either flash via the USB MSD recovery path (Vol 4) or buy a new CM4. The microSD lets you swap a card.
• eMMC is required for some workloads. Heavy database work, kernel compilation, RetroArch ROM caches with thousands of files — these benefit from the lower latency of eMMC.
• Lite is more flexible. You can have ten different SD cards each with a different OS / loadout, and slot in the right one for the task.

The Vol 1 decision tree treats this as an “if your loadout matters, it eMMCs” tradeoff. For the field-pen-test loadout (which gets reflashed often) or the multi-OS user, Lite is correct. For the sit-on-the-desk-as-a-coding-tablet loadout, eMMC is correct.

3.4 WiFi-equipped vs WiFi-less

The WiFi+BT variant of the CM4 carries a Cypress CYW43455 chip on-module — dual-band 802.11ac (2.4 GHz / 5 GHz) and Bluetooth 5.0, integrated with the BCM2711’s SDIO bus. The chip has two antenna IPEX (U.FL) connectors on the module: one routed to a PCB-trace antenna for short-range / table-top use, and one to an external pigtail (the kit’s antenna mount).

The non-WiFi variant has no chip and no antenna pads — the SDIO bus from the BCM2711 is unused. Power consumption drops by ~150 mW. The uConsole’s WiFi antenna pigtail routes from the case to the U.FL connector on the module; on a WiFi-less module that pigtail goes to nothing. (The case still has the cosmetic antenna nub — it’s a plastic stub when not connected, no harm done.)

For the uConsole, the WiFi-equipped variant is strongly recommended unless you have a USB WiFi adapter you prefer. The on-module CYW43455 supports:

• Client mode (connect to an AP) — works out of the box.
• AP mode — works with hostapd and a USB WiFi dongle on top, or in nmcli’s “shared” mode for a quick hotspot.
• Monitor mode on 2.4 GHz — works with the Clockwork kernel patches and the right firmware blob. Not officially supported by Cypress; community-supported via patched brcmfmac.
• Monitor mode on 5 GHz — does not work on the CYW43455. For this you need a USB adapter (Alfa AWUS036ACH, Panda PAU09 N, similar). This is documented in detail in Vol 8.

3.5 Power, thermals, and the uConsole envelope

The CM4 is a 28 nm SoC with an idle power of ~0.4 W and a peak power (all four cores at 100 %, GPU active, USB host loaded) of ~6 W. The uConsole’s 18650 cells run at ~3.7 V nominal, so peak current at the cells is ~1.6 A and average current under typical use (one core busy, screen at 50 %, WiFi connected) is ~0.6 A. With a 2× 3000 mAh pack and 80 % AXP228 efficiency, that gives ~4 hours runtime under typical use — the figure usually quoted by community reviews.

The CM4 has no heat-spreader ledge on the die. There’s just bare silicon at the top of the QFN-like package. Clockwork ships a small adhesive heat-pad and a metal frame that conducts heat from the SoC to the underside of the keyboard, which acts as a passive heatsink. This works for the typical ~6 W peak. It does not work for sustained 100 % load — the SoC will throttle from 1.5 GHz to ~600 MHz after about 90 seconds of stress-ng --cpu 4. This is normal and documented in the Pi datasheet.⁴

3.6 Boot path

The CM4 boots from a multi-stage chain:

1. Stage 0 — Boot ROM (in the BCM2711 ROM, immutable). On power-up, reads the EEPROM at EEPROM_nWP/I²C-1 and discovers boot order configuration.
2. Stage 1 — EEPROM (Pi-style, 16 MB SPI flash on the CM4 module). Initialises DRAM, loads the GPU firmware, decides what to boot from (eMMC, SD, USB, network).
3. Stage 2 — bootcode.bin (lives on the boot partition of eMMC or SD). Hands off to:
4. Stage 3 — start.elf / start4.elf, the GPU firmware blob. This is what loads the Linux kernel (via kernel.img / kernel8.img).
5. Stage 4 — Linux kernel boots, mounts root, calls /sbin/init.

Volume 4 covers each stage in detail. For Volume 3, the relevant fact is: the CM4’s EEPROM stores boot-order preferences, and you can use rpi-eeprom-config from any running Pi OS to reconfigure (e.g., “try USB before SD”). This is how multi-boot SD setups become non-flaky and how you can use a uConsole with an external USB-C SSD as the root filesystem.

3.7 Where to buy and what costs what

Authorised distributors as of 2026:

Distributor	Region	Notes
Raspberry Pi (direct)	EU/UK	https://www.raspberrypi.com/products/compute-module-4/
DigiKey	US/Worldwide	Stock varies — check the SKU table
Mouser	Worldwide	Same as DigiKey
RS Components / Allied	Worldwide	EU-based; faster EU shipping
The Pi Hut	UK/EU	UK reseller
PiShop.us / PiShop.ca	NA	NA reseller; CM4 always in stock
Adafruit	US	Smaller selection but reliable
Pimoroni	UK/EU	Premium pricing, fast shipping

Approximate 2026 prices (USD, mid-quantity):

Variant	Price (USD)
CM4 Lite, no WiFi	~$30
CM4 Lite, WiFi	~$40
CM4 2 GB / 32 GB / WiFi	~$70
CM4 4 GB / 32 GB / WiFi	~$80
CM4 8 GB / 32 GB / WiFi	~$100

The kit’s bundled CM4 is at the low-end of this range — Clockwork buys in bulk and includes shipping in the kit price.

4. Raspberry Pi CM5

The CM5 was announced and released by Raspberry Pi Trading in late 2024.⁵ It is the same form factor as the CM4 (55 × 40 mm, two DF40 connectors, 200 pins, same mounting holes) and the same product family — but the SoC is a generational step forward, the memory bus is wider, and several incidental signal-routing details change in ways that matter for the uConsole.

4.1 SoC and topology — what changed from CM4

The BCM2712 SoC⁶ in the CM5 is the same chip that ships in the Raspberry Pi 5 Model B:

Block	CM5 spec	vs CM4
Process node	16 nm	28 nm (CM4)
CPU	4× ARM Cortex-A76 @ 2.4 GHz	4× Cortex-A72 @ 1.5 GHz
Single-core perf	~3000 Geekbench 6	~1500 Geekbench 6
Multi-core perf	~7500 Geekbench 6	~3500 Geekbench 6
GPU	VideoCore VII @ 800 MHz	VideoCore VI @ 500 MHz
Memory bus	32-bit LPDDR4X-4267 (17.0 GB/s peak)	LPDDR4-3200 (12.8 GB/s)
L2 cache	1 MB	1 MB
L3 cache	2 MB shared (new!)	None
Display	2× HDMI 2.0 4Kp60, 2× DSI	Same
Camera	2× MIPI 4-lane	Same
Storage	eMMC 5.1, SDIO 3.0 (faster), SD	eMMC 5.1
PCIe	1× PCIe Gen 2 ×1 + 1× PCIe Gen 3 ×1	1× PCIe Gen 2 ×1
USB	2× USB 3.0 (separate root hubs)	1× USB 2.0 only
Audio	I²S out + analog (PWM-driven, like CM4)	Same — no on-die DAC improvement

The two changes the uConsole user feels viscerally:

1. Two USB 3.0 root hubs. The CM5 has separate USB-3 PHYs for two different hosts. On a CM5-aware mainboard, this means you can put the GL850G hub on one root port and an external USB-3 device (HackRF, NVMe-over-USB) on the other, and the two don’t fight for bandwidth. The V3.14 mainboard does not break out the second USB-3 host — it’s still wired in CM4-mode, fanning everything through the GL850G. To get the second USB-3 host, you need either the HackerGadgets V3.14_V5-compatible adapter board or a community mod (Vol 11).
2. PCIe Gen 3 ×1 second lane. The CM5 has a second PCIe lane that runs at Gen 3 speeds (8 GT/s, ~1 GB/s usable). This second lane is exposed in the CM5 on different DF40 pins than the primary lane. The uConsole mainboard does not route this second lane. The HackerGadgets AIO V2 product page makes this explicit: USB caps at 2.0 in the standalone mode and goes to 3.0 only with the upgrade-kit adapter that re-routes signals to access the second PCIe/USB lane. (See Vol 7 §7.4.3.)

4.2 The variant matrix (CM5)

Axis	Options	Effect
RAM	2 / 4 / 8 / 16 GB LPDDR4X-4267	16 GB is the headline new option; useful for VMs and big datasets
eMMC	None (“Lite”) / 16 / 32 / 64 GB	64 GB is new (CM4 capped at 32)
Wireless	With CYW43455 (same chip as CM4) / without	Same chip — same monitor-mode constraint as CM4
Antenna	PCB-trace / IPEX U.FL	Same options

A quick sanity check: the CM5 retains the CYW43455 for WiFi and BT. This is the same chip as the CM4. So WiFi performance on a CM5 is identical to a CM4. If you bought into the CM5 expecting WiFi 6 or BT 5.4, you get neither — Pi kept the Cypress chip to ease software portability, and that means the radio side of the uConsole is unchanged across CM4 and CM5.

4.3 Pin compatibility: same connectors, not the same module

The CM5 uses the same DF40C-100DS-0.4V connectors at the same physical positions as the CM4. So a CM5 will physically fit a CM4-designed adapter card and a CM4-designed mainboard. But several signal meanings changed:

Pin (DF40)	CM4 signal	CM5 signal	Affects uConsole?
RUN	Reset (active-low)	Same	No
nEXTRST	External reset request	Same	No
EEPROM_nWP	EEPROM write-protect	Same	No
WL_DISABLE	WiFi disable	Same	No
BT_DISABLE	Bluetooth disable	Same	No
GLOBAL_EN	Power-good gating	Same — but CM5 latches it	Yes — see §4.5 below
Several “reserved” pins	NC / pull-up reserve	New PCIe-Gen3 lanes, USB3-2	Yes — uConsole leaves them NC; CM5 perf is reduced
CM4_GND reference pins	GND	GND (sometimes power-out)	Mostly no, but a few “former GND” pins now carry rails
BOOT0 / BOOT1	Boot mode select	Same — but new EEPROM behaviour	No physical change, but boot logic is different

The “GLOBAL_EN” change is the most significant for older mainboards: on the CM5, this pin is latched internally by the SoC’s power sequencer rather than being a pure input. If the mainboard pulls it briefly low to reset (as the AXP228’s PWROK-low-during-charge-fault behaviour does on the CM4), the CM5 latches off and refuses to come back until it’s power-cycled. This is the famous “CM5 in CM4 carrier won’t come back from a deep idle” community bug; the workaround is to set POWER_OFF_ON_HALT=1 (per Vol 2 §14) and accept that the CM5’s idle-power behaviour is slightly different.

4.4 Power profile and thermal implications

The CM5 has higher peak power than the CM4 — about 9 W under all-cores load vs the CM4’s 6 W. Idle power is similar (~0.4 W) because the cores aggressively clock-gate. But the peak is more frequent (the A76 cores are rated higher and will turbo more aggressively). For battery life:

• CM5 light load (web browsing, terminal): roughly the same as CM4 — idle power dominates. ~3.5–4 hours.
• CM5 heavy load (kernel compile, GNU Radio at high sample rates): ~30 % shorter battery life vs CM4 doing the same work. Closer to 2.5–3 hours. The SoC finishes the work faster (because A76 > A72 by ~2×), but the integral of power-over-time is larger.
• CM5 with active cooling: a small fan (community mod, Vol 11 §11.5) can extend the sustained-load time before throttling kicks in.

The thermal pad and frame from the CM4 still works for the CM5 — it’s a slightly higher heat load but the same package. Don’t expect to run a CM5 at full burst for an hour without throttling.

4.5 Boot path — the Pi 5 EEPROM era

The CM5 boots through the same multi-stage chain as the CM4 but with a different EEPROM image — the Pi 5 era boot logic understands new boot sources (NVMe boot, USB-3 mass storage) and has a hardware-based RTC support that the CM4 lacks. For the uConsole, this means:

• The CM5’s EEPROM by default tries: eMMC → SD → USB → network. SD-first is also configurable.
• USB-3 mass storage boot works on the CM5 but the V3.14 mainboard caps USB at 2.0 — so you boot from USB-2 even if you have an NVMe-USB-C bridge. (USB-3 boot needs the upgrade-kit adapter. See Vol 7 §7.4.3.)
• rpi-eeprom-config still works to inspect and update — same tool as on the CM4.
• The CM5’s RTC can be backed by a coin cell on community/AIO boards (e.g., the HackerGadgets AIO V2’s PCF85063A + CR1220) to keep the time over a battery-out condition. The stock uConsole has no RTC.

4.6 Official support status from Clockwork

As of mid-2026, Clockwork’s official position is:

• The V3.14 mainboard “supports” CM5 in the sense that the SoC boots and the kernel runs.
• Clockwork-flavored OS images for CM5 are not officially shipped — you use community Bookworm or Trixie images (see §4.7).
• The DSI driver for the JD9365DA-H3 LCD is the same as for the CM4 (same kernel patches apply); they work on CM5 once the kernel is up.
• The keyboard and audio paths work — both rely on USB and PWM-driven analog respectively, both unchanged.
• The CM4 adapter card works for CM5. This is the practical fact that keeps the swap easy: you do not need a different adapter to swap a CM4 for a CM5 in a stock uConsole.⁷

4.7 The community CM5 path on the uConsole

The de facto path for running a CM5 on the uConsole is Rex’s Bookworm/Trixie images maintained on the Clockwork forum:⁸

Alternative path: CrossPlatformDev’s CI-built images at https://github.com/crossplatformdev/uConsole-Image-Builder/releases — auto-builds Jammy/Bookworm/Trixie for CM3/CM4/CM5 with pluggable desktop environments.

Both approaches give you a working CM5-on-uConsole with the JD9365DA display, the keyboard, and the audio working. The “officially supported” outcome from Clockwork is still the CM4; the CM5 is community-supported but very stable as of 2026.

5. Radxa CM5 (RK3588S2)

The Radxa CM5 is not a Raspberry Pi product. It is a third-party Compute Module from Radxa Computer Co. (Shenzhen, China) that mimics the CM4/CM5 form factor and pinout, but uses a Rockchip RK3588S2 SoC instead of a Broadcom BCM27xx.⁹ It’s the most “different” of the modules covered here, but it’s also the one with the most to offer for some workloads.

5.1 Why anyone picks an RK3588S2 over a CM5

The RK3588S2¹⁰ is a 2023-launched Rockchip SoC with:

Block	RK3588S2 spec	vs Pi CM5
Process	8 nm	16 nm
CPU	4× Cortex-A76 @ 2.4 GHz + 4× Cortex-A55 @ 1.8 GHz (big.LITTLE)	4× Cortex-A76 only
GPU	Mali-G610 MP4 (3D + GPGPU + OpenCL)	VideoCore VII (3D + limited GPGPU)
NPU	6 TOPS dedicated NPU	None
Memory bus	32-bit LPDDR4X-4267 or LPDDR5-5500	LPDDR4X-4267
Storage	eMMC, SD, NVMe	Same
PCIe	1× PCIe 3.0 ×4 OR 2× PCIe 3.0 ×2	1× Gen2 + 1× Gen3 ×1
USB	1× USB 3.0 + multiple USB 2.0	2× USB 3.0
Hardware codec	H.264/H.265/VP9/AV1 8K decode, 4K encode	H.265 4K decode only
ML hardware	Yes (NPU + Mali GPU)	No

What you get: more cores (8 vs 4), an NPU for inference workloads, AV1 decode, and a bigger PCIe bus. What you give up: the entire Pi software ecosystem.

For uConsole users, the RK3588S2’s interesting workloads are:

• On-device LLM inference — run quantised Llama or Phi models locally via the NPU. Vol 8 sidebar.
• AV1 video transcoding — useful for media-server loadouts.
• GNU Radio at high sample rates — Mali GPU can be pressed into FFT acceleration via OpenCL kernels.
• VLM-based pen-test workflows — vision-language models for screenshot OCR-then-attack chains.

What you give up: Raspberry Pi’s huge ecosystem of curated documentation, kernel patches that “just work,” apt-installable hardware-aware packages (raspi-config, rpi-update, etc.), and the firstparty software stack (the start.elf GPU firmware path doesn’t exist on RK3588 — the Mali driver is an entirely separate userland from the VideoCore stack).

5.2 Topology and signal mapping

The Radxa CM5 mostly preserves the DF40 pinout from the CM4 — power, ground, DSI0, HDMI 0, USB 2.0, PCIe (Gen 3, not Gen 2), I²S audio, GPIO, the EEPROM control pins, and the WiFi-disable pins all map cleanly. Where it diverges:

• No CYW43455. Radxa CM5 has its own WiFi chip (Wi-Fi 6 / RTL8852BE) on a different SDIO bus. The uConsole’s antenna pigtail still connects to a U.FL pad on the module, but the on-module chip and its kernel driver are different. Monitor mode and other advanced WiFi behaviour have to be re-validated.
• Different boot ROM behaviour. Rockchip has its own multi-stage boot (TPL → SPL → U-Boot → Linux). Pi-style EEPROM tools don’t apply; you flash via rkdeveloptool over USB.
• No rpi-eeprom-config equivalent. The boot order is set in U-Boot environment variables, edited via U-Boot’s command line over UART or via the fw_setenv tool from Linux.
• The DSI0 lane assignment is the same — the JD9365DA-H3 driver works because the kernel device-tree overlay tells the driver which Rockchip DSI controller to use. This is a non-trivial port: see §5.4.
• PCIe is Gen 3 ×4 — much faster than CM4’s Gen 2 ×1. But the uConsole’s mainboard only routes one lane, so you get Gen 3 ×1 (~1 GB/s usable). That’s still 2× the CM4’s PCIe bandwidth.

5.3 Boot path — Rockchip TPL/U-Boot

A Radxa CM5 boots through a totally different chain than a Pi CM4/CM5:

1. BootROM (in the RK3588S2 mask ROM) — reads BOOT_MODE strap pins.
2. TPL (Tertiary Program Loader) — initialises DRAM from the SPL image.
3. SPL (Secondary Program Loader) — loads U-Boot from eMMC/SD/SPI.
4. U-Boot — selects kernel and initrd; loads device tree.
5. Linux — kernel + rootfs.

The whole chain is OSS — you can rebuild every stage from source via Buildroot or Yocto. Compare to Pi’s closed-source bootcode.bin and start.elf GPU firmware blobs (which are required for Pi boot but cannot be modified outside Pi Trading).

For the uConsole, what this means:

• You flash a Radxa-CM5-aware uConsole image (community-built, see §5.4).
• First boot is slower than Pi (RK3588S2 + LPDDR4X memory training runs on every cold boot, ~3 s vs Pi’s ~1 s).
• Subsequent boots are similar or faster than Pi.
• Updating the bootloader is via rkdeveloptool (Linux/Mac) or the Rockchip vendor flash tools.

5.4 The software story: Armbian and Debian community images

The maintained image paths for Radxa CM5 on uConsole as of mid-2026:

• Armbian (Debian-based) — https://www.armbian.com/radxa-cm5/ — first-class support; routine kernel updates; uConsole DTS patches need to be applied separately.
• Radxa Debian images — https://wiki.radxa.com/Cm5/ — Radxa’s own Debian builds; come with their kernel and userland.
• Community uConsole-Radxa builds — the crossplatformdev/uConsole-Image-Builder releases page includes an experimental RK3588 target as of late 2025.

The DTS patches needed are non-trivial — the kernel needs to know:

• DSI0 routes to a JD9365DA panel (Clockwork patch, ported from Pi).
• I²S audio path uses the Rockchip I²S controller, fed to the AS4729 / OCP8178 amp chain (Vol 2 §7.3 — same path, different upstream).
• The keyboard MCU is on USB1.0/USB2.0 of the GL850G hub on the mainboard side.
• The Mini PCIe slot is on PCIe 3.0 x1 (vs Pi’s PCIe 2.0 x1).
• Power management requires the Rockchip PMIC driver paired with the AXP228 awareness from the carrier side — the AXP228 still sits on the mainboard, not on the module.

5.5 Compatibility caveats on the uConsole

In practice, the Radxa-CM5-on-uConsole works but with these caveats as of mid-2026:

• WiFi monitor mode is unproven. The RTL8852BE chip’s monitor-mode driver support varies across kernel versions. If your loadout relies on WiFi monitor mode, stay with the Pi CM4/CM5 + CYW43455.
• Kali ARM installs are unsupported. Kali targets the Pi; running Kali on a Radxa CM5 means manually backporting tools and dealing with apt package incompatibilities. ParrotOS and BlackArch have similar caveats.
• The official Clockwork OS is not Radxa-aware. You’re on community images for the foreseeable future.
• The CM4 adapter card still works. Same pinout, same connectors — no adapter swap.

For most uConsole users, the Radxa CM5 is interesting but premature; the Pi CM4 or CM5 is the lower-friction path. Volume 5 covers the OS landscape for each module in detail.

6. Other Pin-Compatible Modules

Several other compute modules use the same DF40 pinout and (mostly) the same signal mapping. None are first-class options for the uConsole — you’ll spend time on kernel patches and adapter-card edge cases — but they’re worth knowing about.

6.1 BananaPi BPI-CM4 (A311D)

The BananaPi BPI-CM4 from SinoVoip uses an Amlogic A311D SoC (4× Cortex-A73 + 2× Cortex-A53, Mali-G52 MP4 GPU, 5 TOPS NPU). It’s pin-compatible with the Pi CM4 except for some power-rail differences. Linux support is via Armbian or BananaPi’s vendor builds.

For the uConsole:

• Power: caution. The A311D has a different VBAT requirement (2.7–3.6 V vs Pi CM4’s 3.0–4.2 V). The AXP228’s CM_VBAT rail can support both, but verify the V3.14_V5 schematic before plugging in.
• DSI: works with kernel patches. The A311D’s MIPI-DSI controller is different from VideoCore’s; the JD9365DA-H3 driver needs porting.
• USB: USB 2.0 only. The A311D doesn’t have native USB 3.0 in this configuration.
• PCIe: PCIe 2.0 ×1, similar to CM4.

Realistic verdict: not worth the trouble for the uConsole unless you have a specific A311D affinity (the NPU is the only differentiator, and the Radxa CM5 has a faster NPU at higher cost).

6.2 Pine64 SOQuartz (RK3566)

The Pine64 SOQuartz is a Pine64-built CM4 form factor module using Rockchip RK3566 (4× Cortex-A55 @ 1.8 GHz, Mali-G52 MP1, 1 TOPS NPU). It’s a less powerful module than the CM4 (A55 cores are about half as fast as A72) but uses the same connectors.

For the uConsole:

• Cheaper than CM4 ($35 for 4 GB / 16 GB). Useful for budget-build experiments.
• Cooler thermals (less peak power, won’t throttle as quickly).
• Software: Armbian and Pine64-supported Debian work; same DTS-porting story as Radxa.
• Performance: about half a CM4. Not appropriate for SDR-heavy or pentest workloads.

Verdict: useful for a “PicoCalc-class but cheaper” loadout where you’d want minimum power for maximum battery life. Not for performance-critical work.

6.3 Radxa CM3 (RK3566) and others

The Radxa CM3 is similar to the SOQuartz — RK3566, 4× A55, similar tier — but produced by Radxa with their toolchain. The CM3 is the “small Rockchip” path; the CM5 is the “big Rockchip” path.

There are also a few exotic options: the Pine64 SOPine (older A53), the Khadas VIM3 Pro (Amlogic S922X, similar to A311D), and the Hardkernel ODROID-CM4 (Amlogic A311D again). None have first-class uConsole support; all require kernel patching.

6.4 Why these aren’t first-class options

The uConsole’s value proposition is that the hardware just works — Clockwork’s kernel patches handle the LCD, the keyboard, the audio, the PMIC, and the WiFi. Every off-Pi module breaks one or more of these “just works” assumptions. The community has made enormous progress on the Rockchip path (Radxa CM5 in particular), but the further you stray from the Pi family, the more time you spend in kernel-DTS land instead of in your loadout.

The decision matrix in §7 captures this — for most loadouts, the Pi CM4 or Pi CM5 is the right answer. The Rockchip path is available and workable; that doesn’t make it the right starting point.

7. Decision Matrix

This section is the “I want to buy a compute module — what should I get?” cheat sheet. It distills §3 through §6 into a decision tool.

7.1 Cost vs capability table

Module	Approx price (USD)	Single-core	Multi-core	RAM ceiling	Notes
CM4 Lite, no WiFi	~$30	1500	3500	8 GB	Bare-minimum, useful for “one-shot dev unit”
CM4 2 GB / 32 GB	~$70	1500	3500	2 GB	The kit’s bundled SKU
CM4 4 GB / 32 GB	~$80	1500	3500	4 GB	Sweet spot pre-CM5
CM4 8 GB / 32 GB	~$100	1500	3500	8 GB	RAM-hungry workloads
CM5 4 GB / 32 GB	~$100	3000	7500	4 GB	Sweet spot if buying new
CM5 8 GB / 32 GB	~$120	3000	7500	8 GB	The “future-proof” modal choice
CM5 16 GB / 64 GB	~$160	3000	7500	16 GB	VM / large-dataset workloads
Radxa CM5 8 GB	~$100	3000	8500	8 GB	NPU + 8 cores; software effort
BPI-CM4	~$80	2500	4500	8 GB	Niche; A311D NPU
SOQuartz 4 GB	~$35	1200	2400	4 GB	Cheap and cool-running; slow

(Geekbench-6 scores are approximate; exact figures depend on cooling, governor settings, and OS. The numbers are for ranking, not absolute spec sheets.)

7.2 The “what should I buy?” decision tree

                       ┌─────────────────────────────┐
                       │ Are you starting from scratch│
                       │ (no existing CM yet)?        │
                       └──────┬──────────────────────┘
                              │ yes
                              ▼
                ┌─────────────────────────────┐
                │ Will you run pentest /       │
                │ Kali / monitor-mode WiFi?     │
                └────┬────────────────┬─────────┘
                     │ yes            │ no
                     ▼                ▼
        ┌────────────────────┐  ┌─────────────────┐
        │ Pi CM4 4 GB / 32 GB │  │ Need NPU /      │
        │ — proven monitor    │  │ on-device ML?   │
        │   mode kernel       │  └────┬──────┬─────┘
        │   patches           │       │ yes  │ no
        └────────────────────┘       ▼      ▼
                              ┌──────────┐  ┌──────────┐
                              │ Radxa CM5│  │ Pi CM5   │
                              │ 8 GB     │  │ 8 GB /   │
                              │          │  │ 32 GB    │
                              └──────────┘  └──────────┘

7.3 Three concrete recommendations

If the table and tree above are too abstract, three opinionated picks:

1. “I want the kit Clockwork sells.” Pi CM4 Lite + WiFi (CM4102000), 2 GB. ~$40. Add a high-quality A2 microSD (SanDisk Extreme Pro or Samsung Pro Plus, 64–256 GB). This is the canonical uConsole and what every official Clockwork tutorial assumes.

2. “I want the best balance of speed and software simplicity.” Pi CM5 8 GB / 32 GB. ~$120. Use Rex’s Bookworm image (forum reference in §4.7). Twice the speed of CM4 across the board. No software headaches.

3. “I want NPU and AV1 decode and I’m willing to do kernel work.” Radxa CM5 8 GB. ~$100. Use Armbian; expect to spend a weekend on DTS porting. Reward: 8 cores + 6 TOPS NPU + AV1 + LPDDR5.

8. Swap Procedure

Swapping modules is one of the strengths of the uConsole’s architecture — the same case, the same keyboard, the same screen, but a different brain. The procedure is mechanical-then-software. This section is the canonical reference.

8.1 Mechanical swap — DF40 connector handling

Tools and parts:

• Phillips #00 screwdriver (small).
• Anti-static wrist strap (recommended; not optional for $200 modules).
• Replacement compute module.
• Tweezers (for the antenna pigtail).
• Thermal pad (re-use the existing one; replace if torn).

Steps:

1. Power off and unplug. No charger, no USB, no anything. Remove the back battery cover and pop the cells out.
2. Remove the back panel screws (eight Phillips screws around the perimeter).
3. Disconnect the antenna pigtail at the U.FL connector — use tweezers to lift it straight up off the module’s IPEX socket. Do not pull on the cable.
4. Disconnect the LCD ribbon and keyboard ribbon if they’re in the way. Mark their orientation (a sharpie line on cable + connector helps).
5. Remove the four standoff screws that hold the compute module to the adapter card.
6. Lift the compute module straight up to disengage the DF40 connectors. They snap rather than slide; lift evenly from both ends. The connectors will release with a small “click.”
7. Inspect both DF40 sockets — no bent pins, no foreign matter, no burnt residue.
8. Verify thermal pad placement on the new module; replace if torn or contaminated.
9. Insert the new module at one corner first, then press evenly down — the connectors will engage with a “click” each. If you feel resistance, stop and check alignment. A misaligned insertion can short power to ground.
10. Replace the four standoff screws.
11. Re-attach the antenna pigtail to the new module’s U.FL socket. Press straight down; the ground ring of the pigtail must be flush with the socket.
12. Reconnect ribbons (matching the orientation marks).
13. Reseat battery board’s mainboard connector firmly — community feedback (Talking Sasquach) reports this connector is finicky and is a frequent “won’t power on” cause. Push it in firmly.
14. Insert batteries. Don’t replace the back panel yet.
15. First-boot test with the back open — power on, verify the screen lights, the boot logo appears, the keyboard responds. If something is wrong, easier to debug with the case open.
16. Replace the back panel.

Safety notes:

• Always remove the cells before swapping. The battery board can deliver ~2 A of short-circuit current; that’s enough to damage the module pins or worse.
• Hold the module by its edges; don’t touch the QFN pads or the silicon.
• The thermal pad is conductive and slightly sticky — if it bonds to the heat-spreader on the chassis, gently pry it off rather than tearing.

8.2 The CM adapter card and why it gets reused

The CM4 adapter card¹¹ sits between the compute module’s DF40 connectors and the V3.14 mainboard’s matching DF40 sockets. It exists because the V3.14 mainboard was originally designed for an older module footprint, and the adapter card translates between mainboard pinout and CM4-DF40 pinout. The good news: this same adapter card works for the Pi CM5 and the Radxa CM5 — the DF40 pinouts are compatible enough that the adapter is module-class-agnostic.

The exception is the HackerGadgets V3.14_V5 adapter board (sold separately) which routes signals to expose USB 3.0 on a CM5 + the second PCIe lane + RJ45 ethernet on the AIO V2. That adapter is not required for a CM4 → CM5 swap — only for the “I want to use the AIO V2’s full feature set with USB 3.0 and gigabit ethernet” upgrade.

8.3 Software side — image flash, EEPROM, kernel

After mechanical swap, you have to provision the new module’s software:

• CM4 → CM4 (different RAM/eMMC): same image, no changes. Software is identical.
• CM4 → CM5: you cannot use a CM4 SD-card image. Boot a CM5 image (Rex’s Bookworm/Trixie or the CrossPlatformDev CI build for CM5). The CM5 needs the Pi-5-era kernel and EEPROM.
• CM4 → Radxa CM5: you cannot use any Pi image. You need an Armbian or Radxa Debian image with uConsole DTS patches (community).
• eMMC vs SD: if the new module is eMMC, you flash via the USB MSD recovery path (Vol 4) — this requires connecting the uConsole’s USB-C in “device” mode to a host computer running rpiboot (Pi) or rkdeveloptool (Rockchip).

8.4 Going CM4 → CM5: the eight-step checklist

The most-common upgrade path. Steps:

1. Buy CM5 (with eMMC or Lite as preferred). $100+ depending on RAM.
2. Download Rex’s Bookworm or Trixie image. Flash to a microSD (Lite path) or prepare for USB-MSD flash to eMMC.
3. Mechanical swap (§8.1).
4. Power on and verify boot. The CM5 takes ~5 s longer for first-boot due to memory training; subsequent boots are fast.
5. Run rpi-eeprom-update to confirm the EEPROM is current.
6. Run apt update && apt full-upgrade for kernel and userland updates.
7. Verify the keyboard, audio, WiFi all work. (LCD should already work — same kernel patches.)
8. Note: if your old SD card has CM4-specific firmware (/boot/config.txt overrides, dtparam entries that reference deprecated CM4 syntax), update these to CM5-aware values. Rex’s images come pre-configured.

8.5 Going Pi CM5 → Radxa CM5: the harder swap

Steps 1–3 same as above. Step 4 onwards:

4. Boot Armbian Radxa-CM5 image (uConsole-patched).
5. Verify LCD works. If not: kernel DTS patch is missing. Check /boot/dtb/rockchip/rk3588s2-*.dtb for the JD9365DA reference.
6. Verify keyboard works. The keyboard MCU is on USB; if the GL850G hub is detected, the keyboard should show up as /dev/input/event*.
7. Verify audio. The Rockchip I²S controller has different ALSA card numbers than the BCM2712; you may need to update the ALSA config.
8. Verify PCIe. The Mini PCIe slot should show the device on lspci. If not, the Rockchip PCIe driver may need device-tree updates.
9. Verify WiFi. The RTL8852BE driver is rtw89_8852be in current kernels — confirm it’s loaded.
10. Verify monitor mode (if needed). This is the most likely failure point on the Rockchip path; some kernels don’t fully support monitor mode for rtw89_8852be. Validate with a airmon-ng start wlan0.

9. Benchmarks and Performance Headroom

This section documents what you can expect to measure on each module class. All numbers are approximate and assume:

• The module’s stock kernel governor is ondemand (Pi default) or schedutil (modern default).
• The cooling is the stock thermal pad and frame.
• The battery is at >50 % to avoid voltage-droop throttling.
• The display is at 50 % brightness (so the SoC isn’t fighting the LCD’s PWM noise into the ADC chain).

9.1 Single-core and multi-core

Geekbench 6 (a workload-aggregate benchmark widely run on Linux ARM):

Module	Single-core	Multi-core	Notes
Pi CM4 (BCM2711)	~1500	~3500	Throttles after ~90 s sustained
Pi CM5 (BCM2712)	~3000	~7500	Throttles after ~60 s sustained without fan
Radxa CM5 (RK3588S2)	~3000	~8500	Throttles after ~120 s sustained (cooler 8 nm)
BPI-CM4 (A311D)	~2500	~4500	A73 + A53 split — variable single-core
SOQuartz (RK3566)	~1200	~2400	Cool-running; rarely throttles

9.2 Memory bandwidth

Stream benchmark (sequential MB/s):

Module	Stream Copy	Stream Triad	Notes
Pi CM4 (LPDDR4-3200)	~5500	~5400	Single 32-bit channel
Pi CM5 (LPDDR4X-4267)	~7800	~7600	Same channel, faster IO
Radxa CM5 (LPDDR4X-4267)	~7500	~7400	Similar; slightly higher latency
Radxa CM5 (LPDDR5-5500)	~9500	~9300	LPDDR5 variant

Memory bandwidth dominates SDR sample-rate handling, GNU Radio flowgraph throughput, and parallel matrix workloads.

9.3 Storage I/O

Sequential read (dd if=/dev/sdX of=/dev/null bs=1M count=4096):

Storage	Sequential read	Random 4K read	Notes
eMMC 5.1 (typical)	~100 MB/s	~50 MB/s	What’s on a CM4 8 GB eMMC
microSD A1 class	~25 MB/s	~10 MB/s	Cheap ($5) cards
microSD A2 class	~80 MB/s	~25 MB/s	Premium ($15) cards
USB-C SSD via USB-2	~35 MB/s	~30 MB/s	Capped by mainboard’s USB 2.0
USB-C SSD via USB-3 (CM5 + adapter)	~400 MB/s	~80 MB/s	With the V3.14_V5 adapter only
NVMe via Mini PCIe (uPCI)	~500 MB/s	~100 MB/s	Adapter required; works on CM4/CM5

9.4 PCIe-attached SDR throughput

For the Mini PCIe slot (which is PCIe Gen 2 ×1 on CM4 / Gen 3 ×1 on CM5):

Workload	CM4 sustained	CM5 sustained	Notes
RTL-SDR @ 2.4 Msps	Yes	Yes	Trivial — both modules handle this
HackRF @ 8 Msps	Yes	Yes	Easily handled
HackRF @ 20 Msps	Marginal	Yes	CM4 drops samples occasionally
GNU Radio FFT @ 20 Msps	Marginal	Yes (with some FFT acceleration via VC7)	CM5 has the headroom

9.5 Real-world workloads

Workload	CM4	CM5	Radxa CM5	Notes
nmap -sV -A against /24	~6 min	~3 min	~3 min	Memory-bound, scales with single-core
aircrack-ng 1M handshake test	~12 min	~6 min	~6 min	CPU-bound; A76 ~2× A72
Kernel compile (4 parallel make)	~32 min	~15 min	~12 min	I/O-bound on eMMC; benefits from more RAM
GNU Radio FM demod @ 8 Msps	OK	OK	OK	Plenty of headroom
GNU Radio TDD analysis @ 20 Msps	Marginal	OK	OK	CM4 drops samples; CM5 has headroom
RetroArch N64 emulation	30–40 fps	60 fps	60+ fps	GPU-bound; CM5 wins
LLM inference (Phi-2 quantised)	~1 tok/s	~3 tok/s	~6 tok/s	Radxa NPU dominates

10. Power and Thermal Tradeoffs

The compute module choice doesn’t just set performance — it sets the entire power and thermal budget for the device, which then bounds your loadout choices.

10.1 Idle, light, and heavy

State	CM4 power	CM5 power	Radxa CM5 power
Display off, idle	~0.6 W	~0.7 W	~0.8 W
Display on, idle	~1.4 W	~1.5 W	~1.6 W
Light load (web)	~3 W	~3 W	~3 W
Heavy load (compile)	~6 W	~9 W	~10 W
Burst peak	~7 W	~11 W	~13 W

Add the LCD’s ~1 W (50 % brightness) and the WiFi’s ~0.5 W when active — you get the total uConsole power.

10.2 Battery life by module

With 2× 18650 (3000 mAh, 7.4 Wh) cells and an AXP228 efficiency of ~80 %:

Module	Heavy load	Typical	Light / standby
Pi CM4	1.0 hr	3.5 hr	6 hr
Pi CM5	0.7 hr	3.0 hr	5.5 hr
Radxa CM5	0.6 hr	2.8 hr	5.0 hr
SOQuartz	1.5 hr	4.5 hr	7 hr

For extended field use, the CM4 is still the best — and a SOQuartz is even better if you don’t need the performance.

10.3 Why the CM5 needs more cooling than the CM4

Both modules use the same package and approximately the same die size. But:

• The CM5’s A76 cores draw more current per clock-cycle than the CM4’s A72 cores.
• The CM5’s L3 cache (2 MB shared) adds a small but constant overhead.
• The CM5’s higher clock (2.4 GHz vs 1.5 GHz) means more thermal energy per second.

In practice: the stock thermal-pad-and-frame system handles ~6 W steady-state on a CM4 indefinitely. On a CM5, it handles ~6 W steady-state for ~60 seconds before throttling. Volume 11 covers the various community cooling mods (copper shim, active fan, vapor chamber) that close this gap.

11. Resources

Source	URL
Raspberry Pi CM4 datasheet	https://datasheets.raspberrypi.com/cm4/cm4-datasheet.pdf
Raspberry Pi CM5 datasheet	https://datasheets.raspberrypi.com/cm5/cm5-datasheet.pdf
BCM2711 peripherals	https://datasheets.raspberrypi.com/bcm2711/bcm2711-peripherals.pdf
BCM2712 peripherals	https://datasheets.raspberrypi.com/bcm2712/bcm2712-peripherals.pdf
Hirose DF40 connector datasheet	https://www.hirose.com/
Radxa CM5 product page	https://radxa.com/products/cm5/
Radxa wiki — uConsole notes	https://wiki.radxa.com/Cm5/
Pine64 SOQuartz	https://wiki.pine64.org/wiki/SOQuartz
BananaPi BPI-CM4	https://www.banana-pi.org/en/bpi-computer/64-bpi-cm4.html
Rex’s CM5 Bookworm image (forum)	https://forum.clockworkpi.com/t/bookworm-6-6-y-for-the-uconsole-and-devterm/13235
Rex’s CM5 Trixie image (forum)	https://forum.clockworkpi.com/t/trixie-6-12-y-for-the-uconsole-and-devterm/19457
CrossPlatformDev image builder	https://github.com/crossplatformdev/uConsole-Image-Builder/releases
Armbian Radxa CM5 page	https://www.armbian.com/radxa-cm5/
rpi-eeprom-config documentation	https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#raspberry-pi-boot-eeprom
Clockwork uConsole product page	https://www.clockworkpi.com/uconsole
ClockworkPi forum (uConsole subforum)	https://forum.clockworkpi.com/c/uconsole/
rkdeveloptool (Rockchip flash tool)	https://github.com/rockchip-linux/rkdeveloptool
Pi CM4 SKU table	https://www.raspberrypi.com/products/compute-module-4/specifications/

12. Footnotes

(Footnotes are listed inline above; this section is a placeholder anchor for the index. Pandoc collects footnotes at the end of the document automatically.)

13. Index

A — A311D — §6.1. A55 / A72 / A76 — §3.1, §4.1, §6.2. Adapter (CM) — §8.2. Antenna IPEX — §3.4. Armbian — §5.4. Audio (PWM-only) — §3.1, §4.1.

B — Battery life by module — §10.2. BCM2711 — §3.1. BCM2712 — §4.1. BPI-CM4 — §6.1. Boot ROM — §3.6, §4.5, §5.3. Bootloader (Rockchip) — §5.3.

C — CM4 — §3 (full chapter). CM5 — §4 (full chapter). Connector (DF40) — §2.1. Cooling — §10.3. Cortex-A72 — §3.1. Cortex-A76 — §4.1. CrossPlatformDev — §4.7. CYW43455 — §3.4, §4.2.

D — Datasheet (CM4 / CM5) — §11. DF40 — §2. Decision matrix — §7. Decision tree — §7.2. DSI0 / DSI1 — §2.2. Dual USB-3 (CM5) — §4.1.

E — eMMC — §3.3, §4.5. EEPROM — §3.6, §4.5. Envelope (thermal) — §10.

F — Flash (Rockchip) — §5.3. Form factor — §1, §4.

G — Geekbench — §9.1. GL850G — §2.3. GLOBAL_EN — §4.3. GPU (VideoCore VI) — §3.1. GPU (VideoCore VII) — §4.1.

H — HackerGadgets V3.14_V5 adapter — §8.2. Hirose — §2.1. HDMI — §2.2.

I — I²S audio — §5.4. Idle power — §10.1.

J — JD9365DA-H3 — §5.4.

K — Kernel patches — §4.7, §5.4. Kit SKU — §3.2.

L — L3 cache (CM5) — §4.1, §10.3. Lite vs eMMC — §3.3. LPDDR4 / LPDDR4X / LPDDR5 — §3.1, §4.1, §5.1.

M — Mali-G610 (Radxa) — §5.1. Memory bandwidth — §9.2. Mini PCIe — §2.2, §9.4. Module swap — §8 (full chapter). Monitor mode — §3.4, §5.5.

N — NPU — §5.1. nEXTRST — §4.3. NVMe — §9.3.

O — OCP8178 — §5.4.

P — PCIe (Gen 2 ×1, Gen 3 ×1, Gen 3 ×4) — §3.1, §4.1, §5.1. Performance benchmarks — §9 (full chapter). Pinout — §2.2. Power profile — §10.1. Pre-built option (Carbon Computers) — Vol 1 §1 cross-ref. PWM (audio) — §3.1.

Q — QFN — §8.1.

R — Radxa CM3 — §6.3. Radxa CM5 — §5 (full chapter). RAM ceiling — §3.2, §4.2. Resources — §11. RetroArch — §9.5. Rex’s images — §4.7. RK3566 — §6.2. RK3588S2 — §5. Rockchip TPL — §5.3. RTL8852BE — §5.2. RUN — §4.3.

S — SDIO — §3.3, §3.4. SOQuartz — §6.2. Stream benchmark — §9.2. Swap procedure — §8 (full chapter).

T — Thermal envelope — §3.5, §10. Throttling — §3.5, §10.3. TPL (Tertiary Program Loader) — §5.3.

U — U-Boot — §5.3. USB-2 / USB-3 — §3.1, §4.1, §9.4.

V — Variants (CM4 SKU) — §3.2. Variants (CM5 SKU) — §4.2. VideoCore VI / VII — §3.1, §4.1.

W — WiFi (CYW43455) — §3.4, §4.2. WiFi (RTL8852BE) — §5.2.

X, Y, Z — None.

Footnotes

1. Hirose DF40C-100DS-0.4V datasheet (https://www.hirose.com/). The two 100-pin connectors used by the CM4 and CM5 are part of the “DF40C-100DS-0.4V(51)” SKU on the carrier side and the matching DF40C-100DP-0.4V plug side on the module. ↩

2. BCM2711 is documented on the Raspberry Pi developer pages: peripheral specification at https://datasheets.raspberrypi.com/bcm2711/bcm2711-peripherals.pdf, ARM architecture at the official Cortex-A72 datasheet from Arm Holdings. ↩

3. The kit-vs-bare pricing is documented on the Clockwork product pages — https://www.clockworkpi.com/uconsole. The CM4 is sold separately by Raspberry Pi authorised distributors (DigiKey, Mouser, RS, PiShop) with availability varying by region. CM4 supply was constrained 2021–2023 but stabilised in 2024+. ↩

4. Pi 4 throttle behaviour: https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#frequency-management-and-thermal-control. The uConsole-specific thermal envelope is discussed in detail in Vol 11. ↩

5. CM5 datasheet: https://datasheets.raspberrypi.com/cm5/cm5-datasheet.pdf. The CM5 became generally available November 2024. ↩

6. BCM2712 peripheral specification: https://datasheets.raspberrypi.com/bcm2712/bcm2712-peripherals.pdf. Released alongside the Pi 5 in October 2023. ↩

7. Confirmed in community_research_notes.md from the Talking Sasquach video and matches the CM4-adapter schematic in 02-inputs/schematics/clockwork_Adapter_CM4_Schematic.pdf. Where you do need a different adapter is for the HackerGadgets V3.14_V5 ecosystem when you want USB-3 + RJ45 + PCIe Gen 3 access — that’s an upgrade beyond the swap, not a swap requirement. ↩

8. https://forum.clockworkpi.com/t/bookworm-6-6-y-for-the-uconsole-and-devterm/13235 and https://forum.clockworkpi.com/t/trixie-6-12-y-for-the-uconsole-and-devterm/19457. Maintained by community member “Rex” (forum handle); CM5-specific kernel patches and DSI driver fixes already integrated. ↩

9. Radxa CM5 product page: https://radxa.com/products/cm5/. Datasheet: https://radxa.com/products/cm5/cm5-datasheet. Note that Radxa sells a separate “Radxa CM3” using RK3566 — that’s a lower-end module; details in §6.3. ↩

10. RK3588S2 datasheet from Rockchip: http://www.rock-chips.com/. The RK3588S2 is a “S” variant of the RK3588 — slightly reduced peripheral count, same compute core complement. ↩

11. Clockwork_uConsole/02-inputs/schematics/clockwork_Adapter_CM4_Schematic.pdf. The adapter has the ETA1096 boost converter (Vol 2 §13.1) on it for the eMMC’s 1.8 V rail and a few decoupling caps; otherwise it’s pure pin-passthrough. ↩