boards: mps4: Enable non-secure variant support #95105
Conversation
Zephyr's TF-M has been aligned with upstream TF-M v2.2.0, which includes Corstone-320 (CS320) support so, enable build and execution of non-secure variants of MPS4-based boards. Note that the testing is disabled by default for these boards because TF-M builds with a few warnings and they need to be fixed for twister to pass the ci. Signed-off-by: Sudan Landge <[email protected]>
What is the change? Split and redefine the DDR4 device tree nodes, in their respective board variants so that linker scripts automatically generates a memory section for each node. Why do we need this change? According to the official memory map of Corstone-320 available here: https://developer.arm.com/documentation/109760/0000/SSE-320-FVP/SSE-320-FVP-memory-map the non-secure world alias of DDR4 starts at 0x6000_0000 and the secure world alias starts at 0x7000_0000. Previously, the shared DDR4 node in mps4_common.dtsi listed multiple regions, but Zephyr generated a linker memory region **only** for the first address (0x6000_0000). This broke samples like `tflm_ethosu`, on Corstone-320, which expect DDR4 memory region to start at 0x7000_0000 for secure variants of the MPS4 board. Moving DDR4 definitions to per-board dts files ensures Zephyr creates correct memory regions for each variant. This also makes all the DDR4 regions available for applications to use not just the first (applications would otherwise have to use some linker magic to make those regions available in linker script). Signed-off-by: Sudan Landge <[email protected]>
zephyrbot
added
area: TF-M
zephyrbot
requested review from
d3zd3z,
ithinuel,
tomi-font,
valeriosetti and
Vge0rge
There was a problem hiding this comment.
I don't quite understand why we are deleting this and the other board's YAML files?
There was a problem hiding this comment.
Its because I couldn't find any another way to stop the boards from running in the ci, I tried testing:default:false in the yaml but ci still tried to build the boards, the build resulted in tf-m warning and failed the test.
There was a problem hiding this comment.
Hmm okay, interesting. I'll let people that know better judge and review the PR, but I don't have anything against it.
There was a problem hiding this comment.
I've also update the TF-M docs, could you have a look at it as well?
Ideally, TF-Ms python dependencies would be installed automatically with Zephyr's own requirements.txt, but since the module paths can vary across workspaces we can't reliably do that today.
This document update should help prepare users and reduce "surprise build failures but I'll see if we can add this to zephyr's upstream docker as well.
The TF-M requirements document contained a hard-coded list of Python packages which is incomplete and can easily drift out of sync with the TF-M project. Replace this list with a reference to TF-M’s own ``tools/requirements.txt`` so that all required dependencies are covered. Also update the list of boards that support TF-M. Signed-off-by: Sudan Landge <[email protected]>
wearyzen
force-pushed
the
cs320_ns_support
branch
from
0076e2b to
9e516ee
Compare
|
Zephyr's TF-M has been aligned with upstream TF-M v2.2.0, which includes
Corstone-320 (CS320) support so, enable build and execution of
non-secure variants of MPS4-based boards.
Note that the testing is disabled by default for these boards because
TF-M builds with a few warnings and they need to be fixed for twister to
pass the ci.