启动流程分析：从按下电源到用户空间

做嵌入式Linux开发，说白了就是在跟启动流程打交道。我记得刚入行那会儿，板子起不来，第一反应就是怀疑硬件坏了。后来被老工程师带着调了一次启动，才发现——嗯，启动的每个阶段都有它的脾气。

Tina Linux的启动，我习惯把它拆成五个阶段：Boot ROM → SPL → U-Boot → Kernel → Init。每个阶段都有明确的分工，也都有各自的坑。咱们一个一个来看。

2.1 Boot ROM 阶段：芯片出厂的第一段代码

Boot ROM是固化在芯片内部的一段只读代码，你改不了它。它的任务很简单：上电后初始化最基本的硬件（时钟、SRAM），然后去检测启动介质——SD卡、NAND、SPI NOR Flash等等。

我个人习惯把Boot ROM看作一个“硬件引导器”。它不加载操作系统，只负责把下一级代码（SPL）从存储介质搬到芯片内部的SRAM里。

特性	说明
存储位置	芯片内部ROM，出厂固化
可修改性	不可修改
主要工作	初始化时钟、SRAM，检测启动介质
加载目标	SPL（通常限制在32KB以内）
常见问题	启动介质检测顺序导致启动失败

2.2 SPL 阶段：U-Boot的“迷你版”

SPL（Secondary Program Loader）是U-Boot的精简版本。为什么需要它？因为芯片内部的SRAM通常很小（比如64KB），装不下完整的U-Boot。SPL的任务就是：初始化DRAM，然后把完整的U-Boot从存储介质加载到DRAM里。

你想想看，SPL其实是个“中间人”。它不能太复杂，否则SRAM装不下；但又不能太简单，否则没法初始化DRAM。我一般建议SPL的代码量控制在16KB以内，超过这个数就容易出问题。

2.3 U-Boot 阶段：真正的引导加载器

U-Boot是嵌入式Linux的标配。它负责初始化外设（网卡、USB、显示等），加载设备树（DTB），然后把Kernel镜像和DTB一起传递给内核。

我个人觉得U-Boot是启动流程中最灵活也最复杂的阶段。你可以在这里做很多事情：网络启动、从多种介质启动、甚至做简单的固件升级。但灵活性也意味着容易出错。

// U-Boot 启动内核的典型命令
=> setenv bootargs console=ttyS0,115200 root=/dev/mmcblk0p2
=> fatload mmc 0:1 0x42000000 uImage
=> fatload mmc 0:1 0x43000000 sunxi.dtb
=> bootm 0x42000000 - 0x43000000

U-Boot 关键功能	说明
环境变量	存储启动参数，可持久化到存储介质
设备树加载	将DTB传递给内核，描述硬件拓扑
网络启动	通过TFTP/NFS加载内核和根文件系统
校验机制	支持镜像签名校验，防止篡改

2.4 Kernel 启动阶段：从压缩镜像到进程调度

Kernel启动是整个流程中最核心的部分。U-Boot把控制权交给Kernel后，Kernel会经历：解压自身 → 初始化架构相关代码 → 启动进程调度器 → 挂载根文件系统 → 执行第一个用户空间进程（通常是/sbin/init）。

这里有个关键点：Kernel启动时间受很多因素影响。驱动初始化顺序、设备树解析、文件系统类型，都会影响启动速度。我习惯用initcall_debug内核参数来查看每个驱动的初始化耗时。

// 在U-Boot的bootargs中添加 initcall_debug
setenv bootargs console=ttyS0,115200 root=/dev/mmcblk0p2 initcall_debug
// 启动后可以看到类似这样的输出：
[    0.123456] initcall sunxi_mmc_init+0x0/0x100 returned 0 after 12345 usecs

2.5 Init 进程与用户空间启动

Kernel启动完成后，会执行第一个用户空间进程——/sbin/init。在Tina Linux中，这个进程通常是BusyBox的init，或者Procd（OpenWrt的进程管理守护进程）。

Init进程负责：读取/etc/inittab（或Procd的配置文件）→ 启动系统服务 → 挂载文件系统 → 启动网络 → 启动应用程序。说白了，就是从内核态切换到用户态，把系统从“能跑”变成“能用”。

Init 系统	特点	适用场景
BusyBox init	简单、轻量、配置直接	资源受限的嵌入式设备
Procd	支持热插拔、服务依赖管理	OpenWrt/LEDE 系统
Systemd	功能强大、并行启动	性能较强的设备（较少用于Tina）

2.6 启动流程全景图

下面这张图把整个启动流程串起来了。我建议你把它打印出来贴在工位上，调试的时候对照着看，思路会清晰很多。

2.7 各阶段耗时与优化切入点

根据我多年的调试经验，启动时间分布大致如下。注意，这个比例会因硬件平台和软件配置不同而变化，但大方向是稳定的。

启动阶段	典型耗时占比	优化切入点
Boot ROM	3% - 5%	无法优化（固化代码）
SPL	2% - 5%	减少DRAM初始化延时
U-Boot	15% - 25%	裁剪驱动、减少延时、使用FIT镜像
Kernel	35% - 45%	驱动模块化、延迟加载、优化设备树
Init + 用户空间	25% - 35%	并行启动、按需启动、精简服务