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 00:55 | Nová verze

Po téměř 13 měsících vývoje od verze 0.11.0 byla vydána verze 0.12.0 hardwarově nenáročného desktopového prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklého sloučením projektů Razor-qt a LXDE. Přehled novinek v příspěvku na blogu.

Ladislav Hagara | Komentářů: 9
včera 12:33 | Zajímavý software

Článek ne Medium představuje nejnovější stabilní verzi 2.0 svobodné decentralizované mikroblogovací platformy a sociální sítě podobné Twitteru Mastodon (Wikipedie). Detailní přehled novinek na GitHubu [Hacker News].

Ladislav Hagara | Komentářů: 0
včera 06:00 | Komunita

V Praze na půdě Elektrotechnické fakulty ČVUT dnes probíhá RT-Summit 2017 – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt. Přednášky lze sledovat online na YouTube.

Ladislav Hagara | Komentářů: 0
20.10. 14:33 | Zajímavý projekt

Blender Animation Studio zveřejnilo první epizodu z připravovaného animovaného seriálu The Daily Dweebs o domácím mazlíčkovi jménem Dixey. Ke zhlédnutí také ve 3D s rozlišením 8K.

Ladislav Hagara | Komentářů: 0
20.10. 12:34 | Komunita

Aktualizovanou počítačovou hru Warhammer 40,000: Dawn of War III v ceně 39,99 eur běžící také na Linuxu lze o víkendu na Steamu hrát zdarma a případně ještě v pondělí koupit s 50% slevou. Do soboty 19:00 lze na Humble Bundle získat zdarma Steam klíč k počítačové hře Sid Meier's Civilization® III v ceně 4,99 eur běžící také ve Wine.

Ladislav Hagara | Komentářů: 0
20.10. 00:22 | Nasazení Linuxu

Společnost Samsung oznámila, že skrze dokovací stanici DeX a aplikaci Linux on Galaxy bude možno na Samsung Galaxy S8 a S8+ a Galaxy Note 8 provozovat Linux. Distribuce nebyly blíže upřesněny.

Phantom Alien | Komentářů: 19
19.10. 23:55 | Komunita

Společnost Purism na svém blogu oznámila, že její notebooky Librem jsou nově dodávány se zrušeným (neutralized and disabled) Intel Management Engine (ME). Aktualizací corebootu na již prodaných noteboocích lze Management Engine také zrušit. Více v podrobném článku.

Ladislav Hagara | Komentářů: 2
19.10. 21:44 | Nová verze

Organizace Apache Software Foundation (ASF) na svém blogu slaví páté výročí kancelářského balíku Apache OpenOffice jako jejího Top-Level projektu. Při této příležitosti byl vydán Apache OpenOffice 4.1.4 (AOO 4.1.4). Podrobnosti v poznámkách k vydání. Dlouhé čekání na novou verzi tak skončilo.

Ladislav Hagara | Komentářů: 7
19.10. 19:22 | Pozvánky

Již příští týden - 26. a 27. října se v Praze v hotelu Olšanka odehraje OpenWRT Summit. Na webu konference naleznete program a možnost zakoupení lístků - ty stojí 55 dolarů. Čtvrtek bude přednáškový a v pátek se budou odehrávat převážně workshopy a meetingy.

Miška | Komentářů: 1
19.10. 13:44 | Nová verze

Bylo vydáno Ubuntu 17.10 s kódovým názvem Artful Aardvark. Ke stažení jsou Ubuntu Desktop a Server, Ubuntu Cloud Images, Ubuntu Netboot, Kubuntu, Lubuntu a Lubuntu Alternate, Lubuntu Next, Ubuntu Budgie, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio a Xubuntu. Podrobnosti v poznámkách k vydání.

Ladislav Hagara | Komentářů: 25
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (10%)
 (1%)
 (1%)
 (1%)
 (75%)
 (13%)
Celkem 186 hlasů
 Komentářů: 7, poslední 19.10. 23:06
    Rozcestník

    Optimalizácia bootovania Linuxu na ARMe

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