RK3588 通过 RGMII 扩展四网口:TRL8367s 交换芯片调试与优化实战

发布时间:2026/9/28 14:29:18
RK3588 通过 RGMII 扩展四网口:TRL8367s 交换芯片调试与优化实战 1. 项目缘起与方案选型考量RK3588 这颗芯片在边缘计算和嵌入式视觉领域的热度一直居高不下八核 CPU 加六 TOPS NPU 的配置让它成了不少工业网关、NVR、智能座舱项目的首选主控。但只要你做过 RK3588 的板子就会知道它原生只有两路 GMAC其中一路还经常被复用成其他功能。当项目需要三网口甚至四网口的时候外挂一颗千兆交换芯片就成了绕不开的选择。TRL8367s 就是在这个背景下进入视野的——八口千兆交换支持 RGMII 接口价格比某些进口方案便宜不少供货也相对稳定。我这次的项目需求很明确RK3588 通过 RGMII 连接 TRL8367s实现四个千兆网口的扩展其中一路还要支持 WAN/LAN 切换。听起来不复杂但实际调试过程中踩的坑一个接一个。从硬件上电到链路协商成功前后折腾了将近两周中间经历了 PHY 识别不到、链路只能跑百兆、丢包严重、延迟抖动大等一系列问题。这篇文章就是把这整个过程完整记录下来把每个坑的成因和解决办法讲清楚让后来的人少走弯路。先说方案选型。为什么选 RGMII 而不是 SGMII 或者 PCIeRGMII 的优势在于引脚少、成本低、不需要额外的 SerDes 电源对于千兆速率来说完全够用。RK3588 的 GMAC 控制器原生支持 RGMII驱动层面也相对成熟。TRL8367s 这边它的 RGMII 接口支持内部延迟Internal Delay配置这一点非常关键——后面会详细讲为什么。SGMII 虽然速率更高、走线更灵活但需要额外的时钟和电源设计对于四口千兆交换来说属于性能过剩。PCIe 方案则涉及更复杂的枚举和驱动适配开发周期不可控。提示选型阶段一定要确认交换芯片的 RGMII 接口是否支持内部延迟调节。如果芯片不支持就必须在 PCB 上做时钟走线的等长绕线来补偿延迟这会大大增加 Layout 难度和板子面积。另一个关键决策是 PHY 地址的分配。TRL8367s 内部集成了八个 PHY每个 PHY 有独立的地址。RK3588 的 GMAC 通过 MDIO 总线去访问这些 PHY 时需要知道每个 PHY 的地址。TRL8367s 的 PHY 地址由硬件引脚决定通常是通过上拉或下拉电阻来配置。我这次的设计里交换芯片的 PHY 地址基址设为 0x10八个 PHY 依次为 0x10 到 0x17。这个地址必须在设备树里正确配置否则内核根本找不到 PHY链路自然起不来。还有一点容易被忽略TRL8367s 的 RGMII 接口是接在交换芯片的哪个 Port 上。TRL8367s 有八个 PHY Port 和两个 RGMII/MII Port通常叫 Port 6 和 Port 7。RK3588 要连接的是 Port 6 或 Port 7这两个 Port 是 MAC 侧的接口不是 PHY 侧。在配置交换芯片的 VLAN 和端口映射时这个区别非常重要。我一开始就是把 Port 6 当成了普通 PHY Port 来配结果数据包根本转发不出去。2. RGMII 接口时序与延迟机制深度解析RGMII 接口的时序问题是整个调试过程中最核心、也最容易出问题的部分。很多人以为 RGMII 就是简单的并行数据总线接上就能跑实际上它的时序要求非常严格尤其是在千兆速率下时钟周期只有 8ns任何一点延迟偏差都可能导致采样错误。RGMII 的时钟和数据关系是这样的发送方向MAC 发出 GTX_CLK同时发出 TXD[3:0] 和 TX_CTL接收方向PHY 发出 RX_CLK同时发出 RXD[3:0] 和 RX_CTL。关键点在于RGMII 标准规定数据在时钟的上升沿和下降沿都采样DDR 模式而且时钟和数据之间有一个默认的 1.5ns 到 2ns 的延迟关系。这个延迟可以由 MAC 侧提供也可以由 PHY 侧提供还可以两边各提供一部分。问题就出在这里如果 MAC 和 PHY 都认为自己应该提供延迟或者都认为对方应该提供那采样窗口就会完全错位。表现出的现象就是链路能协商成功但 ping 不通或者丢包率极高。我一开始遇到的就是这个情况——链路显示 1000Mbps 全双工但 ping 网关丢包率超过 50%。解决这个问题的核心思路是明确延迟由哪一侧提供然后通过寄存器配置把另一侧的延迟关掉。RK3588 的 GMAC 支持在设备树里配置tx_delay和rx_delay参数单位是皮秒ps。TRL8367s 这边它的 RGMII 接口也有内部延迟配置寄存器可以分别控制 TX 和 RX 方向的延迟使能。我最终的配置方案是RK3588 侧关闭 TX 和 RX 延迟设为 0TRL8367s 侧开启内部延迟。这样做的原因是 TRL8367s 的内部延迟精度更高而且一旦配置好就不需要再动。RK3588 侧的延迟参数如果设得不好反而会引入额外的抖动。具体到寄存器操作TRL8367s 的 RGMII 延迟配置涉及以下几个寄存器寄存器地址功能推荐值说明0x1F扩展寄存器页选择0x0A切换到 RGMII 配置页0x0ARGMII 延迟控制0x03开启 TX 和 RX 内部延迟0x0BRGMII 时钟控制0x00默认时钟配置注意不同批次的 TRL8367s 在寄存器定义上可能有细微差异操作前务必对照最新版数据手册确认。我手里这批芯片的 0x0A 寄存器 bit[1:0] 分别控制 RX 和 TX 延迟写 0x03 就是两个都开。RK3588 设备树里的配置是这样的gmac1 { phy-mode rgmii; tx_delay 0x00; rx_delay 0x00; clock_in_out output; phy-handle phy0; mdio { compatible snps,dwmac-mdio; #address-cells 1; #size-cells 0; phy0: ethernet-phy10 { reg 0x10; }; }; };这里有个细节clock_in_out设为output表示 RK3588 的 GMAC 输出 GTX_CLK 给 PHY。如果设成input则时钟方向反过来。这个配置必须和硬件设计一致否则时钟根本没有输出链路不可能起来。还有一个容易被忽视的点是 RGMII 的电压电平。RK3588 的 GMAC IO 电压通常是 1.8V 或 3.3V取决于具体的电源域设计。TRL8367s 的 RGMII 接口电压也要匹配。如果一边是 1.8V 一边是 3.3V中间就需要电平转换芯片否则要么通信失败要么长期运行可靠性有问题。我这次的设计两边都是 1.8V省去了转换电路但 Layout 时要注意 1.8V 电源的纹波控制纹波过大会导致眼图恶化。3. 硬件设计与 Layout 关键要点硬件设计阶段的问题往往在调试阶段才会暴露而且排查起来非常痛苦。我在这次项目里就遇到了因为 Layout 不当导致的信号完整性问题最后不得不飞线验证才找到原因。先说过孔。RGMII 的时钟线和数据线在千兆速率下信号频率是 125MHz但因为是 DDR 采样实际有效数据率是 1000Mbps。这个速率下过孔带来的寄生电容和电感会影响信号上升沿。我的建议是RGMII 的六根信号线GTX_CLK、TXD[3:0]、TX_CTL和接收方向的六根线RX_CLK、RXD[3:0]、RX_CTL尽量少打过孔最好全程走在同一层。如果必须换层换层过孔不要超过两个而且要在过孔附近加回流地过孔。等长控制是另一个重点。RGMII 的数据线和时钟线之间需要做等长误差控制在多少合适我的经验是时钟线和数据线的长度差控制在 100mil 以内数据线之间的长度差控制在 50mil 以内。这个要求比 DDR 内存的等长要求宽松很多但也不能完全不管。我见过有工程师把 RGMII 当 SPI 来走线结果千兆跑不起来只能跑百兆就是因为时序余量被走线偏差吃掉了。提示如果板子空间实在紧张做不到严格的等长优先保证时钟线的长度匹配数据线之间的偏差可以适当放宽。因为 RGMII 的采样窗口有 1.5ns 左右的余量对应到走线上大约是 225mil 的长度容差。电源滤波也不能马虎。TRL8367s 的 RGMII 接口电源引脚需要就近放置 0.1uF 和 1uF 的退耦电容而且电容的地要直接打到地平面不要通过长走线连接。我这次有一块板子因为退耦电容的地走线太长导致 RGMII 眼图闭合链路频繁掉线。后来把电容地重新处理问题立刻消失。还有一点关于时钟的RK3588 输出的 GTX_CLK 是 125MHz这个时钟的抖动要求比较严格。如果 PCB 上时钟线靠近了开关电源或者高频信号线耦合进来的噪声会导致时钟抖动增大进而影响采样。我的做法是在时钟线两侧包地并且包地线上每隔 200mil 打一个地过孔。这个做法虽然增加了 Layout 工作量但对于千兆 RGMII 来说稳定性提升非常明显。TRL8367s 的复位电路也值得一说。这颗芯片的复位引脚需要保持低电平至少 10ms而且复位释放的时机要在电源稳定之后。我一开始用了一个简单的 RC 复位电路结果因为电容充电时间不够芯片偶尔启动失败。后来改用专门的复位芯片问题解决。如果你不想增加成本至少要把 RC 的时间常数算够确保在最差情况下也能满足 10ms 的要求。4. 软件配置与调试实操全流程软件层面的调试从设备树配置开始但远不止设备树。RK3588 的 GMAC 驱动、TRL8367s 的交换芯片驱动、以及两者之间的 MDIO 通信每一环都可能出问题。第一步是确认 MDIO 通信正常。在设备树配置好之后系统启动时内核会通过 MDIO 总线扫描 PHY 地址。你可以通过以下命令查看 PHY 是否被正确识别# 查看 MDIO 总线上的 PHY 设备 ls /sys/class/mdio_bus/ # 查看具体 PHY 的状态 cat /sys/class/mdio_bus/stmmac-0/phy0/phy_id如果 PHY ID 读出来是 0x00000000 或者 0xffffffff说明 MDIO 通信有问题。常见原因有三个MDIO 时钟频率太高、PHY 地址配错、MDIO 总线上拉电阻缺失。RK3588 的 MDIO 时钟默认是 2.5MHz如果走线较长可以适当降低到 1MHz 试试。第二步是确认链路协商状态。PHY 识别到之后用ethtool查看链路状态ethtool eth0重点看Speed、Duplex、Link detected这三项。如果显示Speed: 100Mb/s而不是1000Mb/s说明千兆协商失败。这时候要检查 RGMII 延迟配置是否正确以及硬件上是否有信号完整性问题。第三步是打流测试。链路协商成功不代表数据能正常传输。我习惯用iperf3做双向打流测试# 服务端 iperf3 -s # 客户端 iperf3 -c 192.168.1.100 -t 60 -i 5千兆环境下TCP 吞吐应该能跑到 940Mbps 左右。如果只有 100Mbps 或者丢包严重就要回头检查 RGMII 时序。我这次遇到的情况是单向能跑满反向丢包严重最后定位到是 RX 方向的延迟配置不对。第四步是交换芯片的 VLAN 和端口映射配置。TRL8367s 默认所有端口在同一个 VLAN 里如果你需要做 WAN/LAN 隔离就要配置 VLAN 表。这部分通常通过交换芯片的寄存器或者专用的配置工具来完成。我这次用的是通过 MDIO 间接访问交换芯片寄存器的方式写了一个简单的配置脚本# 切换到交换芯片寄存器页 mdio-tool w eth0 0x1F 0x0A # 配置 Port 6 为 RGMII 模式 mdio-tool w eth0 0x06 0x01 # 配置 VLAN 成员 mdio-tool w eth0 0x07 0x3F注意交换芯片的寄存器操作一定要在链路起来之前完成否则可能出现配置不生效的情况。我习惯在 U-Boot 阶段就把交换芯片初始化好这样内核启动后直接就能用。调试过程中还有一个实用技巧用示波器抓 RGMII 的时钟和数据波形。把探头接在 GTX_CLK 和 TXD0 上触发方式设为时钟上升沿观察数据是否在时钟边沿附近稳定。如果数据跳变沿和时钟边沿重合说明延迟配置有问题。正常的波形应该是数据跳变沿在时钟边沿之前或之后至少 1ns。5. 常见问题速查与排查思路调试过程中遇到的问题五花八门我把最典型的几个整理成速查表方便对照排查。现象可能原因排查方法解决方案PHY ID 读不到MDIO 通信失败示波器看 MDIO/MDC 波形检查上拉电阻、降低 MDIO 时钟链路只能跑百兆RGMII 延迟配置错误检查设备树 tx_delay/rx_delay调整延迟参数或启用 PHY 内部延迟链路频繁掉线电源纹波大或信号完整性差示波器看电源纹波和眼图加强退耦、优化 Layoutping 通但丢包严重时序余量不足打流测试看丢包率重新配置延迟、检查等长交换芯片不转发端口模式配置错误读交换芯片寄存器确认 Port 6/7 配置为 RGMII 模式系统启动后网口不亮复位时序不对示波器看复位引脚调整 RC 时间常数或换复位芯片除了表格里的内容还有几个排查思路值得分享。第一个是“二分法”如果怀疑是硬件问题可以先在 U-Boot 阶段测试网口。U-Boot 的网口驱动比内核简单如果 U-Boot 下能 ping 通说明硬件基本没问题问题在内核配置。如果 U-Boot 下也不通那就要重点查硬件。第二个是“替换法”如果手头有另一块已知好的板子可以把交换芯片或者 RK3588 的配置换过去试试。我这次就是通过替换法确认了是 Layout 问题而不是芯片问题。第三个是“降速法”如果千兆跑不起来先降到百兆试试。百兆对时序的要求宽松很多如果百兆能稳定运行说明硬件基本通路是好的问题出在千兆特有的时序要求上。这个方法能快速缩小排查范围。提示调试 RGMII 的时候一定要有示波器或者逻辑分析仪。靠猜和试错效率太低而且容易把问题搞复杂。一个 200MHz 带宽的示波器就能满足 RGMII 调试需求不算太高的门槛。还有一个容易被忽略的点内核版本和驱动版本。RK3588 的 GMAC 驱动在不同内核版本之间有差异有些版本对 RGMII 延迟的处理方式不一样。我这次用的是 5.10 内核设备树的tx_delay和rx_delay参数直接生效。如果你用的是 4.19 或者更早的版本可能需要通过stmmac驱动的模块参数来配置。建议在调试前先确认内核版本和对应的驱动配置方式。6. 性能优化与长期稳定性验证链路调通只是第一步长期运行的稳定性才是产品化的关键。我这次在实验室环境下连续跑了 72 小时打流测试中间遇到过两次链路掉线最后定位到是交换芯片温度过高导致的。TRL8367s 在满负荷工作时发热量不小如果板子散热设计不好芯片温度超过 70 度就可能出现异常。散热方面的经验是交换芯片底部一定要铺铜并且打足够多的散热过孔到背面。如果空间允许加一块小散热片效果更明显。我这次是在芯片背面贴了一块 15x15mm 的铝散热片温度从 75 度降到了 55 度链路再没掉过。性能优化方面有几个参数可以调整。第一个是中断合并Interrupt CoalescingRK3588 的 GMAC 支持中断合并可以减少 CPU 中断次数提升吞吐。通过ethtool -C可以配置ethtool -C eth0 rx-usecs 100 tx-usecs 100第二个是 DMA 描述符数量。默认的 DMA 描述符可能不够用在高负载下会出现丢包。可以在设备树里调整gmac1 { snps,axi-config stmmac_axi_setup; snps,mtl-rx-config mtl_rx_setup; snps,mtl-tx-config mtl_tx_setup; };第三个是 CPU 亲和性。把网口中断绑定到特定的 CPU 核心上可以减少缓存失效提升处理效率# 查看网口中断号 cat /proc/interrupts | grep eth0 # 绑定到 CPU2 echo 4 /proc/irq/123/smp_affinity长期稳定性验证除了打流测试还要做异常场景测试。比如反复插拔网线、强制链路重新协商、在打流过程中重启对端设备等。我这次在测试中发现在反复插拔网线 50 次左右时交换芯片偶尔会挂死最后发现是驱动里缺少链路状态变化的去抖处理。在驱动里加了 200ms 的去抖延时后问题解决。还有一个实际部署中会遇到的问题电磁兼容性。千兆 RGMII 的时钟频率是 125MHz它的谐波可能会干扰到其他无线设备。如果产品需要通过电磁兼容认证建议在时钟线上加一个 33 欧姆的串联电阻并且预留一个对地的电容位置方便后续调试。我这次的产品因为旁边有 4G 模块一开始电磁兼容测试辐射超标后来在 RGMII 时钟线上加了 RC 滤波才通过。最后分享一个我在实际项目中总结的检查清单每次调试 RGMII 网口时按这个顺序过一遍基本能覆盖 90% 的问题电源电压是否正常纹波是否在 50mV 以内复位时序是否满足芯片要求MDIO 通信是否正常PHY ID 能否正确读取设备树配置是否与硬件一致时钟方向、PHY 地址、延迟参数链路协商速率是否正确打流测试吞吐和丢包率是否达标长时间运行是否稳定芯片温度是否可控异常场景插拔、重启是否正常这套流程走下来基本上能把 RGMII 网口的问题都覆盖到。TRL8367s 加 RK3588 这个组合本身是成熟的只要把时序和电源这两个大头处理好剩下的都是细节问题。我在实际使用中发现最耗时间的往往不是技术难点而是那些看起来不起眼的小问题比如一个上拉电阻没焊、一个寄存器地址写错。所以调试的时候耐心和细致比什么都重要。