Linux und die Realtek RTL9210 USB-zu-NVMe-Brücke

Zusammenfassung: • Symptome: Wiederholte USB-Resets, I/O-Fehler oder verschwindende Laufwerke unter Linux. • Betroffen: Realtek RTL9210 (bestätigt) und RTL9220 (möglicherweise). • Ursache: Rückfall auf interne ROM (f0.01) nach Prüfsummenfehler. • Auswirkungen: Dauerhafte Instabilität, keine Linux-Reflash-Tools verfügbar. • Lösung: Nur OEM-Windows-Dienstprogramme können die Firmware wiederherstellen – Realtek blockiert Open-Source-Alternativen.

Vorwort

Im Jahr 2025 sollte es völlig normal sein, einen Raspberry Pi von einer über USB angeschlossenen SSD zu starten. Doch dank der Eigenheiten der Realtek-Firmware ist dieses vernünftige Ziel zu einem Abenteuer geworden. Nach Monaten ungeklärter Instabilität – zufällige Resets, verschwindende Laufwerke, beschädigte Dateisysteme – hat der Autor alle üblichen Lösungen ausgeschöpft: neue Kabel, stromversorgte Hubs, Kernel-Updates, USB-Anpassungen und Firmware-Optimierungen. Der Durchbruch kam erst, als ChatGPT auf eine seltsame nächtliche Frage antwortete: „Ist es möglich, dass die USB-zu-NVMe-Brücke auf eine alte Firmware zurückgefallen ist?“

Einführung

Wenn Ihr Realtek-basierter NVMe-Gehäuse plötzlich nach Wochen einwandfreien Betriebs instabil wird – wiederholte USB-Resets, I/O-Fehler oder verschwindende Laufwerke – sind Sie nicht allein. Das Muster ist bei mehreren Marken aufgetreten, von No-Name-Geräten bis hin zu bekannten OEMs wie Sabrent und Orico. Der gemeinsame Nenner: Realteks RTL9210 und möglicherweise RTL9220 USB-zu-NVMe-Brückenchips.

Anfangs funktioniert alles. Dann, scheinbar ohne Grund, beginnt das Gerät unter Last oder bei längerem Gebrauch, insbesondere auf Linux- oder Raspberry Pi-Systemen, die Verbindung zu verlieren. Die wahre Ursache ist weder die SSD noch die Stromversorgung – es ist der Firmware-Controller selbst, der leise auf seinen in der ROM eingebetteten Rückfallcode zurückgreift, eine Version, die Realtek intern immer noch als f0.01 ausliefert.

Der verborgene Mechanismus – Firmware-Rückfall durch Design

Die Brückenchips von Realtek speichern ihre Betriebsfirmware und Konfigurationsdaten in einem externen SPI-Flash. Beim Einschalten überprüft der Controller eine einfache Prüfsumme. Wenn diese Prüfsumme nicht übereinstimmt, verweigert er das Laden der externen Firmware und startet stattdessen aus seiner internen ROM.

Diese Rückfall-Firmware ist veraltet und fehlerhaft. Sie enthält mehrere fehlende USB-Stabilitätskorrekturen und Verbesserungen der Link-Zustandsverwaltung, die in späteren Revisionen vorhanden sind, was zur klassischen Sequenz führt, die jeder Linux-Benutzer erkennt:

usb 3-2: Reset des Hochgeschwindigkeits-USB-Geräts Nummer 2 mit xhci-hcd
usb 3-2: Gerätebeschreibung lesen/64, Fehler -71
EXT4-fs Warnung (Gerät sda2): I/O-Fehler beim Schreiben in Inode …

Die Prüfsumme kann ungültig werden, wenn Konfigurationsdaten überschrieben werden – zum Beispiel, wenn die Brücke ihre Energieverwaltungs- oder UAS-Einstellungen aktualisiert – und das Gerät während des Schreibens die Stromversorgung verliert. Beim nächsten Start erkennt es eine beschädigte Prüfsumme und fällt dauerhaft auf die ROM-Firmware zurück.

An diesem Punkt verhält sich Ihr „hochleistungsfähiges NVMe-Gehäuse“ genau wie das billigste No-Name-Gehäuse, da es intern nun denselben fehlerhaften Basiskode ausführt, der in das Silizium eingebrannt ist.

Überprüfung des Problems

Sie können diesen Zustand unter Linux einfach bestätigen:

lsusb -v | grep -A2 Realtek

Eine gesunde Realtek-Brücke meldet eine Firmware-Revision (bcdDevice) über 1.00. Eine zurückgefallene zeigt:

bcdDevice f0.01

Diese f0.01-Signatur bedeutet, dass der Controller aus der ROM startet – und kein Entstecken, Neuformatieren oder Kernel-Tuning wird dies beheben.

Dieser Rückfallmechanismus wurde für den RTL9210 bestätigt. Der RTL9220 scheint die gleiche Designarchitektur und Firmware-Layout zu teilen, sodass er wahrscheinlich identisches Verhalten zeigt, aber dies bleibt wahrscheinlich, nicht bewiesen.

Warum Sie es nicht selbst reparieren können

Im Prinzip ist die Lösung einfach: Die richtige Firmware auf den SPI flashen. In der Praxis macht Realtek dies unmöglich.

Das Unternehmen stellt OEMs und Integratoren ein Closed-Source-Windows-Update-Tool zur Verfügung. Linux-Benutzern wird nichts angeboten. Community-Entwickler haben kompatible Flash-Tools (rtsupdater, rtl9210fw, rtsupdater-cli) reverse-engineered, die eine vollständige Firmware-Wiederherstellung von Linux-Systemen aus ermöglichten – bis Realtek DMCA-Abbauanforderungen ausstellte, um sie zu unterdrücken.

Es gibt keinen plausiblen Grund für den Schutz des geistigen Eigentums, um solche Tools zu blockieren: Sie legen keinen Mikrocode offen, sondern orchestrieren lediglich die Update-Sequenz über USB. Die Abbauanforderungen von Realtek waren nicht zum Schutz gedacht. Sie waren ideologisch.

Der Preis einer Ideologie

Hier geht es nicht um Open-Source-Idealismus. Es geht um die ideologische Feindseligkeit eines Hardware-Herstellers gegenüber offenen Systemen, die Geräte zerstört, die als Linux-kompatibel vermarktet werden.

Realteks Widerstand gegen Dokumentation und offene Tools besteht seit zwei Jahrzehnten und erstreckt sich über WLAN, Ethernet, Audio und jetzt Speichercontroller. Diese Abschottung mag in einer reinen Windows-Welt unbemerkt bleiben, wird jedoch toxisch, wenn dieselben Chips in Multi-Plattform-Produkte wie das Sabrent EC-SNVE integriert werden, das offen das Linux-Logo auf seiner Verpackung zeigt.

Durch das Verbot von Linux-Flash-Tools und die Blockierung der Community-Wartung hat Realtek Selbstreparatur effektiv kriminalisiert. Die Folgen breiten sich aus:

• Linux-Benutzer sehen, wie „unterstützte“ Hardware in Instabilität abgleitet.
• OEMs wie Sabrent und Orico stehen vor unnötigen RMA- und Garantiekosten.
• Realteks langjähriger Ruf für schlechte Linux-Kompatibilität wird erneut verstärkt.

Am Ende ist es nicht Open Source, das Realteks Geräte zerstört – es ist Realteks Feindseligkeit gegenüber Open Source, die sie zerstört.

Ein rationaler Weg nach vorn

Die Lösung erfordert keinen ideologischen Wandel, sondern nur Pragmatismus. Realtek könnte:

1. Ein vom Hersteller signiertes Kommandozeilen-Update-Tool für Linux veröffentlichen (keine Offenlegung des Quellcodes erforderlich).
2. Den Prüfsummenalgorithmus veröffentlichen, damit Integratoren Flash-Images sicher validieren können.
3. Einen DFU-ähnlichen Modus einführen, der Updates über USB-Massenspeicher akzeptiert, unabhängig vom Betriebssystem.

Jeder dieser Schritte würde Garantiekosten verhindern, OEM-Beziehungen schützen und das Vertrauen in Realteks Brückenchips unter professionellen Linux-Benutzern – von Workstation-Bauern bis hin zu Raspberry Pi-Entwicklern – wiederherstellen.

Was Sie tun können

Wenn Sie vermuten, dass Ihr Gehäuse auf die ROM-Firmware zurückgefallen ist:

• Überprüfen Sie mit lsusb -v | grep bcdDevice.
• Wenn es f0.01 anzeigt, melden Sie das Problem an Ihren OEM.
• Fügen Sie den dmesg-Auszug hinzu und verweisen Sie auf diesen dokumentierten Rückfallmechanismus.
• Bitten Sie Ihren Anbieter, das Problem an Realtek zu eskalieren, und verweisen Sie auf die Notwendigkeit eines Linux-kompatiblen Update-Tools.

Realteks Firmware-Politik stört nicht nur Enthusiasten; sie verursacht greifbare finanzielle Verluste für ihr eigenes Ökosystem. Je früher diese Realität im Unternehmen anerkannt wird, desto schneller können sowohl Linux-Benutzer als auch OEM-Partner aufhören, Zeit mit vermeidbaren RMA-Zyklen zu verschwenden.

Antworten der Hersteller

Sowohl Realtek als auch Sabrent wurden eingeladen, Stellungnahmen zu dem oben beschriebenen Firmware-Rückfallproblem abzugeben. Ihre Antworten – falls erhalten – werden hier angehängt.

Anhang – Identifizierung betroffener Geräte

Firmware-Rückfallsignatur: bcdDevice f0.01
Bekannte stabile Revisionen: 1.23 – 1.31