implementing noinit section on zephyr

RE: implementing noinit section on zephyr

Jason — Mon, 03 Nov 2025 07:29:08 GMT

Hi Anthony Ambuehl : How did you place a variable to the app_noinit section ?
I add 4K app_noinit memory, but in the final Linker.cmd, it just add app_noinit into the MEMORY, so I can not use

"int test __attribute__((section(".app_noinit"))); " to place the variable test to the app_noinit memory.

RE: implementing noinit section on zephyr

td-pradecki — Tue, 25 Mar 2025 16:13:40 GMT

Hi! I found your answer very helpful!
Question to nordic developers: can you confirm this is a safe solution?

RE: implementing noinit section on zephyr

Anthony Ambuehl — Mon, 06 Jan 2025 22:46:23 GMT

There are the changes I made to my boards devicetree:

/ {
	sram@2003F700 {
		compatible = "zephyr,memory-region";
		reg = <0x2003F700 0x400>;
		zephyr,memory-region = "app_noinit";
		status = "okay";
	};
	sram@2003FB00 {
		compatible = "zephyr,memory-region";
		reg = <0x2003FB00 0x500>;
		zephyr,memory-region = "rtt";
		status = "okay";
	};
};
/* Reduce SRAM0 to isolate the defined memory regions */
&sram0 {
        reg = <0x20000000 0x3F700>;
};

After building the application with default system build (single image) I get:

[300/303] Linking C executable zephyr\zephyr.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:      521340 B         1 MB     49.72%
             RAM:      125056 B       256 KB     47.71%
      app_noinit:          26 B         1 KB      2.54%
             rtt:        1208 B       1280 B     94.38%
        IDT_LIST:          0 GB        32 KB      0.00%
Generating files from D:/Flipperz/flipper_workspace/app.git/mfg_app/build_thomas_c/zephyr/zephyr.elf for board: thomas_c
[303/303] Generating zephyr/merged.hex

Will I need to do anything when I switch to static partition file pm_static.yml for this configuration?

RE: implementing noinit section on zephyr

Anthony Ambuehl — Mon, 06 Jan 2025 21:52:48 GMT

The retained memory library approach seems dramatically overkill. It requires a virtualized driver API, with extra kernel level code, and would require me to rewrite the existing code to use that API.

Fundamentally the retained_memory driver (zephyr,retained-memory) itself isn't doing anything with the linker or memory its just creating instance of a driver to access that parent memory region. The parent memory region (zephyr,memory-region) creates the named linker section, however it doesn't actually mark it as noinit.

It looks to me that that the way the boot_mode is preserved between app and mcu_boot is actually caused by removing that segment from the sram0..

essentially this code

/* Reduce SRAM0 usage by 1 byte to account for non-init area */
&sram0 {
        reg = <0x20000000 0x3FFFF>;
};

The macro __noinit actually puts code into sram0 in a uniquely named section but it doesn't appear to be protected from mcuboot. Also many areas such as the thread stacks are placed in the noinit section simply to avoid initializing them not because retention is desired.

I think my best option is to adjust the sram boundaries and create a new zephyr,memory region there.

I will create a macro similar to the one used by SEGGER_RTT_PUT_SECTOIN to place my variables into the defined region.

RE: implementing noinit section on zephyr

Hung Bui — Tue, 17 Dec 2024 08:57:29 GMT

Hi Anthony,
For a simple non-init could you take a look at this ticket ? non init section

(it refers back to the code of the retained driver actually).

But I think there is a concern about MCUBoot may overwrite this area if the non init is not configured in MCUBoot as well.

Regarding the retained library, if you take a look at the retention library : https://docs.zephyrproject.org/latest/services/retention/index.html

You can find that it utilize the hardware RAM retention as you mentioned and the non-init configuration of the compiler to ensure the validity of the data. My understanding is that when you use this in device tree as shown in the documentation , the RAM retention hardware will be automatically configured accordingly and non-init will be used when compiling.
This solution has been used for sharing data between the application and the MCUBoot bootloader between reboot (and not power reset)

RE: implementing noinit section on zephyr

Anthony Ambuehl — Mon, 16 Dec 2024 20:58:08 GMT

Hi Hung,

I'm looking at nrf52840 product specification to understand better the retained RAM region. As far as I can tell, all RAM regions can be retained. A retained ram region has the RAM[n].POWER.RETAINED flag set. Perhaps there are some regions where this flag is automatically set?

The effect of this flag is to maintain power to the RAM bank in the SYSTEM OFF state. It doesn't tell us anything about whether the system initialization like the .bss initialization will overwrite it.

I reviewed the retained ram driver API. It adds a read/write/clear system call API to access the retained memory, which adds significant overhead, from the system call wrappers.

I'd like to know how I can create a named region that is not-initialized within zephyr. In the previous sdk we could simply add a new named region to the flash_placement.xml and add an attribute to a variable to tell the compiler/linker where to put it. Then I could assign a value to the variable (LHS) and the noinit region would be updated. Similarly I could use the variable on the right hand side(RHS) of an assignment to read it.

RE: implementing noinit section on zephyr

Hung Bui — Wed, 11 Dec 2024 09:24:26 GMT

Hi Anthony,

Sysbuild is replacing the parent/child image configuration. But it doesn't replace partition manager. At latest NCS SDK (NCS v2.8.0) partition manager is still used in sysbuild. I don't know if we will replace partition manager in the future, but if there is a new system, it will be made so that it's compatible with partition manager and that you should be able to do DFU update to the new system.

I assume you will include MCUBoot in your application ? Or do you plan to release a product without any option to do DFU update ? we wouldn't recommend so.

Have you tried what I mentioned about RAM retention ? That's how we retain data for to send from application sending to MCUBoot bootloader between a soft reset.

RE: implementing noinit section on zephyr

Anthony Ambuehl — Tue, 10 Dec 2024 23:44:56 GMT

My questions are regarding a RAM region which is not initialized by the reset routines.

I am only mentioning NRF5 SDK because the reference code that I am porting was based on NRF5 SDK. The work I am doing now is entirely zephyr/NCS.

The manufacturing test in this case is to verify the battery protection circuit when shipping device to customer. The battery is shipped partially charged and the hardware has a feature to isolate the battery from the system, called ship mode.

The test writes a crc protected magic value to a noinit region of memory, then the power is cut to NRF52 device. For the test to pass, (eg power is successfully cut and battery is protected) the noinit region must lose its value. During a normal reset without the power cutoff the noinit region must maintain its value.

This project will be released in 2025 and will be actively maintained for several years beyond. I need to develop a solution that will allow easy transition to NCS 2.8 and hopefully next version beyond.

It seems like sysbuild replaces partition manager and parent/child image approach, is that right?

Also, personally, I prefer the flexible partition definition of device tree over the limited hardcoded partitions supported by partition manager. I briefly attempted to switch to partition manager with CONFIG_PM_SINGLE_IMAGE and could not readily find a way to implement the custom partitions that my application has defined.

RE: implementing noinit section on zephyr

Hung Bui — Mon, 09 Dec 2024 21:43:43 GMT

Hi Anthony,

Due to unexpected reason I'm out of office in the next 2 days. I won't be able to answer all your questions but I will try to answer your question about noinit. Let us know if the ticket is urgent. I can try to find another engineer to look into it.

1. Correct

2. Please explain what exactly you want to do . Also please explain how you plan to run the nRF5 SDK image on Zephyr. If your image is a child image/remote image of a zephyr application then pm.yml can be used.

3. I assume you are talking about noinit for FLASH, not noinit for RAM, correct ? Please elaborate more on this procedure: One of the tests utilized a noinit region to confirm that power to the nrf processor was cut between phases of the test.
If you simply want to define a partition in Flash that partition manager doesn't allocate other child image into, I believe pm-static.yml is what you need. The easiest way of making the pm-static.yml file is to build your application normaly (without the noinit area defined) then you can copy the content of the partitions.yml file and make your own pm-static.yml file in your project folder. You then can adjust the partitions (if needed) and add your own "noinit" partition. For example here is an "unused" page define after mcuboot_secondary:

unused_page:
  address: 0xf7000
  placement:
    after:
    - mcuboot_secondary
  size: 0x1000

If you are asking about noinit for RAM, I don't think partition manager has anything to do here. It only deal with flash.

For RAM:

It's the RAM retention region in device tree need to be defined (check the chip spec for RAM retention region).
You can take a look at this sample : https://github.com/nrfconnect/sdk-zephyr/tree/v3.6.99-ncs2/tests/boot/mcuboot_data_sharing

The noinit ram is configured in nrf52840dk_nrf52840.overlay :

/ {
	sram@2003F000 {
		compatible = "zephyr,memory-region", "mmio-sram";
		reg = <0x2003F000 DT_SIZE_K(1)>;
		zephyr,memory-region = "RetainedMem";
		status = "okay";

		retainedmem {
			compatible = "zephyr,retained-ram";
			status = "okay";
			#address-cells = <1>;
			#size-cells = <1>;

			boot_info0: boot_info@0 {
				compatible = "zephyr,retention";
				status = "okay";
				reg = <0x0 0x100>;
			};
		};
	};

	chosen {
		zephyr,bootloader-info = &boot_info0;
	};
};

The data at 0x2003F000 is accessed in https://github.com/nrfconnect/sdk-mcuboot/blob/main/boot/zephyr/shared_data.c
See:
static const struct device *bootloader_info_dev =
DEVICE_DT_GET(DT_CHOSEN(zephyr_bootloader_info));

The rest of the questions we can discuss after we have more info from you.

RE: implementing noinit section on zephyr

Anthony Ambuehl — Fri, 06 Dec 2024 19:33:39 GMT

And it gets more confusing!

I just started learning about sysbuild...

9) does the addition of sysbuild mean I should continue with the single image approach for now and plan to use sysbuild to integrate the bootloader instead of using the multi-image parent/child build approach?

10) If I'm building single images and integrating with sysbuild, how do I specifiy the applications noinit sram region?

RE: implementing noinit section on zephyr

Anthony Ambuehl — Fri, 06 Dec 2024 19:12:09 GMT

After switching on CONFIG_PM_SIGNLE_IMAGE, I'm finding that my fixed partitions defined in device tree are broken. It looks like partition manager can only handle predefined regions that are commonly used by zephyr.

6) Is there any plan for multi-image builds to fully support device tree specified fixed partitions? Perhaps the partition_manager could process devicetree output and automatically generate the correct sections based for the fixed partitions?

7) Is it the case that I need to define custom partitions in the root image via a file like pm.yml?