How to specify signing the key with MCUBoot

RE: How to specify signing the key with MCUBoot

NelsonGoncalves — Mon, 05 Jul 2021 09:41:23 GMT

Great, thanks again !

RE: How to specify signing the key with MCUBoot

Håkon Alseth — Mon, 05 Jul 2021 09:37:31 GMT

Hi,

mcuboot is, from the user application, transport agnostic.

You use the DFU library (dfu_target_init), as you linked to, and push data to it (dfu_target_write), and then you signal that its finished via "dfu_target_done".

Ofcourse, the above is simplified in terms of the type of image, callbacks, error handling etc.

If you search in the whole ncs tree for "dfu_target_init", you will see tests/samples/libs that use this module. One example is the fota_download library (lib used in samples/nrf9160/http_update/application):

https://github.com/nrfconnect/sdk-nrf/blob/master/subsys/net/lib/fota_download/src/fota_download.c#L122

The job that you need to do is to implement a backend to route your proprietary transport into the dfu target lib, just as download_client + fota_download does for downloading a binary from a webserver.

Kind regards,

Håkon

RE: How to specify signing the key with MCUBoot

NelsonGoncalves — Mon, 05 Jul 2021 09:07:19 GMT

Hakon,

Thanks again for your help. I got everything up and running.

I will take the opportunity to ask another question:

In my application, the new firmware image is first transfered (through a proprietary protocol) to the device. And the upgrade only occurs if the user has requested it. With MCUBoot, will it try to update the firmware image as soon as it sees a valid new image in the secondary slot ?

Is there a library for controlling the firmware update process ? I only could find the DFU library, but it appears to be specific for the modem firmware, not the user application.

RE: How to specify signing the key with MCUBoot

Håkon Alseth — Mon, 05 Jul 2021 08:35:19 GMT

Hi Nelson,

[quote user="NelsonGoncalves"]

Thanks for the fast response and correcting my project configurations. I am now able to build, flash and boot my application. I still have two questions. The first is about the external flash organization.

In my case, the external flash is divided in two parts. One for logs and application config items, and another for storing the new firmware image. When you edited the file pm_static.yml to become:

[/quote][quote user="NelsonGoncalves"]

The firmware image slot is placed at the start of the external flash. Is this mandatory or can I place the image slot anywhere else in external flash ?

[/quote]

You can offset the flash as you'd like, as long as the size of the primary and secondary is equal. Note that you need to adjust this in the pm_static.yml and prj.conf.

Example where I add a 0x20000 offset. pm_static.yml:

external_flash:
  address: 0x0000
  device: mx25r6435f
  end_address: 0x00200000
  region: external_flash
  size: 0x200000

mcuboot_secondary:
  address: 0x200000
  device: mx25r6435f
  end_address: 0x2f0000
  placement:
    align:
      start: 0x200000
  region: external_flash
  size: 0x0f0000

prj.conf:

...
CONFIG_PM_EXTERNAL_FLASH_BASE=0x200000
CONFIG_PM_EXTERNAL_FLASH_SIZE=0x00f0000
...

[quote user="NelsonGoncalves"]

The second question is related to the MCUBoot keys. I uncommented CONFIG_BOOT_SIGNATURE_KEY_FILE in mcuboot.conf, and the build process appears to have used my own private key. However on boot I got:

*** Booting Zephyr OS build v2.4.99-ncs1 ***
[00:00:00.377,990] <inf> mcuboot: Starting bootloader
[00:00:00.378,997] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.379,943] <inf> mcuboot: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.379,943] <inf> mcuboot: Boot source: none
[00:00:00.381,378] <inf> mcuboot: Swap type: none
[00:00:00.471,130] <err> mcuboot: Image in the primary slot is not valid!
[00:00:00.471,130] <err> mcuboot: Unable to find bootable image

So, what is the proper way to specifiy the private signing key ? Is it through the CONFIG_BOOT_SIGNATURE_KEY_FILE option ? Or should I specify it in the command line ? Should I sign the image myself, or is it done by the build process ?

[/quote]

This must be set in mcuboot.conf, not in prj.conf.

Note that if you have a space or a special character like "\" in your path, it must be escaped, as this needs to be in C-string format.

Let's say that you have the key.pem located in C:\key.pem, then the string must be:

CONFIG_BOOT_SIGNATURE_KEY_FILE="c:\\key.pem"

If you have issues, you can go into menuconfig for mcuboot, setting the above mentioned config to point to your pem file, then "Save minimal config (advanced)" (shift + d in menuconfig) and look at the stored defconfig file.

This will format the string for you.

Kind regards,

Håkon

RE: How to specify signing the key with MCUBoot

NelsonGoncalves — Mon, 05 Jul 2021 08:17:55 GMT

Hello Hakon,

In my case, the external flash is divided in two parts. One for logs and application config items, and another for storing the new firmware image. When you edited the file pm_static.yml to become:

external_flash:
  address: 0xf0000
  device: mx25r6435f
  end_address: 0x00100000
  region: external_flash
  size: 0x10000

mcuboot_secondary:
  address: 0x0
  device: mx25r6435f
  end_address: 0xf0000
  placement:
    align:
      start: 0x000
  region: external_flash
  size: 0x0f0000

The firmware image slot is placed at the start of the external flash. Is this mandatory or can I place the image slot anywhere else in external flash ?

The second question is related to the MCUBoot keys. I uncommented CONFIG_BOOT_SIGNATURE_KEY_FILE in mcuboot.conf, and the build process appears to have used my own private key. However on boot I got:

Best regards,

Nelson

RE: How to specify signing the key with MCUBoot

Håkon Alseth — Mon, 05 Jul 2021 07:35:18 GMT

Hi,

Thank you for providing a sample. I needed to override your configuration slightly, as I'm testing on a DK.

This means that you will get a JEDEC ID error check printed on runtime if you do not change back to your configuration in the boards/arm/dng_nrf9160/dng_nrf9160_common.dts

[quote user=""]the secondary slot for the firmware image upgrade is stored on an external flash.[/quote]

The external flash setup is usually the reason for this error message in mcuboot, and it highly likely does not have anything to do with your signing process.

You need to adjust mcuboot.conf::CONFIG_BOOT_MAX_IMG_SECTORS.

The calculation is:

flash_size / sector_size = CONFIG_BOOT_MAX_IMG_SECTORS.

for a 1M flash, with 4k pages, this means it should be the default value of 256. In your case, you have set 8M, which needs a value of '2048'.

However:

What will be printed when the primary and secondary has different sizes is this:

*** Booting Zephyr OS build v2.4.99-ncs1  ***
[00:00:00.400,848] <inf> mcuboot: Starting bootloader
[00:00:00.402,801] <wrn> mcuboot: Cannot upgrade: not a compatible amount of sectors

After looking at the build-folder/partitions.yml, you can read out the range (start+size) of the mcuboot_primary_app, and adjust your secondary to the same.

prj.conf: CONFIG_PM_EXTERNAL_FLASH_BASE and SIZE

pm_static: "mcuboot_secondary:"

I may have butchered your project slightly (and added prints to the main app), my apologies for this:

devzone.nordicsemi.com/.../272717.zip

I also included the build folder, with a merged.hex which runs on the nRF9160-DK (note: we have slightly different flash! remember to change back the configuration).

Kind regards,

Håkon