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

Objetivos

El CM4 es el primer Compute Module con un bootloader en una EEPROM SPI integrada en el módulo. Consecuencias concretas: recovery.bin nunca se ejecuta desde la eMMC/SD, el servicio rpi-eeprom-update está desactivado por defecto, y cualquier modificación del orden de arranque debe realizarse mediante usbboot/rpiboot. Este tutorial: leer la versión del bootloader, cambiar BOOT_ORDER (0xf1 SD/eMMC, 0xf2 red, 0xf15 USB→eMMC, 0xf6 NVMe) a través del flujo de recuperación, y luego bloquear la escritura en la EEPROM.

Material

• 1 × CM4 (preferiblemente con eMMC) sobre una IO Board CM4
• Jumper en J2 (nRPI_BOOT), cable micro-USB entre J11 y el host
• 1 PC Linux host (un Pi 4 con RPiOS de 64 bits sirve); atención: el paquete rpiboot de Ubuntu ≤ 24.04 se conoce como defectuoso — compilarlo desde las fuentes
• Evitar hubs USB entre el módulo y el host (la enumeración a veces es imposible)

Código completo

#!/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)

Luego, una vez que el módulo haya reiniciado normalmente (J2 retirado):

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

Verificación esperada

vcgencmd bootloader_version muestra la fecha de la compilación regenerada; con BOOT_ORDER=0xf15, conectar una memoria USB arrancable hace que el módulo inicie desde ella con respaldo en eMMC. El registro del arranque (uart o journalctl -b) registra el orden de arranque utilizado.

Errores frecuentes

• Confiar en rpi-eeprom-update: desactivado por defecto en los Compute Modules (la eMMC no es extraíble); el modo self-update existe pero no es atómico — un corte de corriente durante la actualización puede corromper la EEPROM.
• Olvidar el jumper J2 durante la escritura, o dejarlo puesto después: en el primer caso rpiboot no detecta nada, en el segundo el módulo no reinicia normalmente.
• EEPROM_nWP mantenido en nivel bajo (protección de hardware activa): la escritura falla silenciosamente o es rechazada.
• rpiboot de distribución defectuoso: en Ubuntu ≤ 24.04, compilar usbboot desde las fuentes, y conectar directamente (sin hub).