文章讲述了Linux系统在嵌入式领域的应用，尤其是强调了在高响应速度需求的设备中面临的实时性和快速启动的挑战。尽管Linux的实时性相对较弱，但开发者通过RTLinux、双内核等方案进行优化。在瑞芯微的RK3588平台上，实现了约1秒的快速启动，主要通过优化Bootloader、Kernel配置和启动脚本来达成。然而，由于ARMv7/v8的安全启动机制，涉及ATF（ARMTrustFirmware），使得Bootloader优化变得复杂。作者详细描述了启动流程和尝试跳过不同阶段的挑战，最终成功跳过uboot，实现了快速启动。
Linux强大的功能、卓越的硬件兼容性、优秀的模块化设计，使其不仅在服务器和非x86桌面系统中占据主导地位，在嵌入式系统领域也越来越被广泛应用，而某些嵌入式设备对系统的响应速率要求很高，包含两方面的需求，一方面是指设备上电或复位快速启动系统；另一方面要求设备启动后，系统能对外部事件作出快速反应。
Linux作为宏内核系统，其实时性比不上VxWorks/VRTX/uCos等微内核系统，不过全球有无数开发人员在孜孜不倦地为提高Linux系统的实时性贡献代码，已有RTLinux、双内核系统等优化方案，望获Linux的攻城狮们也提出了自己的实时性优化改造方案，并在加紧垒码实现中，待有实际成果再给大家分享。
快速启动对于嵌入式应用的重要性也不言而喻，就像快速反应部队，必须在受到攻击前整装完毕予以还击；一旦遭受意外干扰卡壳宕机，能在看门狗的驱使下快速重启。近期，望获Linux在瑞芯微的RK3588平台上尝试实现了快速启动Linux系统功能，从上电到登录耗时约1秒，其中包含厂家的bootstrap二进制代码时间。
Linux系统启动包括三个阶段，Bootloader（BIOS）、Linux kernel、Linux app（命令脚本），最后进入登录界面。后两个阶段相对比较好优化，第二阶段我们把kernel配置裁剪到尽量小，关闭图形输出、静默串口打印输出、关闭启动阶段不必用的外设；第三阶段基于busybox制作小型根文件系统，尽量简化启动脚本。最难的是第一阶段的优化。
我们在RK3588平台上使用uboot作为Bootloader，在以前的arm、mc68k、powerpc、mips或者dsp平台中，其Bootloader比如：uboot、redboot、ppcboot、cfe、pmon、bios（TI）的所有代码都是开源并充分足够的，也就是说系统启动第一阶段的代码我们都是可以修改简化的，对这些代码越熟悉，就能越彻底优化bootloader，更加缩短启动时间，我们甚至可以自己写一段简单的初始化代码，然后直接启动Linux 系统（这个我们十多年前在自制的龙芯2F开发板上已经实现），但是，ARMv7/v8之后加入了安全启动机制，光有uboot并不足以启动系统，在uboot之前以及内核启动多核的过程中还需要运行厂家提供的ATF（ARM Trust Firmware）代码，完整的ATF包括BL1/BL2（SPL）/BL31/BL32（OPTEE）/BL33（uboot/uefi），其中SPL和uboot整合在统一的uboot源码中，编译uboot时可以选择编译spl，而BL1/BL31/BL32厂家通常只提供二进制文件以及将其与uboot链接到一起的工具，这使优化Bootloader变得很困难。
带ATF系统的正常启动流程是BL1->BL2（SPL）->BL31->BL32（OPTEE）->BL33（uboot）->Linux kernel->app，基于此，最理想的优化方式：BL1直接启动kernel，因没有BL1源码而无法实现；其次：从SPL直接跳转到kernel，我们做了很多尝试，均告失败。SPL运行在EL3级别，kernel运行在EL1级别，SPL本身没有从EL3切换到EL1，这个工作由BL31完成，每一款芯片切换级别的具体方法都不一样，在RK3588芯片手册中没找到切换操作以及相关寄存器说明，咨询厂家也不提供技术支撑，这种情况下我们只能摸黑一点一点尝试跳过BL31、BL32、BL33，反复试验后确认只能跳过BL33（uboot）阶段，BL1/BL31/BL32等二进制阶段都跳不过去。
为了完整跳过uboot，尽量缩短启动时间，我们又花了不少时间对spl和kernel源码做了修改，最终在RK3588平台上实现了1秒快速启动Linux系统。
扫一扫
3034
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
