Problem with signing images for OTA DFU

RE: Problem with signing images for OTA DFU

dstarling — Tue, 08 Dec 2020 20:32:47 GMT

I can also confirm the stack change fixed the issue on nrf52840dk as well. Thanks

RE: Problem with signing images for OTA DFU

Antonio — Tue, 08 Dec 2020 17:13:18 GMT

Thank you Einar, that did the trick.

About modifying the boot Kconfig, at least with ubuntu, only the relative path worked. I placed it as:

default "../../../Documents/tracker_sensor/Tools/psl-rsa-2048.pem" if BOOT_SIGNATURE_TYPE_RSA && BOOT_SIGNATURE_TYPE_RSA_LEN=2048

Placing an absolute path would have problems at compile time.

The other option that worked was to simply rename my key and substitute root_rsa-2048.pem at the mcuboot folder that contains all of the default keys.

Please let me know when the issue has been fixed.

Thank you! 😀

RE: Problem with signing images for OTA DFU

Einar Thorsrud — Tue, 08 Dec 2020 14:22:15 GMT

Hi,

There is unfortunately an issue with too little stack in the sample. You can fix this by adding CONFIG_MAIN_STACK_SIZE=4096 to prj.conf.

As a general tip you can often find these problems by testing with CONFIG_DEBUG=y (though in this case that would not work on the nRF52832 without removing a few things, as the app would be too large to fit in flash).

RE: Problem with signing images for OTA DFU

dstarling — Tue, 08 Dec 2020 06:50:18 GMT

I also am having the exact same issue currently that I program the smp_svr example and no matter what I seem to do, it just continues in the same reboot loop as shown above. Since I see that it is not just me, I guess I'll go work on something else and monitor this thread. Also I am trying to get this to work on the nrf52840dk_nrf52840 dev board.

RE: Problem with signing images for OTA DFU

Antonio — Mon, 07 Dec 2020 16:47:07 GMT

Hi Einar,

My request is more basic right now. I cannot get the smp_svr sample working on the BT configuration not even with the default signature. I have tried 1.4.0, 1.4.1-rc1 and 1.4.99-dev1.

We already know that the manual west instructions for smp_svr sample do not work for the BT configuration, since they have the header size problem, so I opted for the Segger Studio option by including the CONFIGs from overlay-bt.conf to prj.conf and compiled-flashed, as is, to a nrf52dk_nrf52832 board, and the result in the serial terminal is a continuous re-boot from mcuboot with no error or warning, maybe rejecting the image in slot-0.

Can you tell me how to make work the smp_svr sample with the BT configuration, as is?

Thanks!

RE: Problem with signing images for OTA DFU

Einar Thorsrud — Fri, 04 Dec 2020 10:05:22 GMT

Hi,

I am sorry for the delay with this. I do not have a proper way of handling this yet, but the R&D team responsible has it on their list.

There is a dirty but very simple workaround you can do though, which is to simply replace the path to the default key with the path to your key in ncs/bootloader/mcuboot/boot/zephyr/Kconfig:

devzone.nordicsemi.com/.../5460.Kconfig.diff

This is not ideal, but it is a simple workaround that works.

RE: Problem with signing images for OTA DFU

Antonio — Thu, 03 Dec 2020 23:57:03 GMT

Hi Einar,

I tried again with the sample app smp_svr from the v1.4.1-rc1, using the default keys, not even mine, and could not make it work. It would keep reseting, I imagine because it is not accepting the primary image.

Can you make it work with that sample code in the BLE configuration, flash the first image, create another and OTA it, and send me a step by step of how to do it?

Or, if you prefer, copy the smp_svr folder outside ncs, like ~/Documents, make it work in the BLE configuration, flash the first image, create another and OTA it, and attach here the folder? I can just check what you did in the config files.

At this point I am feeling helpless and I already tried everything.

Thanks.

RE: Problem with signing images for OTA DFU

Einar Thorsrud — Tue, 01 Dec 2020 13:35:11 GMT

Hi Antonio,

No, it is not fixed in 1.4.1. I think the only way around it for now is to set the key configurations in your app for the app and in the mcboot folder in within NCS. It has been reported though and the developers are looking at it, so I hope it will be fixed in 1.5.

RE: Problem with signing images for OTA DFU

Antonio — Mon, 30 Nov 2020 20:20:24 GMT

Hi Einar,

Do you have news on this?

I saw that there is a 1.4.1-rc1. Do you think it is fixed there?

Thanks!

RE: Problem with signing images for OTA DFU

Einar Thorsrud — Mon, 23 Nov 2020 11:38:13 GMT

Hi,

I am sorry this has taken so long, but we are still looking into this. There is also another bug in NCS 1.4 which prevents setting MCUboot overlay via CMakeLists.txt. So instead the key file must be specified on the command line similar to this instead:

west build -b nrf52dk_nrf52832 --pristine -- -Dmcuboot_OVERLAY_CONFIG=mcuboot.conf

That brings us a bit further, but are still some issues. I am discussing with the R&D team and hope to have a proper solution in a few days.

RE: Problem with signing images for OTA DFU

Antonio — Fri, 20 Nov 2020 15:30:56 GMT

Hi Einar,

That is how I was doing it on v1.3.2. It does not work on v1.4.0, that is the reason I started again this thread, when 1.4.0 was official.

This is a functionality esencial and basic, signed OTA DFU, and the sample that I included is from the NCS.

Could you please modify the sample included so that it works, or should we all stay away from 1.4.0 for now?

Thank you.

RE: Problem with signing images for OTA DFU

Einar Thorsrud — Fri, 20 Nov 2020 13:29:38 GMT

Hi,

I am also not able to get this to work as you want in NCS 1.4. The logic is changed a bit and it does not seem straightforward to adapt it to refer to external keys. Perhaps another approach in the mean time could be to copy the key in the mcuboot folder and refer to it, then delete it again if you write a build script, as suggested in this post.

RE: Problem with signing images for OTA DFU

Einar Thorsrud — Thu, 19 Nov 2020 11:48:27 GMT

Hi,

I am sorry for the delay. I have not been able to test your project yet, but I will do so and get back to you later today.

RE: Problem with signing images for OTA DFU

Antonio — Tue, 17 Nov 2020 19:07:58 GMT

Hi Again Einar,

I tried the new PR as presented, and did not work either.

I am attaching the project as modified and tested. Can you try to cmake it and tell me what is wrong? It includes a temporary pem key for testing purposes that I created using imgtool

To reproduce:

Environment: Ubuntu 20.04, SES v5.10d, Clean NCS v1.4.0 @ ~/ncs
Updated the affected files as PR-3239.
Did a west update, which brought the updated mcuboot kconfig as in PR 129
Copied smp_svr from samples to ~/Documents
Modified as per original instructions to include the mcu_boot child image
You can find the modified project, including the pem file, as an attachment.

Can you please cmake it and tell me what I might be doing wrong?

Thanks!

devzone.nordicsemi.com/.../5265.smp_5F00_svr.zip

RE: Problem with signing images for OTA DFU

Einar Thorsrud — Mon, 16 Nov 2020 10:02:44 GMT

Hi,

I am sorry for not getting back to you sooner. I got the same problem as you when I tested, and it turns out that the reason was that this PR (sdk-mcuboot 129) is not enough. You also need this PR (sdk-nrf 3239) (it is linked to in the first one, but it is easy to miss it). With this you can use the same approach in NCS 1.4 as in NCS 1.3.

RE: Problem with signing images for OTA DFU

Antonio — Sun, 15 Nov 2020 15:44:29 GMT

Hi Einar,

I am very eager to jump to 1.4. Do you know if this has been fixed or there is a workaround?

Thanks!

RE: Problem with signing images for OTA DFU

Einar Thorsrud — Wed, 04 Nov 2020 15:27:28 GMT

Hi,

There seems to be more problems with this in 1.4 then just what is fixed by this PR. I am not able to make it work with 1.4 either, but unfortunately I have not made any progress yet. I am checking with the developer and will let you know when I know more.

RE: Problem with signing images for OTA DFU

Antonio — Tue, 03 Nov 2020 20:01:48 GMT

Hi Einar,

I think I must be doing something wrong because I tried all the combinations possible and neither one worked.

I modified Kconfig as you and the PR described, tried with and without default (which should not matter because i am changing the key) tried the key with absolute and relative paths (relative ended up compiling).

I also tried with and without the extra mcuboot.conf, calling the setting both CONFIG_BOOT_SIGNATURE_KEY_FILE and the new CONFIG_MCUBOOT_SIGNATURE_KEY_FILE, etc, etc.

This is my setting. I take the smp_srv project and place it under ~/Documents/, my key is on ~/Documents/tracker_sensor/Tools/psl-rsa-2048.pem, created using imgtool, and I added to prj.conf the folowing in order for it to load BT:

# Enable the Bluetooth (unauthenticated) and shell mcumgr transports.

CONFIG_MCUMGR_SMP_BT=y

CONFIG_MCUMGR_SMP_BT_AUTHEN=n

# Linux

CONFIG_BOOT_SIGNATURE_KEY_FILE="../../../Documents/tracker_sensor/Tools/psl-rsa-2048.pem"

and added also to CMakeLists.txt:

if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/mcuboot.conf")

set(mcuboot_CONF_FILE prj.conf ${CMAKE_CURRENT_LIST_DIR}/mcuboot.conf)

endif()

As well as the included mcuboot.conf.

So, I tried all combinations, some of them would not even make the project, some others would fail at compiling, some other would fail on runtime.

Bottom line is I am not sure if it is CONFIG_MCUBOOT_SIGNATURE_KEY_FILE or CONFIG_BOOT_SIGNATURE_KEY_FILE or a combination, if I need to modified CMakeLists to load mcuboot.conf, if the path is absolute or relative to my key,

Could you tell me in a few steps how to make smp_srv sample work out of tree?

Thanks!

RE: Problem with signing images for OTA DFU

Einar Thorsrud — Tue, 03 Nov 2020 13:47:59 GMT

Hi Antonio,

There is a bug in NCS 1.4 that causes problems in this case. BOOT_SIGNATURE_KEY_FILE needs to be duplicated in bootloader/mcuboot/zephyr/Kconfig, but that was removed from NCS 1.4. So you should put it back as done in this PR.

RE: Problem with signing images for OTA DFU

Antonio — Fri, 30 Oct 2020 19:56:41 GMT

Updated request now that v1.4.0 is official

I am using the just released v1.4.0, the sample which I started with smp_srv, with the board nrf52dk_nrf52832, but since now it does not loads BL automatically, I added to the pro.conf:

CONFIG_MCUMGR_SMP_BT=y

CONFIG_MCUMGR_SMP_BT_AUTHEN=n

This compiles and runs as expected, but does not OTA (as expected) since the new rule is that if no valid key is presented, you have to sign yourself afterwards. If you try to do an OTA, y connects, then you select “Test and verify” with the android app nRF Connect, and it keeps at “Validating” for like a minute, and then disconnects. The logger does not show any error, other that disconnecting…

If introduce a key, that in my case is:

CONFIG_MCUBOOT_SIGNATURE_KEY_FILE="~/Documents/tracker_sensor/Tools/psl-rsa-2048.pem"

The behavior is exactly the same as when I did not include any key.

And finally, if, as per last instructions, I modify CMakeLists.txt after minimum_required with:

if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/mcuboot.conf")

set(mcuboot_CONF_FILE prj.conf ${CMAKE_CURRENT_LIST_DIR}/mcuboot.conf)

endif()

And I include such file with:

CONFIG_MCUBOOT_SIGNATURE_KEY_FILE="~/Documents/tracker_sensor/Tools/psl-rsa-2048.pem"

Or:

CONFIG_BOOT_SIGNATURE_KEY_FILE="~/Documents/tracker_sensor/Tools/psl-rsa-2048.pem"

When I reload the project it responds with the following error:

CMake Warning at /home/antonio/ncs/zephyr/kernel/CMakeLists.txt:54 (message):

Single threaded mode (CONFIG_MULTITHREADING=n) is deprecated

MCUBoot bootloader key file: ~/Documents/tracker_sensor/Tools/psl-rsa-2048.pem

-- Configuring done

-- Generating done

-- Build files have been written to: /home/antonio/Documents/tests/smp_svr/build_nrf52dk_nrf52832/mcuboot

=== child image mcuboot - end ===

CMake Error at /home/antonio/ncs/nrf/cmake/mcuboot.cmake:112 (get_filename_component):

get_filename_component unknown component

/home/antonio/Documents/tests/smp_svr/mcuboot.conf

Call Stack (most recent call first):

/home/antonio/ncs/bootloader/mcuboot/zephyr/CMakeLists.txt:1 (include)

CMake Warning at /home/antonio/ncs/nrf/cmake/mcuboot.cmake:120 (message):

---------------------------------------------------------

--- WARNING: Using default MCUBoot key, it should not ---

--- be used for production. ---

---------------------------------------------------------

Call Stack (most recent call first):

/home/antonio/ncs/bootloader/mcuboot/zephyr/CMakeLists.txt:1 (include)

CMake Warning at /home/antonio/ncs/nrf/cmake/mcuboot.cmake:303 (message):

CONFIG_MCUBOOT_SIGNATURE_KEY_FILE is set to

"~/Documents/tracker_sensor/Tools/psl-rsa-2048.pem".

You are using the NCS Mcuboot signing, which means this option will be

ignored.

Image signing in NCS is done via the MCUboot image's

CONFIG_BOOT_SIGNATURE_KEY_FILE option.

Consider setting CONFIG_MCUBOOT_SIGNATURE_KEY_FILE in your application

image back to its default value, the empty string.

Call Stack (most recent call first):

/home/antonio/ncs/bootloader/mcuboot/zephyr/CMakeLists.txt:1 (include)

-- Configuring incomplete, errors occurred!

See also "/home/antonio/Documents/tests/smp_svr/build_nrf52dk_nrf52832/CMakeFiles/CMakeOutput.log".

See also "/home/antonio/Documents/tests/smp_svr/build_nrf52dk_nrf52832/CMakeFiles/CMakeError.log".

Project load failed

Reported error: solution load command failed (1)

Please advise…

RE: Problem with signing images for OTA DFU

Antonio — Wed, 28 Oct 2020 13:59:13 GMT

Thanks Einar,

I see that it is somehow fixed in v1.4.0-rc2, but I am failing to make it work so far. It does not say if the mcuboot.conf is still needed.

Also, and it has happened to me before, my modules that use the "u8_t" short typing start failing, they expect the normal "uint8_t". Do yo know if it is a header that I am missing?

Also a comment. if you do in ubuntu in a terminal "git checkout v1.4.0-rc2" it fails to find it. You have to use a GUI git handler like VS Code or SmartGit to do the checkout.

Thanks!

Update

It does look like the key directories is fixed on the new 1.4.0 release.

I failed to make smp_srv work though. I tested 1.4.0-rc2

I did not have a problem signing with the new CONFIG_MCUBOOT_SIGNATURE_KEY_FILE, which is supposed to take care of both signings, and is no longer an extension of the absolute position of mcuboot dir, and now yo have to add CONFIG_MCUMGR_SMP_BT=y and CONFIG_MCUMGR_SMP_BT_AUTHEN=n since BLE is not a default now.

I hope the is a guide (I did not find one), as the instructions to do BLE OTA changed, and this sample project is the only guide for that.

I'll wait for the final release to test again.

Thanks!

RE: Problem with signing images for OTA DFU

Einar Thorsrud — Wed, 28 Oct 2020 13:52:35 GMT

Hi Antonio,

[quote user="antoniordz"]The whole thing is a mess, I hope something is figured out for portability sake.[/quote]

It should be possible to do this more elegantly using a Zephyr module in the future. Then you can use _defconfig and point to a Zephyr module with your key (and code). That is not available in NCS 1.3.x, though.

[quote user="antoniordz"]I have another question, is there a guide or a plan to be able to have the BLE controller separately in its own image, so only the app can be OTA?[/quote]

I do not see how. The controller is part of the application (for the nRF52 series / single CPU) so it is not easily separated. (This is fundamentally different from when using the nRF5 SDK and SoftDevice, as then the SoftDevice and application are built independently).

Einar

RE: Problem with signing images for OTA DFU

Antonio — Wed, 28 Oct 2020 00:34:43 GMT

Hi Einar,

I did not think of that. My logic was that imgtool is being called from the ncs/bootloader/mcuboot location and it makes an assumption of going back from the zepyr env location and then forward, to where the default keys are, and from there I had to go back and into my own directory.

The main problem is that KConfig in prj.conf has a default on CONFIG_BOOT_SIGNATURE_KEY_FILE which if it is not set there, iot places a default, overriding whatever you do in CMakeLists.

And even when that is solved, there is still a problem with the key for mcuboot.conf.

The whole thing is a mess, I hope something is figured out for portability sake.

I have another question, is there a guide or a plan to be able to have the BLE controller separately in its own image, so only the app can be OTA?

Thanks!

RE: Problem with signing images for OTA DFU

Einar Thorsrud — Tue, 27 Oct 2020 14:35:39 GMT

Hi Antonio,

I see.

There are some issues with your Cmake code. ${CMAKE_CURRENT_SOURCE_DIR} gives you the absolute path, so it makes no sense to prefix it with ../../../. A possible way to solve this is to slightly adjust the suggestion from here and use something like this:

if (EXISTS "${CMAKE_CURRENT_LIST_DIR}/mcuboot.conf")
  set(mcuboot_CONF_FILE prj.conf ${CMAKE_CURRENT_LIST_DIR}/mcuboot.conf)
  set(CONFIG_BOOT_SIGNATURE_KEY_FILE "${CMAKE_CURRENT_LIST_DIR}/../../../psl-rsa-2048.pem")
endif()

But then you need to have both the mcuboot.conf and key file at the correct location. Also, this will only work if it comes before find_package(Zephyr).

Br,

Einar

RE: Problem with signing images for OTA DFU

Antonio — Tue, 27 Oct 2020 13:06:52 GMT

Thanks Einar.

Actually my question was not about how to detect the OS, but rather that setting the CONFIG_BOOT_SIGNATURE_KEY_FILE in CMakeLists did not work, as I highlighted in yellow, and even if it did, I would still need to find a way to set it for the mcuboot build, outside mcuboot.conf, which will not let me do conditionals to detect the OS.

Please advice.