Using zephyr,code-partition for correct generation of image code location and size

[Laczen]

Is your enhancement proposal related to a problem? Please describe.

At the moment it is possible to generate images for a specific partition by using zephyr,code-partition = &partition in the dts.

However it is not possible to specify the size of the header. This is specified by e.g. selecting CONFIG_USE_MCUBOOT = y,
this selects CONFIG_USE_DT_CODE_PARTITION=y and introduces a header size.

If the partitions are specified in more detail the correct code partition could be specified and there would be no Kconfig specification. Suppose USE_DT_CODE_PARTITION would be always selected (or at least if a chosen code-partition is defined) and the partition definition is:

&flash0 {
	partitions {
		compatible = "fixed-partitions";
		#address-cells = <1>;
		#size-cells = <1>;
		image_partition: partition@0 {
			label = "image";
			reg = <0x00000000 0x0003e000>;
			partitions {
				compatible = "fixed-partitions";
				#address-cells = <1>;
				#size-cells = <1>;
				boot_partition: partition@0 {
					label = "mcuboot";
					reg = <0x00000000 0x8000>;
				};
				slot0_partition: partition@8000 {
					label = "image-0";
					reg = <0x00008000 0x1a000>;
					partitions {
						compatible = "fixed-partitions";
						#address-cells = <1>;
						#size-cells = <1>;
						slot0_hdr_partition: partition@8000 {
							label = "header-0";
							reg = <0x00008000 0x200>;
						};
						slot0_image_partition: partition@8200 {
							label = "image-0-1";
							reg = <0x00008200 0x19e00>;
						};
					};
				};
				slot1_partition: partition@22000 {
					label = "image-1";
					reg = <0x00022000 0x1a000>;
					partitions {
						compatible = "fixed-partitions";
						#address-cells = <1>;
						#size-cells = <1>;
						slot1_hdr_partition: partition@22000 {
							label = "header-1";
							reg = <0x000022000 0x200>;
						};
						slot1_image_partition: partition@22200 {
						label = "image-1-1";
						reg = <0x00022200 0x19e00>;
						};
					};
				};
				scratch_partition: partition@3c000 {
					label = "image-scratch";
					reg = <0x0003c000 0x2000>;
				};
			};
		};
		storage_partition: partition@3e000 {
			label = "storage";
			reg = <0x0003e000 0x00002000>;
		};
	};
};

Note that there are no partitions that are overlapping.

To generate a image that would not touch the storage partition: zephyr,code-partition = @image_partition.
To generate the mcu bootloader image: zephyr,code-partition = @boot_partition.
To generate a chainloader image in slot0: zephyr,code-partition = @slot0_partition.
To generate a mcuboot loadable image for slot0: zephyr,code-partition = @slot0_image_partition.
To generate a mcuboot xip loadable image for slot1: zephyr,code-partition = @slot1_image_partition.

Describe alternatives you've considered
Alternative solutions have been proposed in #27974 and #31073 (side benefit).

This proposal replaces #31400.

[Laczen]

@mbolivar-nordic, @galak, @ioannisg, @de-nordic, fyi.

[JordanYates]

What part of the build system is moving around the zephyr,code-partition chosen node?
As per https://docs.zephyrproject.org/latest/guides/build/index.html, devicetree generation is the first step in the build system

[Laczen]

What part of the build system is moving around the zephyr,code-partition chosen node?
As per https://docs.zephyrproject.org/latest/guides/build/index.html, devicetree generation is the first step in the build system

An overlay file of course.

[JordanYates]

An overlay file of course.

And how is that overlay file being selected? The point is that overlays are set in CMake or from the command line, which was my comment on the other thread.

[Laczen]

And how is that overlay file being selected? The point is that overlays are set in CMake or from the command line, which was my comment on the other thread.

From the command line indeed, and what is the problem with that, just add -- -DDTC_OVERLAY_FILE=xxx.overlay. Your proposal in the other thread is exactly going to do the same.

By setting the code-partition in the boards dts file equal to &image_partition from the above dts the behavior would be exactly as it is now, but solving the issue that images can flow into the storage area.

All other (more advanced) usages use an overlay file to override the default code partition, without any Kconfig symbol. Support for whatever bootloader/partitioning scheme is supported by a appropiate dts (if the default does not fit) and a overlay for selecting the correct location.

A further extension could be to use linker generated memory regions for the parent of the code-partition, in that case the image would have access to its header (and possibly trailer for bootloaders that use trailers to verify images).

The proposal does all this by just using the tools in a correct way. Removing the confusing (Kconfig) generation of image headers, avoiding the need to add extra Kconfig options for other kind of images that need to be generated (these extra Kconfig definitions are only trying to describe extra info not included in the dts). In all cases the image size is correctly evaluated against the area that is used. It only takes a change in the dts describing the partitions how they are really used.

[JordanYates]

From the command line indeed, and what is the problem with that, just add -- -DDTC_OVERLAY_FILE=xxx.overlay. Your proposal in the other thread is exactly going to do the same.

It is not necessarily a problem, its just a change from the current setup where selecting CONFIG_MCUBOOT is the way to build a chain loaded application. It is not the same as my proposal, which eliminates code-partition.

One concern is that specifying the overlay file is rather clunky. Either you need a board_mcuboot.overlay in each application for each board, or you are left to type -DDTC_OVERLAY_FILE=zephyr/boards/arm/board_mcuboot.overlay each time. Looking through the options to automatically use overlays, perhaps the board revision mechanism could be used:
https://docs.zephyrproject.org/latest/guides/porting/board_porting.html#multiple-board-revisions

Something like west build -b board@mcuboot zephyr/samples/hello_world seems quite clean to me.

[Laczen]

From the command line indeed, and what is the problem with that, just add -- -DDTC_OVERLAY_FILE=xxx.overlay. Your proposal in the other thread is exactly going to do the same.

It is not necessarily a problem, its just a change from the current setup where selecting CONFIG_MCUBOOT is the way to build a chain loaded application. It is not the same as my proposal, which eliminates code-partition.

The overlay file is very simple:

/{
	chosen {
		zephyr,code-partition = &image_partition;
	};
};

and could reside in the project folder, but yes it would change the usage of CONFIG_MCUBOOT (because as it is this takes ownership of code-partition, which it shouldn't). CONFIG_MCUBOOT could be removed in the proposal (or at least it's influence on image generation).

One concern is that specifying the overlay file is rather clunky. Either you need a board_mcuboot.overlay in each application for each board, or you are left to type -DDTC_OVERLAY_FILE=zephyr/boards/arm/board_mcuboot.overlay each time. Looking through the options to automatically use overlays, perhaps the board revision mechanism could be used:
https://docs.zephyrproject.org/latest/guides/porting/board_porting.html#multiple-board-revisions

Something like west build -b board@mcuboot zephyr/samples/hello_world seems quite clean to me.

Yes, this would be very clean. It is possible to add a mcuboot_boot, mcuboot_image, ... to the board definitions with just the above overlay file. But this might limit the ability to add board revisions.

[JordanYates]

The CONFIG_MCUBOOT symbols would need to stick around in some form as they are used for other things.
Perhaps chainable revisions would work, board@rev@mcuboot, where all revisions are merged together.
The CMake revision functions aren't written with this in mind however.