做嵌入式网络这一行最烧时间的往往不是协议栈而是链路起不来、link灯乱闪、ping通几秒又断这种玄学问题。尤其是涉及嵌入式设备的switch和PHY芯片时很多人会被MAC、PHY、Switch这仨角色搞晕寄存器读不到东西就先怀疑芯片是坏的结果绕了一大圈发现是PHY地址配错或者时钟相位没对准。这篇文章我会把switch和PHY芯片的调试方法和选型思路做一个偏实战的梳理适合正在调网口、做评估板选型、写设备树驱动、或者准备把百兆/千兆以太网接入自己系统的工程师参考。1. 先把角色理清楚MAC、PHY、Switch各管哪一段1.1 从信号通路看PHY的位置很多软件背景的嵌入式工程师调试网络习惯性先看协议栈、看socket、看netfilter链路不通就抓包。但实际上一块板子的网络通路是这样的CPU内部或者SoC内部集成了一个MAC控制器MAC出来的是数字信号比如MII/RGMII/SGMII这种信号完全没有办法直接驱动网线必须交给PHY芯片做物理层编码PHY最后通过MDI差分对把信号送到RJ45再过变压器耦合出去。你可以这么理解MAC负责把数据帧组织好、做好CRC校验、决定什么时候发它是“翻译官加交通警察”PHY负责把MAC给它的数字码流转成能在网线上传输的模拟差分信号同时负责链路检测、自协商、载波监听它是“跑在路上的车”。而变压器和RJ45就是“马路”。所以链路起不来问题可能出在MAC配置、PHY配置、PCB差分走线、变压器设计、对端设备等任何一个环节而PHY往往是第一个被甩锅的对象。1.2 Switch的本质是“多口MAC交换引擎”那Switch在这套体系里又是什么角色说白了一颗交换芯片内部集成了多个MAC、一个交换/转发引擎有些型号还直接内置了PHY。以常见的5口百兆交换芯片为例比如IP175G它内部自带5个PHY用MII或RMII接口接一个CPU口上来。这种芯片对你来说就是个“傻瓜交换机”上电就能通但它通常没有管理接口QoS、VLAN、IGMP这些功能要么阉割掉了要么需要用strap引脚配置成硬件模式调试手段非常有限。而管理型交换芯片比如瑞昱的RTL8367系列、博通的BCM53系列、微芯的KSZ系列内部有完整的交换查表引擎支持VLAN、端口镜像、ACL、IGMP Snooping一般通过MDIO、SPI、I2C或独立的CPU接口做配置。这种芯片调试起来复杂度高很多你得能读它的寄存器理解它的查表转发逻辑和端口映射关系不然就会出现“明明物理链路通了但两个端口之间就是不通”的典型问题。1.3 为什么很多工程师把PHY和Switch混为一谈我见过不少人在选型时把“带PHY的Switch”和“不带PHY的Switch”完全没分清导致原理图设计完发现MAC口对MAC口没法直接连中间还缺PHY。这个问题的根源在于有些芯片厂商喜欢把“Switch”定义成一个完整的二层交换方案里面PHY、MAC、转发引擎都有了你只需要配个CPU口接主机另一些芯片则是纯粹的交换核心必须外接PHY才能出网口。比如你要做8口千兆管理型交换机选了RTL8367RB这颗片但它不内置千兆PHY你需要另配8颗千兆PHY或者选用PHY集成度更高的型号这个成本和工作量差异是巨大的。所以做方案的第一步永远是在原理图之前把器件手册里的功能框图仔细看一遍搞清楚你面对的芯片到底是“带PHY的交换芯片”“不带PHY的交换芯片”还是“单口PHY”这决定了后面所有调试策略和寄存器访问方式。2. 接口选择决定后续所有调试难度MII/RGMII/SGMII怎么取舍2.1 接口本质是“马路宽度”MAC和PHY之间靠什么连接就是MAC侧接口常见的有MII、RMII、GMII、RGMII、SGMII。它们的本质区别就是数据通路的宽度和时钟频率。MII是4位数据线25MHz/2.5MHz时钟配合10M/100M速率RMII把数据线砍到2位但是时钟固定50MHz通过DDR方式采样GMII是8位数据线125MHz时钟对应千兆RGMII则是把GMII的数据线减半到4位然后用DDR方式在125MHz时钟的上下沿各采一次等效千兆带宽。接口类型数据线宽度时钟频率支持速率引脚数量估算适用场景MII4位25/2.5MHz10/100M约16根老平台、百兆RMII2位50MHz10/100M约7根引脚受限的百兆方案GMII8位125MHz1000M约24根早期千兆方案引脚多RGMII4位DDR125MHz10/100/1000M约12根当前最主流的千兆MAC-PHY接口SGMII1对差分线1.25Gbps串行10/100/1000M约4根高速背板、交换芯片互联、SoC与PHY长距离连接说它决定调试难度是因为MII/GMII这种并行接口时序比较宽松只要原理图没画错基本能通RGMII则要求时钟和数据之间的相位关系正确经常会遇到“千兆link up但吞吐量极低”的时序问题SGMII虽然是串行接口引脚少布线方便但配置复杂尤其涉及到SGMII IP核的MAC/PHY角色选择、自协商方式一旦配错就完全没有链路。所以选型时能用RMII解决百兆问题就别强行上万兆的RGMII能做SGMII背板互联就一定预留好调试接口。2.2 RGMII的时序坑时钟延迟与设备树配置RGMII最典型的坑就是发送时钟的相位。RGMII标准里MAC发送数据给PHY时发送方要把时钟相对于数据偏移大约2ns这样接收方的建立/保持时间才能满足。问题在于这个2ns偏移谁来做有的MAC内部支持delay配置有的PHY内部支持delay配置有的干脆需要PCB走线来做。常见的做法是在设备树里通过phy-mode来指定fec1 { phy-mode rgmii-id; phy-handle ethphy0; status okay; }; mdio { #address-cells 1; #size-cells 0; ethphy0: ethernet-phy0 { reg 0; }; };这里的rgmii-id表示RGMII的TX和RX延迟都由PHY端处理rgmii-txid表示只做TX延迟rgmii-rxid表示只做RX延迟如果配成rgmii就表示端侧都不做延迟完全靠PCB走线。问题是很多人拿到一个新板卡发现千兆起不来直接把phy-mode从rgmii改成rgmii-id能通就算完事但其实可能只是把问题掩盖了。正规做法是先看PHY芯片手册里的delay配置寄存器再看SoC的MAC侧是否支持内部delay最后结合PCB走线长度决定由谁承担这2ns。如果两边都做了延迟时序反而会差得更多。2.3 SGMII/1000BASE-X的SerDes配置MAC模式还是PHY模式SGMII和1000BASE-X都是高速串行接口跑的速率都是1.25Gbps但它们的自协商机制完全不同。SGMII是MAC和PHY之间的短距互联协议自带一种特殊的SGMII自协商用来传递速度/全双工信息1000BASE-X是真正的光口或者铜口千兆以太网的物理层标准自协商内容包含对端能力、流控、Master/Slave时钟等。所以当你把一颗PHY的SerDes口接到SoC的SGMII IP核时IP核的角色配置非常关键。在实际调试中最容易踩的坑就是FPGA或SoC内部的SGMII IP核默认工作在PHY模式也就是IP核自己模拟成一个PHY去和对端对接这个模式本身是给两个MAC通过背板互联用的。但你现在是要让IP核作为MAC去接外置PHY芯片如果IP核还是PHY角色两边都会以为对面是MAC或PHY自协商直接失败SGMII Link完全起不来。类似的词还有Xilinx SGMII IP核里的“MAC mode”和“PHY mode”选项还有一些SoC叫“SGMII”和“1000BASE-X”两种模式。我个人的经验是外接SGMII PHY时IP核必须配成MAC模式SGMII和1000BASE-X的auto-negotiation方式不要混用如果对端是PHY就用SGMII的自协商如果对端是另一个MAC或者交换芯片的SerDes口才考虑1000BASE-X模式。3. 实战调试链路从寄存器读写到回环定位3.1 第一步确认MDIO/MDC能访问到PHY寄存器拿到一个PHY或者交换芯片第一步永远是确认管理接口能读到芯片寄存器。绝大多数PHY和交换芯片都支持MDIO/MDC两根线来访问寄存器MDIO是一根双向数据线MDC是时钟线时序类似SPI最高频率一般在2.5MHz左右但很多芯片可以跑到更高。你在Linux下可以用mdio-tools直接操作# 读PHY ID寄存器 mdio read eth0 0x02 mdio read eth0 0x03如果读出来是0xffff说明MDIO根本没访问到目标芯片原因大概率是PHY地址不对、MDIO无上拉、PHY没复位或供电异常如果读出来是0x0000可能是PHY处于复位状态或者strap引脚配置异常。这里有一个经验PHY芯片的地址通常靠外部strap电阻在复位时锁存常见做法是把AD0、AD1等地址引脚通过上下拉设成某个固定值。你在原理图阶段就要记录好每个PHY的地址规划否则等板子回来一个地址对应好几颗芯片怎么调都调不对。写寄存器之前建议先把PHY的ID寄存器读出来跟数据手册核对一下。我遇到过从代理商拿到的样品丝印是A型号实际读到ID却是B型号完全不影响功能但寄存器配置差异很大这个核对能帮你省掉很多无谓的折腾。3.2 第二步用回环缩小问题范围当链路不通时最忌讳东改一下西改一下。我自己的调试习惯是先做回环测试把网络通路切分成几段逐一验证。PHY的回环一般有两类一类是MAC侧回环就是把MAC发出来的数据直接在MAC和PHY接口前端弹回MAC验证MAC和驱动是否正常另一类是PHY远端回环也就是PHY收到MAC的数据后不往网线上发而是从接收通路弹回MAC这样可以验证MAC到PHY之间的数据通路、PHY配置、时钟是否正常。实际上很多PHY在寄存器0BMCR里就有一个loopback位比如# 打开PHY回环 mdio write eth0 0x00 0x4000 # 用ping验证如果此时能通说明MAC到PHY的路径正常 ping -I eth0 192.168.1.1ethtool -t eth0在很多驱动里也会执行PHY内建的自检和回环测试可以直接用来快速判断PHY健康状况。回环测完仍然不通问题基本就锁定在PHY往外的物理链路段再去查变压器、RJ45、网线和对端设备。3.3 第三步外回环与对端设备测试链路MAC和PHY路径验证通过后可以用一个外部的RJ45回环头把PHY发出的差分信号直接环回到PHY的接收端验证PHY到连接器这一段。没有回环头的话也可以用短网线把板子的两个网口对接。这个阶段如果link还是起不来基本可以断定问题出在PHY的时钟、配置或者PCB差分设计上。外部回环通了之后再接真实的交换机或PC用交叉线或直通线测。这里要注意自协商失败的问题。PC网卡、交换机端口的自协商能力通常很强但你的PHY如果通过strap pin把自协商关掉了强制成100M全双工而对端强制成100M半双工两边速度一致但双工不一致就会出现链路能通、通信吞吐极差、大量CRC错误的经典故障。这种问题用mii-tool eth0看一眼就能发现mii-tool eth0正常应该显示negotiated link speed和duplex如果显示100baseTx-HD这种半双工而你要的是全双工那就要check PHY的ANEN bit和speed/duplex配置寄存器。3.4 第四步用ethtool做软硬件协同验证软件侧能做的事不止于ping。我的习惯是先用ethtool eth0看当前链路状态再用ethtool -S eth0看发送/接收/CRC错误的统计计数这些计数能帮你快速定位是物理层问题还是驱动问题。比如rx_crc_errors疯狂增长说明信号质量差大概率是RGMII时序偏或者PCB走线过长但如果tx_packets和rx_packets都正常增长只是业务报文不通那问题可能在协议栈或者对端配置上。ethtool eth0 ethtool -S eth0还可以用ethtool -s eth0 speed 100 duplex full autoneg off强制速率和自协商结果做对比。如果自协商只能协商到100M但对端明明支持1000M多半是PHY的千兆能力没有开启、晶体频率不对、或者PCB差分线等长问题导致信号质量达不到千兆标准。这一步整个链路基本就跑完了剩下就是按章节2、3的方法去调具体参数。4. 选型时我会按这个顺序做判断4.1 先把“必须项”定死速率、接口、温度、封装选型不是先看哪个便宜而是先把不可能让步的硬指标定死。速率是第一个你确定是10/100M还是千兆这个直接决定PHY接口的选择。百兆PHY用MII/RMII千兆PHY用RGMII/SGMII接口定了SoC侧能不能支持也就定了。第二个是温度范围工业设备跑-40℃到85℃甚至105℃消费级PHY在高温下丢包、寄存器乱跳的现象我见过不止一次这个省不得。第三个是封装和引脚间距QFN封装的PHY焊接和散热考虑和LQFP完全不同小批量打样时QFN开钢网、贴片良率都值得提前评估。另外PHY芯片外围器件也是选型的一部分。以百兆PHY为例最常见的是25MHz晶体有些芯片也可以用50MHz时钟输入少一颗晶振在成本上可以省一点但走线要求会更高。电源设计方面很多PHY有1.8V或2.5V的模拟供电和数字供电对电源纹波敏感PCB上滤波电容的位置和数量几乎直接决定PHY的稳定性。选一颗芯片前最好把它的参考设计完全吃透再决定如何裁剪。4.2 资源可得性和软件配套同样要命很多工程师选型只盯数据手册忽略了软件生态。一颗PHY再好如果你的内核、BSP、设备树里没有对应驱动适配或者厂商只提供老版本驱动不愿意给你移植补丁那你要么自己啃寄存器手册写驱动要么项目进度就得等。有一说一瑞昱、美满、微芯这些大厂的PHY驱动在Linux内核里已经很成熟基本是开箱即用但一些国产新锐芯片虽然硬件参数看起来不错驱动适配和勘误文档的完善程度往往跟老牌厂商有差距这个在选型时一定要纳入评估。我一般会做一个检查清单内核或SDK里有没有现成的PHY驱动厂商有没有对应的设备树配置说明官方评估板的原理图能不能直接拿到有没有已知的勘误表errata这些比峰值速率、功耗这些纸面参数更能决定项目能不能顺利落地。4.3 国产与国外PHY/Switch的现状对比最近几年国产PHY和Switch芯片选择确实多了不少百兆PHY这片基本已经卷到家了裕太微、景略、昆高新芯这些厂商都有对应型号千兆PHY也在逐步铺开。交换芯片方面像盛科这类厂商在接入/聚合场景有不少方案微芯、瑞昱、博通依然占有大量份额。从选型角度我的判断原则是对成本敏感、量大、功能固定、技术支持到位的产品国产芯片完全可以上对协议兼容性要求极高、Ethernet/IP或者Profinet这类工业协议需要认证的场景老牌厂商的成熟方案能少很多坑。这里说一个真实感受国产PHY的硬件本身问题不大但寄存器定义和驱动适配方式跟国际主流芯片差异较大如果你的BSP是基于老牌PHY调通的切到国产芯片后需要预留足够的驱动调试时间。设备树里除了compatiblePHY的地址、中断脚、复位脚的差异都要重新适配这部分工作量经常被低估。5. 三个实战踩坑记录能帮你省下至少一周调试时间5.1 坑一复位时序不对PHY地址都读不对有一块板子CPU通过MDIO访问一个外接百兆PHY现象是复位之后读ID寄存器全是0xFFFF。我第一反应是MDIO上拉或者PHY地址不对量了地址引脚的电平也正常后来用示波器抓了PHY的复位脚波形才发现CPU的GPIO复位信号在上电后很快就释放了但PHY的供电电压还没完全爬升到稳定值导致PHY内部的strap引脚锁存失败地址根本没有被正确识别。排查链路是这样的先量PHY供电端电压爬升曲线再量复位释放点发现复位释放比电源稳定早了约30ms。解决方案最简单的是在GPIO控制的复位脚上增加RC延时确保复位释放晚于电源稳定至少10ms以上更可靠的做法是在驱动里面做延时复位后等待50ms再开始MDIO访问。这类问题在所有PHY和Switch芯片上都可能出现尤其是电源和复位由不同PMIC管理时时序更难保证。5.2 坑二RGMII时钟相位link up了但吞吐上不去另一个项目是SoC的RGMII口接了一颗千兆PHY以太网link能正常起来协商在1000M全双工但是跑吞吐测试只有几十Mbps而且大包测试直接丢包小包还算正常。这种情况下开始只怀疑PHY驱动和DMA配置反复改中断合并、改描述符数量都没用。后来老老实实用示波器抓RGMII总线的TX_CLK和TXD发现时钟沿和数据的边沿几乎完全对齐按标准应该有大约2ns的偏移。排查后发现这颗SoC的MAC内部不带delayPHY端配置寄存器里也没有把TX delay打开于是出现时钟和数据相位重合。解决办法是在PHY的厂商私有寄存器里面打开TX clock delay或者在设备树里把phy-mode设成rgmii-txid。改完之后吞吐测试直接跑到接近线速。这个案例给我的教训是RGMII调试如果不带头去关心时钟相位很多“性能问题”会伪装成驱动问题浪费很长时间。5.3 坑三交换芯片镜像口抓不到包最后一个案例是关于Switch芯片的。我在用一颗带管理功能的交换芯片做网络抓包TAP设备CPU连的是交换芯片的CPU口另外两个普通网口分别接上行和下行设备。我配置了端口镜像想把A口和B口的双向流量都镜像到CPU口结果A口到B口的流量能正常转发但CPU口收到的镜像包只有零星几个广播包根本抓不到单播流量。查了很半天才发现这颗芯片的镜像功能默认只镜像收到的包ingress mirror不镜像发出的包egress mirror而且默认的镜像VLAN过滤把很多CPU口不关心的报文直接丢弃了。加上单播流量在转发表命中后走的是专门的转发路径跟镜像路径是两个引擎配置没有在镜像引擎里同时使能ingress和egress就会漏包。这个问题在不看数据手册的“Mirror”章节时根本想不到。所以用交换芯片做TAP设备第一步就是把镜像的ingress/egress方向、镜像VLAN、以及是否影响正常转发这几个概念一次查清楚。这次先分享到这里。做嵌入式网络链路调试最宝贵的就是把“职责边界”画清楚再一层一层做回环大多数问题都能在一个小时内定位到具体段落。下一期我会继续聊交换芯片内部的VLAN配置、IGMP Snooping、端口隔离这些管理功能的调试要点以及CPU口和物理口之间的查表转发行为这些在项目里踩的坑比PHY层只多不少。
做嵌入式网络这一行最烧时间的往往不是协议栈而是链路起不来、link灯乱闪、ping通几秒又断这种玄学问题。尤其是涉及嵌入式设备的switch和PHY芯片时很多人会被MAC、PHY、Switch这仨角色搞晕寄存器读不到东西就先怀疑芯片是坏的结果绕了一大圈发现是PHY地址配错或者时钟相位没对准。这篇文章我会把switch和PHY芯片的调试方法和选型思路做一个偏实战的梳理适合正在调网口、做评估板选型、写设备树驱动、或者准备把百兆/千兆以太网接入自己系统的工程师参考。1. 先把角色理清楚MAC、PHY、Switch各管哪一段1.1 从信号通路看PHY的位置很多软件背景的嵌入式工程师调试网络习惯性先看协议栈、看socket、看netfilter链路不通就抓包。但实际上一块板子的网络通路是这样的CPU内部或者SoC内部集成了一个MAC控制器MAC出来的是数字信号比如MII/RGMII/SGMII这种信号完全没有办法直接驱动网线必须交给PHY芯片做物理层编码PHY最后通过MDI差分对把信号送到RJ45再过变压器耦合出去。你可以这么理解MAC负责把数据帧组织好、做好CRC校验、决定什么时候发它是“翻译官加交通警察”PHY负责把MAC给它的数字码流转成能在网线上传输的模拟差分信号同时负责链路检测、自协商、载波监听它是“跑在路上的车”。而变压器和RJ45就是“马路”。所以链路起不来问题可能出在MAC配置、PHY配置、PCB差分走线、变压器设计、对端设备等任何一个环节而PHY往往是第一个被甩锅的对象。1.2 Switch的本质是“多口MAC交换引擎”那Switch在这套体系里又是什么角色说白了一颗交换芯片内部集成了多个MAC、一个交换/转发引擎有些型号还直接内置了PHY。以常见的5口百兆交换芯片为例比如IP175G它内部自带5个PHY用MII或RMII接口接一个CPU口上来。这种芯片对你来说就是个“傻瓜交换机”上电就能通但它通常没有管理接口QoS、VLAN、IGMP这些功能要么阉割掉了要么需要用strap引脚配置成硬件模式调试手段非常有限。而管理型交换芯片比如瑞昱的RTL8367系列、博通的BCM53系列、微芯的KSZ系列内部有完整的交换查表引擎支持VLAN、端口镜像、ACL、IGMP Snooping一般通过MDIO、SPI、I2C或独立的CPU接口做配置。这种芯片调试起来复杂度高很多你得能读它的寄存器理解它的查表转发逻辑和端口映射关系不然就会出现“明明物理链路通了但两个端口之间就是不通”的典型问题。1.3 为什么很多工程师把PHY和Switch混为一谈我见过不少人在选型时把“带PHY的Switch”和“不带PHY的Switch”完全没分清导致原理图设计完发现MAC口对MAC口没法直接连中间还缺PHY。这个问题的根源在于有些芯片厂商喜欢把“Switch”定义成一个完整的二层交换方案里面PHY、MAC、转发引擎都有了你只需要配个CPU口接主机另一些芯片则是纯粹的交换核心必须外接PHY才能出网口。比如你要做8口千兆管理型交换机选了RTL8367RB这颗片但它不内置千兆PHY你需要另配8颗千兆PHY或者选用PHY集成度更高的型号这个成本和工作量差异是巨大的。所以做方案的第一步永远是在原理图之前把器件手册里的功能框图仔细看一遍搞清楚你面对的芯片到底是“带PHY的交换芯片”“不带PHY的交换芯片”还是“单口PHY”这决定了后面所有调试策略和寄存器访问方式。2. 接口选择决定后续所有调试难度MII/RGMII/SGMII怎么取舍2.1 接口本质是“马路宽度”MAC和PHY之间靠什么连接就是MAC侧接口常见的有MII、RMII、GMII、RGMII、SGMII。它们的本质区别就是数据通路的宽度和时钟频率。MII是4位数据线25MHz/2.5MHz时钟配合10M/100M速率RMII把数据线砍到2位但是时钟固定50MHz通过DDR方式采样GMII是8位数据线125MHz时钟对应千兆RGMII则是把GMII的数据线减半到4位然后用DDR方式在125MHz时钟的上下沿各采一次等效千兆带宽。接口类型数据线宽度时钟频率支持速率引脚数量估算适用场景MII4位25/2.5MHz10/100M约16根老平台、百兆RMII2位50MHz10/100M约7根引脚受限的百兆方案GMII8位125MHz1000M约24根早期千兆方案引脚多RGMII4位DDR125MHz10/100/1000M约12根当前最主流的千兆MAC-PHY接口SGMII1对差分线1.25Gbps串行10/100/1000M约4根高速背板、交换芯片互联、SoC与PHY长距离连接说它决定调试难度是因为MII/GMII这种并行接口时序比较宽松只要原理图没画错基本能通RGMII则要求时钟和数据之间的相位关系正确经常会遇到“千兆link up但吞吐量极低”的时序问题SGMII虽然是串行接口引脚少布线方便但配置复杂尤其涉及到SGMII IP核的MAC/PHY角色选择、自协商方式一旦配错就完全没有链路。所以选型时能用RMII解决百兆问题就别强行上万兆的RGMII能做SGMII背板互联就一定预留好调试接口。2.2 RGMII的时序坑时钟延迟与设备树配置RGMII最典型的坑就是发送时钟的相位。RGMII标准里MAC发送数据给PHY时发送方要把时钟相对于数据偏移大约2ns这样接收方的建立/保持时间才能满足。问题在于这个2ns偏移谁来做有的MAC内部支持delay配置有的PHY内部支持delay配置有的干脆需要PCB走线来做。常见的做法是在设备树里通过phy-mode来指定fec1 { phy-mode rgmii-id; phy-handle ethphy0; status okay; }; mdio { #address-cells 1; #size-cells 0; ethphy0: ethernet-phy0 { reg 0; }; };这里的rgmii-id表示RGMII的TX和RX延迟都由PHY端处理rgmii-txid表示只做TX延迟rgmii-rxid表示只做RX延迟如果配成rgmii就表示端侧都不做延迟完全靠PCB走线。问题是很多人拿到一个新板卡发现千兆起不来直接把phy-mode从rgmii改成rgmii-id能通就算完事但其实可能只是把问题掩盖了。正规做法是先看PHY芯片手册里的delay配置寄存器再看SoC的MAC侧是否支持内部delay最后结合PCB走线长度决定由谁承担这2ns。如果两边都做了延迟时序反而会差得更多。2.3 SGMII/1000BASE-X的SerDes配置MAC模式还是PHY模式SGMII和1000BASE-X都是高速串行接口跑的速率都是1.25Gbps但它们的自协商机制完全不同。SGMII是MAC和PHY之间的短距互联协议自带一种特殊的SGMII自协商用来传递速度/全双工信息1000BASE-X是真正的光口或者铜口千兆以太网的物理层标准自协商内容包含对端能力、流控、Master/Slave时钟等。所以当你把一颗PHY的SerDes口接到SoC的SGMII IP核时IP核的角色配置非常关键。在实际调试中最容易踩的坑就是FPGA或SoC内部的SGMII IP核默认工作在PHY模式也就是IP核自己模拟成一个PHY去和对端对接这个模式本身是给两个MAC通过背板互联用的。但你现在是要让IP核作为MAC去接外置PHY芯片如果IP核还是PHY角色两边都会以为对面是MAC或PHY自协商直接失败SGMII Link完全起不来。类似的词还有Xilinx SGMII IP核里的“MAC mode”和“PHY mode”选项还有一些SoC叫“SGMII”和“1000BASE-X”两种模式。我个人的经验是外接SGMII PHY时IP核必须配成MAC模式SGMII和1000BASE-X的auto-negotiation方式不要混用如果对端是PHY就用SGMII的自协商如果对端是另一个MAC或者交换芯片的SerDes口才考虑1000BASE-X模式。3. 实战调试链路从寄存器读写到回环定位3.1 第一步确认MDIO/MDC能访问到PHY寄存器拿到一个PHY或者交换芯片第一步永远是确认管理接口能读到芯片寄存器。绝大多数PHY和交换芯片都支持MDIO/MDC两根线来访问寄存器MDIO是一根双向数据线MDC是时钟线时序类似SPI最高频率一般在2.5MHz左右但很多芯片可以跑到更高。你在Linux下可以用mdio-tools直接操作# 读PHY ID寄存器 mdio read eth0 0x02 mdio read eth0 0x03如果读出来是0xffff说明MDIO根本没访问到目标芯片原因大概率是PHY地址不对、MDIO无上拉、PHY没复位或供电异常如果读出来是0x0000可能是PHY处于复位状态或者strap引脚配置异常。这里有一个经验PHY芯片的地址通常靠外部strap电阻在复位时锁存常见做法是把AD0、AD1等地址引脚通过上下拉设成某个固定值。你在原理图阶段就要记录好每个PHY的地址规划否则等板子回来一个地址对应好几颗芯片怎么调都调不对。写寄存器之前建议先把PHY的ID寄存器读出来跟数据手册核对一下。我遇到过从代理商拿到的样品丝印是A型号实际读到ID却是B型号完全不影响功能但寄存器配置差异很大这个核对能帮你省掉很多无谓的折腾。3.2 第二步用回环缩小问题范围当链路不通时最忌讳东改一下西改一下。我自己的调试习惯是先做回环测试把网络通路切分成几段逐一验证。PHY的回环一般有两类一类是MAC侧回环就是把MAC发出来的数据直接在MAC和PHY接口前端弹回MAC验证MAC和驱动是否正常另一类是PHY远端回环也就是PHY收到MAC的数据后不往网线上发而是从接收通路弹回MAC这样可以验证MAC到PHY之间的数据通路、PHY配置、时钟是否正常。实际上很多PHY在寄存器0BMCR里就有一个loopback位比如# 打开PHY回环 mdio write eth0 0x00 0x4000 # 用ping验证如果此时能通说明MAC到PHY的路径正常 ping -I eth0 192.168.1.1ethtool -t eth0在很多驱动里也会执行PHY内建的自检和回环测试可以直接用来快速判断PHY健康状况。回环测完仍然不通问题基本就锁定在PHY往外的物理链路段再去查变压器、RJ45、网线和对端设备。3.3 第三步外回环与对端设备测试链路MAC和PHY路径验证通过后可以用一个外部的RJ45回环头把PHY发出的差分信号直接环回到PHY的接收端验证PHY到连接器这一段。没有回环头的话也可以用短网线把板子的两个网口对接。这个阶段如果link还是起不来基本可以断定问题出在PHY的时钟、配置或者PCB差分设计上。外部回环通了之后再接真实的交换机或PC用交叉线或直通线测。这里要注意自协商失败的问题。PC网卡、交换机端口的自协商能力通常很强但你的PHY如果通过strap pin把自协商关掉了强制成100M全双工而对端强制成100M半双工两边速度一致但双工不一致就会出现链路能通、通信吞吐极差、大量CRC错误的经典故障。这种问题用mii-tool eth0看一眼就能发现mii-tool eth0正常应该显示negotiated link speed和duplex如果显示100baseTx-HD这种半双工而你要的是全双工那就要check PHY的ANEN bit和speed/duplex配置寄存器。3.4 第四步用ethtool做软硬件协同验证软件侧能做的事不止于ping。我的习惯是先用ethtool eth0看当前链路状态再用ethtool -S eth0看发送/接收/CRC错误的统计计数这些计数能帮你快速定位是物理层问题还是驱动问题。比如rx_crc_errors疯狂增长说明信号质量差大概率是RGMII时序偏或者PCB走线过长但如果tx_packets和rx_packets都正常增长只是业务报文不通那问题可能在协议栈或者对端配置上。ethtool eth0 ethtool -S eth0还可以用ethtool -s eth0 speed 100 duplex full autoneg off强制速率和自协商结果做对比。如果自协商只能协商到100M但对端明明支持1000M多半是PHY的千兆能力没有开启、晶体频率不对、或者PCB差分线等长问题导致信号质量达不到千兆标准。这一步整个链路基本就跑完了剩下就是按章节2、3的方法去调具体参数。4. 选型时我会按这个顺序做判断4.1 先把“必须项”定死速率、接口、温度、封装选型不是先看哪个便宜而是先把不可能让步的硬指标定死。速率是第一个你确定是10/100M还是千兆这个直接决定PHY接口的选择。百兆PHY用MII/RMII千兆PHY用RGMII/SGMII接口定了SoC侧能不能支持也就定了。第二个是温度范围工业设备跑-40℃到85℃甚至105℃消费级PHY在高温下丢包、寄存器乱跳的现象我见过不止一次这个省不得。第三个是封装和引脚间距QFN封装的PHY焊接和散热考虑和LQFP完全不同小批量打样时QFN开钢网、贴片良率都值得提前评估。另外PHY芯片外围器件也是选型的一部分。以百兆PHY为例最常见的是25MHz晶体有些芯片也可以用50MHz时钟输入少一颗晶振在成本上可以省一点但走线要求会更高。电源设计方面很多PHY有1.8V或2.5V的模拟供电和数字供电对电源纹波敏感PCB上滤波电容的位置和数量几乎直接决定PHY的稳定性。选一颗芯片前最好把它的参考设计完全吃透再决定如何裁剪。4.2 资源可得性和软件配套同样要命很多工程师选型只盯数据手册忽略了软件生态。一颗PHY再好如果你的内核、BSP、设备树里没有对应驱动适配或者厂商只提供老版本驱动不愿意给你移植补丁那你要么自己啃寄存器手册写驱动要么项目进度就得等。有一说一瑞昱、美满、微芯这些大厂的PHY驱动在Linux内核里已经很成熟基本是开箱即用但一些国产新锐芯片虽然硬件参数看起来不错驱动适配和勘误文档的完善程度往往跟老牌厂商有差距这个在选型时一定要纳入评估。我一般会做一个检查清单内核或SDK里有没有现成的PHY驱动厂商有没有对应的设备树配置说明官方评估板的原理图能不能直接拿到有没有已知的勘误表errata这些比峰值速率、功耗这些纸面参数更能决定项目能不能顺利落地。4.3 国产与国外PHY/Switch的现状对比最近几年国产PHY和Switch芯片选择确实多了不少百兆PHY这片基本已经卷到家了裕太微、景略、昆高新芯这些厂商都有对应型号千兆PHY也在逐步铺开。交换芯片方面像盛科这类厂商在接入/聚合场景有不少方案微芯、瑞昱、博通依然占有大量份额。从选型角度我的判断原则是对成本敏感、量大、功能固定、技术支持到位的产品国产芯片完全可以上对协议兼容性要求极高、Ethernet/IP或者Profinet这类工业协议需要认证的场景老牌厂商的成熟方案能少很多坑。这里说一个真实感受国产PHY的硬件本身问题不大但寄存器定义和驱动适配方式跟国际主流芯片差异较大如果你的BSP是基于老牌PHY调通的切到国产芯片后需要预留足够的驱动调试时间。设备树里除了compatiblePHY的地址、中断脚、复位脚的差异都要重新适配这部分工作量经常被低估。5. 三个实战踩坑记录能帮你省下至少一周调试时间5.1 坑一复位时序不对PHY地址都读不对有一块板子CPU通过MDIO访问一个外接百兆PHY现象是复位之后读ID寄存器全是0xFFFF。我第一反应是MDIO上拉或者PHY地址不对量了地址引脚的电平也正常后来用示波器抓了PHY的复位脚波形才发现CPU的GPIO复位信号在上电后很快就释放了但PHY的供电电压还没完全爬升到稳定值导致PHY内部的strap引脚锁存失败地址根本没有被正确识别。排查链路是这样的先量PHY供电端电压爬升曲线再量复位释放点发现复位释放比电源稳定早了约30ms。解决方案最简单的是在GPIO控制的复位脚上增加RC延时确保复位释放晚于电源稳定至少10ms以上更可靠的做法是在驱动里面做延时复位后等待50ms再开始MDIO访问。这类问题在所有PHY和Switch芯片上都可能出现尤其是电源和复位由不同PMIC管理时时序更难保证。5.2 坑二RGMII时钟相位link up了但吞吐上不去另一个项目是SoC的RGMII口接了一颗千兆PHY以太网link能正常起来协商在1000M全双工但是跑吞吐测试只有几十Mbps而且大包测试直接丢包小包还算正常。这种情况下开始只怀疑PHY驱动和DMA配置反复改中断合并、改描述符数量都没用。后来老老实实用示波器抓RGMII总线的TX_CLK和TXD发现时钟沿和数据的边沿几乎完全对齐按标准应该有大约2ns的偏移。排查后发现这颗SoC的MAC内部不带delayPHY端配置寄存器里也没有把TX delay打开于是出现时钟和数据相位重合。解决办法是在PHY的厂商私有寄存器里面打开TX clock delay或者在设备树里把phy-mode设成rgmii-txid。改完之后吞吐测试直接跑到接近线速。这个案例给我的教训是RGMII调试如果不带头去关心时钟相位很多“性能问题”会伪装成驱动问题浪费很长时间。5.3 坑三交换芯片镜像口抓不到包最后一个案例是关于Switch芯片的。我在用一颗带管理功能的交换芯片做网络抓包TAP设备CPU连的是交换芯片的CPU口另外两个普通网口分别接上行和下行设备。我配置了端口镜像想把A口和B口的双向流量都镜像到CPU口结果A口到B口的流量能正常转发但CPU口收到的镜像包只有零星几个广播包根本抓不到单播流量。查了很半天才发现这颗芯片的镜像功能默认只镜像收到的包ingress mirror不镜像发出的包egress mirror而且默认的镜像VLAN过滤把很多CPU口不关心的报文直接丢弃了。加上单播流量在转发表命中后走的是专门的转发路径跟镜像路径是两个引擎配置没有在镜像引擎里同时使能ingress和egress就会漏包。这个问题在不看数据手册的“Mirror”章节时根本想不到。所以用交换芯片做TAP设备第一步就是把镜像的ingress/egress方向、镜像VLAN、以及是否影响正常转发这几个概念一次查清楚。这次先分享到这里。做嵌入式网络链路调试最宝贵的就是把“职责边界”画清楚再一层一层做回环大多数问题都能在一个小时内定位到具体段落。下一期我会继续聊交换芯片内部的VLAN配置、IGMP Snooping、端口隔离这些管理功能的调试要点以及CPU口和物理口之间的查表转发行为这些在项目里踩的坑比PHY层只多不少。
