先看arm官网提供的一张图:
上图详细概括了arm官方推荐的armv8的启动层次结构:
官方将启动分为了BL1,BL2,BL31,BL32,BL33阶段,根据顺序,芯片启动后首先执行BL1阶段代码,接着验签启动BL2,BL2根据具体设计启动BL31或者BL33,BL32只有在有BL31时才可能会存在并被验签加载启动。
armv8分为Secure World和Non-Secure World(Normal World),四种异常级别从高到低分别为EL3,EL2,EL1,EL0。
• Secure World就是可以执行可信的firmware和app,比如密码支付,指纹识别等一系列依赖安全保证的服务。
• Non-Secure World就是我们常见的u-boot,linux,qnx等裸机程序或者操作系统。
• EL3具有最高管理权限,负责安全监测和安全模式切换。
• EL2主要提供了对虚拟化的支持。
• EL1是一个特权模式,能够执行一些特权指令,用于运行各类操作系统,在安全模式则是可信任OS。
• EL0是无特权模式,所有APP应用都在EL0。
上图中的BL1,BL2,BL31,BL32,BL33分别对应如下功能:
• BL1:是一切信任的根,一般就是固化在ROM中的一段启动加载代码,用于引导bl2,并对bl2进行验签保证可信任执行;
•BL2:一般是在flash中的一段可信安全启动代码,它的可信建立在bl1对它的验证,主要完成一些平台相关的初始化,比如对ddr的初始化等,并在完成初始化后寻找BL31或者BL33进行执行;如果找到了BL31则不会继续调用BL33,如果没有BL31则BL33必须有;
•BL31:BL31不像BL1和BL2是一次性运行的,它作为最后一道可信任固件存在,在系统运行时通过smc指令陷入EL3调用系统安全服务或者在Secure World和Non-Secure World之间进行切换;在完成BL31初始化后会去寻找BL32或者BL33进行验签后加载执行;
• BL32:OPTee OS + 安全app,它是一个可信安全的OS运行在EL1并在EL0启动可信任APP(上述的指纹验证等app),并在Trust OS运行完成后通过smc指令返回BL31,BL31切换到Non-Seucre World继续执行BL33;
• BL33:非安全固件,也就是我们常见的UEFI firmware或者u-boot也可能是直接启动Linux
kernel;启动BL1,BL2,BL31,BL32则是一个完整的ATF信任链建立流程(ARM Trusted Firmware),像常见的PSCI(Power State Coordination Interface)功能则是在ATF的BL31上实现;
最后一张图完整展示整个调用流程:
BL2根据是否存在BL31和BL32可选择性的加载不同firmware;
综上所述可知u-boot是一个运行在非安全世界的bootloader,负责加载各类操作系统,并提供丰富的驱动接口;
并根据是否存在安全固件还可以进行不同的boot流程,如下。
•u-boot,u-boot-spl,u-boot-tpl的关系:对于一般嵌入式而言只需要一个u-boot作为bootloader即可,但是在小内存,或者有atf的情况下还可以有spl,tpl;
• spl:Secondary Program Loader,二级加载器
• tpl:Tertiary Program Loader,三级加载器
出现spl和tpl的原因最开始是因为系统sram太小,rom无法在ddr未初始化的情况下一次性把所有代码从flash,emmc,usb等搬运到sram中执行,也或者是flash太小,无法完整放下整个u-boot来进行片上执行。
所以u-boot又定义了spl和tpl,spl和tpl走u-boot完全相同的boot流程,不过在spl和tpl中大多数驱动和功能被去除了,根据需要只保留一部分spl和tpl需要的功能,通过CONFIG_SPL_BUILD和CONFIG_TPL_BUILD控制;
一般只用spl就足够了,spl完成ddr初始化,并完成一些外设驱动初始化,比如usb,emmc,以此从其他外围设备加载u-boot,但是如果对于小系统spl还是太大了,则可以继续加入tpl,tpl只做ddr等的特定初始化保证代码体积极小,以此再次从指定位置加载spl,spl再去加载u-boot。
从目前来看,spl可以取代上图中bl2的位置,或者bl1,根据具体厂商实现来决定,有一些芯片厂商会将spl固化在rom中,使其具有从emmc,usb等设备加载u-boot或者其他固件的能力。
当然在有atf的情况下可以由atf加载u-boot,或者由spl加载atf,atf再去加载u-boot。
甚至在快速启动的系统中可以直接由spl启动加载linux等操作系统而跳过启动u-boot;
在上图中arm官方只是给出了一个建议的启动信任链,具体实现都需要芯片厂商来决定;
后续分析启动流程中会在具有SPL和TPL的地方拓展它们的分叉执行路径尽量把SPL和TPL的功能也一并分析;
全部0条评论
快来发表一下你的评论吧 !