Although hotpluggging PCIe cards isn't common, it's how I'm testing this in the
device test enclosure. Add a tiny delay to wait for the kernel to populate the
net class on hotplug.
Unconditionally delete FWUPDATE_VERBOSE and FWUPDATE_DEBUG_LOG when deploying
the update using fwupdtool or fwupd and leave it to fwupdate.
If you want to debug the efi binary you then have to use fwupdate and squirt
the .cap file rather than using all the other layers.
Upon restarting the upstream VLI USB hub the cxaudio device re-enumerated okay
but would not service HID requests for 100ms, returning 'endpoint stalled'.
To make this more reliable retry the SetRequest up to 10 times after a short
delay to make enumeration reliable.
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.
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
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.
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 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.
With how well fwupd UEFI updates work these days >99% of people
don't need to see messages about the capsule update running.
Those who have problems, this isn't going to help them.
