[参考译文] DP83867IS：除非强制使用 MDI 主模式、否则链路不稳定

嗨、Evan、

我已向您发送了一封包含示意图的电子邮件、本例中的链路合作伙伴是 NETGEAR GS108v4、但我们在其他交换机上看到这种情况的频率较低、尽管找到某种触发方式或方式开始失败是很困难的、 有时它会长期保持良好状态、然后经常变得糟糕

我们已经尝试过加热组件、看看温度是否有任何影响、但情况似乎没有。

感谢您在寄存器上进行确认、

杰西

您好、Jesse：

感谢您分享原理图-我认为引脚排列没有任何问题。

您如何将器件设置为主模式？ 请分享以下寄存器转储：

-具有强制主模式的工作案例,寄存器0x0到0x1F 和任何其他寄存器您正在写入

-故障不稳定链路情况,寄存器0x0和0x1F

谢谢！

埃文

您好 Evan：

很抱歉延迟回复、我们在调试过程中转移了一点、偶然发现了与模式3下缺少 RX_CTRL 引导程序相关的未记录问题。

我们注意到、我们正在使用的模块启用了 EEE、如果我们查看 PHY 驱动器调用以检查 EEE 功能、则表明它支持 EEE。

手动强制关闭 EEE 似乎可以解决我们的问题、除了几年前的论坛主题帖之外、我们在任何数据表或勘误表中都无法找到这一点。

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/716392/dp83867ir-eee-energy-efficient-ethernet-with-dp83867

数据表似乎也不完全正确、因为它说支持的唯一 DEVAD 为0x1F、但 PCS 是定义和可访问的、因此使用以下命令

phytool WRITE ETH0/0/0x0d 0x3
phytool WRITE ETH0/0/0x0E 0x14
phytool WRITE ETH0/0/0x0d 0x4003
phytool 读取 eth0/0/0x0E

我们回读了0x6、它与我们看到的用于10/100/1000的 EEE CAP 匹配、但这很混乱、因为数据表指定唯一支持的 DEVAD 应该是0x1F。

我们还尝试了几种方法、例如设置/清除 CFG4/0x31中的 TEST 模式位、然后进行软件复位、但这些操作都不会清除 PCS 寄存器中的 EEE 功能。

您是否能够按照说明验证此问题是否存在？ 这是 EtherNet/kernel/uboot 团队能够为其生成驱动程序补丁上行吗？ 如果我们知道如果您能够确认问题和潜在的权变措施、此解决方案的正确解决方案是什么样的、我们也可以考虑尝试自己来解决此问题。

谢谢！

杰西

您好、Jesse：

要澄清一点、在模式3中设置 RX_CTRL 以禁用 EEE 是否可以解决该问题？

EEE 是 DP83867IS 上的一个弃用特性、在 PCS 空间中有为 EEE 保留的寄存器、但不应为应用修改这些寄存器。

您正在使用什么驱动程序？ 我们目前无法将上游驱动程序写入官方内核、但我们可以修补并共享来自内部存储库的驱动程序。

谢谢！

埃文

嗨、Evan、

我们不会修改这些寄存器、甚至无法执行此操作、因此我最初要求解决方法。

我们的电子工程师目前正在修改我们的一个电路板、以便在模式3中搭接 RX_CTRL、我们假设这样可根据所链接的线程解决该问题。

我们正在使用 dp83867的标准内核驱动程序(在5.10.120版本上)、但我们发现内核中已经存在的另一种变通办法(BROKEN eee 似乎如此常见)、方法是向 Phy 添加"ee-Broked-100TX"和"ee-Broked-1000t"属性、这会禁用其广播并似乎可以完成此任务、 但是最好能够在一定程度上确认这个问题的存在、以及通过引脚束带可以在多大程度上解决这个问题、因为我们需要在未来的设计中牢记这一点。

我们认为、除了需要禁用的内部测试模式之外、至少还应记录此行为、重点放在不执行该操作会导致此 EEE 问题时所需的引脚搭接、 或将其作为勘误表、因为很难进行跟踪、因为没有明显的错误通知您这将会发生、 这尤其令人困惑、因为扩展空间仅讨论使用0x1F 进行自定义访问、但可以访问 PC 空间的器件3、因此、我最初并未深入探究 EEE 是一个可能的原因。

嗨、Evan、

目前、该变通办法足以满足我们的需求、在对多个器件进行一天的测试后、我们没有发现任何问题。

完全同意的文件差距,如果它可以帮助甚至一个人避免头痛的调试这将是伟大的! 我的团队当前阅读文档的方式就像 CFG4位7权变措施足以使其正常工作一样、因此很高兴听到将更加强调的内容加以解决。

非常感谢您花时间研究和反馈,感谢您的帮助!

谢谢！

杰西