[参考译文] TDA4VM-Q1：TDA4VM HSFS Keywriter 挂起

请注意、TI 资源在本周余下时间不在办公室、可能会延迟回复。

此致、

kb

尊敬的 Anders：

它似乎与 keywriter main.c 中的任何函数无关,因为它在看似恒定的时间后挂起,即使我只是使用 printf ()执行循环。

您在等待多久后才看到挂机？

是否在加载 KeyWriter TIFS 二进制文件之前有循环代码？

此致

Suman

挂起发生在 Keywriter 启动后大约1毫秒内。

它只有足够的时间 在循环中使用 UART_printf 打印大约10-20个字符。  该循环在 TISCI init 之前运行、或在未运行 TISCI init 的情况下运行。

启用/禁用固件加载不会改变行为。

如果加载固件 、则其他跟踪 UART 会显示一些十六进制代码、但最终会在冻结发生时停止。

我还应该指出的是、我已在多个电路板上观察到这种行为、并为 J721E EVM 使用较旧的 Keywriter、修改硬件以始终启用 EFUSE 电源允许我写入密钥、以及运行 Linux 和 RTOS 的完整 SDK 套件。

因此、我的结论是、这不是硬件问题、但在我为这款新电路板创建更新的 Keywriter 的过程中可能出现配置错误或缺失的情况  

尊敬的 Anders：

它只有足够的时间 在循环中使用 UART_printf 打印约10-20个字符。  循环在运行 TISCI init 之前或未运行 TISCI init 之前运行。[/QUOT]

嗯、这似乎甚至与 KeyWriter 无关。  

TIFS 固件还具有看门狗超时、需要在 KeyWriter 应用运行的180秒内加载。 但您的问题似乎与 UART 和打印跟踪有关。

 TDA4VM SR1.1上的 KeyWriter 具有完全功能、TI 不知道8.x SDK 上的 KeyWriter 一般有任何问题。  

您是否有来自 MCU UART 和 WkUp UART 的日志？

如果固件加载完成 、另一个跟踪 UART 显示一些十六进制代码、但最终在冻结发生时停止。

您是否能够通过调试器连接到 MCU1_0内核、并查看 PC 卡在何处？

因此我的结论是、这不是硬件问题、但在我尝试为此新电路板创建更新的 Keywriter 时可能出现配置错误或缺失的情况 

所以、这在一些旧版电路板上能正常工作、而在更新的电路板上不能正常工作？ 针对此新电路板、电路板库和引脚多路复用配置是否全部已更新？

此致

Suman

[/quote]

我将使用 UART_printf 作为测试故障行为的一种方法。 它不是导致问题的原因。

我在我的第一篇文章中打印了 MCU 的日志。 它只是挂起前的一行。

相同的电路板硬件、但第一批和第二批编译。
J721e EVM 和我们的硬件之间的重要差异主要与电源相关。 我们使用的是名为 PDN-3F 的电源设计。

由于 PMIC 不同、不用于 EFUSE 电源、因此我已将这些器件从 J721e keywriter_utils.c 中删除
因为 Keywriter 在到达这些函数之前挂起,我不认为我已经删除了其他原因所需的任何东西。

PMIC 看门狗不会触发、我已清除所有中断且没有任何改进。

我确实观察到 AVS 未在 Keywriter 中设置、但我假设它使用 MCU 电源、而不是 AVS_CPU 或核心电源？

尊敬的 Anders：

我在第一篇文章中打印了 MCU 的日志。 它只是挂起之前的一行。

UART printf 后的立即行是 OTP_SciClientInit()、它的全部内容都是关于 KeyWriter TIFS 初始化。

我们使用的电源设计名为 PDN-3F。

您的第一批和第二批版本之间是否存在 PDN 差异？

由于 PMIC 不同、不用于 EFUSE 电源、我已将这些器件从 J721e keywriter_utils.c 中删除
由于 Keywriter 在到达这些函数之前挂起,我不认为我已经删除了其他原因所需的任何东西。[/报价]

你是说这在 OTP_VppEn ()函数本身之前挂起吗? 请确保用于 KeyWriter 映像的 TIFS 二进制文件是 KeyWriter 二进制文件。 SDK 有一个与大小匹配的空白 ti-fs-keywriter.bin、以允许进行编译/链接器验证。

我不确定您是否添加了注释或删除了哪些内容、但 KeyWriter 功能确实要求启用 VPP_EFUSE、而 OTP_VppEn ()函数中的所有逻辑都需要根据您的 PDN 进行调整。  

我确实观察到 AVS 未在 Keywriter 中设置、但我假设它使用的是 MCU 电源、而不是 AVS_CPU 或核心电源？

是的、这应该无关紧要、或者是您挂起的原因。

此致

Suman

[/quote]

如果我用 main.c 版本信息注释掉第一个 UART_printf、我会得到：

OTP Keywriter ver: 21.5.2 -- v2021.05b (了不起的 LLA
密钥编程

两个版本具有相同的 PDN。

无论是否调用 OTP_VppEn、它都会挂起。 它不会到达按键编程呼叫。
我已经根据附加指令更新了 ti-fs-keywriter.bin (替换了0字节版本)。
我可以从 ti-fs 固件中看到版本信息、因此我认为它正在正确加载。

尊敬的 Anders：

两个版本具有相同的 PDN。

感谢您的确认。 并且晶体没有变化或其他与时钟相关的变化？ UART 引脚多路复用是否有变化？

这真的很奇怪。 如果注释掉 OTP_SciClientInit ()、 OTP_VppEn ( )和 Sciclient_otpProcessKeyCfg ()调用、您是否看到了所有跟踪(固件只是一个空的 UART 跟踪示例？

如果在 UART 驱动程序中导致挂起、OTP_SciClientInit()确实会执行一些时钟初始化和 UART 重新配置、但如果您使用的是同一个 SDK、这不应在您的两个板之间发生变化。

此致

Suman

与 J721E 板相比、我们使用更高的25MHz 时钟、但由于引导模式引脚处理所有时钟设置、因此 J721E 的软件无需更改即可运行。

UART 端口保持不变。

如果我不运行任何函数、仍然会发生挂起、但它会进一步运行。
因此、我认为这些调用中的任何一个都不会影响我的问题、而是会导致超时或崩溃。

这似乎不是例外、DWWD (看门狗)、PMIC 看门狗、PMIC 复位、并且 PMIC 不报告电源错误。
BIST 完成和启动后有 PMIC 中断、但清除这些中断无效。

除了 main.c 之外、是否执行了任何驱动程序初始化或配置？

尊敬的 Anders：

您使用哪种引导模式？ 您是否能够从 CTRLMMR_WKUP_DEVSTAT 寄存器中确认25 MHz 设置和引导模式设置？  

如果我不运行任何函数、仍会发生挂起、但只是进展一点点。

新的电路板是否已通过所有电路板验证并检出？ 我建议您只需放入一个 while 循环并查看是否可以连接到内核、或者使用非 UART 进行循环、并 在某些循环计数后定期打印最少。

当然、电路板将在看门狗触发 TIFS 后重新启动、但在此之前、您的执行正在停止。

您是否能够重复使用以前的电路板上的相同二进制文件并验证该电路板不会出现任何此类问题？  

除了 main.c 之外、是否在其他地方执行了任何驱动程序初始化或配置？

不可以、除了 UART 驱动程序代码和相关的引脚多路复用器之外、没有其他驱动程序初始化/配置。

此致

Suman

在第一块电路板上、我们使用25MHz 振荡器验证了 OSPI 引导模式。 如前所述、我们使用 Keywriter 的较旧二进制副本并结合硬件修改来编写密钥、从而启用 EFUSE 电源  

在这些板上、我们拥有可在应用中充分工作的 Linux 和 RTOS。

在这些经过验证的板上,我尝试运行我现在使用的相同键盘写入器,他们确实呈现相同的超时/挂起。

由于我有解决方法、因此我没有尝试在这些电路板上进一步调试此问题。 写入密钥后、我也无法运行 Keywriter、因此必须使用新电路板进行调试。

尊敬的 Anders：

我们使用 Keywriter 的旧二进制副本和硬件修改编写密钥、以启用 EFUSE 电源 

较旧副本与较新副本之间有何区别？

在这些经验证的主板上、我曾尝试运行我现在使用的同一键盘编写器、但它们确实显示了相同的超时/挂起。

嗯、这表明使用较新的二进制文件时存在一些问题。

写入密钥后、我也无法运行 Keywriter、因此我必须使用全新的开发板进行调试。

您在测试过程中注释掉了所有 KeyWriter 相关函数、将其呈现为"Hello World"示例。 这看起来不是 KeyWriter 问题。

您是否能够执行简单环路测试？

如果使用支持引导 HS-SDK FS 器件的较新 SDK、则甚至可以在 MCU1_0上运行非 KeyWriter 固件、如 Sciserver_testapp_freertos 固件映像。

此致

Suman

这看起来确实是构建问题。

旧的 Keywriter 可以正常工作、但需要修改硬件才能成功完成密钥写入
我只有其他人大约在1.5年以前为类似于 J721e 的较旧电路板构建的二进制文件。

如果我尝试使用附加组件和密钥重建这个较旧的 Keywriter、则新的二进制会明显更大、似乎 TIFS 固件无法加载、并且在到达最后之前挂起

如果我构建新的 Keywriter、它看起来比工作中的更大、TIFS 成功、但挂起。

我正在尝试找出为什么较新的版本的 Keywriter 大小都较大,但不起作用。

这是我将遵循的构建过程。 (我之前已经从附加组件更新 TI FEK 密钥和 TIFS 二进制文件)

CD /packages/ti/boot/keywriter/scripts
./ gen_keywr_cert.sh -g
CD 键
RM bmek.key bmpk.pem smek.key smpk.pem
cp ../../../../build/makerules/k3_dev_mpk.pem smpk.pem
xxd -p -r ../../../../build/makerules/k3_dev_mek.txt smek.key
cp ../ti_fek_public.pem tifekpub.pem
CD。
./ gen_keywr_cert.sh -s keys/smpk.pem --- smek keys/smek.key -t keys/tifekpub.pem -a keys/aes256.key

然后从 PDK Build 文件夹中(如果需要、我还将首先构建依赖项)

使 PMIC sciclient_direct 电路板 UART osal_nonos csl csl_init i2c gpm_hal
创建 keywriter_img

尊敬的 Anders：

这些构建命令看起来没有问题。 我还建议在重新构建之前明确清理这些相同的目标。 除非修改了文件并且先前存在相同目标的库、否则 PDK 构建不会重新构建库。  

此致

Suman

是的、我还运行清理命令

将 keywriter_img_clean

或者

清洁

尊敬的 Anders：

Make clean

请注意,这将清理一切,并将需要你重建一切,只要你知道。

此致

Suman

我试图后退一步、尝试从已知良好的状态构建 Keywriter。
因此、我解压缩了 ti-processor-sdk-rtos-j721e-evm-08_01_00_13.tar.gz 并应用了 addon 和密钥。

但是、使用"make keywriter_img"生成时会出现以下错误

make[1]：输入目录/home/anderskagerin/git/ti-processor-sdk-rtos-j721e-evm-08_01_00_13/pdk_jacinto_08_01_00_36/packages/ti/boot/keywriter/build
Gap-fill=0xff -o 二进制/home/anderskagerin/git/ti-processor-sdk-rtos-j721e-evm-08_01_00_13/pdk_jacinto_08_01_00_36/packages/ti/boot/keywriter/binary/j721e/keywriter_img_j721e_release.xer5f /home/anderskagerin/git/ti-processor-sdk-rtos-j721e-evm-08_01_00_13/pdk_jacinto_08_01_00_36/packages/ti/boot/keywriter/binary/j721e/keywriter_img_j721e_release.bin
/bin/sh：1：gap-fill=0xff：未找到
make[1]：[/home/anderskagerin/git/ti-processor-sdk-rtos-j721e-evm-08_01_00_13/pdk_jacinto_08_01_00_36/packages/ti/build/makerules/common.mk：630：sbl_img_bin] 错误127 (已忽略)
Gap-fill=0xff -o 二进制/home/anderskagerin/git/ti-processor-sdk-rtos-j721e-evm-08_01_00_13/pdk_jacinto_08_01_00_36/packages/ti/boot/keywriter/binary/j721e/keywriter_img_j721e_release.xer5f /home/anderskagerin/git/ti-processor-sdk-rtos-j721e-evm-08_01_00_13/pdk_jacinto_08_01_00_36/packages/ti/boot/keywriter/binary/j721e/keywriter_img_j721e_release.bin
/bin/sh：1：gap-fill=0xff：未找到
make[1]：[/home/anderskagerin/git/ti-processor-sdk-rtos-j721e-evm-08_01_00_13/pdk_jacinto_08_01_00_36/packages/ti/build/makerules/common.mk：633：keywr_imagegen] 错误127 (已忽略)

尊敬的 Anders：

您能列举出的输出吗 Ls 您的<ti-processor-sdk-rtos-j721e-evm-08_01_00_13>文件夹和<ti-processor-sdk-rtos-j721e-evm-08_01_00_13>/ PSDK_RTOS/scripts 文件夹的命令？

此致

Suman

这个文件从 SDK RTOS 上下载、从 TI 下载、而不是从我们的软件。

~/git/ti-processor-sdk-rtos-j721e-evm-08_01_00_13 ls -lh
共计96K
drwxr-xr-x 7 anderskagerin 域用户4.0K Feb 3 2022 cg_xml_2.61.00
drwxr-xr-xr-x 8 anderskagerin 域用户4.0K Feb 3 2022 DSPLIB_c66x_3_4_0_0
drwxr-xr-x 11 anderskagerin 域用户4.0K Feb 3 2022 ethfw
drwxr-xr-x 12 anderskagerin 域用户4.0K、2022年2月3日映像
rw-r--r-- 1 anderskagerin 域用户391二月3 2022 index.html
drwxr-xr-x 4 anderskagerin 域用户4.0K、2022年2月3日 ivision
drwxr-xr-x 7 anderskagerin 域用户4.0K Feb 3 2022 mathlib_c66x_3_1_2_1
drwxr-xr-x 6 anderskagerin 域用户4.0K Feb 3 2022 mcusw
drwxr-xr-x 6 anderskagerin 域用户4.0K Feb 3 2022 mmalib_02_02_00_03
drwxr-xr-x 5 anderskagerin 域用户4.0K Feb 3 2022 pdk_jacinto_08_01_00_36
drwxr-xr-x 5 anderskagerin 域用户4.0K、2022年2月3日感知
drwxr-xr-x 4 anderskagerin 域用户4.0K Feb 3 2022 PSDK_RTOS
drwxr-xr-x 9 anderskagerin 域用户4.0K Feb 3 2022 remote_device
drwxr-xr-x 11 anderskagerin 域用户4.0K (2022年2月3日) SDL
drwxr-xr-x18 anderskagerin 域用户4.0k 2022-02月3日 tidalg
drwxr-xr-x 5 anderskagerin 域用户4.0K Feb 3 2022 ti-cgt-armllvm_1.3.0.LTS
drwxr-xr-x 6 anderskagerin 域用户4.0K Feb 3 2022 ti-cgt-c6000_8.3.7
drwxr-xr-x 7 anderskagerin 域用户4.0K Feb 3 2022 ti-cgt-c7000_2.0.1.sts.
drwxr-xr-x 6 anderskagerin 域用户4.0K Feb 3 2022 tidl_j7_08_01_00_05
drwxr-xr-x14 anderskagerin 域用户4.0K Feb 3 2022 tiovx
drwxr-xr-x 7 anderskagerin 域用户4.0K Feb 3 2022 uia_2_30_01_02
drwxr-xr-x 12 anderskagerin 域用户4.0K Feb 3 2022 vision_apps
drwxr-xr-x 6 anderskagerin 域用户4.0K Feb 3 2022 vxlib
drwxr-xr-x 9 anderskagerin 域用户4.0K Feb 3 2022 xDAIS_7_24_00_04

~/git/ti-processor-sdk-rtos-j721e-evm-08_01_00_13/psdk_rtos/scripts ls -lh
共计32K
-rwxr-xr-x 1 anderskagerin 域用户252 Feb 3 2022 board_env.sh
-rwxr-xr-x 1 anderskagerin 域用户1.4K Feb 3 2022 copy_from_sd_card.sh
-rwxr-xr-x 1 anderskagerin 域用户1.1K Feb 3 2022 install_data_set_to_sd_card.sh
-rwxr-xr-x 1 anderskagerin 域用户1.7K、2022年2月3日 install_to_sd_card.sh
-rwxr-xr-x 1 anderskagerin 域用户2.0K FE2月3日2022 mk-linux-card.sh
-rwxr-xr-x 1 anderskagerin 域用户2.6K Feb 3 2022 mk-qnx-card.sh
-rwxr-xr-x 1 anderskagerin 域用户7.6K、2022年2月3日 setup_psdk_rtos.sh

谢谢、这就是从  ti-processor-sdk-rtos-j721e-evm-08_01_00_13文件夹构建时的问题。
澄清一下、此脚本是在我的软件库中自动运行的、因此应该不是最初的问题。

我还遇到了一个问题、即 Keywriter 二进制过大、即使只是构建原始二进制、因此我应用了该补丁(增加链接器大小)
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1106641/tda4vm-otp-keywriter-build-failure

但是、我遇到同样的问题。 Keywriter 将启动、然后挂起。

MCU UART 0：

OTP Keywriter Version: 02.00.00.00 (Nov 5 2024 - 20:28:50)

WKUP UART 0：

0x400002
0x800004
0x4003005
0x4401552
0x40000B
0x800004
0x4003005
0x4401552

尊敬的 Anders：

请澄清、此脚本是在我的软件库中自动运行的、因此不应该是最初的问题。

不知道该怎么做。 如果脚本自动运行并且所有内容都安装在正确的位置、那么您应该不会遇到构建问题。

我还遇到一个问题、即 Keywriter 二进制太大、即使只是构建原始版本、也是如此、所以我应用了此补丁(增加链接器大小)
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1106641/tda4vm-otp-keywriter-build-failure

是的、这是一个补丁、在我们后来的 SDK 版本中合并、当增加程序区段时、该补丁作为"编译器"更新的一部分提供。 鉴于您有其他启用 VPP 的代码、KeyWriter 固件大小会增加、这是一个很好的补丁。

但是、我遇到同样的问题。 Keywriter 启动、然后挂起。

是否确定 KeyWriter 二进制文件中包含了适当的证书？  

MCU UART 0：

OTP Keywriter Version: 02.00.00.00 (Nov 5 2024 - 20:28:50)

然后、我应该在这里看到额外的痕迹、至少是打印 OTP 证书痕迹等的地方、但我看不到任何痕迹。 所以、它基本上没有达到该点。

我建议您从对 MSV 进行编程的基本 KeyWriter 证书(未在安全引导中使用)开始。  

您可以使用以下命令生成证书、

./gen_keywr_cert.sh --msv 0xC0FFE -t ti_fek_public.pem

Wkup UART 上的日志将与此证书一起显示如下：

0x400002
0x800004
0x4003005
0x4401552
0x40000B
0x800004
0x4003005
0x4401552
0x40000D
0x800004
0x20800000
0x20800001
0x400002
0x800004
0x4003005
0x4401552
0x409031
0x800004
#
# Decrypting extensions..
#
MPK Options:  0x0
MEK Options:  0x0
MPK Opt P1:  0x0
MPK Opt P2:  0x0
MEK Opt   :  0x0
SMPKH extension disabled
SMEK extension disabled
EXT OTP extension disabled
* BCH code & MSV: fe0fac8b

KEY CNT extension disabled

KEY REV extension disabled

SWREV extension disabled

FW CFG REV extension disabled

* KEYWR VERSION:  0x20000

#
# Programming Keys..
#

* MSV:
[u32] bch + msv:  0x0
Programmed 2/2 rows successfully
[u32] bch + msv:  0x8BAC0FFE

* SWREV:
[u32] SWREV-SYSFW:  0x1
[u32] SWREV-SBL  :  0x1
SWREV extension disabled
[u32] SWREV-SYSFW:  0x1
[u32] SWREV-SBL  :  0x1

* FW CFG REV:
[u32] SWREV-FW-CFG-REV:  0x1
SWREV SEC BCFG extension disabled
[u32] SWREV-FW-CFG-REV:  0x1

* EXT OTP:
EXT OTP extension disabled

* BMPKH, BMEK:
BMPKH extension disabled
BMEK extension disabled

* SMPKH, SMEK:
SMPKH extension disabled
SMEK extension disabled

* KEYCNT:
[u32] keycnt:  0x0
KEY CNT extension disabled
[u32] keycnt:  0x0

* KEYREV:
[u32] keyrev:  0x0
KEY REV extension disabled
[u32] keyrev:  0x0

您需要 JTAG 设置准备好 对其进行进一步调试。   

此致

Suman

Eason Zhang 说：

您是否确定 KeyWriter 二进制文件中包含了适当的证书？  [报价]

从启动开始、我假定 ti_fek_public.pem 是正确的。
我假设任何其他密钥错误都只会导致向保险丝写入错误的密钥？

[报价 userid="35368" url="~/support/processors-group/processors/f/processors-forum/1432114/tda4vm-q1-tda4vm-hsfs-keywriter-hangs/5500593 #5500593"]

我建议您从对 MSV 进行编程的基本 KeyWriter 证书(未在安全引导中使用)开始。  

[报价]

由于我没有到达将钥匙实际写入保险丝的函数调用、这是否有意义的测试？

尊敬的 Anders：

启动后、我假设 ti_fek_public.pem 正确。

ti_fek_public.pem 仅用于 KeyWriter 证书、不用于引导 KeyWriter 二进制文件本身。 所以、它没有轴承。

由于我找不到将密钥写入保险丝的函数调用、这是否有必要进行测试？

我同意您尚未达到该点、但我也建议您将此作为您的起点。 mSv 是最简单的 KeyWriter 证书,不会对样品产生任何不利影响。

我希望在它开始看到证书之前看到更多的 TIFS 跟踪。  

此致

Suman

是否确定 KeyWriter 二进制文件中包含了适当的证书？  

哦、我误读了您的问题。 我不确定如何验证证书、但我已经遵循了我之前在本主题中详述的构建流程、并且我已确保使用的是我的同事保存为我们内部开发密钥的 SMPK 和 SMEK 密钥。

我没有原始的 AES 密钥、我认为它用于对证书中的密钥进行加密、因此我认为它将与我使用的有效 Keywriter 二进制中的 on 不相同。 即使正确也是如此。

如果证书出现故障、我假设 Keywriter 不会冻结、而是在 调用 Sciclient_otpProcessKeyCfg 时报告错误。

尊敬的 Anders：

我没有原始的 AES 密钥、我认为它用于加密证书中的密钥、因此我认为它将与我拥有的工作中的 Keywriter 二进制中的 On 不相同。 即使正确。

AES 密钥无关紧要。 它也可以从一个 KeyWriter 运行更改为另一个、它仅用于加密证书中的密钥。 AES 密钥未在任何地方融合到器件电子保险丝中。

如果证书出现故障、我假设 Keywriter 不应冻结、而是在 调用 Sciclient_otpProcessKeyCfg 时报告错误。

是的、正确。 您甚至不需要先对 SMPK 和 SMEK 进行编程以流式刷新 KeyWriter 流程。 我建议的 MSV 是第一个基线启动测试。

您当前的问题甚至未达到密钥编程的状态。

此致

Suman

部分好消息。 我的同事建议、较旧(正在工作)的 Keywriter 是使用较旧的 SDK 构建的。

我们在 SDK 8.0 (而不是 SDK 8.1)中设置 Keywriter、并在此处将其替换为补丁版本
https://dr-download.ti.com/software-development/software-development-kit-sdk/MD-bA0wfI4X2g/08.00.00.12/keywriter_patch.tar.gz

编译和运行该 Keywriter 后、我们可以确认它不会冻结/挂起！ 一个好迹象！

我想弄清楚区别是什么、以及 SDK8.1 Keywriter 冻结的原因、
但如果没有时间、可以直接使用 SDK 8.0文件来设置单独的存储库、用于编译 Keywriter。

尊敬的 Anders：

我们在 SDK 8.0 (而不是 SDK 8.1)中设置 Keywriter、

与 SDK 8.0相比,我们在8.1 SDK 中的 KeyWriter 代码本身没有任何重大更改,我不知道有任何其他人报告8.1 SDK 的问题。

在此处将其替换为补丁版本

好的、这来自我们的 TI.com SDK 下载页面、我将看到这里发生了什么变化。

但是如果我没有时间、则可以使用 SDK 8.0文件单独设置一个存储库来构建 Keywriter。

我仍然怀疑您的构建系统中存在一些集成问题。 总之、您可以完全跳过8.1、直接 在较新的9.2 SDK 上进行检查。

此致

Suman