Quectel EG25-G modem in the Pine64 PinePhone and PinePhone Pro can be
booted with the eg25-manager (user space) or modem-power (kernel space).
We only support the eg25-manager for upgrading these modems.
Based on a patch by Dylan Van Assche <me@dylanvanassche.be>, thanks.
tristate features will automatically disable if dependencies marked
as required are missing.
Packagers can manually override using `auto_features`.
Link: https://mesonbuild.com/Build-options.html#features
When fastboot is used, the modem is rediscovered through udev
after upgrading. However, the modem-manager plugin did not mark
the modem as unhibited with ModemManager. This resulted into
ModemManager not exposing the modem without restarting ModemManager or
rebooting the device.
Mark the modem as uninhibited and do not take ownership over the
plugin data as this caused segfaults.
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.
We were calling g_module_symbol() 2703 times, which is actually more
expensive than you'd think.
It also means the plugins are actually what we tell people they are:
A set of vfuncs that get run. The reality before that they were dlsym'd
functions that get called at pretty random times.
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>
Quite a few plugins are using a FuDeviceLocker to detach then attach in
the error path, and finding them isn't easy as we explicitly cast to a
FuDeviceLockerFunc.
For sanity, just provide both symbols so we can do the right thing in
both cases. It seems like a sensible thing to allow.
Fixes https://github.com/fwupd/fwupd/issues/3771
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>
More than one person has asked about 'why call fu_plugin_update() for a
reinstall or downgrade' and I didn't have a very good answer.
The plugin API is not officially stable, and we should fix things to be
less confusing. Use the same verbs as the FuDevice vfuncs instead.
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.
The best way of not getting something wrong is to not require it in the first
place...
All plugins now use DeviceInstanceId-style quirk matches and we can just drop
the prefix in all files. We were treating HwId=, Guid= and DeviceInstanceId= in
exactly the same way -- they're just converted to GUIDs when building the silo!
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.
