接到一个实际项目要在嵌入式Linux平台上驱动RTL8306MB这颗交换芯片。芯片本身不复杂一颗5口百兆交换内部集成了5个PHY通过RMII接口和主控SoC对接。但就是这个RMII接口让我在调试中踩了好几个坑前前后后折腾了大半个月。网上关于这颗芯片的资料不算少但大多停留在datasheet层面真正把RMII调试中那些隐含条件讲透的并不多。这篇就把我这次驱动的完整过程、关键寄存器配置、以及那些容易让人卡住的调试陷阱一次性说清楚。先交代一下背景方便你对号入座。我用的主控是全志T507内核版本Linux 4.9RTL8306MB工作在RMII模式作为系统唯一的有线网口扩展方案。RTL8306MB的优势很明显成本低、功耗低、内置5个10/100M PHY外围只要加网络变压器和RJ45座子就能跑起来特别适合智能网关、工业控制板、边缘计算盒子这类需要多路百兆口但带宽要求不高的场景。如果你做的项目也是这种需求那这篇文章的调试思路和坑点清单可以直接复用。1. RTL8306MB的整体架构与RMII接口的关键角色1.1 芯片内部结构先搞清楚不然驱动无从下手RTL8306MB的内部结构其实是一个“交换核心”“5个内置PHY”的组合体。从主控SoC的角度看它并不是一个普通的PHY芯片而是一个完整的二层交换设备。这意味着SoC只通过一个RMII接口连接RTL8306MB的CPU端口通常是Port 0即P0其他4个端口P1-P4是完全独立的下行LAN口。这里有个非常容易混淆的点很多人第一次拿到这颗芯片会按照“SoC-PHY”的思路去配置也就是在设备树里把RTL8306MB当成一颗单PHY挂在MDIO总线上。这个思路不完全错但只对了一半。RTL8306MB确实有自己的MDIO接口但它既是MDIO从设备也可以通过MDIO接口暴露出内部的PHY寄存器组同时还能通过特殊的page切换机制配置交换核心的寄存器。所以驱动开发的第一步是明确你的目标如果只是想让SoC的MAC通过RMII收发数据那核心在于PHY驱动匹配和RMII时钟配置如果要管理VLAN、端口镜像、速率限制这些交换功能那就必须通过MDIO操作访问扩展寄存器。我在项目里首先实现的是“打通链路”也就是让SoC的eth0能通过RMII接口和RTL8306MB的P0口通信然后P1-P4任意一个口插上网线能和PC互通。这个目标看似简单但对RMII接口的每一个信号都得抠细节。1.2 RMII接口的每个信号线都不能马虎RMIIReduced Media Independent Interface是IEEE 802.3u标准里定义的一种简化MII接口它把原来MII需要的16根信号线缩减到了7根左右代价是时钟频率翻倍到50MHz并且收发数据各占2位。这7根线分别是REF_CLK50MHz参考时钟这是整个RMII接口的灵魂TXD[1:0]2位发送数据RXD[1:0]2位接收数据TX_EN发送使能CRS_DV载波侦听/数据有效MDIO/MDC管理接口用于PHY寄存器读写其中CRS_DV在百兆模式下实际上合并了CRS和RX_DV的功能在接收数据期间保持高电平。很多调试问题就出在这根线上因为有些主控的RMII控制器对CRS_DV的时序要求比较严格差一点点就导致收包断断续续甚至完全收不到。还有一个重要问题RMII的REF_CLK到底由谁来提供。标准RMII有两种模式一种是由外部晶振或时钟芯片生成50MHz同时送给MAC和PHY称为REF_CLK输入模式另一种是PHY自己生成50MHz时钟并输出给MAC称为REF_CLK输出模式。RTL8306MB的P0口既可以作为RMII的PHY端也可以配置成RMII的MAC端每个端口的50MHz时钟方向可以在寄存器里配置。这个时钟方向的选择是你在驱动开发中遇到的第一个大坑后面第3节专门展开讲。1.3 这颗芯片的驱动模型不是标准PHY驱动那么简单RTL8306MB驱动开发的另一个难点在于Linux内核自带的PHY驱动框架phy_device/phy_driver是按照“一颗PHY对应一个phy_device”设计的而RTL8306MB内部有5颗PHY它们共享一个MDIO地址空间通常占用地址0-4外加一个交换核心的寄存器空间需要通过page切换来访问。所以在设备树里你需要把这颗芯片的MDIO设备节点注册成“一个MDIO设备包含多个PHY地址”的结构或者干脆用platform_driver的方式手动分配phy_device并注册。我在项目中选择了后者把RTL8306MB当作一个platform设备在probe函数里手动mdiobus_register、然后逐个phy_device_create。这样虽然代码量稍大但对后续扩展交换核心功能VLAN、端口控制更友好调试排查也方便。2. 设备树配置与PHY驱动匹配的细节2.1 设备树节点怎么写才能被内核正确识别如果你的主控SoC自带MAC控制器比如全志的GMac那设备树里通常已经定义了gmac节点你只需要正确描述PHY的连接关系。但RTL8306MB不走常规路因为它是多PHY设备直接用phy-handle指向一个地址会丢失其他端口的信息。我采用的设备树方案是在soc的mdio节点下定义一个rtl8306mb节点作为MDIO的子设备然后通过reg属性声明它占用的MDIO地址范围。这里有个经验RTL8306MB芯片上电后内部的5颗PHY默认占用MDIO地址0-4交换核心的管理地址需要通过特殊序列切换不要在地址5上浪费时间因为只有在特定page模式下才能访问。mdio { rtl8306mb: rtl8306mb0 { compatible realtek,rtl8306mb; reg 0; reset-gpios pio 4 11 GPIO_ACTIVE_LOW; interrupt-parent pio; interrupts 4 12 IRQ_TYPE_LEVEL_LOW; ref_clock_mode output; /* 或 input取决于硬件设计 */ }; };注意reset-gpios和ref_clock_mode这两个属性。reset引脚必须在你确认硬件上确实连接到SoC的GPIO时才添加否则驱动里请求GPIO失败会导致probe直接退出。ref_clock_mode是自定义属性用来说明当前板子上的REF_CLK方向驱动里会根据这个值决定要不要配置RTL8306MB内部的时钟方向寄存器。2.2 PHY驱动的匹配与probe流程RTL8306MB对应的PHY驱动在Linux 4.9里并没有现成的需要自己写一个phy_driver结构体或者通过genphy驱动来兼容。如果你只是想快速验证链路可以先不写专用驱动直接用内核自带的Generic PHY Drivergenphy。但genphy驱动有个问题它不知道RTL8306MB内部PHY的特殊寄存器布局可能会读错PHY ID导致无法正确识别速率和双工模式。所以我的建议是别偷懒自己写一个RTL8306MB的PHY驱动至少在config_aneg和read_status这两个回调里做对事情。下面这段代码是我实际使用的驱动框架你可以参考static struct phy_driver rtl8306mb_phy_driver[] { { .phy_id 0x001cc830, .phy_id_mask 0xffffffff, .name RTL8306MB, .config_init rtl8306mb_config_init, .config_aneg genphy_config_aneg, .read_status rtl8306mb_read_status, .suspend genphy_suspend, .resume genphy_resume, }, }; module_phy_driver(rtl8306mb_phy_driver);这里有个坑RTL8306MB的PHY ID虽然datasheet里写了但不同批次芯片可能存在ID不一致的情况。我在调试时遇到过PHY ID读出来全是0xffffffff的情况不是芯片坏了而是MDIO时序时序有问题或者PHY在复位中。所以建议调试初期先用mdio工具手动读取PHY ID寄存器地址2和3确认能正确读到数值再做驱动匹配。2.3 MAC侧的RMII配置同样关键设备树里MAC节点的配置也会影响RMII调试结果。以全志T507的gmac为例你需要在设备树里明确指定MAC工作在RMII模式并确保MAC层的TX和RX delay配置正确。gmac { pinctrl-names default; pinctrl-0 gmac_rgmii_pins; phy-mode rmii; phy-handle rtl8306mb; status okay; };注意phy-mode这里是“rmii”而不是“rgmii”。很多人会把这里写错导致MAC按RGMII的125MHz时钟去采样而RMII只有50MHz结果就是数据全乱。另外如果你的SoC支持tx-internal-delay和rx-internal-delay这两个参数建议在RMII模式下先全部设为0也就是不添加内部延迟等基本通信正常了再根据眼图测试结果决定是否调整。RMII模式下50MHz时钟的建立保持时间本来就很紧张贸然加delay反而容易导致采样点偏移。3. 时钟决策REF_CLK方向是调试中的最大陷阱3.1 两种REF_CLK模式到底有什么区别RMII接口需要一个50MHz的参考时钟。这个时钟可以由外部晶振产生也可以由PHY内部PLL产生。对RTL8306MB来说它有两种工作方式第一种是“PHY提供时钟”模式。RTL8306MB内部通过晶振25MHz倍频出50MHz然后通过REF_CLK引脚输出给SoC的MAC。此时RTL8306MB的REF_CLK引脚方向是输出SoC的RMII REF_CLK引脚方向是输入。第二种是“MAC提供时钟”模式。SoC输出50MHz时钟给RTL8306MB的REF_CLK引脚此时RTL8306MB内部不使用自己的PLL而是直接使用外部输入的时钟作为RMII参考时钟。这两种模式在寄存器配置上完全不同。RTL8306MB的端口0CPU端口有一个专门的寄存器位来控制REF_CLK的方向比如通过page 0的0x1A寄存器bit 12。如果配置反了信号就会冲突两个设备都在驱动REF_CLK引脚轻则时钟抖动重则烧毁引脚。3.2 我的调试过程从完全不通到找到时钟方向我最初拿到的开发板原理图上REF_CLK是直接从RTL8306MB的P0口连到SoC的RMII REF_CLK引脚中间没有外部时钟源。按道理这是典型的“PHY提供时钟”模式。但在驱动初始化时我没有显式配置RTL8306MB的时钟方向寄存器而是直接使用了芯片的默认配置。结果就是SoC的MAC始终无法收到RTL8306MB发出的数据包。用示波器测量REF_CLK引脚发现竟然没有波形这说明RTL8306MB的REF_CLK引脚被配置成了输入模式它在等SoC给它时钟而SoC的MAC也在等PHY给时钟两边都在等就僵住了。解决方案是在驱动初始化时通过MDIO访问RTL8306MB的page 0寄存器把P0端口的REF_CLK方向显式配置为输出。原语差不多是这个样子/* 选择page 0 */ phy_write(mdio_bus, 0, 0x1F, 0x0000); /* 读P0控制寄存器 */ val phy_read(mdio_bus, 0, 0x1A); /* 设置bit12为1使P0 REF_CLK方向为输出 */ val | (1 12); phy_write(mdio_bus, 0, 0x1A, val);写完之后再次示波器测量REF_CLK引脚上有稳定的50MHz方波了但链路依然不通。继续排查又发现RXD信号上始终没有数据。这时候我意识到可能不只是时钟方向PHY的速率/双工模式协商也有问题。3.3 时钟模式下速率协商的连带效应RTL8306MB的P0口在RMII模式下与SoC MAC通信时两端的工作模式必须一致同为100M全双工或者同为10M半双工。RMII标准并没有为10M速率定义单独的时钟而是在100M基础上通过TXD/RXD上的编码来区分。实测中发现如果RTL8306MB的P0口通过自动协商把自己配置成了10M半双工而SoC的MAC却固定工作在100M全双工那么RXD数据线上收到的信号完全无法解析。这里就需要在RTL8306MB的P0口配置里把“与MAC通信的CPU端口”固定为100M全双工不参与自动协商。RTL8306MB的CPU端口P0有一个独立的强制模式寄存器通过设置page 0的0x0C寄存器bit 4:3可以将其固定为100M全双工。操作流程/* 选择page 0 */ phy_write(mdio_bus, 0, 0x1F, 0x0000); /* 读P0端口控制寄存器 */ val phy_read(mdio_bus, 0, 0x0C); /* 清bit4:3然后设置为10 */ val ~(0x3 3); val | (0x2 3); phy_write(mdio_bus, 0, 0x0C, val);这一步做完之后链路终于通了。PC插在P1口能通过DHCP获取到IPSoC也能ping通PC。3.4 给REF_CLK模式的几点忠告你在自己的板子上调试时一定要先看原理图确认REF_CLK引脚上是否有时钟源、时钟源的方向是SoC到交换芯片还是交换芯片到SoC。不要想当然地认为RTL8306MB默认就是输出时钟因为芯片内部有一个strapping引脚可以改变默认方向。另外一个细节如果你打算用SoC的RMII REF_CLK输出作为时钟源那么必须确保SoC的MAC控制器在RMII模式下能正确输出50MHz时钟。有些SoC的RMII时钟输出不是默认开启的需要在驱动里通过系统控制寄存器或者时钟树配置打开。这种情况下排查链路的第一步就是测量REF_CLK引脚如果这里没有波形后面的一切都无从谈起。4. 调试工具与故障排查路线的实战盘点4.1 MDIO命令行工具是最基本的排查武器在Linux下如果MDIO总线已经注册你可以使用mii-tool和ethtool直接对PHY寄存器进行读写。但这两个工具能读到的寄存器有限对于RTL8306MB这种需要page切换的芯片更推荐直接写一个小工具通过SIOCGMIIREG/SIOCSMIIREG ioctl来操作或者干脆在驱动里加debugfs接口。我在调试时写了一个简单的shell脚本通过mdio-tools如果内核配置了mdio-mux的debugfs来批量读取PHY寄存器。一个关键点在读RTL8306MB内部PHY寄存器之前一定要先确认MDIO地址和数据线上的时序正常。最简单的方法是用示波器抓MDC的波形看是否有稳定的2.5MHz或SoC配置的其他频率时钟。4.2 网络连通性测试的几个层次当RMII接口的PHY驱动已经注册成功ifconfig可以看到eth0并有IP地址后还需要做几个层次的测试确保链路真正稳定第一层本地回环测试。在SoC上ping自己的IP地址确认MAC层的发送接收路径基本正常。第二层跨板通信测试。在PC端用iperf3打流或者简单用连续ping大包比如ping -s 1400 目标IP来测试。注意一定要测试双向流量因为RMII的收发是独立的两对信号线可能出现“能发不能收”或者“能收不能发”的故障。第三层长时间稳定性测试。我遇到过RMII接口在持续打流半小时后出现丢包率上升的情况查了半天发现是REF_CLK信号质量不好过冲严重导致采样点不稳定。解决办法是在PHY/MAC配置里增加时钟边沿采样偏移或者在硬件上调整时钟走线的串联电阻。4.3 寄存器dump是定位交换芯片问题的必要条件RTL8306MB的调试核心工具是寄存器dump。通过MDIO读取各个PHY的BMCR地址0、BMSR地址1、PHYID地址2/3、ANAR地址4、ANLPAR地址5寄存器就能判断链路协商状态。我在一次排查“插上网线但PHY link up不了”的问题时读取BMSR发现bit2link status始终为0但用网线测试仪检测网线是好的。后来检查P1端口的中断状态寄存器发现是端口的一个极性配置位错了导致PHY检测不到有效信号。这类问题如果不做寄存器dump单纯看内核日志根本定位不了。RTL8306MB的端口状态也有专门的寄存器比如page 0的0x00到0x04对应P1-P4的PHY状态。通过这些寄存器可以快速判断是外部网线/变压器问题还是芯片内部交换核心的问题。4.4 用抓包工具确认交换行为当链路已通但数据包转发行为不符预期时比如P1口收到的包只能在P1口看到不能转发到P0口需要用tcpdump在SoC侧确认有没有收到来自交换芯片的帧同时在PC侧用Wireshark抓包确认PC发的包是否到达了RTL8306MB的P1口。这个阶段的调试重点已经不在RMII接口而在RTL8306MB的交换核心配置。比如VLAN是否默认把所有端口加入同一个广播域地址学习表是否工作正常等。记住RTL8306MB作为交换芯片内置了完整的二层交换引擎SoC只是它的一个上行端口默认情况下P1-P4之间是可以直接二层转发的不需要经过SoC。5. 七个最容易踩的坑避坑清单与排查速查表5.1 坑1错误理解PHY ID和MDIO设备树节点我在调试初期曾尝试用PHY ID 0x001cc830去匹配驱动结果怎么都匹配不上。后来才发现RTL8306MB的PHY ID在MDIO地址0-4上都是同一颗PHY的ID但需要读取地址0的PHY ID才能拿到真实值其他地址返回的可能被芯片内部的映射机制改写了。这里分享一个排查经验先用mii-tool --phy-addr查看每个地址的PHY ID确认芯片在哪个MDIO地址上响应。如果所有地址都不响应检查MDC/MDIO引脚是否正确连接以及PHY的供电和复位是否正常。5.2 坑2复位引脚时序不满足导致芯片不工作RTL8306MB的复位引脚要求低电平保持至少10ms释放后还需要等待内部PLL稳定大概再等5ms才能开始MDIO访问。有些板子在SoC上电后立刻就要配置RTL8306MB导致MDIO访问失败。我当时在设备树里通过gpio-request和gpio-direction-output来管理复位引脚但在probe流程里驱动注册和MDIO初始化是异步并行执行的结果出现复位还没释放MDIO控制器就开始访问芯片的情况。解决办法是在RTL8306MB的probe函数里先拉低复位引脚然后msleep(20)再拉高再msleep(10)之后才进行MDIO读写。5.3 坑3RMII引脚复用冲突全志T507这类SoC的引脚复用比较复杂RMII的TXD/RXD/CLK等引脚可能和SDIO、UART或PWM功能冲突。我在调试时发现TXD0引脚上始终有异常电平查了芯片手册才知道这个引脚默认复用成GPIO功能需要在pinctrl设备树节点里显式配置为RMII功能。检查方法完全断开RTL8306MB让SoC的RMII引脚悬空用示波器看这些引脚上是否有预期的默认状态。如果悬空时引脚状态都不对那就是SoC侧引脚复用配置的问题和交换芯片无关。5.4 坑4MDIO的上拉电阻和电平不匹配RTL8306MB的MDIO引脚是开漏输出需要外部上拉电阻。很多参考设计上拉电阻选的是1kΩ但在长走线的板子上1kΩ下拉能力可能不够导致MDIO信号边沿变缓。我在一次调试中MDIO读取偶尔成功偶尔失败最终定位到是PCB走线过长加上上拉电阻过小导致信号反射。解决办法是把上拉电阻从1kΩ改到4.7kΩ同时在PHY侧并联一个小电容比如22pF滤除高频噪声。这个现象用示波器看最直观正常MDIO信号应该是干净的方波上冲下冲严重时就是阻抗不匹配。5.5 坑5网口变压器的中心抽头接法错误这个问题其实不算是RTL8306MB驱动的问题但它会导致PHY link状态异常极易误判为驱动bug。RTL8306MB的PHY端口要求以太网变压器的中心抽头通过RC电路连接到一个合适电压通常为2.5V或3.3V。有些开发板为了省元件把中心抽头直接接地了结果PHY无法正确检测线路信号。排查方法看原理图确认变压器的中心抽头是否按照datasheet参考电路连接。如果硬件不支持修改可以考虑在驱动中调整PHY的TX amplitude寄存器和RX threshold寄存器来补偿但这治标不治本。5.6 坑6VLAN配置干扰基本通信RTL8306MB的交换核心支持802.1Q VLAN如果寄存器初始化时把端口加进了不同的VLAN即使RMII链路和PHY都是正常的数据包也无法跨VLAN转发。我在调试时曾遇到P1口能link up但P0口收不到P1口的广播包查了半天最后发现是芯片默认的VLAN配置把P1踢出了默认VLAN 1。这个问题的排查方法是读取端口VLAN成员寄存器确认所有端口都在同一个VLAN中。5.7 坑7SoC MAC的FIFO或DMA配置导致偶发丢包这个问题比较隐蔽。RMII链路完全正常PHY也协商成功但大流量下出现规律性丢包。用示波器看RMII接口的数据波形没有发现信号质量问题后来排查到是SoC的MAC DMA描述符没有正确配置导致接收FIFO溢出。如果你用的是标准Linux内核驱动这个坑出现的概率较小。但如果你的SoC的MAC驱动是芯片厂商深度定制的建议检查一下DMA burst size和FIFO threshold的配置。表格汇总一下这七个坑的快速排查方法坑编号现象快速排查方法处理策略坑1PHY ID匹配不上mii-tool扫描所有MDIO地址确认芯片实际响应地址并修改匹配坑2芯片不工作/寄存器读不了示波器测量复位引脚时序延长复位低电平时间和稳定时间坑3信号异常/无波形断开PHY检查SoC引脚状态修正pinctrl设备树配置坑4寄存器读写不稳定示波器测量MDIO/MDC波形调整上拉电阻和滤波电容坑5PHY link不up核对变压器中心抽头接法修改硬件或软件补偿坑6收发不通/广播不转发dump VLAN成员寄存器统一VLAN成员配置坑7大流量丢包检查DMA FIFO配置调整DMA参数6. 从驱动打通到稳定运行的进阶建议当你把RMII接口调通SoC和RTL8306MB之间能正常通信之后千万别急着收工。还有几个事情值得做能帮你后面的项目省下大量时间。第一把RTL8306MB的完整寄存器配置固化到驱动里做成一个rtl8306mb_hw_init()函数每次probe时按照固定顺序执行。RTL8306MB是纯寄存器配置型芯片没有固件可加载所有设置都在寄存器里掉电就丢。如果你不固化初始化流程每次上电后芯片可能处于完全不同的状态排查起来极为痛苦。第二把MDIO调试接口导出到用户空间。建议在驱动里实现一个简单的debugfs节点允许读写任意寄存器。这样后续调VLAN、端口配置时不需要反复编译内核直接echo命令就行。调试效率和体验完全不一样。第三确认SoC的MAC驱动对链路状态变化的处理。RTL8306MB的P0口如果被配置成强制100M全双工那么它的link状态实际上取决于其他下行端口有没有设备接入。有些SoC MAC驱动在检测到link down后会关闭DMA导致P0口无法发包。这种场景下可能需要通过软件方式让MAC始终认为link up或者用RTL8306MB的中断引脚来上报链路状态变化。第四注意散热和长期稳定性。RTL8306MB虽然功耗不高但在多口同时满速转发时芯片温度还是比较明显的。如果你的产品是密闭外壳建议在驱动里增加温度读取功能RTL8306MB内置温度传感器通过特殊寄存器读取并设置告警阈值。按照我个人的经验RTL8306MB这颗芯片在百兆多口场景下性价比确实很高但它的寄存器体系并不算友好page切换机制、各个端口控制位的排列、以及很多未公开的保留位都需要你在调试中反复试验。记住一个原则任何一次寄存器写入之前先把原始值读出来对照datasheet确认再写。很多“玄学”问题最后发现都是因为对某个保留位做了写入导致的。这次调试最大的体会就是RMII接口排错一定要有清晰的层次先是物理层的时钟、复位和引脚电平再是MDIO链路和PHY ID识别然后是MAC层的收发路径最后才是交换核心的转发行为。按照这个顺序排查思路会很清晰不会像无头苍蝇一样乱撞。希望这篇文章能帮你跳过那些我踩过的坑让你的RTL8306MB驱动开发之路顺畅一些。
嵌入式Linux下RTL8306MB交换芯片RMII接口驱动调试实战
接到一个实际项目要在嵌入式Linux平台上驱动RTL8306MB这颗交换芯片。芯片本身不复杂一颗5口百兆交换内部集成了5个PHY通过RMII接口和主控SoC对接。但就是这个RMII接口让我在调试中踩了好几个坑前前后后折腾了大半个月。网上关于这颗芯片的资料不算少但大多停留在datasheet层面真正把RMII调试中那些隐含条件讲透的并不多。这篇就把我这次驱动的完整过程、关键寄存器配置、以及那些容易让人卡住的调试陷阱一次性说清楚。先交代一下背景方便你对号入座。我用的主控是全志T507内核版本Linux 4.9RTL8306MB工作在RMII模式作为系统唯一的有线网口扩展方案。RTL8306MB的优势很明显成本低、功耗低、内置5个10/100M PHY外围只要加网络变压器和RJ45座子就能跑起来特别适合智能网关、工业控制板、边缘计算盒子这类需要多路百兆口但带宽要求不高的场景。如果你做的项目也是这种需求那这篇文章的调试思路和坑点清单可以直接复用。1. RTL8306MB的整体架构与RMII接口的关键角色1.1 芯片内部结构先搞清楚不然驱动无从下手RTL8306MB的内部结构其实是一个“交换核心”“5个内置PHY”的组合体。从主控SoC的角度看它并不是一个普通的PHY芯片而是一个完整的二层交换设备。这意味着SoC只通过一个RMII接口连接RTL8306MB的CPU端口通常是Port 0即P0其他4个端口P1-P4是完全独立的下行LAN口。这里有个非常容易混淆的点很多人第一次拿到这颗芯片会按照“SoC-PHY”的思路去配置也就是在设备树里把RTL8306MB当成一颗单PHY挂在MDIO总线上。这个思路不完全错但只对了一半。RTL8306MB确实有自己的MDIO接口但它既是MDIO从设备也可以通过MDIO接口暴露出内部的PHY寄存器组同时还能通过特殊的page切换机制配置交换核心的寄存器。所以驱动开发的第一步是明确你的目标如果只是想让SoC的MAC通过RMII收发数据那核心在于PHY驱动匹配和RMII时钟配置如果要管理VLAN、端口镜像、速率限制这些交换功能那就必须通过MDIO操作访问扩展寄存器。我在项目里首先实现的是“打通链路”也就是让SoC的eth0能通过RMII接口和RTL8306MB的P0口通信然后P1-P4任意一个口插上网线能和PC互通。这个目标看似简单但对RMII接口的每一个信号都得抠细节。1.2 RMII接口的每个信号线都不能马虎RMIIReduced Media Independent Interface是IEEE 802.3u标准里定义的一种简化MII接口它把原来MII需要的16根信号线缩减到了7根左右代价是时钟频率翻倍到50MHz并且收发数据各占2位。这7根线分别是REF_CLK50MHz参考时钟这是整个RMII接口的灵魂TXD[1:0]2位发送数据RXD[1:0]2位接收数据TX_EN发送使能CRS_DV载波侦听/数据有效MDIO/MDC管理接口用于PHY寄存器读写其中CRS_DV在百兆模式下实际上合并了CRS和RX_DV的功能在接收数据期间保持高电平。很多调试问题就出在这根线上因为有些主控的RMII控制器对CRS_DV的时序要求比较严格差一点点就导致收包断断续续甚至完全收不到。还有一个重要问题RMII的REF_CLK到底由谁来提供。标准RMII有两种模式一种是由外部晶振或时钟芯片生成50MHz同时送给MAC和PHY称为REF_CLK输入模式另一种是PHY自己生成50MHz时钟并输出给MAC称为REF_CLK输出模式。RTL8306MB的P0口既可以作为RMII的PHY端也可以配置成RMII的MAC端每个端口的50MHz时钟方向可以在寄存器里配置。这个时钟方向的选择是你在驱动开发中遇到的第一个大坑后面第3节专门展开讲。1.3 这颗芯片的驱动模型不是标准PHY驱动那么简单RTL8306MB驱动开发的另一个难点在于Linux内核自带的PHY驱动框架phy_device/phy_driver是按照“一颗PHY对应一个phy_device”设计的而RTL8306MB内部有5颗PHY它们共享一个MDIO地址空间通常占用地址0-4外加一个交换核心的寄存器空间需要通过page切换来访问。所以在设备树里你需要把这颗芯片的MDIO设备节点注册成“一个MDIO设备包含多个PHY地址”的结构或者干脆用platform_driver的方式手动分配phy_device并注册。我在项目中选择了后者把RTL8306MB当作一个platform设备在probe函数里手动mdiobus_register、然后逐个phy_device_create。这样虽然代码量稍大但对后续扩展交换核心功能VLAN、端口控制更友好调试排查也方便。2. 设备树配置与PHY驱动匹配的细节2.1 设备树节点怎么写才能被内核正确识别如果你的主控SoC自带MAC控制器比如全志的GMac那设备树里通常已经定义了gmac节点你只需要正确描述PHY的连接关系。但RTL8306MB不走常规路因为它是多PHY设备直接用phy-handle指向一个地址会丢失其他端口的信息。我采用的设备树方案是在soc的mdio节点下定义一个rtl8306mb节点作为MDIO的子设备然后通过reg属性声明它占用的MDIO地址范围。这里有个经验RTL8306MB芯片上电后内部的5颗PHY默认占用MDIO地址0-4交换核心的管理地址需要通过特殊序列切换不要在地址5上浪费时间因为只有在特定page模式下才能访问。mdio { rtl8306mb: rtl8306mb0 { compatible realtek,rtl8306mb; reg 0; reset-gpios pio 4 11 GPIO_ACTIVE_LOW; interrupt-parent pio; interrupts 4 12 IRQ_TYPE_LEVEL_LOW; ref_clock_mode output; /* 或 input取决于硬件设计 */ }; };注意reset-gpios和ref_clock_mode这两个属性。reset引脚必须在你确认硬件上确实连接到SoC的GPIO时才添加否则驱动里请求GPIO失败会导致probe直接退出。ref_clock_mode是自定义属性用来说明当前板子上的REF_CLK方向驱动里会根据这个值决定要不要配置RTL8306MB内部的时钟方向寄存器。2.2 PHY驱动的匹配与probe流程RTL8306MB对应的PHY驱动在Linux 4.9里并没有现成的需要自己写一个phy_driver结构体或者通过genphy驱动来兼容。如果你只是想快速验证链路可以先不写专用驱动直接用内核自带的Generic PHY Drivergenphy。但genphy驱动有个问题它不知道RTL8306MB内部PHY的特殊寄存器布局可能会读错PHY ID导致无法正确识别速率和双工模式。所以我的建议是别偷懒自己写一个RTL8306MB的PHY驱动至少在config_aneg和read_status这两个回调里做对事情。下面这段代码是我实际使用的驱动框架你可以参考static struct phy_driver rtl8306mb_phy_driver[] { { .phy_id 0x001cc830, .phy_id_mask 0xffffffff, .name RTL8306MB, .config_init rtl8306mb_config_init, .config_aneg genphy_config_aneg, .read_status rtl8306mb_read_status, .suspend genphy_suspend, .resume genphy_resume, }, }; module_phy_driver(rtl8306mb_phy_driver);这里有个坑RTL8306MB的PHY ID虽然datasheet里写了但不同批次芯片可能存在ID不一致的情况。我在调试时遇到过PHY ID读出来全是0xffffffff的情况不是芯片坏了而是MDIO时序时序有问题或者PHY在复位中。所以建议调试初期先用mdio工具手动读取PHY ID寄存器地址2和3确认能正确读到数值再做驱动匹配。2.3 MAC侧的RMII配置同样关键设备树里MAC节点的配置也会影响RMII调试结果。以全志T507的gmac为例你需要在设备树里明确指定MAC工作在RMII模式并确保MAC层的TX和RX delay配置正确。gmac { pinctrl-names default; pinctrl-0 gmac_rgmii_pins; phy-mode rmii; phy-handle rtl8306mb; status okay; };注意phy-mode这里是“rmii”而不是“rgmii”。很多人会把这里写错导致MAC按RGMII的125MHz时钟去采样而RMII只有50MHz结果就是数据全乱。另外如果你的SoC支持tx-internal-delay和rx-internal-delay这两个参数建议在RMII模式下先全部设为0也就是不添加内部延迟等基本通信正常了再根据眼图测试结果决定是否调整。RMII模式下50MHz时钟的建立保持时间本来就很紧张贸然加delay反而容易导致采样点偏移。3. 时钟决策REF_CLK方向是调试中的最大陷阱3.1 两种REF_CLK模式到底有什么区别RMII接口需要一个50MHz的参考时钟。这个时钟可以由外部晶振产生也可以由PHY内部PLL产生。对RTL8306MB来说它有两种工作方式第一种是“PHY提供时钟”模式。RTL8306MB内部通过晶振25MHz倍频出50MHz然后通过REF_CLK引脚输出给SoC的MAC。此时RTL8306MB的REF_CLK引脚方向是输出SoC的RMII REF_CLK引脚方向是输入。第二种是“MAC提供时钟”模式。SoC输出50MHz时钟给RTL8306MB的REF_CLK引脚此时RTL8306MB内部不使用自己的PLL而是直接使用外部输入的时钟作为RMII参考时钟。这两种模式在寄存器配置上完全不同。RTL8306MB的端口0CPU端口有一个专门的寄存器位来控制REF_CLK的方向比如通过page 0的0x1A寄存器bit 12。如果配置反了信号就会冲突两个设备都在驱动REF_CLK引脚轻则时钟抖动重则烧毁引脚。3.2 我的调试过程从完全不通到找到时钟方向我最初拿到的开发板原理图上REF_CLK是直接从RTL8306MB的P0口连到SoC的RMII REF_CLK引脚中间没有外部时钟源。按道理这是典型的“PHY提供时钟”模式。但在驱动初始化时我没有显式配置RTL8306MB的时钟方向寄存器而是直接使用了芯片的默认配置。结果就是SoC的MAC始终无法收到RTL8306MB发出的数据包。用示波器测量REF_CLK引脚发现竟然没有波形这说明RTL8306MB的REF_CLK引脚被配置成了输入模式它在等SoC给它时钟而SoC的MAC也在等PHY给时钟两边都在等就僵住了。解决方案是在驱动初始化时通过MDIO访问RTL8306MB的page 0寄存器把P0端口的REF_CLK方向显式配置为输出。原语差不多是这个样子/* 选择page 0 */ phy_write(mdio_bus, 0, 0x1F, 0x0000); /* 读P0控制寄存器 */ val phy_read(mdio_bus, 0, 0x1A); /* 设置bit12为1使P0 REF_CLK方向为输出 */ val | (1 12); phy_write(mdio_bus, 0, 0x1A, val);写完之后再次示波器测量REF_CLK引脚上有稳定的50MHz方波了但链路依然不通。继续排查又发现RXD信号上始终没有数据。这时候我意识到可能不只是时钟方向PHY的速率/双工模式协商也有问题。3.3 时钟模式下速率协商的连带效应RTL8306MB的P0口在RMII模式下与SoC MAC通信时两端的工作模式必须一致同为100M全双工或者同为10M半双工。RMII标准并没有为10M速率定义单独的时钟而是在100M基础上通过TXD/RXD上的编码来区分。实测中发现如果RTL8306MB的P0口通过自动协商把自己配置成了10M半双工而SoC的MAC却固定工作在100M全双工那么RXD数据线上收到的信号完全无法解析。这里就需要在RTL8306MB的P0口配置里把“与MAC通信的CPU端口”固定为100M全双工不参与自动协商。RTL8306MB的CPU端口P0有一个独立的强制模式寄存器通过设置page 0的0x0C寄存器bit 4:3可以将其固定为100M全双工。操作流程/* 选择page 0 */ phy_write(mdio_bus, 0, 0x1F, 0x0000); /* 读P0端口控制寄存器 */ val phy_read(mdio_bus, 0, 0x0C); /* 清bit4:3然后设置为10 */ val ~(0x3 3); val | (0x2 3); phy_write(mdio_bus, 0, 0x0C, val);这一步做完之后链路终于通了。PC插在P1口能通过DHCP获取到IPSoC也能ping通PC。3.4 给REF_CLK模式的几点忠告你在自己的板子上调试时一定要先看原理图确认REF_CLK引脚上是否有时钟源、时钟源的方向是SoC到交换芯片还是交换芯片到SoC。不要想当然地认为RTL8306MB默认就是输出时钟因为芯片内部有一个strapping引脚可以改变默认方向。另外一个细节如果你打算用SoC的RMII REF_CLK输出作为时钟源那么必须确保SoC的MAC控制器在RMII模式下能正确输出50MHz时钟。有些SoC的RMII时钟输出不是默认开启的需要在驱动里通过系统控制寄存器或者时钟树配置打开。这种情况下排查链路的第一步就是测量REF_CLK引脚如果这里没有波形后面的一切都无从谈起。4. 调试工具与故障排查路线的实战盘点4.1 MDIO命令行工具是最基本的排查武器在Linux下如果MDIO总线已经注册你可以使用mii-tool和ethtool直接对PHY寄存器进行读写。但这两个工具能读到的寄存器有限对于RTL8306MB这种需要page切换的芯片更推荐直接写一个小工具通过SIOCGMIIREG/SIOCSMIIREG ioctl来操作或者干脆在驱动里加debugfs接口。我在调试时写了一个简单的shell脚本通过mdio-tools如果内核配置了mdio-mux的debugfs来批量读取PHY寄存器。一个关键点在读RTL8306MB内部PHY寄存器之前一定要先确认MDIO地址和数据线上的时序正常。最简单的方法是用示波器抓MDC的波形看是否有稳定的2.5MHz或SoC配置的其他频率时钟。4.2 网络连通性测试的几个层次当RMII接口的PHY驱动已经注册成功ifconfig可以看到eth0并有IP地址后还需要做几个层次的测试确保链路真正稳定第一层本地回环测试。在SoC上ping自己的IP地址确认MAC层的发送接收路径基本正常。第二层跨板通信测试。在PC端用iperf3打流或者简单用连续ping大包比如ping -s 1400 目标IP来测试。注意一定要测试双向流量因为RMII的收发是独立的两对信号线可能出现“能发不能收”或者“能收不能发”的故障。第三层长时间稳定性测试。我遇到过RMII接口在持续打流半小时后出现丢包率上升的情况查了半天发现是REF_CLK信号质量不好过冲严重导致采样点不稳定。解决办法是在PHY/MAC配置里增加时钟边沿采样偏移或者在硬件上调整时钟走线的串联电阻。4.3 寄存器dump是定位交换芯片问题的必要条件RTL8306MB的调试核心工具是寄存器dump。通过MDIO读取各个PHY的BMCR地址0、BMSR地址1、PHYID地址2/3、ANAR地址4、ANLPAR地址5寄存器就能判断链路协商状态。我在一次排查“插上网线但PHY link up不了”的问题时读取BMSR发现bit2link status始终为0但用网线测试仪检测网线是好的。后来检查P1端口的中断状态寄存器发现是端口的一个极性配置位错了导致PHY检测不到有效信号。这类问题如果不做寄存器dump单纯看内核日志根本定位不了。RTL8306MB的端口状态也有专门的寄存器比如page 0的0x00到0x04对应P1-P4的PHY状态。通过这些寄存器可以快速判断是外部网线/变压器问题还是芯片内部交换核心的问题。4.4 用抓包工具确认交换行为当链路已通但数据包转发行为不符预期时比如P1口收到的包只能在P1口看到不能转发到P0口需要用tcpdump在SoC侧确认有没有收到来自交换芯片的帧同时在PC侧用Wireshark抓包确认PC发的包是否到达了RTL8306MB的P1口。这个阶段的调试重点已经不在RMII接口而在RTL8306MB的交换核心配置。比如VLAN是否默认把所有端口加入同一个广播域地址学习表是否工作正常等。记住RTL8306MB作为交换芯片内置了完整的二层交换引擎SoC只是它的一个上行端口默认情况下P1-P4之间是可以直接二层转发的不需要经过SoC。5. 七个最容易踩的坑避坑清单与排查速查表5.1 坑1错误理解PHY ID和MDIO设备树节点我在调试初期曾尝试用PHY ID 0x001cc830去匹配驱动结果怎么都匹配不上。后来才发现RTL8306MB的PHY ID在MDIO地址0-4上都是同一颗PHY的ID但需要读取地址0的PHY ID才能拿到真实值其他地址返回的可能被芯片内部的映射机制改写了。这里分享一个排查经验先用mii-tool --phy-addr查看每个地址的PHY ID确认芯片在哪个MDIO地址上响应。如果所有地址都不响应检查MDC/MDIO引脚是否正确连接以及PHY的供电和复位是否正常。5.2 坑2复位引脚时序不满足导致芯片不工作RTL8306MB的复位引脚要求低电平保持至少10ms释放后还需要等待内部PLL稳定大概再等5ms才能开始MDIO访问。有些板子在SoC上电后立刻就要配置RTL8306MB导致MDIO访问失败。我当时在设备树里通过gpio-request和gpio-direction-output来管理复位引脚但在probe流程里驱动注册和MDIO初始化是异步并行执行的结果出现复位还没释放MDIO控制器就开始访问芯片的情况。解决办法是在RTL8306MB的probe函数里先拉低复位引脚然后msleep(20)再拉高再msleep(10)之后才进行MDIO读写。5.3 坑3RMII引脚复用冲突全志T507这类SoC的引脚复用比较复杂RMII的TXD/RXD/CLK等引脚可能和SDIO、UART或PWM功能冲突。我在调试时发现TXD0引脚上始终有异常电平查了芯片手册才知道这个引脚默认复用成GPIO功能需要在pinctrl设备树节点里显式配置为RMII功能。检查方法完全断开RTL8306MB让SoC的RMII引脚悬空用示波器看这些引脚上是否有预期的默认状态。如果悬空时引脚状态都不对那就是SoC侧引脚复用配置的问题和交换芯片无关。5.4 坑4MDIO的上拉电阻和电平不匹配RTL8306MB的MDIO引脚是开漏输出需要外部上拉电阻。很多参考设计上拉电阻选的是1kΩ但在长走线的板子上1kΩ下拉能力可能不够导致MDIO信号边沿变缓。我在一次调试中MDIO读取偶尔成功偶尔失败最终定位到是PCB走线过长加上上拉电阻过小导致信号反射。解决办法是把上拉电阻从1kΩ改到4.7kΩ同时在PHY侧并联一个小电容比如22pF滤除高频噪声。这个现象用示波器看最直观正常MDIO信号应该是干净的方波上冲下冲严重时就是阻抗不匹配。5.5 坑5网口变压器的中心抽头接法错误这个问题其实不算是RTL8306MB驱动的问题但它会导致PHY link状态异常极易误判为驱动bug。RTL8306MB的PHY端口要求以太网变压器的中心抽头通过RC电路连接到一个合适电压通常为2.5V或3.3V。有些开发板为了省元件把中心抽头直接接地了结果PHY无法正确检测线路信号。排查方法看原理图确认变压器的中心抽头是否按照datasheet参考电路连接。如果硬件不支持修改可以考虑在驱动中调整PHY的TX amplitude寄存器和RX threshold寄存器来补偿但这治标不治本。5.6 坑6VLAN配置干扰基本通信RTL8306MB的交换核心支持802.1Q VLAN如果寄存器初始化时把端口加进了不同的VLAN即使RMII链路和PHY都是正常的数据包也无法跨VLAN转发。我在调试时曾遇到P1口能link up但P0口收不到P1口的广播包查了半天最后发现是芯片默认的VLAN配置把P1踢出了默认VLAN 1。这个问题的排查方法是读取端口VLAN成员寄存器确认所有端口都在同一个VLAN中。5.7 坑7SoC MAC的FIFO或DMA配置导致偶发丢包这个问题比较隐蔽。RMII链路完全正常PHY也协商成功但大流量下出现规律性丢包。用示波器看RMII接口的数据波形没有发现信号质量问题后来排查到是SoC的MAC DMA描述符没有正确配置导致接收FIFO溢出。如果你用的是标准Linux内核驱动这个坑出现的概率较小。但如果你的SoC的MAC驱动是芯片厂商深度定制的建议检查一下DMA burst size和FIFO threshold的配置。表格汇总一下这七个坑的快速排查方法坑编号现象快速排查方法处理策略坑1PHY ID匹配不上mii-tool扫描所有MDIO地址确认芯片实际响应地址并修改匹配坑2芯片不工作/寄存器读不了示波器测量复位引脚时序延长复位低电平时间和稳定时间坑3信号异常/无波形断开PHY检查SoC引脚状态修正pinctrl设备树配置坑4寄存器读写不稳定示波器测量MDIO/MDC波形调整上拉电阻和滤波电容坑5PHY link不up核对变压器中心抽头接法修改硬件或软件补偿坑6收发不通/广播不转发dump VLAN成员寄存器统一VLAN成员配置坑7大流量丢包检查DMA FIFO配置调整DMA参数6. 从驱动打通到稳定运行的进阶建议当你把RMII接口调通SoC和RTL8306MB之间能正常通信之后千万别急着收工。还有几个事情值得做能帮你后面的项目省下大量时间。第一把RTL8306MB的完整寄存器配置固化到驱动里做成一个rtl8306mb_hw_init()函数每次probe时按照固定顺序执行。RTL8306MB是纯寄存器配置型芯片没有固件可加载所有设置都在寄存器里掉电就丢。如果你不固化初始化流程每次上电后芯片可能处于完全不同的状态排查起来极为痛苦。第二把MDIO调试接口导出到用户空间。建议在驱动里实现一个简单的debugfs节点允许读写任意寄存器。这样后续调VLAN、端口配置时不需要反复编译内核直接echo命令就行。调试效率和体验完全不一样。第三确认SoC的MAC驱动对链路状态变化的处理。RTL8306MB的P0口如果被配置成强制100M全双工那么它的link状态实际上取决于其他下行端口有没有设备接入。有些SoC MAC驱动在检测到link down后会关闭DMA导致P0口无法发包。这种场景下可能需要通过软件方式让MAC始终认为link up或者用RTL8306MB的中断引脚来上报链路状态变化。第四注意散热和长期稳定性。RTL8306MB虽然功耗不高但在多口同时满速转发时芯片温度还是比较明显的。如果你的产品是密闭外壳建议在驱动里增加温度读取功能RTL8306MB内置温度传感器通过特殊寄存器读取并设置告警阈值。按照我个人的经验RTL8306MB这颗芯片在百兆多口场景下性价比确实很高但它的寄存器体系并不算友好page切换机制、各个端口控制位的排列、以及很多未公开的保留位都需要你在调试中反复试验。记住一个原则任何一次寄存器写入之前先把原始值读出来对照datasheet确认再写。很多“玄学”问题最后发现都是因为对某个保留位做了写入导致的。这次调试最大的体会就是RMII接口排错一定要有清晰的层次先是物理层的时钟、复位和引脚电平再是MDIO链路和PHY ID识别然后是MAC层的收发路径最后才是交换核心的转发行为。按照这个顺序排查思路会很清晰不会像无头苍蝇一样乱撞。希望这篇文章能帮你跳过那些我踩过的坑让你的RTL8306MB驱动开发之路顺畅一些。
