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

根据您的描述，问题出现在从 Linux 5.4.31 升级到 6.1.82 后，内核卡在设备探测和根设备识别阶段。以下是系统性的排查和解决方案：

问题根源分析

1. 
   

   设备树（DTB）兼容性问题
   
   Linux 6.1 内核的设备树绑定（Bindings）与 5.4 相比有重大变化，尤其是 RCC（Reset & Clock Controller） 节点：

   
   
   
   
   • STM32MP1 系列的时钟驱动在 6.1 中重构为 stm32mp1 时钟框架。
   
   
   • 旧版设备树中的 rcc 节点定义可能被废弃，导致时钟未初始化。
   
   
   
   


2. 
   

   驱动程序加载顺序变化
   
   新内核的驱动探测机制更严格，依赖时钟的设备（如MMC/SD）可能因 RCC 未就绪 而初始化失败，导致根设备无法识别。

   
   


3. 
   

   U-Boot 版本过旧（2020版）
   
   2020 年的 U-Boot 可能无法正确处理 6.1 内核的设备树或启动参数。

   
   


4. 
   

   关键内核配置未更新
   
   实时补丁（RT Patch）可能依赖额外的内核选项。

   
   

解决方案步骤

1. 更新设备树（DTB）

• 获取新设备树：从 ST 官方仓库下载匹配 6.1.82 的设备树：  
  

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



• 替换关键节点：
  
  
  
  • 检查 stm32mp157d.dtsi 中的 rcc 节点，新版可能使用：
    

    rcc: rcc@50000000 {
    
       compatible = "st,stm32mp1-rcc", "syscon";
    
       reg = <0x50000000 0x1000>;
    
       #clock-cells = <1>;
    
       #reset-cells = <1>;
    
    };

  
  
  • 确保所有依赖 RCC 的设备（如 sdmmc, usb）的时钟引用正确：
    

    &sdmmc1 {
    
       clocks = <&rcc SDMMC1_K>;
    
       resets = <&rcc SDMMC1_R>;
    
    };

  
  


• 重新编译 DTB：
  

   make ARCH=arm stm32mp157d-your-board.dtb

2. 升级 U-Boot

使用 2023+ 版本 U-Boot（支持新内核和设备树）：

   git clone https://github.com/u-boot/u-boot.git

   cd u-boot

   make stm32mp15_defconfig

   make -j8

3. 修复驱动探测逻辑

• 暂时修改内核代码（用于调试）：
  
  在 init/main.c 中找到卡死的 while 循环，暂时注释掉 driver_probe_done() 检查：
  

   // while (driver_probe_done() != 0 || ... 
  
   msleep(100); // 临时跳过等待



• 检查驱动加载顺序：
  
  在卡死位置添加调试打印，确认哪个驱动未就绪：
  

   printk("Waiting for drivers: %d, root_dev: %dn", driver_probe_done(), ROOT_DEV);

4. 启用 RCC 调试

• 添加早期时钟初始化打印：
  
  在 drivers/clk/clk-stm32mp1.c 的 stm32mp1_rcc_init() 添加日志：
  

   pr_info("RCC initialized: status=0x%xn", readl(base + RCC_MP_SREQSETR));



• 检查时钟状态寄存器：
  
  如果寄存器值为 0，说明 RCC 未被正确初始化，需确认设备树中是否启用：
  

   &rcc {
  
       status = "okay";
  
       secure-status = "okay"; // TrustZone 模式下需要
  
   };

5. 更新内核配置

• 启用关键选项：
  

   CONFIG_PINCTRL_STM32=y
  
   CONFIG_CLK_STM32MP1=y
  
   CONFIG_RESET_CONTROLLER=y
  
   CONFIG_MMC_STM32_SDMMC=y



• 禁用旧驱动（如有冲突）：
  

   CONFIG_STM32_HSEM=n  # 检查是否与新驱动冲突

6. 检查启动参数

确保 U-Boot 传递正确的 root= 参数：

   setenv bootargs "root=/dev/mmcblk0p2 rootwait earlyprintk"

验证流程

1. 
   

   逐级测试组件：

   
   
   
   
   • 使用新 U-Boot 启动旧内核（5.4.31） → 确认硬件无故障。
   
   
   • 用新内核启动 最小 Initramfs → 确认是否因根文件系统导致卡死。
   
   
   • 在 Initramfs 中手动挂载根文件系统：
     

     mount /dev/mmcblk0p2 /mnt

   
   
   
   


2. 
   

   捕捉早期日志：

   
   
   
   
   • 开启 Earlycon 输出（在设备树中启用）：
     

     chosen {
     
      stdout-path = "serial0:115200n8";
     
      linux,earlycon = "serial0";
     
     };

   
   
   • 串口捕捉未初始化前的日志：
     

     make menuconfig # 启用 CONFIG_DEBUG_LL, CONFIG_EARLY_PRINTK

   
   
   
   

最终建议

1. 
   

   使用 ST 官方镜像验证：
   
   从 ST Wiki 下载预编译的 6.1.82 镜像，快速验证硬件兼容性。

   
   


2. 
   

   更新 TF-A 和 OP-TEE：
   
   即使未使用 OP-TEE，同步升级 TF-A 可避免低级初始化问题：

   
   

   git clone https://github.com/STMicroelectronics/arm-trusted-firmware

   
   


3. 
   

   检查 RT Patch 兼容性：
   
   ST 的 RT 补丁可能依赖额外的驱动补丁，需在官方文档中确认依赖项。

   
   

通过以上步骤，90% 的问题应集中在 设备树更新 和 U-Boot 升级 上。若仍卡在 RCC，请提供设备树中的 rcc 节点定义和启动日志，以便进一步分析。

   git clone https://github.com/u-boot/u-boot.git

   cd u-boot

   make stm32mp15_defconfig

   make -j8

   setenv bootargs "root=/dev/mmcblk0p2 rootwait earlyprintk"

举报