Booting a Raspberry Pi 4 from a USB SSD: EEPROM, Boot Order and Speed

A microSD card is convenient but it is the weakest part of a Pi 4 system. Cards are slow at the small random writes that databases, Docker and logging produce, and cheap cards wear out or corrupt after power cuts. The Pi 4 has true USB 3.0 ports and a bootloader stored in an on-board EEPROM, which means it can boot directly from a USB SSD with no SD card inserted at all.

This guide explains how the Pi 4 boot process decides where to load the OS from, updates the bootloader, sets the boot order, moves an existing installation to an SSD, and shows how to measure the improvement and fix the most common USB adapter problem.

How the Pi 4 Boots

Unlike the Pi 3, whose boot code lived in the SoC's ROM, the Pi 4 keeps its second-stage bootloader in an SPI EEPROM chip on the board. That bootloader reads a setting called BOOT_ORDER, a hexadecimal number read from right to left, one digit per boot device to try. It can be updated from Linux, which is how USB and network boot support were added after launch.

Digit	Boot mode
1	microSD card
2	Network boot
4	USB mass storage
6	NVMe (CM4 and Pi 5, not applicable to the Pi 4 Model B)
e	Stop and show an error screen
f	Restart and try the list again

For example BOOT_ORDER=0xf41 means try the SD card (1), then USB (4), then restart and repeat (f). With that setting, a board with no SD card inserted boots from the SSD, and you can still recover by inserting an SD card.

Choosing the Drive and Adapter

Item	Good choice	Avoid
Drive	2.5 inch SATA SSD or M.2 SATA SSD	Spinning hard disks without their own power
Enclosure or adapter	USB 3.0 to SATA with a UASP-capable bridge chip	Unknown no-name adapters with poor Linux reports
Port	Blue USB 3.0 port	Black USB 2.0 ports, which are much slower
Power	Official 5.1 V 3 A supply	Weak chargers; SSDs draw current spikes on writes

M.2 NVMe drives in USB enclosures also work as USB mass storage, but they draw more power and may need a powered hub on a Pi 4.

Step-by-Step: Moving to the SSD

1. Update the bootloader EEPROM

Boot from your existing SD card and run the script below. It updates packages, checks the bootloader version, applies any pending EEPROM update, and shows the current configuration.

prepare_usb_boot.sh - update EEPROM and set SD then USB boot order

#!/bin/bash
# prepare_usb_boot.sh - run on a Pi 4 booted from microSD
set -e

# Make sure the rpi-eeprom package and firmware are current
sudo apt update
sudo apt full-upgrade -y

# Show current bootloader version and whether an update is available
sudo rpi-eeprom-update

# Stage the latest bootloader; it is flashed on the next reboot
sudo rpi-eeprom-update -a

# Show the current bootloader configuration (look for BOOT_ORDER)
rpi-eeprom-config

# Set boot order to: SD card, then USB, then retry (0xf41)
# raspi-config's non-interactive mode writes the EEPROM config for us.
# B1 = SD card boot first, B2 = USB boot first. We pick B1 so a
# rescue SD card always wins when it is inserted.
sudo raspi-config nonint do_boot_order B1

echo 'Reboot now with: sudo reboot'

You can also run sudo rpi-eeprom-config --edit to open the configuration in a text editor and set BOOT_ORDER=0xf41 by hand. Saving the file stages it for the next reboot.

2. Copy the system to the SSD

Connect the SSD to a blue USB 3.0 port.
On the desktop, open Accessories, SD Card Copier. Set the source to the internal SD card and the destination to the USB drive, tick New Partition UUIDs, and start the copy.
On a Lite system, use Raspberry Pi Imager on your PC to write a fresh image directly to the SSD instead, then copy your project files across.
Shut down with sudo poweroff, remove the microSD card, and power on. The board should boot from the SSD.

3. Confirm you booted from USB

$ findmnt /
TARGET SOURCE    FSTYPE OPTIONS
/      /dev/sda2 ext4   rw,noatime

$ lsusb -t | grep -i driver
    |__ Port 2: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M

/dev/sda2 as the root device confirms USB boot (an SD card shows as /dev/mmcblk0p2). Driver=uas at 5000M means the drive runs over USB 3.0 using the faster UASP protocol.

Measuring the Improvement

Install fio and run the same 4K random-write test on the SD card system and then on the SSD system. Random 4K writes are what slow down package installs and databases, so they show the difference better than a large file copy.

sudo apt install -y fio
fio --name=randwrite --rw=randwrite --bs=4k --size=256M \
    --direct=1 --ioengine=libaio --runtime=30 --time_based \
    --filename=$HOME/fio.test
rm $HOME/fio.test

Compare the IOPS figure in each report. On typical hardware the SSD is many times faster at this test, but the exact numbers depend heavily on your card, drive and adapter, so record your own results rather than relying on published ones.

Troubleshooting

Rainbow screen or no boot without the SD card: the EEPROM was not updated or BOOT_ORDER does not include 4. Boot from SD and recheck rpi-eeprom-config.
Drive disconnects or I/O errors under load: some USB-SATA bridges misbehave with UASP. Find the adapter's ID with lsusb (for example 152d:0578), then add usb-storage.quirks=152d:0578:u at the start of the single line in /boot/firmware/cmdline.txt. This falls back to the slower BOT protocol but is stable.
Under-voltage warnings after adding the SSD: the drive's current spikes exceed what the supply delivers. Use the official supply or a powered USB hub.
Both SD and SSD contain systems with the same IDs: always tick New Partition UUIDs in SD Card Copier, or the board may mount the wrong root partition.

Summary

The Pi 4's EEPROM bootloader makes SSD boot a configuration change, not a hardware hack. Update it with rpi-eeprom-update -a, set a BOOT_ORDER such as 0xf41, clone the system with SD Card Copier or Imager, and verify with findmnt / and lsusb -t. Use a UASP-capable adapter on a blue port, add a quirks entry only if your bridge chip is unstable, and benchmark with fio to see the gain for yourself.