We're using NCS embedded into our Makefile-based build system to compile nRF5340 applications out-of-tree, but still having unresolved problems. The target board is a custom nRF5340 design. I'm continuously looking for alternative ways to achieve my goal: have MCUBoot run on APP core alongside our program + being able to perform FW upgrade. The problems are described in the linked ticket, now I'd like to show what other things I've been trying to do.
I've figured out how to manually configure, menuconfig and compile NCS's MCUBoot, so now I can generate MCUBoot's zephyr.hex independently of my application. Burning it to the flash isn't a problem either. Important to note, the application has no MCUBoot enabled as a child image (because we're having problems with it, see the linked ticket), it's a simple, standalone program.
Once the application is compiled, the resulting zephyr.hex is signed like this:
imgtool.py sign --align=1 --version="9.8.7" --header-size=512 --slot-size=0x77000 --hex-addr=0x10000 zephyr.hex signed.hex
Burning signed.hex to flash, MCUBoot successfully boots it. Great!
To check how MCUBoot swapping is operating, generated a different zephyr.hex and signed it:
imgtool.py sign --align=1 --version="9.8.7" --header-size=512 --slot-size=0x77000 --hex-addr=0x87000 ph2.hex signed.hex
(In DTS, slot0_partition begins at 0x10000, while slot1_partition begins at 0x87000, their sizes are 0x77000)
After burning the new FW image to slot1, MCUBoot does nothing, still boots the original image. (Swapping is enabled in MCUBoot config). This is what MCUBoot displays on serial console:
*** Booting Zephyr OS build v3.2.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: Bootloader chainload address offset: 0x10000
�*** Booting Zephyr OS build v3.2.99-ncs1 ***
================================================================================
project config: default sample project
...
...
I'd like to ask for some help, pointers or advices on the following questions:
- how can I make MCUBoot swap my new FW image? I believe this must be something with the lack of FW image trailers. If so, how can I manually generate trailers, or how to init them?
- Planned FW upgrade will be working like this: the running application gets the image file fragments via some kind of networking (e.g. TCP/IP). How can the application pass the fragments to MCUBoot? This is pretty unclear to me, as MCUBoot executes first after reset, but when it loads the application from slot0, MCUBoot no longer remains in memory, it's no longer running (if I'm not totally wrong). So if my assumption is right, there must be some MCUBoot-support code in Zephyr, which makes it possible to write new image's fragment to slot1, generate trailer and so on.
The first thing I want to experiment with is that a sample app is being burnt into slot0, and this app contains the image of a new app; this old sample app emits image fragments, which get written to slot1, and then resets and MCUBoot does its job (swaps images);
Many thanks, regards,
