MCUboot image in secondary slot is not valid

RE: MCUboot image in secondary slot is not valid

Håkon Alseth — Thu, 30 Sep 2021 13:54:09 GMT

Hi,

mcuboot cannot update itself. for that you'll need two stage bootloader, for instance the immutable bootloader to update mcuboot:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.7.0/nrf/samples/bootloader/README.html

Kind regards,

Håkon

RE: MCUboot image in secondary slot is not valid

ballen7 — Wed, 29 Sep 2021 18:52:05 GMT

Is it possible to flash build/zephyr/merged.hex by sending an update that contains a bootloader? Or will I run into flash protection issues?

RE: MCUboot image in secondary slot is not valid

ballen7 — Wed, 29 Sep 2021 18:30:58 GMT

Yikes... Well I currently have a large amount of devises deployed with RSA signatures and even more devices deployed with ECDSA signatures. I am guessing what happened was we factory flashed the new sdk right when the default signature was switched.

I guess going forward I will have to add logic to determine what signature the device takes and it have it OTA the binary with the correct signature.

RE: MCUboot image in secondary slot is not valid

Håkon Alseth — Wed, 29 Sep 2021 08:47:35 GMT

Hi,

If you mean manually verifying the .hex, this can be done by programming the "app_test_update.hex" in directory build-folder/zephyr/. This will populate the primary slot with the new firmware.

If you are able to program your external flash, you can program it with "app_moved_test_update.hex"

Kind regards,

Håkon

RE: MCUboot image in secondary slot is not valid

ballen7 — Tue, 28 Sep 2021 21:36:32 GMT

Can I manually flash the area the bootloader is?

RE: MCUboot image in secondary slot is not valid

Håkon Alseth — Mon, 27 Sep 2021 07:30:25 GMT

Hi,

As mentioned, you need to set this configuration consistently on all projects in order for mcuboot to accept your image.

You can either go at this by using RSA (ie. setting CONFIG_BOOT_SIGNATURE_TYPE_RSA), or you can choose the ECDSA signature type (setting CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256).

If you want to use ECDSA signature type, set this in the configuration for your project in ncs v1.3.0, and it will be default-selected for newer versions as its the default selection.

Kind regards,

Håkon

RE: MCUboot image in secondary slot is not valid

ballen7 — Fri, 24 Sep 2021 15:32:26 GMT

Hi, when I specify this in my ncs 1.4.2 project my device running sdk version 1.3 successfully take the image.

When I try to OTA the same image to devices already running ncs 1.4.2 it fails at the same spot... My goal is to OTA all the devices to identical images running the same ncs version

RE: MCUboot image in secondary slot is not valid

Håkon Alseth — Fri, 24 Sep 2021 13:58:46 GMT

Hi,

You should set this in the mcuboot configuration file.

As ncs v1.4.2 is an older version, you need to specify this in the CMakeLists.txt file:

# Add this just below the line "cmake_minimum_required(...)" !!
if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/mcuboot.conf")
  list(APPEND mcuboot_OVERLAY_CONFIG
    "${CMAKE_CURRENT_SOURCE_DIR}/mcuboot.conf"
    )
endif()

Then create mcuboot.conf in your application folder and add the CONFIG entry there.

Note: for newer ncs versions, you should create my_application/child_image/mcuboot.conf and it will be automatically picked up and merged with the default configuration.

Kind regards,

Håkon

RE: MCUboot image in secondary slot is not valid

ballen7 — Fri, 24 Sep 2021 13:52:16 GMT

Hello when I try this I get the error,

Merged configuration 'C:/Users/ballen/code/ttp/lte-modem/prj.conf'
-- Configuring incomplete, errors occurred!
-- Using NCS Toolchain 1.4.2 for building. (C:/Users/ballen/ncs/v1.4.2/toolchain/cmake)
warning: unit address and first address in 'reg' (0x50000) don't match for /soc/peripheral@40000000/flash-controller@39000/flash@0/partitions/partition@40000
warning: unit address and first address in 'reg' (0xc0000) don't match for /soc/peripheral@40000000/flash-controller@39000/flash@0/partitions/partition@b0000

warning: MBEDTLS_SHA1_C (defined at C:/Users/ballen/ncs/v1.4.2/nrfxlib\nrf_security/Kconfig:1293)
was assigned the value 'y' but got the value 'n'. Check these unsatisfied dependencies:
NRF_SECURITY_ANY_BACKEND (=n), NORDIC_SECURITY_BACKEND (=n). See
http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_MBEDTLS_SHA1_C.html and/or look up
MBEDTLS_SHA1_C in the menuconfig/guiconfig interface. The Application Development Primer, Setting
Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be helpful
too.


C:/Users/ballen/code/ttp/lte-modem/prj.conf:48: warning: attempt to assign the value 'y' to the undefined symbol BOOT_SIGNATURE_TYPE_RSA

error: Aborting due to Kconfig warnings

CMake Error at C:/Users/ballen/ncs/v1.4.2/zephyr/cmake/kconfig.cmake:239 (message):
  command failed with return code: 1
Call Stack (most recent call first):
  C:/Users/ballen/ncs/v1.4.2/zephyr/cmake/app/boilerplate.cmake:591 (include)
  CMakeLists.txt:9 (include)



error: cmake failed
create_nordic_project.py failed (1)

RE: MCUboot image in secondary slot is not valid

ballen7 — Tue, 14 Sep 2021 13:51:32 GMT

Hi Hakon,

the original (nor new) project does not have "CONFIG_BOOT_SIGNATURE_TYPE_RSA=y" set. The two versions have identical prj.conf files.

I tested if the new firmware would boot successfully if it was built with sdk version 1.3.0 and it does (boots fine on deployed devices running sdk version 1.3.0).

I will add CONFIG_BOOT_SIGNATURE_TYPE_RSA=y to the the v1.4.2 and do another update test.

RE: MCUboot image in secondary slot is not valid

Håkon Alseth — Tue, 14 Sep 2021 11:43:31 GMT

Hi,

Could you check if the mcuboot boot signature algorithm type is equal on both ends? This was defaulted to ECDSA (CONFIG_BOOT_SIGNATURE_TYPE_RSA=y) in mcuboot after ncs v1.2.0.

If the original project has "CONFIG_BOOT_SIGNATURE_TYPE_RSA=y" set, this must also be set in future projects. Could you check this and set this on the ncs v1.4.x project?

Kind regards,

Håkon