Funktioniert das Plugin rpihddevice eigentlich auf dem rpi4? Oder muss das erst noch weiter entwickelt werden?
Raspberry Pi 4B Unterstützung
-
-
Und auch das USB 3.0 zu SATA Problem ist zumindest für mich nicht lösbar:
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.
-
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
-
Das funktioniert, setzt aber die Geschwindigkeit auf USB 2.0 herunter.
-
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
-
USB Problem hat sich erübrigt. Ich bekomme mit dem Adapter die gleichen Fehler am Linux-Desktop sobald ich versuche auf die SSD zu schreiben.
--> Zurück zu Amazon. Retoure ist schon fertig.
-
JMicron ist eigentlich ein guter Chipsatz.
Wobei mir gerade einfällt, dass es bei JMicron es schon mal so einen ähnlichen Bug gab:
-
Gerade gesehen:
https://archlinuxarm.org/platf…8/broadcom/raspberry-pi-4
Heute Abend gleich mal testen.
Edit: Funktioniert einwandfrei
-
-
Hallo Uwe
Ich befürchte, die Änderungen werden umfangreich sein... scheint ein Projekt für den Winter zu werden.
Gruss
Thomas
-
Zitat
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.
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!