RM551E-GL fully working over USB with 3 small changes — please add support (still hoping for PCIe)
Hi,
Companion to my other thread about the PCIe link not training with this module. Since
PCIe is out of reach for now, I got the Quectel RM551E-GL working over USB/QMI in a
GL-X3000 on firmware 4.9.0, using the stock cellular stack. Three changes are needed.
Everything below is verified across multiple reboots.
What blocks it in stock firmware
1. Neither driver knows PID 0122. All five USB interfaces come up unbound —
option and qmi_wwan have no entry for 2c7c:0122. No /dev/ttyUSB*, no
/dev/cdc-wdm0, not even an AT port.
2. The model is missing from /lib/modem_data/modem_list.json. Moving this table
out of the binaries into a data file in 4.9.0 was a good change, by the way — adding a
module is now a one-entry edit.
3. The cellular manager discards the modem outright. This is the actual blocker:
cellular_manage: (modem.c:454) skip build-in USB bus 1-1.2, PCIe counterpart in build-in list
The device tree declares build-in-modem = 0001:01:00.0,1-1.2, so the built-in modem
is assumed to be a PCIe device and the USB bus is thrown away. Fixing 1 and 2 alone
achieves nothing without this.
What makes it work
# 1. register the PID with both drivers (from /etc/rc.local, backgrounded)
echo "2c7c 0122" > /sys/bus/usb-serial/drivers/option1/new_id
echo "2c7c 0122" > /sys/bus/usb/drivers/qmi_wwan/new_id
# then wait for /dev/cdc-wdm0 and restart gl_cellular_manager — it starts before
# the drivers attach and does not pick the module up on its own
# 2. add an RM551E entry to /lib/modem_data/modem_list.json:
# a copy of the RM520N USB entry with pid "0122"
# 3. stop the manager from discarding the USB bus
uci set board_special.hardware.build_in_modem='1-1.2'
uci commit board_special
Result — the stock stack detects and dials the module normally:
"name":"RM551E-GL", "version":"RM551EGL00AAR02A02M8G_01.001.01.001"
wwan0 up with a public IP, default route metric 40
T-Mobile LTE, RSRP -92, ping 8.8.8.8 → 0% loss, ~65 ms
Why I would still much prefer PCIe
The M.2 slot in the X3000 is wired behind a USB 2.0 hub (speed=480), so the USB path tops out around 250-300 Mbps. The same module does roughly 800 Mbps in other hardware over USB 3. Getting PCIe to work is what would actually unlock this module's speed on the X3000 — hence the other thread.
Requests
-
Add 2c7c:0122 to the option and qmi_wwan ID tables.
-
Add an RM551E-GL entry to modem_list.json.
-
Do not discard a built-in USB modem when its PCIe counterpart is absent — modem.c:454 currently skips it unconditionally.
Happy to share the exact JSON entry and rc.local snippet, or to test any build.
Thanks!
UPDATE!!! 28.07.2026
Got the Quectel RM551E-GL (X75/SDX75) running over PCIe on a GL-X3000/XE3000 
Same board, same spot, same 5G NSA cell:
USB 309 Mbps (M.2 sits behind a USB 2.0 hub — that's the ceiling)
PCIe 
550–620 Mbps (491 on the first run, higher on repeats)
Two things block it in stock firmware:
1. The bootloader doesn't wait long enough. pcie-mediatek-gen3 has no hotplug, so
the modem must be up before the kernel starts. RM520N-GL is ready in ~0.75 s and just
makes it; the X75 needs 4–5 s and misses the window — the link never trains
(PCIe link down, ltssm 0x1), and nothing can be done from userspace afterwards.
Mainline OpenWrt's U-Boot exposes this as an env variable, so I flashed it and changed
init_modem from sleep 1 to sleep 5. Stock GL firmware keeps booting fine under it.
Verified threshold: 4 s is not enough, 5 s is.
2. The MHI driver doesn't know SDX75. The endpoint enumerates as 17cb:0309, but the
PCI ID table in pcie_mhi.ko stops at 17cb:0308. Adding it at runtime is enough:
echo "17cb 0309" > /sys/bus/pci/drivers/mhi_q/new_id
After that mhi_q binds, /dev/mhi_* appear, rmnet_mhi0 comes up and the stock
cellular manager dials on its own.
Request: could both land in a future release?
- a longer (or configurable) modem power-up delay in the bootloader — 1 s only covers
the RM520N;
17cb:0309 in the MHI driver's PCI ID table.
Neither should affect existing hardware, and it would make X75-class modules work on
these routers out of the box.
GL team — worth a look: this is roughly double what the same router does today, on the
same antenna and the same cell, from two small changes. Happy to provide logs, dmesg
output or test any build you want.
