Should You Use the Raspberry Pi CM4 in a Product?

Detailed Explanation

The Raspberry Pi CM4 (Compute Module 4) is a system-on-module (SoM) carrying Raspberry Pi's BCM2711 processor, LPDDR4X RAM, and eMMC flash in a compact form factor designed to be soldered or plugged onto a custom carrier board. It is not a development board — it is a production component, and that distinction matters.

Knowing when the CM4 is the right platform for a product, and what it actually requires to build a product around it, shapes decisions across the full hardware and software stack.

Why Standard Raspberry Pi Boards Are Not Suitable for Products

Raspberry Pi 4B, Pi 5, and Zero boards are designed for development, education, and prototyping. Using them directly in a commercial product introduces three structural problems.

SD card failure. SD cards use NAND flash with limited write endurance — typically 10,000 to 30,000 programme/erase cycles for MLC consumer NAND (lower for TLC/QLC). Linux writes constantly: journaling, temporary files, systemd state, log rotation. In write-intensive production deployments, SD cards fail within months. The CM4's eMMC has a managed NAND controller with wear levelling and bad block management, and is substantially more reliable — though still finite, and still benefiting from write-reduction strategies.

Form factor mismatch. A Pi 4B carries USB-A ports, HDMI connectors, an Ethernet jack, a microSD slot, and a USB-C power input — all of which waste PCB area and complicate enclosure design in products that don't need them. The CM4 exposes the same underlying SoC interfaces as signals on its board-to-board connectors, so a carrier board can bring out only what the product requires.

Supply chain. Consumer Raspberry Pi development boards are not committed long-lifecycle production components. The Compute Module line (CM4, CM5) is marketed as a production component with a longer supply commitment, making it more appropriate for products that must be manufactured over several years.

CM4 Hardware Overview

The CM4 is available in combinations across four independently selectable axes (per the CM4 Datasheet):

The BCM2711 SoC at the core of the CM4 is a quad-core ARM Cortex-A72 running at typically 1.5 GHz. The CM4 exposes the following interfaces on its two board-to-board connectors:

• 2× USB 2.0 host + 1× USB 2.0 OTG (used for eMMC flashing)
• PCIe Gen 2.0 × 1 lane
• SDIO 3.0
• 2× HDMI 2.0 (TMDS differential signals)
• 2× MIPI CSI-2 camera interfaces (up to 4 D-PHY lanes each)
• 2× MIPI DSI display interfaces (up to 4 D-PHY lanes each)
• 4× UART, 6× I2C, 5× SPI, 1× I2S
• Up to 28× GPIO (3.3 V logic)
• 5 V power input and ground

The CM4 uses two Hirose DF40C-100DS-0.4V(51) board-to-board connectors — 100 pins each at 0.4 mm pitch, 200 pins total. These are the mechanical and electrical interface between the CM4 and any carrier board.

Carrier Board Design Requirements

Designing a CM4 carrier board is a genuine PCB engineering task. The DF40 connectors have 0.4 mm pitch, and several CM4 interfaces require controlled-impedance differential routing.

Power supply. The CM4 requires a 5 V ±5% supply input (per the CM4 Datasheet). The CM4 internally generates 3.3 V, 1.8 V, 1.1 V, and other rail voltages from the 5 V input using its own power management. Plan for typically 500 mA to 1,500 mA at 5 V depending on CPU load and connected peripherals — size the carrier board's regulator to the peak current budget, not the idle figure. Use a well-decoupled 5 V rail with adequate bulk and high-frequency bypass capacitance at the CM4 power connector. See PCB power and ground plane design for ground plane strategy.

GPIO interfacing. The CM4 exposes up to 28 GPIO pins at 3.3 V logic. Note that unlike the standard Pi 4B board, the CM4 module itself does not include pull-up resistors on the I2C-1 bus (GPIO 2/3) — a custom carrier board must add them (typically 2.2 kΩ to 4.7 kΩ to 3.3 V). For a complete guide to Pi GPIO interfacing including device tree overlays, I2C/SPI setup, level shifting, and the lgpio API, see How to Interface Sensors and Peripherals with Raspberry Pi GPIO.

DF40 connector footprint. The Hirose DF40C-100DS-0.4V requires a tightly toleranced footprint. Use the manufacturer's recommended land pattern, and cross-reference against Raspberry Pi's published CM4 KiCad carrier board reference files. At 0.4 mm pitch, the carrier board design requires at least four PCB layers to route all signals without crossing.

Controlled impedance for high-speed signals. The CM4 interfaces that require controlled-impedance differential pair routing include:

Route these on inner signal layers with a continuous reference plane underneath. Match differential pair lengths within each pair, keep inter-pair skew within the interface specification, and avoid vias on high-speed differential pairs where practical. See controlled impedance PCB design for stack-up and trace geometry calculations.

eMMC boot mode strapping (nBOOT_ENABLE). The CM4 includes an nBOOT_ENABLE pin (active low) that forces USB slave boot mode when pulled low at power-on. In this mode, the CM4 presents its eMMC as a USB mass storage device to a host PC running rpiboot, allowing the OS image to be written. Every CM4 carrier board must provide a reliable way to pull nBOOT_ENABLE low — typically a solder jumper, a latching pushbutton with a pull-down, or a dedicated 2-pin programming header. Without this, the eMMC cannot be re-flashed in the field or during production programming. The RUN signal (CM4 run enable) should also have a pull-up resistor on the carrier board to ensure the CM4 is enabled at power-on.

USB OTG port for eMMC programming. Provide a USB port on the carrier board connected to the CM4's USB OTG interface (USB0 on the connector). A USB Type-C or Micro-B receptacle with ESD protection is sufficient. This port is active only in nBOOT_ENABLE mode and is used exclusively for eMMC programming.

Antenna keepout (wireless variant). If using the standard CM4 with its on-board PCB trace antenna, maintain the antenna keepout zone specified in the CM4 Datasheet — no copper, vias, or components on any layer beneath the antenna region. For the CM4 with U.FL external antenna connector, route the RF trace at 50 Ω characteristic impedance to the connector.

If you are designing a CM4 carrier board for a commercial product, Zeus Design's engineering team provides carrier board design and embedded Linux development for Raspberry Pi Compute Module-based products.

eMMC Storage Strategy

Even with eMMC, Linux's default filesystem behaviour generates substantial write activity. In production deployments — particularly where the product runs continuously for years — implementing write-reduction strategies significantly extends eMMC lifetime.

Read-only root filesystem with overlayFS. Mount the root filesystem read-only at boot. Use overlayfs (built into the Linux kernel) to allow runtime writes to a RAM-backed overlay layer. Only data that must survive a reboot is written to a dedicated persistent data partition. This protects the root filesystem from write wear and from corruption caused by ungraceful power loss — the most common cause of filesystem corruption in deployed embedded Linux products.

tmpfs for logs and temporary data. Mount /tmp and /var/log as tmpfs (RAM-backed). Log to RAM; rotate or flush to persistent storage at defined intervals. Avoid writing every log line directly to eMMC in production.

Separate partition layout. Structure the eMMC into at least three partitions: boot, read-only root filesystem, and data. This enables atomic OS updates via A/B partition switching (see how OTA firmware updates work) without risk of corrupting the data partition.

Avoid swap on eMMC. Enabling swap on eMMC in a production product accelerates write wear dramatically. If your application's memory footprint requires swap, reconsider whether the CM4's RAM tier is correctly sized — or whether the CM4 is the right platform at all.

CM4 Lite and SD card. The CM4 Lite requires an SD card socket on the carrier board. SD cards are acceptable for low-write-frequency applications (devices that read primarily and write infrequently) with appropriate filesystem hardening. For write-intensive deployments, use the CM4 with eMMC.

Flashing the eMMC on a Custom Carrier Board

The CM4 eMMC is flashed using rpiboot — a Raspberry Pi utility available for Windows, macOS, and Linux (source available on GitHub).

Procedure:

1. Pull nBOOT_ENABLE low on the carrier board (via jumper or button).
2. Power on the carrier board.
3. Connect the CM4's USB OTG port to a host PC via USB.
4. Run rpiboot on the host PC. The CM4 enumerates as a USB mass storage device.
5. Write the OS image using Raspberry Pi Imager or dd.
6. Remove the USB cable, release nBOOT_ENABLE, and power-cycle the carrier board.

For initial carrier board bring-up before the full production board exists, the official CM4IO board provides the nBOOT_ENABLE jumper and USB port for eMMC programming without requiring the custom carrier to be ready.

OS and Software for Production

The CM4 runs the same software stack as the Pi 4B. For production products, the main OS options are:

Raspberry Pi OS (Bookworm, Debian 12-based). Actively maintained by Raspberry Pi Ltd with strong CM4 hardware support — camera, display, PCIe M.2, and all peripheral interfaces. This is the lowest-friction starting point and is appropriate for most CM4 products. Peripheral configuration uses device tree overlays in config.txt.

Buildroot. A build framework that generates a minimal Linux system (kernel, root filesystem, bootloader) from source, configured entirely for your hardware. Images are much smaller than Pi OS, boot faster, and include only what the application requires. Appropriate where image size, boot time, or tight control over the software stack matters — but requires significant build system expertise to set up and maintain.

Yocto Project. A more complex meta-build system producing customised Linux distributions. Better suited to organisations with dedicated embedded Linux engineers and products requiring long-term BSP maintenance. Generally overkill for small-team products.

For the majority of commercial CM4 products, Raspberry Pi OS with overlayFS hardening and automated OTA update is the practical production configuration.

Certification and RCM Compliance

The CM4 carries type acceptance for its integrated Wi-Fi and Bluetooth radio, including ACMA registration in Australia, FCC Part 15 (USA), and CE (EU) for the wireless module. This is a useful starting point — but it is commonly misunderstood.

What the CM4 radio certification covers. The CM4's ACMA registration covers its intentional radio transmitter emissions (2.4 GHz Wi-Fi and Bluetooth 5.0) under the module's own test conditions on its reference host board. This covers the radio transmitter in isolation.

What the CM4 radio certification does not cover. A complete product — CM4 plus your custom carrier board, plus enclosure — is a new product that requires:

1. CISPR 32 EMC testing of the complete assembly. Your carrier board adds switching regulators, oscillators, high-speed buses, and cables that generate non-intentional electromagnetic emissions. These must be tested against CISPR 32 limits on the complete product. The CM4's radio certification is irrelevant to this test.
2. RCM mark and ACMA registration for the complete product. You are the responsible supplier of the complete product. The CM4's existing ACMA registration belongs to Raspberry Pi Ltd, not to your product. Register your complete product separately in the ACMA compliance labelling database.
3. Antenna compliance (wireless variant). If using the CM4's integrated wireless capability, maintain the antenna keepout zone and integration requirements from the CM4 Datasheet. Using an external antenna on the U.FL connector may affect the conditions under which the module was certified; confirm with the test lab before proceeding.

This is exactly the same compliance boundary that applies to ESP32 modules, nRF52840 modules, and cellular modems: the module's radio certification is module-scoped, not product-scoped. For a full explanation of this boundary and the practical compliance steps, see what a pre-certified radio module's certification covers. For the end-to-end RCM certification process — standards selection, NATA lab testing, Declaration of Conformity, and ACMA registration — see how to get RCM certification in Australia.

CM4 vs CM5

The CM5 (Compute Module 5, announced late 2024) uses the BCM2712 SoC (quad-core Cortex-A76, the same processor as the Pi 5) and adds USB 3.0 and PCIe Gen 3.0. It uses the same DF40 connector footprint as the CM4 — many CM4 carrier boards are largely pin-compatible with the CM5, though there are pin differences; verify against the CM5 datasheet before assuming drop-in compatibility.

As of 2026, the CM4 remains the more established production platform: wider base of production-proven carrier board designs, more community documentation, and a longer production history. For new product designs, evaluate both; the CM5's faster Cortex-A76 cores, PCIe Gen 3, and native USB 3.0 are relevant if the application uses NVMe storage or external high-speed USB peripherals.

When Not to Use the CM4

The CM4 is not the right platform for every product. Consider a microcontroller or dedicated application SoC when:

Ultra-low power is required. The CM4 draws typically 500 mA to 1.5 A at 5 V even at moderate load — it is not a platform for battery-powered IoT nodes. A microcontroller in deep sleep draws typically 1–10 µA; the CM4 has no comparable low-power state. See Raspberry Pi vs Microcontroller for a full power comparison.

Hard real-time timing is needed. Linux on the CM4 has scheduler jitter that makes deterministic sub-millisecond response from userspace impossible without PREEMPT-RT patching. For control applications requiring hard real-time guarantees, add a co-processor MCU (STM32, RP2040) alongside the CM4, or use a microcontroller platform. For a detailed guide to the PREEMPT-RT kernel, co-processor selection, and the Pi ↔ MCU communication protocol, see Real-Time Control on Raspberry Pi: PREEMPT-RT and the Co-Processor Pattern.

The BOM cost cannot support it. The CM4 starts at approximately AUD $40 at the low end of the RAM/eMMC matrix (check current pricing with your distributor — pricing varies with configuration and supply conditions). For high-volume, cost-sensitive products, a microcontroller or purpose-specific application processor delivers a substantially lower BOM cost.

The application is straightforward control or sensor interfacing. Reading sensors over I2C, driving actuators via GPIO or PWM, managing a radio link — a microcontroller handles these more simply, at lower power, and at lower cost than a CM4 running Linux. The CM4 adds full OS complexity, eMMC management, and a longer boot time for applications that don't benefit from those capabilities.

Design Considerations

• Start with the CM4IO board for development. Validate software, device tree configuration, and peripheral behaviour on the CM4IO before committing to a custom carrier board design. This avoids costly board respins caused by software assumptions or configuration errors discovered late.
• Design for eMMC flashing from day one. Every CM4 carrier board needs nBOOT_ENABLE access and a USB OTG port. Omitting either will make production programming and field updates significantly more difficult.
• Plan the power supply for peak load, not idle. The CM4's 5 V input must deliver peak current without voltage sag. Size the main regulator and bulk capacitance to the maximum expected load — not the idle measurement used during bench characterisation.
• Controlled impedance routing is non-negotiable. If the product uses PCIe (M.2 storage, USB 3.0 controller), HDMI, or MIPI CSI camera inputs, specify controlled impedance to your PCB manufacturer and design for it from the first revision. Retrofitting impedance control to an existing layout is expensive.
• Factor RCM compliance into the schedule. CISPR 32 testing at a NATA-accredited lab involves scheduling, potentially one or more design iterations, the formal test, and a test report. Allow at minimum 4–8 weeks from first pre-compliance scan to completed formal test report.
• Evaluate CM5 for new designs. If PCIe Gen 3 throughput or USB 3.0 is relevant to the application, compare CM4 and CM5 early — changing compute modules after the carrier board design is advanced adds rework.

Common Mistakes

• Using a standard Pi development board in a production product. SD card failure from write wear is the most common Pi-related field failure. Always use the CM4 (or CM5) with eMMC for production, and design a custom carrier board.
• Omitting the nBOOT_ENABLE jumper from the carrier board. Without a mechanism to pull nBOOT_ENABLE low, the CM4 eMMC cannot be re-flashed without hardware rework. Include a solder jumper or programming header on every carrier board design.
• Routing high-speed signals without impedance control. PCIe, HDMI, USB, and MIPI signals leaving the CM4 connectors require controlled-impedance traces. Treating them as ordinary signal lines causes signal integrity failures that are difficult and expensive to debug after the board is built.
• Assuming the CM4 radio certification covers the complete product. The CM4 holds its own ACMA radio registration; the complete product (CM4 + carrier board) requires separate CISPR 32 testing and ACMA registration under you as the responsible supplier.
• Sizing the power supply to idle measurements. A carrier board that appears stable at idle may cause undervoltage throttling under CPU and peripheral load, causing filesystem corruption and random reboots. Characterise power draw at full operating load before finalising the power supply design.
• Underestimating embedded Linux integration effort. The CM4 runs a full Linux OS. Device tree configuration, kernel driver integration, config.txt overlay management, and production image hardening require embedded Linux expertise. If the team lacks this background, factor in significant additional development time.