[参考译文] AM625：不再检测以太网电缆、也未检测到 PHY 芯片的复位。

您好、Alexis、  

xianfen chen 说：

有时、当以太网电缆仍连接到交换机时、Linux-RT (TISDK 09.02)显示以太网接口为 down。

据我所知、在 SDK 09.02 Linux RT 上不存在可导致在 SK-AM62B EVM 上出现此行为的已知问题。 定制设计的电路板启动后是否立即出现此问题、或者链接是否在一段时间后断开？

您的电路板上有多少个以太网接口？ 如果启用了多个接口、是否仅在一个接口上发生此问题？  

发生此问题时、您是否可以共享控制台日志？ (包括启动日志)

[报价用户 id="52392" url="~/support/processors-group/processors/f/processors-forum/1450307/am625-the-ethernet-cable-is-no-more-detected-the-reset-of-the-phy-chip-is-also-not-detected "]

拔下并再次插入电缆时、Linux 下没有检测、LED 仍处于关闭状态。

使用 GPIO 可以在 PHY 芯片组上完成复位、但不能解决该问题。

使以太网链路再次可用的唯一方法是重新启动 AM625板、因为命令"systemctl restart systemd-networkd"无效。

[报价]

您是否尝试过运行"IP link set dev 以便查看链路是否接通？ (其中"Ethernet iface name"是您的以太网接口名称)

-道林

尊敬的 Daolin：

在功能测试期间、我们的定制设计电路板上已经发现了该问题、但不会100%出现该问题。 我们没有重现此问题的特定测试。

在 Linux 和我们的应用程序运行了一段时间之后、我们发现了该问题。

我们有3个以太网接口(AM625上的2个端口)和一个有线 SMSC95xx USB 转以太网适配器。

发生问题时、AM625上仅连接了1个端口、在问题分析期间、我不测试连接另一个端口。

我尝试了 ip link set dev 命令 向上"、但没有任何效果。

我还尝试使用命令"systemctl restart systemd-netword"循环,每30秒在整晚,但问题不会发生。

我没有跟踪日志、因为我已重新放置电路板。 我会在下次出现问题时提供。

是否有办法从 Linux 复位以太网控制器并使 Linux 驱动程序重新启动 PHY 配置？

感谢您的帮助。

Alexis。

尊敬的 Alexis：

xianfen chen 说：

我尝试使用命令"IP link set dev 向上"、但没有任何效果。

只需仔细检查、您就更换了 以太网接口的名称出现此问题？ 例如、"IP link set dev eth0 up"。

dev_here 说：

是否有办法从 Linux 重置以太网控制器并让 Linux 驱动程序重新启动 PHY 配置？

让我和一位同事核实一下这一点。 据我所知、PHY 配置的设置与 Linux 内核启动过程(从 DTS 读取 PHY 属性、根据驱动程序的探测函数设置 PHY 驱动程序等)紧密相关。

如果您再次看到问题、 可以尝试

1.使用"ethtool"检查接口的链路状态 "

2.如果链路状态显示已断开、尝试读取以太网 PHY 寄存器来确定 PHY 是否可能处于不良状态

3.如果有一个 PHY 寄存器来重新启动自协商过程、请尝试启用该功能

此外、您是否尝试过"systemctl status systemd-networkd"以在发生问题时检查网络服务的状态？

-道林

尊敬的 Daolin：

1、ethtool 没有提出任何问题,链接已连接。

2.是否可以执行 ethtool 命令。 是否与断开并重新连接以太网电缆相同？

3.重新启动 systemd-networkd 不起作用,问题仍然存在。

我再次遇到该问题、但行为不同。

物理层上仍然没有数据交换、物理以太网端口上的 LED 不闪烁、但链路状态连接和断开连接提升到 Linux 内核。 当以太网端口 eth0和 eth1上的电缆插入和拔出时、Linux 会检测到链路的接通和断开。

我使用 ethtool 从接口 eth0和 eth1.e2e.ti.com/.../dump_5F00_eth1.dump.txt 转储了寄存器

您会注意到应该是寄存器 BMCR 的偏移0不包含预期数据。

Datasheet : https://www.ti.com/lit/ds/symlink/dp83867ir.pdf?ts = 1734336387200&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FDP83867IR

您能否确认来自 TISDK 09.02的 ethtool 是否按预期工作？

您能否提供在 Linux -RT (TISDK 09.02)上工作的 Linux 工具来转储 PHY 组件 DP83867IR 的寄存器？

您能否确认勘误表 i2329 MDIO：MDIO 接口损坏(CPSW 和 PRU-ICSS)不是问题的根源？

此致、

Alexis。

尊敬的 Alexis：  

Unknown 说：

2. 如果链路状态显示已关闭、请尝试读取以太网 PHY 寄存器以确定 PHY 是否可能处于不良状态

xianfen chen 说：

您能否提供 ethtool 命令来执行该命令。 断开并重新连接以太网电缆是否相同？

xianfen chen 说：

您能否提供一个在 Linux -RT (TISDK 09.02)上工作的 Linux 工具、该工具可以转储 PHY 组件 DP83867IR 的寄存器？

如果我正确地理解了您的问题、这不是 ethtool 命令、要读取以太网 PHY 寄存器、需要使用以太网 PHY 数据表来确定寄存器地址字段和 phytool 命令。 有关  如何使用 phytool 的更多详细信息、请参阅 e2e.ti.com/.../faq-how-to-read-and-write-ethernet-phy-registers-using-a-linux-terminal。

xianfen chen 说：

您能否确认勘误表 i2329 MDIO：MDIO 接口损坏(CPSW 和 PRU-ICSS)不是问题的根源？

根据勘误表的详细信息、应该有一种权变措施可以使用 MDIO 位拆/手动模式来解决 MDIO 接口损坏问题。 在 Linux SDK 中、应该已经实现了该模式。  在我们确认 PHY 寄存器的预期值是否存在问题(即是否是 MAC 侧问题或 PHY 侧问题)之前、我不知道勘误表是否是问题的根源。  

请尝试使用 phytool 读取 PHY 寄存器(至少读取 BMCR 寄存器的内容)。

-道林

尊敬的 Daolin：

我编译并安装了您在 github.com/.../master 上提供的 MDIO-tool 二进制文件。

我转储 Eth1以太网接口的所有寄存器、它有问题。

e2e.ti.com/.../mdio_5F00_registers_5F00_eth1.log

如果您在转储中看到一些问题、请告诉我。

通过比较工作板和有问题的板之间的日志、我看到在一些偏移处存在差异：

寄存器05 ANLPAR = 0x4de1
B15 B14 B13 B12 B11 B10 B09 B08 B07 B06 B05 B04 B03 B02 B01 B00
 0  1  0 0    1  1  0 1 1 1 1 1          0 0  0 0 1       

寄存器06 ANER = 0x0067
B15 B14 B13 B12 B11 B10 B09 B08 B07 B06 B05 B04 B03 B02 B01 B00
 0 0 0      0 0 0     0 0    0 0 0      1 1  0 0 1 1 1         

REG 08 ANNPRR = 0x000问题？
B15 B14 B13 B12 B11 B10 B09 B08 B07 B06 B05 B04 B03 B02 B01 B00
 0 0 0      0 0 0     0 0 0      0 0 0     0 0 0      0 0 0     0

REG 10 STS1 = 0x000问题？
B15 B14 B13 B12 B11 B10 B09 B08 B07 B06 B05 B04 B03 B02 B01 B00
 0 0 0      0 0 0     0 0 0      0 0 0     0 0 0      0 0 0     0

寄存器14 BISCR = 0x1000
B15 B14 B13 B12 B11 B10 B09 B08 B07 B06 B05 B04 B03 B02 B01 B00
 1 0    0 0  0 0 0       0 0 0      0 0 0     0 0 0      0 0 0   

寄存器19 ISR 0x0000
B15 B14 B13 B12 B11 B10 B09 B08 B07 B06 B05 B04 B03 B02 B01 B00
 0 0 0      0 0 0     0 0 0      0 0 0     0 0 0      0 0 0     0

您能给我命令行 MDIO-TOOL 来重新启动自动协商吗？

此致、

Alexis。

Alexis。

尊敬的 Alexis：  

dev_here 说：

我编译并安装了您在 github.com/.../master.

上提供的 MDIO-tool 二进制文件

消息流  phytool 本操作更简单、因为 SDK 中应该已经提供了该文件(请参阅 https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1164499/faq-how-to-read-and-write-ethernet-phy-registers-using-a-linux-terminal 的 phytool 部分)  

xianfen chen 说：

如果您在转储中发现某些问题、请告诉我。

让我将有关 PHY 转储的问题重定向到 TI 以太网 PHY 团队、因为他们将能够更好地分析 PHY 寄存器的结果。 由于转移、请预计会有延迟。

-道林

尊敬的 Alexis：  

我将浏览您提供的寄存器日志、并从 PHY 端逐步解决该问题。 从寄存器转储中、我可以看到自协商过程已完成、并且在100Mbps 全双工速度下建立了有效链路。

此日志是否在 无法检测到电缆/链路应该断开或处于正常工作状态的阶段记录？ 您是否尝试以不同于100Mbps 的速度建立链路？

当系统的行为与上述情况类似时、在断开/重新连接电缆时未建立链路、我们还可以通过切换寄存器0x00的位9尝试重新启动自动协商、以防发生某种情况、导致自动协商在电缆重新连接时自动重新启动。  

xianfen chen 说：

REG 10 STS1 = 0x000问题？

日志中的寄存器地址似乎采用十进制、而不是十六进制。 这意味着日志中的 REG 10实际上对应于寄存器0xA、而不是0x10、而寄存器0x10将是日志中的 REG 16。

此致！

Vivaan  

尊敬的 Vivaan：

该问题的背景是、虽然连接的电缆和 AM625电路板正常工作、但我们的 PC 检测到 AM625的链路 eth1不再通信。 但在以太网电缆上没有任何物理操作。

由于我们的 MOXA 开关似乎会产生100Mbs 的负值、因此求负的值为1000Mbp。

当电缆连接到交换机且检测到链路、但没有可用数据时、已捕获寄存器日志。  只有一个 LED 为绿色、Linux 显示 Linux 启动、但链路上没有数据交换。

另一次出现此问题、但以太网端口的两个 LED 均已关闭、并且在断开/重新连接电缆时、Linux 不检测到链路接通/断开。

日志文件以十进制格式显示寄存器偏移是真的、MDIO-TOOL 二进制文件仅接受十进制寄存器地址。

因此、十进制偏移10位于十六进制中的0x0A、对应于 DP83867IR 数据表中的寄存器 STS1。

那么、设置为0x0000表示本地和远程接收器不正常、这是正确的吗？

什么能够解释链路正常工作、并且链路立即处于不良状态且协商状态仍然正常。 你有什么想法吗？

请告诉我。

此致、

Alexis。

尊敬的 Alexis：  

感谢您的解释。 您到底是如何检查数据传输/接收的？ 您是否正在从 PC 端发送数据包、正在尝试对 PHY 执行 ping 操作？  

我认为运行反向环回测试来验证 MDI 数据路径的完整性将是一个很好的步骤。 这可通过将寄存器0x16的位5：2设置为1000b 来实现。 使用该设置、在 MDI 侧接收到的所有数据都将环回到 MDI 侧。 在此基础上、您可以配置 PC 以发送一些数据包、并查看是否接收到相同的数据包。  

xianfen chen 说：

因此、设置为0x0000的值表示本地和远程接收器不正常、是不是正确？

此寄存器仅适用于1000Mbps 连接、因为您的连接解析为100Mbps 的速度、因此此寄存器不代表链路的状况。

[报价用户 id="52392" url="~/support/processors-group/processors/f/processors-forum/1450307/am625-the-ethernet-cable-is-no-more-detected-the-reset-of-the-phy-chip-is-also-not-detected/5576631 #5576631"]

另一次出现此问题、但以太网端口的两个 LED 均已关闭、并且在断开/重新连接电缆时、Linux 不检测到链路接通/断开。

[报价]

我想澄清一下这种行为是如何重复的第二次 、就像你在上面所说的。 根据我的理解、PHY 最初通过 LED 和 Linux 终端连接到 PC 端。 然后、断开并重新连接了电缆、之后 Linux 和 LED 上的链路始终处于断开状态。 这是正确的、还是您观察到了不同的行为？

此致！

Vivaan

尊敬的 Vivaan：

在 PC 端有一个使用工业协议对链路进行监控的软件。 一旦数据未交换、就会发出警报、并且监控软件会显示问题。

我还在 PC 和电路板上执行了一些 ping 操作、但没有成功。

当前电路板已重启、以允许我们的验证团队在电路板上执行所有其他测试。

一旦问题再次出现、我将进行反向环回测试。

关于您关于不同行为的最后一个问题:

我们有两种测试环境：

• 在研发团队使用的第一个环境中、发现了这个问题、但行为是以太网端口 LED 指示灯从卡和交换机一直熄灭。 而且网卡上的 Linux 没有检测到以太网电缆的连接/断开、使链路始终断开、没有网络流量。 我没有在该环境中进行寄存器转储。

• 在第二个测试环境中、行为是当连接电缆时、以太网端口 LED 灯始终亮起、当由 Linux 检查时、线路处于启动状态、但没有网络流量。 我在该环境中转储了寄存器。

此致、

Alexis。

尊敬的 Alexis：  

是否也有可能获得您描述的第一个环境的寄存器转储？ 这可能会告诉我们在这种情况下 PHY 根本无法与链路伙伴建立链路的原因。  

dev_here 说：

一旦问题再次出现、我将立即执行反向回送测试。

我们 应 在第二个环境中执行反向环回测试、因为它已经建立了链路。  

此致！

Vivaan

尊敬的 Vivaan：

我不在办公室直至1月6日。

我将在返回时执行寄存器转储和测试。

圣诞快乐,新年快乐!

此致、

Alexis。

尊敬的 Alexis：  

当然,你的假期也是快乐的!

我们期待着这种行为得到解决。  

此致！

Vivaan

尊敬的 Alexis：  

新年快乐！

从 PHY 的角度来看、除了访问和写入您已拥有的寄存器的方法之外、我们不需要任何其他工具来进行调试。  

我也认为没有任何工具来窥探自协商过程。 这是两个器件之间信息交换的一个相当复杂的过程。 我认为目前 PHY 寄存器应该为我们提供有关自协商过程、其状态和所遇到的任何错误的足够信息。  

此致！

Vivaan