Foundation

Raspberry Pi
Documentation

Computers

Accessories

Microcontrollers

Services

Pico C SDK

Compute Module
hardware

Datasheets and Schematics

Edit this on GitHub

Compute Module 4
The latest version of the Compute Module is the Compute
Module 4 (CM4). It is the recommended Compute Module
for all current and future development.

Compute Module 4 Datasheet

Compute Module 4 IO Board Datasheet

NOTE

Schematics are not available for the Compute Module

4, but are available for the IO board. Schematics for
the CMIO4 board are included in the datasheet.

There is also a KiCad PCB design set available:

Compute Module 4 IO Board KiCad Eles

Older Products
Raspberry Pi CM1, CM3 and CM3L are supported
products with an End-of-Life (EOL) date no earlier than
January 2026. The Compute Module 3+ offers improved
thermal performance, and a wider range of Flash memory
options.

Compute Module 1 and Compute Module 3

Raspberry Pi CM3+ and CM3+ Lite are supported prodicts

with an End-of-Life (EOL) date no earlier than January
2026.

Compute Module 3+

Schematics for the Compute Module 1, 3 and 3L

CM1 Rev 1.1

CM3 and CM3L Rev 1.0

Schematics for the Compute Module IO board (CMIO):

CMIO Rev 3.0 (Supports CM1, CM3, CM3L, CM3+

and CM3+L)

Schematics for the Compute Module camera/display

adapter board (CMCDA):

CMCDA Rev 1.1

Under Voltage Detection

Schematic for an under-voltage detection circuit, as used

in older models of Raspberry Pi:

Design Files for CMIO

Boards
Edit this on GitHub

Compute Module IO board for CM4

Design data for the Compute Module 4 IO board can be
found in its datasheet:

Compute Module 4 IO Board datasheet

There is also a KiCad PCB design set available:

Compute Module 4 IO Board KiCad Eles

Older Products
CMIO Rev 1.2

CMIO Rev 3.0

Design data for the Compute Module camera/display

adapter board (CMCDA):

CMCDA Rev 1.1

Flashing the Compute

Module eMMC
Edit this on GitHub

The Compute Module has an on-board eMMC device

connected to the primary SD card interface. This guide
explains how to write data to the eMMC storage using a
Compute Module IO board.

Please also read the section in the Compute Module

Datasheets

IMPORTANT

For mass provisioning of CM3, CM3+ and CM4 the

Raspberry Pi Compute Module Provisioning System is
recommended.

Steps to Flash the eMMC

To Wash the Compute Module eMMC, you either need a
Linux system (a Raspberry Pi is recommended, or Ubuntu
on a PC) or a Windows system (Windows 10 is
recommended). For BCM2837 (CM3), a bug which
affected the Mac has been Exed, so this will also work.

NOTE

There is a bug in the BCM2835 (CM1) bootloader

which returns a slightly incorrect USB packet to the
host. Most USB hosts seem to ignore this benign bug
and work Ene; we do, however, see some USB ports
that don’t work due to this bug. We don’t quite
understand why some ports fail, as it doesn’t seem to
be correlated with whether they are USB2 or USB3
(we have seen both types working), but it’s likely to be
speciEc to the host controller and driver. This bug has
been Exed in BCM2837.

Setting up the CMIO board

Compute Module 4

Ensure the Compute Module is Etted correctly installed on

the IO board. It should lie Wat on the IO board.

Make sure that nRPI_BOOT which is on J2

(disable eMMC Boot) on the IO board jumper is
Etted

Use a micro USB cable to connect the micro USB

slave port J11 on IO board to the host device.

Do not power up yet.

Compute Module 1 and 3

Ensure the Compute Module itself is correctly installed on

the IO board. It should lie parallel with the board, with the
engagement clips clicked into place.

Make sure that J4 (USB SLAVE BOOT ENABLE) is

set to the 'EN' position.

Use a micro USB cable to connect the micro USB

slave port J15 on IO board to the host device.

Do not power up yet.

For Windows Users

Under Windows, an installer is available to install the

required drivers and boot tool automatically. Alternatively,
a user can compile and run it using Cygwin and/or install
the drivers manually.

Windows Installer

For those who just want to enable the Compute Module

eMMC as a mass storage device under Windows, the
stand-alone installer is the recommended option. This
installer has been tested on Windows 10 64-bit.

Please ensure you are not writing to any USB devices

whilst the installer is running.

1. Download and run the Windows installer to install

the drivers and boot tool.

2. Plug your host PC USB into the USB SLAVE port,

making sure you have setup the board as described
above.

3. Apply power to the board; Windows should now

End the hardware and install the driver.

4. Once the driver installation is complete, run the

RPiBoot.exe tool that was previously installed.

5. After a few seconds, the Compute Module eMMC

will pop up under Windows as a disk (USB mass
storage device).

Building rpiboot on your host system.

Instructions for building and running the latest release of

rpiboot are documented in the usbboot readme on
Github.

Writing to the eMMC (Windows)

After rpiboot completes, a new USB mass storage drive

will appear in Windows. We recommend using Raspberry
Pi Imager to write images to the drive.

Make sure J4 (USB SLAVE BOOT ENABLE) / J2

(nRPI_BOOT) is set to the disabled position and/or
nothing is plugged into the USB slave port. Power cycling
the IO board should now result in the Compute Module
booting from eMMC.

Writing to the eMMC (Linux)

After rpiboot completes, you will see a new device

appear; this is commonly /dev/sda on a Raspberry Pi
but it could be another location such as /dev/sdb, so
check in /dev/ or run lsblk before running rpiboot so
you can see what changes.

You now need to write a raw OS image (such as

Raspberry Pi OS) to the device. Note the following
command may take some time to complete, depending
on the size of the image: (Change /dev/sdX to the
appropriate device.)

sudo dd if=raw_os_image_of_your_choice.img of=/dev

Once the image has been written, unplug and re-plug the
USB; you should see two partitions appear (for Raspberry
Pi OS) in /dev. In total, you should see something similar
to this:

/dev/sdX <- Device

/dev/sdX1 <- First partition (FAT)
/dev/sdX2 <- Second partition (Linux filesystem)

The /dev/sdX1 and /dev/sdX2 partitions can now be

mounted normally.

Make sure J4 (USB SLAVE BOOT ENABLE) / J2

(nRPI_BOOT) is set to the disabled position and/or
nothing is plugged into the USB slave port. Power cycling
the IO board should now result in the Compute Module
booting from eMMC.

Compute Module 4 Bootloader

The default bootloader conEguration on CM4 is designed
to support bringup and development on a Compute
Module 4 IO board and the software version Washed at
manufacture may be older than the latest release. For
Enal products please consider:-

Selecting and verifying a speciEc bootloader

release. The version in the usbboot repo is always
a recent stable release.

ConEguring the boot device (e.g. network boot). See

BOOT_ORDER section in the bootloader
conEguration guide.

Enabling hardware write protection on the

bootloader EEPROM to ensure that the bootloader
can’t be modiEed on remote/inaccessible products.

N.B. The Compute Module 4 ROM never runs

recovery.bin from SD/EMMC and the rpi-eeprom-
update service is not enabled by default. This is
necessary because the EMMC is not removable and an
invalid recovery.bin Ele would prevent the system from
booting. This can be overridden and used with self-
update mode where the bootloader can be updated from
USB MSD or Network boot. However, self-update mode
is not an atomic update and therefore not safe in the
event of a power failure whilst the EEPROM was being
updated.

Flashing NVMe / other storage devices.

The new Linux-based mass-storage gadget supports

Washing of NVMe, EMMC and USB block devices. This is
normally faster than using the rpiboot Ermware driver
and also provides a UART console to the device for easier
debug.

See also: CM4 rpiboot extensions

Modifying the bootloader conRguration

To modify the CM4 bootloader conEguration:-

cd usbboot/recovery

Replace pieeprom.original.bin if a speciEc

bootloader release is required.

Edit the default boot.conf bootloader

conEguration Ele. Typically, at least the
BOOT_ORDER must be updated:-

For network boot BOOT_ORDER=0xf2

For SD/EMMC boot BOOT_ORDER=0xf1

For USB boot failing over to EMMC

BOOT_ORDER=0xf15

Run ./update-pieeprom.sh to update the

EEPROM image pieeprom.bin image Ele.

If EEPROM write protection is required then edit

config.txt and add eeprom_write_protect=1.
Hardware write-protection must be enabled via
software and then locked by pulling the
EEPROM_nWP pin low.

Run ../rpiboot -d . to update the bootloader

using the updated EEPROM image pieeprom.bin

The pieeprom.bin Ele is now ready to be Washed to the

Compute Module 4.

Flashing the bootloader EEPROM - Compute Module

4

To Wash the bootloader EEPROM follow the same

hardware setup as for Washing the EMMC but also ensure
EEPROM_nWP is NOT pulled low. Once complete
EEPROM_nWP may be pulled low again.

# Writes recovery/pieeprom.bin to the bootloader E

./rpiboot -d recovery

Troubleshooting
For a small percentage of Raspberry Pi Compute Module
3s, booting problems have been reported. We have traced
these back to the method used to create the FAT32
partition; we believe the problem is due to a difference in
timing between the BCM2835/6/7 and the newer eMMC
devices. The following method of creating the partition is
a reliable solution in our hands.

sudo parted /dev/<device>

(parted) mkpart primary fat32 4MiB 64MiB
(parted) q
sudo mkfs.vfat -F32 /dev/<device>
sudo cp -r <files>/* <mountpoint>

Attaching and Enabling

Peripherals
Edit this on GitHub

NOTE

Unless explicitly stated otherwise, these instructions

will work identically on Compute Module 1 and
Compute Module 3 and their CMIO board(s).

This guide is designed to help developers using the

Compute Module 1 (and Compute Module 3) get to grips
with how to wire up peripherals to the Compute Module
pins, and how to make changes to the software to enable
these peripherals to work correctly.

The Compute Module 1 (CM1) and Compute Module 3

(CM3) contain the Raspberry Pi BCM2835 (or BCM2837
for CM3) system on a chip (SoC) or 'processor', memory,
and eMMC. The eMMC is similar to an SD card but is
soldered onto the board. Unlike SD cards, the eMMC is
speciEcally designed to be used as a disk and has extra
features that make it more reliable in this use case. Most
of the pins of the SoC (GPIO, two CSI camera interfaces,
two DSI display interfaces, HDMI etc) are freely available
and can be wired up as the user sees Et (or, if unused, can
usually be left unconnected). The Compute Module is a
DDR2 SODIMM form-factor-compatible module, so any
DDR2 SODIMM socket should be able to be used

NOTE

The pinout is NOT the same as an actual SODIMM

memory module.

To use the Compute Module, a user needs to design a

(relatively simple) 'motherboard' which can provide power
to the Compute Module (3.3V and 1.8V at minimum), and
which connects the pins to the required peripherals for
the user’s application.

Raspberry Pi provides a minimal motherboard for the

Compute Module (called the Compute Module IO Board,
or CMIO Board) which powers the module, brings out the
GPIO to pin headers, and brings the camera and display
interfaces out to FFC connectors. It also provides HDMI,
USB, and an 'ACT' LED, as well as the ability to program
the eMMC of a module via USB from a PC or Raspberry
Pi.

This guide Erst explains the boot process and how Device
Tree is used to describe attached hardware; these are
essential things to understand when designing with the
Compute Module. It then provides a worked example of
attaching an I2C and an SPI peripheral to a CMIO (or
CMIO V3 for CM3) Board and creating the Device Tree
Eles necessary to make both peripherals work under
Linux, starting from a vanilla Raspberry Pi OS image.

BCM283x GPIOs
BCM283x has three banks of General-Purpose
Input/Output (GPIO) pins: 28 pins on Bank 0, 18 pins on
Bank 1, and 8 pins on Bank 2, making 54 pins in total.
These pins can be used as true GPIO pins, i.e. software
can set them as inputs or outputs, read and/or set state,
and use them as interrupts. They also can be set to
'alternate functions' such as I2C, SPI, I2S, UART, SD card,
and others.

On a Compute Module, both Bank 0 and Bank 1 are free

to use. Bank 2 is used for eMMC and HDMI hot plug
detect and ACT LED / USB boot control.

It is useful on a running system to look at the state of

each of the GPIO pins (what function they are set to, and
the voltage level at the pin) so that you can see if the
system is set up as expected. This is particularly helpful if
you want to see if a Device Tree is working as expected,
or to get a look at the pin states during hardware debug.

Raspberry Pi provides the raspi-gpio package which is

a tool for hacking and debugging GPIO

NOTE

You need to run raspi-gpio as root.

To install raspi-gpio:

sudo apt install raspi-gpio

If apt can’t End the raspi-gpio package, you will need

to do an update Erst:

sudo apt update

To get help on raspi-gpio, run it with the help

argument:

sudo raspi-gpio help

For example, to see the current function and level of all

GPIO pins use:

sudo raspi-gpio get

NOTE

raspi-gpio can be used with the funcs argument to

get a list of all supported GPIO functions per pin. It will
print out a table in CSV format. The idea is to pipe the
table to a .csv Ele and then load this Ele using e.g.
Excel:

sudo raspi-gpio funcs > gpio-funcs.csv

BCM283x Boot Process

BCM283x devices consist of a VideoCore GPU and ARM
CPU cores. The GPU is in fact a system consisting of a
DSP processor and hardware accelerators for imaging,
video encode and decode, 3D graphics, and image
compositing.

In BCM283x devices, it is the DSP core in the GPU that

boots Erst. It is responsible for general setup and
housekeeping before booting up the main ARM
processor(s).

The BCM283x devices as used on Raspberry Pi and

Compute Module boards have a three-stage boot
process:

1. The GPU DSP comes out of reset and executes

code from a small internal ROM (the boot ROM).
The sole purpose of this code is to load a second
stage boot loader via one of the external interfaces.
On a Raspberry Pi or Compute Module, this code
Erst looks for a second stage boot loader on the SD
card (eMMC); it expects this to be called
bootcode.bin and to be on the Erst partition
(which must be FAT32). If no SD card is found or
bootcode.bin is not found, the Boot ROM sits and
waits in 'USB boot' mode, waiting for a host to give
it a second stage boot loader via the USB interface.

2. The second stage boot loader (bootcode.bin on

the sdcard or usbbootcode.bin for usb boot) is
responsible for setting up the LPDDR2 SDRAM
interface and various other critical system
functions and then loading and executing the main
GPU Ermware (called start.elf, again on the
primary SD card partition).

3. start.elf takes over and is responsible for

further system setup and booting up the ARM
processor subsystem, and contains the Ermware
that runs on the various parts of the GPU. It Erst
reads dt-blob.bin to determine initial GPIO pin
states and GPU-speciEc interfaces and clocks, then
parses config.txt. It then loads an ARM device
tree Ele (e.g. bcm2708-rpi-cm.dtb for a Compute
Module 1) and any device tree overlays speciEed in
config.txt before starting the ARM subsystem
and passing the device tree data to the booting
Linux kernel.

Device Tree
Device Tree is a special way of encoding all the
information about the hardware attached to a system
(and consequently required drivers).

On a Raspberry Pi or Compute Module there are several

Eles in the Erst FAT partition of the SD/eMMC that are
binary 'Device Tree' Eles. These binary Eles (usually with
extension .dtb) are compiled from human-readable text
descriptions (usually Eles with extension .dts) by the
Device Tree compiler.

On a standard Raspberry Pi OS image in the Erst (FAT)

partition you will End two different types of device tree
Eles, one is used by the GPU only and the rest are
standard ARM device tree Eles for each of the BCM283x
based Raspberry Pi products:

dt-blob.bin (used by the GPU)

bcm2708-rpi-b.dtb (Used for Raspberry Pi 1

Models A and B)

bcm2708-rpi-b-plus.dtb (Used for Raspberry Pi

1 Models B+ and A+)

bcm2709-rpi-2-b.dtb (Used for Raspberry Pi 2

Model B)

bcm2710-rpi-3-b.dtb (Used for Raspberry Pi 3

Model B)

bcm2708-rpi-cm.dtb (Used for Raspberry Pi

Compute Module 1)

bcm2710-rpi-cm3.dtb (Used for Raspberry Pi

Compute Module 3)

NOTE

dt-blob.bin by default does not exist as there is a

'default' version compiled into start.elf, but for
Compute Module projects it will often be necessary to
provide a dt-blob.bin (which overrides the default
built-in Ele).

NOTE

dt-blob.bin is in compiled device tree format, but is

only read by the GPU Ermware to set up functions
exclusive to the GPU - see below.

A guide to creating dt-blob.bin.

A guide to the Linux Device Tree for Raspberry Pi.

During boot, the user can specify a speciEc ARM device

tree to use via the device_tree parameter in
config.txt, for example adding the line
device_tree=mydt.dtb to config.txt where
mydt.dtb is the dtb Ele to load instead of one of the
standard ARM dtb Eles. While a user can create a full
device tree for their Compute Module product, the
recommended way to add hardware is to use overlays
(see next section).

In addition to loading an ARM dtb, start.elf supports

loading additional Device Tree 'overlays' via the
dtoverlay parameter in config.txt, for example
adding as many dtoverlay=myoverlay lines as
required as overlays to config.txt, noting that overlays
live in /overlays and are sujxed -overlay.dtb e.g.
/overlays/myoverlay-overlay.dtb. Overlays are
merged with the base dtb Ele before the data is passed to
the Linux kernel when it starts.

Overlays are used to add data to the base dtb that

(nominally) describes non-board-speciEc hardware. This
includes GPIO pins used and their function, as well as the
device(s) attached, so that the correct drivers can be
loaded. The convention is that on a Raspberry Pi, all
hardware attached to the Bank0 GPIOs (the GPIO header)