[gustavgans]

Hallo liebe Community,
ich bin - man ahnt es - neu hier und melde mich wegen eines Problems.
Habe einen RPi5 (2GB), der hat ein M2-HAT+ Board, darauf aber (noch) keine SSD, ich warte auf fallende Preise...
DER PLAN: MLD mit VDR und Sundtek Twin-DVB-S2, soll nur Live-TV und halt Aufnahmen machen, Ausgabe direkt üer HDMI, kein SAT-IP Server o.ä., Steuerung mittelfristig über Sundtek-integrierten IR-Empfänger, ansonsten per Web-IF über Wlan.
Ja ich weiß (inzwischen...) der RPi5 ist nicht die beste Wahl wegen fehlendem x.264/265 HW-Dekoder, aber nu isser halt da. Ich kann also nur MLD V6.x nehmen und habe die aktuelle netinstall (2026-05-23) verwendet.
DAS PROBLEM: Der WLAN-Adapter wird nicht erkannt, daher läuft der Installer nicht, sondern meldet nur "keine Netzwerkverbindung".
N.B.: Da das WLAN nun ja nicht geht komme ich nur mit dem lokalen Web-IF dran, das ist wie bekannt recht lahm: Alle 3..4sec wird EINE Aktion durchgeführt, z.B. eine Eingabe entgegen genommen, irgend wann das <CR> erkannt und dann wieder 3sec später darauf reagiert. Ich komm damit ja zurecht, aber komisch ist es jedenfalls. Wie ist das Web-IF denn implementiert? Kann man da nicht die busybox drauf ansetzen und implizit nen Chromium lokal da drauf schicken? So eine Kombi (busybox lauscht auf Port 88, damit nichts mit 80 kollidiert...) hab ich hier in anderem Zusammenhang und das ist vernünftig responsiv.
Zurück zum Thema.
ANALYSEN: Ich habe ein RaspberryPi-OS ("pios"), damit funzt alles inklusive WLAN. Habe damit auch dafür gesorgt, dass z.B. die Rpi5-Firmware im EEPROM aktuell ist.
ifconfig meldet im pios drei Adapter (eth0, lo(opback) und wlan0, in MLD nur eth0 und lo.
rfkill list meldet in pios, dass weder für Bluetooth noch für Wlan eine Hardware- oder Software-Deaktivierung im Eingriff sei.
Ich habe von beiden Umgebungen lshw, lsusb und dmesg Ausgaben parat, habe aber mangels Wissen nicht selber viel darin gewühlt. Beide Plattformen erkennen bereits den Sundtek Dual S2 am USB. Das WLAN-IF ist interessanterweise im Baum "*-mmc1" geführt. Die
Product-ID ist "4345", beide Plattformen erkennen sie, aber MLD löst sie nicht auf, also gibts kein WLAN. Im lshw des pios stehen noch folgende, vielleicht relevante Informationen:
logical name: mmc1:0001:1; logical name: wlan0; serial: 88:a2:9e:e0:53:4c (das is die MAC); capabilities: ethernet physical wireless; configuration: broadcast=yes driver=brcmfmac driverversion=7.45.16.144 firmware=01-b677b91b ip=192.168.1.42 multicast=yes wireless=IEEE 802.11
Ich bin ahnungslos, aber das schaut so aus als wäre der Treiber 'brcmfmac' nicht in den Kernel integriert, sondern würde nachgeladen?
Das WiredLAN ist erwartungsgemäß im Baum *-network aufgeführt.
Die Kernelversionen sind unterschiedlich: MLD=6.06.63-V8-16k, pios=6.18.33+rpt-rpi-2712, ich bin damit recht sicher, dass die Raspi-Foundation im Kernel jene Zusatztreiber eingebaut hat, die sie für ihren Broadcom-Chilsatz halt brauchen.
In dmesg finde ich zu 'mmc1' nur eine einzige Zeile bei MLD:
[    1.703274] mmc1: new ultra high speed DDR50 SDIO card at address 0001
Der brcmfmac scheint durchaus da zu sein, aber ist vll. nicht aktuell genug?
[    6.332596] brcmfmac: F1 signature read @0x18000000=0x15264345
[    6.333820] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[    6.334681] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43455-sdio.raspberrypi,5-model-b.bin failed with error -2
[    6.334685] brcmfmac mmc1:0001:1: Falling back to sysfs fallback for: brcm/brcmfmac43455-sdio.raspberrypi,5-model-b.bin
[  127.965583] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43455-sdio.txt failed with error -2
[  127.965591] brcmfmac mmc1:0001:1: Falling back to sysfs fallback for: brcm/brcmfmac43455-sdio.txt
[  190.417494] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50
Hierzu zum Vergleich das was im pios dmesg so drin steht...:
[    0.914926] mmc1: CQHCI version 5.10
[    1.105256] mmc1: SDHCI controller on 1001100000.mmc [1001100000.mmc] using ADMA 64-bit
[    1.137932] mmc1: new UHS-I speed DDR50 SDIO card at address 0001
[    4.947618] brcmfmac: F1 signature read @0x18000000=0x15264345
[    4.949414] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[    5.210883] brcmfmac: brcmf_c_process_txcap_blob: no txcap_blob available (err=-2)
[    5.211196] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Aug 29 2023 01:47:08 version 7.45.265 (28bca26 CY) FWID 01-b677b91b
[    9.119361] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
WIE WEITER: Mit reichlich Anleitung könnte ich vielleicht VDR, Sundtek-Treiber etc. im pios installieren, aber die schlanke MLD wäre mir schon lieber. Ich könnte einstweilen dem RPi5 ein WiredLAN verschaffen, damit es überhaupt weiter geht, aber am Ende muss dann ja doch auch WLAN funktionieren. Mein Wunsch wäre eine aktualisierte mld-image-netinstall-raspberrypi5.img. Gibt es dafür eine Chance? Kann ich noch irgend was beitragen?

Beste Grüße
gustavgans

[franky]

Hi gustavgans,

ich verwende den RPI5 bisher nicht produktiv, habe jedoch ein Testsystem das ich bisher bevorzugt mit dem WiredLan als Streamdev bzw. SatIP (VTuner) Client getestet hatte.
WLan hatte ich nur kurz mal getestet.

WLan sollte also beim RPI5 funktionieren.

Installiert und später aktiv getestet hatte ich den RPI5 aber bisher nur mit WiredLan, da das auf jeden Fall unkomplizierter abläuft.

Ich vermute mal, dass dein Problem daran liegt, dass MLD 6.5 einen Großteil der benötigten Firmware per Internet nachlädt und daher WLan erst mal nicht funktioniert.

Ich habe gerade mal meinen RPI5 wieder reaktiviert (per WiredLan verbunden) und der kann sich auch (konfiguriert per Remote WebIF) mit meinem WLan verbinden.
Somit funktioniert also prinzipiell auch WLan mit dem RPI5.

Ich würde vorschlagen, du verbindest den RPI5 erst mal per WiredLan und installierst und konfigurierst die MLD 6.5 per Remote WebIF.
Danach sollte auch bei dir ein Verbindung zu deinem WLan möglich sein.

[clausmuus]

Hallo,

ganz ehrlich: fallende SSD Preise sind auf längere Sicht eher nicht zu erwarten, eher das gegenteil. Die Produktion der Speicherbausteine kann den Bedarf nicht decken, und es dauert Jahre bis neue Fabriken fertig gestellt sein werden.

Die Performance Probleme des Webif liegt nicht an der Implementierung des Webif, sondern an einem Problem des verwendeten Browsers (surf) mit dem Grafikkarten Treiber des RPI. Der RPI kann auch so gebootet werden, dass das Webif genauso flüssig läuft wie auf jedem PC. Nur funktioniert dann die Video Ausgabe des VDR nicht. Die Verwendung von Chrome (bei dem das Webif immer flüssig läuft) ist leider auch keine Option, da dies bei der MLD aus einem Flatpack Paket kommt, und daher beim Installer Image nicht zur Verfügung steht.

Das Problem mit Deinem Netzwerk könnte daher kommen, dass die MLD für das RPI5 WLAN eine Firmware braucht, die im Image fehlt. Das kann immer wieder wieder vorkommen, wenn z.B. eine aktuellere RPI Firmware eine andere WLAN Firmware erwartet, und diese daher noch nicht im Image enthalten ist. Eine recht einfache Lösung wäre, beim ersten Booten eine LAN Verbindung herzustellen. Dann wird die benötigte WLAN Firmware automatisch nachgeladen und das WLAN dürfte sich konfigurieren lassen.
Da ich selber keinen RPI5 habe, kann ich das nicht selber prüfen und untersuchen was genau dem RPI fehlt. Bis das Image ohne einmaliger LAN Verbindung wieder funktioniert, kann es also ein bisschen dauern, bis einer unserer Entwickler oder testen das untersucht hat. Alternativ könntest aber auch Du ein Debug-Log erstellen, nachdem Du mit LAN-Kabel gebootet hast, denn da drinn kann ich sehen welche Firmware Dateien nachgeladen werden, bzw. nicht gefunden werden können.