1. Rockchip 写号工具与 U-Boot 以太网 MAC 处理机制解析
在嵌入式Linux开发中，以太网MAC地址的管理是一个看似简单但实际复杂的问题。Rockchip平台通过VendorStorage机制提供了一套完整的MAC地址读写方案，本文将深入剖析这套机制的技术实现细节。
1.1 VendorStorage 架构概述
VendorStorage是Rockchip平台特有的小型键值存储系统，位于存储介质的固定偏移位置。它的核心特点包括：
- 采用ID-Value的存储模型，每个条目通过16位ID标识
- 支持多种存储介质，包括EMMC、NAND、SPI NOR等
- 提供读写接口：
vendor_storage_read()和vendor_storage_write() - 典型存储内容包括：序列号(SN_ID)、WiFi MAC(WIFI_MAC_ID)、以太网MAC(LAN_MAC_ID)等
在RK3576平台中，VendorStorage的实现位于arch/arm/mach-rockchip/vendor.c，通过rockchip_get_bootdev()获取当前启动介质信息后，在介质特定位置维护这块存储区域。
1.2 MAC地址相关关键定义
在Rockchip的U-Boot实现中，与MAC地址相关的关键定义如下：
c复制// arch/arm/include/asm/arch-rockchip/vendor.h
#define SN_ID 1 // 序列号
#define WIFI_MAC_ID 2 // WiFi MAC地址
#define LAN_MAC_ID 3 // 以太网MAC地址(本文重点)
// arch/arm/mach-rockchip/board.c
#define MAX_ETHERNET 0x2 // 最大支持以太网口数量
#define ARP_HLEN 6 // MAC地址长度(字节)
#define ARP_HLEN_ASCII 17 // MAC地址字符串形式长度(包括冒号)
MAC地址在VendorStorage中的存储格式为原始二进制，对于多网口情况，采用连续存储方式：
- 单网口：6字节
- 双网口：12字节(前6字节为eth0，后6字节为eth1)
2. 写号工具写入以太网MAC的完整流程
2.1 设备进入Loader模式
Rockchip设备进入Loader模式通常有以下几种方式：
- BootROM检测到特定引脚状态(如Recovery按键按下)
- 通过烧录工具发送复位命令
- U-Boot环境中执行特定命令
进入Loader模式后，U-Boot以RockUSB Gadget身份枚举，相关驱动位于：
drivers/usb/gadget/f_rockusb.c- 使用SCSI传输协议变种实现自定义命令
2.2 RockUSB协议命令处理
PC端工具通过RockUSB协议与设备通信，核心命令处理流程：
c复制// drivers/usb/gadget/f_rockusb.c
rkusb_cmd_process(struct fsg_common *common, struct fsg_buffhd *bh, int *reply)
{
switch (common->cmnd[0]) { // 命令字
case RKUSB_VS_WRITE: // VendorStorage写入
*reply = rkusb_do_vs_write(common);
rc = RKUSB_RC_FINISHED;
break;
case RKUSB_VS_READ: // VendorStorage读取
*reply = rkusb_do_vs_read(common);
rc = RKUSB_RC_FINISHED;
break;
// 其他命令处理...
}
}
2.3 MAC地址写入过程详解
当PC工具需要写入MAC地址时，完整的处理链条如下：
-
PC工具发送RKUSB_VS_WRITE命令，指定：
- type=0(VendorStorage操作)
- id=LAN_MAC_ID(3)
- 数据区包含MAC二进制内容
-
U-Boot端接收数据帧，结构为：
c复制struct vendor_item { u16 id; // 条目ID(LAN_MAC_ID) u16 offset; // 保留 u16 size; // 数据大小(6或12字节) u8 data[0];// 实际MAC数据 }; -
调用vendor_storage_write写入存储介质：
c复制vendor_storage_write(vhead->id, (char __user *)data, vhead->size); -
写入位置由存储介质决定：
- EMMC: 通常放在user分区前的保留区域
- NAND: 在MTD分区中预留固定偏移
实际开发中发现：某些型号的EMMC芯片需要在写入后执行sync操作才能确保数据持久化，这是容易忽略的一个细节。
3. U-Boot启动时MAC地址处理机制
3.1 初始化调用栈
MAC地址处理发生在U-Boot的board_late_init阶段：
c复制board_late_init()
→ rockchip_set_ethaddr()
→ vendor_storage_read(LAN_MAC_ID, ...)
→ 校验并生成MAC
→ env_set("ethaddr", ...)
关键配置选项：
- CONFIG_ROCKCHIP_VENDOR_PARTITION: 启用VendorStorage支持
- CONFIG_ROCKCHIP_SET_ETHADDR: 启用自动MAC设置
3.2 MAC地址生成算法
当VendorStorage中没有有效MAC时，U-Boot会按以下规则生成：
-
第一个网口(eth0):
c复制net_random_ethaddr(ðaddr[0]);生成的MAC满足：
- 本地管理地址(第2位为1)
- 非多播地址(第1位为0)
-
后续网口(eth1等):
c复制memcpy(ðaddr[i], ðaddr[i-1], 6); ethaddr[i][0] |= 0x02; // 设置本地管理位 ethaddr[i][0] += (i << 2); // 增加偏移避免冲突
这种设计确保：
- 同一设备的多个网口MAC处于相近地址段
- 不同设备间MAC冲突概率极低
3.3 环境变量设置
有效的MAC地址会被设置到U-Boot环境变量：
c复制snprintf(buf, sizeof(buf), "%pM", ðaddr[i]);
env_set(i == 0 ? "ethaddr" : "eth1addr", buf);
环境变量格式为常见的"xx:xx:xx:xx:xx:xx"字符串形式，网络驱动初始化时会读取这些变量配置硬件寄存器。
4. MAC地址读取与调试技巧
4.1 PC工具读取流程
-
发送RKUSB_VS_READ命令，指定：
- type=0(VendorStorage)
- id=LAN_MAC_ID(3)
-
解析返回数据：
- vhead->size: 实际数据长度
- data区域: 原始MAC字节
4.2 常见问题排查指南
问题1: 写入后读取不到
可能原因：
- VendorStorage分区未正确预留
- 存储介质写保护未解除
- 写入后未正确同步
解决方法：
- 检查内核dmesg中VendorStorage初始化日志
- 确认存储介质写保护引脚状态
- 在写入后添加sync操作
问题2: MAC地址随机变化
可能原因：
- VendorStorage读取失败
- MAC校验未通过(is_valid_ethaddr返回false)
解决方法：
- 在rockchip_set_ethaddr()中添加调试打印：
c复制printf("Vendor read ret=%d, MAC=%pM\n", ret, ethaddr); - 检查硬件CRC校验是否启用
问题3: 多网口MAC重复
可能原因：
- MAX_ETHERNET配置不正确
- 生成算法未正确执行
解决方法：
- 确认MAX_ETHERNET与实际网口数一致
- 检查生成的MAC地址差异位：
c复制printf("eth%d MAC: %pM\n", i, ðaddr[i*6]);
4.3 开发建议
-
生产环境建议：
- 在烧录镜像前预先写入MAC地址
- 使用OTP或efuse存储基地址，提高安全性
-
调试技巧：
bash复制# U-Boot命令行查看MAC printenv ethaddr eth1addr # 强制重新生成MAC setenv ethaddr; setenv eth1addr; saveenv -
代码修改建议：
- 如需自定义MAC生成算法，可重写rockchip_set_ethaddr()
- 支持从DTB读取预设MAC地址作为后备方案
5. 底层机制深度解析
5.1 VendorStorage物理布局
以EMMC为例，典型分区布局：
code复制| Bootloader | VendorStorage | Reserved | Userdata |
VendorStorage通常占用64KB空间，结构如下：
code复制Offset Size Description
0x0000 4KB Header(magic, version, crc)
0x1000 60KB Item存储区
每个Item的结构：
c复制struct vendor_item {
u16 id; // 条目ID
u16 offset; // 在存储区内的偏移
u16 size; // 数据大小
u16 flag; // 标志位
u32 reserved; // 保留
};
5.2 MAC地址校验逻辑
is_valid_ethaddr()的实现细节：
c复制bool is_valid_ethaddr(const u8 *addr)
{
// 非全0
if (!(addr[0] | addr[1] | addr[2] | addr[3] | addr[4] | addr[5]))
return false;
// 非广播
if ((addr[0] & addr[1] & addr[2] & addr[3] & addr[4] & addr[5]) == 0xff)
return false;
// 多播位检查
if (addr[0] & 0x01)
return false;
return true;
}
5.3 多平台兼容性考虑
不同Rockchip芯片的差异处理：
- RK3566/RK3568: VendorStorage位于EMMC的IDBLK区域
- RK3588: 支持RPMB安全存储作为备选
- RV1106: 使用SPI NOR专用区域
在移植时需要注意：
- 确认bootdev类型获取接口
- 检查存储介质偏移量定义
- 验证CRC校验算法兼容性
6. 高级应用场景
6.1 批量生产方案
大规模生产时的优化策略：
- 预生成MAC地址池
- 使用高速写号工具链：
code复制
PC端工具 → 交换机 → 多设备并行烧录 - 日志记录与防重放机制
6.2 安全增强方案
提升MAC地址安全性的方法：
- 结合OTP/efuse存储根密钥
- 实现MAC地址加密存储
- 添加数字签名验证
6.3 故障恢复方案
当VendorStorage损坏时的恢复流程：
- 从备份分区读取
- 通过SN计算衍生MAC
- 提供恢复模式专用固件
在实际项目中，我们曾遇到因EMMC寿命到期导致VendorStorage区域读写失败的情况。最终的解决方案是在U-Boot中实现多级回退机制：
- 优先读取VendorStorage
- 失败时尝试读取备份分区
- 最后使用SN生成的确定性MAC
这种设计确保了设备在各种异常情况下都能获得可用的网络标识。