U-Boot RB1: Add support for EFI firmware capsule updates via fwupdtool

[b49020]

Enable support for EFI firmware capsule updates via fwupdtool on RB1 U-Boot. fwupd allows to perform over the air EFI firmware capsule updates. U-Boot script is updated to additionally build LVFS cabinet archive which can be deployed on RB1 using:

$ sudo fwupdtool install u-boot.cab

[b49020]

@lool Just fyi.., marking this PR as ready for review as I am able to test EFI firmware capsule updates on RB1. Note that currently we only support updating U-Boot without dual A/B bank support.

[lool]

Meh, I typed a long review comment after my misc other comments yesterday, but I'm not sure how I lost it, so this will be the short version instead :-)

I wish there would be:

• a mini doc / update to some doc somewhere explaining how the capsule update stuff works for the RB1 using these binaries – right now it's only in the commit message
• we need to address hardcoded ids in comments and assumptions/requirements somewhere

This is good to build for now as for us to play with capsule updates, I do think we need to write our plan on how we / others would implement capsule updates end-to-end, I believe we'll need a boot firmware "product" for that (I can think of a good person to lead that :D)

[b49020]

Thanks @lool for your comments

This is good to build for now as for us to play with capsule updates, I do think we need to write our plan on how we / others would implement capsule updates end-to-end, I believe we'll need a boot firmware "product" for that (I can think of a good person to lead that :D)

Yeah this is really the next step we have to take to see how we can create a boot firmware product. Ideally we should upload the EFI capsule updates cabinet archive to https://fwupd.org/ for firmware updates to happen automatically via the fwupd daemon.

a mini doc / update to some doc somewhere explaining how the capsule update stuff works for the RB1 using these binaries – right now it's only in the commit message

Sure, it will work through the standard fwupd and LVFS stuff. The fwupdtool usage here is just to play around with things until we have a firmware distribution strategy ready.

we need to address hardcoded ids in comments and assumptions/requirements somewhere

I hope I addressed those but I agree with you that those should be documented. I can create a google document if you like but I would rather prefer finally that documentation to go alongside the boot firmware "product".

[lool]

I hope I addressed those but I agree with you that those should be documented. I can create a google document if you like but I would rather prefer finally that documentation to go alongside the boot firmware "product".

Yup, your comments and intentions I think would address this; I guess for this pull request:

• could you replace the GUID with a call to guidgen?
• could you document assumptions either comments in the build-u-boot shell script, in README.md, or some other place public that we can patch in the future? I think it's ok to say this is a WIP implementation

[b49020]

could you replace the GUID with a call to guidgen?

Let me see if I can parse that output (the format is quite complex) from guidgen tool and give that as an input in the script. Otherwise, if you agree I can document it that the guid gets generated using this command.

could you document assumptions either comments in the build-u-boot shell script, in README.md, or some other place public that we can patch in the future? I think it's ok to say this is a WIP implementation

Sure I can add proper comments and update README too.

[lool]

could you replace the GUID with a call to guidgen?

Let me see if I can parse that output (the format is quite complex) from guidgen tool and give that as an input in the script. Otherwise, if you agree I can document it that the guid gets generated using this command.

Sure, we could document this instead of running the command (it's already a dependency though, so I thought it was elegant to use it, but fine with me either way :))

[ricardosalveti]

I hope I addressed those but I agree with you that those should be documented. I can create a google document if you like but I would rather prefer finally that documentation to go alongside the boot firmware "product".

We should probably use https://github.com/qualcomm-linux/qualcomm-linux.github.io to documentation for this (repo just created, need to setup the infra).

[b49020]

Updated PR with documentation around firmware updates, let me know if there are any further comments.

[lool]

@b49020 Merging this now, you addressed comments, and the implementation didn't change after your statement that you had manually validated this.