You copied the Doc URL to your clipboard.

OS configurations

Various operating system configurations are possible with the ARMv8-M architecture. Since the ARMv8-M architecture Security Extension is optional, a processor design implementing the ARMv8-M architecture might have no TrustZone technology support.

Without TrustZone technology support, the processor:

  • Is always in Non-secure state.
  • Has no Secure Attribution Unit (SAU).
  • Has no Secure MPU, Secure SysTick, or SCB registers.

Designs which include the Security Extension allow multiple configuration arrangements. The following table describes several.

Configuration

RTOS Design requirement

RTOS running in Secure state.

Some threads are Secure, and some threads are Non-secure. Cross domain APIs calls are also possible between domains.

Each thread might have Secure and Non-secure stack space allocation.

RTOS running in Non-secure state.

Threads are Non-secure, but potentially some of the threads can call Secure API.

All threads have a Non-secure stack, and some threads that call Secure API also must have Secure stack allocation.

Secure firmware must include CMSIS-RTOS API (version 2) to support handling of stack switching on the Secure side.

RTOS running in Non-secure state.

Threads are Non-secure and there is no calling to Secure APIs. (Secure state is not used by the application).

All threads have Non-secure stack only.

The design is identical to RTOS for chip designs without TrustZone technology support.

RTOS and all applications running in Secure state. Non-secure state is not used.

All threads have Secure stack only.

RTOS on Secure domain and use the idle thread of that OS to run a second OS (not real time) in the Non-secure domain.

Secure RTOS

Each thread might have Secure and Non-secure stack space allocation.

Non-secure OS

All threads have a Non-secure stack, and some threads that call Secure API also must have Secure stack allocation.

Secure firmware must include CMSIS-RTOS API (v2) to support handling of stack switching on the Secure side.

More configurations are possible, for example, by having a bare-metal or interrupt driven application in one security domain and running an RTOS in the other domain.

Case 1 - RTOS in Secure state

When a real-time operating system is running in Secure state, threads can be Secure or Non-secure. It is also possible to have cross-domain API calls between Secure and Non-secure software, which means each thread can have both Secure and Non-secure stack allocation.

When creating a thread from Secure handler mode, the EXC_RETURN code can be:

  • 0xFFFFFFFD if the new thread is Secure. The stack frame is PSP_S.
  • 0xFFFFFFBD if the new thread is Non-secure. The stack frame is PSP_NS.

Case 2 - RTOS in Non-secure state

In Non-secure state threads are Non-secure by default. However, threads can call APIs in Secure firmware memory, so threads can have both Secure and Non-secure stack allocation.

Because the RTOS is on a Non-secure domain, it cannot directly access the Secure stack pointers and is therefore unable to handle context switching of Secure stacks. To solve this problem, new versions of the CMSIS-RTOS APIs are being developed which support Secure stack management.

When creating a thread from Non-secure handler mode, the EXC_RETURN code must be 0xFFFFFFBC (thread is Non-secure). The stack frame must be pointed to by PSP_NS.

Case 3 - RTOS and application all in Non-secure state only

Threads are always Non-secure when the RTOS and application are in Non-secure state.

In Non-secure state only, the RTOS can be based on existing code that was written for ARMv8-M processors. However, the following modifications are still required:

  • EXC_RETURN for creating a thread must be 0xFFFFFFBC (thread is Non-secure). The stack frame must be pointed to by PSP_NS.
  • MPU support code must be updated to support the new programmers’ model.

Case 4 - RTOS and application all in Secure state only

It is possible for a microcontroller vendor to ship a blank device without locking down the Secure memory. In this case, software developers can create an application with an RTOS which runs entirely in the Secure domain.

In Secure state:

  • EXC_RETURN for creating a thread must be 0xFFFFFFFD (thread is Secure).
  • The stack frame must be pointed to by PSP_S.
Was this page helpful? Yes No