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(a)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(a)lists.trustedfirmware.org; nd <nd(a)arm.com>
> Cc: nd <nd(a)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(a)lists.trustedfirmware.org> on behalf of Antonio De
> Angelis via TF-M <tf-m(a)lists.trustedfirmware.org>
> Sent: Tuesday, April 23, 2019 9:58 PM
> To: tf-m(a)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(a)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(a)arm.com>
> Cc: TF-M(a)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(a)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(a)lists.trustedfirmware.org
> Cc: nd <nd(a)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(a)lists.trustedfirmware.org> on behalf of Andrej
> Butok via TF-M <tf-m(a)lists.trustedfirmware.org>
> Sent: Tuesday, April 23, 2019 9:16 PM
> To: Antonio De Angelis
> Cc: TF-M(a)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(a)lists.trustedfirmware.org> On Behalf Of Antonio De
> Angelis via TF-M
> Sent: Tuesday, April 23, 2019 3:02 PM
> To: tf-m(a)lists.trustedfirmware.org
> Cc: nd <nd(a)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(a)lists.trustedfirmware.org> On Behalf Of Andrej
> Butok via TF-M
> Sent: 23 April 2019 13:19
> To: Andrej Butok <andrey.butok(a)nxp.com>
> Cc: TF-M(a)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(a)lists.trustedfirmware.org> On Behalf Of Andrej
> Butok via TF-M
> Sent: Tuesday, April 23, 2019 1:38 PM
> To: TF-M(a)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(a)lists.trustedfirmware.org
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
> 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(a)lists.trustedfirmware.org
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
> 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(a)lists.trustedfirmware.org
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
> 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(a)lists.trustedfirmware.org
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
> 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(a)lists.trustedfirmware.org
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
> 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(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-m
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-m
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Good, will wait for the official fix ;)
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M
Sent: Tuesday, April 23, 2019 4:06 PM
To: TF-M(a)lists.trustedfirmware.org; nd <nd(a)arm.com>
Cc: nd <nd(a)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(a)lists.trustedfirmware.org> on behalf of Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Tuesday, April 23, 2019 9:58 PM
To: tf-m(a)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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper… . We are investigating if this can be related to the issue you're observing.
Thanks,
Antonio
-----Original Message-----
From: TF-M <tf-m-bounces(a)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(a)arm.com>
Cc: TF-M(a)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(a)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(a)lists.trustedfirmware.org
Cc: nd <nd(a)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(a)lists.trustedfirmware.org> on behalf of Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Tuesday, April 23, 2019 9:16 PM
To: Antonio De Angelis
Cc: TF-M(a)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(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M
Sent: Tuesday, April 23, 2019 3:02 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)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(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: 23 April 2019 13:19
To: Andrej Butok <andrey.butok(a)nxp.com>
Cc: TF-M(a)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(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: Tuesday, April 23, 2019 1:38 PM
To: TF-M(a)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(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
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(a)lists.trustedfirmware.org> on behalf of Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Tuesday, April 23, 2019 9:58 PM
To: tf-m(a)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(a)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(a)arm.com>
Cc: TF-M(a)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(a)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(a)lists.trustedfirmware.org
Cc: nd <nd(a)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(a)lists.trustedfirmware.org> on behalf of Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Tuesday, April 23, 2019 9:16 PM
To: Antonio De Angelis
Cc: TF-M(a)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(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M
Sent: Tuesday, April 23, 2019 3:02 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)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(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: 23 April 2019 13:19
To: Andrej Butok <andrey.butok(a)nxp.com>
Cc: TF-M(a)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(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: Tuesday, April 23, 2019 1:38 PM
To: TF-M(a)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(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
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(a)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(a)arm.com>
Cc: TF-M(a)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(a)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(a)lists.trustedfirmware.org
Cc: nd <nd(a)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(a)lists.trustedfirmware.org> on behalf of Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Tuesday, April 23, 2019 9:16 PM
To: Antonio De Angelis
Cc: TF-M(a)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(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M
Sent: Tuesday, April 23, 2019 3:02 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)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(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: 23 April 2019 13:19
To: Andrej Butok <andrey.butok(a)nxp.com>
Cc: TF-M(a)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(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: Tuesday, April 23, 2019 1:38 PM
To: TF-M(a)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(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
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(a)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(a)lists.trustedfirmware.org
Cc: nd <nd(a)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(a)lists.trustedfirmware.org> on behalf of Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Tuesday, April 23, 2019 9:16 PM
To: Antonio De Angelis
Cc: TF-M(a)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(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M
Sent: Tuesday, April 23, 2019 3:02 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)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(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: 23 April 2019 13:19
To: Andrej Butok <andrey.butok(a)nxp.com>
Cc: TF-M(a)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(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: Tuesday, April 23, 2019 1:38 PM
To: TF-M(a)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(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
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(a)lists.trustedfirmware.org> on behalf of Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Tuesday, April 23, 2019 9:16 PM
To: Antonio De Angelis
Cc: TF-M(a)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(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M
Sent: Tuesday, April 23, 2019 3:02 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)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(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: 23 April 2019 13:19
To: Andrej Butok <andrey.butok(a)nxp.com>
Cc: TF-M(a)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(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: Tuesday, April 23, 2019 1:38 PM
To: TF-M(a)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(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
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(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M
Sent: Tuesday, April 23, 2019 3:02 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)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(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: 23 April 2019 13:19
To: Andrej Butok <andrey.butok(a)nxp.com>
Cc: TF-M(a)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(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: Tuesday, April 23, 2019 1:38 PM
To: TF-M(a)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(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
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(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: 23 April 2019 13:19
To: Andrej Butok <andrey.butok(a)nxp.com>
Cc: TF-M(a)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(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: Tuesday, April 23, 2019 1:38 PM
To: TF-M(a)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(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
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(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: Tuesday, April 23, 2019 1:38 PM
To: TF-M(a)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(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
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
