- TF-M - lists.trustedfirmware.org

by Ken Liu (Arm Technology China)

Hi, A patch is pushed for couple of days reveals the update on PSA API prototype and its related caller change: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1572 The most obvious part is a new parameter member 'type' is introduced in 'psa_call'. This is the first step of our upgrading to the latest PSA Firmware Framework Specification. The API internal behavior would come step by step later and now we can call PSA FF API in 1.0.0 prototypes. The callers included in TF-M has been updated in this patch. Developers who developed extra services should mention this change and update PSA API related sources. Any feedback please comment under the patch, or reply to this mail thread. Thanks. -Ken

6 years, 5 months

1
0
0 0

TF-M Internal Trusted Storage service design proposal

by Jamie Fox

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

6 years, 5 months

1
0
0 0

Please review multi-core TF-M topology improvement patches

by David Hu (Arm Technology China)

Sorry. Switch into plain text and correct the bad format. Something was wrong with the Outlook. Hi all, Could you please take a look at the following patches to improve topology implementation on `feature-twincpu` branch? https://review.trustedfirmware.org/c/trusted-firmware-m/+/1542 ~ https://review.trustedfirmware.org/c/trusted-firmware-m/+/1549 and https://review.trustedfirmware.org/c/trusted-firmware-m/+/1603/ As you know, we are bringing up TF-M on multi-core topology platform. Currently, preprocessor directives TFM_MULTI_CORE_TOPOLOGY are used to comment/uncomment the functionalities here and there to fit different scenarios. It can work but makes code difficult to be understood or maintained, in both single Armv8-M and multi-core topologies. The above patches try to eliminate multi-core directives from common sequence and functions shared by single Armv8-M and multi-core topologies. It is expected to not only improve the code readability, but also protect one topology from being affected by changes to another. Although those changes are for twincpu feature branch, I'd like to ask for review and comment since they also impact the single Armv8-M scenario. Merging feature-twincpu branch back to master would be more smooth if we can figure out and fix issues now on `feature-twincpu`. I'd like to summarize the common basic ideas of the topology implementation. 1. If single Armv8-M and multi-core topology both call the same API but require different implementations a. If that API can be classified to a specific functionality/module, separate the implementations into topology exclusive files. Take https://review.trustedfirmware.org/c/trusted-firmware-m/+/1542 as an example. Add multi-core specific NS Client ID implementations in tfm_multi_core.c. Thus multi-core topology doesn't rely on the single Armv8-M implementations in tfm_nspm.c. Then all the multi-core directives can be removed from tfm_nspm.c and tfm_nspm.c can be clearly excluded from multi-core topology build. b. If that API don't belong to a specific functionality/module, extract it out and organize the implementations in topology abstraction file. For example, in https://review.trustedfirmware.org/c/trusted-firmware-m/+/1545, tfm_core_topology_set_pendsv_priority() is defined to wrap the PendSV settings in diverse topologies. The implementations are selected according to current topology in tfm_core_topology.h. It help maintain a more clear and uniform sequence by removing multi-core directives from tfm_core.c. 2. In common sequence, if an API is called in single Armv8-M but not used in multi-core topology, add an empty function for this API in multi-core topology in the header file and vice versa. For example, secure core in multi-core topology doesn't need to configure_ns_code(). As show in https://review.trustedfirmware.org/c/trusted-firmware-m/+/1543, instead of placing several multi-core directives in tfm_core.c, move configure_ns_code() implementation to tfm_nspm.c and define an empty function in header file tfm_nspm.h in multi-core topology for configure_ns_code(). Any comment or suggestion is welcome. Please kindly let me know if the above changes may cause troubles in single Armv8-M scenario. Thank you. Best regards, Hu Ziji

6 years, 5 months

1
0
0 0

Please review multi-core TF-M topology improvement patches

by David Hu (Arm Technology China)

Hi all, Could you please take a look at the following patches to improve topology implementation on `feature-twincpu` branch? https://review.trustedfirmware.org/c/trusted-firmware-m/+/1542 ~ https://review.trustedfirmware.org/c/trusted-firmware-m/+/1549 and https://review.trustedfirmware.org/c/trusted-firmware-m/+/1603/ As you know, we are bringing up TF-M on multi-core topology platform. Currently, preprocessor directives TFM_MULTI_CORE_TOPOLOGY are used to comment/uncomment the functionalities here and there to fit different scenarios. It can work but makes code difficult to be understood or maintained, in both single Armv8-M and multi-core topologies. The above patches try to eliminate multi-core directives from common sequence and functions shared by single Armv8-M and multi-core topologies. It is expected to not only improve the code readability, but also protect one topology from being affected by changes to another. Although those changes are for twincpu feature branch, I'd like to ask for review and comment since they also impact the single Armv8-M scenario. Merging feature-twincpu branch back to master would be more smooth if we can figure out and fix issues now on `feature-twincpu`. I'd like to summarize the common basic ideas of the topology implementation. 1. If single Armv8-M and multi-core topology both call the same API but require different implementations * If that API can be classified to a specific functionality/module, separate the implementations into topology exclusive files. Take https://review.trustedfirmware.org/c/trusted-firmware-m/+/1542 as an example. Add multi-core specific NS Client ID implementations in tfm_multi_core.c. Thus multi-core topology doesn't rely on the single Armv8-M implementations in tfm_nspm.c. Then all the multi-core directives can be removed from tfm_nspm.c and tfm_nspm.c can be clearly excluded from multi-core topology build. * If that API don't belong to a specific functionality/module, extract it out and organize the implementations in topology abstraction file. For example, in https://review.trustedfirmware.org/c/trusted-firmware-m/+/1545, tfm_core_topology_set_pendsv_priority() is defined to wrap the PendSV settings in diverse topologies. The implementations are selected according to current topology in tfm_core_topology.h. It help maintain a more clear and uniform sequence by removing multi-core directives from tfm_core.c. 1. In common sequence, if an API is called in single Armv8-M but not used in multi-core topology, add an empty function for this API in multi-core topology in the header file and vice versa. For example, secure core in multi-core topology doesn't need to configure_ns_code(). As show in https://review.trustedfirmware.org/c/trusted-firmware-m/+/1543, instead of placing several multi-core directives in tfm_core.c, move configure_ns_code() implementation to tfm_nspm.c and define an empty function in header file tfm_nspm.h in multi-core topology for configure_ns_code(). Any comment or suggestion is welcome. Please kindly let me know if the above changes may cause troubles in single Armv8-M scenario. Thank you. Best regards, Hu Ziji

6 years, 5 months

1
0
0 0

Re: [TF-M] Hotfix for auto-merge caused build error

by Ken Liu (Arm Technology China)

Hi, The hotfix has been merged. /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: Monday, July 22, 2019 4:37 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [TF-M] Hotfix for auto-merge caused build error > > Hi, > The gerrit merge with auto rebase on this patch caused the function type change > and a build error is generated: > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1560 > > A hotfix is on the way for fixing this: > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1602 > > Sorry for the troublesome. > > /Ken > > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 5 months

1
0
0 0

Hotfix for auto-merge caused build error

by Ken Liu (Arm Technology China)

Hi, The gerrit merge with auto rebase on this patch caused the function type change and a build error is generated: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1560 A hotfix is on the way for fixing this: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1602 Sorry for the troublesome. /Ken

6 years, 5 months

1
0
0 0

Please help review memory access check design for multi-core topology

by David Hu (Arm Technology China)

Hi all, Could you please help review the design of TF-M memory access check in multi-core topology on https://review.trustedfirmware.org/c/trusted-firmware-m/+/1601 ? Since CMSE support is likely to be unavailable on multi-core platforms, that design proposes a general memory access check process for multi-core topology and corresponding HAL APIs to retrieve platform specific memory attribute configurations. Any comment would be gratefully received. If this design may not work in certain use cases, it would be very helpful if you can let me know the details. Thank you. Best regards, Hu Ziji

6 years, 5 months

1
0
0 0

Re: [TF-M] including platform specific interrupt definitions

by DeMars, Alan

Mate, Thank you for your response. I discovered not long after I posted my inquiry that recent merges to master should resolve the problem I'm having. I'm in the process of pulling in those commits locally. Thanks again, Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Mate Toth-Pal via TF-M Sent: Friday, July 19, 2019 1:22 PM To: TF-M(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] including platform specific interrupt definitions Hi Alan, I'm not sure on what version of TF-M is your base. This part of TF-M changed recently. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1354/ This change introduced the generated manifest header files. For each partition a header file is generated, which contains the signals for the partition. Both IRQ signals, and normal signals in case of IPC mode. Up to the following change all the signals (except for IRQ) had to be defined manually in a header file tfm_spm_signal_defs.h. This replaces the manually created IPC model signal definitions to the generated signals: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1356/ This does the same to the IRQ signals (up until this change, IRQ signals had to be defined in tfm_irq_signal_defs.h): https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1589/ This, and the related changes remove the manually created signal files. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1382/ So depending on your base you either need to manually define the signals, or should have it automatically once the generator script is run. As a general advice I would suggest to look at the IRQ signal 'SPM_CORE_IRQ_TEST_1_SIGNAL_TIMER_0_IRQ' which is the IRQ signal for one of the test services, and see where it appears and compare it to yours. Also if you could publish some of your code in the gerrit, we might be able help to find out what is the problem. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 19 July 2019 18:35 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] including platform specific interrupt definitions I'm trying to add s secure interrupt to my secure partition manifest but am getting a compile error because there are no definitions of my secure interrupt IRQ name and SIGNAL name. What is the mechanism for including a platform-specific header that defines platform specific interrupts when compiling "secure_fw/core/ipc/tfm_svcalls.c"? Alan -- 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

6 years, 5 months

1
0
0 0

Re: [TF-M] including platform specific interrupt definitions

by Mate Toth-Pal

Hi Alan, I'm not sure on what version of TF-M is your base. This part of TF-M changed recently. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1354/ This change introduced the generated manifest header files. For each partition a header file is generated, which contains the signals for the partition. Both IRQ signals, and normal signals in case of IPC mode. Up to the following change all the signals (except for IRQ) had to be defined manually in a header file tfm_spm_signal_defs.h. This replaces the manually created IPC model signal definitions to the generated signals: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1356/ This does the same to the IRQ signals (up until this change, IRQ signals had to be defined in tfm_irq_signal_defs.h): https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1589/ This, and the related changes remove the manually created signal files. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1382/ So depending on your base you either need to manually define the signals, or should have it automatically once the generator script is run. As a general advice I would suggest to look at the IRQ signal 'SPM_CORE_IRQ_TEST_1_SIGNAL_TIMER_0_IRQ' which is the IRQ signal for one of the test services, and see where it appears and compare it to yours. Also if you could publish some of your code in the gerrit, we might be able help to find out what is the problem. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 19 July 2019 18:35 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] including platform specific interrupt definitions I'm trying to add s secure interrupt to my secure partition manifest but am getting a compile error because there are no definitions of my secure interrupt IRQ name and SIGNAL name. What is the mechanism for including a platform-specific header that defines platform specific interrupts when compiling "secure_fw/core/ipc/tfm_svcalls.c"? Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 5 months

1
0
0 0

including platform specific interrupt definitions

by DeMars, Alan

I'm trying to add s secure interrupt to my secure partition manifest but am getting a compile error because there are no definitions of my secure interrupt IRQ name and SIGNAL name. What is the mechanism for including a platform-specific header that defines platform specific interrupts when compiling "secure_fw/core/ipc/tfm_svcalls.c"? Alan

6 years, 5 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M