DRA7xx平台Linux启动时间从6.7秒优化至2.9秒全解析

1. 项目概述

在嵌入式系统开发领域，尤其是汽车电子、工业控制和智能设备中，系统的启动速度是一个至关重要的性能指标。想象一下，当你启动一辆汽车的中控系统，或者启动一台工业产线上的控制设备，如果系统需要花费近7秒的时间才能进入可操作状态，这不仅影响用户体验，在某些紧急或实时性要求高的场景下，甚至可能带来安全隐患或效率损失。因此，如何将系统启动时间从“秒级”压缩到“亚秒级”，是每一位嵌入式工程师都需要面对的挑战。

我最近在基于德州仪器（TI）的DRA7xx系列处理器平台上，进行了一次深入的Linux系统启动时间优化实践。这个平台广泛应用于高级驾驶辅助系统（ADAS）和车载信息娱乐系统（IVI），对启动速度有着严苛的要求。我们的目标非常明确：将系统从上电复位到进入用户空间（Userspace）的总时间，从原始的6.7秒大幅缩短。经过一系列从硬件选型、引导流程到内核配置的精细调整，最终我们成功地将启动时间优化到了2.9秒，实现了超过56%的性能提升。这篇文章，我将详细拆解这次优化的完整思路、具体步骤、踩过的坑以及最终验证的方法，希望能为面临类似挑战的同行提供一个可复现的参考案例。

2. 核心优化思路与方案选型

启动优化不是一个单点问题，而是一个系统工程。在动手之前，我们必须对整个启动流程有一个全局的、量化的认识。DRA7xx平台的典型Linux启动流程可以简化为几个关键阶段：芯片上电后，首先运行在ROM中的第一级引导程序（Boot ROM），然后加载并运行SPL（Secondary Program Loader，通常就是MLO），接着是第二阶段的引导加载程序（如U-Boot），最后由U-Boot加载并启动Linux内核，内核初始化完成后跳转到用户空间的init进程。

2.1 量化分析：找到瓶颈在哪里

盲目优化是效率最低的做法。我们的第一步是建立精确的基准测试（Benchmarking）体系。原始文档中提供了一个非常关键的数据对比表：

从数据中可以一目了然地看出，内核启动阶段（t3）是绝对的性能瓶颈，占据了总启动时间的93%以上（优化前）。因此，我们的优化火力必须集中在内核上。同时，引导加载程序也有近60ms的优化空间，蚊子腿也是肉。

2.2 关键决策：启动介质与引导模式

在制定具体优化策略前，有两个架构层面的决策至关重要，它们直接决定了优化的上限。

2.2.1 启动介质选择：为什么是QSPI NOR？

DRA7xx支持多种启动介质，如eMMC、NAND、QSPI NOR等。选择哪种介质对启动速度有根本性影响。我们主要对比了eMMC和QSPI NOR：

• eMMC：容量大，适合存储根文件系统，但其初始化过程相对复杂，涉及控制器上电、CMD线训练、识别设备等步骤，会引入几十到上百毫秒的固定延迟。对于尺寸较小的引导加载程序和内核镜像，这个初始化开销占比过高。
• QSPI NOR Flash：作为一种简单的线性存储设备，其初始化速度极快。控制器上电后，几乎可以立即开始读取数据。虽然其绝对读取速率可能不如eMMC，但对于小体积的引导镜像（MLO、U-Boot、内核）的加载，其“快速就绪”的特性带来了巨大优势。

结论：我们将MLO、U-Boot、内核镜像和设备树（DTB）全部放置在QSPI NOR Flash中，而将庞大的根文件系统放在eMMC里。这样，在关键的早期启动阶段，我们利用了QSPI的快速初始化特性；在需要大容量存储时，再初始化eMMC。

2.2.2 引导模式选择：单阶段启动（Falcon Mode）

标准的U-Boot是一个功能丰富的“小型操作系统”，它提供了命令行、环境变量、灵活的引导脚本等功能，但这些灵活性是以启动时间为代价的。在我们的优化场景中，启动参数、内核位置等都是确定的，不需要U-Boot的交互功能。

因此，我们启用了单阶段启动模式（也称为Falcon Mode）。在这个模式下，SPL（MLO）在完成最基本的硬件初始化后，不再跳转到完整的U-Boot，而是直接加载并启动Linux内核。这相当于“砍掉”了U-Boot第二阶段，节省了至少一秒的启动时间。代价是失去了U-Boot的调试和配置灵活性，但在产品化阶段这是完全可以接受的。

注意：启用单阶段启动后，内核启动参数（bootargs）无法再通过U-Boot环境变量传递，必须直接编译进设备树（DTB）的chosen节点中。这是一个关键的技术细节，后续配置中会具体说明。

3. 内核深度优化：从6.2秒到2.5秒的魔法

内核优化是本次实践的重头戏，目标是砍掉那多余的近3.8秒。我们的策略可以概括为：“减负、提速、静默”。

3.1 内核压缩算法选型：LZO的胜利

内核镜像通常以压缩格式存储，以节省Flash空间，启动时在内存中解压。压缩率越高，镜像越小，加载越快，但解压计算开销越大。这是一个需要权衡的经典问题。

我们对比了内核支持的几种压缩格式（gzip, LZO, LZ4等）在DRA7xx A15内核上的表现：

• gzip：压缩率高，镜像体积最小，但解压算法复杂，CPU耗时最长。
• LZO/LZ4：压缩率稍低，镜像体积稍大，但解压速度极快，算法设计为追求解压性能。

在我们的测试中，LZO压缩格式提供了最佳的综合权衡。虽然它的镜像比gzip格式大了约10%，但解压时间从优化前的1651ms骤降至49ms！这节省的1.6秒是“白捡”的。对于从QSPI加载镜像，这点体积增加带来的加载时间增长微乎其微，完全被解压时间的巨大节省所覆盖。

配置方法：在内核配置菜单中，执行make menuconfig，进入General setup->Kernel compression mode，选择LZO compression。

3.2 内核配置的精简：做减法艺术

默认的SDK内核配置为了兼容各种潜在用例，开启了大量可能用不到的功能和驱动。每一个被编译进内核的模块，都会增加镜像大小，并在初始化时消耗CPU时间。我们的原则是：非必需，则移除；非紧急，则模块化。

以下是核心的精简策略，对应文档中的ti_config_fragments/boot_opt.cfg文件：

3.2.1 文件系统模块化除非你的根文件系统是EXT4，否则将其他文件系统支持（如EXT2/3, FAT, VFAT, CRAMFS）全部编译为模块（=m）或直接禁用（=n）。内核在初始化时不需要加载这些模块的代码。

CONFIG_EXT2_FS=m CONFIG_EXT3_FS=m CONFIG_FAT_FS=m CONFIG_VFAT_FS=m CONFIG_CRAMFS=n

3.2.2 外设驱动模块化对于当前启动阶段不需要的硬件，将其驱动设为模块。例如，MTD（Flash驱动）、NAND、QSPI控制器、SCSI、ATA、CAN总线等。同样，如果硬件平台不需要PCIe，直接禁用。

CONFIG_MTD=m CONFIG_MTD_NAND=m CONFIG_SPI_TI_QSPI=m CONFIG_SCSI=m CONFIG_CAN=m CONFIG_PCI=n CONFIG_PCI_DRA7XX=n

3.2.3 性能调优配置

• CPU频率调节器（Governor）：在启动阶段，我们希望CPU全力运行。将默认调节器设置为performance，可以避免动态调频带来的延迟和性能波动。

  CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y

• I/O调度器（Elevator）：对于嵌入式设备，尤其是从Flash启动的场景，简单的noop调度器往往比复杂的CFQ或Deadline调度器效率更高，因为它减少了内核的调度开销。 （此选项通过内核启动参数elevator=noop设置）

3.2.4 剥离调试信息调试功能对开发至关重要，但对最终产品的启动速度是纯粹的负担。

• CONFIG_DEBUG_FS=n：禁用调试文件系统。
• CONFIG_KPROBES=n：禁用动态内核探测。
• CONFIG_DEBUG_INFO=n：禁止在内核镜像中包含DWARF调试信息，这能显著减小内核体积。
• CONFIG_KALLSYMS=n：禁用内核符号表，进一步减小体积并略微提升安全性。

实操心得：配置精简是一个迭代过程。最稳妥的方法是，先基于一个能正常启动的配置，然后逐一检查System.map文件和内核日志，将初始化阶段调用的、但你确认不需要的功能模块化或禁用。也可以利用initcall_debug内核参数来观察每个初始化函数的耗时，进行精准打击。

3.3 启动参数优化：让内核“闭嘴”

内核启动时，串口（UART）输出大量的调试信息是拖慢启动的另一个元凶。每一行打印都需要CPU时间，并且受限于串口波特率（通常是115200），大量打印会造成严重的阻塞。

关键优化：在内核启动参数中设置loglevel=0（或quiet）。这将禁止除了最紧急消息（KERN_EMERG）之外的所有内核打印。实测中，仅此一项就能节省数百毫秒的启动时间。同时，结合之前提到的elevator=noop和consoleblank=0（防止控制台自动黑屏），构成了优化的启动参数集：

elevator=noop console=ttyS0,115200n8 cma=64M omapdrm.num_crtc=1 consoleblank=0 snd.slots_reserved=1,1 fixrtc loglevel=0 root=/dev/mmcblk0p4 rootfstype=ext4 rw rootwait

4. 引导加载程序（U-Boot/SPL）的微调

在单阶段启动模式下，完整的U-Boot不再运行，我们的优化重点放在了SPL（即MLO）上。

4.1 禁用SPL中的环境变量支持

SPL通常设计得非常精简，但某些配置可能默认包含了环境变量（env）支持，以便从存储设备读取U-Boot的配置。在单阶段启动中，SPL直接跳转内核，不需要这些环境变量。禁用它可以减少SPL的代码体积和初始化步骤。 对应文档中的U-Boot补丁dra7xx_evm: spl: disable env support即实现了此功能。

4.2 为基准测试植入“探针”

为了精确测量每个阶段的耗时，我们在SPL和内核的关键代码路径中插入了时间戳采集点。这依赖于DRA7xx SoC内部的一个32KHz时钟计数器，它在芯片复位后很快就能运行，并且所有核心都能访问，提供了跨阶段统一的时间基准。

在SPL中，我们在以下位置采集时间点：

• m-entry-time: SPL开始执行的时刻（近似Boot ROM结束）。
• m-boardinit-time: 进入板级初始化函数的时刻。
• m-image-load-dur: 加载内核和DTB镜像的耗时。
• m-kernelstart-time: SPL跳转到内核入口点的时刻。

这些时间戳数据通过修改设备树（DTB）中chosen节点的属性，从SPL传递到Linux内核。内核在启动后，可以读取这些属性，并与自身记录的时间戳一起，在/proc/device-tree/chosen/目录下呈现完整的启动时间线。我们提供的readproc用户空间工具会自动将这些32KHz时钟计数值转换为毫秒，方便阅读。

5. 完整实操流程与配置记录

理论说再多，不如一步步做出来。以下是基于TI Processor SDK Linux Automotive 3.02版本的完整操作流程。

5.1 软件与硬件环境准备

• 软件：TI Processor SDK Linux Automotive 3.02。确保你的主机开发环境可以正常编译U-Boot和内核，并能通过SD卡启动EVM开发板。
• 硬件：DRA7xx Rev H EVM开发板，一块1280x800分辨率的LG LCD屏幕（或其他兼容屏幕，需对应修改设备树文件），串口调试线，USB线。

5.2 源码修改与补丁应用

首先，确保你的U-Boot和内核代码基于文档指定的基准提交（Commit ID）。

1. 应用U-Boot补丁：按照文档中表3的顺序，应用8个补丁。这些补丁主要分为三类：

• 基准测试类（补丁5,6,7）：增加时间戳记录和传递功能。
• 优化类（补丁8,9）：调整配置选项，禁用SPL环境支持。
• 刷写工具类（补丁1-4）：增强fastboot工具，方便对QSPI和eMMC进行分区和烧录。

  cd <your-u-boot-dir> # 使用git am或patch命令依次应用补丁

2. 应用内核补丁：按照文档中表4的顺序，应用6个补丁。这些补丁同样包括基准测试支持和优化配置。

• 关键补丁ti_fragments: add configuration options to reduce boot time.提供了我们之前讨论的内核优化配置文件boot_opt.cfg。
• 补丁dra7: dts: disable mmc4 to save on boot time禁用了未使用的MMC4控制器，减少内核探测时间。

  cd <your-kernel-dir> # 应用内核补丁

3. 配置内核：应用补丁后，需要确保优化配置被包含进最终的内核.config文件。

make ARCH=arm <your_defconfig> # 例如：dra7xx_evm_defconfig ./ti_config_fragments/merge_config.sh .config ti_config_fragments/boot_opt.cfg make ARCH=arm olddefconfig # 解析新配置，使用默认值处理新选项

5.3 构建与烧录系统

1. 构建U-Boot：编译后，将生成的MLO和u-boot.img复制到SD卡的FAT分区。

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- dra7xx_evm_defconfig make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- # 假设SD卡挂载在 /media/boot cp MLO u-boot.img /media/boot/

2. 构建内核与设备树：编译内核，并使用mkimage工具将zImage封装为U-Boot可引导的uImage格式（单阶段启动需要）。

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- uImage dtbs LOADADDR=0x80008000 -j$(nproc) # 生成uImage mkimage -A arm -O linux -C none -T kernel -a 0x80008000 -e 0x80008000 -n 'Linux uImage' -d arch/arm/boot/zImage uImage

3. 修改设备树以嵌入启动参数：由于是单阶段启动，内核参数必须编译进DTB。使用fdtput工具（来自dtc工具包）修改。

# 假设使用 dra7-evm-lcd-lg.dtb BOOTARGS="elevator=noop console=ttyO0,115200n8 cma=64M omapdrm.num_crtc=1 consoleblank=0 snd.slots_reserved=1,1 fixrtc loglevel=0 root=/dev/mmcblk0p4 rootfstype=ext4 rw rootwait" fdtput -v -t s "dra7-evm-lcd-lg.dtb" "/chosen" bootargs "$BOOTARGS"

注意：console=ttyO0对应DRA7xx的UART0，请根据你的实际硬件连接确认串口设备名。

4. 通过Fastboot烧录至QSPI：

• 将EVM设置为SD卡启动模式，进入U-Boot命令行。
• 执行fastboot 0命令使设备进入Fastboot模式。
• 在主机上，使用fastboot工具依次烧录镜像到QSPI的相应分区：

  fastboot flash xloader MLO fastboot flash bootloader u-boot.img fastboot flash kernel uImage fastboot flash environment dra7-evm-lcd-lg.dtb # 此处‘environment’分区名存放DTB fastboot oem format # 初始化eMMC分区表

5. 通过USB Mass Storage拷贝根文件系统：

• 在U-Boot命令行中，执行ums 0 mmc 1将EVM的eMMC作为U盘挂载到主机。
• 在主机上挂载该eMMC的分区（通常是第四个分区），并用rsync同步根文件系统。

  sudo mount /dev/sde4 /mnt/emmc # 请根据实际情况替换 /dev/sde4 sudo rsync -av --delete /path/to/sdk/targetfs/ /mnt/emmc/ sudo umount /mnt/emmc

• 同步完成后，将EVM启动模式开关改为从QSPI启动，重启。

5.4 验证优化结果

系统启动后，登录串口终端，执行提供的脚本读取启动时间明细：

target # readproc; sh /etc/visualization-scripts/list-boot-time.sh

你将看到类似下面的输出，其中k-user-space-entry-time就是内核启动完成的最终时间戳（从复位开始计算）。用这个值减去m-entry-time（Boot ROM结束时间），就得到了总的用户空间到达时间。优化后，这个值应该在2849ms（约2.85秒）左右。

6. 常见问题排查与进阶技巧

在实际操作中，你可能会遇到一些问题。这里记录一些典型的排查思路和进阶优化方向。

6.1 问题排查速查表

6.2 进阶优化思路

当通用优化手段用尽后，可以针对你的具体应用场景进行深度定制：

1. 基于Initcall的精准裁剪：Linux内核的初始化函数是通过initcall机制按优先级调用的。你可以使用内核参数initcall_debug来打印每个initcall的耗时。分析输出，找出那些耗时较长但又与你的应用无关的初始化模块（例如，你不用的摄像头驱动、音频驱动等），将其彻底编译为模块或禁用。

2. 延迟初始化（Deferred Init）：对于非启动必须的硬件或服务，可以考虑将其初始化推迟到用户空间，或者在内核启动完成后，由专门的守护进程来加载。这能显著减少内核阶段的耗时。

3. 用户空间启动优化：本文聚焦于内核及之前的优化。到达用户空间后，系统的启动速度取决于你的init系统（如systemd, busybox init）和需要启动的服务。优化手段包括：并行启动服务、禁用不必要的服务、使用静态链接的BusyBox减少动态链接开销、优化文件系统挂载选项（如使用noatime）等。这是一个同样深广的领域。

4. 自定义基准测试点：文档中提供了在SPL和内核中添加自定义时间戳测量的方法。你可以将“探针”插入到你怀疑的耗时函数中，例如某个复杂外设的驱动初始化函数，从而获得更细粒度的性能分析数据，指导你的优化方向。

这次将DRA7xx平台Linux启动时间从6.7秒优化到2.9秒的实践，本质上是一次对系统启动链路的全栈审视和精细化手术。它告诉我们，显著的性能提升往往来自于对每个环节“理所当然”的设定的重新思考：从存储介质的选择、引导路径的裁剪，到内核配置的极致精简。这个过程没有银弹，依靠的是科学的测量（基准测试）、大胆的假设（架构决策）和小心的验证（逐步优化）。希望这份详细的记录能成为你手中一份可靠的“地图”，当你在追求更快的启动速度时，知道从哪里开始，以及可能会遇到什么样的“地形”。