[Berlin-wireless] WRT54GS zu Tode geflasht?

[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