nRF5340 non-simultaneous netcore updates with external QSPI

RE: nRF5340 non-simultaneous netcore updates with external QSPI

Sigurd Hellesvik — Fri, 25 Nov 2022 10:24:57 GMT

Hi Darshan,

There have been a lot of discussion in this case, so it can be hard to tell which issue you are referring to

Please create a new ticket, and we will help you with your problem.
Feel free to link to this case in your new ticket.

Regards,
Sigurd Hellesvik

RE: nRF5340 non-simultaneous netcore updates with external QSPI

ErDarshan — Fri, 25 Nov 2022 06:57:56 GMT

Any update?
I am also facing the same issue. Saving netcore image in mcuboot_secondary and setting permanent flag, upgrade app core with net core image.

How to have support of non simultaneous upgrade on NRF53 (App core & Net core)? I am using NCS2.1.0

RE: nRF5340 non-simultaneous netcore updates with external QSPI

Riccardo Gaiati — Thu, 15 Sep 2022 22:04:53 GMT

Hi Simon,

is there any update about a new version of MCUboot which fixes this problem ? I have been told sdk 2.1.0 might contain some fixes, but as far as i can see, it does not.

Thanks in advance !

RE: nRF5340 non-simultaneous netcore updates with external QSPI

Sigurd Hellesvik — Tue, 09 Aug 2022 08:18:18 GMT

Hi,

I have explained how to do relative-path MCUBoot keys in another ticket, and I guess you should be able to use the same method for the hooks. I will copy the relevant answer in below here as well, as the context is not really needed:

Here are some info on how I have been setting the path to the private key for MCUBoot:

If you have your mcuboot.conf inside the child_image/ folder, the application will look for your key in "ncs/bootloader/mcuboot/boot/zephyr/" I think.

To work around this, you can create a "child_image/mcuboot" folder, and place the key + a prj.conf file inside this folder, as I show in my sample. This way, mcuboot will find your key file in your own project (See Multi Image builds for the explanation of this folder setup).

Another alternative is to use CMake to add the key yourself. To do this, you need some extra apostrophes and backslashes, but the following line into CMakeLists.txt should point to a key in the directory below your source directory.

set(mcuboot_CONFIG_BOOT_SIGNATURE_KEY_FILE \\"${CMAKE_CURRENT_SOURCE_DIR}/../private_key.pem\\")

(Try "message(${CMAKE_CURRENT_SOURCE_DIR}) in CMake to test the path)
"

Is this what you were looking for?

EDIT: Since you use windows, you might have to pay some attention to which way the slashes go in the CMake path definitions. Also from the same post as the one I linked above:
"Escaping the backslashes may have worked too, but I have only tried just changing all the back slashes to forward slashes. This is probably only going to be an issue on Windows based development systems."

Regards,
Sigurd Hellesvik

RE: nRF5340 non-simultaneous netcore updates with external QSPI

D Miller — Mon, 08 Aug 2022 13:35:52 GMT

Is it possible to set a path for this file relative to my source directory (such as the hooks file I wish to use being in my project directory)? Seems like the current setup makes it a little hard to introduce the hooks from an out-of-tree application without using an absolute path for the hooks file.

RE: nRF5340 non-simultaneous netcore updates with external QSPI

D Miller — Tue, 02 Aug 2022 16:42:22 GMT

Hello,

The tips to get the hooks file started were useful. I am needing to do a little more testing to confirm but I might have a hooks file way to perform this update scheme. Have done a net core update.

Will know more by the end of the week but I am no longer stuck.

Thanks,

Derrick

RE: nRF5340 non-simultaneous netcore updates with external QSPI

Simon — Fri, 29 Jul 2022 13:06:21 GMT

Hello Miller,

What is the current state on this? Were you able to implement the changes to a hook file? Unfortunately, I haven't gotten time myself to do it yet. I will be gone for the next two weeks, and my colleague Sigurd will watch the case in the meanwhile (he will be gone until 2 of Aug.).

Best regards,

Simon

RE: nRF5340 non-simultaneous netcore updates with external QSPI

Simon — Thu, 21 Jul 2022 21:38:43 GMT

[quote user="D Miller"]Yes, I did try with and without CONFIG_BOOT_IMAGE_ACCESS_HOOKS. This required I do the whole CONFIG_UPDATEABLE_IMAGE_NUMBER=2 and CONFIG_BOOT_UPGRADE_ONLY=y to get running (the depends for the KConfig on that flag seem to confirm) as there is code in the hooks that assume >1 slots on the secondary and the partitions only seem to be correctly generated with that configuration. But we are not wanting upgrade only updates.[/quote]

I was able to enable CONFIG_BOOT_IMAGE_ACCESS_HOOKS, I simply set CONFIG_BOOT_IMAGE_ACCESS_HOOKS=y inside smp_svr\child_image\mcuboot.conf (should be set in mcuboot sample, not main application). However, I did get some errors, but that is not related to the Kconfigs, but the nrf53_hooks.c file. The nrf53_hooks.c file tries to access the primary_1 partition, which is not present in your case since you're not doing multi-image updates. I then modified nrf\modules\mcuboot\hooks\nrf53_hooks.c like shown below and was able to build the sample:

diff --git a/modules/mcuboot/hooks/nrf53_hooks.c b/modules/mcuboot/hooks/nrf53_hooks.c
index ebc61666c..fb7213f3c 100644
--- a/modules/mcuboot/hooks/nrf53_hooks.c
+++ b/modules/mcuboot/hooks/nrf53_hooks.c
@@ -24,7 +24,7 @@ int boot_read_image_header_hook(int img_index, int slot,
 	if (img_index == 1 && slot == 0) {
 		img_head->ih_magic = IMAGE_MAGIC;
 		img_head->ih_hdr_size = PM_MCUBOOT_PAD_SIZE;
-		img_head->ih_load_addr = PM_MCUBOOT_PRIMARY_1_ADDRESS;
+		img_head->ih_load_addr = 0x00;//PM_MCUBOOT_PRIMARY_1_ADDRESS;
 		img_head->ih_img_size = PM_CPUNET_APP_SIZE;
 		img_head->ih_flags = 0;
 		img_head->ih_ver.iv_major = 0;
@@ -81,10 +81,10 @@ int network_core_update(bool wait)
 	void *mock_flash;
 	size_t mock_size;
 
-	mock_flash_dev = device_get_binding(PM_MCUBOOT_PRIMARY_1_DEV_NAME);
+	/*mock_flash_dev = device_get_binding(PM_MCUBOOT_PRIMARY_1_DEV_NAME);
 	if (mock_flash_dev == NULL) {
 		return -ENODEV;
-	}
+	}*/
 
 	mock_flash = flash_simulator_get_memory(NULL, &mock_size);
 	hdr = (struct image_header *) mock_flash;

Then I could see that CONFIG_BOOT_IMAGE_ACCESS_HOOKS was set to y and that CONFIG_BOOT_IMAGE_ACCESS_HOOKS_FILE was equal to "nrf/modules/mcuboot/hooks/nrf53_hooks.c" in smp_svr\build\mcuboot\zephyr\.config.

Be aware that the above file is not meant to work, I made it just so the code would compile, and it can be a starting point for creating your own custom hook file.

Of course the proper way would be to add your own file to nrf/modules/mcuboot/hooks/ and set CONFIG_BOOT_IMAGE_ACCESS_HOOKS_FILE (in smp_svr\child_image\mcuboot.conf) accordingly.

[quote user="D Miller"] there seems to be some discussion relating to this specifically where hooks do not cover the functionality we are seeking.[/quote]

Yes, that is true. The nrf53_hooks.c file is tailored towards multi-image, so it needs to be modified to your need, non simultaneous netcore/appcore updates.

I did try to play around and add the changes you made to loader.c into the hooks file, but wasn't able to make it work (the hooks stuff are new to me and I don't have complete control of how it works). I will see if I can get it to work the next days. If you succeed if would be nice if you could share the solution, as I'm sure many other customer will benefit from it as well.

Best regards,

Simon

RE: nRF5340 non-simultaneous netcore updates with external QSPI

D Miller — Thu, 21 Jul 2022 15:14:09 GMT

(moved my reply up here)

Hello,

Yes, I did try with and without CONFIG_BOOT_IMAGE_ACCESS_HOOKS. This required I do the whole CONFIG_UPDATEABLE_IMAGE_NUMBER=2 and CONFIG_BOOT_UPGRADE_ONLY=y to get running (the depends for the KConfig on that flag seem to confirm) as there is code in the hooks that assume >1 slots on the secondary and the partitions only seem to be correctly generated with that configuration. But we are not wanting upgrade only updates.

The net core updates in nrf53_hooks.c are hooked to `boot_copy_region_post_hook` and `boot_serial_uploaded_hook`. The first is called in loader.c `boot_copy_image` which is only used in `MCUBOOT_OVERWRITE_ONLY` configurations. And the latter is used for serial recovery.

In the github patch conversation ([nrf noup] loader: Fix reading reset addr to support ext flash by chrta · Pull Request #197 · nrfconnect/sdk-mcuboot · GitHub), there seems to be some discussion relating to this specifically where hooks do not cover the functionality we are seeking.

RE: nRF5340 non-simultaneous netcore updates with external QSPI

Simon — Thu, 21 Jul 2022 12:00:15 GMT

Did you remember to enable CONFIG_BOOT_IMAGE_ACCESS_HOOKS?

Then add CONFIG_BOOT_IMAGE_ACCESS_HOOKS_FILE to your prj.conf file and set it to your custom hook file. That is better than trying to modify loader.c. By default the hook file modules/mcuboot/hooks/nrf53_hooks.c is used: https://github.com/nrfconnect/sdk-nrf/blob/v2.0.0/modules/mcuboot/boot/zephyr/Kconfig#L95.

Best regards,

Simon

RE: nRF5340 non-simultaneous netcore updates with external QSPI

Simon — Wed, 20 Jul 2022 21:56:08 GMT

I've asked internally about your patch. I'll get back to you.

RE: nRF5340 non-simultaneous netcore updates with external QSPI

Simon — Tue, 19 Jul 2022 17:53:24 GMT

Hello D Miller,

I got affected by the SAS strike in Norway and didn't get home until today.

I'll look into this the next days

Simon

RE: nRF5340 non-simultaneous netcore updates with external QSPI

D Miller — Tue, 19 Jul 2022 13:44:47 GMT

Hello Simon,

Has anyone had a chance to take a look at this matter?

RE: nRF5340 non-simultaneous netcore updates with external QSPI

Simon — Wed, 13 Jul 2022 16:38:08 GMT

Hello D Miller,

Sorry for the late repsonse in this. A huge part of the support team is on summer vacation and that may cause some delayed responses.

I will test your sample Before the weekend/Monday and investigate the root cause of this.

Best regards,

Simon

RE: nRF5340 non-simultaneous netcore updates with external QSPI

D Miller — Tue, 12 Jul 2022 18:42:13 GMT

I have applied the changes in that commit in the pull request and then tried the removal of the code block also suggested, both to no avail, the system still attempts all updates like they are for the application core.

I see the intention is to use nrf53_hooks.c to trigger a net core update but those hooks are only called in UPGRADE_ONLY configurations and I wish to retain app core reversion. It seems like the code block that was suggested to be removed in the other ticket is supposed to handle the "one core at a time" netcore updates but the flash simulator in RAM just isn't getting set up to pull the data from the external flash like it is in hooks.

So, I applied the patch like before which correctly runs the header check, but instead of removing the further down lines as the other thread suggested, I turned them into something closer to what is done in nrf53_hooks.c:

#if defined(CONFIG_SOC_NRF5340_CPUAPP) && defined(PM_CPUNET_B0N_ADDRESS)
        /* If the update is valid, and it targets the network core: perform the
         * update and indicate to the caller of this function that no update is
         * available
         */
        if (upgrade_valid && reset_addr > PM_CPUNET_B0N_ADDRESS) {
            BOOT_LOG_INF("Starting network core update");
            static const struct device *mock_flash_dev;
            void *mock_flash;
            size_t mock_size;

            BOOT_LOG_INF("Reading update image to flash simulator");
            mock_flash_dev = device_get_binding(PM_MCUBOOT_PRIMARY_DEV_NAME);
            if (mock_flash_dev == NULL) {
                swap_type = BOOT_SWAP_TYPE_NONE;
            }
            mock_flash = flash_simulator_get_memory(mock_flash_dev, &mock_size);
            int rc = flash_area_read(secondary_fa, 0U, mock_flash, hdr->ih_hdr_size + hdr->ih_img_size);
            if (rc != 0) {
                return BOOT_SWAP_TYPE_FAIL;
            }

            BOOT_LOG_INF("Starting PCD update to network core");
            hdr = (struct image_header *) mock_flash;
            uint32_t vtable_addr = (uint32_t)hdr + hdr->ih_hdr_size;
            uint32_t *vtable = (uint32_t *)(vtable_addr);
            rc = pcd_network_core_update(vtable, hdr->ih_img_size);
            if (rc != 0) {
                swap_type = BOOT_SWAP_TYPE_FAIL;
            } else {
                BOOT_LOG_INF("Done updating network core");
#if defined(MCUBOOT_SWAP_USING_SCRATCH) || defined(MCUBOOT_SWAP_USING_MOVE)
                /* swap_erase_trailer_sectors is undefined if upgrade only
                 * method is used. There is no need to erase sectors, because
                 * the image cannot be reverted.
                 */
                rc = swap_erase_trailer_sectors(state,
                    secondary_fa);
#endif
                swap_type = BOOT_SWAP_TYPE_NONE;
            }
        }
#endif /* CONFIG_SOC_NRF5340_CPUAPP */

I also added the needed includes at the top:

#if defined(CONFIG_SOC_NRF5340_CPUAPP) && defined(PM_CPUNET_B0N_ADDRESS)
#include <dfu/pcd.h> 
#include "flash_map_backend/flash_map_backend.h"
#include <zephyr/drivers/flash/flash_simulator.h>
#endif

No other changes to the SDK or project. With this, I can now perform net and app core updates one at a time from a single secondary slot on the external qspi in a way that still allows for reversion of the application core.

I don't feel like I'm doing everything correctly here, especially with the use of the flash simulator, but I can do my update scheme. I've uploaded my loader.c, otherwise it is v2.0.0 SDK.

devzone.nordicsemi.com/.../loader.c

RE: nRF5340 non-simultaneous netcore updates with external QSPI

Simon — Fri, 08 Jul 2022 12:58:20 GMT

Check out this ticket Busfault when MCUboot reads Network core secondary image header in external flash

Try applying this patch https://github.com/nrfconnect/sdk-mcuboot/pull/197/commits/b628d6e238bb15eae06a9582fb19b00ea4990e13 and see if you're able to update the netcore using external flash.

Best regards,

Simon