MC7455/EM7455 dependencies and protocols
Tim Harvey
tharvey at gateworks.com
Tue Mar 7 20:34:58 UTC 2017
On Mon, Mar 6, 2017 at 3:01 PM, Dan Williams <dcbw at redhat.com> wrote:
> On Mon, 2017-03-06 at 14:42 -0800, Tim Harvey wrote:
>> On Sat, Mar 4, 2017 at 4:21 AM, Bjørn Mork <bjorn at mork.no> wrote:
>> > [starting a new thread with the answers...]
>>
>> oops - my apologies for hijacking the previous thread.
>>
>> >
>> > Tim Harvey <tharvey at gateworks.com> writes:
>> >
>> > > Hi Bjørn,
>> > >
>> > > Can you tell me more about how you got this modem working? I'm
>> > > trying
>> > > to understand:
>> > > - what Linux drivers are required and do you have to inject
>> > > new_id's
>> > > vis sysfs to get them to probe (none of the drivers seem to
>> > > recognize
>> > > the 0x1199:0x9079 by default)
>> >
>> > Depending on the modem firmware configuration you may need
>> > cdc_mbim,
>> > qmi_wwan and qcserial.
>> >
>> > The 9079 PID is Lenovo specific, and AFAIK always in MBIM mode by
>> > default. The cdc_mbim driver matches on class attributes, so there
>> > is no
>> > need for any device specific IDs.
>> >
>> > Wrt non-default configurations, both the 1199:9071 (Sierra default)
>> > and
>> > 1199:9079 (Lenovo ID) were added to the qcserial and qmi_wwan
>> > drivers in
>> > Linux v4.5.
>> >
>> > > - what managment and communication dev nodes should be created
>> >
>> > Depends on modem firmware configuration. Typically one or more
>> > /dev/cdc-wdmX nodes, one or more wwanY netdevs and zero or more
>> > /dev/ttyUSBz nodes.
>> >
>> > > - what libqmi version is required
>> >
>> > The latest.
>> >
>> > > - what the difference is between mbim and qmi
>> >
>> > Different protocols for management and data framing. No need to
>> > worry
>> > about that. The drivers and ModemManager will figure it out.
>> >
>> > But if you do want to worry, then Google has lots of interesting
>> > info :)
>> >
>> > > - what the firmware dependencies are, how to tell what firmware I
>> > > have
>> > > on them, and how to update if required
>> >
>> > ModemManager will tell you the firmware revision regardless of
>> > protocols
>> > and drivers in use. AFAIK, updating is not required for any
>> > production MC7455/EM7455.
>> >
>> > > I've got an MC7455 as well as an EM7455 on hand to test with but
>> > > haven't gotten either to be recognized by any of the Linux
>> > > drivers (at
>> > > least in 4.4).
>> >
>> > You'll need Linux v4.5 or later for QMI on these modems.
>> >
>> > And you'll probably need v4.7 or later for MBIM. Or one of the
>> > stable
>> > kernels with a backport of c086e7096170 ("cdc_ncm: workaround for
>> > EM7455
>> > "silent" data interface"), for example v4.4.16 or later.
>> >
>>
>> Thank you this was very helpful! I'm glad I asked before spending a
>> lot of time with Linux 4.4.
>>
>> I've built a 4.10 kernel and do see the following for the 1199:9079
>> EM7455
>> - /dev/cdc-wdm0 management device from cdc_mbim (2 of them for
>> 1199:9071 MC7455)
>> - wwan0 registered net device from cdc_mbim
>> - /dev/ttyUSB0,1,2 devices from qcserial
>>
>> I believe this confirms that the modem is using MBIM. It would seem
>> that I should be using libmbim/mbimcli but then it also looks like
>> libqmi has some MBIM support? In fact it looks like libqmi-1.16.0+
>> has
>> added support for QMI-over-MBIM (requires libmbim-glib-1.14.0+?)...
>> perhaps this was to simplify applications like ModemManager so they
>> only had to worry about one API?
>
> Not really. It turns out that some modems require QMI commands to
> power up (the FCC Auth thing) that are non-standard, and thus aren't
> part of the standard MBIM spec. So ModemManager just uses the QMI-in-
> MBIM thing to send that command, and then proceeds to use MBIM for the
> rest.
>
> Yes, MM could skip MBIM and use QMI all the way, but that's fighting
> against a tide. If the modem comes up in MBIM mode, we assume that's
> what the manufacturer intended. That's also probably what Windows does,
> and the manufacturer probably tests with MBIM, and the connection
> manager uses MBIM, so Linux and MM should too. That way we don't try
> to use buggy behavior the manufacturer never intended or tested.
>
>> I've built libmbim-1.14.0 and libqmi-1.17.901 (from source tarballs)
>> and seem to be able to communicate with the modem now (I get sane
>> responses for things like --dms-get-model) but I still can't connect
>> without error using qmi-network.
>
> You wouldn't use qmi-network for this, you'd use mbim-network instead.
> Basically does the same thing, but with MBIM not QMI. Doesn't
> guarantee you'll be successful, but at least follows the path of least
> resistance.
>
> Might be interesting to see what MBIM says if the data connection
> fails.
>
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?
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.
The EM7455 does not have this issue:
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_000'
Build ID: '02.08.02.00_GENERIC'
[image 1]
Image type: 'pri'
Unique ID: '002.007_000'
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: EM7455
Boot version: SWI9X30C_02.08.02.00
AMSS version: SWI9X30C_02.08.02.00
SKU ID: 1102782
Package ID: unknown
Carrier ID: 1
Config version: 002.007_000
root at ventana:~# mbimcli -d /dev/cdc-wdm0 --query-device-caps
[/dev/cdc-wdm0] Device capabilities retrieved:
Device type: 'remote'
Cellular class: 'gsm'
Voice class: 'no-voice'
Sim class: 'removable'
Data class: 'umts, hsdpa, hsupa, lte'
SMS caps: 'pdu-receive, pdu-send'
Ctrl caps: 'reg-manual'
Max sessions: '8'
Custom data class: 'unknown'
Device ID: '014582002248145'
Firmware info: 'SWI9X30C_02.08.02.00'
Hardware info: 'EM7455'
root at ventana:~# mbimcli -d /dev/cdc-wdm0 --query-subscriber-ready-status
[/dev/cdc-wdm0] Subscriber ready status retrieved:
Ready state: 'sim-not-inserted'
Subscriber ID: 'unknown'
SIM ICCID: 'unknown'
Ready info: 'unknown'
Telephone numbers: (0) 'unknown'
^^^^ haven't gotten a SIM on this device yet so can't go further -
working on this
Thanks,
Tim
> Dan
>
>> I've queried the following from the MC7455:
>> # qmicli -d /dev/cdc-wdm0 --dms-get-manufacturer
>> [/dev/cdc-wdm0] Device manufacturer retrieved:
>> Manufacturer: 'Sierra Wireless, Incorporated'
>> # qmicli -d /dev/cdc-wdm0 --dms-get-model
>> [/dev/cdc-wdm0] Device model retrieved:
>> Model: 'MC7455'
>> # qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode
>> [/dev/cdc-wdm0] Operating mode retrieved:
>> Mode: 'online'
>> HW restricted: 'no'
>> # qmicli -d /dev/cdc-wdm0 --dms-get-activation-state
>> [/dev/cdc-wdm0] Activation state retrieved:
>> State: 'not-activated'
>> # qmicli -d /dev/cdc-wdm0 --nas-get-signal-strength
>> [/dev/cdc-wdm0] Successfully got signal strength
>> Current:
>> Network 'umts': '-81 dBm'
>> RSSI:
>> Network 'umts': '-81 dBm'
>> ECIO:
>> Network 'umts': '-14.0 dBm'
>> IO: '-106 dBm'
>> SINR (8): '9.0 dB'
>> # qmicli -d /dev/cdc-wdm0 --nas-get-signal-info
>> [/dev/cdc-wdm0] Successfully got signal info
>> WCDMA:
>> RSSI: '-81 dBm'
>> ECIO: '-12.0 dBm'
>>
>> I've set my APN in /etc/qmi-network.conf yet 'qmi-network
>> /dev/cdc-wdm0 start' fails:
>> error: couldn't start network: QMI protocol error (14): 'CallFailed'
>> call end reason (1): generic-unspecified
>> verbose call end reason (3,2504): [cm] (null)
>> Saving state at /tmp/qmi-network-state-cdc-wdm0... (CID: 35)
>> error: network start failed, no packet data handle
>> Clearing state at /tmp/qmi-network-state-cdc-wdm0...
>>
>> What is the best method to troubleshoot to determine if the issue is
>> with the SIM, signal strength, APN configuration, etc?
>>
>> Regards,
>>
>> Tim
>>
>> >
>> >
>> > Bjørn
>>
>> _______________________________________________
>> libqmi-devel mailing list
>> libqmi-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/libqmi-devel
More information about the libmbim-devel
mailing list