替换uImage后i.MX6平台启动内核panic问题求助

咱们来拆解你的问题，一步步排查——嵌入式ARM系统里自定义内核编译后出现这类问题很常见：

问题核心回顾 #

你替换ISO里的预编译uImage为自定义编译版本后（哪怕回退代码重新编译），系统启动时触发VFS: Unable to mount root fs on unknown-block(1,0)错误，最终导致Kernel Panic，但预编译版本能正常运行。你怀疑kexec阶段内核解压时覆盖了initrd，这个方向很值得深挖。

1. 排查内核配置的隐蔽差异 #

你提到用了旧内核配置，但哪怕是微小的重新编译，都可能引入细节问题：

• 编译前务必执行make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- oldconfig：就算是同一版本内核，重新编译时可能会出现新的配置项，默认值未必和预编译内核一致。重点检查：
  • 根文件系统所在存储介质的驱动（比如USB存储、MMC/SD控制器驱动）——unknown-block(1,0)通常意味着内核识别不到对应的块设备。
  • CONFIG_BLK_DEV_INITRD及相关initrd配置项——这里的不匹配会直接破坏启动流程，包括kexec阶段。
• 直接对比配置文件：用预编译内核正常启动后，执行zcat /proc/config.gz > prebuilt_config导出配置，再和你的.config做diff对比，重点关注块设备、initrd、内存管理相关的配置。

2. 验证uImage的加载地址与内存布局 #

你用的编译命令可能缺少关键参数：

• 查看预编译uImage的加载地址：执行mkimage -l prebuilt_uImage获取加载地址和入口地址，自定义编译时需要显式指定，比如：

  make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- uImage LOADADDR=0x10008000
  

  （i.MX6平台通常用0x10008000作为内核加载地址，以预编译镜像的实际值为准）
• 检查U-Boot启动脚本的内存地址：确认U-Boot中加载uImage和initrd的内存区域没有重叠。如果内核解压到initrd占用的内存区域，就会直接覆盖它——这正好对应你怀疑的点。

3. 确认ISO重构的完整性 #

用mkisofs重构ISO可能破坏了ARM平台的引导结构：

• 改用xorriso处理ARM可引导ISO：它比mkisofs更适合处理混合引导结构，示例命令（根据原ISO参数调整）：

  xorriso -as mkisofs -o new_custom.iso -isohybrid-mbr /usr/lib/ISOLINUX/isohdpfx.bin -c boot.cat -b isolinux.bin -no-emul-boot -boot-load-size 4 -boot-info-table ./extracted_iso_contents
  

• 验证文件路径与权限：确保自定义uImage放在ISO里和预编译版本完全相同的路径，且权限一致。有些启动脚本对文件路径和权限有严格要求。

4. 验证kexec阶段的内存冲突猜想 #

要确认是否是内核解压覆盖initrd：

• kexec前查看内存区域：执行cat /proc/iomem查看initrd占用的内存范围，再对比内核源码中arch/arm/boot/compressed/head.S里的解压地址，看两者是否重叠。
• 手动指定kexec的内存地址：强制内核和initrd使用不同的内存区域，避免重叠，比如：

  kexec --load-address=0x10008000 --initrd-load-address=0x12000000 ./uImage --initrd ./initrd.img
  

5. 隔离问题：绕过ISO直接测试 #

先排除ISO重构的问题，直接测试自定义uImage：

• 通过U-Boot的TFTP加载：

  tftpboot 0x10008000 custom_uImage
  tftpboot 0x12000000 initrd.img
  bootm 0x10008000 0x12000000
  

  如果这样能正常启动，说明问题出在ISO重构环节；如果还是panic，那肯定是内核配置或编译参数的问题。

内容的提问来源于stack exchange，提问作者vidhya