Hi, The fix for this problem has been logged here: https://developer.trustedfirmware.org/T327 And the patch is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/922

I used a fake thread object to collect initial context to make scheduler has an initial CURR_THRD. This is because I need to avoid unnecessary condition checking while context switch since CURR_THRD only equals to ZERO for ONCE time:

ctx_switch: If (pcurr) Tfm_memcpy(&pcurr->ctx, pctx, sizeof(*pctx)); Tfm_memcpy(pctx, &pnext->ctx, sizeof(pnext->ctx)):

The TFM_ASSERT in source is another thing since they may get removed in a release product.

Please help to provide feedback on it if you see this patch. And I will try to merge it after several +1/2 is collected since it is an hotfix patch.

Thanks.

-Ken

-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Tuesday, April 23, 2019 10:06 PM To: TF-M@lists.trustedfirmware.org; nd nd@arm.com Cc: nd nd@arm.com Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault

Hi Andrej, Ah, great finding! We moved the default IDLE thread into partition now so there is no default CUR_THRD at very start. I guess reverting the latest commit 4dcae6f69db61af31316831d773e5d8777e9fbd3 should fix this problem. Sorry I don't have working platform now so can not verify it. Will provide a fix soon.

-Ken ________________________________ From: TF-M tf-m-bounces@lists.trustedfirmware.org on behalf of Antonio De Angelis via TF-M tf-m@lists.trustedfirmware.org Sent: Tuesday, April 23, 2019 9:58 PM To: tf-m@lists.trustedfirmware.org Cc: nd Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault

Hi Andrej,

While trying to replicate your issue I have found a (maybe related) issue with ConfigCoreIPC.cmake and Regression enabled on the current tip, described by the following ticket: https://developer.trustedfirmware.org/T326 . We are investigating if this can be related to the issue you're observing.

Thanks, Antonio

-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Andrej Butok via TF-M Sent: 23 April 2019 14:50 To: Ken Liu (Arm Technology China) Ken.Liu@arm.com Cc: TF-M@lists.trustedfirmware.org Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault

Hi Ken, May be context is static, but the CURR_THRD (p_curr_thrd) pointer is NULL, before the first tfm_thrd_context_switch() call. OR I have something wrong.

-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Tuesday, April 23, 2019 3:43 PM To: tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault

WARNING: This email was created outside of NXP. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe.

Hi Andrej, Thanks for the investigation, we will take a look ASAP.

The thread context is allocated statically in global which should not have chance to be NULL. If you have time for digging, you can put message in function './secure_fw/core/ipc/tfm_spm.c:tfm_spm_init()' to show all thread context value of partitions.

Thanks.

-Ken ________________________________ From: TF-M tf-m-bounces@lists.trustedfirmware.org on behalf of Andrej Butok via TF-M tf-m@lists.trustedfirmware.org Sent: Tuesday, April 23, 2019 9:16 PM To: Antonio De Angelis Cc: TF-M@lists.trustedfirmware.org Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault

Hi Antonio,

We have own port for LPC55S69, so not sure if you are able to run it. But, the issues happens in general code (master branch, the latest current commit). Defined TFM_PSA_API, TFM_LVL = 1. The NULL parameter is causing fault in the first call of tfm_thrd_context_switch(..., NULL,...) => tfm_memcpy(&NULL-

...

state_ctx.ctxb, ...) => memcpy(wrong address), and should cause an issue on

any platform.

Thanks, Andrej

-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Antonio De Angelis via TF-M Sent: Tuesday, April 23, 2019 3:02 PM To: tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: [EXT] Re: [TF-M] TFM_PSA_API =>BusFault

WARNING: This email was created outside of NXP. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe.

Hi Andrej,

Could you provide us with instructions on how to replicate the issue you're observing? In particular, which build configuration you're building (.cmake), compiler, platform used and if it's observed on board or FVP/model? Also, are you able to identify the latest commit which was still working in your setup / identify the commit which brings in this issue?

Thanks, Antonio

-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Andrej Butok via TF-M Sent: 23 April 2019 13:19 To: Andrej Butok andrey.butok@nxp.com Cc: TF-M@lists.trustedfirmware.org Subject: Re: [TF-M] TFM_PSA_API =>BusFault

Father investigation shows, that tfm_pendsv_do_schedule() calls tfm_thrd_context_switch() and passing pth_curr which is set to NULL, so it is causing memcpy() to 0 address => Bus Fault. So this code may not work properly. Please provide a fix.

-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Andrej Butok via TF-M Sent: Tuesday, April 23, 2019 1:38 PM To: TF-M@lists.trustedfirmware.org Subject: [EXT] [TF-M] TFM_PSA_API =>BusFault

Hello,

After last commits on TFM master branch, when TFM_PSA_API is defined, the tfm examples finish in main()=>tfm_spm_init()=>....=> tfm_thrd_context_switch()=>tfm_memcpy()=>BusFault_Handler(). When TFM_PSA_API is not defined, everything is OK. Also, TFM examples were OK at least 2 weeks ago, even when TFM_PSA_API was defined.

Is it known issue? Or something new (during last week) must be added into our target-specific code?

Thanks, Andrej Butok

-- TF-M mailing list TF-M@lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.trus... edfirmware.org%2Fmailman%2Flistinfo%2Ftf- m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 916237904331396&sdata=663%2F9XukXmp8lCoKUM6qEa4h5mxn6I9my0jh W8P9wLM%3D&reserved=0 -- TF-M mailing list TF-M@lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.trus... edfirmware.org%2Fmailman%2Flistinfo%2Ftf- m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 916237904331396&sdata=663%2F9XukXmp8lCoKUM6qEa4h5mxn6I9my0jh W8P9wLM%3D&reserved=0 -- TF-M mailing list TF-M@lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.trus... edfirmware.org%2Fmailman%2Flistinfo%2Ftf- m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 916237904341405&sdata=QvbSlGT7udwTcKcJajgtO8rvCvH0UJOMMqOJUc 2YPMo%3D&reserved=0 -- TF-M mailing list TF-M@lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.trus... edfirmware.org%2Fmailman%2Flistinfo%2Ftf- m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 916237904341405&sdata=QvbSlGT7udwTcKcJajgtO8rvCvH0UJOMMqOJUc 2YPMo%3D&reserved=0 -- TF-M mailing list TF-M@lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.trus... edfirmware.org%2Fmailman%2Flistinfo%2Ftf- m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 916237904341405&sdata=QvbSlGT7udwTcKcJajgtO8rvCvH0UJOMMqOJUc 2YPMo%3D&reserved=0 -- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m