A practical guide to designing carrier boards for the Raspberry Pi Compute Module 4 and 5 — power sequencing, boot media, PCIe and USB fan-out, display and camera interfaces, thermal budget and production test.
A development board is an excellent way to prove that a product idea works. It is a poor way to ship one. Somewhere between the working prototype and the first production batch, most teams run into the same wall: the connectors face the wrong way, the enclosure has to be built around a board nobody designed for it, half the GPIO header is unused while the two interfaces the product actually needs are missing, and the mechanical fit depends on a board whose outline could change in a future revision.
The Raspberry Pi Compute Module exists for exactly this transition. CM4 and the newer CM5 package the processor, memory, storage and power management into a module that mates with a carrier board you design, so the product gets exactly the connectors, mechanics and interfaces it needs while the complicated silicon stays on a module that is manufactured, tested and supported by someone else. You keep the Raspberry Pi software ecosystem — the same kernel, the same device tree conventions, the same enormous body of community knowledge — and you drop the development-board compromises.
What teams underestimate is that the carrier board is a real hardware project. The module hides the DDR routing and the SoC power rails, which removes the hardest work, but everything else is yours: power sequencing, boot media, high-speed fan-out, display and camera interfaces, thermal design, EMC, and production test. This article covers what we check on a Compute Module carrier design, and where we most often see boards go wrong.
The module needs a clean supply and a controlled power-up. Most first-revision carrier problems we see are power problems wearing other costumes — a board that boots on the bench but not in the enclosure, a device that works from a lab supply but resets from the product's own battery, a unit that is fine at room temperature and unstable at 50°C.
Three things deserve explicit attention on every carrier design:
We treat the power tree as the first design artefact on a carrier project, before the connector placement is argued about. Every rail gets a budget, a worst-case transient estimate and a measurement plan. On delivered projects this discipline is what separates a board that needs three revisions from one that needs one — in our smart medication dispenser, a Raspberry Pi served as the main controller alongside a dedicated main board, a speaker amplifier and 12V-to-5V power management supporting both 1-cell and 3-cell battery arrangements. The electronics, the power path and the mechanical frame iterated together, because on an electromechanical product the power margin and the enclosure are the same problem viewed from two sides.
CM4 and CM5 are available with on-module eMMC or in a "Lite" variant that boots from an SD card you place on the carrier. The choice has consequences well beyond the bill of materials.
eMMC is the right default for most products. It is soldered down, which removes a connector, a mechanical failure point and a service-call category. It is faster than most SD cards and far more predictable under sustained writes. The cost is provisioning: you need a way to get an image onto the module, which means exposing the USB device port used for mass-storage flashing, and a production process that handles it. We design that port in deliberately, with test points or a fixture-friendly connector, rather than discovering at the factory that the only way to flash a unit is to open it.
SD cards earn their place when field-swappable media is genuinely required, or when the product ships in small volumes with frequent image changes. If you go that way, specify the card. Industrial-grade cards with known controllers behave very differently from the cheapest consumer part, and the difference shows up as corruption after months in the field, not on the bench.
Either way, plan the filesystem for power loss. Read-only root with an overlay, a separate writable data partition, and journaled writes for anything that matters are standard practice on products we deliver. This is a software decision made at hardware design time, because it affects partitioning, media sizing and sometimes the choice of module variant.
The single biggest change from CM4 to CM5 is bandwidth. Both expose PCIe, both expose USB and Ethernet, and both make those interfaces available to your carrier through the board-to-board connectors. The design work is in the routing.
PCIe is the least forgiving. Differential pairs need controlled impedance, intra-pair length matching, careful reference plane continuity, and AC coupling capacitors placed where the layout tool says rather than where the board outline is convenient. A via stub in the wrong place or a pair that crosses a plane split can turn a link that negotiates at full speed on the bench into one that drops to a lower rate, or that works on two units out of three. We route PCIe first, before the connectors are finalised, because the geometry it needs constrains everything else.
USB is more tolerant but still differential. The common failures we see are impedance discontinuities at connectors, ESD protection placed after a long stub instead of right at the port, and hubs added late to make up for a connector count that was decided before the interface budget was understood.
Ethernet brings magnetics, isolation and a connector that is mechanically significant. Where the product is industrial, we check the surge and isolation requirements early because they influence the connector choice and the board outline, not just the schematic. Our Allwinner R528 control board is a useful reference point from an adjacent platform: five UART channels, GPIO and USB peripherals all had to coexist with web services on one Linux device, and the interface allocation was settled at the architecture stage rather than negotiated during bring-up.
Compute Modules expose MIPI DSI and CSI lanes, and this is where many products get their differentiation — a custom panel, an embedded camera, a cover glass with bonded touch. It is also where carrier projects most often lose time.
MIPI is a short-reach, tightly specified interface. Lane lengths must be matched, the flex connector choice matters, and the panel's power-up sequence and initialisation commands have to be right before anything appears on screen. Many panels are not driven directly but through a bridge, and the bridge brings its own configuration and timing requirements.
We have taken this path on Raspberry Pi hardware. Our Raspberry Pi DSI display project brought up multiple panel sizes — 4.3, 5, 7 and 10 inch — on a Raspberry Pi 5, with an ICN6211 bridge handling MIPI DSI conversion, the display configured through DTS and DTBO device tree overlays, and I2C debug logging used to diagnose the touch path. The lesson that transfers directly to Compute Module carriers: the device tree is the real battleground. Swap the panel on the same electrical interface and timing parameters, power-up sequence and touch configuration all change with it. Putting that configuration in device tree overlays rather than hard-coding it into drivers is what makes a product line with several screen options maintainable.
Camera work follows the same shape. The sensor initialisation sequence, ISP configuration and V4L2 integration are each straightforward in isolation and time-consuming together, especially with a module whose vendor documentation assumes a different host.
More performance means more heat. A CM5 under sustained load dissipates meaningfully more than a CM4 doing the same job, and a carrier designed around CM4 thermal assumptions can throttle or become unreliable when the module is upgraded.
Thermal design on a carrier is mostly mechanical, which means it has to start when the enclosure does. Copper area and via stitching under the module, clearance for a heatsink, airflow paths if there is a fan, and the surface the enclosure presents to ambient all matter more than anything in the schematic. For sealed enclosures — common in industrial and outdoor products — the enclosure itself is the heatsink and the thermal path has to be designed as one system.
We design the mechanical and electrical sides together for this reason. On the medication dispenser the chassis frame was modelled in FreeCAD alongside the boards; on the microscope motorised stage the micro-motion platform PCB and its mechanical parts were verified together on every revision, because tuning either side alone never converged. A Compute Module carrier in a sealed enclosure is the same class of problem.
Products built on Compute Modules routinely need FCC, CE or equivalent certification, and almost everything that determines the outcome is fixed during layout. Clock and high-speed trace routing, return path continuity, connector placement and cable shielding decisions, filtering on power entry, antenna keep-out if the product has radios — these are layout-stage decisions that cannot be patched in firmware afterwards.
The common and expensive mistake is treating certification as a test you book rather than a constraint you design for. By the time a board reaches a test lab, a radiated emissions failure usually means a revision and another lab booking. We prefer to spend an hour on return paths during layout than three weeks on a re-spin.
A carrier board that cannot be tested quickly becomes a factory problem. We specify, at design time, how a finished unit will be verified: test points on the rails that matter, a boot-and-report sequence that exercises each interface, access for programming, and a pass/fail criterion a technician can apply without judgement calls.
Our prototyping practice puts a first-article inspection and a defect record at the centre of every pilot run, with design-for-manufacturing review done before the order is placed — pad and stencil aperture matching, placement clearances, polarity silkscreen, and whether the test points a technician will need actually exist. A DFM change at the Gerber stage costs nothing; the same change after assembly means reworking a batch.
CM5 is the right default for new designs that need the performance — heavier application workloads, higher display resolutions, more aggressive camera or AI processing. CM4 remains sensible where the workload is modest, where the thermal envelope is tight, where an existing CM4 carrier already exists and the product does not need more, or where supply and cost favour it.
What matters more than the comparison is designing the carrier so the decision is not permanent. Where a product may plausibly move between modules, we check the pinout and mechanical differences up front, budget the power and thermal design for the more demanding option, and avoid building the carrier around assumptions that only hold for one variant. The cost of that foresight at schematic stage is small; the cost of discovering it after tooling is not.
A typical engagement runs as follows. We start with the interface list and the enclosure constraints, because those two together determine most of the board. The power tree and thermal strategy are settled next, then the high-speed routing geometry, then the connector placement everyone has an opinion about. Schematic and layout are done in KiCad, mechanical parts in FreeCAD, and the two are checked against each other — mounting holes, connector positions and height limits aligned during layout rather than discovered when the enclosure arrives.
From there the board goes through fabrication and assembly, first-article inspection, and bring-up. Because we also write the firmware and the Linux side, bring-up problems get diagnosed across layers: when a peripheral misbehaves we check the schematic, put a scope on the signal, read the kernel log and change the device tree, rather than passing a symptom between suppliers. That cross-layer capability is the main reason clients bring whole products to us rather than board design alone.
If you are planning a product around a Compute Module and want the carrier, the Linux bring-up and the application layer handled by one team, our hardware design service and Linux BSP service cover that path end to end.
Contact us for customized solutions and quotes