Partition Manager and device tree partitions

[liteyear]

This is a continuation of this question. It may be necessary reading to understand the context.

I'm confused by this topic too, however I think the error about "boot_partition" may have gone away? In Nov 2022, shortly before the OP, there were a couple of changes addressing Partition Manager support:

https://github.com/nrfconnect/sdk-mcuboot/commit/f7de93fe96daf9776a7331d2157d33f54e9f526f

https://github.com/nrfconnect/sdk-mcuboot/commit/82ee5d0bb9ac68c14033b102705904ee9991ee3d

As far as I can tell now (at least since ncs v2.5.2), if MCUBoot is enabled with CONFIG_BOOTLOADER_MCUBOOT, the build becomes a "Multi-image build". That enables Partition Manager, which makes fixed-partitions in the DTS irrelevant.

At least when I try it, removing all trace of fixed-partitions results in the same output, and no mention of boot_partition.

But then that makes comments like this one:

https://github.com/nrfconnect/sdk-nrf/blob/5c862041c865a7e8c6046b98608078cac852f0d0/boards/nordic/nrf7002dk/nrf5340_cpuapp_partition_conf.dts#L14

incorrect. So which is it? Does MCUBoot make fixed-partitions necessary, or unnecessary? Perhaps the answer is here, which seems to suggest fixed-partitions do nothing in ncs, but are still expected in Zephyr, so things like "slot0" are faked internally for Zephyr's benefit?

[Vidar Berg]

Hello,

I understand the confusion. I hope this is something we will be able to address in the not too distant future by aligning on a common solution for upstream Zephyr and our nRF Connect SDK.

In the nRF Connect SDK, the multi-image build feature requires the use of the partition manager, but the multi-image support with parent/child images is currently being replaced by the Sysbuild feature from upstream. The partition manager allows the memory layout to be controlled dynamically based on what is enabled by the parent image (bootloader, settings storage, etc.). Before Sysbuild (a multi-image build equivalent) was introduced in Zephyr upstream, you would have to build firmware images such as MCUBoot separately.

As far as I can tell now (at least since ncs v2.5.2), if MCUBoot is enabled with CONFIG_BOOTLOADER_MCUBOOT, the build becomes a "Multi-image build". That enables Partition Manager, which makes fixed-partitions in the DTS irrelevant.

This is correct. The project will become a multi-image project when enabling child images. For instance, when you enable MCUBoot, or Bluetooth. With Bluetooth enabled, the Bluetooth controller FW for the network core will also be automatically included as a child-image.

incorrect. So which is it? Does MCUBoot make fixed-partitions necessary, or unnecessary?

The DT would still be relevant if you built the MCUBoot project separetly instead of building it as a child-image to your parent applicaiton.

Best regards,

Vidar

[liteyear]

Okay thanks. I still get occasional build errors complaining about missing partitions like "slot0_partition", now that I've stripped out fixed-partitions, but they always turn out to be a KConfig issue, not DT. So I suppose it makes sense the references will remain, even in the scenarios where the DT definitions aren't required.