🛠 Boot sans EEPROM : fallback USB et bootcode.bin sur eMMC

Objectives

Understand and leverage the CM1 boot chain, which lacks a boot EEPROM. The BCM2835 attempts to read from an SD card or eMMC depending on the state of the EMMC_DISABLE_N pin; on the eMMC side, the probe fails after approximately 2 seconds if no valid media is present, after which the module falls back to USB device mode (the mode exploited by rpiboot). Practical consequence: the boot firmware (bootcode.bin, then start.elf and config.txt) resides on the first FAT partition of the eMMC, and placing a recent bootcode.bin there can trigger a full firmware update. This is the recovery lever for a CM1 with obsolete or corrupted firmware.

Hardware

• A Compute Module 1 (eMMC programmable via rpiboot)
• Access to the eMMC FAT partition (via programmer mode or mounted under Linux)
• A recent firmware image (raspberry pi-firmware repository or Raspbian image)

Complete code

# 1. Passer en mode programmeur (J4 en 1-2) et monter la partition FAT
sudo rpiboot -d /usr/lib/rpiboot/usb &
sleep 5
sudo mount /dev/sdb1 /mnt

# 2. Placer un bootcode.bin récent + config.txt minimal
sudo cp bootcode.bin start.elf fixup.dat config.txt /mnt/
sync && sudo umount /mnt

# 3. J4 en 2-3 : le BCM2835 sonde l'eMMC (~2 s de timeout max),
#    trouve le bootcode.bin, enchaîne sur start.elf puis kernel.img

# 4. Si l'eMMC est vide/illisible : timeout écoulé, le module
#    réapparaît en périphérique USB sur le PC -> rpiboot
lsusb | grep -i '0a5c:2711\|Broadcom'

Expected verification

With a valid bootcode.bin on the eMMC FAT partition, the module boots normally (LED, serial console). With the eMMC wiped (sudo dd if=/dev/zero of=/dev/sdb bs=1M count=64), the probe times out in ~2 s and the module reappears on the PC's USB bus, proving the fallback. Pulling the EMMC_DISABLE_N pin to the active level masks the eMMC and forces this same USB path — useful on custom boards for a hardware recovery mode.

Common errors

• Formatting the eMMC FAT partition as exFAT or NTFS: the first boot stage only reads FAT; the module falls back to USB.
• Confusing this with the EEPROM on RPi 3/4/5: here, rpiboot -e and OTP rewriting are meaningless; everything happens on the FAT partition.
• Relying on the eMMC timeout to detect an absent card in a product: ~2 s of startup latency, which must be included in the boot budget.
• Leaving J4 in position 1-2 after intervention: the module remains in USB disk mode, and the eMMC firmware is never read.
• Writing bootcode.bin to the ext4 root partition instead of the FAT partition: nothing changes, the module does not see it.