Linux i mostek USB do NVMe Realtek RTL9210

Podsumowanie: • Objawy: Powtarzające się resety USB, błędy I/O lub znikające dyski w systemie Linux. • Dotyczy: Realtek RTL9210 (potwierdzone) oraz RTL9220 (prawdopodobnie). • Przyczyna: Powrót do wewnętrznego ROM (f0.01) po niepowodzeniu sumy kontrolnej. • Wpływ: Trwała niestabilność, brak dostępnych narzędzi do ponownego flashowania dla Linuksa. • Rozwiązanie: Tylko narzędzia OEM dla Windows mogą przywrócić oprogramowanie układowe – Realtek blokuje alternatywy open-source.

Przedmowa

W roku 2025 uruchomienie Raspberry Pi z dysku SSD podłączonego przez USB powinno być całkowicie rozsądne. Jednak z powodu osobliwości oprogramowania układowego Realtek, ten rozsądny cel stał się przygodą. Po miesiącach niewyjaśnionej niestabilności – losowe resety, znikające dyski, uszkodzone systemy plików – autor wyczerpał wszystkie standardowe poprawki: nowe kable, zasilane huby, aktualizacje jądra, modyfikacje USB i dostrajanie firmware’u. Przełom nadszedł dopiero, gdy ChatGPT odpowiedział na dziwne pytanie zadane późną nocą: „Czy możliwe jest, że mostek USB do NVMe powrócił do starego oprogramowania układowego?”

Wprowadzenie

Jeśli twoja obudowa NVMe oparta na Realtek nagle staje się niestabilna po tygodniach bezbłędnego działania – powtarzające się resety USB, błędy I/O lub znikające dyski – nie jesteś sam. Ten wzorzec pojawił się w kilku markach, od bezimiennych jednostek po znanych producentów OEM, takich jak Sabrent i Orico. Wspólnym mianownikiem są: chipy mostkowe USB do NVMe Realtek RTL9210 i prawdopodobnie RTL9220.

Początkowo wszystko działa. Następnie, pozornie bez powodu, urządzenie zaczyna się rozłączać pod obciążeniem lub podczas długotrwałego użytkowania, szczególnie na systemach Linux lub Raspberry Pi. Prawdziwą przyczyną nie jest dysk SSD ani zasilanie – to sam kontroler oprogramowania układowego, który cicho wraca do swojego wbudowanego w ROM kodu zapasowego, wersji, którą Realtek wciąż dostarcza wewnętrznie jako f0.01.

Ukryty mechanizm – Powrót oprogramowania układowego z założenia

Chipy mostkowe Realtek przechowują swoje oprogramowanie układowe operacyjne i dane konfiguracyjne w zewnętrznym flashu SPI. Przy uruchamianiu kontroler sprawdza prostą sumę kontrolną. Jeśli suma kontrolna się nie zgadza, odmawia załadowania zewnętrznego firmware’u i zamiast tego uruchamia się z wewnętrznego ROM.

Ten zapasowy firmware jest przestarzały i wadliwy. Brakuje w nim wielu poprawek stabilności USB i ulepszeń zarządzania stanem łącza, które są obecne w późniejszych wersjach, co prowadzi do klasycznej sekwencji, którą rozpoznaje każdy użytkownik Linuksa:

usb 3-2: reset szybkiego urządzenia USB numer 2 za pomocą xhci-hcd
usb 3-2: odczyt deskryptora urządzenia/64, błąd -71
Ostrzeżenie EXT4-fs (urządzenie sda2): Błąd I/O podczas zapisu do inoda …

Suma kontrolna może stać się nieważna, gdy dane konfiguracyjne są nadpisywane – na przykład, gdy mostek aktualizuje ustawienia zarządzania energią lub UAS – a urządzenie traci zasilanie w trakcie zapisu. Kolejne uruchomienie wykrywa uszkodzoną sumę kontrolną i trwale wraca do firmware’u ROM.

W tym momencie twoja „wysokowydajna obudowa NVMe” zachowuje się dokładnie jak najtańsza bezimienna obudowa, ponieważ wewnętrznie działa teraz na tym samym wadliwym kodzie bazowym, który został wypalony w krzemie.

Weryfikacja problemu

Możesz łatwo potwierdzić ten stan w systemie Linux:

lsusb -v | grep -A2 Realtek

Zdrowy mostek Realtek zgłasza wersję oprogramowania układowego (bcdDevice) powyżej 1.00. Wrócony do tyłu pokazuje:

bcdDevice f0.01

Ten podpis f0.01 oznacza, że kontroler uruchamia się z ROM – i żadna ilość odłączania, ponownego formatowania czy strojenia jądra tego nie naprawi.

Ten mechanizm powrotu został potwierdzony dla RTL9210. RTL9220 wydaje się dzielić tę samą architekturę projektową i układ oprogramowania układowego, więc może wykazywać identyczne zachowanie, ale pozostaje to prawdopodobne, a nie udowodnione.

Dlaczego nie możesz tego naprawić samodzielnie

Zasadniczo rozwiązanie jest proste: ponownie wgrać poprawny firmware na SPI. W praktyce Realtek czyni to niemożliwym.

Firma dostarcza zamknięte oprogramowanie aktualizujące dla Windows dla producentów OEM i integratorów. Użytkownicy Linuksa nie otrzymują nic. Deweloperzy społeczności przeprowadzili inżynierię wsteczną kompatybilnych narzędzi do flashowania (rtsupdater, rtl9210fw, rtsupdater-cli), które umożliwiały pełne przywrócenie oprogramowania układowego z systemów Linux – dopóki Realtek nie wydał żądań usunięcia DMCA, aby je stłumić.

Nie ma wiarygodnego uzasadnienia dla własności intelektualnej, aby blokować takie narzędzia: nie ujawniają one mikrokodu, a jedynie organizują sekwencję aktualizacji przez USB. Usunięcia Realtek nie dotyczyły ochrony. Były ideologiczne.

Cena ideologii

To nie jest kwestia idealizmu open-source. Chodzi o ideologiczną wrogość dostawcy sprzętu wobec otwartych systemów, która niszczy urządzenia sprzedawane jako kompatybilne z Linuksem.

Opór Realtek wobec dokumentacji i otwartych narzędzi trwa od dwóch dekad, obejmując Wi-Fi, Ethernet, audio, a teraz kontrolery pamięci masowej. Ta izolacja może pozostać niezauważona w świecie tylko Windows, ale staje się toksyczna, gdy te same chipy są integrowane w produktach wieloplatformowych, takich jak Sabrent EC-SNVE, który otwarcie wyświetla logo Linuksa na swoim opakowaniu.

Zakazując narzędzi flashowania dla Linuksa i blokując konserwację społeczności, Realtek skutecznie skryminalizował samodzielną naprawę. Konsekwencje rozprzestrzeniają się na zewnątrz:

• Użytkownicy Linuksa widzą, jak „wspierany” sprzęt degraduje się do niestabilności.
• Producenci OEM, tacy jak Sabrent i Orico, ponoszą niepotrzebne koszty RMA i gwarancji.
• Długotrwała reputacja Realtek za słabą kompatybilność z Linuksem zostaje po raz kolejny wzmocniona.

Ostatecznie to nie open-source niszczy urządzenia Realtek – to wrogość Realtek wobec open-source je niszczy.

Racjonalna droga naprzód

Rozwiązanie nie wymaga zmiany ideologicznej, tylko pragmatyzmu. Realtek mógłby:

1. Wydać narzędzie aktualizujące w linii poleceń podpisane przez dostawcę dla Linuksa (nie jest wymagane ujawnianie kodu źródłowego).
2. Opublikować algorytm sumy kontrolnej, aby integratorzy mogli bezpiecznie weryfikować obrazy flash.
3. Przyjąć tryb w stylu DFU, który akceptuje aktualizacje przez pamięć masową USB, niezależnie od systemu operacyjnego.

Każdy z tych kroków zapobiegłby kosztom gwarancyjnym, chronił relacje z OEM i przywrócił zaufanie do chipów mostkowych Realtek wśród profesjonalnych użytkowników Linuksa – od budowniczych stacji roboczych po deweloperów Raspberry Pi.

Co możesz zrobić

Jeśli podejrzewasz, że twoja obudowa wróciła do firmware’u ROM:

• Sprawdź za pomocą lsusb -v | grep bcdDevice.
• Jeśli pokazuje f0.01, zgłoś problem swojemu OEM.
• Dołącz fragment dmesg i wskaż ten udokumentowany mechanizm powrotu.
• Poproś swojego dostawcę, aby eskalował problem do Realtek, powołując się na potrzebę narzędzia aktualizującego kompatybilnego z Linuksem.

Polityka firmware Realtek nie tylko przeszkadza entuzjastom; tworzy realne straty finansowe dla ich własnego ekosystemu. Im szybciej ta rzeczywistość zostanie uznana w firmie, tym szybciej użytkownicy Linuksa i partnerzy OEM mogą przestać marnować czas na możliwe do uniknięcia cykle RMA.

Odpowiedzi producentów

Zarówno Realtek, jak i Sabrent zostali zaproszeni do złożenia oświadczeń dotyczących problemu powrotu oprogramowania układowego opisanego powyżej. Ich odpowiedzi – jeśli zostaną otrzymane – zostaną dodane tutaj.

Załącznik – Identyfikacja dotkniętych urządzeń

Sygnatura powrotu oprogramowania układowego: bcdDevice f0.01
Znane stabilne wersje: 1.23 – 1.31