Hi all,
May I ask you to take a look at the following patch set to decouple NS specific code from TF-M NS interface?
https://review.trustedfirmware.org/q/topic:%22decouple-ns-interface%22+(sta…
The decoupled NS code is moved from trusted-firmware-m repo to tf-m-tests repo, as an example of NS implementation.
https://review.trustedfirmware.org/q/topic:%22add-ns-code%22+(status:open%2…
The purpose of this change is to make it more flexible and simple to integrate NS OS with TF-M NS interface.
Currently TF-M provides some reference implementations of NS interface for NS OS integration. However, it may have limitations during NS OS integration as various NS OSes/application usages prefer different implementations.
Therefore, those NS OS specific code is removed from TF-M interface for NS clients in this patch set. The removed NS code includes NS interface lock ops, os wrappers and NS test specific implementation.
Those NS code can be taken as an example in tf-m-tests. NS developers can follow or replace them during integration with TF-M, according to NS OS implementation and actual scenarios, without hacking trusted-firmware-m repo.
This patch set doesn't change the current integration scheme. Instead, it exports the "tfm_ns_interface_dispatch()" API and enables NS OS to implement it according to NS OS and application specific requirement, such as NS interface lock operations.
Any comment is welcome!
Best regards,
Hu Ziji
Hi, Anton
I would like to introduce the topic about "FP support in TF-M". It may take about 60 mins.
Best Regards
Feder
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Wednesday, April 7, 2021 9:27 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Technical Forum call - April 15
Hi,
The next Technical Forum is planned on Thursday, April 15, 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
Hi Andrew,
[Sorry for the long delay of resuming this discussion.]
I think psa_irq_is_enabled() could be removed.
As the peripherals are exclusively owned by Partitions, Partitions should be able to manage the status of the IRQs by themselves.
And the psa_irq_disable() could still return the previous status.
It (and the psa_irq_enable() as well) should be atomic anyway because the caller would consider the IRQ is disabled or enabled by calling the corresponding API.
The APIs must ensure the validness, to do that disabling interrupts entirely might be inevitable.
In TF-M, this is done by calling SVC in the APIs to tell SPM to manipulate the interrupt controller. And SVC has higher priority than all interrupts.
Best Regards,
Kevin
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrew Thoelke via TF-M
Sent: Monday, February 22, 2021 11:03 PM
To: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com>
Subject: Re: [TF-M] Arm Firmware Framework for M 1.1 Extensions Alpha specification
I've had some further input on the interrupt management API. The use of patterns such as:
bool irq_enabled = psa_irq_is_enabled(MY_IRQ); // [1]
psa_irq_disable(MY_IRQ); // [2]
// critical section
if (irq_enabled)
psa_irq_enable(MY_IRQ);
must be discouraged as this is not guaranteed to be safe in the presence of interrupts that can change the status of MY_IRQ between the query [1] and the disable [2]. In general, it requires whole system analysis to determine that there are no such interrupts, and that this code is 100% reliable.
However, providing the originally proposed API such as psa_irq_disable(), which returns the prior status, does not practically solve the problem. Instead, it just moves the race condition window into the implementation of that API.
The only way in which such an API would be generally safe from the race condition is if the query+disable is atomic with respect to all other interrupts in the system - this either requires disabling interrupts entirely, or having an atomic read+disable capability in the interrupt controller. In systems which worry about such race conditions, disabling all interrupts can be unacceptable.
The recommended approach is to avoid having software that depends on the state of the interrupt, but which does not implicitly know the state of the interrupt. In such a system, there is never a need to query the current interrupt state as on any line of code, the interrupt state is always known at design time.
I am not sure if this suggests that we should:
1. Remove even the psa_irq_is_enabled() function, to prevent developers writing the above code, OR 2. We do not document the above pattern as a way to manage nested critical sections, OR 3. Retain the example above, but explain that this must be coupled with a software design that ensures the stability of the MY_IRQ status between [1] and [2]?
Regards,
Andrew
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: 22 February 2021 04:49
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Arm Firmware Framework for M 1.1 Extensions Alpha specification
As the ‘psa_irq_status_t’ is a implementation-defined value, is it possible let the implementation-define the status encoding?
Then the status and its checking code needs to be define by implementation, too:
PSA_IRQ_STATUS_NOCHANGE
PSA_IRQ_STATUS_DISABLE
PSA_IRQ_STATUS_ENABLE
PSA_IRQ_STAUTS_IS_ENABLED(status)
This would make everything implementation-defined and this affects the headers, and one extra header: psa_impdef.h needs to be created by implementations. With this the ffm based applications just use preprocessors to get status and check them; the enable/disable can be out of ‘true’ and ‘false’ values.
/Ken
From: TF-M <mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Kevin Peng via TF-M
Sent: Tuesday, January 26, 2021 11:08 AM
To: mailto:tf-m@lists.trustedfirmware.org
Cc: nd <mailto:nd@arm.com>
Subject: Re: [TF-M] Arm Firmware Framework for M 1.1 Extensions Alpha specification
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 <mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Andrew Thoelke via TF-M
Sent: Friday, January 15, 2021 1:25 AM
To: mailto:tf-m@lists.trustedfirmware.org; nd <mailto:nd@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 mailto:arm.psa-feedback@arm.com, or discuss the proposals here in the TF-M mailing list.
Regards,
Andrew
--
TF-M mailing list
mailto:TF-M@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
Hi,
TF-M release cadence is 4 month. In theory 1.4 release is around July.
Tamas
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Jamie Mccrae via TF-M
Sent: 2021. április 14., szerda 8:10
To: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Timeframe on release/approval
Hi Minos/David/Shebu,
Many thanks for the details. Is there a timeframe in mind for the next major release of TF-M i.e. version 1.4?
Thanks,
Jamie
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shebu Varghese Kuriakose via TF-M
Sent: 13 April 2021 17:57
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] Timeframe on release/approval
Hi Jamie,
My understanding is that Zephyr integrates release tags of TF-M. TF-M v1.2 was integrated and I assume v1.3 will be done sometime soon.
Regards,
Shebu
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of David Hu via TF-M
Sent: Tuesday, April 13, 2021 3:14 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] Timeframe on release/approval
Hi Jaime,
Anton and I have reviewed your patch. Please check our comments on the patch.
I believe other reviewers will provide their input as well soon.
Although it is difficult to guarantee the timeframe in TF-M as in other open-source project, it will speed up the review process if reviewers’ comments can be addressed in time. 😊
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Minos Galanakis via TF-M
Sent: Tuesday, April 13, 2021 12:09 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] Timeframe on release/approval
Hi Jamie,
Thank you very much for your interest in supporting for TF-M in your platform. Since you are contributing a new platform, I would recommend that you read the Trusted Firmware maintenance process<https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…>, for further details on the process.
To answer your questions about the timeframe, that really depends on various factors, such as how busy the maintainers of this code are, weather there is a release pending which would follow a code freeze, and how complicated the changes are. I don't believe it is easy to estimate a figure.
Regards,
Minos
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Jamie Mccrae via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Sent: 12 April 2021 09:40
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>>
Subject: [TF-M] Timeframe on release/approval
Hi,
I submitted a patch to add our board to the Trusted Firmware-M repository under https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9508 and was wondering on timeframes for receiving comments or having the pull request accepted? We want to have our board added to Zephyr RTOS and for that, we need the board in TF-M and pulled into the Zephyr version of this repository (I’m not sure if they can pull any version of the code or if they only pull full release versions e.g. 1.3.0), are there any comments on this and does anyone have any idea of a rough estimate the time required from now to get the base files into the zephyr version of the repository so we can submit our boards file?
Thanks,
Jamie
THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.
Hi Minos/David/Shebu,
Many thanks for the details. Is there a timeframe in mind for the next major release of TF-M i.e. version 1.4?
Thanks,
Jamie
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shebu Varghese Kuriakose via TF-M
Sent: 13 April 2021 17:57
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Timeframe on release/approval
Hi Jamie,
My understanding is that Zephyr integrates release tags of TF-M. TF-M v1.2 was integrated and I assume v1.3 will be done sometime soon.
Regards,
Shebu
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M
Sent: Tuesday, April 13, 2021 3:14 AM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Timeframe on release/approval
Hi Jaime,
Anton and I have reviewed your patch. Please check our comments on the patch.
I believe other reviewers will provide their input as well soon.
Although it is difficult to guarantee the timeframe in TF-M as in other open-source project, it will speed up the review process if reviewers’ comments can be addressed in time. 😊
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Minos Galanakis via TF-M
Sent: Tuesday, April 13, 2021 12:09 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] Timeframe on release/approval
Hi Jamie,
Thank you very much for your interest in supporting for TF-M in your platform. Since you are contributing a new platform, I would recommend that you read the Trusted Firmware maintenance process<https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…>, for further details on the process.
To answer your questions about the timeframe, that really depends on various factors, such as how busy the maintainers of this code are, weather there is a release pending which would follow a code freeze, and how complicated the changes are. I don't believe it is easy to estimate a figure.
Regards,
Minos
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Jamie Mccrae via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Sent: 12 April 2021 09:40
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>>
Subject: [TF-M] Timeframe on release/approval
Hi,
I submitted a patch to add our board to the Trusted Firmware-M repository under https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9508 and was wondering on timeframes for receiving comments or having the pull request accepted? We want to have our board added to Zephyr RTOS and for that, we need the board in TF-M and pulled into the Zephyr version of this repository (I’m not sure if they can pull any version of the code or if they only pull full release versions e.g. 1.3.0), are there any comments on this and does anyone have any idea of a rough estimate the time required from now to get the base files into the zephyr version of the repository so we can submit our boards file?
Thanks,
Jamie
THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.
Hi Jamie,
My understanding is that Zephyr integrates release tags of TF-M. TF-M v1.2 was integrated and I assume v1.3 will be done sometime soon.
Regards,
Shebu
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M
Sent: Tuesday, April 13, 2021 3:14 AM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Timeframe on release/approval
Hi Jaime,
Anton and I have reviewed your patch. Please check our comments on the patch.
I believe other reviewers will provide their input as well soon.
Although it is difficult to guarantee the timeframe in TF-M as in other open-source project, it will speed up the review process if reviewers’ comments can be addressed in time. 😊
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Minos Galanakis via TF-M
Sent: Tuesday, April 13, 2021 12:09 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] Timeframe on release/approval
Hi Jamie,
Thank you very much for your interest in supporting for TF-M in your platform. Since you are contributing a new platform, I would recommend that you read the Trusted Firmware maintenance process<https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…>, for further details on the process.
To answer your questions about the timeframe, that really depends on various factors, such as how busy the maintainers of this code are, weather there is a release pending which would follow a code freeze, and how complicated the changes are. I don't believe it is easy to estimate a figure.
Regards,
Minos
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Jamie Mccrae via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Sent: 12 April 2021 09:40
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>>
Subject: [TF-M] Timeframe on release/approval
Hi,
I submitted a patch to add our board to the Trusted Firmware-M repository under https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9508 and was wondering on timeframes for receiving comments or having the pull request accepted? We want to have our board added to Zephyr RTOS and for that, we need the board in TF-M and pulled into the Zephyr version of this repository (I’m not sure if they can pull any version of the code or if they only pull full release versions e.g. 1.3.0), are there any comments on this and does anyone have any idea of a rough estimate the time required from now to get the base files into the zephyr version of the repository so we can submit our boards file?
Thanks,
Jamie
THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.
The video links to the TF-M presentations @ Linaro Virtual Connect 2021 can be found here - https://developer.trustedfirmware.org/w/tf_m/tf-m_videos/linaro_virtual_con…
Thanks,
Shebu
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Thursday, March 18, 2021 3:58 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] TF-M at Linaro Connect 2021
Hello,
This is the list of TF-M related sessions on Linaro Virtual Connect 2021 https://connect.linaro.org/schedule/
* 23/3 @ 17:15 Introducing the Trusted Services project - Julian Hall
* 23/3 @ 18:30 Physical Attack Mitigation - Tamas Ban, Raef Coles
* 24/3 @ 9:45 Firmware update service in TF-M - Sherry Zhang
* 24/3 @ 10:45 Firmware Framework - M 1.1 feature update in TF-M - Ken Liu
* 25/3 @ 12:45 X.509 Certificate Management with Zephyr/TF-M - David Vincze
* 25/3 @ 13:15 Essential ARM Cortex-M Debugging with GDB - Kevin Townsend
Cheers,
Anton
Hi Jaime,
Anton and I have reviewed your patch. Please check our comments on the patch.
I believe other reviewers will provide their input as well soon.
Although it is difficult to guarantee the timeframe in TF-M as in other open-source project, it will speed up the review process if reviewers’ comments can be addressed in time. 😊
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Minos Galanakis via TF-M
Sent: Tuesday, April 13, 2021 12:09 AM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Timeframe on release/approval
Hi Jamie,
Thank you very much for your interest in supporting for TF-M in your platform. Since you are contributing a new platform, I would recommend that you read the Trusted Firmware maintenance process<https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…>, for further details on the process.
To answer your questions about the timeframe, that really depends on various factors, such as how busy the maintainers of this code are, weather there is a release pending which would follow a code freeze, and how complicated the changes are. I don't believe it is easy to estimate a figure.
Regards,
Minos
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Jamie Mccrae via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Sent: 12 April 2021 09:40
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>>
Subject: [TF-M] Timeframe on release/approval
Hi,
I submitted a patch to add our board to the Trusted Firmware-M repository under https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9508 and was wondering on timeframes for receiving comments or having the pull request accepted? We want to have our board added to Zephyr RTOS and for that, we need the board in TF-M and pulled into the Zephyr version of this repository (I’m not sure if they can pull any version of the code or if they only pull full release versions e.g. 1.3.0), are there any comments on this and does anyone have any idea of a rough estimate the time required from now to get the base files into the zephyr version of the repository so we can submit our boards file?
Thanks,
Jamie
THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.
Hi Jamie,
Thank you very much for your interest in supporting for TF-M in your platform. Since you are contributing a new platform, I would recommend that you read the Trusted Firmware maintenance process<https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…>, for further details on the process.
To answer your questions about the timeframe, that really depends on various factors, such as how busy the maintainers of this code are, weather there is a release pending which would follow a code freeze, and how complicated the changes are. I don't believe it is easy to estimate a figure.
Regards,
Minos
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Jamie Mccrae via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 12 April 2021 09:40
To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>
Subject: [TF-M] Timeframe on release/approval
Hi,
I submitted a patch to add our board to the Trusted Firmware-M repository under https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9508 and was wondering on timeframes for receiving comments or having the pull request accepted? We want to have our board added to Zephyr RTOS and for that, we need the board in TF-M and pulled into the Zephyr version of this repository (I’m not sure if they can pull any version of the code or if they only pull full release versions e.g. 1.3.0), are there any comments on this and does anyone have any idea of a rough estimate the time required from now to get the base files into the zephyr version of the repository so we can submit our boards file?
Thanks,
Jamie
THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.
Hi,
I submitted a patch to add our board to the Trusted Firmware-M repository under https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9508 and was wondering on timeframes for receiving comments or having the pull request accepted? We want to have our board added to Zephyr RTOS and for that, we need the board in TF-M and pulled into the Zephyr version of this repository (I'm not sure if they can pull any version of the code or if they only pull full release versions e.g. 1.3.0), are there any comments on this and does anyone have any idea of a rough estimate the time required from now to get the base files into the zephyr version of the repository so we can submit our boards file?
Thanks,
Jamie
THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.
