Alpine Ridge and Alpine Ridge LP also include flash size field so follow
Titan Ridge and validate those as well.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
This reverts commit ed7acc7819.
As pointed out by @YehezkelShB during review the Titan Ridge IDs 0x15E8
and 0x15EB are for the NHI (the host controller). Windows SDK tool uses
them to keep track of different controllers but in Linux we don't need
them and can use the already existing bridge IDs.
There is no harm to have them listed but to avoid possible confusion in
future remove them.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
/boot is a special cased directory when using ProtectSystem=full
Due to this, it's marked read only even if it's listed in ReadWritePaths.
Allow folks to use this for their ESP, but they need to create /boot/EFI
in advance of starting fwupd.
Titan Ridge devices may contain multiple controllers so we need to make
sure the supplied NVM image multi controller number matches the
controller in question. This is pretty much same than we had for Alpine
Ridge (X of N) but the difference is that this multi controller
information is found in DROM instead and the location is not fixed.
For this reason we implement a generic DROM entry parser and use it to
dynamically fill in correct location of multi controller entry based on
the controller active firmware.
In addition to that we add a check for the NVM flash size just like we
do for Titan Ridge host.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Titan Ridge has same set of bits than Alpine Ridge telling whether the
Thunderbolt controller is in native or legacy mode. Add validation for
that.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
We need to make sure the Thunderbolt controller and the NVM image agree
with the expected flash memory size.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Add 0x15E8 and 0x15EB Titan Ridge IDs that were previously missed.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Thunderbolt devices typically have a discrete PD (power delivery)
controller and firmware for that controller is part of the NVM image. To
make sure the supplied NVM image provides the necessary PD firmware we
implement a check that compares existence of both PD pointers and fails
the validation if they differ.
Since the PD pointer is part of ARC_PARAMS section we need to populate
that section offset also for hosts (following DROM section).
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
At least with Titan Ridge devices 50 * 20 ms is way too short time
reading nvm_version so most of the time the daemon fails to figure out
the version of the just connected device. To make it work better with
Titan Ridge devices increase the timeout to 50 * 200 ms.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
There are other places in the plugin where we read nvm_version and it
can return -EAGAIN as well. To make sure it works consistenly accross
the plugin factor reading nvm_version to a helper function and use instead.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Additionally, if the user specified something invalid, do not autodetect the
ESP but return with a journal error. It seems wrong to ignore what the user
explicitly set and perhaps do something dangerous.
Alternative to https://github.com/hughsie/fwupd/pull/599
Panamera is a newer MST chip with a different flash layout and
multiple MCU running and accessing SPI/EEPROM simultaneously.
The firmware update process has to be run separately for each
SPI/EEPROM region.
Signed-off-by: Ryan Chang <ryan.chang@synaptics.com>
Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
- Split up `synapticsmst_device_write_firmware` to smaller more manageable
chunks
- Use `FuDeviceLocker` to ensure that device is in a known state after
update is complete (both in success or failure scenarios)
- Retry the write process up to 10 times in case of DPCD update failures
- Wait for flash clear to settle before writing to EEPROM/SPI
Any previously failed runs or outside tools may adjust the remote
control register leaving the MST controller in a poor state.
If remote control enablement fails, try to disable and then re-enable
before aborting.
As seen by recent testing this is not working every time.
Since e6cda81f we're now building GUIDs that represent all the possibilities
for shared parts so it's not important to set dock type.
Since the Redfish service may use a self-signed certificate without
specifying the hostname, we could have the problem to verify such
certificate. A new option, CACheck, is introduced so that the user can
decide whether to ignore the CA verification or not.
Signed-off-by: Gary Lin <glin@suse.com>
This commit adds redfish.conf to configure the IP and username/password
in case those are not available in SMBIOS and the EFI variables.
Since we can configure the IP in the conf file, the environment
variable, FWUPD_REDFISH_URI, is removed.
Signed-off-by: Gary Lin <glin@suse.com>
Although SoupAuthManager can create a proper SoupAuth from the
WWW-Authenticate header, some redfish implementations didn't provide
such header, and we would get a 401 response in the end.
In DSP0266, it mentions that "HTTP BASIC authentication as defined by
RFC7235 shall be supported", so it shall be safe to use Basic Auth
by default.
Signed-off-by: Gary Lin <glin@suse.com>
DeviceClass in Oem/Hpe indicates the type of device in the HPE machine.
In case SoftwareId is absent, we can use DeviceClass instead.
Signed-off-by: Gary Lin <glin@suse.com>
Although "Updateable" is defined in SoftwareInventory schema since
redfish v1.0.0, some machines(*) didn't support the field.
"SoftwareId" is defined in SoftwareInventory schema since v1.1.0, so
it probably isn't supported by every redfish machines.
(*) Try "/redfish/v1/UpdateService/FirmwareInventory/1/" with HPE DL380
Gen 10 in https://ilorestfulapiexplorer.ext.hpe.com/
Signed-off-by: Gary Lin <glin@suse.com>
In the Members array of FirmwareInventory or SoftwareInventory, each
element of the array only contains the URI to the member. For example:
"Members":
[
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/1/"
},
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/2/"
},
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/3/"
}
]
We have to get the real member object through the given URI.
If the dock information is available then show that in the device name
and restrict the GUIDs created.
If it's not available, then just create GUIDs for all known docks
Previously if missing secure boot binaries, or invalid ESP was created the
plugin would just not load.
Now instead populate UpdateError and remove the updateble flag, but still show
the device in fwupdmgr and fwupdtool.
1) Drop the path at the end of the title (\fwupdx64.efi)
2) Linux-Firmware-Updater to Linux Firmware Updater
The behavior that required the hacky name has been fixed since shim 10
which is in all the relevant distros now.
3322257e61
In the redfish emulator, "/redfish/v1" returns "ServiceVersion".
However, in the HPE API explorer(*), it returns "RedfishVersion".
This commit checks both member and print the one that is available.
(*) https://ilorestfulapiexplorer.ext.hpe.com/
Redfish is an open industry standard specification and schema that helps enable
simple and secure management of modern scalable platform hardware.
This has only ever been tested using an emulator and not on real hardware.
Check across a list of common EFI system partition locations for a mounted
location before starting fwupd.
This also will cause the plugin to not initialize if the EFI system partition
is not mounted.
If the user is using some super-old kernel or broken system we want to return
early with an error rather than try to catch each way this can fail at runtime.
This pivots the data storage so that the group is used as the preconditon
and the key name is used as the parameter to change. This allows a more natural
data flow, where a new device needs one new group and a few few keys, rather
than multiple groups, each with one key.
This also allows us to remove the key globbing when matching the version format
which is often a source of confusion.
Whilst changing all the quirk files, change the key prefixes to be more familiar
to Windows users (e.g. Hwid -> Smbios, and FuUsbDevice -> DeviceInstanceId)
who have to use the same IDs in Windows Update.
This also allows us to pre-match the desired plugin, rather than calling the
probe() function on each plugin.
We need to remove the flag if the quirk is not present.
Fixes the cosmetic-but-scary-looking 'failed to send to device on ep 0x01: USB
error on device 2dc8:9001 : Input/output error'.
Fixes the other half of https://github.com/hughsie/fwupd/issues/565
If the daemon either de-duplicates or replaces the object passed emitted from
device-added then the object set as the alternate may not be the same instance
as the daemon version. This causes weird things to happen.
To make this less fragile, specify the *ID* of the object that should be the
alternate device, which allows the daemon to do clever things, and then assign
the object from the ID as the last step.
Although fixing no bug, this makes implementing future functionality easier.
Get the TPM v2.0 and v1.2 devices explictly rather than assuming the non-alt
device is always added first. This has the side effect of making the tests
easier to read and means we can check the dock components more carefully.
Requiring colord to be built before fwupd makes it hard to build packages.
The HID-based flashing protocol is stable and documented, so there's no need
to use an external library for this now.
Using just the default GUID is fragile and might break if the GUIDs get added
in the 'wrong' order or if the GUID list is sorted.
Fixes https://github.com/hughsie/fwupd/issues/518
Several places in the UEFI plugin operate on the default GUID rather
than iterating a list of GUIDs. This is normally fine since UEFI
GUIDs are tied to the ESRT and normally one FuDevice shouldn't
have multiple GUIDs.
The alternate GUID was added to set parents accordingly but this
caused no CAB files to be able to install.
Fixes: cc664d7d (amt: Put the AMT device as a child under the system UEFI firmware)
../plugins/amt/fu-plugin-amt.c: In function ‘mei_context_new’:
../plugins/amt/fu-plugin-amt.c:77:2: error: implicit declaration of function ‘memcpy’ [-Werror=implicit-function-declaration]
memcpy (&ctx->guid, guid, sizeof(*guid));
^~~~~~
../plugins/amt/fu-plugin-amt.c:77:2: error: incompatible implicit declaration of built-in function ‘memcpy’ [-Werror]
../plugins/amt/fu-plugin-amt.c:77:2: note: include ‘<string.h>’ or provide a declaration of ‘memcpy’
../plugins/amt/fu-plugin-amt.c:78:2: error: implicit declaration of function ‘memset’ [-Werror=implicit-function-declaration]
memset (&data, 0, sizeof(data));
^~~~~~
../plugins/amt/fu-plugin-amt.c:78:2: error: incompatible implicit declaration of built-in function ‘memset’ [-Werror]
../plugins/amt/fu-plugin-amt.c:78:2: note: include ‘<string.h>’ or provide a declaration of ‘memset’
../plugins/amt/fu-plugin-amt.c: In function ‘mei_recv_msg’:
../plugins/amt/fu-plugin-amt.c:117:9: error: implicit declaration of function ‘strerror’; did you mean ‘g_strerror’? [-Werror=implicit-function-declaration]
rc, strerror(errno));
^~~~~~~~
g_strerror
../plugins/amt/fu-plugin-amt.c:117:9: error: nested extern declaration of ‘strerror’ [-Werror=nested-externs]
../plugins/amt/fu-plugin-amt.c:116:39: error: format ‘%s’ expects argument of type ‘char *’, but argument 6 has type ‘int’ [-Werror=format=]
"read failed with status %zd %s",
~^
%d
rc, strerror(errno));
~~~~~~~~~~~~~~~
../plugins/amt/fu-plugin-amt.c: In function ‘mei_send_msg’:
../plugins/amt/fu-plugin-amt.c:142:40: error: format ‘%s’ expects argument of type ‘char *’, but argument 6 has type ‘int’ [-Werror=format=]
"write failed with status %zd %s",
~^
%d
written, strerror(errno));
~~~~~~~~~~~~~~~
../plugins/amt/fu-plugin-amt.c: In function ‘amt_verify_code_versions’:
../plugins/amt/fu-plugin-amt.c:288:14: error: implicit declaration of function ‘strlen’ [-Werror=implicit-function-declaration]
len != strlen(code_ver->versions[i].version.string))
^~~~~~
../plugins/amt/fu-plugin-amt.c:288:14: error: incompatible implicit declaration of built-in function ‘strlen’ [-Werror]
../plugins/amt/fu-plugin-amt.c:288:14: note: include ‘<string.h>’ or provide a declaration of ‘strlen’
../plugins/amt/fu-plugin-amt.c: In function ‘fu_plugin_amt_create_device’:
../plugins/amt/fu-plugin-amt.c:430:2: error: incompatible implicit declaration of built-in function ‘memcpy’ [-Werror]
memcpy (&ver, response->data, sizeof(struct amt_code_versions));
^~~~~~
../plugins/amt/fu-plugin-amt.c:430:2: note: include ‘<string.h>’ or provide a declaration of ‘memcpy’
cc1: all warnings being treated as errors
This reverts commit 6b0eb07886.
Per debian bug 896012 this is intentional behavior and a problem with
linitin. An additional commit will be added to ignore this lintian
error.
This allows plugins to set and explicit build-time version. It also uses the
same AppStream component-ID scheme rather than the home-grown 'FooVersion' key.
Also, use the new runtime and compile-time versions in the report metadata.
Due to the key change we'll also need to update some LVFS rules.
In some cases firmware can only be installed with an up to date GUsb (e.g. with
some STM-DFU hardware) or with a new version of fwupdate (e.g. any UEFI
UpdateCapsule without a capsule header).
We should be able to match against other software versions like we can the
fwupd version, e.g.
<requires>
<id compare="ge" version="0.9.2">org.freedesktop.fwupd</id>
<id compare="ge" version="11">com.redhat.fwupdate</id>
</requires>
Also, rather than checking each requirement we know about on the component,
check each requirement on the component about things we know. This ensures we
don't allow firmware to be installs that requires for instance fwupdate 22 when
the runtime version is only being added in fwupdate 12 and up.
This means the following is now an error that will fail to allow the firmware
to be installed:
<requires>
<firmware>doesnotexist</firmware>
<some_future_tag>also_unknown</some_future_tag>
</requires>
Also add a lot of self tests to test the various new failure modes.
Fixes https://github.com/hughsie/fwupd/issues/463
This is a workaround for what looks like a compiler bug introduced
in Debian and Ubuntu gcc-7.
After the compiler bug is sorted in Debian testing it should be
reverted.
There are a lot of hacks here;
* Pulling newer libappstream-glib from Fedora
* Pulling a systemd backport
* Manually installing pillow and pygobject
* PKCS7 is turned off (gnutls is too old)
GLib creates two static inline functions for paramaters that may
not be used that set off warnings in clang but not gcc.
Ignore these on clang builds everywhere that
G_DEFINE_AUTOPTR_CLEANUP_FUNC is used.
A test run should really fail if it cannot find the test data, rather
then reporting success (thus masking that it never ran). Fix the test to
find it data (probably broken with the port to meson) and make it fail
if it cannot find its data.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Rather then always assuming open() fails because of permission denied,
generate the GError code from the errno and add the related strerror to
the message. And ofcourse output the error message in debugging rather
then just ignoring it.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
If recoldplug is called in the middle of a Thunderbolt firmware update it will
cause the Thunderbolt controller to be in the wrong state and make it appear
that the controller update failed.
The type of Dell dock gets used in the device GUID, so make that
mandatory for device enumeration to succeed. Only relying on the
synapticsmst plugin to be cold plugged after the dell plugin isn't
enough to ensure this.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
When hitting a failure during enumerating make sure remote control mode
is disabled again.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
On Dell dock devices set the FU_DEVICE_METADATA_DELL_DOCK_TYPE metadata
field which gets used by the synapticsmst plugin for recognizing dell
dock types.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
A race condition is hypothesized in the following scenario:
1. User starts up the system and fwupd doesn't start automatically.
2. User manually calls fwupdmgr install blah.cab (or fwupdmgr update really) which uses dbus activation to start fwupd systemd unit.
3. This runs coldplug on thunderbolt plugin, no devices found. Thunderbolt power runs coldplug routine.
a. This sets forcepower with a timeout to turn off after 20 seconds.
b. Coldplug exits.
4. update routine starts
a. Thunderbolt plugin starts flash routine.
b. Thunderbolt power plugin turns off force power in middle of flash routine.
c. Issue described happens.
Some devices like the Nitrokey use a generic DFU bootloader that reports a
version number unrelated to the version number of the runtime. Add a flag so
that we can set the correct version when switching plugins during detach and
attach.
Previous to having the history database we could only notify about firmware that
as installed using the uefi plugin, as that had a few system-wide API calls to
say 'this update failed' or 'this was the error'.
Now we have the local history database not only can we report more details about
the UEFI update (e.g. the old version number) but we can also offer the same
functionality for all other plugins.
Although this does rework how the data for GetResults() is populated, it does
make the FuEngine object quite a lot less confused.
It also fixes a warning in the fwupd plugin for gnome-software, which was
expecting the FwupdRelease to be populated for the FwupdDevice.
4a036018 broke the callback progress by putting the wrong device type in.
23:34:11:0715 GLib-GObject invalid cast from 'SynapticsMSTDevice' to 'FuDevice'
23:34:11:0715 Fu fu_device_set_progress: assertion 'FU_IS_DEVICE (device)' failed
b6f79556 caused the device ID strings to change, which synaptics
MST plugin was relying upon.
Update to use metadata instead to communicate this information.
This does mean fixing up the version numbers. The idea is that we have a
virtual device that goes from 1.2.2->1.2.3 for an update, and 1.2.3->1.2.2 for
a downgrade.
In newer releases libusb has started returning LIBUSB_TRANSFER_ERROR (rather
than the arguably more correct LIBUSB_TRANSFER_STALL...) when the device is
removed before the control transfer has completed.
This will be useful in the future for debugging crashes with known
problematic versions of libsmbios.
Also use this information to turn off the blacklist from previously
bad known combinations of libsmbios + certain systems
The work for this landed in what will turn into efivar 33.
Later down the road when efivar 33 is in most the major distros
this can be removed and a requirement set for efivar 33.
Rename FuPending to FuHistory to better represent what the object is now doing.
Also, while we're here, switch to using SQLite prepared statements to avoid a
possible invalid read on i386 hardware.
Kernel v4.15 added support for native enumeration of Thunderbolt
topology. The enumeration mode affects both the BIOS and TBT FW
operation so they must agree on it. Platforms may support both modes,
native and "legacy" (or "BIOS-assist").
This change makes sure the new image is compatible with the current
controller mode (otherwise the BIOS and TBT FW will not be alligned on
it at least until next boot) and also adds a new GUID generation logic
for a controller in "native" mode so LVFS could contain 2 images, one for
the "legacy" mode and one for "native".
Signed-off-by: Yehezkel Bernat <yehezkel.bernat@intel.com>
The SF30/SN30 pro support 4 different modes:
* Switch mode (START + Y)
This looks like a nintendo switch pro controller
* Xinput mode (START + X)
This looks like an XBOX 360 controller
* Dinput mode (START + B)
This looks like a more generic gamepad
* macOS mode (START + A)
This looks like a Sony DS4 controller
3 modes have had a difficult time enumerating in fwupd.
Switch mode:
* failed to add USB device: unexpected device response
Xinput mode:
* failed to add USB device: USB error on device 045e:028e : Pipe error [-9]
macOS mode:
* failed to add USB device: failed to send to device on ep 0x01: USB error on device 054c:05c4 : Input/output error [-1]
The only mode I've gotten a nearly full update flow working is Dinput
so far. After updating the controller comes back in switch mode.
This means we can trivially support new devices in the future without compiling
any new code. This makes it easier to add support for new hardware for LTS
distros like RHEL.
CSR is short for Cambridge Silicon Radio, which is a the OEM that makes most
of the bluetooth audio chips in vendor hardware. The hardware vendor can enable
or disable features on the CSR microcontroller depending on licensing options.
The hardware vendor can also use a custom USB descriptor, or just set a custom
PID. In the latter case we need to set the vendor and model to reality using
quirks.
This commit allows the user to update the firmware in the AIAIAI H05 wireless
headphones.
Switching to build in -werror in 4016c839a8
was not working properly. Adjust the CI builds to use --werror instead.
Also while doing this, enable -werror in clang builds.
This makes more sense; we're updating the device, not the plugin itself.
This also means we don't need to funnel everything through callbacks like
GFileProgressCallback and we can also update the state without adding an
explicit callback to each derived device type.
That GUdev function returns a const gchar*, not an allocated pointer, so
don’t try to autofree it. This would have caused a crash (I only
observed it as a compiler warning with
-Wincompatible-pointer-types-discards-qualifiers).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This saves all the USB plugins from connecting to the context and managing the
device lifecycle and allows devices that uses FuUsbDevice to be removed
automatically.
This makes supported plugins *much* smaller indeed.
By filtering out the devices not in runtime we have two problems:
* We can't use fwupdmgr to 'fix' any devices that failed to flash and are
stuck in bootloader mode
* We can't transition from a runtime-less FuDevice to a DFU-capable FuDevice.
This allows the Nitrokey to be updated using fwupd.
The ColorHug plugin was the very first plugin for fwupd, and it's not been
ported to use all the various helpers used in other USB plugins. It shows.
This gets rid of a lot of complexity and makes the plugin more reliable.
Kernel 4.15 adds support for Thunderbolt P2P devices via
CONFIG_THUNDERBOLT_NET. When turned on and activated fwupd will
show an empty device representing the IP connection between machines.
These device types aren't useful in fwupd and should be filtered.
Suggested-by: Mika Westerberg <mika.westerberg@intel.com>
Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
Although we don't quite do the right thing, we only need to typically work out
the start offset of the firmware. This fixes 'dfu-tool dump foo.hex' for files
produced for the ATMEL ATXMEGA architechure.
Previously, the various install paths were obtained using get_option
as needed.
This patch unifies the directory selection inside the top-level meson
file as requested in https://github.com/hughsie/colord/pull/62.
This allows us to flash hardware like the Retrode and other devices using chips
like the AT90USB1287.
The test files can be re-generated using the sample code found here:
https://github.com/hughsie/fwupd-test-firmware and are designed
to be used on the AT90USBKEY2 development board.
It's actually less scary to see a SHA1 hash than it is to see a path like
/sys/devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.2. It's also way easier to
copy and paste into the various fwupdmgr command that require a device ID and
also means we can match a partial prefix much like git allows.
If we also move to a model where plugins can be changed during different stages
of the update (e.g. during detach) then the device might change connection type
and then the sysfs path not only becomes difficult to paste, but incorrect.
Session software doesn't care about the format of the device ID (it is supposed
to be an implementation detail) and so there's no API or ABI break here. A few
plugins also needed to be ported, but nothing too worrying.
This allows end-users testing a specific plugin to start fwupd with an extra
command line parameter, e.g. `--plugin-verbose=unifying` to output a lot of
debugging information to the console for that specific plugin.
This replaces a lot of ad-hoc environment variables with different naming
conventions.
Crashes will happen when UEFI capsule is turned off due to fwupdate
trying to do a SMI request that invalidates the buffer used by fwupd.
This is due to both fwupdate and fwupd using libsmbios in the same process.
Fixes: https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/1726367
This also adds an *almost* throw-away python script to import the chip-ids from
the default conf file from the avrdude project. I've imported it here in case we
have to start caring about different page sizes or application offsets.
Notably, bootloaders for this class of device export an incorrect DFU interface.
Additionally, allow setting the buffer size for the UPLOAD to a larger size
than the defined device transfer size, which allows us to return the full
packet from the larger XMEGA devices.
Ignoring the warning is not good enough when we're setting policy based on the
specific version. Use the new quirk functionality to do this easily, which
also allows us to remove one more thing in the quirk mega-bitfield.
If page_sz == 0, which is supported, then we try to take the modulus of it
which is undefined behaviour and can cause a division by zero crash.
Found using Coverity.
This allows us to remove the Jabra-specific quirk entry in the device bitfield,
and more importantly allows us to support some more Jabra devices in the future
without code changes.
This is slightly more verbose than desired as we also have to include the quirk
information when running the dfu-tool, which does not have an already set-up
FuQuirks object as it has no plugin.
umockdev 0.9.4 changed how to test for running in mock and this
causes the assumptions on mock testing at init to fail.
Move the test for this to after the environment has been set up.
Although it makes things faster to ignore the timeout, it violates the DFU
specification which could break some devices.
Lets err on the side of caution for now, even if this means slowing down an
uncommon operation.
This reverts commit 144473c1f4.
8Bitdo devices with firmware <= 4.0.0 used a few different USB VIDs, some of
which being shared with other projects. For the older firmware, compare the
vendor against a whitelist to ensure we only try to update 8Bitdo game pads.
Fixes https://github.com/hughsie/fwupd/issues/275
As type-C docks become more common MST controllers in the host are
going to become rarer. This should be a manageable whitelist
and prevent running the SMI on the majority of systems.
Some (HIDPPv1?) devices don't like being probed, and in some cases actually
stop working altogether. As we only really support the K780, just whitelist
that and another test device.
Fixes bugs like #127 and #258
This allows us to show the devices in a GUI with a nice icon. Some of the icon
mappings are not perfect and I'll be asking the GNOME designers for some
additions to the icon specification.
Custom vendor icons can also be specified, and /usr/share/fwupd/icons would be
a good place to put them. If vendor icons are used they should show a physical
device with the branding, rather than just the vendor logo.
This ensures that only firmware uploaded with this vendor ID can be flashed to
the hardware. This stops vendors on the LVFS from accidentally updating devices
from other vendors on the LVFS.
The hardware does not support the DFU specification enough for a metadata table
to be embedded, so there's no way to reliably detect the 'devo' cipher, thus
making the support useless.
This was a mistake originally for two reasons:
* The only device to use ELF as a deliverable is the altos devices
* ELF has nothing to do with the DFU specification
This moves the code to where it belongs.
It's not super useful. If this has no bad effects for a couple of releases we
can either remove it completely or move the functionality to the test plugin.
This reverts commit 257c14ebd1.
Although this is the preferable way to detect Dell systems this was
leading to executing SMI on some systems with problems.
libsmbios has some memory issues that need to be fixed first.
It's been decided that TPM mode switching won't be supported
on any other new platforms. Instead of blacklisting the outliers
whitelist the (smaller) list of platforms that do support the
feature.
This is to help break the dependence on the Dell plugin during
initalization.
NOTE: there are corner cases that this plugin will no longer
detect Dell systems now, but these are expected to be rare.
Over the months the original meaning of ALLOW_OFFLINE and ALLOW_ONLINE have be
lost, and there is now a confusing mixture of uses in the source tree. With this
commit we make it clear the UPDATABLE flag is used to specify when the device is
updatable (e.g. from the desktop live session, or from the systemd offline
updates mode, or both) and the NEEDS_REBOOT flag lets us know when the update
is actually going to be done.
For instance, a UEFI UpdateCapsule can be *scheduled* from either the desktop
or from the update mode (but the latter would be a bit weird), but does require
a reboot. Some devices might only be updatable outside the live session, for
instance a hard drive update or a GPU update -- there's just too much going on
with a live session and we want to tightly control what's running during the
firmware flash.
This also means we don't have to "retry" the update when scheduling an update
that really can be scheduled whenever, but just requires a reboot to apply.
This could be used, for instance, to set a property on ThunderBolt controllers
inside Dell computers saying that they support forcing the power level during
coldplug. It could also be used to set the dock type for the synapticsmst hub.
Adding this level of complexity allows us to avoid the creep of HAVE_DELL and
HAVE_LENOVO into seemingly unrelated plugins, and also allows us to have
multiple vendor plugins providing the same end result with two different
vendor-specific mechanisms.
Thunderbolt has a new kernel interface starting from version 4.13,
which simplifies updating the host controller and devices: the
kernel now exposes a sysfs interface for the non-volatile memory
as a device node. This can be used to write the new firmware blob.
Updates are then triggered also via a simple write to a sysfs
file (nvm_authenticate), which in turn is also used for error
reporting.
The plugin should be functionally, but a few items are missing:
- image verification
- safe mode handling
This should hopefully fix the error:
../../checkout/fwupd/plugins/amt/fu-plugin-amt.c:238:1: error: initializer element is not constant
uuid_le MEI_IAMTHIF = UUID_LE(0x12f80028, 0xb4b7, 0x4b2d, \
^
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This reverts commit 1a5c7f6fe5.
The warning is obviously complaining that the value cannot be evaluated
at compile time, rather than that it’s being assigned to a const storage
location.
Unfortunately it seems that the definition of UUID_LE is not const (or
not evaluatable as const by the compiler) on a Debian Jessie machine,
which causes compilation to fail with:
../../checkout/fwupd/plugins/amt/fu-plugin-amt.c:238:1: error: initializer element is not constant
const uuid_le MEI_IAMTHIF = UUID_LE(0x12f80028, 0xb4b7, 0x4b2d, \
^
Fix that by dropping the const. Sadness.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
When my SNES30 controller was in bootloader mode, it wouldn't update,
and when it was in controller mode, it tried and failed. Now, it prints
out the instructions on how to reset the device if it's in controller
mode, and if it's in bootloader mode, it successfully installs the
firmware update from the .DAT file.
Pre-filter the pending LuDeviceBootloaderRequest's after they are parsed so
that we know exactly how many packets need to be sent to the hardware.
As shown in https://github.com/hughsie/fwupd/issues/155, people get worried
if the progress bar finishes before 100% as they'll wonder if all the writing
completed successfully.
The kernel offers two interfaces for manipulation of EFI variables.
Make sure that at least one of these is available.
If another interface is added (and supported by efivar) then this
list will need to be appended as well.
This was raised as a potential problem in #100.
Before:
$ fwupdmgr install XPS_test.cab
Retrying as an offline update...
Scheduling… UEFI firmware update failed: -1
After:
$ fwupdmgr install XPS_test.cab
Retrying as an offline update...
Scheduling… UEFI firmware update failed: libfwup.c:733 get_paths(): could not find shim or fwup on ESP: No such file or directory
We used to do this dance to avoid reading the Option ROM on hardware by default
(some faulty hardware would crash...) but now we're doing the verify update in
the daemon there's no need to split this into two steps.
Fixes: https://github.com/hughsie/fwupd/issues/149
If we happen to poll when the device is in the *process* of closing then the
open() fails in a weird way. If we're flashing it's probably a good idea to not
be too clever anyway...
This also moves the tests into one file as gnome-desktop-testing-runner
intentionally randomizes the order and runs them in parallel where allowed.
Since tests like get-updates have to be run after the metadata injection simply
put these into one test that calls a simple script.
Although we supported other hashes than SHA1 (which is now moderately unsafe)
we had to switch the metadata provider and daemon on some kind of flag day to
using SHA256. Since that's somewhat impractical, just allow multiple checksums
to be set on objects and just try to match whatever is given in preference
order.
This also means we can easily transition to other hash types in the future.
The removed API was never present in a tarball release, so not an API break.
Although the device does send a response, in some cases the Linux USB stack
processes the disconnect before the reply is processed.
Resolves: https://github.com/hughsie/fwupd/issues/122
Automake and autoconf are impossible to fully understand and Meson now provides
everything we need for a much smaller, faster, and more understandable build.
See http://mesonbuild.com/ for more information.
As found in https://github.com/dell/libsmbios/pull/13
there are some errors with libsmbios error paths.
These need to be fixed in libsmbios, but at least avoid
running this code on those systems (and crashing fwupd).
My compiler doesn't understand -Wno-discard-qualifiers so drop it and
fix the warnings instead. I think it is better to explicitly fix them
anyways instead of just to ignore the discarded const qualifier in
general.
I think the option should be avoided in hand-written code. The warning
is there for a reason: To protect you from possibly overwriting data you
expect to not be modified when passing pointers around.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41215
This significantly speeds up the test suite.
They can't really be easily represented anyways in the test suite
since the devnode would have to change so much between steps.
Although the same payload is used for all 3 MST hubs in TB16 or WD15
it's possible this may change one day. Create separate GUID's for
all 3 different combinations by encoding the chip ID into the GUID
string.
Although WD15 and TB16 share a same payload today, this may not
be the case some day in the future. Use the fu-dell-common method
to determine the dock in use to build the GUID.
Tracking a single smi object in the plugindata is more similar
to how other plugins operate and also allows moving FuPluginData
out of fu-dell-common, making fu-dell-tool less hacky and letting
other plugins use fu-dell-common as needed.
* thunderbolt: Add special handling for safe mode on Dell systems
Dell systems are known to have the Model ID the same as the SystemID
that can be recovered from libsmbios. If the thunderbolt controller
is in safe mode, identify with this ID to allow the controller to be
flashed with a good FW.
* Minor changes in Thunderbolt README file
* Remove PCI-oriented GUID
* Handle Thunderbolt controller in safe-mode
* Get progress status updates for Thunderbolt
* Fix for Thunderbolt FW version display
* Style changes from pull request review
There was a lot of confusion about when remote control was turned
on or off leading to dsyfunctional cascade support.
This has been confirmed to work for querying and flashing both
VMM3320s in a Rugged Latitude 5414 + dock.
The synapticsmst-common.c file had some global state so that cascade devices
could use the device fd. This made the control flow error prone, and it meant
that the fd could be leaked trivially on any error path.
Moving the fd ownership to the device is the logical place for the control, and
means we can create "connections" to access the main device and the cascade
devices.
This fixes the warnings detected by Coverity.
It now supports enabling things for other plugins too, so rather
mark any devices created by Dell as only readable, not flashable
when UEFI capsule is off.
The linker does not know which public symbol to call if a plugin calls it's own
symbol. Without this change one plugin could call into another plugin with the
wrong GsPluginData set.
Remove the dummy devices created for NVM and MST, these will
be created by other plugins. Other plugins will however
be using the Dell methods to enable these devices.
This functionality is required so that AppStream metadata can check the fwupd
version, the firmware version, bootloader version or a combination of all three.
failed to open plugin
/usr/lib/x86_64-linux-gnu/fwupd-plugins-2/libfu_plugin_dfu.so:
failed to open plugin:
/usr/lib/x86_64-linux-gnu/fwupd-plugins-2/libfu_plugin_dfu.so:
undefined symbol: dfu_device_upload
failed to open plugin /usr/lib/x86_64-linux-gnu/fwupd-plugins-2/libfu_plugin_udev.so:
failed to open plugin: /usr/lib/x86_64-linux-gnu/fwupd-plugins-2/libfu_plugin_udev.so:
undefined symbol: g_udev_device_get_property
This is a large commit that removes all the providers and turns them into
plugins. I think having both providers _and_ plugins was super confusing.
Plugins are loaded at runtime so you could in theory develop a new plugin
without putting it in the fwupd source tree, although there are no installed
headers or PC files as I'm not sure it's a good idea at this stage.
This commit moves all the per-provider docs, tests, notes, debug dumps and test
data to plugin-specific directories -- these also allows the plugin author to
"own" more of the source tree so we don't enforce fu- prefixes and the style
guide everywhere.
This allows us to run the same action on all the plugins in the future, so we
could have a prepare(FuPlugin, FuDevice) and cleanup(FuPlugin, FuDevice) run
on *all* plugins, so doing an update using one plugin would allow us to work
around hardware quirks in other plugins.
If I've broken your out-of-tree provider it's trivial to port to the new API
with sed and a fixed up build file. If you need help please let me know.
