[参考译文] AM6442：以太网 LwIP ICSSG 示例帮助：无法打开 UDMA RX 通道 (AM64x-EVM、SDK 11.00.00.15)

尊敬的 Luca：

enet_lwip_icssg 示例在 MCU+ SDK v11.00.00.15 中按预期运行。 我已确认您所做的修改也不会对功能产生任何影响。 但是、日志看起来与未在运行之间通过系统复位来设置电路板的情况类似。 板载 UDMA 模块需要在运行之间进行系统复位、以恢复到复位状态。 因此、请在运行和测试之间重置系统。

跟进您的问题：

1. DebugP_assertNoLog (status == SystemP_Success) 是一项有效的检查、对于避免开发后期阶段出现问题至关重要。  注释掉 TI 不建议进行有效检查。
2. 如前所述、SysConfig 处于工作状态。 请在运行之间进行系统复位、以将 UDMA 模块设置为复位状态。
3. 这是 11.00.00.15 版本的预期行为。 这并不表示资源冲突。  

如果您需要进一步的支持或有任何疑问、请告知我们。

此致、
Teja。

尊敬的 Teja：

感谢您的回复和测试行为。

根据您的建议、我尝试了如下所述的系统重置。 首先、我关闭电路板的电源并使其打开、然后使用 F5 启动调试会话。 遗憾的是、结果与之前的测试相比保持不变。

我还尝试了另一种方法：给电路板上电后、我启动了调试会话、然后在使用 CCS 运行 enet_lwip_icssg 示例的 R5 内核上手动执行系统复位。

点击“System Reset“后、MAIN_Cortex_R5_0_0 线程从已停止→正在运行→HELDINRESET→正在运行转换。 但是、复位后不会打印任何调试日志、并且所有断点都会被忽略。 电路板对 ping 命令无响应、如文档中所述。 这表明重置未解决问题。

在调试时、我还注意到几个标有 ICSS 的线程。 我尝试手动启动这些设置、但这也没有任何影响。

当我切换到 Release Build 配置时、日志略有更改。 系统成功初始化大多数组件、包括 EnetUdma、Icssg 和 EnetPer。 但是最后一步 enet_open () 仍然失败,触发与调试模式相同的断言:

MAIN_Cortex_R5_0_0：=========================

MAIN_Cortex_R5_0_0：      Enet LWIP App       

MAIN_Cortex_R5_0_0：=========================

MAIN_Cortex_R5_0_0：启用时钟！

MAIN_Cortex_R5_0_0：EnetAppUtils_redueCoreMacAllocation：将 CoreID：1 的 Mac 地址分配从 4 减少到 1

MAIN_Cortex_R5_0_0：EnetUdma_openRxCh：2328

MAIN_Cortex_R5_0_0：EnetUdma_openRxCh：2328

MAIN_Cortex_R5_0_0：EnetHostPortDma_open：121

MAIN_Cortex_R5_0_0：Icssg_openDma：747

MAIN_Cortex_R5_0_0：Icssg_open：1090

MAIN_Cortex_R5_0_0：EnetPer_open：1231

MAIN_Cortex_R5_0_0：Enet_open：933

MAIN_Cortex_R5_0_0：Enet_open 失败

MAIN_Cortex_R5_0_0：断言@在 syscfg/ti_enet_open_close.c 中的行：324：  失败！！

这表明尽管大多数 ENET 堆栈组件都在正确初始化,但 enet_open () 仍然失败,这使我们回到了同样的问题。

考虑到这一点、我有几个问题：

1. 是否有替代方法来执行系统复位、从而保留调试日志可见性并允许断点正常运行？
2. 在释放模式下观察到的行为是否表示任何进展或建议不同的潜在问题？
3. 是否有任何其他诊断工具或日志记录机制可以让您更深入地了解 enet_open () 为何会失败？

我感谢您提供的任何进一步指导、如果需要、我很乐意提供其他详细信息或日志。

此致

Luca.

尊敬的 Luca：

1. 发出系统复位命令的正确方法是先断开内核、然后进行系统复位。 如果在内核仍处于连接状态时发出系统复位命令、它将导致系统崩溃、从而导致不正确的行为
2. 上面的日志也指失败的示例、但错误消息会替换为代码中的行号。 初始化仍然失败。
3. 您是否对 SDK 进行了任何更改？ 您是否在开箱即用示例时遇到了任何问题？ 您能否尝试在不对 SDK 进行任何修改的情况下运行示例？

您是否还可以检查您在设置中使用的 SBL 版本？ 该错误看起来是资源分配问题。 SBL 版本与预期不同也会导致类似的问题。 请使用开箱即用示例进行测试后告知我们结果。

此致、
Teja。

尊敬的 Teja：

我遵循了您有关系统重置的指导、首先断开核心连接、但结果保持不变。

此外、我还完全重新安装了 SDK 和 Code Composer Studio、无需进行任何修改即可恢复完整的开箱即用设置。 不过、在不进行任何更改的情况下运行示例仍会导致相同的问题。 在故障排除过程中、我从 Linux 器件树中移除了以太网端口、怀疑 A53 和 R5 内核之间存在潜在的资源冲突。 不幸的是、这并没有解决问题。 然后、我从 Linux-RT SDK 版本 11.01.05.03 重新安装了默认的 Yocto SD 卡映像、确保设置返回到开箱即用配置。

为了进行进一步测试、我运行了hello_world和ipc_rpmsg_echo示例（均基于 FreeRTOS）、并按预期运行。 但是、我仍然遇到一些问题、特别是 LwIP ICSSG 示例（和）enet_lwip_icssgeneth_icssg_tcpserver。

在提到 SBL 版本之前、您指的是 U-Boot 版本？ 如果是、我当前使用的是 version2025.01-00527-gd2a72467939e。 如果您指的是不同的 SBL 版本、能否请告知您如何进行检查？

您提到此问题可能与资源分配有关。 如果根本原因确实是 A53 和 R5 内核之间的资源冲突、是否有必要手动将特定的以太网端口分配给各个 CPU？ 目前、A53 可以访问所有三个以太网端口。 如果需要手动分配、如何执行分配。 如果没有、您能否说明 R5 和 A53 内核如何共享或拆分以太网端口？

我期待您的进一步见解。

此致、
Luca.

尊敬的 Luca：

我以为您是独立运行 R5 示例。 您是否将该应用程序与 Linux 一起使用？ 如果是、则必须完全阻止 Linux 在启动期间不探测 ICSSG 驱动程序。 在当前的 ICSSG 和 CPSW 资源在 A53 和 R5 内核之间共享、但 在给定的时间只有一个内核可以拥有该资源。 在您的案例中、ICSSG 资源似乎并未完全放弃、驱动程序仍在接受探测、这导致 Linux 拥有外设、然后 R5 内核无法成功分配。  

您必须禁用端口和驱动程序以及设备树中的相应模块、然后重建设备树。 我附加了一个参考来执行同样的操作。

Add k3-am642-evm-icssg1-disable.dtso overlay file that disables
icssg1-eth from Linux so that icssg peripherals can be used by
RTOS or some other OS running on R5 core.

Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
---
 arch/arm64/boot/dts/ti/Makefile               |  7 +--
 .../dts/ti/k3-am642-evm-icssg1-disable.dtso   | 49 +++++++++++++++++++
 2 files changed, 53 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm64/boot/dts/ti/k3-am642-evm-icssg1-disable.dtso

diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 6bd06bd76b68..0fd95b7df5a8 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -76,6 +76,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-am642-evm.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am642-evm-nand.dtbo
 dtb-$(CONFIG_ARCH_K3) += k3-am642-evm-icssg1-dualemac.dtbo
 dtb-$(CONFIG_ARCH_K3) += k3-am642-evm-icssg1-dualemac-mii.dtbo
+dtb-$(CONFIG_ARCH_K3) += k3-am642-evm-icssg1-disable.dtbo
 dtb-$(CONFIG_ARCH_K3) += k3-am642-evm-pcie0-ep.dtbo
 dtb-$(CONFIG_ARCH_K3) += k3-am642-phyboard-electra-rdk.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am642-sk.dtb
@@ -235,8 +236,8 @@ k3-am62p5-sk-microtips-mf103hie-lcd2-dtbs := k3-am62p5-sk.dtb \
     k3-am62p5-sk-microtips-mf103hie-lcd2.dtbo
 k3-am642-evm-icssg1-dualemac-dtbs := \
     k3-am642-evm.dtb k3-am642-evm-icssg1-dualemac.dtbo
-k3-am642-evm-icssg1-dualemac-mii-dtbs := \
-    k3-am642-evm.dtb k3-am642-evm-icssg1-dualemac-mii.dtbo
+k3-am642-evm-icssg1-disable-dtbs := \
+    k3-am642-evm.dtb k3-am642-evm-icssg1-disable.dtbo
 k3-am642-evm-pcie0-ep-dtbs := \
     k3-am642-evm.dtb k3-am642-evm-pcie0-ep.dtbo
 k3-am642-tqma64xxl-mbax4xxl-sdcard-dtbs := \
@@ -323,7 +324,7 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
     k3-am62p5-sk-microtips-mf101hie-panel.dtb \
     k3-am62p5-sk-microtips-mf103hie-lcd2.dtb \
     k3-am642-evm-icssg1-dualemac.dtb \
-    k3-am642-evm-icssg1-dualemac-mii.dtb \
+    k3-am642-evm-icssg1-disable.dtb \
     k3-am642-evm-pcie0-ep.dtb \
     k3-am642-tqma64xxl-mbax4xxl-sdcard.dtb \
     k3-am642-tqma64xxl-mbax4xxl-wlan.dtb \
diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm-icssg1-disable.dtso b/arch/arm64/boot/dts/ti/k3-am642-evm-icssg1-disable.dtso
new file mode 100644
index 000000000000..dc04e2999e97
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am642-evm-icssg1-disable.dtso
@@ -0,0 +1,49 @@
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
+/**
+ * DT overlay for enabling 2nd ICSSG1 port on AM642 EVM
+ *
+ * Copyright (C) 2020-2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include "k3-pinctrl.h"
+
+&oc_sram {
+    #address-cells = <1>;
+    #size-cells = <1>;
+
+    r5f0_0_sram: r5f0_0_sram@0 {
+        reg = <0x0 0x180000>;
+    };
+};
+
+&main_r5fss0_core0 {
+    sram = <&r5f0_0_sram>;
+};
+
+&cpsw_port2 {
+    status = "disabled";
+};
+
+&icssg0 {
+    status = "disabled";
+};
+
+&icssg1 {
+    status = "disabled";
+};
+
+&ospi0 {
+    status = "disabled";
+};
+
+&mdio_mux_1 {
+    status = "disabled";
+};
+
+&icssg1_eth {
+    status = "disabled";
+};
-- 
2.34.1

如果您遇到任何其他问题、敬请告知。  

此致、
Teja。

尊敬的 Teja：

感谢您的响应和参考器件树叠加层。 我按照建议应用了覆盖图、它似乎已生效、ifconfig 不再显示两个以太网端口、这表明补丁已成功应用。

但是、问题仍然存在。 经过进一步检查、U-Boot 似乎正在引导期间探测 ICSSG1 以太网端口 (eth2)。 以下是启动日志中的相关代码片段：

U-Boot 2025.01-gd2a724679e (2025 年 7 月 18 日 — 17：37：52 +0200)
SoC：AM64X SR2.0 HS-SOC FS
型号：Texas Instruments AM642 EVM
板：AM64-EVM 修订版 D
[...]
网络：eth0：以太网@8000000port@1、eth2：icssg1-eth-port @0

这个 U-Boot 探测是否会导致 ICSSG 资源保持被占用、从而阻止 R5 内核成功获取这些资源？ 如果是、您是否有关于阻止 U-Boot 初始化或探测 eth2 的建议？

此外、根据您的建议、我在无 Linux 的环境中测试了 R5 示例、可以按预期工作、而不会出现任何问题。 因此、问题肯定是源于共享外设所有权方面的冲突。  

感谢您的持续支持！

此致、
Luca.

尊敬的 Luca：

您是否可以将以下行添加到 k3-am64x-evm.dts 文件并重新检查？

&icssgX_eth {
    status = "reserved";
};
&cpswXg {
    status = "reserved";
};

这应该完全禁止探测 ICSSG。 要验证其他更改（例如 CPSW）的有效性、您可以与 Linux 一起在 R5 上运行 CPSW 示例而不是 icssg 示例。 这应该能让我们了解是否实际停止了探测的外设。

此致、
Teja。

尊敬的 Luca：

这些是我从我们的 Linux 专家那里得到的建议。 请对此进行一次测试、并告知我调查结果。 同时、我将要求我们的 Linux 团队查看崩溃日志。  

1. 删除此主题中先前建议的所有更改、并从干净的 DTS 开始、没有任何覆盖层
2. 在 DTS 文件中添加确切的行：
   

   &icssg0_eth {
       status = "reserved";
   };
   &icssg1_eth {
       status = "reserved";
   };
   &cpsw3g {
       status = "reserved";
   };

   
   前一篇文章中的“X"表示“表示系统中存在的实例。

谢谢。此致、
Teja。

尊敬的 Luca：

我已将此问题的详细信息发送给我们的 Linux 专家。 敬请期待 2 天内回复。  

此致、
Teja。

尊敬的 Luca：

在与我们的 Linux 专家审查后、我们了解到必须更新 u-boot、而不是 探测外设。 可以在文件“arch/arm/dts/k3-am642-evm-u-boot.dtsi"中“中更新它、并且必须再次编译 u-boot。  

&icssg1_eth {
    status = "reserved";
};
&cpsw3g {
    status = "reserved";
};

此致、
Teja。

尊敬的 Luca：

我们的 Linux 专家正在研究这个问题。 请在 2 天内回复此问题。

此致、
Teja。

尊敬的 Teja：

关于内核崩溃、我注意到 LwIP 示例中使用的 DDR 存储器区域起始地址设置为 0x80000000、这与 Linux 存储器空间重叠、并导致 Linux 端崩溃。 将地址更改为 0xA0100000 表示了崩溃。 但是、这一变化并没有解决原来的问题。

经过进一步调查、我看到了 SDK 开发人员指南： AM64x MCU+ SDK：修改资源分配中的“修改资源分配“部分

我在资源分区工具中看到、R5 内核与 A53 内核共享多个资源、包括以太网端口。 我怀疑这种资源共享可能会导致问题的发生。 按照指南操作、我能够禁用与 A53 内核的默认资源共享。 完成这些步骤后、生成了两个文件：boardcfg_blob.bin 和 boardcfg_blob_linux.bin。

我已经弄清楚如何将 boardcfg_blob.bin 应用于用于独立 R5 应用程序的 SBL、并已成功将更新的 SBL 刷写到目标中。 但是、我不确定如何在 Linux 端应用这些文件。

您能否提供有关如何继续的建议？

此致、
Luca.

尊敬的 Luca：

如果您使用 SPL 引导流程、则更新用于资源配置的 SBL 映像无效、因为资源配置将是正在刷写的 Linux 映像的一部分。 但在您的中、由于 Linux 仍在探测以太网外设、因此我们必须找到一种方法来从 uboot 级别本身禁用它们。  

您能否对早期的补丁进行轻微修改、并将“reserved"状态“状态设置为“disabled"？“？ 虽然这两种器件的运行时行为相同、但我了解到、如果完全禁用外设、最好保持禁用它们。

此致、
Teja。

尊敬的 Teja：

感谢您的澄清！ 我更新了补丁、将“保留“状态替换为“已禁用“、但很遗憾、问题仍然存在。

您是否能够建议进一步的步骤或调整？

编辑：日志中显示“探测 prueth 驱动程序失败“和“探测 am65_cpsw_Nuss 驱动程序失败“。 u-boot 似乎尝试探测驱动程序、但由于在设备树中被禁用、因此失败。 这种探测尝试是否会导致问题？  

以下是上下文的日志：

U-Boot 2025.01-gd2a72467939e-dirty (Aug 20 2025 - 17:45:07 +0200)

SoC:   AM64X SR2.0 HS-FS
Model: Texas Instruments AM642 EVM
Board: AM64-EVM rev D
DRAM:  2 GiB
Core:  102 devices, 33 uclasses, devicetree: separate
MMC:   mmc@fa10000: 0, mmc@fa00000: 1
Loading Environment from nowhere... OK
In:    serial@2800000
Out:   serial@2800000
Err:   serial@2800000
Failed to probe am65_cpsw_nuss driver
Failed to probe prueth driver
Net:   No ethernet found.
Hit any key to stop autoboot:  0

此致
Luca.