MCUBoot, Zephyr, and static partition manager

RE: MCUBoot, Zephyr, and static partition manager

Roiger — Thu, 09 Mar 2023 17:01:18 GMT

OK we are veering a bit off subject - so I will close this ticket and open a new one on this specific problem.
Thanks very much Sigurd!

RE: MCUBoot, Zephyr, and static partition manager

Roiger — Thu, 09 Mar 2023 11:01:18 GMT

I fear not - because I am still receiving "bt_settings: settings_subsys_init failed (err -45)"

RE: MCUBoot, Zephyr, and static partition manager

Sigurd Hellesvik — Tue, 07 Mar 2023 10:59:58 GMT

From Bluetooth Persistent storage:

CONFIG_BT_SETTINGS=y
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_NVS=y
CONFIG_SETTINGS=y

I also find these configurations in many of our Bluetooth samples

If I build the hello world sample with these configurations:

CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_BT=y

CONFIG_BT_SETTINGS=y
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_NVS=y
CONFIG_SETTINGS=yONFIG_SETTINGS=y

I get the following partition_manager_report:

  flash_primary (0x100000 - 1024kB): 
+-------------------------------------------------+
| 0x0: mcuboot (0xc000 - 48kB)                    |
+---0xc000: mcuboot_primary (0x79000 - 484kB)-----+
| 0xc000: mcuboot_pad (0x200 - 512B)              |
+---0xc200: mcuboot_primary_app (0x78e00 - 483kB)-+
| 0xc200: app (0x78e00 - 483kB)                   |
+-------------------------------------------------+
| 0x85000: mcuboot_secondary (0x79000 - 484kB)    |
| 0xfe000: settings_storage (0x2000 - 8kB)        |
+-------------------------------------------------+

  sram_primary (0x40000 - 256kB): 
+--------------------------------------------+
| 0x20000000: sram_primary (0x40000 - 256kB) |
+--------------------------------------------+

I see that with this, I can still not select it as chosen.

But I think you do not need to choose it, as Bluetooth LE will use this to store its persistent data at that point automatically.

Does that fix your issue?

Regards,
Sigurd Hellesvik

RE: MCUBoot, Zephyr, and static partition manager

Roiger — Tue, 07 Mar 2023 10:46:36 GMT

BT settings (so LTKs and such)

RE: MCUBoot, Zephyr, and static partition manager

Sigurd Hellesvik — Tue, 07 Mar 2023 10:35:52 GMT

I will have a look at how to do that, but first:

Quick question: What do you intend to use settings for?
NVS? Bluetooth? Something else?

Regards,
Sigurd Hellesvik

RE: MCUBoot, Zephyr, and static partition manager

Roiger — Tue, 07 Mar 2023 10:06:10 GMT

OK, but if I remove the flash redefinition entirely, the settings_partition will no longer exist, and I will not be able to choose it for settings in "chosen"

RE: MCUBoot, Zephyr, and static partition manager

Sigurd Hellesvik — Tue, 07 Mar 2023 07:46:09 GMT

[quote user="Roiger"]

Hi!
Was finally able to make this happen by:

Removing the addition lines from cmake
Moving mcuboot.conf to child_image subfolder
Configuring in /ncs/bootloader/mcuboot/boot/zephyr/dts.overlay to use our board's UART pins in mcuboot
Configuring UART logging for MCUBoot

After this, I receive the following message:

*** Booting Zephyr OS build v3.2.99-ncs1 ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
I: Bootloader chainload address offset: 0x9000
I: Jumping to the first image slot

However - our app still doesnt run after this, but that is a different question.

Thanks very much!

[/quote]

Good job!
And thanks for posting a detailed explanation of what you did.

[quote user="Roiger"]How would I go about adding an overlay for mcuboot without having to alter /ncs/bootloader/mcuboot/boot/zephyr/dts.overlay?[/quote]

From Multi Image builds:

So child_image/mcuboot/boards/board_name.overlay.
Or just child_image/mcuboot.overlay

[quote user="Roiger"]My question was if it matters how much empty space exists after MCUboot, per your suggestion. You stated that I may downsize the partition from default 48 KB to 0x9000 (since MCUBoot size for us is currently 0x871b if I recall correctly). My question was if there is some "must" for MCUBoot parition to be the exact size of the actual MCUBoot.\[/quote]

The partition may be larger than the actual MCUboot build.

And it often has to be.
I know that for example for the nRF5340 or the nRF9160, the MCUboot can not share codepages with the application, for security.
I do not know exactly how this works for the nRF52833, but I will try to figure it out. See Partition Manager not using flash efficiently for some discussion on the MCUboot partitioning.

In your build log, you can see an overview of the MCUboot partition:

[190/190] Linking C executable zephyr/zephyr.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:       33676 B        48 KB     68.51%
             RAM:       17792 B       256 KB      6.79%
        IDT_LIST:          0 GB         2 KB      0.00%

[quote user="Roiger"]So should I remove the flash redefinition section entirely?[/quote]

Yes

[quote user="Roiger"]How would I go about marking the settings partition for code ( zephyr,settings-partition = &settings_partition;)?[/quote]

Setting "chosen" are still done in dts overlays.
For example, if you need to add external flash for the partition manager:

/ {
	chosen {
		nordic,pm-ext-flash = &mx25r64;
	};
};

Regards,
Sigurd Hellesvik

RE: MCUBoot, Zephyr, and static partition manager

Roiger — Mon, 06 Mar 2023 16:36:51 GMT

How would I go about adding an overlay for mcuboot without having to alter /ncs/bootloader/mcuboot/boot/zephyr/dts.overlay?

RE: MCUBoot, Zephyr, and static partition manager

Roiger — Mon, 06 Mar 2023 16:35:42 GMT

Hi!
Was finally able to make this happen by:

Removing the addition lines from cmake
Moving mcuboot.conf to child_image subfolder
Configuring in /ncs/bootloader/mcuboot/boot/zephyr/dts.overlay to use our board's UART pins in mcuboot
Configuring UART logging for MCUBoot

After this, I receive the following message:

However - our app still doesnt run after this, but that is a different question.

Thanks very much!

Roi

RE: MCUBoot, Zephyr, and static partition manager

Roiger — Mon, 06 Mar 2023 13:00:08 GMT

Reegarding the override - I think the CMake line simply appends:

if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/mcuboot.conf")
list(APPEND mcuboot_OVERLAY_CONFIG
"${CMAKE_CURRENT_SOURCE_DIR}/mcuboot.conf"
)
endif()

and I can see in the build log that it merges mcuboot.conf

RE: MCUBoot, Zephyr, and static partition manager

Roiger — Mon, 06 Mar 2023 12:52:47 GMT

Hi Sigurd,

I have tried with the child_image folder as suggested - it now seems that it is not working at all, or at least not logging the boot message to RTT as it did before
My question was if it matters how much empty space exists after MCUboot, per your suggestion. You stated that I may downsize the partition from default 48 KB to 0x9000 (since MCUBoot size for us is currently 0x871b if I recall correctly). My question was if there is some "must" for MCUBoot parition to be the exact size of the actual MCUBoot.\
So should I remove the flash redefinition section entirely? How would I go about marking the settings partition for code ( zephyr,settings-partition = &settings_partition;)?

Thanks!

Roi

RE: MCUBoot, Zephyr, and static partition manager

Sigurd Hellesvik — Mon, 06 Mar 2023 12:26:44 GMT

I see now that you write:

[quote user=""]mcuboot.conf (merged via edit to CMakeLists):[/quote]

How do you merge this?

I suspect you overwrite default MCUboot configurations instead of overlaying them.
This might cause you to miss flash drivers (CONFIG_FLASH) in your MCUboot configuration.

Instead of adding mcuboot.conf via CMake, try to use a child_image/ folder instead. (docs and sample)

[quote user="Roiger"]I understand from your comment that I may resize the static partition for mcuboot according to the actual size - does it mean I HAVE to for mcuboot to work?[/quote]

I do not understand the question.

If you use a single bootloader, the partitioning must never change when doing DFU.

[quote user="Roiger"]In the DTS overlay - does that mean that image-0 needs to include the mcuboot_pad or not?[/quote]

If you use MCUboot, the Partition Manager will be enabled.
The partition manager will override any DTS overlays for partitioning. => The DTS overlay will best case, be ignored.

Regards,
Sigurd Hellesvik

RE: MCUBoot, Zephyr, and static partition manager

Roiger — Sun, 05 Mar 2023 12:40:05 GMT

Hi,
I have in addition changed the static partitioning + DTS overlay to match the smaller MCUBoot + enlarged CONFIG_BOOT_MAX_IMG_SECTORS to 256 per your suggestion:

pm_static.yml:

app:
  address: 0x9200
  end_address: 0x3b000
  region: flash_primary
  size: 0x31e00
mcuboot:
  address: 0x0
  end_address: 0x9000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0x9000
mcuboot_pad:
  address: 0x9000
  end_address: 0x9200
  placement:
    align:
      start: 0x1000
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0x9000
  end_address: 0x3b000
  orig_span: &id001
  - mcuboot_pad
  - app
  region: flash_primary
  sharers: 0x1
  size: 0x32000
  span: *id001
mcuboot_primary_app:
  address: 0x9200
  end_address: 0x3b000
  orig_span: &id002
  - app
  region: flash_primary
  size: 0x31e00
  span: *id002
mcuboot_secondary:
  address: 0x3b000
  end_address: 0x6d000
  placement:
    after:
    - mcuboot_primary
    align:
      start: 0x1000
  region: flash_primary
  share_size:
  - mcuboot_primary
  size: 0x32000
scratch_partition:
  address: 0x6d000
  end_address: 0x77000
  placement:
    align:
      start: 0x1000
  region: flash_primary
  size: 0xa000
settings_storage:
  address: 0x77000
  end_address: 0x79000
  placement:
    align:
      start: 0x1000
  region: flash_primary
  size: 0x3000
storage_partition:
  address: 0x7A000
  end_address: 0x80000
  placement:
    align:
      start: 0x1000
  region: flash_primary
  size: 0x6000
sram_primary:
  address: 0x20000000
  end_address: 0x20020000
  region: sram_primary
  size: 0x20000

DTS (relevant part):

/delete-node/ &boot_partition;
/delete-node/ &slot0_partition;
/delete-node/ &slot1_partition;
/delete-node/ &scratch_partition;
/delete-node/ &storage_partition;
&flash0 {

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

		boot_partition: partition@0 {
			label = "mcuboot";
			reg = <0x00000000 0x9000>;
		};
		slot0_partition: partition@9000 {
			label = "image-0";
			reg = <0x00009000 0x31e00>;
		};
		slot1_partition: partition@3b000 {
			label = "image-1";
			reg = <0x0003B000 0x32000>;
		};
		scratch_partition: partition@6d000 {
			label = "image-scratch";
			reg = <0x0006D000 0xA000>;
		};
		settings_partition: partition@77000 {
			label = "settings";
			reg = <0x00077000 0x00003000>;
		};
        storage_partition: partition@7a000 {
			label = "storage";
			reg = <0x0007A000 0x00006000>;
		};
	};
};

I am still receiving the error of 256 sectors being too small

RE: MCUBoot, Zephyr, and static partition manager

Roiger — Sun, 05 Mar 2023 11:59:26 GMT

Hi Sigurd!

Our SDK is 2.2.0, and our hardware is custom hardware but is based on nrf52833 as the MCU.

When I raised CONFIG_BOOT_MAX_IMG_SECTORS to 256 in mcuboot.conf, I still get the following:

00> *** Booting Zephyr OS build v3.2.99-ncs1 ***
00> I: Starting bootloader
00> W: Failed reading sectors; BOOT_MAX_IMG_SECTORS=256 - too small?
00> W: Cannot upgrade: not a compatible amount of sectors
00> E: Unable to find bootable image

We do not have external flash.
Thanks for the explanation about alignment and pad! A few followup questions:
1. I understand from your comment that I may resize the static partition for mcuboot according to the actual size - does it mean I HAVE to for mcuboot to work?
2. In the DTS overlay - does that mean that image-0 needs to include the mcuboot_pad or not?

Thanks!

Roi

RE: MCUBoot, Zephyr, and static partition manager

Sigurd Hellesvik — Fri, 03 Mar 2023 13:12:16 GMT

Hi,

I took the liberty to clean up your post using Insert->Code.

For us to help you with this in the best possible way, please list the following information:

SDK Version
Development Kit Version
Do you use custom hardware or code?

Tip:
VS Code -> Memory Report -> Partitions is handy for looking at MCUboot partitioning.
I took your configurations and added them to the hello world example. v2.2.0, nrf52833dk_nrf52833.
Then from Actions->Memory Report->Partitions:

Alternatively, I personally prefer the command line: "west build -t partition_manager_report":

Now, onto your questions:

[quote user=""]I have created the partition manager file (pm_static.yml) from the original build of our project, and added partitions to match our dts overlay (both are at bottom). The default setup causes s.t. the bootloader. which is much smaller than the default of 0xC000 = 48 KB for MCUboot, to sit apart from the mcuboot_pad and the app more than needed (see picture from nrfConnect Programmer below). What is the correct way to work with this?[/quote]

You can change the size of the MCUboot partition in the static partitioning.
From the build log, we can see how much space your MCUboot image is using:

Memory region         Used Size  Region Size  %age Used
           FLASH:       34652 B        48 KB     70.50%
             RAM:       23808 B       128 KB     18.16%
        IDT_LIST:          0 GB         2 KB      0.00%

I suggest you try configuring MCUboot to use less space and then set the partition to 32KiB (0x8000).
Yes, changing the partition size means you must manually move all the other partitions.
See the prj.conf of the machine learning example for tips on decreasing the footprint.

FYI: Do not give up on static partitioning, though. If you use a single bootloader, static partitioning is mandatory.

[quote user=""]If I try to remove the mcuboot_pad totally, I consistently receive a failure of the static partition manager on build: "Partition manager failed: End of last partition is after last valid address". Why is this? Is the pad a must?[/quote]

I think the pad is where MCUboot stores metadata about images.
So yes, you must use mcuboot_pad.

[quote user=""]In the default partition manager (As you can see below), alignment is consistently used ("align: start: 0x1000"). Is there a specific reason for this?[/quote]

Is it possible to change the flash page size of nrf52

For the FICR.INFO.CODEPAGESIZE for nrf5340, it says it should be 0x1000. I kind of would expect the same in FICR.CODEPAGESIZE for the nrf52833, but it is not. Unsure if it is possible to change it or if this is a documentation bug.
However, I think it is a good idea to align it with 0x1000 either way, as I think most of our partitioning does this by default, and it can be argued using 0x1000 alignment will make the project more portable.

[quote user=""]The big one - what is the reason that the aforementioned mcuboot print is received?[/quote]

In my experience, the error "W: Failed reading sectors; BOOT_MAX_IMG_SECTORS=128 - too small?" can mean two things:

CONFIG_BOOT_MAX_IMG_SECTORS is too small. Try setting this to 256 in mcuboot.conf.
The external flash driver has not been initialized for MCUboot.
Have you configured Using external flash memory partitions, and more specifically, External flash memory partitions?

Regards,
Sigurd Hellesvik

RE: MCUBoot, Zephyr, and static partition manager

Roiger — Thu, 02 Mar 2023 15:04:18 GMT

Forgot to add image from nrfConnect Programmer: