• 状态
  • 已锁定 已锁定
  • 回复 32 回复
  • 订户 0 订户
  • 视图 83 视图
  • 用户 0 会员在此处
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] AM69A：间歇启动故障 — 频率握手超时和 SPL 挂起

admin
Guru**** 2416280 points
Other Parts Discussed in Thread: AM69A, SYSCONFIG

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1522868/am69a-intermittent-boot-failures---frequency-handshake-timeout-and-spl-hang

器件型号：AM69A
Thread 中讨论的其他器件： AM69、 SysConfig、 TDA4VH

工具/软件：

大家好、TI 专家。
我们正在使用基于 AM69A 的定制硬件平台、目前正在进行多次重新启动测试。
在此过程中、我们观察到两个反复出现的启动问题、它们会间歇性地阻止电路板启动：

1.由于频率握手超时而导致 SPL 挂起： 

U-Boot SPL 2024.04-ti-gcedb677ccf6e (Apr 25 2025 - 10:55:48 +0000)
SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.9--v11.00.09+ (Fancy Rat)')
Timeout during frequency handshake
### ERROR ### Please RESET the board ###

2. SPL 到 U-Boot 正确转换期间挂起： 

U-Boot SPL 2024.04-34430-gf8c18ba41a3-dirty (May 16 2025 - 08:41:36 +0200)
SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.9--v11.00.09+ (Fancy Rat)')
Initialized 4 DRAM controllers
SPL initial stack usage: 13456 bytes
HW CFG: 0x 0
Trying to boot from MMC1
Authentication passed
Authentication passed
Authentication passed
Loading Environment from nowhere... OK
init_env from device 17 not supported!
Authentication passed
Authentication passed
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.11.0(release):v2.11.0-906-g58b25570c9-dirty
NOTICE:  BL31: Built : 04:20:32, Nov  1 2024
I/TC: 
I/TC: OP-TEE version: 4.4.0-dev (gcc version 13.3.0 (GCC)) #1 Fri Oct 18 17:45:27 UTC 2024 aarch64
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check optee.readthedocs.io/.../porting_guidelines.html
I/TC: Primary CPU initializing
I/TC: GIC redistributor base address not provided
I/TC: Assuming default GIC group status and modifier
I/TC: SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.9--v11.00.09+ (Fancy Rat)')
I/TC: Activated SA2UL device
I/TC: Enabled firewalls for SA2UL TRNG device
I/TC: SA2UL TRNG initialized
I/TC: SA2UL Drivers initialized
I/TC: HUK Initialized
I/TC: Primary CPU switching to normal world boot

U-Boot SPL 2024.04-34430-gf8c18ba41a3-dirty (May 16 2025 - 08:42:40 +0200)
SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.9--v11.00.09+ (Fancy Rat)')
HW CFG: 0x 0
Trying to boot from MMC1
Authentication passed
Authentication passed

------- Hangs here -------

我们的设计在 DDRSS 布局/配置和软件栈方面密切镜像了 AM69 SK 板。

我们在 TI E2E 论坛中遇到了一个潜在相关的问题：
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1308890/tda4vh-q1-timeout-during-frequency-handshake/5211296#5211296

我们尝试了上述线程中的 DDRSS 参数更改、这略微改善了行为。 不过、与原始配置相比、相应的眼图显示信号完整性会下降、因此我们不打算在没有更有力证据的情况下采用这些变化。

您能帮助我们了解这些引导问题的潜在根本原因吗？
如有任何指导或建议、将不胜感激。

此致、
第 P 部分

  • 0
    TI__Guru**** 2416280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Parth、

    我在我们的 DDR 专家..我们会在几天内回来给你.  

    此致、

    Keerthy  

  • 0
    TI__Guru**** 2416280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、

    频率握手期间超时
    ###错误###请重置主板###

    发生上述问题时、您是否可以通过 CCS 从 R5 内核运行附加的二进制文件并提供结果？  

    e2e.ti.com/.../3414.tda4vh_5F00_lp4_5F00_debug_5F00_CCSoutput.zip

    谢谢、
    Kevin

  • 0
    TI__Guru**** 2416280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好 Kevin S、

    感谢您的回答。

    频率握手期间超时
    ###错误###请重置主板###

    由于此问题是随机的、而且需要很长时间才能重现、因此我想知道是否有任何替代方法可以帮助调试它、例如通过在 U-Boot/SPL 中启用或转储 DDRSS 寄存器来进行调试？
    与此同时、我将触发测试、并计划在问题发生时运行共享 LP4 调试工具。

    附注： 我在正常启动期间（即未遇到问题 1）在设置中成功运行了该工具、并在此处附加了日志以供参考、即主要是为了在我的设置中对 LP4 调试工具进行健全性检查。

    /cfs-file/__key/communityserver-discussions-components-files/791/Aquila_5F00_AM69_5F00_LP4_5F00_Debug_5F00_Sample_5F00_run_5F00_logs_5F00_in_5F00_working_5F00_good_5F00_case.txt

    此致、
    第 P 部分

  • 0
    TI__Guru**** 2416280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    只需添加 — 在上一个测试周期中，我启用了额外的 DDRSS 日志、并在三个 DUT 中的一个上观察到以下日志。 

    U-Boot SPL 2024.04-00774-g375342660d72-dirty (Jun 05 2025 - 15:49:26 +0200)
SYSFW ABI: 4.0 (firmware rev 0x000a '10.0.8--v10.00.08 (Fiery Fox)')
HW CFG: ti_dm6441_gpio gpio@42110000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19
ti_dm6441_gpio gpio@42110000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19
ti_dm6441_gpio gpio@42110000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19
ti_dm6441_gpio gpio@42110000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19
ti_dm6441_gpio gpio@42110000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19
0x00
k3_ddrss_probe(dev=41c675c8)
k3_ddrss_ofdata_to_priv(dev=41c675c8)
k3_ddrss_power_on(ddrss=41c6de48)
k3_ddrss memorycontroller@2990000: vtt-supply not found.
k3_lpddr4_probe: PASS
k3_lpddr4_init: PASS
--->>> LPDDR4 Initialization is in progress ... <<<---
k3_lpddr4_freq_update: received freq change req: req type = 1, req no. = 0, instance = 0
wait_for_bit_le32: Timeout (reg=114080 mask=80 wait_set=1)
Timeout during frequency handshake
### ERROR ### Please RESET the board ###


    分享这一点以防它提供任何有用的提示、尽管考虑到问题的随机性质、这可能只是许多可能的原因之一、不应过早地转移焦点。

    谢谢你。

    此致、
    第 P 部分

  • 0
    TI__Guru**** 2416280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    最后提供的日志显示了该问题。 您是否也能够捕获调试输出？  

    谢谢、
    Kevin

    U-Boot SPL 2024.04-00774-g375342660d72-Dirty (2025 年 6 月 5 日 — 15：49：26 +0200)
    SYSFW ABI：4.0（固件版本 0x000a '10.0.8--v10.00.08 (Fiery Fox)')
    HW CFG：TI_dm6441_GPIO@42110000：pinctrl_select_state_full：uclass_get_device_by_phandle_id：err=–19
    TI_dm6441_gpio GPIO@42110000：pinctrl_select_state_full：uclass_get_device_by_phandle_id：err=–19
    TI_dm6441_gpio GPIO@42110000：pinctrl_select_state_full：uclass_get_device_by_phandle_id：err=–19
    TI_dm6441_gpio GPIO@42110000：pinctrl_select_state_full：uclass_get_device_by_phandle_id：err=–19
    TI_dm6441_gpio GPIO@42110000：pinctrl_select_state_full：uclass_get_device_by_phandle_id：err=–19
    0x00
    k3_ddrss_probe (dev=41c675c8)
    k3_ddrss_ofdata_to_priv (dev=41c675c8)
    k3_ddrss_power_on (ddrss=41c6de48)
    k3_ddrss 存储器控制器@2990000：未找到 VTT-SUPPLY。
    K3_LPDDR4_PROBE：通过
    K3_LPDDR4_INIT：通过
    -->>> LPDDR4 初始化正在进行中...<<<--
    k3_lpddr4_freq_update：接收到的频率变化 req：req 类型= 1、req 编号 = 0、实例= 0
    WAIT_FOR_BIT_LE32：超时 (reg=114080 MASK =80 WAIT_SET=1)
    频率握手期间超时
    ###错误###请重置主板###

  • 0
    TI__Guru**** 2416280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Kevin S：

    我们能够重现报告的 DDRSS 问题 1、并通过 JTAG 成功捕获了 LP4 调试日志。

    请在下面找到同一 DUT 上两种场景（引导卡滞和引导正常）的 LP4 调试日志：

    DDRSS 问题 1（引导卡滞）： /cfs-file/__key/communityserver-discussions-components-files/791/Aquila_5F00_AM69_5F00_LP4_5F00_Debug_5F00_Logs_5F00_When_5F00_DDR_5F00_Issue_5F00_Boot_5F00_Stuck_5F00_10062025.txt

    工作（引导正常）：/cfs-file/__key/communityserver-discussions-components-files/791/Aquila_5F00_AM69_5F00_LP4_5F00_Debug_5F00_Logs_5F00_Good_5F00_case_5F00_Boot_5F00_OK_5F00_10062025.txt

    期待着随后就可能的原因和解决办法提出一些建议进行分析。
    谢谢你。

    此致、
    第 P 部分

  • 0
    TI__Guru**** 2416280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Parth：

    谢谢、您也可以上传寄存器设置。 如果您使用该工具的电子表格版本、请提供用于生成寄存器设置且已填写的电子表格。 如果您使用的是 SysConfig、除.dtsi 或.h 文件之外、还请提供*。sysconfig 文件。

    根据提供的日志文件、DDRSS2 的命令总线训练失败。  

    一些初步建议：

    1. 尝试调整 CA/CS IO 设置。 如果还没有、您能否尝试  CS 驱动强度= CA/CS ODT = 2x CA 驱动强度的组合
      1. 示例：CS drive = 80 欧姆、CA/CS ODT = 80 欧姆、CA drive = 40 欧姆
    2. 可以尝试缩小 CA VREF 训练范围
      1. 通过以下修改更改 DDR 寄存器配置文件（其中  N  可以是 0、1、2 或 3)：
        #define DDRSS N _pi_199_data 0x24182418
        #define DDRSS N PI_200_DATA 0x01012418

    此致、
    Kevin

  • 0
    TI__Guru**** 2416280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    非常感谢 Kevin S 的快速响应。

    SysConfig 文件： /cfs-file/__key/communityserver-discussions-components-files/791/Toradex_5F00_Aquila_5F00_AM69_5F00_DDRSS_5F00_Register_5F00_Configuration_5F00_32GB.zip

    LPDDR4 配置 DTSI： https://git.toradex.com/cgit/u-boot-toradex.git/tree/arch/arm/dts/k3-am69-aquila-lpddr4-4266.dtsi?h=toradex_ti-u-boot-2024.04

    关于您的初步建议、

    尝试调整 CA/CS IO 设置。 如果还没有、您能否尝试  CS 驱动强度= CA/CS ODT = 2x CA 驱动强度的组合
    1. 示例：CS drive = 80 欧姆、CA/CS ODT = 80 欧姆、CA drive = 40 欧姆
    [/报价]

    我认为该设置已经存在、因为这些配置是从 AM69-SK 设置原封不动地延续下去的。 请从共享文件中再次确认。

    请查看随附的 SysConfig 文件、如果需要进行任何其他调整、敬请告知。

    尝试缩小 CA VREF 训练范围
    1. 通过以下修改更改 DDR 寄存器配置文件（其中  N  可以是 0、1、2 或 3)：
      #define DDRSS N _pi_199_data 0x24182418
      #define DDRSS N PI_200_DATA 0x01012418
    [/报价]

    同时、我将尝试缩小 CA VRAF 培训范围、然后分享结果。

    谢谢你。

    此致、
    第 P 部分

    [/quote]
  • 0
    TI__Guru**** 2416280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Parth：

    我有一个与你非常相似的问题。 我临时通过将 DDR 频率从 2133MHz 降低到 2000MHz 或仅全速使用前 2 个 DDR 芯片来解决这个问题。

    我在将程序 3414.tda4vh_lp4_debug_CCSoutput.zip 加载到 R5 内核中时遇到问题。 请您能否在此处发布两种情况下都要加载的过程 DDRAM OK/NOK？ 谢谢你。

  • 0
    TI__Guru**** 2416280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好 Juraj Golej、

    我按照以下链接中概述的类似步骤通过 CCS 加载 LP4 调试二进制文件：

    https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-j784s4/09_01_00_06/exports/docs/psdk_rtos/docs/user_guide/ccs_setup_j784s4.html

    要收集日志、请执行以下操作：

    • 将 XDS110 调试探针连接到硬件
    • 在 CCS 中启动目标配置
    • 复位 R5 CPU
    • 加载 GEL 文件
    • 最后、加载并运行 tda4vh_lp4_debug-temp.out 二进制文件

    如需更详细的指导、TI 专家应能提供进一步帮助。

    此致、
    第 P 部分

  • 0
    TI__Guru**** 2416280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Kevin S：

    只需快速更新：

    [报价 userid=“584660" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1522868/am69a-intermittent-boot-failures---frequency-handshake-timeout-and-spl-hang/5868945 #5868945“]
    Kevin S 说：
    可以尝试缩小 CA VREF 训练范围
    1. 通过以下修改更改 DDR 寄存器配置文件（其中  N  可以是 0、1、2 或 3)：
      #define DDRSS N _pi_199_data 0x24182418
      #define DDRSS N PI_200_DATA 0x01012418

    同时、我将尝试缩小 CA VRAF 培训范围、然后分享结果。

    [/报价]

    此更改似乎可以改善问题 1 的行为。

    您能否说明 SysConfig 中的哪个参数与这些寄存器值相对应？ 换句话说、如何通过 SysConfig 自动生成这些值？

    谢谢你。

    此致、
    第 P 部分

  • 0
    TI__Guru**** 2416280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。


    你好 Keerthy J

    我正在等待 Kevin S 对以下问题的回复。

    您能否阐明 SysConfig 中的哪个参数与这些寄存器值相对应？ 换句话说、如何通过 SysConfig 自动生成这些值？
    [/报价]

    在我等待答案的同时、感谢您对问题 2 的帮助、我在原始帖子中报告了该问题、在我看来与 DDRSS/RAM 存储器配置无关。

    如前所述、问题 2 发生在从 SPL 转换到 U-Boot 正常状态期间、引导过程会卡住。
    我设法在故障期间捕获了 R5 跟踪日志、它们似乎很重要。 根据这些迹线、似乎有一个明确的问题需要 TI 方面注意。

    发生问题 2 时、原始中的 R5 布线： /cfs-file/__key/communityserver-discussions-components-files/791/R5_5F00_Traces_5F00_200625.txt
    发生问题 2 时解析 R5 跟踪： /cfs-file/__key/communityserver-discussions-components-files/791/R5_5F00_Traces_5F00_Parsed_5F00_200625.txt

    期待您的指导。

    谢谢你。

    此致、
    第 P 部分

  • 0
    TI__Guru**** 2416280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    你好 Keerthy J

    我能够再重现问题 2 两次、并针对每次问题收集了相应的 R5 迹线。
    虽然这些日志不像我之前分享的日志那样包含清晰的异常签名、但我将在此处包含它们、以防它们有助于识别问题 2 的潜在根本原因。

    发生问题 2 时、原始中的 R5 布线：
    Hit1：/cfs-file/__key/communityserver-discussions-components-files/791/R5_5F00_Traces_5F00_23062025_5F00_Failed_5F00_Try1.txt
    Hit2：/cfs-file/__key/communityserver-discussions-components-files/791/R5_5F00_Traces_5F00_23062025_5F00_Failed_5F00_Try2.txt

    当问题 2 发生时解析 R5 跟踪：
    Hit1：/cfs-file/__key/communityserver-discussions-components-files/791/R5_5F00_Traces_5F00_Parced_5F00_23062025_5F00_Failed_5F00_Try1.txt
    Hit2：/cfs-file/__key/communityserver-discussions-components-files/791/R5_5F00_Traces_5F00_Parced_5F00_23062025_5F00_Failed_5F00_Try2.txt

    谢谢你。

    等待答复、并对可能的原因和解决办法进行分析、然后提出一些建议。

    此致、
    第 P 部分

  • 0
    TI__Guru**** 2416280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    你好 Keerthy J

    关于问题 2、即系统在 SPL 到 U-Boot 正确转换期间卡住。 在 U-Boot R5 配置中启用“CONFIG_K3_QoS"似乎“似乎是为了改善该行为。 TI 已对以下提交进行了类似更改：

    https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/?h=ti-u-boot-2024.04&id=3d51439612d1ed516e3ceb7091293e90dc71b952 

    但是、缺少此配置可能导致引导失败和系统不稳定、这一点并不明确、也有点令人惊讶。

    您能否说明“CONFIG_K3_QoS"与“与此问题有何关联？
    换句话说、您是否认为未启用“CONFIG_K3_QoS"会“会导致此类重新启动稳定性问题？
    如果是这样、默认情况下不应启用“CONFIG_K3_QoS"，“，可能、可能是通过暗示“arch_k3"，“，类似于、类似于“TI_SECURE_DEVICE"的“的处理方式？

    期待您的答复。

    谢谢。

    此致、

    第 P 部分

  • 0
    TI__Guru**** 2416280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    Parth、

    我将深入探究这一点。 我会在几天内回来的。  

    此致、

    Keerthy  

  • 0
    TI__Guru**** 2416280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Keerthy J：

    只是一个快速的更新。 即使启用了“CONFIG_K3_QoS"，“，我、我仍然遇到问题 2、即系统在从 SPL 转换到 U-Boot 期间挂起。 这表明启用“CONFIG_K3_QoS"无法“无法完全解决该问题。

    我能够在故障期间捕获 R5 迹线日志、它们再次显示 FWL 异常、与之前的情况类似。

    此外、我观察到 MCU_RESETSTZ 和 RESETSTZ SoC 引脚在发生此问题时保持低电平、表明 SoC 不退出复位、而所有 PMIC 电源轨看起来都处于预期电压。

    R5 迹线（FWL 除外）：

    /cfs-file/__key/communityserver-discussions-components-files/791/Aquila_5F00_AM69_5F00_R5_5F00_Trace_5F00_QOS_5F00_250625.txt

    /cfs-file/__key/communityserver-discussions-components-files/791/Aquila_5F00_AM69_5F00_R5_5F00_Trace_5F00_QOS_5F00_250625_5F00_Parsed.txt

    U-Boot 控制台日志：

    /cfs-file/__key/communityserver-discussions-components-files/791/Aquila_5F00_AM69_5F00_QOS_5F00_250625_5F00_Uboot.txt

    随着产品开发即将进入最后阶段、解决这种系统不稳定问题已成为当务之急。 请你优先考虑这一问题。 如需了解更多详细信息或进行测试、请随时与我们联系。

    如果您能就 R5 FWL 例外情况提供任何见解、我将不胜感激。

    感谢您的理解。

    此致、
    第 P 部分

  • 0
    TI__Guru**** 2416280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    Parth、

    感谢您提供更多详细信息。 我正在绕过我们的安全专家 w.r.t 防火墙例外。

    - Keerthy

  • 0
    TI__Guru**** 2416280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Parth：

    我们很难分析您提供的 TIFS 跟踪、因为报告异常的防火墙 ID 与防火墙应保护的地址范围之间存在不一致。

    例如：

    根据 TISCI 文档 (https://software-dl.ti.com/tisci/esd/latest/6_topic_user_guides/firewall_faq.html#how-do-i-debug-firewall-issues)、、 


    检查迹线时：

    地址 0x45B00000 异常
    FWL 异常 0x1027F00   ->防火墙 ID 639
    0x30000
    0x1FFFEB0   -->  事务地址。
    0x0
    0x2201
    0x10

    日志表明 A72 处理器正在尝试写入地址 0x1FFFEB0。 但是、引发异常的防火墙 ID 为 639、根据文档 (https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j784s4/firewalls.html#list-of-region-based-firewalls)、该 ID应保护完全不同的地址范围、而不是 0x1FFFEB0。

    这种不匹配使我们难以正确诊断问题。

    如何 从 uboot 日志运行测试有时它会引导至 Linux、在某些情况下、它只是在 uboot 之后重置。

    此致
    Diwakar

  • 0
    TI__Guru**** 2416280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    Diwakar Dhyani

    我们可以做些什么来简化调试过程并确保更快地获得解决方案？ 有没有任何时间来回浪费,我们可以削减一些会议? 我们可以向您发送我们的硬件吗？  您是否尝试过在您的硬件上重现此问题（您可以从本讨论中了解到，这不是一个系统性问题，需要相当长的时间才能重现）？ 还有其他建议吗？

  • 0
    TI__Guru**** 2416280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    你好、 Diwakar Dhyani、

    日志表明 A72 处理器正在尝试写入地址 0x1FFFEB0。 但是、引发异常的防火墙 ID 为 639、根据文档 (https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j784s4/firewalls.html#list-of-region-based-firewalls)、该 ID应保护完全不同的地址范围、而不是 0x1FFFEB0。

    感谢您查看日志并分享您的初始分析。
    很明显、系统中存在配置错误或 TISCI 运行方式错误。 鉴于这种意外行为、我不会质疑测试设置本身。 相反、我认为 TISCI 等低级固件应该独立于特定的系统用例运行。 如果情况并非如此、则说明需要解决的问题。

    您如何 从 uboot 日志运行测试有时它会引导到 Linux、在某些情况下它只是在 uboot 之后重置。

    测试设置很简单。 在 U-Boot 中切换测试 GPIO、由测试硬件在外部进行监控。 然后、该测试硬件在 5 到 10 秒的随机延迟后触发下电上电。 在共享 U-Boot 日志中、在第 4136 行之后、不再尝试引导 Linux。 第 91640 行出现该问题、表示需要分析和返回跟踪的迭代次数很长。

    尽管我对 TISCI 的了解有限、但我认为无论使用的 HLOS (U-Boot 或 Linux) 如何、其防火墙映射都应保持一致。

    如下文所述、我们非常希望能够就帮助解决这一问题的后续步骤提供指导。

    [引述 userid=“546986" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1522868/am69a-intermittent-boot-failures---frequency-handshake-timeout-and-spl-hang/5896492 #5896492“]

    我们可以做些什么来简化调试过程并确保更快地获得解决方案？ 有没有任何时间来回浪费,我们可以削减一些会议? 我们可以向您发送我们的硬件吗？  您是否尝试过在您的硬件上重现此问题（您可以从本讨论中了解到，这不是一个系统性问题，需要相当长的时间才能重现）？ 还有其他建议吗？

    [/报价]

    期待您的答复。

    谢谢你。

    此致、
    第 P 部分

  • 0
    TI__Guru**** 2416280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    你好、 Diwakar Dhyani、

    我有另一组带有 FWL 异常的 R5 迹线日志、可以提供进一步的见解。
    此测试中启用了 R5F 的 CONFIG_K3_QoS 和锁步模式、使我们的平台与 TI 的 J784S4 EVM 配置更紧密地对齐。
    除了这些更改、R5 迹线显示的信息更具体以及与例外相关、如下所示。 

    FWL Bit  0x1D
Exception addr  0x45B0B800
FWL Exception  0x1141400
0x00030000:   BasePort: INIT_COMPLETE(OSAL/Baseport init complete): MSG:0x030000
0x706F9C10: Power Management/FAIL(Action failed):   DEVICE_OFF(Device has been Turned OFF): Device ID: 3120144
0x00000000:   BasePort: INIT_COMPLETE(OSAL/Baseport init complete): MSG:0x000000
0x00C82201:   BasePort: Unknown Action: 0x03 MSG:0x082201
0x00000010:   BasePort: INIT_COMPLETE(OSAL/Baseport init complete): MSG:0x000010
...
...
FWL Bit  0x1E
Exception addr  0x45B0B000
FWL Exception  0x1112000
0x00070000:   BasePort: INIT_COMPLETE(OSAL/Baseport init complete): MSG:0x070000
0x30C07E10:   Security/FAIL(Action failed): SEC_BOOT(Points of failures during secure boot api call): 0x01 => Certificate length > ASN1P_IMAX, 0x02 => Issue fetching certificate, 0x3 => Issue with Hash operation, 0x4 => Hash comparison fails: 0
0x00000000:   BasePort: INIT_COMPLETE(OSAL/Baseport init complete): MSG:0x000000
0x00002201:   BasePort: INIT_COMPLETE(OSAL/Baseport init complete): MSG:0x002201
0x00000004:   BasePort: INIT_COMPLETE(OSAL/Baseport init complete): MSG:0x000004

FWL Bit  0x1E
Exception addr  0x45B0B000
FWL Exception  0x1112000
0x00070000:   BasePort: INIT_COMPLETE(OSAL/Baseport init complete): MSG:0x070000
0x30B1FE10:   Security/FAIL(Action failed): SEC_INIT(Security post boardconfig initialization): Start(0) or End(1): 0
0x00000000:   BasePort: INIT_COMPLETE(OSAL/Baseport init complete): MSG:0x000000
0x00002201:   BasePort: INIT_COMPLETE(OSAL/Baseport init complete): MSG:0x002201
0x00000004:   BasePort: INIT_COMPLETE(OSAL/Baseport init complete): MSG:0x000004
...
...

    R5 迹线（FWL 除外）：

    /cfs-file/__key/communityserver-discussions-components-files/791/Aquila_5F00_AM69_5F00_R5_5F00_Traces_5F00_Parsed_5F00_26062025.txt

    /cfs-file/__key/communityserver-discussions-components-files/791/Aquila_5F00_AM69_5F00_R5_5F00_Traces_5F00_26062025.txt

    U-Boot 控制台日志：

    /cfs-file/__key/communityserver-discussions-components-files/791/Aquila_5F00_AM69_5F00_U_2D00_boot_5F00_26062025.txt

    以下是有关我们硬件的相应 U-Boot 源代码详细信息

    期待您的答复。

    谢谢你。

    此致、
    第 P 部分

  • 0
    TI__Guru**** 2416280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Parth：

    请允许我花些时间进行检查。

    还有一个问题是、您是否看到 TI EVM 也有类似的行为？

    此致
    Diwakar

  • 0
    TI__Guru**** 2416280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    你好、 Diwakar Dhyani、

    您是否也看到了与 TI EVM 类似的行为？

    我无法访问 J784S4 EVM、因此无法对其行为进行评论。

    在 AM69-SK 上、我确实观察到了过去（很久以前）与 DDRSS 问题 1 有关的系统不稳定。 但是、鉴于当前问题的性质、我认为它几乎不依赖于硬件本身。
    我们的软件栈与 TI 非常密切相关、我个人已经回顾了 TI EVM 和我们平台之间的配置差异、但没有发现任何问题。
    尽管如此、我非常希望一位 TI 专家进行更仔细的审查、确信无疑。 （在上一个响应中共享源链接）

    如有任何其他信息、请随时与我联系。

    谢谢你。

    此致、
    第 P 部分

  • 0
    TI__Guru**** 2416280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Parth：

    我分析了 TIFS 跟踪, 有多个防火墙例外,之后我们看到了身份验证失败,这是非常不可能的,因为身份验证已经通过。所以我假设跟踪有一些问题。

    我想我们需要弄清楚在 失败的情况下 A72 为什么会执行这些随机事务、因为这些随机事务我们看到防火墙异常。

    此外、防火墙例外地址和共享的日志中的防火墙 ID 仍然不匹配。

    从 uboot 日志来看、似乎正在传递 uboot 和 dtb 的身份验证、但当 uboot 开始在 A72 上执行时、似乎会出现问题。

    此致
    Diwakar

  • 0
    TI__Guru**** 2416280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Diwakar Dhyani：

    因此、我假设跟踪存在一些问题。

    您能否详细说明一下当前迹线可能有什么问题？
    换句话说、我们如何确保捕获正确的 R5F 布线？ 以下是我为启用 R5F 跟踪日志记录所做的更改。 

    diff --git a/board/toradex/aquila-am69/board-cfg.yaml b/board/toradex/aquila-am69/board-cfg.yaml
index 17b517118d3e..9a37360d612e 100644
--- a/board/toradex/aquila-am69/board-cfg.yaml
+++ b/board/toradex/aquila-am69/board-cfg.yaml
@@ -33,5 +33,5 @@ board-cfg:
         subhdr:
             magic: 0x020C
             size: 8
-        trace_dst_enables: 0x00
-        trace_src_enables: 0x00
+        trace_dst_enables: 0x0d
+        trace_src_enables: 0x3f

    此外、您共享的日志中的防火墙例外地址和防火墙 ID 仍然不匹配。

    该问题是否与 TISCI 本身有关、或者可能与布线收集方式有关？
    我们如何确保捕获准确的迹线？ 我尝试在出现故障时将 JTAG 连接到 R5 和 A72、但没有成功。

    当在 A72 上开始执行 uboot 时、似乎会出现问题。

    这是非常清楚和清楚的理解。

    谢谢你。

    此致、
    第 P 部分

  • 0
    TI__Guru**** 2416280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Parth：

    您能添加一个 while 循环吗  Board_init_f  正确安装传递函数  common/board_f.c 归档并重新编译 uboot。 使用 JTAG 加载 uboot 符号文件、然后查看它是否到达该文件。
    这种情况。

     位于 下的 Uboot 符号文件 :board-support/ /build/a72/u-boot

    因为我们在获取 uboot 版本打印之前会看到防火墙异常。只是想检查它正在执行的确切内容。

    此致
    Diwakar

  • 0
    TI__Guru**** 2416280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    你好、 Diwakar Dhyani、

    我遵循了你的建议,但似乎执行甚至没有达到 board_init_f().

    因为我们在获得 uboot 版本打印之前看到了防火墙异常。只是想检查它正在执行什么。

    从上面的代码片段中、系统似乎卡在 lib/vsprintf.c 中的 vsnprintf_internal () 函数中、该函数在 U-Boot 正常运行需要打印其版本信息时与观察到的空白控制台对齐。

    谢谢你。

    此致、
    第 P 部分

  • 0
    TI__Guru**** 2416280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    嗨、Parth  

    版本打印将在  board_init_f() 中的控制台初始化后进行。 之前卡在打印中的奇怪函数。

    这是否每次都停留在同一个位置,即在 vsnprintf_internal ()?

    此致
    Diwakar

  • 0
    TI__Guru**** 2416280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    你好、 Diwakar Dhyani、

    这是否每次都停留在同一位置、即 vsnprintf_internal()？

    当然很难说。 我很幸运地发现一个系统卡在问题上、已准备好进行调试并与您分享观察结果。
    但是、系统并不总是在同一点挂起。 例如、在一种情况下、发生问题时 SoC 并未退出复位状态、导致无法连接 JTAG。 （请查看以下回复。）

    [报价 userid=“584660" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1522868/am69a-intermittent-boot-failures---frequency-handshake-timeout-and-spl-hang/5893801 #5893801“]

    此外、我观察到 MCU_RESETSTZ 和 RESETSTZ SoC 引脚在发生此问题时保持低电平、表明 SoC 不退出复位、而所有 PMIC 电源轨看起来都处于预期电压。

    R5 迹线（FWL 除外）：

    /cfs-file/__key/communityserver-discussions-components-files/791/Aquila_5F00_AM69_5F00_R5_5F00_Trace_5F00_QOS_5F00_250625.txt

    /cfs-file/__key/communityserver-discussions-components-files/791/Aquila_5F00_AM69_5F00_R5_5F00_Trace_5F00_QOS_5F00_250625_5F00_Parsed.txt

    U-Boot 控制台日志：

    /cfs-file/__key/communityserver-discussions-components-files/791/Aquila_5F00_AM69_5F00_QOS_5F00_250625_5F00_Uboot.txt

    [/报价]

    谢谢你。

    此致、
    第 P 部分

  • 0
    TI__Guru**** 2416280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    嗨、Parth  

    很难确定。 我很幸运地发现一个系统卡在问题上、已准备好进行调试并与您分享观察结果。
    但是,系统并不总是在同一个点上挂起。

    您看到此防火墙问题的速率与其他任何问题的速率是多少？  

    另外、重现此问题需要多少时间？

    此致
    Diwakar

  • 0
    TI__Guru**** 2416280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    你好、 Diwakar Dhyani、

    您看到此防火墙问题的速率与其他问题的速率是多少？  [/报价]

    在长期下电上电测试期间（100%的时间）、所有观察到的情况下、故障始终会导致 FWL 异常 — 目前没有其他类型的问题。
    我只是想再次强调这一点,以防它在我们以前的交易所丢失,特别是因为系统行为明显变化时, FWL 异常发生。

    重现此问题需要多长时间？

    遇到该问题通常只需经过一夜下电上电测试（大约 12 到 14 小时）、并且可能在该时间范围内的任何时候发生。

    谢谢你。

    此致、
    第 P 部分

    [/quote]
  • 0
    TI__Guru**** 2416280 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    Parth、

    您是否尝试过降低 DDR 频率以查看这是否会产生任何影响？ 例如、可以尝试 3733 或 3200MT/s 的数据速率。

    为了降低频率、需要使用寄存器配置工具新建 DDR DTSI 文件。  

    这是因为之前已经确定了 DDR 问题、虽然初始化失败似乎可以解决、但 当前问题可能与边缘 DDR 读取/写入问题有关。 如果通过降低 DDR 频率来解决问题、那么我们可以重点关注 DDR 接口。 如果此实验对故障没有影响、则 DDR 接口可能无关。

    此致、
    Kevin