前言
我这次折腾 RK3566,并不是单纯为了"能刷进飞牛"这件事。真正决定这台小盒子能不能长期当 NAS 用的,是后面一整条链:先确认主板版本和短接点,装好 RKDevTool 驱动,在不接电源的状态下进入 MASKROM 并写入 ARM 版飞牛;系统能启动以后,再把 SATA 硬盘接上,通过 SSH 和管理工具把系统克隆到硬盘,并切换启动引导;等本地存储和启动方式都稳定下来,最后才配置 cpolar,让飞牛后台从局域网扩展到公网。这里最不能省的是顺序。刷机、分区、引导切换都不是适合"看个大概就点下一步"的操作,我更愿意每完成一层就确认一次结果,再继续往下走。
1. 开始之前,先确认设备版本和准备条件
飞牛 NAS 的 ARM 版正在做不同 Rockchip 平台适配,本文涉及的设备是 RK3566。

这批 RK3566 设备存在 1.0、1.1、2.0、2.1 等主板版本。短接位置并不完全一样,所以我在真正动手前先拆机确认版本,而不是直接照一张图去碰触点。

这次刷机需要准备:
- RK3566 设备 × 1;
- 12V/2A 电源适配器 × 1;
- 网线 × 1;
- USB Type-C 数据线 × 1;
- 起子、镊子 × 1;
- SATA 硬盘 × 1(教程后半段用于把系统写入硬盘);
fnos_Mainland-PE_arm_1.0.0_rk3566-null_258.img镜像、RKDevTool等刷写资源。
资源获取方式按现有教程说明执行。

这一步我最在意的不是"东西都凑齐了",而是设备版本、镜像、刷写工具必须对应后面的实际步骤。
2. 先把 RKDevTool 驱动装好
解压 RKDevTool.zip,进入 DriverAssitant_v5.0。

双击运行:
DriverInstall.exe
点击【驱动安装】,直到提示安装成功。

驱动装好以后,Windows 才有条件在后面识别 MASKROM 设备。
3. 第一次刷机,最需要谨慎的是拆机和短接
3.1 刷机时不要接电源
这里我把原步骤里最重要的提醒保留下来:
刷机的时候不要接入电源。
无论是首次拆机短接,还是后续用 Reset 复位方式线刷,本文的操作流程都是让设备通过 Type-C 与电脑连接时完成识别。
首次刷机需要拆机短接;后续再刷,可以使用 Reset 复位按钮配合数据线。
3.2 拆开设备确认主板版本
先拆下底部 4 颗螺丝。

拿掉顶盖后,再拆 SATA 接口和边缘螺丝。

把 SATA 排线抽出。

从标有"正面朝上"的位置向上取出主板。

我这次实际使用的是 1.1 版本。
1.1 与 1.0 版本的短接点为:
GND 和 1V8 金属点

如果设备是 2.0 / 2.1,短接位置不同,需要按对应位置操作。

这一步绝对不能因为"都是 RK3566"就把不同板版当成同一个位置。
4. 进入 MASKROM 并刷入 ARM 版飞牛
打开 RKDevTool.exe。

首次刷机时,按教程勾选对应两个项目,然后在 LoaderToDDR 末尾选择相应文件。

接着在 system 一栏选择已经解压好的系统镜像。

要确认选择的是:
.img
而不是压缩包。

接下来就是最关键的一步。
先用镊子抵住正确的短接点,再插入 Type-C 数据线连接电脑。
这里依然不要接设备电源。

等待 RKDevTool 显示:
发现一个 MASKROM 设备
看到提示以后再松开镊子,然后点击执行开始刷写。

我不会把"工具开始跑进度条"当成成功,只有等刷写结束并看到完成状态,才继续装机和上电。
5. 第一次启动,先确认飞牛真的能进后台
刷写完成后,工具会显示下载完成。
这时拔掉 Type-C,接上电源和网线。

然后进入路由器管理页面查看设备列表。
本文环境里可以看到一台名为:
debian
的设备,也可以使用局域网 IP 扫描工具寻找。

这次获得的访问地址是:
shell
http://192.168.50.211

浏览器能打开飞牛 NAS 初始化页面以后,创建管理员账号。

进入主页。

到这里我只确认一件事:
ARM 版飞牛已经能在这台 RK3566 上启动,并且 Web 管理页面可以正常进入。
接下来才处理更适合长期使用的 SATA 启动。
6. 把系统克隆到 SATA 硬盘,再切换引导
首次刷机完成以后,后续就不需要每次都拆机短接,可以通过 Reset 配合线刷。
装回设备,接上 SATA 硬盘,重新进入飞牛,在系统设置里确认硬盘能够识别。

然后开启 SSH。

在 Windows 中按 Win + R,输入 cmd,通过 SSH 连接飞牛:
shell
ssh 飞牛用户名@飞牛的访问的IP地址

再切换到 root:
shell
sudo -i

接着运行 RK3566 管理工具:
shell
curl -fsSL https://gitee.com/jun-wan/script/raw/master/rk3566-fnos-arm-tools/xxfn-tool.sh -o /usr/local/bin/xxfn-tool && chmod +x /usr/local/bin/xxfn-tool && xxfn-tool

6.1 初始化 SATA 分区
进入工具后输入:
7
回车后,再次回车会默认给分区 1 分配 32G,也可以手动指定容量。
然后输入:
y
确认初始化 SATA 分区。

没有报错并提示初始化成功后,再继续。
6.2 克隆系统到 SATA
回到菜单,输入:
13
然后输入:
y
开始克隆。

等待克隆完成。

6.3 切换到 SATA 启动
再次回到菜单,输入:
1
把启动引导切换到:
SATA 硬盘
输入 y 确认并立即重启。

系统重启后,再登录飞牛设置页面,可以看到分区 1 变成 32G。

之后在存储空间管理里创建剩余 SATA 分区。

这里有一个必须保留的提醒:
千万不要选择内置硬盘。格式化内置硬盘会导致系统无法启动。
创建完成后,剩余 SATA 分区也会显示出来。

到这里,这台 RK3566 才从"能启动飞牛"进一步变成了"系统已经迁移到 SATA,并完成启动引导切换"的状态。
7. 本地 NAS 稳定以后,再处理公网访问
飞牛能启动、SATA 能识别、系统也已经切到硬盘启动,这时候再做远程访问比较合理。
cpolar 在这里负责的事情很单一:
把飞牛 NAS 已经运行正常的 Web 管理页面从局域网映射到公网。
它不参与刷机、不参与分区,也不负责 SATA 启动。

8. 在飞牛里安装 cpolar
回到 SSH 终端,执行:
shell
sudo curl https://get.cpolar.sh | sh

安装完成以后检查服务状态:
shell
sudo systemctl status cpolar

看到:
active(running)
说明服务处于运行状态。
然后在浏览器访问飞牛 IP + 9200:
shell
# 请使用你的访问IP + 9200端口
http://192.168.50.211:9200

Web UI 能打开以后,再继续配置隧道。
9. 先用随机公网地址验证飞牛后台
登录 cpolar 后,进入【隧道管理 → 隧道列表】。

编辑默认的 website 隧道,也可以新建隧道。
创建或者更新完成后,接着点击状态>在线隧道里列表,可以看到有2条隧道,一条为http的协议,另一条为https的协议:
创建或更新后,到【状态 → 在线隧道列表】查看生成的 http / https 公网地址。

本文使用 https 地址做测试。

飞牛 NAS 登录页面可以正常打开。
这里我还把一个明显的复制残留去掉了:原小节标题写成了"穿透 HiNas 的 web 页面",但整篇实际操作对象一直是飞牛 NAS,这里统一按真实对象继续写。
10. 长期使用,再换固定二级子域名
随机地址适合先验证链路。
现有教程说明随机域名大约每 24 小时变化一次,如果准备长期使用,就继续配置固定二级子域名。
进入预留页面:
shell
https://dashboard.cpolar.com/reserved
在【保留二级子域名】里填写地区、名称和描述。

这次保留的是:
- 地区:
China Top - 二级域名:
fnos01
二级域名以自己账号实际保留的名称为准。
10.1 把隧道切换到固定子域名
回到【隧道管理 → 隧道列表】,可以看到名为:
fnos
的隧道。

点击编辑,把域名类型改成【二级子域名】,填入前面保留的名称。

然后在在线隧道列表里确认 fnos 已经变成固定二级子域名形式。

继续使用 https 测试。

再实际登录。

固定地址可以正常进入飞牛后台。
到这里,远程入口才算完整:
局域网飞牛后台 → 随机公网地址 → fnos01 固定二级子域名。
总结
这次真正跑通的,不只是"RK3566 能刷飞牛",而是一条完整的硬件到远程访问链:
确认主板版本 → 安装 RKDevTool 驱动 → 拆机短接 → MASKROM → 写入 ARM 飞牛镜像 → 本地登录 → 接入 SATA → SSH → 初始化分区 → 克隆系统 → 切换 SATA 启动 → cpolar → 随机公网访问 → fnos01 固定二级子域名。
我更愿意把这套方案看成一次完整迁移,而不是一次刷机。
真正需要小心的几个地方也很明确:
- 1.0 / 1.1 与 2.0 / 2.1 的短接位置不同;
- 刷机时按本文流程不要接电源;
- 镜像要选解压后的
.img; - 只有看到 MASKROM 设备以后才继续刷写;
- SATA 分区和克隆完成以后再切换启动引导;
- 不要格式化内置硬盘;
- 公网访问应该放在本地系统已经稳定以后再配置。
本文还提到了大约 3--5W 功耗、低成本等特点,但这次流程没有单独做功耗计测试和成本核算,所以我没有把这些数字继续扩大成性能结论。
对我来说,这台 RK3566 真正有意思的地方不是"便宜小盒子也能当 NAS",而是从刷机、启动、存储到公网访问,每一层都能被单独验证。这样后面不管是继续跑 Docker,还是把它放到角落长期工作,至少知道问题应该从哪一层开始查。