[参考译文] AM5728：Cortex-A15运行问题

您好 XIN、

-0-

从您的描述中、似乎出现了 L3互连协议违规、导致 A15挂起。  为了使 JTAG 调试器停止 A15、它必须能够转换到调试暂停状态。  在流水线中的当前指令完成之前、不能发生这种状态变化。  由于违反规定、总线将被一个总线暂停阻止。  此类问题可由硬件或软件触发。  硬件触发器往往是不稳定或电压过低或电源噪声等因素。  软件触发器往往是编程错误、例如接口超频或错误配置总线主控。   由于上下文涉及 EDMA、因此可能存在一些编程问题。 我看到一些情况、如果软件不能完全关闭 DMA 通道、就会触发一个问题。 如果代码在传输过程中重置 DSP 或 EDMA IP、而不是在关闭之前等待竞争对手、我就看到了总线挂起的情况。

在 ETB 中使用跟踪上下文是了解 ARM 在挂起之前正在执行的操作的好方法。  您可能必须手动保存缓冲区。  如果臂已挂起、则可能是最后的一些数据尚未被清空。  您还应查看每个 CPU 的 DBGPCSR 寄存器(调试 PC 采样寄存器)。  这将显示上次提交的指令航点。  我怀疑它不会出现在您的 ETB 跟踪中。 可以使用调试器 DAP (AHBtoL3)视图通过 ABP 总线或系统 L3总线读取 DBGPCSR。

转储这些地址以查看 CPU0和 CPU1的 PC。  它们可能停留在单个值上。  寄存器说明可在 ARMv7的 ARM 架构参考手册中找到。

data.dump ensd：0x54140084
data.dump ensd：0x54142084

-1-

如果 ARM 是该挂起的一方、上述步骤将有所帮助。  但是、如果其他一些内核导致了该问题、则 ARM 数据可能不有用。  为了弄清发生了什么、接下来您应该遵循 TRM 的互连章节流程图、其中显示了如何调试 L3错误。  基本上、您可以通过 JTAG 连接到 DAP 端口并读出 L3 FLAGMUX 寄存器的值。  这些寄存器是位数组、用于显示是否有任何互连目标代理(TARGS)记录了错误。  然后，您可以查看单个 TAGR 并对其进行解码，以查看有关错误的更多信息(读取、写入、导致问题的主控方、尝试写入的地址...)。   对于 CCS、您应确保"显示隐藏目标"以连接到 DAP。  如果您使用的是 Lauterbach 的 TRACE32之类的器件、则只需使用"E"限定符(如上文所述)即可直接检查 TRM 物理地址的寄存器。  如果您的代码运行不正常/不成熟、但它可能已经进行了几次错误写入、这些写入记录在这些寄存器中。  在这种情况下、可能需要清除一些错误、然后才能看到最后一个错误、因为状态只有1个深。

此致、

Richard W.

我们只使用 A15的 CPU0、读取 dbgpcsr 寄存器的值、每次 A15崩溃时该值都不同。 附件中有提取的 ETB 数据、我们在 第218行中标记了我们认为异常的位置 e2e.ti.com/.../ETB-data-2020_2D00_11_2D00_11.xlsx、它是否有用？

2.当 ARM 崩溃时、我们连接仿真器并检查内存以找到以下内容：

CLK1_FLAGMUX_CLK1_1 L3_MAIN  L3_FLAGMUX_REGERR0寄存器（0x4480 350C）值：0x00020800。
L3_FLAGMUX_REGERR1寄存器（0x4480 3514）值：0x00000000。

CLK1_FLAGMUX_CLK1_2 L3_MAIN  L3_FLAGMUX_REGERR0寄存器（0x4480 360C）值：0x00000004。
L3_FLAGMUX_REGERR1寄存器（0x4480 3614）值：0x00000006。

CLK2_FLAGMUX_CLK2_1 L3_MAIN  L3_FLAGMUX_REGERR0寄存器（0x4500 020C）值：0x00000000。
L3_FLAGMUX_REGERR1寄存器（0x4500 0214）值：0x00000005。

通过查看 TRM、可以分析出它可能与 GPMC 总线相关、这是对的吗？  我们的 AM5728通过 GPMC 总线连接到 FPGA。 MMU 应如何配置 FPGA 的映射关系？ 我们不太清楚此配置是否会影响 L3总线。

非常感谢您的帮助！

此致、

XIN LUO

您好 XIN、

关于1) ETB：

如果跟踪与符号关联、可能会更有意义。  逻辑上下文可帮助您了解正在发生的情况。  在查看操作码级别时、我倾向于查找不常见或敏感的指令、例如缓存和 MMU 操作。   该跟踪主要用于常见指令。  在几个地方、使用的跟踪解码器失败、这会引发一个问题、即内核是否提取了垃圾、或者它只是一个解码器问题。  由于没有自动关联的符号、我猜使用的流速可能会稍微不够成熟、这可能是由于解码器造成的。

此致2)  

报告了几个 L3错误(失败的事务)。  其中任何一个都可能是宝贵的线索。  其中可能有2/3来自早期代码、不有用。  在开始挂起的代码序列之前、应确保清除所有现有错误。  通过向 TARGs "L3_TAGR_STDERRLOG_MAIN "寄存器写入 A 可以清除 TAGG 错误。 一些事务错误是良性的、是错误编程序列的结果。  我看到的一个示例是、在正确设置 DMA 基座之前有人打开了显示屏、通常、这些取指令会寻址空穴、但如果存储器以不同的方式出现、它们可能会发生在更敏感的区域。

REGERROR1日志来自调试状态。  这通常来自您或调试器、他们会探测到一些不安全的空间。  REGERR0是要挖掘的数据。

CLK1_FLAGMUX_CLK1_1 L3_MAIN  L3_FLAGMUX_REGERR0寄存器（0x4480 350C）值：0x00020800。  

 BIT17 = PCIe SS2

 BIT11 = GPMC

CLK1_FLAGMUX_CLK1_2 L3_MAIN  L3_FLAGMUX_REGERR0寄存器（0x4480 360C）值：0x00000004。

 位2 = CLK1_TIMEOUT

根据上述信息、您的挂起"可能"是由于 PCIe 链路造成的。  对于 PCIe 挂起、常见的问题涉及总线事务期间远端时钟停止、链路丢失状况恢复不良或 PCI IO 空间中的致命 A15推测取数据。  推测取指令是由于 MMU 表格式不正确而导致的、这些表不会将 IO 区域标记为 NO-EXEC。  在我的记忆中、我可以认为每个类别中的几个故障是最终的根本原因。

GPMC 也可能会有问题、但更常见的情况是没有问题。  GPMC TAGR 是一个"集合"点、用于查找没有其他主目录的错误。  写入地址空洞将在 GPMC Targ 结束。  值得注意的是、如果 GPMC 时钟未启动、当互连错误逻辑试图处理错误写入时、可能会发生挂起。   

您应该查看 FLAGMUX 超时寄存器以查看哪个 TAGG 发出超时。  此超时意味着65K L3周期已通过一个停止的内联事务。  这很可能会指向卡死的 PCI。  但它可能是其他的东西。

MMU 修复是最简单的修复、只有几行代码。  PCI 可能会更困难。  您可能需要分解 PCI 总线分析器。

此致、
Richard W.

你(们)好、Richard

   我们不使用 PCIe 总线。

此致、

XIN LUO

您好 XIN、

也许有些代码会打开它的时钟。  转储 PRCM 寄存器是一个好主意。  如果使用 TI CTT 工具、则可以使用其 GEL 或 CMM 脚本提取常用时钟。

此致、
Richard W.

您好、 Richard、

为了降低功耗、我们关闭未使用内核(如 DSP)的电源域。 当我们今天进行测试时、我们发现当我们读取 DSP 的地址(读取0x40d00000)时、将会发生崩溃、这与我们的应用程序崩溃相同。 如果我们不关闭 DSP 内核的电源域并读取0x40d00000、则不会发生崩溃。

基于此，我们修改了应用程序，而不关闭其他内核的电源域。 运行超过10小时后、没有发生碰撞。 以前 、应用程序将在一小时内崩溃。 但是、L3标志复用寄存器上仍有一些错误消息。

你有其他建议吗？

此致、

XIN LUO

您好 XIN、

很高兴知道您已取得一些进展。

从实验中可以看出、为模块断电的代码可能不会对至少一个模块以干净的方式执行此操作、这会导致挂起。  跳过某些系统问题(就像您在 DSP 实验中所做的那样)是一件非常简单的事情。  DSP 本身可能是也可能不是您的代码中的问题、因为许多来源可能会消除类似的最终症状。  通常、如果某个域从未计时或复位、则很可能很容易将其关闭。  但是、一旦启动域、通常应遵循一个序列以安全地将其停止。   很多时候、我看到引导加载程序会将一组时钟作为"服务"而不会真正考虑后续影响。  提前半使能 DSP/C66是触发稀疏引导故障并具有高于所需功率的好方法。

确保已从其 PRCM 控制寄存器启用 GPMC 模块时钟。  正如我提到的、它需要一个时钟来正确记录进程地址空洞访问的错误。  在产品开发过程中清除 L3错误是最佳做法。  应启用 L3错误中断、以便随着代码的推出、您可以快速找到修复错误、而不是尝试在最终生产过程中找到并修复所有错误。

此致、

Richard W.

您好、此致、

     我们如何启用 L3错误中断，哪些寄存器需要配置？

此致、

XIN LUO

您好 XIN、

有关如何设置此设置的示例代码、请单击此处：

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/bus/omap_l3_noc.c?h=v5.10-rc4

该链接中编入的大纲如下所示：

L3互连级屏蔽寄存器需要启用中断生成。

ARM GIC 有一个 APP 中断、需要启用此中断以获得关于"系统级 L3问题"的通知。  A15是"管理器"。

如果 ARM 接收因对物理总线的不良访问而中止的数据、则需要取消屏蔽 ARM 的 CPSR.A 位。  其他启动器需要启用它们的事务错误中断才能在直接路径上看到它。

通常、SERROR 直接传送(但延迟- aka 异步-不精确中止)回引发问题的发起方。  这可能会导致一些本地错误状态和本地中断流(例如导致物理中止的 DMA)。  同时，该路径的 L3-TAGR (目标代理)将捕获错误信息并在 L3 REGGERR0中设置状态。  如果相应位为屏蔽位、则中断信号将发送给 A15。  如果设置为服务 IRQ、您的应用程序现在可以记录事件。  使用日志、您可以在运行时修复代码。

此致、

Richard W.

此致、

Richard W.

您好 XIN、

感谢您反馈您的结果。  很高兴它看起来是固定的。

此致、
Richard W.