This commit adds initial support for non secure nRF7120 targets in
zephyr.
There are important limitations, such as:
- The hardware Crypto accelerator is not supported and thus the non
secure target is NOT secure for production applications in upstream
Zephyr.
- The BL2 is not supported, so no DFU is supported with this support
Signed-off-by: Robert Robinson <robert.robinson@nordicsemi.no>
Added MCNX947 support in trusted-firmware-m
module Cmake and Kconfig. Cmake is cleaned,
removed unused variables.
Signed-off-by: Guido Roncarolo <guido.roncarolo@nxp.com>
Add support for building Trusted Firmware-M (TF-M) non-secure
applications for the STM32H573I-DK board.
Signed-off-by: Tim Pambor <tim.pambor@codewrights.de>
Zephyr generates the system call headers using CMake custom
targets and various scripts. Some platforms, like the Nordic onces,
reuse some files located in Zephyr inside the TF-M build as well.
Because of this the generated Zephyr headers needs to exist before
TF-M starts the build process in order to succeed.
This adds a dependency to make sure TF-M starts building after the
Zephyr custom command which generates the system call headers is
executed.
Signed-off-by: Georgios Vasilakis <georgios.vasilakis@nordicsemi.no>
If the image is not confirmed, there is no need to pad the entire flash
slot with empty data. This reduces the size of
`tfm_s_zephyr_ns.signed.bin` (the file actually sent for an OTA upgrade)
from 100% of the slot size down to the size of the application.
Signed-off-by: Jordan Yates <jordan@embeint.com>
New nrfx release contains major rework of nrfx drivers
instantiation making it easier to integrate with dts nodes.
Now, nrfx driver instances can no longer be `const`
because they contain driver runtime state.
Additionally, all nrfx drivers return `errno` error codes
instead of deprecated `nrfx_err_t`.
Signed-off-by: Nikodem Kastelik <nikodem.kastelik@nordicsemi.no>
Explicitly disable the SECURE_UART TFM define when
`CONFIG_TFM_LOG_LEVEL_SILENCE=y`. The secure UART is only enabled by
default on nRF platforms to match the current TF-M defaults.
Signed-off-by: Jordan Yates <jordan@embeint.com>
Since `tfm_merged.bin` now contains BL2, it can only be used for the
same purposes as `tfm_merged.hex` (intial firmware loading). Therefore
it should be using the confirmed images that `tfm_merged.hex` does.
Since the only difference between the two files with that change is now
the output format, we can directly generate `tfm_merged.bin` from
`tfm_merged.hex` with `objcopy` instead of going through `mergehex.py`.
Signed-off-by: Jordan Yates <jordan@embeint.com>
Generate a binary version of `tfm_s_zephyr_ns_signed.hex` with objcopy.
This file is valid for performing OTA upgrades, unlike `tfm_merged.bin`,
which contains BL2.
Signed-off-by: Jordan Yates <jordan@embeint.com>
`S_NS_CONFIRMED_HEX_FILE` was never generating a confirmed file, just
the same file contents as `S_NS_HEX_FILE`. Since no logic needs a
confirmed merge of `tfm_s.hex` and `zephyr.hex`, just remove the logic
instead of fixing it.
Signed-off-by: Jordan Yates <jordan@embeint.com>
When CONFIG_TFM_MCUBOOT_IMAGE_NUMBER is 1, all images are merged.
Currently, there is no tfm_merged.bin file for use in FOTA. This
adds file generation to fulfill that requirement.
Signed-off-by: BUDKE Gerson Fernando <gerson.budke@leica-geosystems.com>
When CONFIG_TFM_MCUBOOT_IMAGE_NUMBER is 1, the process to create the
final tfm_merged.bin file is more complex. This prepares the content
to introduce the generation of tfm_merged.bin for use in FOTA
applications.
Signed-off-by: BUDKE Gerson Fernando <gerson.budke@leica-geosystems.com>
Use cmake_parse_arguments() for more idiomatic code. This makes the
code more readable and easier to extend with new options.
Signed-off-by: BUDKE Gerson Fernando <gerson.budke@leica-geosystems.com>
A fundamental use of Trusted Firmware-M is to provide security for
IoT applications, where firmware upgrades (FOTA) are almost always
mandatory. The current file signing process does not produce the
necessary binaries for multi-image S/NS FWU, since hex images are
not suitable for this use case. This introduces the missing signed
binary files for use by the FWU partition. The changes were tested
in multi-image FWU scenarios, and support for single-image scenarios
can be easily added in the future.
Signed-off-by: BUDKE Gerson Fernando <gerson.budke@leica-geosystems.com>
Make variables that define output files explicitly include 'HEX' in the
name. This refactoring step allows for the introduction of BIN file
generation.
Signed-off-by: BUDKE Gerson Fernando <gerson.budke@leica-geosystems.com>
The current behavior when signing an image adds --pad but does not
confirm the image. This appears to be a mistake, as the user should
inspect the image status in the Firmware Upgrade software. If an image
is not --confirmed, the FSM cannot infer the correct states. This sets
the image as confirmed to resolve the issue.
Signed-off-by: BUDKE Gerson Fernando <gerson.budke@leica-geosystems.com>
The current behavior when signing an image is to always set --pad and
--pad-header for all images unless TFM_USE_NS_APP is set. This does not
allow for easy creation of signed images for FOTA applications. Rewrite
the PAD parameter as HEADER and TRAILER to simplify the setup of more
signing options.
Another important reason for this change is that the NS image, when
signed without --pad, runs on the hardware but does not perform the
MCUboot test, and the FWU never upgrades the image. This fixes the NS
image signing process to correctly support TF-M FWU using the PSA API
functions.
Signed-off-by: BUDKE Gerson Fernando <gerson.budke@leica-geosystems.com>
The --max-sectors option helps catch problems with flash overlap when
merging images. If there is a misalignment in flash partitions, the
merge process usually fails. This uses information from Zephyr flash
partitions and the flash controller to automatically determine the
max sectors value and apply it when signing an image.
Signed-off-by: BUDKE Gerson Fernando <gerson.budke@leica-geosystems.com>
The current version of TF-M script that sign MCUboot image uses a
default alignment of 1. This value varies between flash devices
and not all accept the default 1. This improve the script picking
the write-block-size property from the current flash controller
and pass as the --align parameter when signing an image.
Note: This solution works out-of-box for the vast majority of
devices in the Zephyr tree and an exception will throw when
a device is not supported.
Signed-off-by: BUDKE Gerson Fernando <gerson.budke@leica-geosystems.com>
Removes two Kconfig which seemed to indicate downloading of a
project would happen automatically, which does not abide by how
to get additional module code in Zephyr. Due to TF-M always setting
these to "DOWNLOAD" in the repo, they are set even if the modules
do not exist so that they do not download e.g. in CI. Unfortunately
it seems that the qcbor one cannot be removed at this time due to
being needed in some applications and is not apache licensed,
though instructions should be provided to users instead describing
how to add it to a module manifest instead, in a later task
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Add board files for nRF54LM20A/ns.
Update existing nRF54LM20A board files to support this.
Signed-off-by: Dag Erik Gjørvad <dag.erik.gjorvad@nordicsemi.no>
Add TF-M directive STM32_FLASH_LAYOUT_BEGIN_OFFSET needed to specify
the gap needed by external boot stage resources at flash beginning.
The offset tells STM32 TF-M firmware the base offset in the flash
where the several TF-M and non-secure image areas shall be located.
The CMake directive was introduced mainline TF-M commit [1] and merged
in Zephyr TF-M repository [2].
Link: fc035b874e [1]
Link: 954dc80541 [2]
Signed-off-by: Etienne Carriere <etienne.carriere@st.com>
Declare stm32wba65i-dk1 and nucleo_wba65ri boards support in TF-M.
Both comply with TF-M integration of platform stm/stm32wba65i-dk.
Signed-off-by: Etienne Carriere <etienne.carriere@st.com>
Zephyr's TF-M has been aligned with upstream TF-M v2.2.0, which adds
support for Corstone-320 (CS320). The previous commit also updates TF-M
to fix compiler warnings seen with MPS4. So, with this update, enable
build and execution of non-secure variants of MPS4-based boards.
Signed-off-by: Sudan Landge <sudan.landge@arm.com>
Following changes to arch/arm/core/cortex_m/fpu.c,
the dependency on CONFIG_FPU_SHARING is moved into this file.
Signed-off-by: Michele Sardo <michele.sardo@st.com>
Utilize a code spell-checking tool to scan for and correct spelling errors
in `Kconfig` files within the `arch`, `boards`, `kernel`, `modules`,
`samples`, and `share` directory.
Additionally, incorporates a fix recommended by the reviewer.
Signed-off-by: Pisit Sawangvonganan <pisit@ndrsolution.com>
Support for list of images in build info was added with commit
4061311da3 and is used by sysbuild.
Zephyr itself also uses CMake's External Project feature when including
TF-M or TF-A in a Zephyr build.
Populate build info with TF-M / TF-A information when said image is
included in the build.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
What is the change?
Fix the path for module CMSIS_6 and use CMSIS_6 module for TF-M.
Why do we need this change?
After Zephyr updated TF-M to v2.1.0,
bb037d4469842c96f5872b271490aceb0734d965 added a local copy of CMSIS_6
to stop Zephyr's TF-M from downloading the CMSIS_6 from upstream.
The correct way would be to have CMSIS_6 as a module in Zephyr (which
we have now) and pass the path of this module to TF-M.
A fork of the upstream CMSIS_6 was added to Zephyr however,
the path in west.yml makes it a lib and not a module.
Fixing the path generates the ZEPHYR_CMSIS_6_MODULE_DIR symbol which
can now be used to pass to TF-M and the copy in TF-M would no longer be
required.
Signed-off-by: Sudan Landge <sudan.landge@arm.com>
This adds the nrf54l15dk/nrf54l10/cpuapp/ns board variant to
Zephyr. It allows to build applications for this target.
This is an initial support for the non secure target which allows
building and running tfm_ipc and config_build.
This is NOT full support of the non secure target in upstream
Zephyr.
There are important limitations, such as:
- The hardware Crypto accelerator is not supported and thus the non
secur target is NOT secure for production applications in upstream
Zephyr.
- The BL2 is not supported, so no DFU is supported with this support
Most of the code changes here are taken from nRF Connect SDK
in order to avoid having noups there.
Signed-off-by: Georgios Vasilakis <georgios.vasilakis@nordicsemi.no>
Update the header to include a generic header for the NRF54L
series and not a specific one for the NRF54L15.
Signed-off-by: Georgios Vasilakis <georgios.vasilakis@nordicsemi.no>
This adds the nrf54l15dk/nrf54l15/cpuapp/ns board variant to
Zephyr. It allows to build applications for this target.
This is an initial support for the non secure target which allows
building and running tfm_ipc and config_build.
This is NOT full support of the non secure target in upstream
Zephyr.
There are important limitations, such as:
- The hardware Crypto accelerator is not supported and thus the non
secur target is NOT secure for production applicatiions in upstream
Zephyr.
- The BL2 is not supported, so no DFU is supported with this support
Most of the code chagnes here are taken from nRF Connect SDK
in order to avoid having noups there.
Signed-off-by: Georgios Vasilakis <georgios.vasilakis@nordicsemi.no>
If CONFIG_TFM_BL1 config has been enabled
bl2_signed.bin/hex image will be be generated during build tf-m
these binaries shall be used while generating tfm_merged.hex
Signed-off-by: Sadik Ozer <sadik.ozer@analog.com>
Define BL1 and sign key for BL2 configs and pass them to the TF-M
This will allow to trigger BL1 over zephyr and specify BL2 sign key
Signed-off-by: Sadik Ozer <sadik.ozer@analog.com>
This is to fix the below compiler warning from TF-M builds
that don't use the Ethos-U driver.
```
CMake Warning:
Manually-specified variables were not used by the project:
ETHOS_DRIVER_PATH
```
Signed-off-by: Sudan Landge <sudan.landge@arm.com>
What is changed?
- Use the updated TF-M that is compatible with the Zephyr's
latest Ethos-U driver repo.
- Change the default behavior of TF-M builds to use Ethos driver
locally fetched by Zephyr, using west update, instead of
downloading it from external repo.
Why is this change required?
- This is to be inline with Zephyr's rules to not fetch code from
external repo.
Fixes#81656
Signed-off-by: Sudan Landge <sudan.landge@arm.com>
This commit removes the TF-M support for the `xtools` toolchain variant,
which has been deprecated since Zephyr v3.3.0 and now removed.
Note that `zephyr` toolchain variant must be used instead of `xtools` when
building with Zephyr SDK.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
What is changed?
- Added a new mps3 board an555 for the soc corstone310.
The qualifier to build/run application with board mps3/an555 is
`mps3/corstone310/an555` for secure and
`mps3/corstone310/an555/ns` for non-secure.
- Added FVP variant to enable FVP testing with corstone310
and it uses the ARM FVP `FVP_Corstone_SSE-310`.
The qualifier to build/run application with FVP is
`mps3/corstone310/an555fvp` for secure and
`mps3/corstone310/an555fvp/ns` for non-secure.
Why do we need this change?
- This enables FVP support and testing for corstone310.
- A separate FVP variant was added for AN555 because, the TFM board
used for non-secure variant differs for FPGA and FVP.
TFM board `arm/mps3/corstone310/an555` should be used when testing
AN555 with FVP and `arm/mps3/corstone310/fvp` should be used when
testing with AN555 FPGA.
Signed-off-by: Sudan Landge <sudan.landge@arm.com>
What is changed?
- Added a new mps3 board an552 for the soc corstone300.
The qualifier to build/run application with board mps3/an552 is
`mps3/corstone300/an552` for secure and
`mps3/corstone300/an552/ns` for non-secure.
- Added FVP variant to enable FVP testing with corstone300
and it uses the ARM FVP `FVP_Corstone_SSE-300_Ethos-U55`.
The qualifier to build/run application with FVP is
`mps3/corstone300/fvp` for secure and
`mps3/corstone300/fvp/ns` for non-secure.
- Note: the qualifier to build/run application with board mps3/an547
is now changed to
`mps3/corstone300/an547` for secure and
`mps3/corstone300/an547/ns` for non-secure.
How is it changed?
- Moved common code from mps3/an547 to corstone300.
- Renamed soc for an547 to corstone300 and added
a new soc corstone300/an552.
Why do we need this change?
- This enables FVP support and testing for corstone300.
- SOC/qualifier for mps3/an547 was renamed to reduce code redundancy
- A separate FVP variant was added for AN552 because, the TFM board
used for non-secure variant differs for FPGA and FVP.
TFM board `arm/mps3/corstone300/fvp` should be used when testing
AN552 with FVP and `arm/mps3/corstone300/an552` should be used when
testing with AN552 FPGA.
Signed-off-by: Sudan Landge <sudan.landge@arm.com>
Don't attempt to take a mutex if operating from inside an ISR. The only
expected use-case where this should occur is when attempting to reboot
via `tfm_platform_system_reset` from an exception handler.
Fixes#79687.
Signed-off-by: Jordan Yates <jordan@embeint.com>
By default, TFM enables hardware rollback protection, which requires a
security counter to be embedded in the image trailer. The default
behaviour of constructing this counter from the image version breaks the
TFM `boot_nv_security_counter_update` implementation once the version
number is greater than `0.0.1024`. As such, explicitly specify the
desired security counter value. As per the MCUboot docs, this does not
need to be incremented on every firmware update.
Signed-off-by: Jordan Yates <jordan@embeint.com>
