Linux och Realtek RTL9210 USB-till-NVMe-brygga

Sammanfattning: • Symptom: Upprepade USB-återställningar, I/O-fel eller diskar som försvinner i Linux. • Drabbade: Realtek RTL9210 (bekräftat) och RTL9220 (möjligen). • Orsak: Återgång till intern ROM (f0.01) efter misslyckad kontrollsumma. • Påverkan: Permanent instabilitet, inga omprogrammeringsverktyg tillgängliga för Linux. • Lösning: Endast OEM Windows-verktyg kan återställa firmware – Realtek blockerar open source-alternativ.

Förord

År 2025 borde det vara fullt rimligt att starta en Raspberry Pi från en SSD ansluten via USB. Men på grund av Realteks firmware-egenskaper har detta rimliga mål förvandlats till ett äventyr. Efter månader av oförklarlig instabilitet – slumpmässiga återställningar, försvunna diskar, korrupta filsystem – uttömde författaren alla vanliga lösningar: nya kablar, strömförsörjda hubbar, kärnuppdateringar, USB-justeringar och firmware-finjustering. Genombrottet kom först när ChatGPT svarade på en konstig fråga sent på natten: ”Är det möjligt att USB-till-NVMe-bryggan har återgått till en gammal firmware?”

Inledning

Om din Realtek-baserade NVMe-kapsling plötsligt blir instabil efter veckor av felfri drift – upprepade USB-återställningar, I/O-fel eller diskar som försvinner – är du inte ensam. Detta mönster har dykt upp hos flera märken, från namnlösa enheter till välkända OEM-tillverkare som Sabrent och Orico. Den gemensamma nämnaren: Realteks RTL9210 och möjligen RTL9220 USB-till-NVMe-bryggchip.

I början fungerar allt. Sedan, till synes utan anledning, börjar enheten koppla från under belastning eller vid långvarig användning, särskilt på Linux- eller Raspberry Pi-system. Den verkliga orsaken är varken SSD:n eller strömförsörjningen – det är själva firmware-kontrollern som tyst återgår till sin inbyggda backup-kod i ROM, en version som Realtek fortfarande levererar internt som f0.01.

Den dolda mekanismen – Firmware-återgång genom design

Realteks bryggchip lagrar sin operativa firmware och konfigurationsdata i en extern SPI-flash. Vid uppstart kontrollerar kontrollern en enkel kontrollsumma. Om denna kontrollsumma inte stämmer, vägrar den att ladda den externa firmwaren och startar istället från sin interna ROM.

Denna backup-firmware är gammal och defekt. Den saknar flera USB-stabilitetsfixar och förbättringar i länkhantering som finns i senare revisioner, vilket leder till den klassiska sekvensen som varje Linux-användare känner igen:

usb 3-2: återställ höghastighets-USB-enhet nummer 2 med xhci-hcd
usb 3-2: läsning av enhetsbeskrivning/64, fel -71
EXT4-fs varning (enhet sda2): I/O-fel vid skrivning till inode …

Kontrollsumman kan bli ogiltig när konfigurationsdata skrivs om – till exempel när bryggan uppdaterar sina energihantering eller UAS-inställningar – och enheten förlorar ström under skrivningen. Nästa uppstart upptäcker en korrupt kontrollsumma och återgår permanent till ROM-firmwaren.

Vid denna punkt beter sig din ”högpresterande NVMe-kapsling” exakt som den billigaste namnlösa skalet, eftersom den internt nu kör samma defekta baskod som är inbränd i kisel.

Verifiering av problemet

Du kan enkelt bekräfta detta tillstånd i Linux:

lsusb -v | grep -A2 Realtek

En frisk Realtek-brygga rapporterar en firmware-revision (bcdDevice) över 1.00. En som har återgått visar:

bcdDevice f0.01

Denna f0.01-signatur innebär att kontrollern startar från ROM – och ingen mängd avkoppling, omformatering eller kärnjusteringar kommer att fixa det.

Denna återgångsmekanism har bekräftats för RTL9210. RTL9220 verkar dela samma designarkitektur och firmware-layout, så den kan uppvisa identiskt beteende, men detta förblir sannolikt snarare än bevisat.

Varför du inte kan fixa det själv

I princip är lösningen trivial: omprogrammera rätt firmware till SPI. I praktiken gör Realtek detta omöjligt.

Företaget tillhandahåller en sluten källa-uppdaterare för Windows till OEM och integratörer. Linux-användare erbjuds ingenting. Gemenskapsutvecklare omvände kompatibla flash-verktyg (rtsupdater, rtl9210fw, rtsupdater-cli) som möjliggjorde fullständig firmware-återställning från Linux-system – tills Realtek utfärdade DMCA-borttagningsmeddelanden för att undertrycka dem.

Det finns ingen trovärdig immateriell rättighetsmotivering för att blockera sådana verktyg: de exponerar inte mikrokod, utan orkestrerar bara uppdateringssekvensen via USB. Realteks borttagningar handlade inte om skydd. De var ideologiska.

Kostnaden för en ideologi

Detta handlar inte om open source-idealism. Det handlar om en hårdvarutillverkares ideologiska fientlighet mot öppna system som förstör enheter som marknadsförs som Linux-kompatibla.

Realteks motstånd mot dokumentation och öppna verktyg har pågått i två decennier, omfattande Wi-Fi, Ethernet, ljud och nu lagringskontrollers. Denna isolering kan gå obemärkt förbi i en värld med enbart Windows, men blir giftig när samma chip integreras i multiplattformsprodukter som Sabrent EC-SNVE, som öppet visar Linux-logotypen på sin förpackning.

Genom att förbjuda Linux-flash-verktyg och blockera gemenskapsunderhåll har Realtek effektivt kriminaliserat självreparation. Konsekvenserna sprider sig utåt:

• Linux-användare ser ”stött” hårdvara försämras till instabilitet.
• OEM-tillverkare som Sabrent och Orico står inför onödiga RMA- och garantikostnader.
• Realteks långvariga rykte för dålig Linux-kompatibilitet förstärks återigen.

I slutändan är det inte open source som förstör Realteks enheter – det är Realteks fientlighet mot open source som förstör dem.

En rationell väg framåt

Lösningen kräver ingen ideologisk förändring, bara pragmatism. Realtek skulle kunna:

1. Släppa ett leverantörsignerat kommandorads-uppdateringsverktyg för Linux (ingen källkodspublicering krävs).
2. Publicera kontrollsummealgoritmen så att integratörer kan verifiera flash-bilder säkert.
3. Anta ett DFU-liknande läge som accepterar uppdateringar via USB-masslagring, oberoende av operativsystem.

Vart och ett av dessa skulle förhindra garantikostnader, skydda OEM-relationer och återställa förtroendet för Realteks bryggchip bland professionella Linux-användare – från arbetsstationsbyggare till Raspberry Pi-utvecklare.

Vad du kan göra

Om du misstänker att din kapsling har återgått till ROM-firmware:

• Kontrollera med lsusb -v | grep bcdDevice.
• Om det visar f0.01, rapportera problemet till din OEM.
• Inkludera utdraget från dmesg och peka på denna dokumenterade återgångsmekanism.
• Be din leverantör att eskalera problemet till Realtek, med hänvisning till behovet av ett Linux-kompatibelt uppdateringsverktyg.

Realteks firmware-policy stör inte bara entusiaster; den skapar konkreta ekonomiska förluster för deras eget ekosystem. Ju tidigare denna verklighet erkänns inom företaget, desto snabbare kan Linux-användare och OEM-partners sluta slösa tid på undvikbara RMA-cykler.

Svar från tillverkare

Både Realtek och Sabrent har bjudits in att ge uttalanden om det firmware-återgångsproblem som beskrivs ovan. Deras svar – om de mottas – kommer att läggas till här.

Bilaga – Identifiering av drabbade enheter

Firmware-återgångssignatur: bcdDevice f0.01
Kända stabila revisioner: 1.23 – 1.31