To successfully configure a Raspberry Pi 5 boot from USB, you must update the bootloader EEPROM BOOT_ORDER to 0xf416 (USB first, then SD), use a UAS-compatible USB 3.0 drive, and ensure your power supply negotiates a full 5V/5A (27W) USB-C Power Delivery handshake. Without the 27W PD handshake, the Pi 5's RP1 I/O chip restricts USB port current to 600mA, which will instantly brownout high-performance NVMe USB enclosures during the boot sequence.

Unlike the Pi 4, the Pi 5 features a dedicated RP1 southbridge chip that handles USB and PCIe. This architectural shift means USB mass storage boot is faster but strictly gated by power negotiation and specific drive controller chipsets. Below is the exact hardware matrix, EEPROM configuration, and debugging framework you need to get your system running reliably.

USB Boot EEPROM Parameters & Controller Compatibility

The bootloader relies on hex codes to determine the boot sequence. Furthermore, not all USB NVMe/SATA bridge chips play nicely with the Linux UAS (USB Attached SCSI) driver out of the box. Use this table to verify your hardware before flashing.

Parameter / Chipset Hex Code / Model Behavior on Pi 5 Action Required
BOOT_ORDER (USB First) 0xf416 Tries USB-MSD, falls back to SD card, then restarts. Set via rpi-eeprom-config.
BOOT_ORDER (USB Only) 0xf146 Tries USB, then SD. Skips network/other peripherals. Best for headless kiosk builds.
ASMedia ASM2362 NVMe Bridge Native UAS support, high throughput (~400MB/s). None. Plug and play.
Realtek RTL9210B NVMe/SATA Bridge Generally stable, but early firmwares drop UAS. Update enclosure firmware if hanging.
JMicron JMS583 NVMe Bridge Notorious for UAS driver crashes on boot. Must add usb-storage.quirks to cmdline.txt.
Max USB Current (5A PD) 1600mA (Total) RP1 chip allows full current to USB ports. Requires official 27W Pi 5 PSU.
Max USB Current (3A PD) 600mA (Total) RP1 restricts current to protect the board. Will fail to boot NVMe drives. Upgrade PSU.

Hardware Requirements & Pin Mapping

To build and debug this setup, you need specific hardware variants. Generic USB enclosures and phone chargers will cause intermittent boot failures.

Parts List:
  • Board: Raspberry Pi 5 8GB (Model SC11108)
  • Power: Official Raspberry Pi 27W USB-C PD Power Supply (White/Black)
  • Storage: Sabrent USB 3.2 NVMe Enclosure (ASMedia ASM2362 chipset) + WD Blue SN580 500GB NVMe
  • Debug Sensor: Adafruit INA219 High Side DC Current Sensor Breakout (I2C)
  • OS: Raspberry Pi OS (Bookworm) 64-bit

To debug power brownouts—the number one cause of USB boot failure—we wire an INA219 current sensor to the Pi 5's I2C bus to monitor the 5V rail during the boot sequence.

INA219 Pin Pi 5 GPIO Header (40-pin) Function
VCCPin 1 (3.3V)Logic Power
GNDPin 6 (GND)Common Ground
SDAPin 3 (GPIO 2 / SDA1)I2C Data
SCLPin 5 (GPIO 3 / SCL1)I2C Clock

Note: The INA219 Vin+ and Vin- pads must be spliced inline with your USB-C power delivery line to measure the actual current draw of the board and USB peripherals.

Step-by-Step: Flashing the EEPROM for USB Boot

The Pi 5 bootloader is stored in an onboard SPI flash chip. You must update it to prioritize USB mass storage (USB-MSD).

  1. Boot from SD Card: Flash Raspberry Pi OS (Bookworm) to a microSD card using the Raspberry Pi Imager. Insert it into the Pi 5 and boot to the desktop or SSH in.
  2. Update the EEPROM Firmware: Ensure you are on the latest bootloader release.
    sudo apt update && sudo apt full-upgrade -y
    sudo rpi-eeprom-update -a
  3. Edit the Boot Configuration: Open the EEPROM config in the nano editor.
    sudo rpi-eeprom-config --edit
  4. Set the Boot Order: Locate the BOOT_ORDER line. Change it to 0xf416.
    BOOT_ORDER=0xf416

    Breakdown: 6 = USB-MSD, 1 = SD Card, 4 = Restart loop, f = Boot from first available.

  5. Save and Reboot: Press Ctrl+O, Enter, then Ctrl+X to save. Reboot the Pi.
    sudo reboot
  6. Clone the OS: Once rebooted, open the Raspberry Pi Imager app on the Pi, select your USB NVMe drive as the target, and clone the active SD card OS directly to the USB drive. Shutdown, remove the SD card, and power on.

Debugging Boot Failures: The "Timeout" Error

If your Pi 5 fails to boot from the USB drive, you will see a blinking green LED pattern. If you connect a USB-to-TTL serial cable to GPIO 14 (TXD) and GPIO 15 (RXD) at 115200 baud, the bootloader will output the exact failure reason.

The most common exact error string is:

Boot mode: USB-MSD (06) order 01
USB-MSD: timeout waiting for device
Boot failed: code 0x00040006

The First Three Things to Check

When you see USB-MSD: timeout waiting for device, do not immediately assume the drive is dead. Follow this ranked diagnostic path:

  1. Check the PD Handshake (Power Brownout): NVMe drives can pull 2.5A+ during spin-up. If your power supply is a standard 5V/3A phone charger, the Pi 5's RP1 chip detects the lack of a 5A PD handshake and hard-limits the USB ports to 600mA. The drive fails to initialize, causing the timeout. Fix: Use the official 27W Pi 5 power supply.
  2. Disable UAS for JMicron Controllers: If your enclosure uses a JMicron JMS583 chip, the Linux UAS driver will crash during the bootloader handoff. Fix: Boot via SD, mount the USB drive's boot partition, and edit cmdline.txt. Add usb-storage.quirks=152d:0583:u (replace 152d:0583 with your drive's lsusb ID) to force standard BOT (Bulk-Only Transport) mode.
  3. Verify USB 3.0 Cable Integrity: The Pi 5 is highly sensitive to signal degradation on the USB-C to USB-A/C adapter. If the cable lacks proper shielding, the RP1 chip will silently fall back to USB 2.0 speeds, which alters the enumeration timing and can trigger a bootloader timeout. Fix: Use the short, thick cable included with the NVMe enclosure.

Python Power Monitor Script (Pi 5 Native)

To prove whether your power supply is browning out during the USB boot sequence, run this Python script on your Pi 5 (via SSH) while triggering a reboot, or run it continuously to log voltage sags. This code targets the Raspberry Pi 5 8GB running Bookworm, utilizing the smbus2 library to read the INA219 sensor on I2C Bus 1.

#!/usr/bin/env python3
"""
Pi 5 USB Boot Power Monitor
Target: Raspberry Pi 5 8GB (RP1 Silicon)
Sensor: INA219 on I2C Bus 1 (GPIO 2/SDA, GPIO 3/SCL)
"""

import smbus2
import time
import sys
import os

# I2C Bus 1 is the default user-space bus on the 40-pin header
INA219_ADDRESS = 0x40
BUS = smbus2.SMBus(1)

# INA219 Registers
REG_VOLTAGE = 0x02
REG_CURRENT = 0x01

def check_i2c_connection():
    """Verify the sensor is present on the bus."""
    try:
        BUS.read_byte_data(INA219_ADDRESS, 0x00)
        return True
    except OSError:
        return False

def read_bus_voltage():
    """Reads the Bus Voltage register and converts to Volts."""
    try:
        raw = BUS.read_word_data(INA219_ADDRESS, REG_VOLTAGE)
        # Swap endianness (RP1 I2C returns little-endian word)
        val = ((raw >> 8) | (raw << 8)) & 0xFFFF
        # Shift right by 3 and multiply by 1.25mV per bit
        return (val >> 3) * 0.00125
    except OSError as e:
        print(f"[ERROR] I2C Read Failure: {e}. Check SDA/SCL on Pins 3 & 5.")
        sys.exit(1)

def read_current_ma():
    """Reads the Current register (requires prior calibration, assumes 0.1 ohm shunt)."""
    try:
        raw = BUS.read_word_data(INA219_ADDRESS, REG_CURRENT)
        val = ((raw >> 8) | (raw << 8)) & 0xFFFF
        if val > 32767:
            val -= 65536
        return val * 0.1 # mA per bit for standard 0.1 ohm shunt
    except OSError:
        return 0.0

if __name__ == "__main__":
    if not check_i2c_connection():
        print("FATAL: INA219 not found at 0x40. Verify wiring and enable I2C in raspi-config.")
        sys.exit(1)

    print("Monitoring Pi 5 5V Rail... Press Ctrl+C to stop.")
    print(f"{'Timestamp':<15} | {'Voltage (V)':<12} | {'Current (mA)':<12} | Status")
    print("-" * 60)

    try:
        while True:
            v = read_bus_voltage()
            ma = read_current_ma()
            status = "NOMINAL"
            
            # The Pi 5 brownout threshold is typically around 4.65V
            if v < 4.65:
                status = "WARNING: BROWNOUT DETECTED"
            elif ma > 4500:
                status = "WARNING: OVERCURRENT"
                
            print(f"{time.strftime('%H:%M:%S'):<15} | {v:<12.3f} | {ma:<12.1f} | {status}")
            time.sleep(0.5)
            
    except KeyboardInterrupt:
        print("\nMonitoring stopped.")
        sys.exit(0)
Debugging Tip: If you see the voltage drop below 4.65V exactly when the bootloader attempts to mount the USB-MSD, your power supply is failing the transient load test. The Pi 5 PMIC will trigger a hardware reset to protect the silicon, resulting in a boot loop.

Extending and Simplifying the Build

Once you have a stable USB boot environment, you have two distinct paths forward depending on your project goals.

How to Simplify: Switch to PCIe M.2 HAT+

If your primary goal is simply "faster storage" and you don't strictly need the drive to be externally removable, drop the USB enclosure entirely. The Raspberry Pi 5 features an exposed PCIe 2.0 x1 connector. By using the official Raspberry Pi M.2 HAT+ (approx. $12), you bypass the USB controller stack entirely. This eliminates UAS driver quirks, removes USB protocol overhead, and yields native NVMe speeds (up to 800MB/s). You will need to change the EEPROM BOOT_ORDER to 0xf416 (where '1' represents PCIe/NVMe boot in newer EEPROM revisions) or use the dedicated PCIE_PROBE=1 flag in config.txt.

How to Extend: Network Boot Fallback & Watchdogs

For remote deployments (e.g., digital signage or agricultural sensors), a dead USB drive means a dead node. Extend your EEPROM configuration to include a PXE network boot fallback. Change your BOOT_ORDER to 0xf4162 (the '2' adds network boot). If the USB drive times out, the Pi 5 will automatically request a boot image from your TFTP server.

Additionally, enable the hardware watchdog in /boot/firmware/config.txt by adding dtparam=watchdog=on, and install the watchdog daemon in user-space. If the USB drive experiences a file system lockup post-boot, the watchdog will force a clean hardware reset, allowing the EEPROM to re-attempt the boot sequence.

For deeper technical specifications on the RP1 southbridge and EEPROM flags, consult the official Raspberry Pi 5 documentation and the rpi-eeprom GitHub repository.