20240605排查OK3588-C核心板Buildroot刷机后PCIe初始化失败导致启动卡死问题

1. 问题现象与初步分析

最近在给OK3588-C核心板刷入Buildroot系统时，遇到了一个棘手的问题：系统启动过程中会在PCIe初始化阶段卡死。从内核日志中可以清晰看到反复出现的错误信息："PCIe Linking... LTSSM is 0x3"，最终导致系统完全挂起。

这个问题看起来和PCIe3.0控制器的初始化直接相关。LTSSM（Link Training and Status State Machine）状态码0x3表示设备处于"Detect.Quiet"状态，这是PCIe链路训练失败时常见的状态。简单来说，就是系统在尝试建立PCIe连接时，无法完成握手协议。

我注意到这个问题有几个关键特征：

1. 系统能够正常启动到U-Boot阶段
2. 内核初始化过程中会在PCIe初始化时卡住
3. 错误信息显示PCIe链路训练失败（LTSSM 0x3）
4. 系统最终会完全停止响应

2. 深入理解PCIe初始化过程

要解决这个问题，我们需要先理解RK3588的PCIe初始化流程。RK3588芯片内置了多个PCIe控制器，包括PCIe3.0和PCIe2.0接口。在系统启动时，内核会依次初始化这些控制器。

PCIe初始化的关键步骤包括：

1. 时钟和电源管理单元初始化
2. PHY（物理层）配置
3. 控制器寄存器配置
4. 链路训练（LTSSM状态机运行）
5. 枚举连接的设备

从日志来看，问题出在第4步 - 链路训练阶段。LTSSM状态0x3表示控制器一直在尝试检测对端设备但未能成功建立连接。这种情况通常有几种可能原因：

• PCIe物理链路存在问题（如时钟信号不稳定）
• 对端设备未正确供电或初始化
• PHY配置参数不正确
• 设备树中对PCIe控制器的配置有误

3. 设备树配置分析与修改

查看原始设备树配置，我发现PCIe3.0相关节点配置如下：

&pcie30phy { rockchip,pcie30-phymode = <PHY_MODE_PCIE_AGGREGATION>; status = "okay"; }; &pcie3x4 { reset-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>; vpcie3v3-supply = <&vcc3v3_pcie30>; pinctrl-names = "default"; pinctrl-0 = <&pcie20x1_0_clkreqn_m1>; status = "okay"; };

这里有几个需要注意的点：

1. 使用了PCIe3.0 PHY的聚合模式（PHY_MODE_PCIE_AGGREGATION）
2. 配置了3.3V电源供应
3. 启用了复位GPIO控制

经过多次测试，我发现将PCIe3.0相关模块禁用可以解决启动卡死的问题。修改后的设备树配置如下：

&pcie2x1l0 { reset-gpios = <&gpio1 RK_PB4 GPIO_ACTIVE_HIGH>; status = "okay"; }; &pcie30phy { rockchip,pcie30-phymode = <PHY_MODE_PCIE_AGGREGATION>; status = "disabled"; }; &pcie3x4 { reset-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>; vpcie3v3-supply = <&vcc3v3_pcie30>; pinctrl-names = "default"; pinctrl-0 = <&pcie20x1_0_clkreqn_m1>; status = "disabled"; };

关键修改点：

1. 禁用了PCIe3.0 PHY（pcie30phy）
2. 禁用了PCIe3x4控制器
3. 保留了PCIe2x1l0控制器的启用状态

4. 问题根源与解决方案

经过深入分析，我认为问题根源在于OK3588-C核心板的硬件设计与Buildroot系统中的PCIe3.0驱动存在兼容性问题。具体可能的原因包括：

1. 时钟配置不匹配：PCIe3.0对时钟信号质量要求很高，可能存在时钟抖动或频率偏差
2. 电源时序问题：PCIe3.0设备的电源上电时序要求严格，可能与当前配置不符
3. PHY校准参数不准确：不同板卡的PCB走线差异需要不同的PHY参数

临时解决方案是禁用PCIe3.0相关模块，这可以通过修改设备树实现。长期解决方案则需要：

1. 检查硬件设计，特别是PCIe3.0的时钟和电源电路
2. 调整PHY校准参数
3. 更新内核驱动以更好地兼容硬件

5. 详细操作步骤

如果你遇到了同样的问题，可以按照以下步骤操作：

1. 获取当前设备树源文件（DTS）
2. 定位到PCIe相关节点（通常在rk3588s.dtsi或板级DTS文件中）
3. 修改PCIe3.0相关节点的状态为"disabled"
4. 重新编译设备树

具体命令示例：

# 解压原始镜像获取dts dtc -I dtb -O dts -o output.dts original.dtb # 修改dts文件后重新编译 dtc -I dts -O dtb -o new.dtb modified.dts

对于Buildroot用户，可以通过以下方式更新设备树：

1. 在Buildroot配置中启用设备树覆盖支持
2. 将修改后的设备树文件放入output/images目录
3. 重新生成系统镜像

6. 验证与测试

修改后需要验证系统是否正常启动以及PCIe功能：

1. 检查内核启动日志，确认没有PCIe相关错误
2. 使用lspci命令查看已识别的PCIe设备
3. 测试PCIe2.0接口的功能

验证命令示例：

# 查看PCIe设备 lspci -vvv # 检查内核日志 dmesg | grep -i pcie

如果系统能够正常启动且PCIe2.0设备工作正常，说明修改成功。

7. 进阶调试建议

对于希望深入解决问题的开发者，可以尝试以下调试方法：

1. 使用示波器检查PCIe时钟信号质量
2. 调整PHY参数（如pre-emphasis、swing等）
3. 尝试不同的PHY工作模式
4. 检查电源轨的上电时序和电压稳定性

内核调试选项：

# 启用PCIe调试信息 echo 8 > /sys/module/pcie/parameters/debug

这些调试方法需要一定的硬件知识和调试工具，但对于彻底解决问题很有帮助。

8. 替代方案与注意事项

如果必须使用PCIe3.0功能，可以考虑以下替代方案：

1. 尝试不同的内核版本（某些版本可能对硬件兼容性更好）
2. 联系硬件厂商获取针对性的补丁或建议
3. 考虑使用PCIe2.0模式运行（如果性能可接受）

注意事项：

1. 修改设备树前务必备份原始文件
2. 每次修改后都要完整重新编译系统
3. 如果使用SDK开发，注意保持环境一致性
4. 某些修改可能需要同步调整uboot配置

这个问题虽然看起来复杂，但通过系统性的分析和调试，通常都能找到解决方案。我在实际项目中遇到过多次类似的硬件兼容性问题，关键是要有耐心，一步步排除可能的原因。