你好,
关于1469x的安全引导，我有几个问题。我一直在尝试使用安全映像启动开发工具包。我没有任何运气让它接受我的图像，这是由一个产品头，fw图像头，和二进制。我的设置如下:
—存储在OTP签名有效载荷区域的ed25519公钥
—在OTP QSPI FW解密区域保存AES256密钥
—根据数据手册的规格制作产品和fw镜像头。我必须做一些试验和错误，以使一些字段工作，并使它在SmartSnippets工具箱QSPI头工具中被正确识别。但我显然还是有问题，因为我的映像不能启动。
因此为了澄清，我想知道一些关于存储格式的OTP键和一些头字段内容的事情。
1)从代码片段，它似乎是键是存储4字节在小的endian格式一次。所以如果我有一个以'0011223344556677开头的键…'然后它被存储为'3322110077665544…'这是正确的吗?
2)在报头字段中，从实验来看，大多数(如果不是所有)多字节字段都是小端序(不管描述中缺少LE)。这包括安全字段和签名长度字段的节长度。这也适用于现在和签名吗?
3) ECC和对称密钥索引是基于0的(第一个密钥将是索引0)?
4)在SmartSnippets工具箱的帮助文件中，fw图像头的大小字段表示该大小包含了图像头。这是正确的吗?这意味着对于0x2000的fw hdr, ivt偏移量为0x400，二进制大小为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)正如我可以告诉，16字节的IVT不存在的前面提供的图像时使用mkimage。它确实将图像填充到最接近的16字节。这真的没有必要，因为AES256-ctr不需要填充。长度就是二值图像+填充。
5)对加密图像进行CRC校验。
6）随机数是前8个字节。用于加密的IVT是下8个字节中的ONCE，其中8个
mkimage没有把IVT放进去，所以这真的不重要。图像只是一些填充的图像(不确定是否有必要)。
我不能复制mkimage为二进制图像创建的签名。一旦我添加了一个产品标头，mkimage输出就可以在系统上正常引导。我不确定是什么签名被计算过，但我不认为它只是图像。我没有一个撤销块，所以根据数据表，它应该只是横跨图像本身。
更新:
最后一个问题已经解决。该签名是通过设备管理区域、填充和附加图像计算的。无论设备管理区域的长度是否为零，都会发生这种情况。