Optimalizácia bootovania Linuxu na ARMe

12.4.2014 19:00 | Přečteno: 2187× | Hardware | poslední úprava: 12.4.2014 18:55

V dnešnom blogu sa trochu bližšie pozrieme na proces bootovania Linuxu na embedded zariadeniach (konkrétne ARM Allwinner A13).

Typický proces bootovania

Jednoduché embedded zariadenia bootujú podobným spôsobom ako donedávna bootovali bežné desktopy. Pre istotu si postupnosť jednotlivých krokov pripomenieme.

• Bootloader
• Kernel + ovládače
• Mount
• Inittab / Init skripty
• GUI

Žiaden s týchto krokov (hádam okrem GUI) nie je možné vynechať. Je však možné ich optimalizovať rôznymi technikami.

Bootloader

V prípade Allwinneru A13 sa bootloader skladá z niekoľkých úrovní - BROM > boot0 > boot1 > boot.axp > uBoot > kernel. Okamžite po zapnutí SOC spustí BROM na adrese 0xFFFF0000, ktorý rozhodne, či prepne zariadenie do FEL módu, alebo bude pokračovať v štandardnom boote. Pri bežnom boote pokračuje načítaním programu boot0 z NAND / Flash, ktorý inicializuje hardvér. Nasleduje boot1, ktorý "pripojí" boot partíciu, inicializuje zvyšný hardvér podľa script.bin, zobrazí splash screen, načíta do pamäte súbor boot.axp a odovzdá mu riadenie. Boot.axp zvyčajne znovu pripojí boot partíciu, načíta uBoot a spustí ho. Samotný kernel načíta a spustí až uBoot. Zdrojové kódy bootloadera sú dostupné tu.

Inicializáciu hardvéru majú na starosti stupne boot0 a boot1. Najjednoduchšou zmenou oproti štandardnému bootu je nahradenie súboru boot.axp obrazom kernelu bImage, čím zredukujeme pár milisekúnd potrebných na načítanie uBootu. Dosť veľký potenciál na zrýchlenie sa skrýva v stupni boot1. Čítanie súborov z filesystému sa dá teoreticky nahradiť čítaním z pevne zadanej adresy.

Kernel

Najdôležitejšou optimalizáciou kernelu je odstránenie nepotrebných funkcií (make menuconfig a odstrániť všetko, čo nie je potrebné). V zvyšných ovládačoch, ktoré potrebujeme sú zvyčajne rôzne oneskorenia pre inicializáciu hardvéru. Ak však vieme, že náš hardvér sa inicializuje rýchlejšie je možné tieto delaye výrazne skrátiť. Niektoré časti kernelu sa dajú skompilovať ako moduly a inicializovať paralelne počas bootu.

Mount

Embedded zariadenia sa často vypínajú odpojením zariadenia od napájania. Preto je vhodné pripájať disky ako read only. Zbavíme sa tak zdĺhavej inicializácie journalu pri pripájaní.

Init

Spustenie základných služieb má na starosti /etc/inittab. Busybox má v ňom (medzi inými) nasledujúci riadok:

::sysinit:/etc/init.d/rcS

Pri inicializácii systému sa má spustiť skript rcS, ktorý následne spúšťa zvyšné skripty z /etc/init.d. V tomto kroku optimalizácie je vhodné všetky súbory z /etc/init.d presunúť a nechať tam len rcS a rcK. Následne tam pridávať len tie, služby, ktoré sú skutočne potrebné.

GUI

Najtvrdším orieškom je optimalizácia štartu GUI. Za predpokladu, že nebudeme GUI aplikácie vytvárať priamo od nuly, ale použijeme nejaký framework je dosť pravdepodobné, že zo samotnej aplikácie sa pri štarte použije len malá časť. Za ideálnych podmienok by mali byť funkcie v aplikácii zoradené v presne takom poradí, v akom sa bežne používajú pri štarte. To môžme dosiahnuť kompiláciou s parametrom --finstrument-functions, analýzou behu a použitím špeciálneho ld skriptu.

Výsledky

Na záver je tu moje video z bootu na Allwinneri. Kernel začína bootovať až pri zapnutí podsvietenia LCD. Po približne sekunde bootovania sa zobrazí na 2s top (je spúšťaný priamo z inittabu), následne je po 2s zabitý a spustí sa malý Qt 5 program. Grafika môže teoreticky nabehnúť o 2s skôr (ak vynecháme delay). Žiadna optimalizácia Qt nebola vykonávaná, takže je možné ísť optimalizáciou ešte ďalej.

       

Obrázky

Komentáře

[Roman Došek]

Další možnost zrychlení je používat obdobu uspávání na disk, swsusp. Viděl jsem kopu lidí se tím na armech zabývat a měli dost pěkné výsledky, ale pokaždé to bylo přímo pro specifické zařízení. Hlavní důvod proč to "nejde" obecně bylo, že spousta ovladačů systému na to nebyla připraven a většinou vytuhly. Netušíš, jestli se ohledně toho něco pohlo?

[mirec]

Nejaké pokusy tam boli, ale nevidel som nič takto rýchle (od zapnutia po Qt 4 grafiku za 0.77s). Môj hardvér má max. rýchlosť čítania 10MB/s, uspávaním nie je šanca dostať sa na tak dobré hodnoty. Celkovo je uspávanie na ARM-e ešte v plienkach, ovládače sú rady ak prežijú unload (v lepšom prípade sú aspoň skompilovateľné ako moduly). Pri unloade napr. NAND modulu mi takmer vždy vytuhne celý kernel.

[Peter Golis]

Pekné. Ale ako potom funguje tlačítko sleep na Android STB, je to len suspend to RAM alebo to vypne procesy a prepne jednu LEDku?

[Kvakor]

Další možná otimaliza u GUI programů je nahodit XWindows hned ze začátku (po udevu a nahození loopbacku), takže zatím co se inicializují Xka, tak se pokračuje v další inicializaci hardwaru. Někde jsem dokonce viděl popsanou optimalizaci xorg.conf pro rychlejší start, ale mám pocit, že se tím moc času neušetří. U jednoúčelové aplikace stačí většinou spustit jen XServer a samotnou aplikaci, různé display managery, grafická (nebo, bohové chraň, dokonce desktopová) prostředí jen zbytečně zdržují a zabírají pak paměť. Jako alternativa jde použít nějaký minimalistický display manager, třeba nodm.

Pokud se má dělat opožděná inicializace, tak mně vždy vycházela jako lepší možnost dát "pomalý" modul do blacklistu (skrz soubor v /etc/modprobe.d) a vložit ho do jádra později, aby zbytečně nebrzdil udev při startu. Nebo, pokud je zařízení málo a jsou převážně jen cold-plug, tak je možné vůbec nepoužívat vůbec udev, protože jádro umí základní obsazení /dev udělat samo o sobě skrz devtmpfs (CONFIG_DEVTMPFS a CONFIG_DEVTMPFS_MOUNT), dokonce je možné nacpat i binární bloby přímo do jádra (i pokud je využívají ovladače přeložené jako moduly), takže se nemusí při startu načítat. Většinou pak stačí jen pár řádek na donastavení práv a je to. Jesliže se vše (s vyjímkou jako /var a /tmp) mountuje jen read-only, tak se u pomalejších médií a rychlejších procesorů vyplatí použí kompresi a SquashFS - pokud jde čistě o čas, je lepší, aby procesor načítal méně dat a rozbaloval je, než aby načítal více dat a trávil čas tím, že nečině čeká na I/O. Chce to ale vyzkoušet a vybrat, jaká kompresní metoda je optimální pro danou kombinaci hardwaru.

No a pokud je spouštěná GUI aplikace primitivní (typu zobrazení tří čísel, jednoho řádku texu a dvou tlačítek), tak je tu možnost uplně se vykvajznou na XWindows a jet jen přes framebuffer (třeba přes SDL).

[mirec]

No celkovo na embedded je X dosť zlá voľba. Ja spúšťam Qt 5 s OpenGL akceleráciou (žiaľ trvá to pomerne dlho keďže sa mi nechcelo robiť optimalizáciu knižníc Qt, reálne by to malo skrátiť čas štartu aplikácie tak na 1/3) priamo na framebufferi. A mimochodom SDL som na framebufferi tiež skúšal .

[Kvakor]

A pokud se SDL framebuffer nelíbí (píše třeba No video mode large enough ...), tak stačí nastavit proměnnou prostředí SDL_FB_BROKEN_MODES=1, po které se testy přeskočí (ale pak musíte sami dohlédnou, aby jste nastavili stejné rozlišení, jaké má framebuffer). Pokud ani pak nechce fungovat, tak je ještě možné v SDL_SetVideoMode() zkoušet různé kombinace flagů SDL_HWSURFACE/SDL_SWSURFACE a SDL_DOUBLEBUF (optimum je SDL_HWSURFACE | SDL_DOUBLEBUF), případně s SDL_FULLSCREEN a/nebo SDL_OPENGL (které nejspíš nepůjde nastavit, pokud nejde nastavit ani SDL_HWSURFACE).

[BFU]

"Čítanie súborov z filesystému sa dá teoreticky nahradiť čítaním z pevne zadanej adresy." jak si toto ma clovek vylozit ? Rovnou to tu radeji reknu: nacpat kernelovy image primo do RAW NAND je kravina, nebot NAND se chova jako DRAM s trochu delsim refreshem . Casem se ty data v NAND zcorrupti a pokud kernelovy image nema checksum, tak to nemusi byt ani poznat.

btw. doporucuju se zamyslet v pripade ARMu nad kernelovou volbou CONFIG_CC_OPTIMIZE_FOR_SIZE . Duvod je jednoduchy, ARM ma malou L1 icache => caste prehazovani kerneloveho kodu mezi L1 a {L2 cache , DRAM} je masivni performance hit. Redukci velikosti jadra a tim redukci vyuziti cacheline v L1 cache se snizi pocet vyhozeni cacheline do vzdalenejsi pameti (protoze se do te L1 vleze vice kodu). Ve vysledku je ten system rychlejsi nez kdyz je kompilovany "FOR_SPEED".