Bring up a Raspberry Pi CM5

Where this stands

The CM5 is a supported target. Two profiles ship in the platform’s profile catalog, cm5-dev and cm5, and automated image tests exercise them. The platform source records this in its support matrix (docs/support-matrix.md), which lists the CM5 alongside the development VM and hosted Linux as the three supported rows.

One leg is open: the operator procedure that boots and tampers with a physical board has not been run, so locked boot, rollback and attestation on hardware carry no evidence beyond the automated image tests.

The Raspberry Pi Compute Module 5 is the SpaceOS deploy reference and the board running the system-image model. SpaceOS owns the boot path here, with native board secure boot, dm-verity, health-gated system releases with automatic rollback, and real KVM for Solo5 hvt unikernels. It is a supported target at 1.0, alongside the development VM and hosted Linux. The CM5 and the development VM are the two places you get verified boot and system-release rollback; every other board in the target matrix runs SpaceOS as a daemon install. The CM5 is bench hardware, so use it to prove the full deploy flow before you move 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.
• Gigabit Ethernet between workstation and board.

Pick a profile

Two content-addressed target profiles ship for the CM5. They make different trust claims, and you cannot swap one for the other:

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. You cannot return the board to the cm5-dev profile after that.

Start with cm5-dev for bring-up and fault injection, then move to cm5 once your provisioning flow works.

Path A: daemon bring-up on Raspberry Pi OS

Daemon bring-up runs SpaceOS on stock Raspberry Pi OS (64-bit), the daemon install model. The vendor OS keeps verified boot.

1. 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.
2. Boot the module and finish first-run setup, then confirm KVM with ls /dev/kvm. The stock 64-bit kernel ships with KVM, so unikernels run under hvt.
3. Install the SpaceOS runtime binaries from the release channel for your platform.
4. Connect the board to your context as a target.

space target connect cm5-01 --profile cm5-dev \
  --endpoint ipn:7.1 --cla-address cm5-01.local:4556 --always-reachable

From your workstation, space run --name web <image> now places signed workloads onto the board through the scheduler. Watch them with space status and space logs. The telemetry is in space status --json. That command reads the local runner, so it needs the local context.

Path B: the SpaceOS system image

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

1. Connect the target with its profile, signing custody, and transport. Claim --always-reachable for a bench board on your network. A node reached over real passes names its orbit with --tle and its ground station with --station.

space target connect cm5-demo --profile cm5-dev \
  --endpoint ipn:7.1 --cla-address cm5-demo.local:4556 --always-reachable

2. Rehearse the release. --plan assembles the flashable cm5.img and prints the release descriptor. That image carries the firmware boot partition first, then signed boot.img with boot.sig, then the system content store.

   --signing-profile names a release identity that already exists. space keys generate release makes one on the bench; a flight release names an identity generated where the release is authorized.

space build . -t app:release --release --signing-profile release \
  --rollback-index 1
space deploy app:release --target cm5-demo --plan

3. The first install is physical. Flash the assembled image to the eMMC over rpiboot, then power-cycle. Every later release travels over the link into the content store. It boots on trial and confirms only after a health check.

4. Deploy and inspect the pipeline.

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

Smoke-test coverage

The cm5-dev profile declares the cm5-dev-v1 smoke test, and its pass criteria are exactly four:

• native-signed-boot, and modified-image-rejection.
• dm-verity.
• hvt-workload, a signed workload under the Solo5 hvt tender.

The locked cm5 profile declares cm5-v1, which adds otp-locked-boot, tpm2-sessions, nv-floor-replay-rejection and sealed-secret-policy.

Blue/green promotion and a system-release trial with automatic fallback are part of the platform design and are not pass criteria of either smoke test.

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 steps. Run them with the Raspberry Pi provisioning tools, at the board, once you have tested the reversible profile.

Selection criteria

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