Armbian项目：Radxa E20C开发板LAN端口故障分析与解决方案

问题背景

在Radxa E20C开发板上运行最新构建的Bookworm系统镜像时，用户发现WAN端口工作正常，但LAN端口（end1）虽然能够检测到链路连接，却无法正常收发数据包。这一现象在多个E20C设备上均能复现，表现为接口状态显示为UP，链路检测正常，但实际网络通信完全失效。

技术现象分析

通过系统诊断工具收集的信息显示：

• 接口状态：end1显示为UP和LOWER_UP
• 链路协商：成功协商为1000M全双工模式
• 数据包传输：tcpdump显示有出站数据包，但对端设备无法接收
• ARP解析：目标MAC地址显示为<incomplete>

内核日志中值得注意的是与RK3528以太网控制器相关的初始化信息，特别是关于时钟和延迟设置的警告信息：

rk_gmac-dwmac ffbe0000.ethernet: cannot get clock mac_clk_rx
rk_gmac-dwmac ffbe0000.ethernet: cannot get clock mac_clk_tx
rk_gmac-dwmac ffbe0000.ethernet: set rx_delay to 0xffffffff

根本原因调查

经过深入分析，发现问题与以下因素相关：

1. PCIe与GMAC的交互问题：RK3528芯片上PCIe控制器和GMAC网络控制器的协同工作存在异常。当PCIe功能启用时，会影响GMAC的正常工作。

2. 内核驱动变更：对比6.1.75-vendor-rk35xx内核版本（工作正常）与最新版本，发现PCIe驱动程序的修改是导致问题的关键因素。

3. PHY芯片配置：板载使用的YT8531物理层芯片（驱动位于drivers/net/phy/motorcomm.c）可能因电压或初始化时序问题导致发送功能异常。

解决方案

经过社区协作，最终确定了以下解决方案：

1. 内核版本回退：临时使用修复后的内核分支（rk-6.1-rkr5），该分支回退了导致问题的PCIe驱动修改。

2. 构建配置调整：在Armbian构建系统中，通过修改板级配置文件指定使用修复后的内核源码：

function post_family_config_branch_vendor__radxa-e20c_use_custom_source() {
    KERNEL_MAJOR_MINOR="6.1"
    KERNELSOURCE='https://github.com/CodeChenL/linux-rockchip.git'
    KERNELBRANCH='branch:rk-6.1-rkr5'
    EXTRAWIFI=no
}

3. 驱动修复：长期解决方案是等待相关修复被合并到主线内核，包括：
   • PCIe驱动中与时钟管理相关的修正
   • GMAC初始化流程的优化
   • PHY芯片配置参数的调整

技术启示

这一案例展示了嵌入式Linux系统中硬件资源冲突的典型表现和解决方法：

1. 外设交互复杂性：现代SoC中多个高速外设（如PCIe和GMAC）共享资源时，驱动程序的微小变化可能导致功能异常。

2. 回归测试重要性：内核更新可能引入难以预料的副作用，特别是在特定硬件组合上。

3. 社区协作价值：通过开发者社区的共同分析和测试，能够快速定位和解决复杂的硬件兼容性问题。

对于使用Radxa E20C开发板的用户，建议在构建系统时应用上述修复，或等待Armbian官方发布包含完整修复的稳定版本。同时，这一案例也为其他Rockchip平台类似问题的解决提供了参考思路。