Cortex-A76（AArch64）MMU Fault时FAR_EL1寄存器值异常问询

针对你遇到的FAR_EL1有时无法正确存储故障地址的问题，结合AArch64架构规范、Cortex-A76实现特性及ThreadX场景，原因可从以下几个维度分析：

1. FAR_EL1的写入并非无条件，依赖ESR_EL1的ISS字段细节 #

你遇到的ESR_EL1值0x860000XX（EC=0x21，指令中止）和0x960000XX（EC=0x25，数据中止）仅说明异常类型，具体是否写入FAR_EL1要看ISS字段的**Fault Status Code（FSC）**及附属位：

• 对于EC=0x21（指令中止）：只有当FSC属于地址翻译类故障（如0x06=Level1翻译故障、0x07=Level2翻译故障）且未被调试事件触发时，CPU才会将故障预取地址写入FAR_EL1；若FSC是对齐错误、调试相关故障，FAR_EL1可能不会更新。
• 你调试中遇到的ESR_EL1=0x86000006，FSC=0x06属于Level1翻译故障，但如果ISS的D位（调试触发位）被置1，说明异常由调试逻辑触发，此时FAR_EL1的写入行为会被调试状态覆盖。

2. Cortex-A76分支指令触发故障的流水线特性 #

你通过bl 616e00直接跳转到未映射地址，此时CPU流水线会直接将PC更新到目标地址并触发预取故障。Cortex-A76的分支预测与流水线设计中，若分支目标地址未映射的故障发生在预取阶段而非执行阶段，部分场景下CPU可能未将目标地址写入FAR_EL1，而是仅更新ELR_EL1（记录异常发生时的PC）。这种行为属于Cortex-A76的实现细节，需参考其技术手册确认特定场景下的FAR_EL1更新规则。

3. 单步调试场景的干扰 #

你使用CodeViser单步执行时，CPU处于调试状态（DBG模式），此时调试逻辑会介入指令执行流程：

• 单步模式下，流水线被强制打断，预取故障可能被调试异常优先捕获，导致CPU未按正常MMU故障流程更新FAR_EL1；
• 调试寄存器的配置（如DBGBCR_EL1）可能修改了异常的触发优先级，使得FAR_EL1的写入逻辑被跳过。

4. ThreadX异常处理的上下文覆盖风险 #

ThreadX在EL1下的异常入口汇编代码若存在以下情况，可能导致FAR_EL1被覆盖：

• 异常处理入口未及时保存FAR_EL1，后续嵌套异常或寄存器操作覆盖了该寄存器；
• ThreadX的调度逻辑在双核场景下，若核间切换未正确隔离异常上下文，可能导致FAR_EL1被另一个核的操作改写。

排查建议 #

• 拆解ESR_EL1的完整ISS字段，确认D位（调试触发位）是否置1，区分调试触发与原生MMU故障；
• 对比非单步调试（正常运行）下的FAR_EL1值，验证是否仅调试场景出现问题；
• 检查ThreadX的异常入口汇编代码，确认未在处理前修改或覆盖FAR_EL1；
• 查阅Cortex-A76 TRM中EL1下指令中止的FAR_EL1更新规则，重点关注分支到未映射地址的场景。

内容的提问来源于stack exchange，提问作者zhj L