做底层驱动和BSP调试这几年我最常被问到的其实不是CPU本身而是PHY芯片。飞腾D2000和RK3568这两个平台一个是国产化信创场景里的常客一个是工控、边缘计算和EtherCAT用户手里的香饽饽芯片架构都是ARM看着差不多但真正调起PHY来踩坑的角度完全不同。我手上一块板子用的是裕太微YT8521另一块用的是老朋友AR8035两边都折腾过千兆丢包、CRC错误、冷启动link不上这些破事。这篇就把两个平台上的调试思路、寄存器读写手段、设备树配置要点和排障过程整理成一份能直接抄作业的避坑指南哪怕你是第一次调PHY跟着流程走也能少掉几斤头发。1. 平台底层的差异D2000和RK3568到底差在哪1.1 从SoC外设接口看RGMII、SGMII与PCIe的取舍先说结论飞腾D2000虽然有原生的GMAC接口但实际板卡上很少有直接把PHY挂在GMAC下的更多是通过PCIe转出网络控制器或者由国产交换芯片、BMC去承接网络路径。RK3568则完全不同它自带两个千兆GMAC控制器分别对应gmac0和gmac1其中一个还支持TSN时间敏感网络通过RGMII接口外接PHY是默认玩法。这个差异直接决定了你调试PHY时的工作方式。在RK3568上PHY挂在MDIO总线上内核里能看到完整的mdio bus、phy device、phy driver这套链路设备树里可以清清楚楚指定PHY地址、中断引脚、RGMII延时想改寄存器直接用mdio-tools读写就行。飞腾D2000这类平台如果是走PCIe网卡PHY一般被网卡芯片比如RTL8111、Intel I210内部管理对外不暴露MDIO接口你想直接读PHY寄存器基本没门。就算D2000集成了GMAC很多国产板子的固件或PMON飞腾平台的引导程序会提前把PHY初始化好内核驱动拿到的是一份已经配置完的“半成品”设备树里可能压根没有mdio节点出了问题只能去翻固件调试链路长得多。所以如果你拿到D2000的板子第一步不是去挖PHY而是先搞清楚网络路径到底是“GMAC直连PHY”还是“PCIe网卡”路径不同后边所有手段完全不一样。1.2 PHY驱动框架内核帮你做了多少事Linux内核的PHY驱动框架drivers/net/phy/已经非常成熟基本流程是MAC驱动或DSA驱动注册MDIO总线总线扫描得到PHY ID匹配PHY driver然后通过phy_state_machine状态机做自动协商、Link检测、速率切换。这套逻辑在RK3568上跑得很顺畅因为Rockchip官方内核已经适配好了gmac驱动你只要在设备树里把PHY节点描述准确基本开箱就能用。飞腾平台的BSP则比较多样化。有的用标准内核加补丁有的直接用厂商定制内核MDIO控制器驱动可能没完全暴露到用户态甚至在/sys/class/mdio_bus/下都看不到总线。这时候需要确认内核配置里有没有打开PHYLIB、mdio-bus-mux这类选项同时检查dmesg里有没有“mdio_bus: mdioxxx”的初始化打印。如果确实没暴露建议先在固件侧确认PHY初始化状态否则你在内核层折腾半天可能是白费力气。我在飞腾D2000上遇到过一种典型场景板卡PCIe通道挂了一颗RTL8211FPHY完全由RTL8168驱动接管但系统里还残留一个假的mdio节点导致设备树解析报错。这种问题表面看是PHY配置问题本质上是平台对网络路径定义不清属于“平台差异导致的地图开错”。2. YT8521与AR8035寄存器世界的两条脉络2.1 标准寄存器区0x00到0x1F是通用语言不管是裕太微YT8521还是高通Atheros AR8035第一眼看到的0x000x1F这32个寄存器都遵循IEEE 802.3标准。这意味着基本操作完全一致0x00 BMCR负责复位、自协商开关和速率控制0x01 BMSR反映Link状态、自协商完成标志和芯片能力0x02和0x03是PHY ID0x04和0x05看自协商广告和对端能力。调试时我首先会读0x01 bit2判断Link是否建立读bit5判断自协商是否完成。注意BMSR的bit2是锁存位必须读两次或者写1清除才能拿到实时状态这是很多人排查时容易忽略的细节。然后是0x02/0x03确认当前PHY的ID是否和预期一致很多时候设备树里写错了PHY地址读回来的ID会变成0x0000或0xffff一眼就能定位。用mdio-tools临时读一下比任何驱动日志都快mdio read eth0 0x01 # 读BMSR mdio read eth0 0x02 # 读PHY ID1 mdio read eth0 0x03 # 读PHY ID2标准寄存器区还有一个关键点0x00 BMCR的bit15是软件复位写入1会复位整个PHY并重新启动自协商。调试过程中我习惯先写BMCR复位等500ms再读状态这样可以排除芯片死锁的干扰。但注意复位后所有扩展寄存器配置都会丢需要重新初始化这在调试delay配置时很容易让人心态崩掉。2.2 YT8521的特殊玩法扩展页和私有寄存器YT8521是国产PHY里性价比很高的一款兼容RGMII和SGMII但它的私有配置不是全放在标准寄存器区而是通过扩展页机制访问典型操作是写0x1E寄存器页面选择切页再通过0x1F读写页面内寄存器。这和Marvell那套MMD思想类似不过寄存器地址含义完全是自家定义。调试中遇到最多的是RGMII的RX/TX延时配置。YT8521通过扩展页里的具体bit位控制RXC/TXC的延时但不同批次的芯片默认值可能不一样千万不要直接照搬datasheet里的“推荐值”。我在两块RK3568板子上用过同一型号的YT8521一块必须把RX delay调到固定值另一块默认值就完美差一个阻容摆位就能让时序完全变样。还需要注意的是YT8521和某些MAC配合时默认的clk output方向和行为可能与预期不符导致功耗异常或时钟干扰。碰到这种情况一定要把PHY的“clock output”相关寄存器先关掉再用示波器看波形而不是盲目怀疑delay配置。另外YT8521这类千兆PHY在EtherCAT场景下很常见原因之一是它支持在百兆强制模式下稳定工作。但需要注意如果你用IGHEtherCAT主站适配RK3568PHY的自协商一定要关掉强制100M全双工否则EtherCAT的实时帧抖动会让你怀疑人生。这个后面单独展开。2.3 AR8035的经典坑delay藏在0x1D/0x1E里AR8035作为Qualcomm的经典百兆/千兆PHY在路由器、网络打印机、高端工控板上用了很多年文档相对完整坑也相对固定。它一个比较大的特点是RGMII RX/TX delay默认通过硬件strape引脚RXD2、RXD3、RXD6等在上电瞬间锁存之后也支持通过Copper Specific Control寄存器0x1D、0x1E覆盖。我碰到过一种AR8035的典型问题硬件工程师按照SGMII模式设计PHY的strap引脚配置成无delay但实际跑的是RGMII模式结果千兆下丢包严重百兆正常。原因是RGMII标准规定发送端应该提供2ns延时这个在很多MAC上并未实现而AR8035的上电strap没配delay接收端又没加导致建立/保持时间不满足。这种情况光看寄存器状态根本看不出来必须拿到硬件原理图核对strap电阻。AR8035还有一个很出名的坑它的中断是开漏输出需要外部上拉很多板子为了省电阻直接悬空导致PHY中断一直拉高或拉低驱动侧的link状态变迁检测失灵。表现为系统运行一段时间后网口状态不刷新但业务流量还在跑。如果你发现网口Link状态和实际不符先量一下PHY的INT引脚电平别急着重刷固件。3. 调试第一课把工具链准备好再动手3.1 mdio-tools加ethtool的组合拳调试PHY寄存器最顺手的工具是mdio-tools它由mii-tool的作者维护提供了mdio和mdio-netlink两个命令支持通过netlink直接访问MDIO总线比老的phycalc好用太多。安装方式很简单一般直接apt或源码编译git clone https://github.com/wkz/mdio-tools.git cd mdio-tools make sudo make install使用上最频繁的是读和写mdio read eth0 0x01 mdio write eth0 0x00 0x8000 # 复位PHY mdio read eth0 0x02 mdio read eth0 0x03注意mdio命令操作的是net_device对应的PHY写寄存器前先确认网口是up状态否则部分驱动会直接把mdio操作丢弃。如果遇到“Operation not supported”大概率是网卡驱动没有实现mdio控制函数需要换用devmem直接操作MDIO控制器这个方法比较粗暴不推荐新手。在调试阶段每次读写寄存器的间隔最好控制在100ms以上尤其是写BMCR复位后立刻读状态大概率读到的是复位中间态。ethtool则是从驱动和协议层看全局ethtool eth0 # 查看速率、双工、自协商状态 ethtool -S eth0 # 查看硬件计数重点关注rx_crc_errors、rx_errors、tx_errors ethtool -s eth0 speed 100 duplex full autoneg off # 强制百兆全双工调试EtherCAT常用 ethtool --phy-statistics eth0 # 有的驱动支持输出PHY统计信息建议把这两个工具配合dmesg一起用PHY初始化阶段dmesg会打印link up/down、协商模式、PHY ID注册信息ethtool看协议层协商结果mdio看底层寄存器真实状态。三层数据对照才能准确定位是MAC问题还是PHY问题或者是物理链路问题。3.2 一张随时能查的寄存器速查表调试过程中最烦的就是翻datasheet几千页文档翻到眼花。我结合YT8521和AR8035的常用需求整理了一份速查表至少在现场能快速定位问题方向寄存器地址作用调试时怎么用BMCR0x00控制复位、自协商、速率、双工写0x8000复位写0x1000开自协商BMSR0x01Link状态、自协商完成、能力读bit5和bit2注意link位是锁存位PHY ID10x02芯片厂商ID高16位判断当前PHY是否被正确识别PHY ID20x03芯片厂商ID低16位与0x02配合确认PHY型号ANAR0x04本端自协商能力确认是否广播1000M/100M能力ANLPAR0x05对端自协商能力确认对端广播了哪些能力判断协商不一致1000BASE-T Control0x09千兆master/slave、test mode遇到千兆协商不稳定时可读少改1000BASE-T Status0x0A千兆协商状态、master/slave结果排查千兆降级为百兆的问题对于YT8521还要补充一个关键点0x1E是扩展页选择寄存器0x1F是数据端口。不同page里的bit定义差异很大我通常会在拿到新批次芯片后先把0x1E设置成0x0000再读0x1F把默认值记录下来再和datasheet比对确认芯片不是翻新料。AR8035则重点关注0x1D和0x1E这两个铜缆控制寄存器delay配置和配对极性检测都在里面。但这两颗芯片的私有寄存器地址不通用千万不要把YT8521的经验原封不动套到AR8035上。曾经有人在AR8035上照搬了YT8521的delay寄存器地址结果把AR8035的某个测试模式打开网口彻底闷死最后只能断电重启。4. 设备树与固件配置让PHY正确的“进场”4.1 RK3568设备树MDIO与PHY节点RK3568官方内核里gmac1的典型设备树是这样组织的gmac1 { phy-mode rgmii; clock_in_out input; snps,reset-gpio gpio4 RK_PB4 GPIO_ACTIVE_LOW; snps,reset-active-low; snps,reset-delays-us 0 20000 50000; pinctrl-names default; pinctrl-0 gmac1_rgmii_pins; status okay; mdio1: mdio { compatible snps,dwmac-mdio; #address-cells 1; #size-cells 0; phy0: ethernet-phy0 { reg 0; reset-gpios gpio4 RK_PB4 GPIO_ACTIVE_LOW; reset-delay-us 20000; }; }; };这里最值得注意的坑有三处。第一phy-mode到底用rgmii还是rgmii-id直接影响MAC侧和PHY侧谁负责延时。如果你在PHY里已经通过寄存器配了RX/TX delay并且硬件上PHY不负责额外延时那么这里应该写“rgmii”避免两边同时加延时而导致时序翻倍。反过来如果PHY采用默认加延时模式而MAC侧也配了delay就会出现双倍延时千兆直接跑出大量CRC错误百兆可能侥幸能跑。第二snps,reset-gpio和PHY节点里的reset-gpios要统一。我见过有人MAC层配了一个GPIOPHY节点又配了另一个结果PHY被反复复位状态机一直处于重新启动自协商的状态。建议只保留PHY节点里的reset定义时序控制更清晰。第三PHY地址reg必须和硬件电路一致常见的是0、1、4、7。如果读PHY ID读到0x0000或0xffff首先检查reg地址其次检查reset引脚是否拉了足够长时间有些PHY要拉低50ms以上才算彻底复位配置里的reset-delay-us不要太抠门。4.2 飞腾D2000平台的特殊性飞腾平台在网口配置上不像RK3568那样标准化很多时候PMON或UEFI固件里已经把PHY初始化流程写死了。比如固件里跑了一段自协商内核启动后又重新复位PHY再自协商一次两次配置不同就会导致Link状态不稳定表现为开机后前几秒能上网之后网口就通了但丢包。如果遇到这种情况优先检查固件里是否设置了“auto-negotiation disable”或者“force link speed”。飞腾D2000的GMAC如果走SGMII对接交换芯片PHY往往是管理型交换芯片内置的而不是独立PHY芯片寄存器访问路径更加隐蔽。我的经验是先看固件源码里的serdes配置确认SGMII/QSGMII通道对应的PHY地址范围再用示波器量serdes参考时钟不要一上来就怀疑内核dts。另外飞腾D2000平台上如果走PCIe网卡PHY的寄存器基本没法通过标准mdio总线访问这时候要在网卡驱动的私有ioctl上下功夫。比如某些国产PCIe网卡的PHY是挂在内部MDIO上的驱动支持通过ethtool register dump间接读取。遇到问题先用ethtool -d eth0 dump一份寄存器现场比瞎猜强得多。4.3 RX/TX Delay 到底该怎么配这是千兆RGMII最核心、最玄学的部分。RGMII标准原始定义是发送端加2ns延时接收端不加这样可以避免PCB走线带来的偏差。但实际MAC和PHY厂商各有各的做法导致“谁负责延时”成了千古难题。我自己的判断方法是先用排除法。第一步把MAC和PHY的所有delay全部关掉用短网线30cm以内直连交换机跑千兆看是否通。如果全关能通说明PCB走线非常干净后边只是小修小补。如果全关不通第二步打开PHY端的TX delay也就是MAC接收方向只开这一个再测。如果通了说明问题出在MAC侧接收采样窗口可以尝试微调RX delay。第三步如果只开TX delay还不够再逐步开RX delay注意每次只改一个变量。在RK3568上可以在设备树里通过tx_delay和rx_delay属性调整单位是ns或0~15的档位但这只影响MAC内部的delay不会自动匹配PHY的配置。我通常把MAC侧的全关掉完全通过PHY寄存器做delay微调这样更可控。YT8521的delay调整在扩展页里AR8035在0x1D/0x1E里两边要多试几组值记录下来最后选一版在高温和低温下都稳定的参数。另外delay调完之后要用iperf或者ping -f做长时间压力测试单纯ping通不算数。我遇到过RK3568配好之后ping能通但跑iperf到800Mbps就疯狂掉包最后发现是TX delay多加了0.5ns导致高速传输时窗口抖动。5. 千兆CRC错误一场典型的信号与时序排障5.1 从现象定性开始“百兆正常千兆出现接收硬件CRC很多错误”这个现象背后通常不是芯片坏了而是物理层的某种不匹配。我拿到这种问题第一步不是动代码而是先看错误计数分布ifconfig eth0 ethtool -S eth0 | grep -E crc|error如果RX方向的rx_crc_errors持续增长而TX方向是干净的问题大概率在PHY接收链路可能是RGMII RX delay不对、PCB走线过长、PHY的1000BASE-T信号质量差、或者对端交换机端口能力不足。如果rx_errors和rx_crc_errors同时涨还要考虑MDI/MDIX配对问题也就是TX/RX线对是否被错误识别。千万不要忽略一种安静的场景百兆正常千兆CRC错误高发但dmesg里没有任何异常ethtool里Link依然是1000M。这说明自协商已经完成物理层能建立千兆链路但数据采样边缘靠近临界区域属于“能通但随时可能崩”的状态必须靠调整delay或检查时钟来解决。5.2 排查步骤实录我通常按下面的顺序排查性价比最高每一步都能排除一个变量。第一步强制降速到百兆ethtool -s eth0 speed 100 duplex full autoneg off如果降到百兆后CRC计数归零说明MAC侧的DMA配置基本没问题问题集中在千兆特有部分也就是RGMII的三组时钟/数据线时序或者1000BASE-T的物理层协商细节。第二步用mdio读取0x0A1000BASE-T Status Register看master/slave配置和link partner的协商结果。正常情况下两个设备之间master/slave必须一主一从如果都认为自己是master千兆协商会反复抖动。这种场景多出现在两块板卡直连时一端PHY配置强制master另一端也强制master。第三步逐项调整delay。我把delay调整想象成“在一个时间窗口里找采样点”一点点移。每次调整后用下面这个命令打流量iperf3 -c 192.168.1.2 -t 60 -u -b 900M如果UDP丢包和CRC计数都下来说明时序窗口对了。只ping不通不代表延时没问题必须用UDP或TCP高压测试验证。第四步如果delay调完还是有问题回到硬件。示波器量PHY的125MHz时钟看上升沿是否干净、有没有明显振铃。RGMII千兆模式下PHY输出时钟抖动如果超过200ps数据线时序基本都会崩。时钟源来自晶振还是SoC的CLKOUT两种场景下的容忍度不同。我遇到过YT8521用SoC时钟输出做参考源时由于CLKOUT驱动能力不够导致时钟边沿变缓CRC错误高发换成外部有源晶振后问题消失。这已经不是软件能解决的了。5.3 一例真实排障过程说一个例子RK3568 YT8521设备树rgmii模式全默认配置跑千兆ping包正常但iperf3打流后rx_crc_errors每秒掉几千个。我先强制百兆CRC清零。然后用mdio读0x0A发现master/slave协商结果是slave正常。然后我将MAC侧tx_delay从默认值逐档往下调同时监控rx_crc_errors。调到某几个档位时CRC瞬间降了一大截。最终把tx_delay设为0、通过YT8521扩展页打开RX delay生效同时关闭MAC侧delayCRC归零。之后用高低温箱验证-10℃到70℃都稳定。这个案例的关键是“双击”问题默认配置下MAC侧和PHY侧对delay的归属不清晰等于两边都没有提供有效延时或不一致延时导致千兆的RX采样窗口正好卡在数据跳变边缘。百兆速率低窗口宽不影响千兆速率高窗口窄直接崩。6. 常见问题与避坑速查表6.1 冷启动Link不上但复位后正常这种问题在YT8521和AR8035上都遇到过典型特征是断电重启后网口无法link但加载驱动后手动reset一下又好了。根源往往是PHY的上电时序和SoC的GPIO reset时序不满足要求PHY要求上电后至少等待一定时间才能释放reset否则内部配置加载不完整。解决方法是确保设备树或驱动里reset-delay时间足够。我见过有人把reset-delay-us设置为2000us结果PHY的供电电容还没充满就拉高了reset所以网口早上起不来。建议至少给20ms。还有一些板子在PHY的电源轨上加了大电容上电瞬间电压爬升慢reset释放后PHY在内核配置时还没ready此时可以通过检查dmesg来看是否是reset GPIO反复触发。如果复用GPIO有问题要确认GPIO的默认方向和默认电平。有些GPIO控制器在系统启动前默认输出低导致PHY一直被复位直到驱动加载后才正常。6.2 百兆正常千兆错误这个基本可以锁定在RGMII接口的延时配置上具体排查逻辑在第5章已经写透。这里补充一个容易忽略的变量对端设备的PHY能力。有些老交换机千兆口是“只支持1000BASE-T但不支持EEE节能以太网”如果本端PHY开启了EEE可能造成兼容性问题。排查时可以强制关闭EEE试试一般在ethtool里ethtool --set-eee eth0 eee off另外网线质量也很重要。千兆跑在4对线上其中任何一对接触电阻过大或线序错误都会造成CRC错误。如果调整delay后依然不达标换一根短一点的六类网线重新测试至少能排除物理线缆的干扰。6.3 EtherCAT场景下的额外功课最近很多人在RK3568上适配EtherCAT IGH主站我也折腾过一遍。EtherCAT对以太网链路的要求比较苛刻不要求高带宽但要求低延迟和低抖动。所以PHY这边要做几个固定动作关闭自协商强制100M全双工ethtool -s eth0 speed 100 duplex full autoneg off在驱动侧关闭中断合并如e1000e的int_moderation或Rockchip GMAC的napi weight调小。PHY的中断引脚尽量不要使用轮询模式IGH对时间敏感轮询会造成抖动。如果使用YT8521还需要关注它在100M模式下的时钟行为有些版本默认对外输出25MHz如果电路上没做隔离可能干扰相邻走线。EtherCAT调试时如果出现周期性丢帧不要只盯PHY建议在IGH主站日志里同时打开周期统计。通过观察实际周期误差进一步定位是MAC侧的中断延迟还是PHY在link切换时的额外开销。6.4 速查表遇到的坑和对应解法现象可能原因优先排查动作读PHY ID为0x0000PHY地址错误或复位未完成写BMCR复位等50ms再读核对reg地址读PHY ID为0xffffMDIO总线通信失败、MDC/MDIO引脚极性错误用示波器量MDC/MDIO确认驱动是否注册mdio busLink up但ping丢包延时配置不匹配、对端协商异常ethtool -S看CRC和error计数调整delay千兆降到百兆master/slave协商不一致、线缆不支持千兆读0x0A检查master/slave换线测试冷启动link不上reset时序不满足、供电电容未充满加大reset-delay-us到20ms以上CRC错误随温度变化加剧delay余量不足、时钟抖动过大高低温下测delay窗口调整PHY侧delayEtherCAT周期性丢帧中断合并、PHY轮询、自协商抖动关闭自协商和中断合并IG日志看周期误差寄存器写入不生效PHY处于隔离模式或电源down读0x00确认bit10和bit11状态最后再分享一点个人经验PHY调试最大的敌人不是芯片而是“默认值”三个字。YT8521和AR8035的默认寄存器配置放在不同的MAC、不同的PCB走线、不同的时钟源下表现天差地别。拿到一块新板子第一步一定是完整dump一遍全部PHY寄存器保存成baseline以后每次出问题都能对比“默认状态”和“异常状态”。不要凭经验一上来就改这改那先把现场留档再去动手术。这个习惯帮我省下了大量时间也让我在换批次芯片后能快速发现是芯片默认值变了还是板子走线出了问题。