Issues with Building MCUboot for nRF7002DK Using NCS V2.5.2

Hello,

I've been encountering build issues when trying to include MCUboot as a bootloader for my nRF7002DK project using the Nordic Connect SDK version 2.5.2. Specifically, when CONFIG_BOOTLOADER_MCUBOOT=y is set in my prj.conf, the build process fails with errors:

c:/ncs/toolchains/c57af46cb7/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe: zephyr/drivers/flash/libdrivers__flash.a(spi_nor.c.obj): in function `k_sleep':
####\build\mcuboot/zephyr/include/generated/syscalls/kernel.h:135: undefined reference to `z_impl_k_sleep'
c:/ncs/toolchains/c57af46cb7/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe: ####\build\mcuboot/zephyr/include/generated/syscalls/kernel.h:135: undefined reference to `z_impl_k_sleep'
c:/ncs/toolchains/c57af46cb7/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe: zephyr/drivers/flash/libdrivers__flash.a(spi_nor.c.obj):(.rodata.spi_nor_config_0+0x0): undefined reference to `__device_dts_ord_142'

Has anyone faced similar issues or can offer guidance on properly integrating MCUboot with the nRF7002DK using NCS V2.5.2? Any advice or pointers to relevant documentation would be greatly appreciated.

Thank you in advance for your help!

Parents
  • Hello,

    The problem appears to be that 'CONFIG_MULTITHREADING' and 'CONFIG_SPI_NOR' is not enabled for the MCUBoot build. To fix this, you can create a folder named 'child_image' in your project and add the neccessary Kconfig file for the bootloader. Attached is an example which enables these symbols for the bootloader.

    smp_svr_7000dk.zip

    Best regards,

    Vidar

  • Is it possible to place image-1 into the mx25r64 and boot from it over the SPI interface?

    /delete-node/ &slot0_partition;
    /delete-node/ &slot0_ns_partition;
    /delete-node/ &slot1_partition;
    /delete-node/ &slot1_ns_partition;
    /delete-node/ &scratch_partition;
    /delete-node/ &storage_partition;
    
    &flash0 {
    	partitions {
    		boot_partition: partition@0 {
    			label = "mcuboot";
    			reg = <0x000000000 0x00010000>;
    		};
    		slot0_partition: partition@10000 {
    			label = "image-0";
    			reg = <0x00010000 0x000e8000>;
    		};
    	};
    };
    
    &mx25r64 {
    	partitions {
    		compatible = "fixed-partitions";
    		#address-cells = <1>;
    		#size-cells = <1>;
    
    		slot1_partition: partition@0 {
    			label = "image-1";
    			reg = <0x000000000 0x0000e8000>;
    		};
    	};
    };
    
    / {
        chosen {
            nordic,pm-ext-flash = &mx25r64;
        };
    };
    


    I was able to use your repo example with the cdc to write an image over to it.

    mcumgr list:
    ➜  ~ mcumgr --conntype serial --connstring "<port>,baud=115200" image list
    Images:
     image=0 slot=0
        version: 0.0.0
        bootable: true
        flags: active confirmed
        hash: e8c0528e4782d4a95a60bc3235231886731da18af2bd6c15dfe8672c56d0396d
     image=0 slot=1
        version: 0.0.0
        bootable: true
        flags: pending
        hash: 157b9ea327e5418e79b28691967ed22259305b7a600eb707eba0c62b2bd9a299
    Split status: N/A (0)


    If I try to test it however it gets marked as pending but won't boot into it.

    ➜  ~ mcumgr --conntype serial --connstring "<port>,baud=115200" image test 157b9ea327e5418e79b28691967ed22259305b7a600eb707eba0c62b2bd9a299



    My application is unfortunately too big to place two of them together, and with the QSQI being used for the 7002 the SPI is my last resort.

    Best Regards,
    Waderq21

  • Hello,

    I'll respond here, but please create a new thread for future questions. You may reference any related threads that you think may be relevant to your issue. This helps us keep the forum tidy and maintain the Q&A format.

    waderq21 said:
    My application is unfortunately too big to place two of them together

    The secondary slot will be relocated to external flash once you've assigned your SPI flash device with the 'nordic,pm-ext-flash' property in your device tree. By default, the CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY  symbol is set to 'y' when this property is set. You can verify this by checking the memory report (link). However, executing the application directly from a secondary slot in external SPI flash is not possible. The bootloader must copy it to the primary slot before it can be run. The main reason for this is that SPI does not support Execute in place (XiP) like QSPI. XiP would also negatively impact the processing speed and power consumption.

    Best regards,

    Vidar

Reply
  • Hello,

    I'll respond here, but please create a new thread for future questions. You may reference any related threads that you think may be relevant to your issue. This helps us keep the forum tidy and maintain the Q&A format.

    waderq21 said:
    My application is unfortunately too big to place two of them together

    The secondary slot will be relocated to external flash once you've assigned your SPI flash device with the 'nordic,pm-ext-flash' property in your device tree. By default, the CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY  symbol is set to 'y' when this property is set. You can verify this by checking the memory report (link). However, executing the application directly from a secondary slot in external SPI flash is not possible. The bootloader must copy it to the primary slot before it can be run. The main reason for this is that SPI does not support Execute in place (XiP) like QSPI. XiP would also negatively impact the processing speed and power consumption.

    Best regards,

    Vidar

Children
Related