Raspberry Pi 4B Unterstützung

  • So weit, wie ich das mitbekommen habe liegt das Problem im Moment noch mehr beim kernel, der noch nicht optimal angepasst ist. Danach kann erst rpihddevice angepasst werden.


    vdr-User-# 755 to_h264 chk_r

  • Und auch das USB 3.0 zu SATA Problem ist zumindest für mich nicht lösbar:

    https://github.com/raspberrypi/linux/issues/3070

    Oh je, das erinnert mich irgendwie an die alten Athlon-Zeiten. Die USB-Controller von den VIA-Chipsätzen hatten mir mehrfach solche Überraschungen bereitet.

    Ich hoffe das ist kein substanzielles Problem und die kriegen das bald in den Griff.

    Bei mir half damals nur eine USB-Controllerkarte.

    Gruss
    SHF


  • Oh je, das erinnert mich irgendwie an die alten Athlon-Zeiten. Die USB-Controller von den VIA-Chipsätzen hatten mir mehrfach solche Überraschungen bereitet.

    Ich hoffe das ist kein substanzielles Problem und die kriegen das bald in den Griff.

    Bei mir half damals nur eine USB-Controllerkarte.

    Kann durchaus sein. Ich habe jetzt einen anderen USB3 nach SATA Adapter ausgeliehen und damit geht alles bestens...

    Ich bestelle jetzt das gleiche Modell. Den anderen Adapter behalte ich aber. JMicron ist eigentlich ein guter Chipsatz.


    Ich hoffe nur das die Auswahl von passenden USB3 nach Gigabit LAN Adaptern nicht ähnliche Probleme auftreten.

  • Thermal Pads zu löten (entlöten) ist keine große Sache, man braucht Heißluftequipment. Einen Preheater von unten mit passender Scheibe zum punktgenauen vorwärmen der PCB auf ca 150°C genau an der Stelle. Dann braucht man nur noch mit dem Heißluftstab von oben das kurzzeitig so auf 260° - 280° erhitzen und mit der Vakuum Pinzette das IC abheben. Fummelei sind eher die hauchdünnen Drähte. Die muss man leider per Hand anlöten. Bei 0,4mm Pitchabstand sollten die Drähte so 0,1 - 0,2mm dick sein, damit sie sich nicht berühren. Dafür braucht man schon eine Micro Nadel zum löten. Einfacher wäre es, wenn man die Drähte vorher mit Sekundenkleber in der Nähe an passender Stelle fixiert und unter der Lupe dann genau über den Pads positioniert. Dann etwas Lotpaste drauf mit viel Flussmittel. Bei Aufschmelzen über Heißluft "schwimmt" sich dann das Lot schön auf dem Pad ein und das Flußmittel trennt das Lot zwischen den Pads.


    Ich habe einen großen Lötkolben. Den würde ich etwas verzinnen (wegen Wärmeübertragung) und dann einige Zeit unter dem Chip auf die Massefläche halten. Sollte zum Vorwärmen eigentlich gehen. Dann von oben mit Heißluft (eher so 350°C bis 400°C. Das Zeug wird wohl bleifrei sein) möglichst punktgenau mit wenig Volumenstrom auf den IC. Umliegendes evtl. mit etwas Alufolie schirmen.


    Letztlich bestätigt die Beschreibung meine Annahme, dass die "Spannungsführenden" Pins im USB3-Stecker für anderes zweckentfremdet sind.

    Schon aus optischen Gründen würde ich beide USB-Doppelbuchsen runternehmen. Bei einer neu eingebauten einzelnen USB 3.0 Buchse dann hinten das Schirmblech abnehmen und GND und +5V nach hinten wegbiegen. So können die Pins schon am Raspberry passend verbunden werden. Ein Mod auf der PCI-Express Platine entfällt dann.

  • @ usb3->sata evtl mal probieren in /etc/modprobe.d/foo_bar.conf:


    options usb-storage quirks=2109:8110:u

  • Ja, das war der Sinn des Tests.

  • Ich habe einen großen Lötkolben. Den würde ich etwas verzinnen (wegen Wärmeübertragung) und dann einige Zeit unter dem Chip auf die Massefläche halten. Sollte zum Vorwärmen eigentlich gehen.

    notfalls möglich. Besser wäre ein temperaturgeregelter Heizer. Wenn Du von unten zu viel Dampf gibst, dann kann es passieren, das evtl. die Bauteile vom Bottom Layer abfallen oder wegen längerer Überhitzung ausfallen. Durch das Masse Layer brauchst Du viel Hitze, die sich weitflächig verteilt. Oder aber das durch die zu große Hitze die Platine überhitzt, Blasen wirft und die Schichten sich lösen. 150° ist das, was man bei der Rampentemperatur im Lötprozess meist längere Zeit draufgeben kann. Am besten wäre ein Pyro Thermometer mit dem man von oben den Aufheizprozess überwacht.


    Nebenbei, einen Preheater hatte ich mir mal vor Jahren selbst gebaut aus einem alten 1000W Heizstrahler. Damit lässt sich die Temperatur und Volumenstrom genau einstellen



       

  • JMicron ist eigentlich ein guter Chipsatz.

    Wobei mir gerade einfällt, dass es bei JMicron es schon mal so einen ähnlichen Bug gab:

    USB Platte defekt?

    Gruss
    SHF


  • Hallo zusammen,


    reufer Hallo Thomas. Kannst du schon eine Aussage treffen, wie Umfangreich der Umbau des Ausgabeplugins für den RaspberryPi4b wird?


    Gruß

    Uwe

  • Quote

    The end result should be that we start to adhere to more standard Linux libraries rather than the vendor specific MMAL.

    Das hört sich doch sehr vernünftig an! Den Sonderweg OMX/MMAL hab ich nie gemocht. Wenn jeder Hersteller seine eigenen Bibliotheken hat muss für jedes Board extra geschrieben werden. Wenn Standarts wie v4l oder ffmpeg genutzt werden ist der Aufwand die Hardware zu unterstützen gering.

  • Das hört sich doch sehr vernünftig an! Den Sonderweg OMX/MMAL hab ich nie gemocht. Wenn jeder Hersteller seine eigenen Bibliotheken hat muss für jedes Board extra geschrieben werden. Wenn Standarts wie v4l oder ffmpeg genutzt werden ist der Aufwand die Hardware zu unterstützen gering.

    OpenMAX wäre sehr wohl ein plattformübergreifender Standard, im Gegensatz zu ffmpeg. V4L wiederum auch, aber das scheint noch kein Thema zu sein.

  • Das hört sich doch sehr vernünftig an! Den Sonderweg OMX/MMAL hab ich nie gemocht. Wenn jeder Hersteller seine eigenen Bibliotheken hat muss für jedes Board extra geschrieben werden. Wenn Standarts wie v4l oder ffmpeg genutzt werden ist der Aufwand die Hardware zu unterstützen gering.


    So funktioniert "Decodieren mit ffmpeg" in aller Regel aber nicht.

    Wir haben für den VDR mittlerweile eine bunte Auswahl an Ausgabe-Plugins. Softhddevice, Vaapidevice, Softhdcuvid, ...

    Alle bauen auf ffmpeg auf aber alle haben dennoch spezielle Anpassungen auf genau ein Ausgabeformat.


    Wenn ffmpeg eingangsseitig wirklich neutral wäre, dann bräuchte es genau ein Ausgabe-Plugin. Eines das den Datenstrom eingangsseitig in ffmpeg reinkippt.

  • Wenn ffmpeg eingangsseitig wirklich neutral wäre, dann bräuchte es genau ein Ausgabe-Plugin. Eines das den Datenstrom eingangsseitig in ffmpeg reinkippt.

    Das Decodieren an sich ist ja nur die halbe Wahrheit - problematisch, weil plattformabhängig, ist auch die synchronisierte Ausgabe der decodierten (ob nun mit oder ohne Hardwareunterstützung) Audio- und Videoframes. V4L scheint da ein vielversprechender Weg zu sein, aber wann das für die neue Himbeere kommt ist fraglich.

  • Softhddevice, Vaapidevice, Softhdcuvid, ...

    ... alle haben Johns als Ursprung. Das ist halt mit forks so. Ob die wieder zusammen geführt werden ist fraglich aber schön wäre es schon.

    Das Decodieren an sich ist ja nur die halbe Wahrheit - problematisch, weil plattformabhängig, ist auch die synchronisierte Ausgabe der decodierten (ob nun mit oder ohne Hardwareunterstützung) Audio- und Videoframes. V4L scheint da ein vielversprechender Weg zu sein, aber wann das für die neue Himbeere kommt ist fraglich.

    Die Ausgabe per DRM funktioniert eigentlich recht gut. Problematisch sind die unterschiedlichen FB Formate.


    Die v4l Entwickler sind momentan dabei sich eigene Standarts zu erarbeiten. Auch da ist der Zoo recht gross(plane, mplane, statefull, stateless, ...). Aber immer noch besser als wenn jeder Hersteller sein eigenes Süppchen kocht.

  • ... alle haben Johns als Ursprung. Das ist halt mit forks so. Ob die wieder zusammen geführt werden ist fraglich aber schön wäre es schon.


    Ist mir schon klar. Ändert aber nichts an der Tatsache das ffmpeg eben doch nicht so schön "neutral" ist wie man es gerne haben würde. Wenn dem so wäre, dann hätte nämlich einmalig ein Ausgabe-Plugin gebaut werden können und dieses kann einfach auf alles wiedergeben was ffmpeg kann.


    Gleiches Problem bei Kodi. VDPAU geht. NVDEC geht nicht. Obwohl die auch ffmpeg drunter liegen haben.


    Zusammenführen wird schwer. Wäre eigentlich nur möglich wenn jemand ein modulares Ausgabe-Plugin baut. Grafikkarten sind teuer und kein Entwickler will sich alle möglichen Modelle aus der eigenen Tasche kaufen. Den Einfluss, dass VDR-Entwickler kostenlose Samples bekommen, hat VDR bei weitem nicht.