5G module over MHI PCI?

[EPinci]

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]

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]

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]

which OS and kernel do you use?

[EPinci]

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

[frank-w]

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]

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

[frank-w]

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

[EPinci]

…? 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]

@ibada

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]

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]

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

[EPinci]

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]

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

How-To: Installing Vanilla OpenWRT on GL X3000

[EPinci]

I think you might be right.
Without the ready_delay the modem starts but… flaps between being recognized as “quectel” or “generic”. With the ready_delay in place, it’s stably “quectel”.

[EPinci]

DEFINITELY useful!