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.

[参考译文] Linux/DP8.3867万IS:PHY似乎会无缘无故进入断电状态

Guru**** 2481985 points


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

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/664819/linux-dp83867is-phy-appears-to-enter-power-down-unprovoked

部件号:DP8.3867万IS

工具/软件:Linux

 我们在设计中遇到了DP8.3867万IS的稳定性问题。 这在~60原型上效果很好,直到我们引入了新的以太网交换机来连接我们的主板。 此开关是Planet FSD-803。 在引入此交换机后,我看到使用 DP8.3867万IS的设计中存在大致的2 % 数据包丢失(之前我们没有看到),但使用此交换机的其他产品似乎都不受影响。

最糟糕的是,在2分钟到几天之间,这种情况会变得更糟,我们与设计之间的联系会永久失去联系。 唯一的解决方法是关闭并重新启动设计,将物理重置引脚拉低不足以解决问题。

测量MDIO接口时, DP8.3867万IS似乎已进入断电状态,尽管我们的软件不应接触物理PWDNn或写入此位(物理信号也被拉高2k2)。

我不像以太网正常工作时那样经常看到MDIO事务,但当我执行ifdown -> ifup时,我看到以下两个事务:

第一:

ST=01

TA=10 (写入)

PHYADD=0.1111万

REGADR=0万

TA=10

Data=0000-0001-1110-0001</s>0001 11100001

第二:

ST=01

OP=01 (读取)

PHYADD=0.1111万

REGADR=0万

TA=10

Data=0000-1001-1110-0001</s>1001 11100001

我们非常感谢您就此问题提供的任何帮助!

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

    您好,

    请分享以下信息:

    1.使用绑带设置的硬件配置。

    2.当您认为DP8.3867万处于低功耗状态时,是否可以测量功率?

    3.在DP8.3867万至MDIO上执行的寄存器配置列表。

    4.示意图

    此致,

    很棒

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

    e2e.ti.com/.../Eth0PHY.pdfHello,感谢您的快速回复。

    1: 除了RX_D0和RX_D2 (PHYADD 15)上的2k49上拉,所有引脚都保持打开-但当连接的SoC在启动过程中对其中一些引脚实施了内部25k上拉时,我们在启动过程中遇到了问题。 这就是为什么我们在SoC完全配置时拔出PHY的物理重置引脚的原因,因此当PHY在重置后读取这些引脚时,我们不应干扰带状配置。 随附的示意图中列出了绑带配置。

    2:我们无法测量PHY似乎进入断电状态时的功率差异。 该设计由24V电源供电,故障前和故障期间的电流消耗为0.17A。

    3:寄存器配置,我们应该通过DTS设置以下内容:

    TI,rx-internal-delay =<DP8.3867万_RGMIIDCTL_2_25_NS>;>>寄存器0x0086

    TI,TX-INTERNAL -延迟=<DP8.3867万_RGMIIDCTL_2_75_NS>;>>寄存器0x0086

    TI,fifo-depth =<DP8.3867万_PHYCR_FIFO_DEPT_4_B_NIB>;>>寄存器0x0010

    我们已经使用Rocketboards的Linux内核版本4.12 和4.15 进行了测试,我们在这里使用/drivers/net/phy/dp8.3867万。

    4:随附示意图。

    5:我们还列出了一些在故障之前和期间运行的MII诊断程序,但我们尚不知道我们对故障期间运行的结果的信任程度。 结果载于所附文本file.e2e.ti.com/.../mii_5F00_diag.txt

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

    在这一案件中出现了一些事态发展。 为了一次只关注一个问题,我还没有提到我们还观察到与某些GbE以太网设备的自动协商失败。 我们发现了 与模式1或2中捆绑的RX_DV/RX_CTRL引脚相关的修复(有关详细信息和我们希望澄清的一些问题,请参阅随附的Word文档)。

    这解决了与GbE设备的自动协商问题,并且它似乎对导致断电的不稳定产生了影响。 使用新的修复程序,DP8.3867万与“不稳定”100Mbit交换机的自动协商失败-但是,如果我们禁用GbE通告,我们将获得100 % 稳定100Mbit链接和通信。

    我希望您能够回答随附文档中的问题,我们希望了解此问题的根本原因是什么。

    最后,我们使用此PHY实现了对TDR的支持。 我们是否可以使用DP8.3822万所述的"电缆长度和故障位置"计算? 根据我们的测试,我们得到的值似乎是7 10 m 过高-我们应该从该测量中得到什么类型的精确度?

    e2e.ti.com/.../GBitIssue.docx

    此致,

    Thomas

    RX_DV/RX_CTRL引脚捆绑

                                       模式1或2

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

    如果RX_CTRL上的模式3没有捆绑,则需要清除寄存器0x31中的位[7],如您所述。
    请通过写入0x4000以注册0x1F进行软重置来遵循此步骤。
    DP8.3867万IS有一个隐藏的引导程序,但无法正常工作。 如果您没有绑定到模式3,PHY可能会与某些链接伙伴发生问题。 如果不能绑带到模式3,则寄存器0x31中的位[7]是另一个解决方案。

    Rx/TX延迟和FIFO深度取决于您的系统。 您需要查看MAC的内部延迟,并考虑任何跟踪延迟。 执行此操作后,您可以选择为设置/保持提供最大余量的延迟类型。 FIFO深度取决于预期的帧大小。

    当您看到100Mbps交换机出现不稳定链路问题时,您是否看到MDI上的信令为DP8.3867万IS更改? 您能否探测RD和TD引脚的MDI以查看信令的外观? 在与连接的交换机建立链路之前,是否在寄存器0x31中写入了bit[7]?
    如果您遇到此问题,然后断开电缆连接,PHY是否会恢复? 寄存器是否始终读取0x01E1?

    是否可以检查发生问题时为DP8.3867万IS提供的时钟?
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好Ross:

    现在,我们还在清除寄存器0x31中的位[7]后实现了软复位。 这样做后,我们无法引发我们之前报告的不稳定状态或断电状态。

    我没有在不稳定存在时测量计量吸入器,只是在不稳定状态以永久"断电"模式结束时才测量。 一旦PHY进入此模式,拔下电缆并连接到任何其它设备都不会改变任何情况,并且我们无法通过尝试更改PHY设置来重新建立AutoNeg或链接-寄存器继续读取0x01E1。 发生这种情况时,我们没有清除bli [7]。

    MDI的RD和TD引脚,我不确定我是否理解。 我们有MDC和MDIO,我一直在探测MDIO TX和RX时隙,但由于设计紧凑,无法将探头连接到MDC。

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

    您遇到的问题似乎是无效手提带状态造成的。
    在初始化过程中,请将束带状态设置为模式3或使用寄存器0x31中的bit[7]。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好Ross:

    是的,现在情况要稳定得多。 感谢您的支持!

    此致,
    Thomas