Hat jemand ein M.2 5G-Modem FM350-GL (von Fibocom/Mediatek/Intel) zum Laufen gebracht?

Wenn Du etwas funktionierendes haben willst: Quectel RM500Q mit Qualcom Chipsatz. Das habe ich bei meinem Arbytegeber unter PC-Linux, an einem Raspberry Pi 4 und an NVidia Jetson ARM64/GPU Systemen (nach dem Nachcompilieren einiger Kernelmodule) zum Laufen gebracht.

Wir beziehen die Teile von einem offiziellen Distributor, hier www.tekmodul.de. https://shop.tekmodul.de/RM500Q-GL-p541645391

Aufpassen, diese Teile können bis zu 3A ziehen und möchten gerne etwas Kühlung haben.

fchk

Vielen Dank für den Tipp und Hinweis! Gerade erst jetzt durch Zufall gesehen, weil trotz Abo keine Benachrichtigung kam.

Linux? Wenn ja, dann

mtk_t7xx Treiber libmbim (vom ModemManger Projekt) ModemManager selber (möglichst aktuelle Version) Oben drauf noch NetworkManager

Was auffällt sind Diskussionen im Netz dass das FM350-GL ein FCC Unlock braucht aber dass ein Unlock-Script für den ModemManager fehlt. Angeblich auch für die -GL (= global) Version. Die ModemManager Dokumentation https://modemmanager.org/docs/modemmanager/fcc-unlock/ erwähnt kein Unlock-Skript für FM350-GL. Aber ModemManager ist notorisch beschissen dokumentiert.

Ansonsten kann ich für Linux nur unterschreiben dass Modems aus der Quectel RM50xQ-Serie brauchbar sind und man sie, eventuell mit etwas Gefummel, unter Linux zum Laufen bekommt.

Ebenso Telit Cinterion FM980[m]. Wobei ich die zickiger fand.

Dann habe ich noch mit einem Simcom 82<??> gearbeitet. Genauen Typ weiß ich nicht mehr. Das war bei uns unter Linux eher so eine geht mal, geht mal nicht Ding. Wir haben die schnell durch Quectel ersetzt.

@Hannes Vielen Dank auch für deine Infos.

Linux ist schon richtig, dort würde ich es brauchen. Genauer gesagt auf einem Raspberry Pi 4. Eine Idee, wie ich dort zum Treiber mtk_t7xx kommen könnte? Den Kernel übersetze ich dort ja nicht selber.

Funktioniert dies ähnlich, wie wenn ich USB patchen muss, also Header zum passenden Kernel herunterladen, auspacken, Treiber-Sourcen herunterladen und auspacken und dann versuchen ihn außerhalb des Kernels zu übersetzen?

Oder kann dies nur Raspberry selbst, also müsste ich denen eine Anfrage senden, ob sie den Kernel-Schalter aktivieren könnten?

Ich habe gesehen, dass im Kernel 6.4 einiges in Richtung USB mainlined wurde, was den Funkmodulen zu Gute kommt. Vielleicht abwarten, ab es damit dann automatisch geht...?

Noch zum FCC-Unlock: Wenn ich nur AT Befehle nutze und nicht MBIM, muss ich FCC-Unlock trotzdem via ModemManager machen? Oder gibt es da evt. AT-Kommandos wo ich selbes machen kann?

Martin M. schrieb:

Linux ist schon richtig, dort würde ich es brauchen. Genauer gesagt auf einem Raspberry Pi 4. Eine Idee, wie ich dort zum Treiber mtk_t7xx kommen könnte? Den Kernel übersetze ich dort ja nicht selber.

Die Linux Kernel Driver Database sagt:

https://cateee.net/lkddb/web-lkddb/MTK_T7XX.html

Das ist offensichtlich ein Treiber für PCIe und ab Kernel 5.19 dabei. Ab 6.1.irgendwas soll er auch funktionieren.

Normalerweise schaut man erst, ob das Teil bei einem selber funktioniert und drückt erst dann auf den "Kaufen" Button.

fchk

Martin M. schrieb:

Linux ist schon richtig, dort würde ich es brauchen. Genauer gesagt auf einem Raspberry Pi 4. Eine Idee, wie ich dort zum Treiber mtk_t7xx kommen könnte? Den Kernel übersetze ich dort ja nicht selber.

Ich kann dir nicht sagen was in deinem OS für Raspberry Pi drin ist. Besonders da es ja mehrere Linux-Distributionen für Raspberry Pi gibt.

Wenn dein OS den Treiber nicht hat dann könntest du die anderen Linux-Distributionen für Raspberry Pi durchprobieren.

Funktioniert dies ähnlich, wie wenn ich USB patchen muss, also Header zum passenden Kernel herunterladen, auspacken, Treiber-Sourcen herunterladen und auspacken und dann versuchen ihn außerhalb des Kernels zu übersetzen?

Müsste grob so sein, wenn du nicht den ganzen Kernel kompilieren willst. Aber ich bin mittlerweile bei Linux (nicht speziell Raspberry Pi) an dem Punkt dass ich bei so etwas normalerweise den ganzen Kernel (cross-)kompiliere. Ich finde es einfacher als das Gefummel mit Fragmenten des Kernel-Source.

Oder kann dies nur Raspberry selbst, also müsste ich denen eine Anfrage senden, ob sie den Kernel-Schalter aktivieren könnten?

Kannst du machen. Ich glaube allerdings die werden dich ignorieren.

Martin M. schrieb:

Noch zum FCC-Unlock: Wenn ich nur AT Befehle nutze und nicht MBIM, muss ich FCC-Unlock trotzdem via ModemManager machen? Oder gibt es da evt. AT-Kommandos wo ich selbes machen kann?

Theoretisch sollte ein FCC-Lock nur in US-Firmware Versionen von Modems sein. Beim FM350-GL munkelt man (Gerücht, muss nicht stimmen), dass der FCC-Lock weltweit drin ist. Vielleicht hast du ja Glück und das stimmt nich. Für erste Versuche kannst du ModemManager und NetworkManager weg lassen (beide nicht starten) und statt dessen mbim-network konfigurieren und benutzen.

Dann, FCC-Unlocking ist hersteller-spezifisches, propritäres Geheim-Wissen. Das ist so gewollt. Die Unlock-Scripte für Linux basieren entweder auf hersteller-spezifischen, propritären Binaries oder sind durch Reverse-Engineering entstanden.

Die wenigen Unlock-Scripte die mit ModemManager kommen (ich kenne keine anderen) verwenden Unlock-Funktionen die in libqmi und libmbim einkompiliert sind. Die Scripte rufen diese über mbimcli oder qmicli auf. Scripte mit AT-Kommandos mag es geben, ich kenne keins.

Frank K. schrieb:

https://cateee.net/lkddb/web-lkddb/MTK_T7XX.html

Das ist offensichtlich ein Treiber für PCIe

Nur falls es nicht klar ist, das Modem verwendet PCIe über M.2, müsste also passen.

Normalerweise schaut man erst, ob das Teil bei einem selber funktioniert und drückt erst dann auf den "Kaufen" Button.

Du meinst wahrscheinlich "bei anderen mit vergleichbare Konfiguration funktioniert". Das kann ich nur unterschreiben. Mobilfunk-Modems unter Linux können ziemlich garstig sein und die Tools sind miserabel bis gar nicht dokumentiert. Wenn du dann bei Fehlern nicht einmal weißt ob das Modem, Treiber, die Management-Software oder die eigene Konfiguration schuld ist wird Debuggen ekelig.

Hannes J. schrieb:

Frank K. schrieb:

https://cateee.net/lkddb/web-lkddb/MTK_T7XX.html

Das ist offensichtlich ein Treiber für PCIe

Nur falls es nicht klar ist, das Modem verwendet PCIe über M.2, müsste also passen.

Ein normaler Raspberry Pi hat kein PCIe, also müsste es sich um ein CM4 handeln, oder?

fchk

Frank K. schrieb:

Ein normaler Raspberry Pi hat kein PCIe, also müsste es sich um ein CM4 handeln, oder?

Weiß ich nicht. Ich kenne mich im Pi-Universum nicht aus. Er schrieb Pi 4.

Ich glaube (ich weiß es nicht), dass das Modem PCIe über den M.2 Anschluss benötigt. Und zwar weil ich zu den USB Anschlüssen über M.2 für das Modem nur das finde:

USB 2.0 (For debug)/USB 3.1 Gen1 (Reserved)

Also nix mit Steuerung über USB.

Es müsste ein M.2 Steckplatz mit PCIe und SIM-Card Unterstützung sein, B Keying. Dazu ein SIM-Card Halter auf dem Mainboard oder Adapterboard. Die im Modem in einigen Firmware-Versionen eingebaute Möglichkeit für eine eSIM wird er höchst wahrscheinlich nicht nutzen (können).

Auch bei der Hardware gilt was du schon früher gesagt hast. Erst schauen was bei anderen läuft, dann zur Risikominimierung gleiche Hardware, in gleicher Hardwarerevision, mit gleicher Firmware kaufen.