AT+QCFG="pcie/mode"
+QCFG: "pcie/mode",0
OK
AT+QCFG="data_interface"
+QCFG: "data_interface",0,0
OK
AT+QCFG="usbnet"
+QCFG: "usbnet",0
OK
Is the pcie_mode:0 a problem?
Edit:
I updated AT+QCFG="data_interface",1,0 and we are back in business with the mhi interface.
No. This setting has nothing to do with PCIE mode. It is used for other purposes so you’re all set.
Yes as I said you were running in usb mode that’s why you got the wwan0 interface m.
This is a good read:
" AT+QCFG="pcie/mode"
AT+QCFG="pcie/mode",0AT+QCFG="pcie/mode",1https://github.com/iamromulan/RM520N-GL?tab=readme-ov-file#connection-methods
I just wanted to jump in and give a massive kudos for this. This got me going using a GLAP model (PCI only) on a generic x86 desktop motherboard running OpenWRT. The latest 23.05.4 and snapshots don't seem to have this fix in (not surprising giving the timestamps I'm seeing on the comments here) and experience the same issues where most of the /dev/wwan* devices appear but neither the MBIM, QMI, or ModemManager tools register the modem being available to use. Added this patch and the whole thing works 100% with some brief testing. So also an added confirmation on the RM520N-GLAP models as well. It comes up with the same Qualcomm vendor/device ID's.
The root complex mode isn't useful on a gl-x3000, but is a really interesting feature on the modem. It turns out you can configure it to act as the host, and attach an ethernet card to it as a pcie peripheral, to get a completely standalone modem interfaced over ethernet.
Glad it was helpful. Over the years, I've found the work the Openwrt team do on porting mainline(ish) linux to these kinds of devices incredibly useful; it's nice to be able to return the favour a bit!
It looks like my PR for running upstream u-boot on gl-x3000 is close to being merged in Openwrt too now.
Can you please expand on this ? Do you mean we can flash the stock glinet uboot with the upstream one ? What is the added benefits of using an upstream uboot?
To be honest, I wouldn't try to replace u-boot unless you have a very specific reason to want to, as getting anything wrong has a high risk of bricking the router sufficiently that you'd need to take it apart and connect a 3.3V serial console to recover it.
It's something that is mainly of interest to developers who want to hack on the bootloader itself or avoid any proprietary/non-free code on the device.
PS For your amusement, the process of porting u-boot looked something like this:
One of the more entertaining bugs I found along the way was in Arm trusted firmware, which turned out to have an alignment issue that reared its head when compiled with clang but not with gcc:
Was a tiny bit worrying when it wouldn't even boot as far as bl31 when I rebuilt the first time!
Interesting ! Thanks for sharing the details and screenshot!
I have used a serial cable long time ago to connect to my DrayTek DSL modem in order to bypass the protection and research vulnerabilities.
Now I am interested again to try to tinker around with my gl-x3000 utilizing your research! Something I will consider when I get some spare time from work, I need to get tweezers though for my serial cable.
That's the right kind of thing, although you need to make sure it's 3.3V serial not 5V or 1.8V. When you connect to the unpopulated header on the x3000, you want to connect the GND, RX and TX lines (GND to GND, TX to RX, RX to TX) but leave the V+ line disconnected. (This last part is quite important: that pin is intended for taking power from the x3000 serial interface, e.g. to power a little bluetooth serial adaptor or optical coupler, not for putting power into the board, which is what connecting the power-out pin of your cable would do.)
Just jumping in here again. This may not even be fully applicable to the discussion here but figured I would ask anyways given you all seem to have put in a bit of work with the RM520N-GL with some focus on the PCI side.
So the above patch did work to get the card to enumerate. And initial testing it was working great. However somewhere along the line now it is to where I can get a connection established fine with ModemManager in stock OpenWRT and it gets the expected V6 and V4 addresses and associated routes. But no packets are transferred at all. Or more specifically after reviewing a tcpdump log, DNS queries are tried, ICMP's are tried, and even doing a quick wget test to a known V4 and V6 address and not a hostname, nothing comes back at all. I've even provided manual DNS address in the form of both of Google's V6 and V4 addresses.
root@OpenWrt:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-lan state UP qlen 1000
link/ether 2c:cf:67:83:69:79 brd ff:ff:ff:ff:ff:ff
3: mhi_swip0: <POINTOPOINT,NOARP> mtu 16384 qdisc noop state DOWN qlen 1000
link/[519]
4: mhi_hwip0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 1000
link/[519]
inet 192.0.0.2/27 brd 192.0.0.31 scope global mhi_hwip0
valid_lft forever preferred_lft forever
inet6 2607:fb91:16a3:4dee:c4ce:abae:c501:5801/128 scope global
valid_lft forever preferred_lft forever
inet6 fe80::200:ff:fe00:0/64 scope link
valid_lft forever preferred_lft forever
5: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 2c:cf:67:83:69:7a brd ff:ff:ff:ff:ff:ff
6: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 2c:cf:67:83:69:79 brd ff:ff:ff:ff:ff:ff
inet 172.17.17.1/24 brd 172.17.17.255 scope global br-lan
valid_lft forever preferred_lft forever
inet6 2607:fb91:16a3:4dee::1/64 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 fd2f:5a2c:e402::1/60 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 fe80::2ecf:67ff:fe83:6979/64 scope link
valid_lft forever preferred_lft forever
root@OpenWrt:~# ip r
default via 192.0.0.1 dev mhi_hwip0 src 192.0.0.2
172.17.17.0/24 dev br-lan scope link src 172.17.17.1
192.0.0.0/27 dev mhi_hwip0 scope link src 192.0.0.2
root@OpenWrt:~# ip -6 r
default from 2607:fb91:16a3:4dee::/64 via 2607:fb91:16a3:4dee:ac11:871c:647:e91b dev mhi_hwip0 metric 1024
2607:fb91:16a3:4dee:ac11:871c:647:e91b dev mhi_hwip0 metric 1024
2607:fb91:16a3:4dee:c4ce:abae:c501:5801 dev mhi_hwip0 metric 256
2607:fb91:16a3:4dee::/64 dev br-lan metric 1024
unreachable 2607:fb91:16a3:4dee::/64 dev lo metric 2147483647
fd2f:5a2c:e402::/64 dev br-lan metric 1024
unreachable fd2f:5a2c:e402::/48 dev lo metric 2147483647
fe80::/64 dev br-lan metric 256
fe80::/64 dev mhi_hwip0 metric 256
anycast 2607:fb91:16a3:4dee:: dev br-lan metric 0
anycast fd2f:5a2c:e402:: dev br-lan metric 0
anycast fe80:: dev br-lan metric 0
anycast fe80:: dev mhi_hwip0 metric 0
multicast ff00::/8 dev br-lan metric 256
multicast ff00::/8 dev mhi_hwip0 metric 256
root@OpenWrt:~#
I did give the original Quectel driver/utilities a go per the original instructions in the OP and that worked perfect. This is now testing on both my original x86 device and a Raspberry Pi 5 with this RM520N-GLAP. Latest OpenWRT snapshots.
One other person posted about this on the OpenWRT forums which I've chimed in on as well and looks like both of us are at a loss on this one at the moment. Need Help: RM520NGL-AP, Openwrt, and cellular connectivity - Installing and Using OpenWrt - OpenWrt Forum
Just curious if maybe anyone else has seen this yet or at the very least has suggestions where to troubleshoot. I'm all for doing some of my own troubleshooting legwork but have exhausted the obvious options I can currently think of. 
If ModemManager connects successfully, then the issue could be related to the underlaying binary invoked by MM (e.g.qmicli, mbimcli.. etc).
Did you try to set the modem to MBIM vs QMI? Also you can try to change the protocol type from list menu to unsupported and see if MM connects correctly.
One last tip! Before spending so much time troubleshooting MM, first make sure the connection can be established correctly using mbimcli.
In the ip address output you give, there are mhi_swip0 and mhi_hwip0 interfaces instead of a wwan0 interface.
For me, this is what happens if the modem is recognised as a generic qcom-sdx65m instead of a quectel-rm5xx, e.g. before I apply my patch. I also see that in dmesg, where it used to read
mhi-pci-generic 0000:01:00.0: MHI PCI device found: qcom-sdx65m
instead of
mhi-pci-generic 0000:01:00.0: MHI PCI device found: quectel-rm5xx
now its working with the patch to add the right PCI ID. Is your modem definitely being recognised as a quectel-rm5xx?
Putting this here for want of a better place. The 6.11 kernel has been out for about three hours, so I've updated my GitHub - arachsys-hosts/gl-x3000: Build recipe for GL-X3000 router recipe to use linux 6.11 and refreshed all the patches. Linux 6.11 runs nicely on these devices if anyone else is eccentric enough to be running mainline!
# uname -a
Linux router 6.11.0 #1 SMP PREEMPT Sun Sep 15 19:28:20 BST 2024 aarch64 GNU/Linux
#
Thanks for great work, and for sharing it !
Can we use your receipt build script to flash it minus the uboot? Or uboot is needed to be able to boot at specific offset ?
Can I recover GL stock uboot and firmware without serial uart?
Yeah, the interface names threw me as well. But so weird. Just checked and it's still showing as an sdx65m
root@OpenWrt:~# dmesg | grep MHI
[ 6.659791] mhi-pci-generic 0000:01:00.0: MHI PCI device found: qcom-sdx65m
I'll have to re-check my source tree and see what's going on. Everything looks to be good there. (FYI I haven't updated the patch to take care of the sequence number glitch lines)
cr08@OpenWRT-Dev-Debian:/mnt/LXC-Bulk/openwrt-pi5$ cat ./target/linux/generic/pending-6.6/101-rm520n-fix.patch
diff --git a/drivers/bus/mhi/host/pci_generic.c b/drivers/bus/mhi/host/pci_generic.c
index 08844ee7..7043d366 100644
--- a/drivers/bus/mhi/host/pci_generic.c
+++ b/drivers/bus/mhi/host/pci_generic.c
@@ -620,6 +620,9 @@ static const struct pci_device_id mhi_pci_id_table[] = {
.driver_data = (kernel_ulong_t) &mhi_telit_fn980_hw_v1_info },
{ PCI_DEVICE(PCI_VENDOR_ID_QCOM, 0x0306),
.driver_data = (kernel_ulong_t) &mhi_qcom_sdx55_info },
+ /* RM520N-GL variant with Qualcomm vendor and subvendor ID */
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_QCOM, 0x0308, PCI_VENDOR_ID_QCOM, 0x5201),
+ .driver_data = (kernel_ulong_t) &mhi_quectel_rm5xx_info },
/* Telit FN990 */
{ PCI_DEVICE_SUB(PCI_VENDOR_ID_QCOM, 0x0308, 0x1c5d, 0x2010),
.driver_data = (kernel_ulong_t) &mhi_telit_fn990_info },
Actual build source:
./build_dir/target-aarch64_cortex-a76_musl/linux-bcm27xx_bcm2712/linux-6.6.50/drivers/bus/mhi/host/pci_generic.c
/* Keep the list sorted based on the PID. New VID should be added as the last entry */
static const struct pci_device_id mhi_pci_id_table[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_QCOM, 0x0304),
.driver_data = (kernel_ulong_t) &mhi_qcom_sdx24_info },
{ PCI_DEVICE_SUB(PCI_VENDOR_ID_QCOM, 0x0306, PCI_VENDOR_ID_QCOM, 0x010c),
.driver_data = (kernel_ulong_t) &mhi_foxconn_sdx55_info },
/* EM919x (sdx55), use the same vid:pid as qcom-sdx55m */
{ PCI_DEVICE_SUB(PCI_VENDOR_ID_QCOM, 0x0306, 0x18d7, 0x0200),
.driver_data = (kernel_ulong_t) &mhi_sierra_em919x_info },
/* Telit FN980 hardware revision v1 */
{ PCI_DEVICE_SUB(PCI_VENDOR_ID_QCOM, 0x0306, 0x1C5D, 0x2000),
.driver_data = (kernel_ulong_t) &mhi_telit_fn980_hw_v1_info },
{ PCI_DEVICE(PCI_VENDOR_ID_QCOM, 0x0306),
.driver_data = (kernel_ulong_t) &mhi_qcom_sdx55_info },
/* RM520N-GL variant with Qualcomm vendor and subvendor ID */
{ PCI_DEVICE_SUB(PCI_VENDOR_ID_QCOM, 0x0308, PCI_VENDOR_ID_QCOM, 0x5201),
.driver_data = (kernel_ulong_t) &mhi_quectel_rm5xx_info },
/* Telit FN990 */
{ PCI_DEVICE_SUB(PCI_VENDOR_ID_QCOM, 0x0308, 0x1c5d, 0x2010),
.driver_data = (kernel_ulong_t) &mhi_telit_fn990_info },
/* Telit FE990 */
{ PCI_DEVICE_SUB(PCI_VENDOR_ID_QCOM, 0x0308, 0x1c5d, 0x2015),
.driver_data = (kernel_ulong_t) &mhi_telit_fn990_info },
And just for completeness:
0000:01:00.0 Unassigned class [ff00]: Qualcomm Technologies, Inc Device 0308
Subsystem: Qualcomm Technologies, Inc Device 0308
Flags: bus master, fast devsel, latency 0, IRQ 158
Memory at 1b00000000 (64-bit, non-prefetchable) [size=4K]
Memory at 1b00001000 (64-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable+ Count=1/32 Maskable+ 64bit+
Capabilities: [70] Express Endpoint, IntMsgNum 0
Capabilities: [100] Advanced Error Reporting
Capabilities: [148] Secondary PCI Express
Capabilities: [168] Physical Layer 16.0 GT/s <?>
Capabilities: [18c] Lane Margining at the Receiver
Capabilities: [19c] Transaction Processing Hints
Capabilities: [228] Latency Tolerance Reporting
Capabilities: [230] L1 PM Substates
Capabilities: [240] Data Link Feature <?>
Kernel driver in use: mhi-pci-generic
Weird that it worked fine initially but is just now failing even on the original device where it worked. I imagine this will resolve the issue if I can figure out why it doesn't seem to be taking effect.
EDIT: Think I may have spotted something with the subsytem device ID and thinking in all of my own testing I may have been on my own wild goose chase all along. Making some tweaks and recompiling and will report back!
Alrighty! Mystery solved. I'm thinking I just went on my own long winded wild goose chase and it never worked properly to begin with but I had a separate WAN connection available fooling me into seeing data transfer. 
Looking over things and the logs I just posted, it seems the GLAP (at least my specific card) is using a different subvendor ID of 0308 instead of 5201. I swapped that out in the patch and it picked it up correctly with the appropriate wwan interface and wwan device ID's with the AT port now finally showing.
Unfortunately still having some issues getting a connection established both with MBIM and now ModemManager. But I still need to do more testing here before I post anything further. Didn't have much time to do thorough checks last night after I updated my build.
Going forward, I'm happy to continue this discussion over on the OpenWRT thread since I see you've commented there @ChrisW and the GLAP cards seem to be out of the scope of the X3000 being discussed here which, as best I can tell, comes with the AA variant. I'm just thinking there may be some potential differences in the variants at play other than just the subvendor change. After all the AP's are normally intended for system integrators/OEMs and even Quectel is a bit cagey about providing firmware updates on their forum and seems to be referring users to their carriers/vendors.
thank you all for your great work. i am really happy now with my spitz.
i found an interesting repository on github:
(GitHub - 4IceG/Modem-extras: Packages added to my images | MY REPOSITORY | Updated: 22.05.2024)