MK802 (Android 4.0 Mini PC) + Linux

[Gargamel]

Wayland nema ohlaseny ziadny support vyrobcov HW, naopak, zamietnuty napr. priamo nVidiou... Waylandom bud pochovas kompatibilitu s terajsimi X aplikaciami, alebo ich spomalis (kedze to pojde este cez jednu vrstvu)... Achjo...

Jisteze nema, taky nepotrebuje, protoze diky chytremu navrhu grafickeho stacku ma podporu uz ted. Jedine, co odpadne, je DDX driver X.org, zbytek stacku zustava a vyuziva se. Tzn. DRM, Mesa, input drivery (ktere byly nedavno odstepeny a zuniverzalneny od X.org stacku). Nativni podporu nejpouzivanejsich toolkitu uz mas ted, stejne uz temer vsechno bezi na Cairu. Takze ti zbyde radove nekolik aplikaci vyuzivajici legacy X protokol, ktere bez problemu budou fungovat pres kompatibilni vrstvu.

Jedine nebezpeci vidim v zadratovani Xlibu kvuli drobnostem - zejmena X extensions. Je to nesvar, ktery pujde lehce odstranit, ale tech hacku je kolem kopa a potrva, nez se to vsechno opravi.

To, ze je to zamitnute nVidii, je jen srani do vlastnich kalhot. Nouveau je na dobre urovni uz ted, s Waylandem chodi bez problemu. Vyjimkou budou samozrejme specifike aplikace typu HPC, OpenCL/CUDA a dalsi, kde se hojne vyuziva binarnich GL knihoven. Jsou to ale aplikace usite na miru, vetsinou pro enterprise segment, ktery je sam o sobe dost specificky.

Kdyby ses o to zajimal vic, muzu ti poslat nejake zdroje, nedavno nam Kristian delal interni prednasku, nevim jestli uz nekde visi verejne, ale vicemene to bylo podobne jako jeho talk na FOSDEMu.

Proste akokolvek mam ako pouzivatel Linux rad na serveroch, tak ho musim nenavidiet na desktope ...

Porid si vhodny HW a budes ho milovat

[PiT]

Dakujem za obsirne vysvetlenie.

Porid si vhodny HW a budes ho milovat

Ma MK802 nejaku vhodnu alternativu?

[Gargamel]

Poridil jsem si http://cubieboard.org/ jakozto alternativu Raspberry Pi s vyssim vykonem a vybavou. Oproti Raspberry ma vyssi ARM core, lip resenou sitovku a take SATA port. Planoval jsem to jako levne HTPC reseni a vkladal jsem velke nadeje do HW dekodovani videa.

Zarizeni ma na sobe 4GB NAND Flash, ve kterem je nahrany Android. Obsahuje taky microSD slot, ktery dostava pri bootu vyssi prioritu (ale da se nastavit v bootloaderu). Boot ze SATA primo AFAIK neni zatim podporovany, ale to se da jednoduse obejit umistenim jadra jinam a jen zmenu root device v kernelu. SATA je reseno driverem "sw_ahci", ve kterem ta pritomnost "SW" budi trochu rozpaky. Ale to je u ARMovych SoC bezne, polovina veci se resi za pomoci SW/driveru nebo navesenim interne na USB. Kolega k tomu pripojoval starsi SSD Intel 80GB, realna rychlost zapisu byla kolem 60MB/s, cteni bohuzel netestoval. Nicmene i to staci, sitovka na desce je jen 100Mbit. Slot na microSD je SDXC, bohuzel bezi v defaultu jen na 24MHz pri 4bitech, tzn. 12MB/s. Bude se jeste tunit.

Android bezi a to je tak asi vsechno, co o nem muzu rict. Nepochopil jsem ovladani toho systemu ani zpusob, jak treba namountovat NFS a prehrat film (jakysi interni prehravac ani nenabidne vyber souboru). Prepinani HDMI modu chodi, sitovka taky, audio skrze HDMI pipa, animace jsou plynule... Pro me je to zkratka blackbox.

Bootovani do linuxu je jednoduche, na SD kartu nebo do NAND Flash na specifikovanou adresu se nahraje bootloader "u-boot" vc. HW konfigurace, ten pak hleda prvni partition na danem mediu na urcite adrese (prvni partition musi zacinat az dal na mediu a je to boot partition), na ktere je bootloader skript a jadro. Ve skriptu se daji nastavit dalsi HW parametry, treba rozliseni HDMI, pamet, adresy zarizeni, MAC sitovky atd. Kernel a bootloader se buildi zvlast oproti rootfs, k dispozici jsou ruzne predpripravene buildy pro ruzne zarizeni a je to vzdy sada bootloader, boot skript, jadro, moduly a par souboru v /etc s konfiguraci modulu pro dane zarizeni.

Rootfs si clovek stahne separatne podle toho, co tam chce. K dispozici je napr. Linaro (Ubuntu), Fedora, Debian, Gentoo, Archlinux atd. Ja zvolil Debian, ma primo armhf port. Takze krome jadra je vsechno distribucni. Bezi to vcelku pekne, dodavane drivery jsou dostatecne. Funguje zvuk, sit, infra, dynamicke skalovani frekvence, SATA, USB atd. V baleni CubieBoardu je dodavan USB-to-serial prevodnik a je pripojeny na UART do desky, takze clovek ma primy pristup do bootloaderu a konzoli systemu. Na http://linux-sunxi.org/ je pekna wiki k rodine Allwinner s popisem, jak to vsechno rozchodit.

Vsechno tohle mi bezi napajene z USB. Nominalne deska potrebuje 5V 2A a to hlavne kvuli napajeni SATA disku (v baleni je i kabel vc. napajeni). CPU jsem pretaktoval na 1.20GHz a bezi stabilne, da se az na 1.50GHz, ale chce to asi lepsi zdroj prip. maly pasivek na cip. Luxus je to vsechno ovladat pres standardni cpufreq nastroje.

Akorat je trosku problem s grafikou, ale to se dalo cekat. SoC obsahuje GPU Mali 400, ke kteremu jsou v dodavanem kernelu potrebne drivery. HDMI mod je zatim potreba nastavit pred bootem, podle toho se alokuje pamet framebufferu z RAM (da se i nastavit, jak velka). Neco jako Xrandr zatim nema podporu. Zmena rozliseni za behu je zatim jen hack. Graficka konzole je resena driverem mali_drm, zaklad pro akceleraci tedy mame. Xorg normalne bezi a to bud pres fbdev driver (ktery obstarava mali_drm) nebo primo pres xf86-video-mali, ktery sice hlasa podporu EXA, ale v praxi je obcas pomalejsi, nez fbdev. DRI driver pro OpenGL neexistuje a mam taky pocit, ze Mali podporuje jen subset OpenGL, OpenGL ES. Takze na standardni Xkove OpenGL muzeme rovnou zapomenout, muselo by se to resit SW fallbackem.

K dispozici jsou GLES knihovny, ktere muzou aplikace vyuzivat. Stejne tak jsou k dispozici knihovny pro CedarX, coz je engine HW dekodovani videa. Vyzkousel jsem XBMC a VLC, oba s dohackovanou podporou pro GLES a CedarX. XMBC se kompilovalo cca tri hodiny (oproti deseti minutam na quadcore Xeonu), VLC asi hodinu a pul. Obe aplikace je nutno poustet na konzoli, bez X, protoze prostrednictvim zminenych knihoven pristupuji primo k HW a mlatily by se s X serverem. XBMC najede (zkouseno v 1080p) do plynuleho akcelerovaneho prostredi a zjevne pouziva i HW dekodovani videa. Ovsem ten vykon je dost na hrane, v 1080p dostavam cca 29fps v idle, v 720p nejakych 56fps. Jakmile se pusti narocnejsi video, framerate klesa pod uroven potrebnou pro film. Muze za to zrejme system bufferovani a dekodovani dopredu, viditelne se to kazdych 3-5 sekund trha vic. Trhanost je stejna pri ruznych bitrate videi, je jedno, jestli je to 10Mbit nebo 50Mbit/s. Takze dekodovaci engine zrejme zvlada. Problem muze byt zvuk, ktery se dekoduje SW nebo zpusob vykreslovani pres GLES. VLC je opet konzolove a nema ani OSD. Prehravani je ale plynule, vlivem nejakeho bugu se kousne po par sekundach, asi nejaka race condition. Mplayer je mimo hru, nema podporu pro CedarX.

Takze v soucasne dobe je prehravani videa nemozne, board je na trhu teprve velice kratkou dobu, nekteri jej jeste ani nedostali. Pokud se vytvori komunita jako kolem Raspberry Pi, verim, ze se SW podpora zlepsi. Ale muze to trvat treba rok. Lima driver jsem nezkousel, neda se zatim poradne zkompilovat.

Jeste pro porovnani vykonu obligatnim testem openssl (je to single thread test):

                            type     16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
CubieBoard @ 1.20GHz:       md5      4926.74k    20025.43k    56566.52k   100769.16k   132149.61k
Xeon X5460 @ 3.16GHz:       md5     43202.41k   140334.63k   312750.68k   381595.31k   430858.10k
CuBox @ 800MHz (Gentoo):    md5      2703.27k     9465.54k    26972.16k    50259.97k    67373.74k
Raspberry Pi (unoptimized): md5       380.13k     1501.12k     4800.77k    11312.81k    21682.77k
Raspberry Pi (optimized):   md5      1954.05k     7217.96k    20805.95k    39365.29k    53226.15k

http://www.abclinuxu.cz/clanky/prvni-dny-s-cuboxem
http://elinux.org/RPi_Performance