My CM3588 project — a 4-NVMe ARM64 home NAS on 10 W idle

TL;DR — The FriendlyElec CM3588 NAS Kit is an RK3588-based compute module on a carrier board with four M.2 NVMe slots (PCIe 3.0 x1 each), 2.5 GbE, 2× HDMI out, USB 3.0, and an 8- or 16-core ARMv8 CPU (4× Cortex-A76 + 4× Cortex-A55). Fully loaded with four NVMe drives it idles at about 10 W, peaks around 20 W under heavy I/O, and reads/writes an NVMe at roughly 1 GB/s (the bus limit, not the drive). My own unit runs Debian on the mainline kernel, with ZFS on root, four 2 TB NVMe drives in a raidz2 pool, Samba for LAN shares, and Tailscale for off-LAN access. It has replaced a tower PC running TrueNAS and cut NAS power draw by about 60 W.

Why this board

I’d been running a tower PC as a home NAS for years: a second-hand desktop, six 3.5“ spinning disks, and a noisy fan. It worked, but it was using 70–80 W idle and sitting in a cupboard that needed active ventilation. The disks were loud enough that I’d moved them to the far corner of the house.

Three things I wanted from a replacement:

NVMe-only. Spinning disks are cheaper per terabyte but the noise, vibration, and heat aren’t worth it for a home NAS sized in the single-digit terabytes. 4× 2 TB NVMe is plenty.
ARM, for the power draw. An x86 board with 4× PCIe slots wired to NVMe would pull 30–40 W idle. ARM can do it in 10.
Mainline Linux, not a vendor fork. I want apt-get dist-upgrade to work, zfs to compile from DKMS against a current kernel, and no three-year-old vendor BSP.

The CM3588 NAS Kit hits all three.

Hardware

SoC: Rockchip RK3588 (4× Cortex-A76 @ 2.4 GHz + 4× Cortex-A55 @ 1.8 GHz, Mali-G610 GPU, 6 TOPS NPU). ARMv8.2-A.
RAM: 8 GB LPDDR4X on the module I bought. 16 GB and 32 GB variants exist.
Storage: 64 GB eMMC on-module for OS + 4× M.2 Key-M 2280 slots, each PCIe Gen 3 x1 (so ~1 GB/s per slot, not x4).
Network: 1× 2.5 GbE (Realtek RTL8125B).
USB: 2× USB 3.0 Type-A, 1× USB 3.0 Type-C (DisplayPort alt-mode), 1× USB 2.0.
Video: 2× HDMI out, 1× HDMI in (RK3588’s capture block).
Power: 12 V barrel jack. A 60 W brick is more than enough.

The board is small — roughly 10 × 10 cm — and passive over the SoC plus a small fan blowing across the NVMe drives. Mine sits flat on a shelf without a case.

NVMe compatibility caveat

The one gotcha worth knowing: the CM3588 NAS Kit is not compatible with some WD Blue SN580 and WD Black SN850 drives — the linkup flaps at boot. I use Samsung 990 EVO and Crucial P3 Plus; both are fine. Check the FriendlyElec wiki compatibility list before buying NVMe drives.

OS and filesystem

I run Debian 13 (trixie) with the mainline kernel — RK3588 support is good enough from 6.8 onwards for headless use. The FriendlyElec-provided Debian image works out of the box, but I reinstall on top of it to get a clean Debian rather than their BSP.

Root filesystem: ext4 on eMMC.
Data pool: zfs raidz2 across the four NVMe drives. With 4× 2 TB, raidz2 gives ~3.5 TB usable with two-disk redundancy. Yes, raidz2 on four drives is conservative; it also means a double failure doesn’t eat the pool, and on NVMe the rebuild is fast enough that I don’t lose sleep.
ZFS module: DKMS against the running kernel. Rebuilds automatically on kernel upgrades. Has worked without manual intervention across three kernel bumps.
ARC tuning: Capped at 2 GB. This leaves headroom on an 8 GB system.

Throughput is bottlenecked by 2.5 GbE for network I/O (~280 MB/s sustained) long before ZFS or the NVMe drives break a sweat. Local operations on the pool hit around 2 GB/s aggregate sequential read.

Services

Kept deliberately simple:

Samba for SMB shares to the Macs and Windows box on the LAN.
rsync + cron for nightly backups from three other machines.
ZFS snapshots every hour, retained for a week. zfs send pipes the dataset weekly to an off-site B2 bucket via zfs-autobackup + rclone.
Tailscale for off-LAN access. No port-forwarding, no dyndns, no VPN concentrator. SSH and Samba both ride the Tailscale interface when I’m away.
Cockpit for the occasional “why is the fan loud” dashboard moment.

That’s it. No Docker swarm, no Kubernetes, no dozen sidecar containers. The board does one job — serve files on the LAN and let me pull backups off-site — and it does it quietly.

Power and noise

Idle (all four NVMe spun up, no traffic): ~10 W at the wall.
Busy (NVMe read saturating 2.5 GbE, ZFS ARC warm): ~18–20 W.
Peak (scrub across the whole pool, all cores hot): ~25 W.

Compared to the 70–80 W tower it replaced, the ROI on electricity alone is about 500 kWh/year, or roughly 1,500 kr/year at Danish residential rates. The board paid for itself in about a year.

Noise: effectively inaudible from more than a metre away. The fan is small and 80% of the time it’s barely spinning.

What didn’t work, or took effort

Vendor kernel. The FriendlyElec-shipped kernel is FriendlyElec’s fork of 6.1 with RK-specific patches. It works for their turnkey NAS image, but DKMS ZFS builds are painful against it. Moving to mainline fixed this.
HDMI capture. The RK3588 has a hardware HDMI input block. In mainline it’s still experimental. I have a rough use case for it (pulling a signal from an old device for archival) but haven’t made it work end-to-end. Parked for now.
NPU. The 6 TOPS NPU is underused. Mainline has basic RKNPU support but for anything practical you still need FriendlyElec’s rknn-toolkit2. Not a blocker for a NAS.

FAQ

Why not x86?

An x86 mini-PC with 4× NVMe is ~2× the idle power and ~2× the purchase price (once you include the case, PSU, and CPU). For a home NAS where the workload is “serve files” rather than “run 40 containers”, ARM wins.

Why not Raspberry Pi 5?

The Pi 5 has one PCIe 2.0 x1 lane exposed via an HAT — you can bolt on an NVMe, but only one, and at ~500 MB/s ceiling. The CM3588 has four lanes at PCIe 3.0 wired directly. Different class of board.

Why not OpenMediaVault or TrueNAS?

Both would work. I prefer plain Debian + Samba + ZFS because the upgrade path for Debian is well-known to me, and OMV/TrueNAS are a layer I’d have to re-learn. Your mileage will vary.

Why `raidz2` on four drives and not `mirror + mirror`?

I considered it. mirror + mirror gives you faster writes and easier expansion but only 4 TB usable from 4× 2 TB, same as raidz2. With raidz2 any two drives can fail; with striped mirrors you can lose two drives, but only if they’re in different mirror pairs. On four drives the capacity is identical and raidz2 has the stronger failure tolerance.

Can it run Plex / Jellyfin?

Yes, and the RK3588’s hardware H.265/VP9/AV1 decode block does the heavy lifting. Jellyfin with rkmpp accelerated decoding handles 4K HEVC transcodes at about 3× realtime. I don’t run either on this box — my Plex lives elsewhere — but it’s viable.

Does it suspend?

Not reliably. Leave it on; idle is 10 W anyway.

What about noise and heat in summer?

Passive heatsink plus one small fan. In a Danish summer (20–25 °C ambient) it tops out around 55 °C die temp under a ZFS scrub. No throttling I’ve measured.

Verdict

If you want a quiet, low-power, all-NVMe home NAS with enough PCIe to matter and you’re willing to spend an evening on Debian + ZFS, the CM3588 NAS Kit is the best option I’ve found. It’s not the cheapest — a second-hand Optiplex is cheaper upfront — but on three-year TCO including electricity it pays back clearly.

The RK3588 itself is a surprisingly capable SoC for homelab workloads. Once mainline kernel support landed, I stopped treating it as “an ARM curiosity” and started treating it as a default answer for small always-on servers.

Two years in, mine has been rebooted twice (once for a kernel upgrade, once because I moved the shelf). I’d buy it again.