Is static partition management necessary?

[clockis]

Greetings,

After migrating to the NCS v2.5.2, I noticed a warning that recommends using static partition management (which I have also confirmed is recommended by other Nordic engineers in various support cases).

For our use case for which we have a Bootloader (MCUBoot, non-upgradable) + Application (upgradable via OTA) is the static partition necessary because every time I perform a new build I check the current partition configuration and it is always the same and aligns with the partition configuration defined in out custom boards partition node.

Partition node:

//Relevant chosen section of the .dts file
chosen {
		zephyr,console = &uart0;
		zephyr,uart-mcumgr = &uart0;
		zephyr,sram = &sram0;
		zephyr,flash = &flash0;
		zephyr,code-partition = &slot0_partition;
	};

/* Flash configuration copied from nRF52840DK */
&flash0 {

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

		boot_partition: partition@0 {
			label = "mcuboot";
			reg = <0x00000000 0x0000C000>;
		};
		slot0_partition: partition@c000 {
			label = "image-0";
			reg = <0x0000C000 0x00067000>;
		};
		slot1_partition: partition@73000 {
			label = "image-1";
			reg = <0x00073000 0x00067000>;
		};
		scratch_partition: partition@da000 {
			label = "image-scratch";
			reg = <0x000da000 0x0001e000>;
		};

		/*
		 * The flash starting at 0x000f8000 and ending at
		 * 0x000fffff is reserved for use by the application.
		 */

		/*
		 * Storage partition will be used by FCB/LittleFS/NVS
		 * if enabled.
		 */
		storage_partition: partition@f8000 {
			label = "storage";
			reg = <0x000f8000 0x00008000>;
		};
	};
};

So my question is, since the partitions created are always the same (same start address and length for the application partition), is the static partition management configuration really necessary for our use case (we won't have more than one upgradable fw image in the future)?

Thank you!

Best regards,

Stavros

[Amanda Hsieh]

Hi, 

See Static partition requirement for DFU.

Regards,
Amanda H.

[clockis]

I have read this documentation in detail, I am just trying to understand the underlying workings of the dynamic partition management system. 
That is because it seems to always follow the partition mapping I have setup in the .dts file (which I have included in my original post) no matter the build it always stays the same. It is specified in the documentation that the pm_static.yml file specifies the start address foe each partition but that is defined in the .dts for my FW (as seen above) and the partition manager always uses the start addresses for each partition defined there, so I am trying to understand if this is truly necessary since the start addresses of my partitions are explicitly defined in my .dts.

So, if all info in the pm_static file defines the start address and size of each partition which is already done for my application in the .dts is the pm_static redundant? I have also checked the auto-generated partitions.yml and it always respects and follows the definitions of the partitions in the .dts file

partition_name:
   address: 0xab00
   size: 0x1000

/* Flash configuration copied from nRF52840DK */
&flash0 {

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

		boot_partition: partition@0 {
			label = "mcuboot";
			reg = <0x00000000 0x0000C000>;
		};
		slot0_partition: partition@c000 {
			label = "image-0";
			reg = <0x0000C000 0x00067000>;
		};
		slot1_partition: partition@73000 {
			label = "image-1";
			reg = <0x00073000 0x00067000>;
		};
		scratch_partition: partition@da000 {
			label = "image-scratch";
			reg = <0x000da000 0x0001e000>;
		};

		/*
		 * The flash starting at 0x000f8000 and ending at
		 * 0x000fffff is reserved for use by the application.
		 */

		/*
		 * Storage partition will be used by FCB/LittleFS/NVS
		 * if enabled.
		 */
		storage_partition: partition@f8000 {
			label = "storage";
			reg = <0x000f8000 0x00008000>;
		};
	};
};

If it is possible to explain to me the inner workings of this system and why the pm_static.yml is necessary considering the .dts definitions of the partitions it would be really helpful as I want to learn how this works.

Thank you for the support and I look forward to hearing from you!

Best regards,

Stavros

[Amanda Hsieh]

Hi, 

See the Partition Manager documentation. 

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

-Amanda H.

[clockis]

Hello,

My mistake, I missed this. Thank you for pointing that out!

Please correct me if I am wrong, when using a dynamic pm(without pm_static.yml file) and two builds generate the same partitions.yml file the DFU can be performed correctly from one to the other? Is that so or does the MCUBoot use other partitions than the ones in the generated file partitions.yml(in the build folder)?

I am trying to make sure that the contents of my pm_static.yml file will be correct and previously programmed devices can be updated with newer version of the FW.

So my main concern is that we have rolled out some prototype devices that are fully assembled that have been programmed during assembly(flashed using a J-Link programmer directly to the boards) by the manufacturer using a specific version of our FW (lets call this Version Alpha) with DFU OTA capabilities (MCUBoot & MCUMgr/SMP), and can only be updated OTA (because they have sealed shut with no access to the PCB). Since then I have been updating them OTA using the default dynamic pm (with no pm_static.yml file) with newer versions of the FW but now I want to make sure that for the most recent version I set the correct pm_static.yml file. Will it be sufficient to copy the contents of the generated partitions.yml file that the first ever build(Version Alpha) that was flashed on the board with the J-Link programmer (as a .hex file), to my pm_static.yml file(for the newest most recent version of the FW) to ensure correct DFU OTA?

That is main question and concern (and my main reason for opening this ticket).

Please excuse the long winded approach to this issue.

Thank you and I look forward to hearing from you!

Best regards,

Stavros

[Amanda Hsieh]

Hi,

clockis said:

when using a dynamic pm(without pm_static.yml file) and two builds generate the same partitions.yml file the DFU can be performed correctly from one to the other?

Correct. 

clockis said:

Is that so or does the MCUBoot use other partitions than the ones in the generated file partitions.yml(in the build folder)?

Not sure I understand the question correctly. Without pm_static.yml file, Partition Manager would generate partitions.yml for the mcuboot in multi-image builds.

clockis said:

Will it be sufficient to copy the contents of the generated partitions.yml file that the first ever build(Version Alpha) that was flashed on the board with the J-Link programmer (as a .hex file), to my pm_static.yml file(for the newest most recent version of the FW) to ensure correct DFU OTA?

Yes, that's correct. You can run "ninja partition_manager_report" under build folder or Memory report in VS Code to check the memory layout. 

Regards,
Amanda H.