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

[参考译文] AM6442：AM64 PRU-ICSSG 以太网问题

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1599879/am6442-am64-pru-icssg-ethernet-issue

器件型号： AM6442

你（们）好

客户使用自己的电路板并报告 2 个问题、SDK 是 Linux SDK 9.0。  

问题 1：

客户在 AM64 电路板的 PRU-ICSSG1 网络接口上设置自动 eth2 链路建立/链路断开测试、并遇到命令超时问题。 在应用层、链路建立和链路断开操作正常、但无法 ping 通网络接口。

1765876258523v1.png

内核缓冲区记录了 PRU 异常日志、请参见随附的 2678.log.txt 。 重新启动后此问题已解决。

问题 2：

尽管链路建立和链路断开操作是正常的、但 PRU 网络接口始终无法 ping 通。 内核缓冲区日志显示在附加的 2678.log2.txt 中 。

我们将下图中所示的补丁程序添加到主板上、并执行多次重新引导、但问题仍然存在。

919191.png

是否有解决此问题的想法、或者是否有任何已知的补丁可以尝试基于最新 SDK 进行测试？

谢谢。此致

Zekun

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

    SDK 9.2：  

    已关闭问题：

    LCPD-37223

    AM64x：ICSSG1 MII 模式无法正常工作

    am64xx-EVM、am64xx-hsevm

    LCPD-37831.

    ICSSG、因为开关断开

    am64xx-EVM、am64xx-hsevm

    SDK 9.2.1

    已关闭问题：

    LCPD-36358.

    am64xx-EVM

    am64x：eth2 链路无法启动以进行 TEST_Nway 测试

    SDK 10.0

    已知问题：

    LCPD-38326

    ICSSG 以太网：将 FDB 配置时段大小更新为 512

    am64xx-EVM

    LCPD-36864

    ICSSG1 在 Debian 中无法工作、但在 Yocto 中工作

    am64xx-EVM

    已关闭问题：

    LCPD-38253.

    AM64：ICSSG 测试失败

    am64xx-hsevm

    PINDSW-7980

    ICSSG FW：FDB：学习和刷新问题

    am64xx-EVM、am654x-EVM

    PINDSW-7981

    ICSSG FW：FDB：初始化期间不会清除所有插槽

    am64xx-EVM、am654x-EVM

    PINDSW-7982

    ICSSG FW：IEP 配置期间的竞态条件

    am64xx-EVM、am654x-EVM

    PINDSW-7990

    ICSSG FW：HalfDuplex：需要在固件中处理 CRS、COL 连接组合

    am64xx-EVM

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

    问题 1：

    MII 模式

    自动协商使能

    将重现 100 次。  

    重启可以修复、Mac 孤立的重新测试无法修复。  

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

     嗨、Nick

    我与客户进行了会谈、这个项目很紧迫、将于 2025 年底大规模生产。 在进行最终验证时会发现此问题。

    我建议基于 SDK 10.x 进行客户测试、因为您可以看到、SDK 10.X 和 SDK 9.X 构建了许多 ICSSG1 问题、尤其是对于 MII 模式和链路问题。

    但是、客户提到他们在下面的主题中与您进行了讨论。 根据 SDK10.0、这些问题仍然可能会重现。

    HTTPS：// e2e.ti.com/support/processors-group/processors/f/processors-forum/1343987/am6422-10mbps-link-down-cause-icssg-ethernet-driver-crash/5176057

     

     AM6442：在 PRU0 以太网端口上以 10Mbps 速度持续链路建立/断开期间内核崩溃 

    那么、您对客户测试的 SDK 版本有何建议？ SDK11.3？

    需要考虑的几点：

    SDK 稳健性

    2. SDK 反向端口问题。 如果最新的 SDK 可以解决此问题、那么我们可以通过反向补丁来启用它们。

    谢谢

    Zekun

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

    此处的任何更新？

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

    嗨、Nick

    我已建议客户测试 SDK11.3。  但是、客户很难在这么短的时间内更新整个 SDK。

    所以,如果它可以通过压力测试,你的建议是从最新到 9.X？回传部件

    谢谢

    Zekun

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

    大家好

    我们在电路板上的 TI SDK 版本 11.02.08.02 上进行了测试。 问题仍然存在。

    有关详细信息、请参阅以下测试用例和结果。

    此问题也存在于 SDK 版本 09.00.00.06 中。

    此外、测试用例 10 代表最基本的使用场景、应优先考虑解决方案。

    案例 10 日志：e2e.ti.com/.../occurs-negotiated-to-10M10M_0CFF_report-timeout.txt

    请参阅 PRU eth PC 网络适配器 测试步骤 结果 注释
    1. 自动协商功能 自动协商功能 在 PC 上运行脚本、反复模拟插入和拔出 3 秒 好的 测试大约 90 小时
    2. 自动协商功能 100M FD 在 PC 上运行脚本、反复模拟插入和拔出 3 秒 好的 测试大约 20 小时
    3. 自动协商功能 100M HD 在 PC 上运行脚本、反复模拟插入和拔出 3 秒 不正常 PRU eth 无法启动
    4. 自动协商功能 10M FD 在 PC 上运行脚本、反复模拟插入和拔出 3 秒 不正常 PRU eth 无法启动或报告超时
    5. 自动协商功能 10M HD 在 PC 上运行脚本、反复模拟插入和拔出 3 秒 不正常 PRU eth 无法启动或报告超时
    6. 100M FD 自动协商功能 在 PC 上运行脚本、反复模拟插入和拔出 3 秒 好的 测试大约 20 小时
    7. 100M HD 自动协商功能 在 PC 上运行脚本、反复模拟插入和拔出 3 秒 不正常 PRU eth 报告超时
    8. 10M FD 自动协商功能 在 PC 上运行脚本、反复模拟插入和拔出 3 秒 好的 测试大约 20 小时
    9. 10M HD 自动协商功能 在 PC 上运行脚本、反复模拟插入和拔出 3 秒 不正常 PRU eth 报告超时
    10. 自动协商功能 自动协商功能 反复手动插上插头和拔下插头 不正常 协商为 10M、PRU eth 报告超时、然后启动脚本 插入并拔出、重新协商为 100Mbps。
  • 0
    TI__Guru**** 2826755 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、

    测试用例 1 重新运行约 23 小时、 两个器件报告超时问题、两个器件工作正常。

    我们发现、  在报告的超时。μ s 之前、故障器件肯定协商为 10Mbps

    我发现另一个问题：PRU ETH 不广播 默认半双工功能。 但是、使用 mii-tool（-R、--reset 以使 MII 恢复到其上电状态）复位 MII 后、PRU ETH 开始广播半双工功能。

    设备 A 日志：

    [425637.668120] icssg-prueth icssg1-eth eth2：链路接通 — 10Mbps/full — 流量控制关闭
    [425638.691320] icssg-prueth icssg1-eth eth2：链路断开
    [425643.816483] icssg-prueth icssg1-eth eth2：链路接通 — 100Mbps/full — 流量控制关闭
    [425645.859338] icssg-prueth icssg1-eth eth2：链路断开
    [425649.961070] icssg-prueth icssg1-eth eth2：链路接通 — 100Mbps/full — 流量控制关闭
    [425652.008430] icssg-prueth icssg1-eth eth2：链路断开
    [425656.100567] icssg-prueth icssg1-eth eth2：链路接通 — 100Mbps/full — 流量控制关闭
    [425658.147265] icssg-prueth icssg1-eth eth2：链路断开
    [425662.249236] icssg-prueth icssg1-eth eth2：链路接通 — 100Mbps/full — 流量控制关闭
    [425663.267261] icssg-prueth icssg1-eth eth2：链路断开
    [425668.389068] icssg-prueth icssg1-eth eth2：链路接通 — 100Mbps/full — 流量控制关闭
    [425669.411275] icssg-prueth icssg1-eth eth2：链路断开
    [425674.532108] icssg-prueth icssg1-eth eth2：链路接通 — 100Mbps/full — 流量控制关闭
    [425675.560065] icssg-prueth icssg1-eth eth2：链路断开
    [425675.567873] icssg-prueth icssg1-eth eth2：等待命令完成超时
    [425675.590979] icssg-prueth icssg1-eth eth2：等待命令完成超时
    [425675.608912] icssg-prueth icssg1-eth eth2：等待命令完成超时
    [425679.716207] icssg-prueth icssg1-eth eth2：链路接通 — 100Mbps/full — 流量控制关闭
    [425679.737874] icssg-prueth icssg1-eth eth2：等待命令完成超时

    器件 B 日志：

    [334760.930683] icssg-prueth icssg1-eth eth2：链路断开
    [334764.003543] icssg-prueth icssg1-eth eth2：链路接通 — 100Mbps/full — 流量控制关闭

    [334767.074671] icssg-prueth icssg1-eth eth2：链路断开
    [334769.123557] icssg-prueth icssg1-eth eth2：链路接通 — 10Mbps/half — 流量控制关闭
    [334770.146660] icssg-prueth icssg1-eth eth2：链路断开
    [334782.435519] icssg-prueth icssg1-eth eth2：链路接通 — 100Mbps/full — 流量控制关闭
    [334784.482670] icssg-prueth icssg1-eth eth2：链路断开
    [334788.583175] icssg-prueth icssg1-eth eth2：链路接通 — 100Mbps/full — 流量控制关闭
    [334790.626598] icssg-prueth icssg1-eth eth2：链路断开
    [334794.723597] icssg-prueth icssg1-eth eth2：链路接通 — 100Mbps/full — 流量控制关闭
    [334796.775462] icssg-prueth icssg1-eth eth2：链路断开
    [334801.895172] icssg-prueth icssg1-eth eth2：链路接通 — 100Mbps/full — 流量控制关闭
    [334802.914670] icssg-prueth icssg1-eth eth2：链路已关闭
    [334807.011475] icssg-prueth icssg1-eth eth2：链路接通 — 100Mbps/full — 流量控制关闭
    [334809.05858587] icssg-prueth icssg1-eth eth2：链路断开
    [334814.185146] icssg-prueth icssg1-eth eth2：链路接通 — 100Mbps/full — 流量控制关闭
    [334815.202573] icssg-prueth icssg1-eth eth2：链路断开
    [334815.220189] icssg-prueth icssg1-eth eth2：等待命令完成超时
    [334815.238321] icssg-prueth icssg1-eth eth2：等待命令完成超时
    [334815.256372] icssg-prueth icssg1-eth eth2：等待命令完成超时

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

    你好、Wei

    感谢您对测试用例和日志进行了细化。 我已在内部将此问题上报至紧急优先级。

    嗨、Nick

    我已将此问题上传到 Sitara 关键问题列表并上报。  

    如客户报告、 SDK 9.0 和 SDK 11.2 都存在超时问题。  

    似乎更频繁地出现在下 10Mbps c. 令人不快 。  

    有什么想法吗？

    谢谢

    Zekun

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

    您好、

    I test PRU eth with speed 100M full set by eththool、no timeout issues、no 10M 协商协议报告了 更多 100 小时的插拔

     SDK 9.0 和 SDK 11.2 均正常。

    $ sudo ethtool eth2
    eth2 的设置：
    支持的端口：[ TP mii ]
    支持的链路模式：10BaseT/Full
    100BaseT/Full
    支持的暂停帧使用：否
    支持自动协商：可以
    支持的 FEC 模式：未报告
    广播的链路模式：100BaseT/Full
    广播的暂停帧使用：否
    广播的自动协商：是
    广播 FEC 模式：未报告
    链路伙伴广播的链路模式：10BaseT/Half 10baseT/Full
    100BaseT/Half 100BaseT/Full
    链路伙伴广播的暂停帧使用：对称仅接收
    链路伙伴广播的自动协商：是
    链路伙伴广播的 FEC 模式：未报告
    速度：100MB/s
    双工：全双工
    自动协商：打开
    端口：双绞线
    PHYAD：3.
    收发器：外部
    MDI-X：未知
    当前消息级别：0x00000000 (0)

    检测到链路：是

  • 0
    TI__Guru**** 2826755 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    [引述 userid=“679723" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1599879/am6442-am64-pru-icssg-ethernet-issue/6175330

    I test PRU eth with speed 100M full set by eththool、no timeout issues、no 10M 协商协议报告了 更多 100 小时的插拔

     SDK 9.0 和 SDK 11.2 均正常。

    [/报价]

    意味着问题已解决？ 变化是什么？

    此致

    Ashwani

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

    尚未解决。  我只做更多测试用例。

    PRU eth 仅在  100M 双工全广播模式下工作正常。

    默认情况下、自动协商和 10M 速度都存在此问题。

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

    还有一个问题、使用“sudo ethtool -s eth2 autoneg off speed 100 duplex full“、PC adapter set to autoneged  。

    PRU eth 无法启动。

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

    你（们）好 Ashwani

    TI 是否会在 10Mbps 场景下测试压力测试？ 任何测试报告都可以与客户共享？

    我与客户进行了检查、此测试用例在工业环境中是正常的。

    谢谢

    Zekun  

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

    你好、Wei

    您的项目是否使用了 CLEAR SDK 并且在关于以太网/网络之前不应用任何补丁？

    您能尝试在 AM64 EVM 上重现问题吗？ 我认为 TI 能 解决 这一问题（无论它是否与硬件差异和软件错误有关）、将会非常有帮助。   

    谢谢

    Zekun

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

     SDK 11.2 很明确

  • 0
    TI__Guru**** 2826755 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    [引述 userid=“679723" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1599879/am6442-am64-pru-icssg-ethernet-issue/6177406

    还有一个问题、使用“sudo ethtool -s eth2 autoneg off speed 100 duplex full“、PC adapter set to autoneged  。

    PRU eth 无法启动。

    [/报价]

    您可以就此问题单独创建主题吗？

    TI 是否会在 10Mbps 场景下测试压力测试？ 任何测试报告都可以与客户共享？

    Nick Saulnier 对此发表评论。

    此致

    Ashwani

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

    大家好！

    对此处延迟的回复表示歉意。 我已经阻止了几个小时的明天运行测试,并确保我可以复制你的观察. 我们开发团队的一名成员在 2025 年底花了一些时间进行了测试、但没有观察到相关行为、因此我还需要研究他们做了什么、了解它与您所做的工作有何不同。

    澄清问题

    1) 在 12 月 28 日的帖子中,您提供了测试结果。 这些测试结果是基于 SDK 11.2 还是 SDK 9.0？

    2) 在 12 月 29 日的帖子中,您提到了端口广告方式的差异。 在哪些 SDK 版本上观察到该问题？

    3) 发现链路接通/断开超时问题通常需要多长时间? 我是否应该在 10 次测试中看到结果？ 在 10 小时内？ 我是否需要让测试运行几天、然后再发布一个问题？

    4) 同意 Zekun 的意见、确保您也可以看到 TI EVM 上的行为会有所帮助。 该 EVM 是软件开发人员使用的电路板。 如果 EVM 上的问题无法重现、 我们将更难帮助您解决问题。

    此致、

    Nick

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

    您好 Nick、

    1) 测试结果是使用 SDK 11.2 得出的。  但我们在 SDK 9.0 上也发现了相同的问题。

    2)   默认情况下、两个 SDK 都不广播半双工功能。

    3) 如果 PRU eth 设置的速度为 10M、则插件将发生超时问题 、并将其插件几次、某时间插入不到 10 次。 如果 PRU eth 默认情况下自动协商、时间不确定、通常超过 10 小时 插件并 重复插件。

    4) EVM 现在不可用、我会尽快尝试。

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

    另外、您使用什么命令来使用-R 复位 MII、然后观察随后广播的半双工模式？

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

    我们使用  与 PHY 的 RGMII 连接。

    器件树中未添加“ti、半双工型“。

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

    mii-tool 命令、使用“R"复“复位后、mii-tool 显示支持半功能、但 ethtool 仍然无法显示半功能  

    $ sudo mii-tool -v eth2
    eth2：无链路
    产品信息：供应商 10：00：14 或 08：00：28、型号 36 修订版 0
    基本模式：自动协商已启用
    基本状态：无链接
    功能：100BaseTX-FD 100BaseTX-HD 10baseT-FD 10baseT-HD
    广播：100BaseTX-FD 10baseT-FD
    AUGOS/ARM64：8 月@8 月在~
    $
    AUGOS/ARM64：8 月@8 月在~
    $ sudo mii-tool -R eth2
    正在重置收发器...
    AUGOS/ARM64：8 月@8 月在~
    $
    AUGOS/ARM64：8 月@8 月在~
    $ sudo mii-tool -v eth2
    eth2：无链路
    产品信息：供应商 10：00：14 或 08：00：28、型号 36 修订版 0
    基本模式：自动协商已启用
    基本状态：无链接
    功能：100BaseTX-FD 100BaseTX-HD 10baseT-FD 10baseT-HD
    广播：100BaseTX-FD 100BaseTX-HD 10baseT-FD 10baseT-HD
    AUGOS/ARM64：8 月@8 月在~

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

    您好 Zekun、

    有新的问题、使用“sudo ethtool -s eth2 autoneg off speed 100 duplex full“、PC 适配器设置为  autoneged 。  PRU eth 无法启动。

    请帮助创建新问题。 谢谢

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

    嗨、Nick

    因此、您可以基于 SDK11.X 在 EVM 上重现 10M 超时问题、对吗？

    你好、Wei

    我建议您可以另行处理另一个 E2E 主题以讨论 100M 问题。 您只需单击 上角的“提出相关问题“  、即可重新构建另一个问题。 我会跟进一下。

    谢谢

    Zekun

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

    您好、Nick：

    有关 10M 超时问题的任何更新？

    尊敬的 Zekun：

    报告相关问题需要填写一些信息、如 器件型号。  

    我选择 了 AM6442BSDFHAALV 并创建了 CPR261138305。 但相关的问题似乎 还没有。

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

    您好、Wei、

    我已经留出了更多的时间来运行测试明天.

    问题 1

     使用 Linux SDK 11.2 向 Linux 器件树添加“ti、半双工支持“后、您的半双工问题是否会消失？ （我们正在讨论此主题上的许多不同事项，因此我想澄清什么是未决问题，以及解决了什么问题）

    问题 2.  

    我能否让您分享 用于“在 PC 上运行脚本、模拟 3 秒反复循环的插头和拔出“的脚本？

    在 10M 上似乎与之前链接的问题不同

    开发团队对最新的 Linux 内核进行了更多测试、以确保他们没有看到此测试脚本在 10M 时内核崩溃： 

    #!/bin/bash

counter=0

while true
do
    counter=$((counter + 1))

    ifconfig eth1 down
    echo "[$counter] eth1 is down"

    sleep 10

    ifconfig eth1 up
    echo "[$counter] eth1 is up"

    sleep 10

    if (( counter % 10 == 0 )); then
        echo "[$counter] Pinging google.com"
        ping -c 10 google.com
    fi
done

    此致、

    Nick

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

    您好、Nick、

    我们的要求是解决 SDK 9.0 上的所有问题。  

    问题 1：

    请检查 SDK 9.0 中是否支持“ti、半双工 Capable“。

    问题 2：

     PRU eth 和 PC 之间有以太网适配器交换机控制器。   产品模式为  ZP_RJ45ST01。

    脚本控制适配器开关的 物理 上电和断电、 例如手动插入和拔出。

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

    您好、Nick、

    我 在 SDK 9.0 中启用 Half Capable、似乎有效、但链接无法打开

    $ sudo ethtool eth2
    eth2 的设置：
    支持的端口：[ TP mii ]
    支持的链路模式：10BaseT/Half 10baseT/Full
    100BaseT/Half 100BaseT/Full
    支持的暂停帧使用：否
    支持自动协商：可以
    支持的 FEC 模式：未报告
    广播的链路模式：10BaseT/Half 10baseT/Full
    100BaseT/Half 100BaseT/Full
    广播的暂停帧使用：否
    广播的自动协商：是
    广播 FEC 模式：未报告
    速度：10MB/s
    双工：半双工
    自动协商：打开
    端口：双绞线
    PHYAD：2.
    收发器：外部
    MDI-X：未知
    当前消息级别：0x00000000 (0)

    检测到链路：否

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

    嗨、Nick

    今天下午、我们与客户亲自会面、讨论以太网问题。

    该问题阻止了客户的大规模生产。 通过讨论、您已经可以在我们的 EVM 上重现相同的问题。  

    那么、您能否提供解决此问题的时间表？  

    谢谢

    Zekun

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

    大家好：

    现在、我们可以处理的是复制最新 SDK 11.2/Linux 内核 6.12 上的行为、并解决 SDK 11.2 上的高优先级行为。

    我将整理一个行为列表、并在 SDK 11.2 中标记它们是否看起来是个问题。 我们将使用此列表与开发团队交谈、并指导他们首先了解的内容。 我可能需要您对哪些行为对您最重要、才能在 SDK 11.2 上修复问题进行排序。

    良好 看到的
    SDK 9.0？     		看到的
    SDK 11.2？

    注释

    从链路伙伴发起的重复链路建立和断开会导致超时消息。 超时消息开始后、链路不再工作、没有重新启动（通过 PC 脚本测试，该脚本可打开和关闭以太网适配器开关，以模拟插拔，或者在某些情况下使用手插拔和拔下电缆）- Nick 在 AM64x 上复制了 10M FD、在 PC 上进行自动协商、手插拔和拔出 y y Nick 在该响应中的观察结果
    PRU 以太网不广播半双工、无法协商到 10M HD 或 100M HD y ？？ TODO：需要在 SDK 11.2 上使用 Linux 器件树中的“ti、半双工支持“进行测试。 我预计该演示在 SDK 11.2 上有效
    不清楚：链路接通是否存在单独的问题？ （AM64x 自动协商、PC 10M FD，链路不出现？） ？？ ？？
    不清楚：链路接通是否存在单独的问题？ （AM64x 100M FD、PC 自动协商，链路没有出现？） ？？ ？？ 这 在先前的答复中被标记为有效、然后在 后面的答复中被列为问题

    请注意、除了此列表外、还有许多不同的错误是 SDK 9.0 中的潜在问题、这些错误已在 SDK 11.2 中解决。 需要单独讨论哪些已知错误的 bug 修复可以反向移植到 SDK 9.0、哪些 bug 修复无法反向移植。

    良好 注释
    从 AM64x 电路板启动的 10Mbps 链路建立和断开会导致内核崩溃    AM6442： 在 PRU0 以太网端口上的连续链路建立/断开期间内核崩溃、速度为 10Mbps、开发人员在最新 SDK 上使用此测试脚本进行测试、无法看到任何内核崩溃  

    此致、

    Nick

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

    注释

    从链路伙伴发起的重复链路建立和断开会导致超时消息。 超时消息开始后、链路不再工作、没有重新启动（通过 PC 脚本测试，该脚本可打开和关闭以太网适配器开关，以模拟插拔，或者在某些情况下使用手插拔和拔下电缆）- Nick 在 AM64x 上复制了 10M FD、在 PC 上进行自动协商、手插拔和拔出

    AM64x 电路板侧：启用自动协商时观察到问题、同时将链路设置为 10M。  

    		 y y  Nick 在该响应中的观察结果  

    PRU 以太网不广播半双工、无法协商到 10M HD 或 100M HD

    >>需要在 SDK11.2 上进行测试

    		y ？？ TODO：需要在 SDK 11.2 上使用 Linux 器件树中的“ti、半双工支持“进行测试。 我预计该演示在 SDK 11.2 上有效

    不清楚：链路接通是否存在单独的问题？ （AM64x 自动协商、PC 10M FD，链路不出现？）

    >>忽略此问题、因为此问题与特殊卡有关、仅发生一次。

    		？？ ？？

    不清楚：链路接通是否存在单独的问题？ （AM64x 100M FD、PC 自动协商，链路没有出现？）

    >>在 AM64x 电路板端：禁用 Autoneg 时观察到问题、同时将链路设置为 100M。 先前标记为有效的响应未禁用 Autoneg。

    		？？ ？？

    这 在先前的答复中被标记为有效、然后在 后面的答复中被列为问题
    良好 注释

    从 AM64x 电路板启动的 10Mbps 链路建立和断开会导致内核崩溃                                                                                     

    >>低优先级。

    		 AM6442： 在 PRU0 以太网端口上的连续链路建立/断开期间内核崩溃、速度为 10Mbps、开发人员在最新 SDK 上使用此测试脚本进行测试、无法看到任何内核崩溃  
  • 0
    TI__Guru**** 2826755 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好 Zekun、

    我验证了 100M 链路问题、并向开发团队提供了摘要和测试日志以供我们查看。 今天没有用于测试半双工的带宽、将需要在本周晚些时候进行测试。

    良好 看到的
    SDK 9.0？     		看到的
    SDK 11.2？

    注释

    当 10M 链路反复拔出时、传输队列超时

    		y y LCPD-46420

    PRU 以太网不广播半双工、无法协商到 10M HD 或 100M HD

    >>需要在 SDK11.2 上进行测试

    		y ？？ TODO：需要在 SDK 11.2 上使用 Linux 器件树中的“ti、半双工支持“进行测试。 我预计该演示在 SDK 11.2 上有效

    如果禁用自动协商、100M 链路无法启动

    		？？ y LCPD-46419

    此致、

    Nick

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

    大家好：

    开发团队能够复制 10M“传输队列超时“问题、并且正在积极调试。 到目前为止、他们还无法重现 100M 链路无法建立的情况。

    仔细检查您这边的一些信息：

    1)  10M“传输队列超时“问题:启用自动协商时,我发现了这个问题。 您是否曾在禁用自动协商时发现此问题？

    2) 100M 链路无法启动并禁用自动协商:您能尽可能完整地描述您的测试设置吗? （描述用于从电路板连接到链路伙伴的以太网硬件，链路伙伴是链路伙伴，在终端中键入的任何脚本或命令等）

    此致、

    Nick

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

    嗨、Nick

    客户将在今天举行年度会议、明天将更新。

    谢谢

    Zekun

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

    您好、Nick、

    1) 同样的问题在 自动协商 下关闭速度 10.

    使用以下命令设置 PRU eth2：
    # ethtool -s eth2 自动协商关闭速度 10 双工全速

    只能插入/拔出两次、链路接通但无法 ping 通、然后报告超时和紧急情况

    请参阅详细信息日志：

    # ping 192.168.2.66
    Ping 192.168.2.66 (192.168.2.66) 56 (84) 字节的数据。
    从 192.168.2.10 ICMP_Seq=1 无法访问目标主机
    从 192.168.2.10 ICMP_Seq=2 无法访问目标主机
    从 192.168.2.10 ICMP_Seq=3 无法访问目标主机
    从 192.168.2.10 ICMP_Seq=4 无法访问目标主机
    从 192.168.2.10 ICMP_Seq=5 无法访问目标主机
    从 192.168.2.10 ICMP_Seq=6 无法访问目标主机
    从 192.168.2.10 ICMP_Seq=7 无法访问目标主机
    从 192.168.2.10 ICMP_Seq=8 无法访问目标主机
    从 192.168.2.10 ICMP_Seq=9 无法访问目标主机
    从 192.168.2.10 ICMP_Seq=10 无法访问目标主机
    从 192.168.2.10 ICMP_Seq=11 无法访问目标主机
    从 192.168.2.10 ICMP_Seq=15 无法访问目标主机
    从 192.168.2.10 ICMP_Seq=18 无法访问目标主机
    [276.961653]---- 【在这里剪切】------
    [276.966337] NETDEV 看门狗: eth2 (icssg-prueth): Transmit queue 0 timed out
    [ 276.973455]警告：CPU：0 PID：0 at net/sched/sch_generic.c：525 DEV_WATCHDOG+0x214/0x220
    [276.981736]模块链接到：
    [ 276.984790] CPU：0 PID：0 通信：swapper/0 未污染 6.1.33-g40c32565ca #1
    [ 276.991740]硬件名称：Texas Instruments AM642 EVM (DT)
    [276.997298] pstate：600005 (nZCv daif -pan -uao -TCO -DIT -SSB BTYPE=--)
    [277.004248] PC：dev_watchdog+0x214/0x220
    [277.008249] lr : dev_watchdog+0x214/0x220
    [277.012248] sp : ffff8003e20
    [ 277.015552] x29：ffff8003e20 x28：0000000000000005 x27：ffffff8008b18280
    [277.022681] x26：ffff80093f79c0 x25：ffffff00003fdba1a8 x24：ffffff8003ef0
    [ 277.029810] x23：ffff8000093f7000 x22：000000000000 x21：ffff00000588039c
    [ 277.036941] x20：ffff000005880000 x19：ffffff000005880448 x18：ffffffffffffffffff
    [277.044069] x17：ffff800036b5c000 x16：ffff800000080000 x15：ffff800088003b07
    [ 277.051197] x14：000000000000 X13：ffff800009413ff0 x12：0000000005a9
    [277.058324] x11：00000000000001e3 x10：ffff80000946bff0 x9：ffff800009413ff0
    [277.065451] x8 : 00000000fffffff x7 : ffffff800946bff0 x6 : 0000000000000000
    [277.072578] x5：ffff00003fdb9b60 x4：000000000040 x3：0000000000000001
    [277.079705] x2：000000000000 x1：000000000000 x0：ffffff80000009405440

    2) 使用以下命令禁用  100m 的自动协商,等待 10 分钟以上,链接无法接通。

    # ethtool -s eth2 自动协商关闭速度 100 双工全速
    #
    AUGOS/ARM64：root@Aug in ~
    #
    AUGOS/ARM64：root@Aug in ~
    # ethtool eth2
    eth2 的设置：
    支持的端口：[ TP mii ]
    支持的链路模式：10BaseT/Full
    100BaseT/Full
    支持的暂停帧使用：否
    支持自动协商：可以
    支持的 FEC 模式：未报告
    广播的链路模式：10BaseT/Full
    100BaseT/Full
    广播的暂停帧使用：否
    广播的自动协商：否
    广播 FEC 模式：未报告
    速度：100MB/s
    双工：全双工
    自动协商：关闭
    端口：双绞线
    PHYAD：3.
    收发器：外部
    MDI-X：未知
    当前消息级别：0x00000000 (0)

    检测到链路：否
    AUGOS/ARM64：root@Aug in ~

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

    你好杜伟、

    您是否有关于测试硬件设置的更多信息？

    目前、该团队正在隔离最新 SDK 版本 11.2 并修复问题。 这与 SDK 9.0 的行为不同、因为我们在这两个版本之间的 2 年里进行了所有开发。 例如、当我今天重新测试时、没有自动协商的 10M 全双工模式已为我的所有测试用例建立了链路。

    下面是我向开发人员提供的测试信息、旨在帮助他们复制我对“100M 全双工无自动协商“问题的观察结果以及我的测试日志：

    SDK 11.2、与作为链路伙伴的外部交换机连接（没有插入外部交换机）(NETGEAR GS308v2)

     

    自动协商已启用

    自动协商已禁用

    10M HD

     

     

    10M FD

    y

    y

    100M HD

     

     

    100M FD

    y

    N

    1G HD

     

     

    1G FD

    y

    链路接通@100M

     

    SDK 11.2、与 Linux PC 作为链路伙伴连接（PC 和 EVM 之间没有切换）(Ubuntu 22.04)

     

    自动协商已启用

    自动协商已禁用

    10M HD

     

     

    10M FD

    y

    Y（但花了很长时间）

    100M HD

     

     

    100M FD

    y

    N

    1G HD

     

     

    1G FD

    y

    链路接通@100M

     

    SDK 11.2、与作为链路伙伴的 Windows PC 连接（PC 和 EVM 之间没有切换）（Windows 11 64 位）

     

    自动协商已启用

    自动协商已禁用

    10M HD

     

     

    10M FD

    Y“等待命令完成超时“、DID 链路接通->断开->接通

    Y、DID 链路接通->断开->接通

    100M HD

     

     

    100M FD

    y

    N

    1G HD

     

     

    1G FD

    Y、DID 链路接通->断开->接通

    链路接通@100M

     e2e.ti.com/.../260128_5F00_linkUptests.txt

    此致、

    Nick

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

    您好 Nick、

    我主要在 SDK 9 上进行测试、它 与作为链路伙伴的 Windows PC 相连（PC 与我们的电路板之间没有切换）（Windows 11 64 位）。

    1.  Windows PC eth 适配器是自动模式

    2.插件/手动插件在 PRU eth 侧.

     

    自动协商已启用

    自动协商已禁用

    10M FD

    能够建立链路、报告超时问题

    CAN 链路、 报告超时问题

    100M FD

    就可以建立链路、没有问题

    无法建立链路

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

    大家好：

    开发团队能够在 SDK 11.2 上复制 10M 超时问题和 100M 链路建立问题。 调试正在进行中。

    请提供有关特定产品用例的更多信息  

    如果这些信息很敏感、请随时通过 Zekun（而不是公共论坛）提供。

    对于您的产品、您是否实际使用了所有这些链路配置？ （例如，您的产品是否实际设置了 100M FD 无自动协商？） 还是只是进行验证测试、这些测试是作为测试的一部分进行的？

    请向我们提供一个完整的列表、列出您尝试在短期内走出大门的此特定产品所需的每种配置。 这将帮助我指导团队首先进行最重要的调试。

    对于 100M 链路建立问题、变通办法是否“足够好“？  

    暂时看起来、这些是针对 100M 链路建立+自动协商问题的权变措施：

    *使用 ethtool -r（参见日志 1）

    * 首先启用自动协商,然后禁用自动协商  

    请耐心等待、100M 链路在未启用自动协商的情况下启动需要一分钟。

    日志 1：ethtool -r  

    ## Tested on SDK 11.2
root@am64xx-evm:~# uname -a
Linux am64xx-evm 6.12.57-ti-g31b07ab8dfbc #1 SMP PREEMPT Thu Dec  4 13:07:37 UTC 2025 aarch64 GNU/Linux

***************************************************************
[   21.187930] icssg-prueth icssg1-eth eth2: Link is Up - 1Gbps/Full - flow control off

am64xx-evm login: root
...
root@am64xx-evm:~# ifconfig eth2 down
[   74.841023] icssg-prueth icssg1-eth eth2: Link is Down
[   74.848501] remoteproc remoteproc7: stopped remote processor 3008a000.txpru
[   74.855523] remoteproc remoteproc16: stopped remote processor 30084000.rtu
[   74.862419] remoteproc remoteproc15: stopped remote processor 300b4000.pru
[   74.869337] remoteproc remoteproc8: stopped remote processor 3008c000.txpru
[   74.876322] remoteproc remoteproc14: stopped remote processor 30086000.rtu
[   74.883253] remoteproc remoteproc13: stopped remote processor 300b8000.pru

## Set 100M FD autoneg off
root@am64xx-evm:~# ethtool -s eth2 speed 100 duplex full autoneg off
## Restart autonegotiation if enabled (not sure yet why this has an effect)
root@am64xx-evm:~# ethtool -r eth2

## Bring link back up
root@am64xx-evm:~# ifconfig eth2 192.168.1.164
[  123.295487] remoteproc remoteproc15: powering up 300b4000.pru
[  123.305386] remoteproc remoteproc15: Booting fw image ti-pruss/am64x-sr2-pru0-prueth-fw.elf, size 39848
[  123.314956] remoteproc remoteproc15: unsupported resource 5
[  123.320664] remoteproc remoteproc15: remote processor 300b4000.pru is now up
[  123.327799] remoteproc remoteproc16: powering up 30084000.rtu
[  123.333868] remoteproc remoteproc16: Booting fw image ti-pruss/am64x-sr2-rtu0-prueth-fw.elf, size 31576
[  123.343424] remoteproc remoteproc16: remote processor 30084000.rtu is now up
[  123.350605] remoteproc remoteproc7: powering up 3008a000.txpru
[  123.356740] remoteproc remoteproc7: Booting fw image ti-pruss/am64x-sr2-txpru0-prueth-fw.elf, size 39340
[  123.366332] remoteproc remoteproc7: remote processor 3008a000.txpru is now up
[  123.373537] remoteproc remoteproc13: powering up 300b8000.pru
[  123.379600] remoteproc remoteproc13: Booting fw image ti-pruss/am64x-sr2-pru1-prueth-fw.elf, size 40008
[  123.389046] remoteproc remoteproc13: unsupported resource 5
[  123.394719] remoteproc remoteproc13: remote processor 300b8000.pru is now up
[  123.401839] remoteproc remoteproc14: powering up 30086000.rtu
[  123.407851] remoteproc remoteproc14: Booting fw image ti-pruss/am64x-sr2-rtu1-prueth-fw.elf, size 30812
[  123.417309] remoteproc remoteproc14: remote processor 30086000.rtu is now up
[  123.424435] remoteproc remoteproc8: powering up 3008c000.txpru
[  123.430606] remoteproc remoteproc8: Booting fw image ti-pruss/am64x-sr2-txpru1-prueth-fw.elf, size 37828
[  123.440171] remoteproc remoteproc8: remote processor 3008c000.txpru is now up
root@am64xx-evm:~# [  140.867912] icssg-prueth icssg1-eth eth2: Link is Up - 100Mbps/Full - flow control off

## link is good
root@am64xx-evm:~# ping 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
64 bytes from 192.168.1.100: icmp_seq=1 ttl=64 time=0.131 ms
64 bytes from 192.168.1.100: icmp_seq=2 ttl=64 time=0.151 ms

    日志 2：首先启用自动协商、然后禁用自动协商  

    ## Tested on SDK 11.2
root@am64xx-evm:~# uname -a
Linux am64xx-evm 6.12.57-ti-g31b07ab8dfbc #1 SMP PREEMPT Thu Dec  4 13:07:37 UTC 2025 aarch64 GNU/Linux

***************************************************************
[   20.675934] icssg-prueth icssg1-eth eth2: Link is Up - 1Gbps/Full - flow control off

am64xx-evm login: root
...
root@am64xx-evm:~# ifconfig eth2 down
[   48.124214] icssg-prueth icssg1-eth eth2: Link is Down
[   48.131638] remoteproc remoteproc7: stopped remote processor 3008a000.txpru
[   48.138685] remoteproc remoteproc14: stopped remote processor 30084000.rtu
[   48.145592] remoteproc remoteproc13: stopped remote processor 300b4000.pru
[   48.152510] remoteproc remoteproc8: stopped remote processor 3008c000.txpru
[   48.159496] remoteproc remoteproc16: stopped remote processor 30086000.rtu
[   48.166413] remoteproc remoteproc15: stopped remote processor 300b8000.pru

## First enable autonegotiation, then disable autonegotiation
root@am64xx-evm:~# ethtool -s eth2 speed 100 duplex full autoneg on
root@am64xx-evm:~# ethtool -s eth2 speed 100 duplex full autoneg off

root@am64xx-evm:~# ifconfig eth2 192.168.1.164
[   85.749160] remoteproc remoteproc13: powering up 300b4000.pru
[   85.755332] remoteproc remoteproc13: Booting fw image ti-pruss/am64x-sr2-pru0-prueth-fw.elf, size 39848
[   85.765045] remoteproc remoteproc13: unsupported resource 5
[   85.770775] remoteproc remoteproc13: remote processor 300b4000.pru is now up
[   85.777947] remoteproc remoteproc14: powering up 30084000.rtu
[   85.783972] remoteproc remoteproc14: Booting fw image ti-pruss/am64x-sr2-rtu0-prueth-fw.elf, size 31576
[   85.793467] remoteproc remoteproc14: remote processor 30084000.rtu is now up
[   85.800667] remoteproc remoteproc7: powering up 3008a000.txpru
[   85.806843] remoteproc remoteproc7: Booting fw image ti-pruss/am64x-sr2-txpru0-prueth-fw.elf, size 39340
[   85.816404] remoteproc remoteproc7: remote processor 3008a000.txpru is now up
[   85.823651] remoteproc remoteproc15: powering up 300b8000.pru
[   85.829738] remoteproc remoteproc15: Booting fw image ti-pruss/am64x-sr2-pru1-prueth-fw.elf, size 40008
[   85.839212] remoteproc remoteproc15: unsupported resource 5
[   85.844835] remoteproc remoteproc15: remote processor 300b8000.pru is now up
[   85.851976] remoteproc remoteproc16: powering up 30086000.rtu
[   85.858003] remoteproc remoteproc16: Booting fw image ti-pruss/am64x-sr2-rtu1-prueth-fw.elf, size 30812
[   85.867534] remoteproc remoteproc16: remote processor 30086000.rtu is now up
[   85.874749] remoteproc remoteproc8: powering up 3008c000.txpru
[   85.880883] remoteproc remoteproc8: Booting fw image ti-pruss/am64x-sr2-txpru1-prueth-fw.elf, size 37828
[   85.890457] remoteproc remoteproc8: remote processor 3008c000.txpru is now up
root@am64xx-evm:~# [  207.747829] icssg-prueth icssg1-eth eth2: Link is Up - 100Mbps/Full - flow control off

root@am64xx-evm:~# ping 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
64 bytes from 192.168.1.100: icmp_seq=1 ttl=64 time=0.569 ms
64 bytes from 192.168.1.100: icmp_seq=2 ttl=64 time=0.408 ms

    此致、

    Nick

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

    您好 Nick、

    100M 链路建立问题：

    workaround1： “ethtool -r“ 表示“reload autoneg on“。  因此如果 PC 强制为 10M AutoNeg 、则 PRU eth  在 10M 速度上为 AutoNeg 成功。

    workaround2： 在 SDK 9.0 中不起作用。

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

    您好 Nick、

    今天、我们发现  SDK 9.0 上的 AutoNeg on/100M/full 处的超时问题仍然重现。

    测试步骤：

    1.设置 eth2  速度 100 双工全双工、默认 启用自动协商

    ethtool -s eth2 速度 100 双工全速

    2. 做我们的其他测试用例,这将导致 CPU 负载非常高。

    3. ping eth2,然后发现超时报告

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

    您好 Nick、

    我得到了昨天问题的整个内核日志。 仍然是 10M 问题。

    请检查下面的红色日志、为什么在已配置为“ethtool -s eth2 speed 100 duplex full“时 PRU eth 下移了 10M 半

    Feb 3 05:31:30 Aug 内核：[9442.960870] icssg-prueth icssg1-eth eth2：链路接通 — 100Mbps/full — 流量控制关闭
    Feb 3 05：31：40 Aug 内核：[9452.960668] TI DP83822 300b2400.MDIO：03：从协商速度 100Mbps 降至实际速度 10Mbps、请检查布线！
    Feb 3 05:31:42 Aug 内核：[9453.986202] icssg-prueth icssg1-eth eth2：链路接通 — 10Mbps/half（下移）-流量控制关闭
    Feb 3 05:32:07 Aug 内核：[9479.970643] icssg-prueth icssg1-eth eth2：链接断开
    Feb 3 05:32:07 Aug 内核：[9479.995501] icssg-prueth icssg1-eth eth2：等待命令完成超时

     

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

    您好、

    线程所有者将在 2 月 17 日的一周内停止工作。 如果您在这周内没有收到更新、请 ping 通该线程。

    感谢您的耐心。

    此致、
    Harshith

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

    你好  

    请查看以下补丁是否帮助您 、这是  将 PRU 速度锁定到 100M、从而绕过该 10M 超时问题、看看这样是否对您有帮助
    这意味着根本不支持 10M。 此修复仅适用于您的用例、不能是我们在 SDK 或上游中支持的内容

    e2e.ti.com/.../0001_2D00_net_2D00_ti_2D00_icssg_2D00_prueth_2D00_Workaround_2D00_for_2D00_10M_2D00_speed_2D00_Tx_2D00_watc.patch

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

    你好 Mukul、

    此 100M 锁定补丁解决方法工作正常。  我将执行更多测试。

    谢谢

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

    你好杜伟、

    对此处延迟的回复表示歉意。 我回到办公室并恢复工作。 本周我将与 Zekun 沟通、请给他一个项目状态的最新信息、以便我了解本周我还需要做些什么。

    此致、

    Nick

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

    在这里有什么进展?

    此致

    Ashwani