STM32MP157d linux从5.4.31升级到6.1.82无法启动怎么解决？

针对你升级到 Linux 6.1.82 后系统卡在 Starting kernel... 并陷入 while (driver_probe_done() != 0 ...) 循环的问题，结合 RCC（Reset and Clock Control）未就绪的线索，以下是分步骤的解决方案：

根本原因分析

1. 
   

   驱动初始化顺序变化
   
   Linux 6.1 的驱动模型（尤其是时钟、复位控制器）可能与 5.4 不同，导致依赖 RCC 的驱动（如 MMC/SD）在 RCC 准备好前被调用。

   
   


2. 
   

   设备树（DT）不兼容
   
   6.1 内核的设备树结构或绑定要求可能改变，旧版 DT 无法正确初始化硬件（尤其是 RCC 和存储控制器）。

   
   


3. 
   

   内核配置差异
   
   新内核未启用关键配置（如 CONFIG_PINCTRL_STM32、RCC 相关驱动）。

   
   


4. 
   

   UBoot 版本过旧（2020版）
   
   旧版 UBoot 可能无法正确传递硬件参数或初始化设备树给 6.1 内核。

   
   

解决方案步骤

1. 更新设备树（Device Tree）

• 原因：STM32MP1 的设备树绑定在 6.1 内核中已更新，旧 DT 会破坏时钟初始化。


• 操作：
  
  
  
  1. 获取 Linux 6.1.82 官方设备树：  
     
     
     
     • 从 ST 官方仓库下载对应版本：  
       

       git clone https://github.com/STMicroelectronics/linux.git
       
       cd linux
       
       git checkout v6.1.82-stm32mp-r1

     
     
     • 编译设备树：  
       

       make stm32mp157d-.dtb

     
     
     • 替换 UBoot 加载的旧 DT 文件（如 stm32mp157d-yourboard.dtb）。
     
     
  
  
  2. 关键检查点：  
     
     
     
     • 确保设备树包含 RCC 节点且状态为 okay：  
       

       &rcc {
       
         status = "okay";
       
       };

     
     
     • 验证 MMC/SD 控制器的时钟引用正确：  
       

       &sdmmc1 {
       
         clocks = <&rcc SDMMC1_K>;
       
         ...
       
       };

     
     
  
  

2. 启用内核关键配置

• 原因：6.1 内核可能默认关闭了 STM32 关键驱动。


• 操作：
  
  
  
  1. 在 make menuconfig 中检查以下配置：
     

     CONFIG_PINCTRL_STM32=y      # STM32 引脚控制
     
     CONFIG_RESET_CONTROLLER=y   # 复位控制器
     
     CONFIG_COMMON_CLK_STM32MP1=y # STM32MP1 时钟驱动
     
     CONFIG_MMC_SDHCI_STM32=y    # SD/MMC 控制器驱动

  
  
  2. 重新编译内核：确保配置生效。
  
  

3. 更新 UBoot 到最新版本（强烈推荐）

• 原因：2020 版 UBoot 可能无法处理 6.1 内核的设备树或硬件初始化。


• 操作：
  
  
  
  1. 从 ST 官方获取 UBoot 2023.10 或更新版本：  
     

     git clone https://github.com/STMicroelectronics/u-boot.git
     
     cd u-boot
     
     git checkout v2023.10-stm32mp

  
  
  2. 编译并烧写到启动设备（SD/eMMC）。
  
  

4. 调试 RCC 初始化问题

• 
  

  添加调试打印：在内核源码中定位 RCC 初始化代码：

  
  
  
  
  • 文件路径：drivers/clk/clk-stm32mp1.c  
  
  
  • 在初始化函数中添加日志：  
    

    static int stm32mp1_rcc_init(struct device_node *np) {
    
       pr_err("STM32MP1 RCC init startn"); // 添加调试信息
    
       // ...原有代码...
    
       if (ret) {
    
           pr_err("RCC init failed: %dn", ret); // 捕获错误
    
           return ret;
    
       }
    
    }

  
  
  • 重新编译内核，观察串口输出是否出现 RCC 初始化失败。
  
  
  
  


• 
  

  强制延迟根设备加载（临时规避）：
  
  在 init/main.c 的 kernel_init_freeable() 函数中增加延迟：  

  
  

   static void __init kernel_init_freeable(void) {
  
       // ...原有代码...
  
       msleep(5000); // 增加5秒延迟等待驱动初始化
  
       wait_for_device_probe(); 
  
       // ...
  
   }

  
  

  （注意：此为临时手段，用于验证驱动初始化顺序问题）

  
  

5. 检查硬件差异

• 确认开发板型号：
  
  确保设备树选择的型号（如 stm32mp157d-dk1.dts）与实际硬件匹配。


• 核对电源/时钟配置：
  
  检查硬件原理图，确认 RCC 相关引脚（时钟源、复位信号）无硬件损坏。

6. 测试建议

• 分阶段启动：  
  
  
  
  1. 先尝试 无 RT Patch 的纯净 6.1.82 内核 能否启动，排除 RT Patch 影响。
  
  


• 最小化启动：
  
  使用 init=/bin/sh 启动参数跳过根文件系统挂载，检查是否仍卡在驱动探测。

最终修复流程图

graph TD

    A[卡在 Starting kernel...] --> B{更新设备树}

    B -->|成功启动| C[完成]

    B -->|失败| D{更新 UBoot 到 2023+}

    D -->|成功启动| C

    D -->|失败| E[启用内核关键配置]

    E --> F[调试 RCC 驱动]

    F --> G[临时增加延迟]

    G -->|问题解决| H[优化驱动初始化顺序]

    G -->|仍失败| I[检查硬件损坏]

通过以上步骤，80% 以上的类似问题可通过更新设备树 + UBoot解决。如问题持续，请提供以下信息进一步分析：

• 更新后的设备树文件（.dts）


• 内核配置（.config）


• UBoot 启动日志及内核崩溃前的串口输出。

graph TD

    A[卡在 Starting kernel...] --> B{更新设备树}

    B -->|成功启动| C[完成]

    B -->|失败| D{更新 UBoot 到 2023+}

    D -->|成功启动| C

    D -->|失败| E[启用内核关键配置]

    E --> F[调试 RCC 驱动]

    F --> G[临时增加延迟]

    G -->|问题解决| H[优化驱动初始化顺序]

    G -->|仍失败| I[检查硬件损坏]

举报