大家好！
由于下一次尝试中另一个线程已锁定在此处：
我正在尝试使用 AM6422芯片在我们的平台上实现安全启动。
我们设法使用 otp-keywriter 将 SMPK 和 SMEK 编程到电子保险丝。
使用 SMPK I 成功地对引导过程中的所有二进制文件进行签名、以使其通过器件身份验证。
现在、我尝试启用加密以实现 IP 保护。
这是一个粗略的地方。
我启用了"系统固件加密扩展"、使用 AES256-CBC 借助编程的 SMEK 加密二进制 文件、并补丁了在 HS 器件上安全启动的二进制文件签名后的"系统固件映像完整性扩展"—TISCI 用户指南。
我为所有二进制文件都执行了该操作。
在 U-Boot 启动 Linux 内核之前、我们会引导多个阶段的 U-Boot。
我们提供了 tiboot3.bin、tispl.bin 以及使用 Yocto/bitbake 生成的 u-boot.img。
只要我没有对任何可执行的 u-boot 二进制文件进行加密、我就可以成功引导加密的二进制文件。
tiboot3.bin
该证书不使用此处所述的扩展名： 为 HS 器件上的安全启动签名二进制文件- TISCI 用户指南、而是使用 OID 为 1.3.6.1.4.1.294.1.9的 ext_boot_info 扩展名
如果在填充 enrcyption 扩展名时对此文件进行加密、器件不再启动。
我的问题是：
- 是否可以对 tiboot3.bin 文件进行加密-是否有相关文档说明如何加密？
tispl.bin / u-boot.img
如果对两个字段内的 SPL 或 uboot 映像进行加密、器件会在引导期间停止。
当加密最后一个阶段 uboot 时、我在引导停顿之前获得以下日志：
尝试从 MMC2引导
身份验证已通过
身份验证已通过
当使用不同的加密密钥、或操纵加密扩展中填充的魔术值时、会导致身份验证错误。
因此、我假设器件可以成功地对二进制进行解密和身份验证、但没有执行。
所有其他二进制文件(optee、ATF 以及器件树)都支持已启用的加密。
问题：
- 对 u-boot 二进制文件进行加密时、什么原因会导致引导过程停止？ 是否有任何方法可用于调试器件上发生的情况？
非常感谢！
斯特凡
