لينكس وجسر Realtek RTL9210 USB إلى NVMe

  الملخص:
  • الأعراض: إعادة ضبط 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 إصلاح الذات جريمة. تمتد العواقب إلى الخارج:

-   يرى مستخدمو لينكس أجهزة “مدعومة” تتدهور إلى عدم استقرار.
-   تواجه الشركات المصنعة مثل Sabrent وOrico تكاليف RMA وتكاليف الضمان غير الضرورية.
-   يتم تعزيز سمعة Realtek الطويلة في ضعف التوافق مع لينكس مرة أخرى.

في النهاية، ليس المصدر المفتوح هو الذي يكسر أجهزة Realtek - إنه عداء Realtek للمصدر المفتوح هو الذي يكسرها.

طريق عقلاني للأمام

الحل لا يتطلب تحولًا أيديولوجيًا، فقط الواقعية. يمكن لـ Realtek:

1.  إصدار مُحدِّث سطر أوامر موقع من البائع للينكس (لا حاجة للكشف عن المصدر).
2.  نشر خوارزمية الجملة الاختبارية حتى يتمكن المتكاملون من إعادة التحقق من صور الفلاش بأمان.
3.  اعتماد وضع DFU-style الذي يقبل التحديثات عبر تخزين USB الجماعي، بغض النظر عن نظام التشغيل.

كل من هذه الخطوات ستمنع تكاليف الضمان، وتحمي علاقات الشركات المصنعة، وتستعيد الثقة في رقائق جسر Realtek بين مستخدمي لينكس المحترفين - من بناة محطات العمل إلى مطوري Raspberry Pi.

ما يمكنك فعله

إذا كنت تشك في أن حاويتك قد عادت إلى برنامج الروم الثابت:

-   تحقق باستخدام lsusb -v | grep bcdDevice.
-   إذا أظهرت f0.01، أبلغ المشكلة إلى الشركة المصنعة الخاصة بك.
-   قم بتضمين مقتطف dmesg وأشر إلى آلية الرجوع الموثقة هذه.
-   اطلب من بائعك تصعيد المشكلة مع Realtek، مشيرًا إلى الحاجة إلى مُحدِّث متوافق مع لينكس.

سياسة برنامج 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