Loosen the requirement of the user ID to match root for the following
actions:
* Install release
* Activate firmware
For install release action, reject CAB files not signed by LVFS
The GLib g_byte_array_set_size() function does not zero the contents if the
array size is larger, which leads to unpredictable output when using valgrind.
```
$ sudo mv /usr/lib/x86_64-linux-gnu/libtss2-esys.so.0.0.0 /usr/lib/x86_64-linux-gnu/libtss2-esys.so.0.0.0.renamed
$ sudo fwupdtool get-devices --plugins=uefi
14:15:48:0735 FuEngine cannot load: failed to open plugin /usr/local/lib/x86_64-linux-gnu/fwupd-plugins-3/libfu_plugin_uefi.so: libtss2-esys.so.0: cannot open shared object file: No such file or directory
Loading… [- ]14:15:48:0753 FuEngine failed to update history database: device ID b6c08fb9e5384d9d101853cc1ca20cf0ce2df2e2 was not found
Loading… [***************************************]
WARNING: Plugin depdendencies missing
No detected devices
```
Rather than using a recursive GMainLoop, just run a single iteration of the
mainloop every 1ms while we're waiting.
This simplifies the device lifecycle dramatically as we don't have to worry
about reentrant removals. It's also a lot simpler to debug as we know the only
way to return is the timeout elapsing or FWUPD_DEVICE_FLAG_WAIT_FOR_REPLUG being
unset.
If multiple devices got removed and we're waiting for one to re-appear, also
wait for all devices to come back before returning to the main loop.
In the worst case, this causes the device list to wait the full removal_delay
for the device rather than returning when the first device matches. This allows
us to simplify the hub update when we reboot the entire device and various
devices from different plugins come back in an unpredictable order.
Fixes the other half of https://github.com/fwupd/fwupd/issues/2376
To do this without rebooting the device implement VliUsbhubPdDevice->reload()
like the other FuVliUsbhubDevice child devices.
Fixes half of https://github.com/fwupd/fwupd/issues/2376
This fixes the error: 'Update Error: device version not updated on success,
0x00000002 != 0x0002' -- it seems a bit crazy to have to specify 32 bits of
zero digits in the firmware.metainfo.xml
For instance, we can tell the user that UEFI UpdateCapsule is disabled in the
system firmware, or that efivarfs is not mounted. This is much better than
creating "dummy" devices which are really just hacks around the problem because
no better API existed. THe dummy devices cause as many problems as they solve.
Plugins have to set FWUPD_PLUGIN_FLAG_USER_WARNING if a warning should be shown
to the user, and only one warning will be shown of each failure type.
It is expected that GUI clients like gnome-software and gnome-firmware would use
this API to notify the user the localized message for why firmware updates are
not being shown.
Fixes https://github.com/fwupd/fwupd/issues/2456
Add quirks for PID 5048 and 5049, which are cros-ec devices
that update via USB endpoint. Notable about these two are
they support rw_sig, for RW region signature verification.
Our update flow prior to this was:
1. On detach, reboot to RO.
2. From Old RO, Update RW.
3. Reboot to New RW
4. From New RW, Update RO.
5. Reboot to finish
This flow has a flaw, which is that the Old RO may be buggy (especially
during development, before it's actually locked down and actually Read-Only).
This change will do the following instead:
1. On detach, do not reboot to RO if RO is writeable, and we are in RW
2. From old RW, Update RO
3. Reboot to new RO
4. From New RO, update RW
5. Reboot to finish.
This has a speed advantage as well, as we save one reboot cycle (2 vs 3).
As a result of the previous change, where we send an immediate reset to
devices in order to transition back to rw, we will end up reenumerating
as RO briefly, although the destination we wanted to get to was RW.
In that case, basically skip the write firmware step, set another write
required and allow the RO firmware to complete rw_sig and jump to the rw
partition.
Previously, we sent a 'stay-in-ro' subcommand when we are in
fu_cros_ec_usb_device_reset_to_ro, which is called from the detach phase,
in other words, we are currently sitting in RW.
This is incorrect, since stay-in-ro only interrupts an RO's
rw_sig process if it is in progress.
Instead, 'stay-in-ro' must be issued when the device reenumerates in RO,
immediately before the writing sequence starts. On devices that implement
rw_sig, they will briefly enumerate as RO before self-issuing a jump to RW
on the signature check being valid. In order to stay in RO to perform a RW
partition update, we must interrupt it as soon as we see the RO version
enumerate.
- Use pci function 0 instead of 1 when flashing firmware.
In certain situations, the BCM5719 NVM controller can lockup if
a function other than 0 is used to read from NVM word-by-word like
the kernel driver does.
- Fix APE_MODE offset in BAR[2] to enable proper resetting of the APE.
- Remove unnededed NVRam lock when resetting the APE.
Signed-off-by: Evan Lojewski <github@meklort.com>
1. Check FW in bootloader mode, need send reset command to firmware.
2. IAP Type register parameter is defind as how many bytes/page to be written.
3. Write IAP Type function in detach function.
4. Remove IAP Type function in setup function.
5. Modify page format for i2c-device
6. Modify firmware bin file size.
7. Modify firmware update flow when the firmware in bootloader mode.
8. Add another instance ID which corresponds to the IC type & module ID
* `ELANTP\ICTYPE_09&MOD_1234`
9. Add Lenovo ThinkPad X1 nano gen1 to elantp.quick
10. Add recovry device - lenovo thinkpad x1 nanao gen 1
11. Add elan touchpad device - vid:04f3 pid:314f
12. Set the firmware version when the firmware is incorrect.
The clients don't need to know this, and exporting them means we paint-ourselves
into a corner if we want to change the 'namespace' or how HSI actually works.
Setting the default to number unconditionally causes problems when the device
is created using _register_proxy_device().
Based on a patch by Mario Limonciello <mario.limonciello@dell.com>, many thanks.
