[参考译文] TDA4VM：SDK 迁移后 Sysfw.itb 身份验证问题

您好、 Kishore：

您是否能够在8.1基础上验证最新生成的 sysfw.itb？

您能否将 sysfw 9.2与8.1的证书进行比较？

您是否可以共享日志、以便在 9.2基础版中对其他图像进行身份验证？

此致
Diwakar

尊敬的 Diwakar：

感谢您的答复。

关于要点：

1.您能否在8.1基础上验证最新的 sysfw.itb？

• 是的、我们已经对此进行了测试、最新的映像验证在8.1基础上成功。

2.可以比较 sysfw 9.2与8.1的证书吗?

• 我们使用pdk_jacinto_09_02_00_30/packages/ti/build/makerules/x509CertificateGen.sh具有以下 OID 的脚本：

[v3_ca]
basicConstraints = CA:true
1.3.6.1.4.1.294.1.3=ASN1:SEQUENCE:swrv
1.3.6.1.4.1.294.1.34=ASN1:SEQUENCE:sysfw_image_integrity
1.3.6.1.4.1.294.1.35=ASN1:SEQUENCE:sysfw_image_load
1.3.6.1.4.1.294.1.4=ASN1:SEQUENCE:encryption
1.3.6.1.4.1.294.1.1=ASN1:SEQUENCE:boot_seq
1.3.6.1.4.1.294.1.2=ASN1:SEQUENCE:image_integrity

注意：8.1 SDK 中的同一证书(x509CertificateGen.sh)用于为9.2生成 sysfw 证书。

3.您可以在其他图像经过身份验证的情况下分享来自9.2基础版的日志吗?

以下是映像身份验证的日志：

• tiboot3.bin

  Image to be validated: /datafs/upgrade/flash_images/tiboot3.bin
  Memory Allocation for Image Validation succeeded
  VIRTUAL MMAP ADDRESS: 0x0xffff8bdb0000
  Size of image file: 196361
  MMAP of IMAGE FILE SUCCEEDED
  Base Addr: 0x8bd80000
  FIT Image format check succeeded
  Image Name: tiboot3 Addr: 0x8bd80000 Size: 196361 offset: 0
  tiboot3 image authentication status SUCCESS
  

• tispl.bin

  Image to be validated: /datafs/upgrade/flash_images/tispl.bin
  Memory Allocation for Image Validation succeeded
  VIRTUAL MMAP ADDRESS: 0x0xffffb35a0000
  Size of image file: 998119
  MMAP of IMAGE FILE SUCCEEDED
  Base Addr: 0xb34ac000
  FIT Image format check succeeded
  Image Name: atf Addr: 0xb34ac158 Size: 54588 offset: 344
  atf image authentication status SUCCESS
  Image Name: tee Addr: 0xb34b9728 Size: 433947 offset: 55080
  tee image authentication status SUCCESS
  Image Name: dm Addr: 0xb35236e4 Size: 254044 offset: 489188
  dm image authentication status SUCCESS
  Image Name: spl Addr: 0xb35617e8 Size: 240748 offset: 743400
  spl image authentication status SUCCESS
  Image Name: k3-j721e-common-proc-board.dtb Addr: 0xb359c4e8 Size: 12465 offset: 984296
  k3-j721e-common-proc-board.dtb image authentication status SUCCESS
  

如果您需要更多详细信息、敬请告知。

此致、

Kishore

我还要提一点、上面成功的日志来自  ti_sci_cmd_proc_auth_boot_image ()：：drivers/firmware/ti_sci.c、其中 ti_sci_cmd_proc_auth_boot_image ()返回 tiboot3和 tisp 映像的成功结果。

尊敬的团队：

温柔的提醒。

您好、Kishore：

Diwakar 正在度假,直到下周中旬才会上班。

Unknown 说：

ti_sci_cmd_proc_auth_boot_image ()返回错误"Mbox send fail -110"

哪个组件正在执行此检查？ Linux 内核？

如果 MCU1_0固件没有响应、Mbox 发送失败通常是一个问题。 您是否能够连接到 MCU1_0内核、并检查内核的卡住位置？

此致

Suman

尊敬的 Diwakar：

关于、  
哪个组件正在执行此检查？ Linux 内核？
>>是的、它是 Linux 内核。

除了上面提到的为 sdk9.2生成的 sysfw.itb 外、所有图像都在 sdk9.2上经过身份验证。

同样的最新 sdk9.2 sysfw.itb 图像也能够在 sdk8基础上进行验证。

此致、

Kishore

您好、Kishore：

Unknown 说：

除上述为 sdk9.2生成的 sysfw.itb 之外、所有图像都在 sdk9.2上进行了身份验证。

 通常、身份验证过程与被身份验证的数据无关。

mbox 故障是仅在 sysfw.itb 的验证过程中触发还是在之前进行？   您是否可以 尝试 重复重新验证某些先前已验证的映像？

Unknown 说：

此外、相同的最新 sdk9.2 sysfw.itb 图像还能够在 sdk8基础上进行身份验证。

嗯、至少这表明 sysfw.itb 文件没有问题。

不过、我建议您将此9.2 sysfw.itb 的内容与之前的8.1 SDK 进行比较。 您可以使用 U-Boot 的 dumpimage 实用程序检查映像大小以及内容。

此致

Suman

尊敬的团队：
感谢您的答复。

我们试图了解问题是否指向中的任何更改 SDK 9.2 sysfw.itb. 、特别是在它需要附加 OID 或需要特定 OID 顺序才能成功验证的情况下。

以下是我们观察到的详细信息：

• 刷写时 第8.1. 在中 SDK 9.2软件 、所有图像均已成功验证。
• 不过、需要刷写时这样做 第9.2. 在中 SDK 9.2软件 、所有图像最初都通过、但在什么时候通过 第9.2. 经验证、我们遇到了 MBOX 错误 。 这导致之前通过验证的其他映像随后失败。
• 此外、我们尝试移除 加密 OID 在中 SDK 9.2软件、因为 sdk8.1也没有 、但这导致主板无法启动。

 第2点和第3点之间的区别是验证固件映像的顺序/顺序。  
 在验证 sysfw 后、系统会从表中明确显示出来、进入 mbox 错误模式、之后系统不会恢复。
 在此序列中、当我们执行软重启时、在引导过程中还会观察到几个 mbox 错误。

 显然、当电路板加载了 sdk9.2 sysfw 并随后验证 sysfw (sysfw_8.1和 sysfw_9.2)时、系统进入 mbox 错误模式。  

考虑到这些观察结果、我们有几个问题：

1. SDK 9.2 sysfw.itb 是否需要额外的 OID 或特定的 OID 顺序才能正确验证？
2. 在 SDK 9.2中正常运行和验证是否需要 OID 的强制性列表？

关于、
不过、我建议您将此9.2 sysfw.itb 的内容与之前的8.1 SDK 进行比较。 您可以使用 U-Boot 的 dumpimage 实用程序检查映像大小以及内容。
>>

sdk9.2：

1.3.6.1.4.1.294.1.3=ASN1:SEQUENCE:swrv
1.3.6.1.4.1.294.1.34=ASN1:SEQUENCE:sysfw_image_integrity
1.3.6.1.4.1.294.1.35=ASN1:SEQUENCE:sysfw_image_load
1.3.6.1.4.1.294.1.4=ASN1:SEQUENCE:encryption
1.3.6.1.4.1.294.1.1=ASN1:SEQUENCE:boot_seq
1.3.6.1.4.1.294.1.2=ASN1:SEQUENCE:image_integrity

sdk8.1：
1.3.6.1.4.1.294.1.3= ASN1：序列：swrv
1.3.6.1.4.1.294.1.34= ASN1：序列：sysfw_image_integrity
1.3.6.1.4.1.294.1.35= ASN1：序列：sysfw_image_load
1.3.6.1.4.1.294.1.4= ASN1：序列：加密
1.3.6.1.4.1.294.1.1= ASN1：序列：BOOT_Seq
1.3.6.1.4.1.294.1.2= ASN1：序列：IMAGE_INTEGRITY

内容：



提前感谢。

此致、
Kishore

您好、Kishore：

Unknown 说：

我们正在尝试了解问题是否指向中的任何更改 SDK 9.2 sysfw.itb. 、特别是在它需要额外的 OID 或需要特定的 OID 顺序才能成功验证的情况下。

对于给定的二进制文件、所需的 OID 都是固定的、因此这不是问题、9.2 sysfw.it 不需要额外的 OID  

Unknown 说：

以下是我们观察到的详细信息：

感谢您提供详细说明。

Unknown 说：

但是、刷写时 第9.2. 在中 SDK 9.2软件 、所有图像最初都通过、但在什么时候通过 第9.2. 经验证、我们遇到了 MBOX 错误 。 这导致之前通过验证的其他映像随后出现故障。

mbox 错误是由于没有得到正确的响应而导致的。 这通常是 MCU R5F 内核进入异常的结果。 遇到此错误后、TI-SCI 协议无法正常工作、并且所有后续的 TI-SCI 消息都将无法正常工作(不仅限于对正在测试的其他映像进行身份验证)。

假设您要通过 Linux 执行身份验证步骤、则 TI-SCI 请求会通过 MCU R5F 固件进行路由。 您在 MCU R5F 上使用哪些固件、您的 SDK 9.2 MCU R5F 固件似乎存在问题。

Unknown 说：

此外、我们尝试删除 加密 OID 在中 SDK 9.2软件、因为 sdk8.1也没有 、但这导致主板无法启动。

TIFS 固件是主要的安全信任根固件、是加密固件。 因此、您不能删除解密固件所需的此 OID。

Unknown 说：

 第2点和第3点之间的区别是验证固件映像的顺序/顺序。

您的表格显示8.1 sysfw.itb 文件在第2点也失败。  

Unknown 说：

SDK 9.2 sysfw.itb 是否需要额外的 OID 或特定的 OID 顺序才能正确验证？

否

Unknown 说：

在 SDK 9.2中正常运行和验证是否需要 OID 的强制列表？

这不是 OID 的问题。

Unknown 说：

Content Wise：

谢谢这个垃圾。 总的来说、没有什么特别的。 9.2 sysfw.itb 文件/内容稍大、这是由于在使用 SDK 9.x 发布的较新 Ubuntu 22.04计算机上、来自 OpenSSL 3.x 的证书的大小差异增大所致。

此致

Suman

尊敬的团队：

我们已启用 Enet lwIP 示例 在 MCU10 R5F 固件的 SDK 9.2上、符合预期。 我们每隔10秒打印一次 CPU 负载、如下所示。

在中、问题仍然存在 sysfw.bin 验证 在 SDK 9.2中、无法通过 MBOX 错误 刷写基于 sdk9.2的 sysfw 时。

MCU10日志：

观察结果：

• 所有其他映像也已成功验证、如上表所述。

• 仅在刷写和验证时出现问题 sysfw.bin 基于 SDK 9.2。

根据我们的观察、您能指导我们如何解决这个问题吗？

感谢您的帮助。

此致、
Kishore

您好、Kishore：

Unknown 说：

根据我们的观察、您能指导我们如何解决此问题吗？

您是否能够连接和调试 MCU R5F 内核？ 您能否检查您的 MCU R5F 内核是否卡在例外情况下？

此外、我还建议从 Wkup UART 启用跟踪并捕获 TIFS 调试日志(如果您的电路板支持这种情况)？

此致

Suman

尊敬的 Suman：

关于、
您是否能够连接和调试 MCU R5F 内核？  

>>董事会对此不提供支持。

此外、我们还能够在 MCU10 UART 上看到常规 CPU 负载印刷。 如果有例外情况、则应该卡住、但情况并非如此。

关于、

此外、我还建议从 Wkup UART 启用跟踪并捕获 TIFS 调试日志(如果您的电路板支持这种情况)？

>>董事会对此不提供支持。

此致、

Kishore