w700v - kein Bootloader mehr?

[johnp]

Hallo liebes Forum,

ich hab einen w700v geschenkt bekommen, der das Dauer-Reboot-Problem hatte. Nach der Anleitung von http://www.kessler-design.com kam ich auf drauf und konnte die alte 1.22 Firmware erfolgreich flashen. Da das Problem jedoch weiterhin nach einem erneuten Update auf eine höhere Version auftrat, wollte ich ihn mal ganz "sauber" machen.

Leider habe ich es im Erase-Menü etwas zu gut gemeint, denn jetzt sagt er nur noch:

Version 1.0.1
Read EEPROM
Jump to Flash

-und das wars.

Weiß jemand, welche Möglichkeiten es jetzt noch gibt? Jtag etc.

Viele Grüße
john

 

[scolopender]

Ich drehe das mal herum:

Jtag ...

Der Platz für einen JTAG-Pfostenstecker ist zwar vorhanden, jedoch scheint mir die JTAG-Schnittstelle nicht komplett zu sein: Man kann schreiben, aber nicht zurücklesen.

Weiß jemand, welche Möglichkeiten es jetzt noch gibt?

Flash auslöten, mit dem Bootloader programmieren, wieder einlöten.
Einen Bootloader bekommst Du, wenn Du die aktuelle FW mir dem SP700EX-Tool in ihre Komponenten zerlegst, es ist der dritte Teil ("Teil mit bislang unbekannter Funktion").

Nachtrag: Es geht auch noch anders - siehe weiter unten.

G., -#####o:

 

[Jpascher]

Gibt dafür eine Anleitung für den W701, die nötigen Programme und auch einen Plan wie die Verdrahtung aussehen muss.

Damit geht auslesen so wie auch schreiben, somit sollte das in ähnlicher weise auch beim W700 funktionieren.

 

[johnp]

Erstmal vielen Dank an euch beide. Das klingt ja vielversprechend.
Dann werde ich mal die Anleitung suchen...

 

[scolopender]

... für den W701

Zwischen W701V (AVM) und W700V (Arcadyan) liegen Welten, der Unterschied ist mitnichten lediglich 1.

... somit sollte das in ähnlicher weise auch beim W700 funktionieren.

Sollte - tut es aber nicht.

G., -#####o:

 

[Jpascher]

Das stimmt schon nur was jtag angeht wird vieles gleich sein.

 

[scolopender]

Das stimmt schon nur was jtag angeht wird vieles gleich sein.

Es geht (zumindest mit einschlägigen Tools wie z.B. hier) trotzdem nicht (es sei denn, man weiß genau, was man - sozusagen blind - an der JTAG-Schnittstelle ausgeben muss - ich weiß es nicht).
Pinout des JTAG-Headers "J16" beim W700V. Pin 1 hat ein quadratisches Lötauge und ist mit einer Pfeilspitze (Dreieck) markiert.
"TDO" ist nicht mit dem Prozessor (oder sonst irgendeinem Chip) verbunden. Außerdem muss man den "R17" (0 Ohm, sozusagen Drahtbrücke nach Masse, bei "J16") entfernen, damit "nTRST" ansteuerbar wird.

G., -#####o:

 

[Jpascher]

Gut ich hab das Teil nicht darum weist du das sicher besser.

Ich habe aber in meine Variante des wrtg54 auch Test Routinen eingebaut die einen ermöglichen die Pinbelegung prüfen.
Quellcode ist vorhanden und könnte erweitert werden wenn das erforderlich sein sollte.

Und wenn in der Chain mehr als ein Chip sein sollte so findet das Tool auch selbständig die vorhanden Chips wenn diese bereit in der Liste vorhanden sind auch mit der Chipbezeichnung. Es spielt somit keine Rolle ob TDO direkt an die CPU geht oder nicht.
nTRST muss natürlich richtig gesetzt sein.

 

[scolopender]

Es spielt somit keine Rolle ob TDO direkt an die CPU geht oder nicht.

Auf die Gefahr hin, dass ich mich wiederhole: TDO geht an garnichts, es hat lediglich einen Pull-Up-Widerstand. Dagegen hilft kein noch so tolles Tool.

G., -#####o:

 

[Jpascher]

Gut das verwundert mich sehr, aber auch in diesen Fall kann man herausfinden wo die TDO Leitung am Print endet.

Man taktet den TDI (mit meinen Tooll oder mit etwas alternativen) und sucht mit einen Hilfsmittel, am einfachsten mit ein Oszilloskope (eine low current LED mit Widerstand in Serie reicht aber auch) den Hotspot an dem TDO auftaucht. Wenn es eine Pinbelegung zur CPU gibt kann auch da nachsehen an welchen Pins TDI und TDO zu finden sind. Wird TDI länger Zeit getackte so erscheint am TDO fast das selbe was man am TDI rein schickt. Wahrscheinlich stellt sich raus, dass am Print irgendwo ein Null Ohm Widerstand bestückt werden muss um TDO am Steckverbinder zu bekommen.

Der Chip wurde sicher in der Fertigung im eingebauten Zustand programmiert, und Tests werden normalerweise ebenfalls bei der Fertigung verwendet die das EJTAG nutzen, also müsste es auch die passenden Anschlüsse geben auch wenn diese normal nur über Nadelkontakte angeschlossen werden.

 

[scolopender]

Gut das verwundert mich sehr...

Mich auch.

aber auch in diesen Fall kann man herausfinden wo die TDO Leitung am Print endet.

Die Leitung geht von der Durchkontaktierung (für die Pfostenleiste) zum besagten Pull-Up-Widerstand - Ende.

... und sucht mit einen Hilfsmittel ...den Hotspot an dem TDO auftaucht.

Genau - an einem ball vom Prozessor-BGA - unzugänglich.

Wahrscheinlich stellt sich raus, dass am Print irgendwo ein Null Ohm Widerstand bestückt werden muss um TDO am Steckverbinder zu bekommen.

Einer der Anschlüsse eines nicht bestückten Widerstands müsste dann eine Verbindung zum TDO-Pin der Pfostenleiste haben - ich habe keinen gefunden.

Der Chip wurde sicher in der Fertigung im eingebauten Zustand programmiert...

Der Flash-Speicher wird schon vorprogrammiert auf die Leiterplatte montiert. Nur deshalb (d.h. zur Unterscheidung von nichtprogrammierten ICs) hat er einen Aufkleber oder einen Aufdruck - da steht dann sinnigerweise drauf, was drin ist.

G., -#####o:

 

[scolopender]

W700V - kein Bootloader mehr - Update!

Neue Erkenntnisse - auch wenn möglicherweise für johnp zu spät :?.

So ganz tot ist das W700V ja nicht, immerhin kann es noch ausgeben:

Version 1.0.1
Read EEPROM
Jump to Flash

Da geht noch mehr: Auf der Leiterplatte befinden sich zwischen dem Prozessor und den beiden RAM-ICs leergelassene Einbauplätze für ein paar Widerstände, und zwar R959 und R960 auf der (eigentlichen) Bauteilseite der Leiterplatte und ungefähr an der gleichen Stelle auf der Rückseite R966. Baut man bei R960 und R966 2.2kOhm-Widerstände ein *), schreibt das W700V nach dem Einschalten:

Version 1.0.1
Read EEPROM
Serial Download

Es wird dann eine Textdatei mit einem Programm (in Hex-Ziffern) erwartet, das in das RAM geladen und gestartet wird.

Näheres (u.a. eine passende Datei für den "Serial Download") bei Bedarf.

Alle möglichen Einbauvarianten:

  |R960|R959|R966| Textausgabe
--+----+----+----+------------------------------------------------
0 | -  | -  | -  | Version 1.0.1 / Read EEPROM / Jump to Flash
--+----+----+----+------------------------------------------------
1 | -  | -  | +  | (keine Ausgabe, Verhalten wie "Jump to Flash")
--+----+----+----+------------------------------------------------
2 | -  | +  | -  | Version 1.0.1 / Read EEPROM / Mii Download
--+----+----+----+------------------------------------------------
3 | -  | +  | +  | Version 1.0.1 / Read EEPROM / Mii Download
--+----+----+----+------------------------------------------------
4 | +  | -  | -  | Version 1.0.1 / Read EEPROM / Read Serial Flash
--+----+----+----+------------------------------------------------
5 | +  | -  | +  | Version 1.0.1 / Read EEPROM / Serial Download
--+----+----+----+------------------------------------------------
6 | +  | +  | -  | Version 1.0.1 / Product Test Done
--+----+----+----+------------------------------------------------
7 | +  | +  | +  | Version 1.0.1 / Wrong Pin Strap
--+----+----+----+------------------------------------------------

- leergelassen   
+ Widerstand "eingebaut"

Was bei Nummer 2/3 und 4 erwartet wird, weiß ich nicht. Interessant ist nur die Nummer 5.

*) Ich habe die Widerstände zusammen mit einer 2x3-Pin-Pfostenreihe auf ein kleines Stück Lochrasterplatte motiert und mit dünnem Kupferlackdraht mit den Einbaupositionen verbunden. Die Pin-Paare der Pfostenreihe sind so verbunden, dass ich mit Jumpern die Widerstände einzeln zu- und wegschalten kann.

G., -#####o:

 

[Jpascher]

Ja es scheint nicht mehr aktuell zu sein,a aber trotzdem man weiß ja nie ob das nicht noch einmal jemand braucht.

Wenn du noch mehr Infos dazu hast oder Links dazu, bitte poste diese auch noch.

Ist die bin Datei (Firmware) auch irgendwo zum runter laden?
Ein Link wäre nützlich.

 

[byteeater]

[EDIT: Riesenquote von scolopender entsorgt. --gandalf.]

:groesste:
FETTES THXS FÜR DIE INFO !!!

 

[scolopender]

W700V Bootloader - Serial Download

Ist die bin Datei (Firmware) auch irgendwo zum runter laden?

Nicht direkt - aber man braucht ja zunächst lediglich wieder einen funktionierenden Bootloader im Flash.
Der Bootloader ist auch in der derzeit aktuellen FW-Version 3.30.000 enthalten. Wenn man die mit dem SP700EX-Tool zerlegt, ist es die dritte der insgesamt fünf enstehenden Dateien (ebendort als "Teil mit bislang unbekannter Funktion" bezeichnet).

In die angehänge .zip-Datei habe ich gepackt:
bl0930.bin den aus der aktuellen Firmware extrahierten Bootloader
blrecover.hex die Textdatei für den "Serial Download"
serloadtest.hex eine Datei zum Testen des "Serial Download".

Beim Entpacken darauf achten, das die in den .hex-Dateien enthaltenen Zeilenumbrüche <cr><lf> (0x0D 0x0A) erhalten bleiben!

Die blrecover.hex (und zum Testen: die serloadtest.hex) muss (müssen) so, wie sie ist (sind), an das W700V übertragen werden (HyperTerminal: Übertragung - Textdatei senden).
Damit das korrekt funktioniert, musste ich zuvor in der HyperTerminal ASCII-Konfiguration "Gesendete Zeilen enden mit Zeilenvorschub" anhaken.
Wenn nach dem Senden der Testdatei serloadtest.hex ein "Jump to Flash" ausgegeben wird, funktioniert der Download (an sich) richtig. Passiert danach garnichts oder es kommt eine Fehlermeldung ("Terminator Wrong" oder "ChSum Wrong"), stimmen die Einstellungen nicht!

Beim Laden der blrecover.hex gibt das W700V für jede empfange Textzeile einen Punkt aus, danach kommt das bekannte:

=======================================================================
 Wireless ADSL Gateway AMAZON Loader V0.93.0 build Nov 10 2006 17:16:22
                    Broad Net Technology, INC.
=======================================================================
EON EN29LV320B bottom boot 16-bit mode found
[GPIO FLOW] SetGpio() Begin ..
[GPIO FLOW] SetGpio() End.

Copying boot params.....DONE

Press Space Bar 3 times to enter command mode ...123
Yes, Enter command mode ...


[AMAZON Boot]:

(Wenn die "boot params" auch gelöscht waren, steht an der Stelle was anderes.)
Das läuft aber jetzt nicht aus dem Flash, sondern steht nur im RAM!
Nach dem "123" musste ich den Haken bei "Gesendete Zeilen enden mit Zeilenvorschub" wieder herausnehmen, damit die weitere Bedienung richtig funktioniert:
Eingabe eines Ausrufezeichen ! (für den Administrator-Mode), U (Upload to Flash), 0 (Area "Boot").
Nun den Bootloader bl0930.bin laden (HyperTerminal: Übertragung - Datei senden - Protokoll: Xmodem) - der wird dann wieder ins Flash geschrieben!
Schließlich: W700V ausschalten, Widerstände "deaktivieren", W700V wieder einschalten. Wenn alles gut gegangen ist, läuft jetzt zumindest das "Recovering Tool" (s.u.).

G., -#####o:

 

[Jpascher]

Danke das sind wertvollere Infos!

 

[el_valiente]

Wenn alles gut gegangen ist, läuft jetzt zumindest das "Recovering Tool" (s.u.)

Auch von mir: Danke
Zwar habe ich keinen (Bedarf an) Speedport W700V, aber man kann ja nie wissen, was die Zukunft noch alles bringt ...

 

[Mona2000]

Die blrecover.hex (und zum Testen: die serloadtest.hex) muss (müssen) so, wie sie ist (sind), an das W700V übertragen werden (HyperTerminal: Übertragung - Textdatei senden).
Damit das korrekt funktioniert, musste ich zuvor in der HyperTerminal ASCII-Konfiguration "Gesendete Zeilen enden mit Zeilenvorschub" anhaken.
Wenn nach dem Senden der Testdatei serloadtest.hex ein "Jump to Flash" ausgegeben wird, funktioniert der Download (an sich) richtig. Passiert danach garnichts oder es kommt eine Fehlermeldung ("Terminator Wrong" oder "ChSum Wrong"), stimmen die Einstellungen nicht!

Beim Laden der blrecover.hex gibt das W700V für jede empfange Textzeile einen Punkt aus, danach kommt das bekannte:

I see blrecover.hex it's not a 1:1 byte copy of bl0930.bin.
Could you explain how to encode a binary file into that hex representation?
I see it's something like:

[8 byte memory address][64 bytes of data]
[8 byte memory address][64 bytes of data]
...
11111111[8 byte checksum][56 bytes of 0s]
99999999[8 byte memory address]

What part of the binary file gets put into memory? It's way smaller than the 128kbs of bl0930.bin.
Also, what kind of checksum is that? Is it calculated only using the bytes above?
What about the memory address in the last line?

Sorry if I write in english but my german is very bad,
Thanks

 

[scolopender]

I see blrecover.hex it's not a 1:1 byte copy of bl0930.bin

This is only the beginning (I omitted the Recovering Tool) with some minor modifications.

Could you explain how to encode a binary file into that hex representation?

I'll try it:

[8 byte memory address]

8 hexadecimal digits, representing a 32-bit memory address, big endian.

[64 bytes of data]

Should be 128 hexadecimal digits, representing 16 32-bit pices of code or data (also big endian), consecutively loaded at the preceeding memory address.

11111111[8 byte checksum]

Checksum signature and 8 hexadecimal digits, representing a 32-bit checksum (also big endian), sum of all preceeding 32-bit quantities, ie. addresses and code/data.

[56 bytes of 0s]

Should be 120 digits padding.

99999999[8 byte memory address]

Start address signature and 8 hexadecimal digits, representing a 32-bit start address (also big endian), entry point of the loaded program.

Each address must be at least a multiple of 4, so 11111111 and 99999999 never are valid addresses.

Attached the C program I scribbled to convert a binary into this format. You will need to modify the buffer size and the addresses. Unfortunately, comments are in German. Use it at your own risk .

G., -#####o:

 

[Mona2000]

Thanks.
I managed to convert the bootloader into that format, but after all the dots (lines received by device) it does nothing and stays blank (the only working jump i ever saw was your serloadtest.hex).
I'm starting to think the RAM is damaged...