---
title: "The prototype boots. Production has to repeat it without mistakes"
locale: "en"
url: "https://irz.fr/en/articles/cm5-jig-prototype-production-en"
markdown_url: "https://irz.fr/en/articles/cm5-jig-prototype-production-en.md"
category: "tech"
tags: ["Raspberry Pi", "Compute Module 5", "production", "provisioning", "hardware"]
published_at: "2026-08-21T13:40:00.000Z"
author: "Camille Morel"
translation: "https://irz.fr/fr/articles/cm5-jig-prototype-production-fr.md"
---

# The prototype boots. Production has to repeat it without mistakes

The Compute Module 5 jig turns manual provisioning into a repeatable cycle and can create device-specific security state along the way.

A prototype can tolerate a certain amount of ceremony: put Compute Module 5 on an IO Board, select its boot mode, connect USB to a host computer, run `rpiboot`, then write the system image, a perfectly reasonable sequence for one module.[4](https://www.raspberrypi.com/documentation/computers/compute-module.html) Repeat the same procedure across a box of boards, however, and what looked like setup work starts behaving like a manufacturing process.

Raspberry Pi’s **Compute Module 5 Programming Jig** makes that shift unusually visible because the product is almost entirely about the work surrounding the computer. A bare CM5 drops into a mechanically defined bay, spring-loaded pogo pins make direct contact, and closing the clamp starts provisioning without requiring a separate carrier board.[1](https://www.raspberrypi.com/ew-programming-jig/)

Faster flashing helps, but the main industrial change lies elsewhere. The more important change is that a developer procedure can be turned into something another operator can repeat, observe and later audit.

## Remove the ritual

The standard development route temporarily builds a small system around the module: an IO Board, power, boot selection, a USB connection and host-side software.[4](https://www.raspberrypi.com/documentation/computers/compute-module.html) The jig transfers much of that knowledge into its physical design. Four locating studs constrain the board, the lid supplies repeatable pressure, and a switch linked to the clamp tells the provisioning software when the target is in place.[1](https://www.raspberrypi.com/ew-programming-jig/)

> Same CM5
> **From gesture to cycle**
> - IO Board, boot selection, USB, rpiboot and manual checks.: Prototype
> - Mechanical location, pogo pins, clamp closure and automatic detection.: Fixture
> - LEDs and services expose bootstrap, provisioning, completion and faults.: State
> - Logs and manufacturing data can follow each unit by serial number.: Record
> The module stays the same. The process around it becomes a tool.

But the operator matters in a narrower way: place the module correctly, close the fixture, watch the state and remove the board when the cycle has actually finished. Reconstructing the whole technical sequence from memory is no longer part of every repetition, which is a small improvement for one board and a large one once the operation fills an afternoon.

## Delicate contacts

Pogo pins are a standard production-fixture idea, yet Raspberry Pi is unusually blunt about their weakness here. The contacts are delicate, and closing an empty fixture can damage them. Poor alignment can bend the pins or spoil a provisioning attempt; removing a CM5 while work is in progress can leave the target unusable.[1](https://www.raspberrypi.com/ew-programming-jig/)

That warning explains why the interesting object is the complete fixture rather than the pins themselves. The bay controls position while the studs prevent sideways drift and the clamp applies contact force. So software ties that mechanical state to the start of the cycle, leaving fewer decisions for the operator to repeat correctly every time.

A jig does not abolish error. It moves repeated judgement into geometry and interlocks, where the same answer is produced without asking somebody to remember it for board number 97.

## Three outcomes

The software behind the station, `rpi-sb-provisioner`, also makes “copy this disk image” an incomplete description. Its main paths include a bare installation, full-disk encryption but not secure boot, and secure boot combined with encrypted storage; prepared IDP artefacts can carry their own partition and storage description as well.[2](https://github.com/raspberrypi/rpi-sb-provisioner)[3](https://github.com/raspberrypi/rpi-sb-provisioner/blob/main/docs/architecture.md)

> Same image, different outcome
> **Three provisioning modes**
> - Installs the OS with neither encryption nor secure boot.: Naked
> - Encrypts storage and uses device-specific secret material.: FDE
> - Adds a signed chain and writes the customer key hash into OTP.: Secure boot
> - Deploys prepared artefacts carrying partition and storage metadata.: IDP
> Provisioning can keep software consistent, with each unit remaining cryptographically distinct.

In the encrypted modes, hardware-held device-specific secret material is used to derive the data needed to unlock storage. Secure-boot provisioning goes further by writing the customer signing-key hash into OTP memory, a permanent hardware state that means two modules can receive the same operating-system image while not becoming cryptographically identical copies.[2](https://github.com/raspberrypi/rpi-sb-provisioner)[3](https://github.com/raspberrypi/rpi-sb-provisioner/blob/main/docs/architecture.md)

That difference is easy to miss when provisioning is described as flashing. Production wants consistency, but the security state must not become identical across every device.

## Permanent means careful

Irreversible state changes raise the cost of a careless sequence, which is why the provisioner divides work into bootstrap, triage and provisioning phases rather than treating the whole job as one opaque command. It keeps state by serial number and writes per-device logs, including `/var/log/rpi-sb-provisioner/<serial>/provisioner.log`.[3](https://github.com/raspberrypi/rpi-sb-provisioner/blob/main/docs/architecture.md) The manufacturing database can also retain serial numbers, MAC addresses, timestamps and the security configuration applied to an individual unit.[2](https://github.com/raspberrypi/rpi-sb-provisioner)

Months later, that record can answer a question that rarely matters for the first prototype and routinely matters in support: **what was actually done to this particular device?** The engineer who remembers every manual step is no longer the database; the process has its own memory.

## Forty an hour

Raspberry Pi gives one useful cycle-time figure: a 2.6 GB image in `naked` mode typically takes about **1.5 minutes per device**, with actual time depending on image size, storage and network conditions.[1](https://www.raspberrypi.com/ew-programming-jig/) If a single head could run continuously with zero handling time, the arithmetic ceiling would be 40 modules an hour, because `60 / 1.5 = 40`.

The arithmetic ceiling says nothing about measured factory throughput. A real operator has to open the fixture, swap boards, verify status and deal with failures, while encryption and secure-boot paths perform more work than a bare OS installation.[1](https://www.raspberrypi.com/ew-programming-jig/)[3](https://github.com/raspberrypi/rpi-sb-provisioner/blob/main/docs/architecture.md) The useful change is simpler: we now have an engineering number for the cycle instead of a vague impression of how quickly somebody can repeat a terminal session.

Although the software architecture supports parallel provisioning,[3](https://github.com/raspberrypi/rpi-sb-provisioner/blob/main/docs/architecture.md) Raspberry Pi’s documented CM5 fixture has one physical head.[1](https://www.raspberrypi.com/ew-programming-jig/) So more throughput means more stations or heads, not one black box somehow programming several loose modules by industrial telepathy.

> Naked mode, 2.6 GB
> **The cycle becomes data**
> - Published typical time for one device in this configuration.: 1.5 min
> - Theoretical one-head ceiling before handling and failures.: 40/h
> - The documented physical jig provisions one CM5 at a time.: 1 head
> - The software can run provisioners in parallel across multiple stations.: N heads
> Production starts when a repeated gesture can be timed, observed and reproduced.

## Tooling around the board

Compute Module is designed to disappear inside somebody else’s product, and Raspberry Pi has long positioned the family around commercial and industrial integration.[5](https://www.raspberrypi.com/news/compute-module-5-on-sale-now/) The Programming Jig exposes the less photogenic half of that promise. Once a module has been selected for a product, somebody has to decide how every unit receives software, how its security state is created, how completion is signalled and how a returned board will be identified later.

None of those decisions improves CPU performance, yet together they determine whether the hundredth unit can be treated like the first. The prototype-to-production transition often hides in exactly this surrounding layer of fixtures, interlocks, logs and serial numbers, where repeated human choices are gradually converted into a process that can remember what it did.

## References

1. [Raspberry Pi, Compute Module 5 Programming Jig](https://www.raspberrypi.com/ew-programming-jig/)
2. [Raspberry Pi, rpi-sb-provisioner](https://github.com/raspberrypi/rpi-sb-provisioner)
3. [Raspberry Pi, rpi-sb-provisioner architecture](https://github.com/raspberrypi/rpi-sb-provisioner/blob/main/docs/architecture.md)
4. [Raspberry Pi Documentation, Compute Module hardware](https://www.raspberrypi.com/documentation/computers/compute-module.html)
5. [Raspberry Pi, Compute Module 5 on sale now](https://www.raspberrypi.com/news/compute-module-5-on-sale-now/)