🛠 Bootloader EEPROM du CM4 : maîtriser BOOT_ORDER via usbboot

Objectifs

Le CM4 est le premier Compute Module avec un bootloader dans une EEPROM SPI embarquée sur le module. Conséquences concrètes : recovery.bin n'est jamais exécuté depuis l'eMMC/SD, le service rpi-eeprom-update est désactivé par défaut, et toute modification de l'ordre de boot passe par usbboot/rpiboot. Ce tuto : lire la version du bootloader, changer BOOT_ORDER (0xf1 SD/eMMC, 0xf2 réseau, 0xf15 USB→eMMC, 0xf6 NVMe) via le flux recovery, puis verrouiller l'EEPROM en écriture.

Matériel

• 1 × CM4 (eMMC de préférence) sur IO Board CM4
• Jumper sur J2 (nRPI_BOOT), câble micro-USB entre J11 et l'hôte
• 1 PC Linux hôte (un Pi 4 sous RPiOS 64 bits convient) ; attention : le paquet rpiboot d'Ubuntu ≤ 24.04 est connu cassé — le compiler depuis les sources
• Éviter les hubs USB entre le module et l'hôte (énumération parfois impossible)

Code complet

#!/usr/bin/env bash
# bootorder-cm4.sh — reprogrammer BOOT_ORDER de l'EEPROM d'un CM4 (flux officiel).
set -euo pipefail
git clone --depth 1 https://github.com/raspberrypi/usbboot && cd usbboot
cd recovery
cat > boot.conf <<'EOF'
[All]
BOOT_ORDER=0xf15
EOF
./update-pieeprom.sh                     # régénère pieeprom.bin depuis boot.conf
cd .. && sudo ./rpiboot -d recovery      # écrit l'EEPROM (J2 posé, EEPROM_nWP non maintenu bas)

Puis, une fois le module redémarré normalement (J2 retiré) :

vcgencmd bootloader_version | head -1    # la date doit correspondre au build fraîchement écrit
grep -i boot /var/log/bootstrap.log 2>/dev/null || true
# Durcissement production : protection en écriture
echo 'eeprom_write_protect=1' | sudo tee -a /boot/firmware/config.txt

Vérification attendue

vcgencmd bootloader_version affiche la date du build régénéré ; avec BOOT_ORDER=0xf15, brancher une clé USB bootable fait démarrer le module dessus avec repli eMMC. Le log du boot (uart ou journalctl -b) trace l'ordre de boot utilisé.

Erreurs fréquentes

• Compter sur rpi-eeprom-update : désactivé par défaut sur Compute Modules (l'eMMC n'est pas amovible) ; le mode self-update existe mais n'est pas atomique — une coupure de courant pendant la mise à jour peut corrompre l'EEPROM.
• Oublier le jumper J2 pendant l'écriture, ou le laisser après : dans le premier cas rpiboot ne voit rien, dans le second le module ne redémarre pas normalement.
• EEPROM_nWP maintenu bas (protection matérielle active) : l'écriture échoue silencieusement ou est refusée.
• rpiboot de distribution cassé : sur Ubuntu ≤ 24.04, compiler usbboot depuis les sources, et brancher en direct (pas de hub).