Add new HAB fuse update type

[jsrc27]

Tested on Verdin i.MX8MP and Apalis i.MX8. Also did a test build for AM62 just to make sure the build still works on non-NXP machines.

Marking as draft for now till after the quarterly release is done, but should be ready for review otherwise.

[rborn-tx]

I'm about to start a review but I have some comments on the commit messages for things you may want to change:

Regarding commit "aktualizr-default-sec: Refactor common functions from bootloader action handler":

• Commit title exceeds the 68 characters limit.
• Typo: "prepartion" -> "preparation".

Regarding the two commits:

• They are signed with a personal e-mail account rather than a Toradex one.

[rborn-tx]

Finished my first pass.

I looks like we're in the right path but I raised a couple of points I believe we should address before merging.

[jsrc27]

Regarding the comments surrounding get-firmware-info, I'm not sure I understand the point. Currently the way the logic works is a fuse.yaml file will get generated if and only if there wasn't a file there to begin with. In normal operation this would only happen once really.

Once the file is generated based on the U-Boot environment (which is our source of truth), why not just pass normal operation (exit code 64) back to Aktualizr? Aktualizr already has the logic and operations to determine hash, length, target-name, and all that based on the file. Seems like it would just be duplicate work to have logic in the action handler to determine these when Aktualizr can already do this for us.

The end result is the same on the web UI the device reports a correct hash for the fuse secondary.

Then if the firmware file came from a real update then we would want to pass normal operation (exit code 64) to Aktualizr anyways.

[jsrc27]

Commit title exceeds the 68 characters limit.

Since when has this been an enforced rule in this repo?

I can see we have various commit titles that do not adhere to this.

[rborn-tx]

Commit title exceeds the 68 characters limit.

Since when has this been an enforced rule in this repo?

I can see we have various commit titles that do not adhere to this.

Sorry, my mistake. For some reason I thought we had that general rule but checking internal docs that doesn't seem to be the case.

[rborn-tx]

Regarding the comments surrounding get-firmware-info, I'm not sure I understand the point. Currently the way the logic works is a fuse.yaml file will get generated if and only if there wasn't a file there to begin with. In normal operation this would only happen once really.

Got it. So it's not bad in terms of flash wearing.

Once the file is generated based on the U-Boot environment (which is our source of truth), why not just pass normal operation (exit code 64) back to Aktualizr? Aktualizr already has the logic and operations to determine hash, length, target-name, and all that based on the file. Seems like it would just be duplicate work to have logic in the action handler to determine these when Aktualizr can already do this for us.

The end result is the same on the web UI the device reports a correct hash for the fuse secondary.

Then if the firmware file came from a real update then we would want to pass normal operation (exit code 64) to Aktualizr anyways.

The ideal case is to always get the information from the source of truth because then we'd report a correct hash even when the information changes outside of control of Aktualizr. If we were to follow this ideal case with the present approach then we'd need to always write to the file (pretending it was downloaded) to let Aktualizr determine all the information to report to the server which would be bad for flash wear. That's why I mentioned generating a temporary/volatile file and determining the information from it. Though this means some duplication of logic that exists inside Aktualizr, we're talking about a couple of lines of script code.

Having said that, I don't think it's bad to keep it as is since we expect users to only do fusing through subsystem updates. Thus, feel free to close the related threads if the above doesn't change your opinion.

[rborn-tx]

It looks like all points have been addressed - approving now.