🛠 Provisionnement en masse de l'eMMC et migration CM1 vers CM4
Objectifs
Industrialiser la programmation de l'eMMC des CM1 : écriture en masse de la même image via le mode rpiboot, vérification par empreinte, puis préparation de la migration mécanique/électrique CM1 -> CM4 quand le BCM2835 disparaît des approvisionnements. Le point de référence officiel est le white paper Raspberry Pi RP-003469-WP sur les Compute Modules : il documente les différences d'interface (USB, PCIe, double rangée de GPIO, alimentation) et l'enveloppe mécanique — la hauteur d'encombrement passe d'environ 30 mm à 31 mm, ce qui impacte capots et dissipateurs. Côté provisioning, le CM4 disposant d'une EEPROM, le flux change : rpiboot réveille l'EEPROM puis l'eMMC devient disque USB.
Matériel
- Un lot de CM1 (et CM4 pour l'étude de migration)
- Un hub USB industriel ou une station multi-ports (en provisioning, le hub alimenté est validé par essai : le mode programmeur du CM1 n'aime pas les hubs chainés)
- L'image maître + sha256sum, le white paper RP-003469-WP
Code complet
#!/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
Vérification attendue
Le script écrit N modules en parallèle et chaque empreinte de contrôle correspond au maître (à la zone variable près si la partition racine est redimensionnée au premier boot). Le passage en production est validé par un boot complet aléatoire sur un échantillon. Pour la migration, la checklist RP-003469-WP est parcourue point par point et le gabarit de hauteur 31 mm est validé en CAO avant toute refonte de carte.
Erreurs fréquentes
- Chaîner des hubs non alimentés pour multiplier les ports : le mode programmeur du CM1 est capricieux sur USB, valider chaque topologie en essai réel ou programmer un port à la fois.
- Valider le provisioning sans rebrancher : un module correctement écrit mais J4 oublié en 1-2 échoue au test final ; automatiser le contrôle de J4 ou le masquer mécaniquement.
- Croire l'image CM1 (ARMv6/Bullseye) réutilisable telle quelle sur CM4 : le CM4 est ARMv8/aarch64, l'image maître doit être rebâtie.
- Ignorer le passage 30 -> 31 mm : le capot du boîtier produit ne ferme plus en série.
- Négliger l'usure eMMC en écriture maître répétée : garder une image compressée et écrire en gros blocs (bs=4MiB), jamais octet par octet.
Autres tutoriels pour cette carte
- Flasher l'eMMC du CM1 avec rpiboot et le jumper J4
- Premier boot : Bullseye legacy, rails 3,3 V et ordre des alimentations
- Première LED sur GPIO17 : banques, courants et broches réservées
- Servo moteur sur PWM0 (GPIO18) : 50 Hz et 2,5 à 12,5 %
- BME280 sur I2C0 (GPIO2/3) : activer i2c_arm et lire l'ID 0x60
- Caméra officielle sur le connecteur FPC CSI du CM1
Exemples de code pour cette carte
clignotante.pyPythonbouton-gpio.pyPythoncapteur-i2c.shBashsurveillance-temperature.shBashcapteur-dht11.pyPythonservo-pwm-sysfs.shBash