My modification is very draft, so I just list it here. Actually, the above has mentioned in total.

Shorten the build directory -B C:/build can help, but not enough. The same error still occurs.

Thanks for your check. Would you also backport the patch to TF-M 1.4?

The WEAK mechanism sounds OK, but I think not just OS abtraction layer, the TFM NS interface (tfm_ns_lock_dispatch(...), tfm_ns_lock_init()) also needs to be WEAK. For the interrupt-disable scenario, the mutex-like reference implementation cannot apply, and the TFM NS interface may need to implement in a wholly different way.

So the NS lock in TF-M is a reference implementation. Proprietary implementation may be needed to meet target platform. But per my mbed-os/tf-m port, mbed-os team follows the rule of importing TF-M and not making modification to such as this NS lock implementation for its maintenance. That's one of my dilemma. My biggest dilemma is still how to make secure call in interrupt-disabled context at NS side of mbed-os. The NS lock mechanism with mutex apparently collides with interrupt-disabled context.

One idea for heuristic. With NS secure call run-to-completion, it can run in interrupt-disabled context with mutex removed. For example, disable task switch during NS secure call period:

The secure partition init function cannot cover all use cases. The requirement of pre-rtos secure call actually comes from my mbed-os/tf-m port on Nuvoton's M2351 chip. For example, on mbed-os, the CMSIS API SystemCoreClockUpdate(...) is called to update SystemCoreClock in pre-rtos stage on NS side. On Nuvoton's M2351, SystemCoreClockUpdate(...)'s implementation needs to access CLK space registers which are hardwired to secure. That's where secure call in pre-rtos stage is necessary. I've also checked SystemCoreClockUpdate(...)'s implementation on Arm's Musca A1. It has SystemCoreClock fixed in macro, and so it needn't.

This call involves a Thread -> Handler mode request on every service call to check if we are in pre-RTOS stage. I think this will introduce a non-negligible penalty; in most of the cases, we expect this call to happen when the RTOS has been loaded.

Upstream change 1231 to support secure call in pre-rtos stage in tfm_ns_lock_dispatch(...). I think some audience would benefit from it. Without it, I need to make an extra check for pre-rtos scenario before making a secure call.

After dropping 1123, create another change which adds support for pre-retos dispatch in tfm_ns_lock_dispatch by checking kernel state with osKernelGetState, right?

1123 is for NS secure call at pre-rtos stage and 1124 for in interrupt-disabled condition. They are different and so separate changes. For 1123, since osKernelGetState can substitute for get_init_state. I have three choices:

1. Abandon 1123 (and also get_init_state)
2. Re-implement get_init_state with osKernelGetState
3. Abandon 1123 (and also get_init_state) and integrate pre-rtos NS secure call into tfm_ns_lock_dispatch

Toolchain: Arm Compiler 6.10
Platform: Nuvoton M2351 (M23-based)
mbed-os/tf-m