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
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
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…
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
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
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
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.
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
