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

[Aleksander Morgado]

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...

-- 
Aleksander
https://aleksander.es