Belajar Embedded Engineer - Embedded Linux

#Pendahuluan

Sepuluh episode terakhir berkutat di dunia MCU — bare-metal, register, RTOS. Kini saatnya naik kelas: embedded Linux. Ketika kebutuhan perangkat melampaui kemampuan MCU — butuh networking kompleks, bluetooth stack, banyak proses, driver USB — embedded engineer beralih ke SoC yang menjalankan Linux.

Perbedaan mentalitasnya besar. Di MCU kalian menulis semuanya; di embedded Linux kalian memanfaatkan ekosistem raksasa: kernel, toolchain, libraries, dan package manager. Tapi kekuatan itu datang dengan lapisan abstraksi baru yang wajib dipahami: device tree — file yang memberi tahu kernel hardware apa yang ada di depan matanya. Episode ini membangun fondasi untuk menguasai ketiganya: kernel, device tree, dan rootfs.

#Mengapa Linux untuk Embedded?

Rugi-ruginya: boot lebih lama (detik), konsumsi daya lebih tinggi, dan determinisme real-time lebih sulit dijamin (dibahas di episode 14). Itulah sebabnya banyak sistem memakai arsitektur hybrid — SoC Linux untuk aplikasi, MCU kecil untuk tugas real-time.

#Alur Boot Linux

Empat komponen wajib: bootloader (U-Boot adalah standar de facto), kernel zImage, device tree blob (.dtb), dan rootfs. Kalian akan menemukan keempatnya di board Linux mana pun — termasuk Raspberry Pi (yang menyembunyikan kompleksitas ini di balik config.txt).

#Device Tree: Kamus Hardware untuk Kernel

Masalah yang dipecahkan device tree: satu kernel bisa jalan di ribuan board berbeda. Daripada meng-compile kernel per board, Linux membaca deskripsi hardware dari file .dts (source) yang di-compile ke .dtb (binary). Ini "hardware datasheet" versi mesin:

/dts-v1/;
 
/ {
    compatible = "vendor,my-board";
    #address-cells = <1>;
    #size-cells = <1>;
 
    soc {
        uart0: serial@40004000 {
            compatible = "vendor,uart";
            reg = <0x40004000 0x400>;
            clock-frequency = <16000000>;
            status = "okay";
        };
 
        leds {
            compatible = "gpio-leds";
            led0 { gpios = <&gpio1 12 0>; label = "status"; };
        };
    };
};

Konsep kunci:

• compatible — string yang menghubungkan node dengan driver di kernel: kernel mencari driver dengan of_match_table yang cocok.
• reg — alamat dan ukuran blok register peripheral.
• gpios — referensi ke node gpio1 dengan pin 12 — contoh cara node saling merujuk.
• status — okay (aktif) vs disabled.

Kesalahan device tree adalah sumber "hardware tidak terdeteksi" paling umum di embedded Linux. Perbaikannya bukan menulis ulang driver, melainkan memperbaiki deskripsi. Ini keterampilan yang sangat dicari — dan jarang diajarkan.

#Kernel & Driver: Berbicara dengan Hardware

Kernel menangani scheduling proses, memory, dan semua hardware. Saat aplikasi ingin memakai peripheral, ia tidak menyentuh register langsung — ia lewat driver yang terdaftar sebagai file device di /dev:

/dev/ttyS0     # UART (serial console)
/dev/gpiochip0 # GPIO controller
/dev/i2c-0     # I2C bus

Pengembangan driver di kernel adalah topik besar (butuh series sendiri), tapi untuk embedded engineer ada dua level yang harus dikuasai:

1. User-space I/O — memakai peripheral lewat /dev dan sysfs dari aplikasi C/Python. Untuk 80% kebutuhan (GPIO, I2C, SPI, UART) ini sudah cukup dan jauh lebih aman.
2. Kernel module — menulis driver untuk hardware khusus yang tidak punya driver baku; masuk ke dunia module_init, probe, dan read/write callbacks.

Aturan praktis: mulai dari user-space. Hanya tulis kernel module jika benar-benar dibutuhkan (timing ketat, interupsi khusus, hardware unik).

#Rootfs & Build System

Rootfs adalah filesystem yang berisi userland: init, busybox, libraries, dan aplikasi kalian. Dua build system utama untuk membuat image:

Buildroot mengubah ~2000 paket menjadi satu image bootable dengan satu konfigurasi:

git clone https://github.com/buildroot/buildroot.git
cd buildroot
make qemu_arm_vexpress_defconfig
make -j$(nproc)

Hasilnya output/images/ berisi zImage, vexpress-v2p-ca9.dtb, dan rootfs.ext2 — lengkap siap boot. Menguji image tanpa hardware fisik? Pakai QEMU: boot Linux embedded di PC dengan qemu-system-arm — cara tercepat dan termurah untuk belajar tanpa board mahal.

#Praktik: Boot Linux di Board

Alur praktik di board nyata (misal Raspberry Pi atau board i.MX):

1. Buat rootfs dengan Buildroot (atau pakai image resmi board).
2. Siapkan SD card: partisi boot (kernel + dtb) dan rootfs.
3. Nyalakan, amati boot log lewat serial console (UART di pin board).
4. Setelah masuk shell: cat /proc/cpuinfo, cat /proc/device-tree/model, ls /dev, dan coba GPIO user-space lewat sysfs.

Uji kecil yang menguatkan pemahaman device tree: ubah satu nilai compatible di .dts dengan sengaja, rebuild dtb, boot — dan lihat hardware "hilang". Ganti kembali, boot lagi, hardware muncul. Itulah bukti langsung bahwa kernel buta tanpa deskripsi hardware yang benar.

#Common Pitfalls

1. Device tree tidak cocok dengan board — hardware tidak terdeteksi; cek dulu compatible dan reg.
2. Rootfs tidak lengkap — boot hang di Kernel panic - not syncing: VFS: Unable to mount root fs; periksa initramfs dan jenis filesystem.
3. Menyentuh driver terlalu awal — kuasai user-space dulu (sysfs, /dev).
4. Lupa konsol serial — bootlog tidak terlihat; set console=ttyS0,115200 di kernel cmdline.

#Penutup

Inti yang harus dibawa pulang:

• Embedded Linux dipilih saat kebutuhan melebihi MCU: networking penuh, multimedia, banyak proses.
• Alur boot: BootROM → U-Boot → kernel + DTB → rootfs → init.
• Device tree mendeskripsikan hardware ke kernel; compatible + reg adalah paspor device.
• Driver diakses lewat /dev; mulai dari user-space, baru kernel module.
• Buildroot untuk image sederhana; Yocto untuk produk kompleks; QEMU untuk belajar gratis.

Di episode 11 selanjutnya kita menambahkan senjata bahasa modern: Rust untuk embedded — no_std, memory safety tanpa garbage collector, dan praktik membuat aplikasi embedded di Rust. Di era 2026, Rust bukan lagi sekadar alternatif — ia sudah mainstream di industri. Sampai jumpa di episode 11!