Spesifikasi protokol Component Firmware Update (CFU)
Spesifikasi ini menjelaskan protokol HID generik untuk memperbarui firmware untuk komponen yang ada pada PC atau aksesori. Spesifikasi ini memungkinkan komponen untuk menerima firmware tanpa mengganggu operasi perangkat selama pengunduhan. Spesifikasi ini mendukung konfigurasi di mana komponen yang menerima firmware mungkin memiliki subkomponen, yang memerlukan gambar firmware terpisah. Spesifikasi ini memungkinkan komponen yang bertanggung jawab untuk memutuskan apakah akan menerima firmware. Ini juga bertindak sebagai pengoptimalan karena gambar firmware hanya dikirim ke komponen jika mampu atau siap menerimanya.
Catatan
CFU tersedia di Windows 10, versi 2004 (Windows 10 Pembaruan Mei 2020) dan versi yang lebih baru.
Konten
- 1 Pengenalan
- 2 Arsitektur Perangkat Keras yang Didukung
- 3 Prasyarat Protokol
- 4 Gambaran Umum Protokol CFU
- 4.1 Urutan Perintah Pemrograman Pembaruan Firmware
- 4.1.1 Status: Pemberitahuan Yang Diinisialisasi Host
- 4.1.2 Status: Pemberitahuan OFFER_INFO_START_OFFER_LIST
- 4.1.3 Status: Perintah Kirim FIRMWARE_UPDATE_OFFER
- 4.1.4 Status: Kirim Firmware
- 4.1.5 Status Keputusan: Apakah ada lebih banyak penawaran
- 4.1.6 Status: Pemberitahuan OFFER_INFO_END_OFFER_LIST
- 4.1.7 Status Keputusan: Daftar Penawaran Pemutaran Ulang
- 4.1.8 Status: Perangkat Sibuk
- 4.1 Urutan Perintah Pemrograman Pembaruan Firmware
- 5 Format Paket Protokol CFU
- 6 Lampiran 1: Contoh Urutan Perintah Pemrograman Pembaruan Firmware
Tabel
Tabel 5,1-1 GET_FIRMWARE_VERSION Tata Letak Respons
Tabel 5.1-2 GET_FIRMWARE_VERSION Respons - Tata Letak Header
Tabel 5.1-3 GET_FIRMWARE_VERSION Respons - Bit Header
Tabel 5.1-4 GET_FIRMWARE_VERSION Respons - Versi Komponen dan Tata Letak Properti
Tabel 5.1-5 GET_FIRMWARE_VERSION Respons - Versi Komponen dan Gigitan Properti
Tabel 5.2-1 FIRMWARE_UPDATE_OFFER Tata Letak Perintah
Tabel 5.2-2 FIRMWARE_UPDATE_OFFER Perintah - Tata Letak Informasi Komponen
Tabel 5.2-3 FIRMWARE_UPDATE_OFFER Perintah - Bit Informasi Komponen
Tabel 5.2-4 FIRMWARE_UPDATE_OFFER Command - Tata Letak Versi Firmware
Tabel 5.2-5 FIRMWARE_UPDATE_OFFER Command - Bit Versi Firmware
Tabel 5.2-6 FIRMWARE_UPDATE_OFFER Command - Tata Letak Khusus Vendor
Tabel 5.2-7 FIRMWARE_UPDATE_OFFER Command - Versi Misc. dan Protocol
Tabel 5.2-8 FIRMWARE_UPDATE_OFFER Tata Letak Token Respons
Tabel 5.2-9 FIRMWARE_UPDATE_OFFER Respons - Tata Letak Token
Tabel 5.2-10 FIRMWARE_UPDATE_OFFER Respons - Bit Token
Tabel 5.2-11 FIRMWARE_UPDATE_OFFER Respons - Tolak Tata Letak Alasan
Tabel 5.2-12 FIRMWARE_UPDATE_OFFER Respons - Tolak Bit Alasan
Tabel 5.2-13 FIRMWARE_UPDATE_OFFER Respons Nilai Kode RR
Tabel 5.2-14 FIRMWARE_UPDATE_OFFER Tata Letak Status Respons
Tabel 5.2-15 FIRMWARE_UPDATE_OFFER Respons - Bit Status
Tabel 5.2-16 FIRMWARE_UPDATE_OFFER Nilai Status Respons
Tabel 5,3-1 FIRMWARE_UPDATE_OFFER - Tata Letak Perintah Informasi
Tabel 5.3-2 FIRMWARE_UPDATE_OFFER - Perintah Informasi - Tata Letak Komponen
Tabel 5.3-3 FIRMWARE_UPDATE_OFFER - Perintah Informasi - Bit Komponen
Tabel 5.3-4 FIRMWARE_UPDATE_OFFER - Perintah Informasi - Nilai Kode Informasi
Tabel 5.3-5 FIRMWARE_UPDATE_OFFER - Tata Letak Respons Informasi
Tabel 5.3-6 FIRMWARE_UPDATE_OFFER- Tata Letak Token Respons Paket Informasi
Tabel 5.3-7 FIRMWARE_UPDATE_OFFER - Respons Informasi - Bit Token
Tabel 5.3-8 FIRMWARE_UPDATE_OFFER - Respons Informasi - Tata Letak Kode RR
Tabel 5.3-9 FIRMWARE_UPDATE_OFFER- Respons Informasi Penawaran - Bit Kode RR
Tabel 5.3-10 FIRMWARE_UPDATE_OFFER- Respons Informasi - Nilai Kode RR
Tabel 5.3-11 FIRMWARE_UPDATE_OFFER - Tata Letak Status Respons Informasi Penawaran
Tabel 5.3-12 FIRMWARE_UPDATE_OFFER - Informasi Penawaran - Bit Status Respons
Tabel 5,4-1 FIRMWARE_UPDATE_OFFER - Tata Letak Perintah Yang Diperluas
Tabel 5,4-2 FIRMWARE_UPDATE_OFFER - Paket Perintah Yang Diperluas - Perintah - Tata Letak Komponen
Tabel 5,4-3 FIRMWARE_UPDATE_OFFER - Perintah Diperluas - Bit Komponen
Tabel 5,4-4 FIRMWARE_UPDATE_OFFER - Perintah Diperluas - Nilai Kode Perintah
Tabel 5,4-5 FIRMWARE_UPDATE_OFFER - Tata Letak Respons Paket Perintah Yang Diperluas
Tabel 5.4-6 FIRMWARE_UPDATE_OFFER- Respons Paket Perintah Penawaran - Tata Letak Token
Tabel 5.4-7 FIRMWARE_UPDATE_OFFER - Respons Perintah Penawaran - Bit Token
Tabel 5,4-8 FIRMWARE_UPDATE_OFFER - Tata Letak RR Respons Paket Informasi Penawaran
Tabel 5.4-9 FIRMWARE_UPDATE_OFFER- Respons Perintah Penawaran - Kode RR
Tabel 5.4-10 FIRMWARE_UPDATE_OFFER- Paket Perintah Penawaran - Nilai Kode RR
Tabel 5.4-11 FIRMWARE_UPDATE_OFFER - Tata Letak Status Respons Paket Perintah Penawaran
Tabel 5.4-12 FIRMWARE_UPDATE_OFFER- Menawarkan Kode RR Respons Paket Perintah
Tabel 5,5-1 FIRMWARE_UPDATE_CONTENT Tata Letak Perintah
Tabel 5,5-2 FIRMWARE_UPDATE_CONTENT Tata Letak Header Perintah
Tabel 5,5-3 FIRMWARE_UPDATE_CONTENT Header Bit
Tabel 5,5-4 FIRMWARE_UPDATE_OFFER- Paket Perintah Penawaran - Nilai Bendera
Tabel 5,5-5 FIRMWARE_UPDATE_CONTENT Tata Letak Data Perintah
Tabel 5,5-6 FIRMWARE_UPDATE_CONTENT Command Data Bits
Tabel 5,5-7 FIRMWARE_UPDATE_CONTENT Tata Letak Respons Perintah
Tabel 5,5-8 FIRMWARE_UPDATE_CONTENT Respons - Nomor Urut
Tabel 5,5-9 FIRMWARE_UPDATE_CONTENT - Perintah - Bit Respons
Tabel 5,5-10 FIRMWARE_UPDATE_CONTENT Tata Letak Status Respons
Tabel 5,5-11 FIRMWARE_UPDATE_OFFER - Respons - Bit Status
Tabel 5.5-12 FIRMWARE_UPDATE_OFFER- Respons - Nilai Kode Status
1 Pendahuluan
PC dan aksesori saat ini memiliki komponen internal yang melakukan operasi kompleks. Untuk memastikan produk berkualitas, ada kebutuhan untuk sering memperbarui perilaku perangkat ini di tahap pengembangan selanjutnya atau setelah dikirim ke pelanggan. Pembaruan mungkin memperbaiki masalah fungsi atau keamanan yang diidentifikasi, atau kebutuhan untuk menambahkan fitur baru. Sebagian besar logika kompleks ada di firmware yang berjalan pada perangkat, yang dapat diperbarui.
Spesifikasi ini menjelaskan protokol HID generik untuk memperbarui firmware untuk komponen yang ada pada PC atau aksesorinya. Implementasi HID berada di luar cakupan spesifikasi.
Beberapa fitur protokol adalah:
Protokol ini didasarkan pada HID—di mana-mana dan memiliki dukungan windows dalam kotak melalui berbagai bus interkoneksi seperti USB dan I2C. Oleh karena itu, solusi perangkat lunak (driver) yang sama dapat dimanfaatkan untuk memperbarui firmware untuk semua komponen.
Catatan
Karena spesifikasinya berbasis paket, mudah untuk menyesuaikannya dengan skenario non-HID.
Spesifikasi ini memungkinkan komponen untuk menerima firmware tanpa mengganggu operasi perangkat selama pengunduhan. Ini memungkinkan pengalaman yang lebih baik bagi pengguna karena mereka tidak perlu menunggu proses pembaruan firmware selesai sebelum mereka dapat melanjutkan tugas lain. Firmware baru dapat dipanggil dalam satu operasi atom pada satu waktu yang memiliki dampak minimal terhadap pengguna.
Spesifikasi ini mendukung konfigurasi di mana komponen yang menerima firmware mungkin memiliki subkomponen, yang memerlukan gambar firmware terpisah.
Catatan
Proses komponen menyerahkan firmware ke sub-komponen berada di luar cakupan spesifikasi ini.
Spesifikasi mendukung konsep penawaran dan bergantung pada komponen yang bertanggung jawab untuk memutuskan apakah akan menerima firmware. Keputusan untuk menerima firmware baru tidak sepele. Mungkin ada dependensi antara jenis firmware dan/atau versi dan jenis/versi perangkat keras yang mendasar tempat firmware baru berlaku. Penawaran juga bertindak sebagai mekanisme pengoptimalan karena gambar firmware dikirim ke komponen hanya jika mampu /siap menerimanya.
1.1 Daftar istilah
| Istilah | Deskripsi |
|---|---|
| ID Komponen | Di perangkat dengan beberapa komponen, ID komponen secara unik mengidentifikasi setiap komponen. |
| CRC | Pemeriksaan Redundansi Siklik Algoritma hash non-kriptografi yang digunakan untuk menghasilkan hash atau sidik jari blok data. CRC digunakan sebagai pemeriksaan untuk memberikan jaminan bahwa blok data tidak berubah sejak CRC dihitung. CRC tidak sempurna tetapi memberikan keyakinan bahwa data diterima dengan benar. |
| Perangkat | Kumpulan komponen (satu komponen utama dan nol atau lebih subkomponen). Perangkat terlihat oleh sistem operasi sebagai satu unit. Host berinteraksi dengan perangkat, yang biasanya merupakan komponen utama. Komputer mungkin memiliki beberapa perangkat di dalamnya. Sehubungan dengan spesifikasi ini, komunikasi ke 2 perangkat yang berbeda benar-benar independen. |
| Driver | Driver yang ditulis dengan menggunakan kerangka kerja Windows Driver Foundation (WDF). |
| Firmware | Kode yang berjalan pada perangkat keras fisik. Firmware dapat diperbarui dan biasanya berada dalam memori yang dapat diprogram yang terkait dengan perangkat keras. |
| Perangkat Keras | Sepotong fisik silikon di komputer. |
| Komponen Utama | Sepotong perangkat keras di komputer dan firmware untuk itu. Dalam konteks spesifikasi ini, komponen adalah entitas yang membutuhkan dan menerima pembaruan firmware. |
| Segment | Gambar firmware untuk komponen dapat disegmentasi menjadi segmen yang lebih kecil. Setiap segmen adalah gambar firmware kecil. |
| ID Segmen | Jika firmware komponen disegmentasi menjadi segmen yang lebih kecil, ID segmen adalah pengidentifikasi unik untuk segmen tersebut. |
| Tanda Tangan | Kriptografi berarti menentukan apakah gambar firmware telah diubah dengan cara yang tidak sah. Tanda tangan bersifat opsional tetapi direkomendasikan dan di luar cakupan spesifikasi ini. |
| Subkomponen | Tergantung pada arsitektur perangkat keras, tidak semua komponen mungkin terlihat oleh sistem operasi, karena mungkin terhubung ke hilir komponen yang terlihat oleh sistem. Komponen-komponen ini disebut sebagai subkomponen dalam spesifikasi ini. |
| KLT | Koleksi Tingkat Atas HID. |
| Token | Pengidentifikasi untuk sesi host. Host membuat token dan mengirimkannya dalam perintah, dan perangkat mengembalikannya dalam respons. Token dapat digunakan untuk menserialisasikan transaksi tertentu atau untuk mengidentifikasi bahwa sesi telah hilang dan yang lain dimulai. |
1.2 Cakupan
1.2.1 Goals
Solusi agnostik bus diperlukan untuk menghindari protokol baru untuk setiap jenis bus. HID di mana-mana dan memenuhi persyaratan tersebut.
Kemampuan untuk mendukung pembaruan firmware untuk perangkat multi-komponen, di mana satu komponen bertindak sebagai komponen utama dan yang lain adalah subkomponen yang terhubung ke komponen utama. Setiap komponen memerlukan firmware sendiri dengan dependensi non-sepele di antara satu sama lain.
Model driver umum untuk mengunduh gambar firmware ke komponen. Komponen kemudian memiliki algoritma khusus subkomponen untuk diteruskan ke subkomponen. Subkomponen juga dapat melakukan pemeriksaan validitas pada firmware mereka dan meneruskan hasilnya kembali ke komponen utama.
Kemampuan untuk mendukung pembaruan firmware saat operasi perangkat sedang berlangsung.
Kemampuan untuk memperbarui/memutar kembali firmware di perangkat produksi melalui alat resmi, dan memperbarui perangkat di pasar melalui Windows Update.
Fleksibilitas untuk mendukung firmware dalam pengembangan/firmware di pasar.
Kemampuan untuk mengegmentasi gambar firmware besar menjadi segmen yang lebih kecil untuk memudahkan komponen menerima gambar firmware.
1.2.2 Non-Goals
Tentukan format internal gambar firmware: Untuk host, gambar firmware adalah sekumpulan entri alamat dan payload.
Menandatangani/mengenkripsi/memvalidasi firmware yang diterima: Spesifikasi ini tidak menjelaskan cara menandatangani dan mengenkripsi gambar firmware. Diperlukan bahwa firmware yang diharapkan saat ini yang berjalan pada komponen memvalidasi firmware yang diunduh.
Tentukan mekanisme tentang bagaimana komponen berinteraksi dengan subkomponen: Host berinteraksi dengan perangkat sebagai satu unit, biasanya komponen utama. Komponen harus bertindak sebagai jembatan untuk komunikasi yang terkait dengan firmware subkomponen.
2 Arsitektur Perangkat Keras yang Didukung
Untuk mendukung desain perangkat keras yang fleksibel, protokol mendukung perangkat multi-komponen di mana setiap komponen memerlukan gambar firmwarenya sendiri. Dalam desain, satu komponen adalah komponen utama dan subkomponen dependen terhubung ke komponen utama tersebut. Setiap komponen dijelaskan secara unik oleh ID komponen.
Perangkat multi-komponen terlihat oleh sistem operasi sebagai satu unit. Host hanya berinteraksi dengan perangkat, biasanya komponen utama menggunakan protokol CFU ini. Komunikasi antara komponen dan subkomponennya berada di luar cakupan spesifikasi ini.
Pada PC, mungkin ada banyak perangkat yang berbeda (di mana perangkat mungkin memiliki satu atau beberapa komponen di sana). Dalam konteks protokol ini, komunikasi ke setiap perangkat bersifat independen. Setiap perangkat memiliki instans host yang sesuai.
3 Prasyarat Protokol
Bagian ini mencantumkan persyarat dan praktik terbaik yang harus diterapkan untuk memanfaatkan protokol ini:
Penggunaan gambar atomik
Gambar firmware untuk komponen tidak digunakan sampai seluruh gambar firmware berhasil diunduh. Jika firmware dibagi menjadi beberapa segmen, gambar tidak boleh digunakan sampai segmen akhir diterima dari pengirim. Pemeriksaan integritas harus dilakukan pada gambar akhir. Disarankan agar transportasi, digunakan untuk mengirimkan gambar firmware, memiliki koreksi kesalahan dan mencoba kembali mekanisme untuk menghindari unduhan berulang jika terjadi kesalahan transportasi.
Pembaruan firmware tidak boleh mengganggu operasi perangkat
Perangkat yang menerima gambar firmware harus dapat beroperasi selama pembaruan. Perangkat harus memiliki memori tambahan untuk menyimpan dan memvalidasi firmware yang masuk, sementara firmwarenya saat ini tidak ditimpa.
Autentikasi dan integritas
Implementor memutuskan faktor-faktor yang merupakan gambar firmware otentik. Disarankan agar firmware komponen saat ini setidaknya harus memvalidasi CRC dari gambar firmware yang masuk. Firmware saat ini juga harus menggunakan tanda tangan digital, atau, algoritma deteksi kesalahan lainnya. Jika validasi gagal, firmware menolak pembaruan. Pemulihan Kegagalan
Jika gambar firmware diunduh dan tidak berhasil, perangkat tidak boleh memanggil firmware baru dan terus beroperasi dengan firmware yang ada. Host dapat mencoba kembali pembaruan. Frekuensi percobaan ulang spesifik implementasi.
Kerahasiaan
Pilihan. Segmen firmware dapat dienkripsi. Teknik enkripsi dan dekripsi berada di luar cakupan spesifikasi ini. Spesifikasi ini memperlakukan payload firmware sebagai aliran data, terlepas dari apakah itu dienkripsi.
Perlindungan pembatalan
Kebijakan putar kembali diberlakukan oleh komponen utama dan spesifik implementasi. Firmware saat ini pada komponen memvalidasi gambar firmware masuk terhadap kebijakan internal seperti nomor versi harus lebih baru, atau jenis rilis tidak dapat dialihkan dari rilis ke debug, dan sebagainya. Protokol mengizinkan olahpesan untuk menunjukkan bahwa pembaruan diterima meskipun melanggar kebijakan putar kembali.
4 Gambaran Umum Protokol CFU
Protokol CFU adalah sekumpulan perintah dan respons yang diperlukan untuk mengirim gambar firmware baru dari host ke perangkat tempat firmware dimaksudkan.
Pada tingkat tinggi, protokol melakukan iterasi melalui semua gambar firmware untuk dikirim ke perangkat. Untuk setiap gambar firmware, host menawarkan untuk mengirim file ke perangkat. Hanya jika perangkat menerima penawaran, host akan mengirim file.
Untuk mendukung kasus di mana urutan pembaruan perangkat memiliki dependensi, perangkat mungkin tidak menerima penawaran tertentu dalam pass pertama, oleh karena itu protokol memungkinkan host untuk mengirim ulang semua penawaran firmware ke perangkat sampai semua dependensi diselesaikan.
4.1 Urutan Perintah Pemrograman Pembaruan Firmware
Berikut adalah urutan perintah CFU untuk memperbarui gambar firmware.
4.1.1 Status: Pemberitahuan Yang Diinisialisasi Host
Setelah host menginisialisasi dirinya sendiri dan telah mengidentifikasi serangkaian penawaran yang perlu dikirim ke perangkat, host mengeluarkan perintah OFFER_INFO_START_ENTIRE_TRANSACTION untuk menunjukkan kepada komponen bahwa host sekarang diinisialisasi. Tujuan dari perintah ini adalah untuk memberi tahu firmware perangkat saat ini bahwa instans baru host tersedia. Pemberitahuan ini berguna ketika instans host sebelumnya dihentikan secara tiba-tiba. Perangkat harus menyelesaikan perintah ini dengan sukses.
4.1.2 Status: Pemberitahuan OFFER_INFO_START_OFFER_LIST
Dalam status ini, host mengeluarkan perintah OFFER_INFO_START_OFFER_LIST untuk menunjukkan bahwa siap untuk mengirim penawaran ke firmware perangkat saat ini. Komponen utama perangkat harus menyelesaikan perintah ini dengan sukses.
Perintah ini berguna karena host dapat mengirim semua penawaran ke perangkat lebih dari sekali.
4.1.3 Status: Kirim perintah FIRMWARE_UPDATE_OFFER
Host mengirimkan penawaran ke komponen utama (atau subkomponennya) untuk memeriksa apakah komponen ingin menerima/menolak firmware. Penawaran berisi semua metadata yang diperlukan tentang gambar firmware, sehingga firmware saat ini pada komponen dapat memutuskan apakah akan menerima, menunggu, melompati, atau menolak penawaran.
Penawaran mungkin untuk komponen utama atau subkomponen. Jika komponen dapat menerima penawaran, komponen akan mempersiapkan diri untuk menerima firmware. Ini mungkin melibatkan persiapan bank memori untuk menerima gambar firmware yang masuk. Komponen mungkin tidak menerima penawaran, misalnya, komponen mungkin sudah memiliki versi firmware yang lebih baru (atau sama) yang ingin dikirim host. Untuk alasan selengkapnya, lihat contoh yang dijelaskan dalam Lampiran 1: Contoh Urutan Perintah Pemrograman Pembaruan Firmware.
Bahkan jika penawaran diterima, komponen utama mungkin masih menolak gambar firmware setelah pengunduhan untuk kegagalan integritas dan/atau pemeriksaan putar kembali terhadap gambar aktual yang diterima. Komponen harus memeriksa setiap properti gambar firmware terlepas dari informasi apa pun dalam penawaran.
Host mengeluarkan perintah FIRMWARE_UPDATE_OFFER untuk memberi tahu komponen utama tentang gambar firmware yang ingin dikirim host.
Jika komponen menerima penawaran, komponen tersebut dengan status FIRMWARE_UPDATE_OFFER_ACCEPT sehingga menerima penawaran.
Jika firmware perangkat sibuk dan komponen utama tidak dapat menerima ini atau penawaran berikutnya saat ini, firmware perangkat mengirimkan respons sibuk dengan status FIRMWARE_UPDATE_OFFER_BUSY.
Jika firmware saat ini tertarik dengan penawaran, namun tidak dapat menerima penawaran (misalnya, karena dependensi pada pembaruan yang hilang untuk subkomponen) itu merespons dengan FIRMWARE_UPDATE_OFFER_SKIP yang menunjukkan bahwa ia tertarik pada firmware ini namun tidak dapat menerimanya. Host kemudian melanjutkan ke penawaran berikutnya dan harus menawarkan kembali firmware ini nanti.
Jika firmware saat ini tidak tertarik dengan penawaran (misalnya, itu adalah versi yang lebih lama), maka firmware merespons dengan status FIRMWARE_UPDATE_OFFER_REJECT memberikan alasan penolakan yang sesuai. Status ini tidak menunjukkan bahwa host tidak dapat mengirim ulang penawaran ini di masa mendatang. Host biasanya mengirim setiap penawaran setiap kali menginisialisasi atau mengirim ulang daftar penawaran ke perangkat (lihat Status: OFFER_INFO_START_OFFER_LIST Pemberitahuan).
4.1.4 Status: Kirim Firmware
Dalam keadaan ini host mulai mengirim gambar firmware ke komponen utama, yang komponennya sebelumnya telah menerima penawaran.
Karena konten gambar firmware kemungkinan melebihi batas payload dari satu perintah, host memecah gambar firmware menjadi paket. Host mengirimkan setiap paket secara berurutan dalam perintah FIRMWARE_UPDATE CONTENT terpisah. Komponen utama harus menghasilkan paket respons untuk setiap perintah.
Setiap perintah FIRMWARE_UPDATE CONTENT menjelaskan alamat offset yang menyertakan payload firmware parsial. Komponen menggunakan offset untuk menentukan alamat tempat payload firmware parsial harus disimpan. Perangkat menulis konten ke lokasi yang sesuai dan mengakui perintah dengan mengirim respons.
Untuk paket pertama yang dikirim host, ia mengatur bendera FIRMWARE_UPDATE_FLAG_FIRST_BLOCK, menunjukkan ke perangkat bahwa ini adalah paket pertama dari gambar firmware. Jika perangkat belum menyiapkan dirinya sendiri untuk menerima firmware, perangkat dapat melakukannya saat ini.
Untuk paket terakhir, host mengirim, ia mengatur bendera FIRMWARE_UPDATE_FLAG_LAST_BLOCK.
Setelah firmware saat ini pada perangkat menulis payload firmware parsial yang disertakan dalam perintah ini, firmware harus melakukan pemeriksaan validasi dan autentikasi pada gambar firmware yang masuk sebelum mengirim respons. Ini minimal mencakup:
Pemeriksaan CRC untuk memverifikasi integritas seluruh gambar firmware.
Jika pemeriksaan CRC berhasil, verifikasi opsional tanda tangan gambar masuk.
Setelah pemeriksaan tanda tangan opsional, periksa versi untuk memastikan bahwa versi firmware baru sama atau lebih baru dari firmware yang ada.
Jika gambar firmware yang masuk dibagi menjadi segmen yang lebih kecil, terserah firmware saat ini untuk menentukan apakah itu segmen terakhir dari gambar firmware, dan kemudian menyertakan semua segmen sebagai bagian dari validasi.
Jika pemeriksaan sebelumnya lolos, firmware saat ini dapat mengatur perangkat untuk bertukar ke gambar baru pada reset berikutnya dan melaporkan keberhasilan ke host. Biasanya, komponen tidak memulai reset mandiri. Ini untuk mencegah gangguan dalam perangkat lunak, firmware, entitas perangkat keras apa pun yang berinteraksi dengan komponen. Namun, itu bukan persyaratan dan dapat bervariasi tergantung pada implementasinya.
Jika langkah-langkah verifikasi gagal, firmware tidak boleh menyiapkan pertukaran pada reset berikutnya dan harus menunjukkan respons kegagalan terhadap host.
4.1.5 Status Keputusan: Apakah ada lebih banyak penawaran
Dalam status ini, host menentukan apakah ada lebih banyak penawaran untuk dikirim ke perangkat.
4.1.6 Status: Pemberitahuan OFFER_INFO_END_OFFER_LIST
Status ini tercapai ketika host telah mengirim semua penawaran ke komponen utama di firmware perangkat saat ini. Host mengirimkan perintah OFFER_INFO_END_OFFER_LIST untuk menunjukkan bahwa host telah mengirim semua penawaran ke komponen.
Perangkat harus menyelesaikan perintah ini dengan sukses.
4.1.7 Status Keputusan: Daftar Penawaran Pemutaran Ulang
Host menentukan apakah perlu mengirim ulang semua penawaran. Kasus ini mungkin terjadi jika sebelumnya komponen utama telah melewatkan beberapa penawaran dan menerima beberapa penawaran. Host harus memutar ulang daftar penawaran lagi.
Mungkin ada logika spesifik implementasi lainnya yang dapat mengakibatkan keputusan untuk memutar ulang daftar penawaran.
4.1.8 Status: Perangkat Sibuk
Status ini menyiratkan bahwa perangkat mengembalikan respons sibuk terhadap penawaran.
Host mengirimkan perintah OFFER_NOTIFY_ON_READY, di mana perangkat tidak merespons dengan penerimaan hingga perangkat gratis.
5 Format Paket Protokol CFU
Protokol CFU diimplementasikan sebagai serangkaian perintah dan respons. Protokol berurutan bersifat berurutan. Untuk setiap perintah yang dikirim host ke komponen, komponen diharapkan merespons (kecuali dinyatakan sebaliknya secara eksplisit dalam spesifikasi ini). Host tidak mengirim perintah berikutnya, sampai respons yang valid diterima untuk perintah sebelumnya yang dikirimnya.
Jika komponen tidak merespons dalam periode, atau mengirim respons yang tidak valid, host dapat memulai ulang proses dari awal. Protokol ini tidak menentukan nilai batas waktu tertentu.
Ada perintah untuk mendapatkan informasi versi firmware saat ini pada komponen; untuk mengirim penawaran dan mengirim gambar firmware.
Namun, host tidak perlu menahan penawaran berdasarkan respons yang diterima dari komponen utama tentang informasi versi yang dikueri. Informasi ini dibuat dapat ditemukan untuk pengelogan atau tujuan lain.
5.1 GET_FIRMWARE_VERSION
Mendapatkan versi firmware saat ini dari komponen utama (dan subkomponennya). Perintah tidak memiliki argumen apa pun.
5.1.1 Perintah
Perintah ini dikirim oleh host untuk mengkueri versi firmware saat ini pada komponen utama (dan subkomponennya). Host dapat menggunakannya untuk mengonfirmasi apakah firmware berhasil diperbarui. Saat menerima perintah ini, komponen utama merespons dengan versi firmware untuk dirinya sendiri dan semua subkomponen.
5.1.2 Respons
Komponen merespons dengan versi firmware komponen utama dan subkomponen. Ukuran respons adalah 60 byte yang memungkinkan informasi versi hingga tujuh komponen (satu primer dan hingga enam subkomponen).
Tabel 5,1-1 GET_FIRMWARE_VERSION Tata Letak Respons
5.1.2.1 Header
Tabel 5.1-2 GET_FIRMWARE_VERSION Respons - Tata Letak Header
Header untuk respons menyediakan informasi berikut.
Tabel 5.1-3 GET_FIRMWARE_VERSION Respons - Bit Header
| Bit Offset | Bidang | Ukuran | Deskripsi |
|---|---|---|---|
| 0 | Jumlah Komponen | 8 | Jumlah komponen yang dapat diunduh yang dikelola melalui mekanisme ini untuk Komponen ini. Jumlah Komponen menentukan ukuran tabel maksimum. Saat ini hingga 7 komponen didukung untuk memastikan bahwa respons dapat sesuai dalam 60 byte yang diizinkan. |
| 8 | Rsvd | 16 | Bidang yang dipesan. Pengirim harus mengatur ini ke 0. Penerima harus mengabaikan nilai ini. |
| 24 | Versi Protokol | 4 | Bit revisi pembaruan firmware mewakili revisi Protokol Pembaruan FW saat ini sedang digunakan dalam transportasi. Untuk antarmuka yang ditentukan di sini, Revisi Pembaruan FW harus 0010b. |
| 28 | Rsvd | 3 | Bidang yang dipesan. Pengirim harus mengatur ini ke 0. Penerima harus mengabaikan nilai ini. |
| 31 | E | 1 | Bendera ekstensi adalah kait protokol di masa mendatang untuk memungkinkan komponen tambahan dilaporkan. |
5.1.2.2 Versi dan Properti Komponen
Untuk setiap komponen, dua DWORD digunakan untuk menjelaskan properti komponen hingga 7 komponen. Jika jumlah komponen di header kurang dari 7, DWORDS yang tidak digunakan di akhir respons harus diatur ke 0.
Tabel 5.1-4 GET_FIRMWARE_VERSION Respons - Versi Komponen dan Tata Letak Properti
Setiap informasi spesifik komponen dijelaskan dalam dua DWORD sebagai berikut:
Tabel 5.1-5 GET_FIRMWARE_VERSION Respons - Versi Komponen dan Gigitan Properti
| Bit Offset | Bidang | Ukuran | Deskripsi |
|---|---|---|---|
| 0 | Versi firmware | 32 | Mengembalikan versi firmware saat ini untuk komponen tersebut. Spesifikasi ini tidak mengamanatkan format tertentu untuk versi firmware. Lihat bagian Versi Firmware untuk panduan. |
| 32 | Bank | 2 | Pilihan. Tergantung pada arsitekturnya, perangkat keras komponen mungkin memiliki beberapa bank tempat firmware dapat disimpan. Tergantung pada implementasinya, pengirim dapat menentukan bank tempat firmware saat ini berada. Bidang ini Wajib Bersyukur - dukungan bersifat opsional, namun tidak boleh digunakan untuk tujuan lain. |
| 34 | Dicadangkan | 2 | Bidang yang dipesan. Pengirim harus mengatur ini ke 0. Penerima harus mengabaikan nilai ini. |
| 36 | Vendor Spesifik | 4 | Bidang khusus vendor yang dapat digunakan secara spesifik implementasi. Vendor dapat menggunakan bit ini untuk mengodekan informasi seperti: - Jenis firmware: Pra-rilis/host mandiri/produksi; debug/ritel - Fase pengembangan - ID produk, untuk mencegah komponen menerima firmware untuk produk lain menggunakan protokol pembaruan yang sama. |
| 40 | ID Komponen | 8 | Pengidentifikasi unik untuk komponen. |
| 48 | Vendor Spesifik | 16 | Bidang khusus vendor yang dapat digunakan secara spesifik implementasi. |
5.1.3 Pemetaan ke HID
Ini diimplementasikan sebagai permintaan HID Get Feature dengan ukuran respons 60 byte, selain ID Laporan. Panjang laporan fitur mengakomodasi seluruh respons GET_FIRMWARE_VERSION. Tidak ada data yang terkait dengan permintaan Dapatkan Fitur dari host.
5.2 FIRMWARE_UPDATE_OFFER
Menentukan apakah komponen utama menerima atau menolak firmware.
5.2.1 Perintah
Host mengirimkan perintah ini ke komponen untuk menentukan apakah ia menerima atau menolak firmware. Host harus mengirim penawaran dan komponen harus menerima penawaran sebelum host dapat mengirim firmware.
Paket perintah FIRMWARE_UPDATE_OFFER didefinisikan sebagai berikut.
Tabel 5,2-1 tata letak perintah FIRMWARE_UPDATE_OFFER
5.2.1.1 Informasi Komponen
Tabel 5.2-2 perintah FIRMWARE_UPDATE_OFFER - Tata Letak Informasi Komponen
Bit byte Informasi Komponen dijelaskan dalam tabel ini.
Tabel 5.2-3 perintah FIRMWARE_UPDATE_OFFER - Bit Informasi Komponen
| Bit Offset | Bidang | Ukuran | Deskripsi |
|---|---|---|---|
| 0 | Nomor Segmen | 8 | Bidang ini digunakan jika firmware untuk komponen disegmentasi menjadi segmen yang lebih kecil. Jika digunakan, nilai ini menunjukkan segmen yang terkandung dalam paket payload berikutnya. Misalnya - jika gambar firmware untuk komponen sangat besar dan komponen utama hanya dapat mengambil bagian gambar yang lebih kecil pada satu waktu, bidang ini dapat digunakan untuk menunjukkan bahwa penawaran ini adalah untuk segmen ke-i dari gambar lengkap. Penawaran terpisah dapat dikirim ke komponen utama yang berisi segmen gambar ke-1 i dan sebagainya. |
| 8 | Dicadangkan | 6 | Bidang yang dipesan. Pengirim harus mengatur ini ke 0. Penerima harus mengabaikan nilai ini. |
| 14 | I | 1 | Reset Segera Paksa (I) - Nilai bit ini digunakan untuk menunjukkan kepada komponen untuk segera mengatur ulang dirinya sendiri setelah unduhan firmware selesai dan diverifikasi untuk segera memanggilnya. - Bendera ini ditujukan untuk fase pengembangan. |
| 15 | V | 1 | Paksa Abaikan Versi (V) - Bendera ini ditujukan untuk gambar firmware pra-rilis atau debug. Ini menunjukkan kepada komponen untuk tidak menolak firmware berdasarkan versi firmware. - Bendera ini ditujukan untuk fase pengembangan. Ini dapat digunakan untuk dengan sengaja memutar kembali ke versi firmware sebelumnya. - Bendera ini harus diabaikan oleh firmware produksi. |
| 16 | ID Komponen | 8 | Byte ini digunakan untuk skenario multi-komponen. Bidang ini dapat digunakan untuk mengidentifikasi subkomponen yang penawarannya dimaksudkan. Jika tidak digunakan, nilainya harus 0. Nilai yang mungkin dari ID komponen adalah sebagai berikut: 1 - 0xDF: Valid 0xE0 - 0xFD: Dicadangkan. Jangan gunakan. 0xFF: Penawaran ini adalah paket informasi penawaran khusus. Lihat Informasi FIRMWARE_UPDATE_OFFER untuk detailnya. 0xFE : Penawaran adalah paket perintah penawaran khusus. Lihat bagian FIRMWARE_UPDATE_OFFER Diperluas untuk detailnya. |
| 24 | Token | 8 | Host menyisipkan token unik dalam paket penawaran ke komponen. Token ini harus dikembalikan oleh komponen dalam respons penawaran.< Ini berguna jika ada kebutuhan komponen untuk membedakan antara host/jenis host yang berbeda. Nilai yang tepat untuk digunakan adalah implementasi khusus. Misalnya, satu nilai dapat digunakan untuk driver dan satu lagi untuk aplikasi. Ini memungkinkan firmware perangkat saat ini untuk mempertangungjawabkan potensi beberapa pengirim perintah CFU. Salah satu implementasi yang mungkin adalah menerima perintah CFU pertama dan menolak semua perintah lain dengan token yang berbeda sampai transaksi CFU pertama selesai. |
5.2.1.2 Versi Firmware
Keempat byte ini mewakili firmware versi 32-bit. Format untuk versi firmware tidak diamanatkan oleh spesifikasi ini. Berikut ini disarankan.
Tabel 5.2-4 FIRMWARE_UPDATE_OFFER Command - Tata Letak Versi Firmware
Format untuk versi firmware tidak diamanatkan oleh spesifikasi ini, namun berikut ini adalah pedoman yang direkomendasikan.
Tabel 5.2-5 FIRMWARE_UPDATE_OFFER Command - Bit Versi Firmware
| Bit Offset | Bidang | Ukuran | Deskripsi |
|---|---|---|---|
| 0 | Varian | 8 | Bidang ini dapat dijelaskan untuk membedakan antara firmware pra-rilis dan firmware produksi. Ini mungkin menunjukkan jenis tanda tangan yang digunakan untuk menandatangani firmware. |
| 8 | Versi Minor | 16 | Nilai bidang ini harus diperbarui untuk setiap build firmware. Nilai bidang ini harus diperbarui untuk setiap build firmware. |
| 24 | Versi Utama | 8 | Bidang ini adalah versi utama dari gambar firmware. Bidang ini harus diperbarui saat mengirim lini produk baru, pembaruan baru utama untuk firmware, dan sebagainya. |
5.2.1.3 Vendor Spesifik
Keempat byte ini dapat digunakan untuk mengodekan informasi kustom apa pun dalam penawaran yang khusus untuk implementasi vendor.
5.2.1.4 Misc. dan Versi protokol
Keempat byte ini dapat digunakan untuk mengodekan informasi kustom apa pun dalam penawaran yang khusus untuk implementasi vendor.
Tabel 5.2-6 perintah FIRMWARE_UPDATE_OFFER - Tata Letak Khusus Vendor
Bit byte Khusus Vendor dijelaskan dalam tabel ini.
Tabel 5.2-7 FIRMWARE_UPDATE_OFFER Command - Versi Misc. dan Protocol
| Bit Offset | Bidang | Ukuran | Deskripsi |
|---|---|---|---|
| 0 | Versi Protokol | 4 | Bidang ini harus diatur ke 0010b yang menunjukkan bahwa host/penawaran sesuai dengan versi 2 protokol CFU. |
| 4 | Dicadangkan | 4 | Dicadangkan. Jangan gunakan. |
| 8 | Dicadangkan | 8 | Dicadangkan. Jangan gunakan. |
| 16 | Vendor Spesifik | 16 | Bidang ini dapat digunakan untuk mengodekan informasi kustom apa pun dalam penawaran yang khusus untuk implementasi vendor. |
5.2.2 Respons
Paket FIRMWARE_UPDATE_OFFER Response didefinisikan sebagai berikut.
Tabel 5.2-8 FIRMWARE_UPDATE_OFFER Tata Letak Token Respons
5.2.2.1 Token
Tabel 5.2-9 FIRMWARE_UPDATE_OFFER Respons - Tata Letak Token
Bit byte Token dijelaskan dalam tabel ini.
Tabel 5.2-10 FIRMWARE_UPDATE_OFFER Respons - Bit Token
| Bit Offset | Bidang | Ukuran | Deskripsi |
|---|---|---|---|
| 0 | Dicadangkan | 8 | Dicadangkan. Jangan gunakan. |
| 8 | Dicadangkan | 8 | Dicadangkan. Jangan gunakan. |
| 16 | Dicadangkan | 8 | Dicadangkan. Jangan gunakan. |
| 24 | Token | 8 | Token untuk mengidentifikasi host. |
5.2.2.2 Dicadangkan (B7 - B4)
Dicadangkan. Jangan gunakan.
5.2.2.3 Alasan Penolakan (RR)
Tabel 5.2-11 FIRMWARE_UPDATE_OFFER Respons - Tolak Tata Letak Alasan
Tabel 5.2-12 FIRMWARE_UPDATE_OFFER Respons - Tolak Bit Alasan
Bit byte Tolak Alasan dijelaskan dalam tabel ini.
| Bit Offset | Bidang | Ukuran | Deskripsi |
|---|---|---|---|
| 0 | Kode RR | 8 | Kode Alasan Penolakan yang menunjukkan alasan yang disediakan oleh komponen untuk menolak penawaran. Nilai ini tergantung pada bidang Status. Untuk pemetaan Status ke Kode RR, lihat Tabel 5.2-13. |
| 8 | Dicadangkan | 24 | Dicadangkan. Jangan gunakan. |
Tabel 5.2-13 FIRMWARE_UPDATE_OFFER Respons Nilai Kode RR
Nilai yang mungkin untuk byte Kode RR dijelaskan dalam tabel ini.
| Kode RR | Nama | Deskripsi |
|---|---|---|
| 0x00 | FIRMWARE_OFFER_REJECT_OLD_FW | Penawaran ditolak karena versi firmware yang ditawarkan lebih lama atau sama dengan firmware saat ini. |
| 0x01 | FIRMWARE_OFFER_REJECT_INV_COMPONENT | Penawaran ditolak karena firmware yang ditawarkan tidak berlaku untuk platform produk. Hal ini dapat disebabkan oleh ID komponen yang tidak didukung atau gambar yang ditawarkan tidak kompatibel dengan perangkat keras sistem. |
| 0x02 | FIRMWARE_UPDATE_OFFER SWAP_PENDING | Firmware komponen telah diperbarui namun pertukaran ke firmware baru tertunda. Tidak ada pemrosesan Pembaruan Firmware lebih lanjut yang dapat terjadi sampai pertukaran selesai, biasanya melalui reset. |
| 0x03 - 0x08 | (Dicadangkan) | Dicadangkan. Jangan gunakan. |
| 0x09 - 0xDF | (Dicadangkan) | Dicadangkan. Jangan gunakan. |
| 0xE0 - 0xFF | (Khusus Vendor) | Nilai-nilai ini digunakan oleh perancang protokol dan maknanya spesifik untuk vendor. |
5.2.2.4 Status
Tabel 5.2-14 FIRMWARE_UPDATE_OFFER Tata Letak Status Respons
Bit byte Status dijelaskan dalam tabel ini.
Tabel 5.2-15 FIRMWARE_UPDATE_OFFER Respons - Bit Status
| Bit Offset | Bidang | Ukuran | Deskripsi |
|---|---|---|---|
| 0 | Status | 8 | Nilai ini menunjukkan keputusan komponen untuk menerima, menunggu, melewati, atau menolak penawaran. Komponen memberikan alasan dalam nilai bidang Kode RR. Untuk pemetaan Status ke Kode RR, lihat Tabel 5.2-16. |
| 8 | Dicadangkan | 24 | Dicadangkan. Jangan gunakan. |
Nilai yang mungkin untuk byte Status dijelaskan dalam tabel ini.
Tabel 5.2-16 FIRMWARE_UPDATE_OFFER Nilai Status Respons
| Status | Nama | Deskripsi |
|---|---|---|
| 0x00 | FIRMWARE_UPDATE_OFFER_SKIP | Komponen telah memutuskan untuk melewati penawaran. Host harus menawarkannya lagi nanti. |
| 0x01 | FIRMWARE_UPDATE_OFFER_ACCEPT | Komponen telah memutuskan untuk menerima penawaran. |
| 0x02 | FIRMWARE_UPDATE_OFFER_REJECT | Komponen telah memutuskan untuk menolak penawaran. |
| 0x03 | FIRMWARE_UPDATE_OFFER_BUSY | Perangkat sibuk, dan host harus menunggu sampai perangkat siap. |
| 0x04 | FIRMWARE_UPDATE_OFFER_COMMAND | Digunakan saat ID Komponen dalam byte Informasi Komponen (lihat Informasi Komponen 5.1.2.1.1) diatur ke 0xFE. Untuk Kode Perintah yang diatur ke permintaan OFFER_NOTIFY_ON_READY, menunjukkan aksesori siap menerima penawaran tambahan. |
| 0xFF | FIRMWARE_UPDATE_CMD_NOT_SUPPORTED | Permintaan penawaran tidak dikenali. |
5.2.3 Pemetaan ke Protokol HID
Pesan dikeluarkan untuk komponen melalui mekanisme Laporan Output HID , dengan menggunakan ID Laporan Utilitas HID khusus untuk Pembaruan Firmware. TLC Utilitas HID untuk digunakan yang dijelaskan dalam Lampiran.
5.3 FIRMWARE_UPDATE_OFFER - Informasi
Jika ID Komponen dalam byte Informasi Komponen (lihat Informasi Komponen) diatur ke 0xFF, maka bit (15 byte) didefinisikan ulang untuk menunjukkan Informasi Penawaran Saja, dari Host ke komponen. Mekanisme ini memungkinkan ekstensibilitas dan cara bagi Host untuk memberikan informasi spesifik kepada perangkat seperti Daftar Penawaran Mulai, Daftar Penawaran Akhir, Mulai Seluruh Transaksi. Paket Informasi Penawaran selalu segera Diterima oleh komponen.
5.3.1 Perintah
Paket Perintah FIRMWARE_UPDATE_OFFER -Information didefinisikan sebagai berikut:
Tabel 5.3-1 FIRMWARE_UPDATE_OFFER - Tata Letak Perintah Informasi
5.3.1.1 Komponen
Tabel 5.3-2 FIRMWARE_UPDATE_OFFER - Perintah Informasi - Tata Letak Komponen
Bit byte Komponen dijelaskan dalam tabel ini.
Tabel 5.3-3 FIRMWARE_UPDATE_OFFER - Perintah Informasi - Bit Komponen
| Bit Offset | Bidang | Ukuran | Deskripsi |
|---|---|---|---|
| 0 | Kode Informasi | 8 | Nilai ini menunjukkan jenis informasi. Nilai ini bukan bitmask dan hanya bisa menjadi salah satu nilai yang mungkin dijelaskan dalam Tabel 5,3-4. |
| 8 | Dicadangkan. | 8 | Dicadangkan. Jangan gunakan. |
| 16 | ID Komponen | 8 | Atur ke 0xFF. |
| 24 | Token | Host menyisipkan token unik dalam paket penawaran ke komponen. Token ini harus dikembalikan oleh komponen dalam respons penawaran. |
Tabel 5.3-4 FIRMWARE_UPDATE_OFFER - Perintah Informasi - Nilai Kode Informasi
| Status | Nama | Deskripsi |
|---|---|---|
| 0x00 | OFFER_INFO_START_ENTIRE_TRANSACTION | Menunjukkan bahwa host baru, atau telah dimuat ulang, dan seluruh pemrosesan penawaran dimulai (kembali). |
| 0x01 | OFFER_INFO_START_OFFER_LIST | Menunjukkan awal daftar Penawaran dari host jika Accessory memiliki aturan unduhan yang terkait dengan memastikan satu subkomponen diperbarui sebelum subkomponen lain dalam sistem. |
| 0x02 | OFFER_INFO_END_OFFER_LIST | Menunjukkan akhir daftar Penawaran dari host. |
5.3.1.2 Cadangan B7 - B4
Dicadangkan. Jangan gunakan.
5.3.1.3 Cadangan B11 - B8
Dicadangkan. Jangan gunakan.
5.3.1.4 Cadangan B15 - B12
Dicadangkan. Jangan gunakan.
5.3.2 Respons
Balasan paket FIRMWARE_UPDATE_OFFER - Respons Informasi Penawaran didefinisikan sebagai berikut.
Tabel 5.3-5 FIRMWARE_UPDATE_OFFER - Tata Letak Respons Informasi
5.3.2.1 Token
Tabel 5.3-6 FIRMWARE_UPDATE_OFFER- Tata Letak Token Respons Paket Informasi
Bit byte Token dijelaskan dalam tabel ini.
Tabel 5.3-7 FIRMWARE_UPDATE_OFFER - Respons Informasi - Bit Token
| Bit Offset | Bidang | Ukuran | Deskripsi |
|---|---|---|---|
| 0 | Dicadangkan | 8 | Dicadangkan. Jangan gunakan. |
| 8 | Dicadangkan | 8 | Dicadangkan. Jangan gunakan. |
| 16 | Dicadangkan | 8 | Dicadangkan. Jangan gunakan. |
| 24 | Token | 8 | Token untuk mengidentifikasi host |
5.3.2.2 Cadangan B7 - B4
Dicadangkan. Jangan gunakan.
5.3.2.3 Alasan Penolakan (RR)
Tabel 5.3-8 FIRMWARE_UPDATE_OFFER - Respons Informasi - Tata Letak Kode RR
Bit byte Tolak Alasan dijelaskan dalam tabel ini.
Tabel 5.3-9 FIRMWARE_UPDATE_OFFER- Respons Informasi Penawaran - Bit Kode RR
| Bit Offset | Bidang | Ukuran | Deskripsi |
|---|---|---|---|
| 0 | Kode RR | 8 | Kode Alasan Penolakan yang menunjukkan alasan yang disediakan oleh komponen untuk menolak penawaran. Nilai yang mungkin dijelaskan dalam Tabel 5,3-10. Nilai ini tergantung pada bidang Status. |
| 8 | Dicadangkan | 24 | Dicadangkan. Jangan gunakan. |
Nilai yang mungkin untuk byte Kode RR dijelaskan dalam tabel ini.
Tabel 5.3-10 FIRMWARE_UPDATE_OFFER- Respons Informasi - Nilai Kode RR
| Kode RR | Nama | Deskripsi |
|---|---|---|
| 0x00 | FIRMWARE_OFFER_REJECT_OLD_FW | Penawaran ditolak karena versi firmware yang ditawarkan lebih lama atau sama dengan firmware saat ini. |
| 0x01 | FIRMWARE_OFFER_REJECT_INV_COMPONENT | Penawaran ditolak karena firmware yang ditawarkan tidak berlaku untuk platform produk. Hal ini dapat disebabkan oleh ID komponen yang tidak didukung atau gambar yang ditawarkan tidak kompatibel dengan perangkat keras sistem. |
| 0x02 | FIRMWARE_UPDATE_OFFER SWAP_PENDING | Firmware komponen telah diperbarui namun pertukaran ke firmware baru tertunda. Tidak ada pemrosesan Pembaruan Firmware lebih lanjut yang dapat terjadi sampai pertukaran selesai, biasanya melalui reset. |
| 0x03 - 0x08 | (Dicadangkan) | Dicadangkan. Jangan gunakan. |
| 0x09 - 0xDF | (Dicadangkan) | Dicadangkan. Jangan gunakan. |
| 0xE0 — 0xFF | (Khusus Vendor) | Nilai-nilai ini digunakan oleh perancang protokol dan maknanya spesifik untuk vendor. |
5.3.2.4 Status
Tabel 5.3-11 FIRMWARE_UPDATE_OFFER - Tata Letak Status Respons Informasi Penawaran
Bit byte Status dijelaskan dalam tabel ini.
Tabel 5.3-12 FIRMWARE_UPDATE_OFFER - Informasi Penawaran - Bit Status Respons
| Bit Offset | Bidang | Ukuran | Deskripsi |
|---|---|---|---|
| 0 | Status | 8 | Bidang ini harus diatur ke FIRMWARE_UPDATE_OFFER_ACCEPT. Ini menunjukkan bahwa komponen telah memutuskan untuk menerima penawaran. |
| 8 | Dicadangkan. | 24 | Dicadangkan. Jangan gunakan. |
5.4 FIRMWARE_UPDATE_OFFER - Diperpanjang
Jika ID Komponen dalam byte Informasi Komponen diatur ke 0xFE, maka bit (15 byte) didefinisikan ulang untuk menunjukkan Perintah Penawaran dari host ke firmware perangkat. Mekanisme ini memungkinkan ekstensibilitas dan cara bagi host untuk memberikan informasi tertentu ke perangkat. Paket Perintah Penawaran dikembalikan ketika komponen siap untuk merespons Diterima.
5.4.1 Perintah
Jika ID Komponen dalam byte Informasi Komponen diatur ke 0xFE, empat DWORD didefinisikan ulang sebagai berikut:
Tabel 5,4-1 FIRMWARE_UPDATE_OFFER - Tata Letak Perintah Yang Diperluas
5.4.1.1 Komponen
Tabel 5,4-2 FIRMWARE_UPDATE_OFFER - Paket Perintah Yang Diperluas - Perintah - Tata Letak Komponen
Bit byte Komponen dijelaskan dalam tabel ini.
Tabel 5,4-3 FIRMWARE_UPDATE_OFFER - Perintah Diperluas - Bit Komponen
| Bit Offset | Bidang | Ukuran | Deskripsi |
|---|---|---|---|
| 0 | Kode Perintah | 8 | Nilai ini menunjukkan jenis perintah. Nilai ini bukan bitmask dan hanya bisa menjadi salah satu nilai yang mungkin dijelaskan dalam Tabel 5,4-4. |
| 8 | Dicadangkan. | 8 | Dicadangkan. Jangan gunakan. |
| 16 | ID Komponen | 8 | Atur ke 0xFE. |
| 24 | Token | Host menyisipkan token unik dalam paket penawaran ke komponen. Token ini harus dikembalikan oleh komponen dalam respons penawaran. |
Tabel 5,4-4 FIRMWARE_UPDATE_OFFER - Perintah Diperluas - Nilai Kode Perintah
| Status | Nama | Deskripsi |
|---|---|---|
| 0x01 | OFFER_NOTIFY_ON_READY | Dikirim oleh host jika penawaran sebelumnya ditolak oleh komponen. |
| 0x02 - 0xFF | Telah dipesan | Telah dipesan |
5.4.1.2 Cadangan B7 - B4
Dicadangkan. Jangan gunakan.
5.4.1.3 Cadangan B11 - B8
Dicadangkan. Jangan gunakan.
5.4.1.4 Cadangan B15 - B12
Dicadangkan. Jangan gunakan.
5.4.2 Respons
Respons perintah FIRMWARE_UPDATE_OFFER - Penawaran dari perangkat mungkin tidak segera diterima. Respons didefinisikan sebagai berikut.
Tabel 5,4-5 FIRMWARE_UPDATE_OFFER - Tata Letak Respons Paket Perintah Yang Diperluas
5.4.2.1 Token
Tabel 5.4-6 FIRMWARE_UPDATE_OFFER- Respons Paket Perintah Penawaran - Tata Letak Token
Bit byte Token dijelaskan dalam tabel ini.
Tabel 5.4-7 FIRMWARE_UPDATE_OFFER - Respons Perintah Penawaran - Bit Token
| Bit Offset | Bidang | Ukuran | Deskripsi |
|---|---|---|---|
| 0 | Dicadangkan | 8 | Dicadangkan. Jangan gunakan. |
| 8 | Dicadangkan | 8 | Dicadangkan. Jangan gunakan. |
| 16 | Dicadangkan | 8 | Dicadangkan. Jangan gunakan. |
| 24 | Token | 8 | Token untuk mengidentifikasi host. |
5.4.2.2 Cadangan B7 - B4
Dicadangkan. Jangan gunakan.
5.4.2.3 Alasan Penolakan
Tabel 5,4-8 FIRMWARE_UPDATE_OFFER - Tata Letak RR Respons Paket Informasi Penawaran
Bit byte Tolak Alasan dijelaskan dalam tabel ini.
Tabel 5.4-9 FIRMWARE_UPDATE_OFFER- Respons Perintah Penawaran - Kode RR
| Bit Offset | Bidang | Ukuran | Deskripsi |
|---|---|---|---|
| 0 | Kode RR | 8 | Nilai ini tergantung pada bidang Status. Untuk kemungkinan nilai Kode RR, lihat Tabel 5.4-10. |
| 8 | Dicadangkan | 24 | Dicadangkan. Jangan gunakan. |
Nilai yang mungkin untuk byte Kode RR dijelaskan dalam tabel ini.
Tabel 5.4-10 FIRMWARE_UPDATE_OFFER- Paket Perintah Penawaran - Nilai Kode RR
| Kode RR | Nama | Deskripsi |
|---|---|---|
| 0x00 | FIRMWARE_OFFER_REJECT_OLD_FW | Penawaran ditolak karena versi firmware yang ditawarkan lebih lama atau sama dengan firmware saat ini. |
| 0x01 | FIRMWARE_OFFER_REJECT_INV_COMPONENT | Penawaran ditolak karena firmware yang ditawarkan tidak berlaku untuk platform produk. Hal ini dapat disebabkan oleh ID komponen yang tidak didukung atau gambar yang ditawarkan tidak kompatibel dengan perangkat keras sistem. |
| 0x02 | FIRMWARE_UPDATE_OFFER SWAP_PENDING | Firmware komponen telah diperbarui namun pertukaran ke firmware baru tertunda. Tidak ada pemrosesan Pembaruan Firmware lebih lanjut yang dapat terjadi sampai pertukaran selesai, biasanya melalui reset. |
| 0x03 - 0x08 | (Dicadangkan) | Dicadangkan. Jangan gunakan. |
| 0x09 - 0xDF | (Dicadangkan) | Dicadangkan. Jangan gunakan. |
| 0xE0 — 0xFF | (Khusus Vendor) | Nilai-nilai ini digunakan oleh perancang protokol dan maknanya spesifik untuk vendor. |
5.4.2.4 Status
Tabel 5.4-11 FIRMWARE_UPDATE_OFFER - Tata Letak Status Respons Paket Perintah Penawaran
Bit byte Status dijelaskan dalam tabel ini.
Tabel 5.4-12 FIRMWARE_UPDATE_OFFER- Menawarkan Kode RR Respons Paket Perintah
| Bit Offset | Bidang | Ukuran | Deskripsi |
|---|---|---|---|
| 0 | Status | 8 | Bidang ini harus diatur ke FIRMWARE_UPDATE_OFFER_ACCEPT. Ini menunjukkan bahwa komponen telah memutuskan untuk menerima penawaran. |
| 8 | Dicadangkan. | 24 | Dicadangkan. Jangan gunakan. |
5,5 FIRMWARE_UPDATE_CONTENT
Host mengirimkan perintah ini ke firmware perangkat untuk menyediakan konten firmware (yaitu, gambar firmware). Seluruh file gambar tidak diharapkan pas dalam satu perintah. Host harus memecah gambar menjadi blok yang lebih kecil dan setiap perintah mengirimkan satu blok gambar pada satu waktu.
Dengan setiap perintah host menunjukkan informasi tambahan—baik itu blok pertama, blok terakhir, dan sebagainya, dari firmware. Komponen utama firmware perangkat menerima setiap blok gambar firmware yang masuk, menyimpannya ke dalam memorinya, dan harus merespons setiap perintah satu per satu.
Ketika komponen utama menerima blok terakhir, komponen memvalidasi seluruh gambar firmware (pemeriksaan CRC, validasi tanda tangan). Berdasarkan hasil pemeriksaan tersebut mengembalikan respons yang sesuai (kegagalan atau keberhasilan) untuk blok terakhir.
5.5.1 Perintah
Tabel 5,5-1 FIRMWARE_UPDATE_CONTENT Tata Letak Perintah
5.5.1.1 Header (B7 - B0)
Tabel 5,5-2 FIRMWARE_UPDATE_CONTENT Tata Letak Header Perintah
Bit Header FIRMWARE_UPDATE_CONTENT dijelaskan dalam tabel ini.
Tabel 5,5-3 FIRMWARE_UPDATE_CONTENT Header Bit
| Bit Offset | Bidang | Ukuran | Deskripsi |
|---|---|---|---|
| 0 | Bendera | 8 | Bidang ini menyediakan informasi tambahan tentang perintah . Nilai ini adalah masker bendera yang akan digunakan untuk transfer data. Nilai yang mungkin dijelaskan dalam Tabel 5,5-4. |
| 8 | Panjang Data | 8 | Panjang bidang Data yang berlaku menunjukkan jumlah byte yang akan ditulis. Mengingat ukuran perintah ini, nilai maksimum yang diizinkan untuk panjangnya adalah 52 byte. |
| 16 | Nomor Urut | 16 | Nilai ini dibuat oleh host dan unik untuk setiap paket konten yang dikeluarkan. Komponen harus mengembalikan nomor urut dalam responsnya terhadap permintaan ini. |
| 32 | Alamat Firmware | 32 | Alamat Little Endian (LSB First) untuk menulis data. Alamatnya berbasis 0. Firmware menggunakan ini sebagai offset untuk menentukan alamat sesuai kebutuhan saat menempatkan gambar dalam memori. |
Nilai yang mungkin untuk byte Bendera dijelaskan dalam tabel ini.
Tabel 5,5-4 FIRMWARE_UPDATE_OFFER- Paket Perintah Penawaran - Nilai Bendera
| Bendera | Nama | Deskripsi |
|---|---|---|
| 0x80 | FIRMWARE_UPDATE_FLAG_FIRST_BLOCK | Bendera ini menunjukkan bahwa ini adalah blok pertama dari gambar firmware. |
| 0x40 | FIRMWARE_UPDATE_FLAG_LAST_BLOCK | Bendera ini menunjukkan bahwa ini adalah blok terakhir dari gambar firmware dan bahwa gambar siap untuk divalidasi. Penting bahwa firmware saat ini pada komponen melakukan validasi pada seluruh gambar firmware yang diunduh setelah menulis blok ini ke memori non-volatil. |
5.5.1.2 Data
Tabel 5,5-5 FIRMWARE_UPDATE_CONTENT Tata Letak Data Perintah
Bit data FIRMWARE_UPDATE_CONTENT dijelaskan dalam tabel ini.
Tabel 5,5-6 FIRMWARE_UPDATE_CONTENT Command Data Bits
| Bit Offset | Bidang | Ukuran | Deskripsi |
|---|---|---|---|
| 64 | Data | Maksimal 52. | Array byte yang akan ditulis. Host biasanya mengirim blok 4 byte berdasarkan arsitektur produk. Setiap byte yang tidak digunakan pada akhirnya harus 0 padded. |
5.5.2 Respons
Tabel 5,5-7 FIRMWARE_UPDATE_CONTENT Tata Letak Respons Perintah
5.5.2.1 Nomor Urut
Tabel 5,5-8 FIRMWARE_UPDATE_CONTENT Respons - Nomor Urut
Bit respons FIRMWARE_UPDATE_CONTENT (3-0) dijelaskan dalam tabel ini.
Tabel 5,5-9 FIRMWARE_UPDATE_CONTENT - Perintah - Bit Respons
| Bit Offset | Bidang | Ukuran | Deskripsi |
|---|---|---|---|
| 0 | Nomor Urut | 16 | Bidang ini adalah nomor urut yang dikirim oleh host dalam permintaan. |
| 16 | Dicadangkan | 16 | Dicadangkan. Jangan gunakan. |
5.5.2.2 Status
Tabel 5,5-10 FIRMWARE_UPDATE_CONTENT Tata Letak Status Respons
Bit respons FIRMWARE_UPDATE_CONTENT (7-4) dijelaskan dalam tabel ini.
Tabel 5,5-11 FIRMWARE_UPDATE_OFFER - Respons - Bit Status
| Bit Offset | Bidang | Ukuran | Deskripsi |
|---|---|---|---|
| 0 | Status | 8 | Nilai ini menunjukkan kode status yang dikembalikan oleh komponen perangkat. Ini bukan bitwise dan bisa menjadi salah satu nilai yang dijelaskan dalam Tabel 5.5-12. |
| 8 | Dicadangkan | 24 | Dicadangkan. Jangan gunakan. |
Nilai yang mungkin untuk byte Status dijelaskan dalam tabel ini.
Tabel 5.5-12 FIRMWARE_UPDATE_OFFER- Respons - Nilai Kode Status
| Bendera | Nama | Deskripsi |
|---|---|---|
| 0x00 | FIRMWARE_UPDATE_SUCCESS | Permintaan berhasil diselesaikan. |
| 0x01 | FIRMWARE_UPDATE_ERROR_PREPARE | Komponen tidak siap untuk menerima konten firmware. Jika digunakan, kode ini biasanya digunakan sebagai respons terhadap blok pertama. Misalnya, hapus kesalahan pada flash. |
| 0x02 | FIRMWARE_UPDATE_ERROR_WRITE | Permintaan tidak dapat menulis byte. |
| 0x03 | FIRMWARE_UPDATE_ERROR_COMPLETE | Permintaan tidak dapat menyiapkan pertukaran sebagai respons terhadap FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x04 | FIRMWARE_UPDATE_ERROR_VERIFY | Verifikasi DWORD gagal, sebagai respons terhadap FIRMWARE_UPDATE_FLAG_VERIFY. |
| 0x05 | FIRMWARE_UPDATE_ERROR_CRC | CRC gambar firmware gagal sebagai respons terhadap FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x06 | FIRMWARE_UPDATE_ERROR_SIGNATURE | Verifikasi tanda tangan firmware gagal sebagai respons terhadap FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x07 | FIRMWARE_UPDATE_ERROR_VERSION | Verifikasi versi firmware gagal sebagai respons terhadap FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x08 | FIRMWARE_UPDATE_SWAP_PENDING | Firmware telah diperbarui dan pertukaran tertunda. Tidak ada perintah Pembaruan Firmware lebih lanjut yang dapat diterima sampai aksesori telah direset. |
| 0x09 | FIRMWARE_UPDATE_ERROR_INVALID_ADDR | Firmware telah mendeteksi alamat tujuan yang tidak valid dalam konten data pesan. |
| 0x0A | FIRMWARE_UPDATE_ERROR_NO_OFFER | Perintah FIRMWARE_UPDATE_OFFER diterima tanpa terlebih dahulu menerima penawaran pembaruan firmware yang valid dan diterima. |
| 0x0B | FIRMWARE_UPDATE_ERROR_INVALID | Kesalahan umum untuk Perintah FIRMWARE_UPDATE_OFFER, seperti Panjang Data yang berlaku tidak valid. |
5.5.2.3 Cadangan B8 - B11
Dicadangkan. Jangan gunakan.
5.5.2.4 Cadangan B12 - B15
Dicadangkan. Jangan gunakan.
6 Lampiran 1: Contoh Urutan Perintah Pemrograman Pembaruan Firmware
6.1 Contoh 1
Pertimbangkan firmware perangkat berikut:
Komponen Utama - ID Komponen 1 - Firmware versi saat ini 7.0.1
Subkomponen - ID Komponen 2 - Firmware versi saat ini 12.4.54
Subkomponen - ID Komponen 3 - Firmware versi saat ini 4.4.2
Subkomponen - ID Komponen 4 - Firmware versi saat ini 23.32.9
Host memiliki tiga gambar firmware ini:
ID Komponen 1 - Firmware versi 7.1.3
ID Komponen 2 - Firmware versi 12.4.54
ID Komponen 3 - Firmware versi 4.5.0
Urutannya adalah:
Penawaran host: ID Komponen 1 - Firmware versi 7.1.3
Komponen utama menerima penawaran
Host mengirimkan gambar firmware
Komponen utama menerima firmware, memvalidasinya
Penawaran host: ID Komponen 2 - Firmware versi 12.4.54
Komponen utama menolak penawaran
Penawaran host: ID Komponen 3 - Firmware versi 4.5.0
Komponen utama menerima penawaran
Host mengirimkan gambar firmware
Komponen utama menerima firmware, memvalidasinya
Karena semua penawaran tidak ditolak, host memutar ulang semua penawaran:
Penawaran host: ID Komponen 1 - Firmware versi 7.1.3
Penolakan komponen
Penawaran host: ID Komponen 2 - Firmware versi 12.4.54
Penolakan komponen
Penawaran host: ID Komponen 3 - Firmware versi 4.5.0
Penolakan komponen
6.2 Contoh 2
Pertimbangkan firmware perangkat berikut:
Komponen Utama - ID Komponen 1 - Firmware versi 7.0.1 saat ini
Subkomponen - ID Komponen 2 - Firmware versi 12.4.54 saat ini
Subkomponen - ID Komponen 3 - Firmware versi 7.4.2 saat ini
Subkomponen - ID Komponen 4 - Firmware versi saat ini 23.32.9
Host memiliki tiga gambar firmware ini:
ID Komponen 1 - Firmware versi 8.0.0
ID Komponen 2 - Firmware versi 12.4.54
ID Komponen 3 - Firmware versi 9.0.0
Selain itu, implementasi mengharuskan versi firmware subkomponen tidak boleh kurang dari versi firmware yang berjalan pada komponen utama. Host tidak mengetahui persyaratan itu dan siap untuk komponen utama untuk memastikan aturan ini.
Urutannya adalah:
Penawaran host: ID Komponen 1 - Firmware versi 8.0.0
Komponen utama menolak (karena ID komponen 3 belum diperbarui)
Penawaran host: ID Komponen 2 - Firmware versi 12.4.54
Penolakan komponen utama
Penawaran host: ID Komponen 3 - Firmware versi 9.0.0
Komponen utama menerima penawaran
Host mengirimkan gambar firmware
Komponen utama menerima firmware, memvalidasinya
Karena semua penawaran tidak ditolak, host memutar ulang semua penawaran
Penawaran host: ID Komponen 1 - Firmware versi 8.0.0
Komponen utama menerima penawaran
Host mengirimkan gambar firmware
Komponen utama menerima firmware, memvalidasinya
Penawaran host: ID Komponen 2 - Firmware versi 12.4.54
Penolakan komponen utama
Penawaran host: ID Komponen 3 - Firmware versi 9.0.0
Penolakan komponen utama
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk