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í
×

dnes 12:55 | Nová verze

Byla vydána verze 17.12.0 KDE Aplikací (KDE Applications). Přehled novinek v kompletním seznamu změn a na stránce s dalšími informacemi. Aplikace, které nebyly dosud portovány na KDE Frameworks 5, byly z KDE Aplikací odstraněny.

Ladislav Hagara | Komentářů: 16
dnes 03:00 | Komunita

Na Humble Bundle lze získat počítačovou hru Company of Heroes 2 (Wikipedie, YouTube) běžící také v Linuxu zdarma. Speciální akce končí v sobotu v 19:00.

Ladislav Hagara | Komentářů: 0
dnes 02:00 | Zajímavý software

Christian Kellner představil na svém blogu projekt Bolt řešící bezpečnost rozhraní Thunderbolt 3 na Linuxu. Pomocí příkazu boltctl nebo rozšíření GNOME Shellu lze komunikovat s démonem boltd a například zakázat neznámá zařízení a předejít tak útokům typu Thunderstrike nebo DMA.

Ladislav Hagara | Komentářů: 6
dnes 01:00 | Nová verze

Po půl roce vývoje od vydání verze 11.0 byla vydána verze 11.1 svobodného softwaru pro vytváření datových úložišť na síti FreeNAS (Wikipedie). Nejnovější FreeNAS je postaven na FreeBSD 11.1. Přehled novinek v příspěvku na blogu. Zdůraznit lze zvýšení výkonu OpenZFS, počáteční podporu Dockeru nebo synchronizaci s cloudovými službami Amazon S3 (Simple Storage Services), Backblaze B2 Cloud, Google Cloud a Microsoft Azure

Ladislav Hagara | Komentářů: 0
včera 23:55 | Nová verze

Po dvou měsících vývoje od vydání verze 235 oznámil Lennart Poettering vydání verze 236 správce systému a služeb systemd (GitHub, NEWS).

Ladislav Hagara | Komentářů: 6
včera 20:00 | Nová verze Ladislav Hagara | Komentářů: 0
včera 19:33 | Pozvánky

Pražská Fedora 27 Release Party, oslava nedávného vydání Fedory 27, se uskuteční 19. prosince od 19:00 v prostorách společnosti Etnetera (Jankovcova 1037/49). Na programu budou přednášky o novinkách, diskuse, neřízený networking atd.

Ladislav Hagara | Komentářů: 0
včera 18:11 | Nová verze

Byla vydána verze 2.11.0 QEMU (Wikipedie). Přispělo 165 vývojářů. Provedeno bylo více než 2 000 commitů. Přehled úprav a nových vlastností v seznamu změn.

Ladislav Hagara | Komentářů: 0
včera 17:44 | Komunita

Canonical oznámil dostupnost kryptografických balíčků s certifikací FIPS 140-2 úrovně 1 pro Ubuntu 16.04 LTS pro předplatitele podpory Ubuntu Advantage Advanced. Certifikace FIPS (Federal Information Processing Standards) jsou vyžadovány (nejenom) vládními institucemi USA.

Ladislav Hagara | Komentářů: 3
včera 16:11 | Zajímavý software

Společnost Avast uvolnila zdrojové kódy svého dekompilátoru RetDec (Retargetable Decompiler) založeného na LLVM. Vyzkoušet lze RetDec jako webovou službu nebo plugin pro interaktivní disassembler IDA. Zdrojové kódy RetDec jsou k dispozici na GitHubu pod open source licencí MIT.

Ladislav Hagara | Komentářů: 3
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (8%)
 (1%)
 (1%)
 (1%)
 (76%)
 (14%)
Celkem 997 hlasů
 Komentářů: 45, poslední 1.12. 19:00
    Rozcestník

    Optimalizácia bootovania Linuxu na ARMe

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