[参考译文] Linux/DP8.3867万IS：使用特定以太网设备进行无限AutoNeg循环

您好，Thomas：

通常，由于没有按照DS的要求将RX_CTRL线路绑定到模式3或模式4，某些链接伙伴会出现自动NEG循环。

如果您要执行自动调整，模式3手提带将是最适合您的情况。

为避免更改硬件，还可以清除寄存器0x31的位[7]并重新启动自动协商，这将导致与开机时将RX_CTRL设置为模式3相同的稳定链接操作。 此解决方法的问题是每次重置PHY或为其通电时都必须执行此操作。

另请确保您的MAC使用扩展寄存器访问方法来访问PHY寄存器0x31。如果您未执行数据表的“8.4 ．2.1 3写入(无开机自检增量)操作”部分中所述的4寄存器写入方法。

此致，

你好。

感谢您的快速回复。
恐怕我们已经在清除寄存器0x31的位[7]和软件重置PHY，因为是的，我们的RX_CTRL在模式1中捆绑。 在我们实施之前，使用此特定交换机的AutoNeg工作正常。 实施修复后，除非禁用1000BASE-T通告，否则使用此设备的AutoNeg将失败。
当然，实施修复后，我们发现AutoNeg的稳定性和与我们测试过的所有其他设备的通信都要好得多。

此致，
Thomas

您好，Thomas：

很有趣，清除bit[7]会导致此开关出现问题。 此交换机是否已启用EEE？ 如果链接伙伴未启用EEE，它是否会重新启动自动协商？

是否正在清除整个寄存器0x31？ 默认情况下，bit[12]应该=1，并且应该继续为=1，并且在清除bit[7]时不会被覆盖。

此致，

您好，Rob。

EEE所指的是节能吗？ 否，此交换机不支持，它仅列出符合IEEE 802.3 (以太网)，IEEE 802.3u (快速以太网)，IEEE 802.3x (全双工流量控制)。

从我在变通办法中看到的内容中，驱动程序读取0x31，清除此操作中的第7位，然后将结果写回-我们应该只接触第7位：
/* RX_DV/RX_CTRL在模式1或模式2变通办法中捆绑*/
如果(dp8.3867万->rxctrl_strap){
Val = phy_read_md (phydev，DP8.3867万_DEVADDR，DP8.3867万_CFG4)；
Val &=~位(7)；
PHY_WRITE_MMD (phydev，DP8.3867万_DEVADDR，DP8.3867万_CFG4，val)；
}

此致
Thomas

您好，Thomas：

是的，我指的是节能以太网。 通常，仅当涉及EEE链接伙伴时，才需要修改DP8.3867万自动协商。

因此，您可能还会遇到链路稳定性和此交换机的一些其他问题。 当链接打开和关闭时，您能否提供INT状态寄存器地址0x13？ 我想知道那里是否记录了任何事件。

另外，您是否可以检查寄存器0x2D是否设置为0x0。 这是快速链接删除寄存器。 我们已经看到一些问题，其中一些PHY会导致错误，并且在出现一些错误后，链接会迅速断开。 虽然标准IEEE状态机不会丢弃这些链路，但我们面向工业市场的FLD功能可能会影响链路上行/下行循环。

您能否与我分享您的DP8.3867万IS实施示意图？

此致，

Rob，您好！

在连接到有问题的链接合作伙伴时，我们的主板上已读取了以下寄存器读数：

案例1：链路关闭/打开/关闭时重复读出寄存器0x13 ....：
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
# phytool eth0/0xF/0x13
IEEE-phy：reg：0x13 val：0x5dc6
# phytool eth0/0xF/0x13
IEEE-phy：reg：0x13 val：0x0400
# phytool eth0/0xF/0x13
IEEE-phy：reg：0x13 val：0x0044
# phytool eth0/0xF/0x13
IEEE-phy：reg：0x13 val：0x1c42
# phytool eth0/0xF/0x13
IEEE-phy：reg：0x13 val：0x0440
# phytool eth0/0xF/0x13
IEEE-phy：reg：0x13 val：0x0046
# phytool eth0/0xF/0x13
IEEE-phy：reg：0x13 val：0x1c06
# phytool eth0/0xF/0x13
IEEE-phy：reg：0x13 val：0000
# phytool eth0/0xF/0x13
IEEE-phy：reg：0x13 val：0x0444
# phytool eth0/0xF/0x13
IEEE-phy：reg：0x13 val：0x1c42
# phytool eth0/0xF/0x13
IEEE-phy：reg：0x13 val：0x0444
# phytool eth0/0xF/0x13
IEEE-phy：reg：0x13 val：0x1042
# phytool eth0/0xF/0x13
IEEE-phy：reg：0x13 val：0x1c02
# phytool eth0/0xF/0x13
IEEE-phy：reg：0x13 val：0x0440
# phytool eth0/0xF/0x13
IEEE-phy：reg：0x13 val：0x1042
# phytool eth0/0xF/0x13
IEEE-phy：reg：0x13 val：0x1c02
# phytool eth0/0xF/0x13
IEEE-phy：reg：0x13 val：0x0444
# phytool eth0/0xF/0x13
IEEE-phy：reg：0x13 val：0x1c06
# phytool eth0/0xF/0x13
IEEE-phy：reg：0x13 val：0000
# phytool eth0/0xF/0x13
IEEE-phy：reg：0x13 val：0x0444
# phytool eth0/0xF/0x13
IEEE-phy：reg：0x13 val：0x1042
#
#
#

案例2：在同一方案中，寄存器0x002d的3个读数：
----------------------------------
# phytool write eth0/0xF/0x000d 0x001f
# phytool write eth0/0xF/0x000e 0x002d
# phytool write eth0/0xF/0x000d 0x401f
# phytool read eth0/0xF/0x000e
0x0400
# phytool read eth0/0xF/0x000e
0x0400
# phytool read eth0/0xF/0x000e
0x0400
#

此致，Eldor

随附的示意图显示了PHY硬件实施。 在AutoNeg循环期间检查寄存器的结果很快就会出现。

此致

Thomas

e2e.ti.com/.../8831.Eth0PHY.pdf

您好，Eldor和Thomas：

从提供的寄存器转储和原理图中，我看到您偶尔有XGMII_ERR_INT，而您提供的PHY参考时钟来自原理图中未捕获的源。

此参考时钟上的抖动可能较高，或者DP8.3867万的参考时钟与此特定交换机之间存在PPM偏移。 您还可以让DP8.3867万解析预期的100M之外的链路速度。

是否可以查看25MHz_CLK_1参考的抖动？ 我们希望看到1k到10M之间<10 ps RMS，10M > 25M之间<50 ps

同时确保TX_CLK上提供的参考时钟为125MHz，XI时钟为25MHz +/- 50ppm。 测量DP8.3867万的RX_CLK频率，以100m为单位，应为25MHz。 如果您看到它增加到125MHz，则会出现问题。

我还想让您检查寄存器0x11，它将向我们显示DP8.3867万是否解析自动协商为100Base-TX模式，或者是否解析为1000BASE-T

此致，

Rob，您好！

遗憾的是，我们手边没有支持精确抖动测量的设备，但我尝试用我们手头的示波器来捕获这些特性。 25MHz时钟信号来自ASDMB-25.000MHZ-LY-T，通过CDCLVC1104。 额定值为+/- 10ppm。 我们的示波器不支持低至10 ps的测量，但在从触发侧向到测量的2毫秒延迟时间内，我看到信号摆动小于整个周期的+/- 20 %。 这并不足以充分说明抖动，但它表明我们的PPM精度良好。

在使用此特定交换机的AutoNeg循环过程中，RX_CLK和TX_CLK均为25MHz最大值。 除非连接到GbE交换机，否则我看不到125MHz，在这种情况下，我在Rx和Tx CLK上都看到它。

此致
Thomas