SMC WEBT-G + HW mod + Linux

Nem igazán használtam az eszközt mostanában, és mivel sok szabadidőm volt (ami persze nem igaz, mert mindig lehetne valami mást csinálni), elhatároztam, hogy kicsit beleásom magam a témába: hogyan lehetne Linuxot varázsolni rá?

I. RÉSZ

Első nekifutásban körülnéztem a neten, hogy mik a tapasztalatok a téma kapcsán. Több helyen is írták, hogy bár támogatott az architektúra, de mivel nagyon kicsi a gyárilag adott flash és RAM ezen a konkrét modellen (2MB/8MB), sokan bele sem kezdtek a kísérletezgetésbe, az OpenWrt pedig automatikusan a "nem támogatott" kategóriába sorolta be az eszközt. Mivel régóta érdekelnek a beágyazott eszközök, gondoltam, itt a remek alkalom, hogy közelebbről megismerkedjek egy ilyen eszköz hardveres működésével.

A célkitűzés: 8 MB flash-re és 32 MB RAM-ra bővíteni, és egy teljes funkcionalitású Redboot/Linux kombót beüzemelni a vason.

Mielőtt belevágtam volna a projektbe, alaposan körbejártam a témát, mivel nem szeretnék pénzt kiadni feleslegesen olyan alkatrészekre, amelyek nem is biztos, hogy működni fognak ezzel a modellel, a szállítási költségekről és a chipek ki- és beforrasztásához szükséges eszközök áráról nem is beszélve.

Hosszas kutatómunka eredményeként sikerült kiderítenem az eszköz fontosabb paramétereit:

• SoC típusa: Atheros AR5315 (AR531xPlus) + AR2316 CPU
• Processzor architektúra: MIPS32, 4KEc kompatibilis
• RAM: ISSI IS42S16400B-7TL - 8 MB-nyi SDRAM, 1 Mb x 16 bit x 4 bank konfigurációban
• Flash: ST 25P16V6P - 2 MB-os, SPI buszos, 50 MHz órajelű
• MAC: SoC-ba integrált
• PHY: külön IC-n van, Altima AC101 típusú (Realtek-kompatibilis)
• Wifi: SoC-ba integrált, SuperG, vagyis 108 Mbps-os, 802.11bg szabványú
• Soros interfész: SoC-ba integrált UART, ami egy 10 tűs csatlakozóra van kivezetve a panelen

A SoC-ba integrált soros port egyébként remekül használható, egy Raspberry Pi-jal közvetlenül összedrótozva azonnal sikerült működésre bírni, az ilyenkor általában szükséges TTL/RS232 konverter használata nélkül, mivel mindkét eszköz 3.3V-os feszültségszintekkel dolgozik. A soros portra ráakaszkodva szépen nyomon követhető a boot folyamat, amiből rengeteg értékes infót sikerült begyűjteni.

A gyári flash és RAM chipek specifikációját és az architektúrát leíró C header fájlt kielemezve az alábbiakat tudtam megállapítani:

[...]
#define AR531XPLUS_AMBA_CLOCK_RATE 92000000
#define AR531XPLUS_CPU_CLOCK_RATE 184000000
[...]
#define AR531XPLUS_SDRAM_CLOCK_RATE AR531XPLUS_AMBA_CLOCK_RATE

Vagyis, 92 MHz-es órajelen hajtja a vezérlő a RAM-ot. Ez alapján akár egy 100 MHz-es SDRAM chip is megfelelne a célnak, feltéve, hogy lehet még ilyet működőképes állapotban találni 2014-ben.

#define AR531XPLUS_SDRAM_DDR_SDRAM 0 /* Not DDR SDRAM */
#define AR531XPLUS_SDRAM_DATA_WIDTH 16 /* bits */
#if RAM_SIZE == 0x2000000
#define AR531XPLUS_SDRAM_COL_WIDTH 9
#define AR531XPLUS_SDRAM_ROW_WIDTH 13
#elif RAM_SIZE == 0x1000000
#define AR531XPLUS_SDRAM_COL_WIDTH 9
#define AR531XPLUS_SDRAM_ROW_WIDTH 12
#else
#define AR531XPLUS_SDRAM_COL_WIDTH 8
#define AR531XPLUS_SDRAM_ROW_WIDTH 12
#endif

Ebből kiderül, hogy a vezérlő normál SDRAM-ot hajt meg (nem DDR), 16 adatbites chipeket kezel és max. 32 MB-ot tud megcímezni (9-bites oszlop-, illetve 13-bites sorcímzéssel).

Az összegyűjtött infók alapján az alábbi két IC-t választottam ki:

• Micron M25P64-VMF6TP, ami egy SPI buszos, 50 MHz-es, 8 MB-os Flash chip
• Samsung SAMM366S1654DTS-C7A - ez egy 32 MB-os, 133 MHz-es SDRAM chip, a modul specifikációja szerint viszont 8 Mbit x 16 bit x 4 bankos egy chip, vagyis elvileg 64 MB-os

Mivel türelmetlen voltam, kicsit előre akartam dolgozni: az egyik idevágó leírást követve megpróbáltam a gyári flash/RAM kombóval feltölteni egy ap51-es boardhoz fordított Redboot-ot, ám ez nem bootolt az eszközön. Persze eleinte RAM-ból próbáltam meg elindítani, hogy egy szimpla újraindítással vissza lehessen állni a gyári bootloader-re, de ezzel kétféle eredményt sikerült elérnem: vagy meghívódott a gyári bootloader kivételkező kódja és visszakaptam egy szépen megformázott register dump-ot, vagy szimplán újraindult az eszköz, bármiféle kimenet nélkül. Ekkor arra gondoltam, biztos az lesz a gond, hogy a gyári bootloader valami módon beleszól a boot folyamatba, és bátor módon feltöltöttem a Redboot image-et a flash-be. Nagy levegő, újraindítás, de a Redboot még így sem bootol, sőt, mivel kiütöttem a gyári bootloader-t, nem volt semmilyen kód, ami el tudott volna indulni, így sikeresen működésképtelen (de még menthető) állapotba hoztam az eszközt.

Aggodalomra semmi ok, mivel nem voltam biztos a dolgomban, készítettem mentést a korábbi bootloader-ről, de ezt jelenleg visszatölteni nem tudom, működő bootloader - és működő soros port - híján. Ilyen esetekben a következő lépés a JTAG port használata szokott lenni. Szerencsére a processzor kompatibilis az EJTAG 2.6 szabvánnyal, így a flash újraprogramozása egy kis USB-s eszközzel (FlashcatUSB) elvileg különösebb nehézségek nélkül megoldható. A flash programozó már meg is van, viszont egyelőre nem tudok rácsatlakozni a JTAG portra, mivel csak a helye van meg a lapon, a lábak nincsenek gyárilag beforrasztva.

Az eszköz beépített bootloader-e egyébként meglehetősen limitált képességű, pl. TFTP-ről nem képes bootolni (nem kezel hálózatot), illetve a flash partíciók kialakítását sem engedi megváltoztatni, csak olyan alapszintű műveleteket enged, mint a MAC cím megváltoztatása, flash memória törlése/programozása, írás/olvasás a RAM-ba, és természetesen firmware image-ek betöltése és indítása.

Különféle fórumokon utánaolvasva kiderült, hogy a Redboot egyik variánsa támogatja ezt a platformot, így gyorsan le is töltöttem, és készítettem vele egy AP53-as image-et, ami már elvileg gond nélkül el kell, hogy induljon, mivel AR2316-os platformhoz lett kifordítva.

Az új flash chip és a JTAG működéséhez szükséges 14 tűs csatlakozó már úton van. Ha szerencsém van, hétfőn meg is érkezik a rendelés, és ismét nekieshetek a flash-égetésnek.

RAM chipet a régi, levedlett alkatrészek közt kutakodva sikerült találnom, egy 128 MB-os, PC133-as modul formájában, így ezzel elvileg csak annyi dolgom lesz, hogy a modulon lévő 4 chipből egyet leforrasztok és már mehet is RAM-bővítés.

II. RÉSZ

Megérkeztek a hiányzó alkatrészek, így gazdagabb lettem:

• 3 db 50 MHz-es flash chippel
• 3 db 75 MHz-es flash chippel
• 3 db 2x7 tűs tüskesorral
• némi forrasztásban szerzett gyakorlattal
• a felismeréssel, hogy barátnőm egész ügyesen kezeli az ónszívót :)
• egy már forrasztható állapotban lévő, de még használhatatlan EJTAG interfésszel...

A lyukak kipucolása után nekikezdtem volna a frissen kapott tüskesor beforrasztásának, de sajnos kiderült, hogy az alsó lábak túl vastagok, illetve nem elég hosszúak, nem nyúlnak ki eléggé a lap túloldalán... gondolhattam volna rá, hogy megnézem a pontos méreteket, de miután láttam, hogy 2,54 mm a lábak közötti távolság, és a felső érintkezők vastagsága is stimmelt, azt gondoltam, biztosan jó lesz, hiszen a másik, már felforrasztott csatlakozó is pont ilyen - tévedtem. :( A tüskesor méretileg tökéletes, a probléma az, hogy a lyukakat nem sikerült teljesen kitisztítani.

A következő állomás: megfelelő tüskesorpákahegy beszerzése...

***

A pákahegy időközben megérkezett, de a tüskesor beforrasztásával felhagytam, elvégre csak átmenetileg kellett volna a JTAG-hozzáférés, és mivel ennyire körülményes volt a dolog, ezért végül úgy döntöttem, hogy a vezetékeket közvetlenül beforrasztom a lyukakba:

A beforrasztott jumper kábeleket már csak rá kellett csatlakoztatnom a FlashcatUSB megfelelő tüskéire, valahogy így:

Ezzel sikerült is EJTAG-hozzáférést szereznem, ami tökéletesen működött, épp csak egy dologra nem tudtam felhasználni: flash programozásra...

Mint kiderült, a probléma arra vezethető vissza, hogy a FlashcatUSB szoftvere nem tudta megállapítani a proci pontos típusát (0x1-es CPUID-t kapott vissza, amiből nem derül ki se a gyártó, se a modell), ezért nem is töltötte be az Atheros chipekhez írt flash-kezelő interfészt. Mivel a szoftver nyílt forráskódú, egy apró trükkel sikerült átlendülni ezen, de a flash sajnos még így sem volt hozzáférhető, az SPI busszal való kommunikációra fenntartott vezérlőregiszteren keresztül sehogy sem sikerült megszólaltatni a chipet, még a chip JEDEC-azonosítóját sem sikerült lekérdezni.

Ekkor jött az ötlet, hogy mi lenne, ha SPI üzemmódban használnám inkább a Flashcat-et, elvégre semmi mást nem akarok, csak a flash-t újraprogramozni. A JTAG-csatlakozáshoz használt vezetékeket szépen átforrasztottam a flash IC megfelelő lábaira, de se kép, se hang, a Flashcat nem érzékelte a chipet. Leellenőriztem a forrasztásokat, hátha én bénáztam el valamit: a gyanú beigazolódott, a forrasztási pontok megerősítése után megjelent a chip a Flashcat szoftverében, de valamiért nem tudta beazonosítani a chip típusát: mindig valami hamis, folyton változó JEDEC-azonosítót jelzett ki, amiből nem lehetett meghatározni a chip paramétereit. Itt kezdtem azt érezni, hogy valami nem stimmel, lehet, hogy a sok forrasztgatással megöltem az IC-t, esetleg valamelyik vezeték elszakadt, rosszul érintkezik, vagy nem stimmel a lábkiosztás?

Már majdnem feladtam a kísérletezgetést, amikor eszembe jutott, hogy ha már úgyis bővíteni akarom a chipet, akkor akár ki is forraszthatnám, így könnyebben hozzáférek a lábakhoz, ráadásul egy lépéssel közelebb is kerülök a célkitűzésemhez.

Nekiláttam hát a chip kiforrasztásának, majd miután sikeresen hozzájutottam, ráforrasztottam a vezetékeket:

Nagy levegőt vettem, és ismét megpróbáltam elindítani a Flashcat szoftverét. Ekkor csodával határos módon végre sikerült a chip felismerése, és minden további nélkül tudtam írni/olvasni a flash memóriát:

Gyorsan visszatöltöttem a korábban lementett és felülírt bootloader kódját a memória első 128 kbyte-os szegmensébe, majd készítettem egy mentést a memória teljes tartalmáról. Ezzel két problémát is sikerült megoldanom: helyreállítottam az elbarkácsolt bootloader-t, és hozzájutottam az eszköz kalibrálási adatait tároló (kritikus, máshonnan nem beszerezhető) 64 kbyte-os szegmenshez.

Miután a mentés elkészült, leforrasztottam a vezetékeket, majd visszaforrasztottam őket az új flash chip-re. Úgy látszik, ekkorra már kialakulhatott bennem némi rutin a forrasztás terén, ugyanis ez már elsőre sikerült. A korábban lementett, gyári bootloader kódott felprogramoztam a chip első 128 kbyte-os területére, majd a régi chipből kinyert kalibrációs adatokat kiírtam az utolsó 64 kbyte-ba.

A biztonság kedvéért erről a chipről is készítettem egy full mentést, majd leforrasztottam a drótokat, és előkészítettem a következő lépést: a chip beforrasztását.

Ez a kiszereléshez is használt ChipQuik készlettel gyerekjáték volt: a leírást követve kb. 10 perc alatt sikerült hibátlanul beforrasztani a chipet, a folyasztószernek hála az ón nem folyt be kellemetlen helyekre, csak és kizárólag ott tapadt meg, ahol kellett - a chip lábaira és a panelen lévő fém érintkezőkre.

Miután az új flash chip a helyére került, a korábban már bevált módon összedrótoztam az eszköz soros portját egy Raspberry-vel, és áram alá helyeztem. Szinte hihetetlen volt látni, hogy a sok barkácsmunka és ki-be forrasztgatás ellenére minden tökéletesen működik, a hardver ismét bootol a gyári bootloader-rel, az egyetlen különbség a korábbiakhoz képest, hogy kapok egy hibaüzenetet a bootolás során:

=======================================================================
Wireless Access Point WA4001C Loader V0.03 build Mar 29 2005 15:45:48
Arcadyan Technology Corporation
=======================================================================
sysFlashConfigInit: Read of flash device signature failed!


Boot params empty, loading default values.....DONE
cpuFreq=240000000 sysFreq=60000000 cntFreq=120000000

A bootloader kódját hexdump-pal megvizsgálva kiderült, hogy csak 1, 2 és 4 MB-os flash chipeket ismer, valószínűleg van egy else ág a kódban, ami a fenti hibát adja vissza, ha ezektől különböző méretű flash chipet érzékel.

Ettől az apróságtól eltekintve, a bootloader funkciói tökéletesen működnek (pl. bootolás RAM-ból), így ismét lehet kísérletezgetni a Redboot elindításával.

***

Pihenésképp ráforrasztottam az EJTAG interfészt a panelre, ami szépen működik is, így most már az eddiginél kulturáltabb módon tudok JTAG-hozzáférést szerezni, ha szükséges:

III. rész

Befejeztem a FlashcatUSB-vel való szívást, nagyon úgy tűnik, hogy a szoftver nem képes rendesen kezelni ezt a modellt, mivel se a RAM-hoz, se a flash-hez nem sikerült hozzáférnem JTAG-üzemmódban. Arra gyanakszom, hogy a firmware-ben lehet egy bug valahol, ez viszont zárt forrású, úgyhogy esélyem sincs, hogy megpróbáljam megjavítani. :(

A FlashcatUSB helyett találtam egy ígéretes alternatívát, ez a tjtag-pi, ami a tjtag nevű, SOHO-routerek birtokosai körében népszerű flash-programozó Raspberry Pi-ra portolt változata. Ezt sajnos egyelőre nem tudtam kipróbálni, mivel elfogytak a jumper vezetékeim (lásd a flash programozáshoz használt szép színes drótokat :)), a csatlakozók levágása után épen megmaradt 4 db vezeték sajnos kevésnek bizonyult, de sebaj, úton van már az utánpótlás!

Közben továbbmentem a hardveres bővítés irányában is: leforrasztottam egy chipet a kiszemelt SDRAM modulról, és alig 5-6 órányi szenvedés után büszkén jelenthetem, hogy sikeresen felforrasztottam a panelre:

Itt szeretnék lebeszélnék mindenkit arról, hogy ezt utánam csinálja: még a megfelelő eszközök birtokában is (ónszívó, folyasztó, vékony pákahegy stb) igen izzasztó munka volt az IC kiforrasztása után keletkezett, a lábak közé makacsul beragadt ónmaradványok eltávolítása...

Ez persze a lényegen nem változtat: az új chip kitűnően működik a gyári bootloader-rel, a beépített memóriateszt sikeresen lefut, az első tesztek alapján a chip tökéletesen kompatibilis az eszközzel.

***

Megérkeztek a jumper vezetékek, így nekiláttam az eszköz Raspberry-vel történő összedrótozásának. Ez lett a végeredmény:

A kapcsolat eleinte nem akaródzott működni, hiába ellenőriztem a csatlakozásokat újra és újra, a tjtag meg sem nyikkant, nem észlelt semmit a kábel túloldalán. Jobb híján arra gyanakodtam, hogy megsérülhetett valamelyik vezeték, vagy szimplán túl hosszúak. Kísérleti jelleggel átkötöttem a jumper kábelek Raspberry-felőli végeit a FlashcatUSB megfelelő lábaira: így sem működött az elérés, az eszköz nem látszódott a túloldalon. Ekkor feltűnt, hogy van egy plusz láb a lapon (nTRST), ami nincs bekötve. Összedrótoztam a két lábat, és csináltam még egy tesztet: a Flashcat így már képes volt a processzorral kommunikálni, igaz, továbbra sem tudtam hozzáférni a memóriához, de legalább működött a kommunikáció.

Az nTRST egy negatív logikára épülő "reset gomb", ami a TAP-ot (Test Access Port) hozza alaphelyzetbe a processzor és a perifériák "megzavarása" nélkül. Igen ám, de a fordított logika miatt alapesetben reset állapotban van, ezért figyelmen kívül hagy minden interakciót a JTAG-interfészen. A megoldás szinte adja magát: csak össze kell kötni a Raspberry egy szabad GPIO lábával, és logikai egyeseket küldeni neki minden egyes órajel ciklusban, ezzel kiiktatva a reset állapotot.

Ezt a tjtag-pi forrásának minimális módosításával (forkoltam: tjtag-pi2) sikerült elérnem, így már működik az elérés, sőt, a flash chipet is felismeri a kód és el is tudja érni a tartalmát:


==============================================
EJTAG Debrick Utility v3.0.1 Tornado-MOD
==============================================


Probing bus ... Done

Instruction Length set to 5

CPU Chip ID: 00000000000000000000000000000001 (00000001)
*** Found a Atheros AR531X/231X CPU chip ***

- EJTAG IMPCODE ....... : 01000000010000000100000000000000 (40404000)
- EJTAG Version ....... : 2.6
- EJTAG DMA Support ... : No
- EJTAG Implementation flags: R4k ASID_8 NoDMA MIPS32

Issuing Processor / Peripheral Reset ... Done
Enabling Memory Writes ... Skipped
Halting Processor ... ... Done
Clearing Watchdog ... Done

Enabling Atheros Flash Read/Write ... Done

.RE-Probing Atheros processor....
..Found a Atheros AR2316

Probing Flash at (Flash Window: 0x1fc00000) ...
Done

Flash Vendor ID: 00000000000000000000000000100000 (00000020)
Flash Device ID: 00000000000000000010000000010111 (00002017)
*** Found a STMicro M25P64 (8MB) Serial Flash Chip ***

- Flash Chip Window Start .... : 1c000000
- Flash Chip Window Length ... : 00800000
- Selected Area Start ........ : a8000000
- Selected Area Length ....... : 00800000

*** You Selected to Backup the AR-WHOLEFLASH.BIN ***

=========================
Backup Routine Started
=========================

Saving AR-WHOLEFLASH.BIN.SAVED_20140715_172103 to Disk...
^C 6% bytes = 551940

A másolási sebesség persze igen gyatra (alig 5 kbyte/sec), egyfelől azért, mert nincs DMA-támogatás, másfelől azért, mert a JTAG egy diagnosztikai interfész, ami inkább debuggoláshoz használatos, nem pedig nagy mennyiségű adat gyors átviteléhez. Egy átlagosan 100-140 kbyte-os bootloader felprogramozásához mindenesetre bőven elég ez a sebesség is.

Jöhet a Redboot!

***

Ma végre eljutottam odáig, hogy sikerült egy futtatható, de még korántsem tökéletes Redboot image-et gyártanom az eszközhöz. A boot folyamat elindul, de utána már csak egy csöndesen villogó kurzort látok a soros kimeneten - bármi is történik a háttérben, odáig nem jut el a kód, hogy képes legyen bármiféle hibaüzenetet kiírni a konzolra. :(

Ez elég kellemetlen egy beágyazott eszköznél, hiszen a soros porton kívül nincs más kimenet, így ilyenkor az egyetlen lehetséges alternatíva a JTAG interfész felhasználása a kód debuggolásához.

Kis kutatómunkával megtudtam, hogy - természetesen - ez is megoldható egy Raspberry Pi és a megfelelő szoftverek és drótok birtokában. :)

Mivel a Redboot image gcc-vel fordul, és alapból szerepel a paraméterek közt a -g kapcsoló, így a normál, ELF-formátumú, unstripped bináris minden további nélkül használható debuggoláshoz GDB-n keresztül. Ezt, és a diplomamunkának induló, de mára igen széles körben elterjedt nyílt forrású OpenOCD-t felhasználva néhány órányi kísérletezgetés után sikerült összehoznom egy működő debug környezetet:

A kérdés adja magát: a képen látható infók alapján vajon mi lehet a hiba? Jelezném, hogy jelen esetben a gyári bootloader még nem töltődött be (a folyamat elején 0xbfc00000 a PC értéke, vagyis még el sem kezdte a CPU lefuttatni a flash-ben tárolt inicializáló kódot), így annak a kivételkezelője elvileg nem szólhat közbe. De akkor mi? Honnan jön ez a "fura" cím (jól láthatóan kívül esik a futtatandó program címtartományán)? Esetleg a redboot kivéltelkezelője lenne, ami egy kivétel kezelése közben egy újabb kivételt generál (csúnya, de előfordulhat ilyesmi)?

***

Végre eljött a pillanat, amire hetek óta vártam: igaz, egyelőre csak egy kis rásegítéssel, de végre sikerült elindítani a Redboot-ot az eszközön GDB-n keresztül, íme a bizonyíték:

Azt sajnos nem tudtam kideríteni, hogy pontosan miért hasal el a kód, de már megvan a helye - könnyen lehet, hogy egy redboot-ban lévő bug szivatott mostanáig, ezt írták ugyanis a changelog-ban:


packages/hal/mips/arch/current/ChangeLog:
"* src/hal_misc.c (hal_delay_us): Rewrote this routine to work
correctly in higher speed CPUs. The counter register counts at
half CPU clock speed. The original ticks calculation could
overflow very easily. For example in a 133MHz CPU, it overflowed
with any argument greater than 32! This is another of those "how
did it ever work?" things."


No comment. :)

***

És igen, megcsináltam! :D

Idegölő szívások árán, de végül csak sikerült összehozni: az eszközön most már a Redboot legfrissebb, 3.0-s verziója fut, ROMRAM üzemmódban (vagyis, flash-ből indul, aztán menet közben átvált RAM-ra).

Úgy tűnik, minden fontosabb feature hibátlanul működik: tudom írni/olvasni a flash-t, van egy komplett TCP/IP stack-em, számtalan forrásból tudok bootol-ni (flash/TFTP/HTTP/xmodem/ymodem...) és ami a legizgalmasabb: végre minden adott ahhoz, hogy bebootolhassak egy Linuxot a masinán. :)


+PHY ID is 0022:5521
Ethernet eth0: MAC address b1:00:34:84:00:04
IP: 192.168.2.254/255.255.255.0, Gateway: 0.0.0.0
Default server: 192.168.2.1


RedBoot(tm) bootstrap and debug environment [ROMRAM]
Non-certified release, version v3_0 - built 19:40:20, Jul 22 2014

Copyright (C) 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009
Free Software Foundation, Inc.
RedBoot is free software, covered by the eCos license, derived from the
GNU General Public License. You are welcome to change it and/or distribute
copies of it under certain conditions. Under the license terms, RedBoot's
source code and full license terms must have been made available to you.
Redboot comes with ABSOLUTELY NO WARRANTY.

RAM: 0x80000000-0x82000000 [0x8003a7c8-0x80fe1000 available]
FLASH: 0xa8000000-0xa87effff, 128 x 0x10000 blocks
RedBoot>
RedBoot>

RedBoot> fconfig -l
Run script at boot: false
Use BOOTP for network configuration: false
Gateway IP address: 0.0.0.0
Local IP address: 192.168.2.254
Local IP address mask: 255.255.255.0
Default server IP address: 192.168.2.1
Console baud rate: 9600
GDB connection port: 9000
Force console for special debug messages: false
Network debug at boot time: false

RedBoot> fis list
Name FLASH addr Mem addr Length Entry point
RedBoot 0xA8000000 0x8007A000 0x00030000 0x8007A000
FIS directory 0xA87E0000 0xA87E0000 0x0000F000 0x00000000
RedBoot config 0xA87EF000 0xA87EF000 0x00001000 0x00000000
RedBoot>
RedBoot>

RedBoot> x -b 0xa8000000 -l 96
A8000000: 3C 04 B1 00 34 84 00 08 8C 88 00 00 35 08 00 02 |<...4.......5...|
A8000010: AC 88 00 00 00 00 00 0F 3C 04 B1 00 34 84 00 0C |........<...4...|
A8000020: 8C 88 00 00 35 08 00 02 AC 88 00 00 00 00 00 0F |....5...........|
A8000030: 3C 04 B0 10 34 84 40 04 8C 88 00 00 3C 01 FF FC |<...4.@.....<...|
A8000040: 34 21 FF FF 01 01 40 24 35 08 00 00 AC 88 00 00 |4!....@$5.......|
A8000050: 00 00 00 0F 24 09 00 0A 21 29 FF FF 1D 20 FF FE |....$...!)... ..|
RedBoot>
RedBoot>

Annyi probléma van még, hogy az Ethernet MAC-cím nem stimmel, valami gyári default értékre áll be, mivel a valós MAC-címet nem tudja lekérdezni, ezen még egy kicsit finomítani kell.

IV. rész

A helyes MAC-cím beállítását egy apró trükkel meg tudtam oldani: az itt található board config dumpot átalakítottam bináris formátumúra (erre a feladatra remek eszköznek bizonyult az xxd), majd az mcedit hexaeditorával bepötyögtem a MAC-címeket (ethernet és wifi) a megfelelő pozíciókra, végül az így keletkezett bithalmazt feltöltöttem a flash megfelelő szegmensébe. Az eredmény szerencsére nem maradt el: a következő újraindítás után a Redboot már a helyes MAC-címet konfigurálta fel az ethernet interfészen.

Ezek után kellett még egy kis patchelgetés, hogy az LZMA támogatást beleintegráljam a 3-as redboot kódjába. Ezt a meglévő ap61-es (Meraki Mini-féle) Redboot-variánsból viszonylag egyszerűen át lehetett emelni, így már nem okoz gondot az LZMA-val tömörített kernel image-ek bootolása sem.

Következő, és egyben befejező lépésként letöltöttem az OpenWrt legfrissebb stabil kiadásának Atheros eszközökhöz fordított változatát, ezt a Redboot-tal percek alatt sikeresen fel tudtam programozni a flash-be. Előtte persze kísérleti jelleggel megpróbáltam RAM-ból elindítani a kernelt (root fájlrendszer nélkül, csak hogy lássam, mi történik), ami - kész döbbenet - elsőre elindult, a kimenetét szépen kitolva az UART interfészre, ezáltal nyomon követhetővé vált, hogy mi is történik a háttérben.

A végeredmény:

• Moddolt SMC WEBT-G hardver 8 MB flash-sel és 32 MB RAM-mal
• Teljes funkcionalitású redboot 3.0 bootloader
• Openwrt Attitude Adjustment (12.09) az access pointon
• Eggyel több Linuxot futtató eszköz otthon :)

Az openwrt konfigurálása nem okozott már nehézséget, viszont mivel egy TV-re kötve, egyfajta vezetékes wifi adapterként szerettem volna használni (a gyári firmware-rel ezt "ethernet client" üzemmódnak hívták), ezzel még egy kicsit ügyködnöm kellett: a vezetékes interfésznek adtam egy 192.168.2.1/24-es IP-címet, majd a wifit kliens üzemmódban csatlakoztattam az otthoni wifi hálózatomhoz 192.168.0.0/24-es subnettel. Ezután a relayd segítségével beállítottam, hogy a két interfész között duplikálódjon minden forgalom. Erre azért volt szükség, mert a normál, kernel szintű bridge-eléssel nem volt hajlandó együttműködni a wpa_supplicant, így két lehetőségem volt: vagy kikapcsolom a titkosítást (eszem ágába sem volt) vagy WDS üzemmódra váltok. Ez utóbbi még szimpatikus is lett volna, de sajnos a routerem nem támogatja, így kénytelen voltam másképp megoldani.

A relayd elindítása után elkezdett működni a hálózatom: az ethernet interfészre kötött eszköz (TV) már kapott IP-címet a routertől, és tudott is kommunikálni mindenfelé, viszont a minidlna szerveremet nem látta. Mint megtudtam, a DLNA multicast szórással hirdeti magát, a relayd viszont csak unicast és broadcast forgalmat képes továbbítani, így hiába vártam türelmesen, a DLNA szerverem csak nem akart megjelenni a TV-n.

A megoldást végül az igmpproxy nevű kis alkalmazás hozta el: ez annyit csinál, hogy a hálózaton észlelt IGMP üzenetek alapján felépít egy route táblát, amivel képes intelligens módon továbbítani a multicast üzeneteket a konfigurációban megadott upstream és downstream interfészek között. Ezt beüzemelve a DLNA szerver bekapcsolás után kb. egy perccel elérhetővé vált a TV-n, így ismét tudunk filmet nézni. :)

-----------------------------------------------------------

Hasznos linkek:

http://wiki.openwrt.org/toh/fon/fonera
http://hannover.freifunk.net/wiki/SMC_WEBT-G
http://james.slaterspage.com/hacking-the-amx-nxa-wap250g-access-point-w…
http://www.linux-mips.org/wiki/JTAG
http://wiki.openwrt.org/doc/hardware/soldering
http://www.embeddedcomputers.net/products/FlashcatUSB/
http://www.chipquik.com/
http://www.sourceware.org/redboot/
https://github.com/oxplot/tjtag-pi
https://github.com/kissg1988/tjtag-pi2
http://openocd.sourceforge.net/