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?
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.
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?
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.
Hi Markus,
I have to admit that I haven't tried to modify the img_mgmt library myself. But it looks to me that it's where the flash write actually happened. So the function img_mgmt_impl_write_image_data() will write the data it get from cbor_read_object() to flash. The decompression can happens here. I'm not sure how you do decompress but what the code here is doing is to write to flash chunk by chunk, until the /* If this is the last chunk */ .
So if your decompression would work with each chunk then you can do it on the fly, or you will do it when it's the last chunk and the whole image has been received. It depends on how you will do decompression.
Hi, we decided upon implementing decompression chunk by chunk, so in the img_mgmt_impl_write_image_data() function. A problem now occurrs here in the upload function of img_mgmt.c:
It seems like the img_mgmt_impl_upload_inspect does not accept the compressed file.
Hi Markus,
Please inspect which condition is failed inside img_mgmt_impl_upload_inspect().
I'm not so sure how you created the chunks of compressed file but it need to reflect how the "normal" image is sent.
Especially in the first chunk, it must include the image header, and the hash SHA256 of the image.
As far as I can see, to be able to achieve what you planning to do, a deep study of the img_mgt library is needed. And I would suggest to go step by step as follow :
- First please try to study a normal DFU update using a very small image maybe just 1-2 pages in flash size. This make it easy to study a normal successful DFU update.
- After that you can try uploading slightly modified version of the same image. You can do for example XOR the image with a key. Then when you "decompress" it you XOR with the same key. This way, you modified the image but the size of the image/chunk is not changed. To be able to do this you must be able to handle image header and the hash correctly. In addition at this step you would be able to manipulate how the image is written to flash.
- The last step would be to do actual compression and sending smaller chunk size or smaller number of chunks. Then when you write the image to flash you can do compression and manipulate the size of the image you are writing on flash. At this moment the offset in the image you sent and the offset in flash that you write the image would be different and you would need to find a solution to accommodate that.
Again, I haven't done this myself, so this is only a suggestion. And please be aware that img_mgmt is not our code it's contributed to Zephyr by mynewt.
