Hi,
I have merged these patches so they took place now. For lv1 and lv2 users, they don’t need the linker script template any more. The next step is syncing lv3 with lv1/lv2.
This change may miss verification on some platforms, please report the build & run issue if you have, thanks.
BR
/Ken
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Ken Liu via TF-M Sent: Thursday, January 14, 2021 9:49 AM To: tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] [RFC] Static linker scripts for level 1 and 2 isolation
I think the link needs to be updated into:
https://review.trustedfirmware.org/q/topic:%22static_linker_scripts%22+(stat...)
This would make the components arrangement more simpler than using a templating. But for level 3 we still have to using a templating as now there is no 'foreach' like functionalities supported in the ld/sct/icf.
/Ken
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Raef Coles via TF-M Sent: Wednesday, January 13, 2021 11:44 PM To: tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: [TF-M] [RFC] Static linker scripts for level 1 and 2 isolation
Hi everyone
I'd like to request comments on an upcoming change to the linker scripts.
Because of some recent changes to the memory layout for level 1 and level 2 isolation, it's now possible to avoid the generation step via tfm_parse_manifest_lists.py for those linker files. This means that the files are static and have been committed into the source tree (as they used to be).
We anticipate this change will make integrating TF-M into non-cmake buildsystems easier, as it will avoid one of the places where files need to be generated at build-time.
The reason this is an RFC is that it is a potentially breaking change, but only for integrators _not_ using the cmake buildsystem.
Currently the linker uses a large variety of pattern matches to organise the partition symbols, with these patterns being defined in the tfm_manifest_list.yaml. After this change, the linker will only look for two patterns:
`*app_rot_partition*` and `*psa_rot_partition*`
With the intention that the secure partitions will be compiled into a static library, where the filename is (for example) `libtfm_psa_rot_partition_crypto.a`. The cmake buildsystem will be updated to generate these filenames, but other integrators will need to adjust their compilation steps else the linking will fail.
Any comments or concerns would be appreciated.
Patches can be found at: https://review.trustedfirmware.org/q/topic:%23static_linker_scripts%22
Raef