🛠 Provisionnement en masse de l'eMMC et migration CM1 vers CM4

Objectives

Industrialize eMMC programming for CM1: mass writing of the same image via rpiboot mode, verification by checksum, and preparation for mechanical/electrical migration from CM1 to CM4 when the BCM2835 disappears from supply chains. The official reference point is the Raspberry Pi white paper RP-003469-WP on Compute Modules: it documents interface differences (USB, PCIe, dual-row GPIO, power supply) and the mechanical envelope — the height profile changes from approximately 30 mm to 31 mm, impacting enclosures and heatsinks. On the provisioning side, since the CM4 has an EEPROM, the workflow changes: rpiboot wakes up the EEPROM, then the eMMC becomes a USB disk.

Hardware

• A batch of CM1 (and CM4 for the migration study)
• An industrial USB hub or a multi-port station (in provisioning, a powered hub is validated by testing: the CM1 programmer mode does not like chained hubs)
• The master image + sha256sum, the RP-003469-WP white paper

Complete Code

#!/bin/bash
# provisioning.sh - à lancer un module à la fois par port contrôlé
IMG=master-bullseye-armhf.img
for dev in /dev/sdb /dev/sdc /dev/sdd; do
  sudo dd if=$IMG of=$dev bs=4MiB status=none oflag=sync &
done
wait; sync

# Vérification : comparer les premiers 512 Mo + empreinte fichier maître
sha256sum $IMG
sudo dd if=/dev/sdb bs=1M count=512 status=none | sha256sum

# Migration CM1 -> CM4 (synthèse du RP-003469-WP)
- EEPROM de boot présente sur CM4 -> flux rpiboot différent
- USB : device OTG côté CM4, hôte possible via PCIe
- GPIO : connecteurs différents, revoir la carte porteuse
- Hauteur : ~30 mm -> ~31 mm, vérifier capot/ventirad
- Alimentation : exigences VDD_IO et VBAT redéfinies

Expected Verification

The script writes N modules in parallel, and each checksum matches the master (except for the variable area if the root partition is resized on first boot). Production release is validated by a random full boot on a sample. For the migration, the RP-003469-WP checklist is reviewed point by point, and the 31 mm height template is validated in CAD before any board redesign.

Common Errors

• Chaining unpowered hubs to multiply ports: the CM1 programmer mode is finicky over USB; validate each topology with real testing or program one port at a time.
• Validating provisioning without unplugging/replugging: a correctly written module but with J4 left in 1-2 fails the final test; automate the J4 check or mechanically mask it.
• Believing the CM1 image (ARMv6/Bullseye) is reusable as-is on CM4: the CM4 is ARMv8/aarch64, the master image must be rebuilt.
• Ignoring the 30 -> 31 mm change: the product enclosure lid no longer closes in series production.
• Neglecting eMMC wear from repeated master writing: keep a compressed image and write in large blocks (bs=4MiB), never byte by byte.