3、MTK启动流程详解：ROM Code、Preloader、LK、Kernel的启动顺序与职责
做MTK平台开发这么多年，我经常被问到的一个问题是：“手机按下电源键后，到底发生了什么？”
说实话，这个问题看似简单，但背后藏着一整套精密的启动链路。今天我就带大家把这套流程彻底捋一遍。
3.1 整体启动链路概览
MTK平台的启动，说白了就是一场“接力赛”。从芯片上电到用户看到桌面，中间经历了四个核心阶段：
- ROM Code（只读存储器代码）—— 芯片出厂就固化好的，谁也改不了
- Preloader（预加载器）—— 第一个可被升级的引导程序
- LK（Little Kernel）—— 负责加载内核的小型内核
- Kernel（Linux内核）—— 真正的操作系统内核
每个阶段都有明确的职责，就像接力赛中的每一棒，交接不好就会出问题。我在项目中遇到过好几次因为Preloader和LK之间的握手协议没对齐，导致设备变砖的情况——嗯，那滋味可不好受。
核心要点：MTK启动是一个“信任链”传递的过程。每个阶段都要验证下一阶段的完整性和合法性，一环扣一环。
3.2 ROM Code：芯片的“第一声啼哭”
ROM Code是芯片上电后执行的第一段代码。它固化在芯片内部的ROM中，你想想看，这意味着什么？
意味着它不可修改，也不可擦除。这是芯片的“基因”，出厂就定死了。
ROM Code的主要职责
- 初始化最基本的硬件：比如时钟、SRAM（静态随机存取存储器）、看门狗定时器等。这时候DDR（双倍数据速率内存）还没起来，只能用芯片内部那点可怜的SRAM。
- 检测启动模式：是正常启动？还是下载模式？还是恢复模式？通过检测GPIO（通用输入输出引脚）电平或USB插入状态来判断。
- 加载Preloader：从NAND Flash、eMMC或UFS中读取Preloader到SRAM中，然后跳转执行。
个人经验：ROM Code阶段如果出了问题，基本就是芯片物理损坏了。我调试过一台设备，上电后电流只有几毫安，用示波器量时钟信号都没有——最后发现是晶振虚焊。ROM Code连时钟都起不来，后面的流程根本走不动。
3.3 Preloader：第一个“可编程”的引导者
Preloader是MTK平台中第一个可被升级的引导程序。它存储在Flash的特定分区中，大小通常只有几十KB到几百KB。
为什么叫“Preloader”？因为它负责“预加载”后续的LK。说白了，它就是个“二传手”。
Preloader的核心职责
| 职责 | 说明 |
|---|---|
| 初始化DDR | 这是Preloader最重要的任务。DDR的时序参数、电压、频率都在这里配置。配错了，系统直接挂掉。 |
| 加载LK到DDR | 从Flash中读取LK镜像，放到DDR的指定地址，然后跳转。 |
| 下载模式支持 | 如果检测到USB插入或按键组合，进入下载模式，等待PC端工具刷机。 |
| 安全启动校验 | 验证LK镜像的签名，确保没有被篡改。 |
避坑指南：我曾经遇到过一批设备，Preloader加载LK时总是校验失败。查了两天才发现，是Flash的坏块管理出了问题，Preloader读到的LK数据本身就是错的。解决方案是在Preloader中增加ECC（纠错码）校验逻辑。
3.4 LK：承上启下的“小内核”
LK（Little Kernel）是一个轻量级的内核，专门为嵌入式系统设计。在MTK平台上，它扮演着“引导加载器”的角色。
我个人觉得，LK是整个启动流程中最容易被忽视的一环。很多人觉得它就是个“跳板”，但其实它做了很多关键工作。
LK的主要职责
- 初始化更复杂的硬件：比如UART（通用异步收发传输器）、I2C（集成电路总线）、GPIO、显示控制器等。这时候DDR已经可用，可以放开手脚了。
- 显示开机Logo：没错，你看到的第一个品牌Logo就是LK画出来的。它直接操作帧缓冲（Framebuffer），不需要Linux内核参与。
- 加载Kernel和DTB：从Flash中读取Linux内核镜像（zImage/Image）和设备树（DTB），放到DDR中。
- 传递启动参数：通过ATAG或设备树的方式，把硬件信息、内存布局、启动模式等参数传递给Kernel。
关键点：LK和Kernel之间的“握手”是通过设备树（Device Tree）完成的。LK负责填充设备树中的一些运行时信息，比如内存大小、MAC地址、序列号等。如果设备树没传对，Kernel启动后可能找不到某些硬件。
3.5 Kernel：真正的操作系统
当LK跳转到Kernel入口时，Linux内核开始接管系统。这时候，才算是真正进入了“操作系统”的世界。
Kernel的启动过程大家可能比较熟悉了，但有几个MTK特有的点值得注意：
Kernel启动的关键步骤
- 解压内核：如果内核是压缩的（通常是zImage），先解压到内存中。
- 初始化核心子系统：内存管理、进程调度、中断系统、定时器等。
- 解析设备树：从LK传递过来的设备树中读取硬件配置，初始化对应的驱动。
- 挂载根文件系统：通常是initramfs或从Flash分区挂载。
- 启动init进程：用户空间的第一个进程，PID为1。从此进入Android或其它用户空间系统。
我的习惯：调试Kernel启动问题时，我通常会打开earlyprintk或earlycon，这样在Kernel早期初始化阶段就能看到日志输出。否则一旦Kernel在挂载根文件系统之前崩溃，你连错误信息都看不到。
3.6 启动流程中的关键时序点
为了让大家更直观地理解，我整理了一个典型的启动时间分布：
| 阶段 | 典型耗时 | 说明 |
|---|---|---|
| ROM Code | 10-50ms | 主要是硬件初始化和Preloader加载 |
| Preloader | 50-200ms | DDR初始化是主要耗时点，DDR容量越大越慢 |
| LK | 100-500ms | 显示Logo、加载Kernel镜像 |
| Kernel | 500ms-2s | 驱动初始化、挂载文件系统 |
你想想看，从按下电源键到看到桌面，总共也就2-3秒的时间。这背后是四个阶段的紧密配合，任何一个环节出问题，都会导致启动失败。
3.7 常见启动问题与排查思路
最后，分享几个我在项目中遇到的典型问题：
- 设备完全无反应：电流只有几毫安 → 大概率是ROM Code阶段的问题，检查晶振、电源、复位信号。
- 电流在100mA左右跳动：Preloader阶段卡住了 → 检查DDR初始化参数，或者Flash读取是否正常。
- 能看到Logo但卡住：LK加载Kernel失败 → 检查Kernel镜像是否完整，设备树是否正确传递。
- Kernel启动到一半重启：通常是驱动初始化失败，或者看门狗超时 → 打开earlycon日志，定位到具体哪个驱动挂掉。
重要提醒：千万不要在量产阶段随意修改Preloader或LK的代码。这两个阶段的代码一旦出问题，设备可能连下载模式都进不去，只能拆机用SP Flash Tool的“短路法”救砖。我当年就干过这种蠢事，被硬件同事骂了一下午。
好了，MTK的启动流程就讲到这里。下一章我们会深入Preloader的代码实现，看看DDR初始化到底是怎么做的。到时候我会带大家手撕一段Preloader源码，敬请期待。