Embedded Linux बूट चेन

July 30, 2026 · – विज़िटर

पिछली बार मैंने DFU के बारे में लिखा था, USB के ज़रिए फ़र्मवेयर flash करने के एक तरीके के रूप में। उस पोस्ट ने एक ऐसे सवाल को छोड़ दिया था जिसका जवाब अपने आप में देने लायक है: पावर बटन दबाने और shell prompt दिखने के बीच असल में क्या होता है? DFU इसी रास्ते की एक शाखा भर है, इसलिए पूरे रास्ते पर एक बार चलना उचित है।

चरण

Mermaid flowchart के रूप में खींचने पर, यह चेन (जिसमें DFU की जगह भी शामिल है) कुछ ऐसी दिखती है:

flowchart TD
    A[Power-on / Reset] --> B[Boot ROM<br/>immutable, on-chip]
    B --> C{Valid image on<br/>boot media?}
    C -->|No / forced| D[ROM recovery mode<br/>UART / USB]
    C -->|Yes| E[SPL<br/>first-stage bootloader]
    E --> F[U-Boot<br/>second-stage bootloader]
    F --> G{Enter DFU?}
    G -->|Yes| H[DFU mode<br/>waiting for firmware over USB]
    G -->|No| I[Load kernel + device tree]
    I --> J[Linux kernel]
    J --> K[Mount root filesystem]
    K --> L[init / systemd]

और रेंडर होने पर:

Boot ROM

यह manufacturing के समय ही silicon में पक्का बैठाया जाता है — बाद में इसमें कुछ भी बदला नहीं जा सकता। इसका इकलौता काम है, boot-mode pins या eFuses के अनुसार, कुछ सीमित boot media (eMMC, SD, QSPI flash, कभी-कभी USB) में से किसी एक पर बूट होने लायक कुछ भी ढूँढना, और उस पर jump करना। अगर इसे कुछ भी वैध न मिले, तो ज़्यादातर SoCs इस चरण पर एक न्यूनतम UART या USB recovery मोड में fall back करते हैं — यही वह सबसे पहली जगह है जहाँ आप चिप से किसी भी तरह बात कर सकते हैं।

SPL

यह Secondary Program Loader का संक्षिप्त रूप है (यह U-Boot का शब्द है; बाकी vendors इसे FSBL या इसी तरह के नामों से बुलाते हैं)। यह on-chip SRAM की एक छोटी-सी मात्रा से चलता है, DRAM के initialize होने से भी पहले, इसलिए इसका आकार बेहद छोटा होना ज़रूरी है। इसका मुख्य काम ठीक यही है: DRAM को चालू करना, फिर अगले चरण — पूरे U-Boot — को उसमें लोड करना।

U-Boot (पूरा)

यही वह bootloader है जिसे ज़्यादातर लोग "bootloader" कहते समय मतलब निकालते हैं। इसमें drivers, एक shell, environment variables, network support, और एक command interpreter होता है। DFU असल में यहीं रहता है — dfu 0 mmc 0 (या इससे मिलता-जुलता) कमांड चलाने पर U-Boot सामान्य बूट जारी रखने के बजाय DFU मोड में चला जाता है, और यही वह मोड है जिससे dfu-util host की तरफ़ से बात करता है। अन्यथा, यह kernel image और device tree blob को memory में लोड करता है और kernel पर jump कर देता है।

Kernel और Userspace

Kernel खुद को decompress करता है, console चालू करता है, उसे मिले device tree का इस्तेमाल करके hardware probe करता है, और एक root filesystem माउंट करता है — अक्सर वही eMMC या SD card, जिससे bootloader बूट हुआ था, और कभी-कभी development के दौरान NFS भी। एक बार root filesystem माउंट हो जाने पर, kernel नियंत्रण PID 1 को सौंप देता है — Yocto से बनी image पर आमतौर पर systemd — और वहीं से असल में "userspace" शुरू होता है।

यह DFU के लिए क्यों मायने रखता है

DFU का मतलब तभी समझ आता है जब आप देखें कि यह कहाँ बैठता है: यह एक ऐसा रास्ता है जिसे U-Boot kernel लोड करने की बजाय चुन सकता है, न कि कोई अलग चीज़ जो ऊपर से जोड़ दी गई हो। यही वजह है कि DFU हर failure mode को नहीं बचा सकता — अगर boot ROM को खुद ही कोई वैध SPL न मिले, तो आप U-Boot तक पहुँच ही नहीं पाते, और तब आपको boot ROM जो भी recovery मोड सपोर्ट करता है, उसी पर निर्भर रहना पड़ता है (जो vendor के हिसाब से काफ़ी अलग होता है, और किसी और पोस्ट के लिए एक अच्छा विषय है)।

आगे पढ़ने के लिए

U-Boot: Generic SPL framework — SPL कैसे बनाया जाता है और यह किसके लिए ज़िम्मेदार है।
Trusted Firmware-A: Firmware Design — कई आधुनिक Arm SoCs में इस्तेमाल होने वाला, secure boot chain के साथ ज़्यादा विस्तृत multi-stage boot flow (BL1/BL2/BL31/BL32/BL33), जो इन platforms पर U-Boot के नीचे बैठता है।