aleksander/qmi-firmware-update v2: dms-list-stored-images on MC7430

[Aleksander Morgado]

On Fri, Jan 20, 2017 at 12:17 PM, Aleksander Morgado
<aleksander at aleksander.es> wrote:
> I can now reproduce this issue. It only seems to happen when the
> MC7455 is configured with 2 QMI+wwan pairs (AT!USBCOMP=1,1,50D). When
> setting up a single QMI+wwan pair (AT!USBCOMP=1,1,10D), the issue
> doesn't happen.

Ok, I think I now have this issue happening consistently.

The cdc-wdm devices are getting removed and re-added correctly by the
kernel, that is no issue. I've updated the qmi-firmware-update tool to
have an "always-on" udev monitor that just logs the device
addition/removals.

So, firmware upgrade happens and the device reboots. The
qmi-firmware-update application waits for the first cdc-wdm device to
get exposed by the kernel. As soon as we get it, we try to run DMS
commands to query e.g. current firmware preference. The first commands
will timeout, but eventually they will succeed (which is why there's
this loop of retries up to 12 times:

waiting some time for the device to boot...
loading device information after the update (1/12)...
waiting some time for the device to boot...
loading device information after the update (2/12)...
....

All good until now.

Now, the issue is that if the modem exposes 2 cdc-wdm devices, ONLY
the one that qmi-firmware-update uses, i.e. the first one used upon
reboot, will end up working. E.g. if we have cdc-wdm1 and cdc-wdm2
exposed, if we use cdc-wdm1 automatically, cdc-wdm2 won't work
afterwards. If we use cdc-wdm2 automatically, cdc-wdm1 won't work
afterwards. I've validated this assumption using the --skip-validation
option and then manually running qmicli commands myself.

I then went ahead and tried doing manual "Set Firmware Preference"
updates, e.g. selecting a different modem+pri image pair. Upon reboot
*the same issue happens*. Only one cdc-wdm will work, the one that is
used first. So this is not likely related to the firmware download
process itself, but to the process of switching the running firmware.

This seems to be a firmware issue again, or at least that is what looks like.

-- 
Aleksander
https://aleksander.es