- TF-M - lists.trustedfirmware.org

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, March 17, 15:00-16:00 UTC (West 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

4 years

1
0
0 0

The new design proposal guideline now take effect

by David Hu

Hi all, The new and simplified TF-M design proposal guideline is approved: https://tf-m-user-guide.trustedfirmware.org/docs/contributing/tfm_design_pr…. Please feel free to submit your topics to mailing list or tech forum! Formal design documents are NOT required anymore. Best regards, Hu Ziji

4 years

1
0
0 0

TF-M release v1.6,0 date change to April 28

by Anton Komlev

Hello, TF-M release v1.6.0 will be shifted from April 15 to April 28. The main reason is Easter holiday and expected lack of availability from community and platform owners around that date. Feature freeze will be moved to April 6th when the release branch will be created. Please update your plans accordingly. Please let me know if this change make difficulty for you and better date is possible. Thanks, Anton

4 years

1
0
0 0

Simplify TFM_PLATFORM in build system

by Jianliang Shen

Hi all, I want to simplify the flag TFM_PLATFORM in build system. TF-M now already supports two different ways to choose specific platform, for example AN521: - Absolute path: '<tf-m path>/platform/ext/target/arm/mps2/an521' - Relative path: 'arm/mps2/an21' Recently I have uploaded a [tf-m patch]<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/14260> to support platform name: - Platform name: 'an521' I think it will be more convenient for developers to use: - Users don't need to remember and type the absolute or relative path, only target platform name is enough. - If the structure of certain platform is changed, the default build command of TFM_PLATFORM is same. I'd be very grateful if you can give any suggestion or enhancement for me. Thanks. Best Regards Jianliang Shen

4 years

1
0
0 0

TF-M design documents about spm

by zhilei.wang

Dear All, I view the tf-m source code for the first time, and many of the code details can not be make clear. So .., where may I find the design documents of spm, for example: trusted-firmware-m-TF-Mv1.5.0\secure_fw\spm\cmsis_func and cmsis_psa software modules. Best Regards Wang Zhilei | Software Beken Corporation ---------------------------------------------------------------------------- ---------------------------------------------------------

4 years

3
2
0 0

Technical Forum call - March 3

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, March 3, 7:00-8:00 UTC (Asian 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

4 years

2
2
0 0

TF-M covertly results and configs to align our coverity environment to TF-M project CI

by Kostiantyn.Tkachov＠infineon.com

Hi colleagues! Could we get a list of MISRA/CERT-C violations that were found by tf-m Coverity CI, as example from https://ci.trustedfirmware.org/job/tf-m-coverity/lastSuccessfulBuild/ Also (if it possible), could you provide Coverity configs to help align this tool setup on our side to CI and to check all changes before any pool requests? Best regards, Kostiantyn Tkachov Cypress Semiconductor Ukraine Firmware Security

4 years

2
1
0 0

Problem compiling Trusted Firmware M in Linux for PSOC64

by AntonioJavier.CabreraGutierrez＠infineon.com

Hello, I am writing to you asking help because we are having problems when I try to compile the Trusted Firmware M from source code. I downloaded the code from the official repository: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git I moved to the last TAG: TF-Mv1.5.0 I am following this tutorial for PSOC64 platform https://tf-m-user-guide.trustedfirmware.org/platform/ext/target/cypress/pso… When I execute the first cmake command indicating the platform and the toolchain everything works well: cmake -DTFM_PLATFORM=cypress/psoc64 -DTFM_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake .. The problems appears when I build the code using the second cmake command: cmake --build cmake_build -- -j I got this output [cid:image003.jpg@01D82A77.95B43640] /home/admin/Escritorio/trusted-firmware-m/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.c: In function 't_cose_crypto_pub_key_verify': /home/admin/Escritorio/trusted-firmware-m/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.c:145:5: error: conversion to non-scalar type requested 145 | verification_key_psa = (psa_key_handle_t)verification_key.k.key_handle; | ^~~~~~~~~~~~~~~~~~~~ /home/admin/Escritorio/trusted-firmware-m/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.c: In function 't_cose_crypto_pub_key_sign': /home/admin/Escritorio/trusted-firmware-m/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.c:194:5: error: conversion to non-scalar type requested 194 | signing_key_psa = (psa_key_handle_t)signing_key.k.key_handle; | ^~~~~~~~~~~~~~~ /home/admin/Escritorio/trusted-firmware-m/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.c: In function 't_cose_crypto_sig_size': /home/admin/Escritorio/trusted-firmware-m/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.c:245:5: error: conversion to non-scalar type requested 245 | signing_key_psa = (psa_key_handle_t)signing_key.k.key_handle; | ^~~~~~~~~~~~~~~ secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/build.make:425: recipe for target 'secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/__/__/__/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.o' failed make[2]: *** [secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/__/__/__/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.o] Error 1 make[2]: *** Waiting for unfinished jobs.... CMakeFiles/Makefile2:1347: recipe for target 'secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/all' failed make[1]: *** [secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/all] Error 2 Makefile:135: recipe for target 'all' failed make: *** [all] Error 2 There are the version of the software that are using: arm-none-eabi-gcc (GNU Arm Embedded Toolchain 10.3-2021.10) 10.3.1 20210824 (release) cmake version 3.23.0-rc2 It seems strange to me that there are compilation errors in the source code, that's why I am writing this mail, in case there is a bug in the code. Best regards. Antonio Javier Cabrera Gutierrez Infineon Technologies AG PhD Candidate R&D Engineer IFAG BEX RDE RDF ISS Office: +49 89 234 36403 Mobile: +49 151 181 34322 AntonioJavier.CabreraGutierrez(a)infineon.com<mailto:AntonioJavier.CabreraGutierrez@infineon.com> Am Campeon 1-15 85579 Neubiberg Germany www.infineon.com<http://www.infineon.com> Discoveries<http://www.infineon.com/discoveries> Facebook<http://www.facebook.com/infineon> Twitter<http://www.twitter.com/Infineon> LinkedIn<http://www.linkedin.com/company/infineon-technologies> Part of your life. Part of tomorrow. Infineon Technologies AG Chairman of the Supervisory Board: Dr. Wolfgang Eder Management Board: Dr. Reinhard Ploss (CEO), Dr. Helmut Gassel, Jochen Hanebeck, Dr. Sven Schneider Registered Office: Neubiberg Commercial Register: München HRB 126492 This e-mail and any attachments are confidential. They are intended solely for the attention and use of the named addressee(s). If you are not the named addressee(s) you must not use, disclose, retain or reproduce all or any part of the information contained in this e-mail or any attachments. Any unauthorized use or disclosure may be unlawful. If you have received this e-mail by mistake, please inform the sender immediately and delete it and all copies from your system and destroy any hard copies of it.

4 years

3
2
0 0

Locking of PRIS bit in AIRCR register

by JAYLES Romain

Hi all, We are currently testing the tfm-m implementation on a STMicroelectronic chip: stm32u5 board. This stm32u5 has a special register: SYSCFG_CSLOCKR (see https://www.st.com/resource/en/reference_manual/rm0456-stm32u575585-armbase…). This register allows to lock the PRIS bit of the AIRCR register from further modification. The issue here is that, in the ST implementation, thanks to this SYSCFG_CSLOCKR, the PRIS bit of the AIRCR is locked at boot (Reset_Handler in file startup_stm32u5xx_s.c). Resulting in the function tfm_arch_set_secure_exception_priorities() not being able to set the PRIS bit of the AIRCR. This situation lead to big issues at runtime as interrupt priority of NSPE are able to pre-empt interrupt of SPE. Disabling the locking of PRIS bit solve our problem but currently we don't see a clean way to integrate chip specific security features (something like callback/tfm_hal_ ) after the function tfm_arch_set_secure_exception_priorities() has been called. What would be the best way to fix the current issue which could also arise on other platform ? Regards, Romain

4 years

3
4
0 0

Please review a new design proposal guideline

by David Hu

Hi all, As part of the documentation improvements, a new design proposal guideline [1] is proposed to replace and simplify the current process. The basic idea is to encourage developers to share their design via mailing list and tech forum, without a well-formatted design document. If developers prefer a document for a new feature, please provide an integration guide/user manual instead. Please check the details in the patch below. [1] https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/14104 The rendered html version: https://ci-builds.trustedfirmware.org/static-files/KTOoRMhB4VsgNQFkdMgWZcZG… Best regards, Hu Ziji

4 years

1
0
0 0

Issues with psa_wait() when waiting for interrupts and IPC function calls.

by Martin Gunnarsson

Hello, I am trying to write an Application RoT for a research project I am a part of. I have run into an issue that I have been unable to solve independently. My problem is the unexpected behavior of psa_wait() when using signal masks. I have two signals, TFM_TIMER1_IRQ_SIGNAL and TFM_SECURE_FUNCTION_SIGNAL. The TIMER1_IRQ signal is triggered by an FLIH interrupt handler that returns TFM_FLIH_SIGNAL. The interrupt is triggered every 1 second by TIMER1. The TFM_SECURE_FUNCTION_SIGNAL is triggered by a periodic function call from the NSPE (a Zephyr thread) and is called every 10 seconds. Observed result: If PSA_WAIT_ANY is used as a signal mask, the TIMER0_IRQ_SIGNAL will only be received when TFM_SECURE_FUNCTION_SIGNAL is received, ergo, every 10 s. Thus any stage 2 handling of an interrupt would be missed. If TFM_TIMER1_IRQ_SIGNAL is used as a signal mask, the signal will be received every 1 s as expected. The TFM_SECURE_FUNCTION_SIGNAL will never be received, as can be expected in the NSPEtoo. I have tried a "hybrid approach" where I call psa_wait(TFM_TIMER1_IRQ_SIGNAL, PSA_BLOCK) /* handle signals .... */ and then psa_wait(TFM_SECURE_FUNCTION_SIGNAL, PSA_POLL). The stage 2 IRS is called, and the secure function is also called. But not with the regularity that I would like. Am I missing something obvious? I have read the Secure Interrupt Integration Guide and carefully studied the SLIH and FLIH test services for the TF-M regression tests. Have I forgotten to reset a signal somewhere? Does the interrupt not preempt the NSPE? I would be immensely grateful for any or all responses. If you need more information, please let me know. Best wishes, Martin Gunnarsson PhD Student RISE Research Institutes of Sweden & Lund University Complete code of my Application RoT: #include <stdbool.h> #include <stdint.h> #include <stddef.h> #include "tfm_api.h" #include "tfm_secure_api.h" #include "psa/service.h" #include "tfm_sp_log.h" #include "psa_manifest/pid.h" #include "psa_manifest/tfm_secure_partition.h" #include <hal/nrf_gpio.h> #include <hal/nrf_timer.h> #include <helpers/nrfx_reset_reason.h> #include <nrf_board.h> #include <region_defs.h> #define TIMER_RELOAD_VALUE (1*1024*1024) static volatile uint32_t interrupt_ctr = 0; static volatile uint32_t function_ctr = 0; static void timer_init(NRF_TIMER_Type * TIMER) { nrf_timer_mode_set(TIMER, NRF_TIMER_MODE_TIMER); nrf_timer_bit_width_set(TIMER, NRF_TIMER_BIT_WIDTH_32); nrf_timer_frequency_set(TIMER, NRF_TIMER_FREQ_1MHz); nrf_timer_cc_set(TIMER, NRF_TIMER_CC_CHANNEL0, TIMER_RELOAD_VALUE); /* Clear the timer once event is generated. */ nrf_timer_shorts_enable(TIMER, NRF_TIMER_SHORT_COMPARE0_CLEAR_MASK); } static void timer_stop(NRF_TIMER_Type * TIMER) { nrf_timer_task_trigger(TIMER, NRF_TIMER_TASK_STOP); nrf_timer_int_disable(TIMER, NRF_TIMER_INT_COMPARE0_MASK); nrf_timer_event_clear(TIMER, NRF_TIMER_EVENT_COMPARE0); } static void timer_start(NRF_TIMER_Type * TIMER) { timer_stop(TIMER); nrf_timer_task_trigger(TIMER, NRF_TIMER_TASK_CLEAR); nrf_timer_int_enable(TIMER, NRF_TIMER_INT_COMPARE0_MASK); nrf_timer_task_trigger(TIMER, NRF_TIMER_TASK_START); } static void timer_event_clear(NRF_TIMER_Type *TIMER) { nrf_timer_event_clear(TIMER, NRF_TIMER_EVENT_COMPARE0); } void tfm_secure_controller_secure_timer_start(void) { timer_init(NRF_TIMER1); timer_start(NRF_TIMER1); } void tfm_secure_controller_secure_timer_clear_intr(void) { timer_event_clear(NRF_TIMER1); } psa_flih_result_t tfm_timer1_irq_flih(void) { tfm_secure_controller_secure_timer_clear_intr(); interrupt_ctr++; return PSA_FLIH_SIGNAL; } static psa_status_t tfm_sp_secure_function_ipc(psa_msg_t *msg) { function_ctr++; LOG_INFFMT("Secure function called %u times, interrupt ctr: %u\n", function_ctr, interrupt_ctr ); return PSA_SUCCESS; } void tfm_sp_secure_function(psa_msg_t *msg) { psa_status_t status; status = tfm_sp_secure_function_ipc(msg); psa_reply(msg->handle, status); } void tfm_sp_entry(void) { LOG_INFFMT("Secure Partition: Init\n"); tfm_secure_controller_secure_timer_start(); psa_irq_enable(TFM_TIMER1_IRQ_SIGNAL); psa_signal_t signals = 0; uint32_t ctr = 0; while (1) { signals = psa_wait(TFM_TIMER1_IRQ_SIGNAL, PSA_BLOCK); if ( (signals & TFM_TIMER1_IRQ_SIGNAL) == TFM_TIMER1_IRQ_SIGNAL) { ctr++; LOG_INFFMT("FLIH stage 2 %u\n", interrupt_ctr); psa_reset_signal(TFM_TIMER1_IRQ_SIGNAL); } if ( ctr % 10 == 0 ) { signals = psa_wait(PSA_WAIT_ANY, PSA_POLL); if ( (signals & TFM_SECURE_FUNCTION_SIGNAL) == TFM_SECURE_FUNCTION_SIGNAL) { psa_msg_t msg; psa_get(signals, &msg); tfm_sp_secure_function(&msg); } } } }

4 years

2
8
0 0

New API tfm_hal_system_halt()

by Bøe, Sebastian

Hi, in the effort to ease debugging by supporting a choice between halting and rebooting we are introducing a new HAL API: void tfm_hal_system_halt(void) which by default (weak) does: __disable_irq(); while(1) { __WFE(); } CPUs cannot halt. But they can sleep until they are awoken in a loop, which is pretty close. tfm_hal_system_halt() is, when configured so, used by tfm_core_panic() which is why we disable irqs to stop all threads of execution, not just the thread that is executing. Currently it is proposed that tfm_core_panic() halts when TFM_HALT_ON_CORE_PANIC is ON and otherwise reboots. TFM_HALT_ON_CORE_PANIC is default ON if and only if Debug mode is enabled. Any feedback to these changes are welcome, and if any platform needs to halt in a different manner then a contribution would be welcome as well. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/13839

4 years

1
0
0 0

TF-M regression test refinements

by Jianliang Shen

Hi, all I'd like to share two new refinements in TF-M test repo to you. l The struct variable test_result_t has been removed from the definition of struct variable test_t. It is unnecessary to set an initial value of test result for each case. With this change, the binary size will be reduced. Please see [test patch]<https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/13822/4> for more details. l The flag TEST_SKIPPED has been added into enum variable test_status_t, works with TEST_PASSED and TEST_FAILED. TEST_SKIPPED indicates that the test case is skipped in runtime when the test environment is unavailable. Please ee [test patch]<https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/13826/5> for more details. Hope these two changes can help your work in the future. Please let me know if anything can be improved. Thanks! Best Regards Jianliang Shen

4 years

1
0
0 0

FF PSA API overhead

by Bøe, Sebastian

Hi, the performance improvement presentation[0] reports a FF PSA API overhead of 20 000 CPU cycles for the psa_call. Which is 300 us for a 64MHz CPU. This is quite a lot of instructions and I am concerned about whether real world embedded application's will have time to call these secure services. I'm interested in isolation level 2. I understand that it is not possible to have isolation level 2 with library mode. But what about SFN mode, could that eventually support isolation level 2? If not, what is the current status of optimizing the service call overhead for IPC. Is it considered to be as optimized as it can be or is there still hope for optimizing further? [0] https://www.trustedfirmware.org/docs/tf-m_forum_20211209-TF-M_Performance-I…

4 years

2
1
0 0

Technical Forum call - Feb 17

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, February 17, 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

4 years, 1 month

2
2
0 0

[FYI] Tiny update in level 3 ld/sct files

by Ken Liu

Hi, We got a tiny update merged in level 3 ld/sct files to support partition runtime: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/13925 Platforms with level 3 support please have a test and report issue here if spotted. We have internally tested MPS2 and MUSCA_B1. Thanks. /Ken

4 years, 1 month

1
0
0 0

halting or rebooting on faults

by Bøe, Sebastian

Hi, it seems we could try to be more consistent with fault handling. The current default behaviour is: Error code returned from an SPE function? Reboot. MemFault/HardFault/SecureFault in the SPE? Halt. Null-pointer dereference from the NSPE? (results in a secure fault for cortex-m) Halt. Should we perhaps consistently halt or consistently reboot for these three cases and allow this to be configurable? It is not clear to me why an error returned from a function results in a reboot, whereas a Hardfault does not. They both indicate a fault in the SPE. At the very least the behaviour should be configurable, which this PR is a step towards: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/13839

4 years, 1 month

5
4
0 0

Security vulnerability notice - Firmware Update psa_fwu_write service vulnerability

by Sherry Zhang

Hi all, This email is a notification of a new security vulnerability reported to TF-M. In TF-M version between 3e7129f<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/commit/?id=3e71…> and 921d0ea<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/commit/?id=921d…>, the caller of ``psa_fwu_write()`` from SPE or NSPE can overwrite the stack memory outside of the local buffer in Firmware Update partition in IPC model. Please check the details in the security advisory doc<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/13873/5/docs…>. The advisory has been merged in master branch today. The fix<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/commit/?id=78f7…> has been merged into master branch before TF-Mv1.5.0. Regards, Sherry Zhang

4 years, 1 month

1
0
0 0

Dual core broken

by Chris.Brand＠infineon.com

Commit 27f9a49508547320c50056a52a372674c27771eb seems to have missed changing ns_agent_mailbox, breaking dual core. I'd send a patch, but I's not immediately obvious what it should look like... Seems like a good change, but inadequately reviewed? Chris Brand Cypress Semiconductor (Canada), Inc. An Infineon Technologies Company Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com> International Place 13700 V6V 2X8 Richmond Canada www.infineon.com<www.cypress.com> www.cypress.com<http://www.cypress.com> Discoveries<http://www.infineon.com/discoveries> Facebook<http://www.facebook.com/infineon> Twitter<http://www.twitter.com/Infineon> LinkedIn<http://www.linkedin.com/company/infineon-technologies> Part of your life. Part of tomorrow. NOTICE: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material of Infineon Technologies AG and its affiliated entities which is for the exclusive use of the individual designated above as the recipient. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact immediately the sender by returning e-mail and delete the material from any computer. If you are not the specified recipient, you are hereby notified that all disclosure, reproduction, distribution or action taken on the basis of this message is prohibited.

4 years, 1 month

2
1
0 0

Why ARM_FLASH_STATUS is volatile in flash driver?

by Roman Mazurak

Hi all, Why ARM_FLASH_STATUS was declared volatile in https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/commit/platform… commit ? I believe it's much better to declare volatile variable when there is such need instead of forcing all variables to become volatile through typedef. Thanks, Roman.

4 years, 1 month

2
2
0 0

[CANCELLED] Technical Forum call - Feb 3

by Anton Komlev

Hi, Let's cancel the forum tomorrow due to the empty agenda and the holiday time in Asia. Best regards, Anton From: Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Thursday, January 27, 2022 4:36 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - Feb 3 Hi, The next Technical Forum is planned on Thursday, Feb 3, 7:00-8:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. This slot is in Chinese New Year celebration period so we can expect fewer participants from Asia. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

4 years, 1 month

1
0
0 0

Custom implementation of of tfm_hal_system_reset

by Bohdan.Hunko＠infineon.com

Hi everyone, I have a few questions related to TF-M code: 1. Default implementation of tfm_hal_system_reset(void) from platform/ext/common/tfm_platform.c<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…> just calls NVIC_SystemReset(), but some ARM platform, take musca_b1 for example, reimplement it (platform/ext/target/arm/musca_b1/sse_200/tfm_hal_platform.c<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…> ). Custom implementations tend to also disable and clean IRQ and call mpc_revert_non_secure_to_secure_cfg(); Is there any benefits of doing that??? If so then what those benefits are? 1. tfm_core_panic() (secure_fw/spm/ffm/utilities.c<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…>) when TFM_FIH_PROFILE_ON is defined calls fih_delay() and tfm_hal_system_reset() twice. Is this done to ensure that tfm_hal_system_reset() will be called (even if first one was skipped there is second one)? And if so, can a comment be added there to highlight that intention? Regards, Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>

4 years, 1 month

3
2
0 0

Technical Forum call - Feb 3

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, Feb 3, 7:00-8:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. This slot is in Chinese New Year celebration period so we can expect fewer participants from Asia. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

4 years, 1 month

1
0
0 0

Please Use Test Version Specified in TF-M CMake Configs

by Xinyu Zhang

Hi All, Please do use the tf-m-tests version specified in TF-M CMake configs (TFM_TEST_REPO_VERSION in trusted-firmware-m/lib/ext/tf-m-tests/repo_config_default.cmake), otherwise there might be some unexpected build errors. Please let us know if there is any problem. Thanks, Xinyu

4 years, 1 month

1
0
0 0

TF-M Open CI Back to Normal

by Xinyu Zhang

Hi All, TF-M Open CI is back to normal. Please feel free to use. Thanks, Xinyu From: Xinyu Zhang Sent: Monday, January 17, 2022 4:05 PM To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: TF-M Open CI Not Stable Right Now Hi All, Sorry to inform you that TF-M Open CI is not stable right now. Jobs are likely to come into unexpected failure. I'll keep following up with the latest information. Sorry for any inconvenience! Thanks, Xinyu

4 years, 1 month

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M