嵌入式以太网驱动开发实战：从MAC/PHY调试到性能优化

做嵌入式驱动开发这些年以太网这个坑算是踩得最深也最有收获的一个领域。从早期的百兆芯片到现在的千兆、2.5G从简单的RGMII到复杂的SGMII再到工业现场跟各种设备做以太网通讯几乎每个项目都能遇到全新的问题。今天这一期我把自己在Ethernet以太网驱动开发上积累的经验整理出来从底层原理到实际调试从性能优化到工业场景踩坑一次性说透。无论你是刚开始接触网络驱动的新手还是已经在MAC和PHY之间挣扎了一段时间的同行这篇内容应该都能提供一些参考。很多刚入门的朋友容易把以太网驱动理解为“配置寄存器、启用DMA、收发包就完事”但实际上驱动只是整个网络路径中的一环。你写的是网卡驱动但你的代码要跟协议栈、PHY、甚至交换机、对端设备发生关系。所以我先说清楚以太网驱动开发核心是理解数据流而不是只会翻datasheet。1. 以太网驱动开发的核心思路从MAC到PHY的整体认知1.1 网络分层视角下的驱动边界以太网驱动处于硬件和协议栈之间往上对接Linux内核的net_device结构体往下直接操作MAC控制器和PHY芯片。驱动需要处理的是内核协议栈传来的sk_buff通过DMA发送到MAC再由PHY转换成物理层信号反过来PHY收到的电信号经过MAC还原成帧DMA搬到内存再上交协议栈。我见过很多人调试网络不通第一步就去看寄存器这没错但容易迷失方向。更稳妥的做法是先确认物理层链路是否ok——PHY是否完成了自协商link是否established然后看MAC是否收到了帧再看DMA描述符是否有数据。这种从物理层往上层走的排查思路能让你少走很多弯路。驱动开发的第一个关键边界是搞清楚哪些事情由硬件做哪些由驱动做。比如CRC校验、帧间隙、MAC地址过滤这些绝大多数MAC硬件都做了驱动不需要重复处理。但有些功能比如VLAN tag插入、TCP分段卸载TSO虽然硬件支持驱动也要做很多配置和状态维护工作。这里面的“度”没把握好就会出现莫名其妙的丢包或者性能问题。第二个边界是PHY管理。PHY芯片的寄存器空间需要通过MDIO总线访问通常由MAC的MDIO控制器或者独立的MDIO硬件完成。驱动要负责PHY的复位、自协商触发、速度/双工模式读取、loopback测试等。很多新人在初始化时只做一次PHY配置后续不管了结果遇到热插拔或者对端设备切换速率链路就僵死。正确的做法是注册PHY中断或者轮询link状态实时响应链路变化。1.2 速率与介质1G/2.5G Ethernet 的PCS/PMA 与 SGMII 到底在说什么我们在选型的时候经常会看到“1G/2.5G Ethernet PCS/PMA or SGMII”这样的描述。很多工程师一看到PCS/PMA就头大其实它指的是PHY内部的两个子层。PCSPhysical Coding Sublayer负责编码、加扰、对齐等。千兆以太网用的是8B/10B编码2.5G以太网在SGMII接口上往往也是基于类似的编码方式。PMAPhysical Medium Attachment负责串并转换、时钟恢复和信号调制。简单说PCS解决“数据怎么变成可以在线上传输的码流”PMA解决“码流怎么通过物理线缆发出去”。而SGMII是一种MAC和PHY之间的接口协议它本身是一种串行接口类似于SerDes。SGMII可以承载1Gbps或更低的速率而2.5G Ethernet的SGMII通常是2500Mbps有些芯片也支持“USXGMII”这类扩展接口。当你看到“1G/2.5G Ethernet PCS/PMA or SGMII”指的是PHY支持这些接口模式你需要在驱动里通过寄存器配置选择合适的模式。实际项目里我们用的主控芯片可能内置了MAC但缺少PHY或者PHY是外挂的。MAC和PHY之间的接口常见的有RGMII千兆常用的并行接口时钟125MHz数据双沿采样引脚多但布线相对简单。SGMII串行接口引脚少抗干扰强适合高速和板间互联。QSGMII4个SGMII复用一对差分线主要用于交换机芯片。驱动开发时要特别注意SGMII的自协商机制。SGMII本身也有自协商但它不是标准的802.3自协商而是MAC和PHY之间的速率协商。驱动里需要正确配置MAC侧的SGMII自适应通常是在MAC寄存器中使能SGMII autoneg同时也要让PHY侧配合。这个配置如果不对经常出现PHY link up但数据不通或者MAC和PHY速率不一致的情况。有一种比较阴间的现象PHY显示链接速率是1G但MAC那边配置的是2.5G结果就是能收到一点数据但丢包率极高。排查这种问题需要同时读取MAC侧的状态寄存器通常有link速度指示和PHY侧的速度寄存器对比两边是否一致。这也是我强调“接口配置必须两端对齐”的原因。2. 驱动开发中的关键环节接口、描述符与中断处理2.1 从RGMII到SGMII的接口选择与配置选择RGMII还是SGMII很多时候不是开发人员能决定的而是硬件工程师根据板级布局和成本定的。作为驱动开发者你需要做的是适配。RGMII的配置要点主要是时钟延时。RGMII规范要求数据在时钟的双沿采样但实际布线时数据信号和时钟信号可能存在偏差。于是就有了“tx delay”和“rx delay”的概念。很多MAC和PHY都支持在内部插入延时通过寄存器配置。例如你可以设置MAC侧的TX clock delay或者让PHY侧提供RX clock delay。这个配置必须在驱动初始化阶段完成而且要跟硬件原理图对应。我遇到过一块板子初始化PHY后ping不通后来发现是RGMII的RX延时没有配置导致MAC在时钟沿采样数据时采到的都是毛刺。加上delay之后一切正常。所以RGMII调试时如果你不确定延时配置可以用PHY的loopback模式测试MAC侧的数据通路再逐项排查。SGMII的配置相对简单因为它是串行差分线不需要考虑并行数据的时钟偏移。但SGMII也有自己的坑协商失败。特别是当对端设备是交换机或者另一个开发板时如果SGMII配置不是“自协商固定从模式”可能需要强制设置速度。我记得有一款PHY默认SGMII从模式必须等到对端发送自协商配置才能建立链路这在有些场景下会导致长时间无法link up。解决方法是把SGMII配置为master模式自己主动发起协商。2.2 DMA描述符环设计与内存屏障无论MAC是内置还是外置绝大多数以太网控制器都使用DMA搬运网络数据避免CPU逐字节拷贝。DMA描述符环是整个驱动的核心数据结构它描述了一块内存缓冲区的位置、长度、状态等信息。驱动需要维护发送描述符环和接收描述符环。接收描述符环的初始化尤其重要。你需要为每个描述符分配一个缓冲区sk_buff的data区并把物理地址写入描述符。然后设置拥有权位交给硬件。硬件收到数据后会填充缓冲区并把状态位更新为“已接收”驱动在中断或轮询中扫描描述符发现拥有权变化就知道有数据到了。这里有几个容易犯的错分配缓冲区时没有做cache对齐。网络DMA要求缓冲区物理地址对齐到cache line否则可能出现数据不一致。没有处理“拥有权”标志。有些芯片用描述符的最后一个bit来表示归属驱动在回收描述符时如果写错了会覆盖硬件正在使用的描述符。环形队列的索引管理。发送和接收的索引要明确区分“硬件当前使用的索引”和“驱动当前处理的索引”两者没理清就会丢包或者卡死。内存屏障也是一个关键点。CPU往描述符写入状态后需要确保写入顺序对DMA可见DMA更新状态后CPU读取时也需要屏障。在Linux驱动中通常使用dma_wmb()和dma_rmb()。有朋友问过我为什么加了mb()还是有问题其实是因为mb()是全屏障性能损耗大而且有些架构下语义不完全匹配DMA场景。正确的做法是严格区分读写方向。我在调试一个eMMC和网络DMA互相干扰的项目时发现描述符状态一直读取不到硬件更新后来检查发现是描述符本身被分配到了非DMA安全区域。所以在分配描述符时一定要用dma_alloc_coherent()或者类似接口保证内存不会被cache写回覆盖。2.3 中断与轮询的取舍以太网驱动通常有两种收包模式中断驱动和NAPI轮询。中断是及时但高吞吐时频繁中断会吃掉CPUNAPI是把中断和轮询结合起来用少量中断配合轮询批量收包。Linux内核默认使用NAPI这也是为什么netdev驱动里都有一个poll回调。轮询的实现并不复杂在中断处理函数里关闭发送/接收中断激活NAPI调度poll执行。poll中循环处理发送完成和接收数据直到预算耗尽或者无包可收后重新开启中断。这个机制看着普通但对驱动性能影响很大。你要合理设置weight参数比如100、200或者更大。weight越大单次poll时间越长但CPU占用也高。我通常的做法是根据实际吞吐测试结果调整以CPU占用不超标为前提尽量提高weight。还有个细节有些MAC控制器在收包时会自动禁用接收中断驱动如果忘了在poll中重新开启就会出现“网络死”的现象。我在自己的驱动里都是把“重新使能中断”放在poll函数的最后并加一个dummy read来保证寄存器写入顺序。3. 实际调试从寄存器到数据流的排错实战3.1 PHY 初始化与自协商状态机PHY的初始化不是简单的reset然后配置寄存器而是要理解PHY的状态机。PHY上电后通常处于ENERGY-DETECT状态不断探测介质是否有信号。当检测到对端设备时进入自协商状态交换能力信息最终确定速率和双工模式。驱动里需要确保在PHY完成自协商后再去配置MAC的速率和双工。如果MAC侧先配置了错误的速率即使PHY协商好了数据也发不出去。常见的做法是使用PHY驱动的adjust_link回调在link up时读取PHY的状态然后更新MAC的配置。另外自协商超时问题很常见。有些PHY的寄存器配置不当会导致自协商失败或者反复重启。调试时可以先用ethtool -s eth0 autoneg off speed 1000 duplex full强制固定速率确认链路是否能通再排查自协商。但要注意强制速率时MAC侧必须同步配置不能只改PHY。3.2 用Wireshark和抓包工具定位问题很多嵌入式工程师看不起抓包觉得嵌入式环境没有条件。其实现在的开发板大多有两个网口一个跑业务一个做管理或者用交换机镜像端口都能方便地抓包。在驱动调试阶段我强烈建议尽早接上抓包工具。当出现“ping不通”的情况先用Wireshark抓包看有没有请求发出。如果抓不到任何帧说明数据没有从MAC送出去问题可能在驱动或硬件如果能抓到请求但收不到应答说明请求到了对端对端的应答可能没回来或者我们的MAC没有收到如果收到了应答但协议栈没反应那可能是MAC地址、VLAN或者校验和的问题。我在调试一个工业网关时发现设备能被ping通但TCP连接建立失败。抓包发现SYN包发出后对端回了SYN-ACK但我们的设备没再发ACK而且不停地重传SYN。进一步查发现TCP校验和计算错误。原因是MAC硬件开启了TCP校验和卸载TX checksum offload但驱动没有正确设置sk_buff的ip_summed标志导致硬件计算的校验和覆盖了协议栈算好的值结果反而错了。把ip_summed设为CHECKSUM_PARTIAL之后一切正常。3.3 常见问题速查表我整理了一下这几年遇到的最多的以太网驱动问题做成表格方便大家对照排查。现象可能原因排查思路link up但ping不通MAC/PHY速度不一致或RGMII延时错误检查MAC和PHY速度寄存器调整RX/TX delay测试loopback能收到包但丢包严重DMA描述符不足或缓冲区被覆盖检查描述符环大小确认拥有权位处理正确多ring缓冲区传输速度只有100MPHY没有协商上千兆或线缆/接口问题用ethtool查看自协商结果强制千兆测试更换线缆TCP吞吐量极低中断频繁或TSO/GRO未开启开启NAPI确认ethtool -K支持TSO检查中断合并设备长时间运行后断网PHY热链接检测失效或看门狗超时实现PHY link状态轮询增加链路恢复流程发送方向正常接收方向不通接收DMA描述符不完整或接收中断未使能检查接收描述符初始化确认中断配置用loopback测试接收路径无法与特定设备通讯对端设备MAC地址过滤或协议不匹配抓包确认对端是否回包检查MAC地址表检查VLAN和协议字段这张表不可能是全的但覆盖了大部分初级问题。很多时候问题不在驱动本身而在硬件设计或者PHY配置所以在排查时要大胆假设小心验证。4. 工业场景中的以太网驱动与焊机等设备通讯的经验分享4.1 安川焊机以太网通讯的痛点最近一个项目里我需要让嵌入式主控通过以太网与安川焊机通讯实现焊接参数下发和状态读取。这类工业设备使用的以太网协议往往不是标准TCP/IP而是基于Ethernet/IP、Profinet或特定厂商私有协议。安川焊机有些型号支持TCP/UDP但通讯报文有特定的格式要求比如首尾字节固定、CRC校验、数据长度固定等。在这里驱动层面其实不需要做太多特殊事情因为TCP/IP协议栈已经替我们搞定了。真正麻烦的是应用层的协议解析和时序控制。但从驱动开发角度有两个点需要特别留意第一工业设备的以太网端口通常不响应ARP请求或者MAC地址过滤严格。如果主控通过MAC地址白名单方式连接设备那么驱动可能需要构造特殊的ARP包或者干脆不用ARP直接静态ARP表项。第二有些工业设备会在连接空闲时主动断开或者发送特定的“心跳包”。驱动和协议栈需要配合在socket层面保持连接。否则你会发现过一段时间TCP连接还在但数据已经发不过去了。另外工业现场电磁干扰严重网线很容易出现瞬断。此时PHY的link状态会反复变动。驱动要能快速感知link down并在link up后自动恢复。我的做法是用内核的PHY状态机注册phy_start()和phy_stop()流程配合PHY中断每次link变化都打印日志并通知网络协议栈执行重连。4.2 协议无关的驱动设计思路做嵌入式驱动有时会被要求适配多种不同的设备和协议。比如同样是焊接控制器有的用标准Modbus TCP有的用私有协议。驱动如果做得很死每个协议都要改一遍就会很痛苦。我的建议是在驱动层保持“协议无关”只负责把以太网帧正确地收发出去所有协议解析都放到上层应用。为此驱动需要提供干净的接口比如注册netdev_ops上层用socket访问而不是在驱动里解析业务报文。还有一点工业场景经常用到VLAN。比如一台设备同时连接办公网和工业网VLAN隔离可以防止广播风暴。驱动要支持VLAN offload和VLAN过滤。Linux内核有现成的ndo_vlan_rx_add_vid回调驱动只需要在寄存器中配置VLAN ID即可。我在开发支持多种工业协议的主控板时把驱动的重点放在稳定性和可配置性上。比如通过设备树参数配置MAC地址、PHY地址、VLAN ID、速率甚至中断触发方式。这样同一个驱动二进制就能适配不同的设备子型号节省了很多维护成本。4.3 关于Apple Mobile Device Ethernet的插曲最近热搜里有“apple mobile device ethernet下载”这个词一度让我很迷惑。后来才明白这其实是指苹果设备比如iPhone、iPad在连接电脑时通过USB拔号网络或者以太网适配器模拟出的一个网络接口。这个场景在物联网开发里也有价值比如你想用iOS设备与嵌入式主板通讯可以通过雷电转以太网适配器或者通过USB共享网络。从驱动开发的视角当你把苹果设备插入电脑系统会识别出一个“Apple Mobile Device Ethernet”设备这个设备本质上是一个USB网卡。它的驱动是苹果官方提供的在macOS和Windows上都有。对嵌入式开发者来说相关经验就是你的嵌入式设备如果支持USB gadget的RNDIS或者ECM协议也可以被电脑识别为一个虚拟网卡从而进行网络调试。但要注意苹果设备的以太网接口默认可能只支持特定速率和协议。所以如果你用自研的设备去跟苹果设备通讯最好先确认双方的USB以太网类兼容性特别是驱动中的描述符配置。这里就不展开细说了但至少说明以太网驱动并不局限于物理网口还包含USB虚拟网卡等形态。5. 驱动性能优化与稳定性保障5.1 吞吐量优化零拷贝与多队列当你的驱动能正常收发数据之后性能和稳定性就是下一步目标。在嵌入式平台上吞吐量的瓶颈往往不是网络带宽而是内存拷贝和中断开销。零拷贝是一个绕不开的话题。Linux协议栈的sk_buff本身支持headroom和frag机制驱动在接收数据时最好让DMA直接填充到sk_buff的数据区避免额外拷贝一次。发送方向则可以利用sendpage或者MSG_ZEROCOPY让协议栈的数据直接进入DMA描述符。多队列RSS/Flow PIR在高吞吐场景下很重要。如果MAC支持多队列你可以把不同数据流的包分配到不同的DMA通道和CPU核心极大提升并发处理能力。但嵌入式CPU核心数不多多队列也可能带来更多中断需要根据实际情况权衡。我在一个四核ARM平台上把单个队列改成双队列并绑定两个中断到不同的CPU核心吞吐量提升了约30%。代价是CPU占用率从60%升到了70%但整体吞吐从900Mbps提升到了1.2Gbps基于2.5G网口。所以多队列不是万能的但值得尝试。5.2 电源管理与链路检测嵌入式设备对功耗敏感网络驱动的电源管理往往容易被忽略。MAC和PHY通常都有低功耗模式但在进入低功耗前要确保没有未完成的DMA传输。否则数据写到一半设备睡眠醒来后描述符状态不一致就会导致驱动卡死。链路检测要尽量不依赖定时器最好用PHY中断。有些PHY支持活动中断和link状态变化中断驱动在link_change回调中执行相应操作。如果PHY不支持中断就只能周期性地读寄存器但轮询间隔不能太短建议2秒左右。太短会增加功耗太长则反应迟钝。我遇到过一个项目设备为了省电在空闲时关闭PHY但唤醒时总是出现第一次ping不通。后来发现唤醒后PHY的自协商需要几秒而网络协议栈已经在唤醒后立刻发起了ARP请求。解决方法是在驱动唤醒流程中等待PHY完成自协商后再上报__LINK_STATE_START或者通过netif_carrier_on()延迟上报link。5.3 长期稳定运行的注意事项嵌入式设备往往要求7x24小时运行驱动在这种环境下最容易出现的问题是内存泄漏和描述符耗尽。内存泄漏可能来自每个收包分发的缓冲区没有正确释放。我在检查一个老代码时发现接收路径中每次丢包都直接调用dev_kfree_skb_any()但有些分支没有释放导致内存缓慢增长。这类问题很难查需要借助kmemleak工具或者定期查看/proc/net/skbuff这样的信息。描述符耗尽也常见。比如发送路径中如果上层快速发送大量小包而驱动没有及时回收发送完成描述符环形队列会满导致NETDEV_TX_BUSY。解决方法是在发送的时候检查描述符是否够用不够用就停止发送队列等完成中断后重启队列。这个逻辑我每次都会认真检查因为一个简单的错误就会造成死锁。另外建议给驱动添加debugfs接口可以手动查看描述符环状态、PHY寄存器、中断统计。我在正式项目中一定会在debugfs里面放一个“手动触发link down再恢复”的测试入口方便生产测试和现场排查。这不难但对故障定位非常有帮助。结语最后分享一个我自己的习惯。每次写以太网驱动我都会先把PHY的寄存器表打印出来保存一份完整的状态基线。一旦后续出现通讯问题我可以快速对比寄存器值判断是PHY配置变了还是硬件链路有问题。这个方法帮我解决了不少“莫名其妙”的网络故障。如果你也是做嵌入式驱动开发的不妨试试。另外记得在驱动代码里加足够多的日志别嫌麻烦关键时刻就是这些日志救了你。