- TF-M - lists.trustedfirmware.org

by Thomas Törnblom

This is a notification of a patch I pushed yesterday. It consists of standard C source cleanup and initial toolchain support for IAR Embedded Workbench. The target is Musca A and I will provide further support for the psoc6 once the twincpu branch has been merged to master. The Musca A port is not yet fully functional but debugging is in progress. 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>

5 years, 8 months

1
0
0 0

Re: [TF-M] platform-specific hw initialization

by Ken Liu (Arm Technology China)

Hi Andrei, I have taken a look at give some tiny comment -- the idea is good for now since some extra platform initialization is needed. Thanks /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: Friday, September 27, 2019 1:00 AM To: Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] platform-specific hw initialization Hi Andrei, This would solve a problem that we currently have with UART with Zephyr, and seems like a useful addition. Thanks for putting the change request together. Kevin On Thu, 26 Sep 2019 at 09:48, Andrei Narkevitch via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi All, > > We're proposing to add an API that would allow to implement a custom post-startup initialization of hw, peripherals etc. > Contrarily to SystemInit() intended for a high priority hw initialization (for example clock and power subsystems), and called on a very early boot stage from startup code, these functions are called from C code, hence variables and other drivers data are protected from being cleared up by the C library init. > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1973 > > Ken and Mate, as maintainers of the TF-M core part, could you please take a look at the patch? > > Thanks, > Andrey Narkevitch > Cypress Semiconductor > > This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. > -- > 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

5 years, 8 months

1
0
0 0

Re: [TF-M] platform-specific hw initialization

by Kevin Townsend

Hi Andrei, This would solve a problem that we currently have with UART with Zephyr, and seems like a useful addition. Thanks for putting the change request together. Kevin On Thu, 26 Sep 2019 at 09:48, Andrei Narkevitch via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi All, > > We're proposing to add an API that would allow to implement a custom post-startup initialization of hw, peripherals etc. > Contrarily to SystemInit() intended for a high priority hw initialization (for example clock and power subsystems), and called on a very early boot stage from startup code, these functions are called from C code, hence variables and other drivers data are protected from being cleared up by the C library init. > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1973 > > Ken and Mate, as maintainers of the TF-M core part, could you please take a look at the patch? > > Thanks, > Andrey Narkevitch > Cypress Semiconductor > > This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 8 months

1
0
0 0

platform-specific hw initialization

by Andrei Narkevitch

Hi All, We're proposing to add an API that would allow to implement a custom post-startup initialization of hw, peripherals etc. Contrarily to SystemInit() intended for a high priority hw initialization (for example clock and power subsystems), and called on a very early boot stage from startup code, these functions are called from C code, hence variables and other drivers data are protected from being cleared up by the C library init. https://review.trustedfirmware.org/c/trusted-firmware-m/+/1973 Ken and Mate, as maintainers of the TF-M core part, could you please take a look at the patch? Thanks, Andrey Narkevitch Cypress Semiconductor This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 8 months

1
0
0 0

Re: [TF-M] TF-M / CMSIS-Zone Alignment

by Robert Rostohar

Hi Mate, Thanks for the detailed explanation and confirmation that the SAU region number reference can be removed. This will enable using CMSIS-Zone to configure also TF-M in an easy way. I would appreciate if some can create a ticket to track progress. Thanks, Robert -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mate Toth-Pal via TF-M Sent: Thursday 26 September 2019 09:40 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M / CMSIS-Zone Alignment Hi Robert, The region IDs in 'tfm_ns_region_e' are used for two purposes in TF-M (just as you mention in your mail): 1. For configuring the SAU. As far as I understood, with the CMSIS-Zone Utility it is possible to generate a 'tz_sau_nvic.c' file, which then can be added to the platform folder of a target in TF-M. The tfm_spm_hal_init_isolation_hw(...) hal function then can call the TZ_Config_SAU(...) function defined in 'tz_sau_nvic.c'. The TZ_Config_SAU(...) uses integer literals to address the different regions of the SAU, but that is OK for this purpose. 2. The tfm_core_memory_permission_check_handler(...) function The idea was that secure services would be able to query whether the caller NS client has access to a certain NS memory region. Implementing this feature would require TF-M core to know whether a region returned by cmse_check_address_range is a Non-Secure memory or not. With the current output of the CMSIS-Zone Utility I don't see this is possible other than looking into the config of the SAU region and check the content of the RLAR register. (Although this would only reveal whether the region is S/NS, code/data differentiation should be done in a different way) However this feature never got implemented, and this is only supported in Library model. Also after removing isolation level 3 from Library model I think there is no point in keeping this function. So the reference to the SAU regions from this function can be removed. So summarizing the above, I think there is no reason why CMSIS-Zone Utility could not be used in TF-M, and it seems that it could be integrated fairly easily. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Robert Rostohar via TF-M Sent: 26 September 2019 09:27 To: Summer Qin (Arm Technology China) <Summer.Qin(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] TF-M / CMSIS-Zone Alignment Hi Summer, Thanks for looking into this. Requesting a specific SAU region number for a specific memory region is an inconvenience for CMSIS-Zone. It introduces additional complexity for the user who would need to know and configure this and also for the tool to handle. Normally the user just configures the memory region (address, size, access. security, privilege, ...) and leaves to the tool to assign a region and generate the SAU setup code. Having the additional constrain (ex: NS_CODE needs to be assigned to RGN=0) is just another obstacle and source of error in user configuration of the memory layout for TF-M. I would help if TF-M would remove the constrain on specific region number assignments. Thanks, Robert -----Original Message----- From: Summer Qin (Arm Technology China) <Summer.Qin(a)arm.com> Sent: Thursday 26 September 2019 08:14 To: Robert Rostohar <Robert.Rostohar(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] TF-M / CMSIS-Zone Alignment Hi Robert, I think the static defined region number would be much for easier for implementation: First, we need to assign a Region Number together with RBAR and RLAR. Then, we could use the Region Number to stand for the region that is configured by the RBAR and RLAR. It is just like an ID for a block of the memory. Dose it causes some inconvenience for CMSIS-Zone? Regards, Summer On 9/13/19, 6:56 PM, "TF-M on behalf of Robert Rostohar via TF-M" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m(a)lists.trustedfirmware.org> wrote: Hi, We are working on CMSIS-Zone Utility [1] which is a GUI tool for configuring a complex system. This includes also TrustZone setup (SAU) and device specific MPC and PPC. This tool can be also used to configure SAU, MPC and PPC in TF-M. However TF-M currently requires that a specific region number is used for NS_REGION_CODE (0), NS_REGION_DATA (1), ... Those region numbers are used when SAU is configured in function sau_and_idau_cfg and the code in function tfm_core_memory_permission_check_handler depends on it. Is it really necessary that a specific region number is being used and why? I have received indication that this in not really needed and that the code should be redesigned. This would enable the use of CMSIS-Zone to configure TF-M out of the box. Thanks, Robert [1] https://github.com/ARM-software/CMSIS-Zone IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- 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 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 8 months

1
0
0 0

Re: [TF-M] TF-M / CMSIS-Zone Alignment

by Mate Toth-Pal

Hi Robert, The region IDs in 'tfm_ns_region_e' are used for two purposes in TF-M (just as you mention in your mail): 1. For configuring the SAU. As far as I understood, with the CMSIS-Zone Utility it is possible to generate a 'tz_sau_nvic.c' file, which then can be added to the platform folder of a target in TF-M. The tfm_spm_hal_init_isolation_hw(...) hal function then can call the TZ_Config_SAU(...) function defined in 'tz_sau_nvic.c'. The TZ_Config_SAU(...) uses integer literals to address the different regions of the SAU, but that is OK for this purpose. 2. The tfm_core_memory_permission_check_handler(...) function The idea was that secure services would be able to query whether the caller NS client has access to a certain NS memory region. Implementing this feature would require TF-M core to know whether a region returned by cmse_check_address_range is a Non-Secure memory or not. With the current output of the CMSIS-Zone Utility I don't see this is possible other than looking into the config of the SAU region and check the content of the RLAR register. (Although this would only reveal whether the region is S/NS, code/data differentiation should be done in a different way) However this feature never got implemented, and this is only supported in Library model. Also after removing isolation level 3 from Library model I think there is no point in keeping this function. So the reference to the SAU regions from this function can be removed. So summarizing the above, I think there is no reason why CMSIS-Zone Utility could not be used in TF-M, and it seems that it could be integrated fairly easily. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Robert Rostohar via TF-M Sent: 26 September 2019 09:27 To: Summer Qin (Arm Technology China) <Summer.Qin(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] TF-M / CMSIS-Zone Alignment Hi Summer, Thanks for looking into this. Requesting a specific SAU region number for a specific memory region is an inconvenience for CMSIS-Zone. It introduces additional complexity for the user who would need to know and configure this and also for the tool to handle. Normally the user just configures the memory region (address, size, access. security, privilege, ...) and leaves to the tool to assign a region and generate the SAU setup code. Having the additional constrain (ex: NS_CODE needs to be assigned to RGN=0) is just another obstacle and source of error in user configuration of the memory layout for TF-M. I would help if TF-M would remove the constrain on specific region number assignments. Thanks, Robert -----Original Message----- From: Summer Qin (Arm Technology China) <Summer.Qin(a)arm.com> Sent: Thursday 26 September 2019 08:14 To: Robert Rostohar <Robert.Rostohar(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] TF-M / CMSIS-Zone Alignment Hi Robert, I think the static defined region number would be much for easier for implementation: First, we need to assign a Region Number together with RBAR and RLAR. Then, we could use the Region Number to stand for the region that is configured by the RBAR and RLAR. It is just like an ID for a block of the memory. Dose it causes some inconvenience for CMSIS-Zone? Regards, Summer On 9/13/19, 6:56 PM, "TF-M on behalf of Robert Rostohar via TF-M" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m(a)lists.trustedfirmware.org> wrote: Hi, We are working on CMSIS-Zone Utility [1] which is a GUI tool for configuring a complex system. This includes also TrustZone setup (SAU) and device specific MPC and PPC. This tool can be also used to configure SAU, MPC and PPC in TF-M. However TF-M currently requires that a specific region number is used for NS_REGION_CODE (0), NS_REGION_DATA (1), ... Those region numbers are used when SAU is configured in function sau_and_idau_cfg and the code in function tfm_core_memory_permission_check_handler depends on it. Is it really necessary that a specific region number is being used and why? I have received indication that this in not really needed and that the code should be redesigned. This would enable the use of CMSIS-Zone to configure TF-M out of the box. Thanks, Robert [1] https://github.com/ARM-software/CMSIS-Zone IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 8 months

1
0
0 0

Re: [TF-M] TF-M / CMSIS-Zone Alignment

by Summer Qin (Arm Technology China)

Hi Robert, I think the static defined region number would be much for easier for implementation: First, we need to assign a Region Number together with RBAR and RLAR. Then, we could use the Region Number to stand for the region that is configured by the RBAR and RLAR. It is just like an ID for a block of the memory. Dose it causes some inconvenience for CMSIS-Zone? Regards, Summer On 9/13/19, 6:56 PM, "TF-M on behalf of Robert Rostohar via TF-M" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m(a)lists.trustedfirmware.org> wrote: Hi, We are working on CMSIS-Zone Utility [1] which is a GUI tool for configuring a complex system. This includes also TrustZone setup (SAU) and device specific MPC and PPC. This tool can be also used to configure SAU, MPC and PPC in TF-M. However TF-M currently requires that a specific region number is used for NS_REGION_CODE (0), NS_REGION_DATA (1), ... Those region numbers are used when SAU is configured in function sau_and_idau_cfg and the code in function tfm_core_memory_permission_check_handler depends on it. Is it really necessary that a specific region number is being used and why? I have received indication that this in not really needed and that the code should be redesigned. This would enable the use of CMSIS-Zone to configure TF-M out of the box. Thanks, Robert [1] https://github.com/ARM-software/CMSIS-Zone IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 8 months

2
1
0 0

Please continue reviewing the merging patches from feature-twincpu branch

by David Hu (Arm Technology China)

Hi all, Sorry for frequent review requests of merging feature-twincpu back. To avoid making it more annoying, I combine three topics here. Please check the details below. 1. NS part changes NSPE mailbox, NS PSA client call interface in multi-core topology, mailbox initialization in NS App main(). https://review.trustedfirmware.org/q/topic:%22twincpu-merge-ns%22+(status:o… 2. Multi-core memory access check Multi-core specific memory access check since multi-core platform cannot rely on the memory check provided by CMSE. A dedicated design document is uploaded, which has been reviewed and accepted on feature-twincpu branch https://review.trustedfirmware.org/q/topic:%22twincpu-merge-mem-check%22+(s… 3. Changes to linker script Several changes to linker script to enable multi-core build: Adjust secure data sections layout to save MPU region and memory resource on Armv6-M/Armv7-M Add a RAM code section to support running code from RAM. https://review.trustedfirmware.org/q/topic:%22twincpu-merge-link-script%22+… This should be the last review request/last merge step before pushing specific multi-core platform support, I promise, at least in Sept. 😊 Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Tuesday, September 24, 2019 2:07 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Please review the changes to TF-M core/SPM and mailbox from feature-twincpu branch Hi all, Here is the forth step of merging feature-twincpu back to master branch. It includes the changes to TF-M core/SPM and SPE mailbox implementation. Please help review the patches via https://review.trustedfirmware.org/q/topic:%22twincpu-merge-core-mailbox%22… I planned to split those features into multiple topics but failed due to the dependencies between them. They are the key part of multi-core communication, plus the NS mailbox part. I'd like to introduce the components a little bit below. 1. Common PSA client call handlers Multi-core topology invokes PSA client call via mailbox, rather than by calling veneers. https://review.trustedfirmware.org/c/trusted-firmware-m/+/2019/ extracts out common PSA client call handlers from existing svcalls. Single-Armv8-M and multi-core topology can implement their own PSA client call functions respectively and invoke the common PSA client call handlers. 2. Remote Procedure Call (RPC) RPC layer sits between TF-M SPM and underlying SPE mailbox implementation. It decouples the actual mailbox implementations to TF-M SPM and defines several callbacks for underlying mailbox. 3. SPE mailbox As the name implies, it implements the mailbox functionalities and RPC callbacks in SPE. It also defines mailbox HAL APIs for platforms. The NSPE part mailbox will be uploaded later. 4. Generic multi-core functionalities This part adds several TF-M core functions, with multi-core specific implementations, such as tfm_nspm_thread_entry () and tfm_psa_ipc_request_handler(). Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Friday, September 20, 2019 5:57 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Please review topology changes for supporting diverse topology use cases Hi all, Would you please help review the following patches to support multi-core topology in TF-M? https://review.trustedfirmware.org/q/topic:%22twincpu-merge-topology%22+(st… Those patches prepare for multi-core support being merged from feature-twincpu branch to master branch. It is the third step of the merging back progress. The previous steps are multi-core build enhancement and Armv6-M/Armv7-M arch support below. If it sounds interesting to you, I'm glad to share more details about multi-core development and plan of merging it back to master. Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Thursday, September 19, 2019 4:37 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Please review Armv6-M/Armv7-M support patches Hi all, Could you please take a look at the following patch set to add Armv6-M/Armv7-M support? https://review.trustedfirmware.org/q/topic:%22twincpu-merge-arch%22+(status… That patch set merges Armv6-M/Armv7-M support from feature-twincpu branch back to master branch. It is one step of the progress to merge feature-twincpu branch back to master branch. Any suggestion is welcome. Thanks a lot. Best regards, Hu Ziji -- 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 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 8 months

1
0
0 0

Re: [TF-M] TF-M Internal Trusted Storage service design proposal

by Jamie Fox

Hi all, The ITS design document has been on review for quite a while now, so I plan to merge it this week. If anyone still wants to make any comments, please do so soon here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1604 The ITS implementation is also open for review in this series of patches: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1730 Kind regards, Jamie -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Jamie Fox via TF-M Sent: 22 July 2019 12:00 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Internal Trusted Storage service design proposal Hi all, As you may be aware, implementing the PSA Internal Trusted Storage (ITS) APIs is on the TF-M roadmap for this quarter (https://developer.trustedfirmware.org/w/tf_m/planning/). We plan to implement these APIs with a new TF-M Internal Trusted Storage service. The design proposal for the new TF-M ITS service is now available for design review here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1604 . The design is currently in "draft" state, which means further refinements are to be expected, and feedback is welcome. For more information about the PSA ITS APIs themselves, the PSA Storage API document may be downloaded from here: https://pages.arm.com/PSA-APIs Kind regards, Jamie -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 8 months

1
0
0 0

PSoC6 Erase Block Design issue

by Vikas Katariya

Hi, In PSoC6 target, SST block size is configured as 8 flash sectors<https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta…> (4KB) and we observe the following issues due to that. These are related to the current implementation at the driver and SST layer. 1. Erasing a block. When sst_flash_erase_block() is invoked<https://git.trustedfirmware.org/trusted-firmware-m.git/tree/secure_fw/servi…> from Flash File System for PSoC6 target, seeing that it would never be able to erase more than 512 bytes on PSoC6 when SST emulated block is 4KB which is causing flaw in the initialization sequence<https://git.trustedfirmware.org/trusted-firmware-m.git/tree/secure_fw/servi…> or any meta block erase operation<https://git.trustedfirmware.org/trusted-firmware-m.git/tree/secure_fw/servi…>. The ideal solution needs to be addressed on SST Layer, as having a possible workaround in the driver layer would not be ideal. 1. Program Data For the write operation, we do have an implementation in driver layer for PSoC target<https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta…> which takes care of erasing emulated block size of 4KB before write<https://git.trustedfirmware.org/trusted-firmware-m.git/tree/secure_fw/servi…> operation which doesn't seem to be adequate way, as the erase needs to happen at the SST than driver layer of the target. Please post your comments on Task : https://developer.trustedfirmware.org/T497 Patch review request: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2109 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2110 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2111 These patches address the Erase block issue and removes the workaround for PSoC6 target. Further enhances support for future targets with less than 4KB flash sector erase. Thanks & Best Regards, Vikas Katariya IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M