MC7455/EM7455 dependencies and protocols
Dan Williams
dcbw at redhat.com
Thu Mar 9 22:21:32 UTC 2017
On Thu, 2017-03-09 at 11:57 -0800, Tim Harvey wrote:
> On Tue, Mar 7, 2017 at 12:51 PM, Dan Williams <dcbw at redhat.com>
> wrote:
> > >
> > > Dan,
> > >
> > > Thanks for the explanation. Adding libmbim-devel cc
> > >
> > > What is the fundamental difference between the various cdc_wdm
> > > devices
> > > - is it modem/firmware specific which one is for what?
> >
> > Specifically for different cdc-wdm devices exposed by a single
> > *QMI*
> > modem, they all basically do the same thing, but are used for
> > different
> > control/data pairs. So theoretically, if you want to have two IP
> > connections to different APNs at the same time (eg, one for normal
> > data
> > and another for IMS) each connection would use a different cdc-
> > wdmX/wwanX pair. Qualcomm has changed that somewhat and has
> > introduced
> > "muxing" where this is all done on a single pair.
> >
> > > Here are some details about my system/software:
> > > - Board: Gateworks Ventana IMX6 based with USB2.0 to miniPCIe
> > > socket
> > > (for MC7455) and USB2.0 to M.2 socket (for EM7455)
> > > - Linux 4.10.0
> > > - libmbim 1.14.0
> > > - libqmi 1.17.901
> > > - MC7455: 1199:9071
> > > - EM7455: 1199:9079
> > > - I'm not testing with both cards present... testing one at a
> > > time on
> > > different boards
> > >
> > > MC7455:
> > > root at ventana:~# dmesg | egrep -ie qualcom\|mbim\|sierra\|wdm
> > > [ 13.247619] usbcore: registered new interface driver cdc_wdm
> > > [ 13.263903] qmi_wwan 1-1.2:1.8: cdc-wdm0: USB WDM device
> > > [ 13.264564] usbserial: USB Serial support registered for
> > > Qualcomm
> > > USB modem
> > > [ 13.273389] qmi_wwan 1-1.2:1.10: cdc-wdm1: USB WDM device
> > > [ 13.275348] qcserial 1-1.2:1.0: Qualcomm USB modem converter
> > > detected
> > > [ 13.276240] usb 1-1.2: Qualcomm USB modem converter now
> > > attached
> > > to ttyUSB0
> > > [ 13.277736] qcserial 1-1.2:1.2: Qualcomm USB modem converter
> > > detected
> > > [ 13.278354] usb 1-1.2: Qualcomm USB modem converter now
> > > attached
> > > to ttyUSB1
> > > [ 13.278846] qcserial 1-1.2:1.3: Qualcomm USB modem converter
> > > detected
> > > [ 13.279451] usb 1-1.2: Qualcomm USB modem converter now
> > > attached
> > > to ttyUSB2
> > > root at ventana:~# qmicli -d /dev/cdc-wdm0 --dms-get-firmware-
> > > preference
> > > firmware preference successfully retrieved:
> > > [image 0]
> > > Image type: 'modem'
> > > Unique ID: '002.007_001'
> > > Build ID: '02.08.02.00_GENERIC'
> > > [image 1]
> > > Image type: 'pri'
> > > Unique ID: '002.007_001'
> > > Build ID: '02.08.02.00_GENERIC'
> > > root at ventana:~# qmicli -d /dev/cdc-wdm0 --dms-swi-get-current-
> > > firmware
> > > [/dev/cdc-wdm0] Successfully retrieved current firmware:
> > > Model: MC7455
> > > Boot version: SWI9X30C_02.08.02.00
> > > AMSS version: SWI9X30C_02.08.02.00
> > > SKU ID: 1102476
> > > Package ID: unknown
> > > Carrier ID: 1
> > > Config version: 002.007_001
> > > root at ventana:~# mbimcli -d /dev/cdc-wdm0 --query-device-caps
> > > ^^^^ hangs here as well as any mbimcli cmd I've tried regardless
> > > of
> > > which wdm device
> > >
> > > Any idea what's going on here? I have two MC7455's and both
> > > behave
> > > the same.
> >
> > Yeah. These MC7455 devices are in QMI mode, which is why mbimcli
> > doesn't work. Your EM7455 is in MBIM mode, which is why it does
> > work
> > there.
> >
> > > The EM7455 does not have this issue:
> > > root at ventana:~# qmicli -d /dev/cdc-wdm0 --dms-get-firmware-
> > > preference
> > >
> >
> > qmicli has some logic to automatically detect that the device is
> > using
> > MBIM mode, and then do the QMI-over-MBIM thing automatically for
> > you.
> >
> > Look at the driver binding from 'dmesg'. That will always tell you
> > what driver the kernel has chosen for each device, and thus what
> > mode
> > its in.
>
> Ok, checking the bindings to see if the modem make/model/firmware is
> in QMI or MBIM mode makes sense!
>
> So next steps on MC7455 (QMI):
> root at ventana:~# uname -r
> 4.10.0
> root at ventana:~# dmesg | grep wdm
> [ 9.557519] usbcore: registered new interface driver cdc_wdm
> [ 9.566986] qmi_wwan 1-1.2:1.8: cdc-wdm0: USB WDM device
> [ 9.589439] qmi_wwan 1-1.2:1.10: cdc-wdm1: USB WDM device
> root at ventana:~# echo "APN=m2m.com.attz" > /etc/qmi-network.conf
> root at ventana:~# qmi-network /dev/cdc-wdm0 start
> Loading profile at /etc/qmi-network.conf...
> APN: m2m.com.attz
> APN user: unset
> APN password: unset
> qmi-proxy: no
> Checking data format with 'qmicli -d /dev/cdc-wdm0 --wda-get-data-
> format '...
> Device link layer protocol retrieved: raw-ip
> Getting expected data format with 'qmicli -d /dev/cdc-wdm0
> --get-expected-data-format'...
> Expected link layer protocol retrieved: 802-3
> Updating kernel link layer protocol with 'qmicli -d /dev/cdc-wdm0
> --set-expected-data-format=raw-ip'...
> Kernel link layer protocol updated
> Starting network with 'qmicli -d /dev/cdc-wdm0
> --wds-start-network=apn='m2m.com.attz' --client-no-release-cid '...
> [09 Mar 2017, 16:34:29] -Warning ** Error reading from istream: Error
> reading from file descriptor: Input/output error
> error: couldn't create client for the 'wds' service: CID allocation
> failed in the CTL client: Transaction timed out
> error: network start failed, client not allocated
> ^^^^ any idea what could be going on here?
Can you add a "-v" arg to the START_NETWORK_CMD part of /usr/bin/qmi-
network so we can see what the verbose output is?
Also after this happens, can you run other qmicli commands right after
this happens? Like "qmicli -d /dev/cdc-wdm0 --dms-get-ids"? Or is the
modem dead?
> Note that I do not have ModemManager installed - still trying to
> configure the modem by hand to understand the process.
>
> Also occasionally the MC7455 comes up as 1199:9070 (instead of
> 1199:9071) in which case its detected by qcserial which provides a
> /dev/ttyUSB0 but that's it. Have you ever seen that or know what
> could
> cause that? I have two MC7455's and they both behave the same.
The modem is coming back in firmware update mode. Or maybe it's debug
mode. But a single tty is an indication that the device was not able
to start up correctly.
> The next steps on the board with the EM7455 (MBIM):
> root at ventana:~# uname -r
> 4.10.0
> root at ventana:~# dmesg | grep wdm
> [ 24.963503] usbcore: registered new interface driver cdc_wdm
> [ 25.059084] cdc_mbim 2-1.1:1.12: cdc-wdm0: USB WDM device
> root at ventana:~# mbimcli --version
>
> mbimcli 1.15.0
> ...
> root at ventana:~# mbim-network /dev/cdc-wdm0 start
> Loading profile at /etc/mbim-network.conf...
> APN: h2g2
> APN auth protocol: unset
> APN user: unset
> APN password: unset
> mbim-proxy: no
> Querying subscriber ready status 'mbimcli -d /dev/cdc-wdm0
> --query-subscriber-ready-status --no-close '...
> [/dev/cdc-wdm0] Subscriber ready status retrieved: Ready state:
> 'initialized' Subscriber ID: '310260970524563' SIM ICCID:
> '8901260971105245631' Ready info: 'unknown' Telephone numbers: (0)
> 'unknown' [/dev/cdc-wdm0] Session not closed: TRID: '3'
> Saving state at /tmp/mbim-network-state-cdc-wdm0... (TRID: 3)
> Querying registration state 'mbimcli -d /dev/cdc-wdm0
> --query-registration-state --no-open=3 --no-close '...
> [/dev/cdc-wdm0] Registration status: Network error: 'unknown'
> Register
> state: 'deregistered' Register mode: 'automatic' Available data
> classes: 'unknown' Current cellular class: 'gsm' Provider ID:
> 'unknown' Provider name: 'unknown' Roaming text: 'unknown'
> Registration flags: 'packet-service-automatic-attach' [/dev/cdc-wdm0]
> Session not closed: TRID: '4'
> Saving state at /tmp/mbim-network-state-cdc-wdm0... (TRID: 4)
> Attaching to packet service with 'mbimcli -d /dev/cdc-wdm0
> --attach-packet-service --no-open=4 --no-close '...
> error: operation failed: RadioPowerOff
>
Here's your issue (and as you state below). A couple possiblities:
1) Your device needs the FCCAuth command which can only be tunneled
through QMI-over-MBIM. Sierra devices often need this. *Even though
it's an MBIM device*, try:
qmicli -d /dev/cdc-wdm0 --device-open-mbim --dms-set-fcc-authentication
and then run "mbimcli -d /dev/cdc-wdm0 --query-radio-state" to see if
that makes a difference.
2) Your firmware is mismatched. Qualcomm devices have a couple
different firmware images stored onboard, and you have to make sure the
ones that are selected match each other, otherwise it won't let you do
anything radio-related. Try:
qmicli -d /dev/cdc-wdm0 --device-open-mbim --dms-list-stored-images
qmicli -d /dev/cdc-wdm0 --device-open-mbim --dms-get-firmware-preference
And lets see what you get. If those don't show anything, there are
some AT commands we could try (if the device exposes an AT port at all)
that give more information about firmware selections.
Dan
> Saving state at /tmp/mbim-network-state-cdc-wdm0... (TRID: 5)
> Starting network with 'mbimcli -d /dev/cdc-wdm0 --connect=apn='h2g2'
> --no-open=5 --no-close '...
> error: operation failed: RadioPowerOff
> ^^^^ assume this is the issue
> Network start failed
> [/dev/cdc-wdm0] Session not closed: TRID: '6'
> Saving state at /tmp/mbim-network-state-cdc-wdm0... (TRID: 6)
> root at ventana:~# mbimcli -d /dev/cdc-wdm0 --query-radio-state
> [/dev/cdc-wdm0] Radio state retrieved:
> Hardware Radio State: 'on'
> Software Radio State: 'off'
> root at ventana:~# mbimcli -d /dev/cdc-wdm0 --set-radio-state=on
> error: operation failed: Failure
> ^^^^ is this expected? I'm not clear how to set the software radio
> state on
> root at ventana:~# mbimcli -d /dev/cdc-wdm0 --query-signal-state
> [/dev/cdc-wdm0] Signal state:
> RSSI [0-31,99]: '99'
> Error rate [0-7,99]: '99'
> Signal strength interval: '5'
> RSSI threshold: '2'
> Error rate threshold: 'unspecified'
> ^^^^ I'm assuming 99 because the radio is not on?
> root at ventana:~# mbimcli -d /dev/cdc-wdm0 --query-visible-providers
> error: operation failed: NotInitialized
> root at ventana:~# mbimcli -d /dev/cdc-wdm0 --query-home-provider
> error: operation failed: NotInitialized
> root at ventana:~# mbimcli -d /dev/cdc-wdm0 --query-preferred-providers
> [/dev/cdc-wdm0] Preferred providers (28):
> ...
> ^^^^ are these providers from the SIM or the modem?
>
> Googling 'Software Radio State: off' I've found some references to
> using mbimcli -p (Request to use the 'mbim-proxy'). I'm not
> understanding what that does but here's a verbose output:
> root at ventana:~# mbimcli -v -p -d /dev/cdc-wdm0 --set-radio-state=on
> [09 Mar 2017, 18:39:03] [Debug] opening device...
> [09 Mar 2017, 18:39:03] [Debug] [/dev/cdc-wdm0] Read max control
> message size from descriptors file: 4096
> [09 Mar 2017, 18:39:03] [Debug] [/dev/cdc-wdm0] Sent message...
> <<<<<< RAW:
> <<<<<< length = 88
> <<<<<< data =
> 03:00:00:00:58:00:00:00:01:00:00:00:01:00:00:00:00:00:00:00:83:8C:F7:
> FB:8D:0D:4D:7F:87:1E:D7:1D:BE:FB:B3:9B:01:00:00:00:01:00:00:00:28:00:
> 00:00:0C:00:00:00:1A:00:00:00:1E:00:00:00:2F:00:64:00:65:00:76:00:2F:
> 00:63:00:64:00:63:00:2D:00:77:00:64:00:6D:00:30:00:00:00
>
> [09 Mar 2017, 18:39:03] [Debug] [/dev/cdc-wdm0] Sent message
> (translated)...
> <<<<<< Header:
> <<<<<< length = 88
> <<<<<< type = command (0x00000003)
> <<<<<< transaction = 1
> <<<<<< Fragment header:
> <<<<<< total = 1
> <<<<<< current = 0
> <<<<<< Contents:
> <<<<<< service = 'proxy-control' (838cf7fb-8d0d-4d7f-871e-
> d71dbefbb39b)
> <<<<<< cid = 'configuration' (0x00000001)
> <<<<<< type = 'set' (0x00000001)
>
> [09 Mar 2017, 18:39:06] [Debug] [/dev/cdc-wdm0] Received message...
> > > > > > > RAW:
> > > > > > > length = 48
> > > > > > > data =
> > > > > > > 03:00:00:80:30:00:00:00:01:00:00:00:01:00:00:00:00:00:00:
> > > > > > > 00:83:8C:F7:FB:8D:0D:4D:7F:87:1E:D7:1D:BE:FB:B3:9B:01:00:
> > > > > > > 00:00:00:00:00:00:00:00:00:00
>
> [09 Mar 2017, 18:39:06] [Debug] [/dev/cdc-wdm0] Received message
> (translated)...
> > > > > > > Header:
> > > > > > > length = 48
> > > > > > > type = command-done (0x80000003)
> > > > > > > transaction = 1
> > > > > > > Fragment header:
> > > > > > > total = 1
> > > > > > > current = 0
> > > > > > > Contents:
> > > > > > > status error = 'None' (0x00000000)
> > > > > > > service = 'proxy-control' (838cf7fb-8d0d-4d7f-
> > > > > > > 871e-d71dbefbb39b)
> > > > > > > cid = 'configuration' (0x00000001)
>
> [09 Mar 2017, 18:39:06] [Debug] [/dev/cdc-wdm0] Sent message...
> <<<<<< RAW:
> <<<<<< length = 16
> <<<<<< data = 01:00:00:00:10:00:00:00:02:00:00:00:00:10:00:00
>
> [09 Mar 2017, 18:39:06] [Debug] [/dev/cdc-wdm0] Sent message
> (translated)...
> <<<<<< Header:
> <<<<<< length = 16
> <<<<<< type = open (0x00000001)
> <<<<<< transaction = 2
> <<<<<< Contents:
> <<<<<< max_control_transfer = 4096
>
> [09 Mar 2017, 18:39:06] [Debug] [/dev/cdc-wdm0] Received message...
> > > > > > > RAW:
> > > > > > > length = 16
> > > > > > > data =
> > > > > > > 01:00:00:80:10:00:00:00:02:00:00:00:00:00:00:00
>
> [09 Mar 2017, 18:39:06] [Debug] MBIM Device at '/dev/cdc-wdm0' ready
> [09 Mar 2017, 18:39:06] [Debug] Asynchronously setting radio state to
> on...
> [09 Mar 2017, 18:39:06] [Debug] [/dev/cdc-wdm0] Sent message...
> <<<<<< RAW:
> <<<<<< length = 52
> <<<<<< data =
> 03:00:00:00:34:00:00:00:03:00:00:00:01:00:00:00:00:00:00:00:A2:89:CC:
> 33:BC:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:03:00:00:00:01:00:00:00:04:00:
> 00:00:01:00:00:00
>
> [09 Mar 2017, 18:39:06] [Debug] [/dev/cdc-wdm0] Sent message
> (translated)...
> <<<<<< Header:
> <<<<<< length = 52
> <<<<<< type = command (0x00000003)
> <<<<<< transaction = 3
> <<<<<< Fragment header:
> <<<<<< total = 1
> <<<<<< current = 0
> <<<<<< Contents:
> <<<<<< service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-
> 133ec2aae6df)
> <<<<<< cid = 'radio-state' (0x00000003)
> <<<<<< type = 'set' (0x00000001)
>
> [09 Mar 2017, 18:39:06] [Debug] [/dev/cdc-wdm0] Received message...
> > > > > > > RAW:
> > > > > > > length = 56
> > > > > > > data =
> > > > > > > 03:00:00:80:38:00:00:00:03:00:00:00:01:00:00:00:00:00:00:
> > > > > > > 00:A2:89:CC:33:BC:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:03:00:
> > > > > > > 00:00:02:00:00:00:08:00:00:00:01:00:00:00:00:00:00:00
>
> [09 Mar 2017, 18:39:06] [Debug] [/dev/cdc-wdm0] Received message
> (translated)...
> > > > > > > Header:
> > > > > > > length = 56
> > > > > > > type = command-done (0x80000003)
> > > > > > > transaction = 3
> > > > > > > Fragment header:
> > > > > > > total = 1
> > > > > > > current = 0
> > > > > > > Contents:
> > > > > > > status error = 'Failure' (0x00000002)
> > > > > > > service = 'basic-connect' (a289cc33-bcbb-8b4f-
> > > > > > > b6b0-133ec2aae6df)
> > > > > > > cid = 'radio-state' (0x00000003)
>
> error: operation failed: Failure
> [09 Mar 2017, 18:39:06] [Debug] [/dev/cdc-wdm0] Sent message...
> <<<<<< RAW:
> <<<<<< length = 12
> <<<<<< data = 02:00:00:00:0C:00:00:00:04:00:00:00
>
> [09 Mar 2017, 18:39:06] [Debug] [/dev/cdc-wdm0] Sent message
> (translated)...
> <<<<<< Header:
> <<<<<< length = 12
> <<<<<< type = close (0x00000002)
> <<<<<< transaction = 4
>
> [09 Mar 2017, 18:39:06] [Debug] [/dev/cdc-wdm0] Received message...
> > > > > > > RAW:
> > > > > > > length = 16
> > > > > > > data =
> > > > > > > 02:00:00:80:10:00:00:00:04:00:00:00:00:00:00:00
>
> [09 Mar 2017, 18:39:06] [Debug] [/dev/cdc-wdm0] channel destroyed
> [09 Mar 2017, 18:39:06] [Debug] Device closed
>
> Note that the M.2 slot has a Full_Card_Power_Off# (pin 6),
> W_DISABLE1#
> (pin 8), and RESET# (pin 67) all of which are driven logic high by
> CPU
> GPIO's. Additionally 'rfkill list' doesn't show anything blocked by
> rfkill.
>
> Thanks for the continued help!
>
> Tim
More information about the libqmi-devel
mailing list