梳理项目，发现了之前很多没有思考的地方。
以下资料来源：NXP 公开资料
专有名词
Imx8qxp：NXP 芯片系列
OTP：单次编程属性。
efuse：保险熔断区
fuse：写入保险熔断区
close：保险熔断
SRK：安全根密钥 secure root key
目的：通过对镜像签名，达到系统可信加载。防止不可信镜像和被破坏的镜像的加载。
方式：通过签名验签方式进行可信身份认证。
准备阶段：
1、证书相关的准备，生成 证书（多个）和对应私钥（多个）。
2、对证书处理、生成table.bin （多证书集合）、table_fuse_sha512.bin(将table.bin sha512处理，64字节、作为根密钥 )
3、打开编译选项，获取镜像偏移地址。uboot.img 大小略为 1.6M
4、编写 uboot.txt 文档。采用签名工具指定对应的私钥进行镜像签名
输入：偏移地址，公钥（table) 公钥子序号（index） 私钥 待签名镜像（uboot 和 spl）
输出：签名后的镜像 镜像后缀 table
5、fuse 写入、table_fuse_sha512.bin 采用16进制处理后进行 fuse 写入。
uuu 模式写入
ahab 状态查询
ahab 熔断 。熔断后，写入的值无法更改。
?
6、系统自处理。
加载后采用镜像后的偏移地址，获得公钥表（table） 和应该使用的子序号。然后进行 sha512 处理。处理后和 fuse 内容比对。
对比成功则认为证书可信，
采用 table （序号公钥）对镜像进行验签，验签成功，镜像可信。
正常启动。
思考：
1、产线过程产线工人进入uuu 模式进行设置，会影响整个产线效率。
2、车机启动---uuu 模式--完成设置-再重启， 两次车机启动。还是效率问题。
在 boota 阶段。通过系统启动源码修改完成?fuse 写入、
写入后直接加载后直接代码里完成 ahab status 检测和 close 熔断。
引入问题：代码可信问题。也就是相当于把超级密钥写入了代码里。
（同态加密变异引入--是否可以解决这类问题）
签名：
签名输入txt详情： 包含公钥和序号
?相关 key 的关系：
大小：
?摘要：可以看出公钥xxx? ?5e 开头的摘要
?12345678 对应的摘要
对应关系：12345678 对应的私钥
?完成私钥公钥对应。