Compute Module 5 Setup: eMMC, NVMe, and IO Board Guide¶

Compute Module 5 packages the core of Raspberry Pi 5 for carrier-board designs. It is available with 2GB, 4GB, 8GB, or 16GB RAM and either no eMMC (Lite) or 16GB, 32GB, or 64GB eMMC. Unlike a normal Pi 5, the connectors and power design depend on the carrier board.

Choose Lite or eMMC¶

Variant	On-board storage	Best fit	Main trade-off
CM5 Lite	None	NVMe or removable storage, development flexibility	Carrier must provide boot storage path
CM5 eMMC	16/32/64GB	Appliances and controlled production images	eMMC must be exposed with `rpiboot` to reimage

Choose the wireless variant only if the enclosure, antenna location, and certification plan support it. The official Compute Module documentation should take priority over a generic Pi 5 pinout.

Assemble the CM5 IO Board¶

Disconnect every power source.
Align both board-to-board connectors; do not press one end down at an angle.
Press evenly until the module lies flat and both connectors are fully seated.
Fit the recommended cooling solution.
Connect display, network, USB, and storage only after checking the IO Board labels.

For eMMC flashing on the official CM5 IO Board:

fit the nRPI_BOOT jumper at J2 to disable normal eMMC boot
connect the host to the USB-C slave port at J11
then power the IO Board as documented

Do not confuse the slave/data connector with a power-only arrangement on a third-party carrier.

Build and Run `rpiboot` on Linux¶

On a Debian or Ubuntu host:

sudo apt update
sudo apt install git libusb-1.0-0-dev pkg-config build-essential
git clone --depth 1 https://github.com/raspberrypi/usbboot.git
cd usbboot
make
sudo ./rpiboot

Connect directly instead of through a USB hub if the module is not detected. A successful boot exposes eMMC as a mass-storage device on the host.

Identify the Storage Device Safely¶

Never assume the CM5 is /dev/sda. Capture block devices before and after running rpiboot:

1	`lsblk -o NAME,MODEL,SERIAL,SIZE,TRAN,MOUNTPOINTS`

Confirm model and capacity. Unmount any partitions the desktop mounted automatically. The wrong dd target can destroy the host operating system.

Prefer Raspberry Pi Imager because it shows the selected target and can apply hostname, user, SSH, Wi-Fi, and Connect settings. If automation requires dd, validate an explicit device path twice:

target_device=/dev/sdX
image_file=raspios.img

lsblk -o NAME,MODEL,SERIAL,SIZE "$target_device"
sudo dd if="$image_file" of="$target_device" bs=4M \
  conv=fsync status=progress
sync

Replace /dev/sdX only after inspection. Remove power, disconnect USB, and remove the nRPI_BOOT jumper before the first normal boot.

First Boot Validation¶

cat /proc/device-tree/model
cat /etc/os-release
uname -a
lsblk -o NAME,MODEL,SIZE,FSTYPE,MOUNTPOINTS
vcgencmd get_throttled

Update firmware and packages before debugging peripherals:

sudo apt update
sudo apt full-upgrade
sudo reboot

Do not run an EEPROM updater copied from an old Pi 4 guide without confirming CM5 applicability and release notes.

Add NVMe Storage¶

The official IO Board and many carrier boards expose PCIe for an M.2 NVMe device. Check the supported key, physical length, lane routing, and power budget for that carrier.

After installation:

lspci -nn
lsblk -o NAME,MODEL,SERIAL,SIZE,ROTA,TRAN
sudo nvme list
dmesg | grep -Ei 'pcie|nvme'

Partition by stable device identity, not by copying /dev/nvme0n1 blindly from an example. For a data drive, create a filesystem, obtain its UUID with blkid, and mount by UUID in /etc/fstab with nofail while testing.

For NVMe boot, update the bootloader using supported Raspberry Pi OS tools, inspect the current configuration, and place NVMe before or after eMMC in BOOT_ORDER according to the recovery design. Keep a tested eMMC recovery image before changing production boot order.

Cooling and Power¶

CM5 can sustain substantial CPU, GPU, PCIe, and I/O load. A carrier design must account for:

input voltage tolerance and transient load
NVMe startup and sustained power
airflow and heatsink contact pressure
enclosure ambient temperature
USB peripheral power
fan control and failure detection

Check throttling during a controlled load:

watch -n 1 'vcgencmd measure_temp; vcgencmd get_throttled'

Treat a non-zero historical throttling bit as evidence to investigate even when current temperature is normal.

Reproducible eMMC and NVMe Benchmarks¶

Use a disposable test file on the intended filesystem, not the raw production device:

test_dir=/path/to/test-filesystem
sync
/usr/bin/time -f 'elapsed=%e' \
  dd if=/dev/zero of="$test_dir/io-test.bin" bs=1M count=1024 \
  conv=fdatasync status=progress

sudo hdparm -Tt /dev/<device>
rm "$test_dir/io-test.bin"

For publishable results, prefer fio with a saved job file and report CM5 RAM, carrier, drive model/firmware, filesystem, mount options, free space, cooling, power supply, PCIe link speed, test size, runtime, temperature, and throttling state. Do not compare a cached read against an uncached write.

Troubleshooting¶

`rpiboot` waits forever¶

Check J2, connector seating, the USB slave port, cable data capability, power sequence, and lsusb. Remove USB hubs and close Raspberry Pi Imager before retrying.

eMMC appears but imaging fails¶

Unmount auto-mounted partitions, verify free host resources, try a direct port, inspect kernel logs, and confirm the image checksum. Re-run rpiboot after a full power cycle.

NVMe is absent¶

Inspect carrier compatibility, drive key/length, seating, PCIe cable orientation where applicable, power, bootloader version, lspci, and kernel logs. Test another supported drive before changing PCIe generation settings.

Random resets under I/O load¶

Suspect power delivery and thermals. Remove USB loads, test eMMC without NVMe, use the recommended supply, and monitor get_throttled while reproducing the workload.

FAQ¶

Is CM5 a drop-in replacement for CM4?¶

No. Although the form factor is related, power, interfaces, thermal design, firmware, and carrier compatibility must be verified against current CM5 documentation.

Can an eMMC CM5 also boot from NVMe?¶

Yes when the carrier, bootloader configuration, and NVMe device support it. Keep eMMC as a recovery path until the NVMe image and boot order are proven.

Is the IO Board suitable for a final product?¶

It is excellent for development and validation. A production carrier should implement only the required interfaces and complete its own power, signal-integrity, thermal, EMC, and compliance validation.