With how well fwupd UEFI updates work these days >99% of people
don't need to see messages about the capsule update running.
Those who have problems, this isn't going to help them.
Firsly, that HSI isn't expected for embedded devices and then secondary how we
require SecureBoot to be available for HSI:1
At the moment we get a runtime failure if it is disabled. Making SB a part of
`HSI:1` makes this requiremnt explicit and prevents us getting `HSI:2!` if it
is not available.
The 721C is a VL103, which isn't a FuVliUsbhubDevice at all. Fixes the:
already set GType to FuVliPdDevice, ignoring FuVliUsbhubDevice
...message when the Mini dock / powered hub is inserted.
Use one of the errors mapping to FWUPD_UPDATE_STATE_FAILED_TRANSIENT to avoid
uploading a failure report for something the user has to fix, i.e. update the
distro shim package.
Conceptually we were trying to stuff subtly different actions into one vfunc:
* Read firmware from the device to update the verification checksums
* Read a firmware blob from the device for debugging
For the first action we might want to mask out the sections of the flash with
serial numbers (so the verification hashes match the ones published on the LVFS)
and for the second we want just a raw ROM file from the hardware with no
pre-processing that we can compare against an external SPI dumper.
Split out ->dump_firmware to get the raw blob, and allow plugins to also
implement ->read_firmware() if they have to mask out specific offsets or remove
specific images from the FuFirmware container.
In the common case when masking is not required, fall back to using a 'binary'
FuFirmware automatically to make most plugins simpler.
At the moment there are commands to convert one file format to another, but not
to 'merge' or alter them. Some firmware files are containers which can store
multiple images, each with optional id, idx and addresses.
This would allow us to, for instance, create a DfuSe file with two different
raw files that are flashed to different addresses on the SPI flash. It would
also allow us to create very small complicated container formats for fuzzing.
This can be used by writing a `firmware.builder.xml` file like:
<?xml version="1.0" encoding="UTF-8"?>
<firmware gtype="FuBcm57xxFirmware">
<version>1.2.3</version>
<image>
<version>4.5.6</version>
<id>header</id>
<idx>456</idx>
<addr>0x456</addr>
<filename>header.bin</filename>
</image>
<image>
<version>7.8.9</version>
<id>payload</id>
<idx>789</idx>
<addr>0x789</addr>
<data>aGVsbG8=</data>
</image>
</firmware>
...and then using something like:
# fwupdtool firmware-convert firmware.builder.xml firmware.dfu builder dfu
This is only applicable for kernel 5.9 or kernels that backported
the authenticate on disconnect patches.
For installation time this isn't very important since no device will
restart. This also isn't relevant for the authenticate on disconnect
scenario.
However the manual activation scenario, it's important to activate the
WD19TB device first, followed by Thunderbolt.
I2C doesn't have any specification for what is a probe and what is a more
destructive action. Sending tx_buf out on the i2c bus to a generic address
might not be safe in all cases.
To prevent this, use a HWID to check the machine DMI value during device
creation before ->probe() or ->setup() is called on the device.
If the device is not authorized, it may cause a composite update that it's part
of to not behave properly.
If device is authorized at runtime, add updatable flag at runtime as well
See #2374 for more details
This ensures we perform the updates in this order:
* cxaudio
* vli
* thunderbolt
As any other order causes enumeration failures.
Fixes some of https://github.com/fwupd/fwupd/issues/2377
Error will show up if (priv->physical_id == NULL) on
fu_device_ensure_id(). This method is called after probe but before
setup on fu_device_open.
Call fu_device_set_physical_id() on fu_thunderbolt_device_probe()
for the retimer case.
Fixes https://github.com/fwupd/fwupd/issues/2371
Change-Id: I0e462fff5e8abf6073318f6424b6736afc8259b8
This object derives from FuDevice rather than FuVliDevice and so does not
inherit the NO_GUID_MATCHING flag like other devices.
Fixes https://github.com/fwupd/fwupd/issues/2364
It seems the MEI parameters are not set for platforms such as Apollo Lake.
The only bit set was FPF_SOC_LOCK, with the others all cleared to zero.
Fixes https://github.com/fwupd/fwupd/issues/2335 for a peculiar definition of 'fix'.
As described in DFU protocol (7. Manifestation Phase), after the
firmware reprogramming is done, if bitWillDetach = 1, it doesn't
require the host to issue a USB bus reset, but the device can
generate a detach-attach sequence itself to go back to normal.
Add a quirk flag "no-bus-reset-attach" to skip the bus reset in
dfu_device_attach(), and increase the "RemoveDelay" as well.
Print the sysfs path for devices deriving from FuUdevDevice, which also allows
us to use FU_UDEV_DEVICE_DEBUG without monkey-patching the plugins that also
define a device_class->to_string() vfunc.
