Bootloader与内核启动优化：从按下电源到系统跑起来

大家好，我是你们的讲师。今天我们来聊聊嵌入式Linux启动过程中最关键的环节——Bootloader和内核启动优化。说白了，就是从你按下电源键，到系统提示符出现，这中间到底发生了什么，以及怎么让它跑得更快。

我在做第一个工业项目时，客户要求启动时间必须控制在3秒以内。当时我心想，这怎么可能？后来才发现，不是不可能，是你没找对地方下手。这一章，我就把当年踩过的坑和总结的经验，一次性讲清楚。

U-Boot启动流程分析：第一行代码到加载内核

U-Boot的启动，我习惯把它分成三个阶段。你想想看，一个嵌入式系统从复位到加载内核，其实就三步：

1. SPL（Secondary Program Loader）—— 初始化最基础的硬件，比如时钟、DDR。这个阶段代码极小，通常只有几KB。
2. U-Boot proper —— 完整的Bootloader，初始化外设、文件系统、网络，然后加载内核。
3. 加载并跳转到内核 —— 把内核镜像从存储介质读到内存，然后跳过去执行。

我曾经在一个项目里发现，U-Boot启动花了整整2秒，其中1.5秒都浪费在等待某个外设初始化上。后来我把那个外设的初始化挪到内核里做，启动时间直接砍掉一半。

内核压缩与解压优化：别让解压成为瓶颈

内核镜像通常是压缩的，常见的有gzip、lzma、lzo、zstd。解压速度直接影响启动时间。我做过一个对比测试，数据如下：

压缩算法	压缩比	解压速度	适用场景
gzip	中等	慢	兼容性好，老项目常用
lzo	低	快	追求启动速度，存储空间充裕
lzma	高	极慢	存储空间紧张，不介意启动慢
zstd	高	快	现代项目首选，平衡压缩比和速度

我个人建议，如果Flash空间够用，直接用lzo或者zstd。zstd的压缩比接近lzma，但解压速度比gzip还快，简直是工业项目的福音。

另外，还有一个容易被忽略的点——解压位置。内核解压时，如果目标地址和源地址有重叠，解压算法会做额外的拷贝操作。我建议把内核加载地址和解压地址分开，避免这种不必要的开销。

设备树(DTS)裁剪与适配：少即是多

设备树（Device Tree）是描述硬件信息的文件。很多工程师习惯把整个参考板子的DTS拿过来，只改改自己需要的部分。结果呢？里面一堆用不到的外设节点，每个节点在启动时都会被内核扫描一遍，白白浪费时间。

我曾经接手过一个项目，启动时间有4秒，其中1秒花在设备树解析上。我打开DTS一看，好家伙，里面定义了6个I2C控制器，板子上只用了1个；4个SPI控制器，只用了1个；还有一堆没连接的GPIO扩展芯片。全部删掉之后，启动时间直接降到3秒。

具体怎么做？我建议你按以下步骤来：

1. 从参考板子的DTS开始，删除所有未使用的节点。
2. 检查每个节点的status属性，确保用不到的节点设为"disabled"。
3. 精简时钟和电源管理节点，只保留必要的。
4. 用dtc -I dtb -O dts反编译生成的DTB，检查是否有冗余。

嗯，这里要注意，有些节点虽然板子上没有，但内核依赖它们来初始化总线或者时钟树。删之前一定要确认清楚，否则系统可能起不来。我建议你在删除之前，先做一次完整的启动日志分析，看看哪些节点被实际访问了。

启动时间测量与优化技巧：用数据说话

优化启动时间，第一步是测量。没有数据，你就是在瞎猜。我常用的方法有三种：

• GPIO示波器法：在U-Boot和内核的关键位置翻转GPIO，用示波器测量时间间隔。最准确，但需要硬件支持。
• printk时间戳：内核启动时，每个printk都会带时间戳。通过dmesg可以精确看到每个阶段的耗时。
• bootgraph工具：内核自带的一个工具，可以生成启动过程的图形化时间线。

我个人最常用的是GPIO法，因为它不受软件干扰。但如果你没有示波器，printk时间戳也够用。

下面这张图，是我总结的启动优化流程，你可以照着这个思路来：

优化技巧方面，我总结几个实战经验：

• U-Boot阶段：去掉不必要的延时等待，比如有些板子在初始化网络PHY时会等1秒，其实可以改成轮询方式。
• 内核解压：如果Flash读取速度是瓶颈，可以开启DMA或者使用双缓冲。
• 设备树：把不用的节点删干净，尤其是那些status="okay"但实际没接设备的节点。
• 内核配置：关闭不需要的驱动和子系统，比如你不需要蓝牙，就别编译蓝牙驱动。

最后，我想强调一点：启动优化不是一锤子买卖。每次修改硬件或者升级内核，启动时间都可能变化。我建议你把启动时间测量脚本化，每次构建固件后自动跑一遍，一旦发现启动时间变长，立刻报警。这样你就能在问题扩散之前把它扼杀在摇篮里。