11468 2017-05-05 07:28:15 +0000 integrate firmware update into system update 2017-11-07 16:45:36 +0000 1 1 6 Yocto Project Subprojects IoT Reference OS Kit intel-iot-refkit-software-update 2.4 x86 Multiple RESOLVED FIXED Medium enhancement Future 1 patrick.ohly patrick.ohly matti-pekka.sivosuo mikko.ylinen --- --- No (bug/feature does not impact docs) oldest_to_newest 73073 0 patrick.ohly 2017-05-05 07:28:15 +0000 The implementation will be based on UEFI-based capsule update capabilities in the firmware. There are two projects that we should consider for integration: https://github.com/rhinstaller/fwupdate http://fwupd.org.s3-website-eu-west-1.amazonaws.com/ This issue is about: - providing recipes for either fwupdate or fwupd - support for firmware updates as part of the system update (bug #11467), i.e. getting new firmware onto a device and triggering its installation, including a reboot Testing whether the actual firmware gets installed by fwupdate or fwupd is out of scope of this issue, because it is hardware-specific. 75109 1 patrick.ohly 2017-07-18 13:59:51 +0000 swupd uses swupdate for the UEFI capsule support. So both will be integrated. Current status is that I have recipe for both plus several new dependencies. I found one problem in OE-core (bug #11792) which I could work around, but a fix in OE-core would be better. Biggest gaps right now are: - review of the new upstream components (requested, unknown ETA) - removal of the swupd -> polkit dependency - we really don't want to drag that into a build - delivery of firmware updates via system update (at the moment, only direct downloads via http work, and that depends on gpg for verification, which we don't want in an image either) - installation and updates of swupdate in the EFI system partition 75275 2 patrick.ohly 2017-07-25 10:06:28 +0000 I've patched polkit so that we just build the client library and implement the policy checking with groupcheck. Regarding UEFI capsule support: I suggest that we defer this until we actually have hardware that supports it. A quick check for support is to look for /sys/firmware/efi/esrt/entries/ - it must exist. Regarding integration into OSTree (the system update mechanism currently used in refkit): again, lack of a suitable test makes this hard to do now. My plan for integration is this: - disable the default Linux Vendor Firmware Service remote - patch fwupd so that it supports remotes with a file:// url and without GPG signing - enable such a remote which points to a directory that is part of the OS - populate that directory as part of update building with a firmware.xml.gz and actual firmware files, as configured by the device manufacturer for his hardware - in an OSTree post-update hook, trigger fwupd such that it gets these files and applies them This way, we don't need to install gnupg, which is otherwise required to validate the normal LVFS files. Regarding patching, a quick check of the source points to a few places that needed patching: - fwupd_client_update_metadata_with_id - signature file must be optional - fu_util_download_file - must support file:// urls or calls to it for file:// urls must be avoided (whatever is easier) - UpdateMetadataWithId - signature file must be optional - fu_engine_update_metadata - skip signature check Such a patch might be upstreamable, if we explain the use case (updating small devices which do not have access to the LVFS web server and/or can't deal with the full XML file hosted there). 75292 3 patrick.ohly 2017-07-25 15:25:08 +0000 (In reply to comment #2) > I've patched polkit so that we just build the client library and implement > the policy checking with groupcheck. See https://github.com/pohly/intel-iot-refkit/commits/firmware-update This also depends on a patch I just sent to OE-core: "[PATCH] gettext.bbclass: also search for files in target sysroot". I sent patches for appstream-glib and fwupd, so if we wait a bit, we might be able to get rid of those patches in my branch. 75316 4 patrick.ohly 2017-07-26 13:34:41 +0000 Upstream discussion around fwupd integration into system update is now here: https://github.com/hughsie/fwupd/issues/162 75334 5 patrick.ohly 2017-07-27 12:07:51 +0000 (In reply to comment #4) > Upstream discussion around fwupd integration into system update is now here: > https://github.com/hughsie/fwupd/issues/162 And upstream has developed a solution, see https://github.com/hughsie/fwupd/pull/163#issuecomment-318340508 Regarding testing, upstream is using Logitech unifying dongles. This looks like something that we should be able to replicate. However, each dongle can only be used for a while before the EEPROM wears out. So we should integrate this into our master build testing, but not PRs. See https://github.com/hughsie/appstream-glib/pull/182#issuecomment-318042615 76904 6 patrick.ohly 2017-09-15 19:18:56 +0000 I was able to start updating a Logitech Unifying Receive with firmware bundled into the image where it could be delivered via a system update. See https://bugzilla.yoctoproject.org/show_bug.cgi?id=11468 Minimal documentation is in the fwupd recipe README. This is only a partial solution. Missing: - fwupd is completely untested - automated QA tests - automatically starting fwupd update after a system update 78028 7 patrick.ohly 2017-11-07 15:26:06 +0000 https://github.com/intel/intel-iot-refkit/pull/311 was merged into refkit. Automated testing is missing, but as it was excluded from the scope of the issue anyway, I closing this one here as "resolved".