电话打过来，第一句话通常是："你们的芯片 link 不上。" 经验告诉我，十次里有八次不是芯片的问题——而是 PHY 压根没被正确地带起来。下面是我反复走过的一条排查路径，按顺序来，能省掉大量无效沟通。
先记住一条：链路建立的前提是两边都活着并且愿意说话。任何一方没上电、没复位完、没时钟，后面的寄存器读得再漂亮也没用。
第一步：确认供电与时序
别急着抓波形看 MDI。先拿万用表确认 PHY 的各路电源：AVDD / DVDD / IOVDD 是否都到位，纹波是否在规格内。特别注意上电时序——某些 PHY 要求核电压先于 IO 电压建立，顺序反了会直接锁死。
- 核压常见 1.0V / 1.1V，IO 常见 3.3V / 2.5V / 1.8V
- 逐路量，别只量一路就下结论
- 带载与空载都量一遍，空载正常不代表带载正常
第二步：复位信号有没有真正释放
复位脚被 SoC 的 GPIO 拉住不放，是最常见的"低级错误"。用示波器看 reset 引脚：上电后应保持低电平至少规格书要求的时间，然后干净地拉高，不能有过冲或回勾。
# 在 Linux 侧快速确认 reset GPIO 状态
cat /sys/kernel/debug/gpio | grep -i reset
# 预期看到: phy-reset gpio-xx (out hi)第三步：时钟在不在
25MHz 晶振（或来自 SoC 的参考时钟）是 PHY 的心跳。停振、频偏过大、幅度不足，都会让 PHY 静默。用示波器量 XTALI/XTALO 两端，确认：频率准确、幅度达标、起振时间正常。
第四步：MDIO 通不通
MAC 与 PHY 之间的管理通道。读不到 PHY ID，说明前面几步还有问题；偶尔读错，多半是 MDIO 上拉电阻缺失或总线被别的器件抢占。
# 读 PHY ID 寄存器 (MII_PHYSID1 = 0x02, ID2 = 0x03)
phytool read eth0/0/2
phytool read eth0/0/3如果读出来是 0x0000 或 0xFFFF，基本可以判定硬件链路有问题，别在软件配置上浪费时间。
第五步：读 BMSR 看自协商结果
寄存器 0x01（BMSR）的 bit5 是 Auto-Negotiation Complete，bit2 是 Link Status。这是判断链路状态最直接的窗口。
| BMSR 位 | 名称 | 判读 |
|---|---|---|
| bit5 | Auto-Negotiation Complete | 为 1 表示协商已完成 |
| bit2 | Link Status | 为 1 表示物理链路已建立 |
bit5 = 1：自协商已完成 → 去查对端能力是否匹配bit5 = 0且bit2 = 0：链路根本没建立 → 回到硬件侧bit5 = 0且bit2 = 1：可能是被强制成了固定速率
第六步：MDI 走线与变压器
差分对的阻抗控制、等长、参考平面连续性，任何一项失控都会让链路质量断崖式下跌。重点看：
- TX± / RX± 是否 100Ω 差分阻抗，是否跨分割
- 变压器中心抽头的 bias 电阻与退耦电容是否按参考设计
- RJ45 外壳地与 PCB 地的连接方案（这直接关系 EMC）
第七步：软件侧的强制与复位
最后才是软件。确认驱动里没有把自协商关掉、没有强制成错误速率、没有在 probe 阶段错误地软复位 PHY。
# 查看当前协商结果
ethtool eth0
# 重新触发一次自协商
ethtool -r eth0写在最后
七步走完还是不行？那才该怀疑芯片本体——比如 ESD 打伤了某一对差分引脚。这时候做一个对照实验：换一颗料、换一块板、换一根线，把变量一个一个锁死。
排查的精髓不是"我会多少高招"，而是把变量一个一个关掉。顺序感，比招式重要。
