Hello!
I am creating a DFU application and want to customize the bootloader code.
I used this example: https://devzone.nordicsemi.com/guides/nrf-connect-sdk-guides/b/software/posts/ncs-dfu
How can you include a custom MCUBOOT when doing this example?
Hi Markus,
We have a related case here: https://devzone.nordicsemi.com/f/nordic-q-a/86748/override-mcuboot-build-directory
I haven't tried to do custom build MCUBoot myself yet but you can find some suggestions in the case.
Hi, thanks for quick answer!
I went down into a ticket rabbit hole and found this: https://devzone.nordicsemi.com/f/nordic-q-a/79331/how-to-create-own-mcuboot-repository-and-module-on-ncs1-6-1
Sounds appropriate for creating a custom MCUBoot correct?
Hi Markus,
Yes, you can follow the instruction in the ticket. In many cases, if it's just some configuration (for example custom keys, custom GPIO etc) you can just use the configuration overlay to change it and don't need to fork a new MCUBoot repo.
Our plan is to do a LZ4 compressed DFU. So we are planning to implement the decompression in a custom MCUBoot repo.
I suppose this cannot be done with just some configuration?
I agree. That would require the modification of MCUBoot.
Please be aware that MCUBoot usually handle image swap (and do DFU recovery mode of you enable this feature) and it doesn't handle the receiving of the image. So what you can also do is to receive the image by your application (using SMP_SVR for example), decompress it and store it to the 2nd slot and then you can trigger the reset so that the MCUBoot can swap the image.
I agree. That would require the modification of MCUBoot.
Please be aware that MCUBoot usually handle image swap (and do DFU recovery mode of you enable this feature) and it doesn't handle the receiving of the image. So what you can also do is to receive the image by your application (using SMP_SVR for example), decompress it and store it to the 2nd slot and then you can trigger the reset so that the MCUBoot can swap the image.
Hi again! Thanks for the quick answer :)
I did not really understand what you meant here:
So what you can also do is to receive the image by your application (using SMP_SVR for example), decompress it and store it to the 2nd slot and then you can trigger the reset so that the MCUBoot can swap the image.
After looking at this: https://docs.zephyrproject.org/2.6.0/samples/subsys/mgmt/mcumgr/smp_svr/README.html
So the SMP_SVR will flash. Since SMP_SVR needs to do a test before it allows image swap. I suppose the decompression part will come before test, after flash? And is that done through MCUBoot aswell?
Hi Markus,
The main purpose of SMP_SVR is to integrate with your application and can receive the image when the application is running. It will write the new image into flash.
The test and swap is handled by MCUBoot, not SMP_SVR.
You can choose to modify SMP_SVR to do the decompression instead of MCUBoot. This way the MCUBoot will not need to be modified.
Oh ok I see :)
That seems like a very good option. So the decompressed image file would then end up in the image slot correct?
Do you have a recommendation for where to put the decompression in the SMP_SVR example?
Hi Markus,
I haven't looked deep into the code of smp_svr. So I can't point you to the exact place of the flash writing when receiving new image.
But as far as I know the flash handling is in fs_mgmt.c in \zephyr\subsys\mgmt\mcumgr\lib\cmd\fs_mgmt\src. And the image management is in \zephyr\subsys\mgmt\mcumgr\lib\cmd\img_mgmt.
Also, pay attention to the smp.c file, it's when the SMP request is handled.
Hi again!
We have looked into the files.
It seems like img_mgmt.c is an appropriate file to modify. There is a function at line 392 called img_mgmt_upload(struct mgmt_ctxt *ctxt). Also check Line 522 ("/* Write the image data to flash. */")
We believe this could be a good location to include decompress. What do you think? Or should it be "deeper" in the data sending.
