1. 项目缘起与整体方案拆解RK3588 这颗芯片在嵌入式圈子里火了好几年八核 A76/A55 架构、6TOPS NPU、多路 PCIe 和以太网控制器做边缘计算网关、NVR、工业控制板几乎是首选。但真到产品落地阶段很多人会卡在一个看似简单的地方板子本身只有一个千兆网口项目却要求四个千兆口做交换。这时候就得外挂交换芯片而 TRL8367s 是 Realtek 家族里被大量采用的一颗 8 口千兆交换芯片支持二层转发、VLAN、QoS性价比高资料也相对好找。我这次做的项目是一台工业边缘网关主控 RK3588通过 RGMII 接口挂了一颗 TRL8367s对外提供四个千兆网口。需求很明确四个口之间要能二层互通同时其中一个口要能和 RK3588 的 CPU 侧通信让上层系统能管理这台设备。听起来不复杂但实际调试过程中DTS 配置、PHY 地址、RGMII 时序、二层模式这几个环节任何一个出问题都会导致网络不通或者丢包严重。这篇文章我会把整个实战过程拆开讲从硬件连接到 DTS 配置再到二层模式的原理和验证方法尽量把每一步的“为什么”说清楚。适合正在用 RK3588 做多网口方案的嵌入式工程师也适合对交换芯片配置感兴趣的网络方向开发者。即使你用的是其他主控或交换芯片思路也是通用的。先说一下整体架构。RK3588 的 GMAC 控制器通过 RGMII 总线和 TRL8367s 的某个端口相连这个端口在交换芯片内部被配置为“CPU 口”或者叫“上行口”。TRL8367s 的其余端口接外部 RJ45。数据流向是这样的外部设备从某个网口进来交换芯片根据 MAC 地址表决定是转发到另一个外部口还是送到 CPU 口交给 RK3588 处理。二层模式的意思是交换芯片自己完成 MAC 学习和转发不需要 CPU 参与每个包的处理这样吞吐能跑满千兆CPU 占用也低。为什么选二层模式而不是三层因为三层路由需要 CPU 参与路由决策RK3588 虽然性能强但四个千兆口全速跑三层转发CPU 负载会很高而且延迟不稳定。二层交换是硬件转发延迟低、吞吐高适合做纯交换或者桥接场景。如果项目需要跨网段路由那可以在 RK3588 上做但那是另一个话题了。2. 硬件连接与关键信号确认2.1 RGMII 接口的引脚映射RK3588 的 GMAC 支持 RGMII、RMII、SGMII 等多种模式我们用的是 RGMII因为千兆速率下 RGMII 只需要 12 根信号线比 GMII 的 24 根省一半引脚。RGMII 的关键信号包括TXD[3:0]发送数据4 位TXC发送时钟125MHzTX_CTL发送控制复用为 TXEN 和 TXERRRXD[3:0]接收数据RXC接收时钟RX_CTL接收控制复用为 RXDV 和 RXERRMDC/MDIO管理接口用于配置 PHY 和交换芯片寄存器这里有个容易踩的坑RGMII 的时钟延迟模式。RGMII 有两种时序模式一种是时钟和数据同时输出接收端自己延迟采样另一种是发送端延迟时钟接收端用延迟后的时钟采样。RK3588 的 GMAC 和 TRL8367s 都支持内部延迟但两边必须匹配。我见过有人两边都开了延迟结果数据采样错位ping 都通不了。实际连接时RK3588 的 GMAC1 接到 TRL8367s 的 Port 6这个端口在芯片内部默认就是 RGMII 接口。TRL8367s 的 Port 0 到 Port 4 是内置 PHY 的千兆口可以直接接 RJ45。Port 5 和 Port 6 是 RGMII/SGMII 复用我们只用 Port 6 做 CPU 口Port 5 悬空。2.2 复位与时钟电路TRL8367s 需要一个 25MHz 晶振作为参考时钟内部 PLL 倍频到 125MHz 给 RGMII 用。复位引脚要接 RK3588 的一个 GPIO上电后拉低至少 10ms 再拉高确保芯片完成内部初始化。这个复位时序很关键如果复位时间不够芯片可能工作不稳定表现为部分端口不通或者丢包。我用的复位 GPIO 是 GPIO3_A6在 DTS 里配置为输出默认拉高驱动加载时先拉低再拉高。实测下来复位脉冲宽度给 20ms 比较稳妥datasheet 写的是最小 10ms但留点余量没坏处。MDC/MDIO 总线上TRL8367s 的 PHY 地址由硬件引脚决定。Port 0 到 Port 4 的 PHY 地址通常是 0 到 4CPU 口 Port 6 的地址可能是 6 或者 0x1C具体看芯片的 strapping 引脚。我这块板子 Port 6 的地址是 6所以在 DTS 里要写对否则 MDIO 读不到寄存器。3. DTS 配置详解与逐行解析3.1 GMAC 节点配置RK3588 的 DTS 里GMAC 节点需要配置 PHY 模式、时钟、引脚复用等。下面是我实际用的配置片段gmac1 { phy-mode rgmii-id; clock_in_out output; snps,reset-gpio gpio3 RK_PA6 GPIO_ACTIVE_LOW; snps,reset-active-low; snps,reset-delays-us 0 20000 100000; assigned-clocks cru SCLK_GMAC1_RX_TX, cru SCLK_GMAC1; assigned-clock-parents cru SCLK_GMAC1_RGMII_SPEED, cru SCLK_GMAC1; pinctrl-names default; pinctrl-0 gmac1_miim gmac1_tx_bus2 gmac1_rx_bus2 gmac1_rgmii_clk gmac1_rgmii_bus; tx_delay 0x2a; rx_delay 0x1a; phy-handle rgmii_phy; status okay; };逐行解释一下。phy-mode rgmii-id表示 RGMII 模式并且 PHY 侧内部延迟id 是 internal delay 的缩写。这里要注意RK3588 的 GMAC 驱动会根据这个属性决定是否启用内部延迟。如果写成rgmii两边都不延迟那就要靠 PCB 走线等长来保证时序一般不建议。clock_in_out output表示 GMAC 输出时钟给 PHY也就是 RK3588 提供 TXC 和 RXC。有些设计是 PHY 提供时钟那就写input。这个要根据硬件设计来写反了时钟就没有。snps,reset-gpio和snps,reset-delays-us是复位时序0 20000 100000表示延时 0us 拉低20000us 后拉高再等 100000us 后访问 PHY。这个延时给足避免 PHY 还没准备好就被访问。tx_delay和rx_delay是 RGMII 的延迟值单位是 0.1ns 左右具体看 RK3588 的 TRM。我实测下来 tx_delay 给 0x2a、rx_delay 给 0x1a 比较稳但不同板子走线不同这个值需要根据眼图或者丢包率来调。调的时候可以先从默认值开始ping 大包看丢包然后微调。3.2 PHY 节点与 MDIO 配置TRL8367s 的 CPU 口在系统里表现为一个 PHY需要单独定义一个 PHY 节点mdio1 { rgmii_phy: ethernet-phy6 { compatible ethernet-phy-ieee802.3-c22; reg 0x6; realtek,led-link 0x1; realtek,led-act 0x1; }; };reg 0x6就是 PHY 地址必须和硬件 strapping 一致。compatible用标准的 c22 就行TRL8367s 的 CPU 口 PHY 寄存器兼容标准。LED 配置是可选的根据实际需求来。这里有个细节TRL8367s 的 CPU 口在芯片内部其实是一个 RGMII 到交换核心的接口但它对外表现为一个标准 PHY有标准的 BMCR、BMSR 寄存器。所以 Linux 的通用 PHY 驱动能识别它不需要额外写驱动。这也是选这颗芯片的原因之一软件适配成本低。3.3 交换芯片的 DSA 还是纯二层这里要做一个关键决策是用 DSADistributed Switch Architecture框架还是把交换芯片当成一个纯二层的黑盒只通过 CPU 口通信DSA 的好处是每个外部口在 Linux 里都是一个独立的 netdev可以做 VLAN、桥接、流量控制管理粒度细。但 DSA 需要交换芯片驱动支持TRL8367s 的 DSA 驱动在内核里是有的但配置复杂而且 RK3588 的 GMAC 和 DSA 的配合需要额外调试。纯二层模式就简单多了交换芯片自己完成二层转发CPU 口就是一个普通的网口Linux 看到的是 eth1 或者类似的设备。四个外部口之间的通信完全由芯片硬件处理CPU 不感知。这种模式适合不需要精细管理的场景配置简单稳定性高。我这次选的是纯二层模式因为项目需求就是四个口互通不需要 VLAN 隔离也不需要每个口单独统计。如果你需要 VLAN 或者端口镜像那还是得上 DSA。4. 二层模式原理与寄存器配置4.1 二层转发的基本流程二层交换的核心是 MAC 地址表。芯片收到一个包提取源 MAC 和目的 MAC查表决定从哪个口转发。如果目的 MAC 在表里就单播转发到对应口如果不在就泛洪到所有口除了入端口。同时芯片会学习源 MAC 和入端口的对应关系写入地址表。TRL8367s 的地址表大小是 2K 条目支持自动老化默认老化时间是 300 秒。这些参数可以通过寄存器配置但默认值一般够用。地址表的学习和老化都是硬件自动完成的不需要 CPU 干预。CPU 口在二层模式下的角色是如果目的 MAC 是 RK3588 的 MAC或者包需要上送 CPU比如 ARP、DHCP芯片会把包送到 CPU 口。反过来RK3588 发出的包从 CPU 口进入芯片芯片根据目的 MAC 决定从哪个外部口转发出去。4.2 关键寄存器配置TRL8367s 的寄存器分两类PHY 寄存器和交换核心寄存器。PHY 寄存器通过 MDIO 访问交换核心寄存器通过间接方式访问先写地址寄存器再读写数据寄存器。二层模式需要配置的几个关键寄存器端口使能确保 Port 0 到 Port 4 和 Port 6 都使能Port 5 如果不用就关闭。CPU 口配置Port 6 要配置为 CPU 口设置 tag 模式或者透传模式。透传模式下CPU 口收到的包不带 tag就是普通以太网包。VLAN 配置如果不需要 VLAN就把所有端口设为同一个 VLAN或者关闭 VLAN 功能。流控千兆口建议开启流控避免拥塞丢包。这些配置在纯二层模式下其实很多是芯片的默认值。TRL8367s 上电后默认就是所有端口使能、二层转发开启。所以如果你只是做简单的交换可能不需要改任何寄存器直接就能工作。但为了稳定我还是建议显式配置一下 CPU 口的模式。4.3 为什么不需要额外驱动纯二层模式下Linux 只需要驱动 RK3588 的 GMAC 和 CPU 口的 PHY交换芯片本身对系统是透明的。GMAC 驱动会通过 MDIO 读取 PHY 的状态协商速率和双工模式。CPU 口 PHY 协商到 1000M 全双工后GMAC 就以千兆速率和交换芯片通信。交换芯片内部CPU 口和外部口之间的转发是硬件完成的不需要软件参与。所以系统里看不到四个外部口只能看到一个 eth 设备。这也是为什么这种方案简单稳定的原因。5. 实操验证与调试过程5.1 上电后的第一轮检查板子上电后第一件事是看内核启动日志里 GMAC 和 PHY 的识别情况。用dmesg | grep -i eth可以看到类似这样的输出[ 2.345678] rk_gmac-dwmac fe1c0000.ethernet: IRQ eth_lpi not found [ 2.345789] rk_gmac-dwmac fe1c0000.ethernet: no regulator found [ 2.345890] rk_gmac-dwmac fe1c0000.ethernet: clock input or output? output [ 2.346012] rk_gmac-dwmac fe1c0000.ethernet: TX delay(0x2a) [ 2.346123] rk_gmac-dwmac fe1c0000.ethernet: RX delay(0x1a) [ 2.346234] rk_gmac-dwmac fe1c0000.ethernet: integrated PHY? no [ 2.346345] rk_gmac-dwmac fe1c0000.ethernet: cannot get clock [ 2.346456] rk_gmac-dwmac fe1c0000.ethernet: init phy failed如果看到init phy failed说明 MDIO 读不到 PHY。这时候要检查 PHY 地址对不对、复位时序够不够、MDC/MDIO 有没有接反。我遇到过 MDC 和 MDIO 接反的情况现象就是读不到 PHY换过来就好了。如果 PHY 识别成功会看到attached PHY driver之类的日志然后eth0或者eth1就出现了。用ip link能看到设备状态。5.2 速率协商与连通性测试PHY 识别成功后用ethtool eth1看协商结果Settings for eth1: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Speed: 1000Mb/s Duplex: Full Link detected: yes如果 Speed 显示 100Mb/s 或者 10Mb/s说明 RGMII 时序有问题或者 PHY 协商没到千兆。这时候先检查 tx_delay 和 rx_delay用ping -s 1472 -f打大包看丢包率然后微调延迟值。连通性测试分两步先测 CPU 口和外部口的通信再测外部口之间的通信。CPU 口测试就是 RK3588 ping 外部口接的 PC。外部口之间测试就是两个 PC 分别接两个外部口互相 ping。如果 CPU 口通但外部口之间不通说明交换芯片的转发没工作检查端口使能和 VLAN 配置。5.3 性能测试与瓶颈分析用 iperf3 测吞吐。CPU 口和外部口之间跑 iperf3能跑到 940Mbps 左右就是正常的因为千兆线速加上协议开销实际吞吐就是 940 左右。如果只有 500Mbps 或者更低可能是 RGMII 时序问题导致重传或者 CPU 性能瓶颈。外部口之间跑 iperf3应该也是 940Mbps 左右而且 CPU 占用应该很低因为转发是硬件完成的。如果 CPU 占用高说明包被上送到 CPU 了检查交换芯片的 CPU 口配置可能 tag 模式不对。我实测下来四个外部口之间全速跑CPU 占用不到 5%说明二层转发确实在硬件里完成。CPU 口和外部口之间跑CPU 占用大概 20% 到 30%这是正常的因为数据要经过 GMAC 和协议栈。6. 常见问题与排查速查表6.1 PHY 识别失败现象内核日志显示init phy failedip link看不到 eth 设备。排查步骤检查 PHY 地址是否和硬件 strapping 一致用 MDIO 工具读寄存器确认。检查复位 GPIO 是否配置正确复位脉冲宽度是否够。检查 MDC/MDIO 是否接反用示波器看波形。检查 25MHz 晶振是否起振用示波器测频率。6.2 协商不到千兆现象ethtool显示 Speed 为 100Mb/s 或 10Mb/s。排查步骤检查 RGMII 延迟配置调整 tx_delay 和 rx_delay。检查 PCB 走线是否等长RGMII 对走线长度敏感。检查 PHY 的 strapping 引脚是否强制了速率。换一根网线试试有时候是网线质量问题。6.3 外部口之间不通现象CPU 口能通但两个外部口接的 PC 互相 ping 不通。排查步骤检查交换芯片端口使能寄存器确保所有外部口都使能。检查 VLAN 配置确保所有端口在同一个 VLAN。检查地址表是否学习到了 MAC用交换芯片的调试命令看地址表。检查流控配置有时候流控会导致丢包。6.4 丢包严重现象ping 大包丢包率高iperf3 吞吐低。排查步骤调整 RGMII 延迟这是最常见的原因。检查电源是否稳定交换芯片对电源噪声敏感。检查散热芯片过热会导致性能下降。检查是否有环路二层环路会导致广播风暴。6.5 常见问题速查表问题现象可能原因解决方法PHY 识别失败PHY 地址错误核对 strapping修改 DTS regPHY 识别失败复位时序不足增加 reset-delays-us协商不到千兆RGMII 延迟不对调整 tx_delay/rx_delay外部口不通端口未使能配置端口使能寄存器外部口不通VLAN 隔离统一 VLAN 或关闭 VLAN丢包严重时序问题调延迟看眼图丢包严重电源噪声加滤波电容检查 LDOCPU 占用高包上送 CPU检查 CPU 口 tag 模式7. 实操心得与避坑经验第一个心得RGMII 延迟不要照抄别人的值。不同板子走线长度不同延迟值必须自己调。我的方法是先给一个中间值然后 ping 大包看丢包率往丢包少的方向调。调的时候每次改 0x02 或者 0x04改完重新加载驱动或者重启。第二个心得复位时序宁长勿短。datasheet 写最小 10ms我给 20ms多等 10ms 不影响启动速度但能避免很多玄学问题。我遇到过复位给 10ms 偶尔不启动的情况加到 20ms 就稳了。第三个心得MDIO 总线上不要挂太多设备。如果板子上还有其他 PHYMDIO 的负载电容会变大波形变差导致读写失败。这时候可以降低 MDC 频率或者加缓冲器。第四个心得二层模式下交换芯片的配置其实很少大部分用默认值就行。但 CPU 口的模式一定要确认透传模式和 tag 模式的行为完全不同。透传模式下CPU 口收到的包就是普通以太网包协议栈直接处理。tag 模式下包前面会多 4 个字节的 tag协议栈不认识需要驱动处理。我一开始没注意这个导致 ping 不通后来改成透传模式就好了。第五个心得性能测试要用 iperf3 而不是 ping。ping 只能测连通性和大致延迟吞吐必须用 iperf3。而且 iperf3 要跑多线程单线程可能跑不满千兆。我一般用iperf3 -c ip -P 4 -t 30四个线程跑 30 秒看总吞吐。第六个心得如果项目需要 VLAN建议还是上 DSA。纯二层模式下做 VLAN 需要直接操作交换芯片寄存器配置复杂而且容易出错。DSA 框架虽然学习曲线陡但配置清晰管理方便。最后说一个调试技巧TRL8367s 有调试寄存器可以看每个端口的收发包统计、地址表内容、VLAN 表等。这些寄存器通过 MDIO 间接访问需要先写地址再读数据。我一般写个脚本封装读写函数调试的时候很方便。具体寄存器地址参考 datasheet 的寄存器章节这里就不列了因为版本不同可能有差异。整个项目从硬件设计到软件调试大概花了两周时间其中大部分时间花在 RGMII 延迟调整和二层模式验证上。现在板子跑得很稳四个千兆口全速转发CPU 占用低满足工业网关的需求。如果你也在做类似方案希望这篇经验能帮你少走弯路。