abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
včera 21:11 | Nová verze

Vyšla nová verze 1.4.0 nástroje pro připojení ke vzdálené ploše Remmina. Mezi změnami figurují např. opravy autentizace přes SSH nebo nakládání se schránkou při připojení přes RDP. Sestavení dostupná z PPA pro Ubuntu skončí ve prospěch Flatpaku a Snapu.

Fluttershy, yay! | Komentářů: 4
21.2. 16:33 | Komunita

Google zveřejnil seznam 200 organizací přijatých do letošního Google Summer of Code (GSoC). Dle plánu se studenti přihlašují od 16. do 31. března. Vydělat si mohou od 3 000 do 6 600 dolarů. V Česku a na Slovensku 3 600 dolarů. Další informace v často kladených otázkách (FAQ). K dispozici jsou také statistiky z minulých let.

Ladislav Hagara | Komentářů: 1
21.2. 15:55 | IT novinky

Ve věku 74 let zemřel Lawrence Tesler. V 70. letech pracoval v Xerox PARC a posléze odešel do Apple. Zabýval se především zjednodušováním uživatelských rozhraní, byl odpůrcem modality a přispěl k prosazení moderního způsobu označování a kopírování textu – myší a klávesovými zkratkami (kombinace s XCV) – v raných Apple Human Interface Guidelines. Dále se podílel např. na vývoji Smalltalku a souvisejícího přenosného počítače Xerox NoteTaker nebo později PDA Apple Newton.

Fluttershy, yay! | Komentářů: 6
21.2. 13:11 | Zajímavý článek

Aktuální příspěvek What is Mobile PureOS? na stránkách společnosti Purism je věnován operačnímu systému Mobile PureOS, tj. PureOS pro mobilní zařízení a především pro telefon Librem 5. Víceméně se jedná o stabilní Debian s GNOME doplněný o balíčky phosh, phoc, libhandy, Calls, Chats a další.

Ladislav Hagara | Komentářů: 0
20.2. 19:33 | Zajímavý článek

Jozef Mlich se v příspěvku PinePhone je nové OpenMoko na svém blogu věnuje svému novému linuxovému chytrému telefonu PinePhone v edici BraveHeart: "Momentálně se pocity z tohohle zařízení dají přirovnat k BrokenMoku. Většina věcí prostě nefunguje. Minimálně ne sama od sebe. Začít se dá už u samotného hardware, kde existuje wiki stránka popisující nedostatky".

Ladislav Hagara | Komentářů: 23
20.2. 10:00 | Zajímavý projekt

Justine Haupt aktualizovala svůj open source mobilní telefon s rotační číselnicí a zveřejnila kompletní dokumentaci, vlastní kód, schémata i STL soubory pro 3D tisk. Desku plošných spojů případně i vytištěný obal lze koupit v jejím obchodu.

Ladislav Hagara | Komentářů: 40
20.2. 06:00 | IT novinky

Otevřená certifikační autorita Let's Encrypt v příspěvku na svém blogu informuje, že žádosti o vystavení certifikátů nově validuje z několika míst současně (Multi-Perspective Validation). Další informace v diskusním fóru.

Ladislav Hagara | Komentářů: 10
19.2. 13:55 | Nová verze

Byla vydána verze 15.0 na Debianu založené linuxové distribuce Untangle NG Firewall. Přehled novinek v poznámkách k vydání a ve videu na YouTube. Vyzkoušet lze (zatím neaktualizované) demo webového rozhraní.

Ladislav Hagara | Komentářů: 0
19.2. 12:11 | Pozvánky

Letošní ročník konference LinuxDays se uskuteční o víkendu 3. a 4. října, opět se potkáme v pražských Dejvicích na FIT ČVUT. Také během devátého ročníku nás budou čekat desítky přednášek, workshopy, stánky a spousta doprovodného programu. Aktuální dění můžete sledovat na Twitteru nebo Facebooku, přidat se můžete také do telegramové diskusní skupiny.

Petr Krčmář | Komentářů: 7
19.2. 10:22 | Zajímavý článek

Alexander Popov se v příspěvku na svém blogu podrobně věnuje možnostem zneužití bezpečnostní chyby CVE-2019-18683 v linuxovém podsystému V4L2. Videoukázka eskalace práv na YouTube. Chyba byla v upstreamu opravena v listopadu loňského roku. Alexander Popov se chybě věnoval ve své přednášce (pdf) na konferenci OffensiveCon 2020.

Ladislav Hagara | Komentářů: 0
Vydržela vám novoroční předsevzetí?
 (9%)
 (5%)
 (3%)
 (83%)
Celkem 183 hlasů
 Komentářů: 0
Rozcestník

Optimalizácia bootovania Linuxu na ARMe

12.4.2014 19:00 | Přečteno: 2054× | 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.

Ž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.

       

Hodnocení: 100 %

        špatnédobré        

Obrázky

Optimalizácia bootovania Linuxu na ARMe, obrázek 1

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

13.4.2014 01:10 Roman Došek | skóre: 17 | blog: flare
Rozbalit Rozbalit vše Re: Optimalizácia bootovania Linuxu na ARMe
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 avatar 13.4.2014 09:02 mirec | skóre: 31 | blog: mirecove_dristy | Poprad
Rozbalit Rozbalit vše Re: Optimalizácia bootovania Linuxu na ARMe

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.

LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
14.4.2014 21:27 Peter Golis | skóre: 59 | blog: Bežné záležitosti | Bratislava
Rozbalit Rozbalit vše Re: Optimalizácia bootovania Linuxu na ARMe
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?
13.4.2014 05:25 Kvakor
Rozbalit Rozbalit vše Re: Optimalizácia bootovania Linuxu na ARMe
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 avatar 13.4.2014 09:08 mirec | skóre: 31 | blog: mirecove_dristy | Poprad
Rozbalit Rozbalit vše Re: Optimalizácia bootovania Linuxu na ARMe

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 ;-).

LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
14.4.2014 00:39 Kvakor
Rozbalit Rozbalit vše Re: Optimalizácia bootovania Linuxu na ARMe
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).
13.4.2014 17:36 BFU
Rozbalit Rozbalit vše Re: Optimalizácia bootovania Linuxu na ARMe
"Čí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".

Založit nové vláknoNahoru

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.