从飞线到通路：基于uboot的RTL8367交换芯片MDIO调试实战手记

1. 硬件调试背景与挑战这次调试的硬件平台是一个基于ARM架构的嵌入式系统主控芯片采用ast1520运行着老当益壮的Linux 2.4.6内核。项目需求是将原本的PHY芯片替换为RTL8367交换芯片从传统的MAC-PHY架构转变为MAC-MAC直连方式。这种改动看似简单实际操作中却遇到了不少意料之外的挑战。我最初以为只需要简单更换芯片就能搞定但现实很快给了我一记重拳。RTL8367作为一款功能丰富的交换芯片支持MDIO、I2C和SPI三种控制接口。由于uboot 1.1.4版本已经内置了MDIO操作命令phyw/phyr我们决定优先采用MDIO方式进行通信。这里有个小细节需要注意MDIO协议规定所有PHY芯片的前16个寄存器都是标准化的这意味着理论上只要配置好这些寄存器就能实现基本网络功能。2. 飞线连接的硬件调试技巧在实际操作中我们遇到了第一个拦路虎——硬件连接问题。由于板卡设计时并未考虑RTL8367的布局我们不得不采用飞线方式连接主控芯片和交换芯片。这种临时连接方式带来了诸多隐患特别是在高速网络通信场景下。我建议大家在类似情况下首先要做的就是降低通信速率。RGMII接口不仅支持千兆速率还可以降速到百兆甚至十兆运行。我们将两端都配置为10M模式对应2.5MHz时钟这大大降低了信号完整性的要求。这里有个实用技巧在飞线环境下先用万用表检查所有连接线是否导通再用示波器确认时钟信号是否正常。我们当时就发现有几根飞线存在虚接问题导致信号时有时无。3. MDIO寄存器调试实战确认硬件连接基本正常后接下来就是通过MDIO接口调试RTL8367的寄存器了。uboot提供的phyw/phyr命令使用起来很方便基本格式是phyr mac phy_addr reg phyw mac phy_addr reg value其中mac参数指定使用哪个MAC控制器1或2phy_addr对应交换芯片的PHY IDreg是要操作的寄存器地址。这里有个容易踩坑的地方RTL8367作为交换芯片其寄存器访问方式与普通PHY有所不同。需要通过特定的PHY寄存器间接访问内部寄存器。我们在调试中发现即使不配置任何寄存器RTL8367的PHY端口默认也是通的。这个特性可以帮助我们快速判断硬件连接是否正常。如果连默认状态都无法通信那很可能是硬件连接出了问题。4. 信号测量与故障定位当网络仍然不通时信号测量就成了最后的救命稻草。我们使用逻辑分析仪抓取ping包时的数据信号发现了一个关键现象数据线无法正常拉低。经过仔细检查原来是飞线时造成了短路。修复这个硬件问题后信号波形看起来正常了但网络还是不通。这时候我们采用了对比法找来一块RTL8364的demo板做对照实验。发现demo板可以正常ping通但我们的板卡只能单向通信——主机发出的包能被电脑接收但回包却收不到。通过逐个测量信号线最终发现一根关键飞线接错了位置。修正后网络终于恢复正常。这个案例给我的深刻教训是在飞线环境下调试高速信号一定要有足够的耐心和系统的排查方法。建议按照降速测试→信号测量→对比实验的步骤逐步排查可以少走很多弯路。