你好，
我有几个关于安全启动的问题，有关1469倍的安全启动。我一直在尝试使用安全映像获取开发套件。我没有任何运气，让它接受由产品标题，FW图像标题和二进制组成的图像。我的设置是以下内容：
- 在OTP签名有效载荷区域中存储的ED25519公钥
- 在OTP QSPI FW解密区域中存储AES256密钥
- 在数据书中的规格后制作了产品和FW图像标题。我不得不做一些试验和错误来获取一些磁场，以便在SmartSnippets工具箱QSPI标题工具中正确识别。但我显然仍然存在错误，因为我的形象无法启动。
因此，为了澄清，我想知道关于OTP键的存储格式的一些事情和一些标题字段内容。
1）从代码片段，它出现的键将在小型格式的时间一次存储4个字节。所以如果我有一个以'0011223344556677 ...'开始的键，那么它被存储为'3322110077665544 ...'这是正确的吗？
2）在标题字段中，它从实验中出现最多，如果不是所有的多字节字段都是小endian（无论在描述中缺少LE）。这包括安全性和签名长度字段的截面长度。这也适用于随机和签名吗？
3）ECC和对称密钥索引是0的（第一键将是索引0）？
4）SmartSnippets Toolbox中的FW映像头大小字段有助于表示大小包含标题。这样对吗？这意味着对于0x2000的FW HDR，具有0x400的IVT偏移量和0x4000的二进制大小将是0x400 + 16（IVT）+ 0x4000（图像尺寸）。
5）FW图像CRC计算在什么？在产品HDR中，它只是产品HDR本身。这是否超过了IVT +图像？加密之前或之后？
6）是INNCE领域的IVT的前8个字节吗？
7）IVT是否加密？文件中的文件是图中的。
我知道这是很多问题，但我试图钉住我缺少的东西。
谢谢,
安迪
嗨agross，
谢谢你的问题。有人来自团队将与您联系。
问候，pm_dialog
好的。我找到了mkimage工具，并找出了上述问题的一些答案。我仍然有一个签名生成的问题，但我会到达那个问题。让我添加我发现的答案上面的问题：
1）一次确实存储在小型模式32位时的键。使用Mkimage工具验证了我的钥匙对我已经编程到OTP。
2）不可以.NONCE刚刚存储为字节流。不确定签名。
3）键是0。通过实验发现这一点，并且还通过不同SOC的文件。
4）近在咫尺，当使用mkimage时，在提供的图像的前部不存在16个字节的IVT。它确实将图像填充到最接近的16个字节。尽管AES256-CTR不需要填充，但这真的不是必要的。所以长度只是二进制图像+填充。
5）CRC通过ECRYPTED图像计算。
6) Nonce为前8个字节。用于加密的IVT是上面8个字节中的Nonce，下面8个字节中的0
7）Mkimage没有把IVT放进去，所以这真的没关系。图像只是带有一些填充的图像（不确定必要）。
我无法重现mkimage为我的二进制图像创建的签名。一旦我添加产品标题，Mkimage输出就会在系统上启动精细。我不确定签名正在计算，但我不认为这只是图像。我没有撤销块，所以根据数据表，它应该只是跨图像本身。
更新：
最后一个问题已得到解决。通过设备管理区域，填充和附加图像计算签名。无论您是否具有零长度设备管理区域，都会发生这种情况。