5G module over MHI PCI?

EPinci · March 30, 2025, 9:30pm

Hello,

can the BPI r4 access a 5g module with an MHI PCI driver instead of going in USB emulation? I have a patch that enables the RM520-GL to work in another mediatek based router but it does not pickup the module on the BPI r4.

Thank you.

xcaliber · March 31, 2025, 1:38am

You might find 4G modem (wwan0) on debian11 not working - #17 by Dot_Brian useful, I have it working with the same modem and the Quectel MHI PCI driver.

EPinci · March 31, 2025, 1:07pm

Looks like my issue is not with the MHI driver but with the 11280000.pcie slot not discovering at all the device… This ( [BPI-R4] how to activate key B PCIe2 @ 11280000? [solved] - Banana Pi Router design / BPI-R4(MT7988) - banana pi single board computer open source project official forum BPI team) seems to be the case but not sure how to apply it to openwrt-24.10 ToT.

frank-w · March 31, 2025, 1:11pm

which OS and kernel do you use?

EPinci · March 31, 2025, 1:14pm

I’m building my snapshot of OpenWRT from ToT of openwrt-24.10. Uses kernel 6.6.83 atm.

frank-w · March 31, 2025, 1:19pm

have you tried applying the patch you’ve linked above? do you have same errors in dmesg?

clockpatch should be already applied:

https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/mediatek/patches-6.6/252-clk-mediatek-mt7988-infracfg-fix-clocks-for-2nd-PCIe.patch;hb=HEAD

EPinci · March 31, 2025, 1:26pm

Uhm, now that you point me to it, that patch is already in openwrt-24.10 as well. Now I clueless…

frank-w · March 31, 2025, 1:28pm

the clock-patch yes, but not the one you’ve linked…

EPinci · March 31, 2025, 1:32pm

…? I’m lost here, the only patch I’m aware for pcie is the clock one. What other patch are you referring to?

What I can see in the logs, now is:

[    2.401071] mtk-pcie-gen3 11280000.pcie: host bridge /soc/pcie@11280000 ranges:
[    2.408424] mtk-pcie-gen3 11280000.pcie: Parsing ranges property...
[    2.414701] mtk-pcie-gen3 11280000.pcie:       IO 0x0020000000..0x00201fffff -> 0x0020000000
[    2.423149] mtk-pcie-gen3 11280000.pcie:      MEM 0x0020200000..0x0027ffffff -> 0x0020200000

and

[    2.763058] mtk-pcie-gen3 11280000.pcie: PCIe link down, current LTSSM state: polling.compliance (0x3000003)
[    2.772897] mtk-pcie-gen3: probe of 11280000.pcie failed with error -110

frank-w · March 31, 2025, 1:55pm

[BPI-R4] how to activate key B PCIe2 @ 11280000? [solved]

Kernel Patch

--- a/drivers/bus/mhi/host/pci_generic.c
+++ b/drivers/bus/mhi/host/pci_generic.c
@@ -356,6 +356,7 @@ static struct mhi_event_config mhi_quect
 static const struct mhi_controller_config modem_quectel_em1xx_config = {
        .max_channels = 128,
        .timeout_ms = 20000,
+       .ready_timeout_ms = 50000,
        .num_channels = ARRAY_SIZE(mhi_quectel_em1xx_channels),
        .ch_cfg = mhi_quectel_em1xx_channels,
        .num_events = ARRAY_SIZE(mhi_quectel_em1xx_events),

the one in the post you linked above

EPinci · March 31, 2025, 2:45pm

Rereading the whole post, for some reasons, it appears that a reboot is not enough for this to be recognized (???). This does really not add up to me but…

I powered down the r4 and now I get the device in lspci (no need for the timeout patch).
I patched the generic MHI driver to recognize the QCOM device ID or the RM520-GL and (not sure why, but…) it works.

frank-w · March 31, 2025, 2:51pm

it is possible that modem is recognized after reboot, but not on cold boot without this ready_timeout-patch

EPinci · March 31, 2025, 3:07pm

Looks like rebooting is working fine, with the exception of the modem pluging bouncing from “quectel” to “generic”, but still works. It could also be related only to that specific 5g module?

You know if it is normal to get this in the kernel log every 2 seconds (and how to turn it off)?

[  746.246180] mhi-pci-generic 0003:01:00.0: save config 0x00: 0x030817cb
[  746.252725] mhi-pci-generic 0003:01:00.0: save config 0x04: 0x00100402
[  746.259258] mhi-pci-generic 0003:01:00.0: save config 0x08: 0xff000000
[  746.265801] mhi-pci-generic 0003:01:00.0: save config 0x0c: 0x00000010
[  746.272318] mhi-pci-generic 0003:01:00.0: save config 0x10: 0x20200004
[  746.278850] mhi-pci-generic 0003:01:00.0: save config 0x14: 0x00000000
[  746.285371] mhi-pci-generic 0003:01:00.0: save config 0x18: 0x20201004
[  746.291889] mhi-pci-generic 0003:01:00.0: save config 0x1c: 0x00000000
[  746.298411] mhi-pci-generic 0003:01:00.0: save config 0x20: 0x00000000
[  746.304939] mhi-pci-generic 0003:01:00.0: save config 0x24: 0x00000000
[  746.311464] mhi-pci-generic 0003:01:00.0: save config 0x28: 0x00000000
[  746.317990] mhi-pci-generic 0003:01:00.0: save config 0x2c: 0x520117cb
[  746.324514] mhi-pci-generic 0003:01:00.0: save config 0x30: 0x00000000
[  746.331031] mhi-pci-generic 0003:01:00.0: save config 0x34: 0x00000040
[  746.337553] mhi-pci-generic 0003:01:00.0: save config 0x38: 0x00000000
[  746.344068] mhi-pci-generic 0003:01:00.0: save config 0x3c: 0x00000000
[  746.350651] mhi-pci-generic 0003:01:00.0: PME# enabled
[  747.019686] mhi-pci-generic 0003:01:00.0: PME# disabled
[  747.024936] mhi-pci-generic 0003:01:00.0: enabling bus mastering

xcaliber · March 31, 2025, 8:04pm

You may find this thread on the GL.inet forum useful, I certainly did!