Understanding MCUBoot partition management

RE: Understanding MCUBoot partition management

timl2415 — Fri, 14 Jun 2024 17:48:14 GMT

Answered my own question, it seems like MCUBoot can't locate the primary_1 partition (since it doesn't actually exist in accessible flash) unless flash simulator is setup via dts and Kconfig options. The way it's normally done is that Kconfig options add flash_sim.overlay which contains the above definitions and users don't have to add the flash_sim node manually like I do. In my project Cmakelists.txt we are doing

set( mcuboot_DTC_OVERLAY_FILE boards/boot.overlay )

which effectively overwrites the addition of flash_sim.overlay.

RE: Understanding MCUBoot partition management

timl2415 — Thu, 13 Jun 2024 18:13:21 GMT

Hi Hieu, I see that it may compile fine but must clearly be some dependence the slot2_partition in the devicetree for simultaneous OTA. I have the following in my partition manager that indicates mcuboot should transfer the network core image to ram flash (flash sim).

mcuboot_primary_1: { address: 0x0, size: 0x40000, device: flash_ctrl, region: ram_flash }

But for the build to compile with CONFIG_FLASH_SIMULATOR=y (a dependency of CONFIG_NRF53_MULTI_IMAGE_UPDATE) I need a flash_sim node with slot2_partition defined in the device tree like so.

	soc {
		/* Add a flash controller which has the compatible
		 * 'zephyr,sim-flash'. This will ensure that the flash
		 * simulator can use it. None of the other properties in this
		 * node is used for anything.
		 */
		nordic_ram_flash_controller: nordic_ram-flash-controller@0 {
			compatible = "zephyr,sim-flash";
			reg = <0x00000000 DT_SIZE_K(40)>;
			#address-cells = <1>;
			#size-cells = <1>;
			erase-value = <0xff>;

			/* This node label must match that used in the flash
			 * simulator.
			 */
			flash_sim0: flash_sim@0 {
				status = "okay";
				compatible = "soc-nv-flash";
				erase-block-size = <4096>;
				write-block-size = <4>;
				reg = <0x00000000 DT_SIZE_K(256)>;

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

					/* This partition must be defined for
					 * MCUboot to find the partition ID
					 * of the primary slot for image 1,
					 * which is stored in this partition.
					 */
					slot2_partition: partition@0 {
						label = "image-2";
						reg = <0x00000000 0x00000A000>;
					};
				};
			};
		};
	};

So is the reality that mcuboot DOES use the partitions from the partition manager, then the device tree to manage the network core update?

RE: Understanding MCUBoot partition management

Hieu — Thu, 13 Jun 2024 12:24:54 GMT

Hi timl2415,

[quote user=""]This ticket:
Partition Manager and device tree partitions
seems to indicate that MCUBoot relies only on the partitions declared in the devicetree since it's compiled before the partition manager runs[/quote]

I just experimented with NCS v2.6.0, and it seems that the situation is not like that anymore. I removed all partitions in DTS, and the entire project with MCUboot compiled just fine.

Do you still have any confusion with that in mind?

To try for yourself, use this overlay with MCUboot:

/delete-node/ &boot_partition;
/delete-node/ &slot0_partition;
/delete-node/ &slot1_partition;
/delete-node/ &storage_partition;

/{
    chosen {
        /delete-property/ zephyr,code-partition;
    };
};

Hieu