[参考译文] AM2434：TMDS243EVM：有关 Sitara 上打印的安全信息和从寄存器读取的信息的混淆

您好：

如果您的用例是识别器件类型、最好从 SECMGR MMR 中读取器件类型。 JTAG ID 寄存器中的安全位可以区分 GP 和 HS 器件、但无法区分 HSFS 和 HSSE 器件。

至于 JTAG ID 寄存器中安全位的不一致性、我必须在相关的组中循环。

一旦我们确定了您要使用的方法来确定您的用例中的器件类型、我就会这样做。

此致、

Prashant

这是一个非常好的提示,谢谢！
目前我们只使用 hs-fs、但这会发生变化、我们需要考虑到这一点。  

第一篇文章的一些主题相互混合。 但您需要了解以下要点：
我们很早就在只有原型版本可用时使用了 Am64 和 Am243-SoC、所以对我们来说是 GP 版本。 一旦 TI 发布了非 gp-version、我们就只有 hs-Fs-devices。 此外、SDK 中对 gp-devices（以及 SysFw）的支持也已停止。  
我们仍然需要更新旧器件、将来也需要更新。  
我们从 SDK 中取出了 SysFw.bin。
此外、我们还有自己的引导加载程序应用程序、它很松散地基于 ospi-bootloader。 我们使用我们自己的平台和更新机制,有三个插槽用于不同的固件（A/B 和一个备份固件插槽）。
SBL 映像通常还包含由 RBL 激活的 SysFw 和 boardcfg。  
这意味着我们需要构建两个不同的引导加载程序应用程序、一个用于 gp、一个用于 hs-fs、因为 GP 的 SysFw.bin 不会与 hs-fs 配合使用、另一个则用于 hs-fs。  

我们的更新机制还允许将引导加载程序映像添加到更新文件中、然后该文件也将被安装。 我们甚至在更新文件中添加了两个引导加载程序映像、因为我们有一款产品在现场具有不同的 SoC 修订版。 这意味着器件需要区分这两个引导加载程序。  

为此、我们需要一个寄存器从 Sitara 读出以进行识别。 根据这些值、将安装 gp-或 hs-fs-bootloader。

您提到的注册表也是我们通过逆向工程意外发现的。 但我们在 TRM 中没有找到任何有关该内容的更多信息（可能我们只是没有找到它）。 这就是我们选择 JTAG_uder_ID 寄存器的原因。  

目前、它没有产生任何问题、或者我想假设我们没有收到焊接到 EVM 上的任何修订版本。 因此、我们的产品仍然是可更新的、对于我们从 JTAG_USER_ID 寄存器读出的批次而言已经足够好了。  

因此、如果我们可以获得更多有关 SECMGR 及其寄存器值的信息、您认为它更可靠、我们可以更改为这样。  

借助这些知识、我们还可以在不使用任何引导加载程序的情况下准备固件更新、这将只会更改应用程序映像、从而检查 SEC Mgr 寄存器。

现在 你给了一个很好的提示,因为我们可能需要适应这也适用于 hs-se,这不应该是一个大问题,但需要考虑。