RK3568 u-boot网络单向不通：PHY协商与RGMII时序调试指南-开发者社区

1. 问题场景与排查起点：当开发板与PC“失联”

在嵌入式开发，尤其是基于瑞芯微RK3568这类高性能平台进行系统移植时，网络调试是贯穿始终的生命线。u-boot阶段能正常联网，意味着我们可以通过TFTP快速加载内核与设备树，通过NFS挂载根文件系统，极大提升开发效率。然而，一个令人头疼的经典问题就是：在u-boot命令行下，使用ping命令测试与同一局域网内PC的连通性时，发现开发板可以收到PC的回复（PC能ping通开发板），但开发板发出的ping请求却石沉大海，无法ping通PC。

这不仅仅是“网络不通”那么简单。如果完全不通，那可能是物理层或基础IP配置问题。但这种“单向通”的诡异现象，往往把开发者引向防火墙、ARP表等上层问题的排查，浪费大量时间后才发现症结在更底层。最近在调试一块自研的RK3568板卡时，我就再次踩进了这个坑。板子启动后，u-boot能正确获取IP（DHCP或静态设置），ethaddr（MAC地址）也已配置，用PC去ping开发板的IP，回复正常。但一旦在u-boot下执行ping 192.168.1.100（PC的IP），永远都是host 192.168.1.100 is alive的假成功，或者直接超时，根本无法触发真正的ICMP请求交互。

这种问题的隐蔽性在于，它容易让人怀疑是Windows防火墙、交换机设置甚至是网线问题。但在排除了这些因素后，我们需要将目光聚焦回u-boot本身和RK3568的硬件设计上。结合过往经验和网络上的相关讨论（例如围绕rk3568 defconfig配置、设备树等关键词的线索），问题的根源很可能出在网络PHY芯片的初始化配置，特别是与自动协商（Auto-Negotiation）和接口模式相关的设置上。这不仅仅是RK3568的问题，而是所有使用千兆以太网PHY的嵌入式平台在u-boot阶段都可能遇到的“坑”。

2. 核心疑点分析：为什么是“单向不通”？

要解决问题，必须先理解“单向不通”背后的网络通信原理。一个完整的ping（ICMP Echo Request）流程，简化来看需要两步：首先，发送方需要知道接收方的MAC地址，这通过ARP协议完成；其次，组装包含正确源/目的IP和MAC地址的数据包并发送。

当开发板（u-boot）ping PC时：

ARP请求：开发板广播：“谁的IP是192.168.1.100？请告诉MAC地址。”
ARP回复：PC收到广播，回复：“我是192.168.1.100，我的MAC是XX:XX:XX:XX:XX:XX。”
ICMP请求：开发板用PC的MAC地址封装ICMP Echo Request包，发送给PC。
ICMP回复：PC收到后，回复ICMP Echo Reply包给开发板。

如果PC能ping通开发板，说明物理链路、开发板的IP层和基本的收包功能是正常的。但开发板ping不通PC，则意味着上述流程在1、2或3步出现了问题。

一种常见假象是，u-boot的ping命令实现可能比较“简陋”，它有时会直接用缓存中的ARP条目，或者在没有收到ARP回复时也显示“alive”。但这只是表象。更本质的原因，尤其是在千兆网络环境下，通常指向链路层（Layer 2）的状态。百兆网络（10/100M）通常使用4根线（1,2,3,6），而千兆网络（1000M）需要使用全部8根线，并且协商机制复杂得多。如果PHY芯片没有正确完成千兆模式的自动协商，它可能错误地停留在百兆模式，或者协商到了一个不稳定的状态（例如，协商成了半双工）。在这种情况下，链路虽然被激活（link up），物理上也能传输一些简单的数据帧（如PC发来的ARP Reply或Ping Reply），但对于u-boot驱动或PHY本身来说，可能无法正确处理特定速率或双工模式下的发送逻辑，导致发送出的ARP Request或ICMP Request包格式异常或根本无法发出。

因此，我们的排查重点就从“为什么ping不通”转变为“u-boot下，RK3568的千兆网络PHY初始化是否正确完成了千兆模式的协商？”。这需要深入到驱动和设备树的配置中寻找答案。

3. 深入RK3568网络驱动与设备树配置

RK3568的以太网控制器（通常是GMAC）需要通过一个外部的PHY芯片（如裕太微YT8531、瑞昱RTL8211F等）来连接物理网线。u-boot中的网络驱动栈大致分为三层：网络协议栈（处理IP、ICMP、ARP）、MAC控制器驱动（通常是DesignWare GMAC）、以及PHY驱动（通过MII/ RGMII接口管理PHY芯片）。

问题的关键往往在PHY驱动部分的初始化序列。在u-boot中，PHY的初始化通常遵循以下流程：

复位PHY。
等待自协商完成。
从PHY的特定状态寄存器中读取协商结果（速度、双工模式）。
根据协商结果，配置MAC控制器的RGMII/SGMII接口时序参数（如TX/RX delay）。

在RK3568的u-boot源码中，PHY的配置信息主要藏在两个地方：defconfig和设备树（Device Tree）。

3.1 检查`defconfig`中的PHY驱动编译选项

首先，确保你使用的u-boot配置（例如rk3568_defconfig）包含了正确的PHY驱动。使用命令make menuconfig或直接查看.config文件：

grep PHY .config

你需要找到类似于CONFIG_PHY_ROCKCHIP_INNO_USB2=y或CONFIG_PHY_ROCKCHIP_NANENG_COMBOPHY=y的选项，但这些是USB PHY。以太网PHY的配置通常是这样的：

CONFIG_PHY_REALTEK=y # 或者 CONFIG_PHY_YT8531=y # 或者 CONFIG_PHY_VITESSE=y

具体取决于你的板卡使用的PHY芯片型号。如果对应的PHY驱动没有被编译进u-boot，那么网络初始化必然会失败。这是最基础的检查点。网络上提到的“rk3568 defconfig配置不编译buildroot”虽然主题不同，但提醒了我们配置的重要性。

3.2 详解设备树中的网络节点配置

设备树是描述硬件的关键。RK3568平台网络相关的设备树节点通常位于arch/arm/dts/rk3568-xxx.dtsi或板级DTS文件中。我们需要关注两个节点：gmac0或gmac1（以太网控制器）和mdio0（管理PHY的MDIO总线）。

一个典型的配置示例如下：

&gmac0 { phy-mode = "rgmii"; clock_in_out = "output"; snps,reset-gpio = <&gpio2 RK_PD3 GPIO_ACTIVE_LOW>; snps,reset-active-low; /* 复位时间，单位毫秒 */ snps,reset-delays-us = <0 20000 100000>; assigned-clocks = <&cru SCLK_GMAC0_RX_TX>, <&cru SCLK_GMAC0>; assigned-clock-parents = <&cru SCLK_GMAC0_RGMII_SPEED>, <&cru CLK_MAC0_2TOP>; assigned-clock-rates = <0>, <125000000>; pinctrl-names = "default"; pinctrl-0 = <&gmac0_miim &gmac0_tx_bus2 &gmac0_rx_bus2 &gmac0_rgmii_clk &gmac0_rgmii_bus>; tx_delay = <0x30>; rx_delay = <0x10>; phy-handle = <&rgmii_phy0>; status = "okay"; }; &mdio0 { rgmii_phy0: phy@0 { compatible = "ethernet-phy-ieee802.3-c22"; reg = <0x0>; /* 一些PHY可能需要特定的厂商兼容字符串，例如： compatible = "ethernet-phy-id001c.c916", "ethernet-phy-ieee802.3-c22"; */ }; };

这里有几个致命陷阱点，直接关系到千兆协商是否正常：

phy-mode与clock_in_out：
- phy-mode = "rgmii";表示使用RGMII接口，这是百兆/千兆PHY的常见接口。确保它与PHY芯片支持的接口模式一致。
- clock_in_out = "output";表示GMAC向PHY提供125MHz的参考时钟。有些PHY方案可能需要设置为input，即PHY向GMAC提供时钟。这个配置错误会导致链路无法建立或协商速率异常。
tx_delay和rx_delay（RGMII时序参数）：这是千兆网络调试中最棘手的部分之一。RGMII接口为了在125MHz时钟下传输数据，引入了延迟调整（Delay）机制。tx_delay和rx_delay的值需要根据PCB布线长度和PHY芯片特性进行微调。值不正确，可能导致数据采样错位，表现为网络不稳定、丢包严重，甚至就是我们遇到的“单向不通”。原厂SDK或参考设计通常会给出一个经验值，但这不一定适合你的板卡。
PHY芯片的compatible属性：如果compatible字符串不准确，u-boot可能无法加载正确的PHY驱动，或者驱动使用了默认的不合适的初始化序列。务必核对PHY芯片的数据手册，使用最精确的兼容字符串。例如，对于裕太微YT8531，可能需要"ethernet-phy-id0000.0a00"这样的ID。
复位引脚与时序：snps,reset-delays-us = <0 20000 100000>;这三个值分别代表：复位信号拉低后的保持时间、释放复位后到开始MDIO操作前的等待时间、再次操作前的等待时间。时间太短，PHY可能还未准备好，导致初始化失败。

4. 动态调试与诊断：在u-boot中获取关键信息

当修改设备树后，重新编译并烧写u-boot，问题可能依旧。这时，我们需要在u-boot命令行中动态地获取信息，进行诊断。

检查网络初始化信息：在u-boot启动时，观察串口日志。成功初始化会打印类似信息：
```
eth0: ethernet@fe010000 Waiting for PHY auto negotiation to complete...... done Link is Up - 1000/Full - flow control rx/tx
```
重点关注“Link is Up”后面的速率和双工模式。如果显示100/Full甚至10/Half，那说明协商未成千兆。如果根本没有“Link is Up”的日志，说明链路未建立。
使用mii和mdio命令手动诊断PHY： u-boot通常内置了mii命令，可以直接读写PHY寄存器，这是最强大的调试手段。
- 查看基本控制/状态寄存器：
```
=> mii device List of available MII devices: 'eth0' at address 0 => mii info eth0 PHY 0x00: OUI = 0x001C, Model = 0x16, Rev = 0x00, 1000baseT, FDX
```
  这可以确认PHY是否被正确识别。
- 读取关键状态寄存器：读取BMCR（基本模式控制寄存器，地址0）和BMSR（基本模式状态寄存器，地址1）：
```
=> mii read eth0 0 0x1140 => mii read eth0 1 0x796d
```
  需要查阅PHY芯片手册来解析这些值。通常，BMSR的bit5（Auto-negotiation complete）和bit2（Link status）是否为1，表示自协商完成且链路已建立。
- 读取自协商结果寄存器：对于千兆PHY，需要查看自协商扩展寄存器（如地址9或10）。例如，读取RTL8211F的寄存器10（PHY Specific Status Register）：
```
=> mii read eth0 10
```
  通过手册解析，可以确认实际协商到的速度（1000M/100M/10M）和双工模式。
手动配置PHY（绕过自协商）：如果怀疑是自协商问题，可以尝试强制设置PHY的速率和双工模式。注意：这只是一种调试手段，强制模式可能和交换机不匹配导致问题。
- 强制设置为1000M全双工（假设PHY支持）：
```
=> mii write eth0 0 0x0140 # 写入BMCR， bit12=1 (1000M), bit8=1 (Full duplex)， 并禁用自协商(bit12=1时，bit9=0?) => mii write eth0 0 0x2140 # 更常见的写法： bit6=1 (复位)，先复位 => mii write eth0 0 0x0140 # 再写入配置
```
  重要提示：强制设置的寄存器值和具体PHY芯片强相关，必须严格参照数据手册操作。错误的强制设置可能损坏PHY或导致通信完全失败。

5. 解决方案二：调整RGMII时序延迟参数

如果通过上述诊断，确认链路已建立但协商模式正确（显示1000/Full），问题依旧，那么最可能的“凶手”就是设备树中tx_delay和rx_delay的时序参数。这两个参数影响数据（TXD/RXD）相对于时钟（TX_CLK/RX_CLK）的偏移量。

为什么时序不对会导致“单向不通”？想象一下，发送数据时，如果TX_Delay设置过小，数据信号的变化可能早于时钟信号的边沿被对端PHY采样，导致采样到错误的数据位。在复杂的千兆通信中，这可能使得整个以太网帧的CRC校验失败，被对端直接丢弃。而接收方向，由于时钟来自对端，延迟参数的容错性可能稍好，因此PC发来的包开发板可能还能偶然正确接收。这就完美解释了“单向通”的现象。

如何调整？

获取参考值：首先使用原厂SDK或硬件设计提供的默认值。
系统化测试：准备一个固定的网络环境（开发板直连PC或支持千兆的交换机），PC上持续ping开发板（ping -t 开发板IP），同时在u-boot下尝试ping PC。观察PC端是否丢包，以及u-boot端是否成功。
调整策略：
- tx_delay主要影响发送。如果开发板发不出包，优先调整它。每次调整步进为0x05或0x10（十六进制）。范围通常在0x00到0x7F之间。
- rx_delay主要影响接收。如果PC ping开发板也丢包严重，则需要调整它。
- 修改设备树源文件（.dts或.dtsi）中的对应值，重新编译u-boot并烧写测试。
组合测试：这是一个需要耐心的过程。记录下每一组(tx_delay, rx_delay)值的测试结果。一个常见的经验是，对于RK3568平台，某些PCB设计下，tx_delay在0x30附近，rx_delay在0x10到0x20之间可能工作良好，但这绝非定论。

在我的实际案例中，最初使用的是参考设计的tx_delay = 0x30; rx_delay = 0x10;。现象是PC能ping通板子，但板子ping PC全部超时。通过mii命令确认PHY协商为1000M全双工。于是我将tx_delay调整为0x40，重新测试，发现u-boot下ping PC的成功率从0%提升到了约30%，但仍有大量丢包。继续调整至tx_delay = 0x50，成功率达到了90%以上。最终，结合rx_delay微调到0x15，实现了双向100%稳定的千兆ping通。

注意：时序参数的调整没有银弹，严重依赖于具体的PCB layout、PHY芯片型号、甚至电源质量。务必进行充分测试，包括大文件传输（如通过TFTP），以验证链路的长期稳定性。

6. 进阶排查：电源、时钟与PCB设计隐患

如果调整了所有软件参数问题依旧，就必须将怀疑目光投向硬件。

电源完整性：千兆PHY和GMAC对电源噪声非常敏感。确保PHY芯片的模拟电源（AVDD）和数字电源（DVDD）都按照数据手册要求，进行了充分的滤波（使用磁珠和去耦电容）。可以使用示波器测量电源引脚上的纹波，过大的纹波会导致PHY工作异常。
时钟质量：提供给PHY或由PHY反馈给GMAC的125MHz时钟信号必须干净、稳定。检查时钟电路（晶振或时钟发生器）的布局和滤波。时钟抖动过大会导致数据采样错误。
PCB布线：RGMII接口属于高速信号（125MHz时钟，数据在上下边沿都采样，等效速率250Mbps）。必须遵循高速布线规则：
- 阻抗控制：确保TX/RX数据线做50Ω单端阻抗控制。
- 等长布线：TXCLK与TXD[3:0]之间，RXCLK与RXD[3:0]之间的走线长度差应尽可能小（通常要求小于几百mil）。严重的长度不匹配会导致建立/保持时间违例。
- 参考平面：信号线下方应有完整的地平面作为回流路径。
PHY芯片配置引脚：许多PHY芯片有一些硬件配置引脚（strap pin），用于上电时决定默认的工作模式（如RGMII/SGMII选择、时钟方向等）。务必根据你的设计，检查这些引脚的上下拉电阻是否正确焊接，其状态是否与软件配置一致。一个常见的错误是硬件配置为SGMII模式，但软件设备树却配置为RGMII。

7. 总结与固化：将解决方案融入构建流程

经过一番调试，终于找到了合适的时序参数tx_delay = 0x50和rx_delay = 0x15。但这还不够，我们需要将正确的配置固化下来，并思考如何避免下次踩坑。

更新设备树源文件：将调试好的tx_delay和rx_delay值永久写入板级的设备树文件（如rk3568-myboard.dts）。
创建调试补丁：如果该问题涉及多处修改（如PHY复位时序、兼容字符串等），最好创建一个清晰的git补丁，并附上详细的调试记录和最终参数说明。这对于团队协作和后续维护至关重要。
在构建脚本中加入检查：可以在编译前的脚本中，加入对关键设备树节点（如gmac0）的简单语法或属性检查，确保不会因误操作而覆盖正确的配置。
经验沉淀：将此次排查过程的关键点——如“单向不通先查PHY协商和时序”、“mii命令的用法”、“时序参数调整范围”——记录到团队的知识库中。对于特定的硬件平台（如RK3568+某型号PHY），可以形成一份《千兆网络启动必检清单》，涵盖电源测量点、时钟测量点、默认设备树配置、上电启动串口日志关键信息等。

解决u-boot网络问题的过程，是一次对硬件、驱动、协议栈的深度遍历。从看似诡异的“单向不通”现象入手，逐步剥离出PHY协商、设备树配置、时序参数乃至硬件设计这一连串的线索，最终找到那个不起眼却至关重要的tx_delay参数。这种问题没有标准答案，但掌握了从现象到本质的排查方法论，以及mii这类底层调试工具，就能在面对任何新的网络PHY芯片和硬件平台时，做到心中有谱，手中有术。下次当你的RK3568或其他开发板再出现网络“玄学”问题时，不妨先从链路层的自协商和时序这个方向深挖下去，很可能就会柳暗花明。