Belajar Embedded Engineer - Bootloaders & OTA

#Pendahuluan

Perangkat yang kalian bangun tidak akan pernah sempurna di hari pertama. Bug ditemukan, fitur diminta, regulasi berubah — dan jika perangkatnya sudah terpasang di lapangan, satu-satunya jalan perbaikan adalah OTA (Over-The-Air update): memperbarui firmware lewat jaringan tanpa menyentuh perangkat. Tanpa OTA, satu bug di produksi berarti ribuan perangkat harus dikembalikan atau diganti.

Tapi OTA yang sembrono lebih berbahaya dari tidak ada OTA: update yang korup di tengah jalan bisa mengubah perangkat menjadi bata yang tidak bisa boot. Episode ini membangun pemahaman bootloader, strategi partisi A/B, update bertanda tangan, dan pipeline OTA end-to-end — kemampuan yang membedakan produk "matang" dari prototipe.

#Bootloader: Penjaga Gerbang Firmware

Bootloader adalah program kecil yang berjalan sebelum aplikasi utama. Tugasnya: memverifikasi dan menyalakan aplikasi — atau mengambil alih saat perlu update. Layout flash khas:

0x08000000  |  Bootloader  |  verifikasi + decide
0x08008000  |  App A (slot aktif)  |  firmware yang berjalan
0x080C0000  |  App B (slot cadangan) |  firmware update, menunggu verifikasi
0x08100000  |  OTA buffer / metadata  |  konfigurasi update

Alur boot minimal:

1. Bootloader memverifikasi tanda tangan digital aplikasi.
2. Jika valid → lompat ke aplikasi.
3. Jika aplikasi rusak / update baru tidak lolos verifikasi → rollback ke versi terakhir yang baik.

Tanpa bootloader, kalian tidak punya mekanisme aman untuk update di lapangan. Dengan bootloader, update yang gagal bisa "ditarik kembali" tanpa kehilangan perangkat.

#Secure Boot: Kunci Kepercayaan di Awal

Secure boot memastikan hanya firmware yang ditandatangani vendor yang boleh berjalan. Rantai kepercayaannya berlapis:

Mekanismenya:

1. Root of trust — kunci publik vendor disimpan di tempat yang tidak bisa diubah (OTP/efuse atau secure element).
2. Signature — setiap firmware di-sign dengan kunci privat vendor (yang tidak pernah keluar dari build server).
3. Anti-rollback — MCU menyimpan nomor versi minimum; firmware lama yang rentan tidak bisa di-install ulang.

Ini juga fondasi keamanan yang dibahas lebih dalam di episode 18. Kunci privat adalah segalanya: jika bocor, semua perangkat kalian bisa diambil alih. Simpan di HSM/cloud KMS, dan jangan pernah commit ke repo.

#Strategi OTA: A/B dan Rollback

Cara paling umum dan paling aman untuk update di MCU: dual-bank (A/B) update.

1. Firmware baru di-download ke slot B (tidak menyentuh slot A)
2. Slot B diverifikasi (signature + CRC)
3. Bootloader beralih boot ke B
4. Aplikasi B berjalan, lapor "sehat" ke server
5. Baru slot A boleh diisi update berikutnya

Kelebihan A/B: tidak ada window "perangkat tanpa firmware". Update yang gagal membuat perangkat tetap boot dari slot lama. Kekurangannya: flash dobel — biaya yang wajar untuk keandalan.

Untuk sistem dengan satu slot saja (flash terbatas), pakai pola update-in-place + self-test: download ke area update, verifikasi, bootloader salin ke slot aplikasi, lalu app health-check — jika aplikasi baru crash berulang, bootloader otomatis boot ke versi lama. Ini lebih murah tapi punya jendela risiko saat penyalinan.

#Update Bertanda Tangan: Jangan Percaya Siapa Pun

Setiap payload OTA harus ditandatangani dan diverifikasi:

# 1. build firmware
make firmware
# 2. tanda tangani dengan kunci privat (di CI, tidak pernah lokal)
sign-tool --key signing.key --input firmware.bin --output firmware-signed.bin
# 3. unggah ke server / cloud storage
aws s3 cp firmware-signed.bin s3://ota-bucket/v1.2.3.bin

Di sisi perangkat, bootloader (atau update client) memverifikasi signature dengan kunci publik sebelum menyalin. Protokol update juga harus memakai TLS (episode 12) — signature melindungi isi, TLS melindungi transport dari gangguan.

Metadata yang wajib dibawa tiap update: versi, hash, ukuran, dan min-version (untuk anti-rollback). Tanpa metadata, rollback yang salah bisa menurunkan perangkat ke versi yang rentan.

#Pipeline OTA End-to-End

Alur lengkap update dari server ke perangkat:

1. Build & test — CI di episode 16 menghasilkan binary + laporan.
2. Signing — binary ditandatangani, metadata dibuat.
3. Upload & staging — binary diunggah, versi kecil diuji ke grup beta (canary).
4. Distribusi bertahap — update disebar 5% → 20% → 100% sambil memantau laporan kesehatan.
5. Ack perangkat — perangkat melaporkan versi dan status; server menandai sukses/gagal.

Canary update adalah kebiasaan terbaik industri: update dimulai ke sebagian kecil perangkat, diawasi beberapa hari, dan jika tidak ada anomali baru diperluas. Server perlu menyimpan inventory perangkat: versi saat ini, model, dan status terakhir — ini membuat rollback massal menjadi mungkin.

#Praktik: Pipeline OTA Pertama

1. Partisi flash board (ESP32 mudah: tabel partisi otomatis mendukung OTA A/B).
2. Buat bootloader minimal yang memverifikasi checksum sebelum boot app.
3. Build dua versi firmware (v1 berkedip lambat, v2 berkedip cepat) — flashing manual di slot yang berbeda.
4. Implementasikan update HTTP sederhana: download binary, simpan, verifikasi, reboot.
5. (Lanjutan) Tambahkan signature ECDSA dan simulasikan update ditolak vs diterima.

#Common Pitfalls

1. Update tanpa verifikasi signature — pintu masuk perangkat ditimpa malware.
2. Tidak ada rollback — update gagal = bata permanen.
3. Menimpa slot yang sedang berjalan — perangkat tanpa firmware di tengah salin.
4. Anti-rollback tidak ada — perangkat bisa diturunkan ke versi rentan.
5. Tidak memantau hasil update — server tidak tahu perangkat gagal sampai pengguna komplain.

#Penutup

Inti yang harus dibawa pulang:

• Bootloader memverifikasi dan menyalakan aplikasi — gerbang keamanan pertama.
• Secure boot membangun rantai kepercayaan dari ROM ke aplikasi; anti-rollback mencegah downgrade.
• A/B update (dual-bank) menghapus window tanpa firmware; rollback otomatis menjaga perangkat tetap hidup.
• Setiap payload OTA ditandatangani; distribusi bertahap (canary) + inventory perangkat untuk kontrol penuh.
• Rancang rollback sejak desain, bukan setelah produksi.

Di episode 18 selanjutnya kita mendalami sisi gelap yang tak bisa dihindari: embedded security — secure boot, kriptografi di perangkat, dan melindungi firmware dari pembajakan. Dunia terhubung yang kalian bangun di episode 12 adalah juga dunia yang diserang. Sampai jumpa di episode 18!