Fibocom FM350-GL Support

another test with repo: git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git and the same:

root@OpenWrt:/nvme/work# opkg install kmod-mtk-t7xx_6.6.22-1_aarch64_cortex-a53.
ipk
Installing kmod-mtk-t7xx (6.6.22-1) to root...
Configuring kmod-mtk-t7xx.
[ 135.653447] kmodloader: loading kernel modules from /etc/modules.d/*
[ 135.666043] mtk_t7xx 0003:01:00.0: assign IRQ: got 113
[ 135.671289] mtk_t7xx 0003:01:00.0: enabling device (0000 -> 0002)
[ 135.677379] mtk_t7xx 0003:01:00.0: enabling bus mastering
[ 135.683891] (unnamed net_device) (dummy): netif_napi_add_weight() called with weight 128
[ 135.692977] mtk-pcie-gen3 11280000.pcie: msi#0x1 address_hi 0x0 address_lo 0x11280c00 data 1
[ 135.701526] mtk-pcie-gen3 11280000.pcie: msi#0x2 address_hi 0x0 address_lo 0x11280c00 data 2
[ 135.704997] Unable to handle kernel paging request at virtual address ffffffc08521f004
[ 135.709986] mtk-pcie-gen3 11280000.pcie: msi#0x3 address_hi 0x0 address_lo 0x11280c00 data 3
[ 135.717857] Mem abort info:
[ 135.717858] ESR = 0x0000000096000061
[ 135.717861] EC = 0x25: DABT (current EL), IL = 32 bits
[ 135.717864] SET = 0, FnV = 0
[ 135.717866] EA = 0, S1PTW = 0
[ 135.717867] FSC = 0x21: alignment fault

address is differrent but KERNEL PANIC still...

1 Like

Yeah, and still only 32-bit aligned, not 64-bit aligned as it probably has to be to work on non-x86 hardware...

Imho you should report this to netdev kernel mailing list as a first thing, and have all the authors of the driver in Cc. scripts/get_maintainer.pl tells me you should send your crashdump and report to:

Chandrashekar Devegowda <chandrashekar.devegowda@intel.com> (supporter:MEDIATEK T7XX 5G WWAN MODEM DRIVER)
Intel Corporation <linuxwwan@intel.com> (supporter:MEDIATEK T7XX 5G WWAN MODEM DRIVER)
Chiranjeevi Rapolu <chiranjeevi.rapolu@linux.intel.com> (reviewer:MEDIATEK T7XX 5G WWAN MODEM DRIVER)
Liu Haijun <haijun.liu@mediatek.com> (reviewer:MEDIATEK T7XX 5G WWAN MODEM DRIVER)
M Chetan Kumar <m.chetan.kumar@linux.intel.com> (reviewer:MEDIATEK T7XX 5G WWAN MODEM DRIVER)
Ricardo Martinez <ricardo.martinez@linux.intel.com> (reviewer:MEDIATEK T7XX 5G WWAN MODEM DRIVER)
Loic Poulain <loic.poulain@linaro.org> (maintainer:WWAN DRIVERS)
Sergey Ryazanov <ryazanov.s.a@gmail.com> (maintainer:WWAN DRIVERS)
Johannes Berg <johannes@sipsolutions.net> (reviewer:WWAN DRIVERS)
"David S. Miller" <davem@davemloft.net> (maintainer:NETWORKING DRIVERS)
Eric Dumazet <edumazet@google.com> (maintainer:NETWORKING DRIVERS)
Jakub Kicinski <kuba@kernel.org> (maintainer:NETWORKING DRIVERS)
Paolo Abeni <pabeni@redhat.com> (maintainer:NETWORKING DRIVERS)
netdev@vger.kernel.org (open list:MEDIATEK T7XX 5G WWAN MODEM DRIVER)
linux-kernel@vger.kernel.org (open list)
1 Like

I will try to inform netdev@vger.kernel.org and as Kuba suggested add also some debug info from decode_stacktrace.sh

also please have a look on that:
https://lists.openwall.net/netdev/2024/03/21/205

1 Like

I wonder if this patch fixes the alignment issue?

0001-net-wwan-t7xx-Split-64bit-accesses-to-fix-alignment-.patch
From 1ccdc96f2e83dacb8653f2c1935b378f86c660ed Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= <bjorn@mork.no>
Date: Fri, 22 Mar 2024 13:18:04 +0100
Subject: [PATCH] net: wwan: t7xx: Split 64bit accesses to fix alignment issues
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Some of the registers are aligned on a 32bit boundary, causing
alignment faults on 64bit platforms. The inclusion of
io-64-nonatomic-lo-hi.h indicates that all 64bit accesses can
be replaced by pairs of nonatomic 32bit access.  Fix alignment
by forcing all accesses to be 32bit on 64bit platforms too.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
 drivers/net/wwan/t7xx/t7xx_cldma.c     | 4 ++--
 drivers/net/wwan/t7xx/t7xx_hif_cldma.c | 4 ++--
 drivers/net/wwan/t7xx/t7xx_pcie_mac.c  | 8 ++++----
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wwan/t7xx/t7xx_cldma.c b/drivers/net/wwan/t7xx/t7xx_cldma.c
index 9f43f256db1d..f0a4783baf1f 100644
--- a/drivers/net/wwan/t7xx/t7xx_cldma.c
+++ b/drivers/net/wwan/t7xx/t7xx_cldma.c
@@ -106,7 +106,7 @@ bool t7xx_cldma_tx_addr_is_set(struct t7xx_cldma_hw *hw_info, unsigned int qno)
 {
 	u32 offset = REG_CLDMA_UL_START_ADDRL_0 + qno * ADDR_SIZE;
 
-	return ioread64(hw_info->ap_pdn_base + offset);
+	return ioread64_lo_hi(hw_info->ap_pdn_base + offset);
 }
 
 void t7xx_cldma_hw_set_start_addr(struct t7xx_cldma_hw *hw_info, unsigned int qno, u64 address,
@@ -117,7 +117,7 @@ void t7xx_cldma_hw_set_start_addr(struct t7xx_cldma_hw *hw_info, unsigned int qn
 
 	reg = tx_rx == MTK_RX ? hw_info->ap_ao_base + REG_CLDMA_DL_START_ADDRL_0 :
 				hw_info->ap_pdn_base + REG_CLDMA_UL_START_ADDRL_0;
-	iowrite64(address, reg + offset);
+	iowrite64_lo_hi(address, reg + offset);
 }
 
 void t7xx_cldma_hw_resume_queue(struct t7xx_cldma_hw *hw_info, unsigned int qno,
diff --git a/drivers/net/wwan/t7xx/t7xx_hif_cldma.c b/drivers/net/wwan/t7xx/t7xx_hif_cldma.c
index cc70360364b7..47e4dc9b7b91 100644
--- a/drivers/net/wwan/t7xx/t7xx_hif_cldma.c
+++ b/drivers/net/wwan/t7xx/t7xx_hif_cldma.c
@@ -139,7 +139,7 @@ static int t7xx_cldma_gpd_rx_from_q(struct cldma_queue *queue, int budget, bool
 				return -ENODEV;
 			}
 
-			gpd_addr = ioread64(hw_info->ap_pdn_base + REG_CLDMA_DL_CURRENT_ADDRL_0 +
+			gpd_addr = ioread64_lo_hi(hw_info->ap_pdn_base + REG_CLDMA_DL_CURRENT_ADDRL_0 +
 					    queue->index * sizeof(u64));
 			if (req->gpd_addr == gpd_addr || hwo_polling_count++ >= 100)
 				return 0;
@@ -318,7 +318,7 @@ static void t7xx_cldma_txq_empty_hndl(struct cldma_queue *queue)
 		struct t7xx_cldma_hw *hw_info = &md_ctrl->hw_info;
 
 		/* Check current processing TGPD, 64-bit address is in a table by Q index */
-		ul_curr_addr = ioread64(hw_info->ap_pdn_base + REG_CLDMA_UL_CURRENT_ADDRL_0 +
+		ul_curr_addr = ioread64_lo_hi(hw_info->ap_pdn_base + REG_CLDMA_UL_CURRENT_ADDRL_0 +
 					queue->index * sizeof(u64));
 		if (req->gpd_addr != ul_curr_addr) {
 			spin_unlock_irqrestore(&md_ctrl->cldma_lock, flags);
diff --git a/drivers/net/wwan/t7xx/t7xx_pcie_mac.c b/drivers/net/wwan/t7xx/t7xx_pcie_mac.c
index 76da4c15e3de..f071ec7ff23d 100644
--- a/drivers/net/wwan/t7xx/t7xx_pcie_mac.c
+++ b/drivers/net/wwan/t7xx/t7xx_pcie_mac.c
@@ -75,7 +75,7 @@ static void t7xx_pcie_mac_atr_tables_dis(void __iomem *pbase, enum t7xx_atr_src_
 	for (i = 0; i < ATR_TABLE_NUM_PER_ATR; i++) {
 		offset = ATR_PORT_OFFSET * port + ATR_TABLE_OFFSET * i;
 		reg = pbase + ATR_PCIE_WIN0_T0_ATR_PARAM_SRC_ADDR + offset;
-		iowrite64(0, reg);
+		iowrite64_lo_hi(0, reg);
 	}
 }
 
@@ -112,17 +112,17 @@ static int t7xx_pcie_mac_atr_cfg(struct t7xx_pci_dev *t7xx_dev, struct t7xx_atr_
 
 	reg = pbase + ATR_PCIE_WIN0_T0_TRSL_ADDR + offset;
 	value = cfg->trsl_addr & ATR_PCIE_WIN0_ADDR_ALGMT;
-	iowrite64(value, reg);
+	iowrite64_lo_hi(value, reg);
 
 	reg = pbase + ATR_PCIE_WIN0_T0_TRSL_PARAM + offset;
 	iowrite32(cfg->trsl_id, reg);
 
 	reg = pbase + ATR_PCIE_WIN0_T0_ATR_PARAM_SRC_ADDR + offset;
 	value = (cfg->src_addr & ATR_PCIE_WIN0_ADDR_ALGMT) | (atr_size << 1) | BIT(0);
-	iowrite64(value, reg);
+	iowrite64_lo_hi(value, reg);
 
 	/* Ensure ATR is set */
-	ioread64(reg);
+	ioread64_lo_hi(reg);
 	return 0;
 }
 
-- 
2.39.2
1 Like

This patch works and the kernel no longer panics

1 Like

@bmork Will you send the patch upstream and also add it as downstream patch in OpenWrt meanwhile?

ModemManager will very likely need some more work to use this modem in MBIM mode rather than using legacy AT command interface... You could try using umbim instead.

Edit: Looks like it's just our ModemManager which ends up not detecting the modem in MBIM mode or at least not utilizing it. See also


Is there a problem with this?

It probably just means that there are some status things the modem wants to send to the host but ModemManager (as the output has shown) doesn't keep the AT port open and doesn't deal with the MBIM port at all for some reason.

Done: https://lore.kernel.org/netdev/20240322144000.1683822-1-bjorn@mork.no/T/#u

seems like a lot of unnecessary work if this is accepted for stable. And if it isn't, then it's even more work cleaning up.

1 Like

Thank you!

I tend to agree, but I'm afraid that this is the only way to actually give it some testing, which might then again be something kernel maintainers (righteously) demand before merging it in stable.

thank you @bmork :slight_smile:

I have the same:

root@OpenWrt:~# dmesg |grep -i t7xx
[ 15.627214] mtk_t7xx 0003:01:00.0: assign IRQ: got 113
[ 15.632399] mtk_t7xx 0003:01:00.0: enabling device (0000 -> 0002)
[ 15.638488] mtk_t7xx 0003:01:00.0: enabling bus mastering
[ 16.348798] mtk_t7xx 0003:01:00.0: Packet drop on channel 0x1004, port not found
[ 16.356274] mtk_t7xx 0003:01:00.0: Packet drop on channel 0x1012, port not found
[ 21.228523] mtk_t7xx 0003:01:00.0: Port AT is not opened, drop packets
[ 22.119440] mtk_t7xx 0003:01:00.0: Port AT is not opened, drop packets
[ 22.125992] mtk_t7xx 0003:01:00.0: Port AT is not opened, drop packets
[ 22.143870] mtk_t7xx 0003:01:00.0: Port AT is not opened, drop packets
[ 22.356989] mtk_t7xx 0003:01:00.0: Packet drop on channel 0x100a, port not found
[ 66.397344] mtk_t7xx 0003:01:00.0: save config 0x00: 0x4d7514c3
[ 66.403280] mtk_t7xx 0003:01:00.0: save config 0x04: 0x00100406
[ 66.409191] mtk_t7xx 0003:01:00.0: save config 0x08: 0x0d400001
[ 66.415108] mtk_t7xx 0003:01:00.0: save config 0x0c: 0x00000000
[ 66.421017] mtk_t7xx 0003:01:00.0: save config 0x10: 0x2180000c
[ 66.426931] mtk_t7xx 0003:01:00.0: save config 0x14: 0x00000000
[ 66.432846] mtk_t7xx 0003:01:00.0: save config 0x18: 0x20800004
[ 66.438754] mtk_t7xx 0003:01:00.0: save config 0x1c: 0x00000000
[ 66.444667] mtk_t7xx 0003:01:00.0: save config 0x20: 0x2100000c
[ 66.450575] mtk_t7xx 0003:01:00.0: save config 0x24: 0x00000000
[ 66.456487] mtk_t7xx 0003:01:00.0: save config 0x28: 0x00000000
[ 66.462400] mtk_t7xx 0003:01:00.0: save config 0x2c: 0x35001cf8
[ 66.468308] mtk_t7xx 0003:01:00.0: save config 0x30: 0x00000000
[ 66.474219] mtk_t7xx 0003:01:00.0: save config 0x34: 0x00000080
[ 66.480127] mtk_t7xx 0003:01:00.0: save config 0x38: 0x00000000
[ 66.486039] mtk_t7xx 0003:01:00.0: save config 0x3c: 0x00000171
[ 66.492004] mtk_t7xx 0003:01:00.0: PME# enabled

root@BPI-R4:/# dmesg |grep -i wwan
[ 12.763440] usbcore: registered new interface driver qmi_wwan
[ 21.681896] wwan wwan0: port wwan0at0 attached
[ 21.686443] wwan wwan0: port wwan0mbim0 attached

root@BPI-R4:/# ls -ltr /dev/wwan*
crw------- 1 root root 241, 1 Mar 17 23:43 /dev/wwan0mbim0
crw------- 1 root root 241, 0 Mar 17 23:43 /dev/wwan0at0

It is stupid but if I run a simple command:
mmcli -m 0 --simple-connect="apn='internet'"

I see:
Status | lock: sim-pin2
| unlock retries: sim-pin2 (3)
| state: connected
| power state: on
| access tech: lte, 5gnr
| signal quality: 32% (recent)

But need to configure to use it


It is working for me on pcie :smiley:
The automatisation from modemmanager doesnt work for me so I created some scripts as for USB mode (with pci in name) and I put on my repo

I have the same but the modem works :slight_smile:

has anyone else the problem that its only work for the first boot?
if i reboot the router or unload and load the drivermodul the ports wwan0at0 and wwan0mbim0 are not comming up
only the fastboot port comes up then nothing else happend.
If i use the reset key or remove the powern then on the next boot its work

After software reboot:
root@BPI-R4:~# ls -ltr /dev/wwa*
ls: /dev/wwa*: No such file or directory
root@BPI-R4:~# mmcli -L
No modems were found

Maybe Im wrong but sometimes full power cycle restart is only way to fix the issue.

yes only a full power cycle restart work for me

what happend if the modem lost the connectivity (e.g. unplug the antenna) can your modem reconnect?

i have tested on windows and have the same problems so i think its a firmware problem.

boot + shutdown + boot = work
boot + reboot = not work (then after try shutdown windows cannot power of the pc)
standby + wake up = work after 1 minute

what firmware do you have?
my firmware is
firmware revision: 81600.0000.00.19.17.10_GC

this is a different case :slight_smile:
if the modem lose gsm connection <> devices are lost. you can always send some commands to restart your modem. first you can disable/enable it or perform reset and start over new connection and it should work...
my firmware is 81600.0000.00.29.18.01_GC C01
h/w revision: v1.0.6

Hmmm, when I put newest snapshot on the sd card, put to Banana PI R4. Then log, doing all opkg, install luci, etc. Then i install kmod t7xx and that is it. Connection is broken and then I need to install everything from scratch, so there is no luci, etc. When I repeat the excercise, the result is the same, wtf?