- TF-M - lists.trustedfirmware.org

Re: [TF-M] Common scatter files and templates

by Andrej Butok

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…

6 years, 1 month

2
2
0 0

Re: [TF-M] Common scatter files and templates

by David Hu (Arm Technology China)

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

6 years, 1 month

2
2
0 0

Re: [TF-M] Common scatter files and templates

by Antonio De Angelis

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.

6 years, 1 month

1
0
0 0

Common scatter files and templates

by Christopher Brand

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.

6 years, 1 month

1
0
0 0

Re: [TF-M] Using git submodules for dependencies?

by Kumar Gala

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

6 years, 1 month

1
0
0 0

Add multi-image support to MCUBoot

by David Vincze

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

6 years, 1 month

1
0
0 0

Re: [TF-M] Using git submodules for dependencies?

by Ashutosh Singh

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

6 years, 1 month

1
0
0 0

Re: [TF-M] Using git submodules for dependencies?

by Kumar Gala

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

6 years, 1 month

1
0
0 0

Re: [TF-M] Using git submodules for dependencies?

by Andrej Butok

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…

6 years, 1 month

1
0
0 0

Using git submodules for dependencies?

by Kevin Townsend

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

6 years, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M