- cyclops blogja
- A hozzászóláshoz be kell jelentkezni
- 1931 megtekintés
Hozzászólások
mennyiért adják?
(neked mennyibe került)
- A hozzászóláshoz be kell jelentkezni
Nekem semennyibe, de cserébe elkészítem a rendszer élesztését, kernel fordítást, satöbbit leíró útmutatót.
Egyébként épp most 9012 Ft (pontosan 7096 Ft+ÁFA) a micro változat, 16941 Ft (13 340 Ft+FA) a maxi változat. Ez már Magyarországon van, a postaköltség gondolom 1000 körül van.
Íme:
http://www.monosx.hu/index.php?option=com_virtuemart&page=shop.browse&c…
- A hozzászóláshoz be kell jelentkezni
A linken nekem nem töltődik be semmi...
- A hozzászóláshoz be kell jelentkezni
köszi!
igen, a magyar arak miatt kerdeztem, mert gondoltam külföldröl rendelted, es hogy a posta/vam/arfolyam stb. miatt hogy alakult.
de akkor nem :)
- A hozzászóláshoz be kell jelentkezni
Közvetlenül Olimextől rendeltem egy darabot próbálgatni, mezei postán (air mail) 5.5 EUR, a kütyü ára 44.95 EUR, PP Service Charge 2.52 EUR (PayPal). Áfa nulla, van EU adószám, 2 hét alatt jött meg.
Én a kernelt akarnám újrafordítani (ArchLinux) de nem egyszerű a történet (és az Archoz sem értek még, meg a Freescale is új). Sajnálatos, hogy a Freeescale (vagy a közösség) nem készít (teljes értékű) patcheket vanilla kernelhez (vagy csak én nem találok ilyet sehol), és akkor könnyen lehetne (én könnyebben tudnék) akár OpenWRT-t is faragni rá, és nem csak a 2.6.35 kernel lenne az egyetlen választás.
Az első körös OE támogatás az halálos, az OE annyira bonyolult, hogy nincs értelme vele küzdeni, nekem legalábbis nincs annyi időm. Ráadásul az alap Arch kernelből és az OE kernelből is hiányoznak a legalapvetőbb USB driverek is, azért szeretnék sajátot fordítani, de ez nem olyan egyszerű az Arch-nál mint mondjuk OpenWRT/Buildroot esetében, az OE-nél meg megállt a kernelfordítás hibával USB drivereknél, azzal nem is küzdöttem tovább.
Első körben a kernel fordítását kéne valahogy megoldani, még a 2.6.35-el is kibékülnék. Az arch arm módszert kipróbálom majd legközelebb a kernelhez, hátha sikerül, de mégis jobb lenne ha nem kéne a build scripteket a natívan az Olimex kártyán vagy más ARM vason futtatni. Persze QEMU itt segíthetne de CentOS-en nincs ARM támogatás a QEMU-ban, tehát VMware is kell és abban asztali Arch és abban QEMU-ARM, de QEMU-hoz sem találtam még gyors útmutatót, abba is bele kellene merülni ami idő.
Ettől függetlenül ha a kernel problémát sikerülne rendezni, alapvetően egy jó hardver lenne, bár sokszor kéne két darab RS232 és itt is csak egy van sajnos.
- A hozzászóláshoz be kell jelentkezni
Üdv, nem olyan veszes az az OE, igaz raszantam egy munkanapot, mire tudtam magamnaka patchelt kernelt forditani :)
En az egy darab RS232-t (ami amugy TTL UART, nem RS232), egy szimpla USB-serial atalakitoval egeszitettem ki, persze ehhez is uj kernelt kellett forditani...
- A hozzászóláshoz be kell jelentkezni
Igen, TTL UART-ot használok mindenhol (csak az rs232-t rövidebb leírni, meg ránézésre egyébként is látszik, hogy miről van szó) és gyakran pont abból kéne legalább még egy. És igen, többek között pont ugyanitt akadtam meg én is, hogy még az USB-serial driver sincs benne sem az alap OE kernelben sem az Arch kernelben. :)
A leírás alapján próbáltam az OE-t még az elején (ha nem nyúlok hozzá, csak azt csinálom ami a leírásban van, akkor lefordul, USB driverekkel már nem fordult le), de az USB-serial-nál azért több dolog kellene. Az OE annak jó aki ezzel éli az életét vagy OE fejlesztő, ahhoz túlságosan komplikált, hogy poénból +1 ként megtanuljam a többi mellé, amiket egyébként már használok és remekül működnek és nem kell több. Biztosan nagyon klassz az OE és csúcstechnika, csak nekem az nem kell.
Az ArchLinux elsőre szépnek tűnt, de a natív fordítás elég gáz. Lehet hagyom a fenébe az Arch-ot is, megpróbálom majd kikukázni a Freescale patcheket valahogy és OpenWRT-t faragni hozzá.
- A hozzászóláshoz be kell jelentkezni
Sikerült 3.6.0rc2-es kernelt fordítanom ez alapján:
https://github.com/koliqi/imx23-olinuxino
Magyar fordítás itt:
http://monosx.org/index.php?title=IMX23-OLinuXino
Nem volt túl bonyolult, egy probléma van: a framebuffer nem működik. Talán a 3.6.0rc2-ben nincs támogatás. A legújabb 2.6.35-8-ARCH+ ArchLinuxArm-os kernellel megy az fbdev. X windows-t sikerült indítanom és mplayert is. Az mplayer viszont nagyon lassú volt, nem tudom lehet-e gyorsítani rajta.
- A hozzászóláshoz be kell jelentkezni
Köszi az infót! Első körben TFT LCD-t szeretnék vele meghajtani. Legutóbb mikor időm volt vele foglalkozni az akkori Arch kernelben még semmi nem volt, azóta láttam a fórumban, hogy már belefordítottak néhány USB drivert is. Hamarosan majd újra futok vele egy kört...
- A hozzászóláshoz be kell jelentkezni
Helló! A proci LCDIF-ét használnád a meghajtáshoz? Nekem egy ilyen LCD-m van:
http://iteadstudio.com/store/index.php?main_page=product_info&cPath=57_…
Egy STM32F103-mal sikerült is vezérelnem, de ez a Linuxos lap jobb lenne, tervezem, hogy kerítek/írok hozzá framebuffer drivert.
Vagy esetleg olyan LCD-t használnál, ami például a laptopokban is van, LVDS jelekkel kommunikáló kijelzőt (ehhez azt hiszem külön HW kellene)?
Szerk.: most olvasom az adatlapban, hogy DVI jeleket is lehet generálni; hagyományos PC LCD-t próbálsz illeszteni a kártyához?
- A hozzászóláshoz be kell jelentkezni
Igen, az LCDIF lenne a cél. Ezzel a TFT kijelzővel próbálkozom majd. Egyelőre a rezisztív felület nélkül, csak mint kijelző. De amit említettél most: ez a DVI témakör is érdekes lehet a jövőben, erről még nem hallottam. :)
- A hozzászóláshoz be kell jelentkezni
Sajnos az iMX233 prociban levő DVI, nem az az interfész (Digital Visual Interface) amivel egy PC monitorra lenne köthető a board, hanem a composite jel generáló és Intel 8080/Motorola buszra csatlakozó LCD-k meghajtó interfésze...
De hogy legyen valami jó hír is, az SSD1289 LCD meghajtása GPIO-n keresztül már működik:
http://www.ivanov.eu/?q=node/1589
Egyelőre nagyon lassú, de az LCDIF-el felgyorsítható.
- A hozzászóláshoz be kell jelentkezni
Ma rászántam a délutánt, azóta nem volt időm vele foglalkozni. Ezt 8-bit RGB interfészen LCDIF-el sikerült meghajtani most. A színek nem jók, mert a framebuffer BGRA formátumú a kimeneteim meg RGBA ezért nem jók a színek.
De viszont saját szoftverből rajzolgatáshoz lényegében ez így már teljesen jó. Az Arch repóban lévő mplayer bináris codec-jei sajnos YCbCr kereteket állítanak elő így SDL-en keresztül szoftveresen konvertálni kell RGBA-ba ami bazi lassú. A kijelző tudja a YCbCr-t (az ITU-R BT 656 módja ami az IMX233-nál a DVI-nek felel meg), elvileg ilyen framebufferrel gyors lenne a videólejátszás és a színek is jók lennének, csak akkor meg a saját szoftverből rajzolás macerásabb mint a mostani RGB-vel. Lehet egyszerűbb újrafordítani az mplayert RGB-hez, vagy egyszerűen csak nem kell videót lejátszani. :)
update: kép3 a helyes bájtsorrendben. Sajnos ezen a gagyi fotón nem megy át, de élőben szép. Az eredeti kép.
- A hozzászóláshoz be kell jelentkezni
A legújabb 2.6.35-8-ARCH+ ArchLinuxArm-os kernellel megy az fbdev.
Jé és a legújabb kernelbe sikerült végre belefordítani az usbserialt meg az ftdi drivert. De az "option" meg az "usb_wwan" már nem fért bele, nehogy véletlenül működjön a 3G modem. :) Csak nem úszom meg a kernelfordítást ehhez... :(
- A hozzászóláshoz be kell jelentkezni
Kicsit foglalkoztam vele, összedobtam egy scriptet ami cross toolchainnel fordítja újra az Arch kernelt. Ebből így ugyan nem lesz pacman csomag (bár talán lehetne csomagot is gyártani könnyen), de az nekem nem probléma. Így nem kell vacakolni az Arch hivatalos natív fordításával.
- A hozzászóláshoz be kell jelentkezni
Udv,
en meg csinaltam hozza board supportot Buildroothoz, elerheto itt, clone utan csak kovetni kell a board/olinuxino/olinuxino-maxi/readme.txt-t, bovebb info Buildroot-hoz itt.
Sajnos meg csak a 2.6.35.3 freescale-s kernellel tudtam mindent eletre kelteni, meg ki is kene pucolni egyes nem feltetlenul szukseges patcheket, ezert meg nem kuldtem be a mainline Buildrootba...
- A hozzászóláshoz be kell jelentkezni
sub
- A hozzászóláshoz be kell jelentkezni