2397364_zh-CN

はい

ls1021a eTSEC 发送超时

我有一个 LS1021A 物联网芯片和一个基于该芯片的原型板。两者都使用引导加载程序。

它在物联网板上运行完美，但在我的板上，以太网端口出现TX超时错误。我发出几个 ping 请求后，发送超时，然后又发出更多 ping 请求。这使得TFTP几乎无法使用。

当然，硬件方面也存在差异。我们的 MAC 连接到 BCM54616S，然后连接到 LAN9514。自动协商的上限为 100FD。TX超时在环回模式下也会发生。

为了传输数据，我必须在我的板子上的 TBI PHY 中设置 SGMII_AN 位，而 IOT 则不需要这样做（IOT 可以协商 1000FD）。

不确定为什么TX信号如此不稳定。这是否与速度限制有关？

Re: ls1021a eTSEC tx timeout

你好，

对于 100FD SGMII，请在原型板的引导加载程序中验证以下项目：

设置 LS1021A eTSEC 用于 SGMII 100 Mbps
- ECNTRL[TBIM] = 1
- ECNTRL[SGMIIM] = 1
- ECNTRL[R100M] = 1
- MACCFG2[I/F Mode] = 01表示 10/100 模式
  LS1021A RM 特别指出，对于 SGMII 100 Mbps，应将R100M = 1 。
重置和编程内部 TBI PHY。RM 指出 SGMII 使用 TBI 寄存器集，并且对于所有接口模式（包括 SGMII）重置 TBI 非常重要。
保持SGMII_AN设置为 TBI SGMII_AN位“必须设置为 1”。因此，您的电路板只有在设置此位后才会发送数据，这并不奇怪；这表明您的引导加载程序初始化对于此 PHY/MAC 模式不完整。
不要依赖 100 Mbps 下的 1G 式 SGMII AN 行为。已知 LS1021A 报告显示，100 Mbps SGMII 操作在链路循环后会出现“SGMII 链路不正常”或间歇性无数据包行为，而 1G 操作则正常。这并不能证明您的 TX 超时的确切根本原因，但这足以证明 100FD SGMII 配置是一个强烈的怀疑对象。

回环结果很重要。如果您的“环回模式”是外部 PHY 环回或 SGMII 侧环回，则 100FD SGMII/TBI 设置仍然可能参与其中。如果是内部 MAC/eTSEC 环回，那么外部 BCM54616S/LAN9514 路径基本无关紧要，我会重点关注 eTSEC 初始化、描述符环处理、缓存一致性和 TX 停止/错误状态。

为了进行调试，请检查超时发生时 eTSEC TX 停止状态。RM 表示，当 eTSEC 不再处理来自 TxBD 环的发送帧时，会设置发送停止位；可重复出现的原因包括总线错误、无效的 BD/数据地址、无法纠正的 BD/数据读取错误以及 TxBD 编程错误，例如Ready = 1长度为0 。还要检查是否看到IEVENT_BSY ；NXP 的资料将 BSY 描述为由于缓冲区不足/软件无法足够快地服务于 BD 环而导致的 RX 帧丢失，这是一种软件/BD 环的症状，而不是纯粹的 SGMII 电气症状。

推荐的分离步骤：

1.强制外部PHY为 100FD ，如果需要，不进行铜缆自动协商。2.强制LS1021A MAC / eTSEC 为SGMII 100 Mbps ：
 TBIM = 1 ， SGMIIM = 1 ， R100M = 1 ， MACCFG2 I / F模式= 10 / 100。3. 设置 SGMII 模式后 RESET / 重新初始化 TBI 。4.设置TBI SGMII_AN = 1。
 5.确认TBI链路/ AN状态、 eTSEC ECNTRL / MACCFG2和PHY SGMII侧状态。6.超时时，转储IEVENT 、 TX停止寄存器、 DMA状态和TXBD环内容。

此致敬礼

Re: ls1021a eTSEC tx timeout

忘了说了，我的端口设置为SGMII模式。

Re: ls1021a eTSEC tx timeout

在发送函数中添加消息或 1 毫秒延迟，可以确保数据正确传输而不丢失。

我在发送函数中为 TX 描述符添加了 DMA 刷新，这很有帮助。不过，考虑到描述符是在非缓存内存中分配的，这应该不是必要的。这可能是我添加了 LPAE 支持的 MMU 库的缺陷。

现在我想起来了，很久以前我删除了 enet 设备节点中的 dma-coherent 属性，这足以让 LS1021A-IOT 工作。这样会在为描述符分配未缓存内存时强制执行 DMA 刷新。但是发送函数中没有缓存刷新，无法更新每个数据包的 TX 描述符。不确定为什么在我的原型机上不起作用（频率不同，DDR3L 与 DDR4 的区别……）

Re: ls1021a eTSEC tx timeout

您好，

感谢您提供的详细调查结果——您发现的解决方法组合（1 毫秒延迟、手动 DMA 刷新和删除dma-coherent ）是缓存别名问题的典型特征。以下是根本原因分析和推荐的修复方案。

根本原因：TX描述符区域中缓存的虚拟别名

LS1021A ENET DMA 是一个非缓存一致性总线主控器——它直接读取 DDR，无法访问 CPU 缓存。LS1021A 上 gianfar 的正确操作模型是非一致性软件管理模型：描述符分配在非缓存内存中，每当 CPU 更新描述符字段时，都会显式调用dma_sync_* 。

您的 LPAE 更改最有可能引入的是描述符物理地址范围的页表项，该条目携带错误的缓存属性——普通写回而不是设备或普通不可缓存。这为同一物理内存创建了两个具有不同缓存性的虚拟别名：分配路径（通过dma_alloc_noncoherent ）将其映射为未缓存，但发送函数中每个数据包的 TX 描述符更新路径通过缓存别名访问它。CPU 将更新后的描述符字段写入缓存行，这些字段永远不会到达 DDR，导致 ENET DMA 读取到过时的数据并出现欠载。

为什么你的三种变通方案都掩盖了同一个缺陷

1 毫秒延迟/消息插入：在低负载下，增加足够的延迟，使 CPU 回写缓冲区自然耗尽——与时间相关，在流量或频率变化时会失效。
发送函数中的手动dma_flush ：强制在 DMA 读取描述符之前执行缓存清理到 PoC 的操作——这是正确的行为，但如果该区域确实没有缓存，则无需执行此操作。
从 enet 设备节点中移除dma-coherent ：导致内核在提交之前对每个 TX 描述符调用dma_map_single() / dma_sync_single_for_device() ，从而显式地清除缓存——这也是正确的，并解释了为什么 LS1021A-IOT 无需发送路径刷新即可可靠地工作。

缺少发送路径刷新是关键所在。LS1021A-IOT 在移除dma-coherent后可以正常工作，因为内核的 DMA 映射层会自动插入同步信号；你的原型没有这条路径，因为 LPAE 的更改改变了描述符区域的缓存属性，而没有重新引入同步信号。

DDR3L 与 DDR4 的频率差异

这不是根本原因。不同的动态随机存取存储器(DRAM)类型和频率会改变写入延迟和缓冲区漏电时间，这就是为什么故障在您的原型上更明显的原因——但根本缺陷是架构上的，在足够的负载下，两个板上都会出现这种缺陷。

推荐修复方案

正确且自洽的解决方案是将以下两种方法结合起来：

将dma-coherent从 enet 设备节点中移除（非相干模型）。这导致内核 DMA 层在通过dma_alloc_noncoherent分配的描述符的 DMA 所有权转移之前自动发出dma_sync_single_for_device() 。
在 TX 发送路径中，于每个数据包上写入 TX 描述符字段（ status 、 data_length 、 data_pointer ）的位置，添加显式的dma_sync_single_for_device()调用。这是你手动添加的冲洗——但在编写TDAR之前，应该正式地将其放置为dma_sync_single_for_device(dev, desc_dma_addr, sizeof(txbd), DMA_TO_DEVICE) 。无论 MMU 如何对描述符区域进行归属，该模型都明确且正确。
另外，审核分配给 ENET 描述符使用的物理地址范围的AttrIndx / TEX+C+B字段的 LPAE MMU 库更改。描述符池应映射为 Device-nGnRnE（强有序）或 Normal Non-cacheable — 而不是 Normal Writeback。您可以通过在分配后检查描述符池的虚拟地址，使用内核的ptdump调试接口来验证实际使用的属性。

你添加的 DMA 刷新不是一种权宜之计，而是正确的机制。真正的缺陷在于它一开始就不在发送路径中，而 LPAE 的更改暴露了这一点，因为它们改变了该区域的有效缓存性。

此致