QMI Connectivity Issues Quectel RG255C-GL

IoT Modules 5G Module
1

I’m facing really disturbing problems trying to connect my RG255C-GL device since I updated its firmware to RG255CGLABR01A04M4G version.

With factory firmware (RG255CGLABR01A03M4G_01.001.01.001), I was able to connect using ModemManager (QMI) by supporting the device in qmi_wwan and serial option linux drivers:
qmi_wwan:

  •   {QMI_FIXED_INTF(0x2c7c, 0x0316, 3)},    /* Quectel RG355C */

serial_option:

+#define QUECTEL_PRODUCT_RG255C_GL 0x0316
[…]
{ USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_RG255C_GL, 0xff, 0xff, 0xff),
.driver_info = RSVD(3) | NUMEP2 },
{ USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_RG255C_GL, 0xff, 0, 0) },
{ USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_RG255C_GL, 0xff, 0xff, 0x30) },
{ USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_RG255C_GL, 0xff, 0xff, 0x40) },

and aplying patches suggested by quectel in UMTS_LTE_5G_Linux_USB_Driver_User_Guide v 3.2 document.

My current situation is this:
Device: RG255C-GL
Firmware: RG255CGLABR01A04M4G
Kernel: Linux 5.10.72
ModemManager: v1.22
Platform: i.MX8MP (Yocto-based, aarch64)

ModemManager doesn’t detect cdc-wdm0 port

ports: ttyUSB2 (at), wwan0 (ignored)
plugin: quectel

and qmi commands fail with
CID allocation failed in the CTL client: Transaction timed out
error log
I have tried several things such as patching linux driver to export QMI protocol as 0x51 (current shows 0x50):

usb-devices | grep -A10 2c7c

P: Vendor=2c7c ProdID=0316 Rev=05.15
S: Manufacturer=Quectel
S: Product=RG255C-GL
S: SerialNumber=590b3526
C: #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=500mA
I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
I: If#=0x1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan

Tried with quectel custom driver (qmi_wwan_q) v1.2.7 as suggested in firmware release notes and same effect.
Tried to connect in ECM mode also failed even after Modem has public IP.

So my questions are:

  • Does firmware version RG255CGLABR01A04M4G fully support QMI (usbnet=0)?
  • Is there a required AT command to activate the QMI service stack or data plane?
  • Are there any firmware constraints preventing QMI access or CID allocation?
  • Can you provide a known-working firmware version for QMI under Linux?
  • Is a custom initialization sequence needed (e.g. AT+QMAP, AT+QMIWDS)?

Thank you for your help

2

Hi @HectorJimenez,

please retry with the qmi_wwan.c patch from Making sure you're not a bot! instead of the one you are using now. Not using QMI_QUIRK_SET_DTR might explain the observed effect.
Unless there is a firmware regression this should get you to the point where at least qmicli --get-service-version-info works.

Regards,
Reinhard

3

Hello @rspmn . I have changed that in my qmi_wwan driver and now qmi port is working fine:

qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode
[/dev/cdc-wdm0] Operating mode retrieved:
        Mode: 'online'
        HW restricted: 'no'

Thank you very much!

On the other hand, by saying:

Unless there is a firmware regression this …

you mean that with older firmware versions, this driver will not be able to correct configure qmi port?

Just to know if we need to force a device firmware upgrade before trying to connect it to the network by using this driver.

Thank you!

4

Hi @HectorJimenez ,

the “… firmware regression …” part was referring to the case if the QMI port would have been unresponsive despite using QMI_QUIRK_SET_DTR.

Using it with older firmware versions which may not require it should still work. Please note that my SDX35 experience is based on a device from another UE vendor.

Regards,
Reinhard

5

Understood, @rspmn.

Thank you very much