Membedah Jantung Sistem Operasi (Bagian 2): Mekanisme Interupsi dan Tantangan Vector Remapping

January 8, 2026
 |  No Comments

Pada Artikel Bagian Pertama, kita telah membedah struktur Exception Vector Table sebagai “Papan Switchboard Darurat” bagi prosesor. Namun, tabel tersebut hanyalah daftar alamat. Agar sistem operasi benar-benar hidup, tabel ini harus terhubung dengan “saraf-saraf” perangkat keras lainnya.

Bagian ini akan membahas bagaimana sinyal listrik dari tombol atau sensor bisa sampai ke meja kerja CPU, serta satu langkah krusial dalam pemrograman Raspberry Pi yang sering dilupakan pemula: Vector Remapping.

5. Ekosistem Interupsi: Segitiga Komunikasi

Dalam sistem operasi Bare Metal, interupsi tidak terjadi secara ajaib. Ada rantai komando yang melibatkan tiga komponen utama. Memahami “Segitiga Komunikasi” ini adalah kunci untuk menulis driver yang berfungsi.

A. Komponen 1: Periferal (The Trigger)

Ini adalah sumber kejadian, misalnya modul GPIO, UART, atau System Timer.

  • Peran: Mendeteksi kejadian fisik (misal: tombol ditekan, waktu habis, data masuk).
  • Aksi: Mengirim sinyal “Req” (Request) ke komponen penengah. Periferal tidak memiliki akses langsung ke otak CPU.
  • Alamat Penting: Tabel Register Periferal (seperti GPFSEL atau GPEDS di 0x20200000).

B. Komponen 2: Interrupt Controller (The Manager)

Ini adalah “Manajer Lalu Lintas” yang duduk di antara semua periferal dan CPU. Pada chipset BCM2835 (Raspberry Pi 1), komponen ini memiliki alamat dasar 0x2000B000.

  • Peran: Mengumpulkan semua teriakan minta tolong dari periferal (Timer, GPIO, UART, dll).
  • Aksi: Memilah prioritas. Jika Timer dan UART berteriak bersamaan, siapa yang harus didahulukan? Setelah diputuskan, ia menyalakan satu garis sinyal IRQ (Interrupt Request) ke kaki CPU.
  • Penting: Saat menulis kode penanganan interupsi, hal pertama yang dilakukan CPU adalah bertanya kepada manajer ini: “Siapa yang barusan memanggil saya?”

C. Komponen 3: CPU Core (The Executor)

Ini adalah prosesor utama (ARM1176JZF-S).

  • Peran: Mengeksekusi instruksi.
  • Aksi: Ketika sinyal IRQ dari Interrupt Controller aktif, CPU secara otomatis membuang pekerjaan saat ini, mengganti mode menjadi IRQ Mode, dan melompat ke alamat 0x18 di Vector Table.

6. Tantangan Teknis: Anomali Alamat 0x8000 (Vector Remapping)

Jika Anda menyalin kode Vector Table standar ARM begitu saja ke dalam startup code Raspberry Pi, sistem Anda kemungkinan besar akan crash saat interupsi terjadi. Mengapa?

Masalah: Benturan Standar vs Implementasi

  1. Aturan Baku ARM: Arsitektur prosesor ARM mewajibkan Vector Table berada di alamat memori paling awal, yaitu 0x00000000. Ketika interupsi terjadi, CPU hard-wired (terpatri secara fisik) untuk melompat ke 0x00, 0x04, 0x18, dst.
  2. Kenyataan Raspberry Pi: Bootloader GPU pada Raspberry Pi secara default memuat kernel kita (kernel.img) di alamat 0x8000.

Konsekuensinya:

Alamat 0x0000 hingga 0x7FFF pada awalnya kosong (atau berisi sisa kode inisialisasi GPU yang tidak relevan).

Jika tombol ditekan —> CPU lompat ke 0x18 —> Alamat 0x18 berisi data sampah (bukan kode kita) —> Sistem Crash / Undefined Instruction.

Solusi: Vector Remapping (Copy-Paste Memory)

Untuk mengatasi ini, tugas pertama kode startup kita (boot.S) sebelum masuk ke fungsi main() adalah melakukan Relokasi Vektor.

Kita harus menulis rutin assembly kecil yang menyalin 8 baris instruksi Vector Table (32 bytes) dari posisi kernel kita (0x8000) ke alamat nol (0x0000).

Logika Kode (Pseudo-Assembly):

Cuplikan kode

/* 1. Ambil alamat asal (Vector Table di 0x8000) */
LDR R0, =_start 

/* 2. Ambil alamat tujuan (0x0000) */
MOV R1, #0x0000

/* 3. Lakukan Loop Copy sebanyak 8 kali (atau 16 instruksi ldr) */
LOOP_COPY:
    LDR R2, [R0]   /* Baca dari 0x8000 */
    STR R2, [R1]   /* Tulis ke 0x0000 */
    ADD R0, #4     /* Geser pointer asal */
    ADD R1, #4     /* Geser pointer tujuan */
    /* ... ulangi sampai selesai ... */

Setelah proses penyalinan ini selesai, barulah aman bagi kita untuk mengaktifkan fitur interupsi (dengan instruksi cpsie i). Kini, jika CPU melompat ke 0x18, ia akan menemukan instruksi lompatan yang benar yang mengarah ke kode penanganan kita.

7. Kesimpulan Akhir: Peta Jalan Menuju OS Interaktif

Memahami Exception Vector Table dan Tabel Periferal mengubah cara pandang kita terhadap kode sistem operasi:

  1. Vector Table adalah Resepsionis yang menyambut setiap gangguan dari luar.
  2. Tabel Periferal adalah Peta Kontrol untuk mengatur perangkat mana yang boleh bicara.
  3. Vector Remapping adalah Jembatan yang menyelaraskan aturan prosesor dengan aturan board Raspberry Pi.

Dengan fondasi pengetahuan ini, langkah selanjutnya dalam pengembangan OS Bare Metal menjadi jelas. Kita tidak lagi sekadar menyalakan LED dalam sunyi, tetapi siap membangun Driver UART (Universal Asynchronous Receiver-Transmitter).

Driver UART ini akan memanfaatkan mekanisme interupsi yang telah kita pelajari untuk mengirimkan teks dari Raspberry Pi ke layar komputer kita, memberikan “suara” bagi sistem operasi yang sedang kita bangun.