- TF-M - lists.trustedfirmware.org

Re: [TF-M] Is Musca-A deprecated already?

by Minos Galanakis

Hi Thomas, I can also confirm that the build works on a system with the linked environment<https://review.trustedfirmware.org/plugins/gitiles/ci/dockerfiles/+/refs/he…> setup. I have tested your command, as well as the two methods listed in the documentation and all appear to be working. Given this opportunity I would like to share that in accordance to the TrustedFirmware.org project maintenance proposal<https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…>, the project should not be removing a platform in without fair notice. In TF-M we try to do so in three steps between releases: * Adding a deprecation warning patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6516> which will notify the users during compilation and runtime. * Marking is as soon to be deprecated in documentation. * Removing the files on or after the marked release. Back to your problem, I would also confirm that there are no environment variables setting a pre-downloaded repository for TF-M tests. Please let us know how it goes. Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 27 January 2021 08:46 To: Sherry Zhang <Sherry.Zhang2(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] Is Musca-A deprecated already? Hi Sherry, Looks like I have version 1.7.0a1. PS C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\cmake_build_iar> imgtool version 1.7.0a1 Cheers, Thomas Den 2021-01-27 kl. 09:22, skrev Sherry Zhang: Hi Thomas, Can you share the version of the imgtool package you used? The recommended version is >=1.6.0. We run the build command on Linux locally and it works well. An alternative option is to use the imgtool script from the upstream MCUBoot repo. To achieve that you can copy the folder ./build_dir/lib/ext/mcuboot-src/scripts/imgtool to bl2/ext/mcuboot/scripts/wrapper/. Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Wednesday, January 27, 2021 12:28 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Is Musca-A deprecated already? I'm working on some IAR brokenness for the cypress/psoc64 and for comparison I'm attempting to build for my favorite board, the musca_a, but it seems builds fails now. I think it was working last week, but today I'm unable to build with any of the toolchains. I get the following errors frmo all of them. Here's a gcc build: --- [629/629] Generating tfm_s_ns_signed.bin FAILED: bl2/ext/mcuboot/tfm_s_ns_signed.bin cmd.exe /C "cd /D C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\cmake_build_armclang\bl2\ext\mcuboot && C:\Users\thomasto\AppData\Local\Programs\Python\Python39\python.exe C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/bl2/ext/mcuboot/scripts/wrapper/wrapper.py -v 1.2.0 --layout C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/CMakeFiles/signing_layout_s.dir/./signing_layout_s_ns.o -k C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/bl2/ext/mcuboot/root-RSA-3072.pem --public-key-format full --align 1 --pad --pad-header -H 0x400 -s auto -d "(0, 0.0.0+0)" -d "(1, 0.0.0+0)" tfm_s_ns.bin C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/tfm_s_ns_signed.bin && "C:\Program Files\CMake\bin\cmake.exe" -E copy C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/tfm_s_ns_signed.bin C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bin" Traceback (most recent call last): File "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\bl2\ext\mcuboot\scripts\wrapper\wrapper.py", line 126, in <module> wrap() File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 829, in __call__ return self.main(*args, **kwargs) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 782, in main rv = self.invoke(ctx) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 1066, in invoke return ctx.invoke(self.callback, **ctx.params) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 610, in invoke return callback(*args, **kwargs) File "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\bl2\ext\mcuboot\scripts\wrapper\wrapper.py", line 121, in wrap img.create(key, public_key_format, enckey, dependencies, boot_record) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\imgtool\image.py", line 378, in create for tag, value in custom_tlvs.items(): AttributeError: 'NoneType' object has no attribute 'items' ninja: build stopped: subcommand failed. --- cmake line: cmake -GNinja -S .. -B . -DTFM_PLATFORM=musca_a "-DTFM_TOOLCHAIN_FILE=..\toolchain_GNUARM.cmake" -DTEST_NS=ON -DTEST_S=ON -DCMAKE_BUILD_TYPE=Debug -DMCUBOOT_LOG_LEVEL=DEBUG -DTFM_PSA_API=ON I've tested building for several of the other targets, which seems to work, but I don't have any of these here. Ideas? Thanks, Thomas -- Thomas Törnblom, Product Engineer IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems> -- Thomas Törnblom, Product Engineer IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>

4 years, 10 months

1
0
0 0

Is Musca-A deprecated already?

by Thomas Törnblom

I'm working on some IAR brokenness for the cypress/psoc64 and for comparison I'm attempting to build for my favorite board, the musca_a, but it seems builds fails now. I think it was working last week, but today I'm unable to build with any of the toolchains. I get the following errors frmo all of them. Here's a gcc build: --- [629/629] Generating tfm_s_ns_signed.bin FAILED: bl2/ext/mcuboot/tfm_s_ns_signed.bin cmd.exe /C "cd /D C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\cmake_build_armclang\bl2\ext\mcuboot && C:\Users\thomasto\AppData\Local\Programs\Python\Python39\python.exe C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/bl2/ext/mcuboot/scripts/wrapper/wrapper.py -v 1.2.0 --layout C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/CMakeFiles/signing_layout_s.dir/./signing_layout_s_ns.o -k C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/bl2/ext/mcuboot/root-RSA-3072.pem --public-key-format full --align 1 --pad --pad-header -H 0x400 -s auto -d "(0, 0.0.0+0)" -d "(1, 0.0.0+0)" tfm_s_ns.bin C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/tfm_s_ns_signed.bin && "C:\Program Files\CMake\bin\cmake.exe" -E copy C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/tfm_s_ns_signed.bin C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bin" Traceback (most recent call last): File "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\bl2\ext\mcuboot\scripts\wrapper\wrapper.py", line 126, in <module> wrap() File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 829, in __call__ return self.main(*args, **kwargs) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 782, in main rv = self.invoke(ctx) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 1066, in invoke return ctx.invoke(self.callback, **ctx.params) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 610, in invoke return callback(*args, **kwargs) File "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\bl2\ext\mcuboot\scripts\wrapper\wrapper.py", line 121, in wrap img.create(key, public_key_format, enckey, dependencies, boot_record) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\imgtool\image.py", line 378, in create for tag, value in custom_tlvs.items(): AttributeError: 'NoneType' object has no attribute 'items' ninja: build stopped: subcommand failed. --- cmake line: cmake -GNinja -S .. -B . -DTFM_PLATFORM=musca_a "-DTFM_TOOLCHAIN_FILE=..\toolchain_GNUARM.cmake" -DTEST_NS=ON -DTEST_S=ON -DCMAKE_BUILD_TYPE=Debug -DMCUBOOT_LOG_LEVEL=DEBUG -DTFM_PSA_API=ON I've tested building for several of the other targets, which seems to work, but I don't have any of these here. Ideas? Thanks, Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

4 years, 10 months

1
0
0 0

Re: [TF-M] Arm Firmware Framework for M 1.1 Extensions Alpha specification

by Kevin Peng

Hi all, Per the off-line discussion with Andrew, I’d like to start a wider discussion on the interrupt APIs, specifically the Secure Partition API changes for interrupt control in chapter 6.3.3. There are the following APIs: * uint32_t psa_irq_is_enabled (psa_signal_t irq_signal); This API returns 0 if the interrupt is disabled and 1 if the interrupt is enabled. * psa_irq_status_t psa_irq_disable(psa_signal_t irq_signal); This API returns the status of the interrupt prior to this call with an implementation defined value Note the return type of the interrupt status is different. The first one is only to tell whether the interrupt is enabled (1) or not (0) – an equivalent to bool type. The second one could be any value to indicate an interrupt status. And that value is intended to be passed to psa_irq_restore to write to the interrupt control register directly. * void psa_irq_restore(psa_signal_t irq_signal, psa_irq_status_t saved_status); The typical usage: psa_irq_status irq2_state = psa_irq_disable(IRQ2_SIGNAL) ; // manipulate data shared with IRQ2 … psa_irq_restore(IRQ2_SIGNAL, irq2_state); This is a very efficient design as the 'saved status value' can be the exact value that needs to be written to an interrupt control register to restore the previous state. But TF-M seems to be unable to take that advantage. Because the most common interrupt controller is the NVIC provided by the core. The NVIC takes 1/0 to enable or disable the interrupt and one register for 32 interrupts. The underlying NVIC operation provided by CMSIS is NVIC_Enable/DisableIRQ. So the psa_irq_status_t in TF-M would simply 1 or 0 for a specific interrupt signal. Then the psa_irq_restore could be unnecessary if psa_irq_disable returns uint32_t just like psa_irq_is_enabled: uint32_t irq_status = psa_irq_disable(IRQ); ... // critical section if (irq_status) psa_irq_enable(IRQ); Any thoughts on the necessity of the psa_irq_restore API? The draft implementation of the current APIs for easy understanding: https://review.trustedfirmware.org/q/topic:%22psa_interrupt_api%22+(status:… Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrew Thoelke via TF-M Sent: Friday, January 15, 2021 1:25 AM To: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: [TF-M] Arm Firmware Framework for M 1.1 Extensions Alpha specification Hi all, The PSA Firmware Framework for M 1.1 Extensions specification is now published on Arm Developer. This document introduces a set of updates and extensions to the Arm® Platform Security Architecture Firmware Framework (FF-M) specification, designed to build on the capabilities provided in version 1.0. This is an initial ALPHA release in order to enable wider review and feedback on the changes proposed to be included in the v1.1 specification. At this quality level, the changes and interfaces defined are not stable enough for product development. When the proposed extensions are sufficiently stable to be classed as Beta, they will be integrated into the FF-M version 1.1 specification. The 1.1 Extensions document can be downloaded from: https://developer.arm.com/documentation/aes0039/latest Both the 1.0 Specification and the 1.1 Extensions document are linked from the main PSA architecture page: https://developer.arm.com/architectures/security-architectures/platform-sec… Ken and I have presented a number of times at last year's Tech Forums on the proposals in the specification, most recently I provided a summary of the whole document on 10th December 2020. If you have any feedback, please provide it to arm.psa-feedback(a)arm.com<mailto:arm.psa-feedback@arm.com>, or discuss the proposals here in the TF-M mailing list. Regards, Andrew -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 10 months

1
0
0 0

[RFC] Doxygen usage

by Ken Liu

Hi, As mentioned in Tech Forum, call for feedbacks for doxygen usage: - Anyone is checking doxygen documents? - Which API are you checking with doxygen documents? The service APIs, or even some internal static API for SPM? - When you are reading code, will you check the docs or you just open them in editors and then read it? The background is we put many efforts on docs, it costs effort to maintain the doxygen format comments for all sources even the concept is covered in the docs folder, we are trying to find a balance to help mitigate the effort spent on internal logics (such as those static APIs inside SPM fewer people would update). For the interfaces API, doxygen would be always there so user can find them easily. Thanks /Ken

4 years, 10 months

1
0
0 0

Review request on design proposal of adding secure Flash support in TF-M

by Edward Yang

Hi everyone, The design proposal of adding secure Flash support in TF-M has been updated, I would like to ask for a review, any comments and suggestions will be appreciated. Link of the design proposal: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8033 Best Regards, 杨雪松 Edward Yang 旺宏微电子（苏州）有限公司 Macronix Microelectronics(Suzhou) Co., Ltd. 地址：中国苏州工业园区苏虹西路55号 No.55，Su Hong Xi Road，Suzhou Industrail Park，Suzhou 215021 P.R.China TEL: 86-512-62580888 EXT: 3102 FAX: 86-512-62585399 ZIP: 215021 E-mail: edwardyang(a)mxic.com.cn Http: //www.mxic.com.cn ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as it attachments from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

4 years, 10 months

1
0
0 0

Re: [TF-M] Technical Forum call - January 21

by Anton Komlev

Hello, The agenda for the forum: 1. Proposal for changes to the OpenCI job coverage 2. Proposal to reduce Doxygen coverage to the interfaces only 3. Ongoing open issues: * Musca-A platform deprecation * Arm Firmware Framework for M 1.1 Extensions Alpha specification Regards,, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 20 January 2021 14:18 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Technical Forum call - January 21 Hi Anton, I would like to raise a discussion about doxygen usage. I think it is acceptable to apply doxygen usage in interfaces only if we want to keep alignment with CMSIS code since it applied doxygen result as reference manual; but for other logics, the doxygen is almost not used. Wondered how many users would generate reference manual from doxygen; or they just open an editor then start reading code from sources. Thanks. /Ken ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Karl Zhang via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Wednesday, January 20, 2021 7:54 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>; Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Technical Forum call - January 21 Hi Anton, I would like to propose some changes to the openCI job coverage, it may take ~20 mins. BR Karl ________________________________ 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 <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Thursday, January 14, 2021 4:19 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@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] Technical Forum call - January 21 Hello, The next Technical Forum is planned on Thursday, January 21 at 15:00-16:00 UTC (US 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

4 years, 10 months

1
0
0 0

Re: [TF-M] Technical Forum call - January 21

by Ken Liu

Hi Anton, I would like to raise a discussion about doxygen usage. I think it is acceptable to apply doxygen usage in interfaces only if we want to keep alignment with CMSIS code since it applied doxygen result as reference manual; but for other logics, the doxygen is almost not used. Wondered how many users would generate reference manual from doxygen; or they just open an editor then start reading code from sources. Thanks. /Ken ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Karl Zhang via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Wednesday, January 20, 2021 7:54 PM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>; Anton Komlev <Anton.Komlev(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Technical Forum call - January 21 Hi Anton, I would like to propose some changes to the openCI job coverage, it may take ~20 mins. BR Karl ________________________________ 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: Thursday, January 14, 2021 4:19 AM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - January 21 Hello, The next Technical Forum is planned on Thursday, January 21 at 15:00-16:00 UTC (US 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

4 years, 10 months

1
0
0 0

Re: [TF-M] Technical Forum call - January 21

by Karl Zhang

Hi Anton, I would like to propose some changes to the openCI job coverage, it may take ~20 mins. BR Karl ________________________________ 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: Thursday, January 14, 2021 4:19 AM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - January 21 Hello, The next Technical Forum is planned on Thursday, January 21 at 15:00-16:00 UTC (US 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

4 years, 10 months

1
0
0 0

Couple of adjustment patches coming

by Ken Liu

Hi, For implementing coming features and optimization, there would be couples of adjustment patches coming, this is the first one (the number looks good): https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8000 The idea is to get these patches to come in first so that we can have more time before the next release to fix spotted issues. Please help to review the patches and provide different thinking if you have. Thanks. /Ken

4 years, 10 months

1
0
0 0

Re: [TF-M] [RFC] Static linker scripts for level 1 and 2 isolation

by Ken Liu

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(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Thursday, January 14, 2021 9:49 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)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+(sta… 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(a)lists.trustedfirmware.org> On Behalf Of Raef Coles via TF-M Sent: Wednesday, January 13, 2021 11:44 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)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 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 10 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M