west build failed due to mcuboot sysbuild

[DKC]

Hi,

With NCS v3.1.0 and Nordic's downstream zephyr ncs-v3.1.0, I got build failure with following message:

--

warning: attempt to assign the value 'n' to the undefined symbol MCUBOOT_HARDWARE_DOWNGRADE_PREVENTION

--

This failure can be reproduced by building sample 'with_mcuboot'.

Command as below:

west build -p always -b nrf52840dk/nrf52840 zephyr/samples/sysbuild/with_mcuboot --sysbuild

But I can succeed to build it without '--sysbuild'. And BTW, with same system (machine with Ubuntu v22.04 installed) I can build this sample with original 'zephyr' according to 'Getting Started Guide'

docs.zephyrproject.org/.../index.html

[DKC]

Hi Benjamin,

Here is the file, yes, MCUBOOT_HARDWARE_DOWNGRADE_PREVENTION is presented as well.

(v3.1.0) luser@zephyrbuild:~/ncs$ cat v3.1.0/nrf/modules/mcuboot/Kconfig
menu "MCUboot"

if BOOTLOADER_MCUBOOT

menuconfig MCUBOOT_HARDWARE_DOWNGRADE_PREVENTION
        bool "Downgrade prevention using hardware security counters"
        depends on SOC_NRF5340_CPUAPP || SOC_SERIES_NRF91X || SOC_SERIES_NRF54LX
        help
          This option can be enabled by the application and will ensure
          that the MCUBOOT_HW_DOWNGRADE_PREVENTION Kconfig option is
          enabled in the MCUboot image.

if MCUBOOT_HARDWARE_DOWNGRADE_PREVENTION

config MCUBOOT_HW_DOWNGRADE_PREVENTION_COUNTER_SLOTS
        int "Number of available hardware counter slots"
        default 240
        range 2 300
        help
          When MCUBOOT_HW_DOWNGRADE_PREVENTION is enabled, MCUboot will use
          one hardware counter for each updatable image (UPDATEABLE_IMAGE_NUMBER).
          This configuration specifies how many counter slots will be allocated
          for each hardware counter. The hardware counters are stored in OTP storage.
          The rationale for the default number (240): Assume one update a month for
          10 years, then double that value just in case. This default fits
          comfortably within the OTP region of UICR.

config MCUBOOT_HW_DOWNGRADE_PREVENTION_COUNTER_VALUE
        int "Security counter value"
        default 1
        range 1 65535
        help
          The security counter value for this image.
          This is the value that will be passed to the --security-counter
          parameter of imgtool.py

endif # MCUBOOT_HARDWARE_DOWNGRADE_PREVENTION

# HACK: NCS temphack to keep our imgtool integration working now that
# there is no CONFIG_DT_* CMake namespace anymore. Use Zephyr
# kconfigfunctions to thread the flash write block size through
# Kconfig so it can be accessed from CMake. Needs a better solution.
DT_ZEPHYR_FLASH := zephyr,flash
DT_CHOSEN_ZEPHYR_FLASH := $(dt_chosen_path,$(DT_ZEPHYR_FLASH))
config MCUBOOT_FLASH_WRITE_BLOCK_SIZE
        int
        default $(dt_node_int_prop_int,$(DT_CHOSEN_ZEPHYR_FLASH),write-block-size)

endif # BOOTLOADER_MCUBOOT

config DT_FLASH_WRITE_BLOCK_SIZE
        int
        default $(dt_node_int_prop_int,$(DT_CHOSEN_ZEPHYR_FLASH),write-block-size)

config MCUBOOT_USB_SUPPORT
        bool
        default y if "$(dt_nodelabel_enabled,zephyr_udc0)"

config USE_NRF53_MULTI_IMAGE_WITHOUT_UPGRADE_ONLY
        bool "Allow nRF53 multi-image update support [dangerous]"
        help
          Enabling this option allows you to use NRF53_MULTI_IMAGE update
          without having BOOT_UPGRADE_ONLY enabled, allowing you to use
          different swapping methods. This will however give you the potential
          of bricking the network core upon reverts.

config MCUBOOT_USE_ALL_AVAILABLE_RAM
        bool "Allow MCUBoot to use all available RAM"
        depends on ARM_TRUSTZONE_M
        default y if BOARD_THINGY53_NRF5340_CPUAPP_NS || BOARD_THINGY53_NRF5340_CPUAPP
        help
          By default MCUBoot uses only the secure RAM partition.

endmenu
(v3.1.0) luser@zephyrbuild:~/ncs$

[Benjamin]

Thanks. I suspect something may have gone wrong in your system-wide installation of NCS. Did you deviate from the setup steps at any point?

Could you share the build folder generated during the failed build?

[DKC]

Hi Benjamin,

Finally, I found out that the issue is related to the version I've chosen for bootloader/mcuboot.

With source from repo 'https://github.com/nrfconnect/sdk-mcuboot', it can be built successfully.

And my failure case is from repo 'github.com/.../mcuboot'

Sorry for your time on helping me for the debugging.