[参考译文] AM62P：Cadence-QSPI 探头故障

> kern :info :[  0.153619 <  0.012380>] ti-sci 44043000.system-controller: abi: 4.0 (固件版本0x000b '11.0.2-v11.00.02 (花哨 RAT)")

这可能是您的问题所在。 TIFS/DM FW 版本与我们即将推出的 SDK v11.0 (e/o March)关联、后者使用内核6.12、而您使用的是内核6.6。 是否可以在内核中使用"firmware rev 0x000a '10.1.8 --v10.01.08 (Fiery Fox )"？ TIFS 和 DM 适用。 此外、确保将正确的电路板配置与该 SDK/内核版本(在 U-Boot 中)关联、以便能够分配资源。 最好是在当前 SDK v10.1之后更密切地建模。

此致、Andreas

Andreas Dannenberg

我可以确认、使用之前的固件时、它按预期工作、因此您的建议是正确的。

尽管目前的解决方案并不适合我们、但我们期望在固件和操作系统驱动程序之间的接口上具有兼容性。

我们需要这一点、因为

 -固件/引导加载程序更新工作流程和内核/OS 更新工作流程不同。

 - meta-ti 目前支持6.6和6.12内核与此`TI_preferred_bsps`变量(ti-6_6, ti-6_12,..),我们需要能够使用最新的 meta-ti scarthgap 分支,即使在使用以前的 TI 6_6内核时。

有什么建议吗？

仅供参考、请在此处找到随附的日志： e2e.ti.com/.../AM62P_5F00_Latest_5F00_TISCI_5F00_Compatibility_5F00_Issue_5F00_With_5F00_TI_5F00_Linux_5F00_6_5F00_6.txt

Unknown 说：

我可以确认、使用以前的固件时、它按预期工作、因此您的建议是正确的。

感谢您的确认。

Unknown 说：

尽管当前的解决方案对我们来说并不起作用、但我们期望我们在固件和操作系统驱动程序之间的接口上具有兼容性。

当固件和内核使用相同的 ABI 级别时、它们应从根本上协同工作。 对于 SDK v10.x 和 SDKv11.x 的固件、这是 "ABI：4.0" (请参阅您的引导日志)、因此我希望事情可以正常工作、但我没有详细分析这一点。 固件版本是您的 NG 和 OG 场景之间的唯一区别、还是您更改了与 U-Boot 相关的任何其他内容？

此致、Andreas

Xiange Tian 说：

您是否更改了与 U-Boot 相关的任何其他内容？

其他方面没有变化

Xiange Tian 说：

对于 SDK v10.x 和 SDKv11.x 的固件、这是 "ABI：4.0" (请查看您的引导日志)、因此我希望一切正常、但我尚未详细分析

我已就此与我们的固件专家联系；将告诉您我可以在此处了解哪些背景信息、以及我们是否可以对此做些什么或更好地进行管理。

我们需要这一点、因为

 -固件/引导加载程序更新工作流程和内核/OS 更新工作流程不同。

 - meta-ti 目前支持6.6和6.12内核与此`TI_preferred_bsps`变量(ti-6_6, ti-6_12,..),我们需要能够使用最新的 meta-ti scarthgap 分支,即使在使用以前的 TI 6_6内核时。

理想情况下、您希望一起更新这些内容、但也有一个有效的方案。

这可能并不理想、但您可以有一个额外的基于 initramfs 的小型临时内核/文件系统(例如、您甚至可以直接将文件系统烘烤到内核中  、如下所示：e2e.ti.com/.../faq-sk-am62-how-to-build-initramfs-into-kernel-image、从而生成单文件解决方案)、并始终与引导加载程序一起更新此文件、然后引导到该文件系统中。 在此映像中、您可以通过何种方式触发/执行主文件系统/内核映像的更新。

此致、Andreas

Xiange Tian 说：

在内部讨论这件事听起来好像已经有一个离线/ IRC 的讨论与您一起。

正确、为了确认当前发现、我非常有信心这是根本原因、测试完成后、我将在此处确认。

您好 Andreas Dannenberg

很抱歉跳进来、我一直在积极测试这个问题。

我使用最新推荐的配置文件(https://git.ti.com/cgit/ti-u-boot/ti-u-boot/tree/board/ti/am62px?h=ti-u-boot-2025.01)、在我们的定制 Verdin AM62P 硬件和 TI AM62P SK 电路板上运行了几个测试、包括 ti-linux-firmware 11.0.7-v11.00.07 (花哨 Rat)、U-Boot (基于 ti-u-boot-2024.04)和 Linux (基于 ti-linux-6.6.6.y)。

观察结果：

• QSPI DMA 问题：原始问题 TI-UDMA 485c01000.dma-controller：bchan0 cfg 失败-22错误 与 QSPI 相关的信息不再存在。
• CPSW 回归： 以太网端口(CPSW)在 Linux 中无法正常工作。
  
  

  [    1.851949] am65-cpsw-nuss 8000000.ethernet: initializing am65 cpsw nuss version 0x6BA01903, cpsw version 0x6BA81903 Ports: 3 quirks:00000006
  [    1.864839] am65-cpsw-nuss 8000000.ethernet: initialized cpsw ale version 1.5
  [    1.871976] am65-cpsw-nuss 8000000.ethernet: ALE Table size 512
  [    1.878556] am65-cpsw-nuss 8000000.ethernet: CPTS ver 0x4e8a010d, freq:500000000, add_val:1 pps:0
  [    1.889714] am65-cpsw-nuss 8000000.ethernet: Failed to get tx dma irq -6

• 我仔细检查并确认所有相关更改、包括此提交( https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/?h=ti-u-boot-2025.01&id=cc48dd0802c53a7876bdf720344225c034ad1ce5 )、都在我的电路板配置中。
• 使用上述软件配置的最新配置文件时、TI AM62P SK 板上也存在相同的 CPSW 回归。

您能帮助确定这里可能缺少的内容吗？

日志：

• AM62P SK 板 CPSW 回归： /cfs-file/__key/communityserver-discussions-components-files/791/AM62P_5F00_SK_5F00_Board_5F00_CPSW_5F00_Not_5F00_Working_5F00_logs.txt
• 定制 AM62P 硬件(Verdin AM62P)电路板 CPSW 回归： /cfs-file/__key/communityserver-discussions-components-files/791/Verdin_5F00_AM62P_5F00_Board_5F00_CPSW_5F00_Not_5F00_Working_5F00_logs.txt

我们的目标是使 QSPI 在不出现 DMA 错误的情况下工作、同时确保 AM62P 上的 CPSW/Ethernet 端口等关键功能不会回归、并具有：

• TI-LINUX-firmware 11.0.7--v11.00.07 (花哨机)
• U-Boot (基于 ti-u-boot-2024.04)
• Linux (基于 ti-linux-6.6.y)

谢谢你。

此致、
第 P 部分

Parth、

我离开办公室直到3月底。 我会在回来后再研究一下

此致、Andreas

尊敬的 Parth：

您能否检查一下您的代码库中是否包含2025 u-boot 中的这个提交函数？
https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/?h=ti-u-boot-2025.01&id=cc48dd0802c53a7876bdf720344225c034ad1ce5

此致、
Vishal

尊敬的 Vishal Mahaveer：

我之前提到过、是的、这个提交操作是我要测试的 u-boot 代码库的一部分。

Unknown 说：

i 仔细检查并确认所有相关更改、包括此提交( https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/?h=ti-u-boot-2025.01&id=cc48dd0802c53a7876bdf720344225c034ad1ce5 )、都在我的主板配置中。

谢谢你。

此致、
第 P 部分

尊敬的 Vishal Mahaveer：

通过内核提交 https://git.ti.com/gitweb?p=ti-linux-kernel/ti-linux-kernel.git;a=commit;h=2a22ced08c021e976c7c01b9d113ae16a77b03f2 和最新的 U-Boot 电路板配置更新( https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/?h=ti-u-boot-2025.01&id=cc48dd0802c53a7876bdf720344225c034ad1ce5 和 https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/board/ti/am62px/rm-cfg.yaml?h=ti-u-boot-2025.01&id=6905ef58d3e256e02c15fa995f5934eaa49b640d )、我不再观察到 QSPI DMA 错误、并且两个以太网(CPSW)端口似乎都正常工作。

但是、我现在在暂停-恢复用例中遇到了一种新的回归、这种回归以前效果很好。 从暂停状态恢复后、并非所有 CPU 内核都恢复在线、无法实现后续的暂停-恢复和其他功能。

完整日志：
/cfs-file/__key/communityserver-discussions-components-files/791/Verdin_5F00_AM62P_5F00_DMA_5F00_CPSW_5F00_Working_5F00_Suspend_5F00_Resume_5F00_Broken_5F00_26032025.txt

我可以确认这个问题是在更新 U-Boot 配置文件后专门出现的、因为仅在进行上述 Linux 更改时、暂停-恢复就可以正常工作。

您能否帮助确定在同步最新的 tifs-rm-cfg 和 rm-cfg 文件后、可能导致暂停-恢复失败的 U-Boot/Linux 内核设置中缺少的任何更改？

谢谢你。

此致、
第 P 部分

尊敬的 Parth：

Unknown 说：

我可以确认、此问题是在更新 U-Boot 配置文件后专门出现的、因为仅对上述 Linux 更改、暂停恢复就可以正常工作。
[/报价]

我认为该行为与 RM boardcfg 更新无关。

您能分享用于构建 OPTEE 的构建命令吗？

此致、
Vishal

尊敬的 Vishal Mahaveer：

我正在为 TFA 启用暂停支持的以下命令(k3_PM_system_suspend=1)、如 SDK 文档中所述。

https://software-dl.ti.com/processor-sdk-linux/esd/AM62PX/10_01_10_04/exports/docs/linux/Foundational_Components_OPTEE.html
https://software-dl.ti.com/processor-sdk-linux/esd/AM62PX/10_01_10_04/exports/docs/linux/Foundational_Components_ATF.html

如前所述、在相同的设置下、使用相同的 OP-TEE 和 TFA 版本时、暂停恢复即可正常工作、而无需 rm boardcfg 更新。

TFA：
make arch=aarch64 cross_compile="$cross_compile_64" PLAT=K3_PM_system_suspend=1 target_Board=lite spd=opteed

OPTEE：
make cross_compile="$cross_compile_32" cross_COMPILE64="$cross_compile_64" platform=k3-am62px CFG_arm64_core=y

只是重申一下、

我们的目标是在不出现 DMA 错误的情况下使 QSPI 工作、同时确保 AM62P 的关键功能暂停恢复/低功耗模式、以太网等不会回归、并具有：

• TI-LINUX-firmware 11.0.7--v11.00.07 (花哨机)
• U-Boot (基于 ti-u-boot-2024.04)
• Linux (基于 ti-linux-6.6.y)

此致、
第 P 部分

尊敬的 Parth：

我询问了 OPTEE build 命令、因为我们已知如果在 OPTEE 中启用了日志记录、DeepSleep 会不起作用。

此致、
Vishal

尊敬的 Parth：

您共享的日志显示了 OPTEE 调试标志。
您可以尝试禁用 OPTEE 调试标志吗？

我们无法在使用您提到的相同软件组件组合时重现此问题。

此致、
Vishal

你好、 Vishal Mahaveer、

前面提到的暂停-恢复回归现已在我这边得到解决、并且由于 DMA 问题而导致的原始 Cadence QSPI 探针故障也得到解决。

暂停-恢复问题的根本原因是未签名的 OP-TEE 映像导致optee-rng无法在 Linux 中正常运行。

感谢您的支持。

此致、
第 P 部分