Hi Andrej,
Does your IDE support pre-build command? Is there any chance to execute the parse and auto-generation in the pre-build step?
Best regards,
Hu Ziji
________________________________
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: Thursday, July 11, 2019 7:41 PM
To: Ken Liu (Arm Technology China)
Cc: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Common scatter files and templates
Hi Ken,
> Could you help to tell the name of the file you don't want to be removed?
So, any .c,.h,.inc and linker file which may be used during compilation.
An IDE project (ARM Kei, MCUx, IAR etc.) assumes a fixed set of existing files.
Thanks,
Andrej
-----Original Message-----
From: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com>
Sent: Thursday, July 11, 2019 12:44 PM
To: Andrej Butok <andrey.butok(a)nxp.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: RE: Common scatter files and templates
Hi Andrej,
Could you help to tell the name of the file you don't want to be removed?
So that we can estimate what is important for IDE projects and how we could help on that.
An introduction of how your IDE integrate with TF-M code is also welcome.
Would you share this to us?
Thanks.
-Ken
> -----Original Message-----
> From: Andrej Butok <andrey.butok(a)nxp.com>
> Sent: Thursday, July 11, 2019 2:25 PM
> To: David Hu (Arm Technology China) <David.Hu(a)arm.com>; Antonio De
> Angelis <Antonio.DeAngelis(a)arm.com>; Ken Liu (Arm Technology China)
> <Ken.Liu(a)arm.com>; Miklos Balint <Miklos.Balint(a)arm.com>
> Cc: tf-m(a)lists.trustedfirmware.org
> Subject: RE: Common scatter files and templates
>
> Pre-generated files are required for TFM IDE projects.
> Please do not delete them, find other solution!
> It can be solved by adding #if/#ifdef.
>
> Thank you,
> Andrej Butok
>
> -----Original Message-----
> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David
> Hu (Arm Technology China) via TF-M
> Sent: Thursday, July 11, 2019 4:08 AM
> To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com>; tf-
> m(a)lists.trustedfirmware.org; Ken Liu (Arm Technology China)
> <Ken.Liu(a)arm.com>; Miklos Balint <Miklos.Balint(a)arm.com>
> Cc: nd <nd(a)arm.com>
> Subject: Re: [TF-M] Common scatter files and templates
>
> Hi Antonio, Ken, Miklos,
>
> Currently, we use a preprocessor flag `TFM_MULTI_CORE_TOPOLOGY` to
> comment the veneer sections in the templates in multi-core topology.
> Each time before building, we have to run the Python script to
> generate new link script/scatter file with veneer disabled, to replace the existing ones.
> It becomes more inconvenient as the number of developers and users on
> feature-twincpu branch grows.
>
> As Chris proposed on
> https://review.tr
> ustedfirmware.org%2Fc%2Ftrusted-firmware-
> m%2F%2B%2F1527&data=02%7C01%7Candrey.butok%40nxp.com%7C068
> 37920c9bd443236e908d705a48d92%7C686ea1d3bc2b4c6fa92cd99c5c301635%
> 7C0%7C0%7C636984076614785023&sdata=2SVwa0TpX4a4lP86hsIYiw25YS
> Zqi8FzFErhpH3CrYI%3D&reserved=0, does it also make sense to
> directly update the "generated" linker script/scatter file as well, on
> feature-twincpu branch? `TFM_MULTI_CORE_TOPOLOGY` will be a common
> flag used in multi- core topology and will help resolve our urgent problem.
> If the final improvement solution is completed on master branch, we
> will update the feature branch accordingly when merging it back to master branch.
>
> Please let me know if there is a better option for feature-twincpu branch.
> Thank you.
>
> Best regards,
> Hu Ziji
>
> -----Original Message-----
> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of
> Antonio De Angelis via TF-M
> Sent: Thursday, July 11, 2019 3:53 AM
> To: TF-M(a)lists.trustedfirmware.org; nd <nd(a)arm.com>
> Subject: Re: [TF-M] Common scatter files and templates
>
> Hi Chris,
>
> you are right, that file is autogenerated from the template file but
> both are kept under source control. The reason for this is that the
> autogenerated file is not created at build time but by manually
> running the tfm_parse_manifest_list.py, which has to be run every time
> something in the manifest is changed, and the resulting autogenerated file is committed under source control as well.
>
> On the other hand, the build system could be modified to run the
> parsers at build time so that the autogenerated files wouldn't have to
> be stored in source control, and we could keep only the template.
> These two alternatives are both equally valid in my view, but if there
> is strong consensus for the other we can discuss.
>
> Thanks,
> Antonio
>
> ________________________________
> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of
> Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org>
> Sent: 10 July 2019 19:50
> To: TF-M(a)lists.trustedfirmware.org; Miklos Balint
> Subject: [TF-M] Common scatter files and templates
>
> Can somebody please help me understand this?
> $ ls platform/ext/common/armclang/
> tfm_common_s.sct tfm_common_s.sct.template $ ls
> platform/ext/common/gcc tfm_common_s.ld tfm_common_s.ld.template In
> both directories, both files are under source control, but the
> non-template files say that they're auto-generated:
> /*********** WARNING: This is an auto-generated file. Do not edit!
> ***********/
>
> It's unusual to see both the source file and the artifact under source control.
>
> It seems that they're generated by tools/tfm_parse_manifest_list.py,
> but that doesn't seem to be run as part of the build, so when is it run?
>
> Thanks,
>
> Chris
>
>
> This message and any attachments may contain confidential information
> from Cypress or its subsidiaries. If it has been received in error,
> please advise the sender and immediately delete this message.
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
> https://lists.trust
> edfirmware.org%2Fmailman%2Flistinfo%2Ftf-
> m&data=02%7C01%7Candrey.butok%40nxp.com%7C06837920c9bd44323
> 6e908d705a48d92%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636
> 984076614785023&sdata=CwIsfSfixxyMt0BjBQk2p0%2BrzebG2WeLVgAaD
> bfl678%3D&reserved=0
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose
> the contents to any other person, use it for any purpose, or store or
> copy the information in any medium. Thank you.
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
> https://lists.trust
> edfirmware.org%2Fmailman%2Flistinfo%2Ftf-
> m&data=02%7C01%7Candrey.butok%40nxp.com%7C06837920c9bd44323
> 6e908d705a48d92%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636
> 984076614785023&sdata=CwIsfSfixxyMt0BjBQk2p0%2BrzebG2WeLVgAaD
> bfl678%3D&reserved=0
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
> https://lists.trust
> edfirmware.org%2Fmailman%2Flistinfo%2Ftf-
> m&data=02%7C01%7Candrey.butok%40nxp.com%7C06837920c9bd44323
> 6e908d705a48d92%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636
> 984076614785023&sdata=CwIsfSfixxyMt0BjBQk2p0%2BrzebG2WeLVgAaD
> bfl678%3D&reserved=0
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
For clarification, the IAR IDE supports both pre and post build actions.
/Thomas
Den 2019-07-11 kl. 15:17, skrev David Hu (Arm Technology China) via TF-M:
> Hi Andrej,
>
>
> Does your IDE support pre-build command? Is there any chance to execute the parse and auto-generation in the pre-build step?
>
>
> Best regards,
>
> Hu Ziji
>
>
> ________________________________
> 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: Thursday, July 11, 2019 7:41 PM
> To: Ken Liu (Arm Technology China)
> Cc: tf-m(a)lists.trustedfirmware.org
> Subject: Re: [TF-M] Common scatter files and templates
>
> Hi Ken,
>
>> Could you help to tell the name of the file you don't want to be removed?
> So, any .c,.h,.inc and linker file which may be used during compilation.
> An IDE project (ARM Kei, MCUx, IAR etc.) assumes a fixed set of existing files.
>
> Thanks,
> Andrej
>
> -----Original Message-----
> From: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com>
> Sent: Thursday, July 11, 2019 12:44 PM
> To: Andrej Butok <andrey.butok(a)nxp.com>; tf-m(a)lists.trustedfirmware.org
> Cc: nd <nd(a)arm.com>
> Subject: RE: Common scatter files and templates
>
> Hi Andrej,
>
> Could you help to tell the name of the file you don't want to be removed?
> So that we can estimate what is important for IDE projects and how we could help on that.
>
> An introduction of how your IDE integrate with TF-M code is also welcome.
> Would you share this to us?
>
> Thanks.
>
> -Ken
>
>
>> -----Original Message-----
>> From: Andrej Butok <andrey.butok(a)nxp.com>
>> Sent: Thursday, July 11, 2019 2:25 PM
>> To: David Hu (Arm Technology China) <David.Hu(a)arm.com>; Antonio De
>> Angelis <Antonio.DeAngelis(a)arm.com>; Ken Liu (Arm Technology China)
>> <Ken.Liu(a)arm.com>; Miklos Balint <Miklos.Balint(a)arm.com>
>> Cc: tf-m(a)lists.trustedfirmware.org
>> Subject: RE: Common scatter files and templates
>>
>> Pre-generated files are required for TFM IDE projects.
>> Please do not delete them, find other solution!
>> It can be solved by adding #if/#ifdef.
>>
>> Thank you,
>> Andrej Butok
>>
>> -----Original Message-----
>> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David
>> Hu (Arm Technology China) via TF-M
>> Sent: Thursday, July 11, 2019 4:08 AM
>> To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com>; tf-
>> m(a)lists.trustedfirmware.org; Ken Liu (Arm Technology China)
>> <Ken.Liu(a)arm.com>; Miklos Balint <Miklos.Balint(a)arm.com>
>> Cc: nd <nd(a)arm.com>
>> Subject: Re: [TF-M] Common scatter files and templates
>>
>> Hi Antonio, Ken, Miklos,
>>
>> Currently, we use a preprocessor flag `TFM_MULTI_CORE_TOPOLOGY` to
>> comment the veneer sections in the templates in multi-core topology.
>> Each time before building, we have to run the Python script to
>> generate new link script/scatter file with veneer disabled, to replace the existing ones.
>> It becomes more inconvenient as the number of developers and users on
>> feature-twincpu branch grows.
>>
>> As Chris proposed on
>> https://review.tr
>> ustedfirmware.org%2Fc%2Ftrusted-firmware-
>> m%2F%2B%2F1527&data=02%7C01%7Candrey.butok%40nxp.com%7C068
>> 37920c9bd443236e908d705a48d92%7C686ea1d3bc2b4c6fa92cd99c5c301635%
>> 7C0%7C0%7C636984076614785023&sdata=2SVwa0TpX4a4lP86hsIYiw25YS
>> Zqi8FzFErhpH3CrYI%3D&reserved=0, does it also make sense to
>> directly update the "generated" linker script/scatter file as well, on
>> feature-twincpu branch? `TFM_MULTI_CORE_TOPOLOGY` will be a common
>> flag used in multi- core topology and will help resolve our urgent problem.
>> If the final improvement solution is completed on master branch, we
>> will update the feature branch accordingly when merging it back to master branch.
>>
>> Please let me know if there is a better option for feature-twincpu branch.
>> Thank you.
>>
>> Best regards,
>> Hu Ziji
>>
>> -----Original Message-----
>> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of
>> Antonio De Angelis via TF-M
>> Sent: Thursday, July 11, 2019 3:53 AM
>> To: TF-M(a)lists.trustedfirmware.org; nd <nd(a)arm.com>
>> Subject: Re: [TF-M] Common scatter files and templates
>>
>> Hi Chris,
>>
>> you are right, that file is autogenerated from the template file but
>> both are kept under source control. The reason for this is that the
>> autogenerated file is not created at build time but by manually
>> running the tfm_parse_manifest_list.py, which has to be run every time
>> something in the manifest is changed, and the resulting autogenerated file is committed under source control as well.
>>
>> On the other hand, the build system could be modified to run the
>> parsers at build time so that the autogenerated files wouldn't have to
>> be stored in source control, and we could keep only the template.
>> These two alternatives are both equally valid in my view, but if there
>> is strong consensus for the other we can discuss.
>>
>> Thanks,
>> Antonio
>>
>> ________________________________
>> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of
>> Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org>
>> Sent: 10 July 2019 19:50
>> To: TF-M(a)lists.trustedfirmware.org; Miklos Balint
>> Subject: [TF-M] Common scatter files and templates
>>
>> Can somebody please help me understand this?
>> $ ls platform/ext/common/armclang/
>> tfm_common_s.sct tfm_common_s.sct.template $ ls
>> platform/ext/common/gcc tfm_common_s.ld tfm_common_s.ld.template In
>> both directories, both files are under source control, but the
>> non-template files say that they're auto-generated:
>> /*********** WARNING: This is an auto-generated file. Do not edit!
>> ***********/
>>
>> It's unusual to see both the source file and the artifact under source control.
>>
>> It seems that they're generated by tools/tfm_parse_manifest_list.py,
>> but that doesn't seem to be run as part of the build, so when is it run?
>>
>> Thanks,
>>
>> Chris
>>
>>
>> This message and any attachments may contain confidential information
>> from Cypress or its subsidiaries. If it has been received in error,
>> please advise the sender and immediately delete this message.
>> --
>> TF-M mailing list
>> TF-M(a)lists.trustedfirmware.org
>> https://lists.trust
>> edfirmware.org%2Fmailman%2Flistinfo%2Ftf-
>> m&data=02%7C01%7Candrey.butok%40nxp.com%7C06837920c9bd44323
>> 6e908d705a48d92%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636
>> 984076614785023&sdata=CwIsfSfixxyMt0BjBQk2p0%2BrzebG2WeLVgAaD
>> bfl678%3D&reserved=0
>> IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose
>> the contents to any other person, use it for any purpose, or store or
>> copy the information in any medium. Thank you.
>> --
>> TF-M mailing list
>> TF-M(a)lists.trustedfirmware.org
>> https://lists.trust
>> edfirmware.org%2Fmailman%2Flistinfo%2Ftf-
>> m&data=02%7C01%7Candrey.butok%40nxp.com%7C06837920c9bd44323
>> 6e908d705a48d92%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636
>> 984076614785023&sdata=CwIsfSfixxyMt0BjBQk2p0%2BrzebG2WeLVgAaD
>> bfl678%3D&reserved=0
>> --
>> TF-M mailing list
>> TF-M(a)lists.trustedfirmware.org
>> https://lists.trust
>> edfirmware.org%2Fmailman%2Flistinfo%2Ftf-
>> m&data=02%7C01%7Candrey.butok%40nxp.com%7C06837920c9bd44323
>> 6e908d705a48d92%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636
>> 984076614785023&sdata=CwIsfSfixxyMt0BjBQk2p0%2BrzebG2WeLVgAaD
>> bfl678%3D&reserved=0
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-m
--
*Thomas Törnblom*, /Product Engineer/
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com>
Website: www.iar.com <http://www.iar.com>
Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
Pre-generated files are required for TFM IDE projects.
Please do not delete them, find other solution!
It can be solved by adding #if/#ifdef.
Thank you,
Andrej Butok
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M
Sent: Thursday, July 11, 2019 4:08 AM
To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com>; tf-m(a)lists.trustedfirmware.org; Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com>; Miklos Balint <Miklos.Balint(a)arm.com>
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Common scatter files and templates
Hi Antonio, Ken, Miklos,
Currently, we use a preprocessor flag `TFM_MULTI_CORE_TOPOLOGY` to comment the veneer sections in the templates in multi-core topology. Each time before building, we have to run the Python script to generate new link script/scatter file with veneer disabled, to replace the existing ones.
It becomes more inconvenient as the number of developers and users on feature-twincpu branch grows.
As Chris proposed on https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…p;reserved=0, does it also make sense to directly update the "generated" linker script/scatter file as well, on feature-twincpu branch? `TFM_MULTI_CORE_TOPOLOGY` will be a common flag used in multi-core topology and will help resolve our urgent problem.
If the final improvement solution is completed on master branch, we will update the feature branch accordingly when merging it back to master branch.
Please let me know if there is a better option for feature-twincpu branch.
Thank you.
Best regards,
Hu Ziji
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M
Sent: Thursday, July 11, 2019 3:53 AM
To: TF-M(a)lists.trustedfirmware.org; nd <nd(a)arm.com>
Subject: Re: [TF-M] Common scatter files and templates
Hi Chris,
you are right, that file is autogenerated from the template file but both are kept under source control. The reason for this is that the autogenerated file is not created at build time but by manually running the tfm_parse_manifest_list.py, which has to be run every time something in the manifest is changed, and the resulting autogenerated file is committed under source control as well.
On the other hand, the build system could be modified to run the parsers at build time so that the autogenerated files wouldn't have to be stored in source control, and we could keep only the template. These two alternatives are both equally valid in my view, but if there is strong consensus for the other we can discuss.
Thanks,
Antonio
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 10 July 2019 19:50
To: TF-M(a)lists.trustedfirmware.org; Miklos Balint
Subject: [TF-M] Common scatter files and templates
Can somebody please help me understand this?
$ ls platform/ext/common/armclang/
tfm_common_s.sct tfm_common_s.sct.template $ ls platform/ext/common/gcc tfm_common_s.ld tfm_common_s.ld.template In both directories, both files are under source control, but the non-template files say that they're auto-generated:
/*********** WARNING: This is an auto-generated file. Do not edit! ***********/
It's unusual to see both the source file and the artifact under source control.
It seems that they're generated by tools/tfm_parse_manifest_list.py, but that doesn't seem to be run as part of the build, so when is it run?
Thanks,
Chris
This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
--
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 Antonio, Ken, Miklos,
Currently, we use a preprocessor flag `TFM_MULTI_CORE_TOPOLOGY` to comment the veneer sections in the templates in multi-core topology. Each time before building, we have to run the Python script to generate new link script/scatter file with veneer disabled, to replace the existing ones.
It becomes more inconvenient as the number of developers and users on feature-twincpu branch grows.
As Chris proposed on https://review.trustedfirmware.org/c/trusted-firmware-m/+/1527, does it also make sense to directly update the "generated" linker script/scatter file as well, on feature-twincpu branch? `TFM_MULTI_CORE_TOPOLOGY` will be a common flag used in multi-core topology and will help resolve our urgent problem.
If the final improvement solution is completed on master branch, we will update the feature branch accordingly when merging it back to master branch.
Please let me know if there is a better option for feature-twincpu branch.
Thank you.
Best regards,
Hu Ziji
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M
Sent: Thursday, July 11, 2019 3:53 AM
To: TF-M(a)lists.trustedfirmware.org; nd <nd(a)arm.com>
Subject: Re: [TF-M] Common scatter files and templates
Hi Chris,
you are right, that file is autogenerated from the template file but both are kept under source control. The reason for this is that the autogenerated file is not created at build time but by manually running the tfm_parse_manifest_list.py, which has to be run every time something in the manifest is changed, and the resulting autogenerated file is committed under source control as well.
On the other hand, the build system could be modified to run the parsers at build time so that the autogenerated files wouldn't have to be stored in source control, and we could keep only the template. These two alternatives are both equally valid in my view, but if there is strong consensus for the other we can discuss.
Thanks,
Antonio
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 10 July 2019 19:50
To: TF-M(a)lists.trustedfirmware.org; Miklos Balint
Subject: [TF-M] Common scatter files and templates
Can somebody please help me understand this?
$ ls platform/ext/common/armclang/
tfm_common_s.sct tfm_common_s.sct.template $ ls platform/ext/common/gcc tfm_common_s.ld tfm_common_s.ld.template In both directories, both files are under source control, but the non-template files say that they're auto-generated:
/*********** WARNING: This is an auto-generated file. Do not edit! ***********/
It's unusual to see both the source file and the artifact under source control.
It seems that they're generated by tools/tfm_parse_manifest_list.py, but that doesn't seem to be run as part of the build, so when is it run?
Thanks,
Chris
This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi Chris,
you are right, that file is autogenerated from the template file but both are kept under source control. The reason for this is that the autogenerated file is not created at build time but by manually running the tfm_parse_manifest_list.py, which has to be run every time something in the manifest is changed, and the resulting autogenerated file is committed under source control as well.
On the other hand, the build system could be modified to run the parsers at build time so that the autogenerated files wouldn't have to be stored in source control, and we could keep only the template. These two alternatives are both equally valid in my view, but if there is strong consensus for the other we can discuss.
Thanks,
Antonio
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 10 July 2019 19:50
To: TF-M(a)lists.trustedfirmware.org; Miklos Balint
Subject: [TF-M] Common scatter files and templates
Can somebody please help me understand this?
$ ls platform/ext/common/armclang/
tfm_common_s.sct tfm_common_s.sct.template
$ ls platform/ext/common/gcc
tfm_common_s.ld tfm_common_s.ld.template
In both directories, both files are under source control, but the non-template files say that they're auto-generated:
/*********** WARNING: This is an auto-generated file. Do not edit! ***********/
It's unusual to see both the source file and the artifact under source control.
It seems that they're generated by tools/tfm_parse_manifest_list.py, but that doesn't seem to be run as part of the build, so when is it run?
Thanks,
Chris
This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Can somebody please help me understand this?
$ ls platform/ext/common/armclang/
tfm_common_s.sct tfm_common_s.sct.template
$ ls platform/ext/common/gcc
tfm_common_s.ld tfm_common_s.ld.template
In both directories, both files are under source control, but the non-template files say that they're auto-generated:
/*********** WARNING: This is an auto-generated file. Do not edit! ***********/
It's unusual to see both the source file and the artifact under source control.
It seems that they're generated by tools/tfm_parse_manifest_list.py, but that doesn't seem to be run as part of the build, so when is it run?
Thanks,
Chris
This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.
How would a git repo with some submodules preclude any of the things you mentioned? I guess my initial thought is that there would be an “uber” repo in which TFM, CMSIS and mbedcrypto would all be sub-modules.
There’s also the option of using cmake ExternalProject (https://cmake.org/cmake/help/latest/module/ExternalProject.html?highlight=e…)
Or west
https://pypi.org/project/west/
- k
> On Jul 10, 2019, at 8:47 AM, Ashutosh Singh via TF-M <tf-m(a)lists.trustedfirmware.org> wrote:
>
> Hi,
>
> Initial idea was to keep the external dependencies clearly visible (from code auditability point of view). With submodule we can't checkout the dependencies out of tree. Since the dependencies need to be checked out only once it was considered acceptable nuisance, until you do a pull and version of the dependencies have changed.
> 'repo' was considered as well, but repo tool doesn't work on windows(last I checked).
>
> Thanks,
> Ashu
>
> -----Original Message-----
> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kumar Gala via TF-M
> Sent: 10 July 2019 09:50
> To: Andrej Butok <andrey.butok(a)nxp.com>
> Cc: tf-m(a)lists.trustedfirmware.org
> Subject: Re: [TF-M] Using git submodules for dependencies?
>
> There can always be a fork of the sources kept in TF-M repos to handle the case of needing local modifications for some reason.
>
> - k
>
>> On Jul 10, 2019, at 3:48 AM, Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org> wrote:
>>
>> Hi Kevin,
>>
>> Only if 100% of the external project source code is used without change.
>> Even if it is valid now, nobody will give you this guarantee in future.
>>
>> Regards,
>> Andrej
>>
>> -----Original Message-----
>> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M
>> Sent: Wednesday, July 10, 2019 10:41 AM
>> To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org>
>> Subject: [TF-M] Using git submodules for dependencies?
>>
>> Hi,
>>
>> I'm currently working on integrating TF-M into Zephyr and getting TF-M working with QEMU. Part of that work is simplifying the setup and build process to generate a TF-M secure library.
>>
>> Was the idea of git submodules for dependencies considered and rejected?
>> Using sub-modules would reduce the number of setup steps required, and pair external dependency versions with specific TF-M commits/releases.
>>
>> There may be a valid reason this approach was rejected, but it seems like a sensible option on the surface?
>>
>> Best regards,
>> Kevin Townsend
>> --
>> 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
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi All,
I've pushed a set of patches for review which aims to add multi-image support to MCUBoot. It enables the Secure and Non-secure images
to be handled and updated separately by the bootloader. You can find the links of the reviews and more information in the following ticket:
https://developer.trustedfirmware.org/T421
Please feel free to review any of the patches.:)
Thanks,
David
Hi,
Initial idea was to keep the external dependencies clearly visible (from code auditability point of view). With submodule we can't checkout the dependencies out of tree. Since the dependencies need to be checked out only once it was considered acceptable nuisance, until you do a pull and version of the dependencies have changed.
'repo' was considered as well, but repo tool doesn't work on windows(last I checked).
Thanks,
Ashu
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kumar Gala via TF-M
Sent: 10 July 2019 09:50
To: Andrej Butok <andrey.butok(a)nxp.com>
Cc: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Using git submodules for dependencies?
There can always be a fork of the sources kept in TF-M repos to handle the case of needing local modifications for some reason.
- k
> On Jul 10, 2019, at 3:48 AM, Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org> wrote:
>
> Hi Kevin,
>
> Only if 100% of the external project source code is used without change.
> Even if it is valid now, nobody will give you this guarantee in future.
>
> Regards,
> Andrej
>
> -----Original Message-----
> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M
> Sent: Wednesday, July 10, 2019 10:41 AM
> To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org>
> Subject: [TF-M] Using git submodules for dependencies?
>
> Hi,
>
> I'm currently working on integrating TF-M into Zephyr and getting TF-M working with QEMU. Part of that work is simplifying the setup and build process to generate a TF-M secure library.
>
> Was the idea of git submodules for dependencies considered and rejected?
> Using sub-modules would reduce the number of setup steps required, and pair external dependency versions with specific TF-M commits/releases.
>
> There may be a valid reason this approach was rejected, but it seems like a sensible option on the surface?
>
> Best regards,
> Kevin Townsend
> --
> 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
There can always be a fork of the sources kept in TF-M repos to handle the case of needing local modifications for some reason.
- k
> On Jul 10, 2019, at 3:48 AM, Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org> wrote:
>
> Hi Kevin,
>
> Only if 100% of the external project source code is used without change.
> Even if it is valid now, nobody will give you this guarantee in future.
>
> Regards,
> Andrej
>
> -----Original Message-----
> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M
> Sent: Wednesday, July 10, 2019 10:41 AM
> To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org>
> Subject: [TF-M] Using git submodules for dependencies?
>
> Hi,
>
> I'm currently working on integrating TF-M into Zephyr and getting TF-M working with QEMU. Part of that work is simplifying the setup and build process to generate a TF-M secure library.
>
> Was the idea of git submodules for dependencies considered and rejected?
> Using sub-modules would reduce the number of setup steps required, and pair external dependency versions with specific TF-M commits/releases.
>
> There may be a valid reason this approach was rejected, but it seems like a sensible option on the surface?
>
> Best regards,
> Kevin Townsend
> --
> 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
