How to create custom MCUBOOT for DFU

[Markus Arnoldsson]

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?

[Hung Bui]

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. 

[Markus Arnoldsson]

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?

[Hung Bui]

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. 

[Markus Arnoldsson]

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?

[Hung Bui]

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. 

[Markus Arnoldsson]

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?

[Hung Bui]

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. 

[Markus Arnoldsson]

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?