当前位置: 首页 > news >正文

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

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 内启动

http://www.agseo.cn/news/72/

相关文章:

  • 周总结报告5
  • 使用模拟库进行测试的意义是什么?
  • MyEMS:开源领域的能源管理创新解决方案
  • 【Containerd交互命令】ctr、crictl常用基本命令
  • DAG Matters! GFlowNets Enhanced Explainer For Graph Neural Networks | |
  • abap字符串操作
  • [完结16章]COZE AI 智能体开发体系课(从入门到高级)零基础零代码
  • 推出其新一代高性能Sub-GHz射频收发芯片UM2011A
  • 在 Athena UDF 中使用 Java 将数据写入 DynamoDB
  • Pychram 激活
  • 掌控AI编程全链路:Cline让你随意选模型、透明成本、零信任安全 - 公众号
  • 数据库事务隔离级别引发的应用安全竞态条件漏洞分析
  • Node-Red学习笔记
  • 隧道工程LoRa无线监测设备集成方案 直击隧道深部监测痛点
  • 【k8s】为什么ctr导入后通过crictl查看不到导入的镜像
  • Swift 结合 Tesseract 进行验证码识别
  • 当虚拟机目录空间不足时的扩容
  • 使用IText创建PDF
  • MyEMS 深度解析:碳管理赋能与系统集成的实践路径
  • uv包管理 - 小学弟
  • 对口型视频创作指南:AI如何让“假唱”变成真艺术?
  • 用Python + Tesseract OCR:验证码识别全流程解析
  • Dockerfile中的yum install、yum clean和rm -rf /var/cache/yum
  • Linux 完整的用户登录工作流程详解(GUI TTY)
  • 0 元夺宝小程序介绍
  • 线上频繁FullGC?慌得一比!竟是Log4j2的这个“特性”坑了我
  • clickhouse进程stop之后为什么还自动启动
  • 294、瑶池
  • Unix/Linux 高效的平台通过 IP 地址获取接口名的 C++ 构建
  • 每周读书与学习-初识JMeter 元件(一)