subsys/mgmt/hawkBit: Roadmap

[ycsin]

This issue list down a few things that can be improved or implemented in the hawkBit subsys.
Information about hawkBit server can be found at the Eclipse's Hawkbit website.

• hawkBit might have to erase the area when it fails to init the storage.
• SHA256 check for storage - pends subsys: storage: flash_map: Add mbedtls option for flash_area_check_int_sha256 #38982, or else both crypto libs will be compiled to do the same thing. (subsys/mgmt/hawkBit: Verify written image in slot1 #39070)
• Currently the thread invoking hawkbit APIs require stack size of 2~3kiB from my testing, and most of the time it is not running, so basically wasted RAM. We can reduce the RAM usage by using k_malloc, similar to the updatehub, and malloc for the buffer required for the next operation only and free it immediately after to keep the RAM usage minimal.
• mgmt: hawkbit: Convert to use setting subsys from raw NVS R/W #70290
• mgmt: hawkbit: Resume-able download, with download progress stored in flash #71952
• Download progress feedback
• Weak-linked device attribute function(s), so that user can override it in application without patching the source - mgmt: hawkbit: allow user defintion of device attributes. #37640 (subsys/mgmt/hawkbit: Convert hawkbit_get_device_identity to __weak #39068)
• Make server address, port and auth_token settable during runtime mgmt: hawkbit: make server address and port settable during runtime #68806
• Add custom user attributes mgmt: hawkbit: define attributes in the user application #69293
• mgmt: hawkbit: add support for custom device identity callback #70207
• mgmt: hawkbit: Add support for reboot after update #70241
• mgmt: hawkbit: rewrite hawkBit subsystem to use SMF. #71576

Comments are welcomed.

[real-tintin]

Hi,

Any updates w.r.t the Hawkbit roadmap?

We are using Hawkbit for our use case and have many times scratched our heads given the current implementation. I find that the implementation is rather difficult to follow (nested and complex execution/logic paths) and contains bugs e.g., no means to handle lost connections (has caused use troubled during ongoing downloads).

We have made custom adaptions to get it working for us. But we have now realised that a rewrite of the implementation would be needed, as we aim to add more functionality to it e.g., support for soft and force updates. I think that a state machine drive design i.e., a FSM would be well suited.

Any thoughts are welcome.

[ycsin]

Hi there, thanks for your interest in hawkBit!

Any updates w.r.t the Hawkbit roadmap?

Unfortunately no, I don't really have much time for this since I left the company that focused on IoT about 2 years ago.

We are using Hawkbit for our use case and have many times scratched our heads given the current implementation. I find that the implementation is rather difficult to follow (nested and complex execution/logic paths) and contains bugs e.g., no means to handle lost connections (has caused use troubled during ongoing downloads).

It is indeed intimidating at first glance, to follow the request and response it requires developers to literally scroll through the entire source. Download has to be restarted when the connection is lost 🙁, though it shouldn't be too hard to implement resumable download, we just have to save the progress into the nvs and modify the request string.

e.g., support for soft and force updates. I think that a state machine drive design i.e., a FSM would be well suited.

Although not clearly defined, hawkBit currently works in a FSM-ish fashion, there's definitely a big room for improvements, or even be rewritten to use SMF.

I also think that it is possible for hawkBit to do more than firmware upgrade, i.e. downloading custom payload & configuration files for the Settings subsystem.

But we have now realised that a rewrite of the implementation would be needed, as we aim to add more functionality to it

The hawkBit subsystem is currently not maintained, feel free to submit PRs!

[maass-hamburg]

as there are currently a lot major hawkBit PRs open and we are all are having limited resources, I made a litte priority list, beginning with the most important IMO:

• mgmt: hawkbit: make server address and port settable during runtime #68806 (includes migration to settings api)
• mgmt: hawkbit: define attributes in the user application #69293
• mgmt: hawkbit: correct ddi api calls #70386
• mgmt: hawkbit: add support for custom device identity callback #70207
• mgmt: hawkbit: autohandler and shell optimize #71037
• mgmt: hawkbit: reset action id #71918

I did not include the already approved PRs and trivial PRs. If you have any thoughts about it, feel free to comment.