firmware update

[Bjørn Mork]

dailijin  <dailijin126 at 126.com> writes:

> Dec 18 02:31:54 tvupack slqssdk[6499]: SWI0 SDK Process: QM:qmqmireq/1529: WDS Request: Active Client 1, WDS Client 0
> Dec 18 02:31:54 tvupack slqssdk[6499]: SWI0 SDK Process: USB read: bytes2read = 14, read 14 bytes
> Dec 18 02:31:54 tvupack slqssdk[6499]: SWI0 SDK Process: QM:SDK<-Mdm Resp: ch/Msgid/Msglen/client: 0/002e/11/1
> Dec 18 02:31:54 tvupack slqssdk[6499]: SWI0 SDK Process: QM:qmqmireq/1416: Request: QMI Instance 0
> Dec 18 02:31:54 tvupack slqssdk[6499]: SWI0 SDK Process: QM:SDK->Mdm: request received : ipcch/svctype/xactionlen/clientnum: 0/0002/8/1
> Dec 18 02:31:54 tvupack slqssdk[6499]: SWI0 SDK Process: QM:SDK->Mdm: request validated : ipcch/svctype/xactionlen/clientnum: 0/0002/8/1
> Dec 18 02:31:54 tvupack slqssdk[6499]: SWI0 SDK Process: QM:qmqmireq/1529: WDS Request: Active Client 1, WDS Client 0
> Dec 18 02:31:54 tvupack slqssdk[6499]: SWI0 SDK Process: USB read: bytes2read = 14, read 14 bytes
> Dec 18 02:31:54 tvupack slqssdk[6499]: SWI0 SDK Process: QM:SDK<-Mdm Resp: ch/Msgid/Msglen/client: 0/002e/11/1

So there we see the final 0x003e QMI_DMS request causing the modem to
boot into QDL mode.


> Dec 18 02:32:02 tvupack kernel: usb 1-1.6.3: USB disconnect, device number 10
> Dec 18 02:32:02 tvupack slqssdk[6499]: SWI0 SDK Process: ttyUSB1 device on USB Interface 0 not found
> Dec 18 02:32:02 tvupack slqssdk[6499]: SWI0 SDK Process: ttyUSB1 device on USB Interface 0 not found
> Dec 18 02:32:02 tvupack slqssdk[6499]: SWI0 SDK Process: swi_ossdkusbscan/1425: 2 tty interfaces successfully scanned
> Dec 18 02:32:02 tvupack slqssdk[6499]: SWI0 SDK Process: swi_ossdkusbscan/1456: 4/6 interfaces successfully scanned
> Dec 18 02:32:53 tvupack ntpcheck.ntpd[872]: ntpcheck detected interface up 2: eth0    inet 10.12.32.2/18 brd 10.12.63.255 scope global eth0
> Dec 18 02:33:53 tvupack ntpcheck.ntpd[872]: ntpcheck detected interface up 2: eth0    inet 10.12.32.2/18 brd 10.12.63.255 scope global eth0
> Dec 18 02:34:32 tvupack kernel: INFO: task khubd:35 blocked for more than 120 seconds.
> Dec 18 02:34:32 tvupack kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> Dec 18 02:34:32 tvupack kernel: khubd           D 0000000000000000     0    35      2 0x00000000
> Dec 18 02:34:32 tvupack kernel:  ffff88011903da88 0000000000000046 ffff88011903da38 ffff88011903da38
> Dec 18 02:34:32 tvupack kernel:  ffff88011903dfd8 ffff88011903dfd8 ffff88011903dfd8 0000000000013f40
> Dec 18 02:34:32 tvupack kernel:  ffffffff81c15440 ffff8801197445c0 ffff880114339780 ffff88011746ad28
> Dec 18 02:34:32 tvupack kernel: Call Trace:
> Dec 18 02:34:32 tvupack kernel:  [<ffffffff816e0669>] schedule+0x29/0x70
> Dec 18 02:34:32 tvupack kernel:  [<ffffffff816e091e>] schedule_preempt_disabled+0xe/0x10
> Dec 18 02:34:32 tvupack kernel:  [<ffffffff816df597>] __mutex_lock_slowpath+0xd7/0x150
> Dec 18 02:34:32 tvupack kernel:  [<ffffffff81510a11>] ? usb_kill_urb+0x31/0x40
> Dec 18 02:34:32 tvupack kernel:  [<ffffffff816df1aa>] mutex_lock+0x2a/0x50
> Dec 18 02:34:32 tvupack kernel:  [<ffffffffa03be0a1>] usb_serial_disconnect+0x31/0x110 [usbserial]
> Dec 18 02:34:32 tvupack kernel:  [<ffffffff81514ea0>] usb_unbind_interface+0x60/0x1b0
> Dec 18 02:34:32 tvupack kernel:  [<ffffffff8146530c>] __device_release_driver+0x7c/0xe0
> Dec 18 02:34:32 tvupack kernel:  [<ffffffff8146539c>] device_release_driver+0x2c/0x40


But something goes wrong even before we get there?  Looks like the
serial driver (assuming GobiSerial at this point?) fails to handle the
modem suddenly disconnecting.  I have no idea why.  I cannot remember
seeing that on either qcserial or GobiSerial.

Do you have similar problems if you reset the modem in other ways,
e.g. by "AT!RESET"?

Note that the dots in the firmware tool doesn't tell shit.  You still
get those even if the tool never got any of its expected replies from
the modem.  I've found that the only real way to monitor the action is
snooping on the USB port, using usbmon.

BWT, I did some successful experiments uploading firmware to my EM7305
last night, using qcserial+qmi_wwan and a firmware tool I hacked
together based on the discussion here.  I can send you a copy if you
want to try it, but I doubt that it will make much difference.  And be
warned: It's still sketchy, has absolutely no image sanity checking, and
requires manual interaction with qmi_wwan (i.e. the tool won't send the
0x003e command for you - it expects a device already in QDL mode).
These are the reasons I don't want to send it to a public archived list
yet.  Hoping to make it a little more fool proof first.

At the same time I also verified that the firmware application receiving
this on the modem side is virtually unbreakable.  I made quite a few
attempts ;) Any failure to upload a complete and functional image is
resolved by booting into the previous image.  And the process times out
by itself if you don't finish the upload, so stopping half way through
will also result in the previous image being booted.

What I haven't tried, and do not intend to try, is uploading a valid
image for the wrong platform.  I suggest avoiding that.


Bjørn