Hi,
Thank you for the proposal, I have commented in the Gerrit review.
Kind regards,
Jamie
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M
Sent: 02 December 2020 14:28
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Review request for adding External Trusted Secure Storage service in TF-M
Hi everyone,
Please help review the following design proposal of adding External Trusted Secure Storage service in TF-M,any comments and suggestions will be appreciated.
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7295
Best Regards,
Poppy Wu
Macronix Microelectronics (Suzhou) Co.,Ltd
http://www.mxic.com.cn<http://www.mxic.com.cn/>
========================================================
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=====================================================================
Hello,
The next Technical Forum is planned on Thursday, December 10 at 6:00-07:00 UTC (Asia 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
I've created a proof of concept for allowing out-of-tree platforms here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7301
It was simpler than I had thought :)
Øyvind
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: Thursday, November 26, 2020 07:57
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Externally override flash layout and pin configurations (out-of-tree platforms?)
Hi,
In the ideal case with HAL API, the platform itself can decide which variant's layout to be applied, selected by build system switches or just some header files.
Because SPM could get what it needed by HAL API run-time.
It can be mostly done inside the platform folder if one platform has the variants management already.
Others please give inputs as this is a very useful topic, we can list down the problem we met during integration first.
BR
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Rønningstad, Øyvind via TF-M
Sent: Thursday, November 26, 2020 3:47 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: Rasmussen, Torsten <Torsten.Rasmussen(a)nordicsemi.no<mailto:Torsten.Rasmussen@nordicsemi.no>>
Subject: [TF-M] Externally override flash layout and pin configurations (out-of-tree platforms?)
Hi all
In our work integrating TFM into Zephyr and the nRF Connect SDK, it's apparent that the integration would be a lot smoother if we could specify TFM's flash layout externally.
Looking into it a bit, I came up with a draft proposal here: https://github.com/zephyrproject-rtos/trusted-firmware-m/pull/18/files<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>
We could just modify our own platforms to this and be happy, but I'm wondering if there would be interest in standardizing something.
Now, a related problem is: How can we make it easier to add multiple boards based on a single chip. For the Nordic platforms we've already separated the chip-specific code (nRF9160/nRF5340) from the board specific code (DK/PDK), and for the boards, it really boils down to pin configurations.
We could allow to specify pins via Cmake instead, to easily allow users to support their production PCBs.
But (this was brought up in the above PR) we can also solve both problems by adding support for out-of-tree platforms.
For example, allow TFM to be built like so:
cmake -DTFM_PLATFORM=../../../../my_custom_board ...
This would probably be less work that designing a new interface for overriding flash layouts and pin configurations.
What are your thoughts?
BR,
Øyvind Rønningstad
Hi everyone,
Please help review the following design proposal of adding External
Trusted Secure Storage service in TF-M,any comments and suggestions will
be appreciated.
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7295
Best Regards,
Poppy Wu
Macronix Microelectronics (Suzhou) Co.,Ltd
http://www.mxic.com.cn
========================================================
============================================================================
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=====================================================================
Hi everyone,
Please help review the following design proposal of adding External
Trusted Secure Storage service in TF-M,any comments and suggestions will
be appreciated.
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7295
Best Regards,
Poppy Wu
Macronix Microelectronics (Suzhou) Co.,Ltd
http://www.mxic.com.cn
========================================================
============================================================================
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=====================================================================
Hi Everyone,
I would like to propose the deprecation of platform MPS2/SSE-200_AWS because the platform is no longer available to use: https://aws.amazon.com/marketplace/pp/ARM-Ltd-DesignStart-FPGA-on-Cloud-Cor…
As per the process, this proposal is open for discussion for a period of 4 weeks and if there are no major objections, the platform should be marked as deprecated and removed from TF-M master after next release.
Thanks and Best regards,
Marton Berke
Hi Anton
I would have an introduction to TF-M openCI.
Thanks
Karl
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of David Hu via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Monday, November 23, 2020 2:10 PM
To: Anton Komlev <Anton.Komlev(a)arm.com>
Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>
Subject: Re: [TF-M] Technical Forum call - November 26
Hi Anton,
I’d like to share a proposal to improve dual-cpu mailbox.
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Thursday, November 19, 2020 4:59 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Technical Forum call - November 26
Hello,
The next Technical Forum is planned on Thursday, November 26 at 15:00-16:00 GMT (US friendly 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 Chris,
Thanks for point out this. Here is the fix:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7226
Regards,
Shawn
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M
Sent: Thursday, November 26, 2020 2:55 AM
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] gcc compiler requirement documentation
Looking at docs/getting_started//tfm_sw_requirement.rst it says that the version requirement for gcc is "GNU Arm compiler v7.3.1+". then it describes where to get that toolchain, but in that section the two versions it suggests are "GNU Arm Embedded Toolchain: 6-2017-q1-update" and "GNU Arm Embedded Toolchain: 7-2018-q2-update". The former is gcc version 6.3.1, which doesn't actually meet the requirements.
Chris Brand
Sr Prin Software Engr, MCD: WIRELESS
Cypress Semiconductor Corp.
An Infineon Technologies Company
#320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada
www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com>
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.
Hi,
In the ideal case with HAL API, the platform itself can decide which variant's layout to be applied, selected by build system switches or just some header files.
Because SPM could get what it needed by HAL API run-time.
It can be mostly done inside the platform folder if one platform has the variants management already.
Others please give inputs as this is a very useful topic, we can list down the problem we met during integration first.
BR
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Rønningstad, Øyvind via TF-M
Sent: Thursday, November 26, 2020 3:47 AM
To: tf-m(a)lists.trustedfirmware.org
Cc: Rasmussen, Torsten <Torsten.Rasmussen(a)nordicsemi.no>
Subject: [TF-M] Externally override flash layout and pin configurations (out-of-tree platforms?)
Hi all
In our work integrating TFM into Zephyr and the nRF Connect SDK, it's apparent that the integration would be a lot smoother if we could specify TFM's flash layout externally.
Looking into it a bit, I came up with a draft proposal here: https://github.com/zephyrproject-rtos/trusted-firmware-m/pull/18/files
We could just modify our own platforms to this and be happy, but I'm wondering if there would be interest in standardizing something.
Now, a related problem is: How can we make it easier to add multiple boards based on a single chip. For the Nordic platforms we've already separated the chip-specific code (nRF9160/nRF5340) from the board specific code (DK/PDK), and for the boards, it really boils down to pin configurations.
We could allow to specify pins via Cmake instead, to easily allow users to support their production PCBs.
But (this was brought up in the above PR) we can also solve both problems by adding support for out-of-tree platforms.
For example, allow TFM to be built like so:
cmake -DTFM_PLATFORM=../../../../my_custom_board ...
This would probably be less work that designing a new interface for overriding flash layouts and pin configurations.
What are your thoughts?
BR,
Øyvind Rønningstad