Linux og Realtek RTL9210 USB til NVMe-bro Resumé: • Symptomer: Gentagne USB-nulstillinger, I/O-fejl eller diske, der forsvinder under Linux. • Berørte: Realtek RTL9210 (bekræftet) og RTL9220 (muligvis). • Årsag: Tilbagefald til intern ROM (f0.01) efter fejl i tjeksum. • Påvirkning: Permanent ustabilitet, ingen Linux-værktøjer til genindlæsning tilgængelige. • Løsning: Kun OEM Windows-værktøjer kan gendanne firmwaren – Realtek blokerer open source-alternativer. Forord I år 2025 burde det være helt rimeligt at starte en Raspberry Pi fra en SSD forbundet via USB. Men takket være finurlighederne i Realteks firmware er dette rimelige mål blevet et eventyr. Efter måneder med uforklarlig ustabilitet – tilfældige nulstillinger, forsvindende diske, korrupte filsystemer – udtømte forfatteren alle almindelige rettelser: nye kabler, strømforsynede hubs, kerneopdateringer, USB-justeringer og firmware-finjustering. Gennembruddet kom først, da ChatGPT svarede på et mærkeligt spørgsmål sent om natten: „Er det muligt, at USB-til-NVMe-broen er vendt tilbage til en gammel firmware?“ Introduktion Hvis din Realtek-baserede NVMe-kabinet pludselig bliver ustabil efter ugers fejlfri drift – gentagne USB-nulstillinger, I/O-fejl eller forsvindende diske – er du ikke alene. Mønsteret er opstået på tværs af flere mærker, fra ukendte enheder til velkendte OEM’er som Sabrent og Orico. Fællesnævneren: Realteks RTL9210 og muligvis RTL9220 USB-til-NVMe-bro-chips. I starten fungerer alt. Men tilsyneladende uden årsag begynder enheden at afbryde under belastning eller ved længerevarende brug, især på Linux- eller Raspberry Pi-systemer. Den sande årsag er ikke SSD’en eller strømforsyningen – det er selve firmwaren, der stille vender tilbage til sin ROM-indlejrede reservekode, en version, som Realtek stadig leverer internt som f0.01. Den skjulte mekanisme – Firmware-tilbagefald ved design Realteks bro-chips gemmer deres driftsfirmware og konfigurationsdata i en ekstern SPI-flash. Ved opstart tjekker controlleren en simpel tjeksum. Hvis tjeksumen ikke stemmer, nægter den at indlæse den eksterne firmware og starter i stedet fra sin interne ROM. Denne reserve-firmware er gammel og defekt. Den mangler flere USB-stabilitetsrettelser og forbedringer i link-tilstandsstyring, der findes i senere revisioner, hvilket fører til den klassiske sekvens, som enhver Linux-bruger genkender: usb 3-2: nulstil højhastigheds-USB-enhed nummer 2 ved hjælp af xhci-hcd usb 3-2: enhedsbeskrivelse læs/64, fejl -71 EXT4-fs advarsel (enhed sda2): I/O-fejl ved skrivning til inode … Tjeksumen kan blive ugyldig, når konfigurationsdata omskrives – for eksempel når broen opdaterer sine strømstyrings- eller UAS-indstillinger – og enheden mister strøm midt i skrivningen. Næste opstart registrerer en korrupt tjeksum og falder permanent tilbage til ROM-firmwaren. På det tidspunkt opfører dit „højtydende NVMe-kabinet“ sig præcis som det billigste ukendte kabinet, fordi det internt nu kører den samme fejlbehæftede basiskode, der er brændt ind i silicium. Verificering af problemet Du kan nemt bekræfte denne tilstand under Linux: lsusb -v | grep -A2 Realtek En sund Realtek-bro rapporterer en firmware-revision (bcdDevice) over 1.00. En tilbagefaldet viser: bcdDevice f0.01 Denne f0.01-signatur betyder, at controlleren starter fra ROM – og ingen mængde af frakobling, omformatering eller kernejustering vil løse det. Denne tilbagefaldsmekanisme er bekræftet på RTL9210. RTL9220 ser ud til at dele den samme designarkitektur og firmware-layout, så den kan udvise identisk adfærd, men dette er sandsynligt snarere end bevist. Hvorfor du ikke kan reparere det selv I princippet er løsningen enkel: genindlæs den korrekte firmware til SPI. I praksis gør Realtek dette umuligt. Virksomheden leverer en lukket kildekode-opdatering til Windows til OEM’er og integratorer. Linux-brugere tilbydes intet. Fællesskabsudviklere reverse-engineerede kompatible flash-værktøjer (rtsupdater, rtl9210fw, rtsupdater-cli), som tillod fuld firmware-gendannelse fra Linux-systemer – indtil Realtek udstedte DMCA-nedtagelsesmeddelelser for at undertrykke dem. Der er ingen plausibel begrundelse for intellektuel ejendom til at blokere sådanne værktøjer: de afslører ikke mikrokode, kun orkestrerer opdateringssekvensen over USB. Realteks nedtagelser handlede ikke om beskyttelse. De var ideologiske. Prisen for en ideologi Dette handler ikke om open source-idealisme. Det handler om en hardwareleverandørs ideologiske fjendtlighed over for åbne systemer, der ødelægger enheder, der markedsføres som Linux-kompatible. Realteks modstand mod dokumentation og åbne værktøjer har varet i to årtier, spændende over Wi-Fi, Ethernet, lyd og nu lagringscontrollere. Denne isolationisme kan gå ubemærket hen i en verden kun med Windows, men bliver giftig, når de samme chips integreres i produkter til flere platforme som Sabrent EC-SNVE, der åbent viser Linux-logoet på sin emballage. Ved at forbyde Linux-flashværktøjer og blokere fællesskabsvedligeholdelse har Realtek effektivt kriminaliseret selv-reparation. Konsekvenserne spreder sig udad: - Linux-brugere ser „understøttet“ hardware forfalde til ustabilitet. - OEM’er som Sabrent og Orico står over for unødvendige RMA- og garantinomkostninger. - Realteks mangeårige ry for dårlig Linux-kompatibilitet forstærkes endnu en gang. I sidste ende er det ikke open source, der ødelægger Realteks enheder – det er Realteks fjendtlighed over for open source, der ødelægger dem. En rationel vej frem Løsningen kræver ingen ideologisk ændring, kun pragmatisme. Realtek kunne: 1. Udgive en leverandørunderskrevet kommandolinje-opdatering til Linux (ingen kildekode-åbenhed nødvendig). 2. Offentliggøre tjeksum-algoritmen, så integratorer sikkert kan validere flash-billeder. 3. Udrulle en DFU-lignende tilstand, der accepterer opdateringer over USB Mass Storage, uafhængigt af OS. Hver af disse ville forhindre garantinomkostninger, beskytte OEM-relationer og genoprette tilliden til Realteks bro-chips blandt professionelle Linux-brugere – fra arbejdsstationsbyggere til Raspberry Pi-udviklere. Hvad du kan gøre Hvis du mistænker, at dit kabinet er vendt tilbage til ROM-firmware: - Tjek med lsusb -v | grep bcdDevice. - Hvis det viser f0.01, rapporter problemet til din OEM. - Inkludér uddraget fra dmesg og peg på denne dokumenterede tilbagefaldsmekanisme. - Bed din leverandør om at eskalere problemet til Realtek og nævn behovet for en Linux-kompatibel opdatering. Realteks firmware-politik generer ikke kun entusiaster; den skaber håndgribelige økonomiske tab for deres eget økosystem. Jo hurtigere denne virkelighed anerkendes i virksomheden, jo hurtigere kan både Linux-brugere og OEM-partnere stoppe med at spilde tid på unødvendige RMA-cyklusser. Producenternes svar Både Realtek og Sabrent blev inviteret til at give udtalelser om tilbagefaldsproblemet med firmwaren beskrevet ovenfor. Deres svar – hvis de modtages – vil blive tilføjet her. Tillæg – Identifikation af berørte enheder ------------------------------------------------------------------------------------------------------ Controller Leverandør-ID Produkt-ID Noter Status ------------ --------------- ------------ ----------------------------- ------------------------------ RTL9210 0x0bda 0x9210 USB 3.1 Gen 2 10 Gb/s bro Bekræftet tilbagefaldsadfærd RTL9220 0x0bda 0x9220 USB 3.2 Gen 2×2 20 Gb/s bro Mulig, lignende arkitektur ------------------------------------------------------------------------------------------------------ Firmware-tilbagefaldssignatur: bcdDevice f0.01 Kendte stabile revisioner: 1.23 – 1.31