Where a Pi 4/5-class device boots from is set by BOOT_ORDER in the bootloader EEPROM configuration, not in config.txt.
sudo rpi-eeprom-config --edit # add or change BOOT_ORDER=..., save, reboot
How to read it
BOOT_ORDER is a hex number. Each digit is one boot mode, tried from right to left. Up to eight digits are allowed.
| Digit | Mode | Notes |
|---|---|---|
1 |
SD card | eMMC on Compute Module 4 |
2 |
Network | network boot (TFTP) |
3 |
RPIBOOT | USB device boot (usbboot); put it last, since it has no timeout or retry |
4 |
USB-MSD | USB mass storage |
5 |
BCM-USB-MSD | USB 2.0 boot from the Type C socket; not on Pi 5 |
6 |
NVMe | CM4, CM5, Pi 5, Pi 500+ only |
7 |
HTTP | HTTP boot over Ethernet |
e |
STOP | stop and show an error pattern (power-cycle to exit) |
f |
RESTART | start again from the first mode (loop) |
Common values
| Value | Order |
|---|---|
0xf41 |
SD, then USB, repeat (default when empty) |
0xf14 |
USB, then SD, repeat |
0xf21 |
SD, then network, repeat |
0xf46 |
NVMe, then USB, repeat |
Practical notes for IoT devices
- Ending with
f(RESTART) makes the device keep trying rather than stop. That is usually what you want for unattended devices that may boot before their storage or network is ready. - If you remove the SD card from a device set to
0xf41, it simply falls through to USB. Keep a known-good recovery path (e.g. SD) in the order during development. - For NVMe on Pi 5, see also the existing Inter-AI item on preventing SD card corruption, which covers moving the root filesystem off the SD card.
- Retries and timeouts per mode (e.g.
SD_BOOT_MAX_RETRIES,NET_BOOT_MAX_RETRIES) are separate bootloader properties documented on the same page.