<div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial"><div>Hi Bjorn,</div><div><br></div><div>Thanks your response.</div><div><br></div><div>I tried to load GobiSerial.ko, and sent ATI command to the ttyUSB device, no responds was printed on terminal. seemed  there was some error in the GobiSerial driver, I attached it.</div><div><br></div><div>I also captured the usbmon log via tcpdump during updating firmware, the attachment usbmon log begin when start updating firmware, end when the error happen. expect it is useful.</div><div><br></div><div>I am glad to hear that we can upgrade modem firmware via qmi_wwan driver, not Gobi driver, could you send the detail steps to me and let me try it?</div><div><br></div><div>Thanks very much</div><div><br></div><br><div style="position:relative;zoom:1">--<br><div>
<div style="FONT-SIZE: 14px">
<div align="left"><strong><font color="#0000ff"><em>Best Regards,</em></font></strong></div>
<div><strong><font color="#0000ff"><em>Dai,Lijin</em></font></strong></div></div></div><div style="clear:both"></div></div><div id="divNeteaseMailCard"></div><br><pre><br>At 2015-12-18 19:36:25, "Bjørn Mork" <bjorn@mork.no> wrote:
>dailijin  <dailijin126@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
>_______________________________________________
>libqmi-devel mailing list
>libqmi-devel@lists.freedesktop.org
>http://lists.freedesktop.org/mailman/listinfo/libqmi-devel
</pre></div><br><br><span title="neteasefooter"><p> </p></span>