Updating EM7565 on openwrt

Here’s what I’m doing.

root@OpenWrt:~# qmicli -d /dev/cdc-wdm0 -p --dms-set-firmware- 
preference="01.09.04.00,002.019_000,GENERIC"
[/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

    After reset, the modem will wait in QDL mode for new firmware.
    Images to download: 'modem, pri'

root@OpenWrt:~# qmicli -d /dev/cdc-wdm0 -p --dms-set-operating-mode=offline
[/dev/cdc-wdm0] Operating mode set successfully
root@OpenWrt:~# qmicli -d /dev/cdc-wdm0 -p --dms-set-operating-mode=reset
[/dev/cdc-wdm0] Operating mode set successfully
root@OpenWrt:~# /etc/init.d/modemmanager stop
root@OpenWrt:~# qmi-firmware-update -t /dev/ttyUSB0 --update-qdl 
/tmp/fw/SWI9X50C_01.09.04.00.cwe /tmp/fw/SWI9X50C_01.09.04.00_GENERIC
_002.019_000.nvu
error: error creating device: HDLC trailing control character not found

I found a post by Aleksanders0m stating

Please note that you need libqmi git master version for qmi-firmware-update to work on the EM7565, there is no stable release (yet) with the EM7565 firmware upgrade support yet.

The " error: error creating device: HDLC trailing control character not found " error is because you’re using an older libqmi version.

However I’m using the latest libqmi available (1.22.4-1) in his modemmanager-openwrt repo. Also my modem is now stuck is an inoperable state, what command should I use to return it to it’s normal operating mode until I figure out how to properly update it?

You need libqmi 1.24.0 for this to work, where the support for the new sahara/firehose protocol is implemented. Just update the openwrt packaging setup for libqmi to point to that version:

PKG_VERSION:=1.24.0
PKG_RELEASE:=1
PKG_SOURCE_VERSION:=49abf405f5e9f16542476dceeb20de6029edcf1c

Please note I’m no longer maintaining that openwrt repo, it will soon be integrated in the official packages repo

.

1 Like

In what state is it now? If the upgrade fails like that, you should still be able to power cycle the modem and it would go back to QMI mode

Awesome, that’s exactly what I needed. Thank you so much. I’ll check it out when I get back from my day job.

It’s currently stuck in low-power mode, reason “unknown”. dms-set-operating-mode=online fails with invalid transition. Looks like it’s still waiting for the firmware update.

Edit

root@OpenWrt:~# qmicli -d /dev/cdc-wdm0 -p --dms-get-operating-mode
[/dev/cdc-wdm0] Operating mode retrieved:
        Mode: 'low-power'
        Reason: 'unknown'
        HW restricted: 'no'
root@OpenWrt:~# qmicli -d /dev/cdc-wdm0 -p --dms-set-operating-mode=online
error: couldn't set operating mode: QMI protocol error (60): 'InvalidTransition'

Per your suggestion, seems it’s not yet supported in 1.24.0

 root@OpenWrt:~# qmi-firmware-update -t /dev/ttyUSB0 -U /tmp/fw/SWI9X50C_01.09.04.00.cwe 
    /tmp/fw/SWI9X50C_01.09.04.00_GENERIC_002.019_000.nvu
    error: unsupported download protocol

I should have a usb adapter in hand tomorrow to resolve my issue. I hadn’t realized how far behind support for this modem was.

That is extremely unexpected. Was the modem in “download mode” (i.e. with only one single TTY exposed) when you run that command? If so, could you run the command with “–verbose” so that we can see why the sahara protocol detection failed?

May be due to a mismatch between PRI/Modem images? Could you run these commands to see the details of that state?

# qmicli -d /dev/cdc-wdm0 --dms-swi-get-current-firmware
# qmicli -d /dev/cdc-wdm0 --dms-get-firmware-preference
# qmicli -d /dev/cdc-wdm0 --dms-list-stored-images
root@OpenWrt:~# qmi-firmware-update -t /dev/ttyUSB0 -U /tmp/fw/SWI9X50C_01.09.04.00.cwe 
/tmp/fw/SWI9X50C_01.09.04.00_GENERIC_002.019_000.nvu -v
[27 Jun 2019, 12:22:32] [Debug] [qfu-utils] couldn't ping ModemManager: 
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.ModemManager1" 
does not exist
[27 Jun 2019, 12:22:32] [Debug] [qfu-image] loading file info...
[27 Jun 2019, 12:22:32] [Debug] [qfu-image] opening file for reading...
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe] reading image headers...
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe] image offset range: [0,79664946]
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]   image offset range: [400,7360]
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe] image at offset 400 is valid
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]   image offset range: [7360,407216]
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]     image offset range: [7760,14640]
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]   image at offset 7760 is valid
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]     image offset range: [14640,407216]
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]   image at offset 14640 is valid
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe] image at offset 7360 is valid
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]   image offset range: [407216,39478680]
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]     image offset range: [407616,414576]
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]   image at offset 407616 is valid
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]     image offset range: [414576,871292]
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]   image at offset 414576 is valid
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]     image offset range: [871292,1038880]
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]   image at offset 871292 is valid
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]     image offset range: [1038880,39478680]
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]   image at offset 1038880 is valid
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe] image at offset 407216 is valid
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]   image offset range: [39478680,79664946]
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]     image offset range: [39479080,39486040]
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]   image at offset 39479080 is valid
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]     image offset range: [39486040,39937028]
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]   image at offset 39486040 is valid
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]     image offset range: [39937028,72274126]
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]   image at offset 39937028 is valid
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]     image offset range: [72274126,79664946]
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]   image at offset 72274126 is valid
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe] image at offset 39478680 is valid
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe] validating data size...
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe] preloading firmware/config/carrier...
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]   firmware version: 01.09.04.00
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]   config version:   unknown
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]   carrier:          unknown
[27 Jun 2019, 12:22:32] [Debug] [qfu-image] loading file info...
[27 Jun 2019, 12:22:32] [Debug] [qfu-image] opening file for reading...
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe] reading image headers...
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe] image offset range: [0,10081]
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]   image offset range: [400,7680]
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]     image offset range: [800,7680]
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]   image at offset 800 is valid
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe] image at offset 400 is valid
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]   image offset range: [7680,10081]
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]     image offset range: [8080,10081]
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]   image at offset 8080 is valid
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe] image at offset 7680 is valid
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe] validating data size...
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe] preloading firmware/config/carrier...
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]   firmware version: 01.09.04.00
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]   config version:   002.019_000
[27 Jun 2019, 12:22:32] [Debug] [qfu-image-cwe]   carrier:          GENERIC
[27 Jun 2019, 12:22:32] [Debug] [qfu-sahara-device] opening TTY: /dev/ttyUSB0
[27 Jun 2019, 12:22:32] [Debug] [qfu-sahara-device] setting terminal in raw mode...
[27 Jun 2019, 12:22:32] [Debug] [qfu-sahara-device] waiting time for device to boot properly...
[27 Jun 2019, 12:22:34] [Debug] [qfu-sahara-device] initializing sahara protocol...
[27 Jun 2019, 12:22:37] [Debug] [qfu-updater] sahara device creation failed: no sahara response received
[27 Jun 2019, 12:22:37] [Debug] [qfu-qdl-device] opening TTY: /dev/ttyUSB0
[27 Jun 2019, 12:22:37] [Debug] [qfu-qdl-device] setting terminal in raw mode...
[27 Jun 2019, 12:22:37] [Debug] [qfu,dload-message] sent sdp:
[27 Jun 2019, 12:22:37] [Debug] [qfu-qdl-device] >> 70:00:00 [3, unframed]
[27 Jun 2019, 12:22:37] [Debug] [qfu-qdl-device] >> 7E:70:00:00:14:46:7E [7]
[27 Jun 2019, 12:22:37] [Debug] [qfu-qdl-device] << 13:70:00:00:6A:9A:7E [7]
[27 Jun 2019, 12:22:37] [Debug] [qfu-qdl-device] << 13:70:00:00 [4, unframed]
[27 Jun 2019, 12:22:37] [Debug] [qfu-updater] qdl device creation failed: unexpected response received in 
dload sdp: 0x13
error: unsupported download protocol



root@OpenWrt:~# qmicli -d /dev/cdc-wdm0 --dms-swi-get-current-firmware
[/dev/cdc-wdm0] Successfully retrieved current firmware:
        Model: EM7565
        Boot version: SWI9X50C_01.07.02.00
        AMSS version: SWI9X50C_01.07.02.00
        SKU ID: 1103520
        Package ID: unknown
        Carrier ID: 1
       Config version: 002.004_000
root@OpenWrt:~# qmicli -d /dev/cdc-wdm0 --dms-get-firmware-preference
firmware preference successfully retrieved:
[image 0]
        Image type: 'modem'
        Unique ID:  '002.019_000'
        Build ID:   '01.09.04.00_GENERIC'
[image 1]
        Image type: 'pri'
        Unique ID:  '002.019_000'
        Build ID:   '01.09.04.00_GENERIC'
root@OpenWrt:~# qmicli -d /dev/cdc-wdm0 --dms-list-stored-images
[/dev/cdc-wdm0] Device list of stored images retrieved:

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

                [modem0]
                Unique ID:     '?_?'
                Build ID:      '01.07.02.00_?'
                Storage index: '1'
                Failure count: '0'
        [1] Type:    'pri'
            Maximum: '50'
                [pri0]
                Unique ID:     '002.004_000'
                Build ID:      '01.07.02.00_GENERIC'
root@OpenWrt:~#

@LateParrot when you run qmi-firmware-update -t /dev/ttUSB0, is the modem in “download mode”? does it have only one ttyUSB0 exposed, or does it expose more than one TTY and also the cdc-wdm port? This is key to understand, because you may be trying to run qmi-firmware-update on the wrong place.

The “manual” update procedure in openwrt involves 3 steps:

  • First, you set the firmware preference to the one you want to flash, you did that right.
  • Then, we trigger a reboot with --dms-set-operating-mode=offline and --dms-set-operating-mode=reset. Wait for the module to reset itself, and see how it exposes 1 single ttyUSB0.
  • Only then, when the module is exposing a ttyUSB0, is when you should run qmi-firmware-update.

Unfortunately this process is a bit hacky in openwrt because we don’t have udev… In a normal Linux system with udev, all this is automagically handled by qmi-firmware-update --update (instead of --update-download).

@LateParrot to recover from the “low-power stuck”, try to set firmware preference on the firmware you already have installed:

# qmicli -d /dev/cdc-wdm0 --dms-set-firmware-preference="01.07.02.00,002.004_000,GENERIC"
# qmicli -d /dev/cdc-wdm0 --dms-set-operating-mode=offline
# qmicli -d /dev/cdc-wdm0 --dms-set-operating-mode=reset
root@OpenWrt:~# qmicli -d /dev/cdc-wdm0 -p --dms-set-firmware-reference="01.09.04.00,002.019_000,GENERIC"
[/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

        After reset, the modem will wait in QDL mode for new firmware.
        Images to download: 'modem, pri'

root@OpenWrt:~# qmicli -d /dev/cdc-wdm0 -p --dms-set-operating-mode=offline
[/dev/cdc-wdm0] Operating mode set successfully
root@OpenWrt:~# qmicli -d /dev/cdc-wdm0 -p --dms-set-operating-mode=reset
[/dev/cdc-wdm0] Operating mode set successfully
root@OpenWrt:~# /etc/init.d/modemmanager stop
root@OpenWrt:~# qmicli -d /dev/cdc-wdm0 -p --dms-get-operating-mode
error: couldn't create QmiDevice: Couldn't query file info: Error when getting information for file “/dev/cdc-wdm0”: No such file or directory
root@OpenWrt:~# qmi-firmware-update -t /dev/ttyUSB0 -U /tmp/fw/SWI9X50C_01.09.04.00.cwe /tmp/fw/SWI9X50C_01.09.04.00_GENERIC_002.019_000.nvu
error: unsupported download protocol
root@OpenWrt:~# qmi-firmware-update -t /dev/ttyUSB0 -U /tmp/fw/SWI9X50C_01.09.04.00.cwe /tmp/fw/SWI9X50C_01.09.04.00_GENERIC_002.019_000.nvu -v
[27 Jun 2019, 13:23:21] [Debug] [qfu-utils] couldn't ping ModemManager: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.ModemManager1" does not exist
[27 Jun 2019, 13:23:21] [Debug] [qfu-image] loading file info...
[27 Jun 2019, 13:23:21] [Debug] [qfu-image] opening file for reading...
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe] reading image headers...
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe] image offset range: [0,79664946]
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]   image offset range: [400,7360]
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe] image at offset 400 is valid
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]   image offset range: [7360,407216]
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]     image offset range: [7760,14640]
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]   image at offset 7760 is valid
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]     image offset range: [14640,407216]
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]   image at offset 14640 is valid
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe] image at offset 7360 is valid
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]   image offset range: [407216,39478680]
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]     image offset range: [407616,414576]
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]   image at offset 407616 is valid
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]     image offset range: [414576,871292]
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]   image at offset 414576 is valid
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]     image offset range: [871292,1038880]
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]   image at offset 871292 is valid
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]     image offset range: [1038880,39478680]
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]   image at offset 1038880 is valid
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe] image at offset 407216 is valid
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]   image offset range: [39478680,79664946]
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]     image offset range: [39479080,39486040]
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]   image at offset 39479080 is valid
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]     image offset range: [39486040,39937028]
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]   image at offset 39486040 is valid
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]     image offset range: [39937028,72274126]
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]   image at offset 39937028 is valid
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]     image offset range: [72274126,79664946]
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]   image at offset 72274126 is valid
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe] image at offset 39478680 is valid
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe] validating data size...
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe] preloading firmware/config/carrier...
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]   firmware version: 01.09.04.00
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]   config version:   unknown
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]   carrier:          unknown
[27 Jun 2019, 13:23:21] [Debug] [qfu-image] loading file info...
[27 Jun 2019, 13:23:21] [Debug] [qfu-image] opening file for reading...
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe] reading image headers...
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe] image offset range: [0,10081]
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]   image offset range: [400,7680]
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]     image offset range: [800,7680]
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]   image at offset 800 is valid
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe] image at offset 400 is valid
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]   image offset range: [7680,10081]
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]     image offset range: [8080,10081]
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]   image at offset 8080 is valid
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe] image at offset 7680 is valid
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe] validating data size...
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe] preloading firmware/config/carrier...
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]   firmware version: 01.09.04.00
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]   config version:   002.019_000
[27 Jun 2019, 13:23:21] [Debug] [qfu-image-cwe]   carrier:          GENERIC
[27 Jun 2019, 13:23:21] [Debug] [qfu-sahara-device] opening TTY: /dev/ttyUSB0
[27 Jun 2019, 13:23:21] [Debug] [qfu-sahara-device] setting terminal in raw mode...
[27 Jun 2019, 13:23:21] [Debug] [qfu-sahara-device] waiting time for device to boot properly...
[27 Jun 2019, 13:23:23] [Debug] [qfu-sahara-device] initializing sahara protocol...
[27 Jun 2019, 13:23:26] [Debug] [qfu-updater] sahara device creation failed: no sahara response received
[27 Jun 2019, 13:23:26] [Debug] [qfu-qdl-device] opening TTY: /dev/ttyUSB0
[27 Jun 2019, 13:23:26] [Debug] [qfu-qdl-device] setting terminal in raw mode...
[27 Jun 2019, 13:23:26] [Debug] [qfu,dload-message] sent sdp:
[27 Jun 2019, 13:23:26] [Debug] [qfu-qdl-device] >> 70:00:00 [3, unframed]
[27 Jun 2019, 13:23:26] [Debug] [qfu-qdl-device] >> 7E:70:00:00:14:46:7E [7]
[27 Jun 2019, 13:23:26] [Debug] [qfu-qdl-device] << 01:00:00:00:30:00:00:00:02:00:00:00:01:00:00:00:00:04:00:00:02:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 [48]
[27 Jun 2019, 13:23:26] [Debug] [qfu-updater] qdl device creation failed: HDLC trailing control character not found
error: unsupported download protocol

I actually did try resetting the firmware preference then resetting the modem the first time I tried after updating libqmi, saw your reply before work and hastily printed it again. Setting the firmware preference to the installed version and resetting the modem was the very first thing I tried after I realized power-cycling wasn’t going to fix the issue. -set-firmware-preference still wanted to update the pri.

As of now I’ve flashed it via a usb to m.2 adapter on a windows machine and it’s working again. I very much appreciate your help, as I would have preferred not to remove the modem from the router and I wonder whether it was me or libqmi’s issue.
I’d eventually like to solve the problem as this functionality(along with many things available only in Goldenorb and other forks) needs to be accessible via luci in the main openwrt releases. I’m intending on getting in touch with Nick and seeing what his plans were and where I can start.

This is key to understand, because you may be trying to run qmi-firmware-update on the wrong place.

This is what I am expecting to be the problem, 9/10 times computer issues are a lack of understanding. Is there a good place I can read up on how these modems work and the ways to communicate with them?

hey @LateParrot the debug logs is good, but I’m afraid it doesn’t tell much :smiley: Your log shows how when you open the ttyUSB0, there is no data received in the program, and that’s a problem. The way the protocol detection works in qmi-firmware-update is quite simple, it just opens the TTY and waits for the “hello request” sent by the modem, there is no data sent by the program beforehand, it just waits for the modem to speak first (this is done on purpose, if anything is sent to the ttyUSB0 before the hello request, the process will fail later on).

I’m still thinking that your issue could be a problem on the ttyUSB you’re using to run qmi-firmware-update, I have two theories:

  • You run qmi-firmware-update very quickly after running qmicli --dms-set-operating-mode=reset, and so you’re not waiting for the module to reboot itself ( it may take 5s-10s for that to happen). The way to make sure this is not the case is to monitor the kernel events e.g. with “dmesg” and make sure the module goes away and then it comes back again. Only when it has come back again, you should run qmi-firmware-update -U.
  • The second theory, if the previous one is no the culprit, is that you may have some other device in the system exposing a ttyUSB, and so the port to use may not be ttyUSB0 but ttyUSB1 or some other thing. Again, monitoring dmesg could help here, and once the module has rebooted in single-tty mode, you would check e.g. which is the ttyUSB with the biggest number.

I acknowledge that all this is prone to error, but again this only happens in openwrt because it doesn’t have udev. In a normal system with udev you don’t need to do all these manual steps, just running --update with the files to update and everything is automagically done, even device detection. There may be a way to improve this in openwrt, e.g. by doing some busy wait to look for the device coming back, e.g. checking every 5s for it to be exposed. That is probably a better thing than requiring all the manual steps done by the user, truth be told.

I’ve opened a new Issue in fd.o gitlab to track this enhancement qmi-firmware-update: when udev not used, loop waiting for the device reboot (#18) · Issues · Mobile broadband connectivity / libqmi · GitLab

@aleksander0m I figured it was fairly useless, just trying to show you I was actually running those commands. I definitely waited long enough, five minutes on my second go. Don’t know why I didn’t think to check dmesg though. Couldn’t see the forest for the trees I suppose. I have to spend to much time in windows, due to a lack of effective linux CNC/CAM software.

I don’t know why it would have been anywhere other than ttyUSB0. Only had the power and the ethernet cables plugged to it, and the only other package I selected in menuconfig besides luci and modemmanager was luci-proto-qmi(having problems building the latest proto-modemmanager). But I’m still new to openwrt and these cellular modems and I don’t really know what all communicates over the ttyUSB interfaces, nor have I ever seen them populated by anything other than the modem or a tethered cell phone.

Speculation is useless so I’ll take another shot at it this weekend. Can I just attempt to downgrade in a similar fashion? I’d use the last At&t release.

Hello @LateParrot I would like to update the EM7565 under OpenWRT too, did you finally find a way to properly accomplish it?

@hadrien.toma what issues are you having? I’ve done myself lately a couple of upgrades without issues.

Hello @aleksander0m , for the moment I am searching for information on how to do it in the rules of art, may you point me to the correct procedure?

I first need to update the EM7565 then to make a bridge between it and a Wi-Fi modem (in case you have documentation for this configuration too).

I documented my last EM7565 update on OpenWrt here:
https://lists.freedesktop.org/archives/libqmi-devel/2019-November/003166.html

Ignore the first part with the debug output. Look for the prompts (root at wrt1900ac-1) to find the 3 necessary commands. File names, versions and device names must be changed of course.

Note in particular that my QDL device is ttyUSB4 because I have 4 other USB serial ports. Yours will probably be ttyUSB0, but this must be verified by eg looking at dmesg after resetting the modem.

1 Like

Also, run qmi-firmware-update --help-examples to get several examples of how to upgrade the device. The example that applies to the EM7565 should be equivalent to the MC7354 one.

1 Like

Thank you very much to both of you :slight_smile: ! I will check this out and come back here to share feedbacks.