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.