Belajar Firmware Engineer - Bootloader & OTA

#Pendahuluan

Setelah di episode 12 firmware kita terhubung jaringan, pada episode ini kita menjawab pertanyaan yang muncul begitu produk sudah di tangan pengguna: bagaimana memperbaruinya? Tidak mungkin memanggil semua perangkat untuk di-flash manual. Jawabannya adalah bootloader + OTA (Over-The-Air) update — dan ini salah satu kompetensi paling dibedakan antara engineer pemula dan senior.

Mengapa topik ini kritis? Karena update yang gagal bisa mematikan perangkat permanen (brick) — dan kehilangan ribuan perangkat di lapangan adalah bencana. Bootloader yang dirancang benar adalah "jaring pengaman" yang memastikan perangkat selalu bisa boot ke versi yang dikenal baik.

#Apa Itu Bootloader?

Bootloader adalah program kecil yang berjalan pertama kali setelah reset. Tugasnya: memilih dan menjalankan aplikasi utama. Di sinilah awal perjalanan boot (episode 2) mendapatkan "penjaga gerbang":

Karena bootloader adalah titik kepercayaan tertinggi (diperbarui paling jarang), ia harus kecil, stabil, dan sulit dirusak. Memisahkan bootloader dari aplikasi juga berarti aplikasi bisa diperbarui tanpa menyentuh bagian yang paling sensitif.

#Desain Bootloader

#Dua Tahap dan Remap Vector Table

Aplikasi tidak lagi berada di awal flash (offset 0), jadi vector table harus dipindah:

#define APP_BASE 0x08008000UL      // offset aplikasi (misal 32 KB)
 
// di startup aplikasi (setelah bootloader lompat):
SCB->VTOR = APP_BASE;              // pindahkan vector table

Bootloader mengecek image aplikasi (magic number, CRC/signature, versi), lalu lompat ke Reset_Handler aplikasi dengan stack pointer yang benar.

#Partition Table

Flash dibagi menjadi region dengan peran jelas — konsep ini populer dari ESP-IDF:

# name       type   subtype   offset    size    flags
nvs         data   nvs       0x9000    16K     -
bootloader  app    factory   0x1000    32K     -
app_a       app    ota_0     0x20000   1M      -
app_b       app    ota_1     0x120000  1M      -

#Slot A/B

Strategi paling aman: dua slot aplikasi (A/B). Firmware baru ditulis ke slot yang tidak aktif, diverifikasi, lalu swap. Jika boot gagal, perangkat kembali ke slot sebelumnya.

#Secure Boot: Root of Trust

"Valid" saja tidak cukup — image harus asli dari vendor. Secure boot membangun rantai kepercayaan:

Root of trust (fuse/public key di ROM)
   -> verifikasi bootloader (signature)
      -> verifikasi aplikasi (signature)

• Firmware di-sign dengan private key vendor (misal ECDSA/RSA-PSS).
• Perangkat verifikasi dengan public key yang tertanam (di flash terproteksi/fuse).
• Key compromise = produk bisa di-flash malware → simpan private key di HSM, rotasi key, dan support key revocation.

#Alur OTA: Dari Unduh ke Commit

Pipeline OTA produksi mengikuti alur ketat:

1. Unduh image baru (HTTPS/TLS) + metadata (versi, ukuran, hash)
2. Verifikasi: hash -> signature -> versi (harus > versi lama)
3. Tulis ke slot tidak aktif (streaming, chunk by chunk)
4. Verifikasi tertulis: baca balik hash / CRC
5. Set "pending swap" -> reboot
6. Boot dari slot baru; bila sukses -> COMMIT
7. Bila gagal / watchdog / timeout -> ROLLBACK ke slot lama

Commit adalah langkah yang sering dilupakan: tanpa commit eksplisit, perangkat akan menunggu konfirmasi; kalau tidak dapat dalam N reboot, ia rollback sendiri. Inilah jaring pengaman utama.

typedef enum {
    IMG_ACTIVE,     // image yang berjalan sekarang
    IMG_PENDING,    // menunggu commit setelah sukses boot
    IMG_FAULTY,     // gagal, siap rollback
} img_state_t;

#Praktik: Pipeline OTA

Bayangkan arsitektur update untuk produk Anda:

CI build       : sign image (key HSM) + generate manifest JSON
Serving        : upload ke storage (S3/R2) di balik CDN
Perangkat      : HTTPS GET manifest -> unduh image -> verifikasi
Device mgmt    : server menandai versi; perangkat melapor status
Rollout        : gradual (5% -> 25% -> 100%) + auto-pause jika error
Monitoring     : versi, success rate, brick rate per build

Poin paling sering diabaikan: rollout gradual dan monitoring. Melepas update ke 100% perangkat sekaligus mengubah satu bug kecil menjadi bencana besar.

#Kesalahan Umum Bootloader & OTA

1. Tanpa slot cadangan / tanpa rollback — satu update gagal = perangkat mati.
2. Tidak verifikasi hash sebelum boot — image korup ter-flash = brick.
3. Vector table tidak di-remap — aplikasi "jalan tapi interrupt aneh".
4. Lupa commit — perangkat rollback sendiri di lapangan tanpa alasan jelas.
5. Version check lemah — image lama bisa menimpa yang baru.
6. Rollout 100% sekaligus — tidak ada penghenti darurat.

#Penutup

Inti yang harus dibawa pulang:

• Bootloader = penjaga gerbang boot: verifikasi, pilih slot, lompat ke aplikasi.
• Desain: dua tahap + remap VTOR + partition table + slot A/B.
• Secure boot membangun rantai kepercayaan dari root of trust.
• Alur OTA: unduh → verifikasi → tulis slot pasif → commit → rollback.
• Pipeline produksi: sign, serve, gradual rollout, monitoring.

Di episode 14 selanjutnya kita membuat semua ini bisa dipercaya: Firmware Testing & CI — unit testing di host, Hardware-in-the-Loop, dan pipeline CI firmware yang otomatis membangun, menguji, dan memverifikasi setiap commit. Kode kalian akan diuji sebelum pernah menyentuh hardware!