mcuboot test image became active confirm without external confirm from mcumgr

[Anthony Ambuehl]

I am testing with NCS 2.3.0,  nrf5340dk, on an application based on smp_svr sample.

I was testing with mcumgr  and found an unexpected behavior.  Maybe its a feature I have unwittingly enabled. 

I added the configuration from nrf/tests/modules/mcuboot/external_flash to my smp_server sample based application. 

I used mcumgr image upload to send the file

I did mcumgr image test <hash>  to prepare the test. 

I triggered a reset (reset button) and on my next call to image list, only 1 image was found and it was active confirmed state.  I thought this would only be allowed if I used mcumgr to confirm the image.

Did I unknowingly disable the image swap feature from mcuboot when I copied the externa_flash test?

Is this somehow part of the serial recovery settings in the externa_flash test?

[Sigurd Hellesvik]

Hi,

First a note: The test you use have been updated in v2.4.0, I suggest looking at the changes to child image configuration, which makes it configure the MCUboot child image properly.

Then to your question:

Serial Recovery will overwrite the primary slot, and by default not interact with the secondary slot.
So what you explain is expected.

I have written a little intro to MCUboot + samples at https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples. (not official)

Give it a read, and let me know if you got any questions.

Regards,
Sigurd Hellesvik

[Anthony Ambuehl]

Thanks for the link to your (unofficial) documentation. 

As I understand it, serial recover should be a serial interface from mcuboot, right? 

I sent the image using the application running the smp server, NOT serial recovery so it should not have overwritten the primary slot.   Further it only performs the update after i have marked it for TEST and then perform a reset. It Is not marked CONFIRM, yet the image is still written into the primary slow instead of being temporarily swapped.

However perhaps when serial recover is enabled the behavior to always overwrite the primary slot becomes the default?  I will remove the serial recover options and re-test to see if this behavior goes away.   If it does, then I feel this is a bug.  The serial recovery behavior should only be active when mcuboot recieves the image via serial, not when the application / smp server writes it into the secondary slot and clearly marks it as a test image.

[Anthony Ambuehl]

Actually I have already tested with the serial recovery config options disabled, last week.  It was still overwriting and not swapping.  

Also I should add that I did already review the differences between 2.4.0 and 2.3.0.

Here is my child_image/mcuboot/prj.conf, you can see I have commented out the CONFIG_MCUBOOT_SERIAL and CONFIG_MCUBOOT_SERIAL_DIRECT_IMAGE_UPLOAD

# In order to provide board specific configurations to the MCUboot child image
# we also need to provide a base configuration for MCUboot. This file contains
# the basic configurations needed to successfully build and run MCUboot.
CONFIG_PM=n

# MCUboot requires a large stack size, otherwise an MPU fault will occur
CONFIG_MAIN_STACK_SIZE=10240
CONFIG_MBEDTLS_CFG_FILE="mcuboot-mbedtls-cfg.h"

#since flash pages are heterogenous swap with scratch?
CONFIG_BOOT_SWAP_USING_SCRATCH=y
CONFIG_BOOT_PREFER_SWAP_MOVE=n

#AA TODO switch y ?
#CONFIG_BOOT_SWAP_SAVE_ENCTLV=n
CONFIG_BOOT_ENCRYPT_RSA=n
CONFIG_BOOT_ENCRYPT_EC256=n
CONFIG_BOOT_ENCRYPT_X25519=n

CONFIG_BOOT_UPGRADE_ONLY=n
CONFIG_BOOT_BOOTSTRAP=n

# Enable flash operations
CONFIG_FLASH=y

CONFIG_LOG=y
CONFIG_LOG_MODE_MINIMAL=y # former CONFIG_MODE_MINIMAL
### Ensure Zephyr logging changes don't use more resources
CONFIG_LOG_DEFAULT_LEVEL=0
### Decrease footprint by ~4 KB in comparison to CBPRINTF_COMPLETE=y
CONFIG_CBPRINTF_NANO=y
CONFIG_NRF_RTC_TIMER_USER_CHAN_COUNT=0
# This can be increased to accommodate the bigger images.
CONFIG_BOOT_MAX_IMG_SECTORS=256

# Enable serial recovery
# AA TODO maybe?
#CONFIG_UART_CONSOLE=n
#CONFIG_MCUBOOT_SERIAL=y
#CONFIG_MCUBOOT_SERIAL_DIRECT_IMAGE_UPLOAD=

Here is my child_image/mcuboot/boards/nrf5340dk_nrf5340_cpuapp.conf

# The following configurations are required to support simultaneous multi image update
CONFIG_PCD_APP=y
CONFIG_UPDATEABLE_IMAGE_NUMBER=2
CONFIG_FLASH_SIMULATOR=y
CONFIG_FLASH_SIMULATOR_DOUBLE_WRITES=y
CONFIG_FLASH_SIMULATOR_STATS=n
CONFIG_BOOT_UPGRADE_ONLY=y

CONFIG_SIZE_OPTIMIZATIONS=y

Here is my child_image/mcuboot.conf

CONFIG_NCS_MCUBOOT_IN_BUILD=y
CONFIG_FW_INFO_FIRMWARE_VERSION=

# Configure QSPI for external flash
CONFIG_FLASH=y

[Anthony Ambuehl]

I suspect the issue is caused by the CONFIG_BOOT_UPGRADE_ONLY=y option in child_image/mcuboot/boards/nrf5340dk_nrf5340_cpuapp.conf 

Perhaps 

I just tried disabling that option, however I started getting a errors with the partition manager addresses:

[156/198] Building C object modules/nrf/modules/mcuboot/hooks/CMakeFiles/..__nrf__modules__mcuboot__hooks.dir/nrf53_hooks.c.obj
FAILED: modules/nrf/modules/mcuboot/hooks/CMakeFiles/..__nrf__modules__mcuboot__hooks.dir/nrf53_hooks.c.obj
D:\Bmmpr\toolchains\v2.3.0\opt\zephyr-sdk\arm-zephyr-eabi\bin\arm-zephyr-eabi-gcc.exe -DEXT_API_MAGIC=0x281ee6de,0xb845acea,13570 -DFIRMWARE_INFO_MAGIC=0x281ee6de,0x8fcebb4c,13570 -DKERNEL -DNRF5340_XXAA_APPLICATION -DNRF_SKIP_FICR_NS_COPY_TO_RAM -DUSE_PARTITION_MANAGER=1 -D__PROGRAM_START -D__ZEPHYR__=1 -ID:/Bmmpr/v2.3.0/zephyr/include -Izephyr/include/generated -ID:/Bmmpr/v2.3.0/zephyr/soc/arm/nordic_nrf/nrf53 -ID:/Bmmpr/v2.3.0/zephyr/soc/arm/nordic_nrf/common/. -ID:/Bmmpr/v2.3.0/nrf/include -ID:/Bmmpr/v2.3.0/nrf/tests/include -ID:/Bmmpr/v2.3.0/modules/hal/cmsis/CMSIS/Core/Include -ID:/Bmmpr/v2.3.0/modules/hal/nordic/nrfx -ID:/Bmmpr/v2.3.0/modules/hal/nordic/nrfx/drivers/include -ID:/Bmmpr/v2.3.0/modules/hal/nordic/nrfx/mdk -ID:/Bmmpr/v2.3.0/zephyr/modules/hal_nordic/nrfx/. -ID:/Bmmpr/v2.3.0/bootloader/mcuboot/ext/tinycrypt/lib/include -ID:/Bmmpr/v2.3.0/bootloader/mcuboot/boot/bootutil/zephyr/.. -ID:/Bmmpr/v2.3.0/bootloader/mcuboot/boot/bootutil/zephyr/../include -ID:/Bmmpr/v2.3.0/bootloader/mcuboot/boot/bootutil/zephyr/../../zephyr/include -ID:/Bmmpr/v2.3.0/bootloader/mcuboot/boot/bootutil/zephyr/../../../ext/tinycrypt/lib/include -isystem D:/Bmmpr/v2.3.0/zephyr/lib/libc/minimal/include -isystem d:/bmmpr/toolchains/v2.3.0/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.1.0/include -isystem d:/bmmpr/toolchains/v2.3.0/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.1.0/include-fixed -isystem D:/Bmmpr/v2.3.0/nrfxlib/crypto/nrf_cc312_platform/include -fno-strict-aliasing -Os -imacros D:/Bmmpr/provisioning/provisioning_image/smp_svr/build/mcuboot/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -gdwarf-4 -fdiagnostics-color=always -mcpu=cortex-m33 -mthumb -mabi=aapcs -mfp16-format=ieee --sysroot=D:/Bmmpr/toolchains/v2.3.0/opt/zephyr-sdk/arm-zephyr-eabi/arm-zephyr-eabi -imacros D:/Bmmpr/v2.3.0/zephyr/include/zephyr/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-pointer-sign -Wpointer-arith -Wexpansion-to-defined -Wno-unused-but-set-variable -Werror=implicit-int -fno-pic -fno-pie -fno-asynchronous-unwind-tables -fno-reorder-functions --param=min-pagesize=0 -fno-defer-pop -fmacro-prefix-map=D:/Bmmpr/v2.3.0/bootloader/mcuboot/boot/zephyr=CMAKE_SOURCE_DIR -fmacro-prefix-map=D:/Bmmpr/v2.3.0/zephyr=ZEPHYR_BASE -fmacro-prefix-map=D:/Bmmpr/v2.3.0=WEST_TOPDIR -ffunction-sections -fdata-sections -std=c99 -nostdinc -MD -MT modules/nrf/modules/mcuboot/hooks/CMakeFiles/..__nrf__modules__mcuboot__hooks.dir/nrf53_hooks.c.obj -MF modules\nrf\modules\mcuboot\hooks\CMakeFiles\..__nrf__modules__mcuboot__hooks.dir\nrf53_hooks.c.obj.d -o modules/nrf/modules/mcuboot/hooks/CMakeFiles/..__nrf__modules__mcuboot__hooks.dir/nrf53_hooks.c.obj -c D:/Bmmpr/v2.3.0/nrf/modules/mcuboot/hooks/nrf53_hooks.c
D:/Bmmpr/v2.3.0/nrf/modules/mcuboot/hooks/nrf53_hooks.c: In function 'boot_read_image_header_hook':
D:\Bmmpr\v2.3.0\nrf\modules\mcuboot\hooks\nrf53_hooks.c:28:42: error: 'PM_MCUBOOT_PRIMARY_1_ADDRESS' undeclared (first use in this function); did you mean 'PM_MCUBOOT_PRIMARY_ADDRESS'?
28 | img_head->ih_load_addr = PM_MCUBOOT_PRIMARY_1_ADDRESS;
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
| PM_MCUBOOT_PRIMARY_ADDRESS
D:\Bmmpr\v2.3.0\nrf\modules\mcuboot\hooks\nrf53_hooks.c:28:42: note: each undeclared identifier is reported only once for each function it appears in
In file included from D:\Bmmpr\v2.3.0\zephyr\include\zephyr\toolchain\gcc.h:89,
from D:\Bmmpr\v2.3.0\zephyr\include\zephyr\toolchain.h:50,
from D:\Bmmpr\v2.3.0\zephyr\include\zephyr\sys\__assert.h:11,
from D:\Bmmpr\v2.3.0\zephyr\lib\libc\minimal\include\assert.h:11,
from D:\Bmmpr\v2.3.0\nrf\modules\mcuboot\hooks\nrf53_hooks.c:7:
D:/Bmmpr/v2.3.0/nrf/modules/mcuboot/hooks/nrf53_hooks.c: In function 'network_core_update':
D:\Bmmpr\v2.3.0\zephyr\include\zephyr\device.h:83:41: error: '__device_dts_ord_DT_N_NODELABEL_PM_MCUBOOT_PRIMARY_1_DEV_ORD' undeclared (first use in this function)
83 | #define DEVICE_NAME_GET(dev_id) _CONCAT(__device_, dev_id)
| ^~~~~~~~~
D:\Bmmpr\v2.3.0\zephyr\include\zephyr\device.h:209:37: note: in expansion of macro 'DEVICE_NAME_GET'
209 | #define DEVICE_DT_NAME_GET(node_id) DEVICE_NAME_GET(Z_DEVICE_DT_DEV_ID(node_id))
| ^~~~~~~~~~~~~~~
D:\Bmmpr\v2.3.0\zephyr\include\zephyr\device.h:226:34: note: in expansion of macro 'DEVICE_DT_NAME_GET'
226 | #define DEVICE_DT_GET(node_id) (&DEVICE_DT_NAME_GET(node_id))
| ^~~~~~~~~~~~~~~~~~
D:\Bmmpr\v2.3.0\nrf\modules\mcuboot\hooks\nrf53_hooks.c:85:26: note: in expansion of macro 'DEVICE_DT_GET'
85 | mock_flash_dev = DEVICE_DT_GET(DT_NODELABEL(PM_MCUBOOT_PRIMARY_1_DEV));
| ^~~~~~~~~~~~~
[157/198] Building C object modules/hal_nordic/nrfx/CMakeFiles/modules__hal_nordic__nrfx.dir/D_/Bmmpr/v2.3.0/modules/hal/nordic/nrfx/helpers/nrfx_flag32_allocator.c.obj
[158/198] Building C object modules/mcuboot/boot/bootutil/zephyr/CMakeFiles/mcuboot_util.dir/D_/Bmmpr/v2.3.0/bootloader/mcuboot/boot/bootutil/src/bootutil_public.c.obj
[159/198] Building C object modules/hal_nordic/nrfx/CMakeFiles/modules__hal_nordic__nrfx.dir/D_/Bmmpr/v2.3.0/modules/hal/nordic/nrfx/drivers/src/nrfx_dppi.c.obj
[160/198] Linking C static library zephyr\drivers\pinctrl\libdrivers__pinctrl.a
[161/198] Building C object modules/hal_nordic/nrfx/CMakeFiles/modules__hal_nordic__nrfx.dir/D_/Bmmpr/v2.3.0/modules/hal/nordic/nrfx/mdk/system_nrf5340_application.c.obj
[162/198] Linking C static library modules\nrf\lib\fatal_error\lib..__nrf__lib__fatal_error.a
[163/198] Linking C static library modules\nrf\subsys\fw_info\lib..__nrf__subsys__fw_info.a
[164/198] Linking C static library modules\nrf\subsys\pcd\lib..__nrf__subsys__pcd.a
[165/198] Building C object modules/hal_nordic/nrfx/CMakeFiles/modules__hal_nordic__nrfx.dir/D_/Bmmpr/v2.3.0/modules/hal/nordic/nrfx/drivers/src/nrfx_clock.c.obj
ninja: build stopped: subcommand failed.
[429/447] Generating zephyr/b0_container.hex
FAILED: modules/mcuboot/mcuboot_subimage-prefix/src/mcuboot_subimage-stamp/mcuboot_subimage-build mcuboot/zephyr/zephyr.hex mcuboot/zephyr/zephyr.elf
cmd.exe /C "cd /D D:\Bmmpr\provisioning\provisioning_image\smp_svr\build\mcuboot && D:\Bmmpr\toolchains\v2.3.0\opt\bin\cmake.exe --build . --"
[431/447] Linking C executable zephyr\zephyr.elf

[Sigurd Hellesvik]

Hi,

Does this sample do what you want?

mcuboot_serial_recovery_uart_feat_smp_server_app.zip

Regards,
Sigurd Hellevsik

[Anthony Ambuehl]

I'm not interested in serial recovery. 

I'm trying to get nrf5340 cpuapp and cpunet non-simultaneous upgrade from external flash. 

From internal flash I was able to perform the update using the swap method to test the downloaded image. After switching to external flash the swap/test procedure no longer works. 

It seems like cpunet update requires CONFIG_BOOT_UPGRADE_ONLY and CONFIG_BOOT_UPGRADE_ONLY prevents the swap, is that correct?