Error about MCUBOOT_BUILD_STRATEGY_FROM_SOURCE when trying to provide a signing key

I want to do firmware updates over BLE. To do that I added these settings to my prj.conf which I mostly got from the smp_svr example:

# For BLE firmware updates
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_MCUMGR=y
CONFIG_MCUMGR_CMD_IMG_MGMT=y # for writing new firmware
CONFIG_MCUMGR_CMD_OS_MGMT=y # for resetting the device
CONFIG_BT_L2CAP_TX_MTU=252
CONFIG_BT_BUF_ACL_RX_SIZE=256
CONFIG_MCUMGR_SMP_BT=y
CONFIG_MCUMGR_SMP_BT_AUTHEN=n # security is handled by signed firmware images
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096

This "works" but it uses the default signing key. So I added CONFIG_MCUBOOT_SIGNATURE_KEY_FILE="signing_key.pem" according to this answer but I got this message during build:

  CONFIG_MCUBOOT_SIGNATURE_KEY_FILE is set to "signing_key.pem".

  You are using the NCS Mcuboot signing, which means this option will be
  ignored.

  Image signing in NCS is done via the MCUboot image's
  CONFIG_BOOT_SIGNATURE_KEY_FILE option.

  Consider setting CONFIG_MCUBOOT_SIGNATURE_KEY_FILE in your application
  image back to its default value, the empty string.

If I follow that advice and set CONFIG_BOOT_SIGNATURE_KEY_FILE I get these messages:

CONFIG_BOOT_SIGNATURE_KEY_FILE couldn't be set. Missing dependencies:
!MCUBOOT_BUILD_STRATEGY_FROM_SOURCE

warning: BOOT_SIGNATURE_KEY_FILE was assigned the value 'signing_key.pem' but got the value
''. Check these unsatisfied dependencies: (!MCUBOOT_BUILD_STRATEGY_FROM_SOURCE) (=n). See
http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_BOOT_SIGNATURE_KEY_FILE.html and/or
look up BOOT_SIGNATURE_KEY_FILE in the menuconfig/guiconfig interface. The Application Development
Primer, Setting Configuration Values, and Kconfig - Tips and Best Practices sections of the manual

But it doesn't seem like MCUBOOT_BUILD_STRATEGY_FROM_SOURCE is a valid prj.conf setting for an NCS project?

I'm on NCS 1.9.1.

Parents Reply
  • Aaaah, I found the issue. I was putting dfu_application.zip into Dropbox and then opening it directly from Dropbox inside nRF Device Manager. I don't know if it's a problem of Dropbox or of nRF Device Manager, but apparently if I choose a file with the same name again, it will not be reloaded. So I was trying to flash an old file the whole time. This invalidates all my results.

    After taking this into account and renaming the file every time, I get the desired results.

Children
Related