RK3328(ARMv8)裸机系统触发GICv2 ID1023中断导致开发板冻结问题求助

问题根因说明 #

GIC返回ID 1023属于伪中断（Spurious Interrupt），通常出现在中断请求被触发后、CPU应答前中断源已经被撤销，或者GIC配置、中断处理流程存在错误的场景，你当前的问题核心是中断处理流程顺序错误，同时缺少伪中断的兼容处理。

解决步骤 #

• 第一，修正GIC中断处理的执行顺序
  你现有代码中是先写GIC_EOI寄存器通知GIC中断处理完成，再执行VOP的中断处理逻辑，这个顺序完全错误。此时VOP的中断标识还未被清除，仍然持续向GIC发送中断请求，会导致GIC状态混乱，极易触发伪中断。
  必须调整为「先处理外设中断、清除外设中断标识，最后再写GIC_EOI寄存器」，修正后的参考代码：

irqstat = REGW(GIC_BASE+GIC_CPU_INTACK);
irqnr = irqstat & GICC_IAR_INT_ID_MASK;
if(irqnr > 15 && irqnr < 1020){
    if(irq_map[irqnr])
        irq_map[irqnr](); // 先执行VOP中断处理，清除VOP的中断标记
    REGW(GIC_BASE + GIC_CPU_EOI) = irqstat; // 处理完成后再通知GIC结束中断
} else if (irqnr == 1023) {
    // 新增伪中断处理，直接写EOI后返回，避免程序卡死
    REGW(GIC_BASE + GIC_CPU_EOI) = irqstat;
    return;
}

• 第二，确认VOP中断配置正确性
  查RK3328 TRM确认VOP中断的触发类型：如果是电平触发，必须保证中断处理函数中彻底清除中断请求后再退出，避免反复触发。同时检查VOP中断掩码寄存器，仅开启你需要的vblank中断，关闭其他未使用的VOP中断，减少误触发概率。
  你现有的VOP中断清除逻辑（写irqstat|(irqstat<<16)到INTR_CLEAR0寄存器）符合RK寄存器高16位写使能的规范，这部分逻辑没有问题。

• 第三，检查中断上下文保存恢复逻辑
  ARMv8架构进入IRQ异常时，需要手动保存所有用到的通用寄存器、DAIF状态寄存器，中断处理完成后完整恢复上下文，避免寄存器被污染导致程序跑飞，这也是开发板冻结的常见诱因。

• 第四，添加调试日志排查问题
  可以在中断入口添加串口打印，输出每次获取到的中断号，确认第一次VOP中断号是否符合预期，调整顺序后是否还会出现1023号中断，进一步定位问题根因。

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