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.

[参考译文] PROCESSOR-SDK-J784S4:CPSW9G 切换载波

Guru**** 2391165 points


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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1498564/processor-sdk-j784s4-cpsw9g-toggling-carrier

部件号:PROCESSOR-SDK-J784S4

工具/软件:

你(们)好

我们在一段时间前迁移到 SDK 10.1、现在正在迁移到11.0。

自10.0更新以来、CPSW9G 存在零星的载波损耗问题。

这在内核日志中如下所示:

[ 2311.782322] am65-cpsw-nuss c000000.ethernet xg19: yt8614_read_status, phy addr: 10, link down
[ 2311.782577] am65-cpsw-nuss c000000.ethernet xg19: Link is Down
[ 2311.805434] switch: port 4(xg19) entered disabled state
[ 2312.810441] am65-cpsw-nuss c000000.ethernet xg19: yt8614_read_status, phy addr: 10, link up, media UTP
[ 2312.811138] am65-cpsw-nuss c000000.ethernet xg19: Link is Up - 100Mbps/Full - flow control off
[ 2312.811183] switch: port 4(xg19) entered blocking state
[ 2312.811190] switch: port 4(xg19) entered forwarding state
[ 2329.190115] am65-cpsw-nuss c000000.ethernet xg19: yt8614_read_status, phy addr: 10, link down
[ 2329.190394] am65-cpsw-nuss c000000.ethernet xg19: Link is Down
[ 2329.205651] switch: port 4(xg19) entered disabled state
[ 2330.214723] am65-cpsw-nuss c000000.ethernet xg19: yt8614_read_status, phy addr: 10, link up, media UTP
[ 2330.215908] am65-cpsw-nuss c000000.ethernet xg19: Link is Up - 100Mbps/Full - flow control off
[ 2330.217375] switch: port 4(xg19) entered blocking state
[ 2330.217385] switch: port 4(xg19) entered forwarding state
[ 2354.790451] ------------[ cut here ]------------
[ 2354.790466] phy_check_link_status+0x0/0xf8: returned: -5
[ 2354.790546] WARNING: CPU: 4 PID: 12616 at drivers/net/phy/phy.c:1233 phy_state_machine+0xac/0x2f0
[ 2354.790559] Modules linked in: rpmsg_ctrl rpmsg_char virtio_rpmsg_bus rpmsg_ns rpmsg_core ti_k3_r5_remoteproc r8169 atemsys *** fuse
[ 2354.790582] CPU: 4 PID: 12616 Comm: kworker/4:2 Tainted: G        W          6.6.44-krc5-productive #1  Debian 6.6.44-3 d15816b0e2f7511437461580b670dfedb41c32d7
[ 2354.790590] Hardware name: *** KR C5 basic-2 (J784S4) (DT)
[ 2354.790592] Workqueue: events_power_efficient phy_state_machine
[ 2354.790598] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 2354.790602] pc : phy_state_machine+0xac/0x2f0
[ 2354.790607] lr : phy_state_machine+0xac/0x2f0
[ 2354.790611] sp : ffff800085de3d60
[ 2354.790613] x29: ffff800085de3d60 x28: 0000000000000000 x27: 0000000000000000
[ 2354.790619] x26: ffffd90ecc92e360 x25: ffff39670940b940 x24: ffff396ec0109a05
[ 2354.790624] x23: 00000000fffffffb x22: ffff3966c0248ce8 x21: 0000000000000005
[ 2354.790629] x20: ffff3966c0248d40 x19: ffff3966c0248800 x18: ffff8000800d7020
[ 2354.790635] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[ 2354.790640] x14: 0000000000000000 x13: ffffd90ecae15e60 x12: ffffd90ecae82784
[ 2354.790645] x11: ffffd90ecae8b08c x10: 0000000000000b10 x9 : ffffd90ecbb843ac
[ 2354.790650] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
[ 2354.790655] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
[ 2354.790659] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000
[ 2354.790665] Call trace:
[ 2354.790667]  phy_state_machine+0xac/0x2f0
[ 2354.790672]  process_one_work+0x148/0x3d0
[ 2354.790681]  worker_thread+0x354/0x470
[ 2354.790686]  kthread+0x11c/0x128
[ 2354.790692]  ret_from_fork+0x10/0x20
[ 2354.790698] ---[ end trace 0000000000000000 ]---

就我们现在所看到的情况而言、这发生在随机端口上。

我们发现、随机设备连接到该设备时、不太可能出现连接设备的问题。

您能帮助我们找到问题的根本原因吗?

此致

Daniel

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

    尊敬的 TI 专家:

    我已经与客户确认、SDK9.2之前从未发生过这种情况(基于 SDK9.2的客户最后一个项目 SOP)。

    他们在升级到 SDK10.1之后发现了此问题。

    您能为客户提供一些调试指导吗?

    谢谢、

    Kevin

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

    您好、

    这种硬件设置是否可以与 SDK 9.2一起正常工作?

    通常、这些类型的问题是由于在 PHY 或 PHY 上运行的固件依赖不同的驱动程序而不是实际/预期的驱动程序。

    是否有任何服务定期运行以使链路断开和连接?

    此致、
    Sudheer

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

    你好  Sudheer

    此相同硬件设置是否与 SDK 9.2一起工作正常?

    是的、相同的硬件  

    通常、这些类型的问题是由于固件在 PHY 或 PHY 上运行、引用不同的驱动程序而不是实际/预期的驱动程序。

    CPSW9G 仅由 A72内核(Linux)使用。 至少我们不知道有任何 R5要求它的资源。

    是否有任何服务正在运行以定期关闭和打开链路?

    我们的任何服务都不会向上/向下更改链接。

    此致

    Daniel

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

    您好、

    与9.2 SDK 相比、您能否确认 Linux 中的 PHY 驱动程序是否有任何更新?

    另外、是否还要确保9.2中使用的任何设备树配置也已迁移到10.1?

    此致、
    Sudheer

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

    你(们)好

    与9.2 SDK 比为10.1、您能否确认 Linux 中的 PHY 驱动程序是否有任何更新?

    我们使用多个 PHY。 两个 RTL8211F (我们使用的是维护驱动程序)和一个 YT8614 (这不是维护驱动程序)。 但由于我们在这两个页面上都看到了该问题、因此我想它与 PHY 无关。

    此外、确保9.2中使用的任何设备树配置也迁移到10.1?

    我会将我们的完整器件树发送为私人消息。

    可能会感兴趣的一件事是以下内核消息:

    [    0.245858] mux muxchip0: unable to set idle state
    [    0.245862] mmio-mux 104080.mux-controller: probe with driver mmio-mux failed with error -5

    请参阅该主题: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1475984/processor-sdk-j784s4-network-migrating-kernel-device-tree-from-sdk-9-2-to-10-1

    据我所知 、对我们来说、这不是问题。 但可能是这样吗?

    此致

    Daniel

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

    您好、

    [报价 userid="567658" url="~/support/processors-group/processors/f/processors-forum/1498564/processor-sdk-j784s4-cpsw9g-toggling-carrier/5759501 #5759501"]

    可能会感兴趣的一件事是以下内核消息:

    [/报价]

    上面是使用2个协议(即多链路/多协议)的三个或更多链路的补丁。

    我可以根据您的器件树网络配置、您使用的是上述串行器/解串器2通道(SGMII (端口5)、SGMII (端口6)、QSGMII、SGMII (端口8))、请集成上述补丁并检查。

    此致、
    Sudheer

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

    我看不到您指的是哪个补丁。

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

    您好、

    我是指上面指向的 e2e 中描述的补丁。
    https://github.com/torvalds/linux/commit/5b7b83a9839be643410c31d56f17c2d430245813

    请针对您使用的串行器/解串器配置集成该补丁。

    此致、
    Sudheer

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

    补丁已应用。 没有它、网络就根本无法工作。

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

    您好、

    如前面所述、您是否已确认器件树配置并重置为9.2 SDK?

    此外、检查 PHY 驱动程序是否有任何差异?

    此外、您能否检查是否将 PHY 复位/使能 GPIO 用于任何其他目的? 在正常和问题场景中、请共享复位/使能 GPIO 的焊盘配置值?

    另外、您能否确认为什么您没有配置(高/低)其他网络引脚( NETWORK_PINS_DEFAULT )但从 MDIO 节点复位 QSGMII PHY 除外?

    此致、
    Sudheer

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

    大家好!

    今天讨论的更新内容:

    TI 提供了载波切换的可能原因(链路接通/陶氏)
    1)如果用于 PHY 控制的任何 GPIO 在任何应用中重复用于其他用途(因为引脚会进行多路复用以实现 SoC 中的不同功能)
    2)链路伙伴可向 PHY 发出链路断开/接通命令
    3)电缆问题(缠绕或硬连接)
    4)强制 PHY 断开/建立链路状态。

    为缩小问题范围/缩小问题的根本原因、TI 提供了建议
    1)检查 CTRLMMR PAD_CONFIG 寄存器、以确认用于 PHY 控制的 GPIO (如 PHY 复位)、PHY EN 是否配置为 GPIO 功能?
    例如:AE33引脚用于 QSGMII PHY 复位控制


    焊盘配置寄存器可在 技术数据表中找到。

    2)在 CPSW 驱动程序链路接通/链路断开回调 API 中启用调用跟踪、以检查如何启动链路断开/建立状态。


    3)使用(phytool)等可用工具读取 PHY 寄存器、以检查 PHY 端是否真正断开链路?
    https://github.com/wkz/phytool

    4)检查一次电缆连接, 忽略 是否同样、硬件设置能够与 TI SDK 9.2一致运行。

    此致、
    Sudheer