There are now two 'backends' of device plug/unplug events, and there is about
to become three. Rather than just adding two more vfuncs for every backend type
define common ones that all providers can use.
Also fix up the existing in-tree plugins to use the new vfunc names and filter
on the correct GType.
This allows us to check that the plugin is writing into a mutable buffer. Also
fix up the plugins that are currently 'wrong' and use the new function for the
plugins doing the right thing.
At the moment FuChunks are sometimes mutable, and sometimes immutable, and it's
all a bit too low level for comfort.
Before we can do any kind of optimisation or verification we need plugins to
stop reading directly from the C structure. The aim here is to make FuChunk
optionally mutable without making assumptions about the memory model, and also
to be able to introspect it for the docs.
This is really useful when working out HwId quirk values for remote systems.
fwupdtool export-hwids target.hwids
vim target.hwids
fwupdtool hwids target.hwids
It is impossible to choose a static default that is appropriate for both a tiny
ARM IoT device and a giant Xeon server.
Fixes https://github.com/fwupd/fwupd/issues/2760
That giant uint64_t isn't looking so big now, and we'll want to add even more
to it in the future. Split out some private flags that are never useful to the
client, although the #defines will have to remain until we break API again.
The fprint daemon only keeps the device open for 5 seconds and then releases it,
which seems like a small window to hit.
But! We're asking the user to authenticate with the same device we're about to
upgrade so a different part of the stack woke up the hardware just before we're
about to deploy an update onto it.
Just retry a few times to make sure the device is idle. Use a flag to prevent
accidentally causing regressions in other plugins.
Fixes https://github.com/fwupd/fwupd/issues/2650
This is a safer version of g_bytes_new_from_bytes() which returns a GError
if the offsets are invalid rather than emitting a critical warning.
This prevents a critical warning and potential crash when parsing invalid
bcm57xx firmware.
We have to supply it when using fu_device_bind_driver(), so we need to get the
old value for ->attach() to avoid guessing what driver was previously loaded.
The same plugin name was being added to the device from the quirk file more than
once, and so we enumerated the device *again* and tried to add a duplicate
device -- the device list correctly refusing to do so.
Check the plugin name does not already exist before adding it, and add a self
test to catch this for the future.
The GLib g_byte_array_set_size() function does not zero the contents if the
array size is larger, which leads to unpredictable output when using valgrind.
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.
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
For containers with multiple images it is sometimes very helpful to know what
file they've been loaded from. This would also allow us to 'explode' the
firmware container into seporate image files on disk.
The function fu_firmware_add_image() has the comment text 'If an image with the
same ID is present it is replaced' which has not been true for some time.
This was removed, as the common case of adding two images with no ID would only
leave one. However, some plugins do actually want to dedupe on the ID or IDX,
so provide a flag they can set which enables this functionality without
introducing regressions into other plugins.
