Gömülü Linux Boot Zinciri
July 30, 2026 · – ziyaretçi
Geçen sefer DFU'dan USB üzerinden firmware flaşlamanın bir yolu olarak bahsetmiştim. O yazı, tek başına cevaplanmaya değer bir soruyu atlamıştı: güç düğmesine basmakla bir shell prompt'unun belirmesi arasında aslında ne oluyor? DFU bu yolun sadece bir dalı, o yüzden tüm yolu bir kere baştan sona yürümekte fayda var.
Aşamalar
Bir Mermaid akış şeması olarak çizildiğinde, zincir (DFU'nun içindeki yeriyle birlikte) şöyle görünür:
flowchart TD
A[Güç açma / Reset] --> B[Boot ROM<br/>değişmez, çip üzerinde]
B --> C{Boot medyasında<br/>geçerli imaj var mı?}
C -->|Hayır / zorlanmış| D[ROM kurtarma modu<br/>UART / USB]
C -->|Evet| E[SPL<br/>birinci aşama bootloader]
E --> F[U-Boot<br/>ikinci aşama bootloader]
F --> G{DFU'ya girilsin mi?}
G -->|Evet| H[DFU modu<br/>USB üzerinden firmware bekleniyor]
G -->|Hayır| I[Kernel + device tree yükle]
I --> J[Linux kernel]
J --> K[Kök dosya sistemini bağla]
K --> L[init / systemd]Ve render edilmiş hali:
Boot ROM
Üretim sırasında silikonun içine gömülür — sonradan üzerinde hiçbir şey değiştirilemez. Tek görevi, boot-mode pin'lerine veya eFuse'lara göre küçük bir boot medyası setinden (eMMC, SD, QSPI flash, bazen USB) boot edilebilir bir şey bulmak ve ona atlamaktır. Geçerli bir şey bulamazsa, çoğu SoC bu aşamada minimal bir UART veya USB kurtarma moduna düşer — çiple konuşabileceğin ilk nokta tam olarak burasıdır.
SPL
Secondary Program Loader'ın kısaltması (U-Boot'un kullandığı terim; diğer üreticiler FSBL veya benzeri isimler kullanır). DRAM henüz initialize edilmeden önce, çip üzerindeki küçük bir SRAM'den çalışır, bu yüzden çok küçük olmak zorundadır. Ana görevi tam olarak budur: DRAM'i ayağa kaldırmak, sonra bir sonraki aşamayı — tam U-Boot'u — onun içine yüklemek.
Asıl U-Boot
Çoğu insanın "bootloader" derken kastettiği şey budur. Sürücüleri, bir shell'i, ortam değişkenleri, ağ desteği ve bir komut yorumlayıcısı vardır. DFU'nun asıl yaşadığı yer de burasıdır — dfu 0 mmc 0 (veya benzeri) komutunu çalıştırmak, normal boot'a devam etmek yerine U-Boot'u DFU moduna düşürür; dfu-util'in host tarafından konuştuğu mod da budur. Aksi halde, kernel imajını ve device tree blob'unu belleğe yükler ve kernel'e atlar.
Kernel ve Kullanıcı Alanı
Kernel kendini açar (decompress), konsolu ayağa kaldırır, kendisine verilen device tree'yi kullanarak donanımı probe eder ve bir kök dosya sistemi bağlar — genellikle bootloader'ın boot ettiği aynı eMMC veya SD kart, geliştirme sırasında bazen NFS. Kök dosya sistemi bağlandıktan sonra kernel, PID 1'e devreder — bir Yocto imajında genellikle systemd — ve "kullanıcı alanı" gerçekte orada başlar.
Bunun DFU İçin Neden Önemli Olduğu
DFU, ancak nereye oturduğunu gördüğünde anlam kazanır: kernel'i yüklemek yerine U-Boot'un alabileceği bir sapmadır, üzerine sonradan cıvatalanmış ayrı bir şey değil. DFU'nun her başarısızlık modunu kurtaramamasının nedeni de budur — eğer boot ROM'un kendisi geçerli bir SPL bulamazsa, U-Boot'a hiçbir zaman ulaşamazsın ve bunun yerine boot ROM'un desteklediği hangi kurtarma moduysa ona güvenmek zorunda kalırsın (bu üreticiye göre epey değişir ve başka bir yazı için iyi bir konu).
Daha Fazla Okuma
- U-Boot: Generic SPL framework — SPL'in nasıl inşa edildiği ve neyden sorumlu olduğu.
- Trusted Firmware-A: Firmware Design — güvenli bir boot zincirine sahip birçok modern Arm SoC'de kullanılan, o platformlarda U-Boot'un altında oturan daha kapsamlı çok aşamalı boot akışı (BL1/BL2/BL31/BL32/BL33).
İlgili Yazılar
- Device Tree Nedir? — donanımın çekirdeğe nasıl anlatıldığı
- DFU Nedir? — başka yol kalmadığında USB üzerinden firmware yazmak
Yorumlar