首页/资讯中心/详情

Linux 启动耗时优化 1s 内启动(RK3588 平台)

Linux 启动耗时优化 1s 内启动(RK3588 平台)
📅 发布时间：2026/6/19 0:09:43

image

由于在 ARMv6 之后引入了 TrustZone 模块, 目前市面上 ARMv7 和 ARMv8 之后的系统都会包含了该模块, 这个模块由 BL1 启动, 且在 ATF(ARM Trust Firmware) 固件中, 既安全世界中引导到 BL33 (UBOOT)的系统。从 BL1 到 BL33 这个阶段耗时在 643ms 左右, 也就是说, BL33(uboot/linux/其它系统) 启动耗时如果保证在1s内启动必须压缩时间在 300~400ms 左右。

局部截取_20250908_144243

  • 对于实时性的系统而言, 400ms的优化力度难度还是比较大的, 而在 Linux 层面, 优化力度需要相当大才能做到这个程度。目前经过长时间对 SDK 源码深入分析研读, Linux 能够压缩到 1s 内启动(如果还要压缩时间需要更加高精度的裁剪)

优化力度包含了 SPL, DDR调频, ATF 固件配置, UBOOT 裁剪, LINUX (镜像搬运优化 + 内核空间初始化优化 + 用户空间初始化优化)

本人耗费了很大的时间和心力研究这方面的知识点, 以及过程中碰到问题的解决思路和办法, 整理了比较详细的文档, 防止别人抄袭, 不公开分享。需要可 SI。

boot-order

RK平台根据前级Loader代码是否开源，⽬前有两套启动⽅式：
局部截取_20250908_152311

TPL 相当于 ddr bin，SPL 相当于 miniloader。TPL+SPL 的组合实现了跟 RK 闭源 ddr.bin+miniloader
⼀致的功能，可相互替换。

U-Boot 通过使⽤不同的编译条件可以⽤同⼀套代码获取三种不同功能的Loader：TPL/SPL/U-Boot-proper。
TPL(Tiny Program Loader)和 SPL(Secondary Program Loader)是⽐ U-Boot 更早阶段的 Loader：

  • TPL：运⾏在 sram 中，负责完成 ddr 初始化；
  • SPL：运⾏在 ddr 中，负责完成系统的 lowlevel 初始化、后级固件加载（trust.img 和 uboot.img）；
  • U-Boot proper：运⾏在ddr中，即我们通常所说的"U-Boot"，它负责引导kernel；

BOOTROM => TPL(ddr bin) => SPL(miniloader) => TRUST => U-BOOT => KERNEL

SPL说明

SPL 是 Secondary Program Loader（二级程序加载器）或 Super Program Loader 的缩写。它是嵌入式系统（尤其是使用 ARM Cortex-A 系列处理器的系统）启动过程中一个非常关键但又容易让人困惑的环节。
可以把它理解为一个 “引导程序的引导程序”。

为什么需要 SPL？
要理解 SPL，首先要明白现代嵌入式系统的启动困境：

  • 片上 ROM（ROM Code）容量极小：芯片内部有一小块只读存储器（ROM），里面固化了厂家写的初始启动代码（BootROM）。它的主要任务是：从外部存储（如 eMMC、SD 卡、SPI Flash）加载下一阶段的代码到内部 SRAM 并执行。

  • 内部 SRAM 容量极小：芯片内部的 SRAM 速度极快，但容量也非常有限（通常只有几十到几百 KB）。

  • 主引导程序（U-Boot）体积巨大：功能完整的 U-Boot 可能有几百 KB 甚至上 MB 的大小，远远超过了内部 SRAM 的容量。

这就产生了一个矛盾：BootROM 需要把 U-Boot 从慢速的外部存储加载到快速的内部 SRAM 才能运行，但 U-Boot 又太大了，SRAM 装不下。SPL 就是解决这个矛盾的答案。

emmc/flash 启动

瑞芯微⽅案通常使⽤ eMMC / Flash 作为主要引导设备来启动系统。系统的引导加载器和操作系统内核
等固件存储在 eMMC / Flash 芯⽚中。主要流程为：

  1. 加电启动：
    • 当芯⽚上电时，执⾏器件内部的引导 ROM 代码。
    • 引导 ROM 负责加载引导加载器（Bootloader）到内存中。
  2. 引导加载器（Bootloader）：
    • 引导加载器是位于 eMMC / Flash 存储设备的引导分区中的⼀段特殊代码。
    • 引导加载器通常是 U-Boot 或者瑞芯微提供的⾃定义引导加载器。
    • 引导加载器负责初始化系统硬件，加载内核和⽂件系统，并将控制权转交给内核。
  3. 内核加载：
    • 引导加载器从 eMMC / Flash 的引导分区中加载 Linux 内核映像到内存中。
    • 引导加载器还可以加载设备树⽂件（Device Tree Blob，DTB）和其他必要的⽂件。
  4. 内核启动：
    • 加载的内核映像被解压缩到内存中，并开始执⾏。
    • 内核初始化硬件、设置中断、启动调度器等。
    • 内核根据设备树⽂件（DTB）的信息来配置和识别硬件设备。
    • 内核启动时会挂载根⽂件系统。
  5. ⽂件系统挂载：
    • 内核根据设备树⽂件（DTB）中的指⽰，挂载 eMMC / Flash 中的根⽂件系统。
    • 根⽂件系统可以是 ext4、FAT 等⽂件系统类型。
    • ⽂件系统挂载完成后，系统可以访问⽂件系统中的⽂件和⽬录。
  6. ⽤⼾空间初始化：
    • 初始化脚本或系统服务负责启动⽤⼾空间进程和服务。
    • ⽤⼾空间进程和服务可以根据需要启动应⽤程序、⽹络服务等。

单系统

之前使用 SPL 直接启动一个实时性系统耗时优化到了 800ms, 参考这类方法可以对 Linux 做出同样的优化方式(从上电到加载第一个脚本在 1s 内启动)。

(AMP)双系统

  • 0 ~ 1 核心跑 Linux 程序
  • 3 ~ 7 核心跑实时性系统

目前从rockchip了解到 AMP 启动如果包含 Linux, 启动核心 0 只能用来跑 Linux 应用

通过目前一系列的手段, 从上电开始算起, 将 AMP 中 Linux 启动优化到了 1.5 ~ 2s 内启动, 嵌入式实时性系统优化到了 1.2s 内启动