RK3568工控板量产写号指南：用RKDevInfoWriteTool写入SN与MAC

1. 从一块"信息空白"的工控板说起

手里拿到一块瑞芯微RK3568工控主板，通电、串口有输出、系统能跑，但打开设置一看，设备序列号是默认值、MAC地址是随机生成的、厂商信息一片空白。这种板子如果只做一两块自己玩，无所谓；可一旦进入批量出货环节，问题就来了——客户产线上要按MAC做网络准入、售后要靠序列号追溯批次、系统里要显示自家品牌而不是芯片原厂的默认串。这时候你就必须面对一个绕不开的环节：用RKDevInfoWriteTool给主板写入厂商信息、序列号和MAC地址。

RKDevInfoWriteTool是瑞芯微官方提供的一个Windows端小工具，专门用来往RK系列芯片（包括RK3568、RK3566、RK3588等）的存储介质里写入Vendor信息、SN序列号、MAC地址、IMEI等标识数据。它和常见的固件烧录工具（比如RKDevTool）是两回事：RKDevTool负责把整个系统镜像刷进去，而RKDevInfoWriteTool只负责往一个特定的信息分区里"盖章"。很多刚接触RK3568的工程师会把这两件事混为一谈，结果要么是刷完机发现MAC还是随机的，要么是批量写号时把整块板子的系统搞崩了。

这篇内容面向的是正在做RK3568工控主板量产、调试或二次开发的工程师，尤其是那些第一次接触瑞芯微平台、需要把"写号"这件事从手工单板操作升级到批量自动化的人。我会把工具的工作边界、配置文件的字段逻辑、单板写入的完整流程、批量烧录的脚本化方案，以及我自己踩过的几个坑，全部摊开讲清楚。你不需要有瑞芯微原厂的培训背景，只要会基本的Windows操作和串口调试，就能跟着走完。

2. RKDevInfoWriteTool到底改了什么：信息分区的底层逻辑

2.1 它写的不是系统，是一个独立的"身份证分区"

要理解这个工具，先得理解RK3568的存储布局。RK3568支持eMMC、SPI NAND、SPI NOR等多种启动介质，无论哪种，瑞芯微的固件体系里都预留了一块独立区域，通常叫vendor storage或者信息分区。这块区域不参与正常系统的挂载，普通文件系统看不到它，但Bootloader和内核在启动早期会去读它，把里面的MAC、SN、Vendor名取出来，再传给上层。

RKDevInfoWriteTool干的事，就是通过USB或串口，把一段结构化的数据写进这个分区。它不碰boot、不碰rootfs、不碰parameter，所以理论上写号失败不会导致板子变砖——这一点和刷整机镜像的风险等级完全不同。我见过有同事因为怕写坏板子，每次写号前都先备份整机镜像，其实大可不必，只要你不去动分区表，写号本身是低风险操作。

注意：虽然写号本身风险低，但如果你的固件里vendor storage的偏移地址和工具默认配置不一致，写入的数据可能落在错误位置，表现为"写成功了但系统读不到"。这个后面会专门讲。

2.2 Vendor、SN、MAC三类数据的用途差异

工具界面上能填的字段不少，但量产中最核心的是三类：

• Vendor信息：厂商名称、产品型号、硬件版本。这些数据通常被上层应用或定制化的设置界面读取，用来显示"XX公司 XX型号"。它不是系统启动的必需项，但客户验收时会看。
• SN序列号：唯一标识每一块板子。售后追溯、产线MES绑定、保修查询都靠它。SN的编码规则一般由厂商自己定，比如"前缀+日期+流水号"。
• MAC地址：以太网和WiFi的物理地址。RK3568工控板通常至少有一个千兆网口，有的还有双网口或WiFi模块。MAC必须全局唯一，否则同一局域网内会冲突。MAC的分配一般从IEEE购买OUI前缀，后三字节自己按流水号分配。

这三类数据的共同点是：必须在出厂前写入，且每块板子不同。这就是为什么不能靠刷一个统一固件解决，必须用写号工具逐板处理。

2.3 工具与RKDevTool的分工边界

很多人问：能不能用RKDevTool顺便把MAC也写了？答案是：RKDevTool刷的是镜像，镜像是统一的，里面不可能包含每块板子不同的MAC。所以标准流程是两步——先用RKDevTool刷统一固件，再用RKDevInfoWriteTool写差异化信息。顺序不能反，因为写号工具依赖板子已经处于可被识别的工作状态（通常需要进入Loader或Maskrom模式）。

理解这个分工，后面配置和批量操作才不会乱。

3. 写号前的环境准备：别急着插板子

3.1 驱动安装与设备识别

RKDevInfoWriteTool在Windows下工作，依赖瑞芯微的USB驱动。如果你之前装过RKDevTool，驱动通常已经就位；如果是全新电脑，需要先装DriverAssitant（瑞芯微驱动助手），装完重启。判断驱动是否正常的方法很简单：把板子置于Loader模式（通常是按住Recovery键再上电，或者系统里执行reboot loader），然后在设备管理器里看是否出现"Rockusb Device"。

我遇到过一种情况：设备管理器里显示的是带黄色感叹号的未知设备，工具里也识别不到。这九成是驱动没装对，或者USB线是充电线而非数据线。换一根确认能传数据的线，重装驱动，基本能解决。另外，有些工控板用的是USB Type-C口做调试口，注意方向，插反了不识别。

3.2 确认固件里的vendor storage配置

这是最容易被忽略的一步。RKDevInfoWriteTool的配置文件里有一个关键参数，指向vendor storage在存储介质上的偏移和大小。如果你的固件是用官方SDK默认配置编译的，这个值通常是标准的；但如果你改过分区表，或者用的是第三方核心板厂商的固件，就必须先确认。

确认方法：在SDK的device/rockchip/rk3568/目录下找parameter.txt或分区表文件，看有没有vendor或misc相关的分区定义。也可以直接问核心板厂商要他们的写号工具配置文件。我吃过一次亏：用A厂商的板子配B厂商的配置文件，写号显示成功，但系统读出来全是0，排查了半天才发现偏移对不上。

3.3 准备MAC和SN的分配表

批量写号前，你必须先有一张分配表。这张表至少包含三列：SN、MAC1、MAC2（如果有双网口）。MAC的生成规则要提前定好，比如从某个起始地址开始递增，确保不重复。SN同理。

我的习惯是用Excel维护这张表，然后用Python脚本生成工具能识别的格式。为什么不直接在工具里手填？因为手填一百块板子必然出错，而且无法追溯哪块板子写了哪个号。分配表是量产的"账本"，丢了就麻烦了。

提示：MAC地址的前三字节（OUI）如果是购买的，务必记录好，不要和别家冲突。如果是内部测试用，可以用本地管理地址（第二字节的bit1置1），避免和公网设备冲突。

4. 单板写号实操：从配置文件到点击写入

4.1 配置文件的字段逐项拆解

RKDevInfoWriteTool的配置通常是一个ini或xml文件，里面定义了要写入的字段和对应的存储位置。以常见的配置为例，核心字段包括：

• Vendor：厂商名，字符串，长度有限制，别写太长。
• Product：产品型号。
• SerialNumber：SN，字符串。
• MAC：以太网MAC，格式通常是00:11:22:33:44:55。
• WifiMAC：WiFi MAC，如果板子有WiFi模块。
• IMEI：如果板子有4G模块才需要。

每个字段在配置文件里对应一个偏移地址和长度。这些值必须和固件里的定义一致。我建议第一次配置时，直接向核心板厂商要一份"能用的"配置文件，然后在它基础上改，不要从零写。

4.2 单板写入的完整步骤

假设驱动已装好、配置文件已确认、板子已进入Loader模式，操作流程如下：

1. 打开RKDevInfoWriteTool，工具会自动识别到设备，界面下方显示"Found One Rockusb Device"之类。
2. 点击"打开配置"或类似按钮，加载你的配置文件。
3. 在对应输入框里填入这块板子的SN、MAC等信息。如果是单板调试，手填即可。
4. 点击"写入"或"Write"按钮，等待进度条走完，提示成功。
5. 断电重启板子，进系统用ifconfig看MAC是否生效，用cat /proc/device-tree/serial-number或厂商提供的读取接口看SN。

这里有个细节：有些版本的工控板，MAC写入后需要重启才生效，因为内核在启动早期就把MAC读走了。如果你写完不重启就查，可能还是旧的随机MAC，别慌，重启一次再看。

4.3 写完之后怎么验证

验证分两层。第一层是工具层面：重新打开工具，点"读取"，看能不能把刚写的数据读回来。第二层是系统层面：进Linux后，用ip link show看网口MAC，用cat /sys/class/net/eth0/address确认。SN的读取路径因厂商而异，有的在/proc/device-tree/下，有的通过私有ioctl，问清楚厂商。

如果读回来是空的或者全F，先别怀疑板子坏，九成是配置文件偏移不对，或者写的时候板子没真正进入可写状态。回到3.2节重新确认配置。

5. 批量烧录方案：从手工到自动化的三条路

5.1 为什么批量不能靠手填

一块板子手填三十秒，一千块就是八个多小时，还不算出错返工。批量写号的核心诉求是：自动读取分配表、自动逐板写入、自动记录结果。RKDevInfoWriteTool本身有命令行版本，这是自动化的基础。

5.2 方案一：命令行工具+批处理脚本

瑞芯微的写号工具通常带一个命令行可执行文件，参数大致是：

RKDevInfoWriteTool.exe -c config.ini -s SN12345 -m 00:11:22:33:44:55

你可以写一个Windows批处理或PowerShell脚本，从CSV分配表里逐行读取SN和MAC，调用命令行工具写入，然后把结果追加到日志文件。这种方案适合小批量（几十到几百块），实现简单，不需要额外软件。

关键点：每次写入前要确认板子已连接且处于Loader模式。可以在脚本里加一个检测步骤，用工具的设备查询命令判断是否识别到设备，识别到才写，否则提示"请插板"。

5.3 方案二：Python脚本驱动，带分配表管理

如果批量规模上千，建议用Python写一个更完整的工具。逻辑是：

1. 读取Excel或CSV分配表，维护一个"已使用"标记。
2. 循环检测USB设备，发现新板子后，取下一个未使用的SN和MAC。
3. 调用命令行工具写入。
4. 写入成功后，把该行标记为已使用，并记录时间戳。
5. 写入失败则记录错误，跳过或重试。

这种方案的好处是分配表状态实时更新，不会重复写号。我实际用下来，配合一个简单的GUI（比如tkinter），产线工人只需要插板、等提示、拔板，效率很高。

5.4 方案三：产线工装+多路并行

大批量产线通常会用多路USB HUB，一次插多块板子，并行写号。但RKDevInfoWriteTool的命令行版本一般一次只处理一个设备，并行需要开多个进程，每个进程绑定不同的设备实例。这涉及到设备枚举和进程隔离，复杂度较高。

我的建议是：如果日产能在五百块以内，方案二足够；超过这个量，考虑上专业的产线写号工装，或者和核心板厂商合作定制。不要自己硬扛多路并行，调试成本可能超过收益。

6. 踩过的坑：偏移错位、MAC冲突与模式识别失败

6.1 写号成功但系统读不到：偏移错位的排查

这是最典型的问题。工具提示写入成功，但系统里MAC还是随机的。排查链路是这样的：

第一步，确认工具读回的数据是否正确。如果读回正确，说明数据确实写进了某个位置，但系统读的位置不对。第二步，对比固件里的vendor storage定义和工具配置文件的偏移。第三步，如果两者不一致，以固件为准，改工具配置。

我遇到过一次，核心板厂商给的配置文件是给旧版SDK用的，新版SDK把vendor分区往后挪了，结果写进去的数据落在了一个废弃区域。改配置后一次通过。所以配置文件一定要和当前固件版本匹配，这是铁律。

6.2 MAC地址重复导致的网络异常

批量写号最怕MAC重复。两块板子MAC一样，插到同一交换机上，网络会时通时断，排查起来非常痛苦。避免方法就是5.3节说的分配表管理，确保每个MAC只用一次。另外，写号完成后，建议抽检几块板子，用arping或直接看交换机MAC表，确认没有冲突。

注意：有些工控板有两个网口，对应两个MAC。分配表里要区分eth0和eth1，别写反了。写反了虽然不影响启动，但客户按标签接线时会发现MAC对不上。

6.3 板子进不了Loader模式的几种原因

批量写号时，最影响效率的就是板子识别不到。常见原因：

• 板子没真正断电，电容余电导致模式没切换。解决：断电后等几秒再上电。
• Recovery键接触不良或按的时间不对。解决：确认按键时序，通常是上电前按住，上电后保持两秒。
• USB线或HUB供电不足。解决：用带电源的HUB，别用无源HUB带太多设备。
• 驱动被其他软件占用。解决：关掉可能占用Rockusb设备的其他工具。

这些看起来是小事，但产线上每块板子多花十秒，一天下来就是几个小时。

7. 几个让批量写号更稳的实操习惯

第一个习惯：先小批量试产再放量。拿到新板子或新固件，先写十块，全部验证通过再批量。我见过直接上五百块结果偏移错了全部返工的案例，代价太大。

第二个习惯：分配表和写号日志分开存。分配表是"计划"，日志是"实际"。两者对不上时，以日志为准排查。日志至少记录时间、SN、MAC、结果、操作员。

第三个习惯：定期备份配置文件。配置文件丢了，重新配一遍很麻烦，尤其是偏移地址这种需要查固件的数据。我一般把配置文件和对应固件版本号一起存档。

第四个习惯：写号工位单独供电。不要和电烙铁、电机等大功率设备共用插座，电压波动可能导致USB通信中断，写入失败。

第五个习惯：MAC地址预留余量。比如计划一千块，分配表里准备一千二百个MAC，留出返工和测试的余量。MAC用完了再申请很麻烦。

这些习惯看起来琐碎，但都是实际产线里用返工和加班换来的。RK3568工控主板的写号本身不复杂，复杂的是批量场景下的稳定性和可追溯性。把工具用对、把配置对准、把流程理顺，这件事就能从"每次都要折腾"变成"插上就能走"的常规工序。