- User Since
- Tue, Apr 27, 9:15 AM (2 w, 3 d)
This is the explanation for "FP_SOFTABI" in Zephyr.
bool "Floating point Soft ABI"
This option selects the Floating point ABI in which hardware floating point instructions are generated but soft-float calling conventions."
The first thing I want to confirm is "I compile zephyr and Tf-M with soft FP". As you know, TF-M is default with soft FP.
- But for Zephyr, are you using soft FP or hardware FP?
- Is it possible for you to share the compile options and linker options for the source file including the "Non-Secure interrupt" crashing?
- Is it possible to show the assembly code for the "Non-Secure interrupt"?
Tue, May 11
If you didn't change TF-M while integrating into your project, PSA call(handler mode) cannot be interrupted by non-secure interrupt like you mentioned, the reason is non-secure exceptions are de-prioritized (AIRCR.PRIS = 1) in TF-M.
Non-secure interrupt can only be active when system in thread mode.
Fri, Apr 30
For the concern you mentioned, yes, we need to add extra steps in secure scheduler, I am still working on this part.
- When secure doing secure calls: a. if lazy fp is disabled, hardware will push/pop FP context automatically during exception entry/return. b. if lazy fp is enable, for isolation 1, secure scheduler will save and restore FP context, but not invalidate FP context; for isolation 2 and 3, secure scheduler will trigger lazy fp stacking, hardware will push FP context to thread' stack and invalidate them automatically.
- When non-secure doing secure calls, non-secure side will SG to secure world in tfm_nspm_thread_entry, then doing secure calls as same as above. FP context of non-secure can be restored when bxns lr to non-secure side.