RISC-V开发板实战：从零构建轻量级NAS与网络存储

1. 项目概述与需求拆解

1.1 这个项目到底要做什么

我一直想做一个真正属于自己的备份中心。市面上的成品NAS价格摆在那，DIY又总感觉少了点什么——直到我接触了RISC-V架构，才意识到这种精简指令集处理器可能比ARM更适合做嵌入式存储设备。

这个项目的核心目标是：不靠x86平台，用一套RISC-V开发板，配合现代Linux网络栈，搭出一个功耗低、成本可控、能跑常用存储协议的轻量化NAS系统。它可以放在宿舍桌面，也可以塞进弱电箱，24小时挂着不心疼电费。

从技术路径上看，整个项目分为五层：

• 引导层：搞定U-Boot的移植与配置，让板子能正常启动内核
• 内核层：裁剪编译Linux内核，把不需要的驱动全部砍掉，保留网络和存储核心模块
• 用户态：搭建精简rootfs，跑起Samba、NFS等共享服务
• 网络栈：合理配置千兆网络，验证高速传输下的稳定性
• 存储层：设计磁盘分区方案，解决热插拔与数据安全问题

标题里提到的“板级引导”指的就是U-Boot阶段，“现代网络栈”则指基于TCP/IP的完整协议链。整个项目做下来，我最大的感受是：RISC-V生态已经比三年前成熟太多了，很多坑文档里都能查到，真正需要硬啃的反而是存储和网络这两个“老话题”。

1.2 适合谁参考这个方案

如果你满足下面任意一条，这篇文章应该能帮上忙：

• 手里有RISC-V开发板（比如某国产双核/四核开发板），不知道除了跑Demo还能做点什么实事
• 想要低成本NAS方案，但觉得x86平台的功耗和体积不太合适
• 想在嵌入式领域深入了解从开机到网络服务建立的完整过程
• 正在为某个Linux发行版在RISC-V上的适配问题挠头

无论你是嵌入式爱好者、存储发烧友还是Linux玩家，这个项目都值得一试。它不像单片机点灯那样浅，也不像数据中心存储那样深，刚好卡在一个“什么都要懂一点”的位置——既练了底层知识，又出了实际成果。

2. 方案选型与关键技术路径

2.1 为什么选RISC-V而不是ARM和x86

先说x86。x86做NAS的优势非常明显：生态成熟、性能强、资料多，随便一搜就有大量教程。但它的劣势也同样致命——功耗和体积。一块x86 ITX主板要带动整套系统，待机功耗基本在15W以上，对于7x24小时运行的设备来说，一年电费也是一笔开支。

ARM当然能做NAS，市面上很多成品也是ARM架构。但ARM授权费用高，各家芯片封闭性强，而且想深入改底层的门槛不低。

RISC-V的独特性在于“开源指令集”这个底层属性。这意味着：

• 指令集文档完全公开，不需要NDA协议你就知道CPU怎么工作
• 核心可以改，SoC厂商能根据场景自定义扩展指令
• 没有授权费，国产芯片厂商愿意投，所以最近两年出了大量便宜好用的开发板

对个人玩家来说，RISC-V现在就像2012年左右的ARM——东西不错、价格便宜，但有门槛、有挑战，玩的就是这个过程。

当然，这里要说句公道话。单纯论做NAS的省心程度，RISC-V还不如ARM。但如果你想要的是“从指令集开始理解硬件”的完整链路，RISC-V给不了你的就是ARM也给不了的。

2.2 硬件平台与资源规划

我用的是某国产厂商的双核RISC-V处理器开发板，主频1GHz出头，带两个千兆网口，一个USB 3.0，一个M.2接口。这块板子最吸引我的地方是核数适中、功耗极低，整板满载不超过5W，性能足够跑轻量级存储服务。

做NAS之前，先得盘一盘手头的硬件资源：

内存这块我特别提醒一句——如果打算跑ZFS，2GB是绝对不够的，ZFS自己就要吃掉1GB以上。所以这个项目的文件系统我用的是ext4，比较务实，后面会详细说。

2.3 为什么文件系统选了ext4而不是ZFS或Btrfs

很多人做NAS会条件反射地想到ZFS，因为它的数据校验和快照太强了。但ZFS是小内存杀手，尤其对RISC-V这种嵌入式平台极不友好。更关键的是，ZFS在RISC-V这种小众架构上基本没有优化，还可能出现移植问题。

Btrfs虽然轻一些，但它的碎片化问题比较突出，嵌入式设备上如果长时间高强度写入，性能衰减会比较明显。而且RISC-V平台上Btrfs的raid5/6代码路径也未必充分验证过。

最后我选了ext4，理由非常朴素：

• 内核自带支持，零额外依赖
• 稳定性经过二十年验证，任何平台都很少出幺蛾子
• 元数据开销小，对小文件访问更友好
• 单机单盘场景下，ext4的性能和可靠性毫不逊色

如果你以后想上RAID或者快照，可以在用户态方案里解决——比如用mergerfs做目录合并，用syncthing做远程备份，效果一样好，还省内存。

3. 板级引导：从零构建U-Boot与内核

3.1 交叉编译工具链的搭建

做RISC-V开发，第一关就是交叉编译环境。你要在x86的电脑上编出RISC-V可以运行的二进制文件，这需要专门的交叉工具链。

我强烈推荐直接使用发行版仓库里现成的工具链，而不是自己去源码编译。以Ubuntu为例：

sudo apt install gcc-riscv64-linux-gnu binutils-riscv64-linux-gnu libc6-riscv64-cross u-boot-tools

装完之后验证一下：

riscv64-linux-gnu-gcc --version

这里有个血泪教训：不要用Arch Linux的AUR里那个五花八门的riscv工具链包，版本参差不齐，有时gcc和binutils版本不匹配，连接的时候报一堆莫名其妙的错。用发行版官方源里的稳定版本，配合Debian系一般不会出大问题。

教练想让我顺便说一句：工具链版本最好和官方BSP（板级支持包）保持一致。有些开发板的出厂固件用的是较老的工具链编译的，你新编出来的内核如果A-B-I不匹配，启动时会报Illegal instruction这种让人抓狂的错误。

3.2 U-Boot的配置与烧录

U-Boot是整个引导链的第一环，它的任务是初始化时钟、内存、串口，然后从存储介质中加载内核镜像启动。

不同开发板有不同的U-Boot适配方式，我用的这块板子官方提供了一份完整的U-Boot源码。编译流程一般是：

git clone https://github.com/xxx/xxx-uboot.git cd xxx-uboot make CROSS_COMPILE=riscv64-linux-gnu- defconfig make CROSS_COMPILE=riscv64-linux-gnu- -j8

注意即使板子用的是同一颗SoC，不同厂商的外围电路设计也不一样，时钟频率、GPIO分配、DDR初始化参数都不同。所以千万不能用别的板子的U-Boot配置直接编译，否则轻则起不来，重则烧东西。

编译出来的u-boot.spl和u-boot.itb分别对应引导的第一阶段和第二阶段，烧录时可以按官方手册操作。这里我想强调一个细节：SD卡烧录U-Boot时，命令往往是写到特定扇区，不是格式化后拖文件进去：

sudo dd if=u-boot.spl of=/dev/sdX bs=1k seek=8 conv=fsync sudo dd if=u-boot.itb of=/dev/sdX bs=1k seek=128 conv=fsync

seek的偏移是由芯片内部的BootROM决定的，每个芯片不一样，别照抄，看手册。

3.3 内核配置裁剪与编译

U-Boot起来了，接下来就是内核。我不想直接跑发行版预编译的内核，一是因为里面塞了很多我用不到的驱动，二是因为我想把存储和网络相关的模块按需编进去，尽量减少运行体积。

从kernel.org拉LTS版本内核源码，然后：

make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- defconfig make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- menuconfig

在menuconfig里，我做了这些关键操作：

• 开启了SMP，让双核都能工作
• 开启了EXT4文件系统支持（编到内核里，而不是模块）
• 开启了SATA和NVMe支持，因为M.2 SSD走的是SATA通道
• 开启了TCP BBR拥塞控制算法，这对长距离传输有帮助
• 开启了USB存储支持，为了外接移动硬盘
• 关闭了蓝牙、WiFi、声卡、DRM等与NAS无关的模块

裁剪之后的内核镜像大约6MB，启动时间从印象中的十几秒降到大概4秒左右。这里需要提醒的是，裁剪一定要留有余地。比如万一以后想加个USB网卡，你就得把usbnet相关的驱动留着。我吃了这个亏——第一次裁剪后接USB设备直接不识别，又得重新编。

编译内核：

make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- -j$(nproc)

你会得到Image和dts（设备树）文件。设备树在RISC-V平台上是必须的，它告诉内核硬件是怎么连接的、中断号是什么、地址映射在哪。如果设备树写的不对，内核起来后会panic或找不到硬盘。

4. 轻量化系统构建与存储方案

4.1 基于BusyBox的最小rootfs

内核起来后，系统需要一套根文件系统才能进入用户态。我以前用的是发行版的预构建rootfs，但这次要做“轻量化”，所以选择了BusyBox手工构建。

BusyBox是一个精简的Unix工具集，一条命令搞定大部分常用工具。它的优势可以用一组对比数据说明：一个标准的Debian最小安装大概需要400MB空间，而BusyBox加必需的系统库，20MB以内就能跑起来。

具体操作：

mkdir -p rootfs/{bin,sbin,etc,proc,sys,dev,usr,lib,tmp,var,mnt} cd rootfs busybox --install -s bin/

然后你需要把交叉编译的动态库拷进来。这一步很容易漏，我曾经因为漏了某个ld库导致所有程序都报"no such file or directory"——注意这不是文件没了，而是动态链接器ld-linux-riscv64-lp64d.so.1没找到。

把libc和动态链接器拷入：

cp /usr/riscv64-linux-gnu/lib/*.so* lib/

然后创建系统初始化的入口：

#!/bin/sh mount -t proc proc /proc mount -t sysfs sysfs /sys mount -t devtmpfs devtmpfs /dev mkdir -p /dev/pts mount -t devpts devpts /dev/pts /sbin/mdev -s hostname riscv-nas /bin/sh

这个初始化脚本会在内核起来后调用，把虚拟文件系统挂上，接着启动shell。对于NAS场景，脚本还可以加上swapon挂载交换分区，提升内存压力的承受能力。

4.2 磁盘分区与挂载策略

存储是NAS的核心，分区策略直接决定后续的使用体验。我手里的SSD是256GB，系统分区和数据分区分开后，数据的安全性更高——崩溃了重装系统不会把数据带走。

分区表如下：

• /dev/mmcblk0p1: 128MB FAT32，存放内核镜像和设备树
• /dev/mmcblk0p2: 4GB ext4，挂载根文件系统
• /dev/mmcblk0p3: 剩余空间，ext4，作为数据盘

分区操作：

fdisk /dev/mmcblk0 mkfs.ext4 /dev/mmcblk0p2 mkfs.ext4 /dev/mmcblk0p3

挂载配置也很直白，在/etc/fstab里写：

/dev/mmcblk0p2 / ext4 defaults 0 1 /dev/mmcblk0p3 /mnt/data ext4 defaults,noatime 0 2

特别提一下noatime选项。默认情况下，每次读取文件都会更新atime属性，这在高频读操作场景下会产生大量不必要的写IO。加上noatime之后，读操作不会触发磁盘写入，能有效延长SSD寿命，也能降低一点CPU占用。

4.3 外接存储与热插拔支持

NAS不能只靠内置盘，外接硬盘是刚需。我在系统里加了USB存储热插拔的支持，用的是mdev，因为BusyBox环境太“轻”，不想上udev。

mdev的规则在/etc/mdev.conf里配置。我的规则是当检测到USB存储设备插入时，自动挂载到对应目录：

sd[a-z][0-9]* 0:0 660 @/etc/mdev/usb_insert.sh sd[a-z] 0:0 660 @/etc/mdev/usb_remove.sh

对应的挂载脚本：

#!/bin/sh case "$1" in sd[a-z][0-9]*) mkdir -p /mnt/usb mount /dev/$1 /mnt/usb 2>/dev/null ;; esac

拔出的脚本里写unmount逻辑。这里必须提醒：热插拔脚本一定要做状态判断，避免脚本重复执行导致挂载点已经被占用。还有就是，写操作正在进行时拔盘会造成数据损坏，脚本里最好加个同步锁。

5. 现代网络栈的部署与共享服务实现

5.1 静态IP与网络设备管理

网络配置我用的是静态IP而不是DHCP。原因很简单，你说一个存储设备，动不动IP就变了，客户端配置就得跟着改，非常麻烦。

在RISC-V这个轻量系统上，我用了最经典的ifupdown方案，编辑/etc/network/interfaces：

auto eth0 iface eth0 inet static address 192.168.1.200 netmask 255.255.255.0 gateway 192.168.1.1 dns-nameservers 192.168.1.1

这里要注意，RISC-V平台的内核里网络驱动的命名不一定是eth0。找一下启动日志里网络设备的名称，或者直接用ip link命令查看。我第一次配的时候写的eth0，结果实际设备叫end0，网络完全不通，排查了半天。

另外，如果板子有两个网口，建议另一个用来做直连管理，不接入局域网，这样可以避免NAS的管理流量和业务流量混在一起，安全性和稳定性都会更好。

5.2 TCP/IP协议栈调优

“现代网络栈”这个说法不能只是好听，得有实际参数支撑。我针对NAS应用的特点对TCP/IP协议栈做了几个方向的调整：

• TCP缓冲区调大，提高高带宽长链路下的吞吐
• BBR拥塞控制替代默认的Cubic，减少丢包重传
• 网络中断绑定到特定CPU核心，提升处理效率

具体配置在/etc/sysctl.conf：

net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 net.core.netdev_max_backlog = 8192

需要注意，TCP缓冲区调大带来的副作用是内存占用上升。每个TCP连接都能占用到上限，所以前面建议内存至少2GB，就是这个道理。

BBR开启方式：

echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf sysctl -p

在嵌入式平台上，BBR对网络吞吐的提升比较明显，尤其是在经过多跳路由器或无线中继的场景下。但在纯千兆有线局域网里，效果差异不大。

5.3 Samba服务搭建与性能验证

Samba是NAS最核心的服务，负责让Windows、macOS、Linux都能往里存东西。在RISC-V下编译Samba是个不折不扣的体力活，建议直接用发行版交叉编译好的二进制包，或者用Buildroot来集成，省时省力。

我最后是用Buildroot直接编的，把Samba选进去，几分钟搞定。这种方式特别适合不折腾依赖库的玩家。

Samba的配置在/etc/samba/smb.conf：

[global] workgroup = WORKGROUP server string = RISC-V NAS security = user map to guest = Bad User guest account = root [Data] path = /mnt/data read only = no guest ok = no valid users = nasuser create mask = 0664 directory mask = 0775

创建访问用户：

smbpasswd -a nasuser

验证服务：

/etc/init.d/samba start

连接测试我用的是Windows的映射网络驱动器，复制大文件看速度。第一次测试时表现很差，只有40MB/s左右，排查下来是MTU的问题——RISC-V的驱动默认MTU是1500，改成9000（万兆网络一般用得上，千兆也有效果）后，速度提到了106MB/s，基本跑满了千兆网。

SMB的性能瓶颈其实经常不在协议，而在文件系统。ext4在高吞吐顺序写上的表现不错，但如果是大量小文件并发写入，RISC-V的处理能力可能会成为瓶颈，这时可以考虑把多个小文件打包或改用其他策略。

5.4 NFS与iSCSI扩展

除了Samba，我还搭了NFS和iSCSI，分别应对Linux客户端和块设备级访问需求。

NFS配置很简单：

echo "/mnt/data *(rw,sync,no_subtree_check,no_root_squash)" >> /etc/exports exportfs -ra

NFS在Linux到Linux的传输上效率很高，CPU占用也比SMB低。

iSCSI则是把NAS模拟成一块网络硬盘。这对“轻量级NAS”来说有点重，但如果你有特定应用需要块级访问而非文件级访问，它就有用了。我搭iSCSI主要是为了测试一个数据库应用能否通过网络块设备来跑。配置要点是targetcli工具的安装和数据卷的创建。在嵌入式平台上，注意iSCSI的吞吐受网络MTU影响非常明显。

6. 实施过程记录与关键问题排错

6.1 搭建过程时间线

为了让大家对整体工作量有个概念，我把时间线列出来：

总计大概6个工作日。当然，这是有基础的情况。如果你对编译和Linux已经比较熟，时间还能压缩；如果完全是新手，做好花两周的准备。

6.2 高频报错日志与修复方案

这里整理了我在整个实施过程中踩过的最典型的五个坑，希望能给后来者省点时间。

错误1：booting from mmc failed

现象：U-Boot起来后找不到SD卡上的内核镜像。

原因与修复：SD卡分区表格式不对，内核镜像没有放到FAT32分区的固定路径。解决办法是重新分区，确保内核镜像所在分区是FAT32并且U-Boot读取路径与文件名完全匹配。注意U-Boot默认会找extlinux.conf或boot.scr，没有文件就什么都不做。

错误2：VFS: Unable to mount root fs

现象：U-Boot加载了内核，但内核挂载根文件系统失败。

原因：根文件系统编译时没有把ext4驱动编入内核。我在menuconfig里选了ext4模块，但没编进去，导致内核启动到挂载根时发现没有对应的驱动。

修复：make menuconfig里把ext4设为“built-in”，同时确认顶层进入的init进程存在。

错误3：Samba无法启动：error while loading shared libraries

现象：执行smbd时报找不到某个共享库。

原因：我手工拷贝rootfs时漏掉了一个依赖库。用ldd smbd查看依赖，一个一个对照复制，问题解决。

错误4：网络传输只有40MB/s

现象：复制大文件只能跑到40MB/s，明显不满千兆。

原因与修复：MTU依然是1500，尝试把MTU改大，加上BBR和缓冲区调优后，速度回到100MB/s以上。

错误5：USB硬盘热插拔没反应

现象：插入USB硬盘/dev/没有出现sdX设备。

原因：内核配置时关闭了usb-storage相关模块，后面重新开启并编入了内核。

6.3 性能基准测试记录

为了量化优化效果，我做了几组基准测试。测试条件：千兆有线直连路由器，客户端为普通x86笔记本，传输介质为1GB随机数据文件。

这个数据说明在RISC-V平台上，哪怕是双核1GHz的规格，跑满千兆也不是梦。优化前后差距巨大，所以如果你觉得你的NAS慢，先看看网络栈有没有改好，别急着否定硬件。

还要说明一下CPU占用率。满速传输时CPU接近60%，内存剩余空间一直在200MB左右浮动——2GB内存虽然紧，但确实够用。

7. 方案评估与后续演进

7.1 这套方案的优势与边界

整个项目做完，回头看看，这套RISC-V NAS方案的优点主要有三条：

• 功耗低，整机5W以内，可以常年开机
• 成本可控，除了存储设备，板子本身几百块钱
• 能学到东西，从引导到网络再到存储，全链路亲手搭一遍收获非常大

但缺点也明显：

• 性能天花板低，适合家庭和小团队使用，要多人并发重度读写还是吃力
• 数据安全性弱，没有RAID，磁盘说坏就坏，依赖备份方案
• 生态不够完善，出现问题排查时能参考的资料相对少

从“能用的现代嵌入式NAS”这个目标来看，方案算是圆满达成。但要爬更高，得先搞清楚自己需要的是什么——是极致性能还是极致的掌控感和学习收获。

7.2 后续我可以继续扩展的方向

项目做到这，我觉得可以有两条演进路线：

轻量云路线：在这套系统上跑Docker或Podman，用容器化方式部署Nextcloud之类的私有网盘。RISC-V的Docker生态这两年才逐渐完善，是一个值得探索的方向。

存储扩展路线：接入多块硬盘，用mdadm做软RAID，提升数据冗余。RAID1在双盘模式下可靠性提升明显，RAID5则能最大化空间利用率。RISC-V处理器做软RAID的计算开销也不大，可以放心用。

数据备份路线：写定期同步脚本，把关键数据备份到外接移动硬盘。备份是数据安全最后的防线，也是用户最该补上的一环。

回看整个项目，我最大的感受是，“嵌入式”和“NAS”这两个词放在一起，并不代表妥协和简陋，反而能碰撞出很多有意思的可能。RISC-V的低功耗和可定制性，配上长期运行的存储设备需求，本来就是天作之合。板子还在桌上转着，日志还在滚动，我有时候写代码写累了，就看看那个从零搭起来的系统安静地跑着服务，感觉特别好。如果你手头也有块RISC-V板子，别让它吃灰了，动手试试吧。