实战解析--内核移植卡在starting kernel的排查与解决

最新推荐文章于 2026-08-04 13:47:15 发布

原创

最新推荐文章于 2026-08-04 13:47:15 发布 · 756 阅读

1. 当屏幕定格在“Starting kernel...”时，你在想什么？

相信很多刚开始玩嵌入式开发的朋友，都对这个画面不陌生。你满怀期待地敲下 boot 命令，串口终端上，U-Boot 的信息一行行流畅地滚动，直到出现那句 “Starting kernel...”。然后，世界就安静了。光标在那一行闪烁，仿佛在嘲笑你的努力，而你只能对着屏幕干瞪眼，心里一万个问号飘过：“我的板子是不是砖了？”“我到底哪一步做错了？”

别慌，这几乎是每一个嵌入式开发者的“成人礼”。我当年第一次遇到这情况，也是折腾了好几天，查遍了各种论坛和文档。今天，我就把自己这些年踩过的坑、总结的经验，掰开揉碎了跟大家聊聊。内核启动卡在 Starting kernel...，本质上就是 引导程序（Bootloader）把接力棒交给了内核，但内核没能成功跑起来。这就像你按下了电脑的开机键，电源灯亮了，风扇转了，但屏幕就是不亮。问题可能出在“电脑主机”（内核）本身，也可能出在连接“主机”和“显示器”（硬件）的“线缆”（设备树）上。

所以，我们的排查思路就很清晰了：从外到内，从简到繁。先确认最基本的引导环节没问题，再深入内核和硬件配置的细节。这篇文章，我会结合一个真实的瑞萨RZ系列开发板的案例，带你走一遍完整的排查流程。即使你用的不是瑞萨的板子，这套方法论也是完全通用的。咱们的目标是，不仅解决眼前的问题，更要让你下次再遇到时，能自己有条理地分析和定位。

2. 第一步：别急着动内核，先给Bootloader做个“体检”

很多新手一看到卡住，第一反应就是去重新编译内核，这其实是个误区。Bootloader（通常是U-Boot）是启动链条的第一环，如果它本身就有问题，或者它传递给内核的信息是错的，内核当然跑不起来。所以，我们的排查必须从这里开始。

2.1 确认Bootloader自身健康状态

首先，确保你的Bootloader是能正常工作的。怎么确认？一个最直接的证据就是：这块板子以前是否成功启动过某个系统（比如原厂系统或旧版内核）？ 如果答案是肯定的，那至少说明Bootloader的基础功能、串口驱动、内存初始化是没问题的，我们可以暂时排除硬件级的大故障。

在U-Boot命令行下，有几个关键命令可以帮助我们检查：

printenv：查看所有环境变量。重点关注 bootcmd（自动启动命令）、bootargs（传递给内核的启动参数）、fdt_addr（设备树加载地址）、loadaddr（内核镜像加载地址）等。
bdinfo：打印板级信息，可以快速查看内存分布、时钟等，确认U-Boot识别到的硬件信息是否正常。
md（内存显示）和 mw（内存写入）：可以用来简单测试内存访问是否正常。比如 md 0x80000000 10 查看内存起始内容。

一个常见的低级错误：在更新U-Boot或切换存储设备后，忘记重新设置环境变量。比如，你编译了新内核，烧录到了 0x80000 地址，但 loadaddr 还是指向旧的 0x60000，那U-Boot去错误的地方找内核，自然找不到，或者找到的是垃圾数据，导致启动失败。所以，每次更新镜像后，务必核对一遍这些关键地址变量。