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

问题描述

上下文

在i.MX6Quad​​板，当系统运行时，我发现CORE3不能处理任何中断。

查看由TRACE32的GIC接口寄存器，GICC_RPR始终为0，这意味着最高优先级事件正在运行，所以它解释uppon问题：较低优先级的事件不能被处理

问题

我有插入指令：写0 GICC_EOI，可以改变GICC_RPR空闲优先级（0xFF的），但它不工作，保持0

。

目标

我想要做的优先级降和取消成功。

参考

• 的 GIC拱specf 的：3.2.1优先级降和中断停用

  

优先级为是，在一个有效的写操作发生在运行的优先级下降>到EOIR，无论是
  GICC_EOIR或GICC_AEOIR。

  
  

在优先下降，运行优先级是从的优先级降低
  中断由引用
  EOIR写为

解决方案

写入0到EOI于事无补。当中断火灾，一定要仔细阅读GICC_IAR寄存器。你得到的值是引发该中断号。如果你是在传统模式下，你必须写该中断号EOI退休中断。如果你是在优先丢弃模式，写这个号码EOI降低优先级，写相同的值DI将退休中断（检查GICC_CTLR确认您的模式）。希望这清除了RPR和EOI的混乱。

一些指针来调试您的问题：
1.检查GICD_ITARGET寄存器看到有中断指着CPU3。
2.确保您在CPU3期待中断（如果有的话特定的）是不是在掩盖总代理
3. CPU3检查GICC_PMR看到，优先级不会太高。中断是由经销商转发到CPU接口仅当它的优先级高于该寄存器中的值高
对于CPU3 4.检查CPU接口启用
5.检查GICD_ISPEND，看是否有问题的中断正在等待

注：使用T32调试GIC时要小心。 T32的工作原理是从寄存器/存储器读取值。这不希望一些GIC寄存器效果，如GICC_IAR寄存器只能读一次承认中断。进一步的读取会返回伪中断号。当T32连接，并打开一个窗口阅读GICC寄存器，这将导致孤儿的中断，没有人可以照顾。我建议把在日志中的中断处理逻辑调试的问题。

Context

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

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.

Question

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.

Goal

I want to do priority drop and deactivate success.

References

• gic arch specf : 3.2.1 Priority drop and interrupt deactivation

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.

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

解决方案

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.

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

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屋！