Direct XIP + External QSPI

[Roedy]

NCS v2.6.0, NRF5340dk

I'm trying to configure a project that uses mcuboot with direct XIP with the external QSPI flash.  I've been looking at examples in 

ncs/v2.6.0/nrf/tests/modules/mcuboot/external_flash
ncs/v2.6.0/nrf/tests/modules/mcuboot/direct_xip
ncs/v2.6.0/nrf/samples/nrf5340/extxip_smp_svr

The partition manager is having time creating partitions and throwing errors that memory regions are not aligned, so I've been using this as a guideline  Partition Manager Error w/ Direct XIP and MCUboot enabled

This is the process I've been using to build

Starting with the "external_flash" example:

1.  copy the linker script from ncs/v2.6.0/nrf/samples/nrf5340/extxip_smp_svr/linker_arm_extxip.ld

2. create a VERSION file for cmake builds

VERSION_MAJOR = 0
VERSION_MINOR = 1
PATCHLEVEL = 11
VERSION_TWEAK = 0
EXTRAVERSION =

3. modify prj.conf

CONFIG_ZTEST=y

CONFIG_BOOTLOADER_MCUBOOT=y

CONFIG_MCUBOOT_BOOTLOADER_MODE_DIRECT_XIP=y
CONFIG_FLASH=y
CONFIG_HAVE_CUSTOM_LINKER_SCRIPT=y
CONFIG_CUSTOM_LINKER_SCRIPT="linker_arm_extxip.ld"
CONFIG_XIP=y
CONFIG_NORDIC_QSPI_NOR_XIP=y

3. modify child_image/prj.conf

# MCUboot requires a large stack size, otherwise an MPU fault will occur
CONFIG_MAIN_STACK_SIZE=10240

# Enable flash operations
CONFIG_FLASH=y

# This must be increased to accommodate the bigger images.
CONFIG_BOOT_MAX_IMG_SECTORS=256

# Use minimal C library instead of the Picolib
CONFIG_MINIMAL_LIBC=y

CONFIG_BOOT_DIRECT_XIP=y
CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x10000

4. create a pm_static.yml with my custom partitions

nvs_storage:
  address: 0xfa000
  end_address: 0xfc000
  region: flash_primary
  size: 0x2000
settings_storage:
  address: 0xfc000
  end_address: 0xff000
  region: flash_primary
  size: 0x3000
id_storage:
  address: 0xff000
  end_address: 0x100000
  region: flash_primary
  size: 0x1000

5. generate a new pm_static.yml

 west build -b nrf5340dk_nrf5340_cpuapp -t partition_manager_report --pristine
cp pm_static.yml pm_static.yml.bak
cp build/partitions.yml pm_static.yml

6. Modify the pm_static.yml to include mcuboot_secodary_app and mcuboot_secondary_pad

app:
  address: 0x10200
  end_address: 0xfa000
  region: flash_primary
  size: 0xe9e00
external_flash:
  address: 0xea000
  end_address: 0x800000
  region: external_flash
  size: 0x716000
id_storage:
  address: 0xff000
  end_address: 0x100000
  region: flash_primary
  size: 0x1000
mcuboot:
  address: 0x0
  end_address: 0x10000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0x10000
mcuboot_pad:
  address: 0x10000
  end_address: 0x10200
  placement:
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0x10000
  end_address: 0xfa000
  orig_span: &id001
  - app
  - mcuboot_pad
  region: flash_primary
  size: 0xea000
  span: *id001
mcuboot_primary_app:
  address: 0x10200
  end_address: 0xfa000
  orig_span: &id002
  - app
  region: flash_primary
  size: 0xe9e00
  span: *id002
mcuboot_secondary:
  address: 0x0
  device: DT_CHOSEN(nordic_pm_ext_flash)
  end_address: 0xea000
  orig_span: &id003
  - mcuboot_secondary_pad
  - mcuboot_secondary_app
  placement:
    align:
      start: 0x4
  region: external_flash
  share_size:
  - mcuboot_primary
  size: 0xea000
  span: *id003
mcuboot_secondary_pad:
  address: 0x0
  device: DT_CHOSEN(nordic_pm_ext_flash)
  end_address: 0x200
  align:
    start: 0x4000
  region: external_flash
  share_size:
  - mcuboot_pad
  size: 0x200
mcuboot_secondary_app:
  address: 0x200
  end_address: 0xea000
  device: DT_CHOSEN(nordic_pm_ext_flash)
  placement:
    after:
    - mcuboot_secondary_pad
  region: external_flash
  share_size:
  - mcuboot_primary_app
  size: 0xe9e00

nvs_storage:
  address: 0xfa000
  end_address: 0xfc000
  region: flash_primary
  size: 0x2000
otp:
  address: 0xff8100
  end_address: 0xff83fc
  region: otp
  size: 0x2fc
pcd_sram:
  address: 0x20000000
  end_address: 0x20002000
  placement:
    after:
    - start
  region: sram_primary
  size: 0x2000
rpmsg_nrf53_sram:
  address: 0x20070000
  end_address: 0x20080000
  placement:
    before:
    - end
  region: sram_primary
  size: 0x10000
settings_storage:
  address: 0xfc000
  end_address: 0xff000
  region: flash_primary
  size: 0x3000
sram_primary:
  address: 0x20002000
  end_address: 0x20070000
  region: sram_primary
  size: 0x6e000

7. Modify linker script with new external flash memory address

MEMORY
{
     EXTFLASH (wx) : ORIGIN = 0x10ea000, LENGTH = 0x716000
}

#include <zephyr/arch/arm/cortex_m/scripts/linker.ld>

8. Build/flash using vscode

Results:

The application builds and programs, however there is no output on my terminal for either the app core or the net core

Memory report looks like what I'd expect.  I'm surprised the mcuboot_secondary_pad isn't in the correct span, but the address is correct

Any assistance debugging this would be appreciated

[Roedy]

I think it's worth asking the question: is this even possible?  The example and documentation https://docs.nordicsemi.com/bundle/ncs-2.6.0/page/nrf/device_guides/working_with_nrf/nrf53/qspi_xip_guide.html seems to suggest that external XIP is for relocating *some* of the code into external flash.

I want the *entire* secondary slot XIP from external memory. Our system has some unique constraints.  We're using XIP because we want our application to have a backup slot that can be run if the primary slot is corrupted.  Using just the primary flash, this works as expected but we're running out of space, which is why we want the secondary slot in external.

In addition, we have some product requirements that would make it very tough for us to break the application up into internal/external portions of a single slot as demonstrated in the extxip_smp_svr example.

[Sigurd Hellesvik]

Roedy said:

I think it's worth asking the question: is this even possible?

No, you cannot run the entire secondary slot from external memory.

Some amount of code must run in internal flash, such as code in interrupt contexts.

[Sigurd Hellesvik]

Roedy said:

We're using XIP because we want our application to have a backup slot that can be run if the primary slot is corrupted.

Cant you just swap in this case?

[Roedy]

It's been a while, but if I remember correctly, I programmed the primary and secondary slots and then used nrfjprog to corrupt the primary slot. Instead of swapping, MCUBOOT just said that there were no valid images. 

I think this was back in ncs 2.1.0, so things may have changed since then?  Or maybe there was an mcuboot kconfig that I missed?

[Sigurd Hellesvik]

MCUboot does not have any logic to detect failing images and swapping, I think.

I did not think Direct-xip had this feature either, but I am unsure about this I must admit.

Did you test the corrupting of primary slot for Direct-XIP?

[Roedy]

Yes, It worked perfectly!  When I corrupted the primary image, mcuboot only finds the secondary and boots into it.