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模式。工具作用对象数据是否逐板不同风险等级RKDevTool整机镜像boot/rootfs/parameter等否统一高刷错可能变砖RKDevInfoWriteToolvendor storage信息分区是逐板唯一低不影响系统启动理解这个分工后面配置和批量操作才不会乱。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产品型号。SerialNumberSN字符串。MAC以太网MAC格式通常是00:11:22:33:44:55。WifiMACWiFi MAC如果板子有WiFi模块。IMEI如果板子有4G模块才需要。每个字段在配置文件里对应一个偏移地址和长度。这些值必须和固件里的定义一致。我建议第一次配置时直接向核心板厂商要一份能用的配置文件然后在它基础上改不要从零写。4.2 单板写入的完整步骤假设驱动已装好、配置文件已确认、板子已进入Loader模式操作流程如下打开RKDevInfoWriteTool工具会自动识别到设备界面下方显示Found One Rockusb Device之类。点击打开配置或类似按钮加载你的配置文件。在对应输入框里填入这块板子的SN、MAC等信息。如果是单板调试手填即可。点击写入或Write按钮等待进度条走完提示成功。断电重启板子进系统用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写一个更完整的工具。逻辑是读取Excel或CSV分配表维护一个已使用标记。循环检测USB设备发现新板子后取下一个未使用的SN和MAC。调用命令行工具写入。写入成功后把该行标记为已使用并记录时间戳。写入失败则记录错误跳过或重试。这种方案的好处是分配表状态实时更新不会重复写号。我实际用下来配合一个简单的GUI比如tkinter产线工人只需要插板、等提示、拔板效率很高。5.4 方案三产线工装多路并行大批量产线通常会用多路USB HUB一次插多块板子并行写号。但RKDevInfoWriteTool的命令行版本一般一次只处理一个设备并行需要开多个进程每个进程绑定不同的设备实例。这涉及到设备枚举和进程隔离复杂度较高。我的建议是如果日产能在五百块以内方案二足够超过这个量考虑上专业的产线写号工装或者和核心板厂商合作定制。不要自己硬扛多路并行调试成本可能超过收益。方案适用规模实现难度是否需额外开发命令行批处理200块/批低少量脚本Python分配表200-1000块/批中中等多路并行工装1000块/批高较多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工控主板的写号本身不复杂复杂的是批量场景下的稳定性和可追溯性。把工具用对、把配置对准、把流程理顺这件事就能从每次都要折腾变成插上就能走的常规工序。