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@lists.trustedfirmware.org On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:05 AM To: tf-m@lists.trustedfirmware.org Cc: nd 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@lists.trustedfirmware.orgmailto: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@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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.htmlhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Fv3.18%2Fcommand%2Fconfigure_file.html&data=02%7C01%7Candrey.butok%40nxp.com%7Cf2205ffb7731444d87a208d85f869cdf%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637364379048049853&sdata=65at34XRtGlvp4TVaDI%2BDw4BEhJaBru1gX4yOYpr2tw%3D&reserved=0 [2] https://jinja.palletsprojects.com/en/2.11.x/https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjinja.palletsprojects.com%2Fen%2F2.11.x%2F&data=02%7C01%7Candrey.butok%40nxp.com%7Cf2205ffb7731444d87a208d85f869cdf%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637364379048059847&sdata=3Oe%2FAmYSZB2lyNyHiHXz%2FwVBi2GyQR0bKQfCzHH4YC8%3D&reserved=0 [3] https://github.com/kblomqvist/yashahttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkblomqvist%2Fyasha&data=02%7C01%7Candrey.butok%40nxp.com%7Cf2205ffb7731444d87a208d85f869cdf%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637364379048059847&sdata=UutryviJo9IzxLWlHy0ex%2B1vvDtwdoyMCMl1eiKGSlY%3D&reserved=0
From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 22 September 2020 10:15 To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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@lists.trustedfirmware.orgmailto: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@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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,
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: Andrej Butok andrey.butok@nxp.com Sent: Wednesday, September 23, 2020 2:32 PM To: Ken Liu Ken.Liu@arm.com Cc: 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@lists.trustedfirmware.orgmailto: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@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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@lists.trustedfirmware.orgmailto: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@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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.htmlhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Fv3.18%2Fcommand%2Fconfigure_file.html&data=02%7C01%7Candrey.butok%40nxp.com%7Cf2205ffb7731444d87a208d85f869cdf%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637364379048049853&sdata=65at34XRtGlvp4TVaDI%2BDw4BEhJaBru1gX4yOYpr2tw%3D&reserved=0 [2] https://jinja.palletsprojects.com/en/2.11.x/https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjinja.palletsprojects.com%2Fen%2F2.11.x%2F&data=02%7C01%7Candrey.butok%40nxp.com%7Cf2205ffb7731444d87a208d85f869cdf%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637364379048059847&sdata=3Oe%2FAmYSZB2lyNyHiHXz%2FwVBi2GyQR0bKQfCzHH4YC8%3D&reserved=0 [3] https://github.com/kblomqvist/yashahttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkblomqvist%2Fyasha&data=02%7C01%7Candrey.butok%40nxp.com%7Cf2205ffb7731444d87a208d85f869cdf%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637364379048059847&sdata=UutryviJo9IzxLWlHy0ex%2B1vvDtwdoyMCMl1eiKGSlY%3D&reserved=0
From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 22 September 2020 10:15 To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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@lists.trustedfirmware.orgmailto: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@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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
tf-m@lists.trustedfirmware.org
-
Andrej Butok -
Ken Liu