https://review.trustedfirmware.org/c/trusted-firmware-m/+/3886
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3887
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3433
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3514
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3888

https://review.trustedfirmware.org/c/trusted-firmware-m/+/3098
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3350/9
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3360/8

patch link: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3434
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3515
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3563
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3564
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3565
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3566
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3567
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3750
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3751
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3752
https://review.trustedfirmware.org/c/trusted-firmware-m/+/4029
https://review.trustedfirmware.org/c/trusted-firmware-m/+/4116
https://review.trustedfirmware.org/c/trusted-firmware-m/+/4117

All patches had been merged into the master branch.

It's configured in CommonConfig.cmake, line #321.
The name is CONFIG_TFM_ENABLE_CTX_MGMT.

Great, I asssue that this is configured with a #define.

Thanks, Kevin.

Hi Reinhard, FYI the patches have been merged.

Hi Andrej,

Hi Ken,
Yes, the final patch has fixed the issue.
It works now without our workarounds.

Hi Andrej,
I have updated patch and test with FP enabled in my side and it works. Can you take a try on your side?
Thanks.

Hi Andrej, Thomas,

I would really like to see tf-m support the latest mbed-crypto.

Thanks. I just found the patch missed something, I will re-create a patch to update that.

I agree, it definitely shouldn't propagate that MAILBOX status.
Looks like the header file says that it returns 0 on success. We should probably make it clear which zero that is :-)

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

Thx Vikas.
I add @chrisb to take a look since he is the designer. :)

Patch under review:

Fix reviewed and merged:
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3333/

Changes reviewed and merged:
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3334/
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3335/
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3336/

Should to confirm, that after the patch the issue is still present.

Patch created:

Thanks for your input, that helps much. I will create fixes when I back to office.

Are the patches now part of a release? I'm asking as there is a need to support PSA Certification for Level 2 with FreeRTOS.

Hi Ken,
after farther testings, PSA Test application still goes to the memory fault.
So I have returned all my two workarounds, which work for all applications:

1. .stack_top = PART_REGION_ADDR(ARM_LIB_STACK, $$ZI$$Limit) - 0x48,
2. Disable if (stacked_ctx_pos != p_cur_sp->runtime_data.sp_thrd.sp_btm)

Hi Ken,
Also, it should be done something with the check in tfm_svcalls.c, tfm_core_validate_caller() line 1001:

Hi Ken,

Hi sunxi h6,

BTW, can you update other tfm_arch_*.h as well?
We can help verify the changes not covered in your side.

Hi Andrey,

So my workaround, to avoid psa_panic(), is to disable the check:

So I have returned to the RESET issue.

After the following fix - 0x48, the applications does not have the memory fault:

{
    .stack_bottom         = PART_REGION_ADDR(ARM_LIB_STACK, $$ZI$$Base),
    .stack_top            = PART_REGION_ADDR(ARM_LIB_STACK, $$ZI$$Limit) - 0x48, //NXP
    .rw_start             = PART_REGION_ADDR(ARM_LIB_STACK, $$ZI$$Base),
},

Hi Ken,

Related change: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3328

Related change: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3288

More hints for you:

Sorry for the late response and thanks for the findings. Could you share your image binary so that I could take a try? I got a board but not set up the environment yet.

Yes, lower level error codes can vary widely and applications won't know which particular one to check for. Error codes at the same level of abstraction as this API should be used, like TFM_SUCCESS.

I have tried to workaround it. Current steps:

1. Updated to the latest TFM commit.
2. Reverted changes related to:
   1. 5248af2d7b86775364a0e131eb80ac0330bc81fb
   2. 490281df3736b11b62e25bc98d3e2c6e4e10478c
   3. 483da6447e4360c514538807275904be68395dff

After that, PSA Test application starts working.
But the regression test application still goes to the Memory fault during the first App ROT partition initialization, on the first SVC call.

3. Switched App ROT partitions to PSA ROT, in tfm_spm_db.inc => after that regression tests are OK.

Hi Antonio
FYI:
mbedCrypto v3.0.1: https://github.com/ARMmbed/mbed-crypto/tags

Change for this issue had been merged

Fix for this issue had been merged

FYI:
For ARMClang/Keil

1. Functional API and TFM_LVL=1, all applications/tests are OK!!!
2. IPC API and TFM_LVL=1 => repetitive reset.
3. IPC API and TFM_LVL=2 => goes to the mentioned memory fault.

Another experiment. Switching to Armasm V5 from v6 did not help, the same result - goes to the Memory fault.
So, for this moment only GCC (for PSA tests) is OK.

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

BTW: At the same time the TFM Regression Tests application (using GCC) goes to infinite reset on test_app()=>tfm_secure_client_run_tests()=>psa_connect(TFM_SECURE_CLIENT_SFN_RUN_TESTS_SID,TFM_SECURE_CLIENT_SFN_RUN_TESTS_VERSION)=>tfm_ns_interface_dispatch()=>fn()=>causes reset

Hi Ken,

Hi Ken,

Update completed.

Looks like this was caused by the push operation, and it was caused by accessing an address out of ARM_LIB_STACK.

After tfm_core_svc_handler() returns, the execution jumps to tfm_nspm_thread_entry().
Strange is, that during this jump PSP is changed from 0x30000FE0 to 0x30001048.

So the PSP, during main() has following values:
PSP = 0x300001000 PSPLIM = 0x30000800

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