🛠 Flasher l'eMMC du CM1 avec rpiboot et le jumper J4

Objectives

Program the eMMC chip of a blank or reprogrammable Compute Module 1. The CM1 has no boot EEPROM: by placing jumper J4 on pins 1-2, the module presents itself to the PC as a USB mass storage device (rpiboot/OTP mode) and dd writes directly to the eMMC. J4 is then moved back to 2-3 for normal boot. Known pitfall: USB enumeration in programmer mode is finicky; a direct connection is required, without a hub.

Hardware

• A Compute Module 1 with its carrier board (IO Board preferred)
• Jumper J4 (pins 1-2 = programmer mode, 2-3 = normal boot)
• A USB cable to the device port of the CM1's USB connector
• rpiboot (utility from the libusb/raspberrypi/usbboot repository)

Complete code

# 1. J4 sur 1-2, alimenter, brancher l'USB direct (PAS de hub)
sudo rpiboot -d /usr/lib/rpiboot/usb   # attend puis énumère l'eMMC

# 2. Le module apparaît comme disque (ex. /dev/sdb) : vérifier !
lsblk

# 3. Écrire l'image (gros blocs = rapide)
sudo dd if=2023-05-03-raspios-bullseye-armhf.img of=/dev/sdb bs=4MiB status=progress oflag=sync
sync

# 4. J4 retour sur 2-3, débrancher, rebrancher : boot normal

Expected verification

After rpiboot, a new disk the size of the eMMC (typically 4 GB) appears in lsblk. The dd command completes without errors; with J4 moved back to 2-3, the green LED on the IO Board blinks and the serial boot log displays the kernel. On a completely blank CM1, this is the only method: there is no EEPROM to revive.

Common errors

• Using a USB hub or a front-panel port: programmer mode enumeration fails silently, and rpiboot waits indefinitely. Connect directly to the host controller.
• Forgetting to move J4 back to 2-3: the module remains in USB disk mode, leading to a false diagnosis of a corrupted boot.
• Writing to the wrong disk with dd: check the size in lsblk before writing.
• Removing power during dd: results in a partially written eMMC; restart from step 1.
• Looking for an EEPROM with rpiboot -e: the CM1 does not have one, so this option has no effect; fallback behavior is handled elsewhere (see the tutorial on booting without an EEPROM).