NVMe Storage
NVMe Storage
Partition, format, mount, and optionally boot from the M.2 NVMe SSD slot on the Sixfab Edge AI Expansion Board. The slot is routed through an on-board USB 3.2 Gen 1 hub and a Realtek RTL9210B-CG USB-to-NVMe bridge, so the operating system sees a standard USB Mass Storage device, with no extra drivers required.
The NVMe slot is USB-attached, not native PCIe.
The M.2 M-Key socket sits behind an on-board USB 3.2 Gen 1 (5 Gbps) hub and a Realtek
RTL9210B-CG USB-to-NVMe bridge, so Raspberry Pi 5 enumerates the SSD as a
USB Mass Storage device at /dev/sda, not as a native NVMe block device.
No additional drivers are needed beyond Raspberry Pi OS. Sequential read sits in the
380–440 MB/s range and write in the 350–410 MB/s
range, capped by the 5 Gbps USB bus rather than the SSD itself. Setup is the standard
fdisk → mkfs.ext4 → fstab-with-UUID flow used
for any USB drive on Raspberry Pi OS.
How the slot is wired
The M.2 slot labelled M.2-SSD on the Edge AI Expansion Board accepts a
standard NVMe (PCIe) SSD, but the path from the SSD to the Raspberry Pi 5 is
not the Pi 5's PCIe link. That link is reserved end-to-end for the
DEEPX DX-M1 AI accelerator. The NVMe slot is instead routed through an on-board
Realtek RTL9210B-CG USB-to-NVMe bridge chip, then into the board's
internal USB 3.2 Gen 1 (5 Gbps) hub, then upstream to the Raspberry Pi 5 over the USB
Bridge PCBA, a small connector board that occupies one of the Pi 5's two blue
USB 3.0 ports.
The practical consequence: from Raspberry Pi OS' point of view, the SSD looks like any
other external USB Mass Storage device. lsblk shows it as
/dev/sda, lsusb lists the bridge as
0bda:9210 Realtek Semiconductor Corp. RTL9210 NVMe Bridge, and tools like
nvme list will not see it. Use the USB-storage tooling
(lsblk, fdisk, mount, fstab), not
the native-NVMe tooling. UASP is supported by the bridge, so the throughput is the
full USB 3.2 Gen 1 ceiling, not a slower USB Mass Storage profile.
Raspberry Pi 5 exposes a single PCIe Gen 2/Gen 3 x1 lane through its dedicated PCIe FFC connector. The Edge AI Expansion Board commits that entire lane to the DX-M1 AI accelerator over a 40 mm PCIe FFC cable, so AI inference traffic never competes with storage traffic. Putting the NVMe slot on the internal USB 3.2 Gen 1 hub keeps the SSD fast (≈ 400 MB/s in practice) while leaving the PCIe link exclusively for the NPU.
Throughput envelope
Maximum throughput is set by the 5 Gbps USB 3.2 Gen 1 bus and the 8b/10b encoding overhead that goes with it, not by the SSD's underlying PCIe capability. A high-end PCIe Gen 4 SSD will not run any faster in this slot than a mid-range PCIe Gen 3 model. The figures below are the measured envelope as documented by Sixfab; treat them as the ceiling for any SSD installed in this slot.
For an end-to-end concurrency observation (AI + NVMe + cellular running together with no measurable AI throughput hit), see Concurrent operation.
Compatible SSDs
The slot accepts standard M.2 M-Key NVMe (PCIe) SSDs in 2230, 2242, 2260, and 2280 lengths. M.2 SATA drives are not supported and will not enumerate even though they share the M.2 form factor. B+M-keyed NVMe drives are fine; pure B-keyed drives are not NVMe and will not work.
| SSD class | Compatibility | Notes |
|---|---|---|
| M.2 M-Key NVMe (PCIe) | Supported | Standard configuration. 2230, 2242, 2260, and 2280 lengths all fit; up to 2 TB validated. |
| M.2 B+M-Key NVMe | Supported | Mechanically and electrically equivalent to M-Key NVMe in this slot. |
| M.2 SATA SSD | Not supported | SATA-only M.2 drives will not enumerate. The slot is NVMe-only via the USB-to-NVMe bridge. |
| Older / high-end power-hungry SSDs | Use with care | Some firmware or power profiles can trigger instability under burst loads. Pair with a USB-C PD supply that meets the 27 W minimum (45 W recommended). |
Validated SSDs
Sixfab's documented validation set is the Raspberry Pi 256 GB and 512 GB NVMe SSDs. These are the recommended drives for the simplest path to a working setup. Any well-known modern NVMe SSD in the M.2 form factor should also work; the validation list is what has been tested by Sixfab, not the exclusion list.
Certain high-end or older NVMe SSDs draw heavy current bursts that a marginal USB-C PD supply can struggle to deliver, causing under-voltage warnings or intermittent disconnects that look like SSD failures. Always use a high-quality USB-C PD supply rated at 27 W minimum; 45 W is recommended once the AI accelerator and cellular modem are also populated. If you see under-voltage warnings, the power supply is the first thing to replace, not the SSD.
Partition, format, and mount
This is the standard procedure for preparing a brand-new NVMe SSD on the Edge AI
Expansion Board as a secondary (non-boot) data drive. The flow is:
lsblk to confirm the device → fdisk to write a GPT partition
table → mkfs.ext4 to format → mount to a directory under /mnt
→ /etc/fstab with the partition UUID for automatic mounting at boot.
Partitioning and formatting destroys any existing data on the SSD. Before running
fdisk or mkfs, confirm that /dev/sda is the
Edge AI Expansion Board's NVMe SSD and not a different USB drive you have plugged
into the Raspberry Pi 5. lsblk and lsusb together
confirm which device is which: the NVMe bridge always shows up as
0bda:9210 Realtek Semiconductor Corp. RTL9210 NVMe Bridge in
lsusb.
Identify the device
Confirm that the SSD is enumerated as /dev/sda and check that the
RTL9210 bridge is visible in lsusb. If the SSD does not appear,
stop here: re-seat the M.2 module (30° insertion, M2 6 mm flat-head screw,
finger-tight) and the USB Bridge PCBA before running anything else.
# 1. Block-device tree: the SSD should show as /dev/sda lsblk # 2. USB-side view: the RTL9210 NVMe Bridge should be listed lsusb
# lsblk (example with a 256 GB SSD, no partitions yet) NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 238.5G 0 disk mmcblk0 179:0 0 29.7G 0 disk ├─mmcblk0p1 179:1 0 512M 0 part /boot/firmware └─mmcblk0p2 179:2 0 29.2G 0 part / # lsusb Bus 002 Device 002: ID 0bda:9210 Realtek Semiconductor Corp. RTL9210 NVMe Bridge Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
/dev/sdb, /dev/sdc, …). Match the size and the
RTL9210 entry from lsusb to identify the correct disk before
partitioning. The UUID-based fstab entry in step 5 immunises the
mount against device-name reshuffling.
Write a GPT partition table
A new SSD has no usable partition layout. Use fdisk to write a
fresh GPT table and create a single primary partition that spans the entire
disk. GPT is the recommended layout for any drive larger than 2 TB and is the
default Sixfab documents for the Edge AI Expansion Board.
# Open fdisk on the NVMe SSD sudo fdisk /dev/sda # Inside the fdisk prompt, type each letter then press Enter: # g create a new empty GPT partition table # n add a new partition # press Enter to accept defaults (partition 1, full disk) # w write the table to disk and exit
After fdisk exits, run lsblk again. The SSD should now
have a child partition sda1 taking up the full disk:
# lsblk after fdisk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 238.5G 0 disk └─sda1 8:1 0 238.5G 0 part
Format the partition as ext4
ext4 is the recommended filesystem for a secondary data drive on Raspberry Pi OS:
stable, journaled, well-supported, and matches the rest of the system's tooling.
The format runs on the partition (sda1), not the whole disk
(sda).
# Format the new partition with ext4 sudo mkfs.ext4 /dev/sda1
mkfs.ext4 may ask to overwrite an existing filesystem; type
y to confirm only after you have re-verified that
/dev/sda1 is the correct device.
Create a mount point and mount
Mount the freshly formatted partition under a stable directory below
/mnt. /mnt/nvme is the convention used elsewhere in
Sixfab's documentation; the path is not magical, anything you pick can be used
consistently afterwards.
# 1. Make the mount point sudo mkdir -p /mnt/nvme # 2. Mount the partition there for the current boot sudo mount /dev/sda1 /mnt/nvme # 3. Hand ownership to the pi user so applications can write without sudo sudo chown -R pi:pi /mnt/nvme # 4. Confirm it's mounted and writable df -hT /mnt/nvme
Mount automatically at boot via /etc/fstab
The manual mount above survives until the next reboot. To bring the SSD up
automatically every boot, add it to /etc/fstab. Reference the
partition by its UUID, not by /dev/sda1: the
device name can shift if other USB drives are connected and the boot will fail
when it does.
# 1. Read the UUID of the partition sudo blkid /dev/sda1
/dev/sda1: UUID="a1b2c3d4-e5f6-7890-1234-567890abcdef" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="..."
Then edit /etc/fstab with sudo nano /etc/fstab and add
a single line, substituting the UUID printed by blkid:
# NVMe SSD on Edge AI Expansion Board (USB-attached via RTL9210B-CG) UUID=<your-uuid-here> /mnt/nvme ext4 defaults,nofail,x-systemd.device-timeout=10 0 2
Test the entry without rebooting:
# 1. Unmount the partition (if currently mounted from step 4) sudo umount /mnt/nvme # 2. Mount everything in fstab: should remount /mnt/nvme cleanly sudo mount -a # 3. Verify df -hT /mnt/nvme
nofail option means Raspberry Pi OS will continue to boot
even if the SSD is temporarily missing, which is important in field deployments where
you do not want a single hardware issue to leave the unit stuck at the boot
prompt. x-systemd.device-timeout=10 caps the wait at 10 seconds
on each boot.
Boot Raspberry Pi OS from NVMe
Booting Raspberry Pi OS directly from the NVMe SSD is supported. Because the SSD sits
behind the RTL9210B-CG USB bridge rather than the Pi 5's native PCIe lane, this is
technically a USB Boot, not a native PCIe NVMe boot. Raspberry Pi 5
treats the drive as a USB storage device during the boot sequence, which means the
EEPROM bootloader's BOOT_ORDER for USB controls it.
-
Update the Raspberry Pi 5 EEPROM bootloader to a current release with
sudo rpi-eeprom-update. -
Configure the bootloader's
BOOT_ORDERto prefer USB boot usingsudo raspi-config→ Advanced Options → Boot Order, or directly throughsudo rpi-eeprom-config --edit. - Image Raspberry Pi OS onto the SSD using the Raspberry Pi Imager, exactly as you would for any USB-connected SSD on Raspberry Pi 5.
-
Power down, install the imaged SSD in the
M.2-SSDslot, power back up.
Pulling the USB-C PD cable while the SSD is writing does not
cause physical damage to the SSD, but unsaved data is lost and the ext4 journal
may report inconsistencies on the next boot. There is no power button on the
Expansion Board: use a clean shutdown (sudo shutdown -h now) before
disconnecting power, especially when the SSD is the boot device.
Concurrent operation
The NVMe slot and the LTE/5G cellular slot are both routed through the same internal USB 3.2 Gen 1 hub, but they are independent endpoints on that hub. Both can be used at the same time. The DEEPX DX-M1 AI accelerator is on a separate path entirely (the dedicated PCIe Gen 2/Gen 3 x1 link through the 40 mm FFC cable) and never competes with storage or cellular traffic for bandwidth.
The practical result, documented by Sixfab: an Edge AI Expansion Board running AI inference on the DX-M1 NPU, writing inference logs to the NVMe SSD, and uplinking results over the LTE/5G modem shows virtually no AI throughput degradation compared to inference alone. This is the configuration the product is designed for.
The dxrt-runtime does not write to disk by itself; your inference
application owns the storage policy. Point your inference code's log path,
captured-frame folder, or detection-output sink at the mount location, for
example /mnt/nvme/inference-logs/, and the SSD will absorb the
write pressure without slowing down the NPU pipeline. For monitoring tools and
the documented healthy dxrt-cli -s output, see
System Monitoring.
The USB Bridge PCBA occupies one of Raspberry Pi 5's two blue USB 3.0 ports. Plugging another high-speed USB drive into the remaining USB 3.0 port forces all USB devices to share the Pi 5's 5 Gbps USB bandwidth, and the total current budget across all USB ports is capped at 1.6 A: adding a second power-hungry drive alongside an NVMe SSD and an LTE/5G modem may cause instability. Low-power peripherals (keyboard, mouse, UVC camera) are not a concern.
Host compatibility
The Edge AI Expansion Board's NVMe slot, like every other subsystem on the board, is designed for the Raspberry Pi 5. The board's mechanical footprint, the pogo-pin back-power layout, and the USB Bridge PCBA carrier are all tuned to the Pi 5 board revision; the NVMe slot has the same host constraint.
- Raspberry Pi 5, the only validated host platform.
- All Pi 5 RAM tiers (2 GB, 4 GB, 8 GB, 16 GB) and all shipped board revisions.
- Raspberry Pi 4 and Compute Module 4.
- Compute Module 5 on the official Raspberry Pi CM5 IO Board.
- Non-Raspberry Pi SBCs (Orange Pi, Rock Pi, Jetson, etc.).
Updated 5 days ago