efivar experiment #65
Conversation
lool
force-pushed
the
efivar-experiment
branch
3 times, most recently
from
5daa6a6 to
ae1eec5
Compare
|
@b49020 Specially for you :-) Please post here if it works! |
This is to be able to read/write EFI vars from a file used by U-Boot in the ESP.
|
@basak-qcom what do you think of these patches? |
| +efivar (38-3.1~invalid1) trixie-noship; urgency=medium | ||
| + | ||
| + * Add test patches from https://github.com/rhboot/efivar/pull/267 | ||
| + - 0001-efivar-Add-missing-to-usage-help-options.patch |
There was a problem hiding this comment.
As a derivative (Ubuntu) maintainer we're usually reluctant to take such trivial patches - it provides little gain to the user, and such things get fixed eventually as soon as a fixed upstream release rolls through. Given our overall goals, it is perhaps appropriate to set a policy about what delta is acceptable here: no delta over upstream without either: 1) the reason being obvious; or 2) a justification of why it is necessary to have this; with the default policy deliberately being: no extra delta unless necessary, thank you.
There was a problem hiding this comment.
That's true we should be able to drop this trivial patch
| +Acked-by: Ilias Apalodimas [email protected] | ||
| +Tested-by: Ilias Apalodimas [email protected] | ||
| +Signed-off-by: Javier Tia <[email protected]> | ||
| +--- |
There was a problem hiding this comment.
I would like dep3 headers around here somewhere please, to help us track the upstream status. I did find rhboot/efivar#267, which I think corresponds. We should definitely link to this somehow.
There was a problem hiding this comment.
Probably just adding link to efivar PR in this patch will be helpful
|
@b49020 I don't know if you're subscribed to this pull request, so tagging you to check out @basak-qcom's comments :-) |
I am subscribed to this PR but being currently swamped into Imola bringup prep for boot firmware. I will try to give this PR a try. BTW, thanks for the reminder. |
|
Thanks! I see no issue with this landing then, with 1) trivial/unnecessary patch dropped; and 2) reference made to upstream PR. The final thing would be tests: are any appropriate and possible? If not, then I guess it's fine anyway - we have to be pragmatic. |
|
Thanks for your review @basak-qcom
We will be enabling automatic EFI capsule updates via LVFS that will use this feature which I will be testing shortly. You can find corresponding documentation here: https://github.com/qualcomm-linux/qcom-deb-images?tab=readme-ov-file#firmware-updates. Currently we are in process to setup an LVFS account for Qualcomm which will enable OTA firmware updates atleast for U-Boot as of now. |
|
rhboot/efivar#267 was abandoned in favor for implementing a new, separate, cleaner backend; see rhboot/efivar#267 (comment) |
rhboot/efivar#282 was just merged. |
Thanks for the update @ricardosalveti, @lool can we rather switch to the tip of efivar in this PR and rather drop all other patches from this PR? |
|
@b49020 did you give it a try with a local build, does it carry the changes we need? |
|
@lool, yeah you are right, let me give it a try locally on RB1 first. |
Draft as this depends on #64 and is not merged upstream anyway