Phiên bản: 1.0.2
Lần cập nhật gần đây nhất: 12/3/2025
TL;DR
Tài liệu này hướng dẫn cách nhà cung cấp có thể triển khai fwupd cho các dự án trong tương lai. Báo cáo này cũng bao gồm thông tin chi tiết được trích dẫn trực tiếp từ các trình bảo trì LVFS. Fwupd là một khung cập nhật chương trình cơ sở nguồn mở có thể giúp tập trung hoá cách chúng tôi thực hiện việc cập nhật chương trình cơ sở khi hợp tác với các nhà cung cấp bên ngoài.
Bước đầu tiên – Thu thập thông tin và đưa ra hướng dẫn
Đối với nhà cung cấp – Câu hỏi đầu tiên:
Câu hỏi về (các) thành phần có thể cập nhật
Kích thước bản cập nhật
Thời gian cập nhật
Loại bản cập nhật hiện có (mô hình A/B hoặc trình tải khởi động/thời gian chạy)
Điều gì sẽ xảy ra với chức năng của thành phần trong quá trình cập nhật?
Điều gì phải xảy ra với hệ thống để bắt đầu sử dụng bản cập nhật thành công?
Có cần cài đặt nhiều thành phần theo thứ tự cụ thể không?
Quen thuộc với việc làm việc với LVFS/fwupd hoặc có kiến thức về các công cụ này
Có thể cam kết tài nguyên kỹ sư để giúp triển khai trình bổ trợ (xem bên dưới để biết thêm chi tiết)
Cam kết về trình bổ trợ nguồn mở cho LGPLv2+ (mã ghi chương trình cơ sở vào thành phần) và cho phép LVFS phân phối lại chương trình cơ sở
Đối với nhà cung cấp – Hướng dẫn ban đầu:
Quá trình cập nhật phải giảm thiểu thời gian chức năng của thành phần ngoại vi hoặc thành phần nội bộ bị ảnh hưởng, tốt nhất là vài giây. Phần cập nhật dài hơn phải diễn ra thầm lặng ở chế độ nền mà không làm gián đoạn người dùng
- Nếu thiết bị ngoại vi này ảnh hưởng rõ ràng đến trải nghiệm người dùng (ví dụ: màn hình ngừng hoạt động), thì yêu cầu này sẽ trở nên nghiêm ngặt hơn
Để bật loại bản cập nhật thầm lặng này, bạn nên sử dụng bản cập nhật A/B
- Các bản cập nhật A/B có thể kích hoạt khi rút thiết bị ngoại vi là lý tưởng để giảm thiểu sự gián đoạn của người dùng
Phải khôi phục được bản cập nhật – nếu bạn tắt nguồn, rút thiết bị ngoại vi, v.v. thì bản cập nhật không được làm hỏng thiết bị hoặc thiết bị ngoại vi. Hệ thống phải có khả năng khôi phục mạnh mẽ mà không cần người dùng thực hiện hành động.
- Giả định ban đầu là không có hành động nào của người dùng trong toàn bộ quá trình cập nhật, các tập lệnh và giai đoạn cập nhật thích hợp sẽ được điều khiển một cách tự động
Bước thứ hai – Sử dụng fwupd
Nếu nhà cung cấp chưa từng sử dụng fwupd
Chrome OS đưa ra các yêu cầu về việc cập nhật chương trình cơ sở thông qua fwupd cho OEM. OEM nên thông báo trực tiếp điều này cho nhà cung cấp chip / thành phần
Trong một số trường hợp, ODM có thể giúp OEM giao tiếp trực tiếp với nhà cung cấp chip. Nhà sản xuất thiết bị gốc (OEM) chịu trách nhiệm thông báo và truyền đạt các yêu cầu này cho phù hợp
Xin lưu ý rằng nếu cung cấp mã nguồn có giấy phép LGPLv2+, thì việc lấy trình bổ trợ từ mã này thường là không khả thi (có nhiều vấn đề phức tạp). Vì vậy, trong trường hợp này, nhà cung cấp chip sẽ phải có người có thể làm việc với các kỹ sư Google và người duy trì fwupd.
Nhà sản xuất thiết bị gốc (OEM) có thể chủ động và giúp nhà cung cấp chip cam kết hợp tác chặt chẽ với nhà bảo trì. Yêu cầu hỗ trợ kỹ thuật của bên nhà cung cấp có các yêu cầu sau:
Rất quen thuộc với các đặc điểm thiết kế và đặc điểm của thành phần phần cứng có thể cập nhật, tốt nhất là thuộc cùng một nhóm đã viết chương trình cơ sở
Tìm hiểu sự khác biệt giữa các giấy phép nguồn mở phổ biến (ví dụ: LGPLv2 và MIT)
Thành thạo C, có hiểu biết cơ bản về GLib và GObject, cũng như hiểu rõ GErrors
Có tài khoản GitHub và biết cách mở và cập nhật yêu cầu gộp các thay đổi mà bạn thực hiện vào mã nguồn ban đầu, thực hiện bài đánh giá mã GitHub và tìm hiểu cách fwupd được cấu trúc với tất cả các trình trợ giúp mà fwupd cung cấp (ví dụ: phân đoạn, đính kèm/tách, thử lại thiết bị, HID, v.v.)
Không bắt buộc: khả năng gửi mẫu phần cứng đến Vương quốc Anh – rất hữu ích cho các trình bảo trì fwupd để giúp nhà cung cấp gỡ lỗi các vấn đề và thêm bảng vào các thử nghiệm fwupd chạy trên mỗi bản phát hành. Việc này rất quan trọng để ngăn chặn tình trạng hồi quy trong nhánh phát triển.
Song song với đó, nhà sản xuất thiết bị gốc (OEM) có thể bắt đầu tham gia thông qua danh sách gửi thư fwupd hoặc trực tiếp với Richard Hughes (hughsient@gmail.com) và xem lại kế hoạch trước khi viết mã trình bổ trợ
Nếu công ty nhỏ, có ít hoặc không có tài nguyên kỹ thuật hoặc hiểu biết về nguồn mở, thì bạn có thể tham khảo đề xuất sau:
Nhà cung cấp thành phần có thể sử dụng các công ty tư vấn, quen thuộc với công việc nguồn mở (không phải việc này sẽ phát sinh thêm chi phí)
Mặc dù đề xuất này có thể giúp mở rộng quy mô, nhưng giá trị của việc nhà cung cấp tự thực hiện là các kỹ sư sẽ quen thuộc với quy trình này và có thể dễ dàng thêm VID/PID trong tương lai cho phần cứng mới. Bạn cũng có thể nhanh chóng giải quyết các câu hỏi / vấn đề để gỡ lỗi trên phần cứng
Bước thứ ba – Các bước cuối cùng
Cuối cùng, mã được tái cấu trúc thành các thay đổi nhỏ có thể xem xét bằng cách sử dụng tất cả chức năng dùng chung trong fwupd
Sau khi hoàn tất, trình bổ trợ sẽ được hợp nhất ngược
Mã dùng ở thượng nguồn sẽ giống với mã trong ChromeOS
Tệp nhị phân cập nhật chương trình cơ sở dùng bên ngoài ChromeOS sẽ được phân phối cho LVFS
Cụ thể đối với ChromeOS:
Nhà sản xuất thiết bị gốc phải tải tệp nhị phân của chương trình cơ sở lên máy chủ của chúng tôi thông qua CPFE
Vẫn cần có các bản lưu trữ tủ cập nhật có thể phân phối lại trên LVFS để các thử nghiệm hồi quy phần cứng hoạt động
Bước thứ tư (Không bắt buộc) – Thêm thành phần mới
- Nếu khung fwupd đã được triển khai, thì bước bổ sung duy nhất là nhà cung cấp thành phần có thể cập nhật phải xử lý các yêu cầu kéo để thêm các đặc điểm và VID/PID cho các biến thể phần cứng
Hướng dẫn khác – Làm việc trên LVFS
Tạo tài khoản nhà cung cấp mới (thời gian thiết lập khoảng 2 phút)
Nhà cung cấp tạo người dùng cho miền của riêng họ hoặc sử dụng một công cụ như Azure AD để đồng bộ hoá tài khoản người dùng với LVFS. Họ có thể tải phần mềm cơ sở lên chế độ riêng tư và hạn chế của nhà cung cấp hoàn toàn miễn phí mà không cần kiểm tra nhiều (vì vậy, thường là các kỹ sư thực hiện việc này ngay từ đầu)
Cuối cùng, việc đẩy sang giai đoạn thử nghiệm hoặc ổn định sẽ yêu cầu một loại tài liệu từ bộ phận pháp lý của họ, trong đó nêu rõ LVFS có thể phân phối lại và phân tích phần mềm cơ sở. Richard sẽ cung cấp nguyên tắc về tệp PDF. ● Nếu nhà cung cấp chỉ là nhà cung cấp silicon hoặc ODM, thì họ có thể trở thành "đơn vị liên kết" của OEM và có thể thay mặt OEM tải firmware lên, trong đó OEM có toàn quyền xem những gì đang diễn ra với firmware mang thương hiệu của họ.
Có rất nhiều việc khác cần thiết lập (ví dụ: Mã nhà cung cấp giới hạn các mã này vào một nhóm mã PCI hoặc USB) nhưng hầu hết các nhà cung cấp đều đã có mã nhận dạng được chỉ định và bạn sẽ mất 20 giây để thiết lập.
Hướng dẫn khác – Các bit dành riêng cho Chrome OS
Trong trường hợp của chúng ta, các tệp nhị phân cập nhật chương trình cơ sở không được lấy trực tiếp từ LVFS. Thay vào đó, tệp CAB sẽ được lưu trữ trong hệ thống tệp cục bộ (rootfs)
- Quy trình công việc trong tương lai: kết hợp tệp nhị phân của chương trình cơ sở trong DLC bằng cách tạo một bản dựng ebuild của portage trên lớp phủ portage thích hợp
Bạn cần gọi fwupd (thông qua fwupdtool CLI) vào đúng thời điểm. Đối với mỗi thành phần có thể cập nhật, bạn phải tạo một quy tắc udev (hoặc tập lệnh tương đương) để phát ra sự kiện khởi động fwuptool-update. Sự kiện này sẽ được xử lý tự động để thực thi fwupdtool bằng các đối số phù hợp và hộp cát thích hợp (minijail)
Một thành phần khác là quyết định xem có cần giao diện người dùng hay không – chỉ trong một số trường hợp nhất định tuỳ thuộc vào bản chất của thành phần được cập nhật. Để được nhóm PM và nhóm Kỹ thuật đánh giá. Hướng dẫn cấp cao hơn, như đã đề cập trong bước đầu tiên, là giảm thiểu hành động của người dùng
Tài nguyên bổ sung dành cho nhà cung cấp
Tài liệu tham khảo bên ngoài: https://lvfs.readthedocs.io/
Tài liệu tham khảo về thoả thuận với nhà cung cấp bên ngoài: fwupd.org/lvfs/docs/agreement
Hướng dẫn phát triển trình bổ trợ: https://fwupd.github.io/tutorial.html
Hướng dẫn về Trình bổ trợ gỡ lỗi: https://lvfs.readthedocs.io/en/latest/custom-plugin.html
Tệp quirk mẫu: https://github.com/fwupd/fwupd/blob/master/plugins/wacom-usb/wacom-usb.quirk
Nhật ký sửa đổi
| Ngày | Phiên bản | Ghi chú |
|---|---|---|
| 2025-03-12 | 1.0.2 | Chuyển đổi văn bản từ pdf sang markdown |
| 2024-01-31 | 1.0.1 | Xuất bản lại trên nền tảng mới |
| 2023-10-12 | 1.0 | Bản phát hành đầu tiên |