12-2-2025

64 bit ARM architecture -- Interrupt routing

I can't think of a better term, so I am using "interrupt routing".

The issue is this. A 64 bit arm can be running code at 4 different EL. Three of those (1,2,3) have a vector table and a VBAR and they all could have handlers specified for INT or FIQ. When an interrupt happens, what determines which level handles the interrupt?

Two registers control the game as far as EL-3 and EL-2 are concerned:
SCR_EL3 for EL3
HCR_EL2 for EL2
Note that there are no SCR or HCR registers for other levels, so the _EL3 and _EL2 are really not necessary, but help to make clear what level each register affects.

The ATF documents state that there are 2 bits in SCR_EL3 that configure interrupt routing for that level.
When SCR_EL3.FIQ=1, FIQs are routed to EL3.
Otherwise they are routed to the First Exception Level (FEL) capable of handling interrupts.
When SCR_EL3.IRQ=1, IRQs are routed to EL3.
Otherwise they are routed to the FEL

I cannot examine this register from EL2 (I just get a sychronous abort), but it is safe to assume that these bits are 0, else linux could never run at EL1.

If the bits in SCR are set to claim interrupts for EL3, it always wins -- game over.
If those bits are not set, we need to examine bits in HCR_EL2 to see if EL2 should get the interrupts. These bits are named IMO and FMO. FMO is bit 3 (0x08) IMO is bit 4 (0x10)

I can examine HCR_el2 and I see this:
HCR_el2 = 0000000000000022
Bit 0x02 is SWIO -- set/way cache invalidation override
Bit 0x20 is AMO -- claims asynchronous abort and error interrupts for EL2

Will this solve my bare metal interrupt problem

Remember that I am running my bare metal demos exactly as U-boot launches them, which is EL-2 as it turns out. And I am frustrated because I get no interrupts.

So, what if we OR the value 0x18 (FMO and IMO) onto HCR_el2?
Wow! That seems to do the trick, now I see this:

sending SGI 0
Bad exception: 12
And this is just what I needed to know!
Feedback? Questions? Drop me a line!

Tom's Computer Info / tom@mmto.org