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.)
