ZTE MF683

[Shawn J. Goff]

On Tue, Sep 18, 2012 at 3:43 AM, Bjørn Mork <bjorn at mork.no> wrote:
> "Shawn J. Goff" <shawn7400 at gmail.com> writes:
>
>> So far, my dev system doesn't like 3.6. I have been backporting
>> qmi-wwan and cdc-wdm to 2.6.39. As of the 7th, I had everything, so I
>> think the only commit I'm missing right now is "USB: cdc-wdm: fix
>> wdm_find_device* return value". The source is here if you're
>> interested: https://bitbucket.org/accelecon/linux-at91/changesets.
>
> That is definitely interesting!  Especially if you can get it to work
> :-)  Thanks for doing that.

Actually, it is already working. I've tested with with the Pantech 290
and the Huawei UMG366. We also have made a libqmi package for
Buildroot, although I'm having trouble compiling it - I have to
significantly modify some Makefiles to make it build - I suspect I'm
just not configuring it right; I'll post another thread with those
issues when I get a chance.

>> Here are some printk messages that come out when I manually bind the
>> driver in that kernel:
>>
>> [  597.925000] qmi_wwan: probe of 1-2:1.0 failed with error -22
>> [  597.932500] qmi_wwan: probe of 1-2:1.1 failed with error -22
>> [  597.937500] qmi_wwan: probe of 1-2:1.2 failed with error -22
>> [  597.945000] qmi_wwan: probe of 1-2:1.3 failed with error -22
>
>
> Yes, those 4 interfaces have no interrupt endpoint so they can be ruled
> out.  Most likely serial ports all of them, where some are special
> purpose ports like GPS NMEA, QCDM or other serial protocols.
>
>
>> [  597.955000] qmi_wwan 1-2:1.4: cdc-wdm0: USB WDM device
>> [  597.955000] qmi_wwan 1-2:1.4: wwan0: register 'qmi_wwan' at
>> usb-atmel-ehci-2, WWAN/QMI device, 82:28:8e:37:92:dc
>> [  597.960000] qmi_wwan 1-2:1.5: cdc-wdm1: USB WDM device
>> [  597.960000] qmi_wwan 1-2:1.5: wwan1: register 'qmi_wwan' at
>> usb-atmel-ehci-2, WWAN/QMI device, 82:28:8e:37:92:dc
>
> OK, those are the two only likely candidates having an interrupt in and
> bulk in + out endpoints.
>
>> [  597.960000] qmi_wwan: probe of 1-2:1.6 failed with error -22
>
> And the last interface is mass storage, so that is OK.
>
>>
>> As you can see, it created two pairs of devices. I tried
>> --nas-get-signal-strength on both wdm devices:
>>
>> # qmicli --nas-get-signal-strength -d /dev/cdc-wdm0
>> [  657.477500] qmi_wwan 1-2:1.4: unknown notification 32 received: index 4 len 2
>> ###[Nothing for a long time, I sent SIGINT]
>> cancelling the operation...
>> error: couldn't create client for the 'nas' serv[  668.177500]
>> qmi_wwan 1-2:1.4: Error in flush path: -32
>> ice: CID allocation failed in the CTL client: Transaction timed out
>
> I suspect interface #4 is really a serial port.  Can you do AT commands
> on it if you use the option driver instead?
>

There is definitely a serial port - we currently use the modem with
the option driver and PPP.

>
>> # qmicli --nas-get-signal-strength -d /dev/cdc-wdm1
>> **
>> ERROR:qmi-utils.c:72:qmi_utils_read_guint8_from_buffer: assertion
>> failed: (*buffer_size >= 1)
>> Aborted
>
>
> This is odd, but interesting.  I have no clue why you got that result,
> but the fact that it didn't just time out probably means that you got
> some response.  It doesn't necessarily mean that it is QMI though...

I may not have waited long enough. I'll try again today.

>
> Are you able to do usb snooping on this device, using usbmon? Unless
> something went wrong during the backport, I am wondering if this
> interface does support CDC embedded commands, but embedding something
> that is not QMI.
>

I can try this; I don't know if the tcpdump I have has usbmon support.
I do have a hardware sniffer and will use that if I can use usbmon.

> BTW, is this a big endian platform (sorry for my complete ignorance wrt
> Atmel chips...)?
>

It's an ARM 926ej-s chip, so it's either-endian. We're using it in the
little-endian mode.