[参考译文] PROCESSOR-SDK-J784S4：启用 DHCP 时无法获取动态 IP

Doredla Sudheer Kumar 敬请回答上述问题。

提前感谢

您好！

静态 IP 配置是否成功 ping 通？ 运行 ping 时检查 CPSW 统计信息。
此外、通过连接到 PC、检查数据包是否从 Broadcom PHY 发送到对等端、并运行 Wire-shark 以捕获数据包。

您是否在此处将主 CPSW2G 与使用本机 Linux 驱动程序的 Broadcom PHY 配合使用？

此致、
Sudheer

您好！  
感谢您的立即响应。

是的、ping (ping 其自己的 IP)成功进行了静态 IP 配置。  将卡扣安装在下方。

以下是检查 cpsw 统计信息的命令吗？

LS /sys/class/net/eth1/statistics

当然、会尝试使用 wire-shark、并在此处进行更新。

是的、我使用的是 main cpsw2g 并使用本机 Broadcom.c Linux 驱动程序。

您好！

Unknown 说：

是的、ping (ping 其自己的 IP)成功配置了静态 IP。  在下面附加捕捉。

感谢您的确认。

以下是检查 cpsw 统计信息的命令吗？

LS /sys/class/net/eth1/statistics

否 您可以使用 ethtool 获取 CPSW 端口统计信息。

# ethtool -S eth1.

此外、您是否可以通过在 DHCP 网络中连接端口在下面运行来进行检查。

# dhclient eth1

如果上述操作不起作用、您能否检查网络配置。 请参阅下面的。
https://askubuntu.com/questions/891694/systemd-networkd-demon-does-not-start-the-dhcp-client
https://unix.stackexchange.com/questions/319740/use-dhcp-on-eth0-using-command-line

此致、
Sudheer

嗨@Doredla Sudheer Kumar 
你能回答上述问题吗?

提前感谢、

Swedha R

您好！

从 CPSW 统计信息转储中、我可以看到外部端口上接收的数据包是广播和多播。
由于 ALE、多播数据包会被丢弃。 这表示没有 ALE 条目与接收到的数据包的多播地址相匹配。
只有广播包被发送到主机端口、主机端口被传输到应用程序。


此外、我还会将端口传输中的错误视为载波侦听错误。 这似乎是 MAC 到 PHY 信号检测中的问题。

您似乎正在 ping 本地 IP。 它将始终成功、因为网络堆栈本身将响应请求。

root@j784s4-evm：/opt/edgeai-gst-apps ping 192.168.0.2
Ping 192.168.0.2 (192.168.0.2)：56个数据字节
来自192.168.0.2的64字节：SEQ=0 TTL=64时间=0.094ms
来自192.168.0.2的64字节：SEQ=1 TTL=64时间=0.043ms
来自192.168.0.2的64字节：seq=2 TTL=64时间=0.039ms


您能否确认 RMGII 引脚多路复用器是否与 TI SDK 相同？

此外、RGMII 延迟是否已正确配置、有关更多详细信息、请参阅以下常见问题解答。 另请向您的硬件团队了解相同的信息。
e2e.ti.com/.../faq-tda4vm-how-to-configure-rgmii-clock-delay-on-j7-devices

此外、您是否能够检查您的原理图是否已由 TI 审核。 如果没有、请让 TI H/W 团队审查。

此致、
Sudheer

尊敬的 Sudheer：

感谢您的响应。

Unknown 说：

从 CPSW 统计数据转储中、我可以看到外部端口上收到的数据包是广播和多播。
由于 ALE、多播数据包会被丢弃。 这表示没有 ALE 条目与接收到的数据包的多播地址相匹配。
仅将广播数据包发送到主机端口、主机端口传输到应用程序。

如何才能看到 ALE 条目？ 因为我已经尝试从目录/sys/kernel/debug/..but 找到它、所以没有相关的条目或文件夹。  
以及如何确认广播数据包转发正常？ 我有一个疑问、那就是为什么即使我们没有做任何事情、当我们尝试仅仅读取统计数据时、计数器值也会增加(例如 TI 载波检测错误)。

Unknown 说：

在 MAC 到 PHY 信号检测中似乎存在问题。

我是否需要在 CPSW 驱动程序中执行任何其他软件配置、或者是否需要任何其他配置才能解决此问题？

Unknown 说：

您似乎正在 ping 本地 IP。 它将始终成功、因为网络堆栈将自行响应请求。

感谢大家澄清一下。

Unknown 说：

您能否确认 RMGII 引脚多路复用器是否与 TI SDK 相同？

是的、我已交叉确认。 一切都与 TI SDK 相同。

Unknown 说：

此外、RGMII 延迟是否配置正确、请参阅以下常见问题解答了解更多详细信息。 另请向您的硬件团队核实相关信息。

我介绍了常见问题解答、我们在器件树中将 phy-mode 配置为 RGMII-rxid。 但我们没有在其中添加 eny Rx 内部延迟节点。 我们认为、通过自行启用以下位、RGMII RXD 至 RXC 偏斜本身将处理延迟(时序调整)。 我的理解是否正确。 因为我无法看到任何特定的寄存器来配置 RX 内部延迟或 TX 内部延迟。

以及在 MAC 侧如何针对 TX 延迟进行配置。 因为在常见问题解答中提到了它适用于 RTOS SDK 和 DP83867 PHY。 但我们使用的是 Linux SDK。 还有其他方法可以做到这一点吗？


等待您的答复 Doredla Sudheer Kumar, 因为我们不确定我们的后续步骤.

提前感谢、
Swedha Raja。

您好！

Unknown 说：

我们如何查看 ALE 条目？ 因为我已经尝试从目录/sys/kernel/debug/..but 找到它、所以没有相关的条目或文件夹。  
以及如何确认广播数据包转发正常？ 我有一个疑问,为什么我们甚至没有做任何事情,计数器值正在增加(例如, TI 载波检测错误),当我们试图只是阅读统计数据。[/报价]

有关转储页码的信息、请参阅以下常见问题解答。
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1204394/faq-tda4vm-how-to-print-the-ale-table-for-cpsw-in-tda4-dra8-devices

默认情况下、当接口为链路接通时、网络堆栈将发送少量数据包。
从统计数据中可以观察到载波感应误差是可见的、而不是 GOOD_TX_FRAMES 保护。

[报价 userid="619932" url="~/support/processors-group/processors/f/processors-forum/1446512/processor-sdk-j784s4-not-able-to-get-dynamic-ip-when-dhcp-is-enabled/5557168 #5557168"]

Doredla Sudheer Kumar 说：

这似乎是 MAC 到 PHY 信号检测中的问题。

我是否需要在 CPSW 驱动程序中执行任何其他软件配置、或者是否需要任何其他配置才能解决此问题？

[报价]

我认为驾驶员侧不需要任何特定的配置。 它将基于设备树。
 如果需要、我们可以从器件树在 MAC 侧配置 RGMII Tx 延迟。

[报价 userid="619932" url="~/support/processors-group/processors/f/processors-forum/1446512/processor-sdk-j784s4-not-able-to-get-dynamic-ip-when-dhcp-is-enabled/5557168 #5557168"]

Doredla Sudheer Kumar 说：

此外、RGMII 延迟是否已正确配置、有关更多详细信息、请参阅以下常见问题解答。 另请向您的硬件团队了解相同的信息。

我介绍了常见问题解答、我们在器件树中将 phy-mode 配置为 RGMII-rxid。 但我们没有在其中添加 eny Rx 内部延迟节点。 我们认为、通过自行启用以下位、RGMII RXD 至 RXC 偏斜本身将处理延迟(时序调整)。 我的理解是否正确。 因为我无法看到任何特定的寄存器来配置 RX 内部延迟或 TX 内部延迟。

[报价]

PHY 侧的延迟基于 PHY 驱动器实施、 可以接受来自器件树配置的延迟值。
在 MAC 侧 、从器件树来看、我们只能启用 TX 延迟。

Unknown 说：

以及如何在 MAC 端配置 TX 延迟。 因为在常见问题解答中提到了它适用于 RTOS SDK 和 DP83867 PHY。 但我们使用的是 Linux SDK。 是否有其他方法可以执行此操作？

有关 Linux SDK 中 MAC 侧通过器件树 PHY 模式 配置启用 RGMII Tx 延迟的常见问题解答。

此外、您能否向您的 H/W 团队了解传输中的载波侦听错误和 RGMII 延迟。
此外、请检查您的原理图是否已由 TI H/W 专家审查？

此致、
Sudheer

[/quote]

您好！
感谢您的答复。

Unknown 说：

有关转储 ALE 条目、请参阅以下常见问题解答。
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1204394/faq-tda4vm-how-to-print-the-ale-table-for-cpsw-in-tda4-dra8-devices

默认情况下、当接口为链路接通时、网络堆栈将发送少量数据包。
从统计数据中可以观察到载波感应误差是可见的、而不是 GOOD_TX_FRAMES [/报价]。

当然、我会查看 ALE 条目的常见问题解答。 感谢您对统计数据的澄清。

Unknown 说：

PHY 端的延迟基于 PHY 驱动程序实施、 可以接受来自设备树配置的延迟值。
在 MAC 端 、从设备树、到我们只能启用 TX 延迟。

所以我的理解错了吗？ (我们认为、通过自行启用以下位、RGMII RXD 到 RXC 的偏斜本身将处理延迟(时序调整)。) 所以我需要通过硬件团队确认 RGMII 的延迟、在设备树中添加 Rx 内部节点。 是这样吗？ 因为数据表中没有其他提到这些延迟。

Unknown 说：

MAC 侧 从设备树来看、我们只能启用 TX 延迟。

如何仅为 PHY 启用 TX 延迟？

Unknown 说：

常见问题解答有关在 Linux SDK 中通过设备树 phy-mode  配置在 MAC 端启用 RGMII Tx 延迟的信息。
[报价]

但以下寄存器适用于 DP83867 Phy。 对于我们的 Broadcom phy (BCM54810)、没有类似以下类型的寄存器。  

• 寄存器地址0x32 - RGMII 控制寄存器(RGMIICTL)
• 寄存器地址0x86 - RGMII 延迟控制寄存器(RGMIIDCTL)

 我有一个疑问、phy-mode = RGMII-rxid 本身将处理 MAC 侧 TX 延迟？

提前感谢、
Swedha R

[/quote]

Unknown 说：

您好、  
我也检查了 Wireshark。 我已将静态 IP 设置到板中、正如我之前所提到的、当 DHCP 启用时它无法获取 IP。 我已在 PC 中运行 Wireshark 工具、并尝试 对电路板执行 ping 操作。 但这不是偶然的。 我们注意到的一点是、我们甚至无法从评估板本身对评估板的网关执行 ping 操作。 以下是主板的输出、

Doredla Sudheer Kumar 能否 同时介绍一下您对 Wireshark 测试的看法？

您好！

Doredla Sudheer Kumar 说：

PHY 侧的延迟基于 PHY 驱动器实施、 可以接受来自器件树配置的延迟值。
在 MAC 侧 、从器件树来看、我们只能启用 TX 延迟。

所以我的理解错了吗？ (我们认为、通过自行启用以下位、RGMII RXD 到 RXC 的偏斜本身将处理延迟(时序调整)。) 所以我需要通过硬件团队确认 RGMII 的延迟、在设备树中添加 Rx 内部节点。 是这样吗？ 因为数据表中没有其他提到这些延迟。

是的、RGMII 延迟可以根据 MAC 和 PHY 的支持从 MAC 或 PHY 进行配置、也可以从两侧进行配置。
TI SoC 仅支持 MAC 侧的 Tx 延迟、Rx 可通过 PHY 或 PCB 原理图布线进行配置。
检查 PHY 端延迟支持模型、默认情况下是否启用任何延迟。

理想情况下、这些延迟在速度较高时很重要、例如1Gpbs。 但是、基于原理图设计、我们可能还需要更低的速度。  

Doredla Sudheer Kumar 说：

在 MAC 侧 、从器件树来看、我们只能启用 TX 延迟。

如何仅为 PHY 启用 TX 延迟？

TX 可以从 MAC 配置、与 PHY 端相关、请与 PHY 供应商核实。

Unknown 说：

 我有一个疑问、phy-mode = RGMII-rxid 本身将处理 MAC 端的 TX 延迟？

是的、phy-mode "rgmII-rxid"本身启用 MAC 侧 Tx 延迟。

Unknown 说：

此外、您能否向硬件团队了解传输中的运营商感知错误以及 RGMII 延迟问题？
此外、请检查您的原理图是否已由 TI 硬件专家审核？[/QUOT]

也请查看以上要点。

 此致、
Sudheer

您好！

Swedha R 说：

尊敬的 Sudheer：  
我也检查了 Wireshark。 我已将静态 IP 设置到板中、正如我之前所提到的、当 DHCP 启用时它无法获取 IP。 我已在 PC 中运行 Wireshark 工具、并尝试 对电路板执行 ping 操作。 但这不是偶然的。 我们注意到的一点是、我们甚至无法从评估板本身对评估板的网关执行 ping 操作。 下面是电路板的输出、

Doredla Sudheer Kumar 能否 同时介绍一下您对 Wireshark 测试的看法？

您可以将 CPSW 外部端口连接到 PC 端、 在 PC 上运行 Wireshark 并检查是否接收到任何数据包？
如果从 Wireshark 接收数据包、则表示 MAC 侧的 Tx 正常工作。
对于 Rx、请从 PC 向 CPSW 发送一些数据包、并检查统计信息是否有 Rx 计数器在增加？
如果 Rx 计数器增加、但数据包未到达主机应用程序(run (tcpdump -i. -xx)那么这些可能会因为 ALE 而被丢弃。 这可从 CPSW 统计信息中找到。

此致、
Sudheer

Unknown 说：

是的、phy-mode "RgmII-rxid"本身启用 MAC 侧 Tx 延迟。

感谢您的立即响应。

Unknown 说：

此外、您能否向硬件团队了解传输中的运营商感知错误和 RGMII 延迟问题？
此外、请检查您的原理图是否已由 TI 硬件专家审核？[/QUOT]

当然。

Unknown 说：

您可以将 CPSW 外部端口连接到 PC 端、并在 PC 上运行 Wireshark 并检查是否接收到任何数据包？
如果从 Wireshark 接收数据包、则表示 MAC 侧的 Tx 正常工作。
对于 Rx、请从 PC 向 CPSW 发送一些数据包、并检查统计信息是否有 Rx 计数器在增加？
如果 Rx 计数器增加、但数据包未到达主机应用程序(run (tcpdump -i. -xx)那么这些可能会因为 ALE 而被丢弃。 这可以从 CPSW 统计信息中找到。

是的、我也完成了上述场景、但没有检查 RX 计数器。

为了满足您的需要、我将从过去的消息复制粘贴。 在这个信息中,我清楚地解释了我们是如何做的,我们得到了什么。

我也检查了 Wireshark。 我已将静态 IP 设置到板中、正如我之前所提到的、当 DHCP 启用时它无法获取 IP。 我已在 PC 中运行 Wireshark 工具、并尝试 对电路板执行 ping 操作。 但这不是偶然的。 我们注意到的一点是、我们甚至无法从评估板本身对评估板的网关执行 ping 操作。 下面是电路板的输出、

tcpdump -i eth1 arp.
[109.789656] 设备 eth1进入混杂模式
[109.794321] kauditd_printk_skb：抑制6回调
[109.794325] 审核：type=1700审核(1651169166.180:35)：dev=eth1 prom=256 old_prom=0 auid=4294967295 uid=0 gid=0 ses=4294967295
[109.810849] 审核：type=1300审核(1651169166.180：35)：arch=c00000b7 syscall=208成功=yes 退出=0 a0=4 a1=107 a2=1 a3=ffffd7860bb0 items=0 pid=1346 pid=1463 auid=4294967295 uid=0 gid=0 /usr/bin/tcpdump
[109.837743] audit：type=1327 audit (1651169166.180:35)：protitle=74637064756D70002D69006574683100617270
tcpdump：禁用详细输出、请使用-v[v]... 以实现完整协议解码
侦听 eth1、链路类型 EN10MB (以太网)、快照长度262144字节
18：06：07.055256 ARP、请求 who-has _gateway tell j784s4-EVM、长度28
18：06：08.079247 ARP、request who-has _gateway tell j784s4-evm、length 28
18：06：09.103385 ARP、请求 who-has _gateway tell j784s4-evm、长度28
18：06：10.127244 ARP、请求 who-has _gateway tell j784s4-evm、长度28
18：06：11.151246 ARP、请求 who-has _gateway tell j784s4-evm、长度28
18：06：12.175362 ARP、请求 who-has _gateway tell j784s4-evm、长度28
18：06：12.982092 ARP、请求 who-has j784s4-evm tell 192.168.1.107、长度46
18：06：12.982125 ARP、reply j784s4-evm is-at ea：C7：85：95：36：B2 (oui Unknown)、长度28
18：06：13.199244 ARP、请求 who-has _gateway tell j784s4-evm、长度28
18：06：14.043731 ARP、请求 who-has j784s4-evm tell 192.168.1.107、长度46
18：06：14.043743 ARP、reply j784s4-evm is-at ea：C7：85：95：36：B2 (oui Unknown)、长度28
18：06：14.223243 ARP、请求 who-has _gateway tell j784s4-evm、长度28
18：06：15.067687 ARP、请求 whho-has j784s4-evm tell 192.168.1.107、长度46
18：06：15.067697 ARP、reply j784s4-evm IS-at ea：C7：85：95：36：B2 (oui Unknown)、长度28
18：06：15.247347 ARP、请求 who-has _gateway tell j784s4-evm、长度28
18：06：16.091638 ARP、请求 who-has j784s4-evm tell 192.168.1.107、长度46
18：06：16.091645 ARP、reply j784s4-evm is-at ea：C7：85：95：36：B2 (oui Unknown)、长度28
18：06：16.271243 ARP、请求 who-has _gateway tell j784s4-evm、长度28
18：06：25.307471 ARP、请求 who-has j784s4-evm tell 192.168.1.107、长度46
18：06：25.307484 ARP、reply j784s4-evm is-at ea：C7：85：95：36：B2 (oui Unknown)、长度28
18：06：25.487247 ARP、request who-has _gateway tell j784s4-evm、length 28
18：06：26.331434 ARP、请求 who-has j784s4-evm tell 192.168.1.107、长度46
18：06：26.331442 ARP、reply j784s4-evm is-at ea：C7：85：95：36：B2 (oui Unknown)、长度28
18：06：26.511246 ARP、request who-has _gateway tell j784s4-evm、length 28
18：06：27.355334 ARP、请求 who-has j784s4-evm tell 192.168.1.107、长度46
18：06：27.355342 ARP、reply j784s4-evm is-at ea：C7：85：95：36：B2 (oui Unknown)、长度28
18：06：27.535410 ARP、request who-has _gateway tell j784s4-evm、length 28
18：06：28.379313 ARP、请求 who-has j784s4-evm tell 192.168.1.107、长度46
18：06：28.379319 ARP、reply j784s4-evm IS-at ea：C7：85：95：36：B2 (oui 未知)、长度28
18：06：28.559242 ARP、请求 who-has _gateway tell j784s4-evm、长度28
18：06：29.403322 ARP、请求 who-has j784s4-evm tell 192.168.1.107、长度46
18：06：29.403354 ARP、reply j784s4-evm is-at ea：C7：85：95：36：B2 (oui Unknown)、长度28
18：06：29.583251 ARP、请求 who-has _gateway tell j784s4-evm、长度28
18：06：30.427256 ARP、请求 who-has j784s4-evm tell 192.168.1.107、长度46
18：06：30.427272 ARP、reply j784s4-evm IS-at ea：C7：85：95：36：B2 (oui Unknown)、长度28
18：06：30.607426 ARP、请求 who-has _gateway tell j784s4-evm、长度28
18：06：31.451198 ARP、请求 who-has j784s4-evm tell 192.168.1.107、长度46
18：06：31.451207 ARP、reply j784s4-evm is-at ea：C7：85：95：36：B2 (oui Unknown)、长度28
18：06：31.631241 ARP、request who-has _gateway tell j784s4-evm、length 28
^C
捕获39个数据包
过滤器接收到61个数据包
22个数据包[ 135.671573]器件 eth1左侧为混杂模式
 被内核丢弃
[135.681305] 审核: type=1700审核(1651169192.072:36)：dev=eth1 prom=0 old_prom=256 auid=4294967295 uid=0 gid=0 ses=4294967295

还有一点需要注意、
ARP -n
地址                 HWTYPE HWaddress           Flags Mask           iface
192.168.1.107           ether  34:60:F9:ce:36:ae  C                    eth1
192.168.1.1                     (不完整)                             eth1  

无法获取其 MAC 地址。

您好！

Unknown 说：

我们注意到的一件事是、我们甚至无法从主板本身 ping 通主板网关。 以下是主板的输出、

你是如何对门的。

我已从 Linux 计算机本地尝试配置静态 IP 192.168.5.5。
我无法 ping 192.168.5.1或192.168.5.255、但我只能 ping 192.168.5.5、因为它是自 IP。

您可以在测试 PC 中尝试同样的操作并进行检查吗？

您能否从 RGMII 延迟和原理图的角度向您的 H/W 团队核实为何在 Tx 路径中观察到载波检测错误。

此致、
Sudheer

您好！

正如我在上文中所述、由于载波感测错误、不会向外发送数据包。
您能向硬件专家咨询一下吗？

此致、
Sudheer

感谢您的响应。 我们将就该问题与您联系。

我有一个疑问、您刚才提到、如果我们给出的 phy-mode = rgmII-rxid 意味着、MAC 侧 TX 延迟将被考虑在内。 但是 、我们如何知道实际延迟了多少 、以及我们如何通过软件读取、还需要从 PHY 端与我们的硬件团队确认它们是否在硬件中启用如果我们不需要从器件树中的 phy 端添加 Rx 延迟、对吗？ 因为 RGMII 信号图中 仅提到了建立延迟和保持时间延迟。 因此、当我们探测信号时、可以检查这些设置和保持时间延迟。 这本身就足够了吗？
 
此致、
Swedha R

您好！

是的、如果我们将 RGMII-rxid MAC 侧 TX 延迟配置为启用状态。 MAC 侧的延迟是固定的2ns、它是不可配置的值。
这可以通过 CTRL MMR 模块的 ENET CTRL 寄存器(CTRL_MMR_CFG0_CPSW2_ENET1_CTRL)进行验证。
CPSW2_ENET1_CTRL_RGMII_ID_MODE：0表示启用 Tx 延迟、1表示禁用 Tx 延迟。

是的、一旦与 PHY 驱动程序检查它是否从器件树中获得延迟、并相应地使用。

Unknown 说：

原因在于、在 RGMII 信号图中、设置延迟和 保持时间延迟只是他们提到的。 因此、当我们探测信号时、可以检查这些设置和保持时间延迟。 这本身是否足够？

可以、您可以捕获数据并分析信号。

此致、
Sudheer

Unknown 说：

是的、您可以捕获数据并分析信号。

大家好、 Doredla Sudheer Kumar
我们捕获了信号、因为 当我看到数据正在 TX 数据线上传输时、TX_ctl 线路不会变为高电平。 问题是什么？ 如何进行调试？

Unknown 说：

是的、如果我们将 RGMII-rxid MAC 侧 TX 延迟配置为启用状态。 MAC 侧的延迟是固定的2ns、它是不可配置的值。
这可以通过 CTRL MMR 模块的 ENET CTRL 寄存器(CTRL_MMR_CFG0_CPSW2_ENET1_CTRL)进行验证。
CPSW2_ENET1_CTRL_RGMII_ID_MODE：0表示启用 Tx 延迟、1表示禁用 Tx 延迟。[/QUOT]

另一个疑问是、这里的 MAC 端固定延迟是2ns。 但在我们的示例中、在延迟模式下、至少2.9被称为输入保持延时时间。


可能是问题所在？  

提前感谢

Swedha R

 

您好！

您能检查 RGMII TX_CLK 吗？

此外、能否确认 PHY 支持带内信令？  

另外、您能否再次确认使用静态 IP 的 ping 也不能正常工作？

 此致、
Sudheer

您好！  

Unknown 说：

您能看一下 RGMII TX_CLK 吗？

  根据我在上一个查询中分享的 Broadcom PHY 数据表、时钟周期为800皮秒。  

您是将 SGMII、QSGMII 指带内信令吗？ 如果是、我们的 PHY 将不支持带内信令。 MAC 和 PHY 仅通过 RGMII 接口进行通信。
我看到了 cpsw.c 驱动程序代码中提及带内模式的以下部分。

Unknown 说：

此外、您能否使用静态 IP 重新确认 ping 也无法正常运行？

如果我设置静态 IP、就能 ping 其自己的 IP。 但无法 ping 通同一子网中的外部设备。

提前感谢、
Swedha R

您好！

Doredla Sudheer Kumar 说：

您能检查 RGMII TX_CLK 吗？

  根据我在上一个查询中分享的 Broadcom PHY 数据表、时钟周期为800皮秒。  

对于10Mbps RGMII、时钟应为2.5MHz。
800皮秒可能是噪声、请检查峰峰值以确定是噪声还是实际信号。

Doredla Sudheer Kumar 说：

此外、能否确认 PHY 支持带内信令？  

您是将 SGMII、QSGMII 指带内信令吗？ 如果是、我们的 PHY 将不支持带内信令。 MAC 和 PHY 仅通过 RGMII 接口进行通信。
我看到了 cpsw.c 驱动程序代码中提及带内模式的以下部分。

是的、即使 RGMII 也可以具有带内信令。
如果 PHY 不支持带内信号、则10Mbps RGMII 将不起作用。

Doredla Sudheer Kumar 说：

另外、您能否再次确认使用静态 IP 的 ping 也不能正常工作？

如果我设置静态 IP、就能 ping 其自己的 IP。 但无法 ping 通同一子网中的外部设备。

如上所述、10Mbps RGMII 需要带内信号。

此致、
Sudheer

大家好、 Doredla Sudheer Kumar
感谢您的响应。

OK 将检查并返回此处。

如果它输入到上述 else if 语句中、我们是否应该确认已启用带内信令？ 因为我 在 phy 数据表中看不到带内信令。

提前感谢、
Swedha R

您好！

Unknown 说：

如果在上述 else if 语句中输入、我们是否确认启用了带内信令？ 因为我 在 phy 数据表中看不到带内信令。

如果进入 ELSE IF、则在 MAC 侧启用带内。
PHY 还应支持该功能、如果不这样、链路将无法建立、通信也将无法启动、MAC 也无法配置链路所需的时钟。

此致、
Sudheer

大家好、 Doredla Sudheer Kumar

Unknown 说：

PHY 也应支持该功能、如果不能建立链路、通信将无法启动、MAC 也无法配置链路所需的时钟。

但链路已经建立。 仅进行通信。

MAC 和 PHY 配置相同的速度、模式等。

您能否在 ti-sdk 中告诉我哪些文件或函数负责接收 CPSW (PHY->CPSW)从 PHY 发送的数据包？ 我已经浏览了 cpsw.c、am65-cpsw-nuss.c 文件、并找到了 cpsw->cppdma point。  


谢谢！
Swedha R.

您好！

Unknown 说：

Doredla Sudheer Kumar 说：

PHY 还应支持该功能、如果不这样、链路将无法建立、通信也将无法启动、MAC 也无法配置链路所需的时钟。

但链路已经建立。 仅进行通信。

[报价]

此处的链路是从 PHY 读取的、它是与 PHY 和链路伙伴的链路。

MAC 至 PHY 通信需要适当的 RGMII 时钟、MAC 将生成 TXC、PHY 将生成 MAC RXC。

Unknown 说：

MAC 和 PHY 配置为相同的速度、模式等

它 将在 PHY 端作为链路接通。

Unknown 说：

您能否在 ti-sdk 中告诉我哪些文件或函数负责通过 CPSW (PHY->CPSW)接收来自 PHY 的数据包？ 我已经浏览了 cpsw.c、am65-cpsw-nuss.c 文件、并找到了 cpsw->cppdma point。  [报价]

如上所述、您可以检查 CPSW 统计信息以获取良好的 Rx 数据包计数。
在驱动程序或应用程序之前、MAC H/W 必须接受数据包

此致、
Sudheer

[/quote]

您好！

我们没有采用 Broadcom PHY 的 EVM。

P0 ->主机端口、即 CPSW 的内部 CPPI 端口。

P0 Rx 是从应用/网络栈在内部生成的。
p0 Rx ->外部端口 Tx、用于将数据包传输到 CPSW 外。
外部端口 Rx -> P0 Tx、从外部接收的数据包。

我可以有一些 rx_good_packet、即从外部接收这些数据。

从 eth0日志中：
PO_Rx_GOOD_FRAMES：41与 TX_GOOD_FRAMES 匹配、无载波错误(即、从 CPSW 的角度来看、Tx 正常)。
RX_GOOF_FRAMES：39、ALE DROP：18剩余的21发送到主机端口、即 p0_TX_GOOD_FRAMES：21、这意味着 CPSW 也会从外侧接收一些数据包。

您可以运行 tcpdump -i eth0 -XX 查看包装器内容、打开远程端的 Wireshark 并比较数据包。

我是否可以知道为修复载波感应错误进行了哪些更改？

此致、
Sudheer

感谢回复 Sudheer。

Unknown 说：

我是否可以知道为解决运营商感知错误进行了哪些更改？

当我们通过驱动程序本身强制将速度设为100时、不会遇到任何 TX_CARRER_SENSE_ERRORS。

我们对工作 PHY (ADIN1300)(eth0)和 BCM54810 (eth1)进行了内部环回测试。 但是、对于 BCM54810 PHY、我们没有任何 rx_good_FRAMES。 问题可能是什么？ 甚至没有看到速度为100Mbps 的任何 tx_carrier_sense_errors。 该问题是软件还是硬件方面的问题？


提前感谢、
Swedha R

您好！

我是否可以知道为修复载波感应错误进行了哪些更改？

当我们通过驱动程序本身强制将速度设为100时、不会遇到任何 TX_CARRER_SENSE_ERRORS。

您的意思是 PHY 驱动程序更新到100M？ 如果是这样、CPSW MAC 侧配置为100M。

Unknown 说：

我们对工作 phy (ADIN1300)(eth0)和 BCM54810 (eth1)进行了内部环回测试。 但是、对于 BCM54810 PHY、我们没有任何 rx_good_FRAMES。 问题可能是什么？ 甚至没有看到速度为100Mbps 的任何 tx_carrier_sense_errors。 该问题来自软件还是硬件？[/QUOT]

工作 PHY (ADIN1300)表示获得 Rx_GOOD_FRAMES。
对于 BCM、您没有获得？ 检查是否检测到第一个 PHY 以及 PHY 是否退出复位？
此外、RGMII Tx 时钟来自 MAC、因此 TX_GOOD_FRAMES 将增加。 RX 时钟应来自 PHY、而是不从 PHY 提供时钟、不会接收返回数据包。

此致、
Sudheer

您好、感谢您的响应。

Unknown 说：

您是指 PHY 驱动程序更新强制达到100M？ 如果是这样、CPSW MAC 侧配置为100M。

是的、我们更新了 PHY 驱动程序、以强制设置为100M。 显然、CPSW MAC 端也配置为 PHY 端配置的速度。

有。 您还解释了前一个问题中的帧。

Unknown 说：

对于 BCM、您没有获得？ 检查是否检测到第一个 PHY 且 PHY 是否未复位？[/QUOT]

检测到 PHY。

[报价 userid="540868" url="~/support/processors-group/processors/f/processors-forum/1446512/processor-sdk-j784s4-not-able-to-get-dynamic-ip-when-dhcp-is-enabled/5604448 #5604448"]此外、RGMII Tx 时钟来自 MAC、因此 TX_GOOD_FRAMES 将增加。 RX 时钟应来自 PHY、而 IS 时钟不来自 PHY 数据包、不会接收到数据包。[/QUOT]

PHY 侧不提供 RX 时钟可能出现什么问题？

提前感谢、
Swedha R  

您好！

Doredla Sudheer Kumar 说：

此外、RGMII Tx 时钟来自 MAC、因此 TX_GOOD_FRAMES 将增加。 RX 时钟应来自 PHY、而是不从 PHY 提供时钟、不会接收返回数据包。

PHY 侧不提供 RX 时钟可能出现什么问题？

请检查 MAC 的 RGMII TXC 和 PHY 的 RGMII RXC、这些应该是25MHz 时钟以实现100Mbps 链路速度。

如果 PHY 未生成、请检查 PHY 供应商、是否需要任何配置？ 此外、检查 RGMII 延迟配置。

此致、
Sudheer

您好、感谢您的响应。

我们将查看上述内容并返回此处。

谢谢！
Swedha R.

您好！

请检查 MAC 的 RGMII TXC 和 PHY 的 RGMII RXC、这些应该是25MHz 时钟以实现100Mbps 链路速度。

如果 PHY 未生成、请检查 PHY 供应商、是否需要任何配置？ 此外、检查 RGMII 延迟配置。

我们将查看上述内容并返回此处。

当然可以、请在选中上述内容后告知我们更新。

此致、
Sudheer

尊敬的 Sudheer：

Unknown 说：

当然、请在检查上述更新后告知我们。

我们仍然没有检查这一点。 我们计划在 RGMII 引脚中添加探测导线、并考虑探测信号。 一旦完成、我们将返回此处。

此致、
Swedha R

您好！

Doredla Sudheer Kumar 说：

当然可以、请在选中上述内容后告知我们更新。

我们仍然没有检查这一点。 我们计划在 RGMII 引脚中添加探测导线、并考虑探测信号。 一旦完成、我们将返回此处。

当然、请在您进行测量/捕获后告知我们。

此外、如果可能、请尝试使用不同的 PHY 和检查一次。 此外、与 PHY 供应商确认配置。

此致、
Sudheer

您好！  

Unknown 说：

当然、请在测量/捕获完产品后告知我们。

此外、如果可能、请尝试使用不同的 PHY 和检查一次。 此外、与 PHY 供应商确认配置。[/QUOT]

当然、Sudheer。

谢谢！
Swedha R

您好！

Doredla Sudheer Kumar 说：

当然、请在您进行测量/捕获后告知我们。

此外、如果可能、请尝试使用不同的 PHY 和检查一次。 此外、与 PHY 供应商确认配置。

当然、Sudheer。

如有任何更新、请告知我们。

此致、
Sudheer