• State Accepted Answer
  • Locked Locked
  • Replies 3 replies
  • Subscribers 20 subscribers
  • Views 5650 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Issue with exception handler

armdev

Hi,

I am facing an issue where I am setting timer at Guest EL1 (NS) mode and trying to route this interrupt to EL2.

I do see that when timer expires the interrupt is pending (using generic timer PPI 30) in GICD_ISPENDR (bit 30 set) but control reaches to first entry in EL2 exception vector rather then IRQ handler vector ?

I do set the HCR_EL2 (IMO) bit to 1 in order to route all IRQs. I am confused as how the control can reach to first entry in exception vector (EL2t Synch handler) ?

I am not sure for v8 if is there any extra configuration step ?

Thanks,

Parents
  • 0 Arm Employee Badge

    Hello,

    Are you sure that you aren't actually entering the vector table at the IRQ entry for a lower EL, but then somewhere in your handler you're taking a synchronous exception and this is taking you to that entry? The simplest way to test this would be to put a branch-to-self at the start of each of your vector table entries, then test the code again, then use a debugger to interrupt the core after the timer expires, and then see where the core is.

    Please can you try this, and then provide the values of the following registers:

    • PC
    • VBAR_EL2
    • ESR_EL2

    This will help to narrow down the issue.

    Ash.

Reply
  • 0 Arm Employee Badge

    Hello,

    Are you sure that you aren't actually entering the vector table at the IRQ entry for a lower EL, but then somewhere in your handler you're taking a synchronous exception and this is taking you to that entry? The simplest way to test this would be to put a branch-to-self at the start of each of your vector table entries, then test the code again, then use a debugger to interrupt the core after the timer expires, and then see where the core is.

    Please can you try this, and then provide the values of the following registers:

    • PC
    • VBAR_EL2
    • ESR_EL2

    This will help to narrow down the issue.

    Ash.

Children
  • 0 in reply to Ash Wilding

    Hi Ash,

    I found out the issue was as WFI was trapping. I disabled to trap it in EL2 and it works.

    Now i am facing another issue is that even timer condition is asserted it is not generating interrupt.

    I would like to know from EL1 (NS) mode is it possible to see GIC GICD_IGROUP registers ?

    Is there any document which specify the access permissions for GICv2 registers from different ELx ?

    I am trying to narrow down as why the timer interrupt is not firing even though the condition is getting asserted.

    Thanks,

  • 0 Arm Employee Badge in reply to armdev

    Hello,

    The Generic Interrupt Controller Architecture Specification Version 2 (GICv2) documentation can be found here. Note that you'll need to create a free account in order to download the PDF.

    From Section 4.3.4 Interrupt Group Registers GICD_IGROUPRn, under usage constraints:

    In implementations that include the GIC Security Extensions, accessible by Secure accesses only. The register addresses are RAZ/WI to Non-secure accesses.

    So, a few things to keep in mind:

    • GICD_IGROUPRn must be configured while still in the Secure world such that any Non-secure interrupts are Group 1
    • GICC_PMR must be configured (on all cores) while still in the Secure world to a low enough value that it is writeable by Non-secure accesses

    Then, in EL1-NS, you can enable the interrupt by following these steps:

    1. Enable the GIC Distributor via GICD_CTLR (once by primary core)
    2. Configure GICD_ITARGETSRn to target the interrupt at specific core(s) (once by primary core)
    3. Configure GICD_IPRIORITYRn to set the priority of the interrupt (on all targeted cores)
    4. Configure GICC_PMR to a lower priority than the one set for GICD_IPRIORITYRn (on all targeted cores)
    5. Configure GICD_ISENABLERn to enable the interrupt (on all targeted cores)
    6. Enable the GIC CPU Interface via GICC_CTLR (on all targeted cores)
    7. Use "MSR DAIFClr, #0b0010" to unmask IRQs (on all targeted cores)

    I hope that helps,

    Ash.