Hey guys,
I would like to get this HAT working on my Pi3 without the use of the external USB cable:
When I do use the external USB cable, the modem automatically shows up in the balenaOS using “mmcli -L”
When I don’t use the cable, the modem is not recognised (even though it is properly powered).
Any way to do this?
Thanks for helping!
Gr, Frans
Hi, in lack of schematics for this, I found https://github.com/sixfab/Sixfab_PPP_Installer/tree/master/ppp_installer
And in there, there are a bunch of reconnect scripts which you should check and see how to bring the modem up (for example in https://github.com/sixfab/Sixfab_PPP_Installer/blob/master/ppp_installer/reconnect_cellulariot they state that gpio 17 is to bring the modem out of reset and gpio 24 is to power on the modem). You would need to export from userspace for example and set the gpios they use there. But you should really have a schematics for this, otherwise parse the above and see which one do the job.
Ok thanks. I will look into that!
My mail concern is that modemmanager might not pick up this modem because it will communicate over UART instead of USB. Is this a legit concern?
Hi, as long as you look into the above info, you shouldn’t have any more issues, but please come back to us if you do!
Update, because I am making progress:
The modem is now working if I follow these instructions:
Additionally, I can use minicom to connect to the modem on ttyAMA0 and send AT commands & get a response. Super!
Therefore I know that the hardware is working, and the modem is up (no additional GPIO switching is needed).
I would however like the modem to be recognised & controlled by modem manager, from the hostOS (so that connectivity is not controlled from the container, for obvious reasons).
Therefore, is there a way for me to see why modemmanager is not recognising this modem? I am sure it is supported, because if I use the USB cable it is recognised instantly.
(PS: some other forum said I needed to set the following udev rule, which I did. Too bad this didn’t help:)
ACTION=="add",KERNEL=="ttyAMA0",ENV{ID_MM_PLATFORM_DRIVER_PROBE}="1"
Awesome news, thanks for the heads up
Any help on how to debug modemmanager in this case would be highly appreciated!
Hi Frans, based on your previous message, it sounded like the modem was working, if you used their install.sh script. What is not working, or, more precisely, what do you need to debug in modemmanager exactly? Any extra information you can provide would help us get you moving in the right direction. Thanks.
I am sorry for the confusion. Let me elaborate:
Goal:
Current Status:
mmcli -L returns no modems).Context:
mmcli -S), ModemManager (debug)logs are showing:ModemManager[704]: (tty/ttyAMA0): adding device at sysfs path: /sys/devices/platform/soc/3f201000.serial/tty/ttyAMA0ModemManager[704]: [filter] (tty/ttyAMA0): port filtered: tty platform driver
My question to you:
How can I find out WHY ModemManager is not recognising my modem on ttyAMA0? And how can I fix it…
Can any of you help?
Much appreciated!
Hi, thanks for contacting support.
The line:
ModemManager[704]: [filter] (tty/ttyAMA0): port filtered: tty platform driver
suggests that the port is being filtered by MM and it is not being probed.
The approach of flagging the platform TTY should work. I would also suggest trying a flag the serial platform device, with something like:
ACTION=="add", KERNEL=="3f201000.serial", ENV{ID_MM_PLATFORM_DRIVER_PROBE}="1"
Please check that the flag is applied with:
udevadm info /sys/devices/platform/soc/3f201000.serial
If so, then check that mmcli -L can see the modem.
As a side note, according to MM documentation at https://www.freedesktop.org/software/ModemManager/api/1.8.0/ref-overview-modem-filter.html, the ID_MM_PLATFORM_DRIVER_PROBE is kept for backward compatibility. The ID_MM_DEVICE_PROCESS flag replaces it.
Did some testing, but I am getting some really inconsistent results. Its driving me crazy:
I have tried applying the mentioned rule. At first it was being applied (checked with udevadm), currently it is not being applied. No clue what changed. I only rebooted in between.
I have also tried applying the following 2 udev rules at the same time:
ACTION=="add", KERNEL=="3f201000.serial", ENV{ID_MM_PLATFORM_DRIVER_PROBE}="1"
ACTION=="add", KERNEL=="ttyAMA0", ENV{ID_MM_PLATFORM_DRIVER_PROBE}="1"
This helped a little, it made MM pick up on ttyAMA0 once. I saw in the logs that MM actually scanning ttyAMA0 and was sending AT commands to the modem. Sadly it dit not recognise the modem. Have not been able to reproduce this since.
Currently the MM logs are stating the following again 
:
[filter] (tty/ttyAMA0): port filtered: tty platform driver
Current output from udevadm info /sys/devices/platform/soc/3f201000.serial is:
P: /devices/platform/soc/3f201000.serial
L: 0
E: DEVPATH=/devices/platform/soc/3f201000.serial
E: DRIVER=uart-pl011
E: OF_NAME=serial
E: OF_FULLNAME=/soc/serial@7e201000
E: OF_COMPATIBLE_0=brcm,bcm2835-pl011
E: OF_COMPATIBLE_1=arm,pl011
E: OF_COMPATIBLE_2=arm,primecell
E: OF_COMPATIBLE_N=3
E: OF_ALIAS_0=serial0
E: OF_ALIAS_1=uart0
E: AMBA_ID=00241011
E: MODALIAS=amba:d00241011
E: SUBSYSTEM=amba
Would any of the Balena Support crew maybe be able to login to my device to help me find whats going wrong? https://dashboard.balena-cloud.com/devices/eb6f6c5b078728803eae7c1adbd5ee6b/summary
Thanks
Hi, one of my teammates mentioned that v1.12.0 removed the ID_MM_PLATFORM_DRIVER_PROBE - https://gitlab.freedesktop.org/mobile-broadband/ModemManager/commit/f6d5490eebd22d2ce679442b03a72e110d113fa9.
ID_MM_DEVICE_PROCESS should be used instead:
ACTION=="add", KERNEL=="3f201000.serial", ENV{ID_MM_DEVICE_PROCESS}="1"
ACTION=="add", KERNEL=="ttyAMA0", ENV{ID_MM_DEVICE_PROCESS}="1"
Since this is a test device I will take the opportunity to apply the change, reboot the device and see what happens.
Will get back to you in a bit,
Zahari
Hi Zahari, thanks for helping me.
Yeah Im sure I tried ID_MM_DEVICE_PROCESS as well, but since the device behaviour was (in my eyes) not consistent I was also just trying/debugging.
Feel free to do anything to the device. It is indeed a test device.
Modem is connected to the device with antenna.
That did not work either.
I think at this point it is best to contact the ModemManager developers on their modemmanager-devel mailing list. They are quite friendly and will provide useful insights. At least we will know whether this is currently possible under ModemManager - hopefully this is something that could be resolved through configuration only.
You may provide them with the ModemManager version used + full debug logs.
Before doing so however, can you please test with the latest balenaOS v2.47.0, since it includes the latest ModemManager update? There is a slight chance we can get lucky.
BTW, this is a really nice piece of hardware - quite useful for RPi users.
Please let us know if you have any questions.
Zahari
Thanks @majorz, I emailed the main contributor to the github repo https://github.com/aleksander0m.
Will keep you updated!
(ps: updating to 2.47 didn’t help)
Trying to do the same on RPi 4 and the same 6fab hat. I’ll follow your path, and see if I can reproduce or find a solution. Thanks for doing some of the leg work! Will report back soon…
As @majorz said, the way to go is to tag the device with the ID_MM_DEVICE_PROCESS tag, so that the implicit whitelist rule allows the port to be probed and used. Tagging by the port name isn’t ideal though, you should better tag based on the devpath. What is the output of this command?
$ realpath /sys/class/tty/ttyAMA0
Hi @aleksander0m, thanks for helping with this!
The output of the command realpath /sys/class/tty/ttyAMA0
is
/sys/devices/platform/soc/3f201000.serial/tty/ttyAMA0
Would you be able to explicitly state here which udev rule(s) I need to set?
Thanks!
Try this:
ACTION!="add|change|move|bind", GOTO="mm_whitelist_end"
DEVPATH=="/devices/platform/soc/3f201000.serial" ENV{ID_MM_DEVICE_PROCESS}="1"
LABEL="mm_whitelist_end"
Then make sure you reboot to get the rule applied.
Thanks!