简介：面向嵌入式网络设备开发场景，这套源码资源聚焦RK3568处理器与YT9215交换机芯片的驱动程序适配，适用于从事Linux内核驱动、硬件接口调试的工程师学习参考。压缩包共2个文件，包含1个.c源文件和1个.h头文件，整体大小仅4KB；其中.c源文件主要实现设备初始化、数据收发与中断处理等驱动核心逻辑，.h头文件则定义驱动所需的结构体、常量与函数声明，两者配合构成一个精简可研究的驱动模块。目前已有5129人浏览学习，说明该主题在同类调试场景中有一定代表性。参照这两个文件，可梳理出从设备树描述、驱动注册到收发测试的完整思路。同时也能辅助定位硬件接口分析及驱动代码编写阶段的常见问题，为后续优化与维护提供直接参考。
1. RK3568 + YT9215 在做什么：从多网口需求到交换机芯片
一块 RK3568 的板子，原生网口通常只有两三个，而一台千兆交换机的需求往往起步就是四个千兆口起步，有的还要带光口或 PoE。与其换主控，不如在 RK3568 的 PCIe 或 SGMII 接口上外挂一颗 YT9215 交换机芯片，把网口数量一次性扩到五六个。方案听起来顺理成章，但真正把板子拿到手开始调的人都知道，这从来不是“插上就能用”的活。YT9215 不是普通 PHY，它是一颗带完整交换内核的芯片，上电后默认配置可能连 CPU 端口都不通，MDIO 读不到 ID、寄存器写不进去、内核里根本没有对应驱动，这才是常态。这篇文章要讲的，就是我在 RK3568 上把 YT9215 从头调到能跑满千兆的完整路径，适合正在做多网口网关、工业交换机或边缘计算底板的开发者，内容会一直写到验证工具和坑的解法。
2. RK3568 与 YT9215 的硬件链路：接口选型与上电检查
2.1 接口选型：SGMII、RGMII 还是 PCIe
RK3568 与 YT9215 之间的连接方式，决定了我后续所有调试路径的走向。常见的接法有三种：SGMII、RGMII 和 PCIe。YT9215 这类交换芯片通常带有多个 SerDes 通道，通道可以被复用成 SGMII 接口连接主控，也可以配置成 PCIe RC 模式或者作为 PCIe EP 被主控枚举。硬件设计阶段选哪种，直接决定驱动方式是把它当普通 PHY 用，还是当 PCIe 交换机用。
我一般会优先选 PCIe，原因很实际。RK3568 原生 PCIe2.0 控制器打开后，YT9215 会被识别成一个 PCIe 设备，Linux 自带的 switchtec 或者 mdio 触达方式更灵活，吞吐量上限也高，SerDes 跑 5Gbps 跑满千兆毫无压力。如果板子上 PCIe 通道已经被 NVMe 或 Wi-Fi 占用，那就退一步用 SGMII，把 YT9215 接到 RK3568 的 GMAC 控制器上，让 Linux 把它当作一个“带内部交换功能的 PHY”。RGMII 是最后的选择，16bit 数据线布线要求高，频率跑不上 1000Mbps 以上速率，只适合低成本的百兆场景。
选型这件事上踩过的最大一个坑，是把 PCIe 通道复用当成理所当然。RK3568 的 PCIe2.0 控制器和 SATA、USB3 之间本身就存在引脚复用，硬件工程师如果没在原理图阶段确认引脚的 mux 配置，板子回来之后 PCIe 怎么都枚举不到。软件上可以通过修改 pinctrl 节点做尝试，但如果硬件上已经走线错误，系统端是无能为力的。
2.2 上电前的硬件检查：先量电压再做时钟测量
很多 YT9215 调不通的案子，根因并不在软件，而是硬件细节不规范。YT9215 这类交换芯片比普通 PHY 复杂，供电通常有 1.0V 核心电压、1.8V 和 3.3V 三个域，而且对上下电时序敏感。拿到板子第一步，我习惯用示波器同时测三路电源的上升沿，确认 1.0V 不要比 3.3V 先掉电。这个看似玄学的问题，实际导致的典型故障是芯片经常第一次能工作、重启后失联，而且用万用表量电压全是正常的，不加示波器根本发现不了。
之后必须测量 YT9215 的时钟输入。25MHz 参考晶振是这颗芯片正常工作的基础，测的时候不要只看有没有波形，要关注频率偏差，超过 50ppm 的信号会影响 SerDes 的位同步，表现为主控侧链路反复 training 失败。另外一个容易被忽略的是复位引脚的上电释放时间，YT9215 的复位释放要晚于所有电源稳定至少 10ms，很多 ARM 板上的 GPIO 复位是系统起来之后才拉高，导致第一次上电时芯片复位释放时电源还没完全稳定，后续初始化一团糟。
硬件检查做完后，我习惯在 uboot 阶段先做一个最基础的探测。如果走的是 PCIe 连接，在 uboot 命令行里直接执行 pci enum，然后查看设备树中 PCIe 控制器是否识别到了设备。如果 VENDOR ID 读出来是 0xFFFF，说明物理链路就有问题，这时候我会直接量 SerDes 的差分信号是否在输出，排除主控侧 PCIe 控制器没有正常 link up 的情况。
Rockchip U-Boot> pci enum Rockchip U-Boot> pci 0执行后如果没有任何设备号显示，把 dmesg 打开看 PCIe 控制器报错信息，重点找 PHY PLL lock 失败和 LTSSM 状态的打印。LTSSM 停在 Detect 状态基本就是时钟或复位问题，停在 Configuration 之前的状态，则大概率是 SerDes 通道配置不一致。
2.3 用 devmem 验证 YT9215 是否在总线上可见
在 Linux 系统起来之后，第一件事不是急着配置 switch，而是确认 YT9215 在地址空间里可访问。PCIe 连接的情况下，查看 /sys/bus/pci/devices/ 目录下多没多设备，再用 setpci 看配置空间里的 VENDOR ID 和 DEVICE ID。
root@board:/# ls /sys/bus/pci/devices/ 0000:01:00.0 root@board:/# setpci -s 01:00.0 vendor_id如果读到 ID 正常，说明物理链路已经打通了。这时候直接读写 YT9215 的寄存器空间，还是借道 PCIe config space 或者是 BAR 空间映射，取决于这颗芯片的设计。常见做法是 YT9215 会提供一块内部寄存器映射，通过 PCIe BAR0 窗口暴露给主控。可以用 devmem 把 BAR0 的地址映射出来，直接读芯片的 ID 寄存器验证访问通路。
root@board:/# setpci -s 01:00.0 base-address-0拿到 BAR0 的物理地址之后，用 devmem 读芯片内部基地址偏移处的 chip ID 寄存器。如果读出来的值和 datasheet 里写明的一致，说明从主控到芯片的访问通路完全正常，接下来才有必要继续做 PHY 的配置。如果 devmem 读出来是空或者全 F，那就意味着 BAR 窗口没有正确映射，先回头查 PCIe 的 memory space 分配是否正确。
3. 把 MDIO 和 PHY 状态打通：最小驱动加载路径
3.1 最小驱动加载路径：从设备树描述一张外挂设备
YT9215 在 Linux 下没有现成驱动的概率很高，内核 mainline 未必会收录这颗芯片的完整 switch 驱动。常见做法是把它当作普通的 MDIO 设备来描述，让 Linux 的 MDIO 总线框架管理起来，再由用户态工具直接操作寄存器，完成核心的配置工作。
在设备树里，我一般会在 GMAC 节点下面挂一个 mdio 子节点，然后描述这颗 PHY。这种描述方式的最大价值在于让内核的网络子系统认为这个端口上连着一个 PHY，从而 eth0 这个网络设备能正常 up，后续 MDIO 的访问路径也是通的。设备树描述示例如下：
&gmac0 { status = "okay"; phy-mode = "sgmii"; mdio0: mdio { compatible = "snps,dwmac-mdio"; #address-cells = <1>; #size-cells = <0>; switch_phy: ethernet-phy@1 { reg = <1>; compatible = "ethernet-phy-id1234.5678"; }; }; };这里的 phy-mode 根据实际硬件连接方式填写，如果走的是 PCIe 连接，就不需要这个描述，直接用 PCIe 驱动去枚举。ethernet-phy@1中的 reg 是 YT9215 在 MDIO 总线上的物理地址，这个地址取决于硬件上 PHYAD 引脚的上下拉配置，不能随意修改，否则驱动会 probe 不到设备。compatible里的 ID 号要和 YT9215 的实际 PHY ID 对应起来，大部分人这一步会卡住，因为芯片里的 PHY ID 和 datasheet 上写的不完全一致，最稳妥的办法是先用 MDIO 工具读寄存器把 ID 算出来再填。
设备树配好之后，内核启动日志里如果能看到 MDIO bus 上发现了一个 PHY，说明内核已经识别到设备。这时候 eth0 可能还没有 IP，但链路状态应该可以从 down 变成 up。当然，YT9215 有多组 SerDes 和多哥 PHY 端口，需要在 mdio 节点下重复挂多端口描述，后续每个对外网口才能有对应的 net_device。
3.2 用 mdio-tools 直接验证 PHY 寄存器
内核识别之后，不要急着写驱动逻辑，先用 mdio-tools 手动读一遍寄存器。mdio-tools 是 mdio 读写工具集的常见实现，一般在 buildroot 里勾选就能编译进去。如果系统里没有，直接用 busybox 自带的 mdio 命令也可以，只是功能略少。我用的是 mdio-tools 的 mdio read 和 mdio write，命令直观，适合一步一步踩。
先读 PHY ID 寄存器组，标准 PHY 的 ID 寄存器的地址是 2 和 3。执行命令之后，把两个寄存器读取的值拼起来，得到的是一个 32 位 PHY ID。
root@board:/# mdio read eth0 1 2 0x1234 root@board:/# mdio read eth0 1 3 0x5678读出来的 ID 值和 datasheet 里标准的 OUI 对照，确认这颗 PHY 在内核的 PHY ID 列表里有没有被定义。通常 YT9215 这种交换芯片内部的 PHY 核心 ID 是已知的，但也不排除芯片厂家用的自定义 ID，这种情况下要把 compatible 换成实际读到的数字，否则驱动 probe 不了。之后读寄存器 0（BMCR）和寄存器 1（BMSR），看它们的默认值是否和 reset 后的状态一致。
root@board:/# mdio read eth0 1 0 0x1140 root@board:/# mdio read eth0 1 1 0x796dBMSR 寄存器里的 bit5 表示 autoneg complete，bit2 表示 link status。如果读出来 link 状态位为 0，表示物理层没有检测到对端，这并不一定是坏事，因为 YT9215 的某些 SerDes 端口在默认配置下是处于低功耗或未启用状态的。此时可以尝试手动配置 BMCR 寄存器，强制 1000Mbps 全双工，再读 BMSR 确认链路是否能起来。
3.3 驱动加载失败时的三处关键日志
如果 mdio read 命令执行不了，或者 PHY ID 读出来全是 F，大概率是内核网络设备没有真正起来。这时候我会按顺序排查三处日志。
首先是 dmesg 里和 stmmac 或 dwmac 相关的行。RK3568 的 GMAC 驱动是 stmmac 框架，日志里会打印 phy mode、MDIO 时钟频率、初始化状态。如果打印显示 MDIO 时钟配置失败，检查设备树里 mdio 子节点的时钟属性，通常需要显式指定 MDC 的频率上限，否则总线的时序和 YT9215 不匹配。
其次是 /sys/class/net 目录下有没有出现对应的 ethX 设备。如果设备树里 GMAC 节点状态没有改为 okay，整个 MAC 控制器都不会 probe，自然没有网络接口。这个低级问题出现的频率比想象中高，很多时候是设备树 overlay 没有正确加载。
最后是 interrupts 相关的报错。YT9215 的 interrupt 引脚如果接到 RK3568 的 GPIO 上，设备树里必须配置正确的中断号和触发方式。中断配置错了，表现为链路状态变化时内核不感知，即使物理连接恢复了，网络接口依旧显示 down，这种问题非常容易让人困惑，看起来像硬件坏了，实际只是内核没有收到中断。
4. 让数据从网口真正走到 CPU：PCS 环回与转发配置
4.1 先做 PCS 环回：把物理链路的锅关掉
当 PHY 层已经能正常 link，但 ping 不通的时候，先别急着查转发逻辑，在第一层做环回测试是最快的隔离手段。YT9215 这类芯片内部支持 PCS 层的环回，把从主控 MAC 发出的数据在芯片内部直接环回到 MAC 接收侧。这一步通过 MDIO 写一个特定寄存器，不需要外部接网线就能验证主控到芯片之间的通路是否正常。
root@board:/# mdio write eth0 1 0x8000 0x0040这个操作的实质是设置 MII 控制寄存器里的 loopback 位。配置完之后，从 eth0 ping 一个指定 IP 地址，比如 192.168.1.1，如果在环回模式下能 ping 通，说明以太网 MAC 到 YT9215 的 SerDes 通路是完好的。如果 ping 不通，问题就出在 RK3568 的 GMAC 控制器配置或者 DMA 描述符链上，没必要去查后续的交换逻辑。
PCS 环回测试通过后，立即把环回位清除，避免后面调试时数据平面被干扰。环回测试的另一个变种是 MAC 层的环回，通过 RK3568 的 GMAC 控制器本身的 loopback 功能来做。两者可以结合使用，出现问题时能快速确认是主控侧的问题还是 YT9215 侧的问题。我在实际调试中最怕的就是这两层问题交织在一起，不做好环回隔离，后面查 VLAN 和转发配置时很容易被底层链路问题误导。
4.2 转发路径与 CPU 收包：寄存器级最小配置
YT9215 默认状态下，各端口之间未必自动转发，CPU 端口更是需要显式配置。要把数据从某个 LAN 口送到主控的内核协议栈，必须做两件事：让 CPU 端口成为交换矩阵的成员端口，并且配置 VLAN 和端口成员关系。
YT9215 的寄存器空间里有一组端口控制寄存器，我用 MDIO 写的方式逐一配置端口使能和端口模式。常见配置是把所有端口设为千兆全双工，同时使能 802.1Q 的 VLAN 感知功能。最小化的配置是把所有 LAN 口划入同一个 VLAN ID，比如 VLAN 1，CPU 端口也加入这个 VLAN，这样从 LAN 口收到的 untagged 数据帧会被打上 VLAN 1 的标签并转发到 CPU 端口。
root@board:/# mdio write eth0 1 0x2010 0x000F root@board:/# mdio write eth0 1 0x2014 0x0008这两条命令分别配置了端口使能位和 VLAN 成员表。寄存器地址的偏移量每颗芯片略有差异，我这里写的地址是 YT9215 一类芯片的常见布局，实际使用时要以 datasheet 的寄存器偏移为准。这一步最容易翻车的地方，就是把 CPU 端口的标签位配错。有些交换芯片要求 CPU 端口收上来的帧带一个自定义的 tag，不配置这个 tag 识别规则，CPU 收到帧后会被网卡驱动当成错误帧丢掉。
配置完成后，用 tcpdump 在 eth0 上抓包，从某个 LAN 口接一台 PC 发 ping 包。tcpdump 如果能收到 ICMP 请求帧，说明转发路径已经通了。如果只能收到广播帧但收不到单播帧，通常是 VLAN 设置里端口间的单播地址学习没有打开，需要查地址学习相关的寄存器。
4.3 软件转发还是硬件转发：DSA 与普通 PHY 的选择
YT9215 在 Linux 里的角色定位会影响后续开发的复杂度，是把整颗芯片当作一个 DSA switch 接入内核，还是简单地当作多路 PHY 来使用，这是需要权衡的。
DSA 方式能让 YT9215 的各个端口在 Linux 里分别显示为独立的网络接口，比如 lan1、lan2、wan，每个口可以独立配置 IP、防火墙、流量策略，内核的 bridge、VLAN 子系统天然适配。但 DSA 驱动要求芯片的寄存器接口符合 Linux 的 dsa_switch_ops 定义，YT9215 如果没有现成的 DSA 驱动，就需要自己实现一套 port_vlan_add、port_stp_state_set 等回调函数，工作量不小。
另一种思路是把 YT9215 当作一个多端口的 PHY 组，所有 LAN 口在硬件上直接做二层转发，CPU 端口收到的数据全部进 eth0，再由软件做路由或桥接。这种模式适合流量不需要在单个端口之间做硬件隔离的场景，配置量小，但缺点是 VLAN、速率控制、端口统计相关的功能都要自己去写寄存器操作。我在网关类项目里通常会选择 DSA 方式，因为后续维护功能时，内核的标准接口能省下大量代码和时间。如果只是要快速出一个 Demo 验证硬件，选择后者更快落地。
5. 避坑：调试 YT9215 时最容易翻车的五个点
5.1 复位引脚释放时序不对导致设备偶发失联
现象：板子第一次上电能识别到 YT9215，但软件重启之后设备经常消失，必须彻底断电再上电才能恢复。有少数板卡表现为温度降低后概率明显上升，看起来非常像硬件虚焊。
原因：YT9215 的复位释放时序要求比普通 PHY 严格。系统复位时 GPIO 拉高的时间如果在电源电压还没完全稳定的窗口内，芯片内部逻辑可能进入不可恢复状态，PCIe link training 永远失败。软件重启不触发大电容完全放电，所以每次软复位都在赌时序恰好正确。
解决：把复位控制从默认的 GPIO 操作改到硬件复位芯片上，或者在设备树里通过 pinctrl 控制复位引脚，确保复位引脚默认拉低、系统启动后期再拉高。更稳妥的办法是在驱动里加上一段延时操作，从复位释放到访问芯片寄存器之间至少留 100ms 的等待时间。
5.2 MDIO 读到的 PHY ID 全是 0xFFFF
现象：mdio read 命令执行正常，但读 PHY ID 寄存器返回的结果全部是 0xFFFF，而且读取没有任何报错提示。设备树里无论怎么写 reg 都无法读到有效 ID。
原因：这个现象通常不是 MDIO 总线故障，而是 MDIO 地址根本没有映射到正确的 PHY。YT9215 有多个内部 PHY，每个 PHY 都有一个独立的 MDIO 地址，地址由芯片外部引脚配置。读 0xFFFF 意味着该地址上没有任何 PHY 响应，或者 MDIO 控制器时钟配置太快，芯片来不及在规定的时序窗口内回复。
解决：先用逻辑分析仪抓 MDIO 波形，确认 MDC/MDIO 信号确实有活动。然后检查设备树里 MDIO clock 频率，许多 RK3568 方案的默认配置是 2.5MHz，如果 YT9215 要求 2.0MHz 以下，就会偶发读不到数据。最后核对板卡原理图上 PHYAD 引脚的连接，是否存在浮空或者接错的情况。
5.3 CPU 端口能收到广播却收不到单播
现象：从 PC 连续 ping 板卡 IP，tcpdump 在 eth0 上只能看到 ARP 请求，看不到 ICMP echo 帧。同一时刻，PC 上的 ARP 表里板卡地址的状态是 incomplete。
原因：这是典型的地址学习表问题。YT9215 的端口之间默认可能禁用 MAC 地址学习，或者学习到的地址表项没有自动老化刷新。CPU 端口的单播转发依赖 FDB 表项，而 FDB 表项需要交换芯片在收到源地址时更新。地址学习被关掉，单播帧就无法反向查找端口，只能被丢掉。
解决：找到地址学习控制寄存器，显式使能所有端口的学习功能。同时确认发货缺省配置里 FDB 的静态表项没有被设置成错误的手动绑定。如果学习和老化都正常但依然丢单播，查一下端口之间是否存在 STP 状态位被设为 blocking，也会产生同样的症状。
5.4 VLAN 标签在 CPU 端口上未被剥离
现象：eth0 抓包能看到 VLAN ID 存在但板卡不能访问外部网关。内部 LAN 口之间互通正常，但只要涉及 CPU 收发的数据就全部异常，tcpdump 里能看到大量的 vlan 100 标签。
原因：交换芯片把从 LAN 口进入的 untagged 数据自动打上了 PVID，转发到 CPU 端口时帧完整保留了这个 tag。但 RK3568 的 stmmac 驱动默认没有启用 VLAN 处理，接收到带 tag 的帧后，要么错误地提交到协议栈后被丢弃，要么直接在硬件层过滤掉。
解决：配置 CPU 端口为 tag 剥离模式，所有发往 CPU 的帧由芯片先去 tag。或者反过来，在内核里把 eth0 的 vlan 接收功能显式打开，用 vlan 子接口去匹配对应的 VID。我通常推荐前者，改动只涉及一组寄存器，而且对系统路由的影响最小。
5.5 吞吐量只有百兆，但链路显示 1000Mbps
现象：链路协商是千兆全双工，但通过 iperf3 测速稳定在 95Mbps 左右，而且无论换 PC 换网线结果都一样。CPU 占用率不高，网卡 ethtool 统计没看到大量丢包。
原因：这种情况基本可以断定是 SerDes 的工作模式配置问题。YT9215 的某些 SerDes 通道被复用成千兆接口时，如果对应寄存器没有设置成正确的速率匹配组，物理层会在协商时撒谎，报告千兆但实际上内部串口跑在百兆速率。另一个常见诱发点是 PCB 上的差分走线阻抗严重不匹配，但一般硬件评审会挡掉这种问题，软件配置出错更常见。
解决：把涉及 SerDes 速率匹配的寄存器全部重读一遍，重点看强制速率位和 auto-neg 配置位的组合是否合法。不要只依赖 ethtool 的协商结果，用 iperf3 打流做实测，通过不同速率下的吞吐对比来判断 SerDes 配置是否生效。
6. 把链路质量钉死：iperf3 与 tcpdump 的组合验证
6.1 一次完整的链路验证流程
配置完成后，单纯 ping 通并不能说明系统能长期稳定运行。我会用 iperf3 做双向打流验证，同时配合 tcpdump 抓包确认转发路径中不存在隐藏的重传或乱序。先做单方向的 TCP 打流，再做双向同时打流，这一步能暴露交换芯片缓冲区在拥塞场景下的行为。
root@board:/# iperf3 -s & root@board:/# iperf3 -c 192.168.10.1 -t 60 -P 4在打流过程中，tcpdump 的统计结果能清楚看到每个 5 秒窗口里的重传数和乱序包数量。这个数值在空闲系统里应当接近零，如果持续增长，基本可以判断交换芯片的队列管理策略有问题，或者 CPU 端口描述符缓冲区太小。通过 ethtool 查看网卡错误计数，也能快速区分是 MAC 层问题还是交换芯片转发能力问题。
6.2 中断绑核与系统级调优的边界
RK3568 是四核处理器，网络中断默认可能落在 CPU0。当批量转发同时还有业务进程运行时，CPU0 容易成为瓶颈。通过 /proc/irq 接口把网卡中断绑到 CPU2 或 CPU3 上，配合 RPS（Receive Packet Steering）进一步分散软中断负载。但要清醒认识一个边界：YT9215 的硬件转发能力远超 RK3568 的软件处理能力，在千兆模式下 CPU 是瓶颈而不是交换芯片，所以系统调优能改善的幅度是有限的。
做完吞吐验证和中断绑定之后，系统才算真正达到了交付状态。我记得第一次在模拟项目X上把 YT9215 彻底调通那天，结果反而没有想象中兴奋，因为整个调试过程中反复出现的都是这些小问题——时序、地址、标签剥离，没有一项涉及高深技术，但每一项都足以卡住一两天。从那以后我的习惯变了，拿到板子先做硬件清单核对，再写驱动，顺序绝不调换。
这套方法在后续几个项目上一直沿用，希望能帮到你。
本文还有配套的精品资源，点击获取
