- TF-M - lists.trustedfirmware.org

Re: [TF-M] SP thread priority when servicing secure interrupts

by Mate Toth-Pal

Hi Alan, The expected behaviour depends on the Model used in the TF-M. Library model: The generated interrupt handler runs in Handler mode, and after doing an SVC, it starts executing the handler defined in the SP in thread mode. At that point the interrupt handler hadn't returned, so the interrupt is still active in the NVIC. This means that the execution priority of the CPU is equal to the interrupt's priority, even if the processor is executing in thread mode. At the end of the execution of the SP interrupt handler, an SVC is executed, which then return to the context of the generated interrupt handler. And only at this point does the interrupt handler return, and can a pending interrupt with lower priority be active. IPC model: The generated interrupt handler runs at the interrupt’s assigned priority, sets a signal for the partition that should handle the interrupt, and then returns. So the interrupt is cleared in the NVIC. After this, the secure scheduler can schedule the handling partition (the scheduling happens in a PendSV handler), and the signal handler runs in thread mode. In this case the priority of the thread mode is 256 (no priority boosting, and no active exceptions). So the execution can be interrupted. The generated stub is not run again, until the interrupt gets triggered again. If you still find the behaviour of the system unexpected, could you please share some more information about the environment and sequence of steps for reproducing the behaviour? Best would be if you could reproduce the behaviour with one of the platforms supported by the upstream TF-M, and share your patch, so Others could have a look at it in the debugger as well. Thanks, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 29 October 2019 01:52 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] SP thread priority when servicing secure interrupts It appears that when a SP is servicing a manifest-specified secure interrupt configured with a priority equal to or lower than the pendsv interrupt, the processor is operating at the priority of the pendsv interrupt. While the SP is servicing the secure interrupt's signal (ie: in thread mode), If another interrupt is triggered of the same priority or lower than the pendsv, that new interrupt is not immediately vectored to. Instead, it is vectored to AFTER the secure interrupt's stub function (generated by the template) returns. Is this true and expected behavior? Unless BASEPRI is set to some non-zero value, I thought the processor was always running with no exception priority while in thread mode. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 12 months

1
0
0 0

SP thread priority when servicing secure interrupts

by DeMars, Alan

It appears that when a SP is servicing a manifest-specified secure interrupt configured with a priority equal to or lower than the pendsv interrupt, the processor is operating at the priority of the pendsv interrupt. While the SP is servicing the secure interrupt's signal (ie: in thread mode), If another interrupt is triggered of the same priority or lower than the pendsv, that new interrupt is not immediately vectored to. Instead, it is vectored to AFTER the secure interrupt's stub function (generated by the template) returns. Is this true and expected behavior? Unless BASEPRI is set to some non-zero value, I thought the processor was always running with no exception priority while in thread mode. Alan

6 years, 12 months

1
0
0 0

Dual core boot design document review

by Christopher Brand

Hi, Back in March, I wrote the dual-core design document at https://developer.trustedfirmware.org/w/tf_m/design/twin-cpu/bootloader/ It was discussed on the mailing list in a thread that starts at https://lists.trustedfirmware.org/pipermail/tf-m/2019-March/000088.html Since then, TF-M has defined a process for design reviews, and it would be nice to get this design document into the docs/design directory, particularly as the implementation of the design is already in the codebase. Given that there has already been discussion on the mailing list, I've gone ahead and created a review in Gerrit: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2384 I also added all the people who contributed to that thread as reviewers. Please feel free to add yourself as a reviewer. Also, comments on whether this is the right process to follow for design documentation in this transitional state would be useful. Thanks, Chris 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.

7 years

1
0
0 0

Re: [TF-M] IPC Regressions reference platform specific resources

by Mate Toth-Pal

Hi Alan, Andrej is right about PSA certification, for that you don't need to pass the regression test suite. However for submitting a change to the upstream master branch on https://www.trustedfirmware.org/ it is a requirement to pass those tests. The peripherals defined in the tfm_peripherals_def.h files are the peripherals that are mentioned in the 'mmio_regions' node in the partition manifest yaml files. It is a requirement that a macro is defined with this name that is substituted to a pointer type value. For more details see platform\readme.rst, chapter 'platformext/target/tfm_peripherals_def.h'. The type 'tfm_spm_partition_platform_data_t' is defined by the platform implementation, so TF-M core has no knowledge about the content of an object of type 'tfm_spm_partition_platform_data_t', and doesn't use it. The pointer is only considered by it as a token, that is passed to the platform HAL functions. This means that if the platform needs to do nothing related to the peripherals in the HAL functions either because - no isolation is needed to be configured for that peripheral - the peripheral doesn't exist, and the functionality is emulated (1) it is OK to define the value of the macro to be NULL (Just as it is done in platform/ext/target/musca_a/tfm_peripherals_def.h). The TFM_PERIPHERAL_FPGA_IO is used by the core test, to access button state and to blink leds. For the Musca-A platform these functionalities are emulated in the file platform/ext/target/musca_a/plat_test.c TFM_PERIPHERAL_TIMER0 is used by the IRQ tests. The upstreamed platforms all support some kind of timer, so there is a real implementation for all the platforms. (platform/ext/target/musca_a/plat_test.c) If it is not possible to create working implementations for the interfaces in platform/include/tfm_plat_test.h, then it is possible to disable the peripheral access and irq tests, by adding the following lines to the platform cmake file: set(TFM_ENABLE_PERIPH_ACCESS_TEST Off) set(TFM_ENABLE_IRQ_TEST Off) Please note, that even in this case TFM_PERIPHERAL_FPGA_IO and TFM_PERIPHERAL_TIMER0 are still need to be defined (NULL is ok), and the plat_test interface functions also need to have at least an empty implementation. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 24 October 2019 08:39 To: DeMars, Alan <ademars(a)ti.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] IPC Regressions reference platform specific resources Hi Alan > I assume that to obtain any kind of TF-M compliance certification for our platform, I will be required to demonstrate successful execution of these regression tests. Regression tests are only to check if your TFM port is correct (not for certification). You should to demonstrate a successful log from the PSA Test Suite, but only for the "PSA Certified Functional API". For the PSA Certified Level 1, it is not required. Best regards, Andrej Butok NXP Semiconductors -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: Wednesday, October 23, 2019 5:20 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] IPC Regressions reference platform specific resources I'm attempting to build the ConfigRegressionIPC image and have run into the issue that some of the tests rely on device specific resources (TFM_PERIPHERAL_TIMER0 and TFM_PERIPHERAL_FPGA_IO). I assume that to obtain any kind of TF-M compliance certification for our platform, I will be required to demonstrate successful execution of these regression tests. If that is so, how should I proceed to resolve this conflict? Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

7 years

1
0
0 0

Re: [TF-M] contributing to the TF-M project

by Summer Qin (Arm Technology China)

Hi, The process of contributing to TF-M patch is updated now: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1007/ We can get an updated version after reviewing. Regards, Summer On 10/23/19, 7:55 PM, "Shebu Varghese Kuriakose via TF-M" <tf-m(a)lists.trustedfirmware.org> wrote: Hi Alan, 'Create Task' is the correct option to use. You can also add 'Trusted Firmware M' as the project name in the Tags field in the task. Looks like contributing.rst can do with a few updates/corrections. Regards, Shebu -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: Monday, October 21, 2019 7:37 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] contributing to the TF-M project I am trying to follow the instructions provided here: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/contributi… But I'm stumbling on the very first step: - Create an issue in http://issues.trustedfirmware.org to keep others informed about your ongoing work. When I log into the sight, I have not been able to find how to create an issue. I see links for "Create Task" and "Create Project" but nothing for "Create Issue". What am I doing wrong? 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

7 years

1
0
0 0

Align manifest to PSA FF 1.0.0

by Edison Ai (Arm Technology China)

Hi all, I had created a set of patches to align the manifest to PSA FF 1.0.0: https://review.trustedfirmware.org/#/q/topic:manifest_alignment+(status:ope…. The manifest is the basics that are related to almost every module. So please help to review them as far as possible. Thanks, Edison

7 years

1
0
0 0

Re: [TF-M] IPC Regressions reference platform specific resources

by Andrej Butok

Hi Alan > I assume that to obtain any kind of TF-M compliance certification for our platform, I will be required to demonstrate successful execution of these regression tests. Regression tests are only to check if your TFM port is correct (not for certification). You should to demonstrate a successful log from the PSA Test Suite, but only for the "PSA Certified Functional API". For the PSA Certified Level 1, it is not required. Best regards, Andrej Butok NXP Semiconductors -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: Wednesday, October 23, 2019 5:20 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] IPC Regressions reference platform specific resources I'm attempting to build the ConfigRegressionIPC image and have run into the issue that some of the tests rely on device specific resources (TFM_PERIPHERAL_TIMER0 and TFM_PERIPHERAL_FPGA_IO). I assume that to obtain any kind of TF-M compliance certification for our platform, I will be required to demonstrate successful execution of these regression tests. If that is so, how should I proceed to resolve this conflict? Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

7 years

1
0
0 0

IPC Regressions reference platform specific resources

by DeMars, Alan

I'm attempting to build the ConfigRegressionIPC image and have run into the issue that some of the tests rely on device specific resources (TFM_PERIPHERAL_TIMER0 and TFM_PERIPHERAL_FPGA_IO). I assume that to obtain any kind of TF-M compliance certification for our platform, I will be required to demonstrate successful execution of these regression tests. If that is so, how should I proceed to resolve this conflict? Alan

7 years

1
0
0 0

Re: [TF-M] contributing to the TF-M project

by Shebu Varghese Kuriakose

Hi Alan, 'Create Task' is the correct option to use. You can also add 'Trusted Firmware M' as the project name in the Tags field in the task. Looks like contributing.rst can do with a few updates/corrections. Regards, Shebu -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: Monday, October 21, 2019 7:37 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] contributing to the TF-M project I am trying to follow the instructions provided here: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/contributi… But I'm stumbling on the very first step: - Create an issue in http://issues.trustedfirmware.org to keep others informed about your ongoing work. When I log into the sight, I have not been able to find how to create an issue. I see links for "Create Task" and "Create Project" but nothing for "Create Issue". What am I doing wrong? Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

7 years

1
0
0 0

Re: [TF-M] contributing to the TF-M project

by Summer Qin (Arm Technology China)

Hi Alan, Thanks for reporting this issue. Yes, the "Create Task" in https://developer.trustedfirmware.org/maniphest is the place you can use. Just create a task, add the tag "Trusted Firmware M" and others you can set as you want or keep them as default. And please add this task link under your commit as comments, please add the test env and result as well if you have. This part needs to be updated, and we will push a patch to fix it ASAP. Regards, Summer On 10/22/19, 2:37 AM, "TF-M on behalf of DeMars, Alan via TF-M" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m(a)lists.trustedfirmware.org> wrote: I am trying to follow the instructions provided here: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/contributi… But I'm stumbling on the very first step: - Create an issue in http://issues.trustedfirmware.org to keep others informed about your ongoing work. When I log into the sight, I have not been able to find how to create an issue. I see links for "Create Task" and "Create Project" but nothing for "Create Issue". What am I doing wrong? Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

7 years

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M