企业官网建设流程全解析

我从一个反直觉的现象说起：今年手头三个边缘计算项目做选型，需求各不相同，一个是视频结构化，一个是工业质检，还有一个是轻量AI盒子，但最后方案评审表上无一例外都写了瑞芯微。说实话，这个结果不是刻意安排，而是比来比去，瑞芯微总是那个"刚好卡在需求和成本中间"的选项。加上最近逛社区，到处是RK3568设备树改造、RV1106模型部署、固件解包烧录的帖子，连Hugging Face上下的模型都有人问怎么转到瑞芯微的NPU上跑——这让我忍不住想认真复盘一下：为什么总是瑞芯微？

这篇文章不打算做芯片参数的罗列，我想从实际开发者的角度，把瑞芯微从选型、设备树定制、固件操作到AI模型落地的完整链路拆开讲透，顺便也说点它的坏话。无论你是刚入门嵌入式Linux的新手，还是正在做边缘AI方案选型的老手，这篇应该都能给你一些参考。

1. 瑞芯微的分区布局：为什么从RK3228H到RK3568总有一款"够用"

1.1 RK3228H这类"老古董"为什么还在大量出货

很多人不理解，RK3228H这种四核A7、28nm工艺的老芯片，在2024年了为什么还有大批设备在用。我前阵子帮客户维护一批商显设备，拆开主板一看，RK3228H，2016年前后的方案。客户不是不想升级，是这套硬件跑Linux + QT的界面程序，稳定的很，而且当年的模具、电源、外围电路都不用重画，换主控等于整机重新过认证，这个成本没人愿意出。

瑞芯微厉害的地方在于，它不会因为出了新芯片就把老芯片的BSP扔了。RK3228H的固件包到现在还能从官方渠道拿到，Linux 4.4的内核虽然老，但驱动和工具链都是完整可用的。这种"旧平台持续维护"的承诺，在工业客户那里比任何性能参数都重要。很多盒子方案商手里压着几十万片的RK3228H库存，靠的就是瑞芯微平台上开发的固件可以一套代码打天下，换型号时只需要改改设备树和内核配置。

1.2 中坚力量RK3568：一颗芯片吃掉大多数工业场景

真正让我对瑞芯微建立信心的，是RK3568。这颗四核A55芯片可以说是把"够用哲学"发挥到了极致：有PCIe 3.0可以接NVMe或者AI加速卡，有双千兆网口适合当网关，有VPU硬解视频，还带一个0.8TOPS左右的NPU能顺带跑点轻量模型。

做个简单对比你就明白它的定位了：

我见过不少团队在选型时奔着RK3588去，结果发现散热压不住、内存带宽浪费，最后退回RK3568。反过来说，如果一开始就评估RK3568，很多项目其实就够了。瑞芯微这种从低到高的产品线密度，让你在做选型矩阵时，总能在性能-价格-功耗三角形里找到一个落点。

1.3 选型时最容易忽略的三个"软指标"

芯片参数表谁都会看，真正拉开差距的是软指标。我自己的经验是，瑞芯微在这三点上优势明显：

第一，资料开放程度。芯片手册、DTS示例、内核补丁、工具链下载链接，全部公开在官方Wiki和Gitee仓库上。这意味着你可以基于官方BSP做深度定制，而不是只能调用厂商封装好的黑盒API。

第二，上游社区的跟随度。瑞芯微对Linux内核mainline的贡献这些年肉眼可见地增加，很多新板子的基础支持已经合入上游内核。这意味着你可以用主线内核来跑，而不必被厂商的内核版本绑架。

第三，二次开发工具的完善度。无论是烧录工具、固件解包工具还是NPU的RKNN工具链，瑞芯微都有完整的配套。后面我会分别展开讲。

2. RK3568设备树实战：修改、编译和回滚的完整链路

2.1 设备树并不是"软件配置"，它是硬件的地图

很多从单片机和裸机开发转过来的朋友，第一次接触设备树都会犯同一个错误：把它当成一个配置文件，想怎么改就怎么改。实际上，设备树(Device Tree)描述的是硬件拓扑和资源分配。内核通过它知道"板子上有哪些外设、它们挂在哪条总线上、中断号是多少、引脚复用情况如何"。

RK3568平台的设备树文件，在官方BSP里通常位于kernel/arch/arm64/boot/dts/rockchip/。以一块典型的EVB板为例，你会看到类似这样的结构：

• rk3568.dtsi：SoC级定义，包含所有内置控制器（UART、I2C、SPI、GPU等）
• rk3568-evb.dtsi：板级公共配置
• rk3568-evb1-v10.dts：具体型号的板级配置

这种分层设计是瑞芯微BSP的传统，好处是同一个SoC的多个主板方案可以共享大量设备树代码，你只需要在板级文件里覆盖差异。

2.2 动手改一个GPIO按键的完整流程

以最常见的需求"加一个GPIO按键"为例，操作过程分为四步。

第一步，确认引脚。RK3568的GPIO编号规则是GPIOx_y，x从0到4，每个bank有4组（A/B/C/D），每组8个引脚。比如GPIO3_PB5表示GPIO3组的B组第5脚。在设备树中写作gpio3 RK_PB5 GPIO_ACTIVE_LOW，这里的RK_PB5宏定义在include/dt-bindings/pinctrl/rockchip.h中。

第二步，在板级DTS文件里添加节点。例如在根节点下加上：

gpio-keys { compatible = "gpio-keys"; autorepeat; shutdown-key { label = "Shutdown Key"; gpios = <&gpio3 RK_PB5 GPIO_ACTIVE_LOW>; linux,code = <KEY_POWER>; wakeup-source; }; };

第三步，检查引脚复用。这是最容易踩坑的地方。如果这个GPIO同时被其他功能占用，比如I2C或者UART的某个引脚，内核会在启动时打印"pinctrl"相关的警告，甚至直接不识别设备。需要去查找该引脚的默认复用配置，必要时在pinctrl节点里修改rockchip,pins，例如：

&pinctrl { keys { shutdown_key: shutdown-key { rockchip,pins = <3 RK_PB5 RK_FUNC_GPIO &pcfg_pull_up>; }; }; };

第四步，编译。我不建议单独跑dtc，因为设备树源文件包含大量头文件引用。最快的方式是进内核根目录，交叉编译环境配置好后执行：

make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- dtbs

生成的dtb在arch/arm64/boot/dts/rockchip/下。如果你使用的是Buildroot或Yocto，直接重新构建内核包即可。

2.3 设备树烧录与回滚的保命方法

设备树改错最典型的后果是：内核启动到一半就panic，串口打印的最后一个log指向某个内存地址。板子变砖。但变砖不可怕，关键是你有没有回滚方案。

我自己的做法是：烧录前先备份当前正在使用的dtb。如果板子是直接从TF卡启动的，备份更简单，直接把boot分区里的dtb文件复制一份到宿主机即可。如果是烧录到eMMC的，用下面的命令把当前dtb单独读出来：

sudo upgrade_tool rd 0x4000 0x800 dtb_backup.bin

这里的地址参数在不同分区表里不一样，具体要看你编译时的parameter文件。顺带提醒，修改设备树前先去确认串口调试功能是开着的，这样 kernel panic 时你至少能拿到完整的log来定位问题。

3. 固件解包与系统烧录：瑞芯微工具链的隐藏红利

3.1 先搞懂瑞芯微固件的基础结构

瑞芯微的固件分为两种形态：一种是单个的update.img，里面打包了整个系统的所有分区；另一种是分散的分区镜像文件，比如uboot.img、boot.img、rootfs.img。我们在开发调试阶段几乎不会碰update.img，都是直接烧录单个分区镜像。但在做固件定制、学习别人方案、或者恢复出厂固件时，解包update.img就成了必修课。

update.img的内部结构大致是这样的：

• 头部：描述固件版本、芯片型号、创建时间
• Loader：用于初始化DDR和引导系统
• Parameter：描述分区表，包括每个分区的名称、起始地址、大小
• 各分区镜像：Uboot、Boot、Recovery、Rootfs、OEM等

瑞芯微的老固件和新固件在打包格式上有差异，2.0之前和之后的RKAF格式都有工具支持，后面我会讲实际操作。

3.2 固件解包的实际操作：以学习设备树配置为例

我解包固件最常用的一个场景是：拿到一块别人设计的主板，没有源码，但想学习它的引脚配置或外设定义。这时候解包官方固件，从里面提取boot.img里的dtb，再反编译成dts，就能很直白地看到硬件设计思路。

解包工具方面，Windows下推荐瑞芯微官方出的RKDevTool的解包功能，以及开源的imgRePacker（我更喜欢这个，因为命令行操作更可控）。以imgRePacker为例，基本用法：

1. 把update.img放到工具目录下。
2. 打开命令行，运行解包命令，工具会输出固件头信息和分区表。
3. 解包完成后得到config.cfg和各个分区镜像文件。
4. 用dtc反编译得到的dtb文件：

dtc -I dtb -O dts -o rk3568-board.dts boot/dtb/rockchip/rk3568-evb.dtb

这里要特别强调一下合规问题：这种操作只适合用在你自己有权修改的设备上，比如公司采购的开发板、你手头的公版方案。那些加了解锁校验的商业设备固件，不建议也不鼓励去碰。学习设备树的结构和写法，用官方的EVB固件就足够了。

3.3 烧录模式与踩坑记录

进入瑞芯微的烧录模式，最常见的是两种：Loader模式和Maskrom模式。

Loader模式是正常的烧录准备状态，进入方式通常是：断电，按住主板上的Recovery按键或短接对应的触点，再插USB线给板上电。系统启动后，Windows设备管理器里会出现一个Rockusb设备。

Maskrom模式则是在Loader被破坏或者DDR初始化失败时进入的"最后兜底"模式。特征是USB设备名变成Maskrom Device。进入方法通常是短接eMMC/SPI Flash的CLK引脚再上电。进入Maskrom模式后，需要用低级工具先把Loader重新烧进去：

sudo upgrade_tool db loader.bin

烧录过程中最容易出的问题有三个：

第一，USB线没有数据能力。很多杂牌Type-C线只能充电，插上后设备管理器毫无反应。排查方法很简单，换一根能传数据的线试试。

第二，驱动没有装好。Windows下需要用DriverAssitant工具安装瑞芯微的USB驱动，安装完必须重启电脑才生效。

第三，分区表不对导致烧录后无法启动。这个问题一般是因为你烧录了A板子的镜像到B板子上，两边Flash布局不同。解决思路是先把解包固件里的parameter文件重新烧一次。

4. RV1106的AI部署：从Hugging Face模型到板端的完整链路

4.1 为什么偏偏要转成ONNX再碰RKNN-Toolkit2

瑞芯微的NPU不像PC显卡那样可以直接喂PyTorch模型，它需要通过一个叫RKNN的中间格式来部署。官方提供了RKNN-Toolkit2工具链，支持直接把PyTorch、TensorFlow、ONNX等格式转换为RKNN模型。

我的实践体会是，无论来源是PyTorch还是Hugging Face，最稳妥的路径都是先转成ONNX，再转RKNN。原因有三：

第一，Hugging Face上很多模型是动态图，直接导出成TorchScript再转RKNN，经常会遇到算子在转换阶段不兼容的问题。先走一遍torch.onnx.export，模型被固化成静态图，能提前暴露动态维度、控制流等算子问题。

第二，ONNX是中间格式，转换失败时更容易定位到具体算子。RKNN-Toolkit2在加载ONNX时会明确告诉你哪个节点不支持，你可以通过修改模型结构或替换算子来修复。如果你直接用PyTorch走它的前端，错误信息往往非常模糊。

第三，工作流的一致性。团队里模型训练、部署可能是不同人负责，ONNX作为一个标准中间格式，大家都认，后端想换成别的硬件平台时也不用全部重来。

4.2 用RV1106跑一个分类模型的完整转换流程

RV1106是瑞芯微针对IPC和低功耗AI场景出的芯片，NPU算力0.5TOPS，在INT8量化下理论算力约1TOPS。这个算力跑大型Transformer肯定不行，但跑MobileNet级别的分类模型、轻量YOLO检测模型，在720P的输入下可以做到实时。

假设你从Hugging Face上拉了一个MobileNetV3的预训练模型，转换步骤如下：

第一步，安装RKNN-Toolkit2。它依赖的Python库比较多，建议新建一个虚拟环境：

python3 -m venv rknn-env source rknn-env/bin/activate pip install rknn-toolkit2

第二步，把Hugging Face模型导出为ONNX。以PyTorch为例：

import torch from transformers import AutoModelForImageClassification, AutoFeatureExtractor model = AutoModelForImageClassification.from_pretrained("google/mobilenet_v3_small") model.eval() dummy_input = torch.randn(1, 3, 224, 224) torch.onnx.export( model, dummy_input, "mobilenetv3.onnx", input_names=["input"], output_names=["output"], opset_version=12 )

第三步，用RKNN-Toolkit2转换和量化。量化是决定最终效果的关键一步，我用的是官方标注的图片作为量化校准集：

from rknn.api import RKNN rknn = RKNN() rknn.config(target_platform='rv1106', quantized_dtype='w8a8') rknn.load_onnx(model='mobilenetv3.onnx') rknn.build(do_quantization=True, dataset='dataset.txt') rknn.export_rknn('mobilenetv3.rknn')

dataset.txt里面每行是一个图片路径，放几十张有代表性的图就够了。这里有个很多人忽视的细节：量化校准集必须贴近真实应用场景。如果你最终部署在工业现场拍产品表面，校准集却用自然风光图片，量化后精度损失可能高达5个百分点以上。

第四步，在RV1106板上调用。瑞芯微提供了RKNN Runtime的C/C++和Python接口，C接口适合高性能场景，Python接口适合快速验证。部署时核心代码是：

rknn_init(&ctx, "mobilenetv3.rknn", 0, NULL); rknn_input_set(ctx, 1, &input); rknn_run(ctx, NULL); rknn_output_get(ctx, 0, &output, NULL);

4.3 转换和部署中我实际踩过的三个坑

第一个坑是关于量化后的精度波动。RKNN-Toolkit2的默认量化算法在某些层上会出现明显的精度掉点。我排查下来的经验是：优先检查输入归一化方式。PyTorch训练时用的mean和std，在转换到ONNX时通常已经融入到模型中，但有些框架导出的ONNX不带归一化层。如果你的ONNX里没有归一化操作，那么在板端推理时，必须先对输入图做归一化再喂给NPU，否则输出logits的数值范围会全乱掉。

第二个坑是模型输入尺寸和被硬件加速不匹配。RV1106的NPU对输入分辨率有一定的对齐要求，有些层的Channel数也有限制。如果模型输入是1280x1280这种大图，NPU处理时间会显著拉高。我的建议是尽量在模型设计阶段就考虑目标分辨率的适配，而不是转换后才去裁图。

第三个坑是内存带宽瓶颈。RV1106的算力虽然不高，但在某些小模型上仍然会出现NPU吃不满，原因是DMA搬运数据的时间超过了NPU计算时间。遇到这种情况，优先考虑把连续推理的多个预处理步骤合并，减少内存拷贝。

5. 说点瑞芯微的坏话

5.1 文档的"碎片化"问题确实很折磨人

不可否认，瑞芯微的资料很多很全，但分布极其散乱：有的在官方Wiki，有的在Gitee仓库的README里，有的藏在某个技术论坛的历史帖子里。特别是一些底层的寄存器说明，官方数据手册写得非常简略，甚至需要去Linux内核源码里反推。我建议新入坑的朋友直接以官方Git仓库的PDF文档为主，配合内核源码阅读，不要依赖二手转载。

5.2 BSP版本和内核版本的绑定关系

瑞芯微的BSP是基于某个特定版本的内核做深度定制，比如RK3568的官方BSP主要基于Linux 4.19或5.10。当你需要较新内核的特性时，就得自己移植补丁，这个过程容易踩内核API变化的坑。我的建议是：如果项目没有硬性需要，不要轻易换内核大版本。厂商的稳定发布BSP在长期可靠性上通常比你自己升级内核可靠得多。

5.3 什么时候我建议你绕开瑞芯微

讲完这些好话，也得说得罪人的大实话。以下三种场景，我一般不建议用瑞芯微：

• 你的产品需要极其严苛的实时性，比如PLC级别的硬实时控制。瑞芯微虽然支持PREEMPT_RT补丁，但毕竟主要定位在消费和工业边缘计算，真正的确定性响应还是找带PRU/协处理器的方案更合适。
• 你的产品生命周期超过10年，且期间几乎没有现场维护能力。这种情况下芯片的长期供货承诺比性能参数重要得多。瑞芯微的东西在商显、盒子上生命周期管理做得不错，但工业级10年以上供货的案例还不够多，需要单独和代理确认。
• 你的模型结构非常规，包含大量自定义算子或需要FP16/FP32高精度推理。瑞芯微NPU对INT8量化支持得很成熟，对FP16的支持相对有限。如果你必须用高精度跑复杂模型，建议直接选带GPU的Jetson平台，别在NPU工具链上折腾。

回到最初的问题：为什么总是瑞芯微？说到底，它是一个"平均分最高的选手"——单点性能不是最强，但BSP完整性、工具链成熟度、产品线密度和社区资源综合起来，恰恰让它成了大多数边缘项目里最不冒险的选择。至少在我经手的项目里，选瑞芯微很少是因为某人特别喜欢它，而是因为每一轮评估筛到最后，它都还站在那里。如果你正准备评估一款主控芯片，不妨也试着把"出现问题后多快能拿到有效答案"作为一条核心指标——这一点，瑞芯微的社区、文档和工具链确实帮我省下了大量时间。