Using RMNET3 on MC7710 in QMI mode

IoT Modules MC/EM Series
1

I noticed that there are two supported USB descriptor sets in QMI mode. The default set provides a single QMI interface, while the second provides RMNET1, RMNET2 and RMNET3. Is there any difference between a QMI interface and a RMNETx interface or is this just naming? I can get RMNET1 and RMNET2 working just fine using the same driver I use for QMI, but the RMNET3 interface does not respond to QMI commands. Any hints?

Bjørn

2

Hi,

RmNet interface is a new logical device in QMI framework for data services. RmNet defines channels for control and data transfers and it can be used in place of legacy USB modem interface.

3

Thanks, but the single “QMI” interface in the default QMI mode USB composition also “defines channels for control and data transfers and can be used in place of legacy USB modem interface”, so I am still wondering what makes the “RMNETx” interfaces different from the “QMI” interface. If anything at all? Is the “QMI” interface just another name for “RMNET1” in a single RmNet interface configuration?

And I can use RMNET1 and RMNET2 just fine, connecting to e.g. different APNs. The QMI control channels they provide seem to be related to the data channels as I would expect: QMI_WDS commands will affect only the related data channel carried by the bulk endpoints of the USB interface they are sent to, while e.g. QMI_NAS commands naturally have a device wide effect.

It’s just the RMNET3 on which I don’t see any response to any of the QMI commands I send. This made me wonder if there is something special about RMNET3, or if I am doing something wrong? The driver I use will just wrap/unwrap QMI embedded in USB CDC messages. So I send a QMI message as an USB_CDC_SEND_ENCAPSULATED_COMMAND, wait for an USB_CDC_NOTIFY_RESPONSE_AVAILABLE notification and then collect the reply using USB_CDC_GET_ENCAPSULATED_RESPONSE. This works very well on RMNET1 and RMNET2 but not on RMNET3.

Bjørn

4

Still wondering about this… I have uppraded the firmware to

Revision: SWI9200X_03.05.08.00AP R4430 CARMD-EN-10527 2012/01/23 15:28:10

but still no go for RMNET3. Looks like the interrupt endpoint is failing somehow. The interfaces and endpoints are:

bjorn@nemi:~$ sed -n /Sierra/,/^$/p /sys/kernel/debug/usb/devices 
S:  Manufacturer=Sierra Wireless, Incorporated
S:  Product=MC7710
S:  SerialNumber=3581780400xxxxx
C:* #Ifs= 6 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=usbserial_generic
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=usbserial_generic
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=usbserial_generic
E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 8 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
E:  Ad=85(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#=19 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
E:  Ad=87(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#=20 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
E:  Ad=89(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
E:  Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms

The interrupt endpoints 5 and 7 associated with RMNET1 and RMNET2 work just fine. For example for endpoint 7:

Frame 414: 72 bytes on wire (576 bits), 72 bytes captured (576 bits)
    Arrival Time: May 22, 2012 18:32:47.398890000 CEST
    Epoch Time: 1337704367.398890000 seconds
    [Time delta from previous captured frame: 0.002006000 seconds]
    [Time delta from previous displayed frame: 0.002006000 seconds]
    [Time since reference or first frame: 1513.017517000 seconds]
    Frame Number: 414
    Frame Length: 72 bytes (576 bits)
    Capture Length: 72 bytes (576 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: usb]
USB URB
    URB id: 0xffff880178d0b3c0
    URB type: URB_COMPLETE ('C')
    URB transfer type: URB_INTERRUPT (0x01)
    Endpoint: 0x87, Direction: IN
        1... .... = Direction: IN (1)
        .000 0111 = Endpoint value: 7
    Device: 24
    URB bus id: 2
    Device setup request: not relevant ('-')
    Data: present (0)
    URB sec: 1337704367
    URB usec: 398890
    URB status: Success (0)
    URB length [bytes]: 8
    Data length [bytes]: 8
    [Request in: 411]
    [Time from request: 0.003972000 seconds]
    Leftover Capture Data: a101000013000000

But receiving anything from endpoint 9 does not work at all. It just times out and returns -ENOENT:

Frame 434: 64 bytes on wire (512 bits), 64 bytes captured (512 bits)
    Arrival Time: May 22, 2012 18:40:59.311566000 CEST
    Epoch Time: 1337704859.311566000 seconds
    [Time delta from previous captured frame: 10.388861000 seconds]
    [Time delta from previous displayed frame: 10.388861000 seconds]
    [Time since reference or first frame: 2004.930193000 seconds]
    Frame Number: 434
    Frame Length: 64 bytes (512 bits)
    Capture Length: 64 bytes (512 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: usb]
USB URB
    URB id: 0xffff88022f363980
    URB type: URB_COMPLETE ('C')
    URB transfer type: URB_INTERRUPT (0x01)
    Endpoint: 0x89, Direction: IN
        1... .... = Direction: IN (1)
        .000 1001 = Endpoint value: 9
    Device: 24
    URB bus id: 2
    Device setup request: not relevant ('-')
    Data: present (0)
    URB sec: 1337704859
    URB usec: 311566
    URB status: No such file or directory (-ENOENT) (-2)
    URB length [bytes]: 0
    Data length [bytes]: 0
    [Request in: 431]
    [Time from request: 10.390625000 seconds]

I haven’t tried polling for responses yet. Might try that. But it sure would be nice to know whether this is expected behaviour on RMNET3, or me having a faulty device, or something else…

Bjørn

5

Bringing back this old topic because I just had a report that the same problem affects the MC7304, despite both a much newer chipset and of course newer firmware.

The MC7304 can be configured for 3 separate RMNET functions as well, as documented in the “AirPrime MC73xx - USB Driver Developer’s Guide”. But only the first 2 appear to work. RMNET3 (USB interface #11) on the MC7304 gives no response to QMI commands, exactly like RMNET3 (USB interface #20) on the MC7710.

So I wonder if anyone has ever gotten all 3 RMNET functions working simultaneously on any of these modules, and if so: Could you please share the details on how to do that?

6

This is known behavior. I believe only 2 RMnet interfaces are supported…

Thanks