implementing noinit section on zephyr

[Anthony Ambuehl]

NCS 2.7.0

nrf52840

I'm currently porting software that was originally developed for nrf52832 on NRF5 SDK to run on Zephyr. I am currently on a deadline to delivery a prototype of the manufacturing test firmware to the factory for first PCB validation.  This release will be single image and then I will begin work to implement the bootloader which of course will mean multi-image build.

One of the tests utilized a noinit region to confirm that power to the nrf processor was cut between phases of the test.  The implementation of noinit data was fairly straight forward on nrf5 sdk.  A section was defined in the flash_placement.xml.  This section also had to be coordinated with the bootloader so it wasn't overwritten.

I'm trying to understand the process with zephyr. I will make some statements of my understanding from reading portions of the documentation.  Please correct anything I get wrong.  I also have some questions inline which I will number and bold.

It seems like it may vary depending on whether it is single image or multi-image.  For multi-image it appears the partition manager comes into play.  I'm unclear on how it works for single image. 

A note I found on the partition manager page ( Partition Manager )  

When you build a multi-image application using the Partition Manager, the devicetree source flash partitions are ignored.

Would imply that single image builds take partition definitions from devicetree.  

Alternatively, it seems I can use partition manage with a single image by including the Kconfig variable CONFIG_PM_SINGLE_IMAGE in my prj.conf.  

It also appears with partition manager there is a mechanism for a subsystem to provide a supplemental configuration, however I only find subsys/partition_manager within the nrf module.  

1) Out of general curiosity, Is partition_manager a proprietary element of NCS that is not included with Zephyr itself?

2) Can I add a subsystem pm.yml from my out-of-tree customer/application repository?  

3) Is partition_manager the recommended way to add a noinit section?  Are there any samples that would demonstrate how it should be implemented?

4) Since my project will ultimately be multi-image with a bootloader, is my best choice to develop with partition_manager?  

5) Any change with partition_manager in NCS 2.8.0 or planned for the future?

a*

[Anthony Ambuehl]

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?

[Anthony Ambuehl]

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?

[Hung Bui]

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. 

[Anthony Ambuehl]

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.

a*

[Hung Bui]

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.