Cortex-A9 SMP GICC_RPR 始终为 0，中断未触发 [英] Cortex-A9 SMP GICC_RPR always be 0, interrupt not triggered

问题描述

在i.MX6Quad板上，系统运行时发现Core3无法处理任何中断.

on i.MX6Quad board, when the system running, I found that Core3 can not deal with any interrupt.

通过Trace32查看GIC接口寄存器，GICC_RPR始终为0，表示最高优先级的事件正在运行，所以解释了上面的问题:不能处理较低优先级的事件.

view the GIC interface registers by Trace32, the GICC_RPR is always 0, which means the highest priority event is running, so it explain the uppon question: lower priority event cannot be processed.

我插入了一条指令:向 GICC_EOI 写入 0，它可以将 GICC_RPR 更改为空闲优先级(0xFF)，但它不起作用，保持 0.

I have insert a instruction : write 0 to GICC_EOI , which can change GICC_RPR to idle priority(0xFF), but it doesn't work, keep 0.

我想取消优先级并停用成功.

I want to do priority drop and deactivate success.

• gic arch specf:3.2.1 优先级下降和中断停用

• gic arch specf : 3.2.1 Priority drop and interrupt deactivation

优先级下降是在有效写入时发生的运行优先级下降 >到 EOIR，要么GICC_EOIR 或 GICC_AEOIR.

Priority drop is the drop in the Running priority that occurs on a valid write > to an EOIR, either the GICC_EOIR or the GICC_AEOIR.

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

On priority drop, the running priority is reduced from the priority of the interrupt referenced by the EOIR write to either

推荐答案

将零写入 EOI 无济于事.当中断触发时，您必须读取 GICC_IAR 寄存器.你得到的值是触发的中断号.如果您处于传统模式，则必须将此中断编号写入 EOI 以退出此中断.如果您处于优先级丢弃模式，将此数字写入 EOI 会降低优先级，将相同的值写入 DI 将退出中断(检查 GICC_CTLR 以确认您的模式).希望这能消除与 RPR 和 EOI 的混淆.

Writing Zero to EOI does not help. When an interrupt fires, you have to read GICC_IAR register. The value you get is the interrupt number that fired. If you are in legacy mode, you have to write this interrupt number to EOI to retire this interrupt. If you are in priority drop mode, writing this number to EOI decreases the priority, writing the same value to DI will retire the interrupt (check GICC_CTLR to confirm your mode). Hope this clears up the confusion with RPR and EOI.

调试问题的一些提示:1. 检查 GICD_ITARGET 寄存器，看看有没有指向 CPU3 的中断.2. 确保您在 CPU3 中期望的中断(如果有任何特定内容)在分发服务器中没有被屏蔽3、查看CPU3的GICC_PMR，优先级不是太高.只有当中断优先级高于该寄存器中的值时，中断才会从分配器转发到 CPU 接口4.检查CPU3的CPU接口是否启用5. 检查 GICD_ISPEND 以查看有问题的中断是否挂起

Some pointers to debug your issue: 1. Check the GICD_ITARGET registers to see there are interrupts pointed at CPU3. 2. Ensure the interrupts that you are expecting in CPU3 (if anything specific) is not masked in the distributor 3. Check GICC_PMR for CPU3 to see that the priority is not too high. An interrupt is forwarded from distributor to cpu interface only if its priority is higher than the value in this register 4. Check CPU interface for CPU3 is enabled 5. Check GICD_ISPEND to see if the interrupt in question is pending

注意:使用 T32 调试 GIC 时要小心.T32 通过从寄存器/内存读取值来工作.这会对某些 GIC 寄存器产生不良影响，例如 GICC_IAR 寄存器只能读取一次以确认中断.进一步读取将返回虚假中断号.当连接 T32 并打开一个窗口来读取 GICC 寄存器时，这将导致一个没人能处理的孤立"中断.我建议在中断处理逻辑中放入日志以调试问题.

NOTE: Be careful when using T32 to debug GIC. T32 works by reading values from registers/memory. This has undesired effects on some GIC registers, for eg GICC_IAR register can only read once to acknowledge the interrupt. Further reads will return spurious interrupt numbers. When T32 is connected and a window is opened to read GICC registers, this will cause an 'orphan' interrupt that no one can take care of. I would suggest putting in logs in the interrupt handling logic to debug issues.

这篇关于Cortex-A9 SMP GICC_RPR 始终为 0，中断未触发的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！