PINE A64

Na Kickstarteru běží kampaň na podporu miniaturního jednodeskového počítače PINE A64 s 64bitovým čtyřjádrovým procesorem ARM A53. Za 15 dolarů lze získat verzi s 512 MB DDR3 SDRAM a 100 Mb Ethernetem. Za 19 dolarů verzi s 1 GB SDRAM a 1000 Mb Ethernetem. Za 29 dolarů verzi s 2 GB SDRAM. Případné dotazy na fóru.

11.12.2015 02:34 | Ladislav Hagara | IT novinky

Komentáře

[pc2005]

Mali-400 (no nic moc), Allwinner A64 SoC, datasheet s registrama (702 stránek na moderní SoC se mě zdá málo - superstará PXA27x jich má 1200). Ale jinak docela dobrý až neuvěřitelný jak může bejt nízká cena kompa (heh zvlášť když teďka někdo prodává na aukru 9 let starej core2duo druhý-třetí nejrychlejší model za 800Kč a to je nejlevnější cena ) .

[Spike]

Ta cena u Allwinneru není snad ani moc překvapivá. Ale jejich vztah k dodržování GPL je celkem proslulý. A nejsem si jistý, jestli je ještě nějaká aktivita kolem ovladače Lima pro Mali-400.

[Rezza]

No a hlavne to nema ani UEFI, ani ACPI...

[Spike]

A to je dobře, nebo špatně? :)

[Rezza]

No to je spatne - proste ideal jsou svobodne ovladace a standardizovany HW. Pak pripichnu USB a nabootuji co chci ja bez dalsich opruzu. Proste jak to rika jcm - ma to byt uplna nuda z pohledu SW. Zajimave se ma dit na urovni HW.

[Václav "Darm" Novák]

Škoda že se kdysi Intel vykašlal na ARM, tam bych přesně takové vlastnosti čekal…

[pc2005]

Škoda že se kdysi Intel vykašlal na ARM

Naštěstí, že se vykašlal. USB řadič porušující USB specifikaci (a to je Intel jeden z původních developerů, co USB vymysleli). Vlastní instrukční sada a navíc bez kompilátoru . Nastavování frekvence SoC ve speciálním registru (jak triviální z něj udělat read-only). A z ohledu bootloaderu? Každej si vyráběl vlastní (HTC mělo dost ošklivej).

[Václav "Darm" Novák]

Je fakt že jediné zařízení s intelím Armem co jsem viděl byl starý Sharp Zaurus a tam jsem instrukční sadu nějak nezkoumal. Jen jsem tak nějak předpokládal že mimo CPU by kolem toho Intel v dnešní době nasadil technologie které už používá u x86 (uefi a možná i GPU s otevřenými ovladači)

[pc2005]

Instrukční sada iwmmxt je prý okopírovanej MMX z x86, ale opkódy jsou částečně stejný jako normální ARM FPU. Dokonce na to bylo jednou speciální ABI (~ typ ELF binárky). Opkódy jdou v gcc použít jen jako makra nebo přímo inline assembler. Na rozdíl od toho má pro x86 gcc normálně volbu -mmmx. I když tohle by asi šlo přidat, pokud by se nepřešlo na NEON.

On je vývoj bootloaderu stejně většinou na vendorech, hlavně protože většina si ten SoC chce zamknout. Ledaže by v tom UEFI byl povinně secureboot a tajné klíče (což je to, o co se snaží(l) MS v té ARM UEFI specifikaci).

i GPU s otevřenými ovladači

Intel Poulsbo (GMA 500) .

[Rezza]

Tak minimalne serverovy svet 64-bit ARMu bude dle SBSA a SBBR.

[pc2005]

To tam nemaj u-boot?

[Saljack]

Tak smutne je, ze to Mali-400 jde spatne i s tema jejich ovladacema viz Orange PI. Je to fakt smutne, ze nejsou schopni poskytnout funkcni ovladac pro aktualni jadro.

[mirec]

Čo na nich ide zle? Ovládače sú open source, nevidím problém prečo by sa nemali dať portovať na novší kernel (teda okrem toho, že komunita namiesto písania kódu narieka nad tým aká je mizerná podpora).

[Spike]

Kde je ten zdrojový kód, který stačí portovat na novější kernel? Nebo alespoň dokumentace od výrobce?

[mirec]

Tu je zdrojový kód, dokumentáciu pokiaľ viem nemá poriadne nikto (číňania sú dosť prasce). Zdrojové kódy sú pod GPL. Closed source je len userspace knižnica libGL.so (libMali.so), ale samotný kernel driver je open source.

[mirec]

Trochu novšia verzia je napríklad tu. Kedysi mali samostatnú stránku s drivermi pre linux, ale od kedy zmenili dizajn webu neviem ju nájsť. Na požiadanie by mali stále dodávať zdrojové kódy.

[Spike]

Měli… Allwinner zrovna na to celkem peče, nebo je vydává nekompletní, planě slibuje apod.

Jinak shodou okolností na Phoronixu někdo tvrdil, že ten zdrojový kód pro Mali nikdy nevydali, tak mě to zaujalo.

[mirec]

Mnoho ľudí si mýli driver s userspace implementáciou libGL. Väčšinu ťažkej práce odvádza práve propietárna libGL od ... no to to je celkom zaujímavá historka, v každom prípade libGL je binárna a na rozdiel od tej z mesa robí ťažkú prácu. Kernel driver je open source a poskytuje vlastne len rozhranie do pamäte a nejaké tie low level veci okolo inicializácie, napájania, vlastne je toho celkom dosť. Portovať kernel driver na novšiu verziu kernelu je možné keďže zdrojáky sú dostupné. Userspace knižnicu libGL nie je potrebné (ani možné) portovať.

Ešte aby som sa vrátil k libGL. Po internete kolujú pre linux 2 implementácie. Jedna je od allwinneru (používajte si ako chcete, nie je tam EULA) a druhú vydáva odroid (je novšia a má EULA, ktorá zakazuje použitie na komerčné účely alebo použitie libGL.so na iných doskách než sú ich oficiálne). Uznávam, som vinný lebo používam odroid driver na inej doske a ešte k tomu som si musel kernel driver trochu upraviť aby vôbec fungoval s mojim hardvérom (úpravy mám niekde hodené na githube).

Takže aby som to zhrnul: zdrojáky sú, portovať sa to dá len to nemá kto urobiť.

[pc2005]

Pokud exportuješ registrové okno do userspace a v userspace ty registry nastavuješ v binárním blobu, tak to určitě není opensource driver a navíc to dost narušuje bezpečnost. Mám dojem, že něco takovýho dělá i nvidia blob.

[mirec]

Ja považujem za driver iba kernelovskú časť. Sadu registrov sprístupňuje napríklad aj GPIO driver, ale nikto nenazýva program, ktorý rozbliká LED driverom.

Čo sa týka prístupu mali ku komunite ... no sú aj lepšie firmy a sú aj horšie. Samotný blob libGL.so sa mi tiež nepáči. Škoda, že nikomu neuniklo Mali DDK, veľmi rád by som si pozrel čo tak hrozné skrývajú.

[pc2005]

Problém je, že pokud dostaneš od kernelu jen bázovou adresu a délku IOMEM okna, tak ti to je dost k ničemu. Abys byl schopen ty registry v tom okně ovládat, tak potřebuješ něco, co umí daný hardware řídit - tedy driver. U některých HW je ještě vtip v tom, že ty registrová okna můžou být kaskádně propojená.

Například SuperIO komunikuje se systémem jen přes dva IO registry 0x2e a 0x2f (~ tvoje definice kernelové části). Pomocí nich ale můžeš pracovat s interníma registrama toho SuperIO, kterých může být třeba stovka. S 0x2e/0x2f v kernelspace se nedostaneš ani tak daleko abys byl schopen v kernelu detekovat typ SuperIO čipu. Veškeré ovládání a řízení přístupu by bylo nutné v userspace.

Jinak co se týká obecné definice driveru, tak si IMO nemyslím, že to vůbec souvisí s nějakým rozdělením na kernel/user space.

Rozhodně by bylo dobré, kdyby všechny části pro Mali GPU byly opensource (abych byl schopen vkládat debugovcí asserty třeba do ovládaní grafické pipeline) a ideálně dokumentované.

[mirec]

Z userspace pochybujem, že zverejnia niečo viacej než .o (tie sú dostupné mimochodom z tizen SDK). Dôvod prečo celý nie je open source netuším, mali 400 je už poriadne stará, pochybujem, že by im utajovanie zdrojákov v tejto fáze zabezpečilo nejakú konkurenčnú výhodu.

[Václav "Darm" Novák]

A je to celé jejich? Aby tu nebyl klasický problém "nemůžeme to otevřít, protože ostatní firmy nechtěj"

[pc2005]

Mali je od ARMu, tak to může otevřít on. Ale nevím zda neprodává i zdrojáky, to by si to pak výrobce mohl upravit a dokumentace od ARMu by byla k ničemu.

[mirec]

Zdrojové kódy sú dostupné výrobcom SoC.

[Jiří J.]

Eh, čím že se liší od toho milionu ostatních ARM desek?

[saly]

Od boku třeba 64-bit a 4K HDMI.

[Huncut]

Naco mi je 64bitovy procak pri max. 2 GB RAM a načo mi je 4K output ked to pri MALI 400 nezvladne prehrat 4K film

[Sid]

Co moze byt uzasnejsie ako spustit si vystup z terminalu na 4K? Hned aj obycajny script posobi cool v 4K.

[tmysik]

Nejsem HW expert, ale píšou tam, že:

Naco mi je 64bitovy procak

vyšší výkon + nižší spotřeba

načo mi je 4K output ked to pri MALI 400 nezvladne prehrat 4K film

by to přehrát mělo:

"The Pine A64 GPU is dual-core MALI-400 MP2 and runs at 500MHz, capable of 1.1 Gpixel/s throughput. Graphics capabilities are slightly higher than the original Xbox’s level of performance. The GPU provides OpenGL ES 2.0, hardware-accelerated OpenVG, 4Kx2Kp30 H.265 decode, and 1080p60 H.264 high-profile encode and decode."

[mirec]

S 512MB zdieľanej RAM 4k nezvláda. Ja mám 1GB zdieľanej RAM a ledva sa zmestím. Trochu matematiky:

Rozlíšenie 3840 * 2160 * 4 (4B na pixel) * 16 (16 referenčných rámcov pre h.264) = 500MB rezervovanej video pamäte pre referenčné rámce. To ešte nemáme pamäť pre framebuffer (zvyčajne dvojitý), video dekóder, operačný systém, samotné OpenGL ...

[Spike]

Tak píšou:

PINE64 provides almost full motion playback of up to 4K H.265 high-definition video.

:D

[Ovocníček]

1) - HEVC nepodporuje 16 referenčních snímků, jen 8, a to ve všech levelech. Víc už by bylo mimo specifikaci a takovéto dekodéry to asi budou odmítat?

2) - počítat 4 byte na jeden pixel je chyba. Všude se používá barevný prostor YUV s podvzorkováním 4:2:0. Kanály U/V jsou vzorkovány s čtvrtinovým počtem pixelů proti lumě. Tudíž u osmibitového videa se spotřebuje 12 bitů na pixel, u Main 10 (dejme tomu, že je to uloženo všechno v 2 bytech, bez nějakého pakování) pak 3 byty.

[little.owl]

Output je obvykle ARGB32, tedy 4B na pixel a pro ping-pong s display controllerem potrebujete minimalne dva buffery za podminky ze je mozne dekodovat frame s cca +3ms predstihem. Ano, vstup je obvykle YUV420/NV12, takze 1.5B na pixel.

[Ožralý Izidor]

Výstup na obrazovku ale není to, o čem on mluvil, Dekodér si i ty referenční snímky musí držet v natvincím formátu, tedy YUV 4:2:0 buď s hloubkou 8 bitů, nebo 10 u dekodérů Main 10 HEVC. Výstup ze samotného dekodéru je bude YUV, GPU ho převede na RGB až jako poslední věc ve škálovači.

Možná, že nějaká optimalizovaná implementace by to dokázala posílat do LCD i rovnou z YUV, protože ta konverze se dá dělat on the fly po jednom pixelu. Ale jak se to obvkyle implementuje v praxi, to nevím.

[Ožralý Izidor]

*nativním.

Jo a jinak, zapomněl jsem to říct, ale H.264 ten SoC umí dát jenom v 1080p (a to ještě nevíme, jestli to těch 16 dává), proto jsem upozornil, že těch 16 * 4K není třeba, ve 4K to zvládá akorát HEVC.

[24horas]

Za predpokladu, ze mas ovladace, coz je u Allwinner a Mali HW v Linuxu proste problem. Na tom jde pouzivat akorat Android.

[Spike]

Asi tak.

Pokud někdo náhodou nezná… linux-sunxi.org

[Sid]

ktore ale casto zkompilujes na jadre ktore je asi tak aktualne ako niektore v routroch :)

[pc2005]

Naco mi je 64bitovy procak pri max. 2 GB RAM

Prej lepší instrukční mix.

[biolog]

Můžeš mít efektivní ASLR. A 64TB swapu.

[Jendа]

Naco mi je 64bitovy procak pri max. 2 GB RAM

Abys mohl jednou instrukcí zpracovat 64 bitů.

a načo mi je 4K output ked to pri MALI 400 nezvladne prehrat 4K film

Abys mohl statické informace zobrazovat ve vysokém rozlišení.

[little.owl]

Tam nejde jen o 64 bitu, je to novejsi architektura, vetsim poctem registru pocinaje, pres efektivnejsi instruckcni set ci multicore cache management.

[Saljack]

Ono totiz v tech procesorech je jeste CedarX, ktery provadi dekodovani videa. Ovsem v Linuxu je to stejne naprosto k nicemu. Celkem by me zajimalo, jestli na tom opravdu Ubuntu pobezi vcetne vsech ovladacu.

[Václav "Darm" Novák]

Ta gigabitová síťovka taky potěší.

[Jendа]

Je to levnější a rychlejší. A možná to má horší podporu v Linuxu než třeba Raspberry.

[Bystroushaak]

Není mi jasné, proč to nemá SATA, nebo nějakou alternativu přes kterou by se dal připojit disk. Takhle je to pořád v podstatě hračka, místo aby z toho byl ideální domácí server.

[Petr Tomášek]

Další "klon Raspberry Pi", kterej si ničím podstatným neliší. Kua, kdy už někdo udělá podobnou desku s 1Gbit ethernetem, 802.3af/at a mSATA?

[Rezza]

V ramci 96boards budou i enterprise desky. Otazka je kdy a za kolik - uz jsem slysel hodne datumu... Tohle jsou totiz fakt veci, kdy se veme nejaky mobilni SoC a to je vse.

[Petr Tomášek]

Pro mě za mě ať je to klidně „nějaký mobilní SoC“. Koneckonců to vzhledem k otázce, zda to má PoE dost irelevantní... A SATA se tam dost čast najde taky...

[AsciiWolf]

+1

[janc1]

Ja cakam na nove apu od pcengines. Je to sice drhsie ale vyzera to dost dobre. Zatial niesom uplne rozhodnuty.

[Conscript89]

Ctu si tak titulek a rikam si ze nekdo rozjede fork emailoveho klienta a ono nic, jen dalsi arm deska. Sice s ARMv8-A, ale urcite zase bez UEFI, takze nezajimavy...

[pc2005]

To si tam UEFI nemůžeš nakompilovat?

[Rezza]

Tak da se udelat shim nad uktualnim bootloaderem a pak tianocore, ale proste je to ted krok navic, kvuli kteremu proste uefi a acpi je. Stahnu jedno aarch64 ISO, hodim trebas na flashku a instaluji. Nezajima me, co je to za krabicku.

[pc2005]

Osobně bych nechtěl monolit lowlevel init bootloaderu a implementace UEFI rozhraní. Klidně by to ale výrobce mohl zkombinovat a dát to do toho bootloaderu. Jinak pro ISO nepotřebujes plnohodnotný UEFI. A pro boot nepotřebuješ UEFI vůbec (=další věc co se může pokazit).

Každopádně coreboot má strašně malou podporu, nejspíš nejsou lidi :-/.

[Ondrej Santiago Zajicek]

Tohle by mel v zajistit uz flattened device tree, neni k tomu treba obludne UEFI.

[Rezza]

To zajisti ACPI.

[Rezza]

Pekne to napsal JCM - clovek, co za tou standardizaci stoji a bez neho by mozna nebyla. Neni to jen ACPI, UEFI, ale taky upstreamovani driveru, atd. Kazde z toho zvlast se da nejak nahradit, ano. Ale dohromady z toho proste bude jen dalsi nudna architektura, kdy jedny bity pobezi vsude bez zadne magie.

[pc2005]

ACPI je fuj .

[little.owl]

zajistit uz flattened device tree

Z blata do louze.

[Ožralý Izidor]

Tyjo, pine jsme používali ve škole v roce 1998. Telnet na školní server, pine. Byla to legrace, ale zároveň děsná věc, když si vezmu, že v tu chvíli existovaly rozumné klienty a normální webmaily.

[kyknos]

ja pouzival pine jeste v tomhle stoleti... pak jsem z nej presel na gmail :)

[kyknos]

jo pine, na opravdovym unixu, bez systemd, to byly casy :)

[Odin1918]

S 2 GB RAM to zacina znit celkem zajimave.