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
Hi everyone,
When adding support for new platform we ran into an issue with BL2 variable.
In our architecture we have Bootloader based on MCUboot (aka BL2) but we are not planning to build it with TF-M.
Bootloader would be separate repo and be built separately.
So we need the way to build TF-M with FWU service and shared data definitions when BL2=OFF.
I was trying to add support for this but was not able to do this because build structure is quite complicated.
Does anyone have ideas or suggestions about the way we can implement this feature?
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,
The next Technical Forum is planned on Thursday, Sep 30, 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 everyone,
Being notified by some platform vendors that platforms build breaks in MASTER branch (releases are working well and not affected) due to not integrate with the latest HAL change:
The reference link: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11036
And these platforms reported build break:
Nordic
NXP
Because of bandwidth issues, we can’t maintain all the platform sources, hence require upstreamed platform owners to take a look at their platform builds and runs ok, and integrate with the updated HAL if it does fail.
Please reply to this thread if there are problems and I have created one ticket for tracking this if replying in a thread is more convenient for you:
https://developer.trustedfirmware.org/T967
Sorry for the inconvenience made, I should warn all the platform owners in earlier mails – I will validate the build again later in Oct to see if there are still platform breaks and contact the platform code owners to discuss plans.
Thanks.
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: Friday, September 17, 2021 3:06 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] [Request Platform Support] Abstracted MMIO HAL
The MMIO binding patch set are all merged, assume this will simplify the SPM integration much.
Follow up fixups will be created if missing comments reported.
Anyway, all platform patches are not blocked anymore, feel free to merge the reviewed and CI passed patches.
Thanks.
/Ken
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 3, 2021 1:27 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: Re: [TF-M] [Request Platform Support] Abstracted MMIO HAL
Hi,
Another reminder to mention the MMIO binding patches. Several platforms are changed to pass the CI, please platform owners to review the patches, such as:
PSOC: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11187
STM: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11186
Some of other platform patches are created as well.
This is a significant change for platform which helps much easier integration. After the first series of patches, the problems not covered by the CI need to be fixed adhoc.
Please read the tech forum topic on 2nd Sep for more details or you can just scroll down to check the previous content.
Thanks.
/Ken
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: Monday, August 30, 2021 5:18 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: Re: [TF-M] [Request Platform Support] Abstracted MMIO HAL
The patchset has updated and now CI passed okay:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11187
BR
/Ken
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: Thursday, August 19, 2021 2:16 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] [Request Platform Support] Abstracted MMIO HAL
Hi everyone,
The existing HAL interface for isolation hardware is not unified, we have to call several interfaces to setup isolation boundaries.
Hence, a deeper abstracted interface are provided. Here are the details:
- It assumes the hardware resources usages are decided by system designer. Hence there are couple of listed hardware data in the platform code, now most of them are defined in C sources.
- When a partition is referencing peripheral (represented as MMIO in FFM), the manifest tooling would link specified resources with the data defined in platform. Now it is using a naming pattern, to let the partition found the resources defined above (now it uses linker to do this).
- A HAL API 'tfm_hal_bind_partition' is called when a partition runtime structure is created. This API tells partition info to platform, let platform return an encoded 'p_boundaries' for SPM binding partition with platform.
- When boundaries related operations happen in future, SPM would delivery this 'p_boundaries' back to platform, let platform perform boundary setup and check, such as boundary switch or memory check. SPM won't care about the hardware specific settings any more, such as privilged, non-secure/secure and how many MMIO the partition claimed, even the MPU/MPC/PPC things.
- Resources defined in platform sources but not referenced would be stripped by toolchain flag. Resources not defined but referenced by partition would generate a linker error, as symbol can't be resolved.
We created a patch to showcase the usage on AN521:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11036
This patch applies a simple encoding for all isolation levels. You can check how the p_boundaries is used under different isolation levels. Platform can use other encoding mechanism if applicable.
Now come to the request:
Please review this patch, and port similar HAL API into your platform. We are maintaining the default platforms such as AN521, AN519 and MUSCA_B1, but it need so much effort on port to all the platforms.
Current CI cannot pass on this patch (as it contains modification for one platform only), our first goal is to let CI pass build on all checked platforms, and then please platform owner ensures it works on your platform.
Any feedbacks are welcome.
Thank you very much!
/Ken
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi all,
The goal of this proposal is to separate TF-M core and platform code to simplify development and support.
Take, for example, the Cypress PSoC 64 platform, we see that a significant amount of code can be committed into the repository.
For end user perspective, it doesn't seem logical that project source tree has a lot of irrelevant stuff. It complicates a performance of IDE, searching and analyzing a code.
Pros :
Platform support can be provided separately without the need to upgrade outdated platforms or problematic platforms :
https://lists.trustedfirmware.org/pipermail/tf-m/2021-January/001454.htmlhttps://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…
It should help to avoid or at least to minimize number of patches that requires fixes in platform folders :
https://lists.trustedfirmware.org/pipermail/tf-m/2019-April/000162.html
Reduces the amount of work for core team by delegating promotion of a new API support to vendors :
https://lists.trustedfirmware.org/pipermail/tf-m/2019-November/000506.html
Proposed solution :
There are other projects that face a similar situation, for example OpenWRT, Yocto, Android. Their common feature is that they have many dependencies. The solution they propose is based on the fact that these projects have their own build infrastructure. The user's task is to create a configuration in which you can add your own components.
In its current state, the TF-M already has some tools to implement platform as an external dependency. The user can specify the path to the platform using the TFM_PLATFORM variable. There is also work underway to implement support of external test infrastructure. (https://lists.trustedfirmware.org/pipermail/tf-m/2021-September/001824.html).
There is a need to add support of external secure partitions instead of current solution (https://tf-m-user-guide.trustedfirmware.org/docs/integration_guide/services…). I can't say if this issue is directly related to the platform, but it's possible that it will give more opportunities to vendors or will be a useful tool for adding new platforms.
The last question that needs to be addressed is how to link the sources supplied by vendors (platforms or security partitions) to the TF-M sources. Using the git submodule mechanism probably is not a good solution. There are two options :
1. Platforms, security partitions and test-suits will be listed as a submodule in the TF-M tree. But this approach will not actually solve the main problem of delegating more responsibility to vendors and breaking the connection between the vendors component and TF-M.
2. The TF-M source tree will be specified as a submodule in modules supplied by vendors. In this case we will have more problems. Because if the user's project will use two or more vendor components (for example, platform and custom security partitions), then TF-M will be mentioned more than once and it is quite possible to have several different revisions of TF-M. So, it will be impossible to properly assemble the project.
Therefore, I see the use of the following approach as an alternative :
1. External components check the TF-M version using the TFM_VERSION variable.
2. A project that uses TF-M, as well as the necessary components (platforms, external security partitions, vendor / project test suites) specifies dependencies using any method. The simplest way is to commit TF-M and vendor components as submodules in the user project.
3. Paths to all dependencies should be transferred from the project to necessary parts of TF-M via CMake variables.
This should be equally convenient for platforms vendors, TF-M components vendors, and TF-M end users.
Risks :
If the project assembled by end user will use several vendor modules (for example platform and custom security partitions). It is possible that the TF-M version required by different vendors modules will be different. But this problem is present at the moment, because any significant change to the TF-M API generates many problems that need to be solved for all supported platforms (mentioned in the pros).
Any feedbacks are welcome.
Best regards,
Roman
