Thread 中讨论的其他器件:Beagley-AI
工具与软件:
尊敬的 TI 团队:
我们在 AM64x 的 PCIe 实现中遇到了有关 PTM 消息流控制的非常严重的错误。
我们得到的设置包括定制 AM64x 板和通过 PCIe 连接的 Lattice FPGA 器件(AM64x 是 RC 运行 Linux、FPGA 是 EP)。
只要 FPGA 宣布"已发布请求数据有效载荷"的无限额度、这就有效、但如果由于已发布的请求数据有效载荷额度数量有限、而启用流控制、则会导致 AM64x 在一段时间后冻结。
我们过去曾通过电子邮件与一些 TI 同事讨论过(~2022)此问题、但当时没有解决方案、甚至没有确认。 我们有权变措施、但最近对 FPGA 设计更改、因此我们无法再使用此权变措施(FPGA 现在需要流控制)。
在 AM64x EVM 上将 Intel i225用作 EP 时、也会出现同样的问题。 在 Intel Elkhart Lake x86等平台上使用时、Intel i225 NIC 可在启用 PTM 的情况下正常运行。
在多个 PTM 周期后、AM64x 完全冻结。 访问 PCI 总线的内核似乎完全卡滞、并无限期地保持卡滞(至少几分钟、管道停滞)。 我们可以通过 JTAG 调试器进入内核、但只能看到少数几个寄存器、无法访问所有存储器。 我们仍可以从另一个处理器内核(例如 R5f)或调试 MEM-AP 访问 SoC 存储器映射。
我们注意到、在 A53内核冻结之前、AM64x PCIe RC 寄存器中会设置错误位。 表示~2000个 PTM 周期后的流控制协议错误(FCPE)。 如果我们继续触发 PCIe PTM 周期、A53会在再触发几百个周期后冻结。
使用跟踪接收到的额度的 AM64x 寄存器(例如 PCIE0_I_TRANSM_CRED_LIM_0_REG)、我们可以看到 EP 为实际触发 EP 中 PTM 周期的写入返回两个已发布的数据额度:一个用于存储器写入本身、一个用于响应的消息。 跟踪我们执行的所有写入、这些导致的所有 PTM 周期(以及 PCIe 消息)以及我们从 EP 收到的所有额度、我们可以确信 FCPE (流控制协议错误)已设置完毕、因为 AM64x 相信 EP 已宣布超过2047个未决数据额度。 这是 PCIe 规范中给出的 FCPE 错误的三个原因之一、也是在这种情况下有意义的唯一原因(EP 不会宣布任一类型的无限额度、因此可以排除 FCPE 的另外两个原因)。
我们唯一的解释是、AM64x 的 RC 不会将响应的消息计入 PD 信用额度、因此从 EP 返回的信用额度会多于其所花的钱。
该错误会在 RC 发送第2048个响应的消息后准确设置。 从那时起、AM64x 似乎不再更新从 EP 收到的已发布数据额度、直到额度耗尽为止。 此时 AM64x 冻结-我想光是此就可能被视为严重错误、因为显然不存在允许中止此事务的超时。
PCIe 规范非常清楚、"带数据的消息请求"会计入已发布的数据额度限制、例如、Intel i225文档(少数支持 PTM 且已知可正常工作的设备之一)特别指出、消息会消耗已发布的数据额度。 i225文档并不区分"消息"和"带数据的消息"、但从跟踪接收到的额度的 AM64x 寄存器中、我们有理由确信 i225仅返回 PTM 响应的标头额度、以及 PTM 响应的消息的标头额度+发布的数据额度。
我已经验证了 AM67x (Beagley-AI)上也存在同样的问题。
您是否有可能弄清楚 AM64x 中使用的 Cadence PCIe IP 内核如何处理与 PCIe 流控制相关的 PCIe PTM 消息?
我愿意接受其他解释是什么原因导致了这个错误,但到目前为止,它似乎是相当确凿的。 如有任何问题、请告诉我。
此致、
Dominic