ARM 自己编的BL1必须什么是8k纸吗?

来源：蜘蛛抓取(WebSpider) 时间：2019-04-07 00:43 标签： bl游戏

指的注意的是arm设计的一个方案昰BL2在EL1上运行（另一个方案是在EL3）BL1将控制权交给secure EL1（AArch64）或安全SVC模式（AArch32）的BL2image，从其加载地址开始

  1. 此函数返回的指针必须指向包含BL1阶段的安全RAM的范围和可用性的meminfo结构。
  2. BL1使用此信息将BL2映像加载到安全RAM中 BL1还填充了一个类似的结构，告诉BL2可供自己使用的内存范围

代码中直接返回一个靜态结构体变量：

红色部分为bl2可用的sram大小

92行，初始化上下文管理为退出el3做准备

描述的很清楚，先恢复默认值：

已经把EL3上的一些寄存器污染了需要reset下，然后根据SPSR_EL3的状态以及下一个EL的安全状态和入口点属性更新为所需的值

给sctlr变量赋值，用于后续设置sctlr_el1寄存器：

  1. 准备CPU系统寄存器以便首次进入安全或正常的世界
  2. 对于所有入口，EL1寄存器是从cpu_context初始化的

这个函数严格遵循AArch64 PCS使用x9-x17（临时调用者保存的寄存器）来恢复EL1系統寄存器上下文。 它假定'x0'指向'el1_sys_regs'结构从中恢复寄存器上下文。

这个函数用于读写用于异常返回的上下文初始化SP_EL3为指向为所需安全状态设置的“cpu_context”的指针:

首先，这个函数假定SP_EL3指向一个有效的ctx保存secure 状态下的bl2相关寄存器值

  1. 保存当前的SP_EL0即将用于处理下一个SMC的EL3运行时堆栈。 然后切換到SP_EL3
  2. 恢复保存的gp寄存器并返回EL1

对于执行ATF BLX 总是通过ERET（异常返回）指令执行下一阶段的BLx。而执行RERT指令所在的BLx在ARM的设计思想（ARM的Trust Boot规范）里，總是由Secure EL状态执行基本上就是在EL3上执行。

而对于加载BLx加载本身不涉及到安全，而且会使用外设和外部memory则可以在Non-Secure EL上加载。

所以ARM ATF(这套代碼其实主要是linaro写的，你会发现ATF和OPTEE的设计思路函数命名，调用实现方式都是类似的)加载在运行在Non-Secure EL的Blx上执行，跳转是运行在Secure EL的Blx上执行例洳，BL1（EL3）跳到BL2(NS-EL1)BL2加载BL31,BL32,BL33，甚至是kernel通过SMC指令陷入到EL3,此时EL3上异常入口还是在BL1上设置的，自然就返回到BL1上处理BL1通过传递的EP info等参数，配置SCRSPSR等寄存器，执行RERT就返回到了下一阶段的BLx上，开始执行代码

在EL3上执行的BL主要有两个：BL1和BL31。当然BL2也有BL2 AT EL3这种形式的存在，这主要是给那些ROMCODE（BL1）鈈符合trust boot规范的厂商准备的

所以，ATF在设计上充分考虑了各个SoC厂家的可移植性可能也是出于推行Trust boot规范和atf的考虑，基本上只要厂家愿意投入時间和人力都可以很好porting到ATF上。

我要回帖

更多关于 bl游戏 的文章

 

随机推荐