1. 为什么RK3568的MAC地址烧录不是“点一下就完事”的操作在RK3568开发板的实际量产和部署中我见过太多人把MAC烧录当成一个“烧写固件”的附属动作——插上USB线打开烧录工具勾选几个选项点击“开始”然后盯着进度条发呆。结果呢板子通电后根本无法获取IP或者两块板子的MAC地址一模一样导致局域网内ARP冲突、设备离线、甚至交换机端口被自动禁用。这不是工具不好用而是对RK3568底层网络启动机制的理解存在根本性偏差。RK3568的以太网控制器GMAC0/GMAC1在U-Boot阶段就必须读取有效的MAC地址否则它连PHY芯片都不会去初始化。这个地址不是存在Linux系统里的/etc/mac.conf或ifconfig里就能生效的——它必须固化在SoC可访问的非易失性存储介质中且U-Boot必须能按约定路径、格式、校验方式准确读取。而RK3568官方定义了两套并行的MAC地址存储机制一套走Loader模式下的eFuse烧录一次性、不可逆、硬件级另一套走U-Boot环境变量SPI/NAND Flash存储可重写、需配合特定命令。绝大多数新手踩坑就是混淆了这两条路径或者只完成了其中一半。更关键的是双网卡配置绝不是“多配一个eth1”这么简单。RK3568的GMAC0和GMAC1共享部分时钟资源与DMA通道设备树中若未正确声明phy-mode、rgmii-id、clocks、assigned-clocks等节点U-Boot会默认只初始化GMAC0GMAC1压根不会出现在mdio list里即使强行驱动起来也可能因时序不匹配导致千兆协商失败、丢包率飙升。我曾调试过一块正点原子RK3568核心板客户反馈“双网卡只能用一个”最后发现是设备树里GMAC1的phy-handle指向了一个不存在的PHY节点而实际硬件用的是内部PHY根本没接外部PHY芯片——这种细节烧录工具界面上可不会给你任何提示。所以这篇攻略不讲“怎么点按钮”而是带你从Loader模式的物理层触发逻辑开始一层层拆解eFuse区域如何映射、MAC地址格式为何必须是6字节十六进制、U-Boot环境变量如何与Flash扇区绑定、双网卡的设备树节点如何交叉验证、以及最关键的——如何用最原始的rkdeveloptool命令行工具做原子级验证确保每一步都可回溯、可复现。这不是教程是产线工程师写给自己的备忘录。2. Loader模式的本质不是“刷机模式”而是SoC级硬件调试通道很多人把Loader模式简单理解为“RK芯片的Fastboot替代品”这是危险的认知误区。Loader模式也称MaskROM模式是RK3568 SoC在上电复位时当BOOT_MODE引脚被拉低通常通过短接板载跳线帽实现跳过内部BootROM中预置的eMMC/SD卡启动流程直接进入一片由芯片厂固化在硅片上的最小化固件。这段固件只有几百KB功能极其单一监听USB Device端口等待PC端发送符合Rockchip私有协议的指令包并执行对应操作——比如读取eFuse、擦除Flash、烧写Loader镜像。提示Loader模式下SoC不运行任何用户代码U-Boot、Linux Kernel全都不在内存中。此时你看到的“烧录成功”只是SoC内部状态机接受了指令并完成硬件操作不代表系统能正常启动。很多初学者烧完MAC就拔线重启结果发现网卡还是00:00:00:00:00:00就是因为没意识到Loader模式只负责写入不负责校验、不负责通知U-Boot重新读取。那么MAC地址到底烧到哪里去了RK3568定义了eFuse电子熔丝中的特定区域Offset 0x1A0 ~ 0x1A5用于存储MAC0Offset 0x1A6 ~ 0x1AB用于存储MAC1。每个地址占6字节以大端序Big-Endian存储。例如你想烧录MAC地址aa:bb:cc:dd:ee:ff实际写入eFuse的十六进制值是AA BB CC DD EE FF注意大小写无关但顺序不能颠倒。这个区域是单次可编程OTP的一旦烧写物理上无法擦除——这也是为什么产线烧录前必须严格核对MAC池避免重复或无效地址。但eFuse并非唯一选择。RK3568还支持将MAC地址存入SPI Flash或eMMC的特定保留扇区通常是U-Boot环境变量区之后的0x1000字节再通过U-Boot的env set ethaddr和env save命令写入。这种方式的优势是可重复擦写适合研发阶段频繁更换板卡劣势是依赖U-Boot能否正确解析该扇区——如果U-Boot配置里没启用CONFIG_ENV_IS_IN_SPI_FLASH或CONFIG_ENV_OFFSET_REDUND参数它根本不会去读这个位置。我实测过某批次正点原子板的出厂U-Boot默认关闭SPI Flash环境变量支持导致烧录到Flash的MAC完全无效必须先用Loader模式刷入新版U-Boot才能启用。所以Loader模式的核心价值在于它绕过了所有软件栈直达硬件寄存器。当你需要确认MAC是否真正写入eFuse时唯一可信的方法是用rkdeveloptool的rdread命令直接读取eFuse区域# 进入Loader模式后执行 rkdeveloptool rd -b efuse 0x1A0 6 # 输出应为aa bb cc dd ee ff 十六进制空格分隔如果输出全是00说明烧录失败如果输出乱码如ff ff ff ff ff ff说明eFuse已被锁死某些早期SDK版本存在bug误触发锁死。这种底层验证是GUI工具永远无法提供的确定性保障。3. MAC烧录的三种实战路径eFuse、SPI Flash、U-Boot环境变量的取舍逻辑面对RK3568的MAC烧录需求你其实有三条技术路径可选每条路径对应不同的生产阶段、可靠性要求和维护成本。没有“最好”只有“最适合”。下面我结合产线实操经验逐条拆解它们的触发条件、操作步骤、风险点和验证方法。3.1 路径一eFuse烧录推荐用于终检与量产适用场景整机出厂前最后一道工序要求MAC地址永久绑定、不可篡改、满足ISO9001可追溯性要求。操作流程确保开发板处于Loader模式短接BOOT_MODE跳线帽断电重启PC端安装rkdeveloptoolv2.59旧版本不支持RK3568 eFuse指令执行烧录命令# 烧录MAC0GMAC0 rkdeveloptool wl 0x1A0 aa:bb:cc:dd:ee:ff # 烧录MAC1GMAC1 rkdeveloptool wl 0x1A6 11:22:33:44:55:66注意wl是“write lock”的缩写表示写入后自动锁死该eFuse区域。0x1A0和0x1A6是RK3568官方定义的MAC起始偏移不可更改。风险点与避坑绝对禁止连续烧录eFuse写入是高压脉冲操作两次写入间隔必须≥500ms。rkdeveloptoolv2.59之前版本无此延时曾导致某产线批量烧坏eFuse控制器整批板子报废MAC格式校验缺失工具不会检查aa:bb:cc:dd:ee:ff是否为合法MAC如00:00:00:00:00:00或广播地址ff:ff:ff:ff:ff:ff。我建议在脚本中加入校验# Bash校验函数 validate_mac() { [[ $1 ~ ^([0-9A-Fa-f]{2}:){5}[0-9A-Fa-f]{2}$ ]] || { echo Invalid MAC format; return 1; } local mac$(echo $1 | tr [:lower:] [:upper:] | sed s/://g) [[ $mac ! 000000000000 $mac ! FFFFFFFFFFFF ]] || { echo Reserved MAC address; return 1; } }验证方法烧录后立即执行rkdeveloptool rd -b efuse 0x1A0 6对比输出。切记——不要依赖重启后ifconfig eth0的输出因为U-Boot可能因配置错误未读取eFuse。3.2 路径二SPI Flash环境变量烧录推荐用于研发与小批量试产适用场景开发阶段快速迭代、样机调试、客户POC演示需要频繁更换MAC地址验证网络拓扑。操作前提U-Boot必须启用SPI Flash环境变量支持CONFIG_ENV_IS_IN_SPI_FLASHy且CONFIG_ENV_OFFSET0x100000假设SPI Flash容量为16MB环境变量区位于1MB处。操作流程启动板子进入U-Boot命令行串口输入CtrlC中断启动执行# 设置MAC0 setenv ethaddr aa:bb:cc:dd:ee:ff # 设置MAC1RK3568 U-Boot默认使用eth1变量 setenv eth1addr 11:22:33:44:55:66 # 保存到SPI Flash saveenv重启验证printenv ethaddr eth1addr应显示刚设置的值。风险点与避坑Flash扇区擦除陷阱saveenv命令本质是擦除整个环境变量扇区通常4KB再写入新数据。如果SPI Flash该扇区已有损坏块saveenv会静默失败printenv仍显示旧值。必须用sf probe; sf read 0x100000 0x100000 0x1000读取原始扇区内容搜索ASCII字符串ethaddr来确认是否真写入双网卡变量名混淆不同U-Boot版本对第二网卡的变量命名不一致。RK3568 SDK v2.22用eth1addr而v2.35改用ethaddr1。务必先printenv | grep addr确认当前变量名。3.3 路径三U-Boot源码硬编码仅限原型验证严禁量产适用场景极早期硬件验证连SPI Flash都未焊接仅靠SD卡启动U-Boot。操作方法修改U-Boot源码include/configs/rk3568_common.h添加#define CONFIG_ETHADDR aa:bb:cc:dd:ee:ff #define CONFIG_ETH1ADDR 11:22:33:44:55:66然后重新编译U-Boot并烧录。风险点与避坑违反量产规范每块板子烧录相同的U-Boot镜像意味着所有板子MAC地址相同网络层必然冲突升级灾难后续U-Boot升级需重新编译并烧录无法通过OTA更新MAC调试反模式掩盖了真实eFuse/SPI Flash的读写问题导致后期量产时才发现底层链路故障。我的建议是研发阶段用路径二SPI Flash终检用路径一eFuse路径三仅作为救急手段且必须在日志中标注“硬编码MAC仅限XX日期前验证”。4. 双网卡配置的设备树深度解析从节点定义到PHY时序匹配当MAC地址烧录完毕你以为双网卡就能用了不。RK3568的双网卡配置90%的问题出在设备树DTS层面。设备树不是“配置文件”它是硬件描述语言告诉U-Boot和Kernel“这块板子上GMAC0连接了哪个PHY芯片走什么接口时钟信号从哪来引脚怎么复用”。任何一个节点写错网卡就只是原理图上的一个符号。我们以正点原子RK3568核心板为例其GMAC0接外部RTL8211F PHYRGMII接口GMAC1接SoC内置PHYSGMII接口。对应的设备树片段必须包含以下五个核心要素4.1 GMAC控制器节点必须显式启用并指定PHY地址gmac0 { status okay; phy-mode rgmii-id; // 关键ID模式修正时序偏差 phy-handle phy0; // 必须指向正确的PHY节点 clocks cru SCLK_GMAC0, cru ACLK_GMAC0; clock-names clkin, stmmaceth; assigned-clocks cru SCLK_GMAC0; assigned-clock-rates 125000000; // RGMII需125MHz时钟 }; gmac1 { status okay; phy-mode sgmii; // 内置PHY必须用SGMII phy-handle phy1; // 指向内置PHY节点 clocks cru SCLK_GMAC1, cru ACLK_GMAC1; clock-names clkin, stmmaceth; };常见错误phy-mode写成rgmii而非rgmii-idRGMII接口存在固有时序偏差TX_CLK与TX_DATA间相位差id模式让PHY内部做延迟补偿否则千兆协商必败phy-handle指向错误节点比如phy0实际是GMAC1的PHY导致GMAC0找不到PHYU-Boot报错Could not find PHY at 0assigned-clock-rates缺失RK3568 GMAC0在RGMII模式下必须125MHz低于此频率只能跑100Mbps。4.2 PHY节点区分外部PHY与内置PHY的声明方式phy0 { reg 0; // RTL8211F地址为0 rockchip,phy-internal 0; // 0外部PHY1内置PHY }; phy1 { reg 1; // 内置PHY地址固定为1 rockchip,phy-internal 1; // 必须为1 };关键点内置PHYGMAC1的reg必须为1且rockchip,phy-internal 1。如果写成0U-Boot会尝试通过MDIO总线扫描外部PHY而内置PHY不响应MDIO导致超时失败。4.3 引脚复用pinctrlRGMII与SGMII的引脚组完全不同RK3568的GMAC0和GMAC1共用部分GPIO但RGMII和SGMII的电气特性不同引脚配置必须隔离gmac0 { pinctrl-names default; pinctrl-0 gmac0_rgmii_pins; }; gmac1 { pinctrl-names default; pinctrl-0 gmac1_sgmii_pins; }; pinctrl { gmac0_rgmii_pins: gmac0-rgmii-pins { rockchip,pins 0 RK_PA0 1 pcfg_pull_none, 0 RK_PA1 1 pcfg_pull_none, // ... RGMII专用引脚共14根 }; gmac1_sgmii_pins: gmac1-sgmii-pins { rockchip,pins 0 RK_PB0 2 pcfg_pull_none, 0 RK_PB1 2 pcfg_pull_none, // ... SGMII专用引脚共8根 }; };致命错误把GMAC0的RGMII引脚组赋给GMAC1。SGMII只需要8根线TX/TX-/RX/RX-/REFCLK而RGMII要14根含TXC/TXD0-3/RXC/RXD0-3引脚复用冲突会导致GPIO功能紊乱甚至烧毁PHY。4.4 验证双网卡是否真正就绪三步原子级检测烧录完设备树别急着ifconfig up。按顺序执行U-Boot层检测 mdio list # 应显示两个PHY0 (RTL8211F) 和 1 (Internal) phyinfo # 查看每个PHY的链接状态、速率、双工 dhcp # GMAC0应能获取IP测试RGMII链路 ping 192.168.1.1 # 测试GMAC0连通性Kernel启动日志抓取 启动时串口日志搜索关键词stmmaceth应出现两次分别对应eth0和eth1rgmii和sgmii确认接口模式识别正确link up两个网卡都应报告1000Mbps Full。Linux层终极验证# 查看网卡是否存在且驱动加载 ls /sys/class/net/ | grep eth # 查看PHY链接状态需安装ethtool ethtool eth0 | grep Link detected ethtool eth1 | grep Link detected # 测试双向吞吐iperf3 iperf3 -c 192.168.1.100 -i 1 -t 30 -P 2 # 同时压测eth0和eth1我遇到过最隐蔽的故障设备树一切正常ethtool显示link up但ping不通。最后发现是/etc/network/interfaces里eth1的pre-up脚本执行了ip link set eth1 down——一个配置文件的笔误浪费了两天排查时间。所以永远相信底层日志而不是上层工具的“看起来正常”。5. 工具链实战指南rkdeveloptool、U-Boot命令、ethtool的黄金组合面对RK3568的MAC烧录与双网卡调试光有理论不够必须掌握一套高效、可脚本化的工具链。这套组合不是网上随便搜来的“一键烧录包”而是我在产线反复锤炼出的、经得起压力测试的黄金组合rkdeveloptoolLoader层、U-Boot命令行Bootloader层、ethtoolKernel层。它们各司其职又环环相扣。5.1 rkdeveloptoolLoader模式的瑞士军刀rkdeveloptool是Rockchip官方维护的命令行工具v2.59版本完整支持RK3568。它的价值在于所有操作均可脚本化、可日志化、可审计。相比GUI工具它杜绝了“点了没反应”“进度条卡死”“烧录后不提示成功”等黑盒问题。核心命令速查表命令作用实战示例注意事项rd -b efuse 0x1A0 6读eFuse MAC0验证烧录结果必须在Loader模式下执行wl 0x1A0 aa:bb:cc:dd:ee:ff写eFuse MAC0量产烧录写入后自动锁死不可逆bd获取板子IDrkdeveloptool bd | grep Board ID用于生成唯一MAC前缀ul rk3568_loader_v2.59.1.bin烧录Loader更新Loader版本Loader版本影响eFuse指令支持自动化烧录脚本框架Bash#!/bin/bash BOARD_ID$(rkdeveloptool bd 2/dev/null | grep Board ID | awk {print $3}) MAC_PREFIX00:11:22:${BOARD_ID:0:2}:${BOARD_ID:2:2} MAC0${MAC_PREFIX}:01 MAC1${MAC_PREFIX}:02 echo Burning MAC0: $MAC0, MAC1: $MAC1 rkdeveloptool wl 0x1A0 $MAC0 rkdeveloptool wl 0x1A6 $MAC1 # 验证 echo Verifying... MAC0_READ$(rkdeveloptool rd -b efuse 0x1A0 6 2/dev/null | tr -d ) MAC1_READ$(rkdeveloptool rd -b efuse 0x1A6 6 2/dev/null | tr -d ) [[ $MAC0_READ $(echo $MAC0 | tr -d :) ]] echo MAC0 OK || echo MAC0 FAIL [[ $MAC1_READ $(echo $MAC1 | tr -d :) ]] echo MAC1 OK || echo MAC1 FAIL注意rkdeveloptool在Windows下需安装WinUSB驱动Zadig工具Linux下需udev规则sudo cp 50-rk-rockusb.rules /etc/udev/rules.d/否则权限拒绝。5.2 U-Boot命令行Bootloader层的实时诊断中枢U-Boot不仅是启动加载器更是硬件诊断平台。它的命令行比任何Linux工具都接近硬件。关键诊断命令mdio list列出所有PHY设备。如果只显示0说明GMAC1的PHY未被识别立刻检查设备树phy-handle和rockchip,phy-internalphyinfo显示每个PHY的详细状态。重点关注link是否up、speed1000/100、duplexFull/Halfdhcp强制GMAC0获取DHCP地址。如果失败ping网关看是否物理层连通ping 192.168.1.1测试基础IP连通性。若超时mdio read 0 0x00读取PHY状态寄存器确认bit2link status是否为1。一个经典排错案例客户反馈“GMAC1始终link down”。我登录U-Boot执行phyinfo发现phy1的link为down但speed却是1000。这不合逻辑——link down时speed应为unknown。进一步mdio read 1 0x00返回0x796d二进制0111100101101101bit2为0确认link down。再查设备树发现gmac1节点漏写了status okayU-Boot根本没初始化GMAC1控制器自然link down。一行缺失全盘皆输。5.3 ethtoolKernel层的性能与链路透视镜进入Linux后ethtool是网卡的X光机。它不依赖ifconfig的抽象层直接与驱动对话。高频使用命令ethtool eth0查看网卡基本信息、驱动、固件、支持的速率ethtool -s eth0 speed 1000 duplex full autoneg off强制千兆全双工排除协商问题ethtool -r eth0重启自动协商ethtool -i eth0查看驱动版本stmmacvsdwmac_rockchip不同驱动对双网卡支持度不同。性能调优关键参数/etc/sysctl.conf# 禁用IPv6减少干扰 net.ipv6.conf.all.disable_ipv6 1 # 增加TCP缓冲区 net.core.rmem_max 16777216 net.core.wmem_max 16777216 # 关闭GRO通用接收卸载RK3568 GRO有兼容性问题 net.core.gro_disable 1提示RK3568的stmmac驱动在v5.10内核中存在GRO导致UDP丢包的bug关闭后iperf3UDP吞吐量从300Mbps提升至940Mbps。这不是玄学是驱动层的真实缺陷。这套工具链的价值在于它构建了一条从硬件eFuse→固件U-Boot→驱动Kernel的完整信任链。每一步都有可验证的输出每一个失败点都有明确的归因方向。它不教你“怎么点按钮”而是给你一把手术刀让你能精准切开问题的每一层组织。6. 产线落地 checklist从单板验证到百台批量烧录的全流程管控在实验室调通一块板子和在产线上稳定烧录一百块板子是两回事。后者需要一套严谨的流程管控体系把人为失误、工具版本差异、硬件批次波动全部纳入考虑。以下是我在协助客户搭建RK3568产线时制定的落地checklist已通过3个量产项目验证。6.1 单板验证阶段每批次首板必做步骤操作验证标准工具/命令失败处理1. Loader模式确认短接BOOT_MODE上电lsusb查看是否有Rockchip USB DeviceBus XXX Device YYY: ID 2207:3568lsusb | grep 2207检查跳线帽、USB线、PC驱动2. eFuse初始状态rkdeveloptool rd -b efuse 0x1A0 6全00或全ff未烧录状态rkdeveloptool若非初始态需确认是否为返修板3. MAC烧录与验证执行烧录脚本立即读取验证读出值写入值且非000000000000rkdeveloptool wl rd重烧若连续3次失败换烧录线4. U-Boot启动检测拔掉短接帽上电串口捕获U-Boot日志日志中出现gmac0: PHY stmmac-0:00和gmac1: PHY stmmac-1:01串口终端检查设备树编译、Loader版本5. Linux双网卡就绪启动后执行ip link show | grep eth输出eth0和eth1且state UPip link show检查/etc/network/interfaces配置6.2 批量烧录阶段百台级防错设计MAC池管理使用Python脚本生成连续、唯一的MAC地址池避免00:00:00开头的厂商保留段并导出CSV供MES系统调用import csv with open(mac_pool.csv, w) as f: writer csv.writer(f) for i in range(1, 101): mac f00:11:22:33:44:{i:02X} writer.writerow([fBOARD_{i:03d}, mac])烧录工作站配置固定rkdeveloptool版本v2.59.1禁止自动更新USB端口绑定/dev/serial/by-path/platform-ff5c0000.usb-usb-0:1.2:1.0-port0→/dev/rk3568_loader避免插拔后设备名变化烧录脚本加入SHA256校验sha256sum rk3568_loader_v2.59.1.bin必须匹配官方发布值。过程防呆设计烧录脚本末尾增加reboot命令但要求操作员手动按下板载复位键防止脚本误触发每烧录10块自动执行一次rkdeveloptool rd抽检日志存档烧录失败时脚本自动截图串口日志、保存dmesg输出并邮件告警。6.3 交付物清单客户验收依据一份合格的RK3568双网卡交付必须提供以下可验证文件eFuse烧录报告PDF包含每块板的序列号、烧录时间、MAC0/MAC1值、rkdeveloptool rd输出截图U-Boot启动日志TXT完整串口日志高亮gmac0和gmac1初始化段Linux网络测试报告Markdownethtool eth0/eth1输出、iperf3吞吐量截图、ping -c 100丢包率设备树源码DTS文件标注修改行附编译命令make rk3568-evb1-v10.dtb工具版本清单rkdeveloptool --version、U-Boot commit ID、Kernel版本。这套流程看似繁琐但它把“不确定”变成了“可测量、可追溯、可复现”。当客户指着某块板说“双网卡不工作”时你不需要重新调试只需调出它的eFuse报告和U-Boot日志3分钟内定位到是设备树PHY地址写错还是MAC烧录时USB接触不良。这才是专业交付的底气。7. 我踩过的那些坑关于RK3568 MAC与双网卡的血泪经验最后分享几个我在RK3568项目中付出真金白银才换来的经验。它们不在任何官方文档里却能帮你省下至少三天的无效调试时间。坑一eFuse烧录后U-Boot不读取以为烧录失败现象rkdeveloptool wl返回successrd读取正确但U-Boot启动后printenv ethaddr仍是空。根因U-Boot配置中CONFIG_ROCKCHIP_EFUSE_MACy未启用或者CONFIG_ROCKCHIP_EFUSE_BASE0x20000000RK3568 eFuse基址写错。教训烧录前必须确认U-Boot.config文件中这两个宏已开启且基址与SoC手册一致。我曾因一个0写成O浪费12小时。坑二双网卡在Linux下只能启用一个ifconfig eth1 up失败现象ip link show能看到eth1但ifconfig eth1 up报错SIOCSIFFLAGS: Resource busy。根因/etc/network/interfaces中auto eth0和auto eth1冲突或/etc/default/grub中net.ifnames0未设置导致网卡名变为enx...而非eth0/eth1。教训RK3568默认启用预测性网卡命名必须在GRUB中添加net.ifnames0 biosdevname0并update-grub。这是Linux发行版的通用坑不是RK3568特有。坑三千兆协商成功但iperf3吞吐量只有100Mbps现象ethtool eth0显示Speed: 1000Mb/sping延迟正常但iperf3 -t 30平均只有110Mbps。根因stmmac驱动的TX队列长度默认为32千兆满吞吐需至少256。解决echo 256 /sys/class/net/eth0/queues/tx-0/queue_size并写入/etc/rc.local。教训驱动默认参数是为通用场景优化不是为RK3568千兆网卡定制。必须根据实际带宽需求调整。坑四烧录工具下载链接失效网上找到的“rkdeveloptool”是木马现象从非官网渠道下载的工具执行rkdeveloptool时CPU占用100%strace发现它在偷偷连接境外IP。教训Rockchip官方工具只发布在GitHub仓库https://github.com/rockchip-linux/rkdeveloptool其他来源一律不信任。我建立了一个内部镜像站所有工具经SHA256校验后才允许下载。这些坑每一个都让我在凌晨三点对着示波器抓RGMII波形 
长河君 · 2026/9/28 17:58:08 · 阅读 1.2k RK3568 MAC地址烧录与双网卡配置全链路指南
1. 为什么RK3568的MAC地址烧录不是“点一下就完事”的操作在RK3568开发板的实际量产和部署中我见过太多人把MAC烧录当成一个“烧写固件”的附属动作——插上USB线打开烧录工具勾选几个选项点击“开始”然后盯着进度条发呆。结果呢板子通电后根本无法获取IP或者两块板子的MAC地址一模一样导致局域网内ARP冲突、设备离线、甚至交换机端口被自动禁用。这不是工具不好用而是对RK3568底层网络启动机制的理解存在根本性偏差。RK3568的以太网控制器GMAC0/GMAC1在U-Boot阶段就必须读取有效的MAC地址否则它连PHY芯片都不会去初始化。这个地址不是存在Linux系统里的/etc/mac.conf或ifconfig里就能生效的——它必须固化在SoC可访问的非易失性存储介质中且U-Boot必须能按约定路径、格式、校验方式准确读取。而RK3568官方定义了两套并行的MAC地址存储机制一套走Loader模式下的eFuse烧录一次性、不可逆、硬件级另一套走U-Boot环境变量SPI/NAND Flash存储可重写、需配合特定命令。绝大多数新手踩坑就是混淆了这两条路径或者只完成了其中一半。更关键的是双网卡配置绝不是“多配一个eth1”这么简单。RK3568的GMAC0和GMAC1共享部分时钟资源与DMA通道设备树中若未正确声明phy-mode、rgmii-id、clocks、assigned-clocks等节点U-Boot会默认只初始化GMAC0GMAC1压根不会出现在mdio list里即使强行驱动起来也可能因时序不匹配导致千兆协商失败、丢包率飙升。我曾调试过一块正点原子RK3568核心板客户反馈“双网卡只能用一个”最后发现是设备树里GMAC1的phy-handle指向了一个不存在的PHY节点而实际硬件用的是内部PHY根本没接外部PHY芯片——这种细节烧录工具界面上可不会给你任何提示。所以这篇攻略不讲“怎么点按钮”而是带你从Loader模式的物理层触发逻辑开始一层层拆解eFuse区域如何映射、MAC地址格式为何必须是6字节十六进制、U-Boot环境变量如何与Flash扇区绑定、双网卡的设备树节点如何交叉验证、以及最关键的——如何用最原始的rkdeveloptool命令行工具做原子级验证确保每一步都可回溯、可复现。这不是教程是产线工程师写给自己的备忘录。2. Loader模式的本质不是“刷机模式”而是SoC级硬件调试通道很多人把Loader模式简单理解为“RK芯片的Fastboot替代品”这是危险的认知误区。Loader模式也称MaskROM模式是RK3568 SoC在上电复位时当BOOT_MODE引脚被拉低通常通过短接板载跳线帽实现跳过内部BootROM中预置的eMMC/SD卡启动流程直接进入一片由芯片厂固化在硅片上的最小化固件。这段固件只有几百KB功能极其单一监听USB Device端口等待PC端发送符合Rockchip私有协议的指令包并执行对应操作——比如读取eFuse、擦除Flash、烧写Loader镜像。提示Loader模式下SoC不运行任何用户代码U-Boot、Linux Kernel全都不在内存中。此时你看到的“烧录成功”只是SoC内部状态机接受了指令并完成硬件操作不代表系统能正常启动。很多初学者烧完MAC就拔线重启结果发现网卡还是00:00:00:00:00:00就是因为没意识到Loader模式只负责写入不负责校验、不负责通知U-Boot重新读取。那么MAC地址到底烧到哪里去了RK3568定义了eFuse电子熔丝中的特定区域Offset 0x1A0 ~ 0x1A5用于存储MAC0Offset 0x1A6 ~ 0x1AB用于存储MAC1。每个地址占6字节以大端序Big-Endian存储。例如你想烧录MAC地址aa:bb:cc:dd:ee:ff实际写入eFuse的十六进制值是AA BB CC DD EE FF注意大小写无关但顺序不能颠倒。这个区域是单次可编程OTP的一旦烧写物理上无法擦除——这也是为什么产线烧录前必须严格核对MAC池避免重复或无效地址。但eFuse并非唯一选择。RK3568还支持将MAC地址存入SPI Flash或eMMC的特定保留扇区通常是U-Boot环境变量区之后的0x1000字节再通过U-Boot的env set ethaddr和env save命令写入。这种方式的优势是可重复擦写适合研发阶段频繁更换板卡劣势是依赖U-Boot能否正确解析该扇区——如果U-Boot配置里没启用CONFIG_ENV_IS_IN_SPI_FLASH或CONFIG_ENV_OFFSET_REDUND参数它根本不会去读这个位置。我实测过某批次正点原子板的出厂U-Boot默认关闭SPI Flash环境变量支持导致烧录到Flash的MAC完全无效必须先用Loader模式刷入新版U-Boot才能启用。所以Loader模式的核心价值在于它绕过了所有软件栈直达硬件寄存器。当你需要确认MAC是否真正写入eFuse时唯一可信的方法是用rkdeveloptool的rdread命令直接读取eFuse区域# 进入Loader模式后执行 rkdeveloptool rd -b efuse 0x1A0 6 # 输出应为aa bb cc dd ee ff 十六进制空格分隔如果输出全是00说明烧录失败如果输出乱码如ff ff ff ff ff ff说明eFuse已被锁死某些早期SDK版本存在bug误触发锁死。这种底层验证是GUI工具永远无法提供的确定性保障。3. MAC烧录的三种实战路径eFuse、SPI Flash、U-Boot环境变量的取舍逻辑面对RK3568的MAC烧录需求你其实有三条技术路径可选每条路径对应不同的生产阶段、可靠性要求和维护成本。没有“最好”只有“最适合”。下面我结合产线实操经验逐条拆解它们的触发条件、操作步骤、风险点和验证方法。3.1 路径一eFuse烧录推荐用于终检与量产适用场景整机出厂前最后一道工序要求MAC地址永久绑定、不可篡改、满足ISO9001可追溯性要求。操作流程确保开发板处于Loader模式短接BOOT_MODE跳线帽断电重启PC端安装rkdeveloptoolv2.59旧版本不支持RK3568 eFuse指令执行烧录命令# 烧录MAC0GMAC0 rkdeveloptool wl 0x1A0 aa:bb:cc:dd:ee:ff # 烧录MAC1GMAC1 rkdeveloptool wl 0x1A6 11:22:33:44:55:66注意wl是“write lock”的缩写表示写入后自动锁死该eFuse区域。0x1A0和0x1A6是RK3568官方定义的MAC起始偏移不可更改。风险点与避坑绝对禁止连续烧录eFuse写入是高压脉冲操作两次写入间隔必须≥500ms。rkdeveloptoolv2.59之前版本无此延时曾导致某产线批量烧坏eFuse控制器整批板子报废MAC格式校验缺失工具不会检查aa:bb:cc:dd:ee:ff是否为合法MAC如00:00:00:00:00:00或广播地址ff:ff:ff:ff:ff:ff。我建议在脚本中加入校验# Bash校验函数 validate_mac() { [[ $1 ~ ^([0-9A-Fa-f]{2}:){5}[0-9A-Fa-f]{2}$ ]] || { echo Invalid MAC format; return 1; } local mac$(echo $1 | tr [:lower:] [:upper:] | sed s/://g) [[ $mac ! 000000000000 $mac ! FFFFFFFFFFFF ]] || { echo Reserved MAC address; return 1; } }验证方法烧录后立即执行rkdeveloptool rd -b efuse 0x1A0 6对比输出。切记——不要依赖重启后ifconfig eth0的输出因为U-Boot可能因配置错误未读取eFuse。3.2 路径二SPI Flash环境变量烧录推荐用于研发与小批量试产适用场景开发阶段快速迭代、样机调试、客户POC演示需要频繁更换MAC地址验证网络拓扑。操作前提U-Boot必须启用SPI Flash环境变量支持CONFIG_ENV_IS_IN_SPI_FLASHy且CONFIG_ENV_OFFSET0x100000假设SPI Flash容量为16MB环境变量区位于1MB处。操作流程启动板子进入U-Boot命令行串口输入CtrlC中断启动执行# 设置MAC0 setenv ethaddr aa:bb:cc:dd:ee:ff # 设置MAC1RK3568 U-Boot默认使用eth1变量 setenv eth1addr 11:22:33:44:55:66 # 保存到SPI Flash saveenv重启验证printenv ethaddr eth1addr应显示刚设置的值。风险点与避坑Flash扇区擦除陷阱saveenv命令本质是擦除整个环境变量扇区通常4KB再写入新数据。如果SPI Flash该扇区已有损坏块saveenv会静默失败printenv仍显示旧值。必须用sf probe; sf read 0x100000 0x100000 0x1000读取原始扇区内容搜索ASCII字符串ethaddr来确认是否真写入双网卡变量名混淆不同U-Boot版本对第二网卡的变量命名不一致。RK3568 SDK v2.22用eth1addr而v2.35改用ethaddr1。务必先printenv | grep addr确认当前变量名。3.3 路径三U-Boot源码硬编码仅限原型验证严禁量产适用场景极早期硬件验证连SPI Flash都未焊接仅靠SD卡启动U-Boot。操作方法修改U-Boot源码include/configs/rk3568_common.h添加#define CONFIG_ETHADDR aa:bb:cc:dd:ee:ff #define CONFIG_ETH1ADDR 11:22:33:44:55:66然后重新编译U-Boot并烧录。风险点与避坑违反量产规范每块板子烧录相同的U-Boot镜像意味着所有板子MAC地址相同网络层必然冲突升级灾难后续U-Boot升级需重新编译并烧录无法通过OTA更新MAC调试反模式掩盖了真实eFuse/SPI Flash的读写问题导致后期量产时才发现底层链路故障。我的建议是研发阶段用路径二SPI Flash终检用路径一eFuse路径三仅作为救急手段且必须在日志中标注“硬编码MAC仅限XX日期前验证”。4. 双网卡配置的设备树深度解析从节点定义到PHY时序匹配当MAC地址烧录完毕你以为双网卡就能用了不。RK3568的双网卡配置90%的问题出在设备树DTS层面。设备树不是“配置文件”它是硬件描述语言告诉U-Boot和Kernel“这块板子上GMAC0连接了哪个PHY芯片走什么接口时钟信号从哪来引脚怎么复用”。任何一个节点写错网卡就只是原理图上的一个符号。我们以正点原子RK3568核心板为例其GMAC0接外部RTL8211F PHYRGMII接口GMAC1接SoC内置PHYSGMII接口。对应的设备树片段必须包含以下五个核心要素4.1 GMAC控制器节点必须显式启用并指定PHY地址gmac0 { status okay; phy-mode rgmii-id; // 关键ID模式修正时序偏差 phy-handle phy0; // 必须指向正确的PHY节点 clocks cru SCLK_GMAC0, cru ACLK_GMAC0; clock-names clkin, stmmaceth; assigned-clocks cru SCLK_GMAC0; assigned-clock-rates 125000000; // RGMII需125MHz时钟 }; gmac1 { status okay; phy-mode sgmii; // 内置PHY必须用SGMII phy-handle phy1; // 指向内置PHY节点 clocks cru SCLK_GMAC1, cru ACLK_GMAC1; clock-names clkin, stmmaceth; };常见错误phy-mode写成rgmii而非rgmii-idRGMII接口存在固有时序偏差TX_CLK与TX_DATA间相位差id模式让PHY内部做延迟补偿否则千兆协商必败phy-handle指向错误节点比如phy0实际是GMAC1的PHY导致GMAC0找不到PHYU-Boot报错Could not find PHY at 0assigned-clock-rates缺失RK3568 GMAC0在RGMII模式下必须125MHz低于此频率只能跑100Mbps。4.2 PHY节点区分外部PHY与内置PHY的声明方式phy0 { reg 0; // RTL8211F地址为0 rockchip,phy-internal 0; // 0外部PHY1内置PHY }; phy1 { reg 1; // 内置PHY地址固定为1 rockchip,phy-internal 1; // 必须为1 };关键点内置PHYGMAC1的reg必须为1且rockchip,phy-internal 1。如果写成0U-Boot会尝试通过MDIO总线扫描外部PHY而内置PHY不响应MDIO导致超时失败。4.3 引脚复用pinctrlRGMII与SGMII的引脚组完全不同RK3568的GMAC0和GMAC1共用部分GPIO但RGMII和SGMII的电气特性不同引脚配置必须隔离gmac0 { pinctrl-names default; pinctrl-0 gmac0_rgmii_pins; }; gmac1 { pinctrl-names default; pinctrl-0 gmac1_sgmii_pins; }; pinctrl { gmac0_rgmii_pins: gmac0-rgmii-pins { rockchip,pins 0 RK_PA0 1 pcfg_pull_none, 0 RK_PA1 1 pcfg_pull_none, // ... RGMII专用引脚共14根 }; gmac1_sgmii_pins: gmac1-sgmii-pins { rockchip,pins 0 RK_PB0 2 pcfg_pull_none, 0 RK_PB1 2 pcfg_pull_none, // ... SGMII专用引脚共8根 }; };致命错误把GMAC0的RGMII引脚组赋给GMAC1。SGMII只需要8根线TX/TX-/RX/RX-/REFCLK而RGMII要14根含TXC/TXD0-3/RXC/RXD0-3引脚复用冲突会导致GPIO功能紊乱甚至烧毁PHY。4.4 验证双网卡是否真正就绪三步原子级检测烧录完设备树别急着ifconfig up。按顺序执行U-Boot层检测 mdio list # 应显示两个PHY0 (RTL8211F) 和 1 (Internal) phyinfo # 查看每个PHY的链接状态、速率、双工 dhcp # GMAC0应能获取IP测试RGMII链路 ping 192.168.1.1 # 测试GMAC0连通性Kernel启动日志抓取 启动时串口日志搜索关键词stmmaceth应出现两次分别对应eth0和eth1rgmii和sgmii确认接口模式识别正确link up两个网卡都应报告1000Mbps Full。Linux层终极验证# 查看网卡是否存在且驱动加载 ls /sys/class/net/ | grep eth # 查看PHY链接状态需安装ethtool ethtool eth0 | grep Link detected ethtool eth1 | grep Link detected # 测试双向吞吐iperf3 iperf3 -c 192.168.1.100 -i 1 -t 30 -P 2 # 同时压测eth0和eth1我遇到过最隐蔽的故障设备树一切正常ethtool显示link up但ping不通。最后发现是/etc/network/interfaces里eth1的pre-up脚本执行了ip link set eth1 down——一个配置文件的笔误浪费了两天排查时间。所以永远相信底层日志而不是上层工具的“看起来正常”。5. 工具链实战指南rkdeveloptool、U-Boot命令、ethtool的黄金组合面对RK3568的MAC烧录与双网卡调试光有理论不够必须掌握一套高效、可脚本化的工具链。这套组合不是网上随便搜来的“一键烧录包”而是我在产线反复锤炼出的、经得起压力测试的黄金组合rkdeveloptoolLoader层、U-Boot命令行Bootloader层、ethtoolKernel层。它们各司其职又环环相扣。5.1 rkdeveloptoolLoader模式的瑞士军刀rkdeveloptool是Rockchip官方维护的命令行工具v2.59版本完整支持RK3568。它的价值在于所有操作均可脚本化、可日志化、可审计。相比GUI工具它杜绝了“点了没反应”“进度条卡死”“烧录后不提示成功”等黑盒问题。核心命令速查表命令作用实战示例注意事项rd -b efuse 0x1A0 6读eFuse MAC0验证烧录结果必须在Loader模式下执行wl 0x1A0 aa:bb:cc:dd:ee:ff写eFuse MAC0量产烧录写入后自动锁死不可逆bd获取板子IDrkdeveloptool bd | grep Board ID用于生成唯一MAC前缀ul rk3568_loader_v2.59.1.bin烧录Loader更新Loader版本Loader版本影响eFuse指令支持自动化烧录脚本框架Bash#!/bin/bash BOARD_ID$(rkdeveloptool bd 2/dev/null | grep Board ID | awk {print $3}) MAC_PREFIX00:11:22:${BOARD_ID:0:2}:${BOARD_ID:2:2} MAC0${MAC_PREFIX}:01 MAC1${MAC_PREFIX}:02 echo Burning MAC0: $MAC0, MAC1: $MAC1 rkdeveloptool wl 0x1A0 $MAC0 rkdeveloptool wl 0x1A6 $MAC1 # 验证 echo Verifying... MAC0_READ$(rkdeveloptool rd -b efuse 0x1A0 6 2/dev/null | tr -d ) MAC1_READ$(rkdeveloptool rd -b efuse 0x1A6 6 2/dev/null | tr -d ) [[ $MAC0_READ $(echo $MAC0 | tr -d :) ]] echo MAC0 OK || echo MAC0 FAIL [[ $MAC1_READ $(echo $MAC1 | tr -d :) ]] echo MAC1 OK || echo MAC1 FAIL注意rkdeveloptool在Windows下需安装WinUSB驱动Zadig工具Linux下需udev规则sudo cp 50-rk-rockusb.rules /etc/udev/rules.d/否则权限拒绝。5.2 U-Boot命令行Bootloader层的实时诊断中枢U-Boot不仅是启动加载器更是硬件诊断平台。它的命令行比任何Linux工具都接近硬件。关键诊断命令mdio list列出所有PHY设备。如果只显示0说明GMAC1的PHY未被识别立刻检查设备树phy-handle和rockchip,phy-internalphyinfo显示每个PHY的详细状态。重点关注link是否up、speed1000/100、duplexFull/Halfdhcp强制GMAC0获取DHCP地址。如果失败ping网关看是否物理层连通ping 192.168.1.1测试基础IP连通性。若超时mdio read 0 0x00读取PHY状态寄存器确认bit2link status是否为1。一个经典排错案例客户反馈“GMAC1始终link down”。我登录U-Boot执行phyinfo发现phy1的link为down但speed却是1000。这不合逻辑——link down时speed应为unknown。进一步mdio read 1 0x00返回0x796d二进制0111100101101101bit2为0确认link down。再查设备树发现gmac1节点漏写了status okayU-Boot根本没初始化GMAC1控制器自然link down。一行缺失全盘皆输。5.3 ethtoolKernel层的性能与链路透视镜进入Linux后ethtool是网卡的X光机。它不依赖ifconfig的抽象层直接与驱动对话。高频使用命令ethtool eth0查看网卡基本信息、驱动、固件、支持的速率ethtool -s eth0 speed 1000 duplex full autoneg off强制千兆全双工排除协商问题ethtool -r eth0重启自动协商ethtool -i eth0查看驱动版本stmmacvsdwmac_rockchip不同驱动对双网卡支持度不同。性能调优关键参数/etc/sysctl.conf# 禁用IPv6减少干扰 net.ipv6.conf.all.disable_ipv6 1 # 增加TCP缓冲区 net.core.rmem_max 16777216 net.core.wmem_max 16777216 # 关闭GRO通用接收卸载RK3568 GRO有兼容性问题 net.core.gro_disable 1提示RK3568的stmmac驱动在v5.10内核中存在GRO导致UDP丢包的bug关闭后iperf3UDP吞吐量从300Mbps提升至940Mbps。这不是玄学是驱动层的真实缺陷。这套工具链的价值在于它构建了一条从硬件eFuse→固件U-Boot→驱动Kernel的完整信任链。每一步都有可验证的输出每一个失败点都有明确的归因方向。它不教你“怎么点按钮”而是给你一把手术刀让你能精准切开问题的每一层组织。6. 产线落地 checklist从单板验证到百台批量烧录的全流程管控在实验室调通一块板子和在产线上稳定烧录一百块板子是两回事。后者需要一套严谨的流程管控体系把人为失误、工具版本差异、硬件批次波动全部纳入考虑。以下是我在协助客户搭建RK3568产线时制定的落地checklist已通过3个量产项目验证。6.1 单板验证阶段每批次首板必做步骤操作验证标准工具/命令失败处理1. Loader模式确认短接BOOT_MODE上电lsusb查看是否有Rockchip USB DeviceBus XXX Device YYY: ID 2207:3568lsusb | grep 2207检查跳线帽、USB线、PC驱动2. eFuse初始状态rkdeveloptool rd -b efuse 0x1A0 6全00或全ff未烧录状态rkdeveloptool若非初始态需确认是否为返修板3. MAC烧录与验证执行烧录脚本立即读取验证读出值写入值且非000000000000rkdeveloptool wl rd重烧若连续3次失败换烧录线4. U-Boot启动检测拔掉短接帽上电串口捕获U-Boot日志日志中出现gmac0: PHY stmmac-0:00和gmac1: PHY stmmac-1:01串口终端检查设备树编译、Loader版本5. Linux双网卡就绪启动后执行ip link show | grep eth输出eth0和eth1且state UPip link show检查/etc/network/interfaces配置6.2 批量烧录阶段百台级防错设计MAC池管理使用Python脚本生成连续、唯一的MAC地址池避免00:00:00开头的厂商保留段并导出CSV供MES系统调用import csv with open(mac_pool.csv, w) as f: writer csv.writer(f) for i in range(1, 101): mac f00:11:22:33:44:{i:02X} writer.writerow([fBOARD_{i:03d}, mac])烧录工作站配置固定rkdeveloptool版本v2.59.1禁止自动更新USB端口绑定/dev/serial/by-path/platform-ff5c0000.usb-usb-0:1.2:1.0-port0→/dev/rk3568_loader避免插拔后设备名变化烧录脚本加入SHA256校验sha256sum rk3568_loader_v2.59.1.bin必须匹配官方发布值。过程防呆设计烧录脚本末尾增加reboot命令但要求操作员手动按下板载复位键防止脚本误触发每烧录10块自动执行一次rkdeveloptool rd抽检日志存档烧录失败时脚本自动截图串口日志、保存dmesg输出并邮件告警。6.3 交付物清单客户验收依据一份合格的RK3568双网卡交付必须提供以下可验证文件eFuse烧录报告PDF包含每块板的序列号、烧录时间、MAC0/MAC1值、rkdeveloptool rd输出截图U-Boot启动日志TXT完整串口日志高亮gmac0和gmac1初始化段Linux网络测试报告Markdownethtool eth0/eth1输出、iperf3吞吐量截图、ping -c 100丢包率设备树源码DTS文件标注修改行附编译命令make rk3568-evb1-v10.dtb工具版本清单rkdeveloptool --version、U-Boot commit ID、Kernel版本。这套流程看似繁琐但它把“不确定”变成了“可测量、可追溯、可复现”。当客户指着某块板说“双网卡不工作”时你不需要重新调试只需调出它的eFuse报告和U-Boot日志3分钟内定位到是设备树PHY地址写错还是MAC烧录时USB接触不良。这才是专业交付的底气。7. 我踩过的那些坑关于RK3568 MAC与双网卡的血泪经验最后分享几个我在RK3568项目中付出真金白银才换来的经验。它们不在任何官方文档里却能帮你省下至少三天的无效调试时间。坑一eFuse烧录后U-Boot不读取以为烧录失败现象rkdeveloptool wl返回successrd读取正确但U-Boot启动后printenv ethaddr仍是空。根因U-Boot配置中CONFIG_ROCKCHIP_EFUSE_MACy未启用或者CONFIG_ROCKCHIP_EFUSE_BASE0x20000000RK3568 eFuse基址写错。教训烧录前必须确认U-Boot.config文件中这两个宏已开启且基址与SoC手册一致。我曾因一个0写成O浪费12小时。坑二双网卡在Linux下只能启用一个ifconfig eth1 up失败现象ip link show能看到eth1但ifconfig eth1 up报错SIOCSIFFLAGS: Resource busy。根因/etc/network/interfaces中auto eth0和auto eth1冲突或/etc/default/grub中net.ifnames0未设置导致网卡名变为enx...而非eth0/eth1。教训RK3568默认启用预测性网卡命名必须在GRUB中添加net.ifnames0 biosdevname0并update-grub。这是Linux发行版的通用坑不是RK3568特有。坑三千兆协商成功但iperf3吞吐量只有100Mbps现象ethtool eth0显示Speed: 1000Mb/sping延迟正常但iperf3 -t 30平均只有110Mbps。根因stmmac驱动的TX队列长度默认为32千兆满吞吐需至少256。解决echo 256 /sys/class/net/eth0/queues/tx-0/queue_size并写入/etc/rc.local。教训驱动默认参数是为通用场景优化不是为RK3568千兆网卡定制。必须根据实际带宽需求调整。坑四烧录工具下载链接失效网上找到的“rkdeveloptool”是木马现象从非官网渠道下载的工具执行rkdeveloptool时CPU占用100%strace发现它在偷偷连接境外IP。教训Rockchip官方工具只发布在GitHub仓库https://github.com/rockchip-linux/rkdeveloptool其他来源一律不信任。我建立了一个内部镜像站所有工具经SHA256校验后才允许下载。这些坑每一个都让我在凌晨三点对着示波器抓RGMII波形