在 ARM CPU 上启用外部中止 [英] Enabling external aborts on an ARM CPU

问题描述

来自 Cortex-R 参考手册，^{可能不是 Cortex-R 特定的}

异步中止屏蔽

异步中止的性质意味着它们可能在处理器处理不同的中止时发生.如果在这种情况下异步中止生成新异常，r14_abt 和 SPSR_abt 值将被覆盖.如果在将数据推送到内存中的堆栈之前发生这种情况，则有关第一次中止的状态信息将丢失.为了防止这种情况发生，CPSR 包含一个掩码位，即 A 位，以指示不能接受异步中止.当 A 位被设置时，发生的任何异步中止都由处理器保持挂起，直到 A 位被清除，当异常被实际发生时.A 位在中止、IRQ 或 FIQ 异常发生和复位时自动设置.只有在状态信息已堆叠到内存中或不再需要状态信息后，才能清除中止处理程序中的 A 位.

The nature of asynchronous aborts means that they can occur while the processor is handling a different abort. If an asynchronous abort generates a new exception in such a situation, the r14_abt and SPSR_abt values are overwritten. If this occurs before the data is pushed to the stack in memory, the state information about the first abort is lost. To prevent this from happening, the CPSR contains a mask bit, the A-bit, to indicate that an asynchronous abort cannot be accepted. When the A-bit is set, any asynchronous abort that occurs is held pending by the processor until the A-bit is cleared, when the exception is actually taken. The A-bit is automatically set when abort, IRQ or FIQ exceptions are taken, and on reset. You must only clear the A-bit in an abort handler after the state information has either been stacked to memory, or is no longer required.

我的问题是，如果我在重置后将 A 位屏蔽了，我怎么知道 异步中止 是否正在挂起?可以在不取消屏蔽 A 位并接受异常的情况下清除挂起的外部中止吗?或者更一般地说，是否有关于在重置后清除 A 位的建议?

My question is, if I have the A bit masked since reset how can I know if an asynchronous abort is pending? Can pending external aborts be cleared without unmasking the A bit and taking the exception? Or more generally, is there advice on clearing the A bit after a reset?

显然我当前启动链中的某些东西有一个未决的外部中止(但仅在硬启动后).我想启用外部中止，但对于特殊情况异常代码中的第一个外部中止来说似乎相当麻烦.

Apparently something in my current boot chain has a pending external abort (but only after a hard power on). I would like to enable the external aborts, but it seems rather cumbersome to special case the first external abort in the exception code.

推荐答案

在实现安全扩展的系统上，中断状态寄存器 ISR 可以告诉您是否有外部中止待处理.遗憾的是，如果您使用的是未实现它们的 R4，这并没有多大帮助.

On a system that implements the security extensions, the Interrupt Status Register, ISR, can tell you if there's an external abort pending. Sadly this doesn't help much if you're on R4 which doesn't implement them.

否则，我在架构中看不到任何东西来识别或处理中止，除非像您说的那样采取异常.这并不让我感到惊讶 - 一般来说，可以安全地忽略的外部因素非常是一种特殊情况.

Otherwise, there's nothing that I can see in the architecture to identify or deal with an abort short of taking the exception as you say. This doesn't really surprise me - in general an external about that can be safely ignored very much is a special case.

如果系统中的错误无法修复(引导加载程序是否以错误的顺序探测设备，或类似的?)那么解决方法，无论多么繁琐，都是当务之急——如果有一些相当简单的方法来解决从热重置告诉冷启动我可以想象一个非常简单的独立垫片来处理它，所以主代码永远不需要知道.

If the bug in the system can't be fixed (is the bootloader probing devices in the wrong order, or similar?) then a workaround, however cumbersome, is the order of the day - if there's some reasonably straightforward way to tell a cold boot from a warm reset I can imagine a pretty trivial self-contained shim to handle it so the main code never needs to know.

这篇关于在 ARM CPU 上启用外部中止的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！