mcuboot secure boot hello world example

[boris bergman1]

I followed this tutorial, the second example with hello world, added CONFIG_SECURE_BOOT and  CONFIG_SB_SIGNING_KEY_FILE="/path/to/ec-secp256k1-priv-key.pem" in prj.conf file according to this guide.

Now, when I flash the nrf52840dk board with this build, I get a timeout with the command: mcumgr --conntype serial --connstring "/dev/ttyACM0,baud=115200" echo hello. Also the board is not printing anyting in the RTT window.

When I leave out the above parameters (CONFIG_SECURE_BOOT and  CONFIG_SB_SIGNING_KEY_FILE), mcumgr just works fine, AND i get the hello world printing compile time as expected. The file flashed to the board is ../hello_world_dfu/build_dk/zephyr/merged.hex

How do I get this to work?

[Hieu]

Hi Boris,

I followed the same steps and was able to get the setup to work just fine. I also tested upgrading the application, enter test boot, reset. Everything worked as expected.

Given that you stated the MCUboot only setup worked, I think you have the ports figure out right. However, can you just double check to be sure that the port is correct, and is not connected with any other programs while you perform the mcumgr test?

Hieu

[boris bergman1]

Got it to work.

I misread, the above config_secure_boot is used for the nrf-bootloader, and not mcuboot.

In my project directory, I had to make a directory child_image, add the file mcuboot.conf with the following content:

CONFIG_BOOT_SIGNATURE_KEY_FILE="/home/bergm006/nrf-projects/hello_world/boris-key4.pem"
CONFIG_DISABLE_FLASH_PATCH=y
CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y

Now I can upload using mcumgr. Confirming an image only works entering it's hash like with test, only this is not in the manual. And after a reset, the first mcumgr command is always ignored.

For some reason, it only works when increasing the version number, although I haven't configured anything to do so.

CONFIG_MCUBOOT_IMAGE_VERSION="0.1.2+3"

Regards

[Hieu]

boris bergman1 said:

I misread, the above config_secure_boot is used for the nrf-bootloader, and not mcuboot.

It is, and also CONFIG_SB_SIGNING_KEY.
All along I thought that's what you wanted to do. Nonetheless, it should not result in the application not running. Unless you are signing the application image manually?

Another thing that could happen is that RTT malfunctions across device resets. In such case, we can just disconnect and reconnect the RTT connection.

boris bergman1 said:

Confirming an image only works entering it's hash like with test, only this is not in the manual.

Which manual are you referring to? In Simon's guide, which you are using, the steps are mentioned. If one of our tutorials or documentations is lacking, let us know and we will try to fix it.

boris bergman1 said:

For some reason, it only works when increasing the version number, although I haven't configured anything to do so.

You can read more about this behavior in the CONFIG_MCUBOOT_IMAGE_VERSION documentation: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.2.0/kconfig/index.html

[boris bergman1]

Hieu said:

Which manual are you referring to? In Simon's guide, which you are using, the steps are mentioned. If one of our tutorials or documentations is lacking, let us know and we will try to fix it.

Here, you should also add a hash, it is not mentioned.

Hieu said:

Another thing that could happen is that RTT malfunctions across device resets. In such case, we can just disconnect and reconnect the RTT connection.

The RTT is working fine.

The manual has .conf options every time, but not here. It does not notice about the child_image directory option. I've no idea how to get this into my nrf-connect build configuration:

Whatever I try, It doesn't compose the appropriate build parameters.

Hieu said:

All along I thought that's what you wanted to do. Nonetheless, it should not result in the application not running. Unless you are signing the application image manually?

So did you build a mcuboot inside a nrf bootloader?

[Hieu]

boris bergman1 said:

Here, you should also add a hash, it is not mentioned.

According to documentation, the hash is not necessary when it is run on an image booting in test mode.
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/services/device_mgmt/mcumgr.html#image-management

I just tested your observation and also see that not having the hash resulted in Error 3. I will ask internally on what is wrong with this. Perhaps something changed, or a new bug crept up at some point.

boris bergman1 said:

Hieu said:

Another thing that could happen is that RTT malfunctions across device resets. In such case, we can just disconnect and reconnect the RTT connection.

The RTT is working fine.

Please just know that sometime RTT stop working after device is reset, and you will need to disconnect and reconnect. It is a totally fine and good thing that it doesn't happen with you this time.

boris bergman1 said:

The manual has .conf options every time, but not here. It does not notice about the child_image directory option. I've no idea how to get this into my nrf-connect build configuration:

Whatever I try, It doesn't compose the appropriate build parameters.

Does the build system not automatically detect your child_image directory at all? I just tested on two projects and they work fine.

The documentation for that is here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/app_dev/multi_image/index.html.
The particular section is Image-specific variables.

boris bergman1 said:

So did you build a mcuboot inside a nrf bootloader?

It's not that MCUboot is inside a nRF bootloader. It is a two-stage bootloader setup. The device would first boot into Nordic Secure Immutable Bootloader (NSIB), aka b0, then boot into MCUboot. MCUboot then boot the application. You can read more about here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/app_dev/bootloaders_and_dfu/index.html.

[boris bergman1]

Hieu said:

Does the build system not automatically detect your child_image directory at all? I just tested on two projects and they work fine.

Yes, child_image works. I just don't know how to put those parameters in nrf connect, as I'm not using the command line every time to make a build.

[Hieu]

My setup for a different case is show below.
It is how I "overlay" the configuration CONFIG_SINGLE_APPLICATION_SLOT to the MCUboot child image. In this setup, I don't have to use the command line to get the configuration applied.

This is described in detail in the page linked in my last reply, so perhaps it is not what you are asking for though? If so, we probably aren't on the same page, thus please describe in more details what is working, what is not, and what you want to do.

[boris bergman1]

Yes thanks, I got that. My remarks were only about the tutorial not mentioning this (using a child config file) at the time. Only this does not answer how to format the cmake build parameters when not using a config file (as is done in the tutorial).

[Hieu]

boris bergman1 said:

Only this does not answer how to format the cmake build parameters when not using a config file (as is done in the tutorial).

In this part, do you mean how to add the CMake build parameters to a build configuration in the nRF Connect VS Code Extension, like you did here?

boris bergman1 said:

And I take it you mean it is not mentioned in this documentation?
Adding a bootloader chain — nRF Connect SDK 2.3.0 documentation (nordicsemi.com)

[boris bergman1]

Yes, that's what I meant.

Thanks anyway.