- TF-M - lists.trustedfirmware.org

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Ken Liu

Hi, Thanks for the input - this should be the goal we are approaching. I believe the updated build system has changed something, and I will raise an proposal based on that during October, let's discuss when the proposal is done. Before that, two more questions: * So if a user have to modify the file manually, will they work on the .sct directly, or the .sct.template? * Does your IDE support pre-build function? What kinds of command it could support? An IDE specific script or general shell commands or python? Thanks. /Ken From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Wednesday, September 23, 2020 3:33 PM To: Gyorgy Szing <Gyorgy.Szing(a)arm.com>; Ken Liu <Ken.Liu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Ken, So we are using one default/typical configuration. If any change in it, a user have to do changes manually which are not clear without deeper knowledge of the TFM project. But this is the issue of the TF-M chosen approach - fully rely on cmake preprocessing. The proposal is to use approach which is good for all worlds (cmake and IDEs) and which is used by all embedded MCU open-source projects like MbedTLS, FreeRTOS, lwIP, FNET and etc. Which is to have only one set of platform-independent files and the framework configuration from a user/project configuration file. It will work for both worlds, will solve all configuration issues we have, and will make TF-M easy to use and more popular. I am talking about this from very beginning. As no steps in right direction, we have a forked TF-M for our SDK. Thanks George for support ;) Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:45 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Andrej, Sounds like your IDE is using the default .sct/.ld file, may I ask some a question that: * Is there a scenario that someone wants to add more partitions other than the default ones into your system, and how could they do that? I believe the existing .sct/.ld do not support extra partitions out of the default ones unless some manually modification is done. We need to support more components (partition is the direct example), so in this case, the sct/ld can't be avoided to be modified. Or do you think if we put a specific .sct/.ld under nxp folder would work if there is no other partitions are needed? Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Wednesday, September 23, 2020 8:46 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi, Good point, this is an important factor. I think templating can be IDE compliant as long as the IDE does support pre-build step(s). The current build flow already contains steps requiring this and thus I don't think situation would be much worse with any mentioned solution than it is today. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M Sent: 23 September 2020 08:33 To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Please, do not add changes to sources & linker-files which may harm Non-Cmake systems (IDEs). Thanks, Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:05 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder As cmake is still the build system, let me check the cmake related feature - but need to wait the build system change get merged then we can take a look where to start. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Tuesday, September 22, 2020 4:43 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on "simple" values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. "Not sure if all these format support #include" The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org…> [2] https://jinja.palletsprojects.com/en/2.11.x/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjinja.pal…> [3] https://github.com/kblomqvist/yasha<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 22 September 2020 10:15 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

5 years, 5 months

1
0
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Gyorgy Szing

Hi, Good point, this is an important factor. I think templating can be IDE compliant as long as the IDE does support pre-build step(s). The current build flow already contains steps requiring this and thus I don't think situation would be much worse with any mentioned solution than it is today. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 23 September 2020 08:33 To: Ken Liu <Ken.Liu(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Please, do not add changes to sources & linker-files which may harm Non-Cmake systems (IDEs). Thanks, Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:05 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder As cmake is still the build system, let me check the cmake related feature - but need to wait the build system change get merged then we can take a look where to start. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Tuesday, September 22, 2020 4:43 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on "simple" values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. "Not sure if all these format support #include" The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org…> [2] https://jinja.palletsprojects.com/en/2.11.x/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjinja.pal…> [3] https://github.com/kblomqvist/yasha<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 22 September 2020 10:15 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

5 years, 5 months

1
0
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Andrej Butok

Please, do not add changes to sources & linker-files which may harm Non-Cmake systems (IDEs). Thanks, Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:05 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder As cmake is still the build system, let me check the cmake related feature - but need to wait the build system change get merged then we can take a look where to start. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Tuesday, September 22, 2020 4:43 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on "simple" values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. "Not sure if all these format support #include" The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org…> [2] https://jinja.palletsprojects.com/en/2.11.x/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjinja.pal…> [3] https://github.com/kblomqvist/yasha<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 22 September 2020 10:15 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

5 years, 5 months

2
1
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Ken Liu

As cmake is still the build system, let me check the cmake related feature - but need to wait the build system change get merged then we can take a look where to start. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: Tuesday, September 22, 2020 4:43 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on "simple" values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. "Not sure if all these format support #include" The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html [2] https://jinja.palletsprojects.com/en/2.11.x/ [3] https://github.com/kblomqvist/yasha From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 22 September 2020 10:15 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

5 years, 5 months

1
0
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Gyorgy Szing

Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on "simple" values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. "Not sure if all these format support #include" The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html [2] https://jinja.palletsprojects.com/en/2.11.x/ [3] https://github.com/kblomqvist/yasha From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 22 September 2020 10:15 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

5 years, 5 months

1
0
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Ken Liu

Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

5 years, 5 months

1
0
0 0

Linaro Connect Sessions of Interest

by Don Harbin

Hi All, As Linaro Connect starts tomorrow, here are some pointers to sessions that will be of interest related to trustedfirmware.org. - *PSA Secure Partitions in OP-TEE* - Tuesday, September 22nd (1:25-1:50pm UTC) - Speaker: Miklos Balint - Slides available here <https://static.sched.com/hosted_files/lvc20/9a/LVC20-112_PSA_Secure_Partiti…> - *Trusted Firmware Project update* - Tuesday, Sept. 22nd (2:00-2:25pm UTC) - Spreaders: Matteo Carlini, Shebu Kuriakose - Slides available here <https://static.sched.com/hosted_files/lvc20/1e/LVC20-113-Trusted-Firmware-p…> - *Scalable Security Using Trusted Firmware-M Profiles* - Wednesday September 23rd (11.45am – 12.10pm UTC) - Speakers: Shebu Kuiakose, David Want - Slides available here <https://static.sched.com/hosted_files/lvc20/d0/ScalableSecurityUsingTrusted…> - *Enable UEFI Secure Boot using OP-TEE as Secure Partition* - Thursday September 24th (3.45-4.10pm UTC) - Speakers: Sahil Malhotra, Ilias Apalodimas - *Secure Partition Manager (SEL2 firmware) for Arm A-class devices* - Thursday September 24th (4.15-4.40pm UTC) - Speaker: Olivier Deprez - Slides are available here <https://static.sched.com/hosted_files/lvc20/09/LVC20-305-secure-partition-m…> Some general pointers to sessions of potential interest: - Security related topics can be viewed here - Boot architecture topics can be viewed here As a reminder, sign up for tomorrow's event is at Linaro Connect Registration <https://connect.linaro.org/> and is free, so feel free to forward this information on. :) The overall schedule is available at the same link as registration in case you may be interested in other sessions. Best regards, Don

5 years, 6 months

1
0
0 0

Re: [TF-M] Patch to upgrade crypto service to use latest mbedTLS tag (v2.23.0)

by Soby Mathew

For the record, I have attached the full log of the PSA Arch Crypto test run on AN521. The SHA of respective repositories are the test run given below: TF-M - 8f895ab8 PSA Arch tests - ee3c463d tf-m-tests - 7789423 mbedtls - tag: mbedtls-2.23.0 There is an additional failure for test "psa_close_key with RSA 2048 keypair" compared to the summary report below. This is due to incorrect build flag propagation for changing the ITS_MAX_ASSET_SIZE. This will be corrected in the following days. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew via TF-M Sent: 21 August 2020 11:22 To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Patch to upgrade crypto service to use latest mbedTLS tag (v2.23.0) Just an update to this, I have merged the patch which upgrades to the latest mbedTLS tag. The PSA Arch initial attestation test suite fails to build after this merge due to width change of `ecc_curve_t` type. The issue is reported here in PSA Arch test github project : https://github.com/ARM-software/psa-arch-tests/pull/232 The patch for changing the ITS_MAX_ASSET_SIZE is still outstanding and I hope to merge it after a week. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Soby Mathew via TF-M Sent: 11 August 2020 16:24 To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] Patch to upgrade crypto service to use latest mbedTLS tag (v2.23.0) Hi Everyone The following patch updates the crypto service in TF-M to use the latest mbedTLS tag v2.23.0. All reviews for the same will be much appreciated. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5252/1 With this update, additional PSA APIs psa_hash_compute() and psa_hash_compare() are now supported. There is also another patch for platforms to update the ITS_MAX_ASSET_SIZE when testing with PSA Crypto API compliance test as one of the tests require a larger size: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5253/1 . Could the platform owners review the same and let me know whether the size changes are OK ? With the above patches, the API compliance remains the same as v1.0 Beta 3 and the PSA Crypto compliance test suite gives the below results (as tested on AN521) : ************ Crypto Suite Report ********** TOTAL TESTS : 61 TOTAL PASSED : 42 TOTAL SIM ERROR : 0 TOTAL FAILED : 17 TOTAL SKIPPED : 2 ****************************************** Best Regards Soby Mathes

5 years, 6 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - September 17

by Summer Qin

Hi Anton, I'd like to briefly introduce the enhancement of the TF-M initialization flow, about 20 minutes. Regards, Summer ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Sherry Zhang via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Tuesday, September 15, 2020 3:08 PM To: Anton Komlev <Anton.Komlev(a)arm.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M Technical Forum call - September 17 Hi Anton, I would like to give a very brief introduction of the integration work of TF-M and FreeRTOS Kernel which has been merged into FreeRTOS. It will take about 10 minutes around. Regards, Sherry From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, September 9, 2020 11:34 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - September 17 Hello, The next Technical Forum is planned on Thursday, September 17 at 6:00-07:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

5 years, 6 months

2
1
0 0

Re: [TF-M] TF-M Technical Forum call - September 17

by Sherry Zhang

Hi Anton, I would like to give a very brief introduction of the integration work of TF-M and FreeRTOS Kernel which has been merged into FreeRTOS. It will take about 10 minutes around. Regards, Sherry From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, September 9, 2020 11:34 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - September 17 Hello, The next Technical Forum is planned on Thursday, September 17 at 6:00-07:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

5 years, 6 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - September 17

by Kevin Peng

Anton, I'd like to give an update on the HAL APIs, around 10 minutes. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, September 9, 2020 11:34 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - September 17 Hello, The next Technical Forum is planned on Thursday, September 17 at 6:00-07:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

5 years, 6 months

1
0
0 0

Secure Enclave solution in TF-M

by Mark Horvath

Dear All, Following the tech forum presentation (back in 6th August) I uploaded the draft design document for the Secure Enclave topic: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5653 I also updated the first implementation of the proposed solution for the Musca-B1 board with minimal features, marked as WIP: https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope… Limitations, missing features, notes: * No support for isolation level2 on SSE-200 * Protected Storage is an Application RoT partition, but PS also moved to Secure Enclave * Some regression tests running on secure side of SSE-200 fail as all messages are forwarded with the same client ID to Secure Enclave * All IPC message forwarding is a blocking call * Only one message is put into the mailbox at a time * Musca-B1 related documentation is not complete yet * Generated files are not committed, manifest parser should be run before build. * The BL0 component mentioned in the tech forum presentation is not uploaded, as it is based on the new cmake system, and not so interesting right now * Cmake changes are rudimentary, will be rebased to new cmake system. Any feedback very welcomed! Best regards, Márk Horváth Senior Software Engineer Mark.Horvath(a)arm.com<mailto:Mark.Horvath@arm.com> Arm Hungary Kft., Corvin Offices II, Crystal Tower, Budapest, Futó u. 45. H-1082 Hungary www.arm.com<http://www.arm.com/>

5 years, 6 months

1
0
0 0

Re: [TF-M] Integration of TF-M and FreeRTOS Kernel has been merged into FreeRTOS

by Anton Komlev

Great news! Congratulations, Shery, David. You made it happen! Cheers, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang via TF-M Sent: 14 September 2020 04:47 To: tf-m(a)lists.trustedfirmware.org; Sherry Zhang <Sherry.Zhang2(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Integration of TF-M and FreeRTOS Kernel has been merged into FreeRTOS Thanks Sherry for sharing this great news! Regards, David Wang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Sherry Zhang via TF-M Sent: Monday, September 14, 2020 9:50 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] Integration of TF-M and FreeRTOS Kernel has been merged into FreeRTOS Hi all, The integration of TF-M and FreeRTOS Kernel has been merged into the official FreeRTOS Kernel repository<https://github.com/FreeRTOS/FreeRTOS-Kernel> master branch. You can follow this port<https://github.com/FreeRTOS/FreeRTOS-Kernel/tree/master/portable/ThirdParty…> on Cortex-M33 platforms. Regards, Sherry Zhang

5 years, 6 months

1
0
0 0

Re: [TF-M] Integration of TF-M and FreeRTOS Kernel has been merged into FreeRTOS

by David Wang

Thanks Sherry for sharing this great news! Regards, David Wang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Sherry Zhang via TF-M Sent: Monday, September 14, 2020 9:50 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Integration of TF-M and FreeRTOS Kernel has been merged into FreeRTOS Hi all, The integration of TF-M and FreeRTOS Kernel has been merged into the official FreeRTOS Kernel repository<https://github.com/FreeRTOS/FreeRTOS-Kernel> master branch. You can follow this port<https://github.com/FreeRTOS/FreeRTOS-Kernel/tree/master/portable/ThirdParty…> on Cortex-M33 platforms. Regards, Sherry Zhang

5 years, 6 months

1
0
0 0

Integration of TF-M and FreeRTOS Kernel has been merged into FreeRTOS

by Sherry Zhang

Hi all, The integration of TF-M and FreeRTOS Kernel has been merged into the official FreeRTOS Kernel repository<https://github.com/FreeRTOS/FreeRTOS-Kernel> master branch. You can follow this port<https://github.com/FreeRTOS/FreeRTOS-Kernel/tree/master/portable/ThirdParty…> on Cortex-M33 platforms. Regards, Sherry Zhang

5 years, 6 months

1
0
0 0

Re: [TF-M] The GNUARM linker script change about psa_client objects and the integration method [NXP]

by Ken Liu

Hi Andrej, Thanks, if the different approach for project compilation has its own ld file then we can remove these 4 lines - going to create a patch for this. BR /Ken From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Friday, September 11, 2020 9:10 PM To: Ken Liu <Ken.Liu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: The GNUARM linker script change about psa_client objects and the integration method [NXP] Hi Ken, Guess, these lines where upstream from NXP SDK, which is using a different approach for project compilation. Most probably they may be removed for the original TFM. Best regards, Andrej From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Friday, September 11, 2020 3:04 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] The GNUARM linker script change about psa_client objects and the integration method [NXP] Hi, When I was trying to re-arrange the linker script I found below changes: *psa_client.*(.text*) /* NXP */ *psa_client.*(.rodata*) *psa_service.*(.text*) /* NXP */ *psa_service.*(.rodata*) *psa_lifecycle.*(.text*) /* NXP */ *psa_lifecycle.*(.rodata*) *tfm_log_raw.*(.text*) /* NXP */ I think at least the psa_client.o and psa_service.o are included into the libtfmsprt.a so these items looks duplicated. What is the purpose of this change? Would it fix build problem or runtime problem? Thanks. /Ken

5 years, 6 months

1
0
0 0

The GNUARM linker script change about psa_client objects and the integration method [NXP]

by Ken Liu

Hi, When I was trying to re-arrange the linker script I found below changes: *psa_client.*(.text*) /* NXP */ *psa_client.*(.rodata*) *psa_service.*(.text*) /* NXP */ *psa_service.*(.rodata*) *psa_lifecycle.*(.text*) /* NXP */ *psa_lifecycle.*(.rodata*) *tfm_log_raw.*(.text*) /* NXP */ I think at least the psa_client.o and psa_service.o are included into the libtfmsprt.a so these items looks duplicated. What is the purpose of this change? Would it fix build problem or runtime problem? Thanks. /Ken

5 years, 6 months

1
0
0 0

Test message - please ignore

by Bill Fletcher

.. -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

5 years, 6 months

1
0
0 0

Test message please ignore

by Bill Fletcher

. -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

5 years, 6 months

1
0
0 0

Skip GNUARM startup initialization

by Summer Qin

Hi, There is no forwarded define for '__START' in the current TF-M design, then the runtime init provided by toolchain is applied. This runtime init did something unnecessary as the data copying and ZI has been done already by the startup code, jumping to spm::main would be the next job as SPM would prepare runtime environment for subsequent partition execution and itself won't need other runtime operations besides the data moving. I have created a patch to jump to main under GNUARM: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5609 Change the code is because this would easy the code reading -- most of the users won't check a compiler flag given in the build system for forwarding '__START', so they will try to find the __start from the toolchain source. Currently, we can not avoid depending on ARMCLANG runtime init, so need double check (also IAR). Please provide your feedback, we are changing the platform startup code and need your confirmation to see if it is applicable. Best Regards, Summer

5 years, 6 months

1
0
0 0

TF-M Technical Forum call - September 17

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, September 17 at 6:00-07:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

5 years, 6 months

1
0
0 0

Re: [TF-M] TF-M build system update heads-up

by Raef Coles

Note that it's also still possible to use the "old style" cmake syntax: ``` mkdir build cd build cmake -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake .. make ``` Ninja is also supported as a generator by using ``` mkdir build cd build cmake -GNinja -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake .. ninja ``` This has been noted in the updated build documentation patch, which will be pushed to review.trustedfirmware.org as soon as possible (with other bugfixes, including both of the bugs encountered earlier in the email chain). Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 09 September 2020 08:58 To: 'tf-m(a)lists.trustedfirmware.org' Cc: nd Subject: Re: [TF-M] TF-M build system update heads-up Great to hear that that. BTW, instead of building all targets using “install” You can build a specific target separately by: cmake --build cmake_build --target <target> To list the targets available. use: cmake --build cmake_build --target help Cheers, Anton From: Christopher Brand <chris.brand(a)cypress.com> Sent: 08 September 2020 22:30 To: Anton Komlev <Anton.Komlev(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: TF-M build system update heads-up Thanks, Anton. That does work. The command I ran was definitely correct – I’ve tried switching back-and-forth between “-B” and “--build”, and they consistently fail and succeed, respectively. I’ve also seen my email client change “--” to “—“. I’m running cmake 3.18.2 on Ubuntu 18.04. Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: Tuesday, September 8, 2020 1:13 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Chris, Could you try this: cmake --build cmake_build -- install Please note, when I copied your command the minus sign “-” was incorrect – probably a dash or hyphen sign. Need double check the doc. Hope it helps, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: 08 September 2020 19:48 To: Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] TF-M build system update heads-up Hi, Sorry to hear that. When you manage to find out the culprit please drop an email to the list. I am really curious. /George From: Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>> Sent: 08 September 2020 19:08 To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: TF-M build system update heads-up Thanks, Gyorgy. I did indeed have the double dash (pretty sure I just copied and pasted from the doc). I guess my email client decided to “fix it in the mail message. Chris From: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>> Sent: Saturday, September 5, 2020 5:42 AM To: Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Chris, You need two dashes before install. Options with a single dash are processed by cmake. Options after a double dash (--) are passed over to the build tool (in this case gnumake). (See the cmake documentation [1].) So: cmake -B cmake_build -- install is the correct command. [cid:image001.png@01D68687.0FBC1660] I attached an image above to work around potential readability issues of some font sets. I hope it gets trough. [1] https://cmake.org/cmake/help/v3.0/manual/cmake.1.html /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M Sent: 05 September 2020 00:26 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] TF-M build system update heads-up Thanks, Anton. I tried again today, and got further – the first cmake command seems to succeed, but the second failed. I used git fetch "https://review.trustedfirmware.org/TF-M/trusted-firmware-m" refs/changes/72/5472/1 && git checkout FETCH_HEAD to get the tree, followed by cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=debug and then cmake -B cmake_build – install This error seems like something trivial: CMake Error: The source directory “…/trusted-firmware-m/install" does not exist. Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: Thursday, September 3, 2020 11:35 AM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Chris, Thanks for trying. Please specify the build type explicitly: -DCMAKE_BUILD_TYPE=debug It shall be defaulted to “MinSizeRel", but something went wrong. Will be fixed asap. Good luck, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M Sent: 03 September 2020 19:10 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] TF-M build system update heads-up I tried to build PSoC64 with the new build system a couple of days ago, and wasn’t successful. Following docs/getting_started/tfm_build_instruction.rst (the “Example: building TF-M for AN521 platform using GCC:” section), I ran cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake That failed : CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:107 (if): if given arguments: "STREQUAL" "DEBUG" "OR" "STREQUAL" "Debug" "OR" "STREQUAL" "debug" Unknown arguments specified Looking at that file it seemed that the default for CMAKE_BUILD_TYPE wasn’t being applied, so I tried this command: cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=MinSizeRel That got further, but failed with: CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:115 (target_include_directories): Cannot specify include directories for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:120 (target_compile_definitions): Cannot specify compile definitions for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:130 (target_sources): Cannot specify sources for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:135 (target_link_libraries): Cannot specify link libraries for target "mbedcrypto_crypto_service" which is not built by this project. At that point, I gave up. Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: Thursday, September 3, 2020 10:04 AM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello, As I mentioned in the Open Tech Forum today – we are close to merge the new build system to the master branch. Plan to start doing that at the beginning of the next week. It might cause code freeze for several days and minor problems in corner cases after that. The intention is to clean it out before the next release in November. All changes to merge are in feature-ux-buildsystem branch at the moment. Please signal if it conflicts with your plans. Regards, Anton 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. 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. 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. This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 6 months

1
0
0 0

Re: [TF-M] PSA tests: NVMEM section

by David Hu

Hi Øyvind, IMOO, such a NVME area is psa-arch-tests dedicated requirement, instead of TF-M implementation or FF-M definitions. I'd suggest to ask for more details in https://github.com/ARM-software/psa-arch-tests/. FYI a patch from psa-arch-test to enable such a NVME area in TF-M: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/3360 Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Rønningstad, Øyvind via TF-M Sent: Wednesday, September 9, 2020 3:48 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] PSA tests: NVMEM section According to psa-arch-tests[1] the tests need an NVMEM area to write its states to. "Non-volatile memory support to preserve test status over watchdog timer reset. Each byte of this region must be initialised to FF at power on reset." I could not find any code that does this in the TF-M or PSA repos. How do other platforms reserve and manage this 1k area. [1]: https://github.com/ARM-software/psa-arch-tests/blob/master/api-tests/docs/p…

5 years, 6 months

2
1
0 0

Re: [TF-M] TF-M build system update heads-up

by Christopher Brand

Thanks, Anton. That does work. The command I ran was definitely correct – I’ve tried switching back-and-forth between “-B” and “--build”, and they consistently fail and succeed, respectively. I’ve also seen my email client change “--” to “—“. I’m running cmake 3.18.2 on Ubuntu 18.04. Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Tuesday, September 8, 2020 1:13 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Chris, Could you try this: cmake --build cmake_build -- install Please note, when I copied your command the minus sign “-” was incorrect – probably a dash or hyphen sign. Need double check the doc. Hope it helps, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: 08 September 2020 19:48 To: Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] TF-M build system update heads-up Hi, Sorry to hear that. When you manage to find out the culprit please drop an email to the list. I am really curious. /George From: Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>> Sent: 08 September 2020 19:08 To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: TF-M build system update heads-up Thanks, Gyorgy. I did indeed have the double dash (pretty sure I just copied and pasted from the doc). I guess my email client decided to “fix it in the mail message. Chris From: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>> Sent: Saturday, September 5, 2020 5:42 AM To: Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Chris, You need two dashes before install. Options with a single dash are processed by cmake. Options after a double dash (--) are passed over to the build tool (in this case gnumake). (See the cmake documentation [1].) So: cmake -B cmake_build -- install is the correct command. [cid:image001.png@01D685EC.35B811C0] I attached an image above to work around potential readability issues of some font sets. I hope it gets trough. [1] https://cmake.org/cmake/help/v3.0/manual/cmake.1.html /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M Sent: 05 September 2020 00:26 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] TF-M build system update heads-up Thanks, Anton. I tried again today, and got further – the first cmake command seems to succeed, but the second failed. I used git fetch "https://review.trustedfirmware.org/TF-M/trusted-firmware-m" refs/changes/72/5472/1 && git checkout FETCH_HEAD to get the tree, followed by cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=debug and then cmake -B cmake_build – install This error seems like something trivial: CMake Error: The source directory “…/trusted-firmware-m/install" does not exist. Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: Thursday, September 3, 2020 11:35 AM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Chris, Thanks for trying. Please specify the build type explicitly: -DCMAKE_BUILD_TYPE=debug It shall be defaulted to “MinSizeRel", but something went wrong. Will be fixed asap. Good luck, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M Sent: 03 September 2020 19:10 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] TF-M build system update heads-up I tried to build PSoC64 with the new build system a couple of days ago, and wasn’t successful. Following docs/getting_started/tfm_build_instruction.rst (the “Example: building TF-M for AN521 platform using GCC:” section), I ran cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake That failed : CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:107 (if): if given arguments: "STREQUAL" "DEBUG" "OR" "STREQUAL" "Debug" "OR" "STREQUAL" "debug" Unknown arguments specified Looking at that file it seemed that the default for CMAKE_BUILD_TYPE wasn’t being applied, so I tried this command: cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=MinSizeRel That got further, but failed with: CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:115 (target_include_directories): Cannot specify include directories for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:120 (target_compile_definitions): Cannot specify compile definitions for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:130 (target_sources): Cannot specify sources for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:135 (target_link_libraries): Cannot specify link libraries for target "mbedcrypto_crypto_service" which is not built by this project. At that point, I gave up. Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: Thursday, September 3, 2020 10:04 AM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello, As I mentioned in the Open Tech Forum today – we are close to merge the new build system to the master branch. Plan to start doing that at the beginning of the next week. It might cause code freeze for several days and minor problems in corner cases after that. The intention is to clean it out before the next release in November. All changes to merge are in feature-ux-buildsystem branch at the moment. Please signal if it conflicts with your plans. Regards, Anton 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. 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. 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. This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 6 months

2
1
0 0

PSA tests: NVMEM section

by Rønningstad, Øyvind

According to psa-arch-tests[1] the tests need an NVMEM area to write its states to. "Non-volatile memory support to preserve test status over watchdog timer reset. Each byte of this region must be initialised to FF at power on reset." I could not find any code that does this in the TF-M or PSA repos. How do other platforms reserve and manage this 1k area. [1]: https://github.com/ARM-software/psa-arch-tests/blob/master/api-tests/docs/p…

5 years, 6 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M