本文是安全启动的第二次跳转，由TF-A BL2启动U-Boot与OP-TEE，对应第一篇文章中的这个部分。这次会加载并运行2个部分的代码，并且复杂程度较高，我只能按我理解到的程度来写

一.TF-A结构体系

首先了解一下TF-A的结构体制，TF-A被分为好几个部分，如下图所示

这个是不是很熟悉，和第一张图几乎一摸一样，只是文字内容不一样。这张图是一个通用的东西，其中的BLXX就是一些通用的名称，他们的解释如下：

BL1：Boot loader stage 1，应用程序信任的ROM

BL2：Boot loader stage 2，可信的引导固件

BL32：Boot loader stage 3-2，runtime software（我不知道这个应该翻译成什么比较合适）

BL33：Boot loader stage 3-3

在MP1上，是没有BL1的，BL1被我们的ROM Code，也就是BootRom所代替

BL2在MP1上对应TF-A BL2

BL32在MP1上对应OP-TEE

BL33在MP1上对应U-Boot

二.TF-A加载后续软件的方式

TF-A加载后续软件的方式使用的是叫FIP的方法（FIP = Firmware Image Packge），顾名思义就是很多的固件打包在一起，如下图所示

可以看到里面有很多东西，总的来说就是一个cgf文件、多个U-Boot相关的文件、多个OP-TEE相关的文件

其中cfg文件是比较重要的，他的名字叫FCNF（Firmware Configuration Framework），他其实就是一张表，通过它就可以知道FIP中各个部分的内容是什么，相互之间怎么校验，各部分关系怎么样等等

三.TF-A BL2证书信任链的结构

在各个image校验之前，需要学习一下各个证书的校验链，我个人理解一下就是，固件可以通过证书校验，但是谁能知道证书是否被伪造呢？所以就有这个证书链，通过一个最基础的信息，一环套一环的对每个证书进行校验，确保所有的证书都是没有被篡改的

整体流程如下

他这个就是一环套一环，设计的非常巧妙。

简单来说就是通过上一级所携带的key（是PB Key）来校验他下一级的证书所用到的PB Key

这边记录一下一些名字所实际代表的东西

HW Config：U-Boot的设备树

四.MP1 TF-A BL2启动U-Boot与OP-TEE的证书与校验

完整的流程如下

首先我们先看第一个根证书，content证书

他是没有副证书来校验自己的PB Key是否真实有效的，那么这边是使用的是OPT中保存的PB Key的HASH来做校验的。当PB Key的hash与OTP中的一致，那就认为是OK的，那他就可以自己校验这个证书自己，从而得到证书中HW和FW Config HASH的内容是OK的，就可以用于校验HW/FW config

第二个根证书是秘钥证书，同理，他也是用了OTP中的hash，从而得到这个证书里面2个秘钥的真实性

这两个秘钥证书又会向后一步一步最终得到各个image的hash，用于校验image，这儿我就不再多说了，大致意思和上面的类似

五.总结

其实TF-A BL2启动U-Boot与OP-TEE的核心思想还是通过证书验证image是否正确，只是他还多了证明证书是正确的步骤，并且它的iamge很多，所以显得流程特别复杂，步骤很多，但是核心思想和上一篇的BootRom启动FSBL(TF-A BL2)是一样的，只是需要耐心的去理解它的详细流程