Partition manager primary and secondary slot sizes

[rerickson]

I have the following questions about PM and what it generates.  My relevant board and config files are below, along with the PM partitions output.

1. Can you explain the mcuboot_pad?  Is it needed?  When I try to remove it, multi-image builds break.

2. When using mcuboot_pad, how can I get my mcuboot_secondary to match mcuboot_primary size more dynamically?  Currently I had to hack my board DTS partition size for slot_1 to get the size to match.

3. Where is PM coming up with the 0xe2000 size for mcuboot_primary?  In my DTS, i have slot_0 set to a size of 0xe0000. mcuboot_pad is only 0x200, so why is mcuboot_primary padded by an extra 0x1e00?

4. Why is the "storage" partition in my DTS getting renamed to littlefs_storage by PM?

Board file:

/*
 * Copyright (c) 2019 Laird Connectivity
 *
 * SPDX-License-Identifier: Apache-2.0
 */

/dts-v1/;
#include <nordic/nrf52840_qiaa.dtsi>

/ {
	model = "Pinnacle 100 Dev Kit";
	compatible = "lairdconnect,pinnacle100-dvk";

	chosen {
		zephyr,console = &uart0;
		zephyr,shell-uart = &uart0;
		zephyr,uart-mcumgr = &uart0;
		zephyr,bt-mon-uart = &uart0;
		zephyr,sram = &sram0;
		zephyr,flash = &flash0;
		zephyr,code-partition = &slot0_partition;
		zephyr,entropy = &rng;
	};

	leds {
		compatible = "gpio-leds";
		led1: led_1 {
			gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
			label = "Blue LED 1";
		};
		led2: led_2 {
			gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>;
			label = "Green LED 2";
		};
		led3: led_3 {
			gpios = <&gpio1 6 GPIO_ACTIVE_HIGH>;
			label = "Red LED 3";
		};
		led4: led_4 {
			gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
			label = "Green LED 4";
		};
	};

	buttons {
		compatible = "gpio-keys";
		button1: button_1 {
			gpios = <&gpio0 31 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
			label = "Push button switch 1";
		};
		button2: button_2 {
			gpios = <&gpio0 3 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
			label = "Push button switch 2";
		};
		button3: button_3 {
			gpios = <&gpio0 4 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
			label = "Push button switch 3";
		};
		button4: button_4 {
			gpios = <&gpio0 2 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
			label = "Push button switch 4";
		};
	};

	/* These aliases are provided for compatibility with samples */
	aliases {
		led0 = &led1;
		led1 = &led2;
		led2 = &led3;
		led3 = &led4;
		sw0 = &button1;
		sw1 = &button2;
		sw2 = &button3;
		sw3 = &button4;
	};
};

&adc {
	status ="okay";
};

&gpiote {
	status ="okay";
};

&gpio0 {
	status ="okay";
};

&gpio1 {
	status ="okay";
};

&uart0 {
	compatible = "nordic,nrf-uart";
	status = "okay";
	current-speed = <115200>;
	tx-pin = <6>;
	rx-pin = <8>;
	rts-pin = <5>;
	cts-pin = <7>;
};

&uart1 {
	status = "okay";
	current-speed = <115200>;
	tx-pin = <14>;
	rx-pin = <16>;
	rts-pin = <13>;
	cts-pin = <15>;
	hl7800 {
		compatible = "swi,hl7800";
		status = "okay";
		label = "hl7800";
		mdm-reset-gpios = <&gpio1 15 0>;
		mdm-wake-gpios = <&gpio1 13 0>;
		mdm-pwr-on-gpios = <&gpio1 2 0>;
		mdm-fast-shutd-gpios = <&gpio1 14 0>;
		mdm-uart-dtr-gpios = <&gpio0 24 0>;
		mdm-vgpio-gpios = <&gpio1 11 0>;
		mdm-uart-dsr-gpios = <&gpio0 25 0>;
		mdm-uart-cts-gpios = <&gpio0 15 0>;
		mdm-gpio6-gpios = <&gpio1 12 0>;
	};
};

&i2c0 {
	status = "okay";
	sda-pin = <26>;
	scl-pin = <27>;
};

&spi0 {
	/* Cannot be used together with i2c0. */
	/* status = "okay"; */
	sck-pin = <27>;
	mosi-pin = <26>;
	miso-pin = <29>;
};

&qspi {
	status = "okay";
	sck-pin = <19>;
	io-pins = <20>, <21>, <22>, <23>;
	csn-pins = <17>;
	mx25r64: mx25r6435f@0 {
		compatible = "nordic,qspi-nor";
		reg = <0>;
		writeoc = "pp4io";
		readoc = "read4io";
		sck-frequency = <8000000>;
		label = "MX25R64";
		jedec-id = [c2 28 17];
		size = <67108864>;
		has-be32k;
		has-dpd;
		t-enter-dpd = <10000>;
		t-exit-dpd = <35000>;
	};
};

&flash0 {
	/*
	 * For more information, see:
	 * http://docs.zephyrproject.org/latest/guides/dts/index.html#flash-partitions
	 */
	partitions {
		compatible = "fixed-partitions";
		#address-cells = <1>;
		#size-cells = <1>;

		/* 96K */
		boot_partition: partition@0 {
			label = "mcuboot";
			reg = <0x000000000 0x00018000>;
		};
		/* 896K */
		slot0_partition: partition@18000 {
			label = "image-0";
			reg = <0x00018000 0x000E0000>;
		};

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

		/*
		 * Storage partition will be used by FCB/NVS
		 * if enabled. 30K
		 */
		storage_partition: partition@fa000 {
			label = "storage";
			reg = <0x000fa000 0x00006000>;
		};
	};
};

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

		/* 904KB */
		slot1_partition: partition@0 {
			label = "image-1";
			reg = <0x0000000 0x000E2000>;
		};

		/* 128KB */
		scratch_partition: partition@100000 {
			label = "image-scratch";
			reg = <0x00100000 0x00020000>;
		};

		/* 4MB starting halfway */
		lfs_partition: partition@400000 {
			label = "lfs_storage";
			reg = <0x00400000 0x000400000>;
		};
	};
};

&usbd {
	compatible = "nordic,nrf-usbd";
	status = "okay";
};

pm.yml:

#include <autoconf.h>
#include <devicetree_legacy_unfixed.h>

mcuboot:
  size: DT_FLASH_AREA_MCUBOOT_SIZE
  placement:
    before: [mcuboot_primary]

mcuboot_primary_app:
  # All images to be placed in MCUboot's slot 0 should be placed in this
  # partition
  span: [app]

mcuboot_primary:
  span: [mcuboot_pad, mcuboot_primary_app]

mcuboot_secondary:
  region: external_flash
  address: DT_FLASH_AREA_IMAGE_1_OFFSET
  size: DT_FLASH_AREA_IMAGE_1_SIZE

#ifndef CONFIG_BOOT_SWAP_USING_MOVE
mcuboot_scratch:
  region: external_flash
  address: DT_FLASH_AREA_IMAGE_SCRATCH_OFFSET
  size: DT_FLASH_AREA_IMAGE_SCRATCH_SIZE
#endif

lfs_storage:
  region: external_flash
  address: DT_FLASH_AREA_LFS_STORAGE_OFFSET
  size: DT_FLASH_AREA_LFS_STORAGE_SIZE

# Padding placed before image to boot
mcuboot_pad:
  # MCUboot pad must be placed before the 'spm' partition if that is present.
  # If 'spm' partition is not present, it must be placed before the 'app'.
  size: CONFIG_PM_PARTITION_SIZE_MCUBOOT_PAD
  placement:
    before: [mcuboot_primary_app]
    #ifdef CONFIG_FPROTECT
    align: { start: CONFIG_FPROTECT_BLOCK_SIZE }
#endif

partitions_pinnacle_100_dvk.yml (output):

app:
  address: 0x18200
  region: flash_primary
  size: 0xe1e00
external_flash:
  address: 0x0
  region: external_flash
  size: 0x800000
lfs_storage:
  address: 0x400000
  region: external_flash
  size: 0x400000
littlefs_storage:
  address: 0xfa000
  placement:
    before:
    - end
  region: flash_primary
  size: 0x6000
mcuboot:
  address: 0x0
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0x18000
mcuboot_pad:
  address: 0x18000
  placement:
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0x18000
  orig_span: &id001
  - mcuboot_pad
  - app
  region: flash_primary
  size: 0xe2000
  span: *id001
mcuboot_primary_app:
  address: 0x18200
  orig_span: &id002
  - app
  region: flash_primary
  size: 0xe1e00
  span: *id002
mcuboot_secondary:
  address: 0x0
  region: external_flash
  size: 0xe2000

[Simon]

Regarding the first question, I think mcubot_pad is the space reserved for the image header.

I need some more time for investigation and to answer the rest of the questions. You may experience delayed answers since we are low on staff during summer vacation.

Best regards,

Simon

[rerickson]

I would like to add one more question:

5. In a pm_static.yml can you use #include <devicetree_legacy_unfixed.h> so sizes and offsets can be set from the device tree defines like you can do in pm.yml?  I tried this with pm_static.yml and it doesnt seem to work.

[Håkon Alseth]

Hi,

 

1. Can you explain the mcuboot_pad?  Is it needed?  When I try to remove it, multi-image builds break.

 This is the header for mcuboot. Unfortunately, this isn't very widely documented, but it is mentioned in TEXT_SECTION_OFFSET:

https://docs.zephyrproject.org/1.12.0/reference/kconfig/CONFIG_TEXT_SECTION_OFFSET.html

2. When using mcuboot_pad, how can I get my mcuboot_secondary to match mcuboot_primary size more dynamically?  Currently I had to hack my board DTS partition size for slot_1 to get the size to match.

 You can take the generated "my_build_folder/partitions_$(BOARD).yml" file (named pm_static.yml if using ncs v1.2.0) and copy + rename it to your application_folder/pm_static.yml and it should be statically allocated per your .yml file, as described in the documentation for the partition manager:

http://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.3.0/nrf/scripts/partition_manager/partition_manager.html?highlight=pm_static#static-configuration 

If you require to change any sizes there, it should now be statically generated for each time you create a new build for your specific application.

  

3. Where is PM coming up with the 0xe2000 size for mcuboot_primary?  In my DTS, i have slot_0 set to a size of 0xe0000. mcuboot_pad is only 0x200, so why is mcuboot_primary padded by an extra 0x1e00?

Could you share the output from "ninja rom_report" (go into your build folder and call this from cmd.exe/terminal) ?

The 0x200 size is highly likely the vector table in this case, but the padding seems a bit off.

4. Why is the "storage" partition in my DTS getting renamed to littlefs_storage by PM?

 This is intentional, as commented in the nrf52840dk_nrf52840.dts file:

		/*
		 * 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>;
		};

rerickson said:

In a pm_static.yml can you use #include <devicetree_legacy_unfixed.h> so sizes and offsets can be set from the device tree defines like you can do in pm.yml?  I tried this with pm_static.yml and it doesnt seem to work.

This has to be in the yml format similar as shown in the generated build/partitions_$(BOARD).yml file. Could you explain more about what you're trying to achieve, and maybe attach the partitions_*.yml file so I can have a look?

 

Kind regards,

Håkon