Would have done that the problem is that the AT Port also does not come up anymore, my guess is that the fm-350 goes into some other mode and the t7xx cant pull it back to normal operation. Only a full power reset by pulling the plug helps.
Edit: Maybe there is a way by writing something in the pcie device setup in /sys/bus/pci/devices/0000:xx:xx/*. Tried it by echo 1 > ./reset and echo 1 > ./remove followed by a rescan. Both methods work, but they cant reset the device fully. So I cant recover it that way. So the devices stays in that strange state.
Alright found something, the modem goes into fastboot mode, if the driver disconnects, this can be due to reboot, crash etc. According to that post: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2049358 fixes for that where implemented in kernel 6.9.
Thanks for pointing this out. I did see this and a few other bug reports that didn't seem to be related to an issue I've run into with mine.
I've since been trying to get this working on a BPI-R64 where initially it worked but seems like ever since I can't get it to work properly and always ends up with a probe failure message in dmesg. lspci shows it fine and the mtk-t7xx module is active but nothing in mmcli. Here's a short excerpt:
I did initially try doing a pci reset and rescan but got the handshake timeouts like you.
What seemed to work for me at least with one try here (will definitely have to see if it is repeatable) is I went in and commented out the module in /etc/modules.d/mtk-t7xx so it won't automatically insert on boot. Rebooted and gave it a bit of time and manually ran modprobe and it pulled up fine. So may need to test and figure out timing and write a script for this.
Will try it. Thanks. Guess we have to wait for the updates, Openwrt normaly waits for the next LTS release. Maybe with 6.12-15 we will get the next big kernel update. With some luck we maybe get a 6.6 backport, if the changes for the t7xx on 6.9 are really that good.
I have made a unlock script. Not fully tested since my modem was unlocked.
It´s, more or less, a copy of ModemManger's and R00ter's script.
Package dependency: xxd and comgt.
Copy getrun_at.gcom and run_at.gcom, from my atc- package, to /etc/gcom/. Or install atc-fib-fm350_gl_2024-08-04-0.2_all.ipk.
Make sure no other application is using the AT-port.
Copy the script.
Make the script executable: chmod +x fm350_fcc_unlock.sh
Run the script with: ./fm350_fcc_unlock.sh /dev/ttyUSBx
fm350_fcc_unlock.sh
#!/bin/sh
#
# FCC unlock script for Fibocom FM350-GL modem
#
device=$1
VENDOR_ID_HASH="3df8c719"
atOut=$(COMMAND='AT+GTFCCEFFSTATUS?' gcom -d "$device" -s /etc/gcom/getrun_at.gcom | grep -o '[0-9,]\+')
mode_value=$(echo $atOut | awk -F ',' '{print $1}')
status_value=$(echo $atOut | awk -F ',' '{print $2}')
if [ "$mode_value" = '0' ]
then
echo 'Modem is unlocked!'
elif [ "$mode_value" = '1' -o "$mode_value" = '2' ]
then
xxd_installed=$(opkg info xxd | grep 'Status: install')
if [ -z "$xxd_installed" ]
then
echo 'xxd is not installed'
exit 1
fi
[ "$mode_value" = '1' ] && echo *The modem has a One time lock'
[ "$mode_value" = '2' ] && echo *The modem has a Power-up lock'
CHALLENGE=$(COMMAND='AT+GTFCCLOCKGEN' gcom -d "$device" -s /etc/gcom/getrun_at.gcom | grep -o '0x[0-9a-fA-F]\+' | awk '{print $1}')
if [ -n "$CHALLENGE" ]
then
echo 'Got challenge from modem: '$CHALLENGE
HEX_CHALLENGE=$(printf "%08x" "$CHALLENGE")
COMBINED_CHALLENGE="${HEX_CHALLENGE}$(printf "%.8s" "${VENDOR_ID_HASH}")"
RESPONSE_HASH=$(echo "$COMBINED_CHALLENGE" | xxd -r -p | sha256sum | cut -d ' ' -f 1)
TRUNCATED_RESPONSE=$(printf "%.8s" "$RESPONSE_HASH")
RESPONSE=$(printf "%d" "0x$TRUNCATED_RESPONSE")
echo 'Sending response to modem: '$RESPONSE
UNLOCK_RESPONSE=$(COMMAND='AT+GTFCCLOCKVER='$RESPONSE gcom -d "$device" -s /etc/gcom/getrun_at.gcom | grep -o '[0-9,]\+' | awk '{print $1}')
if [ "$UNLOCK_RESPONSE" = '1' ]; then
echo 'FCC unlock succeeded'
if [ "$mode_value" = '2' ]
then
atOut=$(COMMAND='AT+GTFCCLOCKMODE=0' gcom -d "$device" -s /etc/gcom/run_at.gcom)
[ "$atOut" = 'OK' ] && echo 'Power-up unlock succeeded' || echo 'Power-up unlock failed'
fi
else
echo 'Unlock failed.'
fi
else
echo 'Failed to obtain FCC challenge.'
fi
else
echo 'Make sure no application is using the AT-port: '$device
echo 'run AT+GTFCCEFFSTATUS? manually'
fi
However, when I tried the same setup on an RPi 5 with the latest OpenWRT snapshot, I encountered disconnections during the AT command setup (using picocom). Has anyone experienced this issue? Could you share the output of opkg list-installed?
I suspect that my issues could be related to the power supply. The dmesg log shows an "Over-current change" message, but I've also tried using an additional PD charger. It's possible that the RBPi 5 is sending a signal causing the modem to reset. Interestingly, I don't experience any similar issues when I connect the device directly to my laptop running ArchLinux.
Have the same problem with the bpi r4. Can be due to low voltage, because the modem needs more current than the bpi can deliver. Heat could also be a problem, most modems go into forced shutdown if the get warmer than 80°C. But I would tend more to that the driver for the mtk pcie 3.0 controller is also not 100% stable, i do not exp. this on my x86 platform. Despite x86 seems a bit more stable, the mtk-t7xx is still a mess there either.
But fixes for the mtk-t7xx should come with the next move to a newer LTS kernel.
For most of the modules,it will drain a high current to transmit the wireless signal.So your on board dc-dc converter(which converts power from your device to 3.3v) will work with loads,so it may make some noise.
But if you think your module is heating up too quick, you may need to check your antenna or module itself.
