синџирот на подигнување кај embedded Linux
July 30, 2026 · – посетители
Минатиот пат пишував за DFU како начин за флешување firmware преку USB. Тој напис прескокна едно прашање што заслужува свој одговор: што всушност се случува помеѓу притискањето на копчето за вклучување и појавата на shell prompt? DFU е само едно одвојување од овој пат, па вреди еднаш да се помине целиот.
Фазите
Нацртан како Mermaid дијаграм, синџирот (со местото на DFU во него) изгледа вака:
flowchart TD
A[Вклучување / Ресетирање] --> B[Boot ROM<br/>непроменлив, на чипот]
B --> C{Валидна слика на<br/>boot медиум?}
C -->|Не / присилно| D[ROM режим за опоравување<br/>UART / USB]
C -->|Да| E[SPL<br/>прв стадиум bootloader]
E --> F[U-Boot<br/>втор стадиум bootloader]
F --> G{Влез во DFU?}
G -->|Да| H[DFU режим<br/>се чека firmware преку USB]
G -->|Не| I[Вчитување kernel + device tree]
I --> J[Linux kernel]
J --> K[Монтирање root датотечен систем]
K --> L[init / systemd]И рендирано:
Boot ROM
Вграден во силициумот при производството — ништо во него не може да се промени подоцна. Единствената задача му е да најде нешто што може да се подигне на еден од мал број boot медиуми (eMMC, SD, QSPI flash, понекогаш USB) според boot-mode пиновите или eFuse-ите, и да скокне до него. Ако не најде ништо валидно, повеќето SoC-ови паѓаат во минимален UART или USB режим за опоравување на овој стадиум — самото прво место каде воопшто можеш да комуницираш со чипот.
SPL
Кратенка за Secondary Program Loader (терминот на U-Boot; други производители го нарекуваат FSBL или слично). Работи од мала количина SRAM на чипот, пред DRAM воопшто да е иницијализиран, па мора да биде мал. Главната задача му е токму тоа: да го активира DRAM-от, па во него да го вчита следниот стадиум — целосниот U-Boot.
Вистинскиот U-Boot
Ова е bootloader-от на кој повеќето луѓе мислат кога велат „bootloader“. Има драјвери, shell, environment променливи, поддршка за мрежа, и интерпретер на команди. Тука всушност живее и DFU — извршувањето на dfu 0 mmc 0 (или слично) го пренесува U-Boot во DFU режим наместо да продолжи со нормалното подигнување, а тоа е режимот со кој dfu-util комуницира од страна на хостот. Инаку, ја вчитува kernel сликата и device tree blob-от во меморија и скока во kernel-от.
Kernel и кориснички простор
Kernel-от сам себеси се декомпресира, го активира конзолата, го испитува хардверот користејќи го device tree-то што му е дадено, и монтира root датотечен систем — честo истата eMMC или SD картичка од која bootloader-от подигнал, понекогаш NFS во текот на развојот. Откако root датотечниот систем ќе биде монтиран, kernel-от предава на PID 1 — обично systemd кај слика изградена со Yocto — и токму таму всушност започнува „корисничкиот простор“.
Зошто е ова важно за DFU
DFU има смисла дури кога ќе видиш каде се вклопува: тоа е заобиколен пат што U-Boot може да го земе наместо да го вчита kernel-от, не одделна работа прикачена одозгора. Тоа е и причината зошто DFU не може да спаси секој начин на неуспех — ако самиот boot ROM не може да најде валиден SPL, никогаш не стигнуваш до U-Boot, и тогаш се потпираш на кој и да е режим за опоравување што boot ROM-от го поддржува (кој многу варира од производител до производител и е добра тема за друг напис).
Понатамошно читање
- U-Boot: Generic SPL framework — како се изградува SPL и за што е одговорен.
- Trusted Firmware-A: Firmware Design — поразработениот повеќестадиумски тек на подигнување (BL1/BL2/BL31/BL32/BL33) користен кај многу модерни Arm SoC-ови со безбеден синџир на подигнување, кој на тие платформи седи под U-Boot.
Поврзани текстови
- Што е Device Tree? — како хардверот му се опишува на јадрото
- Што е DFU? — запишување firmware преку USB кога нема друг пат
Коментари