FYI to all TF dev teams leveraging Open CI.
Best regards,
Don
---------- Forwarded message ---------
From: Glen Valante via Tf-openci-triage <
tf-openci-triage(a)lists.trustedfirmware.org>
Date: Fri, 23 Jun 2023 at 08:41
Subject: [Tf-openci-triage] FYI; Cambridge Lab Down
To: tf-openci-triage(a)lists.trustedfirmware.org <
tf-openci-triage(a)lists.trustedfirmware.org>
Hello All;
FYI; the Cambridge lab took a serious power hit and is down. They are
scrambling to get things back up, but it may take all weekend.
Expect LAVA failures and other strange results.
Thanks;
-g
--
[image: Linaro] <http://www.linaro.org>
Glen Valante | *Director Program & Project Management*
T: +1.508.517.3461 <1617-320-5000>
glen.valante(a)linaro.org | Skype: gvalante <callto:gvalante>
--
Tf-openci-triage mailing list -- tf-openci-triage(a)lists.trustedfirmware.org
To unsubscribe send an email to
tf-openci-triage-leave(a)lists.trustedfirmware.org
Hi all,
I am currently trying out TF-M together with Zephyr and therefore ported it to the Nucleo-U575ZI-Q evaluation board. I started to struggle when trying to implement an example for a custom Secure Partition (SP) which should access peripherals.
I recognized, that the `target_cfg.*` throughout different vendors follow different design principles. E.g. for Nordic controllers an example is given with their nordic-sdk on how to implement peripheral access for a SP (https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.0.0/nrf/samples/tfm/…). For ST devices I tried to transfer this, however, where unsuccessful so far as for the ST microcontrollers the peripheral definitions are missing, and things are just different.
Is there any example for ST controllers on how to make specific peripherals only accessible through SPE? Is this currently supported for ST devices?
And another question, as the Embedded Open Source Summit arises, is TF-M represented somewhere on conferences?
Kind Regards
Christian Spinnler
Siemens AG
Technology
Connectivity & Edge
T CED SSI-DE
Schuckertstrasse 2
91058 Erlangen, Deutschland
mailto:christian.spinnler@siemens.com
www.siemens.com<https://siemens.com>
Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Jim Hagemann Snabe; Vorstand: Roland Busch, Vorsitzender; Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, Judith Wiese; Sitz der Gesellschaft: Berlin und München, Deutschland; Registergericht: Berlin-Charlottenburg, HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322
Hi all,
In GCC linker scripts ands of sections are aligned using following syntax:
. = ALIGN(TFM_LINKER_XXX_ALIGNMENT);
But in ARMClang TFM does not use similar approach, instead it creates Position tags sections like following:
TFM_APP_CODE_START +0 ALIGN TFM_LINKER_APP_ROT_LINKER_CODE_ALIGNMENT EMPTY 0x0 {
}
TFM_APP_ROT_LINKER +0 ALIGN TFM_LINKER_APP_ROT_LINKER_CODE_ALIGNMENT {
*tfm_app_rot_partition* (+RO-CODE, +RO-DATA)
*libplatform_s* (TFM_*_APP-ROT_ATTR_FN)
*.o (TFM_*_APP-ROT_ATTR_FN)
}
/*
* This empty, zero long execution region is here to mark the end address
* of APP RoT code.
*/
TFM_APP_CODE_END +0 ALIGN TFM_LINKER_APP_ROT_LINKER_CODE_ALIGNMENT EMPTY 0x0 {
}
I believe this is done because clang does not have syntaxes for aligning end of the section (please correct me if I am wrong).
This approach results in bug in TFM_UNPRIV_CODE section protections, because TFM_UNPRIV_CODE Base and Limit are used directly and Limit is not aligned.
For now this problem stayed undetected because present platforms does not validate region_limit when applying protections.
I have created this patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/21169> , which adds validation of region_limit and ran Ci on it and I can see that CI failed in tests for Clang builds
So I guess this is the problem that have to be fixed. I see following possible solutions:
1. Align and of TFM_UNPRIV_CODE section (but I guess clang does not support that)
2. Add position tags for _START and END
Solution 1 will simpler as it will not require changed in platform code, but I guess clang syntaxes is limiting us here.
So my question would be whether there is a plan to fix this issue ?
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 all.
I am trying to port TFM using the corstone1000 platform.
Previously, I was using the 1.7.0 version.
TFM version was recently updated and I am trying to use the 1.8.0 version
by downloading it from the site below.
https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git
As instructed by the site below
(
https://tf-m-user-guide.trustedfirmware.org/platform/arm/corstone1000/readm…
)
I executed the command below.
cmake -B build/ -S . -DCMAKE_BUILD_TYPE=Debug
-DTFM_TOOLCHAIN_FILE=<tf-m-root>/toolchain_GNUARM. cmake
-DTFM_PLATFORM=arm/corstone1000 -DTEST_NS=OFF -DTEST_S=ON -DTEST_S_PS=OFF
-DTEST_S_PLATFORM=OFF
-DEXTRA_S_TEST_SUITE_PATH=platform/ext/target/arm/corstone1000/ci_regression_tests/
However, I got a cmake error as shown below.
- Build type: Debug
-- Host: Linux/x86_64
-- Target: Generic/arm
-- Machine: template
-- Host: Linux/x86_64
-- Target: Generic/arm
-- Machine: template
-- C_FLAGS : -mcpu=cortex-m0plus -Wall -Wextra
CMake Error at platform/ext/target/arm/corstone1000/CMakeLists.txt:144
(target_sources):
Cannot specify sources for target "platform_bl1" which is not built by
this
project.
CMake Error at platform/ext/target/arm/corstone1000/CMakeLists.txt:168
(target_compile_definitions):
Cannot specify compile definitions for target "platform_bl1" which is not
built by this project.
CMake Error at platform/ext/target/arm/corstone1000/CMakeLists.txt:175
(target_include_directories):
Cannot specify include directories for target "platform_bl1_interface"
which is not built by this project.
I think this is caused by the target for platform_bl1 not being specified,
but I don't know how to fix it.
I executed cmake using the same configuration as set in corstone1000's
config.cmake.
Can anyone tell me why I am getting the above error?
Any advice would be very helpful.
thanks you.
Hi all.
I am trying to port TFM using the corstone1000 platform.
Previously, I was using the 1.7.0 version.
TFM version was recently updated and I am trying to use the 1.8.0 version by downloading it from the site below.
https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git
As instructed by the site below
(https://tf-m-user-guide.trustedfirmware.org/platform/arm/corstone1000/readm…)
I executed the command below.
cmake -B build/ -S . -DCMAKE_BUILD_TYPE=Debug -DTFM_TOOLCHAIN_FILE=<tf-m-root>/toolchain_GNUARM. cmake -DTFM_PLATFORM=arm/corstone1000 -DTEST_NS=OFF -DTEST_S=ON -DTEST_S_PS=OFF -DTEST_S_PLATFORM=OFF -DEXTRA_S_TEST_SUITE_PATH=platform/ext/target/arm/corstone1000/ci_regression_tests/
However, I got a cmake error as shown below.
- Build type: Debug
-- Host: Linux/x86_64
-- Target: Generic/arm
-- Machine: template
-- Host: Linux/x86_64
-- Target: Generic/arm
-- Machine: template
-- C_FLAGS : -mcpu=cortex-m0plus -Wall -Wextra
CMake Error at platform/ext/target/arm/corstone1000/CMakeLists.txt:144 (target_sources):
Cannot specify sources for target "platform_bl1" which is not built by this
project.
CMake Error at platform/ext/target/arm/corstone1000/CMakeLists.txt:168 (target_compile_definitions):
Cannot specify compile definitions for target "platform_bl1" which is not
built by this project.
CMake Error at platform/ext/target/arm/corstone1000/CMakeLists.txt:175 (target_include_directories):
Cannot specify include directories for target "platform_bl1_interface"
which is not built by this project.
I think this is caused by the target for platform_bl1 not being specified, but I don't know how to fix it.
I executed cmake using the same configuration as set in corstone1000's config.cmake.
Can anyone tell me why I am getting the above error?
Any advice would be very helpful.
thanks you.
Hi all.
I am trying to port TFM using the corstone1000 platform.
Previously, I was using the 1.7.0 version.
TFM version was recently updated and I am trying to use the 1.8.0 version by downloading it from the site below.
https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git
As instructed by the site below
(https://tf-m-user-guide.trustedfirmware.org/platform/arm/corstone1000/readm…)
I executed the command below.
cmake -B build/ -S . -DCMAKE_BUILD_TYPE=Debug -DTFM_TOOLCHAIN_FILE=<tf-m-root>/toolchain_GNUARM. cmake -DTFM_PLATFORM=arm/corstone1000 -DTEST_NS=OFF -DTEST_S=ON -DTEST_S_PS=OFF -DTEST_S_PLATFORM=OFF -DEXTRA_S_TEST_SUITE_PATH=platform/ext/target/arm/corstone1000/ci_regression_tests/
However, I got a cmake error as shown below.
- Build type: Debug
-- Host: Linux/x86_64
-- Target: Generic/arm
-- Machine: template
-- Host: Linux/x86_64
-- Target: Generic/arm
-- Machine: template
-- C_FLAGS : -mcpu=cortex-m0plus -Wall -Wextra
CMake Error at platform/ext/target/arm/corstone1000/CMakeLists.txt:144 (target_sources):
Cannot specify sources for target "platform_bl1" which is not built by this
project.
CMake Error at platform/ext/target/arm/corstone1000/CMakeLists.txt:168 (target_compile_definitions):
Cannot specify compile definitions for target "platform_bl1" which is not
built by this project.
CMake Error at platform/ext/target/arm/corstone1000/CMakeLists.txt:175 (target_include_directories):
Cannot specify include directories for target "platform_bl1_interface"
which is not built by this project.
I think this is caused by the target for platform_bl1 not being specified, but I don't know how to fix it.
I executed cmake using the same configuration as set in corstone1000's config.cmake.
Can anyone tell me why I am getting the above error?
Any advice would be very helpful.
thanks you.
Hi
For our platform we use some ,across which should set/clear bit 28 of an address (see code below). We do this for convenience reasons.
#define IFX_S_ADDRESS_ALIAS(x) ((x) | 0x10000000)
#define IFX_NS_ADDRESS_ALIAS(x) ((x) & ~0x10000000)
Those macros are used in declaration of S_CODE_START macro. When expended in linker script (tfm_isolation_l3.o), the declaration of LR_CODE section looks as follows:
LR_CODE (0x24000000 | 0x10000000) (0x4B000) {
This code results in following error:
tfm_isolation_l3.o", line 46 (column 21): Error: L6292E: Ignoring unknown attribute '|' specified for region LR_CODE.
I tried experimenting with this and found out that when | is changed to or (see following code) then linker works fine:
LR_CODE (0x24000000 or 0x10000000) (0x4B000) {
Same problem is present when using bitwise and (&). But when using bitwise NOT (~0x...) everything works fine.
Having to define our macros in different way brings some problems for our platform, so maybe someone knows how to solve this problem? Maybe there are compilation flags or something like that? Ideally we want | and & to work fine in linker script.
Thanks!
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!
I found the e-mail below from 2020 and this is exactly where I'm at right now:
I have a Zephyr application with TF-M flashed on an nrf9160dk and managed to open a debugging session following the explanation here: https://tf-m-user-guide.trustedfirmware.org/platform/nxp/lpcxpresso55s69/RE… (might be good to mention in the documentation that this also works on other platforms or have a general "Debug with GDB section").
So far I can either debug the secure image or or the non-secure image, but I would actually like to see the communication between the two. Is it even possible to debug across the boundary?
I'm not very experienced in using GDB (except for the basics). Is there some kind of TF-M specific tutorial or explanation by now? Or is there anyone who can give me a hint on how to do this?
Kind regards,
Lena
Kevin Townsend wrote:
> Hi Anton,
> One particular difficulty I've encountered working with TF-M for the Zephyr
> certification demo app, and with the LPC55S69 port to upstream TF-M is the
> debugging experience with GDB and the dual execution environments. GDB can
> be quite powerful if you are familiar with it, but there is a definite
> learning curve, and the S and NS separation and the dual binary images
> (three with BL2) adds an additional degree of complexity.
> I think having a dedicated debugging tutorial around GDB would be very
> useful to people adopting TF-M and perhaps new to GDB, just to show how
> some basic debugging might happen, how to debug across the NS/S boundary,
> etc.
> For example, the '--tui' option for GDB may not be very well known, and it
> may be useful to highlight (see screenshots at the bottom of this issue:
> https://github.com/microbuilder/trusted-firmware-m/issues/1)
> Practical, step-by-step debugging documentation just seems like a good
> investment to help flatten this inevitable learning curve developing
> real-world solutions with TF-M?
> Best regards,
> Kevin
> On Thu, 27 Feb 2020 at 13:13, Anton Komlev via TF-M <
> tf-m(a)lists.trustedfirmware.org> wrote:
> > A kind reminder.
> > Your feedback is valuable all the time with no deadline defined.
> > *From:* TF-M tf-m-bounces(a)lists.trustedfirmware.org * On Behalf Of *Anton
> > Komlev via TF-M
> > *Sent:* 07 February 2020 13:13
> > *To:* tf-m(a)lists.trustedfirmware.org
> > *Cc:* nd nd(a)arm.com
> > *Subject:* [TF-M] Call for a feedback on TF-M adaptation experience
> > Dear All,
> > As I mentioned on yesterday’s call, there is a concern on user experience
> > related to TF-M use.
> > To In order to understand and potentially improve it I am looking for a
> > voice of partners who adopted TF-M project.
> > Please share your experience and thoughts on parts which are good or might
> > be done better to simplify TF-M integration with your project.
> > You feedback will be very appreciated in any form – as a response to this
> > mail or as a direct mail to me (anton.komlev(a)arm.com) if it’s more
> > comfortable for you.
> > Thank you in advance,
> > Anton
> > TF-M mailing list
> > TF-M(a)lists.trustedfirmware.org
> > https://lists.trustedfirmware.org/mailman/listinfo/tf-m
> >
Hi,
Using isolation level 1 and IPC secure partition, I noticed psa_call() overhead for TFM v1.7 is significantly worse for than v1.1. Is this expected?
Assuming 1 invec and 0 outvec for the PSA call....
TF-M version
Psa_call() round trip cycles
v1.1
4038
v1.7
6051
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
