Az a bizonyos roller...
Pár itt leírt okoskodást a netről összemazsolázott infókból vezettem le - ha valamit nagyon félreértettem, legyetek szívesek segítsetek javítani... :)
Előző írásomat ott hagytam abba, hogy rádobtam a nyákra a minimum alkatrészszámot - proci modul, táp, LAN, soros port, pár csatlakozó - majd indítottam. Bár a kínai oldal azt írja, hogy üresen érkeznek a modulok, a gyakorlatban volt rajta valami WinCE - a soros porton látszott ahogy indul (nem derült ki a bootlog-ból hogy CE 5 vagy 6) - de lévén, hogy grafikus felületre van kitalálva a CE, nem sokra mentem vele LCD nélkül. Azt láttam, hogy felismeri az USB-s eszközöket (pendrive, egér, stb. bejelentkezett csatlakoztatáskor), de semmi másra nem tudtam rávenni - és amúgy is a linuxos vonal érdekelt, úgyhogy ledaráltam...
Sikerült is leölni a CE bootloader-t, de a linuxos uboot nem akart indulni az SD kártyáról, pedig a kínai által mellékelt leírás alapján jártam el: http://openembed.org/wiki/File:SOM6410-software-linux-um.pdf
Vicces dolog a kínai kandzsikat Google fordítóba másolva értelmezni egy ilyen leírást... :)
Először egy 4 gigás Kingston MicroSD HC kártyával próbálkoztam, majd némi sikertelen szenvedés után jött egy 1 gigás Kingston és egy Transcend sima MicroSD kártya (ezek voltak otthon) - de egyikkel sem sikerült életjelet kicsikarnom belőle. Egyszerűen nem indult el róluk. A leírás kifejezetten a 2 gigás Kingston sima MicroSD-t emlegette - és mivel mindenféle sector hivatkozásokat kell írni a Fuser progiba (mellesleg ez a progi csak XP alatt működik, Win7 64bit-esen nem látta a memóriakártyát sehogy) így sejtettem hogy nem mindegy a kártya mérete - elszaladtam egy boltba és rövidesen már ment is a 2 gigás Kingston kártyáról a uboot.
Némi Google fordítás után rájöttem hogyan kell a flash memóriába tölteni az image-eket, viszont a hálózat egyszerűen nem akart működni, valamint az USB slave móddal se tudtam semmit kezdeni, pedig utóbbiról tudtam már, hogy jónak kell lennie fizikailag a bekötésnek, mert még a WinCE-vel kipróbáltam és felismerte a Win7 / XP az eszközt, települt a driver. Első körben így maradt a soros Ymodem áttöltés HyperTerminal-lal. A 256K-s uboot és a ~2 megás kernel image még egész "hamar" átszaladt (12-14K/sec-el), de bizony az ~50 megás rootfs-nek már kb. 1.5 óra kellett - és párszor neki kellett futnom mire rájöttem, hogy pontosan melyik offset értéknél, méret hivatkozásnál mit is kell megadni pontosan.
Végül csak elindult a kernel, belapozta a rootfs-t, bejött a root konzol - kezdtem örülni, de jött a feketeleves. Először minden jónak tűnt, azonban ahogy elkezdtem kínozni - rámásoltam fájlokat, töröltem, ismét rá akartam írni - egyből jöttek a tömeges hibaüzenetek: nem tudja törölni egyik másik sector-t, bad block-nak jelölte. Mintha totál bad sector-os volna az egész NAND chip. Viszont a bootloader alól nem volt semmi hibaüzenet, stabilan írta olvasta. Tudom hogy pár badsector gyárilag megengedett - az enyémen is volt 4 gyárilag jelölt hibás sector - de ezt az MTD NAND meghajtónak és a fájlrendszernek karöltve tudniuk kéne kezelni - ha menet közben elhal 1-1 újabb sector az évek során az nem okozhat gondot elvileg. Itt viszont tömeges volt az elhalási jelenség - amire egyszer írt valamit, azt többé nem volt képes felülírni a futó kernel:
...
nand_erase: attempt to erase a bad block at page 0x0000a980
**>> Erasure failed 647
**>> Block 647 retired
...
Először a kernel YAFFS meghajtójára gyanakodtam - bár eddig a gyári kernellel próbálkoztam, de éreztem, hogy nem fogom megúszni a kernel fordítást... :) VMWare-ben telepítettem egy Ubuntu-t és hamar beletanultam ebbe is. Szerencsére sikerült elég jó leírásokat találnom és a kínai féle kernel csomag is ott volt, így hamar kiismertem. Találtam egy 2 évvel frissebb verziót a meghajtóból ('07 helyett '09 évjáratú) - ezt tettem a régi helyére és újrafordítottam a kernel-t, de azzal is ugyanúgy összebarmolta maga alatt a flash területet. A '07-es megírta a friss blokkokat, látszólag törölte is hibátlanul, de amikor körbeérve ugyanarra a blokkra akart ismét írni, akkor dobta a hibát. A '09-es rögtön az első törlés parancsra dobta a hibaüzenetet. Gondolom a régi verzión a törlés gyors, mert csak megjelöli és az újraírás lassabb a megelőző fizikai törlés miatt - az új pedig a törlésben lassabb mert a fizikai törlést is akkor végzi el, az újraírás művelet pedig ugyanolyan gyors mint az első alkalommal.
Legalább arra jó volt ez a kör, hogy közben kiderült: elszúrtam az UTP csati bekötését... Kis gányolással hamar helyrehoztam és már legalább nem másfél óra volt a rootfs áttöltése, hanem bő fél perc. Kb. 1.3-1.4MB/sec-el tölt a uboot a Windows-os tftpd kliensről.
Gondoltam ki kellene próbálni más fájlrendszer típussal is - rátaláltam a buildroot nevű remek kis keretrendszerre, amivel könnyedén lehet saját rootfs-t gyártatni a kernelfordításhoz hasonló szöveges menürendszerben kiválasztva a kívánt elemeket. Generáltattam vele egy JFFS2 fájlrendszerű rootfs image-et és azt töltöttem a kernel mellé. Bár picit más hibaüzenetek formájában, de lényegében ugyanarra a hibára utalva ugyanúgy összeomlott a fájlrendszer.
Az ilyen flash alapú lemezek kezelése úgy épül fel, hogy felül van a fájlrendszer - JFFS2, YAFFS, stb - ezeknek nem kell tudnia semmit a flash valós eléréséről, mert ez az MTD réteg feladata - azon belül is az MTD NAND kezeli ezt a chip típust. A flash chip csatlakozhat párhuzamos porton, SPI-n, akárhol - ha van hozzá MTD meghajtó, akkor a fájlrendszert simán fölé lehet húzni. Azért itt vannak megkötések, pl. nem ajánlott (vagy nem is lehet?) EXT2/3/4-et vagy VFAT-et rakni ilyen flash-re mert korlátozott számban írhatóak a blokkjai - a kifejezetten erre tervezett fájlrendszerek körbe-körbe járnak az írással így egyenletesen terhelik az összes blokkot. A hagyományos fájlrendszer belátható idő alatt kivégezné a kiemelten használt blokkokat. Pendrive, memóriakártya, SSD, merevlemez esetén az eszköz vezérlője maga oldja meg, hogy egyenletesen terhelje a teljes rendelkezésre álló területet, de az MTD eszközöknél nincsen ilyen réteg.
Végül ennek a felépítésnek utánajárva arra következtettem, hogy nem a fájlrendszer rétegben van a hiba, hanem az MTD NAND meghajtóban. Játszottam a kínai kernel s3c24xx MTD opcióival, de ugyanúgy szétverte magát a fájlrendszer mindig. Újabb verziós MTD meghajtóra volt szükségem, de ezt nem lehet csak úgy cserélgetni, túl szervesen épül a kernelbe - ezért a "gyári" 2.6.21-es kernel helyett leszedtem a sokkal frissebb 2.6.39.4-est - erre már nem is emlékszem hogy egyáltalán működésre tudtam-e bírni, de mindenesetre jó nem lett, az biztos. Kipróbáltam valamelyik 3+ kernel verziót is, de erre meg konkrétan emlékszem, hogy bár elindult, de nem sikerült sehogy alá mount-olni a fájlrendszert - szóval nem derült ki, hogy stabil-e vagy sem a lemezkezelés.
Több hétig kísérleteztem, valamint próbáltam kommunikálni a rizsföldivel is, aki csak pingvinezett, nem jutottam vele egyről a kettőre. Végül ráakadtam egy ukrán kollégára, aki már használta ezt a modult és megerősítette, hogy bizony az eredeti MTD NAND bugos, nem működik jól együtt ezzel a flash-el. Még jó hogy a proci és a flash is Samsung. :) Küldött egy általa készített patch-et, amivel sikerült életet lehelnem a rendszerbe és láss csodát, végre tökéletesen működik a 2.6.39.4-es saját fordítású kernellel a vas.
A szépséghiba csak annyi, hogy a saját kernelemben nincsen YAFFS támogatás és arra sem tudtam rájönni, hogy hogyan lehet beletolni, így nem tudom használni a kínai rootfs-t. Maradt az alapból támogatott JFFS2 - a buildroot-al összerakott sajátba azonban hiába rakattam bele az image-be az opkg package manager-t, az sehogyan sem akart működni. Anélkül viszont meg voltam lőve, nem akartam mindent magam telepíteni a rendszerre utána. Így tovább vadásztam és találtam egy JFFS2 Qtopia nevű image-et, amit ugyan sikeresen mount-olt a kernel, azonban utána se kép, se hang.
Már sok gyakorlatot szereztem azzal a bizonyos rollerrel, így nem estem kétségbe, egyből sejtettem mi lesz a gond: az init rossz portra irányítja a konzolt. Elkezdtem hát bűvészkedni: csináltam egy olyan kernel verziót, amiben volt egy alig pár megás MTD partíció, valamint az összes többi szabad területtel egy másik. Az első partícióra tettem a saját nem sokra jó, de boot-képes picike rootfs image-emet, a másik nagyra pedig a Qtopia-t. Boot indult a kicsiről, mount-al belapoztam a második partíciót, majd elkezdtem turkálni, hogy vajon miért is nem indul el a Qtopia. Talált is a tipp, a konzolt a /dev/ttyS0-ra próbálta belapozni, miközben ebben a kernelben a soros portok a ttySAC0..3-ra lapozódnak be - nálam a ttySAC1 lett erre kijelölve. Gyors vi varázslat, uboot bootargs módosítás és már indult is a Qtopia image. Ugyan rettenet hibaüzenet áradattal indul - tele van tömve az init és rc*.d mindenféle szemetekkel, de végül csak elindul és megy és megy és megy... És a lényeg, hogy működik az opkg manager is! :)
Szóval végül lett egy működőképes rendszerem, amivel elkezdhettem az érdemi ismerkedést. Ha valaki használta már a buildroot-ot és tudna segíteni, hogy mégis mi hiányozhat az opkg manager-nek akkor azt megköszönném, jó lenne végül egy tisztább saját rootfs-t használni, de egyelőre ez is jó...
Az opkg manager-rel felhúztam rá egy perl-t pár modullal - van sqlite-om, sorosportom, TCP socket kezelés, továbbá natív C fordítás stb.
A cikk még nem ért véget, kérlek, lapozz!
