千兆网口调不通的时候最折磨人的不是电路焊错了而是它偶尔通、偶尔不通通的时候还丢包。这次板子上用的 PHY 是 YT8531一颗国产单口千兆以太网 PHY接在 SoC 的 RGMII 接口上。整块板子的 YT8531 调试记录我前后折腾了大约两周从最初 MDIO 完全读不到 PHY ID到后来 iperf3 双向稳定跑满 940Mbps中间踩的坑基本覆盖了这类千兆 PHY 的常见故障模式地址 strap 被 LED 引脚带偏、RGMII 内部延时两边都配或者两边都没配、变压器中心抽头去耦电容选错、内核驱动版本太老认不出型号。这篇记录写给正在做板子 bring-up 的硬件工程师和 BSP 工程师也写给那些百兆能通、千兆一上就崩的朋友。不管你手上是 YT8531 还是别的千兆 PHY排查思路大体是通用的区别只在寄存器的页号和位定义上。1. 先把 YT8531 的角色和边界搞清楚1.1 它在链路里到底管什么事很多人第一次调 PHY 会有一个错觉以为 PHY 是网口功能的主体。其实不是。SoC 内部的 MAC 控制器才是负责组帧、DMA、校验的那一方PHY 干的是翻译的活MAC 那边吐出来的是 RGMII 这种并行数字信号PHY 把它变成能上双绞线跑的模拟差分信号反过来再把线上的模拟信号还原成数字并行信号。所以 PHY 本身没有协议栈它不理解 IP也不理解 TCP它只关心电平、时序、编码8b/10b 或者 PAM-5和自协商。这个定位决定了你调试时的心态PHY 出问题症状一定是最底层的比如链路不 up、速率协商不对、误码、丢包而不是网页打不开这种上层表现。YT8531 的一侧是 RGMII 或者 SGMII 接 MAC另一侧通过 1:1 网络变压器接到 RJ45。需要你重点盯的引脚分几类RGMII 数据组TXD[3:0]、RXD[3:0]、时钟组TXCLK、RXCLK、控制组TX_CTL、RX_CTL、管理接口MDC、MDIO、复位RESET_N、时钟输入XTAL_IN/XTAL_OUT 或者外部 25MHz 直接灌进来、LED 指示以及一堆上电时刻被采样的自举配置引脚。最后这一类最容易被忽视也最容易出事后面单独讲。1.2 为什么这块板子选了它选型这件事我没参与但事后复盘选 YT8531 的理由无非几个单口千兆、RGMII 接口、封装小、外围器件少、价格比同规格的进口料有优势而且主流的 Linux 内核从 5.15 之后已经带了对应的驱动BSP 那边不用自己写。代价是资料相对少社区里踩过的人不多遇到问题时搜到的帖子往往是别的型号的照抄过去大概率翻车——我这次就吃过这个亏后面会细说。另外一个现实问题是国产 PHY 有多个后缀版本供电方案和内部 LDO 的有无可能不一样。有些版本需要外部 1.1V 内核电源有些版本内部集成了稳压器单 3.3V 就能工作。这个差别直接决定你的原理图电源部分画得对不对所以我拿到板子第一件事不是上电而是翻手册确认料号和供电架构。这一步千万别省用错版本的封装 Pin to Pin 也不一定兼容。1.3 调试前必须建立的三条认知第一条PHY 是哑设备它不会主动说话。你必须先有能力通过 MDIO 去问它读它的寄存器确认它还活着。MDIO 通不了后面所有事情都是空谈。第二条链路是两端协商出来的结果不是单方面决定的。你的 PHY 说我支持千兆全双工对面交换机如果只支持百兆那就只能跑百兆这不算故障。第三条千兆和百兆用的物理通道完全不同。1000BASE-T 是四对线双向同时收发100BASE-TX 只用两对线一对收一对发。这就解释了那个经典现象百兆正常千兆不通——如果只有两对线的绕线或者变压器有问题百兆根本发现不了。把这三条想明白你后面的排查就不会乱。我见过有人链路不 up 就开始改驱动、改内核参数改了两天最后发现是复位引脚悬空上电后 PHY 一直在复位状态。2. 上电之前的静态检查把九成的坑拦在实验室台面上2.1 电源架构和上电时序实测YT8531 这类千兆 PHY 一般有 3.3V 的 I/O 电源和 1.1V 左右的内核电源。原理图上会用几路 LDO 或者 DCDC 分出来。静态检查阶段不要只拿万用表量有没有电压那个精度看不出问题。我的做法是先用万用表确认每一路电压的直流值在手册标称范围内再用示波器带宽 100MHz 以上探头用弹簧地针别用长地线看纹波和上电斜率。纹波这块我的经验阈值是峰峰值控制在 50mV 以内比较安心。超过这个量级PHY 可能能起来但会在长时间跑流量时随机丢包这种问题最难查因为你盯着看的时候它不犯。上电时序方面如果手册要求内核电源先于 I/O 电源或者有最大时间差限制得用示波器双通道同时抓两路的上电曲线确认。我在一块板子上遇到过 1.1V 比 3.3V 晚上电约 200ms 的情况那颗 PHY 就是死活读不到 ID加了一颗时序控制的三极管之后立刻正常。还有一点上电瞬间的浪涌和缓启动也要看一眼。有些 LDO 输出电容配得太小上电时电压会冲过头再回落PHY 内部的上电复位电路可能就在那个过冲里被触发了两次状态机跑飞。这种偶发问题静态测量完全看不出来一定要用示波器的单次触发模式抓上电波形。2.2 时钟与复位两个最容易被轻视的地方25MHz 参考时钟是 PHY 的心跳它同时供给了内部 PLLPLL 再倍频出千兆需要的 125MHz。晶振不起振或者频率偏差太大PHY 要么不工作要么链路极其不稳。晶振选型上注意三点负载电容要和晶振规格匹配常见的 12pF、20pF 不能混用、频偏控制在 ±50ppm 以内、起振余量要够。我这次的坑就出在这里原理图上标的是 12pFBOM 里贴成了 20pF结果上电后 PHY 有时能识别有时不能识别用示波器看晶振输出波形幅度明显偏低而且有寄生振荡。把电容换回 12pF现象立刻消失。复位信号这一项检查两个点一是上电时复位需要保持低电平多长时间手册里一般会写一个最小值常见的是 10ms 量级有的型号要求 100us 以上即可具体看手册二是复位结束之后PHY 内部还需要一段时间完成自举引脚采样和寄存器初始化通常再等几十毫秒才能通过 MDIO 访问。如果你的代码在驱动 probe 阶段就读寄存器失败很可能就是复位释放后等得不够。2.3 走线、上下拉和自举引脚的检查清单RGMII 那 12 根信号线MAC 端一般会串 22Ω 或者 33Ω 的匹配电阻位置要靠近 MAC 侧而不是 PHY 侧。差分对TX±/RX± 四对要求 100Ω 差分阻抗、对内等长控制在 5mil 以内、对间等长放宽到 50mil 左右问题不大跨分割和过孔数量能少则少。这些在设计阶段定死了调试期改不了但你要知道它们的存在因为如果走线严重超标你能做的只有降速到百兆用。MDIO 这根线必须有一个上拉到 3.3V 的电阻典型值 1.5k 到 10k 之间我一般用 2.2k 或者 4.7k。MDC 不需要上下拉它是 MAC 输出给 PHY 的时钟。这两个信号最好用示波器在 PHY 引脚端抓一下波形MDC 频率注意不要超过 2.5MHz 这个上限很多 MAC 驱动的默认分频在 SoC 主频较高时会超超了之后表现就是读回来的寄存器值全是 0xFFFF 或者 0x0000。自举引脚是重灾区。PHY 上电时会采样一组引脚的电平来决定默认行为其中包括 PHY 地址也叫 MDIO 从地址、自协商使能、RGMII 延时使能等等。麻烦的是这些引脚往往和 LED 引脚复用。原厂参考设计上 LED 就那么接别人抄过来没事但如果你改了 LED 的上下拉方式PHY 地址可能就从 0 变成了 3你的驱动还在按地址 0 去找自然读不到。我这次就是因为把 LINK LED 的上拉去掉了想让灯灭得彻底一点结果 PHY 地址从 0 变成了 1排查了整整一个下午。所以上电前把手册里那张 strap 表格打印出来对着原理图一个一个勾确认每个自举引脚在复位释放瞬间的电平是你要的那个值。3. 让 MDIO 先开口说话PHY ID 读取与寄存器摸底3.1 三种读 PHY ID 的手段按成本排序最便宜的手段是用 MAC 驱动自带的探测逻辑。Linux 下加载网口驱动时dmesg 里通常会打印 PHY 的探测信息包括它在哪个地址上发现了设备、PHY ID 是多少。这条路径不需要额外工具缺点是一旦驱动报错退出你拿不到更多线索。第二种手段是用 mdio-tools 这类用户态工具在系统起来之后直接对 MDIO 总线做读写。它的好处是可以精确指定地址和寄存器号适合做逐地址扫描也适合在驱动已经绑定了 PHY 的情况下做寄存器微调。用法上就是先确认哪个网络设备对应哪条 MDIO 总线然后按地址 0 到 31 扫一遍寄存器 2 和寄存器 3能读出非 0xFFFF、非 0x0000 的值的地址就是 PHY 所在地址。第三种是硬件级的手段也是最根本的用示波器抓 MDC 和 MDIO 波形或者干脆用一块 MCU 写一段最小的 MDIO 时序去读。当软件层完全没反应的时候只有这种方式能告诉你到底是 MAC 没发出请求还是PHY 没应答。我在项目最开始的两天就是用一块 STM32 飞线到 PHY 的 MDC/MDIO 上写了个几十行的位操作程序才确认了 PHY 其实是活的问题出在 SoC 的 MAC 侧 MDIO 分频配置上。正常读到的 PHY ID寄存器 2 和寄存器 3 拼起来应该是一个固定值我这次读到的是 0x0000011A 这个量级的值。这里要强调一句不同型号、不同后缀、甚至不同批次的 ID 都可能不一样你一定要拿自己手上的手册去核对不要拿别人的博客数值当标准。我曾经就因为照着别的型号的 ID 去比对判定ID 不对说明芯片坏了白白换了两颗片子。3.2 读不到 ID 的排查顺序读不到的时候不要乱试按下面这个顺序走基本能定位地址先扫所有 32 个地址别默认就是 0。供电内核电压和 I/O 电压都要确认缺一路就是完全没响应。时钟示波器看 25MHz 是否有、幅度是否够、频率是否准。复位量复位引脚在空闲状态是否为高如果一直低PHY 永远不工作。MDC 频率抓波形算周期超过 2.5MHz 就调分频。MDIO 上拉量 MDIO 空闲电平必须被拉到高。信号完整性MDC/MDIO 走线是否过长、是否有过孔密集导致的反射。焊接最后再怀疑芯片本身BGA 或者 QFN 底部散热焊盘虚焊会导致这种半死不活的状态。这个顺序的核心逻辑是从最可能到最不可能从改起来最便宜到改起来最贵。地址和供电改起来一分钟换芯片要半天。3.3 常用寄存器摸底表ID 读通之后不要急着去配 RGMII先把几个关键寄存器读一遍建立对当前状态的认知。寄存器地址名称关注什么0x00基本控制软复位位、自协商使能、速率和双工强制位0x01基本状态自协商完成、链路建立、能力支持0x02 / 0x03PHY ID型号识别和手册比对0x04自协商通告本端向对端通告的能力0x05链路伙伴能力对端通告过来的能力能看出对面是谁0x09千兆控制千兆模式下的自协商相关配置0x0A千兆状态千兆链路是否建立、主从模式0x0D扩展状态一些厂商扩展的状态位0x1E / 0x1F扩展页选择 / 数据厂商私有扩展寄存器的入口第一次读的时候把每一页的 0x1E 写进去再把 0x1F 读出来能看到一些出厂校准值这些值一般是出厂烧录的如果读出来是全 0 或者全 F说明芯片校准数据异常基本可以判死刑了。这个判断方法比看 ID 更硬因为 ID 有可能是引脚 strap 出来的而校准数据只可能来自芯片内部。4. 链路能 up 但疯狂丢包RGMII 时序与延时分配4.1 RGMII 为什么天生就有时序难题RGMII 是 DDR 接口数据和控制在时钟的上升沿和下降沿各传一次所以 125MHz 的时钟对应 1000Mbps 的速率。这个设计节省了引脚代价是对时钟和数据之间的相位关系极其敏感。理论上接收端采样时需要时钟边沿落在数据眼图的中心也就是要有大约 1.5ns 到 2ns 的偏斜。问题是这个偏斜由谁来提供MAC 侧、PHY 侧还是 PCB 走线如果三方都没提供你会看到链路能 up因为自协商用的是低速信号不依赖精确延时但一跑数据就大量丢包如果三方都提供了偏斜叠加到 3ns 以上同样丢包。4.2 三种延时方案和它们的取舍方案做法优点风险MAC 内部延时在 MAC 控制器寄存器里开启改软件即可不动硬件部分 MAC 不支持或者只支持单方向PHY 内部延时通过 PHY 扩展寄存器配置通用性好主流方案寄存器页号容易搞错PCB 走线延时对 TXCLK/RXCLK 做蛇形绕线确定性最高不依赖软件改板成本高绕多长要算主流做法是让 PHY 内部做延时SoC 侧的设备树里把 phy-mode 写成rgmii-id含义是 PHY 内部同时给 TX 和 RX 加延时。如果写成rgmii就是两边都不加靠 PCB 绕线写成rgmii-txid或者rgmii-rxid则是只加一个方向。这四个字符串看起来差不多效果天差地别写错了就是能 up 不通。延时的目标值我一般在 1.5ns 到 2ns 之间取。PHY 内部延时通常是以步进为单位配置的步进值在手册里会写比如每档 0.1ns 或者 0.15ns你按目标值反推需要配多少档。4.3 实测调整过程和判定标准我这次的调整方法是这样的先把设备树设成rgmii-id让内核驱动自己去配 PHY 内部延时这是最省事的一步。跑 iperf3 单向如果 TCP 稳定在 900Mbps 以上不丢包基本就对了。如果丢包率在 1% 到 10% 之间晃说明延时偏了需要手工微调。手工微调走 mdio-tools 这条路先写 0x1E 选择扩展寄存器页再往 0x1F 写延时配置值然后用 iperf3 跑一轮 UDP 测试看丢包。一次改一档记录下来。我前后试了大概十几组值最后锁定在一个丢包为零的组合上。这里有个重要提醒用工具改的寄存器重启之后就没了。验证通过以后一定要把这个值固化到驱动的初始化代码或者设备树的延时属性里否则下次重启问题重现你又得重来一遍。判定调好的标准不能只看能 ping 通。我的验收门槛是三条同时满足ping 大包比如ping -s 1472连续十分钟零丢包iperf3 双向 TCP 各跑一分钟都能稳定在 900Mbps 以上换三根不同长度、不同品牌的网线重复上面两项结果一致。只满足第一条就下结论后期返工的概率非常大。5. 软件侧驱动匹配、设备树配置和日志抓取5.1 驱动从哪里来版本要注意什么内核主线从 5.15 开始就有针对这颗 PHY 的驱动支持文件名在drivers/net/phy/目录下以厂商名命名。如果你的 BSP 内核是 5.10 或者更早大概率是没有的需要把新版本的驱动单文件回移到自己的内核树里。回移的时候注意两个坑一是驱动依赖的 PHY 框架 API 在新老内核之间有差异比如某些读扩展寄存器的辅助函数在老内核里没有二是通用的 C22/C24 驱动框架本身的改动别只搬一个文件就编译会缺符号。判断驱动有没有正确绑定看 dmesg 里有没有出现设备探测成功的记录以及/sys/class/mdio_bus/下面能不能看到对应的总线目录。如果能读到 ID 但驱动没绑定通常是设备树里的 compatible 属性或者 reg 地址不匹配。5.2 设备树里的几个关键属性gmac0 { phy-mode rgmii-id; phy-handle phy0; clock-names stmmaceth, ptp_ref; status okay; mdio { #address-cells 1; #size-cells 0; phy0: ethernet-phy1 { compatible ethernet-phy-ieee802.3-c22; reg 1; reset-gpios gpio0 12 GPIO_ACTIVE_LOW; reset-assert-us 10000; reset-deassert-us 50000; }; }; };这里reg 1就是 PHY 地址一定要和硬件 strap 出来的值一致。reset-assert-us和reset-deassert-us是复位保持时间和释放后的等待时间单位是微秒别设太小。phy-mode前面讲过了。另外有些平台支持rx-internal-delay-ps和tx-internal-delay-ps这两个属性单位是皮秒可以比 phy-mode 更精细地控制延时如果你的平台支持优先用这两个来做微调比直接改寄存器干净得多。5.3 日常调试用的日志和状态手段看链路状态的命令就那么几个ethtool eth0看协商结果和速率双工ethtool -S eth0看收发统计里的错误计数CRC 错误、丢包计数、对齐错误这几个计数是判断误码最直接的窗口。ip -s link show eth0能看到收发字节数和错误数。抓内核日志用dmesg -w实时跟PHY 的链路变化事件会打在里面。还有一类工具值得准备串口调试助手用来盯启动日志尤其是从上电到内核起来的这段很多 PHY 初始化失败的信息只在最早那几行里出现网络调试助手用来做最上层的 UDP 收发验证比 iperf3 更直观能直接看到包的内容对不对适合排查链路没问题但数据错了这种诡异情况。这两个工具一个是下层的眼睛一个是上层的眼睛配合起来用。6. 压测验收与常见问题速查6.1 分层测试别一上来就压满我的测试是分层的从下往上逐层排除。第一层MDIO 能不能稳定读写寄存器连续读一百次 ID 看结果是否完全一致出现随机跳变说明 MDIO 信号质量有问题。第二层链路能不能 up插拔网线看 up/down 事件是否及时。第三层ping 小包和大包观察延迟和丢包。第四层iperf3 单向、双向、TCP、UDP 都跑一遍。第五层长时间稳定性连续跑两小时以上中间不要动它。第六层环境扰动比如用手碰一下网口附近、用对讲机在附近发射、拿热风枪稍微加热一下板子看链路会不会掉。最后一层主要是排查接触不良和抗干扰能力很多时候间歇性故障就是这么被逼出来的。6.2 常见问题速查表现象大概率原因处理方向MDIO 完全无响应供电缺失、时钟不起振、复位未释放按 3.2 节顺序排查PHY ID 读出来和手册不符地址错、strap 引脚电平不对核对自举表格和地址链路始终不 up变压器焊接不良、差分对开路、自协商被强制关闭量变压器两侧、检查寄存器 0x00能 up 但大量丢包RGMII 延时配置错误检查 phy-mode 和延时属性百兆正常千兆不通只用了两对线的通道有问题换网线、检查变压器四对是否都通up 了几秒就断反复重启复位信号被干扰、供电跌落示波器长时监控复位和电源换不同网线表现不同走线或者变压器余量不足检查阻抗和共模抑制高低温下链路不稳晶振温漂、电容不匹配换温漂小的晶振6.3 几个不写在手册里的经验阈值板子上跑 iperf3 时如果 CPU 占用率接近 100%那测出来的数字不一定是网口的极限先确认瓶颈不在 CPU 侧。MDIO 总线如果挂了多个 PHY总线上拉电阻要适当减小1.5k 到 2.2k 比较稳同时每个 PHY 的地址必须唯一。示波器抓差分信号别用两个单端探头去减要用差分探头否则看到的波形没意义。网线尽量用成品六类线自己压的水晶头经常是干扰源我至少有一次排查了两天最后发现是网线的问题。7. 踩过的坑和一些个人心得第一个坑是 LED strap 改了 PHY 地址前面说过了教训是任何和 LED、CONFIG 相关的上下拉改动都要回头翻一遍自举表格。第二个坑是照抄别的型号的寄存器页号。YT8531 的扩展寄存器需要通过 0x1E 选择页页号在手册里写得很清楚但我当时搜到一篇讲别家 PHY 的文章页号看着差不多就直接用了。结果调了半天延时发现改的其实是一个完全无关的功能位。所以凡是涉及扩展寄存器的操作页号、位定义、默认值逐条对着自己手上的手册抄抄完再核一遍。第三个坑是驱动里做了延时配置设备树里又写了一次两边叠加。这种情况的表现是链路能 up但怎么调都丢包而且丢包率随网线长度变化特别明显。排查办法是把设备树里的延时属性全部去掉只留 phy-mode跑一遍看基础表现然后再一项一项加回来。第四个坑是热插拔的瞬态。板子上电状态下插网线网口附近如果有感性负载或者电源余量不足会出现 PHY 短暂失联。解决办法是保证电源余量以及在复位引脚上并一个小电容做滤波容量不要太大否则会影响正常复位时序我一般用 100nF 级别。最后一个心得是关于调试节奏的。PHY 这种器件很多时候你改一个参数现象要等几十秒甚至几分钟才显现。所以每改一项都要等稳定之后再判断别改完立刻 ping 一下就下结论。我习惯每改一个参数就记录一条改了什么、跑了什么测试、结果如何。攒到十几条之后规律往往自己就浮出来了比凭记忆瞎试快得多。这套记录方法后面还可以继续用在别的高速接口上比如 SGMII、USB3.0、PCIe 的 bring-up思路是一样的先确认器件活着再确认物理层正确最后才谈性能和稳定性。