Update Firmware (Bootloader and Application) from external flash

RE: Update Firmware (Bootloader and Application) from external flash

Simon — Wed, 31 Aug 2022 08:25:38 GMT

[quote user="Talisca"]But now I would like to know if there is any setting for the build process, so that this is set directly in the image trailer of the firmware? That would not only be very convinient in my eyes, but also a necessity. What would be the point of uploading a firmware that is not recognized as an upgrade by the bootloader? An uploaded firmware is always an upgrade in my use case.[/quote]

First I would like to inform you that it might be smart to confirm the image from within the image itself, this is how the NCS samples are doing it. For example, take a look at the http application update sample and the asset tracker v2 application. The reason for this is to avoid bricking the device. For example if you perform a DFU update with an unconfirmed image, and a fault happens during the Zephyr init process, the chip will reset (and not reach the point where it confirms itself), and it will swap back to the old image. If it's already confirmed, mcuboot will keep running that image and the device is bricked (unless you have added a possibility to let mcuboot perform the DFU update).

However, to answer your question, I think it should be feasible to confirm the image in the buil process. If you look under Image tool --> signing images, you can see that imagetool sign has a --confirm option. Try using that.

The app_update.bin file is created here and here I believe, so try modifying that fail and append --confirm.

Of course, you can also use app_to_sign.bin (see Using MCUboot in nRF Connect SDK) and sign it yourself following the guide https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/mcuboot_manual_sign

Best regards,

Simon

RE: Update Firmware (Bootloader and Application) from external flash

Talisca — Wed, 31 Aug 2022 05:59:20 GMT

I have found the solution by chance.
As already written, I had debugged mcuboot and had the assumption that you still have to somehow tell the bootloader that it is an upgrade.
I found the confirmation at developer.nordicsemi.com/.../design.html

Then I remembered that I had read in some articles that the application itself can confirm the swap with "boot_write_img_confirmed()". Somehow I had the suspicion that there must be a function to set the swap type. And indeed. All I needed for the last two weeks was a call to the function "boot_request_upgrade()" with "BOOT_UPGRADE_PERMANENT or BOOT_UPGRADE_TEST".

But now I would like to know if there is any setting for the build process, so that this is set directly in the image trailer of the firmware? That would not only be very convinient in my eyes, but also a necessity. What would be the point of uploading a firmware that is not recognized as an upgrade by the bootloader? An uploaded firmware is always an upgrade in my use case.

RE: Update Firmware (Bootloader and Application) from external flash

Talisca — Tue, 30 Aug 2022 13:56:29 GMT

Hello Simon,

I followed the instructions for DFU over Bluetooth and that works fine.

Only my use case is quite different, in that I write the firmware with my own method into the flash. mcumgr, smp etc. is not used at all in our case.

The firmware is in the right place, I have already checked that. When I debug mcuboot, I also see that it reads the header information correctly and also checks if both image slots are compatible.
At the end in the function "boot_prepare_image_for_update" in loader.c the swap type is set to none and that's it.
The macro "BOOT_IS_UPGRADE" checks only for BOOT_SWAP_TYPE_TEST, BOOT_SWAP_TYPE_REVERT and BOOT_SWAP_TYPE_PERM. This apparently makes mcuboot think that there is no upgrade and simply ignores the firmware. It's almost like you have to set another flag somewhere so that mcuboot knows about the upgrade.
I don't have time to debug this extensively, so far I've already lost too much time because of this 😞

RE: Update Firmware (Bootloader and Application) from external flash

Simon — Tue, 30 Aug 2022 13:02:59 GMT

Hello, I didn't get time to read detailed through this whole message, but I'll just answer quick before I leave work today.

[quote user="Talisca"]

But now I would like to attempt the application firmware update: This simply does not work at all. Even with a minimal project from the internal flash mcuboot refuses to do anyhing.

For testing I copied the following small project: https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/nsib_mcuboot_smp

[/quote]

It does not seem like this project was made to update the main application, only mcuboot. To update the main application, check out Add DFU support to your application. It was made for NCS v1.8.0, but I think it should work with NCS v2.0.0 as well.

Let me know if that guide is not suficcient, and I will assist you tomorrow.

RE: Update Firmware (Bootloader and Application) from external flash

Talisca — Tue, 30 Aug 2022 08:20:03 GMT

First of all, thanks for the reply. I have looked at the sample projects, continued to read through various posts and now have wasted another week with more attempts.

I just don't get it at all.

In the meantime I have managed to update mcuboot, but not the way I would like.
It seems that mcuboot can only be "updated" via the internal flash, which in the Immutable Bootloader can be done simply
by booting the image with the largest version.
If this is the case, then I can live with that. I just have to develop my own routine, which copies the image from the external flash to the internal flash.

For now I would declare the topic "updateable bootloader" as finished for me. Unless someone has additional information.

But now I would like to attempt the application firmware update: This simply does not work at all. Even with a minimal project from the internal flash mcuboot refuses to do anyhing.

For testing I copied the following small project: https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/nsib_mcuboot_smp

Since this project cannot be built with nRF Connect SDK v.2.0.0, see my changes:

diff --git a/samples_for_nrf_connect_sdk-main/bootloader_samples/nsib_mcuboot_smp/CMakeLists.txt b/nsib_mcuboot_smp/CMakeLists.txt
index ecb7d24..9010aa2 100644
--- a/samples_for_nrf_connect_sdk-main/bootloader_samples/nsib_mcuboot_smp/CMakeLists.txt
+++ b/nsib_mcuboot_smp/CMakeLists.txt
@@ -2,6 +2,10 @@

 cmake_minimum_required(VERSION 3.20.0)

+set(mcuboot_CONF_FILE
+   ${CMAKE_CURRENT_SOURCE_DIR}/child_image/mcuboot.conf
+)
+
 find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
 project(hello_world)
 
diff --git a/samples_for_nrf_connect_sdk-main/bootloader_samples/nsib_mcuboot_smp/prj.conf b/nsib_mcuboot_smp/prj.conf
index 4d50428..3e8e5eb 100644
--- a/samples_for_nrf_connect_sdk-main/bootloader_samples/nsib_mcuboot_smp/prj.conf
+++ b/nsib_mcuboot_smp/prj.conf
@@ -1,13 +1,11 @@
-CONFIG_BOOTLOADER_MCUBOOT=y
 CONFIG_MCUMGR=y
-CONFIG_MCUMGR_SMP_UART=y
-CONFIG_MCUMGR_CMD_IMG_MGMT=y
+CONFIG_BOOTLOADER_MCUBOOT=y

 CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2304
 CONFIG_FLASH=y

 CONFIG_SECURE_BOOT=y
-CONFIG_SB_SIGNING_KEY_FILE="nsib_priv.pem"
+CONFIG_SB_SIGNING_KEY_FILE="private.pem"
 CONFIG_BUILD_S1_VARIANT=y
 # Need to lower the number of counter slots to be able to update several times. Do not know the best number yet.
 CONFIG_SB_NUM_VER_COUNTER_SLOTS=120
 
diff --git a/samples_for_nrf_connect_sdk-main/bootloader_samples/nsib_mcuboot_smp/src/main.c b/nsib_mcuboot_smp/src/main.c
index 1d885f2..39c9e4d 100644
--- a/samples_for_nrf_connect_sdk-main/bootloader_samples/nsib_mcuboot_smp/src/main.c
+++ b/nsib_mcuboot_smp/src/main.c
@@ -6,10 +6,9 @@

 #include <zephyr.h>
 #include <sys/printk.h>
-#include "img_mgmt/img_mgmt.h"

 void main(void)
 {
-    img_mgmt_register_group();
-       printk("Change this to see change\n");
+       printk("Hello World! %s\n", CONFIG_BOARD);
+       printk("My Version is %s\n", CONFIG_MCUBOOT_IMAGE_VERSION);
 }
 
diff --git a/samples_for_nrf_connect_sdk-main/bootloader_samples/nsib_mcuboot_smp/child_image/mcuboot.conf b/nsib_mcuboot_smp/child_image/mcuboot.conf
index 24ccbac..4d4ea08 100644
--- a/samples_for_nrf_connect_sdk-main/bootloader_samples/nsib_mcuboot_smp/child_image/mcuboot.conf
+++ b/nsib_mcuboot_smp/child_image/mcuboot.conf
@@ -2,3 +2,6 @@ CONFIG_LOG=y
 CONFIG_LOG_MODE_MINIMAL=y

 CONFIG_FW_INFO_FIRMWARE_VERSION=5
+
+CONFIG_FLASH=y
+CONFIG_MAIN_STACK_SIZE=10240
\ No newline at end of file

With these changes the project can be built finally.

As you can read in various guides, after the initial build I put the build/partitions.yml file as pm_static.yml in the root directory.

I get the following partition report:

  flash_primary (0x100000 - 1024kB):
+--------------------------------------------------+
+---0x0: b0_container (0x9000 - 36kB)--------------+
| 0x0: b0 (0x8000 - 32kB)                          |
| 0x8000: provision (0x1000 - 4kB)                 |
+---0x9000: s0 (0xc200 - 48kB)---------------------+
| 0x9000: s0_pad (0x200 - 512B)                    |
+---0x9200: s0_image (0xc000 - 48kB)---------------+
| 0x9200: mcuboot (0xc000 - 48kB)                  |
+--------------------------------------------------+
| 0x15200: EMPTY_0 (0xe00 - 3kB)                   |
+---0x16000: s1 (0xc200 - 48kB)--------------------+
| 0x16000: s1_pad (0x200 - 512B)                   |
| 0x16200: s1_image (0xc000 - 48kB)                |
+--------------------------------------------------+
| 0x22200: EMPTY_1 (0xe00 - 3kB)                   |
+---0x23000: mcuboot_primary (0x6e000 - 440kB)-----+
| 0x23000: mcuboot_pad (0x200 - 512B)              |
+---0x23200: app_image (0x6de00 - 439kB)-----------+
+---0x23200: mcuboot_primary_app (0x6de00 - 439kB)-+
| 0x23200: app (0x6de00 - 439kB)                   |
+--------------------------------------------------+
| 0x91000: mcuboot_secondary (0x6e000 - 440kB)     |
| 0xff000: EMPTY_2 (0x1000 - 4kB)                  |
+--------------------------------------------------+

  sram_primary (0x40000 - 256kB):
+--------------------------------------------+
| 0x20000000: sram_primary (0x40000 - 256kB) |
+--------------------------------------------+

If I flash the merged.hex after the initial build and restart the mcu, I get the following output:

*** Booting Zephyr OS build v3.0.99-ncs1  ***
Attempting to boot slot 0.
Attempting to boot from address 0x9200.
Verifying signature against key 0.
Hash: 0xea...6a
Firmware signature verified.
Firmware version 5
*** Booting Zephyr OS build v3.0.99-ncs1  ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
I: Bootloader chainload address offset: 0x23000
*** Booting Zephyr OS build v3.0.99-ncs1  ***
Hello World! nrf52840dk_nrf52840
My Version is 1.1.1

And again the question, what is mcuboot doing here? Why do the lines "Primary image" and "Secondary image" appear twice? Why is magic always unset?
If I change CONFIG_MCUBOOT_IMAGE_VERSION in prj.conf of my application and build again, I get the file app_update.bin. I have read often enough that this should be the binary of my application for the update process. A look into the paritition table tells me that mcuboot_secondary starts at 0x91000.
So for me this is the start address where the firmware has to be written in.
Using my own Python script, I convert the .bin file to Intel Hex format with address offset 0x91000.

Example:

:020000040009F1
:101000003DB8F3960000000000020000EC62000012
:1010100000000000010105000000000000000000C9
:10102000FFFFFFFFFFFFFFFFFFFFFFFFFFD0
:10103000FFFFFFFFFFFFFFFFFFFFFFFFC0
...

I flash this file successfully with nrfjprog.
If I now reset the mcu, I get the following output:

*** Booting Zephyr OS build v3.0.99-ncs1  ***
Attempting to boot slot 0.
Attempting to boot from address 0x9200.
Verifying signature against key 0.
Hash: 0xea...6a
Firmware signature verified.
Firmware version 5
*** Booting Zephyr OS build v3.0.99-ncs1  ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Bootloader chainload address offset: 0x23000
*** Booting Zephyr OS build v3.0.99-ncs1  ***
Hello World! nrf52840dk_nrf52840
My Version is 1.1.1

Notice that the output "I: Swap type: none" before "I: Bootloader chainload address offset: 0x23000" is suddenly missing. But otherwise there are no changes.

So what am I doing wrong? Or is mcuboot no longer functional by now?

RE: Update Firmware (Bootloader and Application) from external flash

Simon — Tue, 23 Aug 2022 17:32:34 GMT

I'm not sure if updating mcuboot on the 52840 is supported, see https://devzone.nordicsemi.com/f/nordic-q-a/84007/does-mcuboot-have-a-mechanisms-to-update-the-bootloader-itself/350956#350956

However, I found this ticket: Update mcuboot with SMP. In that ticket, it seems like my colleague was able to update MCUboot. Test the sample he linked to and see if you're able to do it. He also gives some pointers to some samples that supports putting the update in external flash.

If this didn't help, please let me know and I'll take a closer look at it.

Best regards,

Simon