Possible refactoring available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1460

We have discussed this matter and we would like to propose a solution which might be feasible for you.

https://review.trustedfirmware.org/c/trusted-firmware-m/+/1421

Additional change: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1420/

Patch for this issue: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1409

Change for this ticket: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1389

Patch for this: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1373

https://review.trustedfirmware.org/c/trusted-firmware-m/+/1371

Change associated to this is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1260

Hi Thomas, I see you mention a failure with GNUARM 7.3.1 with some build config. Can you please provide instructions on how to reproduce the build failure? As you say the failure happens with the mainline as well, that shouldn't happen and I am not seeing the failure either. Would like to try to reproduce it here if it's a genuine issue.

In T376#4490, @ccli8 wrote:

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.

For the osKernelGetState() overhead in tfm_ns_lock_dispatch(...), I think it can be replaced by just checking ns_lock.init.

Strictly speaking, the files in interface/src are a possible implementation of the interface described in interface/include. Your integration can provide a different implementation of tfm_ns_lock_dispatch(...) based on your requirements, without the need to upstream your change. But if you think that your change can be useful for a wider audience, yes, please create a change where you modify tfm_ns_lock_dispatch(...) using CMSIS-RTOS2 APIs to check for pre-rtos stage and we'll get that reviewed.

Thanks for summarising the three options.

Just to be clear, as there has been some confusion between get_init_state() and get_lock_state (particularly on my side :) ), I think that the get_init_state(...) doesn't need to be exported as probably the same result can be obtained by proper usage of CMSIS-RTOS2 API's (or equivalent API's, based on the NS side scenario). Regarding the get_lock_state(...), I will comment on the other thread. T378

I agree in principle with the idea, but I have a comment regarding the implementation.

Change for this ticket is available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1223

Additional patch is required for Musca A to make sure that the quantity of RAM assigned to the SPE in the region_defs.h header is increased for IPC mode build even if the tests are not build, as RAM requirements for IPC are higher than the current default limit of 64 KB. Patch for this is available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1184

Additional patch: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1147

This needs to be merged, it has been open for months and the issue is being reported by Summer as well.

Pacthes for this work are as follows:

Task which fixes this issue is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1076

Change which completes this issue is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1073

Change which fixes this issue is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1079

This has been merged and I am able to run Regression in IPC mode, so this ticket can be closed.

Fix for this style issue is available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1019

It turns out that it's a configuration option which can be overriden in our custom CSS file.

The fix for this issue is available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1011

Fix for this is available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1001/

Closing this as it's a design choice.

This is currently merged in the master branch. I am keeping the issue open for some more time in case any other external party needs to report/track the issue in their platforms/setup, I will then close if if no more occurrences of this are reported.

Patch for this issue is available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/881

A candidate fix for this issue is available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/882

Assigned to Ken as he's the one driving this activity.

Got it, thanks for the clarification. Do you think it's worth it to add a comment in the code to explain this in the header? Might be confusing at first glance. Or we should just close this item as a "won't fix, not an issue."

Also, please note that __DOMAIN_NS (and later, DOMAIN_NS for later CMSIS versions) is used in the CMSIS_5 project hence our build systems has to define them to be able to build correctly those files.