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

[Jason Wright]

Thank you Dejan, I'll wait for your update.

[dejans]

Hi Jason,

Described way of having main and recovery images as well as update support for the application is not supported at the moment. However, you might still be able to achieve your goal. As this is design decision, you would need to be aware of its potential implications. You can find some suggestions on similar topic in this discussion.

Best regards,
Dejan