Raspberry Pi Bootloader and EEPROM Configuration for OpenClaw Agents

The Raspberry Pi 5 boots about 21% faster from an NVMe SSD than from a microSD card, cutting startup from roughly 21 seconds to under 17 seconds according to benchmarks from Tom's Hardware and Pimoroni. That four-second difference sounds small until you multiply it across reboots, agent updates, and power recovery cycles in a fleet of 10 or 50 nodes.

But boot time is only part of the story. SD cards have a finite number of write cycles, and OpenClaw's SQLite database, log files, and skill caches generate constant small writes. The OpenClaw Raspberry Pi documentation explicitly warns that "SD cards are slow and wear out" and recommends switching to a USB SSD. Making that switch requires changing the bootloader configuration stored in the Pi's EEPROM, a one-time operation that most Raspberry Pi guides treat as an afterthought buried in forum threads.

The Raspberry Pi bootloader is firmware stored in the board's EEPROM that controls how the Pi starts up, including which storage device to boot from and in what order. On the Pi 4, Pi 5, and Compute Module variants, this firmware lives in an onboard SPI flash chip rather than on the SD card itself. That means the boot order persists across power cycles and storage swaps. You configure it once, and every subsequent boot follows the same sequence regardless of what happens to your OS drive.

This guide walks through the full bootloader lifecycle for an OpenClaw deployment: checking your current firmware version, updating to the latest stable release, configuring boot order for your chosen storage medium, and setting up network boot for fleet provisioning.

Before changing any boot settings, verify your current EEPROM firmware version. Outdated firmware can lack NVMe boot support entirely or contain bugs that cause intermittent boot failures.

SSH into your Pi and run:

sudo rpi-eeprom-update

The output shows your current bootloader version and the latest available version in your selected release channel. If the CURRENT timestamp is older than the LATEST timestamp, an update is available.

The Pi firmware ships in four release channels: critical (rarely updated, highest stability), stable (the default and recommended for production), beta (new features with less testing), and latest (bleeding edge). For OpenClaw agents that run unattended, stick with the stable channel. You can check which channel you're on by looking at the RELEASE line in the rpi-eeprom-update output.

To apply the latest stable firmware:

sudo rpi-eeprom-update -a
sudo reboot

The -a flag stages the update, which gets flashed during the next boot. After the reboot, run sudo rpi-eeprom-update again to confirm the CURRENT version matches LATEST.

If you need to install a specific firmware image, perhaps to roll back after a problematic update, use:

sudo rpi-eeprom-update -d -f /path/to/pieeprom.bin
sudo reboot

Viewing the Current Configuration

To see every bootloader setting currently stored in your EEPROM:

rpi-eeprom-config

This prints the configuration as key-value pairs. The one you care about most is BOOT_ORDER, which controls the boot sequence.

The BOOT_ORDER value is a hexadecimal string read right to left, where each nibble (single hex digit) represents one boot source. The Pi tries each source in sequence, falling through to the next if the current one fails.

Here are the boot mode codes defined by the Raspberry Pi Foundation:

• 0x0: SD card detect (try SD, then wait for card swap)
• 0x1: SD card (or eMMC on Compute Module)
• 0x2: Network boot via TFTP
• 0x3: RPIBOOT (USB recovery mode)
• 0x4: USB mass storage device
• 0x5: BCM USB 2.0 boot (not available on Pi 5)
• 0x6: NVMe SSD over PCIe
• 0x7: HTTP boot over Ethernet
• 0xe: Stop and display error pattern
• 0xf: Restart from the beginning of the boot order

The default BOOT_ORDER on most Pi 5 units ships as 0xf41, which means: try SD card first (1), then USB (4), then restart the sequence (f). NVMe is not in the default boot order, so a Pi 5 with an NVMe drive attached will ignore it unless you change the configuration.

Recommended Boot Orders for OpenClaw

For a single-node OpenClaw agent on NVMe with SD card fallback:

BOOT_ORDER=0xf416

Read right to left: NVMe first (6), SD card second (1), USB third (4), restart (f). If your NVMe drive fails or is removed, the Pi falls back to whatever bootable media it finds.

For a USB SSD deployment (the setup OpenClaw docs recommend):

BOOT_ORDER=0xf14

USB first (4), SD second (1), restart (f).

For a network-booted fleet node with no local storage:

BOOT_ORDER=0xf2

Network boot only (2), restart if it fails (f). This is the leanest configuration for PXE-provisioned clusters.

Applying the Change

Edit the EEPROM configuration directly:

sudo -E rpi-eeprom-config --edit

This opens the configuration in your default editor. Find the BOOT_ORDER line (or add it if missing), set your preferred value, save, and exit. The change takes effect on the next reboot.

Persistent workspace storage for your Raspberry Pi agent fleet

Keep agent outputs, logs, and handoff files in a workspace that survives reboots and SD card failures. 50 GB free, no credit card, MCP-ready.

Sign Up Free

Different boot media create different experiences for an always-on OpenClaw agent. The following comparison reflects real-world usage patterns: cold boot time, sustained random I/O (the pattern OpenClaw's SQLite database creates), and long-term reliability.

SD Card (Boot Mode 0x1)

Typical sequential read speeds sit around 90 MB/s on a quality A2-rated card, with writes around 30 MB/s. Cold boot takes roughly 21 seconds on a Pi 5. SD cards handle large sequential reads well enough, but random 4K writes, the pattern that agent databases and log rotation create, can drop to single-digit MB/s. Expect to replace the card every 12 to 18 months under constant agent workload.

USB SSD (Boot Mode 0x4)

A SATA SSD in a USB 3.0 enclosure delivers 300 to 400 MB/s sequential reads and better random I/O than SD cards. Boot time drops to roughly 18 seconds. The OpenClaw install documentation recommends this configuration as the practical upgrade path, and it requires no additional HAT hardware. Just plug the enclosure into a USB 3.0 port.

NVMe SSD (Boot Mode 0x6)

An NVMe drive on the Pi 5's PCIe interface reaches 400 to 900 MB/s sequential read depending on the drive and whether you enable PCIe Gen 3 in config.txt. Boot time drops to roughly 17 seconds. Random I/O is where NVMe pulls furthest ahead: tens of thousands of IOPS versus hundreds on SD. For OpenClaw agents that manage large skill caches or run frequent database queries, the difference is noticeable in response latency.

Network Boot (Boot Mode 0x2)

Network boot eliminates local storage entirely. The Pi downloads its kernel and root filesystem from a TFTP/NFS server on the local network. Boot time depends on network speed and server performance, but typically adds 5 to 15 seconds compared to local media. The tradeoff is centralized management: update the server image once and every node gets the change on next boot.

For a single OpenClaw node, USB SSD is the best cost-to-performance ratio. For fleets of five or more nodes, network boot pays for itself in reduced maintenance. NVMe makes sense when you need the fast possible cold-start recovery or your agent workload involves heavy file processing.

Running a fleet of OpenClaw agents on Raspberry Pi hardware creates a management challenge that network boot solves cleanly. Instead of flashing and maintaining individual SD cards or SSDs for each node, you maintain one server image and let every Pi pull its OS and OpenClaw installation from the network at boot time.

How PXE Boot Works on the Pi

When BOOT_ORDER includes mode 0x2 (network), the Pi's bootloader sends a DHCP request on the local network. A DHCP server responds with the IP address of a TFTP boot server. The bootloader downloads the kernel and boot files from the TFTP server, then the kernel mounts a root filesystem over NFS.

The Raspberry Pi bootloader uses each Pi's serial number as a directory prefix by default. This means the TFTP server can hold different boot configurations per device: the server looks for files in a directory named after the Pi's serial number first, then falls back to a shared default directory.

Setting Up the Boot Server

You need a machine on the same network running three services: DHCP (to direct Pis to the boot server), TFTP (to serve kernel and boot files), and NFS (to serve the root filesystem). Dnsmasq handles the first two in a single process.

Install dnsmasq and NFS on your server (a separate Pi, a Linux VM, or any Linux machine on the network):

sudo apt install dnsmasq nfs-kernel-server

Configure dnsmasq to serve DHCP with PXE boot options and TFTP from a directory like /tftpboot. Export the root filesystem directory via NFS. The Raspberry Pi Foundation's network boot tutorial covers the specific dnsmasq and NFS configuration in detail.

Configuring the Fleet Nodes

On each Pi that should network boot, update the EEPROM:

sudo -E rpi-eeprom-config --edit

Set the following values:

BOOT_ORDER=0xf21
TFTP_PREFIX=0
NET_BOOT_MAX_RETRIES=-1

BOOT_ORDER=0xf21 means: try SD first (1), then network (2), then restart (f). Starting with SD lets you bootstrap the EEPROM configuration before removing the SD card for pure network boot. Once confirmed working, you can change to BOOT_ORDER=0xf2 to skip local media entirely.

TFTP_PREFIX=0 tells the bootloader to look for a directory named after the Pi's serial number on the TFTP server. This enables per-node customization. Setting it to 2 uses the MAC address instead, which some network administrators prefer.

NET_BOOT_MAX_RETRIES=-1 sets infinite retries, so the Pi keeps trying to network boot if the server is temporarily unreachable. For production deployments, this prevents nodes from giving up after transient network hiccups.

Deploying OpenClaw Across the Fleet

With network boot running, deploying OpenClaw to the fleet is a single-server operation. Install OpenClaw in the NFS-shared root filesystem, configure the onboarding credentials, and every node picks up the installation on next boot. Updates follow the same pattern: update the server image, reboot the fleet.

For agents that need persistent local state (conversation history, skill caches, checkpoint files), configure OpenClaw to write to a Fast.io workspace rather than local disk. This decouples the agent's state from the boot media entirely. If a node fails, a replacement Pi boots from the network, connects to the same Fast.io workspace, and resumes where the previous node left off.

Regardless of which boot medium you choose, the boot drive should not be the only place your OpenClaw agent stores important data. SD cards fail. SSDs fill up. Network-booted nodes have no local persistence at all by default.

Local filesystems work fine for the OpenClaw runtime itself: the Node.js installation, the agent binary, and system logs. But the outputs your agent produces, files it generates, research it compiles, configurations it manages, belong somewhere durable and accessible.

Fast.io provides a persistent workspace layer that sits outside the Pi's boot drive entirely. Your agent writes files to a Fast.io workspace through the MCP server at mcp.fast.io, and those files survive reboots, SD card swaps, and full node replacements. The workspace also gives human operators a browser-based view of everything the agent has produced, with version history and audit trails.

For fleet deployments, centralized storage becomes even more valuable. Multiple OpenClaw agents across different Pis can read and write to the same workspace, coordinating through file locks to prevent conflicts. When an agent finishes a task, it can transfer ownership of the output to a human team member who reviews it through the Fast.io dashboard, no SSH or SCP required.

Alternatives for local persistence include mounting an external USB drive as a data partition (separate from the boot drive), running a local NFS mount back to a NAS, or using S3-compatible object storage. Each adds its own failure modes and maintenance overhead. Fast.io's free agent tier gives you 50 GB of storage, 5,000 credits per month, and 5 workspaces with no credit card and no expiration, which covers most single-node and small fleet deployments without any infrastructure to manage.

The practical setup: configure OpenClaw's output directory to point at a locally mounted Fast.io workspace, or have the agent use Fast.io's MCP tools directly for every file operation. The MCP documentation covers the available tools for file management, workspace operations, and Intelligence Mode queries.