Arm Cortex-A9 SMP GICC_RPR始终为0，未触发中断 上下文

在i.MX6四块板上，当系统运行时，我发现Core3无法处理任何中断

通过Trace32查看GIC接口寄存器，GICC_RPR始终为0，这意味着最高优先级的事件正在运行，因此它解释了uppon问题：无法处理较低优先级的事件

问题: 我插入了一条指令：将0写入GICC_EOI，这可以将GICC_RPR更改为空闲优先级（0xFF），但它不起作用，保持0

目标 我想做优先级下降和停用成功

工具书类

• gic arch规范：3.2.1优先级下降和中断停用

Priority drop是对EOIR的有效写入>时发生的运行优先级下降，或者 GICC_EOIR或GICC_AEOIR

在优先级下降时，运行优先级将从 被引用的中断 EOIR可写入其中一个

---

将零写入EOI没有帮助。当中断触发时，您必须读取GICC_IAR寄存器。您得到的值是触发的中断号。如果您处于传统模式，则必须将此中断号写入EOI以取消此中断。如果您处于优先级下降模式，将该数字写入EOI将降低优先级，将相同的值写入DI将取消中断（检查GICC_CTLR以确认您的模式）。希望这能消除与RPR和EOI的混淆

调试问题的一些指针： 1.检查GICD_ITARGET寄存器，查看是否存在指向CPU3的中断。 2.确保在分发服务器中未屏蔽CPU3中预期的中断（如果有任何特定的中断） 3.检查CPU3的GICC_PMR，查看优先级是否过高。只有当中断的优先级高于该寄存器中的值时，中断才会从分配器转发到cpu接口 4.检查CPU3的CPU接口是否已启用 5.检查GICD_ISPEND，查看相关中断是否挂起

---

注意：使用T32调试GIC时要小心。T32通过从寄存器/存储器读取值来工作。这对某些GIC寄存器有不希望的影响，例如GICC_IAR寄存器只能读取一次以确认中断。进一步读取将返回虚假的中断号。当连接T32并打开窗口读取GICC寄存器时，这将导致无人能处理的“孤立”中断。我建议在中断处理逻辑中加入日志来调试问题。

谢谢您的方法，先生，我按照建议检查了GIC的寄存器，发现问题是SGI0始终保持活动状态，不能变为空闲状态，因为它的优先级最高，核心看起来像死的。这是转储的信息，我不明白为什么GICC_IAR=0x3FF而EOIR=0&GICC_RPR=0&GICC_HPIR=0，这些状态是如何产生的？

ICCICR=1

iccpcr=F0

ICCBPR=2

ICCIAR=3FF

ICCEOIR=0

ICCRPR=0

ICCABPR=3

ICCIIDR=3901243B

ICDDCR=1

icddr=64ICDICERn[0]=FFFF

ICDICERn[0]=FFFF

ICDIPRn[0]=1

icdicrn[0]=1

ICDIPRn[0]=0

ICDIPRn[0]=08080808

icdicrn[0]=aaaaaa

ICDSGIR=0

在触发中断后，GIC\u IAR只能读取一次，以获得实际中断号。之后，读取的信息将返回“伪中断”编号；在您的情况下是0x3FF。这就是为什么我要求您不要使用T32来调试GICC问题。EOIR是一个写寄存器，我不明白读取它的值有什么意义。你能证实我在回答中第2段提到的实验结果吗？是的，结果如下：1。ICDIPTRn[0]=0808080808H，08H表示在Core3 2上绑定。SGI0不能根据手册**3.**GICC_PMR=0xF0屏蔽，优先级低于0x0**4.**ICCICR=1，表示GIC接口已启用**5.**ICDISPRn[0]=1，是的，SGI0处于挂起状态，而GICD_ISACTIVERn[0]=1，这意味着SGI0处于活动状态。也许我做了一些事情，导致GIC进入不可预测的状态？例如，写入EOIR值与从IAR寄存器读取的最后一个有效中断值不匹配。我找到了临时解决方案：避免由除core0之外的其他内核发送SGI。