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.
When support for dynamically mounting disks was added for 25ba41579f
udisks2 became a harder dependency and it was less obvious to users.
Create devices but show an error in why devices aren't updatable if
it's not found.
Users can still configure ESP manually in `uefi.conf`
Fixes: #2444
The FWUPD_INSTALL_FLAG_FORCE flag has really unclear semantics, and ignoring a
file CRC, checksum or model ID should only be done when using fwupdtool actually
debugging a plugin or firmware parser.
Use the existing --force flag when we want a "gentle nudge" like reuploading
previously processed reports.
This is installed by default, but means it can be excluded from the minimal
CoreOS image. It's highly unlikely that anything running CoreOS has anything
unlocked that can be flashed using flashrom.
This drops inclusion of dmidecode, libftdi, pciutils-libs and flashrom as hard
dependencies from the package set.
This is installed by default, but means it can be excluded from the minimal
CoreOS image. It's highly unlikely that anything running CoreOS has mobile
broadband hardware attached.
This drops inclusion of libmbim, libqmi and ModemManager-glib as hard
dependencies from the package set.
This allows us to handle this in the plugin, which might mean detaching the
*proxy* device. It's also very important as a few plugins reboot the device
in ->attach() to get the new firmware version, which isn't required for a dump.
This partially reverts a58510b246 and does the
detach and attach in the few plugins where actually required.
