https://jakarta.ninkilim.com/articles/rtl9210_usb_to_nvme_bridge/ar.html
الملخص: • الأعراض: إعادة ضبط USB المتكررة، أخطاء الإدخال/الإخراج، أو اختفاء الأقراص تحت لينكس. • المتأثرون: Realtek RTL9210 (مؤكد) وRTL9220 (محتمل). • السبب: الرجوع إلى الروم الداخلي (
f0.01) بعد فشل فحص الجملة الاختبارية. • التأثير: عدم استقرار دائم، لا توجد أدوات إعادة تحميل تحت لينكس. • الحل: فقط الأدوات المسجلة لنظام ويندوز يمكنها استعادة البرنامج الثابت - Realtek تمنع البدائل مفتوحة المصدر.
في عام 2025 م، يجب أن يكون من المنطقي تمامًا تشغيل Raspberry Pi من SSD متصل عبر USB. ومع ذلك، بفضل نزوات برنامج Realtek الثابت، أصبح هذا الهدف المعقول مغامرة. بعد أشهر من عدم الاستقرار غير المفسر - إعادة الضبط العشوائية، اختفاء الأقراص، تلف أنظمة الملفات - استنفد المؤلف كل إصلاح عادي: كابلات جديدة، مراكز طاقة، تحديثات الكيرنل، تعديلات USB، وضبط البرامج الثابتة. جاء الاختراق فقط عندما أجاب ChatGPT على سؤال غريب في وقت متأخر من الليل: “هل من الممكن أن يكون جسر USB إلى NVMe قد عاد إلى برنامج ثابت قديم؟”
إذا أصبحت حاوية NVMe القائمة على Realtek غير مستقرة فجأة بعد أسابيع من التشغيل المثالي - إعادة ضبط USB المتكررة، أخطاء الإدخال/الإخراج، أو اختفاء الأقراص - فأنت لست وحدك. ظهر النمط عبر عدة علامات تجارية، من الوحدات غير المعروفة إلى الشركات المصنعة المعروفة مثل Sabrent وOrico. الجامع المشترك: رقائق جسر USB إلى NVMe من Realtek RTL9210 وربما RTL9220.
في البداية، كل شيء يعمل. ثم، على ما يبدو بدون سبب، يبدأ الجهاز في الانقطاع تحت الحمل أو أثناء الاستخدام الممتد، خاصة على أنظمة لينكس أو Raspberry Pi. السبب الحقيقي ليس SSD أو مصدر الطاقة - إنه وحدة التحكم بالبرنامج الثابت نفسها التي تعود بهدوء إلى كود الرجوع المدمج في الروم، وهو الإصدار الذي لا يزال Realtek يشحنه داخليًا كـ f0.01.
تخزن رقائق جسر Realtek برامجها الثابتة وبيانات التكوين في فلاش SPI خارجي. عند التشغيل، تتحقق وحدة التحكم من جملة اختبارية بسيطة. إذا لم تتطابق الجملة الاختبارية، فإنها ترفض تحميل البرنامج الثابت الخارجي وتبدأ بدلاً من ذلك من الروم الداخلي.
هذا البرنامج الثابت الاحتياطي قديم ومعيب. يفتقر إلى عدة إصلاحات لاستقرار USB وتحسينات إدارة حالة الرابط الموجودة في الإصدارات اللاحقة، مما يؤدي إلى التسلسل الكلاسيكي الذي يتعرف عليه كل مستخدم لينكس:
usb 3-2: إعادة ضبط جهاز USB عالي السرعة رقم 2 باستخدام xhci-hcd
usb 3-2: خطأ قراءة واصف الجهاز/64، الخطأ -71
تحذير EXT4-fs (الجهاز sda2): خطأ الإدخال/الإخراج أثناء الكتابة إلى العقدة …
يمكن أن تصبح الجملة الاختبارية غير صالحة عندما يتم إعادة كتابة بيانات التكوين - على سبيل المثال، عندما يقوم الجسر بتحديث إعدادات إدارة الطاقة أو UAS - ويفقد الجهاز الطاقة أثناء الكتابة. عند التشغيل التالي، يرى الجملة الاختبارية التالفة ويعود إلى البرنامج الثابت للروم بشكل دائم.
في تلك النقطة، تتصرف حاوية NVMe “عالية الأداء” الخاصة بك تمامًا مثل أرخص قشرة غير معروفة، لأنها تعمل الآن داخليًا بنفس الكود الأساسي المعيب المحروق في السيليكون.
يمكنك تأكيد هذه الحالة بسهولة تحت لينكس:
lsusb -v | grep -A2 Realtek
يبلغ جسر Realtek السليم عن إصدار برنامج ثابت (bcdDevice) أعلى من 1.00. يظهر الجسر المرتجع:
bcdDevice f0.01
توقيع f0.01 هذا يعني أن وحدة التحكم تعمل من الروم - ولا مقدار من الفصل، إعادة التهيئة، أو ضبط الكيرنل سيصلحها.
تم تأكيد آلية الرجوع هذه على RTL9210. يبدو أن RTL9220 يشارك نفس تصميم الهندسة وتخطيط البرنامج الثابت، لذا قد يظهر سلوكًا مماثلاً، لكن هذا يبقى محتملاً وليس مؤكدًا.
من حيث المبدأ، الإصلاح بسيط: إعادة تحميل البرنامج الثابت الصحيح إلى SPI. في الممارسة، تجعل Realtek هذا مستحيلاً.
توفر الشركة مُحدِّث ويندوز مغلق المصدر للشركات المصنعة ومتكاملي الأنظمة. لا يُعرض شيء لمستخدمي لينكس. قام مطورو المجتمع بتفكيك أدوات فلاش متوافقة (rtsupdater، rtl9210fw، rtsupdater-cli) التي سمحت باستعادة البرنامج الثابت بالكامل من أنظمة لينكس - حتى أصدرت Realtek إشعارات إزالة DMCA لقمعها.
لا يوجد مبرر منطقي لحقوق الملكية الفكرية لمنع هذه الأدوات: فهي لا تكشف عن الميكروكود، بل تنظم فقط تسلسل التحديث عبر USB. كانت إزالات Realtek ليست عن الحماية. كانت أيديولوجية.
هذا ليس عن المثالية مفتوحة المصدر. إنه عن عداء أيديولوجي لبائع الأجهزة تجاه الأنظمة المفتوحة يكسر الأجهزة التي يتم تسويقها على أنها متوافقة مع لينكس.
استمر مقاومة Realtek للتوثيق والأدوات المفتوحة لعقدين من الزمان، تغطي Wi-Fi، Ethernet، الصوت، والآن وحدات التحكم في التخزين. قد لا تُلاحظ هذه العزلة في عالم يعمل فقط على ويندوز، لكنها تصبح سامة عندما يتم دمج هذه الرقائق في منتجات متعددة المنصات مثل Sabrent EC-SNVE، التي تعرض شعار لينكس بشكل علني على تغليفها.
من خلال منع أدوات الفلاش للينكس وحظر صيانة المجتمع، جعلت Realtek إصلاح الذات جريمة. تمتد العواقب إلى الخارج:
في النهاية، ليس المصدر المفتوح هو الذي يكسر أجهزة Realtek - إنه عداء Realtek للمصدر المفتوح هو الذي يكسرها.
الحل لا يتطلب تحولًا أيديولوجيًا، فقط الواقعية. يمكن لـ Realtek:
كل من هذه الخطوات ستمنع تكاليف الضمان، وتحمي علاقات الشركات المصنعة، وتستعيد الثقة في رقائق جسر Realtek بين مستخدمي لينكس المحترفين - من بناة محطات العمل إلى مطوري Raspberry Pi.
إذا كنت تشك في أن حاويتك قد عادت إلى برنامج الروم الثابت:
lsusb -v | grep bcdDevice.f0.01، أبلغ المشكلة إلى الشركة المصنعة الخاصة بك.dmesg وأشر إلى آلية الرجوع الموثقة هذه.سياسة برنامج Realtek الثابت لا تزعج المتحمسين فقط؛ إنها تخلق خسارة مالية ملموسة لنظامها البيئي الخاص. كلما تم الاعتراف بهذه الحقيقة داخل الشركة مبكرًا، كلما تمكن مستخدمو لينكس وشركاء الشركات المصنعة من التوقف عن إضاعة الوقت في دورات RMA القابلة للتجنب.
تمت دعوة كل من Realtek وSabrent لتقديم بيانات بشأن مشكلة الرجوع إلى البرنامج الثابت الموضحة أعلاه. سيتم إضافة ردودهم - إذا تم استلامها - هنا.
| وحدة التحكم | معرف البائع | معرف المنتج | الملاحظات | الحالة |
|---|---|---|---|---|
| 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