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.

[参考译文] AM62A7:定制电路板:SDK 09.01:较差的物体检测性能

Guru**** 1461150 points
Other Parts Discussed in Thread: SK-AM62A-LP
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1357446/am62a7-custom-board-sdk-09-01-poor-object-detection-performance

器件型号:AM62A7
主题中讨论的其他器件:SK-AM62A-LP

在运行 AI 演示后、我碰巧注意到它们不会以接近全速的任何速度运行。  如何调试为什么选择第二条形图(什么核心?) 是100%吗?

来自我们开发套件的图像:

在运行09.01的 EVM 上
图像阐明:FPS 2-3、温度42、几乎所有内核都处于空闲状态。 演示看起来很流畅、是幻灯片放映
对象检测: FPS 30 ,温度43,内核30-50%已使用。 演示看起来很顺利。 DDR RD 2700Mb/s、DDR WR 401Mb/s、DDR 总计3170Mb/s
语义分段: FPS 18 ,温度44,内核20-50%使用。 演示看起来很平滑、尽管 HDMI 输出似乎出现干扰
多通道:FPS 25、温度45。 演示看起来很顺利

在 AM62A 开发套件09.01上
图像分类:FPS 2-3、temp 46、几乎所有内核均空闲。 演示看起来很流畅、是幻灯片放映
对象检测: FPS 3 ,温度46,c7x_1 94%(其它2%)。 演示看起来很落后。 DDR RD 800Mb/s、DDR WR 33Mb/s、DDR 总计830Mb/s
语义分段: FPS 2 ,温度47,c7x_1 97%(其它2%)。 演示看起来很糟糕
多通道:FPS 1、温度37。 演示看起来很糟糕

注意:不确定演示为什么会被切断、EVM 和我们的电路板上都会发生这种情况。  似乎取决于显示器,但两个报告都是1920x1080

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

    尊敬的 Johnathan:

    据我所知、这是该主题的后续内容: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1341665/sk-am62a-lp-manually-compile-u-boot-for-evm (主要面向关注该主题的任何人)。

    您看到的行为是奇怪的... 您会注意到、这里显然正在使用 C7x、因此网络正在卸载到远程内核(即未在 Arm A53上运行 CNN)。 管线的这个 TIDL/C7x 组件似乎运行得非常慢、以至于整个管线只有几个 FPS 的速度、而其他内核的速度小于5%。

    我想收集有关您的 SDK+板的更多诊断信息、但首先要阐明哪些板与哪个 SDK 搭配使用:

    [quote userid="153510" url="~/support/processors-group/processors/f/processors-forum/1357446/am62a7-custom-board-sdk-09-01-poor-object-detection-performance 在运行09.01的 EVM 上 :
    • 我知道、这是您构建的在 TI SK-AM62A-LP 板上运行的 SDK? 还是这个板上的 TI SDK?
    [quote userid="153510" url="~/support/processors-group/processors/f/processors-forum/1357446/am62a7-custom-board-sdk-09-01-poor-object-detection-performance 在 AM62A 开发套件09.01上 :
    • 这是您的电路板、会运行您构建的 SDK 吗?

    要收集的诊断:

    • 运行`k3conf 转储时钟`
      • 或`k3conf 转储时钟211`μ s、仅适用于 C7x 时钟
      • 我想看看 C7x 时钟的运行频率。 它的频率可能非常低(不带 PLL、25 MHz、我记得)、但它应该是850 MHz 或1000 MHz、分别取决于 VDDCORE 的0.75V 或0.85V
    • 运行应用时、让终端打开并运行/opt/vx_remote_app_arm.out 二进制文件以打印更多 OpenVX 消息。 我假设这个二进制文件已经写入到了文件系统中。 我通常会在同样的终端启动命令后台运行这些命令、
      • 如果从 CLI 启动、还可以`export TIDL_RT_DEBUG=1`以获得更多 TIDL 日志记录
    • 我们不要从 GUI 启动、而是尝试从/opt/edgeai-gst-apps 启动、以便可以看到更多日志记录信息。
      • 您可以运行以下命令:根据要运行的网络类型更改 YAML 文件目标。 您可能需要修改输入以使用存储的视频文件。
      • /opt/edgeai-gst-apps/apps_python/app_edgeai.py /opt/edgeai-gst-apps/configs/object_detection.yaml -n
        
        • n 标记禁用 ncurses 输出,这将隐藏一些日志消息
        • 请注意、IMAGE_Classification.YAML 设置为以1fps 的速率运行图像文件。
    • 基于 GUI 的性能条使用与 CLI 工具/opt/edgeai-gst-apps/scripts/perf_stats 相同的基础、该工具包含有关构建和运行的说明。 我不希望这会产生新的信息,但想提及作为一个选项,以防它有助于您的工作流:)

    我看到了与 GUI 切断边缘上输入部分相同的情况。 它在 Qt 应用程序中运行、这可能会奇怪地处理大小。 从 CLI 运行应该可以避免这种情况、但我们也应该纠正这种情况、因为它隐藏了重要的 PERF 信息。

    请使用上述诊断建议生成的一些日志进行回复。

    Br、
    雷塞

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

    我测试了一个第二62A SOM 与相同的基板和 SDcard 和它得到正确的性能。

    较慢的模块在 ARM 上仅报告1.25Ghz 并报告0Hz DSP 时钟? 如何使用相同的软件实现不同的 DSP 时钟设置? 我们在这两个器件上应用相同的 DSP 1GHz 设置。  至少对于 ARM 而言、opp 表具有"opp-supported-hw"位、该位可以对我禁用更高的时钟速度...

    $ diff -u0 /tmp/works.txt /tmp/slow.txt 
    --- /tmp/works.txt	2024-05-06 16:56:55.643191313 -0400
    +++ /tmp/slow.txt	2024-05-06 16:58:30.095559105 -0400
    @@ -18,4 +18,4 @@
    -|   135     |     0    | DEV_A53SS0_CORE_0_A53_CORE0_ARM_CLK_CLK                                                              | CLK_STATE_READY     | 1400000000      |
    -|   136     |     0    | DEV_A53SS0_CORE_1_A53_CORE1_ARM_CLK_CLK                                                              | CLK_STATE_READY     | 1400000000      |
    -|   137     |     0    | DEV_A53SS0_CORE_2_A53_CORE2_ARM_CLK_CLK                                                              | CLK_STATE_READY     | 1400000000      |
    -|   138     |     0    | DEV_A53SS0_CORE_3_A53_CORE3_ARM_CLK_CLK                                                              | CLK_STATE_READY     | 1400000000      |
    +|   135     |     0    | DEV_A53SS0_CORE_0_A53_CORE0_ARM_CLK_CLK                                                              | CLK_STATE_READY     | 1250000000      |
    +|   136     |     0    | DEV_A53SS0_CORE_1_A53_CORE1_ARM_CLK_CLK                                                              | CLK_STATE_READY     | 1250000000      |
    +|   137     |     0    | DEV_A53SS0_CORE_2_A53_CORE2_ARM_CLK_CLK                                                              | CLK_STATE_READY     | 1250000000      |
    +|   138     |     0    | DEV_A53SS0_CORE_3_A53_CORE3_ARM_CLK_CLK                                                              | CLK_STATE_READY     | 1250000000      |
    @@ -148,2 +148,2 @@
    -|   208     |     0    | DEV_C7X256V0_C7XV_CORE_0_C7XV_CLK                                                                    | CLK_STATE_READY     | 1000000000      |
    -|   211     |     0    | DEV_C7X256V0_CLK_C7XV_CLK                                                                            | CLK_STATE_READY     | 1000000000      |
    +|   208     |     0    | DEV_C7X256V0_C7XV_CORE_0_C7XV_CLK                                                                    | CLK_STATE_READY     | 0               |
    +|   211     |     0    | DEV_C7X256V0_CLK_C7XV_CLK                                                                            | CLK_STATE_READY     | 0               |
    @@ -169,4 +169,4 @@
    -|   204     |     0    | DEV_CODEC0_VPU_ACLK_CLK                                                                              | CLK_STATE_READY     | 100000000       |
    -|   204     |     1    | DEV_CODEC0_VPU_BCLK_CLK                                                                              | CLK_STATE_READY     | 100000000       |
    -|   204     |     2    | DEV_CODEC0_VPU_CCLK_CLK                                                                              | CLK_STATE_READY     | 100000000       |
    -|   204     |     3    | DEV_CODEC0_VPU_PCLK_CLK                                                                              | CLK_STATE_READY     | 100000000       |
    +|   204     |     0    | DEV_CODEC0_VPU_ACLK_CLK                                                                              | CLK_STATE_READY     | 400000000       |
    +|   204     |     1    | DEV_CODEC0_VPU_BCLK_CLK                                                                              | CLK_STATE_READY     | 400000000       |
    +|   204     |     2    | DEV_CODEC0_VPU_CCLK_CLK                                                                              | CLK_STATE_READY     | 400000000       |
    +|   204     |     3    | DEV_CODEC0_VPU_PCLK_CLK                                                                              | CLK_STATE_READY     | 400000000       |
    @@ -278 +278 @@
    -|    21     |     4    | DEV_DCC5_DCC_CLKSRC4_CLK                                                                             | CLK_STATE_READY     | 100000000       |
    +|    21     |     4    | DEV_DCC5_DCC_CLKSRC4_CLK                                                                             | CLK_STATE_READY     | 400000000       |

    慢速模块的 MMR0_JTAG_USER_ID

    root@mitysom-am62ax:/opt/edgeai-gst-apps devmem2 0x43000018
    在地址 0x43000018 (0xffffff80a4b018)处读取:0x4A7DB52E

    对于 FAST 模块,

    root@mitysom-am62ax:/opt/edgeai-gst-apps devmem2 0x43000018
    在地址 0x43000018 (0xff83ec1018)处读取:0x4A7DB566


    请注意、较新模块的 AM62A 处理器代码为速度等级 U、数据表显示 DSP 可在850/1000MHz 而非 T 速度等级的500MHz 下计时。 不过、该 EVM 也标识为速度等级 T、似乎可以正常运行演示...

    EVM:        AM62A74A*T*MGGIAMB (DSP 时钟频率为850Mhz)
    慢速模块:AM62A74A*T*MGHIAMB (DSP 时钟频率为0Mhz?)
    快速模块:AM62A74A*U*MHAAMB (DSP 时钟频率为1000MHz)

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    慢速模块:AM62A74A*T*MGHIAMB (DSP 时钟频率为0Mhz?)

    这似乎不是一个问题。  另外至少有3个使用此部件的 SOM、它们在高速运行演示方面不存在问题。

    此外、我之前错过了 EVM 和慢速模块都是 XAM62A 器件、因此也是预量产器件。  目前只有这一个特定模块似乎与 DSP 演示有问题、这很麻烦。

    侧注:我确实有 AM62A74A*U*MHAAMB 部件引导并转储了一个损坏的时钟树。  我必须对其进行下电上电、使时钟树像正常情况下转储。  不确定这是否是 k3conf 工具中的错误、因为 SOM 似乎正常运行。

    e2e.ti.com/.../weird_5F00_dump_5F00_clock_5F00_output.log

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

    尊敬的 Jonathan:

    感谢您在此提供所有这些信息。 该时钟转储肯定具有许多损坏的值。 很难立即判断这是不是一个 k3conf 工具、基本的 TISCI 命令、还是该 SoC 特定实例(您的慢速"T"级器件)内更深入的内容。

    这个转储损坏时钟树的"U"级部分是随机进行的吗? 它仍然在引导、因此至少一些时钟可能是正常的。

    这是我之前从未见过的意外行为。 让我邀请一些人来了解有关这些 TISCI 命令和时钟树的更多知识。

    当提供0.85VDDCore 时、"U"级部件允许1GHz DSP。 您是否在该电压下供电?

    我想让您尝试在500 MHz 为 DSP 提供时钟、看看此时钟树是否损坏以及/或 DSP 是否仍显示为0Hz (在慢速模块中)。

    Br、
    雷塞

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    以及转储损坏时钟树的这一"U"等级部件是否随机发生了这种情况? 它仍在启动、因此至少一些时钟可能是正常的。

    HMM 我到目前为止只启动了两次。  我第一次把树弄乱、然后重新上电、树就被清理干净了。 我可以进行一系列重启、以查看其是否为间歇性问题。

    "U"级部件允许在提供0.85VDDCore 时使用1GHz DSP。 您在该电压下供电吗?

    是的、VDD_CORE 设置为0.85V。 已使用电压表进行验证、以实现两倍精度。

    我想请您尝试在500 MHz 为 DSP 提供时钟,看看是否有部分时钟树损坏和/或 DSP 仍显示为0Hz (在慢模块中)。

    还可以

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

    c7x_0 {
    	/*
    	 * Override C7x frequency to 1 GHz for max performance
    	 * Requires VDD_CORE to be at 0.85V
    	 */
    	clocks = <&k3_clks 208 0>;
    	assigned-clocks = <&k3_clks 208 0>;
    	assigned-clock-rates = <500000000>; /* 500Mhz */
    };
    

    以500MHz DSP 运行于良好模块上、导致74%的 c7x_1使用情况、在物体检测演示中实现~27fps。

    在慢速模块上运行此代码时、C7x 时钟转储仍报告0Hz、奇怪的是 ARM 现在的运行频率为1.4GHz、是否正好是巧合。

    但是、物体检测演示最终会使电子页启动器崩溃。 所以图层会变厚。

    e2e.ti.com/.../edgeai_5F00_launcher_5F00_crash.log

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

    尊敬的 Jonathan:

    在良好的模块上以500MHz DSP 运行,导致74%的 c7x_1使用情况,在物体检测演示中~27 fps。

    看起来很合理;这就是我对500 MHz 的期望。

    在慢速模块上运行此代码时,C7x 时钟转储仍然报告0Hz,奇怪的是 ARM 现在运行在1.4GHz,不确定这只是巧合。

    好的、那么这个慢速器件上当然仍然有问题。 是否将1.4GHz 列为 A53时钟速率选项? 通常在默认 DTS 中低于此值。 有一个设置为1.4GHz 的/boot/dtb/ti/k3-am62a7-sk-e3-max-opp.dtbo、我假设未应用该频率。 我不知道为什么会是1.4 GHz。 它可能链接较松、

    在 demo-init 崩溃的日志中、似乎这是 IPC (RPMesg)通道无法初始化所大致预测的、例如

    May 07 15:35:42 mitysom-am62ax edgeai-launcher.sh[1100]: _rpmsg_char_find_ctrldev: could not find the matching rpmsg_ctrl device for virtio2.rpmsg_chrdev.-1.13
    

    edgeai 演示试图通过 OpenVX 滑向 C7x 端,未能运行任何操作,然后导致 OpenVX 检测到故障,并可能导致进程在没有 systemd 管理的情况下死亡。

    C7x 内核的一些 PLL 问题可能会遇到这些问题。 如果您可以在器件上包含完整的引导日志、这可能有助于识别这一点。

    否则、我的建议是使用9.2 SDK 的 SYSFW 重新编译。 我相信我们在此版本中已修复了 AM62A C7x 的 PLL 问题。 您可以尝试将 linux-sdk-install/board-support/prebuilt-image/ti-sysfw 下的 sysfw 映像替换为9.2 SDK 中的映像

    Br、
    雷塞

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    好了,所以在这个速度较慢的设备上,当然仍然有问题。 是否将1.4GHz 列为 A53时钟速率选项? 通常在默认 DTS 中低于此值。 有一个设置为1.4GHz 的/boot/dtb/ti/k3-am62a7-sk-e3-max-opp.dtbo、我假设未应用该频率。 我不知道为什么会是1.4 GHz。 它可以松散链接

    我们的器件树始终应用0.85V、1.4GHz ARM 和1GHz DSP 更改、因为至少目前我们的所有模块都应该是 U 速度等级。

    用于比较的工作模块日志:

    e2e.ti.com/.../working_5F00_500Mhz_5F00_screenlog.txt

    在慢模块上启动后的首次引导、演示没有崩溃、因此下面是日志:

    e2e.ti.com/.../slow_5F00_500Mhz_5F00_demo_5F00_works_5F00_screenlog.txt

    第二次引导发生崩溃:

    e2e.ti.com/.../slow_5F00_500Mhz_5F00_demo_5F00_crash_5F00_screenlog.txt

    否则,我建议使用9.2 SDK 的 SYSFW 重新构建。 我相信我们在此版本中已修复了 AM62A C7x 的 PLL 问题。 您可以尝试将 linux-sdk-install/board-support/prebuilt-images/ti-sysfw 下的 sysfw 映像替换为9.2 sdk

    当然可以。  

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    否则,我建议使用9.2 SDK 的 SYSFW 重新构建。 我相信我们在此版本中已修复了 AM62A C7x 的 PLL 问题。 您可以尝试将 linux-sdk-install/board-support/prebuilt-images/ti-sysfw 下的 sysfw 映像替换为9.2 sdk

    使用09.02固件重建 u-boot、刷写了09.02 SDK sdcard 映像并替换 u-boot 和内核。  演示运行成功、时钟信息看起来正确。

    请注意,毫不奇怪的是 ti-sci-clk 驱动程序不是超级高兴,因为我认为 sysfw 再次损坏了兼容性。 启动时出现许多"recalc-rate failed"和"is_prepared failed"消息。  拥有非常依赖 sysfw 更新的内核提交使一个非常脆弱的感觉系统...

    对于09.01至09.02之间的 sysfw 更改、是否有版本说明?

    root@am62axx-evm:/opt/edgeai-gst-apps# k3conf dump processors
    |------------------------------------------------------------------------------|
    | VERSION INFO                                                                 |
    |------------------------------------------------------------------------------|
    | K3CONF | (version 0.3-nogit built Wed Mar 06 14:29:58 UTC 2024)              |
    | SoC    | AM62Ax SR1.0                                                        |
    | SYSFW  | ABI: 3.1 (firmware version 0x0009 '9.2.7--v09.02.07 (Kool Koala))') |
    |------------------------------------------------------------------------------|
    
    |-----------------------------------------------------------------------------------------|
    | Device ID | Processor ID | Processor Name       | Processor State | Processor Frequency |
    |-----------------------------------------------------------------------------------------|
    |   121     |       1      | WKUP_R5FSS0_CORE0    | DEVICE_STATE_ON | 800000000           |
    |     9     |       3      | MCU_R5FSS0_CORE0     | DEVICE_STATE_ON | 800000000           |
    |   208     |       4      | C7X256V0_C7XV_CORE_0 | DEVICE_STATE_ON | 1000000000          |
    |   135     |      32      | A53SS0_CORE_0        | DEVICE_STATE_ON | 1400000000          |
    |   136     |      33      | A53SS0_CORE_1        | DEVICE_STATE_ON | 1400000000          |
    |   137     |      34      | A53SS0_CORE_2        | DEVICE_STATE_ON | 1400000000          |
    |   138     |      35      | A53SS0_CORE_3        | DEVICE_STATE_ON | 1400000000          |
    |   225     |     128      | HSM0                 | DEVICE_STATE_ON | 500000000           |
    |-----------------------------------------------------------------------------------------|
    

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

    尊敬的 Jonathan:

    感谢您的尝试。 在现阶段、我认为这是一种频带辅助修复技术。 我很高兴听到基本问题得到解决、但这不是一个干净的解决方法、我建议长期解决。

    此步骤解决了 DSP 时钟/演示问题这一事实强烈表明、PLL 锁定是您所看到行为的根本。 只是为了确认一下、这不是一个幸运的启动、它在哪里工作、对吗? 您可以重新启动多次、并在"低"模块上看到一致的行为?

    接下来、我的第一个建议是升级到9.2 SDK。 考虑到您最近使用的是9.1 SDK 版本、这可能不是理想的选择。 9.2总体而言是更稳定的版本、升级到10.x SDK 后应明显更容易、因为这些版本将包括 Yocto 版本和内核 LTS 更新、这是值得的。

    替代方法是为9.1 SYSFW 的此 PLL 提供一个反向端口补丁。 这可能需要我们一段时间,我要跟进。

    我还被认为 SYSFW 向后兼容、因此您看到的这些错误是不可预料的。 如果您想坚持使用9.1 SDK、您能否提供更多有关在启动期间看到的错误的信息?

    Br、
    雷塞

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    感谢您尝试此版本。 在现阶段、我认为这是一种频带辅助修复技术。 我很高兴听到基本问题得到解决,但这不是一个干净的解决办法,我建议长期使用。

    这只是一个诊断步骤。 但希望能推动我们开发9.2 SDK。

    此步骤解决了 DSP 时钟/演示问题这一事实强烈表明 PLL 锁定是您看到的行为的根源。 只是为了确认一下、这不是一个幸运的启动、它在哪里工作、对吗? 您可以重新启动多次并在"低"模块上看到一致的行为?

    是的、连续多次重新启动都是有效的。

    接下来,我的第一个建议是升级到9.2 SDK。 考虑到您最近使用的是9.1 SDK 版本、这可能不是理想的选择。 9.2是一个更稳定的版本,升级到以后的10.x SDK 应该要容易得多,因为这些版本将包括 Yocto 版本和内核 LTS 更新,这是值得的。

    考虑到这一点、目前似乎只影响一个预生产单元。 我正在考虑发布9.1 SDK、并开始朝着9.2 SDK 版本迈进。

    我也被认为 SYSFW 向后兼容,因此您看到的这些错误是不可预料的。 如果您想继续使用9.1 SDK,您能否提供更多有关在启动时看到的错误的信息?

    以防这种情况有所帮助。

    U-Boot SPL 2023.04-00135-gabe18eed0306-dirty (May 07 2024 - 17:14:35 -0400)
    SYSFW ABI: 3.1 (firmware rev 0x0009 '9.2.7--v09.02.07 (Kool Koala)')
    NOTICE:  BL31: v2.9(release):v2.9.0-614-gd7a7135d32a8
    NOTICE:  BL31: Built : 10:35:05, Feb 15 2024
    I/TC: 
    I/TC: OP-TEE version: 4.0.0 (gcc version 9.2.1 20191025 (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10))) #1 Thu Feb 15 15:35:03 UTC 2024 aarch64
    
    ...
    [    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
    [    0.000000] Linux version 6.1.46-00086-gd28abd4af0db-dirty (jcormier@jcormier-MS-7A93) (aarch64-none-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025, GNU ld (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 2.33.1.20191209) #12 SMP PREEMPT Tue May  7 11:23:28 EDT 2024
    ...
    [    1.747428] input: tps65219-pwrbutton as /devices/platform/bus@f0000/20000000.i2c/i2c-0/0-0030/tps65219-pwrbutton.2.auto/input/input0
    [    1.760382] pca953x 1-0020: supply vcc not found, using dummy regulator
    [    1.767176] pca953x 1-0020: using no AI
    [    1.774509] mmc0: SDHCI controller on fa10000.mmc [fa10000.mmc] using ADMA 64-bit
    [    1.797985] am65-cpsw-nuss 8000000.ethernet: Failed to create device link (0x180) with 1-0020
    [    1.806812] am65-cpsw-nuss 8000000.ethernet: Failed to create device link (0x180) with 1-0020
    [    1.822310] debugfs: Directory 'pd:182' with parent 'pm_genpd' already present!
    [    1.822513] mmc1: CQHCI version 5.10
    [    1.830792] debugfs: Directory 'pd:182' with parent 'pm_genpd' already present!
    [    1.840574] debugfs: Directory 'pd:182' with parent 'pm_genpd' already present!
    [    1.851861] ti-sci-clk 44043000.system-controller:clock-controller: is_prepared failed for dev=42, clk=18, ret=-19
    [    1.862275] ti-sci-clk 44043000.system-controller:clock-controller: is_prepared failed for dev=42, clk=17, ret=-19
    [    1.872666] ti-sci-clk 44043000.system-controller:clock-controller: is_prepared failed for dev=42, clk=16, ret=-19
    ...
    [    1.774509] mmc0: SDHCI controller on fa10000.mmc [fa10000.mmc] using ADMA 64-bit
    [    1.797985] am65-cpsw-nuss 8000000.ethernet: Failed to create device link (0x180) with 1-0020
    [    1.806812] am65-cpsw-nuss 8000000.ethernet: Failed to create device link (0x180) with 1-0020
    [    1.822310] debugfs: Directory 'pd:182' with parent 'pm_genpd' already present!
    [    1.822513] mmc1: CQHCI version 5.10
    [    1.830792] debugfs: Directory 'pd:182' with parent 'pm_genpd' already present!
    [    1.840574] debugfs: Directory 'pd:182' with parent 'pm_genpd' already present!
    [    1.851861] ti-sci-clk 44043000.system-controller:clock-controller: is_prepared failed for dev=42, clk=18, ret=-19
    [    1.862275] ti-sci-clk 44043000.system-controller:clock-controller: is_prepared failed for dev=42, clk=17, ret=-19
    [    1.872666] ti-sci-clk 44043000.system-controller:clock-controller: is_prepared failed for dev=42, clk=16, ret=-19
    

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

    尊敬的 Jonathan:

    大家好、我认为这个问题已经解决(当然还有与 SDK/SYSFW 版本相关的注意事项)。

    您看到的生产设备也遇到了这个问题。 我们将继续跟踪此情况、但应该从9.2 SDK 开始进行解析。 当改变 DSP 时钟时、PLL 锁定问题往往出现、并且与特定单元隔离。

    SYSFW 旨在向后兼容、并且我们已成功地将9.2 SYSFW 应用于8.6版的版本。 通常情况下、此 SYSFW 工作正常、但请注意、以前存在的一些时钟在同一 ID 下不可用。 我认为这款器件42是 TIMER6

    以下上游提交旨在解决您看到的某些打印件。 此提交可应用于 ti-linux-6.1.y
    https://github.com/torvalds/linux/commit/ad3ac13c6ec318b43e769cc9ffde67528e58e555。 我的解释是、它会添加检查功能、以确保每个时钟在配置前都存在

    Br、
    雷塞

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    我也被认为 SYSFW 向后兼容,因此您看到的这些错误是不可预料的。 如果您想继续使用9.1 SDK,您能否提供更多有关在启动时看到的错误的信息?

    仅供参考、我刚刚进行了内核标签09.02.00.05的测试合并、而 ti-sci 错误消失了。  

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

    啊,很好!

    感谢大家耐心快速地解决问题。

    我目前正在关闭此 TT、但您可以在此处回复、以防您发现此解决方案未完全解决问题。