As title, I’m using the latest ‘supplied’ fw but my Quectel RM551E-GL 5G card is not recognised or found in any of the M2 sockets (USB only or USB/PCIe sockets) on the top of the board.
I read there is possibly some issue about USB not being found, but could someone advise me…
You have to make sure pcie lanes are switched to key-b…in my dts aply the overlay for the right pcie slot (cnX)
Thanks. Could you elaborate a bit please?
Also, I want to use a usb connection to the RM551E-GL, not Pcie, if possible…
This likely means you need to modify the GPIO level to select which interface the PCIe signal goes to. However, you might need to check if the module only uses USB signals and not PCIe signals.
Thanks. The RM551E-GL can be connected over both PCIe and USB. Please advise me how to apply the overlay for the right slot - I am afraid I don’t know what you mean… Or if you can tell me of a wiki to read, that would be great, thanks!
There’s also a forum about the RM551E-GL here, but I think you should check the image driver first.
Same thing I can’t get to recognize on the system I try lsusb and Lspci and I can’t find the modem ?
BPI-R4 Pro 8X – RM551E-GL modem on CN15
I found the reason the Quectel RM551E-GL modem installed in the CN15 M.2 B-Key slot was not detected by OpenWrt.
The USB configuration itself is working correctly. The board detects both VIA USB hubs:
2109:2822 VIA Labs USB2.0 Hub 2109:0822 VIA Labs USB3.1 Hub
CN15 is connected through this USB hub path. It is not necessary to disable PCIe2 or change xphyu3port0 from PCIe to USB3.
The problem appears to be the CN15 power/control signals provided by the PCA9555 GPIO expander at I2C address 0x20.
According to the BPI-R4 Pro 8X hardware mapping, the relevant PCA9555 lines for CN15 / BKEY-A are:
PCA9555 GPIO 0 (IO0_0) = BKEY-A-PDN PCA9555 GPIO 1 (IO0_1) = BKEY-A-Vset PCA9555 GPIO 11 (IO1_3) = BKEY-A-RST
The current DTS defines the PCA9555, but does not establish the required CN15 power/VSET/reset output states.
Initially, the PCA9555 configuration registers were:
0x06 = 0xff 0x07 = 0xff
This means the GPIOs were configured as inputs.
After configuring the required PCA9555 outputs, the relevant registers became:
0x02 = 0xff 0x03 = 0xf7 0x06 = 0xfc 0x07 = 0xf7
After this change, the RM551E-GL immediately appeared in lsusb:
Bus 004 Device 003: ID 2c7c:0122 Quectel Wireless Solutions Co., Ltd. RM551E-GL
Linux successfully created:
/dev/ttyUSB0 /dev/ttyUSB1 /dev/ttyUSB2 /dev/ttyUSB3 /dev/cdc-wdm0 wwan0
The kernel also successfully attached qmi_wwan:
qmi_wwan 4-1.1:1.4: cdc-wdm0: USB WDM device qmi_wwan 4-1.1:1.4 wwan0: register ‘qmi_wwan’ at usb-11200000.usb-1.1
The modem responds correctly to AT commands:
ATI
Quectel RM551E-GL Revision: RM551EGL00AAR01A02M8G
OK
AT+QTEMP also returns valid modem temperature readings.
Suggested permanent OpenWrt fix:
The BPI-R4 Pro 8X DTS/device configuration should initialize the PCA9555 CN15/BKEY-A control signals automatically during boot instead of requiring manual I2C writes.
Relevant signals:
GPIO 0 = BKEY-A-PDN GPIO 1 = BKEY-A-Vset GPIO 11 = BKEY-A-RST
It would also be useful to add gpio-line-names for the PCA9555 so these board-specific signals are clearly identified.
The BPI-R4 Pro 8X firmware/device profile should ensure that the PCA953x/PCA9555 GPIO driver (kmod-gpio-pca953x) is included and bound.
Important:
The problem does not appear to be the MT7988 USB3/PCIe SerDes sharing.
ssusb1 and the VIA VL822 USB3 hub are already operational. Once CN15 is powered/configured through the PCA9555, the RM551E-GL enumerates successfully through the VIA USB3 hub.
Therefore, the required fix appears to be CN15 PCA9555 power/VSET/reset initialization at boot, rather than changing the USB/PCIe PHY configuration.
The exact VSET level should be verified against the BPI-R4 Pro 8X schematic and the modem hardware requirements before making it a universal firmware default.
Hardware tested:
Board: Banana Pi BPI-R4 Pro 8X OS: OpenWrt 25.12-SNAPSHOT Modem: Quectel RM551E-GL USB ID: 2c7c:0122 Modem firmware: RM551EGL00AAR01A02M8G Slot: CN15 M.2 B-Key
With the PCA9555 configuration applied, the modem works correctly over USB/QMI.
Thank you ChatGPT for the help and get it working
Have you configures in dts or via sysfs? Can you share your changes?
BPI-R4 Pro 8X – CN15 / Quectel RM551E-GL 5G Modem Workaround
Hardware: Board: Banana Pi BPI-R4 Pro 8X Slot: CN15 M.2 B-Key Modem: Quectel RM551E-GL USB ID: 2c7c:0122 Modem firmware: RM551EGL00AAR01A02M8G OS: OpenWrt 25.12-SNAPSHOT
PROBLEM
The Quectel RM551E-GL installed in CN15 was initially not detected by OpenWrt.
The modem did not appear in lsusb.
The USB controllers and VIA USB hubs themselves were working correctly.
The BPI-R4 Pro 8X has a PCA9555 GPIO expander at:
I2C bus: 3 I2C address: 0x20
I checked the PCA9555 registers with:
i2cget -y 3 0x20 0x02 i2cget -y 3 0x20 0x03 i2cget -y 3 0x20 0x06 i2cget -y 3 0x20 0x07
Before making the change, the result was:
0x02 = 0xff 0x03 = 0xff 0x06 = 0xff 0x07 = 0xff
PCA9555 registers 0x06 and 0x07 are the GPIO configuration registers.
For the PCA9555:
1 = input 0 = output
Therefore 0xff means all GPIOs on the corresponding port were configured as inputs.
According to the BPI-R4 Pro 8X hardware mapping, CN15/BKEY-A uses:
PCA9555 GPIO 0 / IO0_0 = BKEY-A-PDN PCA9555 GPIO 1 / IO0_1 = BKEY-A-Vset PCA9555 GPIO 11 / IO1_3 = BKEY-A-RST
These signals need to be configured as outputs for CN15.
The PCA9555 was configured manually using i2cset.
The commands used were:
i2cset -y 3 0x20 0x02 0xff i2cset -y 3 0x20 0x03 0xf7 i2cset -y 3 0x20 0x06 0xfc i2cset -y 3 0x20 0x07 0xf7
The register changes were therefore:
Before:
0x02 = 0xff 0x03 = 0xff 0x06 = 0xff 0x07 = 0xff
After:
0x02 = 0xff 0x03 = 0xf7 0x06 = 0xfc 0x07 = 0xf7
The relevant GPIO configuration is:
0x06 = 0xfc
This changes IO0_0 and IO0_1 from inputs to outputs.
IO0_0 = BKEY-A-PDN IO0_1 = BKEY-A-Vset
0x07 = 0xf7
This changes IO1_3 from input to output.
IO1_3 = BKEY-A-RST
The resulting output states are:
BKEY-A-PDN = HIGH BKEY-A-Vset = HIGH BKEY-A-RST = LOW
After making the change, I checked the registers again:
i2cget -y 3 0x20 0x02 0xff
i2cget -y 3 0x20 0x03 0xf7
i2cget -y 3 0x20 0x06 0xfc
i2cget -y 3 0x20 0x07 0xf7
After configuring the PCA9555, I checked:
lsusb
The modem appeared:
Bus 004 Device 003: ID 2c7c:0122 Quectel Wireless Solutions Co., Ltd. RM551E-GL
The VIA USB hubs were also present:
2109:2822 VIA Labs, Inc. USB2.0 Hub 2109:0822 VIA Labs, Inc. USB3.1 Hub
lsusb -t showed that the VIA USB3 hub is operating at SuperSpeed.
Therefore the CN15 USB connection is working through the onboard VIA USB hub.
There was no need to:
The existing USB configuration is capable of detecting the modem once CN15 is powered/configured correctly.
After the PCA9555 change, OpenWrt created:
/dev/ttyUSB0 /dev/ttyUSB1 /dev/ttyUSB2 /dev/ttyUSB3
/dev/cdc-wdm0
wwan0
The kernel reported:
qmi_wwan 4-1.1:1.4: cdc-wdm0: USB WDM device
qmi_wwan 4-1.1:1.4 wwan0: register ‘qmi_wwan’ at usb-11200000.usb-1.1, WWAN/QMI device
/dev/ttyUSB2 was tested as the modem AT command port.
ATI returned:
Quectel RM551E-GL Revision: RM551EGL00AAR01A02M8G
OK
AT+QTEMP also works and returns valid internal modem temperature sensors.
CONCLUSION
The RM551E-GL modem itself and the CN15 USB3 connection were working correctly.
The reason the modem did not initially appear in lsusb was that the required CN15/BKEY-A PCA9555 GPIO control lines were not configured as outputs.
The working manual configuration is:
i2cset -y 3 0x20 0x02 0xff i2cset -y 3 0x20 0x03 0xf7 i2cset -y 3 0x20 0x06 0xfc i2cset -y 3 0x20 0x07 0xf7
After these commands, the RM551E-GL appears as:
2c7c:0122 Quectel Wireless Solutions Co., Ltd. RM551E-GL
and OpenWrt successfully creates the ttyUSB ports, cdc-wdm0 and wwan0.
SUGGESTED PERMANENT FIX
The BPI-R4 Pro 8X OpenWrt DTS/board initialization should configure the CN15/BKEY-A PCA9555 lines automatically during boot.
The relevant PCA9555 signals are:
GPIO 0 / IO0_0 = BKEY-A-PDN GPIO 1 / IO0_1 = BKEY-A-Vset GPIO 11 / IO1_3 = BKEY-A-RST
The required working states in my test were:
BKEY-A-PDN = HIGH BKEY-A-Vset = HIGH BKEY-A-RST = LOW
It would also be useful to add gpio-line-names to the PCA9555 DTS node and ensure that the PCA953x/PCA9555 GPIO driver is included in the BPI-R4 Pro 8X firmware.
The exact VSET voltage/default should be verified against the BPI-R4 Pro 8X schematic and modem specifications before making it a universal firmware default.
The important point is that the fix is related to CN15 PCA9555 power/control initialization, not the MT7988 USB3/PCIe PHY configuration.
I can try adding named gpios in my kernel…which image/kernel do you use? I wonder that only put them to output works as at least reset is normally a sequence where the pin is set 2 times in different output value. And also wonder that pcie is detected while you do your changes in userspace…later than pcie initialization (mtk pcie does not support hotswap).
This one
I’d like to help, but I don’t have an X8 available right now, and I won’t give any advice without actually testing it. But I’d probably start by trying to get the module running in CN18, even though the temperature conditions aren’t ideal for it there. CN18 doesn’t require any specific DTS hogs settings or other configurations that are required for CN15. I don’t know if there’s an NVMe drive on the board or not, and if so, in which CN slot.
Thx for replay No I I didn’t use NVMe for boot , I use sd card and I only have WiFi 7 module and 5G modem .
