[参考译文] AM5K2E04：KeyStone II SOC 锁定

Tim、您好！

CPU 锁定可能由多种原因造成。 您能否共享发生锁定时看到的日志？ 此外、您能否说明 CPU 上运行的是什么软件 SDK 以及由谁提供？

请注意、这是一个非常旧的 SOC、我们没有听到任何其他来源的锁定问题。

谢谢。

大家好。 感谢你的帮助。 是的、确实、CPU 锁定的原因似乎有多种。 此勘误表似乎是可能的候选对象，这就是为什么我们希望更多地了解 SOC 中的元素如何连接到 ACE，以便我们可以确认或拒绝可能性。

关于您的问题...

我们正在使用 ARM GNU 工具链编写我们自己的软件格式草稿： developer.arm.com/.../GNU 工具链

锁定发生时不会记录任何内容、因为之前似乎没有任何 CPU 将锁定的警告。 我们试图通过 JTAG 进行调试、但 JTAG 无法对任何 CPU 内核执行任何操作-可能是由于锁定所致。 我们可以访问程序计数器、但它们不会提前-每个内核都卡住。 PC 表明、大多数锁定发生在队列管理寄存器访问周围、但偶尔我们会看到它发生在其他寄存器访问-例如 GIC 或 EDMA 寄存器访问周围。

在我看到的所有情况中、禁用 INT 后似乎都会发生这种情况、但这可能是巧合、因为这些寄存器访问通常发生在中断处理程序中。

您好、感谢您提供的详细信息。 我会传递我们的专家，就这方面提出他们的意见。 请耐心等待。

谢谢。

您好！

如您所说、冻结的 Cortex-A 是在新系统开发过程中发生的。  根本原因往往是内存事务卡住且无法完成。  如果其电力输送网络由于容量问题或噪声而出现功率骤降、则可以由电路板触发。  快速检查是将主轨电压提高大约10%、并查看问题是否有效或速率是否变化。  另一种方法是减慢时钟速度、使其满足大电流消耗者的需求、如4xARM。 如果某个外设被错误编程(比如快速发送时钟或在未事先缓慢取消配置活动接口的情况下发出一些本地复位)、则可能会出现另一个问题、这可能会导致事务无法正确完成、并且 ARM 可能会挂起等待。   调试器可以帮助您找到其中一些、调试器可以获取用于 A15内核的 PC、这似乎您已经在这样做了、如果您使用 ETM、您可以了解到相当多的挂起历史。  另一个要做的事情是在 A15失速时、将调试器连接到 DAP (如果是 CCS 或其他 JTAG 调试器的其他方法、则为隐藏的目标)、并探测从器件地址空间。  如果您轻触"发现从器件已崩溃"(所有总线错误)、它应该处于活动状态、那么它的崩溃可能就是 ARM 卡住的原因。  合理的代码审核。   如果您编写了自己的 MMU 代码、则应检查这一区域、创建不良的可分页可能会导致提取到某个不正确的区域、这也可能会触发挂起。  是的、勘误表也可能导致挂起、但上面列出的其他源往往更有可能发生挂起。  您可以尝试运行某种商用成熟代码(例如 TI 参考 Linux 图像)来查看它是否在您的电路板上挂起。  这可能有助于解决它是否出现某种电路板 PDN 硬件问题、或者它是否来自您正在开发的新代码。   

谢谢 Richard。 这非常有帮助。 我们将在第一个实例中研究 SOC 和 RAM 的功耗和时钟、看看这是否有用。

最后一个问题- SOC 中的任何其他组件是否充当 ACE 内的缓存主设备、或者 ARM CorePac 是唯一的缓存主设备？

非常感谢。

Tim、您好！

ARM 复杂系统(ARM 内核+ SCU + L2)提供集群内部的完全数据一致性、并根据需要向 MSMC2发送一致性消息。  MSMC2互连为标记有可共享属性的事务提供一致性服务。  这使得 IO 与系统中的其他主器件具有一致性。  例如、EDMA (它自己没有缓存)可能会触发(由于 MSMC2)一致性流量、这可以强制 ARM 写出脏数据、或者如果 MSMC2中有一个更新的副本、则会导致 ARM 重新获取数据。   MSMC2具有用于 DDR 地址空间以及其中包含的共享 SRAM 的跟踪资源。   来自 ARM、标记为共享参与的交易、非共享的交易会绕过该交易。  其他主器件通过对 MPAX 区域编程来设置共享属性。 C6x DSP 具有嵌入式 MPAX 阵列、SOC 结构中的外部主器件在每个互连端口 MPAX 阵列的基础上添加或不添加共享。 这种级别的 IO 一致性使 ARM 不再需要 对共享数据进行数据缓存操作、并降低另一个内核可能需要执行的操作量。  具有本地高速缓存的 DSP 仍然必须执行一些高速缓存操作、但其功耗更低、因为它还可以从 IO 一致性中获得帮助。  如果未设置共享、则需要进行全面的软件维护。   

您好、Richard。 再次感谢您对此提供的帮助。

我们还有一些进一步的信息。 我们的板将 PCIe 总线连接到可选 NVMe 硬盘驱动器的插槽。 我们发现：

1)将 CPU 超频到1.6GHz 会显著增加冻结速率。

2)降低 CPU 时钟并不意味着停止冻结。 (冻结很少见且零星、因此很难知道它们的患病率是否随着时钟频率下降而发生变化)。

3)适配 NVMe 驱动器可显著降低冻结速率,即使超频至1.6GHz(可能可以完全消除冻结,但确定还太早)。

4)安装 NVMe 驱动器也会增加我们0.85V 电源上的噪音-我提到这是为了补充,虽然可能是不相关的,因为我们期望噪音会使事情变得更糟不好。

5)如果我们完全不给 PCIe 子系统上电,那么我们就会大大降低死机的速率,但在没有安装 NVMe 驱动器的情况下,死机的情况还是很少发生的。

您有什么建议、为什么安装 NVMe 驱动器或不启用 PCIe 会使我们的系统更加稳定？

非常感谢。

谢谢 Richard、他人非常乐于助人。 关于在没有器件时不为 PCIe 计时的问题、数据表指出有多个时钟、因此我想我们需要确保不为其中任何一个计时。 我们尚未在 LSPC 中启用 PCIe、也未设置 PCIe 串行器/解串器-这是否足以确保其不会引起问题？ 或者我们应该明确执行重置 PCIe 串行器/解串器通道和/或禁用串行器/解串器 PLL 之类的操作？ 还有事吗？

在 LSPC 中未启用和未设置 SerDes 在某些情况下似乎有用、但我们仍然看到一些挂起。 因此、这不是禁用 PCIe 的正确方法、或者我们还有另一个单独的问题。

Tim、您好！

IP 启动通常只有几个正确的初始化排序步骤。  以最佳的任意顺序执行这些步骤会导致单独的故障、而最坏的故障会导致更广泛的系统问题。 TRM (还有希望出现的示例代码)通常记录我们测试的内容以及应该有效的内容。  我们不会查找并记录所有负组合。  因此、我想说如果你不使用一个模块、将其所有资源置于安全启动停止状态。  如果您尝试对现有代码进行极少的改动、则目标时钟会阻止流量的前端、以便互连停止入站流量。

具有多个长期寿命问题是一个重要的产品、在我的采样中很常见。  通常、新代码或新条件会出现各种类型的问题。 在解决所有常见错误后、几个很难找到长期存在的问题。  我不知道有任何微不足道的成功(大量、 在市场中积极使用)系统没有斜坡时间耐久性问题。   对于系统挂起、通常可以"连接"您希望处于活动状态的 JTAG TAP 控制器和探测从器件地址(使用调试子系统的 DAP 端口启动器：用于 KS2的 AHP-AP)。  使用这些探头、有时您可以找出挂起的程度、并使用这些信息制作实验 和审查、以解决或解决问题。