imx53 ArmTrustzone: Why normal world can not response interrupts

[ab]

I am trying load a kernel in normal world, but the problem is it can not response on timer interrupt. I have set SCR, TZIC, CPSR properly, SCR.irq to 0, TZIC all interrupt as non-secure, CPSR.irq to 0. Did i miss anything? Why normal world can not response any interrupt? It doesn't goes into interrupt entry function.

[stefankalkowski]

Hi,

I've a similar problem. I'm able to boot Linux as non-secure guest until it waits for interrupts. I've marked all interrupts as non-secure. The only interrupt that is secure is EPIT1, which is used by my test kernel. Linux uses GPT for scheduling, so there is no conflict. After that I configured the CSU to allow also the non-secure world to access the peripherals (using the CSL registers). Everythings works as expected, but the non-secure interrupts are delivered as fast-interrupts, which is not the intended behaviour following my understanding of Armv7 TrustZone, and the TZIC. The oddity is: obviously the non-secure guest can unmask the interrupts configured as non-secure. But they are delivered as secure ones.

What I'm missing? Is there another device on the SoC, or some configuration in the CSU, which undermines my attempts?

@ab: Did you find any solution to the problem?

[stefankalkowski]

Hi,

ok I've found my problem. It was a priority problem. In fact, I've configured all interrupt to have priority 0 (highest priority). When reading the highest pending interrupt register of the TZIC after receiving a fast-interrupt on the secure side, I first recognized the non-secure GPT IRQ to be pending. This lead to the wrong assumption that the GPT triggered the FIQ. But it was only marked in the highest pending interrupt register in addition to the EPIT IRQ that actually triggered the fast-interrupt.

From previous experiences with ARM's TrustZone aware interrupt-controller, I was expecting non-secure interrupts always getting a lower priority even when setting it to the highest priority on the secure side. With regard to the TZIC, this assumption was obviously wrong. It is probably only lowered when the non-secure side tries to set the highest priority. Now, I simply set the priority of non-secure interrupts to a lower one by hand, and everything works as expected.

regards

Stefan