Lemon Pi

Hardver

Egy kép többet ér ezer szónál, egy videó tízezer szónál... IndieGoGo kampányoldal itt.

( zsirmo v | 2015. 05. 23., szo – 17:37 )

jól látom, ebben az ethernet végre nem az USB-n csücsül.

( joco01 v | 2015. 05. 23., szo – 17:45 )

Egyre több az ilyen kis PC, ennek nagyon örülök.

Elnézést a tudatlanságomért, de van ezek között olyan, amin elmegy egy gyári Linux disztribúció? Az RPi-vel kapcsolatban leginkább az nem tetszik, hogy az "egzotikus" boot folyamata miatt csak (?) egy egyedi disztribúcióval működik.

--

Lásd: ftp://ftp.hu.debian.org/pub/CDROM-Images/debian/8.0.0/

Ha innen kiválasztok egy i386-os telepítőt, fel tudom tenni bármelyik i386-os gépre. Ha kiválasztok egy arm-et ugyaninnen, fel fog menni a Pi-re?

Pont avval van bajom, ha valaki fog egy hivatalos disztribet, és utána valamit hegeszt rajta, hogy fusson egy adott hardveren. Akár egy noname blogger, akár a hardver hivatalos gyártója, mindegy.

--

Én futtattam valamikor hivatalos Debiant rajt még az elején.
Alapvetően a rendszer futott, bár lassabban és nem tudom már, grafikus környezetet mennyire próbáltam, de ezen a téren sokat reszeltek a Raspbianon, így nyilván nagy a különbség...

Hozzáállás kérdése az egész. Én előre tájékozódom, hogy egy eszközt hogyan, mivel érdemes használni, majd a lehetőségek közül kiválasztom a nekem legmegfelelőbbet. Persze lehet sírni is, hogy miért nem működik úgy, ahogy én szeretném, de ez kevésbé hatékony módja az előrejutásnak. Mindenesetre azt az állításod, hogy egyetlen disztribúció van csak az RPi-re, fenn cáfoltam. Az ettől független másik problémád meg nem érzem valós problémának.

Ave, Saabi.

Ha kiválasztok egy arm-et ugyaninnen, fel fog menni a Pi-re?

Lehet, hogy igen, legfeljebb bajlódni kell vele. A Raspbiannal a kevésbé expert közönség is könnyen elindul. A felhasználói élmény tökéletesen ugyanaz, mint a Debian Wheezy: ugyanazok a csomagok, ugyanúgy jönnek a frissítések, stb.
--
ulysses.co.hu

( kozel | 2015. 05. 23., szo – 18:08 )

Szuper! Es akkor most gyozzenek meg arrol, hogy ezt a kutyut vegyem pl. a Banana Pi, vagy a RPi 2 helyett.

Én őszintén meglepődnék ha bármi is alázná a raspberry+xbmc kombót. 1080p-ig szoktam vele tartalmakat nézni NAS-ról, a felület jó UX szempontból, nem csak szép hanem használható is. Menyasszonyom aki távol áll az IT világtól, simán elkezeli a telefonjáról yatse remote appal.

--
arch,debian,openelec,android

Kicsi a világ. Csak azért porosodik, mert a birtoklási vágyon túl nem találtál neki funkciót, vagy valamilyen használati probléma miatt?
Nekem egy mk808b (a régi 2 magos rk3066-os), volt hogy konyhában monitorral, hangszóróval tévé helyett használtam. Raspi is járt ott, de azzal sokkal több probléma volt (256MB-os első szériás).
http://prohardver.hu/tema/raspberry_pi/hsz_6631-6631.html
http://prohardver.hu/tema/raspberry_pi/hsz_7289-7289.html

Aztán a bekapcsolgatás kivárása helyett újabban inkább a tabletet viszem ki.

( sza2king v | 2015. 05. 23., szo – 23:04 )

troll on

Vannak mar programok, amik tudnak ellenorizni helyesirast.

Meg szolhattak volna valakinek, aki tud angolul, ha mar angolul irnak.

troll off

Egyebkent kivancsi vagyok ra.

/sza2

( Soultrane | 2015. 05. 24., v – 08:17 )

$35? Ez nekem kicsit irreálisan alacsonynak tűnik. A cubieboard4-ért ~$130-at kérnek, igaz az egy kicsit erősebb ennél, de nem ennyivel. Valaki ötlet?

Edit: Az internet azt mondja az AllWinner A80 proci de igen is ennyivel erősebb mint a Cortex-A9.

Ezek a Pi kiadások az igényeimnek nagyon gyengék. A Banana-ban két magos A7 processzor van 1 giga rammal. Ez a 4 mag/ 2 Giga miatt lenne szimpatikus (már ha megáll $50-nél). A cubieboard4-ben 8 mag van (4 A15 @ 2Ghz 4 A7 @ 1.3Ghz) de csak 2 giga rammal elérhető. Tippre hamarabb elfogy a memória mint hogy kihajtanám a 8 magot.

Nem mindegy, hogy a gyártó mivel hozza ki. Ha Chromeos-sel jön a gyártótól akkor lesz megfelelő linux driver hozzá, mivel a chromeos is egy linux xorg grafikával. Ha egy androidos valamire megy házilag egy desktop linux, akkor ott már jönnek a problémák gpu driverekkel, hiába linux az android is a gyökereinél.

Ott van még például az olcsóbbak közt az odroid c1, kb hasonló sebességű, mint a raspi2 (igaz hogy A5, de magasabb órajelen). Viszont nincs rajta sem sata.
A solidrun-nak is van többféle iMX6 megoldása: 1-2-4 mag, -/esata/msata, 512MB-1GB-2GB-4GB ram, van amelyiken mini pcie slot is van.
Ez már pénztárcába nyúlósabb.

( uid_6201 v | 2015. 05. 24., v – 20:56 )

Akik a Raspberry Pi-n és az ezt a nevet megszárnyaló *pi-n túl akarnak látni, itt a jelenlegi kínálatról egy összefoglaló:

http://en.wikipedia.org/wiki/Comparison_of_single-board_computers

Linux disztró: kínálnak hozzá Debian, Ubuntu, Fedora, stb klónok némelyikét.
De ettől más mellett is dönthetsz. Néhány nehézség azonban van:
- boot mindegyik procinak sajátos. Ez nem ugyanaz, mint az egységes x86 boot volt.
- kernel gyakran procispecifikus patchekkel van tákolva, cserélni kernel.org -ról általunk fordítottra nem annyira egyszerű.
- néhány segédprogram, LIB még jár hozzá, lásd: Raspberry raspberry.org -os és Debian-os repók együttes használatát.
- többi általános, bármely disztribúció ARM-HardwareFload (armhf) részből jöhet.
- kérdés még, hogy az adot hardver X driverét (PowerVR, Mali xxx) általános disztribúció armhf repóból kaphatod vagy a proci repója adja.

Szóval bonyolultabb dolog saját disztrót felrakni, mint az Intel és AMD által közel egységesre gyártott x86 architektúra esetén. De nem lehetetlen. Bővebben: HA5DI Bélát lehet kérdezni, aki a PiCore portjaival végigszenvedte ezt az utat.

Egyet értek. Tulajdonképpen ugyanaz a probléma, mint az okostelefonoknál/tableteknél. Az xda-developers erről szól. Az ARM-es processzoroknál nincs meg az az egészséges szimbiózis, mint az x86-oknál. Túl olcsó, túl reprodukálható, a gyártók féltik az innovációjukat. Egy új x86 generáció érkezése előtt az új utasításkészlet már fél évvel része a kernelnek. ARM-nél a gyártó összetákol egy működő kernelt és azzal dobja a piacra a terméket, ahelyett, hogy termék dokumentációját tenné publikussá. Aki meg saját rendszert akar rá telepíteni, az problémákba ütközik. Az is lehet, hogy ciki kiadni a dokumentációt, mert abból kiderül, hogy mennyire gyenge a cég minőség biztosítása. Ez a RPi előnye: ők rá tudták venni a gyártót, hogy adja át a dokumentációt.

(De nem kell messzire menni: ugyanez a helyzet a video processzorokkal.)

Ennél még bonyolultabb a helyzet. Elég annyit írnom, hogy annó az első Raspbery boot folyamatát tanulmányoztam. Ez például a benne levő Broadcom VideoCore IV. grafikus chipből kezdi a boot-ot. Ez a grafikus proci zsigerből olvassa a FAT fájlrendszert ... és folytathatnám a mesét mire addig eljutunk hogy a FAT-ról betöltött minimális boot kódot lefuttatva beállítja az órajeleket és bekapcsolja a főprocit.

Kis történelem: x86 kezdete. Főproci kap áramot és a mellette levő, az adott alaplapgyártó alaplapján fixen ott levő EPROM-ból olvassa normál áramköri memória címzéssel egy IBM cég által standardizált BIOS-t. Hiszen nem véletlenül >>> IBM PC <<< az ősi neve, az IBM tartotta kezében magát a számítógép rendszerleírását.
Ehhez az Intel bepályázott processzorral és az IBM cég kérésére egy másik cég, az AMD is kellett hogy tudjon szállítani az Intellel egyező 8086, majd 8088 processzort.
Szoftvere is egységes. Egy bizonyos Microsoft cég Disk Operation System-je (MSDOS). Szintén az IBM cég megrendelésére.

Szóval az a sztori így indult. Ma pedig nincs az ARM felett "IBM-jellegű" SoC rendszerleíró cég, nincs egy egységes boot felületet és egységes minimumszolgáltatást adó BIOS, ami például egyazon "MSDOS" bootolását lehetővé tenné. Jelenleg van egy tetszőleges chip specifikus boot folyamat, a chip pedig nem egy proci, hanem
- proci - ez ARM utasításkészletet darál
- videóchip - gyártóspecifikus és a bootot is esetenként ez kezdi
- tetszőleges számú gyártóspecifikus gpio, spi, uart, i2c, A/D és egyéb perifériák gyártóspecifikus szoftver oldali címzéssel

És felette egy szabadon átmódosított Linux kernel, amely módosítás viszont nem feltétlen jut be a kernel.org -os fába. Ha pedig bejut, akkor is óvatosan mert amíg az egyik procinál ez az I/O GPIO-t hajt, addig a másiknál feszültségszabályozót állíthat.
Tehát nincs egységes szoftver hajtására előírt közös plattform, mint az >>> IBM PC <<< esetén.

Szóval ARM leginkább csak utasításkészlet, miközben a perifériák nincsenek egységesen kézbentartva. Se egy alapszintű egységes bootolási mechanizmus, ahogy a BIOS esetén volt.
Ellenpéldának lásd: http://wiki.osdev.org/I/O_Ports ... ez is >>> IBM PC <<< örökség.

Szerintem fölösleges fanyalogni. A PC, az PC, az ARM-os kütyük pedig ARM-os kütyük. Az ARM csak processzor magokat fejleszt, és pontosan ez benne a jó.
Ha minden gyártó ugyanazt a procit használná, akkor talán lehetne egységes memória kezelést definiálni, és BIOS-t is írni (bár, egy 35 dolláros kütyütől szerintem nem várható el, hogy még párhuzamos flash-t is tegyenek rá a BIOS kedvéért), de akkor meg az lenne a baj, hogy túl sok a megkötés. Ha egységes lenne a proci, akkor sokkal lassabb lenne a fejlődés. Pl. esélytelen lenne új GPU-kat csinálni, mert kompatibilisnek kell maradni a régiekkel.
És különben is, akkor sem örült neki annyira mindenki, hogy minden egységes. Pl. az MSDOS-t lecseréltük DRDOS-ra, meg Novell DOS-ra, meg ki tudja, mire.
De végül is most is van szabvány, csak más van szabványosítva, nem a boot-olás. A mostani szabvány a Linux.

(Amúgy a BIOS rövidítés használata ebben a szövegkörnyezetben nem helyénvaló, mert a BIOS kellett ugyan a boot-oláshoz, de a boot-olást nem a BIOS végezte. De én most ezzel nem törődtem.)

"De végül is most is van szabvány, csak más van szabványosítva, nem a boot-olás. A mostani szabvány a Linux."

Nekem pont avval van problémám, hogy ez sem olyan triviális. Attól, hogy valaki fog egy kernelt és jól agyonhekkeli, hogy POC jelleggel bebootoljon rajta, az még bőven nem a történet vége kellene, hogy legyen. Amíg nem kerül bele a hivatalos kernel repóba és hivatalos disztribúciókba, addig az csak POC marad. Értsd, nem jár hozzá még annyi support se, mint a nagy közösségi hátterű projektekhez. Manapság, hogy már minden a neten lóg, az nem működik, hogy ignoráljuk a biztonsági frissítéseket.

--

http://hup.hu/cikkek/20150408/az_android_okoszisztema_biztonsaganak_hel…

Cseppet sem támogatom az "ignoráljuk a biztonsági frissítéseket" mozgalmat. De elég érdemes ez a tanulmány és valóban nem tapasztalhatóak annak következményei, hogy az androidos cumók gyártói Android frissítésnél általában csak 1-ig tudnak számolni.

( inf3rno | 2015. 11. 23., h – 12:05 )

Volt aki rendelt ilyet, és meg is kapta? Úgy látom, hogy az oldalon csak startupos pénzgyűjtő link van, amire azt írják, hogy sold out és hogy 2015 augusztustól szállítják. Hát vannak komoly kétségeim, hogy akik fizettek azok valaha megkapják e. :-)