Versi: 1.0.2
Terakhir diperbarui: 12-03-2025
TL;DR
Dokumen ini dimaksudkan sebagai panduan tentang cara vendor menerapkan fwupd untuk project mendatang. Laporan ini juga mencakup insight yang dikutip langsung dari pengelola LVFS. Fwupd adalah framework update firmware open source yang dapat membantu memusatkan cara kami melakukan update firmware dalam kemitraan dengan vendor eksternal.
Langkah Pertama - Kumpulkan Informasi & Berikan Panduan
Untuk Vendor - Pertanyaan Pertama:
Pertanyaan tentang komponen yang dapat diupdate
Memperbarui ukuran
Waktu update
Jenis update yang ada (model A/B atau bootloader/runtime)
Apa yang terjadi dengan fungsi komponen selama update?
Apa yang harus terjadi pada sistem untuk mulai menggunakan update yang berhasil?
Apakah beberapa komponen perlu diinstal dalam urutan tertentu?
Memahami cara menggunakan LVFS/fwupd, atau mengetahuinya
Kemampuan untuk melakukan resource eng guna membantu menerapkan plugin (lihat di bawah untuk mengetahui detail selengkapnya)
Komitmen untuk membuka sumber plugin ke LGPLv2+ (kode yang menulis firmware ke komponen) dan mengizinkan firmware didistribusikan ulang oleh LVFS
Untuk Vendor - Panduan Awal:
Update harus meminimalkan waktu saat fungsi komponen periferal atau internal terpengaruh, idealnya hingga beberapa detik. Bagian update yang lebih lama akan terjadi secara otomatis di latar belakang tanpa mengganggu pengguna
- Jika periferal ini memengaruhi pengalaman pengguna dengan cara yang jelas (misalnya, layar berhenti berfungsi), persyaratan ini menjadi lebih ketat
Untuk mengaktifkan jenis update senyap ini, update A/B sangat dianjurkan
- Update A/B yang dapat diaktifkan saat periferal dicabut sangat ideal untuk meminimalkan gangguan pengguna
Update harus dapat dipulihkan - jika Anda mematikan, mencabut periferal, dll., update tidak boleh membuat perangkat atau periferal menjadi tidak berfungsi. Aplikasi harus andal untuk memulihkan tanpa tindakan pengguna.
- Asumsi awal seharusnya tidak ada tindakan pengguna selama seluruh update, skrip dan tahap update yang tepat harus dijalankan secara otonom
Langkah Kedua - Menggunakan fwupd
Jika vendor belum pernah menggunakan fwupd
Chrome OS memberikan persyaratan untuk update firmware melalui fwupd ke OEM. OEM harus menyampaikan hal ini langsung kepada pemasok chip / komponen
Dalam beberapa kasus, ODM dapat membantu OEM berinteraksi dengan vendor chip secara langsung. OEM bertanggung jawab untuk menyampaikan persyaratan ini dengan tepat
Perhatikan bahwa jika menyediakan kode sumber dengan lisensi LGPLv2+, mendapatkan plugin dari kode ini biasanya tidak memungkinkan (banyak kerumitan). Jadi, dalam skenario ini, vendor chip akan diwajibkan untuk memiliki seseorang yang dapat bekerja sama dengan pengelola fwupd dan engineer Google.
OEM dapat bersikap proaktif dan membantu mendapatkan komitmen dari vendor chip untuk bekerja sama dengan pengelola. Permintaan dukungan teknik di sisi vendor memiliki persyaratan berikut:
Sangat memahami keanehan dan fitur desain komponen hardware yang dapat diupdate, sebaiknya bahkan berada di tim yang sama dengan yang menulis firmware
Memahami perbedaan antara lisensi open source umum (misalnya LGPLv2 dan MIT)
Mahir dalam C, dengan pemahaman dasar tentang GLib dan GObject, khususnya juga memahami GErrors
Memiliki akun GitHub dan mengetahui cara membuka serta memperbarui permintaan pull, melakukan peninjauan kode GitHub, dan mempelajari cara fwupd disusun dengan semua bantuan yang disediakan fwupd (misalnya, pengelompokan, pemasangan/pelepasan, percobaan ulang perangkat, HID, dll.)
Opsional: kemampuan untuk mengirim sampel hardware ke Inggris Raya - sangat berguna untuk pengelola fwupd guna membantu vendor men-debug masalah dan menambahkan papan ke pengujian fwupd yang dijalankan pada setiap rilis. Yang terakhir penting untuk menghentikan regresi di cabang pengembangan.
Secara paralel, OEM dapat mulai berinteraksi melalui milis fwupd atau dengan Richard Hughes (hughsient@gmail.com) secara langsung dan membahas rencana sebelum kode plugin ditulis
Jika perusahaan kecil dengan sedikit atau tanpa resource engineering atau pemahaman tentang open source, saran berikut mungkin dapat membantu:
Vendor komponen dapat menggunakan perusahaan konsultan, yang memahami pekerjaan open source (bukan berarti hal ini menimbulkan biaya tambahan)
Meskipun saran ini dapat membantu penskalaan, nilai vendor yang melakukannya secara internal adalah bahwa engineer akan memahami prosesnya dan mereka dapat dengan mudah menambahkan VID/PID di masa mendatang untuk hardware baru. Anda juga dapat lebih cepat menutup pertanyaan / masalah untuk melakukan proses debug pada hardware
Langkah Ketiga - Langkah Terakhir
Akhirnya, kode difaktorkan ulang menjadi commit kecil yang dapat ditinjau menggunakan semua fungsi bersama di fwupd
Setelah selesai, plugin akan digabungkan ke upstream
Kode yang digunakan di upstream akan sama dengan kode di ChromeOS
Biner update firmware yang digunakan di luar ChromeOS akan didistribusikan ke LVFS
Khusus untuk ChromeOS:
OEM harus mengupload biner firmware ke server kami melalui CPFE
Masih perlu ada arsip kabinet update yang dapat didistribusikan ulang di LVFS agar pengujian regresi hardware berfungsi
Langkah Keempat (Opsional) - Menambahkan komponen baru
- Jika framework fwupd sudah ada, satu-satunya langkah tambahan adalah penyedia komponen yang dapat diupdate harus mengerjakan permintaan pull untuk menambahkan keanehan dan VID/PID untuk varian hardware
Panduan Lainnya - Bekerja di LVFS
Membuat akun vendor baru (~2 menit untuk menyiapkannya)
Vendor membuat pengguna untuk domain mereka sendiri atau menggunakan sesuatu seperti Azure AD untuk menyinkronkan akun pengguna ke LVFS. Mereka dapat mengupload firmware ke firmware pribadi dan embargo vendor sepenuhnya secara gratis dengan sangat sedikit pemeriksaan (sehingga sering kali engineer melakukannya sejak awal)
Pada akhirnya, push ke pengujian atau stabil memerlukan semacam dokumen dari departemen hukum mereka yang dengan jelas menyatakan bahwa LVFS dapat mendistribusikan ulang dan menganalisis firmware. Panduan PDF disediakan oleh Richard. ● Jika vendor hanya merupakan pemasok silikon atau ODM, mereka dapat menjadi "afiliasi" OEM dan dapat mengupload firmware atas nama mereka, dengan OEM memiliki visibilitas penuh tentang apa yang terjadi dengan firmware yang bermerek dengan namanya.
Ada banyak hal lain yang perlu disiapkan (misalnya, ID Vendor membatasinya ke sekumpulan ID PCI atau USB), tetapi sebagian besar vendor sudah memiliki ID yang ditetapkan dan memerlukan waktu 20 detik untuk disiapkan.
Panduan Lainnya - Bit Khusus Chrome OS
Dalam kasus kami, biner update firmware tidak diambil langsung dari LVFS. Sebagai gantinya, file CAB akan disimpan di sistem file lokal (rootfs)
- Alur kerja mendatang: menggabungkan biner firmware di DLC dengan membuat ebuild portage pada overlay portage yang sesuai
fwupd perlu dipanggil (melalui fwupdtool CLI-nya) pada waktu yang tepat. Untuk setiap komponen yang dapat diupdate, aturan udev (atau skrip yang setara) harus dibuat yang memunculkan peristiwa upstart fwuptool-update. Peristiwa ini akan ditangani secara otomatis untuk mengeksekusi fwupdtool dengan argumen yang tepat dan sandboxing yang tepat (minijail)
Komponen lain adalah menentukan apakah UI diperlukan - hanya dalam keadaan tertentu, bergantung pada sifat komponen yang diperbarui. Untuk dievaluasi oleh tim PM dan Eng. Panduan tingkat yang lebih tinggi, seperti yang disebutkan dalam langkah pertama, adalah meminimalkan tindakan di sisi pengguna
Referensi Tambahan untuk Vendor
Referensi dokumentasi eksternal: https://lvfs.readthedocs.io/
Referensi perjanjian vendor eksternal: fwupd.org/lvfs/docs/agreement
Tutorial Pengembangan Plugin: https://fwupd.github.io/tutorial.html
Tutorial Plugin Proses Debug: https://lvfs.readthedocs.io/en/latest/custom-plugin.html
Contoh file quirk: https://github.com/fwupd/fwupd/blob/master/plugins/wacom-usb/wacom-usb.quirk
Histori Revisi
| Tanggal | Versi | Catatan |
|---|---|---|
| 2025-03-12 | 1.0.2 | Mengonversi teks dari PDF ke markdown |
| 2024-01-31 | 1.0.1 | Memublikasikan ulang di platform baru |
| 2023-10-12 | 1,0 | Publikasi awal |