硬件板卡调试里有一类问题特别磨人现象看起来一样换个平台、换颗PHY排查思路却要全部推翻。我之前在一套双千兆网口方案上先后用过飞腾D2000和RK3568两个主控平台PHY也分别在YT8521和AR8035之间来回切换期间在RGMII接口的RX/TX Delay配置上栽了不止一次跟头。最典型的一次是RK3568配YT8521百兆完全正常千兆一协商上就疯狂报接收侧硬件CRC错误速度起不来还伴随丢包。当时第一反应是PCB布线或者连接器有问题示波器量了一圈没有明显短路或断线最后才把矛头指向RGMII时序。这篇文章把我的排查思路、寄存器读写方法、设备树配置的坑以及从D2000平台迁移到RK3568时的经验整理出来希望能帮到正在做同样平台迁移或双千兆调试的BSP、嵌入式驱动和硬件工程师。1. 从D2000到RK3568一次“看似简单”的PHY迁移先说项目背景。原来的产品是基于飞腾D2000做的双千兆以太网口PHY选的是裕太微YT8521整机跑Linux。D2000平台上这套网络已经跑得很稳无论是普通业务还是长时间压测都没有问题。后来因为成本和供货原因主控要换成RK3568硬件工程师几乎是把原来的网络部分原样搬过去的——同样的YT8521同样的RGMII接口甚至连PHY地址的上下拉电阻都保持一致。我们一开始乐观地以为软件上只要把设备树搬过去改一改时钟和复位引脚网络就能直接跑起来。实际结果当然没有这么顺利。RK3568平台启动后接口link是能起来的ethtool看协商也正常但一旦跑千兆传入方向的CRC错误就开始暴涨。另一个容易让人麻痹的现象是百兆完全正常丢包为零只有千兆有问题。这个特征让我走了不少弯路因为直觉会告诉你“PHY本身应该是好的问题可能出在别的环节”但实际上它恰恰是RGMII时序配置错误的一个典型表象。在这套方案里我还遇到过一个需要同时兼容AR8035的情况。AR8035是高通系的老牌千兆PHY在很多进口模组和工控板卡上都能看到。YT8521则是国产方案里出货量不小的替代者二者在功能上高度对标都是单端口千兆、支持RGMII/SGMII驱动模型也都是标准phylib那一套。但寄存器级的delay配置方式差别很大AR8035在一些标准的MII寄存器里就能改YT8521则需要走扩展寄存器空间接下来我会单独讲这块。先给这篇文章划个调子PHY调试本质上就是在调三样东西——MDIO总线能不能正确访问到PHY寄存器、PHY的电气参数尤其是RGMII的delay和时钟配置是否正确、设备树或UBoot里描述的复位/时钟/模式是否与硬件一致。平台怎么换这三个问题是不变的。只是D2000和RK3568的SDK风格差异比较大导致你在A平台养成的习惯到了B平台不一定适用。2. 平台差异第一课MDIO总线上怎么找到PHY调试PHY的第一步永远是确认软件能不能通过MDIO总线访问到PHY寄存器。读不到PHY ID后面什么延时、协商、EEE全是空谈。这一小节把D2000和RK3568两个平台在MDIO访问上的差异讲清楚顺便给出一套排查“读不到PHY”的思路。2.1 PHY地址不是猜的是strap引脚定的PHY芯片的地址一般不是软件硬编码而是由芯片的strap引脚在复位时采样的常见设计里用4到5个地址引脚接上下拉电阻来决定。我接触过的板卡里YT8521经常被设计成地址0x18AR8035则常见0x04但这只是“常见”实际一定要去查硬件原理图或者直接量strap电阻不能想当然。我在飞腾D2000平台上第一次调YT8521的时候就吃了这个亏。驱动里默认PHY地址填了0x04结果内核启动时MDIO扫描一直报“PHY ID not found at addr 4”。后来翻原理图才发现板子上把YT8521的地址拉到了0x18改完设备树里的phy-handle地址一次就通了。到了RK3568平台因为板子基本上是复刻过去的地址没变但对不同PCB版本还是可能不同所以推荐在调试开始前用命令实际读一遍总线上的PHY ID。2.2 D2000和RK3568的MDIO访问路径差异飞腾D2000的以太网控制器在SDK里通常是飞腾自己封装的GMAC设备树里也有独立的mdio节点Linux走的是标准phylib框架。有时候PHY寄存器的读写还会经过UBoot阶段初始化内核启动后直接沿用UBoot配置。所以在D2000上如果UBoot阶段网络能起来进内核后一般不会出现“MDIO读不到”的问题但如果UBoot和内核的设备树对PHY地址描述不一致就会出现“UBoot能通内核不通”的怪现象。RK3568则是标准的Rockchip GMACgmac0和gmac1两组控制器设备树里既有mdio节点也有phy节点结构比D2000更直接。常用的调试工具仍然是一样的。当你怀疑MDIO读取有问题时Linux下最先尝试的应该是下面几条命令# 查看网口连通状态和协商速率 ethtool eth0 # mii-tool 是老牌工具能看到link/协商结果 mii-tool eth0 # 用mdio-tools读取PHY ID寄存器0x02和0x03组合出PHY ID mdio read eth0 0x18 0x02 mdio read eth0 0x18 0x03 # 如果板子上没有mdio工具也可以从sysfs读取 cat /sys/class/net/eth0/phy_id cat /sys/class/net/eth0/phy_driver # 查看网口统计信息确认是否有CRC/错误帧 ethtool -S eth0 ifconfig eth0如果没有mdio-tools用busybox的devmem也可以直接访问D2000或RK3568的MDIO控制器寄存器但需要查对应SoC的TRM拿到MDIO基地址和位域定义操作起来比较费劲我一般只在调试早期临时用。2.3 读不到PHY ID时的排查表如果你发现内核日志里出现“mdio_bus: phy not found”之类的提示或者ethtool根本看不到PHY不要急着怀疑驱动。按照下面的顺序排查大多数问题都能在5分钟内定位。排查方向典型现象检查方法PHY复位引脚没释放始终读不到PHY ID用万用表量PHY reset引脚电平确认复位芯片/GPIO正常拉高PHY地址strap不对在某地址扫描不到对照原理图确认strap电阻总线扫描时尝试0x00-0x1FMDIO上拉电阻缺失时有时无概率性失败查看原理图MDIO/MDC是否有上拉尝试降低MDC频率两个PHY地址冲突只有其中一个能识别检查双网口板卡上两片PHY的strapping地址是否错开电源/时钟未就绪上电后短时间内失败检查PHY供电时序和时钟输入适当增加复位延时需要说明的是RK3568支持双GMAC两个PHY的地址一定要设计成不同地址否则MDIO总线挂在同一组控制器下会冲突。有些硬件工程师做兼容设计时会预留两套地址选择电阻但容易在BOM替换时焊错。软件上最直接的验证方法是循环扫描总线上所有PHY地址看每个地址读出的PHY ID值是否合理。扫描可以通过脚本快速做一遍这里以mdio-tools为例for addr in $(seq 0 31); do echo -n addr $addr: mdio read eth0 $addr 0x02 2/dev/null || echo N/A done正常情况下会产生一个有效的PHY ID如果所有地址都是出错或全0/全1的组合基本可以确定问题在硬件侧而不是软件配置。3. RGMII的RX/TX DelayAR8035和YT8521各藏各的坑到了这一步MDIO能读到PHYlink也能建立但性能上不去甚至CRC报错大概率就是RGMII Delay配置的问题。这一节先把原理讲明白再分别说AR8035和YT8521的寄存器怎么配。3.1 为什么RGMII天生需要DelayRGMII是一种源同步接口发送端把数据和时钟同时送出去接收端需要在时钟沿附近采样数据。RGMII规范要求时钟沿和数据变化沿尽量对齐但实际上接收端要稳定采样最好让时钟中心落在数据的稳定窗口内。因此无论是MAC侧还是PHY侧必须在时钟或数据路径上额外地移相约1.5ns到2ns——这就是大家常说的TX Delay和RX Delay。拿数字说话千兆模式下RGMII时钟是125MHz周期8ns数据在上下沿都变化实际每个数据位只占4ns。扣除PCB走线和芯片内部的setup/hold时间真正留给你的时序余量可能只有1ns左右。delay多加0.5ns或者少加1ns就有可能导致采样点落在数据跳变沿附近产生误码。所以你会看到delay配置错误时链路虽然建立但包错误率非常高。百兆就完全不同25MHz时钟周期40ns余量极其充裕这就是为什么很多delay配错的板子百兆做长ping都没事一切到千兆就原形毕露。3.2 AR8035的Delay配置方式AR8035相对友好的一点是它的RGMII Delay配置直接放在标准MII寄存器0x04里不需要切MMD页。寄存器0x04 bit[7]RGMII TX clock delay使能置1开启约1.5ns左右的发送延时寄存器0x04 bit[6]RGMII RX clock delay使能置1开启接收延时调试时可以直接用mdio命令操作# 读取当前0x04的值 mdio read eth0 0x04 0x04 # 在0x04基础上开启TX和RX delayAC1010 1100 mdio write eth0 0x04 0x04 0xAC上面例子中的0xAC是一种常见的组合实际要读出来再改。需要注意的是同一颗AR8035在D2000和RK3568上的初始寄存器值可能不一样因为UBoot阶段可能已经做过初始化。所以调试时务必先读、后改不要直接写入一个“经验值”。3.3 YT8521的Delay配置方式到了YT8521这块事情就没那么直观了。YT8521也支持通过标准寄存器配置大部分功能但RGMII delay这类参数藏在扩展寄存器空间里。标准MII寄存器0x0D和0x0E负责MMD设备地址和数据的访问你需要根据datasheet找到delay对应的MMD地址页和偏移再通过0x0D/0x0E间接读写。裕太微官方Linux驱动里一般也提供了对应的配置接口所以如果你用的是厂家驱动这一步也许会由驱动根据phy-mode自动完成。但问题恰恰出在“自动完成”上。很多RK3568板子的设备树里写的是phy-mode rgmii-id这个模式表示PHY侧自己插入TX和RX delay。如果驱动或UBoot也按照这个模式配置了YT8521的delay寄存器那么链路两侧MAC和PHY就都加了delay。此时百兆还能勉强工作千兆就非常容易CRC错误。我遇到的情况正是如此设备树写的是rgmii-id但PHY寄存器里delay bit也置1了等于重复加delay。在调试阶段最直接的办法是手动读写YT8521扩展寄存器来确认delay bit的状态。由于不同版本的YT8521其扩展寄存器地址不完全一致我这里不给死地址只描述我的操作习惯# 用mdio read读取0x0D先设置MMD设备地址再通过0x0E读回数据 mdio read eth0 0x18 0x0D mdio read eth0 0x18 0x0E # 再根据datasheet的MMD页号设置不同的device address后读对应偏移如果你不想折腾寄存器也有一个更简单的“黑盒判断法”临时把设备树的phy-mode从rgmii-id改成rgmii。如果修改后CRC明显减少说明PHY侧很可能也被驱动配置了delay重复加了。这个判断法我后面会再展开讲。3.4 设备树phy-mode和Delay的归属关系在实际开发中delay到底谁负责加通过设备树的phy-mode字符串来约定。这是RGMII调试里最核心的“契约”phy-modeMAC侧delayPHY侧delay适用场景rgmii否否两侧都不插delay需外部电路/非常规一般不建议rgmii-txid是否MAC插入TX delayPHY不处理rgmii-rxid否是只由PHY插入RX delay少见rgmii-id是是最常见双方各管一段或由某一侧负责全部真正调试时最容易出问题的就是“双方各管一段”变成“双方都管同一段”。RK3568的GMAC驱动在识别rgmii-id这类模式时会在MAC内部插入delay如果你的PHY驱动或UBoot初始化代码看到同样模式又给PHY插了delay重复配置就出现了。所以拿到板子时第一件事是确认你的一个delay到底是在哪一侧生效的而不是一味相信设备树。4. 百兆正常、千兆CRC错误频发完整排查链路复盘这一节是整篇文章的重头戏。先从现象出发把“百兆正常、千兆CRC错误”的完整排查过程拉一遍。这个过程同样适用于AR8035只要把寄存器差异替换掉就行。4.1 现象复现和初步判断我遇到的情况是系统跑在RK3568上eth0接的是YT8521通过交换机连测试机。默认自动协商百兆下连续ping 10000个大包零丢包。切到千兆后ping大包就会出现明显的时延抖动偶尔直接超时。ethtool -S eth0的输出里rx_crc_errors和rx_missed_errors在几分钟内持续增长如果长时间跑iperf甚至会出现网口down/up的情况。这个阶段先不要急着改寄存器按顺序确认以下三点# 1. 确认当前协商结果 ethtool eth0 # 2. 确认是否有link flap查看内核日志 dmesg | grep -i eth0\|phy\|link # 3. 分别测上行和下行流量 iperf3 -c 192.168.1.10 -t 30 # 默认测发送 iperf3 -c 192.168.1.10 -t 30 -R # 反向测试接收上行和下行出问题对应的方向是不同的。如果是接收方向CRC多大概率是RX delay或PHY采样问题如果是发送方向有问题先怀疑TX delay。这种方向性信息能帮你少做一半无用功。4.2 完整排查链路下面是我整理了多次调试经验后的排查顺序按怀疑程度从高到低排列强制千兆全双工测试。用ethtool -s eth0 speed 1000 duplex full autoneg off固定到千兆排除自动协商期间频繁link切换造成的干扰。强制后如果完全不link或依旧CRC基本可以肯定是物理层/时序问题。修改设备树中的phy-mode在rgmii和rgmii-id之间切换观察CRC变化。如果切换后有明显改善说明当前delay配置是主犯。直接读写PHY寄存器确认delay bit的实际状态排除驱动“配置了但没配置成功”的情况。检查PHY参考时钟。用示波器量PHY的125MHz时钟或XI/XO引脚看频率是否准确、边沿是否干净、有没有明显抖动。频率差太多会造成符号间干扰也会表现为CRC错误。检查MAC的RX_CLK和RXD信号质量。这一条最耗时但也最有效示波器探头放在PHY/MAC的RX_CLK和RXD[0..3]上看数据建立保持时间是否满足。没有示波器条件时可以退而求其次通过网线测试仪确认线对良好。排除EEE/节能以太网。PHY开启EEE后在某些交换机的兼容性很差link状态下进入低功耗模式再唤醒会产生突发CRC。可以把PHY的EEE关掉再测试。检查网线和连接器质量。千兆用4对线全部传输只要有一对线接触不良link能协商上千兆但CRC错误会非常多。这个原因在“百兆正常千兆不行”的场景里出现的概率也很高不能因为信号问题就先入为主只怀疑芯片寄存器。每一步都建议做一次“改动前后对比测试”保留ethtool -S的快照方便对比。别凭感觉判断“好像好了”。4.3 一次实际复盘RK3568 YT8521的CRC问题定位那次的问题具体表现是开机后link到千兆ethtool -S显示rx_crc_errors每秒都在增加跑iperf3的接收方向带宽只有几十兆。我先按上面的顺序做了一遍。第一步强制千兆问题依旧。第二步把设备树从rgmii-id改成rgmii重新编译内核dtbCRC数量立刻下降了一个数量级但还没有完全归零。这个结果说明了两个问题一是MAC侧插入delay后链路确实有改善说明MAC侧原本没插delay或插得不对二是CRC还存在说明还有一处delay配置可能在捣乱。第三步用mdio read去读YT8521扩展寄存器里的delay位结果发现PHY侧delay bit被置1了。这样就形成了“MAC也加delayPHY也加delay”的重复配置。我在UBoot和内核启动脚本里检查了一遍发现是UBoot在初始化PHY时手动设置了YT8521的delay寄存器而内核设备树又用了rgmii-id重复加delay就被实锤了。第四步关掉PHY侧delay保留设备树rgmii-id让MAC侧插入delay重新启动后千兆跑满CRC归零。这个复盘有点反直觉修改设备树phy-mode为rgmii时CRC只是减少而不是消失说明设备和代码环境中的delay“来源”不止一处——不要只盯着一个配置文件。UBoot、内核设备树、PHY驱动、甚至板级初始化脚本都有可能插手。4.4 为什么百兆正常、千兆会崩这个问题值得单独说一句。百兆模式下时钟频率25MHz数据在上下沿采样后等效速率50Mbps一个位宽方向的周期40ns信号在跳变沿附近即便被采错也在后续采样窗口里留有巨大裕量。千兆模式下125MHz时钟周期8nsRGMII在每个沿传4bit意味着有效窗口只有4ns实际考虑PCB走线、芯片工作温度、电源纹波上下沿留给你delay的容错范围经常不到1ns。CRC错误本质就是接收端采样到了错误的数据组合而千兆模式对采样点的要求比百兆严苛得多。所以百兆一切正常只能说明PHY芯片、网络变压器、RJ45链路和内核驱动基本没问题不能作为“时序正确”的判据。4.5 其他会导致千兆CRC的因素除了delay还有几个因素在实际项目中把我坑过一并列出来MAC控制器的时钟源配置错误。RK3568的GMAC时钟需要根据PHY的接口模式选用合适频率如果时钟树配置乱了MAC侧输出的125MHz信号质量会很差。PHY供电纹波偏大。PHY的模拟部分对电源敏感电源纹波在百兆下可能被容忍千兆高频率下则直接表现为误码。PCB走线阻抗不连续。尤其RJ45到网络变压器再到PHY之间如果过孔或换层过多千兆信号完整性问题会被放大。软件再折腾也救不回严重走线问题。网口隔离变压器选型不合适回波损耗过大。这个在量产中才容易暴露。如果是这类硬件设计问题软件调试能做到的只是尽量准确下结论然后把现象和数据反馈给硬件工程师避免反复猜测。5. 设备树迁移D2000与RK3568对同一颗PHY的描述差异平台迁移时设备树几乎是最容易出错的地方。D2000和RK3568的SDK风格差异较大同一个PHY在两套设备树里的描述语言和组织方式完全不同。下面以YT8521在双千兆板卡上的设备树为例列出常见的坑。5.1 一个典型的YT8521设备树对比飞腾D2000平台的设备树里网络节点的风格通常更接近“标准Linux GMAC模板”phy-mode和mdio节点在同一个父节点下reset信号往往由板级驱动或UBoot做不一定会写进dts里。示例大致如下gmac0 { status okay; phy-mode rgmii; phy-handle phy0; mdio { #address-cells 1; #size-cells 0; phy0: ethernet-phy18 { reg 0x18; /* 部分版本还需要在这里配max-speed或者eee-broken-1000t */ }; }; };RK3568的设备树风格则完全围绕Rockchip的GMAC驱动展开除了phy-mode还需要配置时钟源、复位GPIO、pinctrl等。常用的配置片段长这样gmac0 { status okay; phy-mode rgmii-id; clock_in_out input; snps,reset-gpio gpio3 RK_PB7 GPIO_ACTIVE_LOW; snps,reset-active-low; snps,reset-delays-us 0 10000 50000; assigned-clocks cru SCLK_GMAC0_RX_TX, cru SCLK_GMAC0; assigned-clock-rates 0, 125000000; assigned-clock-parents cru SCLK_GMAC0_RMII_SPEED, cru SCLK_GMAC0_RGMII_SPEED; pinctrl-names default; pinctrl-0 gmac0_miim gmac0_tx_bus2 gmac0_rx_bus2 gmac0_rgmii_clk gmac0_rgmii_bus; phy-handle phy0; mdio { compatible snps,dwmac-mdio; #address-cells 1; #size-cells 0; phy0: ethernet-phy18 { reg 0x18; }; }; };两组代码最直观的区别是RK3568需要明确clock_in_out和assigned-clocks而D2000往往不需要在dts里关心MAC侧125MHz是从哪来的。如果你在D2000上习惯了只写phy-mode和phy-handle到了RK3568就非常容易漏掉时钟树配置。5.2 PHY复位GPIO和时序RK3568 SDK里挺喜欢用snps,reset-gpio来让GMAC驱动在初始化PHY前拉低并释放复位脚。这个机制本身很方便但有几个坑reset-delays-us的前两个参数分别是“拉低后延时”和“拉高后等待”具体含义需要查dwmac驱动实现。有的SDK版本是0 10000 50000有的版本可能把单位或顺序搞错会导致PHY还没就绪内核就去读PHY ID报mdio_bus: phy not found。如果硬件上用了一个专门的复位芯片控制PHY复位且该芯片由某个GPIO控制那么设备树里snps,reset-gpio和GPIO子系统拉高的时序可能会打架表现为概率性起不来。解决办法通常是在驱动初始化前额外加msleep。我在D2000平台上没见过snps,reset-gpio这种写法基本是UBoot里拉GPIO复位PHY。所以迁移到RK3568时一个容易犯的错误是把复位控制交给内核驱动但UBoot里又没释放干净导致复位时序异常。5.3 时钟配置125MHz到底谁给谁RK3568的GMAC时钟配置其实有一个很关键但很多人忽略的点RGMII模式下GMAC的RX/TX时钟可以由PHY提供时钟输入也可以由MAC提供时钟输出对应的设备树就是clock_in_out input或output。这个必须和硬件设计一致。clock_in_out inputPHY提供125MHz时钟给MAC。常见于外挂晶振给PHY提供独立时钟的场景。clock_in_out outputMAC提供125MHz时钟给PHY。此时需要确保assigned-clock-rates里SCLK_GMAC0_RX_TX设置为125MHz否则PHY可能没有工作时钟或者方向错误。这个配置错了常见现象是PHY完全link不上或者link后随机掉线。和delay问题不同它通常从最开始就不正常不会给你“百兆正常千兆CRC”的过渡性表现。但如果你把clock_in_out填反也可能出现千兆下CRC多、百兆下勉强能用的现象因为PHY内部时钟倍频链在输入质量不好时仍能勉强工作只是误差偏大。排查方法是量PHY的125MHz时钟脚看看到底有没有时钟、时钟是PHY输出的还是输入的。5.4 在RK3568上做EtherCAT IGH主站时的额外提醒最近“正点原子RK3568 EtherCAT”和“适配RK3568的EtherCAT IGH主站驱动”这两个方向很热很多实时通信项目都在RK3568上跑IGH主站。EtherCAT对链路稳定性的要求比普通以太网苛刻得多PHY一旦出现零星CRC实时帧的丢帧就会导致主站报错甚至紧急停机。结合我的经验针对EtherCAT场景需要额外注意三点第一PHY的EEE和低功耗特性一定要关掉。EtherCAT要求主站和从站之间的链路始终处于全速工作状态节能状态下唤醒导致的首帧延迟破坏实时性。在PHY寄存器或设备树中关闭相关能力。第二建议固定速率全双工不要依赖自动协商。自动协商能正常工作但每次link down/up的恢复时间在EtherCAT主站轮询周期里是不可接受的。IGH主站的网卡驱动建议配置为强制千兆或强制百兆具体取决于你的从站支持情况。第三做长时间丢包测试。EtherCAT跑起来后用ethtool -S持续观察CRC错误和missed_error。要求不是“偶尔一次”而是连续长时间运行完全为0。只要CRC计数有缓慢增长就说明链路余量不足必须排查delay或信号质量问题否则现场一定会出事故。6. 稳定性验证与量产避坑经验最后聊一聊稳定性验证和量产阶段容易踩的坑。这部分内容来自我带项目时积累的教训不一定写在任何芯片手册上但非常实用。6.1 一套能发现CRC问题的验证清单我不建议只靠“ping 1000包不丢”就判定网络OK。实际测试时我会按下面的清单过一遍# 1. 持续ping大包至少10000包观察最差延迟和丢包 ping -s 1472 -c 10000 192.168.1.10 # 2. iperf3双向吞吐确认发送和接收方向都跑满千兆 iperf3 -c 192.168.1.10 -t 60 iperf3 -c 192.168.1.10 -t 60 -R # 3. 混合帧长测试64B小包最容易暴露转发性能瓶颈 iperf3 -c 192.168.1.10 -u -l 64 -b 100M -t 30 # 4. 持续观察网口统计 watch -n 1 ethtool -S eth0 | grep -E crc|error|missed如果条件允许最好用两台同样的设备对测而不是用不同厂商网卡交换测试。因为不同网卡的信号质量和对delay的容忍度不同A网卡通过不代表你的设备没问题。6.2 寄存器基线快照和对比量产阶段如果出现“设备用一段时间后性能下降”的反馈比较高效的手段是提前留存PHY寄存器基线快照。开发阶段每调好一个版本就把PHY 0x00到0x1F的标准寄存器全部读出来连同扩展寄存器关键区域一起存成文本。现场出现问题时用同一套脚本读回当前的寄存器状态diff一下就能发现哪些位被改变了。我在AR8035上就遇到过PHY的master/slave配置在长时间运行后被交换设备重新协商改变的情况导致链路速率从千兆掉到百兆。如果没有寄存器基线这个问题会排查很久有基线后一眼锁定变化位直接看是不是master/slave强制配置问题。6.3 三个让我记忆深刻的量产经验第一个是YT8521的EEE默认行为。某批次整机测试时发现千兆链路偶尔出现几秒钟的hang然后自动恢复。后来抓取寄存器快照发现PHY的EEE状态位反复切换。在UBoot阶段把EEE关掉后问题彻底消失。如果你的PHY也频繁出现“链路莫名恢复”的现象可以先排查EEE。第二个是网线质量在千兆下会被放大。实验室测试用的跳线都是品牌六类线现场客户可能随便拿根五类线或者线序不对的线接上。五类线在百兆没问题千兆就可能疯狂CRC。这个不是软件问题但你得能快速判断是线的问题还是板子问题。第三个是温度对PHY的影响。量产高低温测试中某台机器在55度环境下跑iperf出现零星CRC错误常温下完全正常。最终定位到PHY的供电电感在高温下饱和电流下降纹波增大。软件里可以通过关闭EEE、降低工作频率等方式缓解但根治还是得改硬件。对于这种问题软件工程师能做的事情是尽早做高低温验证不要到量产阶段才暴露。PHY调试看似繁琐其实关键点非常集中。只要你把MDIO链路确认、RGMII delay归属、设备树时钟配置这三件事打通D2000和RK3568之间迁移或者YT8521和AR8035之间互相替代都会顺利很多。真遇到千兆CRC别先怀疑玄学按链路、delay、时钟、电源、连接器这个顺序一步一步用数据说话问题通常都能找到根因。
