Hi,
The next Technical Forum is planned on Thursday, Oct 14, 7:00-8: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
Hi all,
We need a mutex to protect access to a shared resource within Platform RoT Services. Is there any plan to add implementation of mutex in TF-M? Maybe it should be a platform specific implementation?
Thanks,
Roman.
Hi all,
In a discussion with Anton, it was realized that all contributors may not
be aware of some of the information available regarding Open CI.
If interested in digging deeper and understanding here are some helpful
links.
- The Open CI "mini-website" can be found here
<https://www.trustedfirmware.org/projects/open-ci/>.
- Note in the intro paragraph a hotlink to the *Open CI Lava farm*
showing the hardware platforms in the lab, recent test results,
etc. Note
it requires a login to see all the information
- Also of value is a detailed *users guide* that provides an overview
of Open CI. You can click on the "docs" icon or just go here
<https://tf-ci-users-guide.readthedocs.io/en/latest/>. It's a living
document and contributions are encouraged. :)
- This page also shares how to get further involved and the location
of the code.
Best regards,
Don
Hi all,
We would like to add a number of platform specific functions to Crypto Service API. Is it ok if such functions will not be related to cryptographic service, but such approach allows us to optimize platform design? Is there any initiative to create a Crypto Service HAL API to extend Crypto with custom functions?
Best regards,
Roman.
Hi everyone,
I am developing an App RoT for STM32L552 and testing the recent integrated
FLIH interrupt feature, but I am missing something in the step of
"Initializing the Interrupts" and "Integrating the Interrupt Handling
Function".
As is described in Secure Interrupt Integration Guide
<https://tf-m-user-guide.trustedfirmware.org/docs/integration_guide/tfm_secu…>,
to enable an interrupt it is needed:
1. Binding the interrupt to a Secure Partition.
2. Granting the Secure Partition access permissions to the device of the
interrupt.
3. Initializing the interrupt.
4. Integrating the interrupt handling function
Step *1 *and *2, * think that is "checked":
- by adding this code to the partition manifest file.
"mmio_regions": [
{
"name": "TFM_PERIPHERAL_TIMER7",
"permission": "READ-WRITE"
}
],
"irqs": [
{
"source": "TFM_TIMER7_IRQ",
"name": "TFM_TIMER7_IRQ",
"handling": "FLIH",
}
- By defining the macro with platform peripheral structure in
*patform/ext/target/stm/common/stm32l5xx/boards/tfm_peripherals_def.h*
extern struct platform_data_t timer7
#define TFM_PERIPHERAL_TIMER7 &timer7
- *By assign the peripheral address
in platform\ext\target\stm\common\stm32l5xx\secure\target_cfg.c*
struct platform_data_t timer7 = {
__TIMER7_BASE,
__TIMER7_BASE + 0x3FF,
-1,
-1
};
- By adding the peripheral name to “partition_named_mmio_list[]” in the
file *patform/ext/target/stm/common/stm32l5xx/boards/mmio_defs.h*
const uintptr_t partition_named_mmio_list[] = {
(uintptr_t)TFM_PERIPHERAL_TIMER0,
(uintptr_t)TFM_PERIPHERAL_STD_UART,
(uintptr_t) TFM_PERIPHERAL_TIMER7,
};
- And add to my partition code, the irq function, and the function to
configure the timer
psa_flih_result_t tfm_timer7_irq_flih(void)
{
....
}
static void flih_test_case_1(psa_msg_t *msg) {
psa_irq_enable(TFM_TIMER7_IRQ_SIGNAL);
timer_start();
.......
timer_stop();
psa_irq_disable(TFM_TIMER7_IRQ_SIGNAL);
psa_reply(msg->handle, PSA_SUCCESS);
}
My problem, I think, is with the other two steps, *3 *and *4. *The TF-M
documentation is not clear in these two steps.
In step *3, *as is said in the documentation it is needed: i) to configure
the interrupt priority; ii) to ensure that the interrupt targets the Secure
State. iii) and save the interrupt information. So I suppose it goes
something like this:
struct irq_t {
void *p_pt;
struct irq_load_info_t *p_ildi;
} save_tfm_timer7_irq_info;
enum tfm_hal_status_t tfm_timer7_irq_init(void *p_pt, struct
irq_load_info_t *p_ildi)
{
//targetting the interrupt to S state
NVIC_ClearTargetState(TIM7_IRQn);
NVIC_SetPriority(TIM7_IRQn, 1);
NVIC_EnableIRQ(TIM7_IRQn);
//Saving the Interrupt Information
save_tfm_timer7_irq_info.p_pt = p_pt;
save_tfm_timer7_irq_info.p_ildi = p_ildi;
return TFM_HAL_SUCCESS;
}
*But in which file should I put this function? And where should I call this
function??*
And in step *4, *I also do not understand how can I meet this requirement
-> "Platforms should call this entry function in the interrupt handlers
defined in Vector Table with the saved information for each interrupt."
Being the function in question -> *void spm_handle_interrupt(void *p_pt,
struct irq_load_info_t *p_ildi).*
*Which file can I do this in? And how should I do this step?*
Cheers,
Cristiano Rodrigues
Hi everyone,
IAS docs have this<https://tf-m-user-guide.trustedfirmware.org/docs/integration_guide/services…> note that says:
There is a size field tlv_len which has different definitions in the upstream MCUboot repository and in its TF-M forked version:
* Upstream MCUboot: Covers only the length of data but not the header size.
* TF-M MCUboot: Covers the size of the entry header and the data together.
This difference is handled by TF-M code based on which bootloader is used along with TF-M runtime.
I was wondering where in code is this difference handled?
When calculating next TLV entry address attest_core.c line 213<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…> takes into account SHARED_DATA_ENTRY_HEADER_SIZE:
tlv_curr = (*tlv_ptr) + SHARED_DATA_ENTRY_HEADER_SIZE + tlv_entry.tlv_len;
So tlv_entry.tlv_len then must cover only length of entry (without header). This way corresponds to: "Upstream MCUboot: Covers only the length of data but not the header size"
I was not able to find anything related to "TF-M MCUboot: Covers the size of the entry header and the data together".
Is this difference handled in TF-M fork of MCUboot or is it just outdated IAS doc?
Best 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>
Hi,
We've been investigating a problem with the armclang builds for PSoC. The symptoms are that the board just repeatedly reboots.
We've narrowed it down to commit 300c68da11 "SPM: Use Main Stack for initialization". This commit is fine with the gcc toolchain but doesn't seem right for armclang (we haven't yet looked at IAR).
Still digging into the issue, but I figured it might be helpful to give it more publicity.
Chris Brand
Cypress Semiconductor (Canada), Inc.
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>
While verifying that my Musca B1/S1 fixes for IAR did not break other
targets I ran into building problems for the nxp/lpcxpresso55s69 for
both gnuarm and iararm.
I've tested with the following cmake line:
cmake -GNinja -S .. -B . -DTFM_PLATFORM=nxp/lpcxpresso55s69
"-DTFM_TOOLCHAIN_FILE=..\toolchain_GNUARM.cmake" -DTEST_NS=ON
-DTEST_S=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo -DTFM_PSA_API=ON -DBL2=OFF
Fails with:
d:/apps/gnuarm/10-2020-q4-major/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld.exe:
C:\Users\thomasto\Projects\tf-m12\trusted-firmware-m\gnuarm/../secure_fw/spm/ffm/psa_api.c:890:
undefined reference to `tfm_hal_irq_disable'
I notice that tfm_hal_irq_disable() is guarded by:
#if TFM_LVL == 3
in .../nxp/common/tfm_hal_isolation.c, while the other targets does not
have this guard. What isthe reason for that? Trying to set that with
cmake causes other failures.
commit 8444011d works
commit 4051016f fails
I tried bisecting between these two commits, but the builds run into
other build failures so I gave up on that.
Is his a known issue?
I have successfully built and run regression tests on musca b1, musca
s1, psoc64 and I have built, but not run an519, an521, an524
Cheers,
Thomas
--
*Thomas Törnblom*, /Product Engineer/
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com>
Website: www.iar.com <http://www.iar.com>
Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
Dear platform owners,
Theses interrupt binding patch(es) are merged:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11474
As the most part of the change happen in platform, please report platform integration if you met.
Sorry I had thought the notification mail has been sent during the PR stage but it did not, hence it is not broadcasted in time.
Current there are build errors reported on nxp/nordic platforms, and this patch should fix the problem:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11741
Also, Ci reported arch-test build fail, hence the fix for arch-test is here:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11742
Feel free to put comments and I will update them later, or just update the patch if it is quick for you, add your name into the author in commit message. You also can create standalone patches if you change is not covered by mentioned patches.
Thanks.
/Ken
