Hello Gyrogy:
Your comment raises the question. Why is TF-M so complex and does it need to be the only answer? Either it needs to be simplified or respect must be paid to support in commercial tools as a first class citizen. Commercial tools are the path for large scale product developers. If they can’t engage TF-M with commercial tools or SiP tools then developers will face challenges to develop with it. It there are challenges they may even avoid using it in favor of simplified solutions much as they do today.
Multiple target use cases will be using various components of TF-M (MbedTLS with and without hardware interfaces, Attestation, Audit Logs, etc.):
1. Arm v8M – Cortex-M33, M35, M55
2. Dual Core Systems – Multiple possible configs
3. Cortex v6M of v7M – M0, M0+, M3 & M4
4. TF-A
5. Other Cortex-R & Cortex-A implementations
This reality argues for a more modular build packaging system that allows for it.
All the best!
Reed
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Gyorgy Szing via TF-M <tf-m(a)lists.trustedfirmware.org>
Reply-To: Gyorgy Szing <Gyorgy.Szing(a)arm.com>
Date: Wednesday, September 23, 2020 at 5:04 AM
To: "tf-m(a)lists.trustedfirmware.org" <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 Andrej,
TF-M relies heavily on compile time configuration, and C is quiet limited on that. This means we cannot rely on the only standardized part of the “ecosystem” solely, and we have to use non-standard tools. I would love to have a portable automation solution supported by most IDEs.
Yes, a lot of projects can go well with a single configuration header but unfortunately TF-M is more complex than that:
* How could we get information from manifest files to the build?
* How could we generate signed binary packages for the boot-loader?
* How could we control memory map in sync with the hw configuration in source files? (The current pre-processing linker files approach is already non-standard.)
None of these can be solved with IDEs in a portable way. I understand that adding IDE support for TF-M is challenging but the root cause is not how we implemented the build system, but how IDEs can handle the complexity needed by TF-M.
/George
From: Andrej Butok <andrey.butok(a)nxp.com>
Sent: 23 September 2020 09:33
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
Thanks Gyorgy for your inputs.
I haven't checked out the details of all the pre-build processing, but it does seem complex to solve this in a portable way, but one suggestion from me is that perhaps the output from the pre-build processing should be a standard C header and from then on the standardized C pre-processing can be used for the rest of the configuration.
For example, instead of the pre-build step generating producing the final linker script , it could instead generate a C header file which then can be consumed by the linker script. Here only the C header is generated and the linker script is untouched.
This means that, if the IDEs can find a path to generate this C header file somehow (either via IDE configuration or different custom pre-build processing), then rest of the setup continues in a C standard way.
Best regards
Soby Mathew
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M
Sent: 23 September 2020 11:04
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 Andrej,
TF-M relies heavily on compile time configuration, and C is quiet limited on that. This means we cannot rely on the only standardized part of the "ecosystem" solely, and we have to use non-standard tools. I would love to have a portable automation solution supported by most IDEs.
Yes, a lot of projects can go well with a single configuration header but unfortunately TF-M is more complex than that:
* How could we get information from manifest files to the build?
* How could we generate signed binary packages for the boot-loader?
* How could we control memory map in sync with the hw configuration in source files? (The current pre-processing linker files approach is already non-standard.)
None of these can be solved with IDEs in a portable way. I understand that adding IDE support for TF-M is challenging but the root cause is not how we implemented the build system, but how IDEs can handle the complexity needed by TF-M.
/George
From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>>
Sent: 23 September 2020 09:33
To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>; Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>>
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,
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
Hi Andrej,
TF-M relies heavily on compile time configuration, and C is quiet limited on that. This means we cannot rely on the only standardized part of the "ecosystem" solely, and we have to use non-standard tools. I would love to have a portable automation solution supported by most IDEs.
Yes, a lot of projects can go well with a single configuration header but unfortunately TF-M is more complex than that:
* How could we get information from manifest files to the build?
* How could we generate signed binary packages for the boot-loader?
* How could we control memory map in sync with the hw configuration in source files? (The current pre-processing linker files approach is already non-standard.)
None of these can be solved with IDEs in a portable way. I understand that adding IDE support for TF-M is challenging but the root cause is not how we implemented the build system, but how IDEs can handle the complexity needed by TF-M.
/George
From: Andrej Butok <andrey.butok(a)nxp.com>
Sent: 23 September 2020 09:33
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
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
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
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
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
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
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
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
