b0 fails to boot using swap algorithm in SDK 3.2.1 in nrf5340

[AlejandroM]

Hello!

We are in the middle of an upgrade to 3.2.1, and we encounter the following issue using SB_CONFIG_MCUBOOT_MODE_SWAP_WITHOUT_SCRATCH, SB_CONFIG_MCUBOOT_MODE_SWAP_USING_MOVE & SB_CONFIG_MCUBOOT_MODE_SWAP_USING_OFFSET


Basically right after flashing `b0` fails to boot:

*** Booting nRF Connect SDK v3.2.1-d8887f6f32df ***
*** Using Zephyr OS v4.2.99-ec78104f1569 ***
Attempting to boot slot 0.
Attempting to boot from address 0x8200.
[00:00:00.000,854] <inf> bl_validation: Trying to get Firmware version
[00:00:00.001,129] <err> bl_validation: Invalid size or total_size in firmware info.
Failed to validate, permanently invalidating!
Attempting to boot slot 1.
Attempting to boot from address 0x18200.
[00:00:00.001,892] <inf> bl_validation: Trying to get Firmware version
[00:00:00.002,197] <err> bl_validation: Invalid size or total_size in firmware info.
Failed to validate, permanently invalidating!
No bootable image found. Aborting boot.

One of the main reasons we want to upgrade to 3.2.1 (qualification aside) is to get the new "OFFSET mcuboot algorithm" (SB_CONFIG_MCUBOOT_MODE_SWAP_USING_OFFSET),  since 2.9.0 does not have that we were using the MOVE algorithm ( SB_CONFIG_MCUBOOT_MODE_SWAP_USING_MOVE ), and that was working fine, until the upgrade.

Another weird thing we found is that (SB_CONFIG_MCUBOOT_MODE_OVERWRITE_ONLY) botos alright and allows us to do the updates ( but we want to move to SWAP using OFFSET)

We seem to have some space available in s0/s1


but not so much on b0

Any ideas? 

[Einar Thorsrud]

Hi,

Swap using offset requiers an additional page on the secondary slot. Can you show your full memory layout including the secondary slot?

Also, the error message is printed from here. Perhaps you can either check with a debugger or expand the printout to see exactly which check fails, and which sizes are compared?

[AlejandroM]

Hi Einar Thorsrud ,
After checking that code, I realized our PM_S0_SIZE & PM_S1_SIZE was wrong in our partition layout, so changing that let the `b0` boot correctly :) , but as you pointed out the OFFSET algorithm is still not working, we are missing something ( MOVE does now :)  ), but here is our partitioning layout:

b0:
  address: 0x0
  end_address: 0x8000
  placement:
    after:
    - start
  region: flash_primary
  size: 0x8000
b0_container:
  address: 0x0
  end_address: 0x8000
  orig_span: &id001
  - b0
  region: flash_primary
  size: 0x8000
  span: *id001

app:
  address: 0x28200
  end_address: 0x100000
  region: flash_primary
  size: 0xd7e00

mcuboot_primary:
  address: 0x28000
  end_address: 0x100000
  orig_span: &id005
  - mcuboot_pad
  - app
  region: flash_primary
  size: 0xd8000
  span: *id005
mcuboot_pad:
  address: 0x28000
  end_address: 0x28200
  placement:
    align:
      start: 0x4000
    before:
    - app
  region: flash_primary
  size: 0x200
mcuboot_primary_app:
  address: 0x28200
  end_address: 0x100000
  orig_span: &id006
  - app
  region: flash_primary
  size: 0xd7e00
  span: *id006

mcuboot_secondary:
  address: 0x00
  end_address: 0xd8000
  orig_span: &id007
  - mcuboot_secondary_pad
  - mcuboot_secondary_app
  span: *id007
  size: 0xd8000
  region: external_flash
  device: mx25r16

mcuboot_secondary_pad:
  address: 0x0
  end_address: 0x200
  placement:
    align:
      start: 0x4000
    before:
    - mcuboot_secondary_app
  device: mx25r16
  region: external_flash
  size: 0x200

mcuboot_secondary_app:
  address: 0x200
  end_address: 0xd8000
  region: external_flash
  size: 0xd7e00
  share_size:
  - app

# Both these partitions are for NetCore updates,
# so they go to ram memory for the b0n to apply them
mcuboot_primary_1:
  address: 0x0
  size: 0x40000
  device: flash_ctrl
  region: ram_flash
mcuboot_secondary_1:
  address: 0xd8000
  size: 0x40000
  device: mx25r16
  region: external_flash


external_flash:
  address: 0x0
  # end_address: 0x320000
  size: 0x200000
  device: mx25r16
  region: external_flash

nureva_uicr:
  address: 0xff8100
  end_address: 0xff8180
  placement:
    before:
      - provision
  region: otp
  size: 0x80
otp:
  address: 0xff8100
  end_address: 0xff8400
  region: otp
  size: 0x300
pcd_sram:
  address: 0x20000000
  end_address: 0x20002000
  placement:
    after:
    - start
  region: sram_primary
  size: 0x2000
provision:
  address: 0xff8180
  end_address: 0xff8400
  region: otp
  size: 0x280
ram_flash:
  address: 0x0
  end_address: 0x40000
  region: ram_flash
  size: 0x40000
rpmsg_nrf53_sram:
  address: 0x20070000
  end_address: 0x20080000
  placement:
    before:
    - end
  region: sram_primary
  size: 0x10000

s0:
  address: 0x8000
  end_address: 0x18000
  orig_span: &id002
  - s0_pad
  - mcuboot
  region: flash_primary
  size: 0x10000
  span: *id002
s0_pad:
  address: 0x8000
  end_address: 0x8200
  placement:
    after:
    - b0_container
    align:
      start: 0x4000
  region: flash_primary
  share_size:
  - mcuboot_pad
  size: 0x200
s0_image:
  address: 0x8200
  end_address: 0x18000
  orig_span: &id003
  - mcuboot
  region: flash_primary
  size: 0xfe00
  span: *id003
  share_size:
  - mcuboot
mcuboot:
  address: 0x8200
  end_address: 0x18000
  region: flash_primary
  size: 0xfe00

s1:
  address: 0x18000
  end_address: 0x28000
  orig_span: &id004
  - s1_pad
  - s1_image
  region: flash_primary
  size: 0x10000
  span: *id004
s1_pad:
  address: 0x18000
  end_address: 0x18200
  placement:
    align:
      start: 0x4000
  region: flash_primary
  share_size:
  - mcuboot_pad
  size: 0x200
s1_image:
  address: 0x18200
  end_address: 0x28000
  placement:
    after:
    - s1_pad
  region: flash_primary
  share_size:
  - mcuboot
  size: 0xfe00

settings_storage:
  address: 0x118000
  end_address: 0x120000
  placement:
    align:
      start: 0x4000
  region: external_flash
  size: 0x8000
future_use_placeholder:
  address: 0x120000
  end_address: 0x200000
  placement: 
    before:
    - end
  region: external_flash
  size: 0xe0000
sram_primary:
  address: 0x20002000
  end_address: 0x20070000
  region: sram_primary
  size: 0x6e000

( the S0/S1 size is fixed in this one )




We could use the `future_placeholder` for OFFSET, if needed.

[Edvin]

Hello,

I am sorry for the late reply. Einar needed to work on something else, so I will handle your ticket for now.

AlejandroM said:

but as you pointed out the OFFSET algorithm is still not working, we are missing something ( MOVE does now :)  ), but here is our partitioning layout:

I am not sure what you mean here. Can you please specify?

What is the current state of the issue? What do you see when you try to run it now?

Best regards,

Edvin

[AlejandroM]

Hi Edvin ,
Let me clarify, the issue with `b0` was resolved by adjusting the `PM_S0_SIZE` and `PM_S1_SIZE` size on the partition layout, the part that we have not resolved is using the OFFSET Algorithm, do you want me to add more information here, or shall I open a new ticket ?

[AlejandroM]

Well to avoid a bit of back and forth, the main issue with `OFFSET` is that basically we follow the same flow as with `MOVE`

1. Upload the updated firmware to secondary slot
2. Mark the secondary slot for testing ( pending: true )
3. Reset the Module to test image
4. OFFSET swap fails, and boots back the firmware in primary slot

The way it fails is by deleting the secondary slot and not performing the `test`

( I added some extra logging on mcuboot to try to debug, my VSCode debugger never stopped in the breakpoints on mcuboot code  :( :shrug: )

On the application side, when uploading, and marking them for test ( pending: true ), it does seem to account for the Offset initial sector used for swap



Same configuration with same flow using `SB_CONFIG_MCUBOOT_MODE_SWAP_USING_MOVE` works fine.. as soon as we replace it with `SB_CONFIG_MCUBOOT_MODE_SWAP_USING_OFFSET` it fails.

Another thing to note is that all Netcore updates also fail, but with no message, again with `MOVE` it all works.

Our sysbuild.conf

SB_CONFIG_BOOTLOADER_MCUBOOT=y
SB_CONFIG_NETCORE_APP_UPDATE=y
SB_CONFIG_PARTITION_MANAGER=y

### TURN THESE ON IF YOU WANT DFU
SB_CONFIG_DFU_MULTI_IMAGE_PACKAGE_BUILD=y
SB_CONFIG_DFU_MULTI_IMAGE_PACKAGE_APP=y
SB_CONFIG_DFU_MULTI_IMAGE_PACKAGE_NET=y
SB_CONFIG_DFU_MULTI_IMAGE_PACKAGE_MCUBOOT=n

SB_CONFIG_SECURE_BOOT_APPCORE=y
SB_CONFIG_SECURE_BOOT_NETCORE=y

# Required for new SDKs
SB_CONFIG_MCUBOOT_UPDATEABLE_IMAGES=2
SB_CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY=y
SB_CONFIG_MCUBOOT_MODE_SWAP_USING_OFFSET=y
SB_CONFIG_MCUBOOT_NRF53_MULTI_IMAGE_UPDATE=y

Our mcuboot/prj.conf:

#
# Copyright (c) 2022 Nordic Semiconductor
#
# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
#
CONFIG_MAIN_STACK_SIZE=10240

# CONFIG_MBEDTLS_CFG_FILE="mcuboot-mbedtls-cfg.h"

# The following configurations are required to support serial recovery
CONFIG_PCD_APP=y
CONFIG_SERIAL=y
CONFIG_MCUBOOT_SERIAL=y
CONFIG_BOOT_SERIAL_UART=y
CONFIG_BOOT_SERIAL_ENTRANCE_GPIO=y
CONFIG_BOOT_SERIAL_DETECT_DELAY=0
CONFIG_BOOT_SERIAL_IMG_GRP_IMAGE_STATE=y
CONFIG_MCUBOOT_SERIAL_DIRECT_IMAGE_UPLOAD=y
# Selecting CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY selects CONFIG_NRF53_MULTI_IMAGE_UPDATE and by its turn it would disable CONFIG_NRF53_RECOVERY_NETWORK_CORE.
# Netcore recovery is still possible as we have CONFIG_NRF53_MULTI_IMAGE_UPDATE and SB_CONFIG_NETCORE_APP_UPDATE and SB_CONFIG_SECURE_BOOT_NETCORE enabled.
# This allows to upload netcore and appcore images then reset only once. This was tested by recovering netcore from dtm_test to ipc_radio
CONFIG_NRF53_RECOVERY_NETWORK_CORE=n
CONFIG_NRF53_MULTI_IMAGE_UPDATE=y
CONFIG_GPIO=y
CONFIG_MCUBOOT_INDICATION_LED=y
# Automatically stay in the bootloader if no valid application is found
CONFIG_BOOT_SERIAL_NO_APPLICATION=y

# Config logger
CONFIG_LOG=y
CONFIG_LOG_MODE_MINIMAL=n
CONFIG_LOG_MODE_IMMEDIATE=y
CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=n
CONFIG_LOG_BACKEND_UART=n
CONFIG_RTT_CONSOLE=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_LOG_BACKEND_RTT=y
CONFIG_BOOT_BANNER=n
# CONFIG_SEGGER_RTT_BUFFER_SIZE_UP=16384

#CONFIG_LOG_DEFAULT_LEVEL=0
### Use info log level by default
CONFIG_MCUBOOT_LOG_LEVEL_INF=y
CONFIG_MCUBOOT_UTIL_LOG_LEVEL_INF=y
### Decrease footprint by ~4 KB in comparison to CBPRINTF_COMPLETE=y
CONFIG_CBPRINTF_NANO=y
CONFIG_NRF_RTC_TIMER_USER_CHAN_COUNT=0
### Use the minimal C library to reduce flash usage
CONFIG_MINIMAL_LIBC=y

# Flash
CONFIG_FLASH=y
CONFIG_FPROTECT=y
CONFIG_FLASH_SIMULATOR=y
CONFIG_FLASH_SIMULATOR_DOUBLE_WRITES=y
CONFIG_FLASH_SIMULATOR_STATS=n
CONFIG_BOOT_IMAGE_ACCESS_HOOKS=y
CONFIG_BOOT_ERASE_PROGRESSIVELY=y
# This means we must swap them and test images first
# and will revert firmware if that fails
CONFIG_BOOT_UPGRADE_ONLY=y

CONFIG_NORDIC_QSPI_NOR=y
CONFIG_NORDIC_QSPI_NOR_FLASH_LAYOUT_PAGE_SIZE=4096
CONFIG_NORDIC_QSPI_NOR_STACK_WRITE_BUFFER_SIZE=16

# CONFIG_MULTITHREADING=y
CONFIG_BOOT_MAX_IMG_SECTORS=1024

As you may notice we do non-simultaneous DFU, and we also have serial recovery, and the secondary slots are on external flash, so space is not a problem.