Only on Lenovo devices the DMI version string is prefixed with
CBETxxxx to make the thinkpad_acpi kernel module happy.
Add a new quirk called "CorebootVersionQuirks" to detect platforms
that need to cut of the prefix.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
In fu_plugin_startup we make sure that the FU_HWIDS_KEY_BIOS_VENDOR
matches "coreboot", so there's no need to read it again.
Remove the call to fu_plugin_get_dmi_value and drop the first call
to fu_device_set_vendor as it gets overwritten below.
Hardcode the id string for now.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
We don't actually need either of the things it provides (looking up in source
and built, and converting to an absolute path) so just replace it with
g_build_filename() instead.
This also has the advantage that it does the right thing on Windows.
Some plugins have devices with more than one protocol. Logically the protocol
belongs to the device, not the plugin, and in the future we could use this to
further check firmware that's about to be deployed.
This is also not exported into libfwupd (yet?) as it's remains a debug-feature
only -- protocols are not actually required for devices to be added.
This support was using the wrong commands to add a HWID and thus
never actually functioned. Furthermore it's purpose is to pull
the PID out of the bootloader to be able to properly identify
the device when in bootloader mode (as in recovery mode).
When in this state, generate the correct instance IDs for both
possible Wacom VID. We can't tell which Wacom VID we are in
bootloader mode.
This makes everything simpler, at the expense of not being able to create a
`BootFFFF` entry -- but if we get that far something has already gone very
wrong with the firmware...
Some derivative distributions re-use bootloader paths from their
upstream. When this happens the current logic to look for the `ID`
key in `/etc/os-release` doesn't work properly.
Adjust the logic to:
1) Use `ID`
2) Test the path exists. If so, use it.
3) If it doesn't use `ID_LIKE`.
4) Test if that path exists, if so use it.
5) If that path doesn't exist, return the key from `ID`
6) The plugin will make this path.
This fixes a regression introduced by 2031ce3bf6
that leads to:
```
USB error on device 2dc8:5750 : No such device (it may have been disconnected) [-4]
```
The GNU gold linker uses the section name `.rela.dyn` instead of
`.rela` for containing the relocation information. If this section
is not copied the EFI executable can crash.
Fixes#1530
In an error block that checks for `NULL` sysfs, you will always see
`(null)` in the string.
```
FuPluginThunderbolt Unable to read generation: failed get id generation for (null)
```
This device was showing up from a LG 38UC99-W USB-C monitor
```
VMM0000:
Device ID: d762543f8c20f636e6fff031a000078d3e10c600
Summary: Multi-Stream Transport Device
Current version: 0.00.000
Vendor: Synaptics
GUIDs: 42addef4-40f9-5e89-b925-d564e35ed368 ← MST-(null)-vmm0000-0
cf8c03c5-18bf-53c4-971f-4a08f88932b5 ← MST-(null)-0
e9427b6a-7389-5461-a592-1da5f8ec99fd ← MST-(null)
Device Flags: • Updatable
```
```
failed to close device: Bad file descriptor
```
fu-udev-device will open a locker automatically now.
However synaptics-rmi closes the file descriptor on it's own with `g_clear_object`.
So destroy the fd in synaptics-rmi.
Set `IS_BOOTLOADER` unconditionally when in fastboot mode. This seems logically
what it is; a degraded mode that's able to update firmware without runtime
functionality.
Fixes https://github.com/fwupd/fwupd/issues/1532
This allows us to do three things:
* Fuzz the loader with `fwupdtool firmware-parse`
* Check the firmware *before* the hardware is put into bootloader mode
* Use FuChunk to build the 32 byte payload chunks
Systems with multiple host controllers will most likely have a different
NVM image for each controller but there is no guarantee that the device_id
within the NVM image varies from one controller to another.
To account for this, build a GUID that contains the last element of the
Thunderbolt controller's udev path.
Sample GUID strings from an XPS 9380 (which only contains one host controller):
```
Guid: 0f401ed2-b847-532a-adc8-3193fc737be6 <- TBT-00d408af-native
Guid: 420b0596-f5cb-5fd7-8416-c99d48ad8de9 <- TBT-00d408af-native-0000:05:00.0
```
This commit follows the presumption that the kernel will enumerate the controllers
in the same order every time.
This also lets us remove the call to dfu_device_wait_for_replug() which was
causing a deadlock due to unsafe main context usage. Splitting the code allows
us to use the device list to watch for replug, without adding even more Jabra-
specific plugin code to the DFU plugin.
Looking at this with a 40,000ft view, the Jabra runtime really doesn't have
much in common with DFU and the reason it was originally all lumped together
was that the daemon couldn't "change" plugins between detach and update.
It's unfortunate that we have to include a sleep() in the DFU code after the
DFU probe, but this is specified by Jabra themselves. Attempting to open the
device without waiting reboots the hub back into runtime firmware mode, so we
can't even retry the failing setup action.
During startup we do 1898 persistent allocations to load the quirk files, which
equates to ~90kb of RSS. Use libxmlb to create a mmap'able store we can query
with XPath queries at runtime.
We can't use the IOTA mechanism in bootloader mode, and failing to create the
FuSynapromDevice object means we can't recover the hardware if the flash failed.
Some devices don't set the CAN_DOWNLOAD attribute in their runtime descriptor.
Rather than quirk these devices just assume that all DFU devices with a DFU
interface can download in DFU mode. The logic being, why would they expose a
runtime DFU interface if they can't download new firmware in DFU mode...
Devices like the DW1820A that are currently blacklisted because of broken DFU
support will remain blocked with this change.
This makes the daemon less destructive at startup, especially if the ESP
is not mounted.
It's stored in 3 different places right now, so move it into one point of truth.
Now the ESP is detected when needed including all point of time safety checks and
dynamically mounted and unmounted if necessary.
It appears to only happen on non-dell systems trying to look up system
ID through `sysinfo_get_dell_system_id`
Other than CI non-dell systems won't be running this code.
Detect and parse current coreboot version.
There's no need to depend on libflashrom for now.
An update mechanism isn't implemented as the kernel interface isn't
stable yet and will be implemented in a separate commit.
Tested on coreboot enabled machine.
Example output:
coreboot System Firmware
DeviceId: 81104bde9db7cb037936659ea727c739f47a5029
Guid: 230c8b18-8d9b-53ec-838b-6cfc0383493a <- main-system-firmware
Guid: de6fd40f-4ec9-5c0b-95e1-8fb13d1b030c <- LENOVO&ThinkPad T410&2537VG5
Guid: 978b0d18-bfe9-5279-9a9f-68dc247a705f <- LENOVO&ThinkPad T410&LENOVO&2537VG5
Summary: Open Source system boot firmware
Plugin: coreboot
Flags: internal|registered
Vendor: LENOVO
Version: 4.10.991
VersionFormat: triplet
Icon: computer
Created: 2019-10-14
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
If calling `ch_strerror` with some values returns `NULL` which makes
the `GError` not get populated.
```
0 0x00007f252d64d3bd in fu_colorhug_device_attach (device=0x560d7b5c4520 [FuColorhugDevice], error=0x7ffc57a51040) at ../plugins/colorhug/fu-colorhug-device.c:200
1 0x0000560d7a398279 in fu_device_attach (self=0x560d7b5c4520 [FuColorhugDevice], error=0x7ffc57a51040) at ../src/fu-device.c:1988
2 0x0000560d7a3a4b6c in fu_plugin_device_attach (self=0x560d7b57e160 [FuPlugin], device=0x560d7b5c4520 [FuColorhugDevice], error=0x7ffc57a51040) at ../src/fu-plugin.c:856
3 0x0000560d7a3a553f in fu_plugin_runner_device_generic
(self=0x560d7b57e160 [FuPlugin], device=0x560d7b5c4520 [FuColorhugDevice], symbol_name=0x560d7a3d4258 "fu_plugin_update_attach", device_func=0x560d7a3a4ac1 <fu_plugin_device_attach>, error=0x7ffc57a51040) at ../src/fu-plugin.c:1049
4 0x0000560d7a3a618d in fu_plugin_runner_update_attach (self=0x560d7b57e160 [FuPlugin], device=0x560d7b5c4520 [FuColorhugDevice], error=0x7ffc57a51040) at ../src/fu-plugin.c:1333
5 0x0000560d7a3bcc33 in fu_engine_update
(self=0x560d7b4b9830 [FuEngine], device_id=0x560d7b64f200 "d45c9d222f7eeb3987c6a7674478bc6aec127b3f", blob_fw2=0x560d7b62c0d0, flags=FWUPD_INSTALL_FLAG_NONE, error=0x7ffc57a51150)
at ../src/fu-engine.c:2001
(gdb) print error_local
$1 = (GError_autoptr) 0x0
```
Currently ICL shows up like this:
```
├─Unknown Device:
│ Device ID: d066959bf1b0da600f4fcaab5aa31cab3ff05eee
│ Summary: Unmatched performance for high-speed I/O
│ Current version: 71.00
│ Update Error: Missing non-active nvmem
│ Flags: internal|require-ac|registered
│ GUID: e72e778e-94f7-5ed2-b560-1c1262ee217c
```
Which isn't very useful to end users. Instead show the generic name
`Thunderbolt Controller` which matches the behavior change we've made
in UEFI FW and Touchpad FW items too.
```
├─Thunderbolt Controller:
│ Device ID: d066959bf1b0da600f4fcaab5aa31cab3ff05eee
│ Summary: Unmatched performance for high-speed I/O
│ Current version: 71.00
│ Update Error: Missing non-active nvmem
│ Flags: internal|require-ac|registered
│ GUID: e72e778e-94f7-5ed2-b560-1c1262ee217c
```
Also, quite the messages about missing vid/did as these won't exist
on ICL either.
I saw a mention that they're actually CX21986 and had some on hand.
They do enumerate:
```
├─Pixel USB-C earbuds:
│ Device ID: 672c087de09848d9e7ee32aa1dea2fbeb8b81e6b
│ Summary: CX21986 USB audio device
│ Current version: 71.133.20
│ Bootloader Version: 03.01.00.00
│ Vendor: Google (USB:0x18D1)
│ Install Duration: 3 seconds
│ Flags: updatable|registered
│ GUIDs: d76048a5-ca69-5cb8-ac86-d418d70c5f29
│ 98043a29-72c5-549b-ad23-de4e2db20a14
│ 93279fe8-d478-531b-9637-05d026be3c2e
│ 8b71f776-f6d0-549d-9547-42740b24bbbc
```
I was seeing on a CML laptop with a Nuvoton TPM the following which
is definitely wrong:
```
Checksum: SHA1(791183aa2c4993dfaf75e95c91bdad067ac2cce1)
Checksum: SHA256(8a0656fe0024cc3300cc4dc8af4fc336112a51013aeb74b21c138ed116bb8691)
Checksum: SHA1(000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000)
```
Actually trying to instantiate the object leads to:
Specified class size for type 'FuWacomEmrDevice' is smaller than the
parent type's 'FuWacomDevice' class size.
Fixes https://github.com/fwupd/fwupd/issues/1456
This was a new file format to help out an OEM, but they didn't actually use it.
If we do need it in the future, it would some back as a src/ helper, not in
plugins/dfu.
We don't support any hardware that actually uses this proposed standard, and
nowadays there is much better public-key encryption people can easily use.
Use this attribute to determine whether or not to try to read 'native'
from the Thunderbolt NVM image at probe time.
This attribute is new to kernel 5.5.
The new plugin is called `optionrom` as this is the only type of image that it
parses for verification only. FuUdevDevice is also the generic parent already.
Although they can be useful for debugging the codepath leading to
a problem, they are also confusing when it comes to the end user
messages:
```
{error #0} linux.c:406 device_get(): readlink of /sys/block/nvme0n1/device/driver failed: No such file or directory
{error #1} linux.c:406 device_get(): readlink of /sys/block/nvme0n1/device/driver failed: No such file or directory
{error #2} linux.c:406 device_get(): readlink of /sys/block/nvme0n1/device/driver failed: No such file or directory
{error #3} linux.c:406 device_get(): readlink of /sys/block/nvme0n1/device/driver failed: No such file or directory:
Error writing to file descriptor: No space left on device
```
Whereas if they weren't shown, that last message would have been plenty.
