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.
