ARMv7双核心SOC中GICv2 GICD_ITARGETSRn设多1引发系统崩溃及中断分发问题

1. 直接设置GICD_ITARGETSRn为011b的错误性 #

GICv2中，GICD_ITARGETSRn寄存器的每个中断目标字段为4位，每一位对应一个CPU接口的SPI中断接收使能。如果将某个中断的目标设为011b（即bit1和bit0置1），意味着该中断会同时发送到两个核心，触发两个CPU并行执行同一个中断处理函数。这种情况下，若中断处理涉及共享资源操作且无同步机制，必然引发竞争条件，直接导致系统崩溃——这就是你当前问题的核心原因。

2. 实现单个IRQ分发至多核心且仅单CPU处理的关键要点 #

（1）GICv2层面配置 #

• 依赖GIC的自动仲裁分发机制：
  • 配置GICD_CTLR的ARE_NS位（非安全世界bit1）为1，此时SPI中断会根据各CPU的当前优先级状态（由GICC_PMR和GICC_BPR控制），自动分发到优先级最高的空闲CPU，确保同一个中断仅被一个核心接收。
  • 不要为中断设置多个目标CPU，而是将GICD_ITARGETSRn对应中断的目标字段设为0（或任意单个CPU），让GIC的仲裁逻辑自动选择处理核心。
• 正确配置中断优先级：
  • 通过GICD_IPRIORITYRn设置中断的优先级值，确保其高于各CPU的GICC_PMR（中断优先级掩码），保证中断能被正常分发。
• 确保CPU接口配置正确：
  • 每个核心的GICC_CTLR需置位bit0（启用中断接收），并设置合理的GICC_PMR值，允许目标优先级的中断进入。

（2）RTOS内核与中断处理同步 #

• 利用AliOS-Things的多核中断亲和性API：
  • 检查AliOS-Things是否提供irq_set_affinity或类似接口，可指定中断的目标CPU集合，结合RTOS的内核调度逻辑，确保中断仅在集合中的一个核心处理。
• 中断处理函数的同步保护：
  • 在中断处理入口处，使用原子操作检查并设置"中断正在处理"标志，若标志已置位则直接退出；处理完成后再清除标志。
  • 涉及共享资源的代码段，必须用自旋锁（中断上下文不可休眠，不能用信号量）保护，避免多核并发访问导致的数据损坏。

（3）避免竞争条件的核心原则 #

• 永远不要让同一个中断同时触发多个核心的中断处理流程，除非你能保证所有核心的处理逻辑完全无共享资源且互不影响。
• 依赖GIC的硬件仲裁而非手动设置多目标CPU，是实现"分发至多核但仅单CPU处理"的最可靠方式，硬件层面的仲裁能避免软件层面的同步延迟问题。

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