firmware update
David McCullough
david.mccullough at accelerated.com
Tue Dec 22 20:26:58 PST 2015
dailijin wrote the following:
> Hi Bjorn,
>
> I just tried to update firmware for MC7304 with S2.25N2.35 and SDK SLQS03.03.12, still fail and system report same kernel error log as below:
I have been sort of following so I thought is was time I put up some info
in case it helps.
We are programming 7304/7354 modems with using the following versions:
GobiSerial: 2015-03-09/SWI_2.23
GobiNet: 2015-03-09/SWI_2.30
The sources were obtained from:
SierraLinuxQMIdriversS2.23N2.30.tar.bz2
No changes were used.
The SDK we are using is:
SLQS03.03.06.bin.tar.gz
I have programmed hundreds on modems with this combination, but, it took
a while to find a process that gave a good rate of success. We use the 2
file process to save on space (common files) so I am not sure iof
into smaller chu
1. black list linux drivers and unload them
2. load the Gobi* drivers
3. reset the modem[*]
wait for it to return
4. start/restart slqssdk
5. load the NVU image is noit already done with
mc7xxximgtool -n <firmware-dir>
on failure goto 3
6. load CWE is not already loaded with
mc7xxximgtool -f <firmware-dir>
on failure goto 3
7. dump settings with
mc7xxximgtool -i
[*] send 'at!greset' on command tty (ttyUSB2 on our single modem systems)
if that does not return OK, do a 'usbreset /dev/bus/usb...'
I rarely if ever make it through a full program without a reset of some
kind, and thats not including the reset done by the programming process.
Seems clunky I know but with the number of HW restarts and drivers swapping
I found things tended to get mixed up or confused fairly regularly.
Hope this helps somehow ;-)
Cheers,
Davidm
>
> Dec 23 03:45:09 tvupack kernel: INFO: task slqssdk:1555 blocked for more than 120 seconds.
> Dec 23 03:45:09 tvupack kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> Dec 23 03:45:09 tvupack kernel: slqssdk D 0000000000000000 0 1555 1390 0x00000000
> Dec 23 03:45:09 tvupack kernel: ffff8801065ab958 0000000000000086 ffff8801065ab978 ffff8801190eb1a0
> Dec 23 03:45:09 tvupack kernel: ffff8801065abfd8 ffff8801065abfd8 ffff8801065abfd8 0000000000013f40
> Dec 23 03:45:09 tvupack kernel: ffff880119b50000 ffff8801067d9740 ffff8801067d9740 ffff88010fe05968
> Dec 23 03:45:09 tvupack kernel: Call Trace:
> Dec 23 03:45:09 tvupack kernel: [<ffffffff816e0669>] schedule+0x29/0x70
> Dec 23 03:45:09 tvupack kernel: [<ffffffff816e091e>] schedule_preempt_disabled+0xe/0x10
> Dec 23 03:45:09 tvupack kernel: [<ffffffff816df597>] __mutex_lock_slowpath+0xd7/0x150
> Dec 23 03:45:09 tvupack kernel: [<ffffffff8151084e>] ? usb_alloc_urb+0x1e/0x50
> Dec 23 03:45:09 tvupack kernel: [<ffffffff816df1aa>] mutex_lock+0x2a/0x50
> Dec 23 03:45:09 tvupack kernel: [<ffffffffa029e10c>] Gobi_dtr_rts+0x6c/0x130 [GobiSerial]
> Dec 23 03:45:09 tvupack kernel: [<ffffffffa03b2725>] ? usb_serial_generic_submit_read_urb+0x25/0x30 [usbserial]
> Dec 23 03:45:09 tvupack kernel: [<ffffffffa03b058f>] serial_dtr_rts+0x7f/0x90 [usbserial]
> Dec 23 03:45:09 tvupack kernel: [<ffffffff81429044>] tty_port_block_til_ready+0x174/0x320
> Dec 23 03:45:09 tvupack kernel: [<ffffffff8107fc10>] ? add_wait_queue+0x60/0x60
> Dec 23 03:45:09 tvupack kernel: [<ffffffffa03b04f2>] ? serial_activate+0x82/0xa0 [usbserial]
> Dec 23 03:45:09 tvupack kernel: [<ffffffff814293eb>] tty_port_open+0xbb/0xe0
> Dec 23 03:45:09 tvupack kernel: [<ffffffff816e159e>] ? _raw_spin_lock+0xe/0x20
> Dec 23 03:45:09 tvupack kernel: [<ffffffffa03b0ad2>] serial_open+0x22/0x30 [usbserial]
> Dec 23 03:45:09 tvupack kernel: [<ffffffff81420fb2>] tty_open+0x172/0x420
> Dec 23 03:45:09 tvupack kernel: [<ffffffff8146848b>] ? kobj_lookup+0x10b/0x170
> Dec 23 03:45:09 tvupack kernel: [<ffffffff8119ff52>] chrdev_open+0xb2/0x1a0
> Dec 23 03:45:09 tvupack kernel: [<ffffffff8119fea0>] ? cdev_put+0x30/0x30
> Dec 23 03:45:09 tvupack kernel: [<ffffffff8119954e>] do_dentry_open+0x21e/0x2a0
> Dec 23 03:45:09 tvupack kernel: [<ffffffff811999c9>] vfs_open+0x49/0x50
> Dec 23 03:45:09 tvupack kernel: [<ffffffff811a7e06>] do_last+0x246/0x820
> Dec 23 03:45:09 tvupack kernel: [<ffffffff8131337c>] ? apparmor_file_alloc_security+0x2c/0x60
> Dec 23 03:45:09 tvupack kernel: [<ffffffff811aa333>] path_openat+0xb3/0x4d0
> Dec 23 03:45:09 tvupack kernel: [<ffffffff811aa776>] ? final_putname+0x26/0x50
> Dec 23 03:45:09 tvupack kernel: [<ffffffff811aa9b9>] ? putname+0x29/0x40
> Dec 23 03:45:09 tvupack kernel: [<ffffffff811ab152>] do_filp_open+0x42/0xa0
> Dec 23 03:45:09 tvupack kernel: [<ffffffff811b8dd5>] ? __alloc_fd+0xe5/0x170
> Dec 23 03:45:09 tvupack kernel: [<ffffffff8119adaa>] do_sys_open+0xfa/0x250
> Dec 23 03:45:09 tvupack kernel: [<ffffffff8119af21>] sys_open+0x21/0x30
> Dec 23 03:45:09 tvupack kernel: [<ffffffff816ea41d>] system_call_fastpath+0x1a/0x1f
>
>
>
>
> About error related with schedule_preempt_disabled, it seems to related to kernel option after review some website. my kernel option is "CONFIG_PREEMPT_VOLUNTARY=y", but CONFIG_PREEMPT is not set, should I set CONFIG_PREEMPT=y?
>
>
> I can confirm this issue don't appear when use the old GobiSerial(NTGR_2.12), but always happen when use Sierra official GobiSerial driver likes S2.25N2.35, S2.24N2.33, I guess the issue related to
> that DTR is on in new Sierra driver, but not sure very much.
>
>
> If anyone also have encountered this error, please give me some suggestions?
>
> Thanks
>
>
>
> --
>
> Best Regards,
> Dai,Lijin
>
> 在 2015-12-23 10:17:21，"dailijin" <dailijin126 at 126.com> 写道：
>
> Hi Bjron,
>
>
> I have added the patch into my qmi_wwan driver, and now I can get QMI response now, and also do QMI connection successfully via command "qmi-network /dev/cdc-wdm14 start",
> but can not fetch IP via dhclient now. I check the data format which is 'raw-ip', this maybe why I can't get IP. because I remember MC7304 and MC7354 can work before only after I set '802-3' as data format for them. right?
>
>
> NOTE:
>
>
> I have upgrade my libqmi from 1.10.2 to 1.12.6.
>
>
> Thanks
>
>
>
>
> --
>
> Best Regards,
> Dai,Lijin
>
>
>
> At 2015-12-22 17:58:37, "Bjørn Mork" <bjorn at mork.no> wrote:
> >dailijin <dailijin126 at 126.com> writes:
> >
> >> Hi All,
> >>
> >>
> >> yes, you are right. I think the issue should be caused by the
> >> GobiSerial driver.
> >>
> >>
> >> if I use the the driver GobiSerial from Sierra S2.24N2.33, the issue
> >> will happen. if use the old GobiSerial driver(NTGR_2.12), seems no
> >> issue appear, Sorry to send incorrect driver source code, I should
> >> send the source code from S2.24N2.33.
> >>
> >>
> >> I know the driver GobiSerial which I am using is not from Sierra, and
> >> the newest Sierra driver package should be S2.25N2.35, I want to test
> >> it, could you send the source codes to me?
> >
> >Sure, it's dual GPL/BSD licensed so that should not be a problem. I'll
> >send it in a private mail. The source is also downloadable from
> >Sierra's "source" website.
> >
> >> Another thing is that I am testing MC7430 modem via libqmi 1.10.2,
> >> always can't successfully get QMI response from the modem, I think
> >> maybe the libqmi version is old, should I upgrade libqmi version for
> >> the modem?
> >
> >Ah, right. I don't know if there are any relevant libqmi changes yet,
> >but 1.10.2 is very old and MC7430 is very new. That's not a good
> >combination in general ;)
> >
> >The MC74xx modems have some new flow control restrictions which I am
> >still trying to figure out. That's what this is an attempt to solve:
> >
> > https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/drivers/net/usb/qmi_wwan.c?id=93725149794d3d418cf1eddcae60c7b536c5faa1
> >
> >The info comes from the newest Sierra GobiNet drivers. And testing on
> >MC7455 showed that the QMI channel will not respond until DTR is on.
> >Previously we did not care about DTR at all. But it appears to have a
> >meaning to earlier firmwares too: A DTR off/on sequence has about the
> >same effect as sending QMI_CTL SYNC. Which means that we cannot do DTR
> >on/off in the driver based on /dev/cdc-wdmX open/close, since a QMI
> >session can be active even if the device is closed.
> >
> >Then the latest Sierra GobiNet driver (N2.35) added another interesting
> >part:
> >
> > MODULE_PARM_DESC( iTEEnable, "Enable/Disable TE Flow Control" );
> >
> >which controls TLV 0x1a of the driver WDS Set Data Format request. But
> >I don't know what that does to the firmware. I tested it on an EM7305
> >and an MC7455, but could not figure out what it is supposed to change.
> >Both modems accept the TLV without changing the reply. The MC7455
> >always returns TLV 0x1a = 0x00000000, and the EM7305 doesn't return any
> >0x1a TLV (but still accepts it as input).
> >
> >Writing too much again :) You may not need the latest libqmi, but you
> >definitely need the latest drivers for MC74xx modems.
> >
> >
> >
> >Bjørn
> >_______________________________________________
> >libqmi-devel mailing list
> >libqmi-devel at lists.freedesktop.org
> >http://lists.freedesktop.org/mailman/listinfo/libqmi-devel
>
>
>
>
>
>
--
David McCullough, david.mccullough at accelerated.com, Ph: 0410 560 763
More information about the libqmi-devel
mailing list