Hi, I would like to raise an issue around Floating Point support in the context of Non-Secure RTOS-based applications integrated with TF-M.

The problem: We cannot fully (and easily) utilize the cortex-m Floating point features in Zephyr running together with TF-M. (Note, this has little to do with TF-M not having a secure floating point support today - we focus entirely on using the FPU in non-secure domain.)

Description of the case:

In Zephyr multi-thread environment we enable the FP co-processor and the advanced context-control features in Cortex-M

* Automatic state preservation * Lazy stacking Zephyr threads are free to use the floating point registers; the automatic state preservation ensures the caller-saved registers are preserved and the context-switch routines ensure the callee-saved registers are preserved as well.

The situation becomes interesting when Zephyr threads with active FP context are doing calls to the TF-M services. In such a scenario, it may happen that the TF-M secure threads will need to preserve the FP context themselves, during a non-secure interrupt that accesses the FP registers. Currently this triggers a TF-M system crash, as TF-M does not enable the FP co-processor. I guess this could be solved by enabling the FP co-processor in TF-M.

Even in this case, the TF-M would need to preserve the FP context state when switching between threads in Secure PendSV, so Non-Secure interrupts (and potential Non-Secure reschedule actions) would not interfere with FP state preservation. What we see today is that the Non-Secure FP context is not preserved during TF-M thread switches, leading to weird situations such as when the lazy state preservation active bit is set in Secure thread mode; which should not be the case.

I would like to ask the community whether these issues have been raised in the past - and if so, please, inform me what the conclusions have been. Are there current activities that attempt to address the problems raised above? Not been able to fully utilize the FP context stacking in Non-Secure Zephyr applications that integrate with TF-M removes value of our TF-M based solutions.

Thanks! I am looking forward to hearing the thoughts of the community.

Ioannis