smp_svr sample: Building MCUboot

[David Ormand]

I've got a project that I'm going to want to do DFU through the UART, and in order to transfer files in a follow-on activity, I want SMP running in the application. Therefore the smp_srv sample.

In my development and test activities, I'm using a nRF52840 DK.

Following instructions at SMP server (docs.nordicsemi.com/.../README.html). The build of MCUboot works, after I specify the complete path to the code:
"west build -b nrf52840dk_nrf52840 -d build_mcuboot /c/ncs/v2.6.0/bootloader/mcuboot/boot/zephyr", and flash it. (I use "west flash -d build_mcuboot --erase", because otherwise, it finds and runs the image from a previous effort!)

However, when I build the application, it includes CONFIG_BOOTLOADER_MCUBOOT=y which apparently builds MCUboot as a child image. So building separately isn't necessary.  Makes me think the sample instructions are out-of-date.

Toward the end of the build process, I try to follow the instructions for signing the image, but they don't work. However, I can flash any of the bin files of the application and they will load and run.

It's like MCUboot isn't really looking for a signature, and I didn't see anything in the instructions to tell MCUboot to do so when it was being built.

[nordicator_prim3]

I remember it being confusing as well since it's an example from raw zephyr. You can build it through vscode like any nrf sample. Like you said, it's not necessary to build and flash separately. NRF connect handles making both images, signing them, and flashing for you. It's been a while since I've DFUd over UART, but I know if you do it with bluetooth you use <project>/build/zephyr/app_update.bin. If you want to flash both bootloader and the app image over jlink, then you would use merged.hex instead (both images merged and app is signed).

[David Ormand]

It's the "signing" part that escapes me.  The project instructions state, "A key feature of MCUboot is that images must be signed before they can be successfully uploaded and run on a target."  I'm going to want that feature before long.  But there seems to be a gap in the instructions to tell MCUboot to actually use the signature; I can send anything and MCUboot will happily boot it.

[nordicator_prim3]

It automatically uses the default mcuboot signing key. When it builds it will warn you about it.

MCUBoot bootloader key file: C:/ncs/v2.4.1/bootloader/mcuboot/root-rsa-2048.pem
-- Configuring done
-- Generating done
-- Build files have been written to: REDACTED
=== child image mcuboot -  end ===

CMake Warning at C:/ncs/v2.4.1/nrf/modules/mcuboot/CMakeLists.txt:310 (message):
  

          ---------------------------------------------------------
          --- WARNING: Using default MCUBoot key, it should not ---
          --- be used for production.                           ---
          ---------------------------------------------------------

You can make a custom key with these instructions or use general tooling like the next section says.

When you want to use your actual custom signed key, you can tell it where to look in your root cmake file:

set(mcuboot_CONFIG_BOOT_SIGNATURE_KEY_FILE \"${CMAKE_CURRENT_SOURCE_DIR}/your_custom_key.pem\")

[David Ormand]

Hmmm okay, I have seen that.

So why does it load/run anything I throw at it?

At the end of the build, I see this:

[196/204] Generating ../../zephyr/app_update.bin
image.py: sign the payload
[197/204] Generating ../../zephyr/app_signed.hex
image.py: sign the payload
[201/204] Generating ../../zephyr/app_test_update.hex
image.py: sign the payload
[204/204] Generating zephyr/merged.hex

I gather than at each step, "image.py: sign the payload" is signing at least app_update.bin, app_signed.hex, and app_test_update.hex.  Maybe that's why I can flash any of these and they will run.  But app_to_sign.bin isn't included in the west output, and it will load and run, also.  There isn't any message about a default key being used when signing the application.

Also, it isn't quite "anything" I throw at it.  There is, for instance, zephyr.hex and mcuboot_primary_app.hex which I can flash but MCUboot will not recognize.  But maybe there are reasons other than not being signed...