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

Christophe Ronco c.ronco-externe at kerlink.fr
Wed Jan 18 15:24:45 UTC 2017


On 01/18/2017 02:38 PM, Aleksander Morgado wrote:
> On Wed, Jan 18, 2017 at 2:00 PM, Aleksander Morgado
> <aleksander at aleksander.es> wrote:
>> On Wed, Jan 18, 2017 at 1:21 PM, Bjørn Mork <bjorn at mork.no> wrote:
>>>> 2) In List Stored Images response, index of running image is given but it is
>>>>> "2" with only image 0 and 1 after. Maybe it is a storage index and not an
>>>>> index in the table of answers. Do you know that?
>>>>>
>>>> Your QMI response for List Stored Images says:
>>>>    index_of_running_image = '2'
>>>> But the list of images only contains 2 items (indices 0 and 1).
>>>>
>>>> I rechecked what that value is supposed to mean, and it is the index
>>>> of the image in the list returned, not the storage index.
>>> well, I've consistenly seen the same issue with the MC7455 and EM7455
>>> modems...
>>>
>>>
>>>> If it were
>>>> the storage index, you wouldn't have seen CURRENT before the firmware
>>>> upgrade (as the CURRENT was index_of_running_image = '0' and your
>>>> storage index was 1).
>>> True. That doesn't add up.  Unless '0' has a different meaning.
>>> Guessing wildly again, but could this indicate a "directly uploaded
>>> image"?  I'm thinking about the case where you've updloaded an image
>>> directly to the modem partition, any not into any of the 4 slots.  Like
>>> you will do if you do AT!BOOTHOLD to switch into QDL mode.
>>>
>>> Just a random thought
>> I really believe this is a firmware bug of some sort, nothing to do with libqmi.
>>
>> Could it be that whenever an image is uploaded, the
>> "index_of_running_image" gets the value from the "storage index", but
>> then after doing selections with --dms-select-stored-image the
>> "index_of_running_image" is again the correct one, i.e. the index from
>> the list reported?
> Ok, so it isn't an off-by-one error.
>
> It looks like the firmware MAY report the "storage index" in the
> "index_of_running_image" field. I've forced a download in slot 4 while
> I only had one other image in slot 1, and I get index_of_running_image
> = '4' for the modem image, so we don't show the CURRENT message (we
> were expecting a '1' reported, not a '4'):
>
> $ sudo qmicli -d /dev/cdc-wdm1 --dms-list-stored-images --device-open-mbim
> [/dev/cdc-wdm1] Device list of stored images retrieved:
>
> [0] Type:    'modem'
>     Maximum: '4'
>
> [modem0]
> Unique ID:     '?_?'
> Build ID:      '02.20.03.22_?'
> Storage index: '1'
> Failure count: '0'
>
> [modem1]
> Unique ID:     '?_?'
> Build ID:      '02.20.03.00_?'
> Storage index: '4'
> Failure count: '0'
>
> [1] Type:    'pri'
>     Maximum: '50'
>
>>>>>>>>>>> [CURRENT] <<<<<<<<<<
> [pri0]
> Unique ID:     '002.017_000'
> Build ID:      '02.20.03.00_GENERIC'
>
> [pri1]
> Unique ID:     '002.026_000'
> Build ID:      '02.20.03.22_VERIZON'
>
> I said "MAY" because this isn't always the case; in Christophe's
> original message in this thread he was getting
> index_of_running_image=0 while storage index was 1:
>
> # qmicli -d /dev/cdc-wdm0 --dms-list-stored-images
> [/dev/cdc-wdm0] Device list of stored images retrieved:
>
>      [0] Type:    'modem'
>          Maximum: '4'
>
>          >>>>>>>>>> [CURRENT] <<<<<<<<<<
>          [modem0]
>          Unique ID:     '?_?'
>          Build ID:      '02.14.03.00_?'
>          Storage index: '1'
>          Failure count: '0'
>
>      [1] Type:    'pri'
>          Maximum: '50'
>
>          >>>>>>>>>> [CURRENT] <<<<<<<<<<
>          [pri0]
>          Unique ID:     '002.012_000'
>          Build ID:      '02.14.03.00_GENERIC'
>
> What do we do with this issue?
>
> Should we just avoid reporting the "CURRENT" message, even if it works
> always for PRI images?
>
> I wonder is this some artifact from how we do things in the updater. I
> actually haven't done any "manual" firmware update doing a reset+QDL
> download in this modem, so not sure if what Bjørn suggested could be
> the root issue here...
>
When I select firmware 2.14 and corresponding PRI, I always have problem 
to get my modem back online.

root at klk-lpbs_040070:~ # qmicli -d /dev/cdc-wdm0 
--dms-select-stored-image=modem1,pri0
[/dev/cdc-wdm0] Firmware preference successfully selected

     You may want to power-cycle the modem now, or just set it offline 
and reset it:
         $> sudo qmicli ... --dms-set-operating-mode=offline
         $> sudo qmicli ... --dms-set-operating-mode=reset

     No new images are required to be downloaded.

     You should check that the modem|pri image pair is valid by checking 
the current operating mode:
         $> sudo qmicli .... --dms-get-operating-mode
     If the Mode is reported as 'online', you're good to go.
     If the Mode is reported as 'offline' with a 
'pri-version-incompatible' reason, you chose an incorrect pair

root at klk-lpbs_040070:~ # qmicli -d /dev/cdc-wdm0 
--dms-set-operating-mode=offline
[/dev/cdc-wdm0] Operating mode set successfully
root at klk-lpbs_040070:~ # qmicli -d /dev/cdc-wdm0 
--dms-set-operating-mode=reset
[/dev/cdc-wdm0] Operating mode set successfully
root at klk-lpbs_040070:~ # qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode
[18 Jan 2017, 15:09:59] -Warning ** Error reading from istream: Error 
reading from file descriptor: No such device
error: couldn't create client for the 'dms' service: CID allocation 
failed in the CTL client: Transaction timed out
root at klk-lpbs_040070:~ #
root at klk-lpbs_040070:~ #
root at klk-lpbs_040070:~ #
root at klk-lpbs_040070:~ # qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode
error: couldn't create client for the 'dms' service: CID allocation 
failed in the CTL client: Transaction timed out

I have to power cycle my modem (twice in most of the cases) to have my 
modem back.

My guess is that my firmware 2.14 stored in index 1 is KO (I don't know 
why) and modem does not manage to boot with it. It goes back to another 
firmware (factory firmware?) which is also a 2.14 and boot with it. The 
storage index of this firmware is 0. Downloadable staorage index start 
from 1.

That's only a guess. I will try to put a 2.23 is storage 1 and see what 
happens.

Christophe





More information about the libqmi-devel mailing list