MC7455 revisions and carrier firmware downgrade

IoT Modules MC/EM Series
1

Hi,

I have 3 different MC7455 modules that I have been testing. One of them is Rev A. Another one is Rev B. The last one is Rev C. I am testing these on an OpenWRT router that is based on the Ralink MT7620 processor and MIPS 24kc architecture. I am currently using OpenWRT/LEDE 18.06 with kernel 4.14.70. I have compiled the firmware with both the qmi_wwan/qcserial and GobiNet/GobiSerial driver. To toggle between the drivers, I use a script which removes the module from the kernel (i.e. insmod and/or rmmod).

All 3 modules have been configured to be in QMI mode with one RMNET enabled (AT!USBCOMP=1,1,10D) and SIM based firmware switching (AT!IMPREF=“AUTO-SIM”). When using the qmi_wwan/qcserial drivers, all 3 modules are detected correctly, and I am able to issue AT commands to all of them in a terminal. However, all utilities that use libqmi (i.e. qmicli, qmi-network) along with uqmi do NOT work with the Rev A module. The QMI commands issued by the applications all time out on it. The other 2 modules (Rev B and C) work just fine with the utilities and I am able to connect to the carrier networks that I have tested with them (AT&T, Verizon, T-Mobile).

When I use the GobiNet/GobiSerial drivers, all 3 modules are detected correctly, and I am able to issue AT commands to all of them in a terminal. I have tested the modules with these drivers on a desktop PC running Ubuntu 18.04 and was able to use the Connection Manager application (provided in the SDK) to successfully connect to 3 different carrier networks above. However, due to the lack of availability of the needed precompiled libraries and SDK process needed (for the MIPS 24kc architecture) in the SDK package, I am unable to compile the applications for the router’s architecture. Therefore, I am currently unable to test the applications on the router. I have been in contact with source to find out whether they can provide me with the needed precompiled libraries and slqssdk, but that is a separate issue. I believe I may have to make this sort of request through a distributor.

So here is my first question. Is there any configuration change or AT command(s) that I can use to enable the Rev A module to work with libqmi based utilities and/or uqmi with the qmi_wwan driver? I’d rather not use MBIM mode since I’d like to be able to access everything that I can in QMI mode. Also, since I currently do not have a complete solution to manage connectivity via the Gobi SDK in the router’s environment, these are my only options.

Now on to my second issue. I recently upgraded another MC7455 module to the latest carrier firmware for Generic, AT&T, Sprint, and Verizon (version 2.30.01.01). I have another SIM card from FreedomPop that I use for testing. They are an MVNO that utilizes AT&T’s network to my knowledge. In the previous firmwares (2.24.05.06), when I used this SIM, the auto SIM switching feature would load the Generic firmware, and I would use a custom APN for FreedomPop (fp.com.attz). This worked perfectly. In the new firmware, the auto SIM switching feature is loading the AT&T firmware instead. This has caused some glitches from time to time. Another thing that I noticed is that if I use a Verizon SIM, then use a T-Mobile SIM, the new firmware’s auto SIM switching is NOT changing to Generic like the previous firmware used to.

So here is my second question. Am I able to download the previous carrier firmware and downgrade? If so, where can I download the files? I cannot find them on source.

Any help would be really appreciated.

Thanks,

TK

2

There is a flaw in the logic I used to detect the chipset used in the MC7455. I assumed that it would always present itself as a USB 3 capable device. I.e. show bcdUSB version 2.10 or higher. I’ve later learned that the MC7455 can be configured to appear as a USB 2 device. I suspect that your rev A module might be? You can easily verify that by using lsusb -v or cat /sys/kernel/debug/usb/devices (with debugfs mounted). If it shows “bcdUSB 2.00” or “Ver= 2.00” respectively, then it is affected by this problem in the qmi_wwan driver.

It was sort of fixed with this commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/usb/qmi_wwan.c?id=922005c7f50e7f4b2a6dbc182e9c575b4f92396b

But that was first in v4.19. It was backported to stable branches, but the first 4.14 release with the fix was v4.14.73, so you don’t have it in your OpenWrt release.

Note that you can use MBIM and get all the QMI bells and whistles, thanks to the “QMI in MBIM” service. Recent qmicli versions have a --device-open-mbim option allowing you to use this. There is also basic support for it in uqmi.