I'm not sure why we can't just use SIO_LDNxx_IDX_CHIPID1, but lets do the same
as the vendor tool in case there is a good reason that I don't know about.
Some system firmware helpfully 'deduplicate' the boot loader entries based on
the filepath, without taking into account either the label or optional data.
This means we have to use a custom copy of shim for firmware updates.
This was caught by LGTM.
This pointer might have type struct <unnamed> (size 28), but the
pointer arithmetic here is done with type UX_CAPSULE_HEADER * (size 16).
This feature is turned on with the new fwupdtool option `--enable-json-state`
The intended use case is for ChromeOS to be able to save information about
devices on the system when `fwupdtool update` was run to display in the UX at
a later time.
If a device reports that qmi-pdc is supported (e.g. DW5821e that
supports both fastboot and qmi-pdc), we'll end up first running the
fastboot installation before doing the qmi-pdc installation procedure.
These changes also make sure that the MM device inhibition is kept for
as long as the whole process is ongoing. Only after the last method is
run, the inhibition will be removed.
In order to handle devices being exposed in the system while the MM
inhibition is in place, e.g. to be able to run qmi-pdc after fastboot,
a simple udev based watcher is included, which will take care of
creating the FuMmDevice that is not associated to any modem currently
exposed by MM, but that shares all the details of the original device.
This new logic assumes that the devices don't change their USB layout
during a firmware upgrade, which is not a very good assumption, but it
works for the case at hand. If this is not the case, we may need to
end up doing some custom AT port probing instead of relying on the
original one reported by MM being still valid (note that we don't rely
on the device name, as that may change if some other device is plugged
in the system while we're doing the update, we rely on the USB
interface number).
This will allow us to switch to the new firmware version during shutdown when
the filesystems have been remounted readonly.
Activating manually means we don't have to get the user to shutdown and then
do a fresh power-on, rather than the more usual restart.
This is intended for devices that it is not safe to immediately activate
the firmware. It may be called at a more convenient time instead.
Both fwupdmgr and fwupdtool support the feature.
- if called at runtime with fwupdmgr it uses the daemon
- during shutdown fwupdtool uses the pending.db to perform this feature.
In some situations SELinux prevents fwupd from executing tpm2_pcrlist, but the
failure mode is that the process just hangs and never completes. This causes
systemd to time out the fwupd daemon startup and then errors to be shown in
GNOME Software.
To prevent this happening, add an optional timeout argument to
fu_common_spawn_sync() and cancel the subprocess if it takes longer than this
to complete.
See https://bugzilla.redhat.com/show_bug.cgi?id=1665701 for details.
The order of events when casting causes an access to unintended memory.
```
0x00007ffff7bc19df in fwupd_guid_to_string (guid=0x8000000090d0, flags=FWUPD_GUID_FLAG_MIXED_ENDIAN) at ../libfwupd/fwupd-common.c:550
550 memcpy (&gnat, guid, sizeof(gnat));
(gdb) bt
#0 0x00007ffff7bc19df in fwupd_guid_to_string (guid=0x8000000090d0, flags=FWUPD_GUID_FLAG_MIXED_ENDIAN) at ../libfwupd/fwupd-common.c:550
#1 0x00007fffdbddd195 in fu_nvme_device_get_guid_safe (buf=0x7fffffffce70 "\\\034\\\034FI83Q060610103M66 BC501 NVMe SK hynix 128GB", ' ' <repeats 15 times>, "80001C0T\004", <incomplete sequence \344\254>, addr_start=3110) at ../plugins/nvme/fu-nvme-device.c:83
#2 0x00007fffdbddd60c in fu_nvme_device_parse_cns_maybe_dell (self=0x5555558cc8a0, buf=0x7fffffffce70 "\\\034\\\034FI83Q060610103M66 BC501 NVMe SK hynix 128GB", ' ' <repeats 15 times>, "80001C0T\004", <incomplete sequence \344\254>) at ../plugins/nvme/fu-nvme-device.c:201
#3 0x00007fffdbddda64 in fu_nvme_device_parse_cns (self=0x5555558cc8a0, buf=0x7fffffffce70 "\\\034\\\034FI83Q060610103M66 BC501 NVMe SK hynix 128GB", ' ' <repeats 15 times>, "80001C0T\004", <incomplete sequence \344\254>, sz=4096, error=0x7fffffffe008) at ../plugins/nvme/fu-nvme-device.c:295
#4 0x00007fffdbddde68 in fu_nvme_device_setup (device=0x5555558cc8a0, error=0x7fffffffe008) at ../plugins/nvme/fu-nvme-device.c:376
#5 0x0000555555587850 in fu_device_setup (self=0x5555558cc8a0, error=0x7fffffffe008) at ../src/fu-device.c:2076
#6 0x0000555555587412 in fu_device_open (self=0x5555558cc8a0, error=0x7fffffffe008) at ../src/fu-device.c:1920
#7 0x000055555558aa88 in fu_device_locker_new_full (device=0x5555558cc8a0, open_func=0x5555555872cb <fu_device_open>, close_func=0x555555587424 <fu_device_close>, error=0x7fffffffe008)
at ../src/fu-device-locker.c:154
#8 0x000055555558a925 in fu_device_locker_new (device=0x5555558cc8a0, error=0x7fffffffe008) at ../src/fu-device-locker.c:104
#9 0x00007fffdbddc4cd in fu_plugin_udev_device_added (plugin=0x5555558a6420, device=0x5555558c6300, error=0x7fffffffe008) at ../plugins/nvme/fu-plugin-nvme.c:24
#10 0x0000555555592cbf in fu_plugin_runner_udev_device_added (self=0x5555558a6420, device=0x5555558c6300, error=0x7fffffffe070) at ../src/fu-plugin.c:1281
#11 0x000055555557f0a8 in fu_engine_udev_device_add (self=0x5555557f9840, udev_device=0x5555558e5900) at ../src/fu-engine.c:3491
#12 0x000055555557f480 in fu_engine_enumerate_udev (self=0x5555557f9840) at ../src/fu-engine.c:3555
#13 0x0000555555580fc6 in fu_engine_load (self=0x5555557f9840, error=0x7fffffffe2c8) at ../src/fu-engine.c:4117
#14 0x0000555555566567 in fu_util_start_engine (priv=0x5555557eeb20, error=0x7fffffffe2c8) at ../src/fu-tool.c:138
#15 0x00005555555674e2 in fu_util_get_devices (priv=0x5555557eeb20, values=0x7fffffffe5d8, error=0x7fffffffe2c8) at ../src/fu-tool.c:490
#16 0x0000555555566aff in fu_util_run (priv=0x5555557eeb20, command=0x7fffffffe81a "get-devices", values=0x7fffffffe5d8, error=0x7fffffffe2c8) at ../src/fu-tool.c:242
#17 0x000055555556a514 in main (argc=2, argv=0x7fffffffe5c8) at ../src/fu-tool.c:1445
```
EC23 is the last version that will be supported on board 4 SKUs with
base PD firmware versions 18+.
* If on EC23 already, don't mark the device as updatable anymore.
* Flashing EC24 or later when currently on EC 22 or less will potentially
cause bricked docks that can't enumerate, so prevent this scenario
during update path.
The unifying version numbers are of the form 'RQR24.00_B0000' which means we
have to force the plugin to 'plain' version format to avoid stripping out the
non-semver chars.
Fixes https://github.com/hughsie/fwupd/issues/1018
The udev plugin is somewhat special as it uses a non-subclassed FuDevice that
never gets 'opened'.
This means that we never automatically call fu_device_setup() and thus the
instance IDs are not converted into GUIDs before the device is added.
The checksum is now stored as the very last flash descriptor, so we need to pad
the SREC data to include the 'missing' data range. As we're doing that, we
should optimize like the Wacom updater does and skip writing descriptors that
are unused.
This also allows us to write mixed-endian structures and adds tests. As part of
this commit we've also changed the API of something that's not yet been in any
tarball release, so no pitchforks please.
This allows hardware from OEMs to *not* match generic firmware supplied by the
device manufacturer. The idea being, that the OEM will supply firmware that
will actually work on the device.
Based on a patch from Mario Limonciello, many thanks.
Similar to NVME, ATA drives distributed by Dell have special values
that should be used to designate fwupd GUIDs and only run correct
firmware.
When detecting Dell GUIDs remove the standard fwupd GUIDs. "Generic"
firmware targeted to those GUIDs will fail to install.
During download and activation we have to reset the drive to apply the new
firmware. If the kernel gets an unexpected ATA reset then it might panic.
Default to activating the command on the next drive power-up to be safe.
Many thanks to the Dell storage team for the advice.
A device that has gone through a fastboot update may need more than
the previous default of 10s to come back up. Just use a much longer
value to make sure it's detected properly.
Signed-off-by: Richard Hughes <richard@hughsie.com>
Splitting the file into lines does increase memory usage, but allows us to use
a much simpler parser design. This is just like we fixed IHEX a few weeks ago.
Some hardware from Lenovo deduplicates UEFI Boot entries, and uses the old
string 'Linux-Firmware-Updater' to avoid removing the firmware update entry.
Although this is forbidden in the UEFI specification we shouldn't break
firmware updates from old firmware versions.
Provide a quirk for this, and automatically whitelist anything with the LENOVO
SMBIOS Manufacturer.
This behavior will prevent the dock from performing most resets until
it has been unplugged from a host system.
This significantly speeds up the perceived update duaration and prevents
data loss during update.
It's not confirmed whether EC23 or later EC will enable it.
* So only enable by a custom flag until this is confirmed.
* Custom flag will be dropped when included into stable EC release.
This functionality also relies upon the CAB file providing a message warning
user that the dock might not be usable after unplugging for up to 1 minute.
Currently used structures were based on early libnitrokey definitions
(which were broken for some time). Corrected their sizes and elements,
and added tests.
Fixes#960
Signed-off-by: Richard Hughes <richard@hughsie.com>
Some aspects of the method for querying dock firmware do work in 'dell' plugin
but that is not useful for fwupd because it's incomplete.
Due to this the following error shows up in fwupd journal if run on a Dell system
when the new Dell dock is plugged in:
failed to add USB device 0bda:8153: failed to add device using on dell: invalid dock component request Query 3 0 2 4 0
Detect this scenario, and prevent showing errors in logs.
Unfortunately the previous fix (6131f5d) introduced this bug.
The code previously was actually looking for the non-zero case
which was correct, but non-obvious since `efi_guid_cmp` works like
`g_strcmp0` where a match returns zero.
So rather than revert 6131f5d make this completly explicit.
Affected drives should have a prominent statement in the update description,
possibly even the first line so it shows up by default in the updates panel.
Microsoft description about the Status is:
The Status field of the BGRT describes whether the image is currently
displayed on the screen. This is not applicable to the firmware update
display capsule.
Many thanks to Steven Chang for identifying this issue.
Fixes: https://github.com/hughsie/fwupd/issues/935
Do not unset the quirks when closing the device, the _NO_DFU_RUNTIME quirk is
needed when re-opening the device during detach.
Fixes https://github.com/hughsie/fwupd/issues/927
On any devices that normally would require checking for AC also
check that at least one battery on the system has at least 30% to
perform an update.
Fixes: #925
Some SKUs of board 4 and later have silicon that will not work with anything
but EC19 or later. So once flashed up to EC19 prohibit downgrades below that
to keep from bricking devices.
This is probably fall out from a previous code re-shuffling.
The EC version is already set elsewhere, and in many cases `self->ec_version`
is `NULL` at this time.
Board 4 was manufactured with package version 89.16.01.00 and this
will prevent properly upgrading between releases. Reset this version
to 00.00.00.00 if detected on this board.
We can't actually access the UEFI ROM from userspace, but the PCR0 is a hash
built from the ROM itself. We could use this value to ensure the firmware has
been written correctly, and that the PCR0 matches the expected value specified
in the metadata.
Future metadata from the LVFS will set the protocol the firmware is expected to
use. As vendors love to re-use common terms like DFU for incompatible protocols,
namespace them with the controlling company ID with an approximate reverse DNS
namespace.
This also allows more than one plugin to define support for the same protocol,
for instance rts54hid+rts54hub and synapticsmst+dell-dock.
This solves issues with implementations that require 4k alignment
of pages in BIOS which is seen on certain architectures.
The UEFI spec prescribes that the "minimum" size is the size of
the EFI header but that this may be increased up to larger sizes
due to extended header entries.
This mirrors the update process over DP aux to run the ESM update
first.
The thought process is as follows:
The "version" displayed doesn't show ESM version, only standard
bank version.
So if the update fails for the ESM then because the update of the
standard happening first it would never be flashed.
`g_ascii_strtoull` returns 0 and sets `errno` to `-EINVAL` only when
the base is invalid. It's hardcoded to `16` so this is impossible.
Reading `-EINVAL` from `errno` is incorrect in these circumstances.
Fixes: https://github.com/hughsie/fwupd/issues/879
This makes startup quicker as we no longer have to probe every USB device, and
is now possible with the new GUIDs we added. Devices not using the
specification-provided values can (and already are) worked around with quirks.
Otherwise this would cause fwupd to sit in an endless loop when providing a bad
image.
This additional enum is only available in EC16, but since it doesn't break existing
API on older EC images, don't bump minimum requirement to EC16 yet.
This metadata key is now unnecessary, as firmwares are expected to set the
version format in the metadata.
If the metadata is missing, the LVFS allows a per-vendor default for non-semver
release versions which is now unconditionally set in metadata.
Plugins are allowed to 'opt-out' of this behaviour using _RULE_INHIBITS_IDLE.
This should be used where waking up the hardware to coldplug is expensive,
either from a power consumption point of view, or if other artifacts are going
to be seem -- for instance if the screen flickers when probing display devices.
This functionality is also inhibited when the actual upgrade is happening,
for obvious reasons.
Admins can turn off this auto-sleep behaviour by editing the daemon.conf file.
Fixes https://github.com/hughsie/fwupd/issues/417
We load the Thunderbolt controller firmware to see if the controller is in
native mode, as this changes the GUID. If the controller is asleep the firmware
is not cached by the kernel and it can take more than 4 seconds to read out
504kB of firmware.
We only need the first two 64-byte chunks, so only read what is required.
This speeds up fwupd starting substantially, and also means we don't have to
allocate a giant chunk of heap memory just to inspect one byte.
Fixes: https://github.com/hughsie/fwupd/issues/848
The ids clash with the Xbox controller ids. This makes the Xbox controller unusable since fwupd unloads the device just after connecting it and fails to update it not being a 8bitdo device.
As seen here: https://github.com/paroj/xpad/issues/114
Since dell_dock is the priority plugin for MST flashing the VMM5331
no need to do delayed callbacks anymore.
When the dell_dock plugin bumps to EC 15 being the minimum requirement
more code can also be dropped.
1. Since board ID in synapticsmst.quirk is different based upon how
the board ID is read, don't whitelist it in `write_firmware`
2. Allow using `--force` with `fwupdmgr` or `fwupdtool` to override
board ID check.
3. Allow using custom flag `ignore-board-id` to ignore board IDs.
This will be the default for EVB boards and can be used in the event
of a factory mistake as well.
4. Move the EVB board IDs into their own synapticsmst_evb.quirk.
This file will not be installed by default (So EVB boards are only
functional when manually installed).
Although this is (currently) slower to flash with, bad behavior
and corner case scenarios such as these don't occur:
* Flickering during enumeration
* Monitor plugged in during enumeration but not during flash
* Heavy DP traffic slowing down update significantly
* Sandboxes without access to `/dev/drm_dp_auxY` unable to flash
* Exercising existing graphics driver bugs leading to system freezes.
Additionally this removes a lot of code in dell_dock that was put
in place specifically to be able to support waking up the MST hub
to try to use DP aux for flashing.
Now DP aux will only be used to flash when fwupd is compiled
without `dell_dock`.
It was identified that at least one other device on this shared
I2C bus can't operate at the speed. This means that it may
inadvertently respond to commands intended for another device.
Ensure the quirk object is set, and then add the GUIDs first so that the
version format can be set from a quirk file.
Additionally, only overwrite the fallback name if the name has not already been
set manually from a quirk.
The libxmlb library is much faster to query, and does not require the daemon
to parse the XML metadata at startup. It's a zero-copy mmap design that is more
modern and less clunky.
RSS has reduced from 3Mb (peak 3.61Mb) to 1Mb (peak 1.07Mb) and the startup
time has gone from 280ms to 250ms.
These are certainly bugs with one of the components, but if the situation
happens in the field the plugin needs to finish initialization to allow
upgrading to a fixed component.
We'll just fall back to the name in the quirk (Dell dock) in this case.
This plugin requires infrastructure introduced in fwupd 1.1.3
and can not be backported to earlier versions of fwupd.
It works together with the Synaptics and Thunderbolt plugins to
coordinate the proper flashing procedure for devices in this dock.
This allows a frontend to call update on an individual device ID which will
cause a CAB file to be downloaded, but then also re-use the same CAB file to
try to process devices with a relationship as part of a transaction.
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 -- which will probably explode in a ball of flames.
The profiling data is of limited use, and better data can be obtained using
kcachegrind and massif. Additionally, the profile samples were the cause of the
small RSS growth over time, when in reality the data would only be shown when
the verbose switch is used at daemon startup.
Since it matches the Realtek dongle, shouldn't show this error:
failed to add USB device 0bda:8153: no dock detected
All the time when that dongle is plugged in
It seems the 'Notebook' vendor is padded with spaces in the DMI data, and so
the GUID changes now we're following the same stripping scheme of Windows 10.
Now devices can have multiple GUIDs and do not share platform IDs there is
really no point waiting to add the device.
This allows us to remove a whole lot of code for this now-unused functionality.
This started popping up in Arch CI:
../fwupd/plugins/uefi/fu-uefi-vars.c: In function ‘fu_uefi_vars_get_data’:
../fwupd/plugins/uefi/fu-uefi-vars.c:233:9: error: pointer targets in assignment from ‘gchar *’ {aka ‘char *’} to ‘guint8 *’ {aka ‘unsigned char *’} differ in signedness [-Werror=pointer-sign]
*data = g_steal_pointer (&data_tmp);
^
Until now, the unifying plugin was a 'special snowflake' and did things in very
different ways to the other plugins. Refactor each object to derive from either
FuUsbDevice or FuUdevDevice, and then remove LuDevice and the LuContext layers.
It wasn't hugely clear what the platform ID was actually meant to represent. In
some cases it was being used like a physical ID, in others it was a logical ID,
and in others it was both. In some cases it was even used as a sysfs path.
Clear up all the confusion by splitting the platform ID into two parts, an
optional *physical* ID to represent the electrical connection, and an optional
*logical* ID to disambiguate composite devices with the same physical ID.
Also create an explicit sysfs_path getter for FuUdevDevice to make this clear.
This allows WAIT_FOR_REPLUG to always work, rather than depending on the order
that the GUIDs were added, and that the kernel would always return the same
sysfs path (which it doesn't have to do, especially for hidraw devices).
As an example use case earlier development versions of a Thunderbolt module
may contain DROM corresponding to one model ID and transition to another
model ID. Even if lying about the GUIDs supported by the device via a
quirk the Thunderbolt validation will fail because the device isn't
intended for that system.
This should only be used during development.
The daemon creates a baseclass of either FuUsbDevice or FuUdevDevice when the
devices are added or coldplugged to match the quirk database and to find out
what plugin to run.
This is proxied to plugins, but they are given the GUsbDevice or GUdevDevice and
the FuDevice is just thrown away. Most plugins either use a FuUsbDevice or
superclassed version like FuNvmeDevice and so we re-create the FuDevice, re-probe
the hardware, re-query the quirk database and then return this to the daemon.
In some cases, plugins actually probe the hardware three times (!) by creating
a FuUsbDevice to get the quirks, so that the plugin knows what kind of
superclass to create, which then itself probes the hardware again.
Passing the temporary FuDevice to the plugins means that the simplest ones can
just fu_plugin_device_add() the passed in object, or create a superclass and
incorporate the actual GUsbDevice and all the GUIDs.
This breaks internal plugin API but speeds up startup substantially and deletes
a lot of code.
If another plugin causes a Synaptics MST device to be removed, it
also needs to be removed from the cache to prevent problems when
the device is re-probed.
1) Switch to daemon provided vfuncs for USB
2) Set quirks so that the plugin only runs when Realtek NIC shows up
3) Rely on the daemon to process all removals by parent tree
The setup() is the counterpart to probe(), the difference being the former needs
the device open and the latter does not.
This allows objects that derive from FuDevice, and use FuDeviceLocker to use
open() and close() without worrying about the performance implications of
probing the hardware, i.e. open() now simply opens a file or device.
These are GUIDs that are related to the main device, but should not be used for
quirk matching. For instance, we might want to list the GUIDs for a bootloader
mode, but we don't want to import all the quirks for the bootloader when in the
runtime mode.
This flag is intended for devices that the restart procedure will
be performed as part of a transactional update by an external
controller.
None of the currently supported devices need this flag.
This allows us to match non-DeviceID GUIDs, and also GUIDs we don't know how to
generate.
To make this fully useful, search for device quirks when GUIDs are added.
This was compiling and passing CI as the un-implemented legacy functionality
was still exported in the header.
Remove the prototypes for the missing symbols and fix up the plugin.
Apparently the linker complains when dlopen'ing a plugin that's linked against
the libfwupdprivate library the daemon is using. This only seems to happen when
using distro packages...
The size check would always short circuit as
FU_WAC_DEVICE_FEATURE_FLAG_ALLOW_TRUNC == 0
is never true. The error message was thus never
written even if a difference was found.
With this patch we check if ALLOW_TRUNC is set in flags
instead, and only write the error if it is not.
Five plugins (soon to be 7) are linking to the DFU plugin just for this simple
segment-aware chunking functionality. Move this into common code to make
building simpler.
systemd-automount will unmount the ESP when not in use for some
people. This causes automatic ESP detection to fail.
In this case the ESP will need to be added to the conf file and
then this commit will let it keep working.
Currently we only parse the nvm_version attribute according fwupd
expectations when the device is initially added. Elsewhere we just use
the raw version as is which might be problematic as the version format
can change in the middle (for example "33.02" vs. "33.2"). Fix this so
that fu_plugin_thunderbolt_udev_get_version () always returns parsed
version string.
Update self tests accordingly to have "parsed" version to which we
compare against.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Since the multi controller entry is part of the DROM and its place is
not fixed, it is possible (however unlikely) that the locations between
controller and the image are different. One scenario is that the new
image has typo in device or vendor name string fixed which could cause
the offset to be different.
To handle this case properly we need to read multi controller locations
of both controller and image separately, read their values and then
compare them against each other.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
During review it was pointed out that the return value of
read_drom_entry_location () should be documented because it also returns
TRUE when an entry was not found from the DROM. Caller needs to look for
the location->offset in that case. Add a comment explaining this.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
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.
