[参考译文] DP83869HM：PHY 检测不一致

尊敬的  Madhusankar：

故障率是多少、故障是否仅限于通过 MDIO 进行驱动器绑定/PHY 检测？

如果不同引导之间的 DTS 配置没有差异、可能会想到以下问题：

1. PHY 未正常供电、导致 MDIO 在引导时无响应。
2. PHY 通电、PHY 地址搭接引脚电压存在一些裕度、导致两次启动之间的 PHY 地址不同。

为了确认 (1)、可以在通过/未通过的情况下执行这些外设引脚检查：

• 如果 PHY 处于活动状态、则 RBIAS 电阻器两端的电压≈1V
• XI 时钟输入处于活动状态、满足 25M+/–100ppm 要求
• RX_CLK 是有效输出（频率可能会有所不同）

要确认 (2)、对于通过/失败的情况、可以在启动时测量 RX_D0 和 RX_D1 引脚上的电压。
RXD0 电压是否≈ 0.165 x VDDIO？
RXD1 电压是否 ≈0V？

谢谢您、
Evan

尊敬的 Evan：

故障率是多少、故障是否仅限于通过 MDIO 进行驱动器绑定/PHY 检测？

答案：Uboot 中有 2 个 10 检测失败、所有引导我可以通过 MDC/MDIO 线路观察到一些活动、即使它未检测到。

如果不同引导之间的 DTS 配置没有差异、可能会想到以下问题：

1. PHY 未正常供电、导致 MDIO 在引导时无响应。

答案：下面给出了 PHY 上电序列、其如下所示（根据数据表中的建议）上电：

1. PHY 通电、PHY 地址搭接引脚电压存在一些裕度、导致两次启动之间的 PHY 地址不同。

为了确认 (1)、可以在通过/未通过的情况下执行这些外设引脚检查：

• 如果 PHY 处于活动状态、则 RBIAS 电阻器两端的电压≈1V

答案：是的、RBIAS 电阻器两端的电压为 1V。

• XI 时钟输入处于活动状态、满足 25M+/–100ppm 要求

回答：是的、时钟输入为 25MHz。

• RX_CLK 是有效输出（频率可能会有所不同）

答案：是的、即使 PHY 未检测到、也始终观察到 2.5MHz 时钟。

要确认 (2)、对于通过/失败的情况、可以在启动时测量 RX_D0 和 RX_D1 引脚上的电压。
RXD0 电压是否≈ 0.165 x V DDIO？

答案：复位时、RXD0 上的电压为 0.555V

RXD1 电压是否 ≈0V？

ANS =复位时 RXD1 处的电压为 0.34V。

请在随附的电路板中找到所附的电路、以供您查看、如果我们的以太网 PHY 后续电路中存在任何问题、请告知我们。

此外、即使 PHY 正在检测到链路、也未发生链路建立、并且当我们将以太网电缆连接到以太网端口时、没有 LED 闪烁/发光。 我们根据“图 7-16 中的模式 0、将 LED 引脚连接到 Magjack 连接器。 配置 (Strap) 连接示例“。

e2e.ti.com/.../DP83869HM_2D00_Circuit.pdf

此致、

Madhusankar

尊敬的 Madhusankar：

RXD1 电压高于模式 0 的 Vmax 限值、这可能会导致 PHY 地址在某些下电上电时配置为意外的值。 是否可以在启动时使用 RXD1 自举电压= 0V 进行测试、并记录故障率来检测 PHY？

谢谢您、
Evan

尊敬的 Evan：

我们已经将 PHY 地址搭接引脚设置为 PHY AD？[0：3]= 0111、现在一直在进行 PHY 检测。  

但我还有一个关于 OPMODE 的搭接引脚的问题。

在 DP83869 数据表的修订版本 C 中、指出对于两级配置 (strap) 表、对于模式 0、Rhi 应打开、Rlo 应使用 2.49k Ω 连接到 GND。  

但在版本 D 数据表中、在相同的两级搭接中、提及的是将 Rlo 和 Rhi 保持为“开路“。

但在“修订版本数据表“的修订历史记录中指出“四级配置 (strap) 模式 0 Rlo 建议从 2.49k 更改为开路“、但四级配置 (strap) 表没有任何更改。  

能否请您说明 MODE0 和两级 Strap 配置模式的 MODE1 的正确 Rhi 和 Rlo 电阻值/条件？

此致、

Madhusankar

尊敬的  Madhusankar：

很抱歉、此处的混淆、修订历史记录说明指的是 2 级配置 (strap) 表、而不是 4 级表。 之所以进行此修订、是因为由于 PHY 内部的 PD 电阻器、Strap 配置引脚上通常不需要 PD 电阻器。 如果您的开路/开路情况下、复位时产生 0.34V 的电压、那么在复位/电源期间似乎有其他组件（或 MAC）在加载引脚。

为避免这种情况、可以在 PHY 首先通电（在 MAC 之前）的情况下进行测试。 如果无法实现此电源序列、建议在引脚上使用 2.49k PD、从而防止负载效应改变 PHY 配置 (strap) 值。

谢谢您、
Evan

尊敬的 Evan：

我随附了更新后的原理图、其中更改了电路中的配置 (strap)。 如果您对原理图有任何反馈或建议、敬请告知。

但是、我们能够建立 100Mbps 的链路、但在动态连接中不能建立 1000Mbps 的链路、但在静态 IP 连接中、我们能够成功建立 1000Mbps 的链路、请指导我们为什么这样做？  

e2e.ti.com/.../DP83869_2D00_Circuit_2D00_updated.pdf

此致、

Madhusankar

尊敬的  Madhusankar：

原理图连接看起来良好、我没有看到任何会导致此 1G 链路问题的问题。

对于以下情况、您能否分享 PHY 寄存器转储：

-带 1G 链路建立的静态 IP 配置
-具有 1G 链路故障的动态 IP 配置

如果两个设置之间唯一的区别是 IP 配置方法、则我的假设是某些地址解析 (DHCP...) 线路上的数据包会干扰启动时的自动协商。

对于快速测试、您是否会在重新启动自动协商 (0x0[9]=“1")“）时看到失败的情况下建立链路？  

两个 PHY 上强制速度为 1G 是否允许建立链路/通信？

谢谢您、
Evan

尊敬的 Evan：

  请参阅随附的从静态和动态 IP 配置尝试中获得的寄存器读数、以供您参考。为了启用自动协商、我们尝试将寄存器 0x0 (BMCR) 的第 9 位设置为“1"；“；但是、位值未按预期更改。 为了进一步研究、我们随后通过设置 BMCR 的第 15 位使 PHY 复位生效。 复位后、我们再次尝试将第 9 位设置为高电平、但该值仍然保持不变、并且未发生链路建立。
为清楚起见、我们随附了一个快照、演示了我们对寄存器进行写入所遵循的过程。

e2e.ti.com/.../reg_5F00_dump_5F00_dynamic.txte2e.ti.com/.../reg_5F00_dump_5F00_static.txt

此致、
Madhusankar SP

尊敬的 Evan：

我们在硬件中遇到了一些问题、原因是 Magjack 连接器接地不正确。 现在纠正该问题后,出现 1G 链路。但自动协商未关闭。意味着在关闭自动协商并将速度设置为  100Mbps 后,链路不会建立。如果我使用 100Mbps 集线器/交换机,则将自动协商关闭,可以更改速度。

此致、
Madhusankar SP

尊敬的  Madhusankar：

很高兴看到自动协商功能正常。

在 PHY 上禁用自动协商功能还需要链路伙伴禁用自动协商功能并强制实现相同的速度。 您能否确认您正在使用的链路伙伴以及为强制速度设置的配置？

谢谢您、
Evan

尊敬的 Evan：

感谢您的支持。我们还有两个额外的以太网 PHY、它们共用一条通用 MDC/MDIO 总线、但每个 PHY 都有一条单独的复位 GPIO 线路。 我们正在评估这种共享 MDC/MDIO 配置中 PHY 的复位要求。

在测试期间、当配置了专用 MDC/MDIO 接口时、可以成功检测到两个 PHY。 但是、当两个 PHY 都连接到共享 MDC/MDIO 总线时、都未检测到这两个 PHY。

您能否澄清在将多个 PHY 与共享 MDC/MDIO 结合使用、但使用单独的复位控制时、建议的复位时序或限制。

此致、
Madhusankar SP

尊敬的 Evan：

这两个 PHY 共享 MDC/MDIO、我们在 SGMII 模式下使用。

此致、
Madhusankar SP

尊敬的  Madhusankar：

主要约束条件是 PHY 地址搭接 — 每个 PHY 必须具有一个唯一的 PHY 地址、该地址通过 RX_D0 和 RX_D1 引脚搭接、以便 MAC 能够在共享总线上区分它们。

每个 PHY 的 DTS 条目需要与每个唯一的 PHY 地址相匹配。

谢谢您、
Evan

尊敬的 Evan：

我们将对每个 PHY 使用唯一的 PHY 地址。请查看以下 DTS 设置和 PHY 地址。此处、GEM1 具有专用的 MDC/MDIO。

PHY 1 = 0001

PHY 2 = 0011

PHY3 = 1111

&gem1｛
    PHY 模式=“RGMII-id"；“；
    状态=“正常“；
    phy-handle =<&phy1>；
    phy1：PHY@1｛
        reg =<1>；
        兼容=“Ethernet-phy-IEEE802.3-C22"；“；
        RX-INTERNAL-DELAY-ps =<2000>；
        tx-internal-delay-ps =<2000>；
    }；
}；

&gem2｛
    PHY-MODE =“SGMII"；“；
    状态=“正常“；
    phy-handle =<&phyf>；
    PHY-RESET-GPIO =<&GPIO 81 1>；
    phyf：PHY@f｛
        reg =<0xF>；
        兼容=“Ethernet-phy-IEEE802.3-C22"；“；
        RX-INTERNAL-DELAY-ps =<2000>；
        tx-internal-delay-ps =<2000>；
    }；
    phy3：PHY@3｛
        REG =<0x3>；
        兼容=“Ethernet-phy-IEEE802.3-C22"；“；
        RX-INTERNAL-DELAY-ps =<2000>；
        tx-internal-delay-ps =<2000>；
    }；

}；

&gem3｛
    状态=“正常“；
    PHY-MODE =“SGMII"；“；
    phy-handle =<&phy3>；
}；


此致、
Madhusankar SP

尊敬的  Madhusankar：

在启动期间、所有三个 PHY 是否同时上电或复位？ 请确认是否遵循了建议的复位序列：

是否仅在引导期间的 PHY 检测出现问题？ 您是否能够 分别通过 phytool 或其他实用程序访问 PHY 寄存器？ 我想确认这是否是 PHY 运行状况的 H/W 问题、或 SoC 状态机正确检测 PHY 的某种时序要求。

谢谢您、
Evan

尊敬的 Evan：

非常感谢您现在的支持、所有 PHY 都能在轮询模式下正常工作。但在配置中断模式时、无法看到崩溃打印。ALS 请找到器件树设置、因为所有 PHY 相同的崩溃都在观察。

[ 2025年07月15日 10：37：54][  21.798104]审计：type=1327 审计 (1709054777.744：2)：proctitle=“(systemd)“
[IRQ10：37：55][22.885989] 2025年07月15日  56：无人关心（尝试使用“irqpoll"选项“选项引导选项引导）
2025年07月15日 10：37：56][22.892701]  CPU：0 PID：741 通信：systemd 未污染 6.6.40-Xilinx g0b36ba42be64 #1
[ 2025年07月15日 10：37：56][  22.900447]硬件名称：xlnx、zynqmp (DT)
2025年07月15日 10：37：56][22.904623]  呼叫跟踪：
2025年07月15日 10：37：56][22.907061]  dump_backtrace+0x90/0xe8  
2025年07月15日 10：37：56][22.910732]   SHOW_STACK+0x18/0x24
2025年07月15日 10：37：56][22.914048]   dump_stack_lvl+0x48/0x60
2025年07月15日 10：37：56][22.917711]   dump_stack+0x18/0x24
2025年07月15日 10：37：56][22.921027]   __report_bad_IRQ+0x38/0x120
2025年07月15日 10：37：56][22.924950]   note_interrupt+0x310/0x360
2025年07月15日 10：37：56][22.928786]   Handle_IRQ_EVENT+0xd8/0xe8
2025年07月15日 10：37：56][22.932623]   Handle_fasteoi_IRQ+0xb0/0x284
2025年07月15日 10：37：56][22.936720]   generic_handle_domain_IRQ+0x2C/0x44
[Zynq 2025年07月15日 10：37：56][  22.941347] Zynq_gpio_irqhandler+0xa0/0x16c
2025年07月15日 10：37：56][22.945617]   generic_handle_domain_IRQ+0x2C/0x44
[GIC_HANDLE_IRQ+0x6C/0x9C   。2025年07月15日 10：37：56][22.950244] GIC_HANDLE_IRQ+0x6C/0x9C
2025年07月15日 10：37：56][  22.953907] CALL_ON_IRQ_STACK+0x24/0x4c
2025年07月15日 10：37：56][22.957830]   Do_interrupt_handler+0x80/0x84
2025年07月15日 10：37：56][22.962014]   el0_interrupt+0x50/0xd8
2025年07月15日 10：37：56][  22.965590] __el0_IRQ_HANDLER_COMMON+0x18/0x24
2025年07月15日 10：37：56][22.970121]   el0t_64_IRQ_HANDLER+0x10/0x1c
2025年07月15日 10：37：56][22.974218]   el0t_64_IRQ+0x190/0x194
2025年07月15日 10：37：56][22.977794]  处理程序：
[IRQ_DEFAULT_PRIMARY_HANDLER 2025年07月15日  线程[<00000000a58e1e22>] phy_interrupt ([IRQ_DEFAULT_PRIMARY_HANDLER 线程[<00000000a58e1e22>] phy_INTERRUPT)
[IRQ 10：37：56][22.989564]  禁用 2025年07月15日#56


器件树中
================
&gem2｛
    PHY-MODE =“SGMII"；“；
    状态=“正常“；
    phy-handle =<&phyf>；
    PHY-RESET-GPIO =<&GPIO 81 1>；
}；

&gem3｛
    状态=“正常“；
    PHY-MODE =“SGMII"；“；
    phy-handle =<&phy3>；
    phy3：PHY@3｛
        REG =<0x3>；
        兼容=“Ethernet-phy-IEEE802.3-C22"；“；
        TI、工作模式=<0x06>；
        RX-INTERNAL-DELAY-ps =<2000>；
        tx-internal-delay-ps =<2000>；
        Interrupt-parent =<&GPIO>；
        中断=<79 8>；
    }；
    phyf：PHY@f｛
        reg =<0xF>；
        兼容=“Ethernet-phy-IEEE802.3-C22"；“；
        TI、工作模式=<0x06>；
        RX-INTERNAL-DELAY-ps =<2000>；
        tx-internal-delay-ps =<2000>；
        Interrupt-parent =<&GPIO>；
        中断=<28 8>；
    }；


}；

&gem1｛
    PHY 模式=“RGMII-id"；“；
    状态=“正常“；
    phy-handle =<&phy1>；
    phy1：PHY@1｛
        reg =<1>；
        兼容=“Ethernet-phy-IEEE802.3-C22"；“；
        RX-INTERNAL-DELAY-ps =<2000>；
        tx-internal-delay-ps =<2000>；
        Interrupt-parent =<&GPIO>；
        中断=<78 8>；
    }；
}；


此致
Madhusankar SP

尊敬的  Madhusankar：

请尝试在启用 irqpoll 选项的情况下引导。 系统引导是否失败、或者它只禁用 IRQ 并且仍然能够运行以进行链路/通信？

谢谢您、
Evan

尊敬的 Evan：

我已尝试在 启用 irqpoll 选项的情况下引导、系统在没有崩溃打印的情况下完全引导。但没有发生链路通信。



此致、
Madhusankar SP

尊敬的 Madhusankar：

由于您的系统引导和轮询模式下的链接功能之前有情况、您能否在通过/失败的情况之间共享寄存器转储以便进行比较？ 这将有助于找出每种情况之间的任何 PHY 配置差异。

我没有遇到中断模式失败的情况 — 是否可以查看是否从驱动程序接收到所需的中断条件？

谢谢您、
Evan

尊敬的 Evan：

这只是为了澄清一下、在器件树中省略了以下属性时、便会出现这种通过的情况：

Interrupt-parent =<&GPIO>；

中断=<78 8>；

请您确认一下、这是否与您所说的一致 轮询模式 、或者您是否建议使用引导 irqpoll内核参数？

此外、在以下哪些情况下、您会建议转储寄存器以进行进一步分析？

此致
Madhusankar

尊敬的  Madhusankar：

我指的是：

1) 设备树中省略了中断属性的传递大小写
2) 启用 irqpoll 参数的失败案例

在每种情况下共享寄存器转储将有助于隔离可能的寄存器配置问题、以调试 (2) 中的故障情况。

谢谢您、
Evan

您好 Evan。

请找到两种失败情况的寄存器转储并传递 case.e2e.ti.com/.../pass_5F00_case.txte2e.ti.com/.../FAIL_5F00_CASE.txt

尊敬的 Madhusankar：

我在两个转储中都看到、PHY 的配置正确、链路接通。 配置之间的主要区别可以在寄存器 0x12（针对中断轮询模式启用中断）中看到。 从 PHY 的角度来看、我预计这两种情况都会出现任何通信故障。

存在一些与中断相关的 SoC 状态机依赖项。 您能否打开一个针对 SoC 的新主题、以对此日志提供调试支持？

[21.798104]  audit: type=1327 audit(1709054777.744:2)：proctitle=“(systemd)“
[IRQ10：37：55][22.885989] 2025年07月15日  56：无人关心（尝试使用“irqpoll"选项“选项引导选项引导）
2025年07月15日 10：37：56][22.892701]  CPU：0 PID：741 通信：systemd 未污染 6.6.40-Xilinx g0b36ba42be64 #1
[ 2025年07月15日 10：37：56][  22.900447]硬件名称：xlnx、zynqmp (DT)
2025年07月15日 10：37：56][22.904623]  呼叫跟踪：
2025年07月15日 10：37：56][22.907061]  dump_backtrace+0x90/0xe8  
2025年07月15日 10：37：56][22.910732]   SHOW_STACK+0x18/0x24
2025年07月15日 10：37：56][22.914048]   dump_stack_lvl+0x48/0x60
2025年07月15日 10：37：56][22.917711]   dump_stack+0x18/0x24
2025年07月15日 10：37：56][22.921027]   __report_bad_IRQ+0x38/0x120
2025年07月15日 10：37：56][22.924950]   note_interrupt+0x310/0x360
2025年07月15日 10：37：56][22.928786]   Handle_IRQ_EVENT+0xd8/0xe8
2025年07月15日 10：37：56][22.932623]   Handle_fasteoi_IRQ+0xb0/0x284
2025年07月15日 10：37：56][22.936720]   generic_handle_domain_IRQ+0x2C/0x44
[Zynq 2025年07月15日 10：37：56][  22.941347] Zynq_gpio_irqhandler+0xa0/0x16c
2025年07月15日 10：37：56][22.945617]   generic_handle_domain_IRQ+0x2C/0x44
[GIC_HANDLE_IRQ+0x6C/0x9C   。2025年07月15日 10：37：56][22.950244] GIC_HANDLE_IRQ+0x6C/0x9C
2025年07月15日 10：37：56][  22.953907] CALL_ON_IRQ_STACK+0x24/0x4c
2025年07月15日 10：37：56][22.957830]   Do_interrupt_handler+0x80/0x84
2025年07月15日 10：37：56][22.962014]   el0_interrupt+0x50/0xd8
2025年07月15日 10：37：56][  22.965590] __el0_IRQ_HANDLER_COMMON+0x18/0x24
2025年07月15日 10：37：56][22.970121]   el0t_64_IRQ_HANDLER+0x10/0x1c
2025年07月15日 10：37：56][22.974218]   el0t_64_IRQ+0x190/0x194
2025年07月15日 10：37：56][22.977794]  处理程序：
[IRQ_DEFAULT_PRIMARY_HANDLER 2025年07月15日  线程[<00000000a58e1e22>] phy_interrupt ([IRQ_DEFAULT_PRIMARY_HANDLER 线程[<00000000a58e1e22>] phy_INTERRUPT)
[IRQ 10：37：56][22.989564]  禁用 2025年07月15日#56[/报价]

我不清楚此中断失败的条件。

谢谢您、
Evan