• State Accepted Answer
  • Replies 2 replies
  • Subscribers 351 subscribers
  • Views 358 views
  • Users 0 members are here
Options
Related
How was your experience today?

GIC-600 How to drop down ICC_RPR_EL1 to normal 0xFF without INTID

duanlin

howdy,

application scenarios:

Quad-A55 AMP system, target core is a bare-metal system all run in Non-Secure EL1 with interrupt preemption enabled. and EOI mode is drop/deactive together.

normal situation:

The guide documents said the order of ICC_EOIR1_EL1 must be the reverse order of ICC_IAR1_EL1 interrupt acknowledge. The INTID read from ICC_IAR1_EL1 should be perserved by software.
This no problem.

question situation:

After a jtag-debugger relaunch, this probably not caused any reset to GIC in my debug platform, because GIC is still servicing for other cores in AMP system.
If the relaunch occured between read ICC_IAR1_EL1 and write ICC_EOIR1_EL1, there is a breakpoint for e.g. then the INTID is lost after the relaunch.
This situation ICC_RPR_EL1 remains the priority of last ICC_IAR1_EL1, If do not drop down ICC_RPR_EL1 to 0xFF, then the lower priority interrupts will not able to be rised.

GICD/GICR_ICACTIVE<n> cannot drop down ICC_RPR_EL1, and foreach active-state interrupt to find INTID is complicated also not reliable.

the question:

Is there any way to drop down ICC_RPR_EL1 to normal 0xFF without INTID in initalization?

thanks, and wish you a nice day

  • +1 Arm Employee Badge

    I'm assuming you're asking about physical interrupts, not virtual interrupts.  If so, there are a couple of possible approaches:

    • Reset the CPU and GIC
      • Cleanest, but requires you also to reset the other connected cores which it sounds like you're trying to avoid.
    • Write 0s the ICC_APxR<n>_EL1 registers
      • This directly clears the active priorities on the PE, thereby reseting the Running Priority.
      • It does not, however, cause the state of the INTIDs to be updated.  Meaning that you could have a bunch of interrupts left in the wrong (Active or Active+Pending) state.  You can possibly solve that be searching the ACTIVE registers and manually clearing affected INTIDs.
    • Search for the Active interrupts, derive the activation order from their priorities, then do the necessary priority drops/deactivates
      • PPIs and SGIs are local to the core, so easy to check.
      • SPIs require you to scan through the GICD_IROUTER<n> registers, but that will be a problem if you use 1:N
      • LPIs are a problem, as you can't read their current State - do you use them?

    This problem is one reason why sharing a GIC between different independent software stacks in the same Security state can be a tricky.  One way to mitigate (although not directly relevant to using a JTAG debugger) is using virtualisation. Run a hypervisor, possibly quite a thin one, across all the cores sharing a physical GIC.  That hypervisor provides each VM with it's own vGIC, which is easier to reset if one VM needs to be restarted without affecting the others.

  • 0 in reply to Martin Weidmann

    Thank you sir,

    Use ICC_APxR<n>_EL1 for clearing active priorities is my suitable solution, from your advise.
    I added extra ICACTIVE and ICPEND in initialization for The explicitly used interrupts.
    Fortunately, I use PE-self-triggered PPI interrupts, neither 1 of N or LPI is used in the case.
    Then there have no wrong state in system.

    best wishes