Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
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 untuk menerimanya.
Nota
CFU tersedia di Windows 10, versi 2004 (Pembaruan Windows 10 Mei 2020) dan versi yang lebih baru.
Isi
- Pengenalan
1 - 1.1 Glosarium
-
1.2 Cakupan
- 1.2.1 Tujuan
- 1.2.2 Bukan Tujuan
- 2 Arsitektur Perangkat Keras yang Didukung
- 3 Prasyarat Protokol
- Gambaran Umum Protokol CFU
4 -
4.1 Urutan Perintah Pemrograman Pembaruan Firmware
- 4.1.1 Status: Pemberitahuan Inisialisasi Host
- 4.1.2 Status: OFFER_INFO_START_OFFER_LIST Pemberitahuan
- 4.1.3 Status: Kirim perintah FIRMWARE_UPDATE_OFFER
- 4.1.4 State: Kirim Firmware
- 4.1.5 Status Keputusan: Apakah ada lebih banyak penawaran
- Status 4.1.6: Pemberitahuan OFFER_INFO_END_OFFER_LIST
- 4.1.7 Status Keputusan: Putar Ulang Daftar penawaran
- 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 Responsenya - Tata Letak Header
Tabel 5.1-3 GET_FIRMWARE_VERSION Respons - Bit Header
Tabel 5.1-4 GET_FIRMWARE_VERSION Tanggapan - Versi Komponen dan Tata Letak Properti
Tabel 5.1-5 GET_FIRMWARE_VERSION Respons - Versi Komponen dan Properti Bit
Tabel 5.2-1 FIRMWARE_UPDATE_OFFER Tata Letak Perintah
Tabel 5.2-2 Perintah FIRMWARE_UPDATE_OFFER - Tata Letak Informasi Komponen
Tabel Perintah FIRMWARE_UPDATE_OFFER 5.2-3 - Bit Informasi Komponen
Tabel 5.2-4 Perintah FIRMWARE_UPDATE_OFFER - Tata Letak Versi Firmware
Tabel 5.2-5 Perintah FIRMWARE_UPDATE_OFFER - Bit Versi Firmware
Tabel 5.2-6 Perintah FIRMWARE_UPDATE_OFFER - Tata Letak Spesifik 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 - Bit Alasan Penolakan
Tabel 5.2-13 Nilai Kode RR untuk Respons FIRMWARE_UPDATE_OFFER
Tabel 5.2-14 Tata Letak Status Respons FIRMWARE_UPDATE_OFFER
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 - Tanggapan 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 Diperpanjang
Tabel 5.4-2 FIRMWARE_UPDATE_OFFER - Paket Perintah Diperpanjang - Perintah - Tata Letak Komponen
Tabel 5.4-3 FIRMWARE_UPDATE_OFFER - Perintah Diperpanjang - 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 Diperpanjang
Tabel 5.4-6 FIRMWARE_UPDATE_OFFER - Paket Respons Perintah Menawarkan - Tata Letak Token
Tabel 5.4-7 FIRMWARE_UPDATE_OFFER - Tanggapan 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 - Tanggapan Kode RR untuk Paket Perintah
Tabel 5.5-1 Tata Letak Perintah FIRMWARE_UPDATE_CONTENT
Tabel 5.5-2 Tata Letak Header Perintah FIRMWARE_UPDATE_CONTENT
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 Tata Letak Respons Perintah FIRMWARE_UPDATE_CONTENT
Tabel 5.5-8 FIRMWARE_UPDATE_CONTENT Tanggapan - Nomor Urutan
Tabel 5.5-9 FIRMWARE_UPDATE_CONTENT - Komando - Respons Bit
Tabel 5.5-10 FIRMWARE_UPDATE_CONTENT Tata Letak Respons Status
Tabel 5,5-11 FIRMWARE_UPDATE_OFFER - Respons - Bit Status
Tabel 5.5-12 FIRMWARE_UPDATE_OFFER - Tanggapan - Nilai Kode Status
1 Pengantar
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—yang umum dan memiliki dukungan bawaan Windows melalui berbagai bus interkoneksi seperti USB dan I2C. Oleh karena itu, solusi perangkat lunak (driver) yang sama dapat dimanfaat untuk memperbarui firmware untuk semua komponen.
Nota
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 waktu tertentu yang memiliki dampak minimal pada pengguna.
Spesifikasi ini mendukung konfigurasi di mana komponen yang menerima firmware mungkin memiliki subkomponen, yang memerlukan gambar firmware terpisah.
Nota
Proses komponen menyerahkan firmware ke sub-komponen berada di luar cakupan spesifikasi ini.
Spesifikasi ini 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 ketergantungan antara jenis dan/atau versi firmware dengan jenis/versi perangkat keras yang mendasari diterapkannya firmware baru. Penawaran juga bertindak sebagai mekanisme pengoptimalan karena gambar firmware dikirim ke komponen hanya jika mampu /siap menerimanya.
1.1 Glosarium
| Istilah | Deskripsi |
|---|---|
| ID Komponen | Di perangkat dengan beberapa komponen, ID komponen secara unik mengidentifikasi setiap komponen. |
| CRC | Pemeriksaan Redundansi Siklik Algoritma hashing non-kriptografi yang digunakan untuk menghasilkan citra atau sidik jari dari 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. |
| Alat | 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. |
| Pengemudi | 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. |
| Segmen | Gambar firmware untuk komponen dapat disegmentasi ke dalam segmen yang lebih kecil. Setiap segmen adalah gambar firmware kecil. |
| Segmen ID | Jika firmware komponen disegmentasi ke dalam segmen yang lebih kecil, ID segmen adalah pengidentifikasi unik untuk segmen tersebut. |
| Tanda tangan | Kriptografi berarti untuk 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. |
| perhatian dan kasih sayang | HID Koleksi Tingkat Atas. |
| Tanda | 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 Tujuan
Solusi agnostik bus diperlukan untuk menghindari protokol baru untuk setiap jenis bus. HID tersebar luas 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 menyegmentasikan gambar firmware besar ke dalam segmen yang lebih kecil untuk mempermudah komponen menerima gambar firmware.
1.2.2 Bukan Tujuan
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 saat ini yang berjalan pada komponen harus memvalidasi firmware yang sedang 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 unit tunggal. 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 diimplementasikan untuk memanfaatkan protokol ini:
Penggunaan gambar atom
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 yang digunakan untuk mengirimkan citra firmware memiliki mekanisme koreksi kesalahan dan mekanisme coba ulang 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, sehingga firmwarenya saat ini tidak ditimpa.
Autentikasi dan integritas
Implementor memutuskan faktor-faktor yang merupakan gambar firmware autentik. Disarankan agar firmware komponen saat ini setidaknya harus memvalidasi CRC 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 dari 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 bergantung pada implementasi.
Kerahasiaan
Fakultatif. 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 pembatalan diberlakukan oleh komponen utama dan spesifik pada implementasi. Firmware pada komponen saat ini memvalidasi citra firmware yang masuk terhadap kebijakan internal seperti nomor versi harus lebih baru, atau jenis rilis tidak dapat diubah dari rilis ke debug, dan sebagainya. Protokol memungkinkan sistem pesan untuk menunjukkan bahwa pembaruan diterima meskipun melanggar kebijakan pembatalan perubahan.
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 berulang 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 mengirimkan file.
Untuk mendukung kasus di mana pesanan 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 Inisialisasi 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 tak terduga. 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 citra firmware, agar firmware saat ini pada komponen dapat memutuskan apakah akan menerima, menunggu, mengabaikan, atau menolak penawaran.
Penawaran mungkin untuk komponen utama atau subkomponen. Jika komponen dapat menerima penawaran, komponen menyiapkan dirinya sendiri 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 masih bisa menolak gambar firmware setelah diunduh karena kegagalan dalam pemeriksaan integritas dan/atau putar kembali terhadap gambar yang sebenarnya diterima. Komponen harus memeriksa setiap properti citra 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 sedang sibuk dan komponen utama tidak dapat menerima tawaran ini atau yang berikutnya pada saat ini, maka firmware itu mengirimkan respons sibuk dengan status FIRMWARE_UPDATE_OFFER_BUSY.
Jika firmware saat ini tertarik dengan penawaran ini, namun tidak dapat menerimanya (misalnya, karena ada dependensi pada pembaruan yang hilang untuk subkomponen), firmware tersebut merespons dengan FIRMWARE_UPDATE_OFFER_SKIP yang mengindikasikan bahwa ia tertarik pada firmware ini, tetapi 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, ini adalah versi yang lebih lama), maka firmware tersebut 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: Mengirim Firmware
Dalam keadaan ini, host mulai mengirim citra firmware ke komponen utama, yang sebelumnya telah menerima penawaran.
Karena konten gambar firmware cenderung melampaui 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 oleh host, host mengatur bendera FIRMWARE_UPDATE_FLAG_FIRST_BLOCK, yang memberi tahu perangkat bahwa ini adalah paket pertama dari citra firmware. Jika perangkat belum menyiapkan dirinya sendiri untuk menerima firmware, perangkat dapat melakukannya saat ini.
Untuk paket terakhir, host mengirim dan mengatur bendera FIRMWARE_UPDATE_FLAG_LAST_BLOCK.
Setelah firmware saat ini pada perangkat telah menulis payload firmware parsial yang disertakan dalam perintah ini, firmware harus melakukan pemeriksaan validasi dan autentikasi pada citra 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 dari gambar yang 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 menyiapkan 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 melakukan pengaturan pertukaran pada reset berikutnya dan harus menunjukkan respons kegagalan kepada host.
4.1.5 Status Keputusan: Apakah ada lebih banyak penawaran
Dalam kondisi ini, host menentukan apakah ada lebih banyak penawaran untuk dikirim ke perangkat.
4.1.6 Status: OFFER_INFO_END_OFFER_LIST Pemberitahuan
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: Putar Ulang Daftar Penawaran
Host menentukan apakah perlu mengirim ulang semua penawaran. Kasus tersebut 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 lain yang dapat mengakibatkan keputusan untuk memutar ulang daftar penawaran.
4.1.8 Status: Perangkat Sibuk
Status ini menyiratkan bahwa perangkat memberikan respons sibuk untuk penawaran.
Host mengirimkan perintah OFFER_NOTIFY_ON_READY, di mana perangkat tersebut tidak memberikan respons penerimaan hingga perangkat dalam keadaan bebas.
Format Paket Protokol 5 CFU
Protokol CFU diimplementasikan sebagai sekumpulan perintah dan respons. Protokol ini 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, hingga 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, tuan rumah tidak perlu menahan tawaran berdasarkan respons yang diterima dari komponen utama tentang informasi versi yang diminta. Informasi ini dibuat dapat ditemukan untuk pengelogan atau tujuan lain.
5.1 MENDAPATKAN_VERSI_PERANGKAT_LUNAK
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
Respons 
Header untuk respons menyediakan informasi berikut.
Tabel 5.1-3 GET_FIRMWARE_VERSION Respons - Header Bit
| Pengimbangan Bit | Ladang | 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 cadangan. Pengirim harus mengatur ini ke 0. Penerima harus mengabaikan nilai ini. |
| 24 | Versi Protokol | 4 | Bit revisi pembaruan firmware mewakili revisi protokol pembaruan FW yang saat ini digunakan dalam lapisan transport. Untuk antarmuka yang ditentukan di sini, Revisi Pembaruan FW harus 0010b. |
| 28 | Rsvd | 3 | Bidang cadangan. Pengirim harus mengatur ini ke 0. Penerima harus mengabaikan nilai ini. |
| 31 | E | 1 | Bendera ekstensi adalah kait protokol masa depan untuk memungkinkan komponen tambahan dilaporkan. |
5.1.2.2 Versi Komponen dan Properti
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 Tanggapan - Versi Komponen dan Tata Letak Properti
Respons 
Setiap informasi spesifik komponen dijelaskan dalam dua DWORD sebagai berikut:
Tabel 5.1-5 GET_FIRMWARE_VERSION Respons - Versi Komponen dan Properti Bytes
| Pengimbangan Bit | Ladang | 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 | Fakultatif. 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 ada. Bidang ini Wajib Bersyarat - dukungan bersifat opsional, namun tidak boleh digunakan untuk tujuan lain. |
| 34 | Dipesan | 2 | Bidang cadangan. Pengirim harus mengatur ini ke 0. Penerima harus mengabaikan nilai ini. |
| 36 | Pemasok Spesifik | 4 | Bidang khusus vendor yang dapat digunakan dengan cara 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 | Pemasok Spesifik | 16 | Bidang khusus vendor yang dapat digunakan dengan cara spesifik implementasi. |
5.1.3 Pemetaan ke HID
Ini diimplementasikan sebagai permintaan Fitur Get HID dengan ukuran respons 60 Byte, selain ID Laporan. Panjang laporan fitur mengakomodasi seluruh respons GET_FIRMWARE_VERSION. Tidak ada data yang terkait dengan permintaan Get Feature dari pihak host.
5.2 PENAWARAN_PEMBARUAN_FIRMWARE
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 FIRMWARE_UPDATE_OFFER Tata Letak Perintah
Tata letak perintah FIRMWARE_UPDATE_OFFER 
5.2.1.1 Informasi Komponen
Tabel 5.2-2 FIRMWARE_UPDATE_OFFER Command - Tata Letak Informasi Komponen
Perintah 
Bit-bit dari byte Informasi Komponen dijelaskan dalam tabel ini.
Tabel 5.2-3 perintah FIRMWARE_UPDATE_OFFER - Bit Informasi Komponen
| Pengimbangan Bit | Ladang | Ukuran | Deskripsi |
|---|---|---|---|
| 0 | Nomor Segmen | 8 | Bidang ini digunakan jika firmware untuk komponen disegmentasi ke dalam 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 i-th dari gambar lengkap. Penawaran terpisah dapat dikirimkan ke komponen utama yang memuat segmen ke-i+1 dari gambar, dan seterusnya. |
| 8 | Dipesan | 6 | Bidang cadangan. Pengirim harus mengatur ini ke 0. Penerima harus mengabaikan nilai ini. |
| 14 | Saya | 1 | Reset Langsung 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) - Penanda ini ditujukan untuk citra firmware pra-rilis atau debug. Ini menunjukkan kepada komponen agar tidak menolak firmware berdasarkan versinya. - Bendera ini ditujukan untuk fase pengembangan. Ini dapat digunakan untuk 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 tempat penawaran 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 | Tanda | 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 tergantung pada implementasi. Misalnya, satu nilai dapat digunakan untuk driver dan nilai lainnya untuk aplikasi. Ini memungkinkan firmware perangkat saat ini untuk memperhitungkan potensi beberapa pengirim perintah CFU. Salah satu kemungkinan implementasinya 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
Perintah 
Format untuk versi firmware tidak diamanatkan oleh spesifikasi ini, namun berikut ini adalah pedoman yang direkomendasikan.
Tabel 5.2-5 Perintah FIRMWARE_UPDATE_OFFER - Bits untuk Versi Firmware
| Pengimbangan Bit | Ladang | 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 citra 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 Lain-lain 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
Perintah 
Bit-bit dari byte Khusus Vendor dijelaskan dalam tabel ini.
Tabel 5.2-7 Perintah FIRMWARE_UPDATE_OFFER - Versi Lain-lain dan Protokol
| Pengimbangan Bit | Ladang | Ukuran | Deskripsi |
|---|---|---|---|
| 0 | Versi Protokol | 4 | Bidang ini harus diatur ke 0010b yang menunjukkan bahwa host/penawaran sesuai dengan versi 2 protokol CFU. |
| 4 | Dipesan | 4 | Direservasi. Jangan gunakan. |
| 8 | Dipesan | 8 | Direservasi. Jangan gunakan. |
| 16 | Pemasok Spesifik | 16 | Bidang ini dapat digunakan untuk mengodekan informasi kustom apa pun dalam penawaran yang khusus untuk implementasi vendor. |
5.2.2 Respons
Paket Respon FIRMWARE_UPDATE_OFFER didefinisikan sebagai berikut.
Tabel 5.2-8 Tata Letak Token Respons FIRMWARE_UPDATE_OFFER
5.2.2.1 Token
Tabel 5.2-9 FIRMWARE_UPDATE_OFFER Respons - Tata Letak Token
Bit-bit dari byte Token dijelaskan dalam tabel ini.
Tabel 5.2-10 FIRMWARE_UPDATE_OFFER Respons - Bit Token
| Pengimbangan Bit | Ladang | Ukuran | Deskripsi |
|---|---|---|---|
| 0 | Dipesan | 8 | Direservasi. Jangan gunakan. |
| 8 | Dipesan | 8 | Direservasi. Jangan gunakan. |
| 16 | Dipesan | 8 | Direservasi. Jangan gunakan. |
| 24 | Tanda | 8 | Token untuk mengidentifikasi host. |
5.2.2.2 Dicadangkan (B7 - B4)
Direservasi. Jangan gunakan.
5.2.2.3 Alasan Penolakan (RR)
Tabel 5.2-11 FIRMWARE_UPDATE_OFFER Respons - Tata Letak Alasan Penolakan
Respon 
Tabel 5.2-12 Respons FIRMWARE_UPDATE_OFFER - Bit Alasan Penolakan
Bit-bit pada byte Alasan Penolakan dijelaskan dalam tabel ini.
| Pengimbangan Bit | Ladang | 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 | Dipesan | 24 | Direservasi. Jangan gunakan. |
Tabel 5.2-13 FIRMWARE_UPDATE_OFFER Nilai Kode Tanggapan RR
Nilai yang mungkin untuk byte Kode RR dijelaskan pada 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 | PENAWARAN_FIRMWARE_TOLAK_KOMPONEN_INV | Penawaran ditolak karena firmware yang ditawarkan tidak berlaku untuk platform produk. Ini dapat disebabkan oleh ID komponen yang tidak didukung atau gambar yang ditawarkan tidak kompatibel dengan perangkat keras sistem. |
| 0x02 | Penawaran Pembaruan Firmware Sedang Ditukar | 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) | Direservasi. Jangan gunakan. |
| 0x09 - 0xDF | (Dicadangkan) | Direservasi. Jangan gunakan. |
| 0xE0 - 0xFF | (Vendor Spesifik) | Nilai-nilai ini digunakan oleh perancang protokol dan maknanya spesifik untuk vendor. |
5.2.2.4 Status
Tabel 5.2-14 FIRMWARE_UPDATE_OFFER Pengaturan Status Respons
Tata Letak Status Respons FIRMWARE_UPDATE_OFFER 
Deskripsi bit dari byte Status terdapat pada tabel ini.
Tabel 5.2-15 Respons FIRMWARE_UPDATE_OFFER - Bit Status
| Pengimbangan Bit | Ladang | Ukuran | Deskripsi |
|---|---|---|---|
| 0 | Keadaan | 8 | Nilai ini menunjukkan keputusan komponen untuk menerima, menunggu, melewati, atau menolak penawaran. Komponen menyediakan alasan dalam nilai bidang Kode RR. Untuk pemetaan Status ke Kode RR, lihat Tabel 5.2-16. |
| 8 | Dipesan | 24 | Direservasi. Jangan gunakan. |
Nilai yang mungkin untuk byte Status dijelaskan dalam tabel ini.
Tabel 5.2-16 Nilai Status Respons dari FIRMWARE_UPDATE_OFFER
| Keadaan | Nama | Deskripsi |
|---|---|---|
| 0x00 | LEWATKAN_TAWARAN_PEMBARUAN_FIRMWARE | Komponen telah memutuskan untuk mengabaikan penawaran. Penyedia harus menawarkannya lagi nanti. |
| 0x01 | TERIMA_TAWARAN_PEMBARUAN_FIRMWARE | Komponen telah memutuskan untuk menerima tawaran. |
| 0x02 | PENOLAKAN_PENAWARAN_PEMBARUAN_FIRMWARE | Komponen telah memutuskan untuk menolak penawaran. |
| 0x03 | Tawaran Pembaruan Firmware Sedang Sibuk | Perangkat sibuk, dan host harus menunggu sampai perangkat siap. |
| 0x04 | PERINTAH_PENAWARAN_PEMBARUAN_FIRMWARE | Digunakan saat ID Komponen dalam byte Informasi Komponen (lihat Informasi Komponen 5.1.2.1.1) diatur ke 0xFE. Untuk Kode Komando yang ditetapkan ke permintaan OFFER_NOTIFY_ON_READY, mengindikasikan aksesori siap untuk menerima penawaran tambahan. |
| 0xFF | FIRMWARE_UPDATE_CMD_TIDAK_DIDUKUNG | Permintaan penawaran tidak dikenali. |
5.2.3 Pemetaan ke Protokol HID
Pesan disampaikan ke komponen melalui mekanisme Laporan Output HID , dengan menggunakan ID Laporan Utilitas HID yang khusus untuk Pembaruan Firmware. TLC Utilitas HID untuk digunakan yang dijelaskan dalam Lampiran.
5.3 PENAWARAN_PEMBARUAN_FIRMWARE - Informasi
Jika ID Komponen dalam bit Informasi Komponen (lihat Informasi Komponen) diatur ke 0xFF, maka bit (15 bit) didefinisikan ulang untuk menunjukkan hanya Informasi Penawaran, dari Host ke komponen. Mekanisme ini memungkinkan ekstensibilitas dan cara bagi Host untuk memberikan informasi spesifik kepada perangkat seperti Daftar Mulai Penawaran, 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-bit dari byte Komponen dijelaskan dalam tabel ini.
Tabel 5.3-3 FIRMWARE_UPDATE_OFFER - Perintah Informasi - Bit Komponen
| Pengimbangan Bit | Ladang | 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 | Direservasi. | 8 | Direservasi. Jangan gunakan. |
| 16 | ID Komponen | 8 | Atur ke 0xFF. |
| 24 | Tanda | 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
| Keadaan | Nama | Deskripsi |
|---|---|---|
| 0x00 | INFO_PENAWARAN_MULAI_SELURUH_TRANSAKSI | 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 Aksesori memiliki aturan unduhan yang terkait untuk memastikan satu subkomponen diperbarui sebelum subkomponen lainnya dalam sistem. |
| 0x02 | OFFER_INFO_END_OFFER_LIST | Menunjukkan akhir daftar Penawaran dari host. |
5.3.1.2 Cadangan B7 - B4
Direservasi. Jangan gunakan.
5.3.1.3 Cadangan B11 - B8
Direservasi. Jangan gunakan.
5.3.1.4 Cadangan B15 - B12
Direservasi. 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-bit dari byte Token dijelaskan dalam tabel ini.
Tabel 5.3-7 FIRMWARE_UPDATE_OFFER - Respons Informasi - Bit Token
| Pengimbangan Bit | Ladang | Ukuran | Deskripsi |
|---|---|---|---|
| 0 | Dipesan | 8 | Direservasi. Jangan gunakan. |
| 8 | Dipesan | 8 | Direservasi. Jangan gunakan. |
| 16 | Dipesan | 8 | Direservasi. Jangan gunakan. |
| 24 | Tanda | 8 | Token untuk mengidentifikasi host |
5.3.2.2 Cadangan B7 - B4
Direservasi. Jangan gunakan.
5.3.2.3 Alasan Penolakan (RR)
Tabel 5.3-8 FIRMWARE_UPDATE_OFFER - Tanggapan Informasi - Tata Letak Kode RR
Bit-bit pada byte Alasan Penolakan dijelaskan dalam tabel ini.
Tabel 5.3-9 FIRMWARE_UPDATE_OFFER - Tanggapan Informasi Penawaran - Bit Kode RR
| Pengimbangan Bit | Ladang | 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 | Dipesan | 24 | Direservasi. Jangan gunakan. |
Nilai yang mungkin untuk byte Kode RR dijelaskan pada 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 | PENAWARAN_FIRMWARE_TOLAK_KOMPONEN_INV | Penawaran ditolak karena firmware yang ditawarkan tidak berlaku untuk platform produk. Ini dapat disebabkan oleh ID komponen yang tidak didukung atau gambar yang ditawarkan tidak kompatibel dengan perangkat keras sistem. |
| 0x02 | Penawaran Pembaruan Firmware Sedang Ditukar | 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) | Direservasi. Jangan gunakan. |
| 0x09 - 0xDF | (Dicadangkan) | Direservasi. Jangan gunakan. |
| 0xE0 — 0xFF | (Vendor Spesifik) | 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
Deskripsi bit dari byte Status terdapat pada tabel ini.
Tabel 5.3-12 FIRMWARE_UPDATE_OFFER - Informasi Penawaran - Bit Status Respons
| Pengimbangan Bit | Ladang | Ukuran | Deskripsi |
|---|---|---|---|
| 0 | Keadaan | 8 | Bidang ini harus diatur ke FIRMWARE_UPDATE_OFFER_ACCEPT. Ini menunjukkan bahwa komponen telah memutuskan untuk menerima penawaran. |
| 8 | Direservasi. | 24 | Direservasi. Jangan gunakan. |
5.4 Penawaran_Pembaruan_Firmware - 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 spesifik kepada perangkat. Paket Perintah Penawaran dikembalikan ketika komponen siap untuk memberikan respons 'Diterima'.
5.4.1 Perintah
Jika Byte ID Komponen di Informasi Komponen diatur ke 0xFE, maka empat DWORD tersebut didefinisikan ulang sebagai berikut:
Tabel 5,4-1 FIRMWARE_UPDATE_OFFER - Tata Letak Perintah Diperpanjang
5.4.1.1 Komponen
Tabel 5.4-2 FIRMWARE_UPDATE_OFFER - Paket Perintah Diperpanjang - Perintah - Tata Letak Komponen
Bit-bit dari byte Komponen dijelaskan dalam tabel ini.
Tabel 5,4-3 FIRMWARE_UPDATE_OFFER - Perintah Diperpanjang - Bit Komponen
| Pengimbangan Bit | Ladang | 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 | Direservasi. | 8 | Direservasi. Jangan gunakan. |
| 16 | ID Komponen | 8 | Atur ke 0xFE. |
| 24 | Tanda | 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
| Keadaan | Nama | Deskripsi |
|---|---|---|
| 0x01 | NOTIFIKASI_TAWARAN_SIAP | Dikirim oleh host jika penawaran sebelumnya ditolak oleh komponen. |
| 0x02 - 0xFF | Dipesan | Dipesan |
5.4.1.2 Cadangan B7 - B4
Direservasi. Jangan gunakan.
5.4.1.3 Cadangan B11 - B8
Direservasi. Jangan gunakan.
5.4.1.4 Cadangan B15 - B12
Direservasi. Jangan gunakan.
5.4.2 Respons
Respons dari perintah FIRMWARE_UPDATE_OFFER - Penawaran dari perangkat mungkin tidak langsung diterima. Respons didefinisikan sebagai berikut.
Tabel 5,4-5 FIRMWARE_UPDATE_OFFER - Tata Letak Respons Paket Perintah Diperpanjang
5.4.2.1 Token
Tabel 5.4-6 FIRMWARE_UPDATE_OFFER- Menawarkan Respons Paket Perintah - Tata Letak Token
Bit-bit dari byte Token dijelaskan dalam tabel ini.
Tabel 5.4-7 FIRMWARE_UPDATE_OFFER - Respons Perintah Penawaran - Bit Token
| Pengimbangan Bit | Ladang | Ukuran | Deskripsi |
|---|---|---|---|
| 0 | Dipesan | 8 | Direservasi. Jangan gunakan. |
| 8 | Dipesan | 8 | Direservasi. Jangan gunakan. |
| 16 | Dipesan | 8 | Direservasi. Jangan gunakan. |
| 24 | Tanda | 8 | Token untuk mengidentifikasi host. |
5.4.2.2 Cadangan B7 - B4
Direservasi. Jangan gunakan.
5.4.2.3 Alasan Penolakan
Tabel 5.4-8 FIRMWARE_UPDATE_OFFER - Susunan Respon RR Paket Informasi Penawaran
Bit-bit pada byte Alasan Penolakan dijelaskan dalam tabel ini.
Tabel 5.4-9 FIRMWARE_UPDATE_OFFER- Respons Perintah Penawaran - Kode RR
| Pengimbangan Bit | Ladang | Ukuran | Deskripsi |
|---|---|---|---|
| 0 | Kode RR | 8 | Nilai ini tergantung pada bidang Status. Untuk kemungkinan nilai Kode RR, lihat Tabel 5.4-10. |
| 8 | Dipesan | 24 | Direservasi. Jangan gunakan. |
Nilai yang mungkin untuk byte Kode RR dijelaskan pada 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 | PENAWARAN_FIRMWARE_TOLAK_KOMPONEN_INV | Penawaran ditolak karena firmware yang ditawarkan tidak berlaku untuk platform produk. Ini dapat disebabkan oleh ID komponen yang tidak didukung atau gambar yang ditawarkan tidak kompatibel dengan perangkat keras sistem. |
| 0x02 | Penawaran Pembaruan Firmware Sedang Ditukar | 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) | Direservasi. Jangan gunakan. |
| 0x09 - 0xDF | (Dicadangkan) | Direservasi. Jangan gunakan. |
| 0xE0 — 0xFF | (Vendor Spesifik) | 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
Deskripsi bit dari byte Status terdapat pada tabel ini.
Tabel 5.4-12 FIRMWARE_UPDATE_OFFER- Paket Perintah Penawaran Respons Kode RR
| Pengimbangan Bit | Ladang | Ukuran | Deskripsi |
|---|---|---|---|
| 0 | Keadaan | 8 | Bidang ini harus diatur ke FIRMWARE_UPDATE_OFFER_ACCEPT. Ini menunjukkan bahwa komponen telah memutuskan untuk menerima penawaran. |
| 8 | Direservasi. | 24 | Direservasi. Jangan gunakan. |
5,5 KONTEN PEMBARUAN FIRMWARE
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 mengirim satu blok gambar sekaligus.
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 menanggapi 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
tata letak perintah 
5.5.1.1 Header (B7 - B0)
Tabel 5.5-2 FIRMWARE_UPDATE_CONTENT Tata Letak Header Perintah
Dijelaskan dalam tabel ini adalah bit dari Header FIRMWARE_UPDATE_CONTENT.
Tabel 5,5-3 FIRMWARE_UPDATE_CONTENT Header Bit
| Pengimbangan Bit | Ladang | Ukuran | Deskripsi |
|---|---|---|---|
| 0 | Bendera | 8 | Bidang ini menyediakan informasi tambahan tentang perintah . Nilai ini adalah masker bendera yang 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 (penanda pembaruan firmware blok pertama) | 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
| Pengimbangan Bit | Ladang | 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 di akhir harus diisi dengan nol. |
5.5.2 Tanggapan
Tabel 5,5-7 FIRMWARE_UPDATE_CONTENT Tata Letak Respons Perintah
5.5.2.1 Nomor Urut
Tabel 5.5-8 FIRMWARE_UPDATE_CONTENT Respon - Nomor Urut
Bit-bit dari Respons FIRMWARE_UPDATE_CONTENT (3-0) dijelaskan dalam tabel ini.
Tabel 5,5-9 FIRMWARE_UPDATE_CONTENT - Perintah - Bit Respons
| Pengimbangan Bit | Ladang | Ukuran | Deskripsi |
|---|---|---|---|
| 0 | Nomor Urut | 16 | Bidang ini adalah nomor urut yang dikirim oleh host dalam permintaan. |
| 16 | Dipesan | 16 | Direservasi. Jangan gunakan. |
5.5.2.2 Status
Tabel 5,5-10 FIRMWARE_UPDATE_CONTENT Tata Letak Status Respons
Bit dari Respons FIRMWARE_UPDATE_CONTENT (7-4) dijelaskan dalam tabel ini.
Tabel 5.5-11 FIRMWARE_UPDATE_OFFER - Tanggapan - Status Bit
| Pengimbangan Bit | Ladang | Ukuran | Deskripsi |
|---|---|---|---|
| 0 | Keadaan | 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 | Dipesan | 24 | Direservasi. 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 | PEMBARUAN_FIRMWARE_BERHASIL | Permintaan berhasil diselesaikan. |
| 0x01 | KESALAHAN_PEMBARUAN_FIRMWARE_PERSIAPAN | Komponen tidak disiapkan untuk menerima konten firmware. Jika digunakan, kode ini biasanya digunakan sebagai respons terhadap blok pertama. Misalnya, hapus kesalahan pada flash. |
| 0x02 | Kesalahan Pembaruan Firmware: Gagal Menulis | Permintaan tidak dapat menulis byte. |
| 0x03 | KESALAHAN_PEMBARUAN_FIRMWARE_SELESAI | Permintaan tidak dapat menyiapkan pertukaran sebagai respons terhadap FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x04 | Kesalahan_Pembaruan_Firmware_Verifikasi | Verifikasi DWORD gagal, sebagai respons terhadap FIRMWARE_UPDATE_FLAG_VERIFY. |
| 0x05 | Kesalahan Pembaruan Firmware CRC | CRC citra firmware gagal sebagai respons terhadap FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x06 | Tanda Kesalahan Pembaruan Firmware | Verifikasi tanda tangan firmware gagal sebagai respons terhadap FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x07 | KESALAHAN_PEMBARUAN_PERANGKAT_LUNAK_VERSI | Verifikasi versi firmware gagal sebagai respons terhadap FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x08 | PEMBARUAN_FIRMWARE_PERTUKARAN_TERTUNDA | Firmware telah diperbarui dan pertukaran tertunda. Tidak ada perintah Pembaruan Firmware lebih lanjut yang dapat diterima sampai aksesori telah diatur ulang. |
| 0x09 | KESAALAHAN_PEMBARUAN_FIRMWARE_ALAMAT_TIDAK_VALID | Firmware telah mendeteksi alamat tujuan yang tidak valid dalam konten data pesan. |
| 0x0A | KESALAHAN_PEMBARUAN_FIRMWARE_TIDAK_ADA_PENAWARAN | Perintah FIRMWARE_UPDATE_OFFER diterima tanpa terlebih dahulu menerima penawaran pembaruan firmware yang valid dan diterima. |
| 0x0B | KESALAHAN_PEMBARUAN_FIRMWARE_TIDAK_VALID | Kesalahan umum untuk Perintah FIRMWARE_UPDATE_OFFER, seperti Panjang Data yang berlaku tidak valid. |
5.5.2.3 Cadangan B8 - B11
Direservasi. Jangan gunakan.
5.5.2.4 Cadangan B12 - B15
Direservasi. 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 saat ini versi 7.0.1
Subkomponen - ID Komponen 2 - Firmware saat ini versi 12.4.54
Subkomponen - ID Komponen 3 - Firmware saat ini versi 4.4.2
Subkomponen - ID Komponen 4 - Firmware saat ini versi 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
Tawaran host: ID Komponen 2 - Versi firmware 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
Tawaran host: ID Komponen 2 - Versi firmware 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 saat ini versi 7.0.1
Subkomponen - ID Komponen 2 - Firmware saat ini versi 12.4.54
Subkomponen - ID Komponen 3 - Firmware saat ini versi 7.4.2
Subkomponen - ID Komponen 4 - Firmware saat ini versi 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
Komponen ID 3 - Firmware versi 9.0.0
Selain itu, implementasi mengharuskan versi firmware subkomponen tidak boleh kurang dari versi firmware yang berjalan pada komponen utama. Penyelenggara tidak mengetahui persyaratan tersebut dan up-to adalah komponen utama untuk memastikan aturan ini.
Urutannya adalah:
Penawaran host: ID Komponen 1 - Firmware versi 8.0.0
Penolakan komponen utama (karena ID komponen 3 belum diperbarui)
Tawaran host: ID Komponen 2 - Versi firmware 12.4.54
Penolakan komponen primer
Penawaran dari host: ID Komponen 3 - Versi Firmware 9.0.0
Komponen utama menerima penawaran
Host mengirimkan gambar firmware
Komponen utama menerima firmware, memvalidasinya
Karena tidak semua penawaran ditolak, host memainkan kembali 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
Tawaran host: ID Komponen 2 - Versi firmware 12.4.54
Penolakan komponen primer
Penawaran dari host: ID Komponen 3 - Versi Firmware 9.0.0
Penolakan komponen primer