- 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, 4 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, 4 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, 4 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, 4 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, 4 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, 4 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, 4 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, 4 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, 5 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, 5 months

2
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M