These are visually similar to Intel hex files, but different enough to demand
their own parser. Multiple images can be stored in one firmware file, with the
`addr` set to the SiliconID and the `idx` set to the position in the file.
Use only one GMainLoop in FuDeviceList; we can only iterate one loop at a time
anyway, and having the mainloops per-item complicates the lifecycle of the
fu_device_list_wait_for_replug() functionality considerably.
Instead of using RequiresMountsFor=/snap/fwupd/current, which will not
work since /snap/fwupd/current is a symlink [1].
This will work since the mount units generated by snapd all have
Before=snapd.service, so will be stopped after snapd.service during
shutdown.
With After=snapd.service, fwupd-activate.service will then stop before
snapd.service, at a point when all snap mount units are still running.
Fixes the issue where fwupd-activate.service hangs when stopped, causing
a stop job timeout during shutdown.
[1] See https://github.com/systemd/systemd/issues/8907Closes#1654
The m-stack DFU quirk also requires that we get the runtime status so that the
USB_DFU_SUCCESS_FUNC callback gets called. We were doing this by accident
before, and since switching to the FuDevice subclass this was dropped.
The dfu_device_refresh_and_clear() function is safe to call on a device which
does not have a working runtime interface.
If we do not ->open() the device (e.g. because it uses a parent device to proxy
writes) then the child never gets a DeviceID which causes all kinds of issues.
If the device has a child with a longer remove_delay we actually crash because
the FuDeviceList tries to remove the child device twice. Just remove all the
children when the parent remove delay elapsed rather than set up each device
with a unique timeout.
I misunderstood the original specification, and it seems even USB-hub-less
devices have the same header location as their "write-through" counterparts.
The logic was wrong; we should have been using command 0xB0 for attach back to
FW mode for both VL10x and VL103. Using a generic reset on VL103 always reset
the device back into bootloader mode as the ROM signatures were being written
by command 0xC0.
As now attach and detach have different code paths, there's no point having a
`FuVliDevice->reset()` vfunc, and so we can make everything a little simpler at
the same time.
Resolves installation for local CAB files that have `VersionFormat`
set but not yet also set from metadata.
In the first pass ignore the version format. This will rule out all
other checks such as GUID and protocol.
Then apply version format to the device if specified in the CAB.
Lastly do a second pass with all requirements set.
When CPU microcode is distributed it typically is versioned in
hexadecimal in all tools. Converting it to any of the existing version
formats provides an unexpected result that requires converting back to
hexadecimal.
