[参考译文] PROCESSOR-SDK-AM64X：PROCESSOR-SDK-AM64X：带有 ICSSG HSR 固件的格式错误的数据包

您好、Tianyi！

这里有一些问题

1."做物理链路中断恢复"是什么意思? 这是否意味着以太网电缆物理断开连接？ 或者只是在软件中断开/建立链路(即使用"IP link set ethX down"命令)？

2.问题是否持续发生(即在"物理链路中断恢复"一段时间后)?

3.格式错误的数据包是否只显示 GOOSE 数据包？ 或者它是否发生在任何数据包(例如 ICMP ping)上？

-道林

您好、Daolin

感谢您快速回答。

1-这意味着以太网电缆物理断开连接！

2-我们进行了3个小时的测试、大约有~12个格式错误的数据包、但这些数据包包含关键信息

3 -我不知道这个...因为我们只针对 GOOSE 包

另外、通过向内部团队澄清、他们预计 HSR PRU 固件会丢弃格式错误的数据包。

HSR PRU 固件是否会丢弃格式错误的数据包？ 格式错误的、我的意思是数据包的 CRC 不正确。

我们的推测是、硬件 FCS (CRC)检查没有滤除端口 B 的链路断开所产生的格式错误的数据包。 相反、它早于冗余数据包从端口 A 进入 HSR LRE、并最终转发到内核。

-天一

您好、Tianyi、

Unknown 说：

1 -这意味着以太网线缆物理断开！

Unknown 说：

2 -我们进行了3小时的测试、大约有~12个格式错误的数据包、但这些数据包包含重要信息

由于是物理断开连接、您是如何在三个小时的时间内对其进行测试的？ 我认为这是自动操作、因为很难让人在如此长的时间内反复断开和重新连接电缆。

Unknown 说：

3 -我不知道这个...因为我们只针对 GOOSE 包

我看到了,为什么我问是因为 我不太熟悉发送 GOOSE 包。 除了您之前与我们共享的 GOOSE 多播发送应用程序之外、我 不确定专门为 GOOSE 数据包设置包生成器是否会比发送简单的 ping 消息更困难。 进行复制。

另外、通过向内部团队澄清、他们预计 HSR PRU 固件会丢弃格式错误的数据包。

HSR PRU 固件是否会丢弃格式错误的数据包？ 格式错误的、我的意思是数据包的 CRC 不正确。

当您观察到这些格式错误的数据包时、您是否还可以捕获"ethtool -S eth1"和"ethtool -S eth2"统计信息(其中 eth1和 eth2是绑定到 HSR 接口的子接口)？

通常、如果存在损坏的数据包(例如)、PHY 或 MAC 将检测这些数据包、并在它们到达内核级/上层之前丢弃这些数据包、正如您所指出的那样。 如果发生这些损坏的数据包、则通常会在从 ethtool -S 显示的 MAC 硬件统计信息中指示这些数据包

这是它处理 CPSW 以太网的方式、据我了解、这也是处理用于 HSR 卸载的 PRU_ICSSG 以太网的方式；但是、我将检查这是否是通过 HSR 固件、PRU 固件、Linux PRU_ICSSG 驱动程序级别完成的。

-道林

尊敬的 Daolin：

感谢您快速回答。

1-2 :是的,它是通过使用设备 OMICRON#1的自动化。 器件 OMICRON#1可以驱动开关 RJ45模块的开/关。

3 -让我检查内部团队,看看它是否可以复制与 ping ...

当您观察到这些格式错误的数据包时、您是否还可以捕获"ethtool -S eth1"和"ethtool -S eth2"统计信息(其中 eth1和 eth2是绑定到 HSR 接口的子接口)？

是的,当然,我们将尝试! 内部团队注意到、如果不卸载 HSR、格式错误的数据包就会被丢弃。 但通过添加 HSR ,它不会被丢弃...

-天一

您好、Tianyi、

>>是的,当然,我们会尝试! 内部团队注意到、如果不卸载 HSR、格式错误的数据包就会被丢弃。 但通过添加 HSR ,它不会被丢弃...

谢谢您发送此注释、似乎表明 HSR PRU 固件上存在问题、可能无法丢弃格式错误/损坏的数据包、因为在不使用 HSR PRU 固件和使用 ICSSG_PRU 固件(在 HSR 未卸载时使用)时可以丢弃这些数据包。

当发现此问题的格式错误的数据包时、您是否在所有设备(包括#3设备)上通过直通转发设置 HSR 卸载？ 3号设备是数据包的最终目的地？

-道林

您好、Tianyi、  

Unknown 说：

实际上、设备#3收到数据包。 此#3还可以将数据包转发到环中的另一个设备。 如果是、那么固件的预期是什么？ 固件是否应丢弃设备要转发的格式错误的数据包？[/QUOT]

通常(不特定于 PRU 固件)、如果器件正在以直通方式转发数据包、那么一旦确定目标地址和传出端口、它就会直接转发数据包、而不会检查数据包 CRC。 目标器件负责检查接收到的数据包、如果存在 CRC 错误、则丢弃该数据包。

从逻辑上讲、我认为设备以直通转发数据包可能会将损坏的数据包转发到目标地址、这一点很合理。 我认为目标设备(#3)不会丢弃损坏的数据包是没有道理的。

[报价 userid="554501" url="~/support/processors-group/processors/f/processors-forum/1458156/processor-sdk-am64x-processor-sdk-am64x-malformed-packet-with-icssg-hsr-firmware/5596698 #5596698"]

我们使用 ethtool -S 进行了测试、当格式错误的数据包到达时、计数器正在增加。 我假设物理层 CRC 检查可能工作正常、但 PRU HSR 固件无法处理"ERROR_CRC"信号或处理不正确。

[报价]

我假设您引用的计数器是"rx_crc_errors"？ 是唯一的错误计数器递增还是其它来自 ethtool 统计信息的错误计数器递增？

我同意、这也意味着 HSR PRU 固件会检测到损坏的数据包、但不会将其丢弃。  

我们团队提出的一个问题是、您使用的 Linux 驱动程序是否经过了修改、以便告知 HSR PRU 固件接受所有数据包(即使是带有 CRC 错误的数据包)？ 如果发生这种情况、也可能是 HSR PRU 固件没有丢弃损坏数据包的原因。

-道林

尊敬的 Daolin：

从逻辑上讲、我认为设备以直通转发数据包可能会将损坏的数据包转发到目标地址、这一点很合理。 我认为目标设备(#3)不会丢弃损坏的数据包是没有道理的。

是的,这对我来说是有意义的,它是接收设备谁决定数据包是否格式错误! 我需要与内部团队确认此案例是否适合他们。

输出如下:

我假设您引用的计数器是"rx_crc_errors"？ 是唯一的错误计数器递增还是其它来自 ethtool 统计信息的错误计数器递增？

是的、它是计数器 RX_CRC_ERROR_FRAMES。

我们团队提出的一个问题是、您使用的 Linux 驱动程序是否经过了修改、以便告知 HSR PRU 固件接受所有数据包(即使是带有 CRC 错误的数据包)？ 如果发生这种情况、也可能是 HSR PRU 固件没有丢弃损坏数据包的原因

是的、您是对的！ 我们需要检查 Linux 驱动程序是否接受所有数据包、即使是错误的 CRC 也是如此。

同时、您是否可以开始调查此错误？

-天一

您好、Tianyi、  

Unknown 说：

与此同时、您是否可以开始调查此错误？

正如我们在本次调用中提到的、HSR PRU 固件存在一个已知问题、固件开发人员正在努力修复该问题、该问题有望解决损坏的数据包不会被丢弃的问题。 一旦新的 HSR PRU 固件二进制文件推出、我将与您分享这些二进制文件(有望在一两天内推出)。

-道林

尊敬的 Daolin：此固件是否可能触发 AM64x SDK v10.2？ 还是进入 SDK v 11？

新年快乐

吉姆

Jim、您好！  

如果尚未合并到 git.ti.com ti-linux-firmware 中、则可能首先将其以 zip 格式提供给 Tianyi 以取消阻止其测试。  

我希望它可以集成到即将推出的 SDK 11.0版本中。 据我所知、我们不会有 SDK 10.2版本(这个版本将被 SDK 11.0版本取代)。

-道林

尊敬的 Daolin：

是的、非常感谢！ 我们将测试此测试并返回给您！

如果这样可以解决我们的问题、您是否计划推入 TI-Linux-firmware ？

-天一

您好、Tianyi、  

Unknown 说：

如果这可以解决我们的问题、您是否计划将此问题延后处理 TI-Linux-firmware ?[/报价]

作为更新、固件团队告知我新固件正在进行一些内部自动化测试、而这些测试直到明天才能完成。  

如果自动化测试顺利、我们计划在周一通过 zip 线(电子邮件)与您分享这些二进制文件、以便您的团队至少可以开始测试。

同时、我将尝试通过故意发送包含 CRC 错误的数据包来测试设置中的固件、以便复制该问题、并验证固件是否确实可以解决该问题。 这可能需要我花一些时间、因此我们计划并行共享这些二进制文件、让您在周一的测试中顺利进行。

如果固件确实为您解决了问题(我也可以重现问题并验证修复)、那么 最好 合并到 ti-linux-firmware 中。

-道林

尊敬的 Daolin：

感谢您的快速响应！ 这是明确的!

是否可以通过故意发送带有 CRC 错误的数据包与我们分享您在设置上测试的过程？

-天一

您好、Tianyi、

>>如果自动化测试顺利进行,我们计划在周一通过一个 zip 离线(电子邮件)与您分享二进制文件,以便您的团队至少可以开始测试。

我尚未收到有关自动测试状态的确认、因此如果二进制文件仍然可以离线与您共享、我会尝试与内部团队达成一致。 我希望明天能收到内部团队的回复。

Unknown 说：

是否可以通过发送您的数据包与我们共享您的数据包来测试您的设置？

我尝试了两种不同的方法、试图在没有特殊设备的情况下将有 CRC 错误的数据包引入我的测试设置中。 遗憾的是、事实证明、这两种方法在发送带有 CRC 错误的数据包时微不足道。

1.调整时钟和数据信号之间的 RX RGMII 延迟、确保信号对齐。 这仍然会导致没有显示 CRC 错误、表明尽管确保没有 RX RGMII 延迟、但可能仍有一些建立和/或保持时间会在 RX 时钟和数据信号之间引入一些偏移。

2.通过切断8根导线的一根线来改编以太网电缆。 在1000BASE-T 电缆中、所有8根线都负责自动协商、因此切割一根线会立即导致链路断开。 需要保持链路以接收数据包、更不用说具有 CRC 错误的数据包。  

我们的固件团队使用更新后的 HSR 固件、通过将包含 CRC 错误的数据包传输到连接到 TI EVM 的 Spirent 测试仪器件、对新二进制文件完成了一些有限的手动测试。 TI EVM 能够丢弃包含 CRC 错误的数据包。 我无法创建相同的设置、因为我无法访问 Spirent 等专用设备。

您的团队是否只能通过发送带有 CRC 错误的数据包进行测试、或者这些格式错误的数据包是否只能通过物理链路接通/断开连接测试进行重现？ 如果您能够通过专门发送包含 CRC 错误的数据包进行测试、您可以使用什么方法来进行测试？

Unknown 说：

如果固件确实为您解决了此问题(我也可以重现此问题并验证此问题)、则 最好 合并到 ti-linux-firmware 中。

如果新固件最终可以为您工作、我们将尝试合并它。 考虑到我复制问题的手段有限、这可能不一定需要我重现问题。

-道林

[/quote]

您的团队是否只能通过发送带有 CRC 错误的数据包进行测试、或者这些格式错误的数据包是否只能通过物理链路接通/断开连接测试进行重现？ 如果您能够通过专门发送包含 CRC 错误的数据包进行测试、您可以使用什么方法来进行测试？

我们在我们这边尝试在没有这个物理上行/下行连接的情况下重现这个错误。。。

您好、Tianyi、  

感谢您提供的信息。

有一件事我没有机会尝试通过将 MAC TX_Dx 信号短接至地(或高)来引入损坏的数据包。 其原理是、由于 PHY 完整性不会处于良好状态、因此这会使 PHY 将数据包标记为不良数据包。 如果您仍在尝试在没有物理上行/下行连接的情况下重现问题的方法、可能需要自行尝试。

-道林

尊敬的 Daolin：

很抱歉耽误你的时间。

实际上、我们无法发送包含 CRC 错误的数据包。

-天一

尊敬的 Daolin：

我会与内部团队核实并返回给你!

非常感谢!

-天一

您好、Tianyi、

感谢您的澄清。 此外、请告诉我们新固件是否可为您的团队解决此问题。 固件二进制文件附在 Pekka 的响应中。  

e2e.ti.com/.../5609242

-道林

尊敬的 Daolin：

我们刚刚完成了所有不同的测试(丢弃不良 CRC 数据包+回归测试)、但我们没有发现新 PRU 固件有任何问题

非常感谢!

-天一