第3章 调试工具介绍：mdio、i2c、PCIe配置空间、Ethernet tools
调试PHY寄存器，说白了就是跟芯片内部的状态机、寄存器位、时序打交道。你用对了工具，几分钟就能定位问题；拿错了工具，可能折腾一整天也摸不着头脑。我最早做嵌入式的时候，手边只有一根JTAG线，翻遍手册找不到对应PHY的调试接口，那叫一个痛苦。
这一章我们就来聊聊那些常用的调试工具。我会把每种工具的核心用法、优缺点，以及我踩过的坑都摊开来说。
核心观点：没有万能的工具，只有合适的组合。调试PHY时，你至少需要掌握mdio和通用总线（I2C/PCIe）两类工具的用法。
3.1 mdio —— PHY调试的"万能钥匙"
mdio（Management Data Input/Output）是IEEE 802.3定义的PHY管理接口。你想想看，几乎所有独立PHY芯片都支持这种接口。它有两根线：MDC（时钟）和MDIO（数据）。通过这两根线，你就可以读写PHY内部的所有寄存器。
为什么我偏爱mdio？
- 通用性强：从百兆到千兆PHY，接口协议完全一样
- 寄存器透明：直接访问从0x00到0x1F的标准寄存器空间
- 工具廉价：一个mdio适配器也就几十块钱，甚至可以用逻辑分析仪模拟
我在一个交换机项目中遇到过PHY频繁断链的问题。当时就是靠mdio反复读状态寄存器，发现链路状态在Link Up和Link Down之间周期性跳变。最后找到原因——芯片的电气特性导致丢同步头。嗯，如果没有mdio，这种间歇性问题几乎没法定位。
标准mdio调试流程：
- 确定PHY的mdio地址（通常是硬件pin脚决定）
- 使用mdio工具（如MII-tool或自家驱动）发送读请求
- 解析返回的16位寄存器值
- 对照手册，排查特定bit的含义
# 命令行mdio读写示例（Linux环境）
# 读PHY地址0x01的寄存器0x01（状态寄存器）
mdio eth0 0x01 0x01
# 输出示例：0x796d —— 其中bit2是Link Status
# 写寄存器，配置PHY的自动协商参数
mdio eth0 0x01 0x00 0x1000
个人经验：如果mdio工具返回全0xFFFF或0x0000，八成不是线没接好就是PHY地址搞错了。我曾经因为这个排查了半小时，结果发现是PCB上PHY地址pin的电阻焊错了。
3.2 i2c —— 躲在暗处的调试通道
有些PHY芯片（尤其是集成在SoC内部的）并没有独立的mdio接口。但放心，它们通常会挂在一个I2C总线上。为啥？因为I2C的引脚更少，布线更灵活。
i2c调试PHY的特点：
- 地址映射复杂：PHY寄存器可能被映射到I2C设备的某个内存块
- 需要先初始化I2C控制器：不像mdio那样开箱即用
- 速率限制：典型I2C速率100kHz~400kHz，不能频繁读写
我记得调试一款车载以太网PHY时，芯片手册说支持MDIO接口，但实际电路板只把PHY挂在了I2C上。我花了整整一天才通过I2C读通第一个寄存器。你想想看，I2C的多字节读写时序和mdio完全不同。
I2C调试小技巧：
- 先用i2c-detect扫描总线上有哪些设备
- 确认PHY的I2C地址正确（通常7位地址+读写位）
- 大部分PHY会把内部寄存器映射到0x00-0xFF的地址空间
# Linux环境下I2C读写PHY寄存器
# 扫描I2C总线，寻找PHY设备
i2cdetect -y 1
# 读PHY寄存器0x10的值（设备地址0x18）
i2cget -y 1 0x18 0x10 w
避坑指南：我曾经遇到一个PHY芯片，它的I2C地址和PCIe配置空间的地址是冲突的。每次通过I2C读写都会导致PCIe链路复位。切记，在调试前先确认总线拓扑，避免同时操作。
3.3 PCIe配置空间 —— 藏在PC内部的PHY
现在越来越多的网络芯片把PHY和MAC集成在同一个PCIe设备里。这时候，PHY寄存器不直接在CPU地址空间可见，而是藏在PCIe配置空间后面。
为什么我们要用PCIe配置空间来调试PHY？
- 有些PHY会被映射成PCIe设备的扩展配置空间（Extended Configuration Space）
- 厂商自定义的PHY寄存器通常放在Vendor Specific Capability里
- 通过PCIe配置空间的读写，可以绕过操作系统复杂的网络协议栈
我在调试一款25G网卡时，发现内核的驱动老是在初始化PHY时卡死。后来我通过lspci -vvv查看了PCIe配置空间，自己写了个小工具去读写PHY寄存器。嗯，终于定位到问题——驱动里写入了一个错误的PHY ID。
调试常用命令：
- lspci -s 02:00.0 -vvv —— 获取PCIe设备的配置空间信息
- setpci（直接读写配置空间寄存器）
- 通过Linux的/sys/bus/pci/devices/下的资源文件进行mmap访问
# 读取PCIe设备的扩展配置空间（BDF为02:00.0）
# 读取偏移0x100处的4字节（PHY寄存器映射位置）
setpci -s 02:00.0 ECAP_ACCESS=0x100
setpci -s 02:00.0 ECAP_DATA
核心难点：PCIe配置空间的访问需要特权级别（root权限），而且在虚拟化环境中可能需要直通设备。我建议你在项目开始前就确定好调试环境的权限和拓扑。
3.4 Ethernet tools —— 网络协议层的"旁敲侧击"
有时候你根本接触不到硬件总线，比如只有一根网线连到设备上。这时候Ethernet tools就派上用场了。通过标准的网络协议（ARP、ICMP等）可以间接推断PHY的状态。
常用工具：
| 工具 | 用途 | 获取的信息 |
|---|---|---|
| ping | 测试链路是否连通 | 间接判断PHY链路状态 |
| ethtool | 查看网卡/PHY状态 | Link detected、Speed、Duplex、Auto-negotiation |
| tcpdump / wireshark | 抓包验证链路层行为 | CRC错误、帧对齐、碰撞检测 |
| arping | 测试Layer2连通性 | MAC层是否正常应答 |
我举个例子你就明白了。有一次板子给客户后，对方说网络不通。我没办法直接飞线接调试器，就让对方发了一个wireshark抓包回来。看到大量CRC错误——这基本锁定是PHY信号质量问题。后来检查发现是变压器抽头没接好。
ethtool调试示例：
# 查看eth0的PHY状态
ethtool eth0
# 输出示例：
# Speed: 1000Mb/s
# Duplex: Full
# Auto-negotiation: on
# Link detected: yes
# 强制协商，排查自动协商问题
ethtool -s eth0 speed 100 duplex full autoneg off
技巧：如果ethtool显示Link detected为yes，但ping不通。大概率是MAC层的驱动有bug，而不是PHY的问题。这时候你应该去看驱动代码，而不是继续纠缠PHY硬件。
工具选择思路总结
讲完了四种工具，我画了一张图帮你梳理它们各自的适用场景。这张图是我在实际项目中反复调整过的，希望对你有参考价值。
我带过不少新人，他们一开始总是纠结"哪种工具最好用"。其实不是的，关键是看你的调试阶段和能接触到的接口。比如，刚拿到板子时我习惯先用ethtool扫一遍，看看链路状态是否正常。如果发现异常，再拿出mdio或I2C工具，直接读PHY的内部状态寄存器。
我建议初学者先折腾mdio调通，再上手I2C，最后熟悉PCIe配置空间。Ethernet tools作为辅助手段，任何时候都值得掌握。你想想看，一个没有PHY调试经验的工程师，光靠这几类工具的组合，也能解决90%以上跟硬件相关的网络问题。
重要提醒：无论用哪种工具，务必先读懂PHY芯片手册中的寄存器和工具章节。我见过太多人对着工具手册猛翻，却忽略了芯片厂商给出的调试建议。那才是最直接的指导。