Bring up a Raspberry Pi CM5

The Raspberry Pi Compute Module 5 is the SpaceOS deploy reference and the board with full OS support: SpaceOS owns the boot path, with native board secure boot, dm-verity, health-gated system releases with automatic rollback, and real KVM for Solo5 hvt unikernels. Only the CM5 and the development VM provide verified boot and system-release rollback; the other supported boards run SpaceOS as a system daemon. The CM5 is a bench board, not flight hardware: use it to test the full deploy flow before moving to a flight computer.

Prerequisites

A CM5 module on a carrier board. The CM5 Dev Kit is self-contained: module (BCM2712, quad Cortex-A76, aarch64, eMMC), IO board, cooling, power supply, and the USB cable used for eMMC flashing.
The Space CLI on your workstation, with a working local loop from the quickstart.
Gigabit Ethernet between workstation and board.

Pick a profile

Two content-addressed target profiles are checked in for the CM5. They make different trust claims and are not interchangeable:

Profile	Boot policy	Rollback claim	Use
`cm5-dev`	Reversible customer-signature validation; nothing burned into the chip	Software trial/rollback state	Development, provisioning tests, fault injection
`cm5`	Customer RSA key hash written into one-time-programmable (OTP) memory; development key path revoked	Discrete TPM with a rollback floor that only counts up, and sealed secrets	Locked deploy reference

Writing the key into OTP memory is permanent: the board cannot be returned to the cm5-dev profile afterwards.

Start with cm5-dev for bring-up and fault injection; move to cm5 once your provisioning flow is proven.

Path A: daemon bring-up on Raspberry Pi OS

Daemon bring-up runs SpaceOS on stock Raspberry Pi OS (64-bit). This is the daemon install model. The vendor OS retains responsibility for verified boot.

Flash Raspberry Pi OS Lite (64-bit) to the eMMC. Put the module in USB-boot mode with rpiboot, which exposes the eMMC as USB mass storage, then flash with Raspberry Pi Imager or dd.
Boot, complete first-run setup, and confirm KVM: ls /dev/kvm. The stock 64-bit kernel ships with KVM; unikernels then run under hvt.
Install the SpaceOS runtime binaries from the release channel for your platform.

Join the board to your context as a runner:

space runner join <context> --name cm5-01 \
  --target-profile cm5-dev@sha256:<digest>

From your workstation, space run --name web <image> now places signed workloads onto the board through the scheduler, and space ps, space logs, and space stats observe them.

Path B: the SpaceOS system image

The SpaceOS system image provides native signed boot, a dm-verity root, content-store release history, and measured launch.

Connect the target with its profile, signing custody, and transport:
Terminal window
```
space target connect cm5-demo --profile cm5-dev \
  --signing-key keys/cm5-demo.pem \
  --endpoint ipn:7.1 --cla-address cm5-demo.local:4556 --always-reachable
```
--always-reachable is the right claim for a bench board on your network; a node reached over real passes names its orbit with --tle and --station instead.
Dry-run the release. --plan assembles the flashable cm5.img (the firmware boot partition first, signed boot.img plus boot.sig, then the system content store) and prints the release descriptor:
Terminal window
```
space build . -t app:release --release --signing-profile release
space deploy app:release --target cm5-demo --plan
```
First install is physical: flash the assembled image to the eMMC over rpiboot, then power-cycle. Every later release goes over the link into the content store, boots on trial, and confirms only after health.

Deploy and inspect the pipeline:

space deploy app:release --target cm5-demo
space status <deploy-id>

Smoke-test coverage

The cm5-dev conformance test exercises native signed boot, rejection of a modified image, dm-verity fault handling, a signed workload through every declared backend (hvt, runc), blue/green promotion, and a system release trial with automatic fallback.

Secure-boot provisioning is separate

Enrolling the customer secure-boot key and burning it into the board’s one-time-programmable memory are irreversible, hardware-gated admin operations (space target enroll, space target fuse). Both ask for explicit confirmation, and both are performed once, with physical access, after the deploy flow passes on the reversible profile. A routine space deploy has no authority to modify fuses.

Selection criteria

You want the full SpaceOS security properties on real hardware: signed boot, verified root, health-gated release rollback, hardware-VM unikernel isolation.
You are testing a provisioning and update flow before committing to a flight computer.
You need a low-cost, self-contained bench node that behaves like the deploy tier with the locked hardware profile.