# लिनक्स और रियलटेक RTL9210 USB से NVMe ब्रिज

> **सारांश:**  
> • **लक्षण:** बार-बार USB रीसेट, I/O त्रुटियाँ, या लिनक्स में ड्राइव गायब होना।  
> • **प्रभावित:** रियलटेक RTL9210 (पुष्टि की गई) और RTL9220 (संभवतः)।  
> • **कारण:** चेकसम विफलता के बाद आंतरिक ROM (**f0.01**) पर वापसी।  
> • **प्रभाव:** स्थायी अस्थिरता, लिनक्स के लिए कोई रीफ्लैश टूल उपलब्ध नहीं।  
> • **समाधान:** केवल OEM विंडोज उपयोगिताएँ फर्मवेयर को पुनर्स्थापित कर सकती हैं - रियलटेक ओपन-सोर्स विकल्पों को अवरुद्ध करता है।

## प्रस्तावना

वर्ष 2025 में, USB के माध्यम से जुड़े SSD से रास्पबेरी पाई को बूट करना पूरी तरह से उचित होना चाहिए। फिर भी, रियलटेक के फर्मवेयर की विचित्रताओं के कारण, यह उचित लक्ष्य एक साहसिक कार्य बन गया है। महीनों की अस्पष्ट अस्थिरता के बाद - यादृच्छिक रीसेट, गायब ड्राइव, दूषित फाइल सिस्टम - लेखक ने हर सामान्य समाधान को आजमा लिया: नए केबल, पावर हब, कर्नेल अपडेट, USB ट्वीक, और फर्मवेयर ट्यूनिंग। सफलता तब मिली जब ChatGPT ने देर रात पूछे गए एक अजीब सवाल का जवाब दिया:
"क्या यह संभव है कि USB से NVMe ब्रिज पुराने फर्मवेयर पर वापस चला गया हो?"

## परिचय

यदि आपका रियलटेक-आधारित NVMe एनक्लोजर हफ्तों तक बिना किसी त्रुटि के काम करने के बाद अचानक अस्थिर हो जाता है - बार-बार USB रीसेट, I/O त्रुटियाँ, या गायब ड्राइव - तो आप अकेले नहीं हैं। यह पैटर्न कई ब्रांडों में देखा गया है, बिना नाम की इकाइयों से लेकर Sabrent और Orico जैसे प्रसिद्ध OEM तक। सामान्य कारक: **रियलटेक के RTL9210 और संभवतः RTL9220** USB से NVMe ब्रिज चिप्स।

शुरुआत में, सब कुछ काम करता है। फिर, बिना किसी स्पष्ट कारण के, डिवाइस लोड के तहत या लंबे समय तक उपयोग के दौरान, विशेष रूप से लिनक्स या रास्पबेरी पाई सिस्टम पर, डिस्कनेक्ट होने लगता है। असली कारण SSD या पावर सप्लाई नहीं है - यह स्वयं फर्मवेयर नियंत्रक है जो चुपके से अपने **ROM में एम्बेडेड बैकअप कोड** पर वापस चला जाता है, एक संस्करण जिसे रियलटेक अभी भी आंतरिक रूप से **f0.01** के रूप में शिप करता है।

## छिपा हुआ तंत्र - डिज़ाइन द्वारा फर्मवेयर रोल बैक

रियलटेक के ब्रिज चिप्स अपने ऑपरेशनल फर्मवेयर और कॉन्फिगरेशन डेटा को एक बाहरी SPI फ्लैश में स्टोर करते हैं। पावर-ऑन पर, नियंत्रक एक साधारण चेकसम की जाँच करता है। यदि वह चेकसम मेल नहीं खाता, तो यह बाहरी फर्मवेयर को लोड करने से इनकार करता है और इसके बजाय अपने आंतरिक ROM से बूट करता है।

यह बैकअप फर्मवेयर पुराना और दोषपूर्ण है। इसमें कई USB स्थिरता सुधार और लिंक-स्टेट प्रबंधन सुधारों की कमी है जो बाद के संशोधनों में मौजूद हैं, जिसके परिणामस्वरूप वह क्लासिक अनुक्रम होता है जिसे हर लिनक्स उपयोगकर्ता पहचानता है:

> usb 3-2: xhci-hcd का उपयोग करके हाई-स्पीड USB डिवाइस नंबर 2 को रीसेट करें  
> usb 3-2: डिवाइस डिस्क्रिप्टर पढ़ने/64, त्रुटि -71  
> EXT4-fs चेतावनी (डिवाइस sda2): इनोड में लेखन के दौरान I/O त्रुटि ...

चेकसम तब अमान्य हो सकता है जब कॉन्फिगरेशन डेटा को फिर से लिखा जाता है - उदाहरण के लिए, जब ब्रिज अपने पावर-मैनेजमेंट या UAS सेटिंग्स को अपडेट करता है - और डिवाइस लेखन के बीच में पावर खो देता है। अगला बूट एक दूषित चेकसम देखता है और स्थायी रूप से ROM फर्मवेयर पर वापस चला जाता है।

उस समय, आपका "उच्च-प्रदर्शन NVMe एनक्लोजर" ठीक उसी तरह व्यवहार करता है जैसे सबसे सस्ता बिना नाम का शेल, क्योंकि यह आंतरिक रूप से अब वही दोषपूर्ण बेस कोड चला रहा है जो सिलिकॉन में जला हुआ है।

## समस्या की पुष्टि

आप लिनक्स में इस स्थिति की आसानी से पुष्टि कर सकते हैं:

> lsusb -v | grep -A2 Realtek

एक स्वस्थ रियलटेक ब्रिज फर्मवेयर संशोधन (**bcdDevice**) 1.00 से ऊपर की रिपोर्ट करता है। एक वापस लौटा हुआ दिखाता है:

> bcdDevice           f0.01

यह **f0.01** हस्ताक्षर का मतलब है कि नियंत्रक ROM से बूट हो रहा है - और कोई भी अनप्लगिंग, रीफॉर्मेटिंग, या कर्नेल ट्यूनिंग इसे ठीक नहीं करेगा।

यह रोल बैक तंत्र **RTL9210 पर पुष्टि किया गया है**। **RTL9220** में समान डिज़ाइन आर्किटेक्चर और फर्मवेयर लेआउट साझा करने की संभावना है, इसलिए यह समान व्यवहार प्रदर्शित कर सकता है, लेकिन यह **संभावित है, सिद्ध नहीं**।

## आप इसे स्वयं क्यों ठीक नहीं कर सकते

सिद्धांत रूप में, समाधान सरल है: सही फर्मवेयर को SPI पर फिर से फ्लैश करें। व्यवहार में, रियलटेक इसे असंभव बनाता है।

कंपनी OEM और इंटीग्रेटर्स को एक बंद-स्रोत विंडोज अपडेटर प्रदान करती है। लिनक्स उपयोगकर्ताओं को कुछ भी नहीं दिया जाता। समुदाय के डेवलपर्स ने संगत फ्लैश उपयोगिताओं (**rtsupdater**, **rtl9210fw**, **rtsupdater-cli**) को रिवर्स-इंजीनियर किया जो लिनक्स सिस्टम से पूर्ण फर्मवेयर पुनर्स्थापन की अनुमति देता था - जब तक कि रियलटेक ने **DMCA टेकडाउन नोटिस** जारी करके उन्हें दबा नहीं दिया।

ऐसे उपकरणों को अवरुद्ध करने के लिए कोई विश्वसनीय बौद्धिक संपदा तर्क नहीं है: वे माइक्रोकोड को उजागर नहीं करते, केवल USB के माध्यम से अपडेट अनुक्रम को व्यवस्थित करते हैं। रियलटेक के टेकडाउन सुरक्षा के बारे में नहीं थे। वे वैचारिक थे।

## एक विचारधारा की कीमत

यह ओपन-सोर्स आदर्शवाद के बारे में नहीं है। यह एक हार्डवेयर विक्रेता की **खुले सिस्टम के प्रति वैचारिक शत्रुता** के बारे में है जो उन उपकरणों को तोड़ देता है जो *लिनक्स-संगत* के रूप में विपणन किए जाते हैं।

रियलटेक का दस्तावेजीकरण और खुले उपकरणों के प्रति प्रतिरोध दो दशकों से चला आ रहा है, जिसमें वाई-फाई, ईथरनेट, ऑडियो और अब स्टोरेज नियंत्रक शामिल हैं। यह अलगाव एक केवल विंडोज वाले विश्व में शायद ध्यान न जाए, लेकिन यह विषाक्त हो जाता है जब वही चिप्स मल्टी-प्लेटफॉर्म उत्पादों जैसे **Sabrent EC-SNVE** में एकीकृत होते हैं, जो खुले तौर पर अपने पैकेजिंग पर लिनक्स लोगो प्रदर्शित करता है।

लिनक्स फ्लैश उपयोगिताओं को प्रतिबंधित करके और समुदाय के रखरखाव को अवरुद्ध करके, रियलटेक ने प्रभावी रूप से **स्वयं-मरम्मत को अपराध बना दिया है**। परिणाम बाहर की ओर फैलते हैं:

* लिनक्स उपयोगकर्ता "समर्थित" हार्डवेयर को अस्थिरता में बदलते देखते हैं।
* Sabrent और Orico जैसे OEM को अनावश्यक RMA और वारंटी लागतों का सामना करना पड़ता है।
* रियलटेक की लिनक्स के साथ खराब संगतता की लंबे समय से चली आ रही प्रतिष्ठा फिर से मजबूत होती है।

अंत में, यह ओपन सोर्स नहीं है जो रियलटेक के उपकरणों को तोड़ता है - यह **रियलटेक की ओपन सोर्स के प्रति शत्रुता** है जो उन्हें तोड़ती है।

## एक तर्कसंगत मार्ग आगे

समाधान के लिए किसी वैचारिक बदलाव की आवश्यकता नहीं है, केवल व्यावहारिकता। रियलटेक निम्नलिखित कर सकता है:

1. लिनक्स के लिए एक विक्रेता-हस्ताक्षरित कमांड-लाइन अपडेटर जारी करें (स्रोत कोड प्रकटीकरण की आवश्यकता नहीं)।
2. चेकसम एल्गोरिदम प्रकाशित करें ताकि इंटीग्रेटर्स सुरक्षित रूप से फ्लैश इमेज को मान्य कर सकें।
3. एक DFU-शैली मोड अपनाएँ जो USB मास स्टोरेज के माध्यम से अपडेट स्वीकार करता हो, ऑपरेटिंग सिस्टम से स्वतंत्र।

इनमें से प्रत्येक वारंटी लागत को रोकेगा, OEM संबंधों की रक्षा करेगा, और वर्कस्टेशन बिल्डरों से लेकर रास्पबेरी पाई डेवलपर्स तक पेशेवर लिनक्स उपयोगकर्ताओं के बीच रियलटेक के ब्रिज चिप्स में विश्वास बहाल करेगा।

## आप क्या कर सकते हैं

यदि आपको संदेह है कि आपका एनक्लोजर ROM फर्मवेयर पर वापस चला गया है:

* **lsusb -v | grep bcdDevice** के साथ जाँच करें।
* यदि यह **f0.01** दिखाता है, तो अपने OEM को समस्या की सूचना दें।
* **dmesg** का अंश शामिल करें और इस प्रलेखित रोल बैक तंत्र की ओर इशारा करें।
* अपने विक्रेता से अनुरोध करें कि वह रियलटेक के साथ समस्या को बढ़ाए, लिनक्स-संगत अपडेटर की आवश्यकता का हवाला देते हुए।

रियलटेक की फर्मवेयर नीति केवल उत्साहियों को परेशान नहीं करती; यह उनके अपने पारिस्थितिकी तंत्र के लिए ठोस वित्तीय नुकसान पैदा करती है। जितनी जल्दी कंपनी के भीतर इस वास्तविकता को स्वीकार किया जाता है, उतनी ही जल्दी लिनक्स उपयोगकर्ता और OEM भागीदार बचने योग्य RMA चक्रों में समय बर्बाद करना बंद कर सकते हैं।

## निर्माताओं की प्रतिक्रियाएँ

रियलटेक और Sabrent दोनों को उपरोक्त वर्णित फर्मवेयर रोल बैक समस्या के बारे में बयान देने के लिए आमंत्रित किया गया था। उनकी प्रतिक्रियाएँ - यदि प्राप्त होती हैं - यहाँ जोड़ी जाएँगी।

## परिशिष्ट - प्रभावित उपकरणों की पहचान

| नियंत्रक    | विक्रेता ID | उत्पाद ID | टिप्पणियाँ                        | स्थिति                            |
|------------|-------------|-----------|----------------------------------|-----------------------------------|
| RTL9210    | 0x0bda      | 0x9210    | USB 3.1 Gen 2 10 Gb/s ब्रिज      | **पुष्टि** रोल बैक व्यवहार        |
| RTL9220    | 0x0bda      | 0x9220    | USB 3.2 Gen 2×2 20 Gb/s ब्रिज    | **संभावित**, समान आर्किटेक्चर     |

फर्मवेयर रोल बैक हस्ताक्षर: **bcdDevice f0.01**  
ज्ञात स्थिर संशोधन: **1.23** – **1.31**