[参考译文] DP83867CR：即使未连接电缆、链路状态位和 LED_0 也亮起

更多信息：

寄存器 0x0031 为 0x10b1、因此我向其写入 0

它没有帮助。

当我读回它时、奇怪的是 0、但有一些保留位是“1"和“和 RO、它们现在也是“0"。“。

为什么 PHY 在内部测试模式（地址 0x31 位 7 的起始状态为“1"，“，而、而不是“0"）“）下唤醒？

在连接正常运行模式（而不是内部测试模式）的其他尝试后、我们在连接/断开 LAN 电缆时成功实现了可靠的链路状态。

此外、我们已成功从 CPU (MAC) 发送到外部 PC。

我们还有一个未决问题 — 从 PC 接收到 CPU (MAC) 的数据 — 尚未成功。

尊敬的 Dan：  

CLK_OUT 引脚上的接收和发送时钟是否源自 MAC 接口的 RX_CLK 和 TX_CLK？ 或者它们是否在内部生成？

当存在链路时、它们是从 MDI 线路恢复的时钟。 在链路已建立但没有实际连接的情况下、PHY 可能无法发送正确的时钟频率。  

根据您的信息、似乎内部测试模式会导致即使未连接电缆、链路也能正常工作。  
此外、您的 TX MAC -> PHY -> MDI -> PC 似乎可以正常工作。  
由于接收不起作用、我怀疑这可能是 RGMII 端的时序问题。 您是否尝试过在 PHY 中使用延迟模式、然后更改 PHY 上 RX_CLK 的延迟？
这可以通过访问寄存器 0x32 和 0x86 来实现。  

此外、如果您读取 0x15、是否看到任何 rx_err_cnt 正在上升？

此致、
j

为什么 PHY 在内部测试模式下唤醒？

我尝试了原理图（模式 3）中的配置、还尝试移除 R301、并将 R300 更改为 2.49k Ω（模式 4）。

在这两种情况下、PHY 都会以“内部测试模式“-未连接电缆。 也是启用端口镜像的原因。

在这两种情况下进行寄存器 0x0031=10B1、0x006E=0x88A0

以下是模式 4（黄色 RX_CTRL 引脚）电压的示波器记录、青色/蓝色是 3.3V (VDDIO)

如您所见、电压为 2.6V、因为它应该为 0.783*3.3=2.58v

尊敬的 Dan：  

这是非常奇怪的。 那么、为了进行确认、PHY 始终斜升至内部测试模式？
否则、当 PHY 初始化为正常状态时、能否向我发送 0x6E 和 0x6F 的寄存器内容？
是否对 PHY 进行了任何其他配置 (strap)、或者 MAC 在 PHY 上电时是否驱动这些线路中的任何一条？

最后、当 PHY 进入内部测试模式时、您能否看到复位器件 (0x1F=0x8000) 还是将复位引脚拉至低电平可以解决问题？

此致、
j

是的、PHY 始终斜升至内部测试模式。

我唯一的配置 (strap) 是 RX_CTRL、LED、GPIO - OP 中的原理图所述。
In RGZ (48 引脚 QFN) 在 CPU MAC 接口中只有 RX_D0 和 RX_D2 是相关的、但它们似乎没问题、因为我们按预期获得的 PHY ADDR 为 00000。

当我们通过 0x001f 寄存器 (0x8000 和 0x4000) 复位时，结果相同 — 仍为内部测试模式。

PHY 进入该模式的条件是什么？

物理复位也连接到 CPU（按下它不会解决问题）。 我可以将 PHY 与此复位隔离、但需要进行一些接线（移除串联电阻器）。 会尝试...

我针对原始设计（模式 3）的 RX_CTRL 引脚搭接进行了额外的测量、结果符合预期。
根据模式 3 的数据表、电压应（对于 VDDIO=3.3V）介于 0.7425v 和 0.9372v 之间。 我们得到 0.82V、这是可以的

因此仍然没有说明 PHY 斜升至内部测试模式的原因

我进行了几次重置（使用电路板上的重置按钮，结果始终相同）

以下是示波器读数：Yelllow 为 RX_CTRL、Cyan 为 RESET_N 引脚

以及放大 RESET_N 释放时间周期来进行检查

此外 、我还在数据表中看到  

我检查了 0x006F = 0x0170、因此位 8 为“1"，“，而、而不是“0"，“，这、这是否意味着请求不是来自 RX_CTRL Strap 配置？ 如果是、那么从哪里来？

尊敬的 Dan：  

通常在 RESET 变为高电平后 120ns 对搭接进行采样。  
观察示波器屏幕截图、RX_CTRL 似乎低至约 120ns 标记、这似乎就是它被误配置的原因。

首先、我猜测 MAC/电平转换器以某种方式驱动这条线路并导致这种情况发生。 如果您隔离 RX_CTRL 连接、PHY 是否仍进入测试模式？

此致、
j

我不知道如何隔离信号、但会尝试隔离。

但是根据数据表以及我在 RX_CTRL Strap 配置上面写的内容、这不是问题（寄存器 0xf6[8]不是“0"。“。
我将尝试将 RX_CTRL 配置为模式 0 或模式 1、并查看该位是否更改为“0"，“，以、以确保内部测试模式指示如数据表中所述。

因此、我在数据表中将 RX_CTRL 更改为模式 1（开路，开路）（删除了 R300 和 R301）

示波器显示预期电压低于 10mV（复位前后，因此与实际锁存的位置无关紧要）、如上所示与模式 1 一致。  

寄存器 0x31 = 10B1（照常）-内部测试模式 就像复活了 但现在寄存器 0x6F = 0x0070 也符合预期 — 位 8 现在是“0"</s>“ 这意味着 RX_CTRL 自举无效（模式 1/2、而不是 3/4）。

这意味着之前在模式 3/4 中当  0x6F = 0x0170（位 8 为“1"）“）时、RX_CTRL 搭接正常 — 识别为模式 3/4。

那么、PHY 为什么 会进入内部测试模式呢？

此外、怀疑 LED_0 Strap 配置、因此移除了物理 LED、使 LED_0 保持悬空 — Strap 配置按照预期进入模式 1（无镜像）（只有模式 1 和 3 有效）、但 0x0031 位 7 仍为“1"-“-内部测试模式

尊敬的 Dan：  

发生这种情况时、您最初如何能够将 PHY 恢复到正常工作模式？ 我们正在内部检查、以查看如何启用测试模式。

此致、
j

这就是我们从内部测试模式中恢复的方式 — 由软件团队提供给我：

加载 U-Boot 后、自动协商失败、我们通过检查 PHY 寄存器的默认值开始调试、并发现以下问题：

• 地址 0x0031 处的配置寄存器 4 (CFG4) 未处于默认状态、启用了内部测试模式和端口镜像。
• 地址 0x0016 处的 BIST 控制寄存器 (BISCR) 也未处于默认值、值为 0x3、PCS 环回已启用、寄存器值为 0x3、速度设置为 1000Mbps。

在 Linux 内核中加载驱动程序后、使用寄存器 0x001f=0x8000 手动复位 PHY 并清除每个寄存器 (0x0031 和 0x0016) 后、我们实现了稳定的连接。

在内核中、 我  在配置处理程序中将寄存器 0x0031 和 0x0016 设置为 0。

但是、自动协商完成后、BISCR 寄存器更改为 0x3 值、为解决此问题、我在自动协商完成后再次清除了该寄存器。

 只要链路状态发生变化、就会触发自动协商完成处理程序、因此每次调用处理程序时我都会清除寄存器。

我清除了配置处理程序中的寄存器 0x0031、并且由于寄存器 0x0016 在自动协商后发生了变化、因此每次在驱动程序中调用处理程序时都将其清除。

尊敬的 Dan：  

PCS 环回自动启用是很奇怪的。 这是意外行为、除非驱动程序写入该寄存器、否则不会发生。 我还在实验室中进行了验证、如果 PCS 环回处于开启状态、则链路状态将变为高电平 (0x0016 = 0x0001)、链路状态不会从内部测试模式变为高电平。 因此、以某种方式启用 PCS 环回很可能是您的问题、而不是内部测试模式。 即使在启用测试模式的情况下、PHY 也应正常工作。  

您能否与 SW 团队签入、看看驱动程序是否在初始启动时写入寄存器 0x0016？ 每次自动协商状态发生变化时、Linux 似乎都会写入 BISCR 寄存器。  

请告诉我。  

此致、
j

我将与 SW 团队核实。 但即使加载 uboot（在 Linux 之前）、我们也已经可以看到寄存器 0x0016 = 0x0003。

尊敬的 Dan：  

请让我在软件方面及时了解最新信息。 如果这是自举问题、在执行软件复位 (0x001F = 0x8000) 后、PHY 仍应处于 PCS 环回状态 (0x0016 = 0x0003)。 如果您执行软件复位、但没有向 0x0031 和 0x0016 写入任何值、您可以看到 PHY 是否仍处于此状态？

此致、
j

进行软件复位时、PCS 环回从 0x3 更改为 0x0。

内部测试模式仍然为“1"，“，不、不会更改。

尊敬的 Dan：  

由于软件复位会将寄存器 0x0016 正确复位至 0x0000、因此我怀疑该寄存器没有因硬件 Strap 配置而触发。 因此、我怀疑 SW 以某种方式将 0x3 写入 0x0016 寄存器。  

启用的内部测试模式不会对 PHY 的功能产生任何影响。 我们在内部进行了更多研究、以了解为什么在 RX_CTRL 引脚搭接至模式 3 和 4 的情况下会启用该位。  

我们将随时为您提供最新信息。  

此致、
j

您好、

我们确定了寄存器 0x0016 的问题是由软件写入 0x3 导致的、这一问题现已解决。

但是、在复位 PHY 后、寄存器 0x0031 仍遇到问题（通过将 0x8000 写入寄存器 0x1f 或执行正常的电路板复位）、我们可以观察到值为 0x10B1 输入 0x0031 。
在 Linux 内核中、我们在内的驱动程序中清除此寄存器 dp83867_config_init  函数。此外、在初始化 PHY 之前、我们将 0x1012 写入寄存器 0x0010、在此步骤之后、PHY 在内核中按预期运行。
我们在 U-Boot 中执行了相同的过程、但它不起作用（没有 ping 或 ARP 消息！）、您能否解释为什么会发生这种情况？

不同应用  U-Boot 2016.11 fslc 、也许我们应该使用最新的？

此致、

Wesam

尊敬的 Wesam：

正如我在上一篇文章中所说的、内部测试模式不应该对 PHY 的功能产生任何影响、但我们正在内部进行验证、以了解为什么在 RX_CTRL 自举的模式 3/4 中启用了该功能。 我们将随时为您提供最新信息。  

此外、在初始化 PHY 之前、我们将 0x1012 写入寄存器 0x0010、完成此步骤后、PHY 在内核中按预期运行。

如果您说 PHY 在内核中按预期运行、这是否意味着 PHY 可以 ping 并执行 ARP 消息？

我查看了寄存器 0x0010、结果 0x1012 好像禁用 125MHz 时钟并启用线路驱动器反转：


禁用 125MHz 时钟和反相线路驱动器会影响 PHY 功能、因为原理图中的 MDI 线路似乎没有反转、并且 RGMII 需要 125MHz 时钟。  

此致、
j

您好、

尊敬的 Wesam：

美国办事处在 9 月 1 日假期关闭。 我会在 9 月 2 日美国时间回来的。

此致、

j

尊敬的 Wesam：  

寄存器 0x0010 上的默认值为 0x5048。 位 11 是保留的、更改该位将导致 PHY 功能出现问题。 发生此问题时、您能否检查 LED_0 引脚的电压是否处于模式 0 而不是不同模式？  

此致、
j

关于 LED_0、我尝试物理安装 DS28 并断开（移除）。

对于 LED、复位值为 0x5848 将 0x8000 写入寄存器 0x1f 后 、端口镜像为“启用端口镜像“寄存器 0x31 的位 (0) 为“1"（“(0x10B1)

如果没有 LED、则复位值为 0x5048 将  0x8000 写入寄存器 0x1f 后 、端口镜像为“正常操作“寄存器 0x31 的位 (0) 为“0"（“(0x10B0)

在启动时 硬件复位 使用复位按钮时、 电压为：

无 LED ==>0v (<20mV)：

当 LED => 1.6V/3.3V 时：

放大重置释放

尊敬的 Dan：  

保留位 (0x0010 的位 11) 受 LED_0 引脚的 Strap 配置影响。 由于 LED_0 引脚为 1.6V、这会导致 LED_0 引脚配置为模式 4。 因此、这将使保留位变为高电平。 我们在数据表中有一条注释、说明如何将 LED_0 引脚配置为模式 1 或 3：

请确保 LED_0 引脚约为 0.255 x VDDIO、约为 0.84V。  


之前、客户已使用以下配置来实现此目的：



此致、
j

您好、

移除 LED 后、寄存器 0x10 的值为 0x5048。 在 Linux 中、清除寄存器 0x31 可以解决问题并且一切正常工作、但 Uboot no ping and no ARP 仍然存在问题。 您对此有何建议？ 我们正在使用 U-Boot fslc 2016、是否应该考虑更新到最新版本？

此致、Wesam

尊敬的 Wesam：  

您能否将寄存器信息从 0x00 转储到 0x1F？ 我想知道是否有任何寄存器从 uboot 更改为 Linux 内核。  
您在 ping 和 ARP 上看到的确切错误是什么？
您是否已验证 0x0011 和 0x0016 值与 Linux 内核上的值一致？

此致、
j

您好、

没有特定的错误、ping 和 ARP 都无法正常工作。

在 uboot 上基本网络连接不起作用。

以下是 U-Boot 值与 Linux 值不同的寄存器：

寄存器范围为 0 至 0x1f

 谢谢

尊敬的 Wesam：  

我注意到 uboot 广播半双工和全双工、而 Linux 仅广播半双工。 是否存在可能导致链路接通但未传输数据的双工不匹配？

此外、您能分享一下您所说的“无法正常工作“的屏幕截图吗？ 很难想象在没有任何错误的情况下无法正常工作是什么意思。  

请告诉我。  

此致、
j

Linux：

Uboot：

尊敬的 Wesam：  

感谢您的屏幕截图。  
这可能是一个愚蠢的问题,但是否设置了 MAC 地址? 似乎您仅在发送的屏幕截图中设置 IP 地址。 另外、我检查了 Dan 发布的类似 uboot 屏幕截图、看起来从不设置 MAC 地址：


请告诉我。

此致、
j

是的、设置了 MAC、这是一种从 EEPROM 读取 MAC 地址的机制。

如果 EEPROM 为空、则将使用默认 MAC 地址。

如果未设置 MAC 地址、您应该在执行 ping 命令后立即看到“ethaddr 未设置“。

相同的代码和 U-Boot 版本适用于旧 PHY、内核中也使用相同的 MAC 地址。

尊敬的 Wesam：  

我明白了。  根据寄存器读取、PHY 本身具有一个链路。 PHY 自动协商失败消息是也发生在旧的 PHY 上、还是仅在我们的 PHY 上显示该消息？

如果该消息仅在 PHY 中发出、则可能是 MAC 和 PHY 连接之间的问题。  
您是否尝试将 0x5e1 写入 0x0004 寄存器和 0x0200 写入 0x0009 寄存器、然后通过将 0x1200 写入 0x0000 寄存器重新启动自动协商？

您还能分享该 PHY 的器件树吗？ 我怀疑 MAC 中的驱动程序未正确初始化、导致网络连接出现问题。  

请让我知道您的想法。  

此致、
j

尊敬的 Wesam：  

如果没有 DTS、我想知道 RGMII 延迟是否设置正确。 这可能会导致 MAC 和 PHY 之间出现时序问题、因此 MAC 和 PHY 之间没有通信。  

在这种情况下、您能否尝试在 U-boot 上的 Linux 寄存器中设置相同的寄存器值 0032 和 0086、然后重新启动自动协商（设置 0x0000 寄存器的第 1 至第 9 位）以及之前的寄存器读取？

我正在 u-boot 上确认。 收到团队成员的确认后、我会回复您。  

此致、
j

您好、

很抱歉耽误你的时间。

我将所有 Linux 寄存器值复制到 U-Boot 和强制自动协商、但我们仍然看到相同的问题！

跟进您的最后一条消息：是否有任何关于您正在等待团队成员的 u-boot 确认的更新？

也许有一些应应用于 uboot 上的 phy 驱动程序的修复程序？

谢谢