• 状态 Resolved
  • 已锁定 已锁定
  • 回复 15 回复
  • 订户 0 订户
  • 视图 592 视图
  • 用户 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.

[参考译文] AM6421：AM6421：可以在 Linux 中使用单个实例启用 PRU_ICSSG0 RGMII2/RGMII1吗？

admin
Guru**** 2478765 points
Other Parts Discussed in Thread: AM6421, SYSCONFIG

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1456855/am6421-am6421-can-pru_icssg0-rgmii2-rgmii1-be-enabled-in-linux-with-a-single-instance

器件型号：AM6421
主题中讨论的其他器件： SysConfig

工具与软件：

我们正在设计具有以下元件的定制电路板：

处理器：AM6421
PHY：DP83822
配置：
a)两个以太网端口、用于使用 MII 连接和运行 FreeRTOS 的 R5F 的工业协议。
b)一个 OPC UA 以太网端口(使用运行 Linux 的 A53的 RMII/RGMII 连接)。

约束条件：
当将 PRU_ICSSG1用于 EtherCAT (示例用例)时、由于引脚冲突、具有 RMII 连接的 CPSW 块无法用于 OPC UA 端口：

IOSET1：CRS 和 COL 引脚冲突。
IOSET2：MDIO 引脚冲突。
OPC UA 唯一可行的选择是将 PRU_ICSSG0与 RGMII 搭配使用。

查询：
可以在 Linux 中使用单个实例启用 PRU_ICSSG0 RGMII2/RGMII1吗？
非常感谢有关在 Linux 中启用和配置此设置的任何参考或指导。

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

    您好 Nikhil：

    是的、我们确实支持在 ICSSG 实例中仅使用2个可能 PRU 以太网端口中的一个。 这实际上是 AM64x EVM 的默认行为、因此您可以参阅该文件以获取我们如何仅启用单个 PRU 以太网端口的模板：
    TI-linux-kernel-6.6.6.32+git-ti/arch/arm64/boot/dts/ti/k3-am642-evm.dts

    Linux SDK 文档表明、应在 Linux devicetre 文件中启用未使用的端口并将其标记为"固定链接"。 但是、我认为这是错误的、因为上面的示例 devicetree 文件会明确禁用未使用的端口。 我已经在 Linux SDK 的文档中针对这一行提交了一个错误报告： https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/10_00_07_04/exports/docs/linux/Foundational_Components / PRU-ICSS / Linux_Drivers / PRU_ICSSG_Ethernet.html

    此致、

    Nick

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

    感谢快速响应  

    a)  ti-linux-kernel-6.6.32+git-ti/arch/arm64/boot/dts/ti/k3-am642-evm.dts： 无法导航链接。

    b)是否可以在 Linux for OPCUA 中使用不带 MDIO 的 CPSW 端口？ 可通过寄存器配置(strap)寄存器完成配置。

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

    您好 Nikhil：

    在这些论坛上、我们支持 AM64x Linux SDK。 在下载的 Linux SDK 中、您可以在 board-support/ti-linux-kernel-x.x.x 文件夹下找到 Linux 代码。

    我将您的主题重新分配给另一位团队成员、以评论 CPSW 问题。

    此致、

    Nick

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

    您好、Nikhil：

    Unknown 说：
    B)是否可以在 Linux 中使用不带 MDIO 的 CPSW 端口用于 OPCUA？ 考虑通过寄存器捆绑寄存器完成的配置。

    请问为什么要在没有 MDIO 的情况下使用 CPSW 端口？ 通常、对于 Linux、在启动过程中、需要通过 MDIO 检测 PHY 并连接相关的 PHY 驱动程序。  

    根据我的理解、通常当需要 MAC 到 MAC 连接时、不需要 MDIO、并且必须在 Linux 设备树中启用"固定链接"属性。

    -道林

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

    尊敬的 Daolin：

    当将 PRU_ICSSG1用于 EtherCAT (示例用例)时、由于引脚冲突、具有 RMII 连接的 CPSW 块无法用于 OPC UA 端口：

    IOSET1：CRS 和 COL 引脚冲突。
    IOSET2：MDIO 引脚冲突。

    我想如果我们能够通过折衷 MDIO 引脚来使用 CPSW 中的 IOSET2、并且可通过寄存器配置(strap)来完成配置。  

    谢谢！

    Nikhil

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

    感谢 Nick 的回复。

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

     , 道歉回到同一个线程,因为它有上下文。  是否可以在具有 RMII 接口的 Linux 中使用具有不同 MDIO 集的 CPSW？ MDIO set information : PRG1_MDIO0_MDIO , PRG1_MDIO0_MDC。  在 MCU_PLUS_SDK 中,这是不可能的,因为 SysConfig 会限制它。

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

    您好、Nikhil：

    Unknown 说：
    是否可以在带有 RMII 接口的 Linux 中使用具有不同 MDIO 集的 CPSW？ MDIO set information : PRG1_MDIO0_MDIO , PRG1_MDIO0_MDC。  在 MCU_PLUS_SDK 中,由于 SysConfig 对其进行了限制,因此无法实现。

    我认为 SysConfig 对其进行了限制、因为正如您提到的、将会发生 pinmux 冲突。  

    Unknown 说：
    IOSET1：CRS 和 COL 引脚冲突。
    IOSET2：MDIO 引脚冲突。

    您能否具体解释哪些引脚(包括引脚编号和引脚名称)与 CPSW 的 MDIO 发生冲突？ 您能否共享设备树的副本(包括导致冲突的当前 Pinmux 配置)？

    [报价 userid="497949" url="~/support/processors-group/processors/f/processors-forum/1456855/am6421-am6421-can-pru_icssg0-rgmii2-rgmii1-be-enabled-in-linux-with-a-single-instance "] 约束条件：
    当将 PRU_ICSSG1用于 EtherCAT 时(示例用例)、由于引脚冲突、具有 RMII 连接的 CPSW 块无法用于 OPC UA 端口：[/QUOT][/support/processors-group/processors/f/processors-forum/1456855/am6421-am6421-can-pru_icssg0-rgmii2-rgmii1-be-enabled-in-linux-with-a-single-instance 报价 USERID="497949" URL"~"OPC UA 唯一可行的选项是将 PRU_ICSSG0与 RGMII 配合使用。[/QUOT]

    是否有特定原因需要将 PRU_ICSSG1与 CPSW 一起使用、或者带有 CPSW 的 PRU_ICSSG0是否足够？

    -道林

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

    尊敬的 Daolin：

    感谢您的答复。

    处理器：AM6421
    PHY：DP83822

    非线性

    • 两个用于工业协议的以太网端口、使用 MII 连接与运行 FreeRTOS 的 R5F。
    •  一个用于 OPC UA 的以太网端口、使用 RMII/RGMII 连接并运行 Linux 的 A53。

    当前配置和约束

    • Industrial Port (MII)-> PRU_ICSSG1 ->(syscfg 与适用于 EtherCAT 的 SDK 中给出的示例相同、也附加在底部)
    • OPCUA 端口(RMII)-> CPSW

         CPSW RMII 端口与一目了然的具有两个 MII 端口的 PRU_ICSSG1的引脚冲突信息

    备选方案

    对于工业协议、我们不希望将 PRU_ICSSG1切换到 PRU_ICSSG0、因为一个版本的硬件和 EVM 已经与 PRU_ICSSG1配合使用。

    选项1：

    • 工业端口(MII)：PRU_ICSSG1
    • OPCUA 端口(RMII)：CPSW -> IOSET2、但 MDIO 端口不同：PRG0_MDIO0_MDC 、PRG0_MDIO0_MDIO  

    选项2：

    • 工业端口(MII)：PRU_ICSSG1
    • OPCUA 端口(RGMII)：PRU_ICSSG0

    查询：

    对于 Linux 中的 CPSW、方案1是否可实现？ 如果是、您能否提供任何相关文档或指导？ 如果没有、我们需要继续执行选项2。我们期待您对此事的意见。

    SYSCFG

    e2e.ti.com/.../8561.Ethercat_5F00_syscfg.txt

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

    您好、Nikhil：

    对于 COL 和 CRS 引脚冲突：

    我仔细检查了所连接的 syscfg、并注意到您提到的 CPSW 接口的以下引脚与 ICSSG 接口的 CRS 和 COL 发生了冲突。这些引脚似乎被分配给了 ICSSG 接口的一组完全不同的信号。 这些引脚似乎分配给了 SysConfig 中的 PRU_ICSSG1_IEP.EDIO_DATA_IN_OUT 信号。 事实上、CRS 和 COL 信号似乎根本没有在您连接的 SysConfig 中分配？

    您共享的 CPSW 引脚与 ICSSG 接口的 CRS 和 COL 发生冲突：

    焊球名称 CPSW 信号 ICSSG 信号
    PRG1_PRU0_GPO9   RMII_REF_CLK PR1_MII0_COL
    PRG1_PRU0_GPO10   RMII1_RX_ER PR1_MII0_CRS
    PRG1_PRU1_GPO9   RMII1_RXD1 PR1_MII1_COL
    PRG1_PRU1_GPO10   RMII1_TXD0 PR1_MII1_CRS

    附加的 SysConfig：

    ethercat1.pru_ICSSG1_IEP.EDIO_DATA_IN_OUT28.$inductestSolution ="PRG1_PRU0_GPO9"；
    ethercat1.pru_ICSSG1_IEP.EDIO_DATA_IN_OUT29.$inductestSolution ="PRG1_PRU0_GPO10"；
    ethercat1.pru_ICSSG1_IEP.EDIO_DATA_IN_OUT30.$inductestSolution ="PRG1_PRU1_GPO9"；
    ethercat1.pru_ICSSG1_IEP.EDIO_DATA_IN_OUT31.$inductestSolution ="PRG1_PRU1_GPO10"；

    我根据所需的3个以太网接口(2个使用 MII 的 ICSSG1、1个使用 RMII 的 CPSW)尝试了使用 pinmux 配置工具组装 SysConfig、并且与 CPSW 信号似乎没有冲突-请参阅以下 SysConfig。  

    /**
 * These arguments were used when this file was generated. They will be automatically applied on subsequent loads
 * via the GUI or CLI. Run CLI with '--help' for additional information on how to override these arguments.
 * @cliArgs --device "AM64x" --package "ALV" --part "Default"
 * @versions {"tool":"1.17.0+3128"}
 */

/**
 * These are the peripherals and settings in this configuration
 */
const iCPSW1                = scripting.addPeripheral("CPSW");
iCPSW1.$useCase             = "CPSW_6";
iCPSW1.$name                = "MyCPSW1";
const iPRU_ICSSG1_MII_G_RT1 = scripting.addPeripheral("PRU_ICSSG1_MII_G_RT");
iPRU_ICSSG1_MII_G_RT1.$name = "MyPRU_ICSSG1_MII_G_RT1";

/**
 * Pinmux solution for unlocked pins/peripherals. This ensures that minor changes to the automatic solver in a future
 * version of the tool will not impact the pinmux you originally saw.  These lines can be completely deleted in order to
 * re-solve from scratch.
 */
iCPSW1.$suggestSolution                            = "CPSW";
iCPSW1.RMII1_CRS_DV.$suggestSolution               = "PRG0_PRU1_GPO19";
iCPSW1.RMII1_RXD0.$suggestSolution                 = "PRG0_PRU1_GPO7";
iCPSW1.RMII1_RXD1.$suggestSolution                 = "PRG0_PRU1_GPO9";
iCPSW1.RMII1_RX_ER.$suggestSolution                = "PRG0_PRU0_GPO9";
iCPSW1.RMII1_TXD0.$suggestSolution                 = "PRG0_PRU1_GPO10";
iCPSW1.RMII1_TXD1.$suggestSolution                 = "PRG0_PRU1_GPO17";
iCPSW1.RMII1_TX_EN.$suggestSolution                = "PRG0_PRU1_GPO18";
iCPSW1.RMII_REF_CLK.$suggestSolution               = "PRG0_PRU0_GPO10";
iPRU_ICSSG1_MII_G_RT1.$suggestSolution             = "PRU_ICSSG1_MII_G_RT";
iPRU_ICSSG1_MII_G_RT1.MII_MT0_CLK.$suggestSolution = "PRG1_PRU0_GPO16";
iPRU_ICSSG1_MII_G_RT1.MII0_TXEN.$suggestSolution   = "PRG1_PRU0_GPO15";
iPRU_ICSSG1_MII_G_RT1.MII0_TXD3.$suggestSolution   = "PRG1_PRU0_GPO14";
iPRU_ICSSG1_MII_G_RT1.MII0_TXD2.$suggestSolution   = "PRG1_PRU0_GPO13";
iPRU_ICSSG1_MII_G_RT1.MII0_TXD1.$suggestSolution   = "PRG1_PRU0_GPO12";
iPRU_ICSSG1_MII_G_RT1.MII0_TXD0.$suggestSolution   = "PRG1_PRU0_GPO11";
iPRU_ICSSG1_MII_G_RT1.MII0_RXDV.$suggestSolution   = "PRG1_PRU0_GPO4";
iPRU_ICSSG1_MII_G_RT1.MII_MR0_CLK.$suggestSolution = "PRG1_PRU0_GPO6";
iPRU_ICSSG1_MII_G_RT1.MII0_RXD3.$suggestSolution   = "PRG1_PRU0_GPO3";
iPRU_ICSSG1_MII_G_RT1.MII0_RXD2.$suggestSolution   = "PRG1_PRU0_GPO2";
iPRU_ICSSG1_MII_G_RT1.MII0_CRS.$suggestSolution    = "PRG1_PRU0_GPO10";
iPRU_ICSSG1_MII_G_RT1.MII0_RXER.$suggestSolution   = "PRG1_PRU0_GPO5";
iPRU_ICSSG1_MII_G_RT1.MII0_RXD1.$suggestSolution   = "PRG1_PRU0_GPO1";
iPRU_ICSSG1_MII_G_RT1.MII0_RXD0.$suggestSolution   = "PRG1_PRU0_GPO0";
iPRU_ICSSG1_MII_G_RT1.MII0_COL.$suggestSolution    = "PRG1_PRU0_GPO9";
iPRU_ICSSG1_MII_G_RT1.MII0_RXLINK.$suggestSolution = "PRG1_PRU0_GPO8";
iPRU_ICSSG1_MII_G_RT1.MII_MT1_CLK.$suggestSolution = "PRG1_PRU1_GPO16";
iPRU_ICSSG1_MII_G_RT1.MII1_TXEN.$suggestSolution   = "PRG1_PRU1_GPO15";
iPRU_ICSSG1_MII_G_RT1.MII1_TXD3.$suggestSolution   = "PRG1_PRU1_GPO14";
iPRU_ICSSG1_MII_G_RT1.MII1_TXD2.$suggestSolution   = "PRG1_PRU1_GPO13";
iPRU_ICSSG1_MII_G_RT1.MII1_TXD1.$suggestSolution   = "PRG1_PRU1_GPO12";
iPRU_ICSSG1_MII_G_RT1.MII1_TXD0.$suggestSolution   = "PRG1_PRU1_GPO11";
iPRU_ICSSG1_MII_G_RT1.MII1_RXDV.$suggestSolution   = "PRG1_PRU1_GPO4";
iPRU_ICSSG1_MII_G_RT1.MII_MR1_CLK.$suggestSolution = "PRG1_PRU1_GPO6";
iPRU_ICSSG1_MII_G_RT1.MII1_RXD3.$suggestSolution   = "PRG1_PRU1_GPO3";
iPRU_ICSSG1_MII_G_RT1.MII1_RXD2.$suggestSolution   = "PRG1_PRU1_GPO2";
iPRU_ICSSG1_MII_G_RT1.MII1_CRS.$suggestSolution    = "PRG1_PRU1_GPO10";
iPRU_ICSSG1_MII_G_RT1.MII1_RXER.$suggestSolution   = "PRG1_PRU1_GPO5";
iPRU_ICSSG1_MII_G_RT1.MII1_RXD1.$suggestSolution   = "PRG1_PRU1_GPO1";
iPRU_ICSSG1_MII_G_RT1.MII1_RXD0.$suggestSolution   = "PRG1_PRU1_GPO0";
iPRU_ICSSG1_MII_G_RT1.MII1_COL.$suggestSolution    = "PRG1_PRU1_GPO9";
iPRU_ICSSG1_MII_G_RT1.MII1_RXLINK.$suggestSolution = "PRG1_PRU1_GPO8";

    就像您共享的发生冲突的 CPSW 信号一样、也可以通过以下引脚进行配置。

    焊球名称 CPSW 信号名称
    PRG0_PRU0_GPO10
    		RMII_REF_CLK
    PRG0_PRU0_GPO9
    		RMII1_RX_ER
    PRG0_PRU1_GPO9
    		RMII1_RXD1
    PRG0_PRU1_GPO10
    		RMII1_TXD0

    对于 MDIO 引脚冲突：

    使用上述引脚多路复用选择(在我随附的 SysConfig 中)、我可能会看到为 ICSSG1接口和 CPSW RMII 接口添加 MDIO 时发生冲突。  

    ICSSG1 MDIO 仅具有使用"PRG1_MDIO0_MDC"和"PRG1_MDIO0_MDIO"的选项

    CPSW MDIO 有两个选项  

    MDC："PRG1_MDIO0_MDC"或" PRG0_PRU1_GPO19 "

    MDIO："PRG1_MDIO0_MDIO"或" PRG0_PRU1_GPO18 "

    但是、" PRG0_PRU1_GPO19 "已被 CPSW 的"RMII1_CRS_DV"信号使用、" PRG0_PRU1_GPO18"  已由 CPSW 的"RMII1_TX_EN"信号使用。

    "RMII1_CRS_DV"无法更改为"PRG1_PRU1_GPO19"、"RMII1_TX_EN"无法更改为"PRG1_PRU1_GPO18"、因为这些信号是 IOSET1的一部分、所有其他 CPSW 信号都是 IOSET2的一部分。

    根据数据表7.10.5.1 CPSW3G、

    "CPSW3G MDIO0、CPSW3G RMII1、CPSW3G RMII2和 CPSW3G RGMII1具有一个或多个
    信号、可以多路复用到多个引脚。 时序要求和切换
    本节中定义的特性仅对称为 IOSET 的特定引脚组合有效 .
    可在 CPSW3G 的表中找到这些接口的有效引脚组合或 IOSET
    IOSET 部分中添加了低功耗说明。"

    我认为、这意味着数据表中报告的规格仅对给定的 IOSET 配置有效。 如果您选择为给定的接口混合 IOSET、我们无法保证您期望从数据表中获得的时序要求和开关特性。

    因此、我认为选择2会更安全。  

    让我也和同事看看这一点、因为在 MII 模式下将 CPSW 与 ICSSG 一起使用应该是一个常见的用例(尤其是对于使用 EtherCAT 的应用)、所以坦率地说、存在这样的引脚配置冲突让我感到很惊讶。

    -道林

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

    Daolin、感谢您理解 ICSSG1和 CPSW 的限制条件。 我期待任何可能的解决办法。

    仅需注意、在 EtherCAT 示例中、SysConfig 工具不显示或允许 CRS 和 COL 与关联PRU_ICSSG1_MII_G_RT。 相反、它们显示在下PRU_ICSSG1_IEP。 最后、信号PRG1_PRU0_GPO9、PRG1_PRU0_GPO10、PRG1_PRU1_GPO9和PRG1_PRU1_GPO10连接到 DP83822 PHY 的 CRS 和 COL 引脚。

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

    您好、Nikhil：

    Unknown 说：
    仅需注意、在 EtherCAT 示例中、SysConfig 工具不显示或允许 CRS 和 COL 与关联PRU_ICSSG1_MII_G_RT。 相反、它们显示在下PRU_ICSSG1_IEP。 最后、信号PRG1_PRU0_GPO9、PRG1_PRU0_GPO10、PRG1_PRU1_GPO9和PRG1_PRU1_GPO10连接到 DP83822 PHY 的 CRS 和 COL 引脚。[/QUOT]

    感谢您的澄清

    [报价 userid="576780" url="~/support/processors-group/processors/f/processors-forum/1456855/am6421-am6421-can-pru_icssg0-rgmii2-rgmii1-be-enabled-in-linux-with-a-single-instance/5596274 #5596274"]请允许我和同事同时检查一下这一点、因为在 MII 模式下将 CPSW 与 ICSSG 一起使用应该是一个常见的用例(尤其是对于使用 EtherCAT 的应用)、所以坦率地说、我对存在这样一种引脚配置冲突感到惊讶。

    与同事讨论后、我当前的理解是、我们支持采用大多数 CPSW 配置的 RGMII 模式 ICSSG、但当选择 ICSSG MII 模式时、这可能会导致引脚多路复用冲突、如我们所观察到的。  

    我仍然想说、你应该继续采用备选案文2。

    -道林

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

    最新动态：

    您是否计划 以半双工模式运行工业端口(ICSSG1 MII)、或者它是否始终使用全双工模式？  

    我最近回顾、在我们的 AM64x EVM 上、我们能够通过多路复用在 MII 和 RGMII 之间更改 ICSSG1接口模式。 具体来说、这是在我们的 Linux SDK 中通过器件树叠加层实现的。 如需覆盖文件、请参阅此链接： https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/arch/arm64/boot/dts/ti/k3-am642-evm-icssg1-dualemac-mii.dtso?h=ti-rt-linux-6.6.y 

    在 AM64x EVM 上、同时还会启用 CPSW RGMII。 当然、当使用 SysConfig 工具检查该组合(ICSSG1 MII + CPSW RGMII)时、唯一的冲突是 ICSSG1 MII 接口上的 CRS 和 COL 引脚。

    通过查看器件树叠加引脚多路复用配置、我发现如果配置了 ICSSG1 MII、则会导致与 CPSW RGMII 引脚发生冲突的 CRS 和 COL 引脚实际上根本没有配置。 经过研究、CRS 和 COL 引脚似乎只在半双工模式下才是真正需要的、这可能是为什么没有在器件树叠加引脚多路复用配置中配置 CRS 和 COL 的原因。

    这表明可以使用以下组合来配置您的设置  如果可以保证 ICSSG1 MII 接口不使用半双工模式、  这需要更改以太网 PHY 驱动程序、使其不会向链路伙伴广播半双工模式(可选)。

    • 工业端口(MII)：PRU_ICSSG1 (省略 CRS 和 COL 引脚)
    • OPCUA 端口(. RGMII )：CPSW  

    请记住此配置、您可以使用 RGMII CPSW 而不是之前研究过的 RMII CPSW。 根据我的理解、OPCUA 端口是否有必须处于 RMII 模式的特殊要求？

    -道林

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

    感谢您的详细说明和对器件树叠加层的引用。 我将与团队一起推进这一工作。

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

    您好、Nikhil：

    Unknown 说：
    您是计划 以半双工模式运行工业端口(ICSSG1 MII)还是始终使用全双工模式？  
    Unknown 说：
    这向我表明、可以使用以下组合配置您的设置  如果可以保证 ICSSG1 MII 接口不使用半双工模式、  这需要更改以太网 PHY 驱动程序、以便它不会向链路伙伴广播半双工模式(作为一个选项)。

    与您的团队讨论时、请牢记这些。 如果您对这个 pinmux 配置问题有任何其他疑问、请随时通过本线程再次联系。

    -道林