- TF-M - lists.trustedfirmware.org

Re: [TF-M] including platform specific interrupt definitions

by DeMars, Alan

Mate, Thank you for your response. I discovered not long after I posted my inquiry that recent merges to master should resolve the problem I'm having. I'm in the process of pulling in those commits locally. Thanks again, Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Mate Toth-Pal via TF-M Sent: Friday, July 19, 2019 1:22 PM To: TF-M(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] including platform specific interrupt definitions Hi Alan, I'm not sure on what version of TF-M is your base. This part of TF-M changed recently. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1354/ This change introduced the generated manifest header files. For each partition a header file is generated, which contains the signals for the partition. Both IRQ signals, and normal signals in case of IPC mode. Up to the following change all the signals (except for IRQ) had to be defined manually in a header file tfm_spm_signal_defs.h. This replaces the manually created IPC model signal definitions to the generated signals: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1356/ This does the same to the IRQ signals (up until this change, IRQ signals had to be defined in tfm_irq_signal_defs.h): https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1589/ This, and the related changes remove the manually created signal files. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1382/ So depending on your base you either need to manually define the signals, or should have it automatically once the generator script is run. As a general advice I would suggest to look at the IRQ signal 'SPM_CORE_IRQ_TEST_1_SIGNAL_TIMER_0_IRQ' which is the IRQ signal for one of the test services, and see where it appears and compare it to yours. Also if you could publish some of your code in the gerrit, we might be able help to find out what is the problem. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 19 July 2019 18:35 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] including platform specific interrupt definitions I'm trying to add s secure interrupt to my secure partition manifest but am getting a compile error because there are no definitions of my secure interrupt IRQ name and SIGNAL name. What is the mechanism for including a platform-specific header that defines platform specific interrupts when compiling "secure_fw/core/ipc/tfm_svcalls.c"? Alan -- 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, 11 months

1
0
0 0

Re: [TF-M] including platform specific interrupt definitions

by Mate Toth-Pal

Hi Alan, I'm not sure on what version of TF-M is your base. This part of TF-M changed recently. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1354/ This change introduced the generated manifest header files. For each partition a header file is generated, which contains the signals for the partition. Both IRQ signals, and normal signals in case of IPC mode. Up to the following change all the signals (except for IRQ) had to be defined manually in a header file tfm_spm_signal_defs.h. This replaces the manually created IPC model signal definitions to the generated signals: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1356/ This does the same to the IRQ signals (up until this change, IRQ signals had to be defined in tfm_irq_signal_defs.h): https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1589/ This, and the related changes remove the manually created signal files. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1382/ So depending on your base you either need to manually define the signals, or should have it automatically once the generator script is run. As a general advice I would suggest to look at the IRQ signal 'SPM_CORE_IRQ_TEST_1_SIGNAL_TIMER_0_IRQ' which is the IRQ signal for one of the test services, and see where it appears and compare it to yours. Also if you could publish some of your code in the gerrit, we might be able help to find out what is the problem. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 19 July 2019 18:35 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] including platform specific interrupt definitions I'm trying to add s secure interrupt to my secure partition manifest but am getting a compile error because there are no definitions of my secure interrupt IRQ name and SIGNAL name. What is the mechanism for including a platform-specific header that defines platform specific interrupts when compiling "secure_fw/core/ipc/tfm_svcalls.c"? Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 11 months

1
0
0 0

including platform specific interrupt definitions

by DeMars, Alan

I'm trying to add s secure interrupt to my secure partition manifest but am getting a compile error because there are no definitions of my secure interrupt IRQ name and SIGNAL name. What is the mechanism for including a platform-specific header that defines platform specific interrupts when compiling "secure_fw/core/ipc/tfm_svcalls.c"? Alan

6 years, 11 months

1
0
0 0

Re: [TF-M] Missing veneer function implementations

by Kevin Townsend

Hi Mate, I was able to get this working by changing the build config to a non-IPC setup (ConfigDefault.cmake), in which case the tfm veneers functions are available and I can call the PSA API shims directly: SYMBOL TABLE: 100efc80 g F *ABS* 00000008 tfm_tfm_crypto_generate_random_veneer 100efc88 g F *ABS* 00000008 tfm_tfm_crypto_get_generator_capacity_veneer ... Thanks for the clarification. Calling `psa_generate_random` from the NSPE works are expected now. Best regards, Kevin On Wed, 17 Jul 2019 at 14:16, Mate Toth-Pal via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > Hi Kevin, > > Based on what you write your build is probably OK. To access the > psa_generate_random service, you need to call the function 'psa_status_t > psa_generate_random(uint8_t *output, size_t output_size)', declared in > interface/include/psa/crypto.h. > > in case the TFM/PSA APIs are in use (your case), the transition to the > secure code is done through the tfm_psa_* veneers. A service (for example > psa_generate_random) is connected with a call to 'psa_connect(...)', which > is provided with the ID of the selected service, and then 'psa_call(...)' > is called with the handle received from 'psa_connect(...)' (as it is > described in the PSA FF Specification). However this exchange is > implemented inside the TF-M's crypto API implementation in > interface\src\tfm_crypto_api.c, so you only need to call the API function. > > The veneer 'tfm_tfm_crypto_generate_random_veneer' is compiled into TF-M > when the Library model is used. In this case the secure services can be > accessed with a single function call, and the tfm_psa_* veneers are not > available. However please note, that even in this case you can use TF-M's > crypto API, which will call the service the correct way. (Look for the > conditionally compiled blocks depending on the TFM_PSA_API macro in the API > implementation.) > > I hope this answers your questions. > > Regards, > Mate > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin > Townsend via TF-M > Sent: 17 July 2019 13:12 > To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> > Subject: [TF-M] Missing veneer function implementations > > Greetings, > > I'm trying to get the TFM/PSA APIs working in Zephyr, based on the > upstream TF-M repository. > > The libraries are being built with the following settings, followed by > make and make install: > > cmake -G\"Unix Makefiles\" -DPROJ_CONFIG=`readlink -f > ../ConfigRegressionIPC.cmake` -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../ > > *ConfigRegressionIPC is used simply to include the test service for > debugging purposes for now. > > The SPE is handled by TF-M, and the NSPE uses Zephyr, with zephyr making > calls to the SPE via the PSA APIs, which should call the appropriate > veneers via the source files in the `install/export/tfm` folder, as well as > `veneers/s_veneers.o` > > This works fine calling the test service via `tfm_psa_call_veneer`, but > whenever I try to make use of any of the .c shims in the PSA API (for > example `psa_generate_random`), I get the following error(s): > > tfm_crypto_api.c:1571: undefined reference to > `tfm_tfm_crypto_generate_random_veneer' > > I assumed the veneers are in the `s_veneers.o` file generated as part of > the TF-M build, and this file is linked into during the Zephyr build > process, but when I look at the contents of the .o file (which was > suspiciously small at 740b) I only see the following: > > $ arm-none-eabi-objdump -t tfm/build/install/export/tfm/veneers/s_veneers.o > > /tfm/build/install/export/tfm/veneers/s_veneers.o: file format > elf32-littlearm > > SYMBOL TABLE: > 100efc80 g F *ABS* 00000008 tfm_psa_framework_version_veneer > 100efc88 g F *ABS* 00000008 TZ_InitContextSystem_S > 100efc90 g F *ABS* 00000008 TZ_LoadContext_S > > 100efc98 g F *ABS* 00000008 tfm_psa_version_veneer > 100efca0 g F *ABS* 00000008 tfm_psa_close_veneer > 100efca8 g F *ABS* 00000008 TZ_FreeModuleContext_S > 100efcb0 g F *ABS* 00000008 tfm_psa_connect_veneer > 100efcb8 g F *ABS* 00000008 TZ_AllocModuleContext_S > 100efcc0 g F *ABS* 00000008 tfm_secure_client_service_veneer_run_tests > 100efcc8 g F *ABS* 00000008 TZ_StoreContext_S > 100efcd0 g F *ABS* 00000008 tfm_psa_call_veneer > 100efcd8 g F *ABS* 00000008 tfm_register_client_id > > Clearly I'm missing something in the build process so that all of the > other veneers are present, but it's not obvious to me at this point what. > At present I can only make calls to `tfm_psa_call` to the test service, but > that isn't going to help with the goal of publishing a sample application > that meets the requirements for PSA Level 1 certification. > > Any suggestions on what knob to turn to include the missing veneers would > be very welcome. > > Best regards, > Kevin Townsend > -- > 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, 11 months

2
1
0 0

Re: [TF-M] Missing veneer function implementations

by Mate Toth-Pal

Hi Kevin, Based on what you write your build is probably OK. To access the psa_generate_random service, you need to call the function 'psa_status_t psa_generate_random(uint8_t *output, size_t output_size)', declared in interface/include/psa/crypto.h. in case the TFM/PSA APIs are in use (your case), the transition to the secure code is done through the tfm_psa_* veneers. A service (for example psa_generate_random) is connected with a call to 'psa_connect(...)', which is provided with the ID of the selected service, and then 'psa_call(...)' is called with the handle received from 'psa_connect(...)' (as it is described in the PSA FF Specification). However this exchange is implemented inside the TF-M's crypto API implementation in interface\src\tfm_crypto_api.c, so you only need to call the API function. The veneer 'tfm_tfm_crypto_generate_random_veneer' is compiled into TF-M when the Library model is used. In this case the secure services can be accessed with a single function call, and the tfm_psa_* veneers are not available. However please note, that even in this case you can use TF-M's crypto API, which will call the service the correct way. (Look for the conditionally compiled blocks depending on the TFM_PSA_API macro in the API implementation.) I hope this answers your questions. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: 17 July 2019 13:12 To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Missing veneer function implementations Greetings, I'm trying to get the TFM/PSA APIs working in Zephyr, based on the upstream TF-M repository. The libraries are being built with the following settings, followed by make and make install: cmake -G\"Unix Makefiles\" -DPROJ_CONFIG=`readlink -f ../ConfigRegressionIPC.cmake` -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../ *ConfigRegressionIPC is used simply to include the test service for debugging purposes for now. The SPE is handled by TF-M, and the NSPE uses Zephyr, with zephyr making calls to the SPE via the PSA APIs, which should call the appropriate veneers via the source files in the `install/export/tfm` folder, as well as `veneers/s_veneers.o` This works fine calling the test service via `tfm_psa_call_veneer`, but whenever I try to make use of any of the .c shims in the PSA API (for example `psa_generate_random`), I get the following error(s): tfm_crypto_api.c:1571: undefined reference to `tfm_tfm_crypto_generate_random_veneer' I assumed the veneers are in the `s_veneers.o` file generated as part of the TF-M build, and this file is linked into during the Zephyr build process, but when I look at the contents of the .o file (which was suspiciously small at 740b) I only see the following: $ arm-none-eabi-objdump -t tfm/build/install/export/tfm/veneers/s_veneers.o /tfm/build/install/export/tfm/veneers/s_veneers.o: file format elf32-littlearm SYMBOL TABLE: 100efc80 g F *ABS* 00000008 tfm_psa_framework_version_veneer 100efc88 g F *ABS* 00000008 TZ_InitContextSystem_S 100efc90 g F *ABS* 00000008 TZ_LoadContext_S 100efc98 g F *ABS* 00000008 tfm_psa_version_veneer 100efca0 g F *ABS* 00000008 tfm_psa_close_veneer 100efca8 g F *ABS* 00000008 TZ_FreeModuleContext_S 100efcb0 g F *ABS* 00000008 tfm_psa_connect_veneer 100efcb8 g F *ABS* 00000008 TZ_AllocModuleContext_S 100efcc0 g F *ABS* 00000008 tfm_secure_client_service_veneer_run_tests 100efcc8 g F *ABS* 00000008 TZ_StoreContext_S 100efcd0 g F *ABS* 00000008 tfm_psa_call_veneer 100efcd8 g F *ABS* 00000008 tfm_register_client_id Clearly I'm missing something in the build process so that all of the other veneers are present, but it's not obvious to me at this point what. At present I can only make calls to `tfm_psa_call` to the test service, but that isn't going to help with the goal of publishing a sample application that meets the requirements for PSA Level 1 certification. Any suggestions on what knob to turn to include the missing veneers would be very welcome. Best regards, Kevin Townsend -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 11 months

1
0
0 0

MCUBoot enhancments

by Tamas Ban

Hi All, I've pushed a set of patches for review which aims to add the following features to MCUBoot: * Integration with HW key(s). * Sign & authenticate S and NS image independently with different keys. Design proposal for this change: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1453/ Related changes are listed here: https://developer.trustedfirmware.org/T438 Please feel free to review any of the patches.:) Thanks, Tamas

6 years, 11 months

1
0
0 0

Missing veneer function implementations

by Kevin Townsend

Greetings, I'm trying to get the TFM/PSA APIs working in Zephyr, based on the upstream TF-M repository. The libraries are being built with the following settings, followed by make and make install: cmake -G\"Unix Makefiles\" -DPROJ_CONFIG=`readlink -f ../ConfigRegressionIPC.cmake` -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../ *ConfigRegressionIPC is used simply to include the test service for debugging purposes for now. The SPE is handled by TF-M, and the NSPE uses Zephyr, with zephyr making calls to the SPE via the PSA APIs, which should call the appropriate veneers via the source files in the `install/export/tfm` folder, as well as `veneers/s_veneers.o` This works fine calling the test service via `tfm_psa_call_veneer`, but whenever I try to make use of any of the .c shims in the PSA API (for example `psa_generate_random`), I get the following error(s): tfm_crypto_api.c:1571: undefined reference to `tfm_tfm_crypto_generate_random_veneer' I assumed the veneers are in the `s_veneers.o` file generated as part of the TF-M build, and this file is linked into during the Zephyr build process, but when I look at the contents of the .o file (which was suspiciously small at 740b) I only see the following: $ arm-none-eabi-objdump -t tfm/build/install/export/tfm/veneers/s_veneers.o /tfm/build/install/export/tfm/veneers/s_veneers.o: file format elf32-littlearm SYMBOL TABLE: 100efc80 g F *ABS* 00000008 tfm_psa_framework_version_veneer 100efc88 g F *ABS* 00000008 TZ_InitContextSystem_S 100efc90 g F *ABS* 00000008 TZ_LoadContext_S 100efc98 g F *ABS* 00000008 tfm_psa_version_veneer 100efca0 g F *ABS* 00000008 tfm_psa_close_veneer 100efca8 g F *ABS* 00000008 TZ_FreeModuleContext_S 100efcb0 g F *ABS* 00000008 tfm_psa_connect_veneer 100efcb8 g F *ABS* 00000008 TZ_AllocModuleContext_S 100efcc0 g F *ABS* 00000008 tfm_secure_client_service_veneer_run_tests 100efcc8 g F *ABS* 00000008 TZ_StoreContext_S 100efcd0 g F *ABS* 00000008 tfm_psa_call_veneer 100efcd8 g F *ABS* 00000008 tfm_register_client_id Clearly I'm missing something in the build process so that all of the other veneers are present, but it's not obvious to me at this point what. At present I can only make calls to `tfm_psa_call` to the test service, but that isn't going to help with the goal of publishing a sample application that meets the requirements for PSA Level 1 certification. Any suggestions on what knob to turn to include the missing veneers would be very welcome. Best regards, Kevin Townsend

6 years, 11 months

1
0
0 0

Re: [TF-M] Old Mbed-Crypto library?

by Andrej Butok

Hi Antonio, > TF-M Crypto will align to newest release of Mbed Crypto when they will become available Just FYI: The newest official release of Mbed Crypto is v1.1.0: https://github.com/ARMmbed/mbed-crypto/releases Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Monday, May 27, 2019 6:22 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Old Mbed-Crypto library? Hi Andrej, TF-M Crypto has moved to use the same API as the latest available *release* of Mbed Crypto which is Mbed Crypto 1.0.0 . Mbed Crypto is a reference implementation of the PSA Crypto API, which are under active development. TF-M Crypto will align to newest release of Mbed Crypto when they will become available; these new releases will incorporate the new features which are developed as part of the PSA Crypto API, and there will be cases where the new features will break legacy code (i.e. API changes). Regarding the change that you mention, i.e. psa_key_slot_t vs psa_key_handle_t . The concept of psa_key_handle_t that TF-M Crypto is using now is indeed a newer (updated) concept introduced with later versions of the PSA Crypto API to replace the outdated concept of psa_key_slot_t. For example, if you look at the current latest development version of the PSA Crypto API, you will see that psa_key_handle_t is used to handle keys. This is an example of a breaking change in the API that has been introduced by newer releases of the PSA Crypto API. You are right, this change will break regression / PSA API compliance tests, in fact as part of the latest set of patches you can see that the Regression tests are upgraded to use the new concept of psa_key_handle_t instead of psa_key_slot_t. From these updated tests, you can get an idea of how to use the psa_key_handle_t. After this update, TF-M Crypto can't support the PSA API compliance tests (ACK) which were run previously (i.e. the ew_beta0 branch). The psa-arch-test team is in the process of providing an update on the master branch which will enable TF-M Crypto to run compliance tests from there. This should happen in the next couple of weeks. Please let me know in case you need any more clarification. Best regards, Antonio ________________________________ 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: 27 May 2019 12:52 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Old Mbed-Crypto library? Hello, tfm_build_instruction.rst tells to use mbed-Crypto instead of mbedTLS: git clone https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… -b mbedcrypto-1.0<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>.0 But the issue is that it references to the obsolete (3 month old) Mbed-Crypto library. Also, it looks like this old MbedCrypto has downgraded TFM/PSA Crypto API (from key-slot to key-handle) => this is step back in PSA TFM API, which should break crypto regression and PSA tests. We do not want to downgrade our SDK MbedCrypto, better to freeze TFM. Any plans to use the last Crypto Lib and to revert the PSA API degradation? 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…

6 years, 11 months

2
2
0 0

Changing IPC design document to .rst format

by Ken Liu (Arm Technology China)

Hi, This is a design document change for IPC, the intention is to change design document from wiki page to rst format. The patch is put at: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1533 The plan is to put this design document under source control and the following feature changes and enhancement about IPC will be pushed as patches on it - which helps review. Since the original text is already public so I changed the doc status to 'Detailed', plan is to merge it soon with some quick comment. If you think some necessary points are missing please leave comments in this mailing thread and we will add them later with a new patch. Thanks. -Ken

6 years, 11 months

1
0
0 0

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

by David Hu (Arm Technology China)

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

6 years, 11 months

2
3
0 0

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

by Thomas Törnblom

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>

6 years, 11 months

1
0
0 0

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, 11 months

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, 11 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.

6 years, 11 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.

6 years, 11 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

6 years, 11 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

6 years, 11 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

6 years, 11 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

6 years, 11 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…

6 years, 11 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

6 years, 11 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

6 years, 11 months

1
0
0 0

independent device driver model working along side SPM

by R, Manoj

Hi, Is there a design guideline available for device driver which is working on secure side alongside SPM. I do not want to plug my driver in TF-M due to latency considerations. Basically my plan is to introduce non secure callable veneers for calling the interfaces of the driver which I am introducing. Any thoughts on this will be helpful. Regards Manoj

6 years, 12 months

1
0
0 0

Changes to PSA headers in TF-M

by Jamie Fox

Hi all, I am proposing a couple of changes to the standard PSA headers in TF-M. The first change is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1458/ It renames the standard PSA headers in TF-M from psa_<api>.h to psa/<api>.h. TF-M defined headers are not affected. This change also tweaks a large number of #includes across the TF-M repo to use the new names. Any code maintained outside the TF-M repo that includes PSA headers from TF-M will also need to be changed to use the new names in #includes once this is merged. The benefit of this change is that is brings the names of the headers in TF-M into agreement with the names used in the PSA Firmware Framework. It will also make running the PSA API tests easier, as the step of copying the PSA headers to the standard names is no longer required. The second change is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1459/ It adds a copy of the psa/error.h header, which contains new standard error codes intended to be used by the SPM and RoT Services. The "PSA_SUCCESS" and "psa_status_t" definitions are also moved to this header, and it is included by psa/client.h and psa/service.h. This change should have minimal impact on other code -- no code is immediately changed to use the new error codes, but upstreaming the header now allows services to start using the new error codes when needed. Kind regards, Jamie

6 years, 12 months

1
0
0 0

[RFC] Secure Partition Runtime Library

by Ken Liu (Arm Technology China)

Hi, We are now involving secure partition runtime library into tf-m design. While implementing isolation level 2, some runtime APIs (printf e.g.) calling would cause fault, because it is accessing global variables (The STDIO instance) or need to manipulate hardware (UART). So we shutdown calling to these APIs - it is lucky that the secure service logic does not rely on these functions. This leads to the thinking of runtime APIs implementation - not only C runtime mentioned in PSA FF specification, but also developer APIs for service client. These APIs are definitely necessary and need to work well under all isolation levels. Since we cannot put multiple runtime copies into secure partitions (waste and not supported by single firmware linker design), shared runtime library looks like the only choice. Here we introduce the design of a runtime library for secure partition usage. We aligned the concepts with PSA FF and it does not break the mandatory requirements of isolation, and proposes designs for some dedicated APIs. I know there may be similar runtime implementations somewhere, while I just want to implement the functions quick to make out a solution before other library searching and investigating stage (which may spent quite much time). The key requirements of this runtime library are: - This library is protected as Read-Only + executable by MPU, so all other data will not be included into protected region. This point is very important. - For those session/handle based API set, necessary supporting from tooling or other parts needs to be involved. Please help to review the design document at: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1425 Feel free to add you as reviewers and comment something; and you can reply to this thread, too. Any new thinking is worthy of being discussed. Thanks. -Ken

7 years

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M