Correct format of reg property in device tree for boot_partition

[nategreco]

I'm adding DFU over Bluetooth support to an existing application based on nRF Connect v2.3.0 following these instructions.  What the instructions lack (and possibly is a given for Peripheral LBS, although I don't readily see it) is the device tree definition of `boot_partion` that is required.

I've added the following block to my custom boards DTS file:

&flash0 {
	partitions {
        compatible = "fixed-partitions";
        boot_partition: partition@0 {
            label = "mcuboot";
			reg = <0x000000000 0x00010000>;
        };
    };
};

But get a warning from the nRF Connect VSCode extension that my defintion of `reg` is ill-formed:

It is saying the form is `addr addr size` as opposed to `addr size`.  Building it anyway I get the following failure:

devicetree error: 'reg' property in <Node /soc/flash-controller@4001e000/flash@0/partitions/partition@0 in 'C:/ncs/v2.3.0/zephyr/misc/empty_file.c'> has length 8, which is not evenly divisible by 12 (= 4*(<#address-cells> (= 2) + <#size-cells> (= 1))). Note that #*-cells properties come either from the parent node or from the controller (in the case of 'interrupts').

Suspecting that the warning is correct I find it builds without issue if I format it `addr addr size`, however, it fails at the very end:

c:/ncs/toolchains/v2.3.0/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.1.0/../../../../arm-zephyr-eabi/bin/ld.exe: zephyr\zephyr_pre0.elf section `rodata' will not fit in region `FLASH'
c:/ncs/toolchains/v2.3.0/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.1.0/../../../../arm-zephyr-eabi/bin/ld.exe: region `FLASH' overflowed by 5436 bytes

This isn't a shock because I didn't know what values to choose for the `addr addr size`  format.

So - My question is 1) What is the correct format for defining the reg property for an image partition? and 2) What should the default value be for a nRF52840 based board?

[Kazi Afroza Sultana]

Hello,

When you use MCUboot, the partition manager is used instead of device tree for partitions. So, use pm_static.yml instead of this.

Or even better, the partition manager will automatically change the partitioning, so you can just set mcuboot_CONFIG_PM_PARTITION_SIZE=0x10000

[nategreco]

Hi Kazi,

Thanks for the help - I've made some progress but still have a few questions.

I ended up adding a `child_image\mcuboot.conf` file with the single line:

CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x8000

 

But I still needed this section in my boards dts file:

&flash0 {
	partitions {
        compatible = "fixed-partitions";
        boot_partition: partition@0 {
            label = "mcuboot";
            reg = <0x000000000 0x000 0x8000>;
        };
    };
};

Otherwise, I get an error that the `boot_partition` node is not defined:

devicetree error: /chosen: undefined node label 'boot_partition'

With both in place the project builds the mcuboot and app images without error.  Flashing the merged.hex image with the nRF Programmer succeeds but then my app does not smart and there's no RTT output. I'm still looking into that.

[nategreco]

I'm hitting "Unable to find bootable image":

    if (fih_not_eq(fih_rc, FIH_SUCCESS)) {
        BOOT_LOG_ERR("Unable to find bootable image");

        mcuboot_status_change(MCUBOOT_STATUS_NO_BOOTABLE_IMAGE_FOUND);

        FIH_PANIC;
    }

My `merged.hex` has mcuboot imgage 0x0000 to 0x7B6B then app image 0x8000 onwards.  That aligns well my configuration above - But my question is - How do I tell where it's looking for the image?  It would be good to verify the mcuboot expects the app image at 0x8000.  Also - Would it arrive here if there was a signing issue with the app image?

[nategreco]

So I've tried both with `pm_static.yml` and letting the partition manager handle partitioning.

What I'm finding is the Addres range displayed in nRF Programmer for the app (loaded from merged.hex) is 0x200 off from the start address for the app in `partions.yml` in the build folder.  It seems to start at the end of the mcuboot image instead of after the `mcuboot_pad`. It seems like this is wrong, and possibly why I get the FIH_PANIC state ate boot.  But I'm clear why the start address in the hex and the partions file doesn't align.


**Update**

After some further testing, it's clear `CONFIG_MCUMGR_CMD_IMG_MGMT` causes the FIH_PANIC condition described above. Looking at my `partions.yml`, they are *nearly* exactly the same with and without this in my prj.conf except `mcuboot_pad` and `app` are swapped after `orig_span` under `mcu_bootprimary`

I would think `mcuboot_pad` belongs before `app`, however, I don't know what's making it change the order? This is the `partions.yml` after I add image management:

Fullscreen partitions.txt Download

app:
  address: 0x8200
  end_address: 0x84000
  region: flash_primary
  size: 0x7be00
mcuboot:
  address: 0x0
  end_address: 0x8000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0x8000
mcuboot_pad:
  address: 0x8000
  end_address: 0x8200
  placement:
    align:
      start: 0x1000
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0x8000
  end_address: 0x84000
  orig_span: &id001
  - app
  - mcuboot_pad
  region: flash_primary
  sharers: 0x1
  size: 0x7c000
  span: *id001
mcuboot_primary_app:
  address: 0x8200
  end_address: 0x84000
  orig_span: &id002
  - app
  region: flash_primary
  size: 0x7be00
  span: *id002
mcuboot_secondary:
  address: 0x84000
  end_address: 0x100000
  placement:
    after:
    - mcuboot_primary
    align:
      start: 0x1000
    align_next: 0x1000
  region: flash_primary
  share_size:
  - mcuboot_primary
  size: 0x7c000
sram_primary:
  address: 0x20000000
  end_address: 0x20040000
  region: sram_primary
  size: 0x40000

Also - W/o `MCUMGR_CMD_IMG_MGMT` the nRF Connect app reports `[McuMgr] Error : NOT_SUPPORTED (8)` when trying to upgrade via DFU. I can only assume this is because of lack of image management support.

[nategreco]

So just another comment for others that might be seeing the same issue.

The 'addr addr size' structure for the `reg` property suggested by the VSCode editor produced a warning by the compiler that #address-cells and #size-cells properties were missing and defaults were used.  If you define those, then the editor expects a 'addr size' stucture.  If you use 'addr size' w/o the #address-cells and #size-sells properties then you end up with the compile error I had above about it not being divisible by 12.

In the end this was needed in my boards .dts even though I did use `CONFIG_PM_PARTITION_SIZE_MCUBOOT` in the childe image .conf:

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

		boot_partition: partition@0 {
				label = "mcuboot";
				reg = <0x000000000 0x00008000>;
		};
	};
};