firmware update
David McCullough
david.mccullough at accelerated.com
Wed Dec 23 03:57:50 PST 2015
dailijin wrote the following:
> Hi David,
>
>
> Thanks your steps.
>
>
> I have tested your suggested driver from S2.23N2.30 , and use the newest SDK SLQS03.03.12, the result still fail and report same kernel error.
> This is very strange, seems only my system always fail for modem firmware update. As for the kernel error, I guess it caused by CONFIG_PREEMPT is not enable, so could you check kernel option whether CONFIG_PREEMPT is enable on your system? below info is captured from my system:
>
>
> tvupack tvu # cat /boot/config-3.8.0-23-generic | grep PREEMPT
> # CONFIG_PREEMPT_RCU is not set
> CONFIG_PREEMPT_NOTIFIERS=y
> # CONFIG_PREEMPT_NONE is not set
> CONFIG_PREEMPT_VOLUNTARY=y
> # CONFIG_PREEMPT is not set
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
So probably not the problem,
Cheers,
Davidm
> At 2015-12-23 12:26:58, "David McCullough" <david.mccullough at accelerated.com> wrote:
> >
> >
> >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
--
David McCullough, david.mccullough at accelerated.com, Ph: 0410 560 763
More information about the libqmi-devel
mailing list