Runtime control over flprcore from cpuappcore with TF-M possible?

[Jonathan Lange]

Hello,

I am working with the following sample project and NRF Connect SDK v3.3.0. (Referenced regarding this topic.)
The sample implements DFU with MCUBoot while using the flprcore.
Part of the solution's design is the fact that the applictation is responsible for copying the flpr image into ram and starting/ending it.

Now I wanted to also enable TF-M which obviously stops me from just executing code somewhere. How do I adjust the sample and configure my flpr SRAM partition to be in the non-secure world and executable?

I added memory_map_ns.dtsi and two .overlay files so MCUBoot and and the application are pointed to it.

/*
 * Copyright (c) 2026 Nordic Semiconductor ASA
 *
 * SPDX-License-Identifier: LicenseRef-Nordic-4-Clause
 */

&cpuapp_rram {
	reg = <0x0 DT_SIZE_K(1524)>;

	/* Remove original board defined partition node to allow to allow it to be rewritten */
	/delete-node/ partitions;

	partitions {
		compatible = "fixed-partitions";
		#address-cells = <1>;
		#size-cells = <1>;

		boot_partition: partition@0 {
			label = "mcuboot";
			reg = <0x0 DT_SIZE_K(32)>;
		};

		slot0_partition: partition@8000 {
            compatible = "fixed-subpartitions";
			label = "image-0";
			reg = <0x8000 DT_SIZE_K(704)>;
            ranges = <0x0 0x8000 0xb8000>;
			#address-cells = <1>;
            #size-cells = <1>;

            slot0_s_partition: partition@0 {
                label = "image-0-secure";
                reg = <0x0 DT_SIZE_K(256)>;
            };

            slot0_ns_partition: partition@40000 {
                label = "image-0-nonsecure";
                reg = <0x40000 DT_SIZE_K(448)>;
            };

		};

		slot1_partition: partition@b8000 {
			compatible = "fixed-subpartitions";
			reg = <0xb8000 DT_SIZE_K(708)>;
            ranges = <0x0 0xb8000 0x169000>;
			#address-cells = <1>;
            #size-cells = <1>;
			label = "image-1";
            slot1_s_partition: partition@0 {
                label = "image-1-secure";
                reg = <0x00000000 DT_SIZE_K(256)>;
            };

            slot1_ns_partition: partition@40000 {
                label = "image-1-nonsecure";
                reg = <0x00040000 DT_SIZE_K(448)>;
            };
			//+ 4KB page sector overhang for swap move with offest not how this should be implemented with the subpartitions
		};

		tfm_ps_partition: partition@169000 {
            compatible = "zephyr,mapped-partition";
            label = "tfm-ps";
            reg = <0x169000 DT_SIZE_K(16)>;
        };

        tfm_its_partition: partition@16C000 {
            compatible = "zephyr,mapped-partition";
            label = "tfm-its";
            reg = <0x16C000 DT_SIZE_K(8)>;
        };

        tfm_otp_partition: partition@16E000 {
            compatible = "zephyr,mapped-partition";
            label = "tfm-otp";
            reg = <0x16E000 DT_SIZE_K(8)>;
        };

		storage_partition: partition@170000 {
			label = "storage";
			reg = <0x170000 DT_SIZE_K(20)>;
		};
		//end 0x175000
	};
};

As a side question I am also wondering why even with a succesfull build no final zephyr.dts file is created in the build folder.

[Susheel Nuguru]

Hi Jonathan, 

I do not think it is that simple task to make this work with TFM.

I think you need to add split image TFM partition to the memory map and you should also somehow make MCUboot use TFM aware partition map.
I do not see any samples or starting point for that. Someone with better memory partition and TFM knowledge might assist you in this, but my first thought is that it wont just be a small configuration change. You most likely need to change your code to guard SPU and RAM power-down code so the non-secure app no longer tries to access secure-only APIs.

[Jonathan Lange]

Thanks for the classification.

The funny thing is for the three features MCUBoot with DFU, flpr support and TF-M I have an example for each combination of two them working together but combining all three, is out of my expertise.

I will post an update here if I find a solution. But for now I will probably just drop TF-M and have to implement some functionality first.

I am hoping that with the transistion of the Nordic partition manager to the Zephyr devicetree approach more examples and documentation will follow.

When building for TF-M I am still not sure how much is decided by ncs/v3.3.0/modules/tee/tf-m/trusted-firmware-m/platform/ext/target/nordic_nrf/common/nrf54l15/partition/flash_layout.h and how much by the devicetree or how they work together exactly. But I also don't want to change the first one cause its not contained in my application.