qmi-firmware-update mc7455

[Nathaniel Haggard]

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 <aleksander at aleksander.es
> wrote:

> On Thu, Sep 7, 2017 at 10:13 PM, Nathaniel Haggard <natester at gmail.com>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20170911/cc6fd611/attachment-0001.html>