嵌入式Linux网络驱动调试：PHY寄存器与mdio-tool/ethtool实战指南

做嵌入式Linux开发这么久网络驱动这块儿坑是真的多。特别是PHY芯片出问题的时候板子上一会儿通一会儿不通或者速率死活协商不上来那种抓瞎的感觉我太熟悉了。很多朋友一上来就翻驱动源码结果看半天头更大了。其实在调试网络驱动和PHY的时候最趁手、最直接的武器就是mdio-tool和ethtool这两个命令行的工具。今天就把我平时调PHY寄存器的路子整理一下从原理到实战把这儿掰开了揉碎了讲清楚。1. 内容整体设计与思路拆解1.1 为什么调试网络驱动要先搞懂PHY寄存器我们常说的网口在主控芯片SoC这边通常分成两部分一个是MAC控制器负责数据链路层的逻辑另一个是PHY芯片负责物理层的信号收发、编码、协商这些脏活累活。两者之间通过MII接口Media Independent Interface介质无关接口连接接口形态有MII、RMII、GMII、RGMII这些花样本质都是传输数据用的。而MAC和PHY之间的控制通道叫做MDIO接口也就是Management Data Input/Output它是用来读写PHY内部寄存器的唯一通道。调试网络驱动本质上就是在调MAC和PHY之间的配合。PHY芯片内部有很多寄存器比如基础控制寄存器 registers 0、基础状态寄存器 registers 1、PHY ID寄存器 registers 2和3、自动协商通告寄存器 registers 4这些寄存器控制了PHY的工作模式、速率、双工、是否开启流控、是否开启交叉直连自适应等功能。搞不定PHY寄存器你连网线插上灯亮不亮的原理都说不清楚。1.2 mdio-tool和ethtool的分工与合作这两个工具不是竞争关系而是配合关系。ethtool是用户态的网络配置工具它通过socket和内核网络协议栈通信然后由内核的PHY驱动框架去读写PHY寄存器它的优势是能查看和配置网络设备的上层属性比如速率、双工、Wake-on-LAN还能读到很详细的link状态统计。而mdio-tool是一个更底层的直接读写工具它直接通过MDIO总线去访问PHY芯片的寄存器完全绕过了网络协议栈和内核PHY驱动框架的层层封装适合需要直接看裸寄存器值的场景。我个人的习惯是先ethtool看整体状态再mdio-tool深入硬件底层两者结合效率是最高的。2. 核心细节解析与实操要点2.1 学会读状态位基础状态寄存器里的门道PHY的基础状态寄存器Register 1是调试时最先要看的寄存器之一。这个寄存器的bit 1是Link Status位bit 5是自动协商完成位bit 6是远端故障标志bit 11~14表示当前协商的能力。我在调试中最常用的操作序列如下# 查看当前网口link状态 ethtool eth0这个命令的输出里Speed、Duplex、Auto-negotiation这几个字段就是底层PHY状态寄存器翻译过来的。如果显示Speed: Unknown!那多半是link丢了如果显示自动协商是off那可能有人在某个环节把它关掉了。然后用mdio-tool来看更细的东西# 读取PHY地址为0的芯片寄存器1的原始值 mdio-tool eth0 0 1看到这个寄存器的16进制原始值之后手动换算成二进制去对照bit位这个习惯会让你对底层机制的理解有一个质的提升。2.2 搞定MDIO总线从驱动树到用户态的命令通路很多时候mdio-tool读写不成功并不是命令敲错了而是MDIO总线的拓扑没搞对。现在的SoC基本都会把MDIO控制器做成一个独立的驱动节点而挂在它下面的PHY芯片是子节点。设备树里通常长这样mac { status okay; phy-mode rgmii-id; phy-handle phy0; mdio { #address-cells 1; #size-cells 0; phy0: ethernet-phy0 { reg 0; compatible ethernet-phy-id001c.c915; reset-gpios gpio1 26 GPIO_ACTIVE_LOW; }; }; };如果你是在老内核或者用mdio-tool直接敲命令必须确认PHY芯片的地址是几。一般PHY地址是由硬件上PHY_AD[2:0]引脚的电平决定的最常见的是0x00或者0x01也有的板子是0x04、0x0F具体要看原理图。我曾经碰过一块板子PHY地址是0x1F所有标准工具默认读地址0导致看到的寄存器全是0xFFFF折腾了半天才反应过来。正常运行时你可以在Linux里用下面的命令枚举一下当前系统里有哪些MDIO总线设备ls /sys/bus/mdio_bus/devices/如果没有把PHY驱动编进内核有可能会出现设备节点存在但读写不响应的情况。排查的时候先用mdio-tool去读PHY ID寄存器寄存器2和寄存器3确认能不能读到正确的ID。2.3 从原理图到代码确认PHY芯片的关键参数与锁存时机调试PHY时光会敲命令不行还得会看原理图。PHY芯片一般都有几个配置引脚比如PHY_AD[2:0]决定PHY地址CLK_25M决定时钟方向MODE引脚决定RMII/RGMII模式还有LED模式配置这些引脚在芯片上电复位的时候会被锁存决定PHY的初始工作状态。如果你在驱动里设置的模式和硬件配置冲突后面就会出现各种诡异现象。我曾经用一款常见的国产PHY芯片硬件上MODE引脚通过上下拉设置成了RMII模式但设备树里写的是rgmii-id结果驱动的初始化流程完全错乱link灯虽然会亮但数据包一个都发不出去。后来用mdio-tool读到PHY的控制寄存器和状态寄存器再对照数据手册的引脚复用表格才定位到问题。所以在动手之前把原理图里PHY周边的上下拉电阻看一遍往往能节省大量排查时间。3. 实操过程与核心环节实现3.1 环境准备与工具编译没有现成工具的板子怎么办很多ARM板子的文件系统里并不自带mdio-tool需要自己交叉编译一个扔进去。源码从内核社区或者GitHub都能找到是一段非常精简的C代码编译起来几乎没有依赖。具体过程如下# 下载源码 git clone https://github.com/Windows10CE/mdio-tool.git cd mdio-tool # 交叉编译 export CROSS_COMPILEarm-linux-gnueabihf- make编译完生成的mdio-tool是静态的还是动态的取决于你系统的libc情况。一般嵌入式根文件系统比较精简建议静态编译make CFLAGS-static把这个工具通过NFS挂载或者adb push等方式传到板子上chmod x之后就能用了。ethtool一般根文件系统里都有如果没有也建议用对应的交叉编译工具链编一份。它依赖libmnlnetlink消息库编译的时候记得把这个库也编进去。交叉编译ethtool时有一个小坑就是configure脚本检测libmnl时容易出错建议用如下命令./configure --hostarm-linux-gnueabihf --prefix/usr/local/arm/ethtool make make install DESTDIR$PWD/_install然后把libmnl的so库一起拷贝到板子的/lib目录下。如果懒得折腾这些依赖也可以直接在板子上用opkg或者apt安装不过要确保软件源的架构匹配。3.2 第一步等PHY稳定先看基础link状态接好串口和网线板子启动进系统之后别急着敲寄存器先让系统和PHY稳定一下。然后执行ifconfig eth0 up ethtool eth0如果输出如下说明PHY的状态基本是健康的Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Link detected: yes这里有一个非常关键的点PHYAD字段显示的0就代表内核驱动认为PHY芯片的MDIO地址是0。如果你的PHY硬件地址不是0这里就会显示对应地址。如果写驱动的时候把phy-handle配错了这个字段会和你原理图上的设计不一致。如果Link detected显示no可以用mdio-tool直接读基础控制寄存器和基础状态寄存器mdio-tool eth0 0 0 mdio-tool eth0 0 1寄存器0的值如果bit 0也就是0x1000为1说明软件把PHY的power down关掉了如果bit 12为0说明自动协商没有使能。我在调试中遇到过一种情况PHY的link状态显示up但是寄存器1里的link status位始终为0后来检查发现是差分信号线布线太长信号质量太差导致PHY一直检测不到有效链路这种情况重写软件没有任何意义必须从硬件上解决。3.3 第二步直读PHY ID确认芯片是否在总线上存活PHY ID寄存器寄存器2和寄存器3是只读寄存器内容是芯片出厂时固化的ID号。用mdio-tool读一下mdio-tool eth0 0 2 mdio-tool eth0 0 3以RTL8211系列为例寄存器2通常读到0x001C寄存器3读到0xC915如果你在数据手册里查到对应关系一致说明MDIO通路没问题芯片是活的。这时候如果网还ping不通问题大概率不在底层通路而在网络配置上。如果读到全是0xFFFF或者全是0x0000那就要小心了。0xFFFF一般是MDIO引脚或者地址不对相当于总线悬空读了个寂寞0x0000说明这地址上没挂设备或者设备被reset了。验证PHY是否被复位一直拉低可以用示波器量一下PHY的RESET_N引脚复位信号上电时是不是有个从低到高的跳变。用mdio-tool读PHY ID这一步我是每块新板子必做的能最快速度排除底层通路故障再做上层协议栈心里就有底。3.4 第三步修改PHY寄存器强制指定速率与双工模式有时候PHY自动协商老是不正常需要强制设置100M全双工来排查。这时可以用mdio-tool直接往控制寄存器寄存器0写值。寄存器0的关键bit位如下bit 13: Speed LSB与bit 6结合使用bit 6: Speed MSBbit 8: Duplex Mode1为全双工0为半双工bit 12: Auto-negotiation Enablebit 9: Restart Auto-negotiation以强制100M全双工为例先关掉自动协商然后设置速度和双工位# 将寄存器0清零相当于先复位 mdio-tool eth0 0 0x0 # 设置成100M全双工bit 8 1 (全双工)bit 13 1 (speed LSB)bit 6 0 # 组合起来就是 0x2100 mdio-tool eth0 0 0x2100把0x2100展开成二进制就是0010 0001 0000 0000bit 13为1bit 8为1对应100Mbps Full Duplex。然后执行ethtool eth0确认一下ethtool eth0如果显示Speed: 100Mb/s, Duplex: Full说明设置生效此时可以ping一下对端PC验证链路通信。调试完成后记得把自动协商打开# 重新开启自动协商 mdio-tool eth0 0 0x1000这里我要专门提醒一句强制定速率只适合临时验证问题不适合长期让设备运行在固定速率下。因为很多交换机和路由器默认是老式半双工模式一旦你强制了100M全双工而它对端是半双工就会出现大量的CRC错误和丢包。我见过一个项目就是有人调试完忘了恢复自动协商结果产线烧录完一批板子到客户现场全部网络丢包严重最后查了一个星期才发现是这个寄存器被强制写死了。3.5 第四步用ethtool的统计信息反推硬件问题ethool不只能看link信息还能读网口的MAC层统计计数器这对排查物理层和数据链路层问题非常有帮助ethtool -S eth0输出里一般会有rx_errors、tx_errors、rx_crc_errors、rx_frame_errors等字段。如果rx_crc_errors数量持续增长说明线路上有干扰或者对端在发坏帧如果是tx_errors持续增长优先检查PHY的配置尤其是时钟极性和延时。对于比较新的内核还可以用ethtool的--phy-statistics参数直接看PHY层的统计信息ethtool --phy-statistics eth0不同的PHY芯片这个命令的输出字段差异很大但通常都会包含symbol errors、false carrier、serdes errors这些物理层的指标。这些字段对判断信号完整性有直接帮助。我曾在一款车载以太网的项目中用这个命令发现symbol error数值异常大后来定位是PCB上网络变压器的抽头接地没有处理好属于硬件设计层面的问题。3.6 第五步利用dump寄存器快速诊断PHY异常当遇到link反复up/down、协商不稳定这类问题时逐个寄存器去看太累建议直接把整个寄存器空间全部读出来。有些版本的mdio-tool支持dump功能mdio-tool dump eth0 0如果工具不支持dump自己写一个for循环去循环读写也没问题for reg in $(seq 0 31); do echo Reg[$reg] 0x$(mdio-tool eth0 0 $reg) donePHY的核心寄存器基本集中在0x00到0x1F这32个寄存器空间里扩展寄存器需要通过特殊方式访问后面细说。把整套寄存器值dump出来之后对照数据手册逐一核实尤其是那些只读的状态位和中断标志位往往在硬件异常时会有很典型的比特组合。我做调试时习惯把正常的和异常的寄存器dump各存一份用diff命令直接对比定位速度会快很多。4. 常见问题与排查技巧实录4.1 问题一PHY地址是0x1F怎么访问都失败有一些PHY芯片的默认地址是0x1F比如某些Marvell和Broadcom的芯片这种地址超出了一般工具默认的地址范围。如果你用mdio-tool eth0 0 2去读可能什么也读不到。这时候需要指定正确的PHY地址来操作# 方式一如果mdio-tool支持直接指定地址参数 mdio-tool eth0 0x1F 2 # 方式二通过mii-tool的phy参数 mii-tool --phy0x1F eth0有的芯片还有一个扩展地址机制比如通过写寄存器0x0D和0x0E来间接访问扩展寄存器。这种芯片你在它的标准寄存器空间里看不到全部信息需要额外的操作流程。找驱动源码的时候看到phy_write这种调用多追一层就能发现扩展寄存器的访问方式。4.2 问题二ethtool可以读PHY但mdio-tool直接报错这个现象一般出现在设备树没有把MDIO子节点正确注册的情况下。ethtool请求走到内核PHY驱动框架时驱动会通过自己的回调函数去访问PHY这时代码路径已经绕过了通用MDIO总线所以即使总线上设备树没有配置好也可能正常工作但mdio-tool是直接打开/dev/miiio设备节点或者通过socket访问MDIO总线如果对应节点不存在或者权限不对就会报错。解决方案是检查设备树里mdio子节点的状态确保它挂在正确的MAC节点下并且status不是disabled。还有一种可能是MDIO控制器驱动没有编译进内核在kernel config里搜一下MDIO_BUS相关的选项grep CONFIG_MDIO /boot/config-$(uname -r)如果ONFIG_MDIO_BUS_MUX没有打开也会导致某些PHY挂在mux总线上时mdio-tool完全无响应。4.3 问题三自协商老是失败强制性速率才行这个现象最容易让新手误判为PHY芯片坏了。其实大部分情况出在硬件信号完整性和变压器端接上。排查思路先确认差分线等长是否满足RGMII模式下时钟线和数据线的skew是否在PHY芯片允许的范围内再用ethtool -S观察CRC错误数有没有指数级增长。如果是软件层面导致的自协商失败最常见的就是自动协商通告的速率能力与实际硬件不匹配。比如你的对端交换机只支持10/100M但PHY通告了1000M能力在某些质量不佳的网线/连接器下协商过程会异常。这时候用mdio-tool把寄存器4自动协商通告寄存器改一下只通告100M能力# 寄存器4 0x01E1 表示通告 10M half/full, 100M half/full mdio-tool eth0 0 4 0x01E1然后重启自动协商mdio-tool eth0 0 0 0x1200 # 也可以在驱动里调 phy_restart_aneg() 函数来完成这个动作4.4 问题四PHY寄存器写不进去值写不进去值有两类原因。一类是物理层面的问题比如MDIO信号线上的上拉电阻太大导致驱动能力不足另一类是MAC芯片的MDIO控制器配置问题比如某个厂商的MAC控制器需要先把MDIO时钟分频系数设置正确否则时序不满足PHY芯片的要求寄存器写了等于白写。我碰到过一次特别极端的情况某SoC的MDIO控制器寄存器物理地址需要先解除写保护才能操作不然所有读写都会失败。这种问题只能靠仔细阅读SoC的数据手册和参考驱动源码去发现工具本身是帮不了你的。遇到写不进去的时候第一时间去翻SoC参考手册有时候配置GPIO复用为MDIO功能的寄存器没设对也会出现这种问题。4.5 问题五网络从休眠唤醒后PHY寄存器值被清空这个现象在低功耗设备上非常常见。系统进入suspend状态后PHY芯片通常会被断电或者进入低功耗状态RAM中保存的寄存器配置在唤醒后会丢失需要重新初始化。如果你发现唤醒后link正常但速率不对多半就是PHY没有执行完整的初始化。解决方式是在驱动里注册suspend/resume回调函数在resume过程中重新配置PHY。实际操作中可以使用内核里的phy_init_hw函数和phy_start函数确保唤醒后的PHY能恢复到正常状态。5. 常用寄存器速查表与定义梳理5.1 标准PHY寄存器集从Reg 0到Reg 31IEEE 802.3标准定义了一套PHY寄存器集只要是符合标准的PHY芯片前16个寄存器地址的含义基本是一致的。下面是我自己积累的速查表分享出来供大家参考寄存器地址名称关键bit说明0x00控制寄存器bit15: 软件复位bit13b6: 速率选择bit12: 自动协商使能bit11: 功率下bit8: 全双工bit9: 重启自协商0x01状态寄存器bit5: 自协商完成bit2: 链路状态bit6: 远端故障bit11~14: 协商能力0x02PHY ID High高16位ID只读0x03PHY ID Low低16位ID包含型号和版本号只读0x04自协商通告bit4: 10M halfbit5: 10M fullbit6: 100M halfbit7: 100M fullbit8: 1000M halfbit9: 1000M fullbit13~15: 流控0x05自协商链路伙伴能力对端支持的能力只读0x06自协商扩展状态用于检测远端的能力变更0x0D扩展寄存器地址选择配合0x0E使用选择要访问的扩展寄存器编号0x0E扩展寄存器数据读写扩展寄存器时数据从这里进出后面从0x10到0x1F的寄存器一般是厂商自定义的中断状态、LED控制、测试模式寄存器不同PHY芯片定义完全不一样没有通吃的速查表只能查对应芯片的数据手册。5.2 两个翻得最多的寄存器位link状态与软复位Status寄存器的bit 2是Link Status这个bit有一个特殊性它是锁存型的链路断了之后它会一直保持0必须读一次寄存器之后才会刷新。所以如果你只读一次寄存器看到link断开不要急着下结论多读两次确认一下。用mdio-tool读的时候重复敲几次mdio-tool eth0 0 1 mdio-tool eth0 0 1 mdio-tool eth0 0 1控制寄存器的bit 15是软件复位向该bit写1会触发PHY的软复位流程复位过程中所有寄存器值会恢复到默认值复位完成后该bit自动归零。如果驱动初始化之后PHY工作状态异常可以手动触发一次软复位往往能解决很多奇怪问题# 写控制寄存器bit15置1其他位保持不变 mdio-tool eth0 0 0x8000不过要提醒的是软复位需要一定的时间才能完成一般是几十毫秒到几百毫秒如果复位后马上读寄存器可能读到的还是旧值。在脚本里加个sleep再继续操作。5.3 扩展寄存器当0x00到0x1F不够用的时候现代PHY芯片的功能越来越多比如支持VoIP、支持Energy Efficient Ethernet、支持1588 PTP的时间戳功能这些能力需要大量的配置寄存器而标准寄存器空间只有32个显然不够用。于是厂商们引入了扩展寄存器机制常见的是通过寄存器0x0D选择索引寄存器0x0E读写数据。在RTL8211系列里这个机制叫做Extended Page。用mdio-tool访问扩展寄存器的方法比较麻烦因为它本身没有直接支持这个流程。你可以写一个小脚本模拟这个操作# 第一步选择扩展页地址 mdio-tool eth0 0 0x0D 0x0001 # 第二步写扩展寄存器值 mdio-tool eth0 0 0x0E 0x1234 # 第三步读扩展寄存器值 mdio-tool eth0 0 0x0E每次切换扩展寄存器地址都要重新写寄存器0x0D这在写自动化脚本的时候尤其要注意。如果你需要频繁操作扩展寄存器建议直接在驱动里封装一个函数不要依赖shell脚本。6. 调试方法论与个人心得6.1 从外到内从易到难调试网络驱动的顺序建议我要推荐一套自己常用的排查路径先看硬件状态网线、指示灯再用ethtool看软件状态再动手改PHY寄存器最后才去翻代码。这个顺序能最大限度地减少你在错误方向上浪费时间。有一次一个同事让我帮忙看一个千兆网口只能协商到百兆的问题。我上来先看了两个板子上的硬件配置发现其中一块板子的PHY旁边的终端电阻焊错位了导致信号反射严重协商不到千兆属于典型的硬件问题。如果直接陷入软件排查几天都出不来。6.2 mdio-tool虽好但批量操作建议写脚本mdio-tool一次只能读写一个寄存器但调试过程中往往需要对多个寄存器做连续操作。比如想确认PHY各个功能模块是否开启需要读控制寄存器、状态寄存器、通告寄存器等多个地址。这时候写个简单的shell脚本就很重要能省去大量的重复敲命令时间。我一般会在板子上放一个/etc/phy_debug.sh这样的脚本内容是各种测试函数比如read_all、force_100f、an_enable、soft_reset用参数来调用。这样就算过了一个月再调试也能快速进入状态。脚本用busybox的sh和mdio-tool组合就能实现不需要额外的依赖。6.3 遇到怪异现象先检查时钟和复位PHY是一个模拟和数字混合的芯片对外部时钟和复位时序都极其敏感。如果遇到PHY寄存器能读、能写但是功能完全不对的情况优先查一下PHY的参考时钟是否正常复位引脚的电平时序是否满足数据手册的要求。RGMII接口模式下RX时钟和TX时钟都是由外部晶振或者MAC提供的如果时钟频率偏移超过50ppm就会出现丢包严重或者link频繁up/down。6.4 记录关键寄存器值建立自己的基线台账每个项目的PHY芯片型号不一样同一型号的不同批次寄存器默认值也可能存在差异。我的习惯是板子首次正常运行后马上dump一份完整的寄存器值保存下来作为这个板子的基线台账。之后每次改动硬件或者驱动先dump一份新的再和基线对比能快速发现异常变化。这个台账还能在量产阶段帮大忙产线反馈某批次网口不稳定直接拿异常板子和基线对比定位问题快得飞起。7. 结语与扩展建议这部分本可以不写但实在是有太多朋友私信问到后续怎么深入所以多说几句。调试PHY寄存器只是嵌入式Linux网络驱动开发的一小部分真正驱动工作的复杂度远不止这些。想深入的话推荐把内核里drivers/net/phy/nxp-tja11xx.c、marvell.c、realtek.c这几个厂家的PHY驱动读一遍再结合你手里的开发板和示波器把每次调试过程记录下来形成自己的经验库。工具永远只是辅助你对芯片和数据手册的理解深度才决定了调试效率的上限。最后再分享一个小技巧调试时养成动不动就抓包的习惯用tcpdump把网络流量存下来有些PHY寄存器层面的问题会在报文层面留下痕迹两者相互印证排查问题的准确率能提高一个台阶。