This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Override MCUBoot build directory

Hello,

It appears as though nRF Connect does not currently support building encrypted images, so I am trying to implement it myself.

Part of creating encrypted images is providing the encryption key in mcuboot/boot/zephyr/keys.c

To that end, I have copied mcuboot into my project directory and edited that file. However, I'm unsure how to direct the build system to build from my copy of mcuboot and not from the one installed by nRF Connect.

Note that I am able to build encrypted images by editing keys.c in the nRF Connect installation and editing the nrf/modules/mcuboot/CMakeLists.txt to provide the "--encrypted" argument to imgtool.py. This proves that building encrypted images is possible, however I would like to avoid editing the installed SDK as several projects will be built against it, each with their own encryption.

Ideally I'd like to leverage the nRF Connect build as well since it figures out things like the header size and alignment to pass to imgtool. This would allow me to build a template that can work across projects as well.

Is it possible to point the build system to my copy of mcuboot?
Or is there perhaps another way to build encrypted images?

Thank you very much!

Parents
  • Hi Hung Bui,

    Thanks for the reply!

    Sorry, it's not that encrypted images cannot be used, but that I'm having trouble generating the encrypted image without editing files within the NCS installation.

    One limitation I've noticed is that the NCS build scripts do not pass the "--encrypt" argument when invoking imgtool.py. It also seems that even for signed images, the signature .pem file needs to be placed in the mcuboot directory inside the NCS installation. Ideally I wouldn't have to edit anything in the NCS installation directories.

    In nrf/modules/mcuboot/CMakeLists.txt you can see where the "sign_cmd" is created to invoke imgtool. Here, it calls the "sign" subcommand to create a signed image. If I edit this file to also pass the "--encrypt" flag, I am able to successfully create encrypted images.

    However, to make encrypted images work, I need to edit the "keys.c" file found in the mcuboot sources.

    I'm trying to copy the mcuboot source files out of the NCS installation and into my project repository where I can edit "keys.c" as well as place the signature and encryption .pem files.

    I'm then able to build this fork of mcuboot separately from my application, but I'm unable to get it to boot the application itself.

    The problem comes with putting this all together with the NCS build scripts.

    As you've said, once you set CONFIG_BOOTLOADER_MCUBOOT to build a bootable image, NCS includes mcuboot.cmake and goes and builds it's own mcuboot. My guess right now is that the resulting application image is placed according to where NCS's mcuboot will find it, but not where my forked mcuboot will find it. I'm not sure if this is necessarily the case since the build scripts are rather complicated and I'm still trying to wrap my head around it all.

    Ultimately, I'm trying to create encrypted images that boot with mcuboot and can be updated over SMP.

    So far, I've proven that it's possible, but I have to edit files in the NCS installation which will cause problems for other projects we are working on.

    If we can find a way to build mcuboot from a directory outside of the NCS installation, and get the "--encrypt" flag passed to imgtool.py, I think that will create bootable encrypted images.

    Hopefully that all make sense Slight smile

    Also, thanks for the info about multi_image.cmake and partition manager. I'll have a look at those today.

Reply
  • Hi Hung Bui,

    Thanks for the reply!

    Sorry, it's not that encrypted images cannot be used, but that I'm having trouble generating the encrypted image without editing files within the NCS installation.

    One limitation I've noticed is that the NCS build scripts do not pass the "--encrypt" argument when invoking imgtool.py. It also seems that even for signed images, the signature .pem file needs to be placed in the mcuboot directory inside the NCS installation. Ideally I wouldn't have to edit anything in the NCS installation directories.

    In nrf/modules/mcuboot/CMakeLists.txt you can see where the "sign_cmd" is created to invoke imgtool. Here, it calls the "sign" subcommand to create a signed image. If I edit this file to also pass the "--encrypt" flag, I am able to successfully create encrypted images.

    However, to make encrypted images work, I need to edit the "keys.c" file found in the mcuboot sources.

    I'm trying to copy the mcuboot source files out of the NCS installation and into my project repository where I can edit "keys.c" as well as place the signature and encryption .pem files.

    I'm then able to build this fork of mcuboot separately from my application, but I'm unable to get it to boot the application itself.

    The problem comes with putting this all together with the NCS build scripts.

    As you've said, once you set CONFIG_BOOTLOADER_MCUBOOT to build a bootable image, NCS includes mcuboot.cmake and goes and builds it's own mcuboot. My guess right now is that the resulting application image is placed according to where NCS's mcuboot will find it, but not where my forked mcuboot will find it. I'm not sure if this is necessarily the case since the build scripts are rather complicated and I'm still trying to wrap my head around it all.

    Ultimately, I'm trying to create encrypted images that boot with mcuboot and can be updated over SMP.

    So far, I've proven that it's possible, but I have to edit files in the NCS installation which will cause problems for other projects we are working on.

    If we can find a way to build mcuboot from a directory outside of the NCS installation, and get the "--encrypt" flag passed to imgtool.py, I think that will create bootable encrypted images.

    Hopefully that all make sense Slight smile

    Also, thanks for the info about multi_image.cmake and partition manager. I'll have a look at those today.

Children
No Data
Related