MCUBoot, Zephyr, and static partition manager

Hi!
We are currently migrating our SD-based SDK code to Zephyr, on nrf52833 boards.

While we have finally been able to get MCUBoot (CONFIG_BOOTLOADER_MCUBOOT=y) to run with a static partition file, we consistently get the following log on runtime, and the app is never started:

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

I have a few questions regarding this:

  1. 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?
  2. 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?
  3. In the default partition manager (As you can see below), alignment is consistently used ("align: start: 0x1000"). Is there a specific reason for this?
  4. The big one - what is the reason that the aforementioned mcuboot print is received?

Thanks ahead of time!

Roi

pm_static.yml:

app:
  address: 0xc200
  end_address: 0x3e000
  region: flash_primary
  size: 0x31e00
mcuboot:
  address: 0x0
  end_address: 0xc000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xc000
mcuboot_pad:
  address: 0xc000
  end_address: 0xc200
  placement:
    align:
      start: 0x1000
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0xc000
  end_address: 0x3e000
  orig_span: &id001
  - mcuboot_pad
  - app
  region: flash_primary
  sharers: 0x1
  size: 0x32000
  span: *id001
mcuboot_primary_app:
  address: 0xc200
  end_address: 0x3e000
  orig_span: &id002
  - app
  region: flash_primary
  size: 0x31e00
  span: *id002
mcuboot_secondary:
  address: 0x3e000
  end_address: 0x70000
  placement:
    after:
    - mcuboot_primary
    align:
      start: 0x1000
  region: flash_primary
  share_size:
  - mcuboot_primary
  size: 0x32000
scratch_partition:
  address: 0x70000
  end_address: 0x7a000
  placement:
    align:
      start: 0x1000
  region: flash_primary
  size: 0xa000
settings_storage:
  address: 0x7a000
  end_address: 0x7c000
  placement:
    align:
      start: 0x1000
  region: flash_primary
  size: 0x2000
storage_partition:
  address: 0x7c000
  end_address: 0x80000
  placement:
    align:
      start: 0x1000
  region: flash_primary
  size: 0x4000
sram_primary:
  address: 0x20000000
  end_address: 0x20020000
  region: sram_primary
  size: 0x20000
dts overlay:
/delete-node/ &storage_partition;
&flash0 {

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

boot_partition: partition@0 {
label = "mcuboot";
reg = <0x00000000 0xC000>;
};
slot0_partition: partition@c000 {
label = "image-0";
reg = <0x0000C000 0x32000>;
};
slot1_partition: partition@3e000 {
label = "image-1";
reg = <0x0003E000 0x32000>;
};
scratch_partition: partition@70000 {
label = "image-scratch";
reg = <0x00070000 0xA000>;
};
settings_partition: partition@7a000 {
label = "settings";
reg = <0x0007A000 0x00002000>;
};
storage_partition: partition@7c000 {
label = "storage";
reg = <0x0007c000 0x00004000>;
};
};
};
mcuboot.conf (merged via edit to CMakeLists):
CONFIG_DISABLE_FLASH_PATCH=y
CONFIG_BOOT_SIGNATURE_KEY_FILE="/mcuboot/skey.pem"
CONFIG_UART_CONSOLE=n
CONFIG_LOG_BACKEND_UART=n
CONFIG_LOG=y
CONFIG_LOG_MODE_MINIMAL=y
CONFIG_PRINTK=n
CONFIG_LOG_PRINTK=n
CONFIG_STDOUT_CONSOLE=n
CONFIG_RTT_CONSOLE=y
CONFIG_BOOT_BANNER=y
CONFIG_USE_SEGGER_RTT=y
  • Hi Sigurd,

    1. 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
    2. 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.\
    3. 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

  • 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

  • Hi!
    Was finally able to make this happen by:

    1. Removing the addition lines from cmake
    2. Moving mcuboot.conf to child_image subfolder
    3. Configuring in /ncs/bootloader/mcuboot/boot/zephyr/dts.overlay to use our board's UART pins in mcuboot
    4. 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!

    Roi

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

  • Roiger said:

    Hi!
    Was finally able to make this happen by:

    1. Removing the addition lines from cmake
    2. Moving mcuboot.conf to child_image subfolder
    3. Configuring in /ncs/bootloader/mcuboot/boot/zephyr/dts.overlay to use our board's UART pins in mcuboot
    4. 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!

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

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

    From Multi Image builds:

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

    Roiger said:
    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.\

    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%
    

    Roiger said:
    So should I remove the flash redefinition section entirely?

    Yes

    Roiger said:
    How would I go about marking the settings partition for code (        zephyr,settings-partition = &settings_partition;)?

    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

Related