mcuboot can't find bootable image when multi-image configuration is used

[Jason Wright]

Hi, I am looking to use mcuboot to manage 2 separate images. The idea is that under certain conditions, image 1 would jump to image 2.

To test the idea, I am using the zephyr hello_world sample with minimal modifications:

prj.conf:

CONFIG_BOOTLOADER_MCUBOOT=y

CONFIG_FLASH=y
CONFIG_IMG_MANAGER=y
CONFIG_UPDATEABLE_IMAGE_NUMBER=2

CONFIG_NRF53_UPGRADE_NETWORK_CORE=n

child_image/mcuboot.conf:

CONFIG_UPDATEABLE_IMAGE_NUMBER=2

pm_static.yml:

app:
  address: 0x10200
  region: flash_primary
  size: 0x1fe00
mcuboot:
  address: 0x0
  region: flash_primary
  size: 0x10000
mcuboot_pad:
  address: 0x10000
  region: flash_primary
  size: 0x200

mcuboot_primary:
  address: 0x10000
  orig_span: &id001
  - mcuboot_pad
  - app
  region: flash_primary
  size: 0x20000
  span: *id001
  
mcuboot_primary_app:
  address: 0x10200
  orig_span: &id002
  - app
  region: flash_primary
  size: 0x1fe00
  span: *id002

mcuboot_primary_1:
  address: 0x30000
  size: 0x20000
  region: flash_primary
mcuboot_secondary:
  address: 0x50000
  size: 0x20000
  region: flash_primary
mcuboot_secondary_1:
  address: 0x70000
  size: 0x20000
  region: flash_primary
EMPTY_0:
  address: 0x90000
  size: 0x70000
  region: flash_primary

On boot, I get the following logs from mcuboot:

*** Booting Zephyr OS build v3.1.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
W: Failed reading image headers; Image=0
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
W: Failed reading image headers; Image=1
E: Image in the primary slot is not valid!
E: Unable to find bootable image

And my application does not boot.

I am using NCS v2.1.0 and nRF5340 DK, along with the nRF Connect VSCode extension for building and flashing.

[dejans]

Hi Jason,

Could you provide more information about your use case?

Best regards,
Dejan

[Jason Wright]

Hi Dejan,

For my use case, I want to support an updateable application with signing and BLE-only transport (SMP server). In the field, there is no possibility of hardware access to the device, so the concern is that having only a single image containing SMP server as part of the application could lead to a bricked device if the application fails to boot properly.

So the idea is to have a "recovery" image and a "main" image, where the recovery image is essentially just SMP sever, but will jump to the "main" image (mcuboot's image 1 slot 0 -- mcuboot_primary_1 partition) after a command is sent or timeout occurs. This way we do not depend on the application itself to provide the upgrade transport.

Let me know if that helps.

Jason

[dejans]

Hi Jason,

I would suggest that you use regular MCUBoot functionality with SMP server as part of the application. In this case it would not be necessary to use pm_static.yml, as partition manager can do partitioning for you. The disadvantages of your idea would be the need for additional flash space and issues with static partitioning. 

Best regards,
Dejan

[Jason Wright]

Do you think Partition Manager is the issue here? I understand the downsides, but it would be worth it for our use case (bricked or non-upgradable device is unacceptable).

I would like to understand what's going wrong as this looks to be a supported use case of mcuboot, any suggestions for how to troubleshoot further?

[dejans]

Hi,

It seems that your use case might be supported. However, additional discussion with developers would be needed to consider potential options and approaches. I'll get back to you when I get new information, hopefully till the end of this week.

Best regards,
Dejan