full recovery oder werksreset

[frodo.]

Der DECT Teil dürfte ähnlich wie bei der AVM 7150 sein, zumindest ist der Funtionsumfang ähnlich wenn auch die Mobilteile unterschiedlich sind.
7150: SwissVoice
W900V: Telekom 300i bzw. 500i

Dort wird die DECT Firmware unabhängig der Fritzfirmware geflasht allerdings über das GUI der Fritzbox und somit auch über dort vorhandene Skripte.

 

[RalfFriedl]

Da beide Geräte von AVM sind, kann man davon ausgehen, daß die Hardware gleich ist. Eine Firmwareupdate für die 7150 passt auch auf den W900V.

Die GUI der FritzBox lädt zum Update ein Programm samt Daten, so daß darüber beliebige Aktionen möglich sind. Deswegen kann man ja auch mit den Pseudo-Updates verschiedenste Modifikationen an der Box vornehmen.

 

[Jpascher]

@RalfFridl
ich kann dir gern das nicht funktionerense Skript für die Anpassung des w701 images an den W900 senden, spannender würde mich interessiern warum überhaut da Probleme entstehn wenn doch die Hardware angeblich so ähnlich ist.
Ein Parameter ist die Hardwarerevisionsnummer "HRrevision" = 102 oder 101.
Das habe ich aber umgangen. Mich würde auch nicht stören wenn zu Beginn mal nicht alles funktioniert aber Abstürze sollte es halt nicht geben.

 

[RalfFriedl]

Die Hardware ist wohl nur teilweise ähnlich. Der interne S0-Bus, USB-Anschluß und DECT fehlen.
Ich vermute, daß zumindest S0-Bus und USB-Anschluß, vielleicht auch DECT über den programmierten xilinx-Baustein realisiert werden.

HRrevision ist auch von Bedeutung für die Initialisierung der Eigenschaften der Box.

 

[Jpascher]

@RalfFridl
Mir ist wohl bewußt das der W701 in macher Beziehung abgemagert ist im vergleich zum W900V, abe das sollte, wennder rest gleich ist doch kein Problem darstellen.
der xilinx spielt eine relativ wichtige Rolle und das bin file das auf den xilinx geladen wird wird auch abhägig von der HWRevisons Nummer ausgewählt.

Interessant ist aber, dass die bin files gleich sind bei beiden Images zumindest das welches geladen wird wenn die HWRevison 102 ist.
Die Software unterscheidet sich prakisch auch kaum, ausser dass bestimmte Teile eben etwas neuer sind. Mir ist nirgens aufgefallen, dass der W701 eine abgemagerte Version hätte, vielmehr wird alles über Softwareschalter gesteuert.
Die Initialisierung der box mit den diversen Variablen hab ich so weit ich glaube ziehmlich im griff, es sind einige neue "Schalter" dazugekommen aber die decken sich weitgehend mit dem neuen Schaltern von der 7170 an denen kann es auch nicht liegen. Ich vermute immer noch, dass es mit den Defaultwerten zusammenhängt warum es zu reboots kommt, asser ihr habt da eh bereits Erfahrungen die ich nicht kenne.

Eine Frage noch hast du eine Ahnung wie ich zu eine Log des Statvorgangs komme?
Die software muss auch einen push tftp (server auf 192.168.178.20) debug modus unterstützen, hat das jemand bereits verwendet?

 

[RalfFriedl]

Ich kenne nur die Möglichkeit mit der Seriellen Konsole.

 

[Jpascher]

@RalfFridl
Danke, zumindest wies ich damit das scheinbar doch kein sehr einfacher alternativer Weg praktiziert wird um zu einen Log zu gelangen.

Aber für einen funktionierenden Speedport müsste es doch ein log geben, darüber hab ich bis jetzt auch noch nichts gefunden.
Wenn ich Zeit finde werde ich mich morgen mal etwas mehr mit dem DS-mod auseinadersetzen hab sowiso jede Mege nachholbedarf.

 

[RalfFriedl]

Wenn das System mal läuft, kann man mit dmesg sich die Kernel-Meldungen anschauen.
Das hilft aber nicht, wenn das System nicht soweit kommt.

 

[Jpascher]

dsmesg hab ich bereits benutzt, dachte ich mir auch dass das nur später von nutzen ist. Ich geb auf für heute bin echt müde, habe heute 11 Stunden bei meinen Nebenjob Elektronik Hardware zerlegt getestet und ...

 

[kriegaex]

dmesg hat das Problem, daß nach dem Starten der Box oft der Anfang der Kernel-Bootvorgangs oft schon aus dem Ringpuffer "herausgescrollt" wurde, weil der nur 16 KB groß ist im Standard-Kernel. Deswegen habe ich zu ds26-15.0 bereits eine Möglichkeit eingebaut, um rechtzeitig in rc.S den ersten Teil des Ringpuffers wegspeichern zu lassen, den zweiten kann man dann in rc.custom oder manuell abspeichern und dann beide zusammensetzen, indem man die Überlappung wegschneidet. Vom Bootloader bekommt man so zwar immer noch kein Log, aber vom Kernel schon. Nur muß er, wie Ralf bereits schrieb, auch so weit hoch kommen, daß man an die Log-Dateien überhaupt herankommt.