Yes that's correct, no udev because of LEDE, but I'm in favor of way way way simpler and less error prone.
After setting the preferences like help recommends, I was able to switch to verizon once, and failed all the other times with "error: error creating device: unexpected response received in dload sdp: 0x70" This is what I'm doing: qmicli -p -d /dev/cdc-wdm0 --dms-set-firmware-preference="02.24.05.06,002.034_000,VERIZON" qmicli -p -d /dev/cdc-wdm0 --dms-set-operating-mode=offline qmicli -p -d /dev/cdc-wdm0 --dms-set-operating-mode=reset read -p "when /dev/ttyUSB0 is available press enter" /etc/init.d/modemmanager stop qmi-firmware-update -t /dev/ttyUSB0 --update-qdl SWI9X30C_02.24.05.06.cwe SWI9X30C_02.24.05.06_VERIZON_002.034_000.nvu To make it automatic maybe I should poll dmesg, unless there is a better way. On Fri, Sep 8, 2017 at 1:55 AM, Aleksander Morgado <[email protected] > wrote: > On Thu, Sep 7, 2017 at 10:13 PM, Nathaniel Haggard <[email protected]> > wrote: > > I'm trying to update the mc7455 to verizon firmware, but I get the > following > > error: > > > > ~# qmicli -d /dev/cdc-wdm0 --dms-set-operating-mode=offline > > [/dev/cdc-wdm0] Operating mode set successfully > > ~# qmicli -d /dev/cdc-wdm0 --dms-set-operating-mode=reset > > [/dev/cdc-wdm0] Operating mode set successfully > > :~# qmi-firmware-update -t /dev/ttyUSB0 --update-qdl > > SWI9X30C_02.24.05.06.cwe SWI9X30C_02.24.05.06_VERIZON_002.034_000.nvu > > > > error: error creating device: unexpected response received in dload sdp: > > 0x70 > > > > /dev/ttyUSB0 does exist of course. > > The offline+reset+update-qdl sequence isn't correct, you need a > --dms-set-firmware-preference command before. The offline/reset > sequence alone will reboot the modem, but will not put it in > boot-and-hold mode to wait for firmware. You're probably sending the > QDL commands to a TTY that isn't capable of using that protocol. > > I assume you cannot use the much simpler --update command for some > reason? That takes care of selecting the firmware to download (DMS Set > Firmware Preference) and also waits for the reboot to happen before > sending the files via the TTY. (way way way simpler and less > error-prone) The only reason why you wouldn't use --update is because > libqmi was compiled without udev support (e.g. if system doesn't have > udev like openwrt), and then you need the "manual" procedure to update > the firmware. Quoting the --help-examples output in > qmi-firmware-update: > > ************************************************************ > ******************** > > Example: Manual process to update a Sierra Wireless MC7354. > (or other 9x15 or 9x30 devices, like the MC7304, MC7330, MC7455... ). > > The upgrade of devices from the 9x15 and 9x30 families is triggered via a > 'firmware preference' setting. If the device accepts the setting, the user > can request a device power cycle, which will boot in QDL download mode: > > a) Set firmware preference setting: > $ sudo qmicli \ > -d /dev/cdc-wdm0 \ > --dms-set-firmware-preference="05.05.58.00,005.025_002,Generic" > > b) Request power cycle: > $ sudo qmicli \ > -d /dev/cdc-wdm0 \ > --dms-set-operating-mode=offline > $ sudo qmicli \ > -d /dev/cdc-wdm0 \ > --dms-set-operating-mode=reset > > c) Wait for the /dev/ttyUSB device to appear. > > d) Run updater operation while in QDL download mode: > $ sudo qmi-firmware-update \ > -t /dev/ttyUSB0 \ > --update-qdl \ > SWI9X15C_05.05.58.00.cwe \ > SWI9X15C_05.05.58.00_Generic_005.025_002.nvu > > d) Now wait for the device to fully reboot, may take up to several > minutes. > > > -- > Aleksander > https://aleksander.es >
_______________________________________________ ModemManager-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
