เวอร์ชัน: 1.0.2
อัปเดตล่าสุด: 12-03-2025
สรุป
เอกสารนี้มีไว้เพื่อเป็นคำแนะนำเกี่ยวกับวิธีที่ผู้ให้บริการสามารถติดตั้งใช้งาน fwupd สำหรับโปรเจ็กต์ในอนาคต รวมถึงข้อมูลเชิงลึกที่ยกมาโดยตรงจากผู้ดูแล LVFS ด้วย Fwupd เป็นเฟรมเวิร์กการอัปเดตเฟิร์มแวร์แบบโอเพนซอร์สที่จะช่วยรวมวิธีที่เราทำการอัปเดตเฟิร์มแวร์ร่วมกับพาร์ทเนอร์ภายนอก
ขั้นตอนแรก - รวบรวมข้อมูลและให้คําแนะนํา
สำหรับผู้ให้บริการ - คำถามแรก:
คำถามเกี่ยวกับคอมโพเนนต์ที่อัปเดตได้
ขนาดการอัปเดต
เวลาอัปเดต
ประเภทการอัปเดตที่มีอยู่ (A/B หรือรูปแบบบูตโหลดเดอร์/รันไทม์)
ฟังก์ชันการทํางานของคอมโพเนนต์จะเป็นอย่างไรในระหว่างการอัปเดต
ระบบต้องดำเนินการใดบ้างจึงจะเริ่มใช้การอัปเดตที่สำเร็จ
ต้องติดตั้งคอมโพเนนต์หลายรายการตามลำดับที่เจาะจงหรือไม่
ความคุ้นเคยในการทำงานกับ LVFS/fwupd หรือความรู้เกี่ยวกับแพลตฟอร์มดังกล่าว
ความสามารถในการคอมมิตทรัพยากร Eng เพื่อช่วยติดตั้งใช้งานปลั๊กอิน (ดูรายละเอียดเพิ่มเติมด้านล่าง)
ความมุ่งมั่นในการเปิดแหล่งที่มาของปลั๊กอินเป็น LGPLv2 ขึ้นไป (โค้ดที่เขียนเฟิร์มแวร์ลงในคอมโพเนนต์) และอนุญาตให้ LVFS แจกจ่ายเฟิร์มแวร์ซ้ำได้
สําหรับผู้ให้บริการ - คําแนะนําเบื้องต้น
การอัปเดตต้องลดเวลาที่ฟังก์ชันการทำงานของอุปกรณ์ต่อพ่วงหรือคอมโพเนนต์ภายในได้รับผลกระทบ โดยควรใช้เวลาไม่เกิน 2-3 วินาที ส่วนการอัปเดตที่ใช้เวลานานกว่าควรเกิดขึ้นในเบื้องหลังโดยที่ผู้ใช้ไม่รู้สึก
- หากอุปกรณ์ต่อพ่วงนี้ส่งผลต่อประสบการณ์ของผู้ใช้อย่างชัดเจน (เช่น จอแสดงผลหยุดทำงาน) ข้อกำหนดนี้จะเข้มงวดยิ่งขึ้น
หากต้องการเปิดใช้การอัปเดตแบบเงียบประเภทนี้ เราขอแนะนําอย่างยิ่งให้ใช้การอัปเดต A/B
- การอัปเดต A/B ที่เปิดใช้งานเมื่อถอดอุปกรณ์ต่อพ่วงเหมาะอย่างยิ่งในการลดการหยุดชะงักของผู้ใช้
การอัปเดตต้องกู้คืนได้ - หากคุณปิดเครื่อง ถอดปลั๊กอุปกรณ์ต่อพ่วง ฯลฯ การอัปเดตไม่ควรทำให้อุปกรณ์หรืออุปกรณ์ต่อพ่วงใช้งานไม่ได้ ข้อมูลควรมีความเสถียรเพื่อกู้คืนได้โดยไม่ต้องให้ผู้ใช้ดำเนินการ
- สมมติฐานเริ่มต้นควรเป็นว่าไม่มีการดำเนินการของผู้ใช้ในระหว่างการอัปเดตทั้งหมด สคริปต์และระยะการอัปเดตที่เหมาะสมควรทำงานอย่างอิสระ
ขั้นตอนที่ 2 - การใช้ fwupd
หากผู้ให้บริการไม่เคยใช้ fwupd
Chrome OS ระบุข้อกำหนดสำหรับการอัปเดตเฟิร์มแวร์ผ่าน fwupd ให้กับ OEM OEM ควรแจ้งเรื่องนี้ให้ซัพพลายเออร์ชิป / คอมโพเนนต์ทราบโดยตรง
ในบางกรณี ODM สามารถช่วยให้ OEM ติดต่อกับผู้ให้บริการชิปได้โดยตรง OEM มีหน้าที่รับผิดชอบในการแจ้งข้อกำหนดเหล่านี้ให้ผู้ใช้ทราบ
โปรดทราบว่าหากให้ซอร์สโค้ดที่มีใบอนุญาต LGPLv2 ขึ้นไป โดยทั่วไปแล้ว การนำปลั๊กอินมาจากโค้ดนี้จะไม่สามารถทำได้ (มีความซับซ้อนมาก) ดังนั้น ในกรณีนี้ ผู้ให้บริการชิปจะต้องมีบุคคลที่สามารถทำงานร่วมกับผู้ดูแล fwupd และวิศวกรของ Google
OEM สามารถเป็นผู้ดำเนินการเชิงรุกและช่วยรับความมุ่งมั่นจากผู้ให้บริการชิปให้ทำงานร่วมกับผู้ดูแลอย่างใกล้ชิด คำขอรับการสนับสนุนด้านวิศวกรรมจากฝั่งผู้ให้บริการมีข้อกำหนดต่อไปนี้
เข้าใจข้อบกพร่องและการออกแบบของคอมโพเนนต์ฮาร์ดแวร์ที่อัปเดตได้เป็นอย่างดี และควรอยู่ในทีมเดียวกับที่เขียนเฟิร์มแวร์
ทําความเข้าใจความแตกต่างระหว่างใบอนุญาตโอเพนซอร์สทั่วไป (เช่น LGPLv2 และ MIT)
เชี่ยวชาญภาษา C และมีความเข้าใจพื้นฐานเกี่ยวกับ GLib และ GObject โดยเฉพาะอย่างยิ่งการทำความเข้าใจ GErrors ด้วย
มีบัญชี GitHub และรู้วิธีเปิดและอัปเดตคำขอดึงข้อมูล ทำการตรวจสอบโค้ด GitHub และดูโครงสร้างของ fwupd ที่มีเครื่องมือทั้งหมดที่ fwupd มีให้ (เช่น การแบ่งกลุ่ม การแนบ/ถอดออก อุปกรณ์ที่พยายามอีกครั้ง HID ฯลฯ)
ไม่บังคับ: ความสามารถในการส่งตัวอย่างฮาร์ดแวร์ไปยังสหราชอาณาจักร ซึ่งมีประโยชน์อย่างยิ่งสำหรับผู้ดูแล fwupd ในการช่วยแก้ปัญหาการแก้ไขข้อบกพร่องของผู้ให้บริการ และเพื่อเพิ่มบอร์ดไปยังการทดสอบ fwupd ที่ทำงานในแต่ละรุ่น ซึ่งการทดสอบหลังมีความสำคัญในการหยุดการเกิดปัญหาซ้ำในสาขาการพัฒนา
ในขณะเดียวกัน OEM สามารถเริ่มมีส่วนร่วมผ่านรายชื่ออีเมล fwupd หรือติดต่อ Richard Hughes (hughsient@gmail.com) โดยตรงเพื่อพูดคุยเกี่ยวกับแผนก่อนเขียนโค้ดปลั๊กอิน
หากบริษัทมีขนาดเล็กและมีทรัพยากรด้านวิศวกรหรือความเข้าใจเกี่ยวกับโอเพนซอร์สเพียงเล็กน้อยหรือไม่มีเลย คำแนะนำต่อไปนี้อาจช่วยได้
ผู้ให้บริการคอมโพเนนต์อาจใช้บริษัทที่ปรึกษาซึ่งคุ้นเคยกับการทำงานแบบโอเพนซอร์ส (แต่ไม่มีค่าใช้จ่ายเพิ่มเติม)
แม้ว่าคำแนะนำนี้จะช่วยปรับขนาดได้ แต่ข้อดีของการใช้ผู้ให้บริการดำเนินการในองค์กรคือวิศวกรจะคุ้นเคยกับกระบวนการนี้และสามารถเพิ่ม VID/PID ให้กับฮาร์ดแวร์ใหม่ในอนาคตได้อย่างง่ายดาย นอกจากนี้ คุณยังปิดคำถาม / ปัญหาเพื่อแก้ไขข้อบกพร่องในฮาร์ดแวร์ได้เร็วขึ้นด้วย
ขั้นตอนที่ 3 - ขั้นตอนสุดท้าย
ในที่สุด โค้ดก็ได้รับการแยกส่วนใหม่เป็นคอมมิตขนาดเล็กที่ตรวจสอบได้โดยใช้ฟังก์ชันการทำงานทั้งหมดที่แชร์ใน fwupd
เมื่อเสร็จแล้ว ระบบจะผสานปลั๊กอินในฝั่งที่ส่งออก
โค้ดที่ใช้ในฝั่งต้นทางจะเป็นโค้ดเดียวกับใน ChromeOS
ระบบจะเผยแพร่ไบนารีการอัปเดตเฟิร์มแวร์ที่ใช้ในที่นอก ChromeOS ไปยัง LVFS
สำหรับกรณี ChromeOS โดยเฉพาะ
OEM ต้องอัปโหลดไฟล์ไบนารีของเฟิร์มแวร์ไปยังเซิร์ฟเวอร์ของเราผ่าน CPFE
ยังคงต้องมีการเก็บถาวรของตู้อัปเดตที่พร้อมแจกจ่ายอีกครั้งใน LVFS เพื่อให้การทดสอบการถดถอยของฮาร์ดแวร์ทำงานได้
ขั้นตอนที่ 4 (ไม่บังคับ) - การเพิ่มคอมโพเนนต์ใหม่
- หากมีเฟรมเวิร์ก fwupd อยู่แล้ว ขั้นตอนเพิ่มเติมเพียงอย่างเดียวคือผู้ให้บริการคอมโพเนนต์ที่อัปเดตได้ต้องดำเนินการกับคำขอดึงข้อมูลเพื่อเพิ่มข้อบกพร่องและ VID/PID สำหรับตัวแปรฮาร์ดแวร์
คำแนะนำอื่นๆ - การทำงานกับ LVFS
สร้างบัญชีผู้ให้บริการใหม่ (ใช้เวลาตั้งค่าประมาณ 2 นาที)
ผู้ให้บริการจะสร้างผู้ใช้สำหรับโดเมนของตนเองหรือใช้เครื่องมืออย่าง Azure AD เพื่อซิงค์บัญชีผู้ใช้กับ LVFS ผู้ใช้สามารถอัปโหลดเฟิร์มแวร์ไปยังที่เก็บข้อมูลส่วนตัวและที่เก็บข้อมูลที่มีการจำกัดเฉพาะตัวแทนจำหน่ายได้ฟรีโดยสมบูรณ์โดยการตรวจสอบเพียงเล็กน้อย (ดังนั้น บ่อยครั้งที่วิศวกรจะเป็นผู้ดำเนินการนี้ตั้งแต่ต้น)
ในที่สุด การพุชไปยังรุ่นทดสอบหรือรุ่นเสถียรจะต้องใช้เอกสารบางอย่างจากฝ่ายกฎหมายที่ระบุว่า LVFS สามารถแจกจ่ายและวิเคราะห์เฟิร์มแวร์ได้อย่างชัดเจน Richard มีหลักเกณฑ์เป็น PDF ● หากเป็นผู้ให้บริการซิลิคอนหรือ ODM เท่านั้น ก็สามารถเป็น "แอฟฟิลิเอต" ของ OEM และอัปโหลดเฟิร์มแวร์ในนามของ OEM ได้ โดย OEM จะมองเห็นข้อมูลทั้งหมดที่เกิดขึ้นกับเฟิร์มแวร์ที่มีแบรนด์ของตน
ยังมีการตั้งค่าอื่นๆ อีกมากมาย (เช่น รหัสผู้ให้บริการจํากัดไว้ที่ชุดรหัส PCI หรือ USB) แต่ผู้ให้บริการส่วนใหญ่มีรหัสที่กําหนดไว้อยู่แล้ว และการตั้งค่านี้จะใช้เวลา 20 วินาที
คำแนะนำอื่นๆ - ข้อมูลเฉพาะของ Chrome OS
ในกรณีของเรา ระบบจะไม่ดึงไบนารีการอัปเดตเฟิร์มแวร์จาก LVFS โดยตรง แต่จะจัดเก็บไฟล์ CAB ในระบบไฟล์ในเครื่อง (rootfs) แทน
- เวิร์กสตรีมในอนาคต: รวมไบนารีเฟิร์มแวร์ใน DLC โดยการสร้าง ebuild ของ portage ในโอเวอร์เลย์ portage ที่เหมาะสม
คุณต้องเรียกใช้ fwupd (ผ่าน CLI fwupdtool) ในเวลาที่เหมาะสม สําหรับคอมโพเนนต์ที่อัปเดตได้แต่ละรายการ คุณต้องสร้างกฎ udev (หรือสคริปต์ที่เทียบเท่า) ซึ่งจะส่งเหตุการณ์ fwuptool-update upstart ระบบจะจัดการเหตุการณ์นี้โดยอัตโนมัติเพื่อเรียกใช้ fwupdtool ด้วยอาร์กิวเมนต์ที่ถูกต้องและการใช้แซนด์บ็อกซ์ที่เหมาะสม (minijail)
คอมโพเนนต์อีกรายการหนึ่งคือการตัดสินใจว่าจำเป็นต้องใช้ UI หรือไม่ ซึ่งจะใช้ก็ต่อเมื่ออยู่ในสถานการณ์บางอย่างเท่านั้น โดยขึ้นอยู่กับลักษณะของคอมโพเนนต์ที่อัปเดต อยู่ระหว่างการประเมินโดย PM และทีมวิศวกร คำแนะนำในระดับที่สูงขึ้นตามที่ได้กล่าวไว้ในขั้นตอนแรกคือลดการดำเนินการฝั่งผู้ใช้
แหล่งข้อมูลเพิ่มเติมสำหรับผู้ขาย
ข้อมูลอ้างอิงเอกสารประกอบภายนอก: https://lvfs.readthedocs.io/
ข้อมูลอ้างอิงเกี่ยวกับข้อตกลงของผู้ให้บริการภายนอก: fwupd.org/lvfs/docs/agreement
บทแนะนำการพัฒนาปลั๊กอิน: https://fwupd.github.io/tutorial.html
บทแนะนำการแก้ไขข้อบกพร่องของปลั๊กอิน: https://lvfs.readthedocs.io/en/latest/custom-plugin.html
ตัวอย่างไฟล์ Quirk: https://github.com/fwupd/fwupd/blob/master/plugins/wacom-usb/wacom-usb.quirk
ประวัติการแก้ไข
| วันที่ | เวอร์ชัน | หมายเหตุ |
|---|---|---|
| 2025-03-12 | 1.0.2 | แปลงข้อความจาก PDF เป็น Markdown |
| 2024-01-31 | 1.0.1 | การเผยแพร่อีกครั้งในแพลตฟอร์มใหม่ |
| 2023-10-12 | 1.0 | การเผยแพร่ครั้งแรก |