EM9190 usbcomp settings

IoT Modules
1

Hello,

Managed to get my hands on a EM9190 from AliExpress. It looks like an old FW, 16.04.00 2020/06/02.
To other users, I will just let you know that most of the M.2 adapters to USB(3) adapters available will not work with this modem, without some rework.
I have been using EM7565 as well, but this modem has a few extra pins for VCC, VBUS_SENSE and a PCIE_DIS pin that needs to be pulled high to 1.8V to force the USB interface to be enabled. After that you will see a USB device 1199/90D3 enumerate.
I hacked the existing Linux USB drivers and got the usbtty0 port up and running and was able to open the AT command interface.

The modem comes up with the MBIM enabled, but I would like to change this to the RMNET to control the modem using QMI.
A few weeks ago the AT command spec for this modem became available, and according to the spec and the modemā€™s own help, I tried to change the USBCOMP, but got errors only. It seems like I can only set the USBCOMP to 1,4,100B, thatā€™s the only value I have found that doesnā€™t return an error. Is this a feature not yet supported in the FW I have? I would like to run 1,4,10D, disable the MBIM and enable the RMNET.

I feel like I am wasting my time here? Is there another FW out there that will enable this?

Sierra WIreless: I know you will just point me to my commercial distributor or account manager for support, which is a deadend for me. But can you at least answer me (us) when will new FW releases be ready on your site? Any way to do a FOTA at this point? The module is commercially available according to your press releases, but not much info on your product page yet, no drivers, no SDK. Any time line you can share?

1 Like
2

Hi @dannypoulsen

I have no information on the EM9190 firmware release and FOTA. This product is still considered under development, I recommend work with your direct support channels with Sierra Wireless or Re-seller for support on EM9190.

3

@dannypoulsen

So technically it is commercially available (as per the marketing) at the moment but we are probably (I say probably because I have no direct visibility or control of it) waiting to push firmware, Linux design guides, etc to the source until it is officially approved at one of the major US carriers, which, if it has not been completed in the last couple of weeks it should be very shortly.

Re the RMNet question. The general movement is towards MBIM overall as it is obviously natively supported by Windows and the open source client on Linux is pretty good. This is something that QC are pressing quite hard at the moment as it means there will be a single open source interface which they (and OEMā€™s) have to support making life easier for everyone. This is to the point that QMI/RMNet is not officially supported by QC on the 5G chipsets (even though it might still be resident in the code and functional). This essentially means that if it is used and there is a problem then it is unlikely that QC will fix it, this will apply to everyone using their chipsets (so donā€™t be taken in by anyone stating categorically that they support it just because it works at the moment).

I say this as a precursor to what I am about to state. When using PCIe the EM9 will support MBIM and QMI/RMNet (in a ā€˜betaā€™ form as we were forced to do this), if the USB interface is used then its going to be MBIM only.

With regards your unit you procured it has probably got very old firmware on it and there have been file system changes meaning you do need specific upgrade files (which are never going to be made publicly available) meaning a single one click updater is not going to work. Its at this point I unhelpfully push you back to your commercial channel to get the procedure and files.

Regards

Matt

4

Hi Matt.

Thank you for your very detailed answer. It may not be what I wanted to hear, but much better than not knowing at all.
I guess our module could be one that mysteriously disappeared from a vendor or test house and ended up for sale on AliExpress? Not exactly the best source I have to admit, next one will definitely be bought from a reputable vendor.

I thought QC was very interested in pushing their ā€œsmarterā€ QMI? The reason that I wanted to run the modem on the QMI/RMNET is to use the modem with multiple PDNs. According to an application note (2174187-1.0) newer Qualcomm modems only offered a single USB RMNET, so you guys were able to multiplex the interface into several GOBI net interfaces.
We implemented this for the EM7565 modem, so I was kind of expecting the EM9190 to be supporting the same setup? But maybe this is not applicable anymore, as there is another way to achieve this on the new modem. Using the same setup, QMI/RMNET, would just have made it a lot easier.

Searching a bit on the subject it looks like I probably bet on the wrong horse, QMI/RMNET, as it looks like cdc_mbim can do the same using virtual LAN and mbicli.

Again, thanks for your comments and info, that will save me a lot of headache and time.
On to MBIM then.

Regards

Danny

5

@dannypoulsen

So with regards you backing the right horse, it was and remains the right horse for all of the LTE modules its just that with 5G Qualcomm are using it to make the leap to MBIM which from their perspective is sensible.

We did have big discussions earlier last year internally when the first units came out about this leap and how all of our customers effectively use QMI/RMNet with it creating migration issues but without QC support there could easily be problems we might not be able to sort if it broke.

In the end the reasoning is sound i.e. one, open source software interface which is good for everyone (les validation, more people working on one standard meaning more resources and bugs being worked out faster, etc) even if it causes some short term pain which we recognise but have limited ability to address.

Regards

Matt

6

Yes, it most certainly can. IP/PDN session multiplexing was always part of the MBIM protocol from the beginning, and it has been supported from the very first version of the Linux driver.

The userspace ABI is akward though. Not the best idea Iā€™ve had. But itā€™s what we are stuck with now: MBIM IP sessions are mapped to VLANs with IDs matching the MBIM session ID. Except for session 0 of course, which by default is mapped as untagged. This is how everything just works for a single session without caring about the VLANs. But personally I find this very confusing when I use multiplexing. It is also inconvenient to use the main netdev for one of the sessions. You canā€™t take that interface down for example. So I added VLAN ID 4094 as an alternative mapping of MBIM session 0. If you create a subinterface with this ID then it will take over the session 0 traffic and no packets go untagged anymore.

Yes, this is much too magic. And it should have had its own userspace ABI instead of overloading VLANs this way. Too late for that.

Iā€™ve tried to document the mapping etc here:
https://www.kernel.org/doc/html/latest/networking/cdc_mbim.html#mbim-data-channel-userspace-abi

The way I use this is typically

  1. create network devices. E.g. using MBIM sessions 0, 1 and 2:
ip link add wwan0.0 link wwan0 type vlan id 4094
ip link add wwan0.1 link wwan0 type vlan id 1
ip link add wwan0.2 link wwan0 type vlan id 2
  1. Connect the sessions to their appropriate APN:
mbimcli -p -d /dev/cdc-wdm0 --query-subscriber-ready-status --no-close
mbimcli -p -d /dev/cdc-wdm0 --attach-packet-service --no-close --no-open=42 
mbimcli -p -d /dev/cdc-wdm0 --connect=apn=myapnA,session-id=0,ip-type=ipv4v6 --no-close --no-open=42 
mbimcli -p -d /dev/cdc-wdm0 --connect=apn=myapnB,session-id=1,ip-type=ipv4v6 --no-close --no-open=42 
mbimcli -p -d /dev/cdc-wdm0 --connect=apn=myapnC,session-id=2,ip-type=ipv4v6 --no-close --no-open=42
  1. Configure the IP interfaces using the addressing info received from the connect request:
ip addr add 10.0.0.42/32 dev wwan0.0
ip addr add 2001:db8::42/64 dev wwan0.0
ip addr add 10.1.1.42/32 dev wwan0.1
ip addr add 2001:db8:1::42/64 dev wwan0.0
ip addr add 10.2.2.42/32 dev wwan0.2
ip addr add 2001:db8:2::42/64 dev wwan0.0
  1. Configure routing policies for the PDNs.
ip route add default dev wwan0.0 table 100
ip -6 route add default dev wwan0.0 table 100
ip route add default dev wwan0.1 table 101
ip -6 route add default dev wwan0.1 table 101
ip route add default dev wwan0.2 table 102
ip -6 route add default dev wwan0.2 table 102
ip rule from .... add pref 1000 lookup table 100
etc..

Yes, itā€™s a mess. But itā€™s actually simpler than using the QMI QMAP.

And you do still have access to all the powers of QMI using the EXT_QMUX MBIM service if you like. I canā€™t imagine Qualcomm killing that. They donā€™t have any replacement. You can qmicli with an MBIM device (as long as the device supports this service):

root@miraculix:/tmp# qmicli -p  --device-open-mbim -d /dev/cdc-wdm0 --nas-get-lte-cphy-ca-info
[/dev/cdc-wdm0] Successfully got carrier aggregation info
DL Bandwidth: '20'
Primary Cell Info
        Physical Cell ID: '176'
        RX Channel: '1450'
        DL Bandwidth: '20'
        LTE Band: 'eutran-3'
Secondary Cell Info
        Physical Cell ID: '284'
        RX Channel: '3050'
        DL Bandwidth: '20'
        LTE Band: 'eutran-7'
        State: 'deconfigured'
Secondary Cell index: '1'
1 Like
7

Ī—Ī¹ @dannypoulsen,
can you please share the modifications of the Linux USB drivers to bring up the EM9190?

8

Hi,

I was previously working with the EM7565 modem and used the Linux QMI drivers, version S2.42N2.64.
I added the USB IDs of the EM9191 (EM9190 seems to be the same for now) in the file GobiSerial.c, two places, where there are other USD IDs. Then at least I can get the AT command handler up and running.

I ended up getting access to docs and drivers through an authorized Sierra Wireless dealer and switched to the EM9190 modem for now. It just so happens that I canā€™t get the supplied drivers to work in my Ubuntu 18 distro, so I ended up using the GobiSerial to talk to the modem, at least for now.
The QMI drivers are end of life at this point, so be aware.

Will be using BjĆørnā€™s MBIM implementation for the data part, in fact working on that right now.

Danny