This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

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

Guru**** 2540720 points
Other Parts Discussed in Thread: AM5K2E04

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1300559/am5k2e04-keystone-ii-soc-lockup

器件型号:AM5K2E04

你好。 我在 AM5K2E04中偶尔遇到 CPU 锁定、我正在尝试找出原因。

我一直在阅读 ARM 勘误表... developer.arm.com/.../

我认为最可能的候选项是814169:"在 ACE 系统中,一系列存储或 PLDW 指令在共享状态下触及 L2缓存可能会导致死锁"。

我有几个问题...

1) 1)是否合理-此 SOC 是否受此勘误表影响? 或者、是否有任何其他已知的 CPU 锁定原因?

2)如果此勘误表相关、是否有任何有关 SOC 的其他元素如何连接到 ACE 系统的信息? 除了 A15 CorePac 之外、系统中是否有缓存主器件? 哪些外设可以将 L2高速缓存的行置于所需的"共享状态"、哪个外设可以发出相关的嗅探?

3) 3)此外、芯片设计或 Linux 驱动程序中是否可以对此采取任何缓解措施? 如果是、是什么?

4)是否可以禁用 ACE 互连? (如果它修复了这些挂起、即使它意味着必须在软件中处理一致性、我也会准备这样做)。

对于上述任何问题、任何帮助都将非常有用。 非常感谢!

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    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 硬件问题、或者它是否来自您正在开发的新代码。   

    此致、
    理查德·W·
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    谢谢 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 一致性中获得帮助。  如果未设置共享、则需要进行全面的软件维护。   

    此致、
    理查德·W·
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Richard、您好!

    感谢您的澄清。 我们的 SOC 没有 DSP、也不使用超链接、因此 SOC 结构中没有外部主设备。 由于 MSMC 为 EDMA 和网络控制器等其他外设提供一致性、我认为在本例中、ARM CorePac 是唯一的缓存主器件。

    此致、
    时间

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

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

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

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

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

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

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

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

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

    非常感谢。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Tim、您好!

    在从 TI"表弟" SOC 到 AM5K 上、我看到了挂起、正如您所描述的、当 PCIe IP 计时但不存在时。  当 PCIe 不使用时钟时、其在被访问时的地址空间应该返回一个中止(故意或错误访问)、CBA 条件为空响应。  当地址空间已计时但模块未正确配置时、访问可以传入子系统、并且在某些情况下一直挂起。 在一些 SOC 上、我记得当时有人告诉我、需要对返回焊盘的环路进行配置、以便允许访问完成故障、如果没有安装/修复模块、这种访问方式不会挂起。

    一个一般经验法则是、如果系统软件不准备为 IP 安装驱动程序、那么不应为该模块的时钟计时并使其脱离复位状态。  在为模块计时并完成复位后、可以有一种特定于模块的有用方法来安全地停止 IP。  我经常看到引导加载程序认为它通过设置一组 PLL 并盲目打开所有模块时钟来执行服务、实际上这往往是一种无效现象、因为像 DSP 这样的东西可能会尝试引导至随机存储器地址。  有时、如果存储器地址倾向于指向某种存储器空间、则会导致引导时挂起。  这也可扩展到引导加载程序激光写入'0xffffff'(全部启用)来控制保留了一些位字段的寄存器。  某些情况下、保留位是未连接的逻辑、写入一些内容会导致状态不可清除或其他不良影响。

    过去、当 A15 MMU 构造不佳时、我跟踪了类似的 PCIe 范围挂起情况。  IO 范围应设置 NX 位、这样推测取数据就不会从 Cortex-A 发生。  此外、当动态更改 MMU 条目时、需要遵循"先断后合"规则、以免打开推测访问窗口。  我记得很久以前在 QNX +汽车应用程序上遇到过这样的问题、当时软件驱动程序映射了 PCI 区域而没有设置 NX。  它的悬挂是稀疏的(2天中1天)。  对于该芯片、我可以根据挂起段为 PCIe 的总线状态、在 Hang See 时通过 JTAG 进行连接。  我能够使用总线监视器来捕获循环中的事务、当它在一天后挂起时、问题是由到 PCIe 区域的 i-cache 推测取指令引起的(事务被捕捉在缓冲区中)。  在这种情况下、ICache 突发访问对于 PCI 是非法的(但 ARM 错误地猜测非 nx 存储器是合法的)、这会导致目标空间崩溃。 只需设置 MMU 以使用 io + NX 属性映射区域、便可删除挂起。

    最后、我看到安装了 PCIe 目标后挂起。  在这些情况下、目标正在向系统提供一个时钟、有时外部目标会以其提供的时钟停止的方式崩溃。  如果时钟停止、为什么 PCI 设备控制与 DDR 的事务、系统将挂起。  如果以某种方式重新启动了 PCI 时钟、则说明挂起已解决。

    我建议在运行时验证实时 MMU 表的格式是否正确。  为此、我通常使用 TRACE32 MMU 解码器、因为所有可能的格式化案例都是手工解码的重要环节。  如果没有为该范围设置 Nx、请修复它。  MMU.info

    是一种快速辨别的方法、但 MMU.list.pageable 可以显示它。  如果您动态构建表、则需要进行更多的验证工作。  我建议从 CPU 为 PCIe 范围设置某种类型的事务监控。  如果您的代码使用 virt=phys、那么一个范围监视点(2个调试比较器)可能会在代码中捕获它。  推测 访问将绕过比较器、但 captureor 可能能够捕获它。  我在 Cousan SOC 中使用了 cptracer2和 ocpwatchpoints 来检查 PCI 空间、我不确定这是否是 AM5K 中的选项。

    此致、
    理查德·W·
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

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

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

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Tim、您好!

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

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

    此致、
    理查德·W·