3. 寄存器地址结构：IEEE 802.3 定义的基本寄存器集（0-31）与扩展寄存器集

你翻开 PHY 数据手册，第一眼看到的往往是一张寄存器地址表。0x00 到 0x1F 是 IEEE 802.3 强制规定的基础寄存器，0x20 以上属于扩展空间。当年我第一次调试千兆 PHY 时，对着手册愣了很久——为什么有些寄存器地址是 16 位的？后来踩了坑才明白，这里头藏着不少门道。

说白了，寄存器地址结构决定了你怎么跟 PHY 沟通。如果你只用过基本集，那只能算刚入门。今天我们就把这两层地址结构掰开揉碎地讲清楚。

3.1 基本寄存器集（0x00 – 0x1F）

IEEE 802.3 第 22 条款定义了 MII（媒体独立接口）管理协议。它规定：每个 PHY 设备必须实现 32 个基本寄存器，地址从 0 到 31。我习惯叫它“法定寄存器”——不管你是哪家厂商的 PHY，前 32 个寄存器必须按标准做事。

寄存器地址（十进制） 寄存器名称 功能简述
0 MII BMCR 基本控制寄存器（复位、环回、速度选择、自动协商使能等）
1 MII BMSR 基本状态寄存器（链接状态、自动协商完成、扩展能力等）
2 PHY ID 高 16 位 OUI（组织唯一标识符）的前 16 位
3 PHY ID 低 16 位 OUI 后 8 位 + 厂商型号 6 位 + 版本号 2 位
4 ANAR 自动协商通告能力（速度和双工模式）
5 ANLPAR 链路伙伴通告能力
6 ANER 自动协商扩展状态
7 … 15 保留（Next Page 相关） 自动协商下一页功能（千兆时常用）
16 … 31 扩展状态 / 厂商特定 IEEE 预留或厂商自定义（如千兆扩展控制）
实用小技巧： 我调试时第一步永远先读寄存器 2 和 3。你能从 PHY ID 看出具体芯片型号——比如 RTL8211 和 KSZ9031 的 ID 完全不同。如果读出来全是 0 或 0xFFFF，基本可以断定 MDIO 时序有问题。

3.2 为什么需要扩展寄存器集？

基本寄存器只有 32 个，对付 10/100M 以太网还行。可到了千兆、万兆甚至更高速率，那点寄存器完全不够用。你想想看：千兆 PHY 需要管理 EEE（节能以太网）、交叉检测、信号质量监控……32 个地址塞都塞不下。

IEEE 802.3 委员会早就想到了这个问题。他们在 802.3ae（万兆以太网）中引入了 MMD（Management Device） 模型，把寄存器地址扩展到 0x0000 ~ 0xFFFF。注意，这里说的是双字节地址——设备地址 + 寄存器地址。MII 管理帧从原来的 5 位地址变成了 设备地址 5 位 + 寄存器地址 5 位 的旧模式，再到 设备地址 5 位 + 寄存器地址 16 位 的新模式（Clause 45）。

我遇到过一位同事，在调试 10G PHY 时死活找不到某个配置寄存器。后来我一看，他还在用老式的 Clause 22 帧格式去写地址 0x100。嗯，这里要注意：Clause 45 的帧格式完全不同，MDIO 控制器的驱动层必须支持切换协议。

避坑指南： 我曾经被一个 PHY 坑过——它的厂商私有寄存器（比如温度传感器、信号质量指示）放在了基本寄存器空间的 16-31 地址里，但同时也在扩展空间有副本。两边读出来的值不一致，导致我的自动协商一直失败。最后查了勘误表才知道，必须用扩展地址访问才有效。所以写驱动前，一定要先确认厂商的寄存器映射是遵循 Clause 22 还是 Clause 45。

3.3 扩展寄存器集地址结构

Clause 45 定义了一种分层的地址结构：

  • MMD 设备地址（DEVAD）：5 位，范围 0–31，用于选择 PHY 内部的某个功能模块（如 PMA、PCS、WIS 等）。
  • 寄存器地址（REGADDR）：16 位，范围 0x0000–0xFFFF，由每个 MMD 自行定义。
  • 物理上，一条 MDIO 帧结构变成了：前导码 + 帧类型 + DEVAD + REGADDR + 数据。

下面这张图展示了基本寄存器集和扩展寄存器集的关系，以及 MMD 设备的分组方式。

寄存器地址结构：基本集与扩展集 基本寄存器集（Clause 22） 地址：0x00 – 0x1F（32个） BMCR, BMSR, PHY ID, ANAR… MDIO 帧格式：5位寄存器地址 适合 10/100M，千兆部分功能 扩展寄存器集（Clause 45） 地址：DEVAD(5位) + REGADDR(16位) MMD 设备地址示例： DEV 1 = PMA（物理介质连接） DEV 3 = PCS（物理编码子层） DEV 7 = Auto-Negotiation DEV 31 = 厂商私有 升级 基本集使用 5 位寄存器地址（≤ 31），扩展集使用 5 位设备地址 + 16 位寄存器地址（≤ 65535）。 两者在 MDIO 帧格式上完全不同，驱动层必须区分 Clause 22 和 Clause 45 协议。 PMA/PMD 物理介质连接 DEVAD = 1 PCS 物理编码子层 DEVAD = 3 Auto-Neg 自动协商 DEVAD = 7 Vendor 厂商私有 DEVAD = 31

3.4 如何在驱动中区分两种地址模式

实际项目里，大部分 PHY 都支持 Clause 22 和 Clause 45 双模。驱动初始化时，你通常要通过读 PHY ID 或一个特定寄存器来判断。我自己的做法是：先尝试用 Clause 22 读寄存器 2，如果返回值合理，就默认走 Cl22 模式。但如果 PHY 支持 10G 或更高，其数据手册往往明确写了必须走 Cl45。

下面是一段伪代码示意，让你感受下寄存器地址的处理差异。

// Clause 22: 直接写 5 位寄存器地址
mdio_write(phy_addr, 0x00, 0x8000); // BMCR 复位

// Clause 45: 需要构造设备地址+寄存器地址
// 假设 PMA/PMD 设备地址为 1，寄存器 0x1000
mdio45_write(phy_addr, 1, 0x1000, 0x0001);

你可能会问：MAC 侧怎么区分这两种帧？嗯，驱动层要设置 MDIO 控制器的一个控制位。比如在 Linux 的 phylib 中，你需要给 phy_device->mdio.dev->bus 设置一个标志位，或者在读写函数中传入不同的协议类型。如果搞混了，PHY 要么不响应，要么返回全 0。

经验之谈： 我调试过一个案子，PHY 的扩展寄存器在 Cl45 下能正常读写温度，但用 Cl22 去写地址 0x10 时竟然也成功了——但那其实不是真正的温度寄存器，而是厂商故意映射的一个只读副本。后来我通过对比两边的数据差异才发现问题。所以一定要记住：扩展寄存器只能通过 Clause 45 协议访问，除非手册明确说可以用 Cl22 的方式。

3.5 常见扩展寄存器功能概述

不同 MMD 设备定义了自己的寄存器空间。举几个高频使用的：

  • PMA/PMD（DEVAD=1）：链路状态、信号丢失、时钟恢复状态、信号质量指示。
  • PCS（DEVAD=3）：编码错误计数、同步状态、回环控制。
  • Auto-Negotiation（DEVAD=7）：Base Page、Next Page、自动协商状态机细节。
  • EEE（DEVAD=13 或 14）：节能以太网唤醒时间、低功耗空闲控制。

如果你的 PHY 支持 2.5G/5G（NBASE-T），那还得关注在 PCS 扩展空间中的速率相关寄存器。千万不要想当然地认为所有千兆以上的 PHY 寄存器结构都一模一样。

特别注意： 有些 PHY 厂商会在基本寄存器集的 16-31 地址中映射一部分扩展寄存器的内容。这是为了兼容老驱动，但数据可能不同步。我遇到过因为读的是“旧版”副本而导致配置没生效的 bug。最后我强制只走 Clause 45 读写才解决。所以调试时，建议尽量用 Clause 45 去访问所有扩展寄存器，除非你明确知道需要兼容什么设备。

3.6 小结几个判断标准

你拿到一个新 PHY，如何快速定位它的寄存器地址结构？我一般按下面几步：

  1. 看手册第一页——如果它提到“Clause 22”“Clause 45”“MMD”“DEVAD”这些词，大概率支持扩展集。
  2. 读寄存器 2 和 3——基本集必须能读出有效的 PHY ID。如果读出来是 0xFFFF，那可能是 Cl45 设备。
  3. 检查 MDIO 控制器的能力——有些老 MCU 只支持 Cl22 帧，那你就只能用到基本集。
  4. 尝试用 Cl45 写一个已知的扩展寄存器（比如 1.0x1000 读链接状态），看返回值是否符合预期。
← 上一章 📖 返回目录 下一章 →