Some modems such as the Quectel EG25-G have alternative firmwares available.
Read the firmware branch if supported by the firmware and set it,
if not, fall back to the default branch.
Normally each AT command is ended with either OK or ERROR,
but that's not the case for the Quectel EG25-G's AT command to enter fastboot.
As soon as AT+QFASTBOOT is sent, the modem switches to fastboot mode without replying OK.
It may make sense to have the modem not doing anything during the upgrade,
so the inhibition would make total sense.
Signed-off-by: Jarvis Jiang <jarvis.w.jiang@gmail.com>
It's actually quite hard to build a front-end for fwupd at the moment
as you're never sure when the progress bar is going to zip back to 0%
and start all over again. Some plugins go 0..100% for write, others
go 0..100% for erase, then again for write, then *again* for verify.
By creating a helper object we can easily split up the progress of the
specific task, e.g. write_firmware().
We can encode at the plugin level "the erase takes 50% of the time, the
write takes 40% and the read takes 10%". This means we can have a
progressbar which goes up just once at a consistent speed.
Module may not have been re-probed and exposed in MM when the FW version was successfully obtained, which leads to the report that failed to get device after update. In fact, FW has been uodated successfully, it needs to add 150s to wait for the module to be re-probed and exposed in MM.
Signed-off-by: Jarvis Jiang <jarvis.w.jiang@gmail.com>
Add the mbim-qdu support for firmware downloading, it will be used for T99W175 module of Foxconn.
Signed-off-by: Jarvis Jiang <jarvis.w.jiang@gmail.com>
This allows us to 'nest' firmware formats, and removes a ton of duplication.
The aim here is to deprecate FuFirmwareImage -- it's almost always acting
as a 'child' FuFirmware instance, and even copies most of the vfuncs to allow
custom types. If I'm struggling to work out what should be a FuFirmware and
what should be a FuFirmwareImage then a plugin author has no hope.
For simple payloads we were adding bytes into an image and then the image into
a firmware. This gets really messy when most plugins are treating the FuFirmware
*as* the binary firmware file.
The GBytes saved in the FuFirmware would be considered the payload with the
aim of not using FuFirmwareImage in the single-image case.
Devices may want to support more than one protocol, and for some devices
(e.g. Unifying peripherals stuck in bootloader mode) you might not even be able
to query for the correct protocol anyway.
It is far too easy to forget to set FWUPD_DEVICE_FLAG_NO_GUID_MATCHING for new
plugins, and without it it all works really well *until* a user has two devices
of the same type installed at the same time and then one 'disappears' for hard
to explain reasons. Typically we only need it for replug anyway!
Explicitly opt-in to this rarely-required behaviour, with the default to just
use the physical and logical IDs. Also document the update behavior for each
plugin to explain why the flag is being used.
This allows you to have two identical Unifying plugged in without one of them
being hidden from the user, at the same time allowing a HIDRAW<->USB transition
when going to and from bootloader and runtime modes.
This removes the workaround added in 99eb3f06b6.
Fixes https://github.com/fwupd/fwupd/issues/2915
Asking the user for the UID mapping isn't working very well, as it requires lots
of manual handholding. It also doesn't work very well when the device vendor
does not actually have a PCI ID or if the vendor has split into two entities.
Just use the OUI address as an additional VendorID and match any of the device
IDs against any of the metadata-supplied values.
The plugin currently supports Fastboot and QMI/PDC methods, but given
that QMI/PDC is exclusively used for carrier config installations,
there is no need for QMI/PDC-only updates, so make sure that
combination is right away forbidden.
This validation will also be useful when adding additional update
methods, as we'll be able to clearly specify which are the
combinations expcted.
The upgrade process requires that the USB interface layout is not
changed between upgrades, something that we require for AT and we also
require now for QMI. We store the USB interface number of the QMI port
as soon as the device is probed, and we use it to match the interface
number once the Udev based device is created.
squash! modem-manager: make sure the correct interface number is used for QMI
Reading the sysfs file seemed to have also eaten the `\n` as mentioned
on a bug.
```
├DW5821e Snapdragon X20 LTE:
│ Device ID: fa707b9af86ff44bc17316b6c3e5ea82aab3ce86
│ Summary: Mobile broadband device
│ Current version: T77W968.F1.0.0.4.2.GC.010
│ Vendor: Dell Inc. (USB:0x413c
│ )
│ GUIDs: 64da2d58-8d1b-5e5b-b793-f88ba5a25a8f
│ 761d6124-0002-5185-b767-9adf67bf1a5e
│ 795e079d-093b-5503-aa59-35b832480e95
│ Device Flags: • Updatable
```
If we say that the version format should be the same for the `version_lowest`
and the `version_bootloader` then it does not always make sense to set it at
the same time.
Moving the `version_format` to a standalone first-class property also means it
can be typically be set in the custom device `_init()` function, which means we
don't need to worry about *changing* ther version format as set by the USB and
UDev superclass helpers.
In many plugins we've wanted to use ->prepare_firmware() to parse the firmware
ahead of ->detach() and ->write_firmware() but this has the limitation that it
can only return a single blob of data.
For many devices, multiple binary blobs are required from one parsed image,
for instance providing signatures, config and data blobs that have to be pushed
to the device in different way.
This also means we parse the firmware *before* we ask the user to detach.
Break the internal FuDevice API to support these firmware types as they become
more popular.
This also allows us to move the Intel HEX and SREC parsing out of the dfu plugin
as they are used by a few plugins now, and resolving symbols between plugins
isn't exactly awesome.
This leads to madness, as some formats are supersets of the detected types,
e.g. 'intel-me' is detected as 'quad' and 'bcd' is detected as 'pair'.
Where the version format is defined in a specification or hardcoded in the
source use a hardcoded enum value, otherwise use a quirk override.
Additionally, warn if the version does not match the defined version format
The timeout to wait for the modem after being uninhibited was until
now exclusively to cover the port probing time, because the device
would be already available and ready to be used as soon as the
inhibition was removed.
With the change to include carrier config selection as part of the
fwupd upgrade process, the time to wait for the modem after being
uninhibited should now cover a full reboot of the module, and so the
original timeout of 45s could be a bit tight under some circumstances
(e.g the MM device probing logic is quite slow when there is no SIM
card detected by the module).
We increase this timeout to a much safer value of 120s, which is
extremely long for most cases, but should also be enough to cover even
the worst case scenario.
