Understanding MCUBoot partition management

[timl2415]

I have an application running on a custom nRF5340 board that supports simultaneous BLE DFU of the network and application core with MCUBoot. 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. If that's the case, then its unclear to me which partitions must match up between the devicetree partitions and pm_yml partitions in this application. What worked for me was:

Device Tree Partition	Equivalent Partition Manager Partition
boot_partition	mcuboot
slot0_partition + slot0_ns_partition	mcuboot_primary
slot1_partition + slot1_ns_partition	mcuboot_secondary
(none since mcuboot can't access nwk core flash)	mcuboot_primary_1

What I don't understand here is the relationship between mcuboot_secondary_1 and slot2_partition (0x0 - 0x000A in the flash_sim node). How does MCUBoot see where the mcuboot_secondary_1 image is stored since it doesn't have an equivalent partition in the device tree. Is it actually that MCUBoot reads where to grab the image to DFU from the partition manager but uses the device tree to determine the DFU destination?

[Hieu]

Hi timl2415,

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

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

[timl2415]

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?

[timl2415]

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.