[参考译文] 66AK2H14：以太网引导模式下的 BOOTP 数据包错误

Yordan、您好！

我 使用的是 mcsdk 版本3.00.03.15

mcsdk 版本在这里是否重要？ 在检索 uboot 之前、RBL 不是唯一运行的软件？

谢谢

————————关

整个 BOOTP req 数据包的视图。   Rx_er 被置为有效的周期有4个、 但最后一个周期只是调用载波扩展(在  Rx_dv 变为0后发生)。 请参阅图1。

放大以太网报头中的第一个错误、其中源 MAC addr 损坏(应为 a0：F6：FD：A5：E5：10)。  当这里出现错误时，我们始终会看到连续的0xA5。 请参阅图2。

放大有效载荷中的第二个误差、其中源 MAC addr 也很糟糕。  有时，MAC addr 的第二个实例是正确的，即使第一个实例是错误的。  请参阅图3。

放大有效载荷末尾附近的第三个误差。  此错误数据段始终为0xC4、并在表中标记为非。  请参阅图4。

这是一个方框图、表示我们的配置：

Rahul、您好、我已经连接了一个良好以太网引导的 Wireshark 日志。  我们有2台服务器与此处的电路板交互。  我从提供 tftp 文件的服务器运行 Wireshark。  KSII 从另一台服务器获取 DHCP 响应、该服务器为其提供 IP 地址、并使用 next 服务器参数告知 KSII 从何处获取 uboot 二进制文件、这是运行 Wireshark 的服务器。  KSII 的 MAC 地址为 a0：F6：FD：A5：E5：10

对于其他问题、是的、我们处于室温下、具有 KSII 的 IO 卡上的温度传感器均为正常温度、最高读取值为35.25摄氏度。

在我们尝试调试的情况下、由于此问题、数据包看起来没有正确格式、因此数据包永远不会输出到网络上。  因此、当这种情况发生时、我们在 Wireshark 中看不到任何内容、因为数据包永远不会将其输出到我们的网络上。

从附件文件名中删除.dat、论坛不允许我使用正常的 Wireshark 文件扩展名上传。

 e2e.ti.com/.../good_5F00_uboot_5F00_eth.pcapng.dat

在这些图中、GMII 信号(gmii_RxD_I、gmii_Rx_er_I、gmii_Rx_dv_I)相对于收发器状态调试信号(gt_rxd色 散 r_dbg、gt_nnotintable_dbg、魅力逗号、rxcharisk)延迟了几个时钟周期。  这是因为我们要在芯片范围内的不同逻辑电平将其关闭。  但是、gmii_Rx_er_I、gmii_RxD_I 和 gmii_Rx_dv_I 以同步时间显示。

在第2个和第3个图表中，我们声称第二次出现0xA5是不正确的，因为数据包中该部分的数据序列显然应该是 Keystone2的 MAC 地址。  gmii_Rx_er_I 信号有效、因为存在8b/10b 视差误差、可以在几个时钟周期之前看到该误差。  但这并不意味着与其关联的数据(0x10)必然是坏的。  这仅意味着收发器需要正或负视差编码、并且接收到相反的编码。  前一个字节可能仍然存在故障。  0xA5具有中性奇偶校验和相同的符号、用于其正编码和负编码、这意味着它不能导致视差误差。 以下是可能发生的情况：

8B   10B-10B+                    网络奇偶校验

--------------------------

0xA5 1010011010 与负      极中性点相同

0x10 0110110100 1001001001001011       零线

0xE5 1010011110 101000001       +/- 2.

在两个0xA5s 之前、我们收到的0xFD 为+1视差计数(同样的想法适用于从-1开始的情况)。  具有正确 MAC 地址的数据包的预期序列为：

0xA5 -> 0xE5 -> 0x10

0-2+0               (符号视差)

+1     -1     -1 - 1     (运行视差计数)

如果我们在中间接收到一个非法0xA5、但0x10仍然使用其正符号进行编码、就像发送0xE5一样、那么收发器可能会期望0x10的负符号、即使它具有中性奇偶校验：

0xA5 -> 0xA5 -> 0x10

0      0     +0

+1     +1 +1     +1 +1 +1

第4个图与前2个图无关。  这是一个可重复的错误、我没有任何理论依据。

K2H 是否具有在 SERDES Tx 线路上发送 PRBS 数据的功能、以便我们可以捕获眼图？

是的、从数据中提取时钟。

不过、我们认为这些症状并不表示存在信号完整性问题。  它们是可重复的、每次都会出现相同的错误。  我们还在超过16Gbps 的速率下测试了相同的高速钢通道、尽管采用了不同的夹层卡配置。

我们根据您在 E2E 上提供的数据进行了内部讨论、并查看了您的 Wireshark 日志消息。  但是、这些信息并未为我们提供足够的信息来确定问题的根源。

您提供的 Wireshark 日志仅在设备正确引导时使用。 执行 FPGA 检测到不良的数据包被过滤掉。 n`t 查看 Wireshark 日志、了解启动失败的情况、但如果在交换机上捕获数据包、并且 FPGA 过滤掉坏的 BOOTP 数据包、则日志将不起作用。 我们已经编写了一组问题、Randy 将向您提出这些问题。

同时、我们希望尝试查看我们是否可以使用我们的评估平台复制您的设置。 为此、我们需要您的引导模式设置、PG 版本、以便我们可以运行相同的测试。 我们的 EVM 已连接、以便 PHY 是自动协商模式下的主设备、K2是从设备 、因此我们可能会对我们可以尝试的操作有一些限制、但获取您的引导模式设置肯定会有所帮助。

如果您有到 KS2的 JTAG 连接、则可以运行我在这里附加的 GEL 并为我们提供日志。

e2e.ti.com/.../K2H_5F00_register_5F00_dump.gel

这将读取您部件中编程的 JTAGID、引导模式引脚和 MACID。 n`t 您没有 JTAG 连接、则可以通过读取 GEL 文件中提供的物理地址从 uboot 或 Linux 读取这些寄存器地址。

此致、

Rahul

您好、Rahul、

我运行了 GEL 文件、我还添加了几个寄存器读取： MM_REVID、 PSC_VCNTLID (存在 define、但没有读取函数)。  以下是输出：

C66xx_0：凝胶输出
C66xx_0：GEL 输出：****** Kepler EFUSE 状态和快照
C66xx_0：凝胶输出

C66xx_0：GEL 输出：DEVSTAT --> 0x02000001
C66xx_0：GEL 输出：PSC_VCNTLID --> 0x002F0000
C66xx_0：GEL 输出：MM_REVID --> 0x00090003
C66xx_0：GEL 输出：bootcfg_JTAGID --> 0x2B98102F

C66xx_0：GEL 输出：****** Kepler MACID 寄存器(MACID)****
C66xx_0：GEL 输出：MacID[31：0]-> 0xFDA5E510
C66xx_0：GEL 输出：MacID[32：47]-->0xA0F6
C66xx_0：GEL 输出：BCast[16](广播接收)-->广播
C66xx_0：GEL 输出：BCast[17](MAC 流控制)-->关闭
C66xx_0：GEL 输出：校验和[24：31]->0x6f

该会话来自 JTAG、我已将电路板引导至睡眠模式。  每当我必须使用 JTAG 调试时、这就是我引导进入的模式、这是可以的吗？  

我在该线程的早期上传了一个好启动的 Wireshark、如果这还不够、请告知我、我将重试。

当我们引导至以太网模式时，我们的引导模式设置如下所示：  

devstat：0x6CEB 引导模式：0x3675 (DEVSTAT [16：1]位映射到引导模式[15：0])

感谢提供 GEL 转储、看起来您使用的是 PG 2.0器件、而您的引导配置是

•  ARM 小端以太网引导模式。
•  SYSPLL 使用122.88Mhz 的输入时钟、而 ARM PLL 使用312.5MHz 的输入时钟。
•  外部连接被强制为最大速度。
•  156.25MHz 的参考时钟
•  PA CLK 与内核基准处于同一基准

您能否确认我们对您的设置以及链路连接的时钟理解。  

此致、

Rahul

您好、Rahul、

我们的 FPGA 对千兆位以太网使用的参考时钟源与 Keystone2相同。  我们无法使 FPGA 和 Keystone2之间的自动协商工作、这就是我们使用强制最大速度设置的原因。

FPGA 不会篡改 Keystone2发送的 CRC/FCS。  但是、FPGA 正在对数据进行解码以进行监控、然后重新对其进行编码。  由于 FPGA 认为它接收的数据包编码数据不在8b/10b 表中、因此坏字节实际上只是任意值、仍然会重新编码并传递到交换机。  当这些数据包到达交换机时、它们一定会出现 FCS 错误。  我已经在 FPGA 中实现了 CRC 来查看这一点、在良好的数据包中、我确实获得了神奇的0xC704DD7B 值。

-Jonny

我们刚刚尝试的另一项测试是在 Keystone2成功引导至 Linux 后查看以太网统计信息。  我们使用  scp 在网络上传输一些大型文件、从未看到报告任何错误或丢失的数据包。  这使人们进一步相信、从引导 ROM 运行时、Keystone2上的收发器设置可能会稍微关闭。

Rahul、dipswitch 设置为0101时不是默认启动？  我认为它不够接近我们的配置。

我对 keystone2_boot_examples 有疑问、不确定这是不是提问的正确地方。  如果我在这里写它、我们或许可以将它发送给合适的人：

在 keystone2_boot_examples 中、k2e 示例多级以太网引导使用名为 ethWard.c 的源文件、但 K2H 不使用、原因是什么？  我可以在 EVMK2H 上获取一些示例、例如单级和多级 UART。  但是、我在 K2H 多级以太网启动方面没有成功。  我无法获取评估板来下载我通过 xmodem 生成的 uartImage1.bin。  但是、使用 dipswitch 设置0100、其他 UART 示例工作正常。 我们的设计确实下载了 uartImage1.bin 文件、但之后没有任何反应。  我觉得这个示例中缺少一些东西、或者我不是很理解、而且这个 ethWard.c 在 k2e 中、但在 K2H 中不是这样、这让我感到困惑。

我是否应该为此启动单独的线程？

谢谢

————————关

Jonny、

我指的是这张图片：

此图与以太网规范不一致。  这可能会导致数据损坏、因为端口可能无法按照您期望 的方式解释数据。  如前所述、FPGA 中与 DSP 相邻的端口是 PHY 端口。  但是、如上所述、该 PHY 模块内部连接了 GMII、媒体端朝向 DSP。  (PCS 和 PMA 是媒体独立接口 端口和媒体端口之间 PHY 中的层。) 尽管您将其称为 SGMII、但它可能不是。  在我看来、它是 1000BASE-X 介质端口、而不 是 SGMII 介质独立接口端口。  有许多相似之处、但它们并不相同。  必须认识到、从电气角度来看、SGMII 接口与1000BASE-X 接口非常相似。 两者均使用8B/10B 编码、串行接口和嵌入式时钟。 但是、这两个接口位于以太网堆栈内明显不同的位置、不能混合使用。 系统可以在 SGMII 连接到媒体端口的情况下运行、但不能保证它们运行、因为它们与以太网标准不一致。   您需要一个支持 SGMII 的"AC 块"、而不是 FPGA 中的"PHY 块"。  然后、您将一个配置为 SGMII 主器件、将一个配置为 SGMII 从器件、以实现兼容接口。  我假设与交换机的连接也是如此、尽管交换机端口可能是真正的1000BASE-X 介质端口。

Tom

您好、Tom、

我不是以太网专家、因此我愿意就此进行讨论、但我不相信我们会做任何不符合以太网规范的事情。

请允许我澄清我发布的图表。  图中的所有内容都完全存在于单个电路板上、因此从技术上讲、图中的所有内容都是媒体独立的。  "1/2.5G 以太网 PC/PMA 内核"的名称可能会使您感到困惑。  它是 Xilinx 经过验证的 IP，可以配置为支持 Cisco 的 SGMII 标准或1000BASE-X，因为两者在物理层面上非常相似。  请再次注意、PC 和 PMA 与介质无关。  图中的 SGMII 和1000BASE-X 标签仅描述了这些接口与介质无关的方面。  我们不会在以太网堆栈的不同层中进行讨论。  只有在以太网交换机(Marvell 88E6185)内、我们才会移至 MAC 的下一层、只有在不同的交换机端口上、我们才会有介质相关端口(我认为是1000BASE-KX 铜背板)。

如果我们的连接不符合以太网标准、您是否认为一旦我们启动 Linux、我们就可以拥有22G 文件的无错安全副本？  我们仅在从 Keystone2的引导 ROM 执行代码时发现问题这一事实是否与您无关？

-Jonny

Jonny、

我们还有许多其他客户在生产中使用基于 SGMII 的 RBL 以太网引导的电路板。   因此、我们将探索您独特的实现方案、以确定它在 RBL 引导期间如何导致损坏的数据包。  您表示一旦启动、以太网传输就会稳定可靠。  因此、我们需要探索在失败的引导过程中您的系统有何不同。

Tom

Jonny、

不、我当时考虑过、启动后传输数据的试验 与未启动的试验之间存在一些不同。  可能是融合到不同操作点的自适应产品。  一种可能是自适应的 SERDES 均衡。  可能还有其他 自适应系统组件。

Tom