[qmi-firmware-update] Parallel flashing of modems

Alexander Dydychkin alexander.dydychkin at vicuesoft.com
Fri Jun 11 12:34:18 UTC 2021


Excuse for troubling. The issue was on the side of the environment. One of
the ttyUSB interfaces was damaged. I re-created it manually and now it
works fine.

So I can confirm that parallel flashing works fine and speed ups the
flashing by the time of the app instances.

If you are interested:

|                                      | Duration downloading, sec |
Duration overall, sec |
|--------------------------------------|---------------------------|-----------------------|
| Flash 1 FW with qmi-firmware-update  | ~120                      | ~220
               |
| Parallel flashing of 2 modems (1 FW) | ~111 (104,118)            | ~210
(203, 216)       |
| Parallel flashing of 3 modems (1 FW) | ~121 (120,121,121)        | ~187
(193,199,168)    |



ср, 9 июн. 2021 г. в 11:32, Alexander Dydychkin <
alexander.dydychkin at vicuesoft.com>:

> Hi all,
> I continue research on how to speed up flashing of multiple modems. In
> addition to flashing without resets which discussed in another thread I try
> to flash modems parallel.
>
> I have 3 devices:
> ```
> ls /dev
> cdc-wdm1
> cdc-wdm2
> cdc-wdm3
> ```
> All Sierra modems right now.
>
> How I start:
> ```
> sudo -E ./_debug_build/src/qmi-firmware-update/qmi-firmware-update
> --verbose-log=/home/libqmi/wdm1.log -w /dev/cdc-wdm1 --update
> /home/0/DOCOMO/SWI9X50C_01.09.04.00.cwe
> /home/0/DOCOMO/SWI9X50C_01.09.04.00_DOCOMO_002.015_000.nvu & \
> sudo -E ./_debug_build/src/qmi-firmware-update/qmi-firmware-update
> --verbose-log=/home/libqmi/wdm2.log -w /dev/cdc-wdm2 --update
> /home/0/SPRINT/SWI9X50C_01.08.04.00.cwe
> /home/0/SPRINT/SWI9X50C_01.08.04.00_SPRINT_000.001_001.nvu & \
> sudo -E ./_debug_build/src/qmi-firmware-update/qmi-firmware-update
> --verbose-log=/home/libqmi/wdm3.log -w /dev/cdc-wdm3 --update
> /home/0/GENERIC/SWI9X50C_01.11.00.00.cwe
> /home/0/GENERIC/SWI9X50C_01.11.00.00_GENERIC_002.023_000.nvu &
> ```
>
> I get the error like:
> ```
> [07 Jun 2021, 18:11:34] [Debug] [qfu-udev] event: add 3-4.4
> [07 Jun 2021, 18:11:34] [Debug] [qfu-udev] event: add 3-4.4:1.0
> [07 Jun 2021, 18:11:34] [Debug] [qfu-udev] event: add ttyUSB2
> [07 Jun 2021, 18:11:34] [Debug] [qfu-udev] waiting device (tty) matched:
> ttyUSB2
> [07 Jun 2021, 18:11:34] [Debug] [qfu-updater] TTY device found:
> /dev/ttyUSB2
> [07 Jun 2021, 18:11:34] [Debug] [qfu-sahara-device] opening TTY:
> /dev/ttyUSB2
> [07 Jun 2021, 18:11:34] [Debug] [qfu-sahara-device] setting terminal in
> raw mode...
> [07 Jun 2021, 18:11:34] [Debug] [qfu-updater] sahara device creation
> failed: error getting serial port attributes: Inappropriate ioctl for device
> [07 Jun 2021, 18:11:34] [Debug] [qfu-qdl-device] opening TTY: /dev/ttyUSB2
> [07 Jun 2021, 18:11:34] [Debug] [qfu-qdl-device] setting terminal in raw
> mode...
> [07 Jun 2021, 18:11:34] [Debug] [qfu-updater] qdl device creation failed:
> error getting serial port attributes: Inappropriate ioctl for device
> ```
> As I understood the code block is:
> ```
>     errno = 0;
>     g_debug ("[qfu-sahara-device] setting terminal in raw mode...");
>     if (tcgetattr (self->priv->fd, &terminal_data) < 0) {
>         inner_error = g_error_new (G_IO_ERROR, G_IO_ERROR_FAILED,
>                                    "error getting serial port attributes:
> %s",
>                                    g_strerror (errno));
>         goto out
> ```
>
> I am working on the improvement right now but I have a question from the
> architecture level. All the processes are independent and have only 1
> crossing point - driver. What do you think about my approach? Any
> "contraindications"? :)  Any comments?
>
>
> --
> With best regards,
> Alexander
>


-- 
With best regards,
Alexander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libqmi-devel/attachments/20210611/f8a54cff/attachment.htm>


More information about the libqmi-devel mailing list