Jaderné novinky – 7. 4. 2011: Nepořádek způsobený divokým rozvojem ARM (diskuse)

[Petr Tomášek]

což vede na plýtvání ⇒ k

[Patrik Uhrak]

Mobilní prostor je o proprietárních ovladačích

-- Mark Charlebois, Qualcomm Innovation Center (na přednášce na Linux Foundation Collaboration Summit)

Myslim, ze zozal nesmierny uspech. Kazdopadne, ak tym mysli, ze je nutne si nainstalovat windows (odsuhlasenie licencie == zaplatenie v idealnom svete), kde povolite urcite funkcie, lebo inak je to len nepouzitelny kus kremiku. Plus to, ze firmware sa distribuuje len pre windows a nie je ho mozne distribuovat dalej podla ich licencie. Mam tedka na mysli Gobi 2000 od Qualcomm a nerobim si iluzie, ze cokolvek z ich ruk bude o moc privetivejsie po takychto vyhlaseniach. Cokolvek skonzumol, uskodilo to.

 

Ale aby som nebol nespravodlivy, tak nie su jediny (intel 3945 na dell xps ma rovnaku featuru ohladne nutnosti pouzitia windows jednorazovo pre jeho zapnutie a dalsi urcite pribudnu), ale nech aspon neprovokuje.

[Sten]

Ještě před pár lety mohl někdo jiný říct to samé o x86 nebo USB zařízeních. Situace se ale razantně změnila a dneska máme mnoho hardware používající obecné a tedy i otevřené ovladače (SATA řadiče, USB sítě, USB PTP, ty debilní „samoinstalační“ USB věci tvářící se před přepnutím jako flash disk, ...). A myslím, že v mobilní oblasti to bude ještě daleko rychlejší.

[Grunt]

kde povolite urcite funkcie, lebo inak je to len nepouzitelny kus kremiku

Tak až zas tak razantní to není. Ale třeba Cortexy-?{0-9} poskytují nativní vykonávání Java bytekódu přímo na procesoru (Dřív Jazelle, teď už ví čert jak se to jmenuje; jinak je to logické – OMAP je mobilní platforma a nějaká ta mobilní Java tam stále frčí) a bez nějakého toho propritárního ovladače poskytovaného jen velkým výrobcům mobilních zařízení je to nefunkční. No furt je možné SW emulovat pomocí OpenJDK (zas kdo ví co to je OpenJDK na nějakém 500-800Mhz Cortexu ví do jaké míry je to funkční). Stejně jako když někdo nechce používat uzavřené OpenGLES knihovny, může emulovat SW pomocí Mesy (znova, kdo ví co je to SW render MESy na 3Ghz x86 asi má představu jak to musí fungovat na tom Cortexu). Nebo třeba když někdo nechce binární BIOS a moduly do DSP, může dekódovat pomocí mplayeru nebo gstreameru.

[Patrik Uhrak]

Ja sa tu nesnazim o nejaku revoluciu, ale tak wifi karta intel 3945 v dell xps sa nedala nijako inak zapnut, len ze sa spustili windows a tam sa zapla. Stacilo tak spravit len raz v zivote tej karty. Terajsia Gobi 2000 je na tom o trosku lepsie, lebo bez windows by mi nefungovalo "iba" GPS. Lebo tu mame wine, kde je nastastie mozne ziskat firmware z ovladacu pre tu kartu. Ale naco si kupovat nieco s GPS, ked to nie je mozne spustit. A keby som chcel byt velice poctivy, tak by som si musel dokupit windows alebo odsuhlasit aspon licenciu.

Skutocne, pri oboch tychto zariadeniach som stravil nejaky nemaly cas hladanim riesenia a vzdy bolo iba jedno a to viedlo cez windows. Pozri na thinkwiki alebo na inych weboch o Gobi 2000 a urcite najdes aj o dell xps 1530 ci tej karte samotnej.

[pc2005]

No všechny tyhle věci jsou ale aspoň minimálně dokumentované. Do DSP si zkompilovat vlastní firmware, bytekódy asi budou taky. OpenGL nevím, neboť jsem nezkoumal. Tam by mohl být problém, protože grafiku má TI licencovanou odjinud.

U mobilů bude hodně velký problém to, že dovolit otevřený ovladač pro vysílací část, si nikdo z výrobců netroufne .

[Grunt]

No všechny tyhle věci jsou ale aspoň minimálně dokumentované.

Jasně. Tohle je proti x86 docela rozdíl.

Do DSP si zkompilovat vlastní firmware

To jo.

bytekódy asi budou taky.

Jak pro co? Pro Jazzele? Tak to právě nevím a aspoň já o ničem nevím. Link by byl náležitě oceněn.

OpenGL nevím, neboť jsem nezkoumal.

Na tom není co zkoumat. SDK (tedy nějaké halavičkové soubory) pro GLES jsou otevřené k vývoji, ale samotné jádro je uzavřené (jaderná část zobrazovadla je zas otevřená).

U mobilů bude hodně velký problém to, že dovolit otevřený ovladač pro vysílací část, si nikdo z výrobců netroufne

O tom se nebavím vůbec. Že pro OMAPy a jiné ARM platformy existuje i nějaký GSM modul ignoruju úplně, protože to je dílo čertovo.

[pc2005]

Do DSP si zkompilovat vlastní firmware

To jo.

Wow dokonce maj i jádro co na tom běží . Myslím, že původně bylo c64x proprietární, ale teďka si to nemůžou dovolit imho, jednak dělaj SoC jen s c64x jádrem, jednak jich dělaj hodně a jednak pro věci, kde na minimálních chybách hodně záleží. Osobně bych řekl, že trh je donutil. Jakmile na c64x (vlastně c6x jenom) poběží linux, tak ta platforma prostě nemůže být zavřená (a že by jejich BIOS tomu linuxu emuloval prostředí o tom pochybuju ).

Jak pro co? Pro Jazzele? Tak to právě nevím a aspoň já o ničem nevím. Link by byl náležitě oceněn.

Nový cortexy maj tu Jazelle jen softwarově emulovanou. Thumb2 je podporován GCC. ThumbEE (Jazelle RCT = Thumb2 + vylepšení v JIT nasazení) je podporován v jádru.

Na tom není co zkoumat. SDK (tedy nějaké halavičkové soubory) pro GLES jsou otevřené k vývoji, ale samotné jádro je uzavřené (jaderná část zobrazovadla je zas otevřená).

Aha takže v případě Imagination SGX5, který je hardwarový je i to API proprietární? Hmm tak to by byla škoda. Jinak by šlo vykašlat se na proprietární nebo softwarový kernel a udělat si wrapper mezi hardwarem a GLES hlavičkama - imho minimální.

Osobně jsem čekal, že c64x nebude otevřený natolik aby na něm běželo jádro a u 3D akcelerátoru jsem určitou proprieraritu čekal (je to jen licencovaný IP core - od nějaké "neznámé" firmičky ). Jazelle je problém, ale jestli je něco lepšího, tak OK. Teď otázka jak otevřenost zvýšit. Maximálně mě napadá buď prudit vlastníky práv nebo TI (a spol) navrhnout openHW core .

[Grunt]

Celý bordel v ARM architektuře nejlépe podtrhují Linusove komentáře #1 a #2. Kdyby člověk nevěděl o koho jde, tak by si normálně řekl, že má tu čest s nějakým dlaždičem.

[Grunt]

Celý bordel v ARM architektuře

Teda ať se opravím – Ne v architektuře jako takové (ale i tam je docela slušný bordílek), ale právě v arch stromu v Linuxu a různých subarchitekturách.

[Sten]

Ale on ten bordel je v samotné architektuře, přesněji samotná architektura způsobuje, že tam ten bordel vzniká. x86 má taky takový bordel v deskách, přesto se objevily standardy jako ACPI (na který tedy Linus tady nadává) a všechno to nějak rozumně nastaví BIOS (nebo UEFI). Na ARM nic takového není — všechno musí nastavovat jádro a proto je v jádře tak strašný bordel. Chybí tam prostě něco, co to nastaví (Linus tomu říká bootloader), aby se jádro nemuselo zabývat tím, jakou přesnou verzi desky tam zrovna výrobce dal a na jaké porty má poslat jaké příkazy, aby ji vyresetoval a spustil tak třeba řadiče úložiště.

[Grunt]

Zas než BIOS nebo nějaký bootloader (u Broadcomackých boardů se to jmenuje CFE), tohle mi přijde trošku lepší. Jen by se ty boardfajly mohly vyházet do nějakého pre-initu (podobně jako třeba u x86 se zpracovávají pře hlavní smyčkou veškeré paramtery předané GRUBem, inicializace VGA, …), nějaké jedné tabulky a co by mohlo do ovaldačů, s tím do ovladačů. Takhle je to fakt hnus zelený (takový chudák Mrkva by mohl vyprávět).

[lukve]

takze nakoniec dospejeme k tomu ze to ze maju x86 jednotny BIOS a ze niekedy existoval DOS od jednej zaujimavej :) firmy ktora bios velmy vyuzivala viedlo v historii k tomu ze x86 su jednotnejsie co do platformy?

 

inac dragonflybsd ma rozdelene /cpu a /platform narozdiel od inych BSD ktore to maju vsetko v jednom /arch ako to ma linux pokope

[Grunt]

takze nakoniec dospejeme k tomu ze to ze maju x86 jednotny BIOS a ze niekedy existoval DOS od jednej zaujimavej :) firmy ktora bios velmy vyuzivala viedlo v historii k tomu ze x86 su jednotnejsie co do platformy?

To jsem řekl? Ale i kdyby, furt to není plus.

[pc2005]

Velká spousta věcí s ARMem používá U-boot a ten podporuje devicetree, v něm můžou být tak lowlevel věci jako třeba MMIO adresy pro periferie čipu. To, že to tam nikdo nechce dát a že informace, na kterým pinu procesoru je jaký výstup, je v hlavičkovým souboru jádra je jiná věc .

Imho kdyby na x86 bylo tolik věcí co se dá konfigurovat, tak by to žádný BIOS taky neutáhl. Už třeba jen fakt, že bootovat se dá i odjinud než jen z USB/HDD/FDD/DVD.

[R]

Na beznej x86 zakladnej doske je vela veci, ktore musi BIOS nastavit (north bridge, south bridge, zvuk, siet, pridavne radice, super i/o, clock generator). Bootovat sa da napriklad aj zo siete. Alebo z radica vlozeneho v PCI slote. A vacsinou nova doska funguje bez toho, ze by sa museli zmenit vsetky OS, ktore tam chces prevadzkovat... Pokial ARM nebude mat toto vyriesene, tak z neho nikdy nebude konkurencia x86.

[Jiří J.]

To by se výrobci museli přestat předhánět v soutěži "kdo vymyslí víc nových rozhraní", což asi jen tak nenastane. To by se Linus musel hecnout a nepullovat celý strom, dokud někdo nevymyslí něco unifikovaného, co by respektovaly všechny společnosti. Což nehrozí.

[pc2005]

x86 BIOS na zařízeních nastavuje jen základní věci, který si navíc stejně často OS nastaví sám znova. Na x86 je jednotnost tak velká, že výrobci BIOSů dodávaj jen šablony, možná ani to ne, aby si výrobci desek doslova naklikali kompatibilitu se svým čipsetem. K Awardu 4.5x tuším existoval dosovskej editor registrů chipsetu a jejich inicializačních hodnot.

Tohle na ARMu není, resp. ARM je miniaturní část, jádro, které licencuje jedna firma. Už věci jako nastavení frekvence jsou řešený u každé firmy jinak.

Bootování ze sítě je pořád málo. Teoreticky totiž jde bootovat z libovolného datového vstupu . Osobně já bootoval například přes sériový port a kdybych si neodpálil parport, tak i z něj. Ale obecně by mělo jít třeba i přes zvukovku . Na ARMu pak jsou věci jako 2-3 různý sériový synchronní protokoly, asynchronní protokol, USB, volné adresovací piny a další sběrnice, o kterých jsem ani nikdy neslyšel. Tam pak jsou periferie různý (pokud existujou) nejen mezi výrobci (hardwarově), ale i mezi jednotlivými řadami a dokonce mezi jednotlivými deskami a to možná i mezi jedním modelem. Na rozdíl od x86 lze totiž často u embedded procesorů konfigurovat na jaký pin bude vyvedeno jaké zařízení. Takže aby to mohl nějaký univerzální BIOS obsáhnout, tak by musel mít brutální databázi všech kombinací - stejně jako to teďka má jádro. Imho by to šlo právě pomocí devicetree, což by si pak jádro naparsovalo a podle toho zavedlo případně ovladače. Proč se to globálně nepoužívá nevím, ale onen U-Boot to 100% podporuje.

BTW Z ARMu nikdy nebude konkurence x86, protože proč by snižoval svoje portfolio .

Jinak on by strom arch/arm/ nebyl tak velkej, kdyby nebyly ovladače zařízení (časovač, sériák (!) a další) právě v něm (taky nechápu proč).

[trekker.dk]

a všechno to nějak rozumně nastaví BIOS

...na který Linus taky nadává

[stativ]

Ale on ten bordel je v samotné architektuře, přesněji samotná architektura způsobuje, že tam ten bordel vzniká.

Kde jsem to jen viděl… Jo aha, u distribucí GNU/Linuxu…