Anton,
I'd like to give an update on the HAL APIs, around 10 minutes.
Best Regards,
Kevin
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Wednesday, September 9, 2020 11:34 PM
To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com>
Subject: [TF-M] TF-M Technical Forum call - September 17
Hello,
The next Technical Forum is planned on Thursday, September 17 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
Dear All,
Following the tech forum presentation (back in 6th August) I uploaded the draft design document for the Secure Enclave topic:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5653
I also updated the first implementation of the proposed solution for the Musca-B1 board with minimal features, marked as WIP:
https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope…
Limitations, missing features, notes:
* No support for isolation level2 on SSE-200
* Protected Storage is an Application RoT partition, but PS also moved to Secure Enclave
* Some regression tests running on secure side of SSE-200 fail as all messages are forwarded with the same client ID to Secure Enclave
* All IPC message forwarding is a blocking call
* Only one message is put into the mailbox at a time
* Musca-B1 related documentation is not complete yet
* Generated files are not committed, manifest parser should be run before build.
* The BL0 component mentioned in the tech forum presentation is not uploaded, as it is based on the new cmake system, and not so interesting right now
* Cmake changes are rudimentary, will be rebased to new cmake system.
Any feedback very welcomed!
Best regards,
Márk Horváth
Senior Software Engineer
Mark.Horvath(a)arm.com<mailto:Mark.Horvath@arm.com>
Arm Hungary Kft., Corvin Offices II, Crystal Tower, Budapest, Futó u. 45. H-1082 Hungary
www.arm.com<http://www.arm.com/>
Great news!
Congratulations, Shery, David. You made it happen!
Cheers,
Anton
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang via TF-M
Sent: 14 September 2020 04:47
To: tf-m(a)lists.trustedfirmware.org; Sherry Zhang <Sherry.Zhang2(a)arm.com>
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Integration of TF-M and FreeRTOS Kernel has been merged into FreeRTOS
Thanks Sherry for sharing this great news!
Regards,
David Wang
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Sherry Zhang via TF-M
Sent: Monday, September 14, 2020 9:50 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: [TF-M] Integration of TF-M and FreeRTOS Kernel has been merged into FreeRTOS
Hi all,
The integration of TF-M and FreeRTOS Kernel has been merged into the official FreeRTOS Kernel repository<https://github.com/FreeRTOS/FreeRTOS-Kernel> master branch. You can follow this port<https://github.com/FreeRTOS/FreeRTOS-Kernel/tree/master/portable/ThirdParty…> on Cortex-M33 platforms.
Regards,
Sherry Zhang
Thanks Sherry for sharing this great news!
Regards,
David Wang
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Sherry Zhang via TF-M
Sent: Monday, September 14, 2020 9:50 AM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Integration of TF-M and FreeRTOS Kernel has been merged into FreeRTOS
Hi all,
The integration of TF-M and FreeRTOS Kernel has been merged into the official FreeRTOS Kernel repository<https://github.com/FreeRTOS/FreeRTOS-Kernel> master branch. You can follow this port<https://github.com/FreeRTOS/FreeRTOS-Kernel/tree/master/portable/ThirdParty…> on Cortex-M33 platforms.
Regards,
Sherry Zhang
Hi Andrej,
Thanks, if the different approach for project compilation has its own ld file then we can remove these 4 lines - going to create a patch for this.
BR
/Ken
From: Andrej Butok <andrey.butok(a)nxp.com>
Sent: Friday, September 11, 2020 9:10 PM
To: Ken Liu <Ken.Liu(a)arm.com>
Cc: nd <nd(a)arm.com>
Subject: RE: The GNUARM linker script change about psa_client objects and the integration method [NXP]
Hi Ken,
Guess, these lines where upstream from NXP SDK, which is using a different approach for project compilation.
Most probably they may be removed for the original TFM.
Best regards,
Andrej
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M
Sent: Friday, September 11, 2020 3:04 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: [TF-M] The GNUARM linker script change about psa_client objects and the integration method [NXP]
Hi,
When I was trying to re-arrange the linker script I found below changes:
*psa_client.*(.text*) /* NXP */
*psa_client.*(.rodata*)
*psa_service.*(.text*) /* NXP */
*psa_service.*(.rodata*)
*psa_lifecycle.*(.text*) /* NXP */
*psa_lifecycle.*(.rodata*)
*tfm_log_raw.*(.text*) /* NXP */
I think at least the psa_client.o and psa_service.o are included into the libtfmsprt.a so these items looks duplicated.
What is the purpose of this change? Would it fix build problem or runtime problem?
Thanks.
/Ken
Hi,
When I was trying to re-arrange the linker script I found below changes:
*psa_client.*(.text*) /* NXP */
*psa_client.*(.rodata*)
*psa_service.*(.text*) /* NXP */
*psa_service.*(.rodata*)
*psa_lifecycle.*(.text*) /* NXP */
*psa_lifecycle.*(.rodata*)
*tfm_log_raw.*(.text*) /* NXP */
I think at least the psa_client.o and psa_service.o are included into the libtfmsprt.a so these items looks duplicated.
What is the purpose of this change? Would it fix build problem or runtime problem?
Thanks.
/Ken
Hi,
There is no forwarded define for '__START' in the current TF-M design, then the runtime init provided by toolchain is applied. This runtime init did something unnecessary as the data copying and ZI has been done already by the startup code, jumping to spm::main would be the next job as SPM would prepare runtime environment for subsequent partition execution and itself won't need other runtime operations besides the data moving.
I have created a patch to jump to main under GNUARM:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5609
Change the code is because this would easy the code reading -- most of the users won't check a compiler flag given in the build system for forwarding '__START', so they will try to find the __start from the toolchain source.
Currently, we can not avoid depending on ARMCLANG runtime init, so need double check (also IAR).
Please provide your feedback, we are changing the platform startup code and need your confirmation to see if it is applicable.
Best Regards,
Summer