[qmi-firmware-update] Flash modem with multiple FWs without resets

Wed Jun 9 08:05:25 UTC 2021

Thanks for the answer.

I made a mistake in the text: I can flash multiple cwe but only 1 nvu,
sorry.

> Did the multiple CWE flashing finish correctly really? i.e. do you see
> all the flashed CWEs installed in different slots in the firmware
> list?

Yes, I call `qmicli -d /dev/cdc-wdm1 --dms-list-stored-images` and all the
CWE flashed correctly in different "pri" slots.
I have log like this:
```
[/dev/cdc-wdm2] Device list of stored images retrieved:

        [0] Type:    'modem'
            Maximum: '4'

                [modem0]
                Unique ID:     '?_?'
                Build ID:      '01.08.04.00_?'
                Storage index: '1'
                Failure count: '0'

        [1] Type:    'pri'
            Maximum: '50'

                [pri0]
                Unique ID:     '000.001_001'
                Build ID:      '01.08.04.00_SPRINT'

                [pri1]
                Unique ID:     '002.000_000'
                Build ID:      '01.08.04.00_US-CELLULAR'

                >>>>>>>>>> [CURRENT] <<<<<<<<<<
                [pri2]
                Unique ID:     '002.015_002'
                Build ID:      '01.08.04.00_VERIZON'
```
But the "modem" will be only with one element.

I have limitations to re-check real wireless possibilities of the modem but
when I try to reflash an already flashed image it says that all is ok and
all the calls of qmicli work fine.

> Yeah, not sure if the modules themselves are ready for that, or at
> least we may not have all the necessary info to know how to do that.
> qmi-firmware-update is mostly based on reverse engineering USB traces
> generated by other proprietary programs :)
I have as an example Windows closed source flash tool which can flash
without resets. Ok, thanks for the comments. I am continuing my
investigation in this field.

P.S.
In addition I have a strange situation when flashing multiple CWE:
```
downloading cwe image: SWI9X50C_01.09.04.00.cwe (79.7 MB)...
finalizing download... (may take several minutes, be patient)
successfully downloaded in 119.69s (665.6 kB/s)
downloading cwe image: SWI9X50C_01.08.04.00.cwe (79.6 MB)...
finalizing download... (may take several minutes, be patient)
successfully downloaded in 22.31s (3.6 MB/s)
```
All the CWEs after the 1st one will be flashed much faster. Any ideas why?

пн, 7 июн. 2021 г. в 12:16, Aleksander Morgado <aleksander at aleksander.es>:

> Hey,
>
> > I am new to libqmi and want to flash multiple FWs with 1 time call of
> qmi-firmware-update app (to eliminate resets).
> > I run the app like this:
> > qmi-firmware-update --update --ignore-version-errors -w /dev/cdc-wdm3
> fws/50-SWI9X50C_01.08.04.00_VERIZON_002.015_002/SWI9X50C_01.08.04.00.cwe
> fws/50-SWI9X50C_01.08.04.00_VERIZON_002.015_002/SWI9X50C_01.08.04.00_VERIZON_002.015_002.nvu
> fws/50-SWI9X50C_01.09.04.00_DOCOMO_002.015_000/SWI9X50C_01.09.04.00.cwe
> fws/50-SWI9X50C_01.09.04.00_DOCOMO_002.015_000/SWI9X50C_01.09.04.00_DOCOMO_002.015_000.nvu
> >
> > If I understand correctly that is not supported because multiple nvu
> files cannot be flashed at 1 time (cwe flashing works fine).
> >
>
> I believe you're abusing the command line tool in an unexpected way :)
> Did the multiple CWE flashing finish correctly really? i.e. do you see
> all the flashed CWEs installed in different slots in the firmware
> list?
>
> The tool is meant to be used only with 1 cwe+ 1 nvu, because we need
> to tell the module to which new firmware version + carrier version it
> needs to switch, and we get that by parsing the cwe+nvu pair. Once the
> module knows the required version is one that it doesn't have
> installed, we trigger a reboot and at this point, the module will
> accept any kind of new file downloaded. Looks like you're downloading
> multiple cwe files at this point and it's working, I really never
> tested that myself.
>
> > And here are some questions:
> > - Why multiple nvus cannot be flashed at 1 time?
>
> Well, I never thought about allowing that truth be told. I don't even
> know if the issue is a problem inside the module or in the tool, I
> have no idea :)
>
> > - Maybe it can be patched? Can somebody give me advice on where to
> search? I can try to patch the source code.
> >
>
> I guess we could extend the qmi-firmware-update operation to say:
> flash the first CWE+NVU pair found, but also try to flash any
> additional CWE or NVU file found. I truly have no idea whether that's
> possible, really. I don't recall all the details of the upgrade
> process, but I do believe there is a way to select in which slot to
> flash, and in the newest firehose based modules the upgrade operation
> also preselects the filename inside the module (e.g. all CWE files
> would be written as "spkg.cwe", so it could be that even if you're
> flashing 10 different CWE files only the last one is really
> considered).
>
> > My main goal is to reduce the time of flashing while working with
> multiple FWs.
> >
>
> Yeah, not sure if the modules themselves are ready for that, or at
> least we may not have all the necessary info to know how to do that.
> qmi-firmware-update is mostly based on reverse engineering USB traces
> generated by other proprietary programs :)
>
> > P.S.
> > Connected email thread: "qmi-firmware-update with multiple NVU for
> Sierra EM7411".
> >
>
> Here's the link to that thread, for context:
>
> https://lists.freedesktop.org/archives/libqmi-devel/2020-October/003402.html
>
> --
> Aleksander
> https://aleksander.es
>

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