https://ninkilim.com/articles/rtl9210_usb_to_nvme_bridge/th.html
สรุป: • อาการ: การรีเซ็ต USB ซ้ำๆ, ข้อผิดพลาด I/O, หรือดิสก์หายไปใน Linux • ได้รับผลกระทบ: Realtek RTL9210 (ยืนยันแล้ว) และ RTL9220 (อาจเป็นไปได้) • สาเหตุ: การย้อนกลับไปใช้ ROM ภายใน (
f0.01) หลังจากเกิดข้อผิดพลาด checksum • ผลกระทบ: ความไม่เสถียรถาวร, ไม่มีเครื่องมือ reflashing สำหรับ Linux • วิธีแก้ไข: เฉพาะยูทิลิตี้ OEM ของ Windows เท่านั้นที่สามารถกู้คืนเฟิร์มแวร์ได้ – Realtek บล็อกตัวเลือกโอเพนซอร์ส
ในปี 2025 การบูต Raspberry Pi จาก SSD ที่เชื่อมต่อผ่าน USB ควรเป็นเรื่องที่สมเหตุสมผลอย่างยิ่ง อย่างไรก็ตาม เนื่องจากความแปลกประหลาดของเฟิร์มแวร์ Realtek เป้าหมายที่สมเหตุสมผลนี้ได้กลายเป็นการผจญภัย หลังจากหลายเดือนของความไม่เสถียรที่อธิบายไม่ได้ – การรีเซ็ตแบบสุ่ม, ดิสก์ที่หายไป, ระบบไฟล์ที่เสียหาย – ผู้เขียนได้ลองทุกวิธีแก้ไขทั่วไป: สายเคเบิลใหม่, ฮับที่ใช้พลังงาน, การอัปเดตเคอร์เนล, การปรับแต่ง USB และการปรับแต่งเฟิร์มแวร์ ความก้าวหน้าเกิดขึ้นเมื่อ ChatGPT ตอบคำถามแปลกๆ ในช่วงดึก: “เป็นไปได้ไหมที่บริดจ์ USB ไปยัง NVMe จะย้อนกลับไปใช้เฟิร์มแวร์เก่า?”
หากเคส NVMe ที่ใช้ Realtek ของคุณกลายเป็นไม่เสถียรอย่างกะทันหันหลังจากทำงานได้อย่างสมบูรณ์เป็นเวลาหลายสัปดาห์ – การรีเซ็ต USB ซ้ำๆ, ข้อผิดพลาด I/O, หรือดิสก์ที่หายไป – คุณไม่ได้อยู่คนเดียว รูปแบบนี้ปรากฏในหลายยี่ห้อ ตั้งแต่หน่วยที่ไม่มีชื่อไปจนถึง OEM ที่รู้จักกันดีเช่น Sabrent และ Orico จุดร่วม: ชิปบริดจ์ USB ไปยัง NVMe ของ Realtek RTL9210 และอาจเป็น RTL9220
ในตอนแรกทุกอย่างทำงานได้ดี จากนั้น โดยไม่มีสาเหตุที่ชัดเจน อุปกรณ์เริ่มตัดการเชื่อมต่อเมื่ออยู่ภายใต้การโหลดหรือใช้งานเป็นเวลานาน โดยเฉพาะในระบบ Linux หรือ Raspberry Pi สาเหตุที่แท้จริงไม่ใช่ SSD หรือแหล่งจ่ายไฟ – แต่เป็นตัวควบคุมเฟิร์มแวร์เองที่ย้อนกลับไปใช้ โค้ดสำรองที่ฝังอยู่ใน ROM อย่างเงียบๆ ซึ่งเป็นรุ่นที่ Realtek ยังคงจัดส่งภายในเป็น f0.01
ชิปบริดจ์ของ Realtek เก็บเฟิร์มแวร์การทำงานและข้อมูลการกำหนดค่าไว้ในแฟลช SPI ภายนอก เมื่อเปิดเครื่อง ตัวควบคุมจะตรวจสอบ checksum อย่างง่าย หาก checksum นั้นไม่ตรงกัน มันจะปฏิเสธการโหลดเฟิร์มแวร์ภายนอกและบูตจาก ROM ภายในแทน
เฟิร์มแวร์สำรองนี้ล้าสมัยและมีข้อบกพร่อง มันขาดการแก้ไขความเสถียรของ USB และการปรับปรุงการจัดการสถานะลิงก์ที่มีอยู่ในรุ่นที่ใหม่กว่า ซึ่งนำไปสู่ลำดับคลาสสิกที่ผู้ใช้ Linux ทุกคนรู้จัก:
usb 3-2: รีเซ็ตอุปกรณ์ USB ความเร็วสูงหมายเลข 2 โดยใช้ xhci-hcd
usb 3-2: อ่านตัวอธิบายอุปกรณ์/64, ข้อผิดพลาด -71
คำเตือน EXT4-fs (อุปกรณ์ sda2): ข้อผิดพลาด I/O ขณะเขียนไปยัง inode …
Checksum อาจกลายเป็นไม่ถูกต้องเมื่อข้อมูลการกำหนดค่าถูกเขียนทับ – ตัวอย่างเช่น เมื่อบริดจ์อัปเดตการตั้งค่าการจัดการพลังงานหรือ UAS – และอุปกรณ์สูญเสียพลังงานระหว่างการเขียน การบูตครั้งต่อไปจะตรวจพบ checksum ที่เสียหายและย้อนกลับไปใช้เฟิร์มแวร์ ROM อย่างถาวร
ในจุดนี้ “เคส NVMe ประสิทธิภาพสูง” ของคุณทำงานเหมือนกับเคสที่ถูกที่สุดที่ไม่มีชื่อ เพราะภายในมันกำลังทำงานด้วยโค้ดพื้นฐานที่มีข้อบกพร่องเดียวกันที่ถูกฝังอยู่ในซิลิคอน
คุณสามารถยืนยันสถานะนี้ได้อย่างง่ายดายใน Linux:
lsusb -v | grep -A2 Realtek
บริดจ์ Realtek ที่สมบูรณ์จะรายงานรุ่นเฟิร์มแวร์ (bcdDevice) สูงกว่า 1.00 อันที่ย้อนกลับจะแสดง:
bcdDevice f0.01
ลายเซ็น f0.01 นี้หมายความว่าตัวควบคุมกำลังบูตจาก ROM – และการถอดปลั๊ก การฟอร์แมตใหม่ หรือการปรับแต่งเคอร์เนลใดๆ จะไม่สามารถแก้ไขได้
กลไกการย้อนกลับนี้ได้รับ การยืนยันสำหรับ RTL9210 RTL9220 ดูเหมือนจะมีสถาปัตยกรรมการออกแบบและการจัดวางเฟิร์มแวร์เหมือนกัน ดังนั้นอาจแสดงพฤติกรรมที่เหมือนกัน แต่ยังคง เป็นไปได้ ไม่ใช่ได้รับการพิสูจน์
ในทางทฤษฎี การแก้ไขนั้นง่าย: reflashing เฟิร์มแวร์ที่ถูกต้องลงใน SPI ในทางปฏิบัติ Realtek ทำให้สิ่งนี้เป็นไปไม่ได้
บริษัทจัดหายูทิลิตี้การอัปเดตแบบปิดซอร์สสำหรับ Windows ให้กับ OEM และผู้รวมระบบ ผู้ใช้ Linux ไม่ได้รับอะไรเลย นักพัฒนาชุมชนทำวิศวกรรมย้อนกลับเครื่องมือแฟลชที่เข้ากันได้ (rtsupdater, rtl9210fw, rtsupdater-cli) ซึ่งทำให้สามารถกู้คืนเฟิร์มแวร์ได้อย่างสมบูรณ์จากระบบ Linux – จนกระทั่ง Realtek ออก แจ้งเตือนการถอน DMCA เพื่อปราบปรามพวกเขา
ไม่มีเหตุผลทางปัญญาที่น่าเชื่อถือในการบล็อกเครื่องมือดังกล่าว: พวกเขาไม่ได้เปิดเผยไมโครโค้ด แต่เพียงจัดการลำดับการอัปเดตผ่าน USB การถอนของ Realtek ไม่ได้เกี่ยวกับการป้องกัน มันเป็นเรื่องของอุดมการณ์
นี่ไม่ใช่เรื่องของอุดมคติของโอเพนซอร์ส มันเกี่ยวกับ ความเป็นศัตรูทางอุดมการณ์ของผู้จำหน่ายฮาร์ดแวร์ต่อระบบที่เปิดกว้าง ที่ทำลายอุปกรณ์ที่ถูกวางตลาดว่า เข้ากันได้กับ Linux
การต่อต้านเอกสารและเครื่องมือที่เปิดกว้างของ Realtek มีมานานสองทศวรรษ ครอบคลุม Wi-Fi, Ethernet, เสียง และตอนนี้ตัวควบคุมการจัดเก็บ การแยกตัวนี้อาจไม่ถูกสังเกตในโลกที่ใช้เฉพาะ Windows แต่จะกลายเป็นพิษเมื่อชิปเดียวกันถูกบูรณาการเข้ากับผลิตภัณฑ์หลายแพลตฟอร์ม เช่น Sabrent EC-SNVE ซึ่งแสดงโลโก้ Linux อย่างเปิดเผยบนบรรจุภัณฑ์
ด้วยการห้ามใช้ยูทิลิตี้แฟลชสำหรับ Linux และปิดกั้นการบำรุงรักษาของชุมชน Realtek ได้ ทำให้การซ่อมแซมด้วยตนเองกลายเป็นอาชญากรรม ผลที่ตามมากระจายออกไปด้านนอก:
ท้ายที่สุด ไม่ใช่โอเพนซอร์สที่ทำลายอุปกรณ์ของ Realtek – มันคือ ความเป็นศัตรูของ Realtek ต่อโอเพนซอร์ส ที่ทำลายพวกเขา
วิธีแก้ไขไม่ต้องการการเปลี่ยนแปลงทางอุดมการณ์ เพียงแค่ความเป็นจริง Realtek สามารถ:
แต่ละขั้นตอนนี้จะป้องกันค่าใช้จ่ายการรับประกัน ปกป้องความสัมพันธ์กับ OEM และฟื้นฟูความเชื่อมั่นในชิปบริดจ์ของ Realtek ในหมู่ผู้ใช้ Linux มืออาชีพ – ตั้งแต่ผู้สร้างเวิร์กสเตชันไปจนถึงนักพัฒนา Raspberry Pi
หากคุณสงสัยว่าเคสของคุณย้อนกลับไปใช้เฟิร์มแวร์ ROM:
lsusb -v | grep bcdDevicef0.01 รายงานปัญหาให้กับ OEM ของคุณdmesg และชี้ไปที่กลไกการย้อนกลับที่ได้รับการบันทึกนี้นโยบายเฟิร์มแวร์ของ Realtek ไม่เพียงแต่รบกวนผู้ที่ชื่นชอบเท่านั้น มันสร้างความสูญเสียทางการเงินที่จับต้องได้สำหรับระบบนิเวศของพวกเขาเอง ยิ่งความจริงนี้ได้รับการยอมรับภายในบริษัทเร็วเท่าไหร่ ผู้ใช้ Linux และพันธมิตร OEM ก็จะสามารถหยุดเสียเวลากับวงจร 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