The changes that complete this task are available here:

I have merged this change in https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/430/

Fix for this is provided with https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/635/

The change which fixes this issue is available here: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/650/

This set of instructions proposed in this patch is now *OUTDATED* as it's based on running on mps2-an505 QEMU board even for AN521. As we have introduces some code now which is specific to AN521 with this commit http://git.trustedfirmware.org/trusted-firmware-m.git/commit/?id=c2f181e5ca4fce219c0e513bd3bf22e25dbdba5d , the instructions are no longer valid and need further update to be able to use AN521 build on QEMU.

The change associated to this ticket is available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/628

TF-M master branch at git sha #de6acfe passes 24/24 tests when running PSA API compliance tests from https://github.com/ARM-software/psa-arch-tests/tree/ew_beta0 at git sha #045bcf0

In the case of integration with mbedOS in the NS side, I would expect the NS binary to provide its own implementation of the functionalities described in interface/include/tfm_ns_lock.h, instead of reusing the implementation that is available in interface/src/tfm_ns_lock_rtx.c, which is aimed specifically to CMSIS.

The current implementation is based on the mechanism provided by the CMSIS-RTOS2 layer as default, which is the "Automatic Dynamic Allocation"

The change which fixes this issue is available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/593

The change related to this task is available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/588

Change for this is here: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/554/

Change for this is here: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/555/

Change for this is here: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/553/

Changes for this are here:
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/556/
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/557/

Change for this is here: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/558/

Change for this is here: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/559/

Change for this is here: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/560/

Change for this is here https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/561/

Hi Miklos, this proposal looks good to me, another good point about it is that using a macro would encapsulate the veneer layer and make sure that any change in the naming convention under the hood of the macro will not need to be reflected in callers of the veneers.

The change that completes this task is available here: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/422/

The change associated with this task is available here: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/419/

Change which completes this task is available here: https://review.trustedfirmware.org/#/c/327/

Changes related to this task are as follows:

One additional change that completes this task is a fix available here: https://review.trustedfirmware.org/#/c/186/

Changes that complete this task are as follows:

The changes associated with this this task are:

The change associated to this task is: https://review.trustedfirmware.org/#/c/115/