当 AXI 事务回复错误时关闭或处理数据中止

Posted 2023-02-22

【中文标题】当 AXI 事务回复错误时关闭或处理数据中止

【英文标题】：Dismiss or Handle Data Abort when AXI transaction replies an error

【发布时间】：2018-12-17 03:16:29

【问题描述】：

背景

我有一个 ZynqMP 系统，它有四个 Cortex-A53 内核 (PS) 以及 FPGA 逻辑 (PL)。它们通过 AXI 总线传输数据。

我在我的设计中放置了一些 Xilinx AXI Quad SPI。在 PS 上运行的 Linux 成功探测到它们，并启动一个守护进程，该守护进程定期（333 Hz）要求 SPI 上的 MCU 回复其数据块（最多约 500 个字节，每 64 个字节拆分一次。）

它们在一段时间内运行良好（中值 50 分钟），但突然readl_relaxed() in SPI driver 导致同步外部中止，导致内核恐慌。根据ARM TRM，这似乎是 AXI 的错误回复，并且可能是可恢复的，因为它是“同步的”，这意味着寄存器没有损坏（在我的理解中）。

经过一番搜索，我找到了处理 SEA 的do_sea() func，还发现根据实现没有机会从中恢复。

我希望将 AXI 错误处理为：丢弃读取、返回 SIGBUS 并导致进程被杀死等。

当然我正在调试 Abort 并找出它发生的原因，但目前我不知道。

问题

所以我的问题是：

为什么 SEA 在 Linux arm64 实施中不可恢复？ 如果我可以“处理”或“忽略”它，我该如何修改 Linux 内核代码（我知道这很愚蠢，但我想知道是否有办法。） Quad SPI IP 中的什么可以回复错误？我上面提到的readl_relaxed读取Rx数据FIFO。

【问题讨论】：

完全不相关的注释：您在个人资料中引用的 C++1x 现在是 C++11。

【参考方案1】：

1) 我从来没有冒险走这条路，但在我看来，如果 inf->fn 返回 0，它们是可以恢复的；这意味着 ghes_notify_sea() 必须返回 0；因此，其中一个 SEA 错误源成功报告了错误。

2) 我认为您需要更多信息。我会从改变开始 驱动程序/acpi/apei/ghes.c:732

from:
rc = ghes_read_estatus(ghes, 0);
to:
rc = ghes_read_estatus(ghes, 1);

当错误发生时，它应该会为您提供更多信息。 有了这些信息，您需要确定您的处理程序是否出现故障或丢失。无论哪种方式，这都是解决问题的地方。

3) 您正在处理 ACPI 实现。内核中有 155 kloc 加上固件和硬件中的未知数量。内核代码似乎无法处理您遇到的任何情况。首先，您需要确定其中涉及哪些嫌疑人以及哪些交互失败，然后才能找出根本原因。

快乐挖掘！

【讨论】：

感谢您的详细建议。我将尝试获取有关中止的更多信息，然后深入研究 ACPI impl。