RFC: aleksander/qmi-firmware-update branch

[Bjørn Mork]

Aleksander Morgado <aleksander at aleksander.es> writes:

>> So we have a mismatch and IMSWITCH is asserted:
>>
>> at!pcinfo?
>> State: Low Power Mode
>> LPM voters - Temp:0, Volt:0, User:0, W_DISABLE:0, IMSWITCH:1, BIOS:1, LWM2M:0, OMADM:0, FOTA:0
>> LPM persistence - None
>>
>> OK
>>
>>
>>
>> No big deal, of course.  This can easily be fixed by either changing the
>> firmware preference or uploading the image, but it's not exactly user
>> friendly.
>>
>>
>
> Hum... what would be the rollback approach in this case? recover the
> original firmware preference settings and fallback to them if any
> error happens?

Probably best? At least if that matches an installed image...  Which
we'd have to check.

Or we could simply give the user a hint on how to manually resolve the
issue. Leaving the modem in this state is no problem IMHO.  We just
need to make sure the user understands why the modem doesn't come out of
low-pwer mode anymore, and how to fix it.

Documenting stuff that will be unexpected to new users is most
important

And while we're there: It could be wise to print a short warning while
waiting for the final ack of a big image.  I know this takes time, and I
guess you know it by now. But a new user can grow a few gray hairs
waiting for any progress at this point.  All the other acks are quick,
but the final one can take minutes. The impatient might think something
failed.  Guess how I know that :)



>> Also a bit confusing: "reset" will not work with with the MBIM device
>> path as selector:
>>
>> root at miraculix:/tmp# qmi-firmware-update -v -w /dev/cdc-wdm0 -p --device-open-mbim  --reset
>> error: device not specified
>>
>
> --reset requires an AT port as it does AT!BOOTHOLD; this is probably a
> missing if() somewhere.
>
> Anyway, maybe it's worth completely removing the cdc-wdm based device
> selection? What do you think? It was the first one I had, but using
> the other methods seems easier in most cases (e.g. I just do "-d 1199"
> most of the times I play with the tool).

Yes, that is probably best. Having too many options is just confusing,
although I did find the cdc-wdm based selection convenient.

We must have a way to select one among a set of identical modems, but
--busnum-devnum will take care of that.


>> But resetting by USB device ID and then uploading in QDL mode work
>> flawlessly.  Although I didn't expect "reset" to use the AT command:
>>
>
> It was the "suggested" way to reset the devices that don't support the
> set firwmware preference command, at least that is what I could find.

OK.  But what about modems without an AT port?

I don't remember and am too lazy to search old mailing list posts, but I
believe the MC7710 updater had a "magic" DMS boot-and-hold QMI request.
0x003e?
>> I'm not 100% sure about this, but the experiments I've done so far seems
>> to indicate that this happens if we force the device into QDL mode
>> instead of letting the bootloader decide.  This should work as requested
>> if we avoid aborting after reset.  The bootloader will then enter QDL
>> mode as a result of "set firmware preference" + "reset", and the upload
>> is copied to one of the slots.
>>
>
> In the tests I've done with the MC7455, I believe the image was in
> fact copied to one of the slots; but this was directly using the
> automatic method which does "set firmware preference" as you said. Is
> this something that we should take care of somehow? Ideally we could
> detect this situation and warn it, but I'm not sure it's worth the
> effort, don't know. No one should need the "manual" QDL download mode
> if the automatic way works as it should, right?

Correct.  This is a non-issue if the automatic update works.

>> Which slot this is, is another question.  I thought the auto-selection
>> worked fine, but that was only when there were empty slots.  Now, when
>> all 4 slots were occupied, the bootloader actually decided to overwrite
>> the last used slot instead of the least used one:
>>
>>
>> at!image?
>> TYPE SLOT STATUS LRU FAILURES UNIQUE_ID   BUILD_ID
>> FW   1    GOOD   22  0 0      ?_?         02.23.00.00_?
>> FW   2    GOOD   21  0 0      ?_?         02.08.02.00_?
>> FW   3    GOOD   18  0 0      ?_?         02.14.03.00_?
>> FW   4    GOOD   17  0 0      ?_?         02.18.02.00_?
>> Max FW images: 4
>> Active FW image is at slot 1
>>
>> TYPE SLOT STATUS LRU FAILURES UNIQUE_ID   BUILD_ID
>> PRI  FF   GOOD   0   0 0      002.018_000 02.23.00.00_GENERIC
>> PRI  FF   GOOD   0   0 0      002.006_000 02.08.02.00_ORANGE-EU
>> Max PRI images: 50
>>
>>
>>
>> Not perfect.  Maybe we need to implement a slot selection algorithm as
>> well? There is an optional 1-byte TLV 0x10 to the "Set Firmware
>> Preference" requests, which can be used to select a specific slot.
>>
>
> I think we should add the slot selection option as an optional
> argument. E.g., if the user doesn't care what gets overwritten, she
> can still ignore the slot id.

Sounds good.  I'm still wondering why slot 1 was selected.  Not
overwriting slot 2 makes sense because of the ORANGE-EU PRI, but slot 3
and 4 should be better candidates by every possible measure.

Maybe I have selected slot 1 in the past and this selection is kept
somewhere until manually changed?


Bjørn