[Berlin-wireless] WRT54GS zu Tode geflasht?

[tm-107]

Hallo nochmal,

Danke für die Tips, einige habe ich ausprobiert, andere nicht (mangels
Linux) ... leider ohne Erfolg.

Nun habe ich mich drangesetzt und beide Schnittstellen aufgelötet.
Könnte ich damit heute Abend in die c-base fahren? Wenn ja, an wen muss
ich mich da wenden und ab wann?
Oder wohnt vielleicht jemand näher dran der mir helfen kann? Ich selbst
wohne in Hohenschönhausen ...

gruss
Torsten

------------------------------------------------------------------------
Am 09.08.2006 15:10 Uhr schrieb Marco Tidow:
> On Mon, Aug.07. 22:40 +0200, Ufo wrote:
>   
>> tm-107 schrieb:
>>     
>>> - dann bin ich soweit gegangen Pin 15+16 am Flash-Chip kurzzuschliessen
>>> um den Flash zu löschen, auch ohne Erfolg
>>>   
>>>       
>> wenn da mal nix kaputtgegangen ist :-/
>>     
>
> @all: für diese Kurzschluß-Variante _immer_ vorher das datasheet des
>       entsprechenden flash-chips konsultieren und prüfen, ob sein pinout
>       (Kurzschluß zweier _Adreßleitungen_) paßt 
>
>   
>>> Könnte da evtl ein JTAG helfen? Wenn ja wo kommt der hin? Dann könnte
>>> ich zumindest schonmal den Anschluss einlöten ...
>>>   
>>>       
>> nicht notwendig!
>>     
>
> JTAG ist der Königsweg.  Etwas nervig wg. Nachbestückung des headers, aber
> in diversen Fällen war es das Einzige, was noch ging...
> Dazu lohnt, einen gepufferten (HC244) Adpater zu bauen, die primitiv-Variante
> mit ein paar Widerständen an der parallelen ist nicht wirklich brauchbar,
> Probleme mit zu schlappen CMOS-Parports, zu hohe Spannungen für 3V-Logik.
>
> Bei den WRT´s >= v1.1 ist es der 12polige header.  Wenn man schon dabei ist,
> sollte man aber gleich auch den 10pol. seriellen nachbestücken.
>
> Das Blinken der power-LED zeigt an, daß kein gültiges firmware-image (checksum)
> im flash gefunden wurde.  Der tftp-server im bootloader ist recht zickig, z.B. was
> die blocksize angeht.  Es lohnt, verschiedene clients - auch z.B. windoze-* - zu
> probieren.  Häßlich dabei kann sein, wenn sich der IP-stack im client schon beim
> arp-en verhaspelt (cat /proc/net/arp), und keine oder eine falsche MAC für die
> 192.168.[01].1 IP hat...  Dazu kann man (unter linux) probieren, per
>
>   ip neighbour add    to 192.168.1.1 lladdr 00:0f:66:5b:65:fc dev eth1
>
> resp.
>
>   ip neighbour change to 192.168.1.1 lladdr 00:0f:66:5b:65:fc dev eth1
>
> den ARP-cache im client statisch vorzubelegen, so daß die tftp-packets wirklich
> an die MAC des routers rausgehen (MAC und interface natürlich anpassen).
>
> Wenn das NVRAM durcheinander gerät, hilft ggfs., an der seriellen den boot-Vorgang
> zu verfolgen:
>
>         power reboot des routers
>
>         sobald [tftp-] timeout msg via serial, reset button drücken
>
>           "==> push button" erscheint im CFE
>
>         CFE started neu
>
>           "update lan mac from [00:90:4C:60:00:2A] to [00:0F:66:C7:80:CC]"  (letztere ist die richtige)
>           "Committing NVRAM...done"
>
>         CFE started neu
>
>         reagiert auf tftp transfer (code.bin)
>
> letzteres stammt von einem GS v1.0, dem ich einen neuen CFE bauen mußte (per JTAG
> geladen), der danach aber immer noch nicht auf tftp reagieren wollte.  Nach dem
> Neu-Schreiben des NVRAM (seitens des CFE) lief´s dann, ist jetzt wieder völlig o.k.
>
> Gruß, marco
>
> P.S. wenn´s garnicht will, melde Dich einfach mal per PM
>
>
> _______________________________________________
> Berlin mailing list
> Berlin at olsrexperiment.de
> https://www.olsrexperiment.de/cgi-bin/mailman/listinfo/berlin
>
>
>   
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: http://lists.olsrexperiment.de/cgi-bin/mailman/private/berlin/attachments/20060809/bbe6197c/attachment.htm 
-------------- nächster Teil --------------
_______________________________________________
Berlin mailing list
Berlin at olsrexperiment.de
https://www.olsrexperiment.de/cgi-bin/mailman/listinfo/berlin