nrf54l15: Available SRAM memory for non-secure application

[Ramakrishnan]

Hi,

I'm building an non-secure application for nrf15l15 SoC using NCS SDK v3.0.2.  The available SRAM memory for my application is set to 188K in the base dtsi files ( see dump below ) instead of 256K that is available on the SOC.  I checked that the final .dts generated for my application has cpu_sram set to 188K.  It looks like we are reserving 68K for FLPR which doesn't get used for my application.

My question is , if I'm not using FLPR , can I safely override cpuapp_sram to 256K in my overlay file.  My application is not fitting within 188K limits ( TF-M also gobbles up about 55K ) and I'd like to explore all options before going down the route of optimizing the application.  

cpu_flpr_sram node anyway gets deleted as shown below ( my final dts also doesn't have it ) - so it looks like we are just letting go of 68K worth of SRAM without any use.  I'd happily take that and use it for my application.  I'd like to be sure that this is okay and doesn't cause any other issues. Please clarify.

DUMPS

From zephyr/dts/common/nordic/nrf54l15.dtsi

&cpuapp_sram {

    reg = <0x20000000 DT_SIZE_K(188)>;

    ranges = <0x0 0x20000000 DT_SIZE_K(188)>;

};

/* 188 + 68 = 256KB */

/ {

    soc {

        cpuflpr_sram: memory@2002f000 {

            compatible = "mmio-sram";

            reg = <0x2002f000 DT_SIZE_K(68)>;

            #address-cells = <1>;

            #size-cells = <1>;

            ranges = <0x0 0x2002f000 DT_SIZE_K(68)>;

        };

    };

};

From zephyr/dts/arm/nordic/nrf54l_05_10_15_cpuapp.dtsi

/delete-node/ &cpuflpr;
/delete-node/ &cpuflpr_rram;
/delete-node/ &cpuflpr_sram;
/delete-node/ &cpuflpr_clic;

[Menon]

Hello,

The nRF54L15 has a total of 256 KB of SRAM, but this is intentionally split in the SoC Devicetree.188 KB is assigned to the CPUAPP, and 68 KB is reserved for FLPR. Even if FLPR isn’t used and its Devicetree nodes are removed in a CPUAPP only build, that reserved FLPR SRAM is not automatically added back to the CPUAPP memory.

It is possible to shrink or remove the FLPR SRAM reservation and use that memory for the application, as long as FLPR is not used and any related Devicetree references or assumptions are handled correctly. That said, this isn’t the default or recommended setup, since the split is part of the SoC memory map and may be relied on by platform code or future features.

Before changing the CPUAPP SRAM size, it’s  better to look at optimizing TF-M instead. TF-M can be built from source with only the required secure features enabled, which can reduce its RAM usage and is the supported way to free up memory for the non-secure application. See the section Minimal TF-M configuration.

Kind Regards,

Abhijith

[Ramakrishnan]

Hi Abhijith

Thanks for your prompt response.  It was helpful to understand a few aspects of what we observe.

I tried the minimal TF-M and it did significantly cut down the usage of TF-M and our application could fit in.  But we are very close to 188K.  I expect more features to get added to our product  - I fear we may not be able take that approach.  

So, I'd like to understand in detail your response about using the reserved memory for FLPR.

There are two points about using the reserved space of FLPR that I get from your response.

1) "It is possible to shrink or remove the FLPR SRAM reservation and use that memory for the application, as long as FLPR is not used and any related Devicetree references or assumptions are handled correctly "

>> a) FLPR is excluded by the build itself , so we don't have any issue with FLPR being accidentally used. 

     b) "Device tree references/assumptions" - Can you elaborate a bit on this - are you referring to any references/assumptions in our application that may point to the FLPR device nodes ?   In which case , we would be still okay as our application knows we aren't using FLPR.  I hope zephyr/nrfx libs don't make any such assumptions, even if it did, it must have failed now as FLPR is not enabled in the build and our application seems to work okay.. 

2) "since the split is part of the SoC memory map and may be relied on by platform code or future features." 

>> Can you please elaborate a bit more on this ? If FLPR is excluded during build time itself, even if you have a future platform code ( not sure what platform code we are referring here - is it nrfx libs/zephyr kernel ? ) that uses FLPR, we shouldn't be affected , isn't it ? Are you saying a future feature which may be needed to run on the M-33 may use up this space ?  That would essentially mean this reservation that is currently being made is not quite for FLPR ? It seems a bit contradictory. 

Excluding 68K out of 256K  ( ~26 % reduction from what the hardware provides ) is quite a big hit on available memory. I'd like get a detailed understanding of this one so that we can make appropriate trade-offs.

Regards..

Ramakrishnan.

[Ramakrishnan]

Hi,

Can you please get back on this ?

Thanks

~Ramakrishnan