Itt 2GB felettit kezel módosított driver-rel.

Bocsi, elqrtam. Nem HDHC, hanem a nagyobbak már SDHC protokollban...

Sziasztok!

Az a furcsa helyzet állt elő, hogy előbb láttam meg a cikket, mint a témát. Ahogy elnéztem, hardveresen csontra ugyaolyan rúterből csináltam téglát, mint Tom-ee. Az ok a bénaságomon túl az volt, hogy SD kártyát akartam belehekkelni, hogy ftp vagy nas szervert faragjak bele, de úgy gondoltam, előbb szoftveresen felkészítem. Sikeresen le is cseréltem a gyári firmet a DD-WRT micro verzióra. E örö, bódottá, csak sehol nem találtam benne az "Enable SD/MMC" opciót. Aztán lázasan kutakodtam, mire rátaláltam, hogy azt nem is tudja a micro, a legkisebb firm, amiben benne van, az a nokain vagy mi... Na, uccu neki, mit nekem firmcsere, feltoltam rá, restart és diszkófények. Azóta megszabadítottam a burkolatától és nézegetem. Közben utánaolvastam, hogy ne is akarjam feltolni rá a nagyobb firmet, mert 2M flash igen rosszul tolerálja, ha 2,6M cuccot akarok beletömni, de a 8M RAM se lenne boldog annyi funkció kezelésétől. Most szögelem hozzá a JTAG kábelt, egyszer csak lesz rá időm....

Közben azt is megtudtam, hogy a kapacitáslimit 2G az SD kártyánál, mert a nagyobbak már HDHC protokollban pofáznak, ahhoz meg hülye a rúter, tehát maximum 2G háttértár lehet. Hát, nem egy nagy pukkantás... Ezért kezdtem el vakarózni azon, hogy egy IDE vezérlőt rá lehetne-e illeszteni a Linksysre... Mivel csak ugatom a témát, lövésem sincs, csak taperálok a sötétben, így aztán jó lenne, ha valaki megmutatná a villanykapcsolót, vagy inkább felkapcsolná.

Nvram törlés után nekem is világítottak a lan ledek. Amint tartalmat írtam az nvram-ba azonnal továbblépett a cfe a boot folyamatban.
Vedd a 'cfe.bin'-t és töltsd be egy hex editorba. Görgesd a tartalmat hexa 1000-ig, ott láthatod az alapértelmezett nvram adatokat (FLSH ascii string jelzi a kezdetét). A FLSH utáni két bájt adja az adattábla hosszát (fordított a bájtsorrend, pl. A8 02 -> 02 A8, azaz az adattábla vége 1000+2A8=12A8 címen lesz). Vágd ki az adatokat és mentsd ki 'nvram.bin' néven. Mielőtt kiírnád az 'nvram.bin'-t, állítsd be a tartalomban az 'et0macaddr=', 'lan_ipaddr=192.168.1.1' és a 'boot_wait=on' értékeket, majd: wrt54g -flash:nvram /noemw.

Az eredeti nem ment fel, vagy a DD-wrt se?

Ezt figyeljétek:

Van egy WRT54GS routerem. Pár hónapja a DD-WRT -ről vissza akartam állítani a gyári firmware-re, de akkor történt valami és ledöglött a router, a lan ledek világítottak és a power led villog.

Ma elővettem, megcsináltam hozzá a JTAG kábelt, fel is ismeri, Broadcom 5352 chip.

Ezt csináltam:

wrt54g -erase:NVRAM
wrt54g -erase:KERNEL
wrt54g -erase:CFE

Le is futott mind.

Majd:

wrt54g -flash:cfe /noemw

ez is lefutott, kikapcs, 1 perc múlva be

változás semmi.

Utána töltöttem még kernelt is rá, semmi, cfe majd kernel egymás után, hardreset, kikapcs bekapcs, semmi....

Van valami ötlet,mi a bánatot lehet ezzel csinálni?

Vagy tényleg döglött és JTAG-al sem lehet felébreszteni? Jelenleg is világít minden LAN LED rajta és villog a POWER LED...

Valami hibajelenség? LED-ek, berregés, füstjelek? Merre induljunk el a megoldásban...

Igazán nincs mit, örülök, hogy végül te is sikerrel zártad a mutatványt.

Megoldódott, de végtelen röstellem magam a figyelmetlenségem miatt. Amikor megcsináltam a melegpont és a soros port szabad tüskéi között az átkötést a nyák alján, megmértem a tüskén a feszt és nem volt ott a várt 9V DC. Utána néztem meg tüzetesen a dugasztápot és vettem észre, hogy szekunder oldalon 9V jelenik meg, de AC! Kicseréltem a tápot és azonnal működött a soros port, jöttek az üzenetek a terminálablakban (115200, 8N1), az eth0 port is megkapta a 192.168.1.1 IP-t. Tftp-vel 2 sec alatt felment az új kernel (ddwrt) és már el is tudtam érni web felületről az eszközt. Talán annyi szolgál mentségemül, hogy a táppal együtt volt az eszköz a szekrényben elhelyezve és csak felületesen futottam át az adatait.
Mindenesetre, köszönöm Lucifer és Tom-ee a türelmet és a segítséget.

Sziasztok!
Próbáltam feltenni Linksys WRT54GR ruteremre a tomto FW-t, de mindig időtólépést kapok vissza, pedig minden a leírás szerint csinálok. MI lehet a gond?

Igen az illesztő megfelelő, ha a panel ugyanolyan mint a képen van, akkor a lábkiosztás is biztosan jó.

Elvileg az átjáró beállítására nem is lenne szükség, mert a két eszköz egyazon hálózatban van (192.168.1.0/24 a hálózat, a router az 1.1 a gép az 1.2 címen), de valóban, egy próbát megér.
Kipróbáltam, de nincs válasz. A furcsa az, hogy csak a 4. újraindítás után aludtak el a lan ledek. Úgy gondolom, hogy valami nem jó a cfe-vel.
Az alábbi leírás jó lesz a serial porthoz?

Sztem akkor vmi ott nem ok. Nekem csak úgy volt hajlandó működni, ha az átjáró ip-je azonos volt azzal, amit a cfe-vel együtt beégettem. Ha az 1.1, akkor az átjáró is az legyen. Egy próbát megér. (én úgy teszteltem, hogy 10 adatcsomagot küldtem pingelésnél, és mikor átment sikeresen 3-4, akkor kihúztam az utp-t vártam kicsit, majd vissza; ha volt adatvesztés - de csatlakozás után újra működött - akkor volt minden ok. (jártam úgy, hogy elsőre átment minden, pedig be se volt dugva az utp, nemtom hova küldte az adatokat... )

Persze, 192.168.1.0 a hálózat és a gépemnek a 192.168.1.2 fix ip-t adtam.

A gépen is beállítottad a tcp/ip protokollt? Más ötletem hirtelen nincs, hogy miért nem éred el...

Simán frissített tegnap. Letölt egy adatbázist a '\skynet\mkcfe' könyvtárba 'cf.bldb' néven. Az 'mkcfe.conf'-ban van az url, hogy honnan tölti.
Közben belenéztem az általad letöltött, wrt54g v5 típushoz való cfe-be. A 'lan_ipaddr' nvram paraméter valóban 192.168.1.245, ezért éred el ott a routert a kezdetekkor. Az általam preferált wrt54gl v1.1 típushoz generált cfe esetében ez a paraméter 192.168.1.1. Ezért próbálom ezen az ip-n elérni, de továbbra is eredménytelenül. Most írtam ki a SkyNet-es cfe-t. Próbáltam törölt nvram mellett, majd a cfe elejéről kinyert default nvram paraméterek kiírása után, de továbbra is süket bármilyen protokollra (boot_wait=on). Hétfőn megcsinálom a soros portot. Ha az sem segít, akkor még megpróbálom a 15-16-os pinek rövidre zárását, majd a 16-os gnd-re húzását, majd kidobom.

Így már világos. Miért nem volt jó, mi nem tetszett neki? Egyébként nekem épp nincs fent a kit, de érdekelne, hogy a cfe generáló résznél neked simán frissített a netről? (ugye írtam a cikkben is, hogy addig el se indul, amíg nem csatlakozott a netre; én a hétvégén akartam szórakozni vele, és már itt elakadtam, azt írta próbáljam később, de azóta nem volt időm)

Először én is a SkyNet-es repair kit-tel próbálkoztam a leírásod alapján, de nem volt jó. Utána kezdtem mások által javasolt, a típushoz illő cfe binárisok után kutakodni. Az így letöltött cfe.bin állományokban állítottam be kézzel a mac címet (a serialt 'miért ne' alapon). Holnap azért újrapróbálom a SkyNet-es változattal.
Valamint kipróbálom, hogy magában a 'cfe.bin'-ben, már a default paraméterek között beállítom a 'boot_wait=on'-t, mert előfordulhat, hogy a cfe újraírja a tartalmat a maga 'off' értékével... Találgatok. Kell a soros port, csak úgy fog kiderülni, hogy rendben fut-e a cfe. Olvastam még 'boot_time=??' paraméterről is, de az OpenWrt alatt használatos.

Olvastam, csak nem egészen egyértelmű minden... Nem akarok hülyeségeket kérdezni, főleg, hogy Lucifer kb. 100x jobban ért hozzá, mint én. (nekem is ő segített ) De pl. az nem volt egyértelmű, hogy miért írtad át a MAC címet és a sorozatszámot? Az a kit, amit használsz, elvileg a cfe generálás elején bekéri a MAC-et, az ip-t meg nem kell bántani, csak a 192.168.1.245-ön kell próbálkozni. (amikor még csak a cfe van beégetve) Nekem egyébként alapból visszaugrott 1.1 végződésre, amint az fw-t is feltoltam.
A netről letöltött cfe sem igazán szimpatikus, én is próbáltam párat, de igazán csak azzal működött, amit a repair kit generált.
Ezeket nem értettem az elején, de úgy vettem észre, hogy már máshol tartotok, úgyhogy nem kontárkodom bele

Egyébként, azt hiszem már cfe (boot loader) fázisban sérül a folyamat. Ha invalid az nvram tartalma, akkor a cfe elején lévő (0x1000) alapértelmezett nvram beállításokat kellene beírnia az nvramba, azaz a router minden előző beállítást felejtene, de legalább elindulna. Ilyenkor kiolvasva az nvramot üresnek találom (0xff), nem csinálja meg az alapraállítást. Ha beírom neki manuálisan az nvram tartalmat, akkor túllép, a ledek elalszanak, de kernel hiányában nem indítja a failsafe tftp-s fázist.

Lucifer:
Nem. Sima ascii karakterláncok nullákkal elválasztva egymástól, így indifferens a bájtsorrend, a másolás nem okozhatott problémát.

Tom-ee:
Igen, persze. A cikked adta az alapötletet, de sajnos nem oldódott meg általa a probléma. :/ Kérlek, olvass vissza, elég részletesen leírtam.

Ezt olvastad?

Bővebben: Link

Nem lehet hogy valami little/bigendian probléma van?

Nem lett jó. Az új kernel után ismét az összes lan led újra világított. Mintha megsérült volna az nvram tartalma. Erre kiírtam az egy bájttal eltolt nvram tartalmat, de semmi előrelépés. A ledek elaludtak, csak az világít amelyikbe bedugtam az utp-t, de továbbra sem válaszol pingre, tftp-n sikertelen a csatlakozás.
Talán még megpróbálom más cfe tartalmakkal, de nem sok reményt fűzök hozzá. Úgy néz ki marad a soros port, legalább az kiderül, hogy rendben elindul-e a boot loader.
Minden ötletet, javaslatot szívesen fogadok. Üdv

Igen, közben utánaolvastam. Kell egy egyszerű terminál program amivel promptot kaphatok a cfe boot alatt és állíthatom az nvram paramétereit.
Most párhuzamos porton írom ki a kernelt. Kb. 1 órája megy, most tart 50%-nál. :/ Időközben olvasgattam még a boot_wait-ról és rájöttem, hogy nem elég az ascii 'off' stringet 'on'-ra átírni és egy nullával zárni, hanem a nulla utáni összes adatot egy bájttal "visszább" kel másolni. Lehet azért nem sikerült a tftp, mert a boot_wait paraméter továbbra is off-on maradt és nem várt a boot loader néhány másodpercet a tftp kapcsolatra. Persze ennek ellentmond az, hogy ha a cfe nem találja helyesnek a kernel checksumját, akkor is tftp wait állapotba kellene kerülnie, várva az új/jó kernel image-t.
Szval most 52%. Ha végzett kiderül... Kösz az eddigit.

Igen a sorosport arra jó, hogy látod hogy mi a helyzet.
http://wiki.openwrt.org/OpenWrtDocs/Hardware/Linksys/WRT54G
lásd itt a soros port bejegyzést.

Én spec csak kibic vagyok a témában sosem volt linksys wrt-m csak más openwrt supported eszközeim vannak. A Netgear DG834GT CFE-je például olyan, hogy, nem ő nyit tftp szervert, hanem a paraccsorból kell behúzatni távolról. Ezért én azt javaslom, hogy a soros portot jó lenne kipróbálni.

A boot_wait paraméter a mentett nvram.bin-ben off-ra volt állítva. On-ra átírtam és kiírtam a flash-be. Újraindítás után a lan ledek rövid világítás után elaludtak. Utp kábel lan1 portra dug -> lan1 led világít, de a 192.168.1.1 nem pingelhető, tftp nem kapcsolódik (kernel ramterület előtte törölve lett, így tuti rossz a checksum, tehát indítania kellene a tftp szervert a cfe-nek). Gondoltam, biztos a backupos nvram paraméterei közül volt hibás valamelyik, ezért a cfe elején található _default_ nvram paramétereket kivágtam és kiírtam az nvram-ba (boot_wait-et on-ra átírtam előtte a binárisban). 192.168.1.1 továbbra sem pingethető, tftp klienssel nem érhető el. Próbáltam kiírni jtag-gel egy gyári kernelt, de megakad az írás elején a folyamat.
Nem értem. Elvileg, ha a boot (cfe) nem talál az nvram-ban megfelelően valid paramétereket, akkor miért nem írja ki automatikusan a cfe elején található alapértelmezett paramétereket, aztán utána hadd konfigoljon újra a user...
Hogyan lépjek tovább? Mit rontok el?
(Szavaidból úgy veszem ki, hogy a boot procedúra afféle debug funkcióként post üzeneteket ír ki a soros portra? Ha végképp kudarc a jtag-es megoldás, teszek rá soros portot.)

Tegyél rá sorosportot és nézd meg mit csinál. van valami boot_wait nvram beállítás, amit lehet kigyalultál belőle az nvram törlésével.

Sziasztok!

Szervesen a topic témájába illik a problémám, ezért is bátorkodom itt tanácsért folyamodni. Amennyiben új topic nyitása lett volna célszerű, úgy, megkérek egy moderátort, hogy helyezze át kérdésem.

Linksys WRT54GL v1.1 (CL7B sorozat, EON EN29LV320B-70TCP flash) téglává vált. Power led villog, lan1-4 folyamatosan világít. JTAG kábellel és wrt54g programmal próbálnám éleszteni. A wrt54g nem ismeri fel a flash típusát, így a /fc: kapcsolóval manuálisan állítom be: 05 és/vagy 30 értékekkel megy az írás/olvasás (időnként azért megakad).
Először csináltam backupot a teljes flash tartalomról (-backup:wholeflash), majd töröltem az nvram-ot, de továbbra is tégla maradt. Töröltem a kernelt és a cfe-t, majd többféle, netről letöltött boot tartalmat (a fenti típushoz való 256k-s cfe-k, amelyekben hex editorral beállítottam a MAC címet és a sorozatszámot) írtam a flash-be, de továbbra sem akar elindulni a boot/failsafe folyamat. A beírt cfe tartalmakat minden esetben visszaolvastam és a kapott állományt binárisan összehasonlítottam a beírt cfe.bin fájllal. Bitre egyeznek.
Frusztrál a dolog. Tanácstalan vagyok, hogy hol hibázhatok, mit tehetek még a sikeres élesztés érdekében. Kérem, ha bármelyikőtök használható ötlettel tud szolgálni: segítsen. Kösz!

Legalább nem unatkoztam, és ebbe is "beletanultam", vagy legalábbis elmondhatom, hogy csináltam már. Nincs esetleg ehhez egy magyar használati utasítást szerezni valahonnan? Azzal azért csak könnyebben menne a dolog... (bár talán az alapokat be tudom lőni a régi beállítások alapján)