- TF-M - lists.trustedfirmware.org

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

5 years, 9 months

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.

5 years, 9 months

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.

5 years, 9 months

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

5 years, 9 months

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

5 years, 9 months

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

5 years, 9 months

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

5 years, 9 months

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…

5 years, 9 months

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

5 years, 9 months

1
0
0 0

Re: [TF-M] [PLEASE READ] Move configuration files into specified directory

by Ken Liu (Arm Technology China)

Hi, The last patch for this task is pushed for review: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1487 Please help to review and the 'configs' directory would be the only place for holding configurations. 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, June 25, 2019 2:02 PM > To: TF-M(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [TF-M] [PLEASE READ] Move configuration files into specified directory > > Hi, > Configurations has been moved into 'configs' directory. Please: > - Update your build commands to build with configurations under 'configs' > directory, check updated document: docs/user_guides/tfm_build_instruction.rst > - If you want to push new configurations, please put new configurations under > 'configs' directory. > > The dummy configurations under root directory will be removed soon so please > DO UPDATE YOUR BUILD COMMAND! > > 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, June 18, 2019 10:03 AM > > To: TF-M(a)lists.trustedfirmware.org > > Cc: nd <nd(a)arm.com> > > Subject: Re: [TF-M] [RFC] Move configuration files into specified > > directory > > > > Hi, > > The patch has been pushed for a while and is going to be merged in one > > week, please help to review it if you planned but still not have a look: > > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1234 > > > > After this patch get merged, all new configurations created in root > > directory will be rejected. Please create new configuration files under ./configs > directory. > > The existing fake configuration files under root directory will be > > removed after CI setting changed. > > > > 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, June 11, 2019 1:40 PM > > > To: TF-M(a)lists.trustedfirmware.org > > > Cc: nd <nd(a)arm.com> > > > Subject: [TF-M] [RFC] Move configuration files into specified > > > directory > > > > > > Hi, > > > Since the number of configuration files is increasing, let’s move > > > the configuration files (ConfigXXXX.cmake) into specified directory. > > > This would reduces the files under root directory and makes the > > > structure more clearer. > > > > > > I have created the issue and patch for it: > > > https://developer.trustedfirmware.org/T394 > > > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1234 > > > > > > IMPORTANT NOTES: > > > To be compatible with the existing building configurations, the > > > existing configuration files have been forwarded into the > > > corresponded configuration file under ./configs. Which means there > > > are two set of configuration files under sources tree at current – > > > but this will change soon. There is a warning while you are building > > > with root configurations files: “Please use the configs available in > > > the ./config sub- > > directory.” > > > > > > So please: > > > > > > - If you are planning to create new configuration, create it under > > > ./configs instead of root directory > > > - The reference of configuration files under root directory will be > > > removed soon, please change your build system setting to reference > > > the configuration files put under ./configs > > > > > > Any feedbacks please reply this mail or put comments under the > > > issue, thanks > > > 😉 > > > > > > -Ken > > > > > > -- > > > 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

5 years, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M