[参考译文] DP83867IR：无法通过 U-Boot 中的 DP83867IRPAP 接收/发送数据包

您好 Sagar、

MAC 上的 RGMII TX 和 RX 延迟设置为什么？

此外、将此问题隔离到 PHY 的 MAC 或 MDI 侧也会有所帮助。 您能否执行模拟回路测试以及 数据表第8.4.4节中所述的反向回路测试？ 这可以为我们提供进一步调查的线索。  

谢谢、

David

尊敬的 David：

感谢您的快速回复。
最初、它被设置为：TX 延迟= 0.25ns 且 RX 延迟= 2.25ns、但由于这不起作用、我们通过迭代循环来进一步分析它
对于每个 ping 请求、RX 延迟设置为0.25ns 时、TX 延迟从0.25ns 增加到4.00ns、然后将 RX 延迟升高到0.5ns 、TX 延迟从0.25ns 增加到4.00ns 等等。
因此、对于整个延迟范围、我们未能成功地向客户端传输有效的数据包。

是的、我们正在尝试确定如何在 U-Boot 环境中检查目标上的环回、并将更新结果。

谢谢和 BR、
Sagar

尊敬的 David：

此外、我们还了解到、我们需要遵循一组特定的序列来将 PHY 置于各自的环回模式、因此无法确定如何将结果推断为通过/失败。
是否需要完成 PRBS 设置？
在 U-Boot 中、我们遵循以下步骤：
1.使用 setenv ipaddr 192.168.10.10配置网络接口
2. ping  192.168.10.10 (相同的 IP 地址)
预期是如果启用了模拟回路、我们应该会得到确认"已激活"(这是对的吗？)
如果我们在这里遇到问题、请告知我们。

谢谢和 BR、
Sagar

尊敬的 David：

进一步更新了我们的分析和环回模式测试：

我们观察到10/100/1000bps 的 eth0 TXCLK。 我们观察到时钟的振幅变化如下：
     10Mbps：1.8V
    100Mbps：2.0至2.1V
      1Gbps：1.1V
   这是预期的吗？
 

在10 Mbps 时、我们有一个正常工作的网络连接。 目标方能够 ping 主机、将 RX/TX 延迟设置为0.25ns。
  相关布线的 PCB 布线延迟最初连接在此螺纹中。

我们在此阶段启用了 MII 环回、遵循的顺序为：

RD_dt = phy_read (phydev、MDIO_DEVAD_NONE、DP83867_CTRL)；
PHY_WRITE_MMD (phydev、DP83867_DEVADDR、DP83867_CTRL、rd_dt | 0x8000)；

RD_dt = phy_read (phydev、MDIO_DEVAD_NONE、DP83867_RGMIICTL)；
PHY_WRITE_MMD (phydev、DP83867_DEVADDR、DP83867_RGMIICTL、RD_dt | 0x00D3)；

PHY_WRITE_MMD (phydev、DP83867_DEVADDR、MII_DP83867_BOSCH、0x0040)；

RD_dt = phy_read (phydev、MDIO_DEVAD_NONE、MII_BMCR)；
PHY_WRITE_MMD (phydev、DP83867_DEVADDR、MII_BMCR、0x4100)；

RD_dt = phy_read (phydev、MDIO_DEVAD_NONE、DP83867_CTRL)；
PHY_WRITE_MMD (phydev、DP83867_DEVADDR、DP83867_CTRL、rd_dt | 0x4000)；

我们观察到、在发送 ping 请求后、只有 MAC 的 TX 计数寄存器根据发送的数据包数量增加。
   但 Mac 的 RX 数据包计数器不接收任何数据包？
在 PHY 中、我们看不到任何 RX/TX 数据包计数器、我们没有推测出什么东西吗？
6. 在数字环回的情况下，行为和观察也是一样的。

计时要求 doc 指定了设置数字回送的以下序列。
在测试环回模式时、自举引脚或其他 PHY 寄存器有什么影响？
默认寄存器值或除下面提到的寄存器之外的任何其他设置是否会干扰环回模式操作、导致其失败？
从文档中可以看到、如何确认环回是否通过/失败并不清楚、您能否详细说明如何实现这一点？

如果您能够了解上述问题、那将会更好、因为这些问题更具阻断性和高优先级。

谢谢和 BR、
Sagar

您好 Sagar、

对于所有速度、时钟振幅应等于 VDDIO、在您的情况下为1.8V。 这可能值得调查。   

ping 请求不是要在环回模式下测试的适当命令。 应改用 PRBS 发生器和校验器。 请执行反向回送测试 、并使用链路伙伴侧的 PRBS 来推送和检查数据、以及 MII 回送测试将 PRBS 数据从 MAC 侧推送。 您会注意到、故障排除指南的第2.8节列出了这些说明。  没有任何其他寄存器或自举值会干扰此测试。  

您能否还提供 RGMII 信号(PHY 上的 RX_CLK 和 RX_D0以及 MAC 上的 TX_CLK 和 TX_D0)的示波器截图？  

您的原理图看起来正常。 不过、为什么 TX_D4-TX_D7引脚对地短路？ 如果未使用它们、则应保持悬空。  

谢谢、

David

尊敬的 David：

很抱歉、由于延迟了反转、我们还在末端进行了一些回路测试实验。

我们启用了 MII 回送、并且能够看到 TX 和 RX 数据包计数器的数量相对于 ping 传输的帧数量增加了。 在分析这一点时、我们将观察 MAC 中的某些寄存器：

我们想知道：

1) 1)如果 PHY 配置为环回模式、那么我们看到数据丢失的原因可能是什么。
假设我们通过 ping 传输4个帧(每个64字节)、那么 phy 应将总共256个字节环回 Mac、但我们观察到的是 Mac 仅接收252字节、 因此、它可能会触发 RX 对齐错误。 不清楚 PHY 内的修整4字节数据的内容是什么。

2) 2)根据您的建议、如果我们要使用 PRBS 发生器和校验器、我们是否必须使用另一个板作为具有相同物理层的链接伙伴、或者在运行 Linux 的任何客户端 PC 上也可以使用该物理层？ 如果是、您能否帮助完成这些步骤、因为对于所需的设置和执行的步骤有点不清楚？

3) 3)如果我们正在运行近端环回、是否可以在同一器件上使用 PRBS 发生器和校验器来验证环回？ 如果是、如何操作？

4) 4) TX_CLOCK 和 TX_Data 行之间的可接受偏差是多少？ 在接收器处测量时、我们当前观察到以下偏差、即 PHY 侧(R368和 R370)

由于我们具有10Mbps 的功能、因此我们也尝试在此处进行分析：

10Mbps 和100Mbps 中的偏差看起来相似、这是否在可接受的范围内？

5) 5) TXD4至 TXD7根据数据表中的建议接地。 如果我们对以下建议的解释有误、请告知我们。

您能帮我们解决上述问题吗？
我将使用最新实验重新捕获 RX 和 TX 时钟并进行分享。

谢谢和 BR、
Sagar

您好 Sagar、

1) 1)看起来 MAC 接口上发生了一些数据包损坏。 查看您之前回复的第4)号中的偏差表、这可能是问题的原因。 为什么 D0偏斜与其他3条数据线有如此大的不同？  您的布线会根据您的第一个帖子进行长度匹配、因此 D0的这种额外偏斜来自哪里？ 所有4条数据线路都应具有非常接近的偏斜量。  

数据表的第7.9节列出了 RGMII 时序规格。 数据到时钟输入偏斜应在1和2.6ns 内、因此您不符合该要求。 无论您进行何种调优、由于 D0偏斜与 D1-D3有很大不同、因此所有4条线路都无法满足规格要求。 这说明了您无法找到可行的调优选项的原因。 首先、您必须将 D0偏斜修正为与其他偏斜相等、然后您可以像以前那样进行调优实验。  

2)是的、对于反向回送测试、您必须使用能够生成和检查 MAC 数据包或 PRBS 的链接伙伴。  如果为此使用另一个 DP83867、 数据表的第8.4.5节介绍了 PRBS 生成/检查。  如果此反向回送测试成功、则将确认问题出在 MAC 接口上。  

3)否、必须使用来自 MAC 的数据包发生器/校验器进行近端回送。

4) 4)回答1)

5) 5)您回答正确、接地端接正常。

此问题似乎是由 RGMII 计时引起的、因此请确保计时符合数据表第7.9节中列出的规格、我怀疑这将解决您的问题。

谢谢、

David

感谢 David 提供您的意见、我们将检查 D0和 D1-D3之间偏差的原因。

谢谢和 BR、
Sagar

此外、如果偏差不正确、我们想知道它是如何实现10Mbps 数据速率的？

谢谢和 BR、
Sagar

尊敬的 David：

3)正如您提到的、在近端回送的情况下、使用"来自 MAC 的数据包生成器/校验器进行近端回送。"。

我们在 MAC IP 文档中进行了检查、但没有看到任何可用于此目的的 PRBS 发生器或校验器。
在这种情况下、我们应该继续使用 ping 作为测试实用程序、或者您对此有其他建议。

谢谢和 BR、
Sagar

您好 Sagar、  

10和100Mbps 的时序要求不太严格、因为时钟周期要慢得多、因此您的设置可能不符合1000Mbps 的设置/保持要求、但仍能在10或100中运行。  

从我的有限理解来看、寄存   器 RX_octet_Count_Good 0x784、RX_octet_Count_Good 0x788和 RX_Alignment _Error_packets 0x798好像正在执行 MAC 数据包检查、因此您可以继续使用它。 我的理解是否正确？

谢谢、

David

尊敬的 David：

只是为了让您随时了解最新信息。 我们正在努力按照之前的讨论匹配偏斜。  我们将调整 MAC 接口信号的驱动强度。  

此外、根据我们的观察结果和偏差、我们考虑将 RGMII_TX_CLK_DELAM/RGMII_RX_CLK_DELAY 设置为0、即将 TX/RX 设置为与时钟对齐、为此我们在此处写入0x00、令人惊讶的是、100Mbps 工作、但1Gbps 在 U-Boot 中失败。

但我们无法理解的是、将 RGMIICTL 设置为0x0会禁用 RGMII 使能位、PHY 根据数据表中的以下上下文开始在 GMII 模式下运行、而板载接口是 RGMII。  

8.4.1 MAC 接口
DP83867支持通过以下接口连接到以太网 MAC：RGMII、GMII 和 MII。
RGMII 禁用自举(RX_D6)决定 MAC 接口的默认状态。 RGMII 禁用自举
对应于 RGMIICTL 寄存器(地址0x0032)中的 RGMII 使能(位7)。 RGMII 模式时
禁用时、DP83867以 GMII 模式运行。

请在这里稍作说明吗？ 即使 PHY 配置错误、它在 U-Boot 中如何工作？
这可能是因为配置无效/错误、1G 可能无法正常工作。

谢谢和 BR、
Sagar Kadam

您好 Sagar、

为什么要在 GMII 中操作器件？ 您的原理图未针对 GMII 进行配置。 请将  RGMIICTL 寄存 器的 bit [7]保留为1、以继续使用 RGMII 并进行调优、正如您为满足数据表第7.9节中列出的规格所做的那样。

谢谢、

David