工具/软件：
您好！
18个月后(!) 我想我会发布更新、因为我们似乎已经解决了我们的问题。 也许这些信息对其他人很有用。
我们 SOC 锁定的根本原因是埋在我们的 MMU 代码中的错误。 有时、我们加载了一个错误的表条目、而该条目应该是空的(页面错误)条目。
这可能会导致 CPU 内核锁定、但(直到我们发现原因)我们很难在测试条件下重新创建。 当我们以特定方式更新我们的内存映射时、它在一些实际使用模式中很少出现。
需要注意的一些有趣的事情...
中断的表条目涵盖了 MMU 表本身的物理地址。 我没有证据表明我们曾经损坏过 MMU 表、但我不确定、因为内核锁定后、我只能检查 RAM、无法知道 CPU 缓存中有什么内容。
这种不正确的表条目可能导致同一个虚拟地址最终可能被两个 TLB 条目引用(作为非全局2MB 区域和具有特定 ASID 的4K 页)。 我进行了大量测试、我确信当页面表不正确时、我们的代码实际上从未访问过受影响的虚拟地址(或任何附近的地址)。 因此、如果我们最终得到了多个 TLB 条目、我只能假设这是由于某种推测性的预加载到 TLB。 它不是显式存储器访问。
通过故意将表条目重写为反复错误、然后纠正、我能够触发锁定以及其他奇怪的症状、例如数据访问故障-包括同步和异步总线解码错误和访问权限故障。
我们最初认为问题与 PCIe 总线有关、因为当 SOC 锁定时、PCIe 寄存器通常无法通过 JTAG 访问。 当我们禁用 PCIe 时、这使我们的系统极其稳定。 但是、修复我们的 MMU 代码消除了我们在使用 PCIe 时遇到的所有问题、因此我现在认为这是一个症状、而不是原因。 似乎我们出现故障的 MMU 表可能会导致随机总线访问、包括对 PCIe 寄存器的访问。
为了完整起见、我要提到在执行测试时、我们还发现可以通过另一种方法产生非常类似的症状：在软重启后通过重新配置10GB 以太网硬件来锁定 CPU。 SOC 器件勘误表中记录了这一点、并且似乎与我们的 MMU 问题无关。
最后,我想对理查德·伍德拉夫的帮助和见解表示非常感谢,没有他的帮助和见解,我们可能永远不会解决这个问题。
祝你一切顺利、
Tim
