- TF-M - lists.trustedfirmware.org

Design proposal: Changing secure service call in library model

by Mate Toth-Pal

Hi All, I'm planning to change the way secure services are called in Library model. The design proposal can be found here: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2201/ Please note that the changes proposed by this document does not affect the PSA dev API, and does not affect IPC model. Please share your opinion in gerrit comments Thanks, Mate

7 years, 1 month

1
0
0 0

TF-M Presentations at SanDiego Linaro Connect

by Shebu Varghese Kuriakose

Hi, Here is a link to TF-M presentations from Linaro Connect held in San Diego last month https://developer.trustedfirmware.org/w/tf_m/tf-m_videos/linaro_connect_san… Archive of all TF-M presentations can be found in https://developer.trustedfirmware.org/w/tf_m/tf-m_videos/ Regards, Shebu

7 years, 1 month

1
0
0 0

Regression test - SST - MAX_ASSET_SIZE

by Vikas Katariya

Hi, This would test the interface for NS and S with the set, get and remove with maximum `SST_MAX_ASSET_SIZE` and different sizes for all platforms (including feature-twincpu targets in the near future). It uses a common 4K buffer in total to assist with read and write of asset data. We need to make sure we are able to perform this operation flawlessly on all the targets. Patch Review Request: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2167 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2168 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.

7 years, 1 month

1
0
0 0

Re: [TF-M] Issues with qspi_ip6514e_set_spi_mode with IAR

by Jamie Fox

Hi Thomas, One way this can happen is if the QSPI driver is being executed in place from QSPI, so the device is never idle because instructions are being fetched from it. On Musca-A, MCUboot is copied to Code SRAM before being executed to avoid this issue. There is some code in the Armclang/GCC scatter/startup files to support this. Is there something similar implemented for the IAR port? Best wishes, Jamie -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 27 September 2019 15:40 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Issues with qspi_ip6514e_set_spi_mode with IAR I'm trying to bring up TF-M on the Musca A with IAR Embedded Workbench and I'm having issues in mcuboot where the boot hangs with the following stack: --- qspi_ip6514e_is_idle qspi_ip6514e_set_spi_mode set_spi_mode mt25ql_config_mode ARM_Flash_Initialize main [_call_main + 0xd] --- Apparently the idle bit (31) in the qspi_cfg register (0x4010a000) never gets set so it loops there. I have no programmers manual for the Cadence qspi ip6514e so I'm at a bit of a loss as to what the issue might be. Obviously something is different between the images built with armclang and gcc, which works properly, and the image I've built with IAR. Ideas anyone? /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> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

7 years, 1 month

2
1
0 0

Issues with qspi_ip6514e_set_spi_mode with IAR

by Thomas Törnblom

I'm trying to bring up TF-M on the Musca A with IAR Embedded Workbench and I'm having issues in mcuboot where the boot hangs with the following stack: --- qspi_ip6514e_is_idle qspi_ip6514e_set_spi_mode set_spi_mode mt25ql_config_mode ARM_Flash_Initialize main [_call_main + 0xd] --- Apparently the idle bit (31) in the qspi_cfg register (0x4010a000) never gets set so it loops there. I have no programmers manual for the Cadence qspi ip6514e so I'm at a bit of a loss as to what the issue might be. Obviously something is different between the images built with armclang and gcc, which works properly, and the image I've built with IAR. Ideas anyone? /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>

7 years, 1 month

1
0
0 0

Re: [TF-M] Design proposal for HW crypto key integration in TF-M secure boot

by Tamas Ban

Hi, In case of no further comment on the proposal I'm planning to merge it by Monday. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1453/ Tamas -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M Sent: 24 September 2019 10:22 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Design proposal for HW crypto key integration in TF-M secure boot Hi, The design proposal about the integration of TF-M secure bootloader (MCUBoot) with HW key(s) are close to finalize: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1453/ If you are interested in the topic and have a comment / suggestion then please share it. Tamas From: Tamas Ban Sent: 03 July 2019 17:50 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Design proposal for HW crypto key integration in TF-M secure boot Hi all, PSA Trusted Boot and Firmware Update specification requires the support of at least one immutable root of trust public key (ROTPK) for firmware verification. It is beneficial to be able to provision these keys during the factory life-cycle of the device independently from any software components. The current key handling solution in TF-M secure boot does not supports this key provisioning process. MCUBoot requires compile time built-in public key(s) for image verification. The following design proposal addressing this issue: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1453/ Feel free to add any comments you want on the review! BR, Tamas -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

7 years, 1 month

1
0
0 0

Re: [TF-M] Please enable -pedantic-errors for gcc builds

by Ken Liu (Arm Technology China)

Hi Thomas, We tried to enable the "-pedantic-errors" flags and finished some fix. Some of them mentioned in your last mail has been pushed, and updated at: https://developer.trustedfirmware.org/T475 The reason we do not enable it as default is that there some sources files from the external project, which causes inconvenience to enable this. Please help to review these patch to see if it is acceptable for the issue for now, after that we could find a chance to merge it. And we can enable this flag internally and create more patches to fix the tf-m native source in future. Thanks. /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Saturday, August 17, 2019 5:48 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Please enable -pedantic-errors for gcc builds Hi Thomas, This is a very helpful suggestion. Since I am doing some cleanup these days, let me try this option and see how much we need to improve. I have created an task for tracking this: https://developer.trustedfirmware.org/T475 And, do you have an error report could be share? You can attch the log in the task if you do have some. Thanks. /Ken ________________________________ 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: Friday, August 16, 2019 4:24 PM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Please enable -pedantic-errors for gcc builds I'm now looking at compilation issues with our standards compliant compiler, and I run into one issue after another that are due to the use of non-standard C allowed by gcc and armclang. Things like zero sized arrays, which are fairly easy to fix by making sure that they have at least one element, but there are other issues that may not be as easy to solve. The latest issue is illegal pointer arithmetic on void * in the IPC code. --- ... [ 20%] Building C object app/secure_fw/CMakeFiles/tfm_s_obj_lib.dir/core/ipc/tfm_svcalls.o msg->invec[invec_idx].base += bytes; ^ "C:\Users\thomasto\Projects\tf-m7\trusted-firmware-m\secure_fw\core\ipc\tfm_svcalls.c",595 Error[Pe852]: expression must be a pointer to a complete object type msg->invec[invec_idx].base += num_bytes; ^ "C:\Users\thomasto\Projects\tf-m7\trusted-firmware-m\secure_fw\core\ipc\tfm_svcalls.c",666 Error[Pe852]: expression must be a pointer to a complete object type tfm_memcpy(msg->outvec[outvec_idx].base + msg->outvec[outvec_idx].len, ^ "C:\Users\thomasto\Projects\tf-m7\trusted-firmware-m\secure_fw\core\ipc\tfm_svcalls.c",750 Error[Pe852]: expression must be a pointer to a complete object type ... --- I suggest enabling "-pedantic-errors" for gcc, and also for clang, if it has a similar setting, to avoid having illegal C code creeping into tf-m. Comments? /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> <http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems> <http://www.twitter.com/iarsystems> -- 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

7 years, 1 month

1
0
0 0

T398/T413

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>

7 years, 1 month

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

7 years, 1 month

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

7 years, 1 month

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M