Bootloader neu flahen ohne löten?!

Beitrag von **kratznich** » Dienstag 18. März 2003, 11:21

Hallo Leute!

Ich habe eine Nokia 2xI Kabelbox und erfolgreich Linux am laufen. Alles wunderbar, bis auf das Problem "dunkelgrünes Display ohne Anzeige - LCD init error -1".
Ich habe viel darüber gelesen und erfolglos alles aus diesem Thread probiert:
http://tuxbox.berlios.de/forum/viewtopi ... &start=100

Ich denke mal, das bei mir das Problem ein defekter Bootloader sein könnte. Nun meine Fragen:

1. Kann es überhaupt sein, das mein BL nur ein bischen defekt ist und alles bis auf das LCD funktioniert?
2. Wenn 1. möglich ist: Kann ich mit diese Methode ( http://www.dbox2.info/doku/reflash.html ) den Booloader überschreiben OHNE den Flash auszulöten, oder ist das unsinn (bzw. der BL bleibt unverändert) und ausschlisslich auslöten hilft?

Vielen Dank für Eure Hilfe!

Beitrag von **Liontamer** » Dienstag 18. März 2003, 11:24

Der Bootloader ist bei deiner Box mit Sicherheit in Ordnung.
Das Problem liegt wo anders.
PS: Solange die Box noch bootet, ist es möglich den BL öhne Lötarbeiten zu schreiben. Davon würde ich dir allerdings abraten.

Beitrag von **DieMade** » Dienstag 18. März 2003, 11:29

Poste doch mal ein Log vom Bootvorgang.

Beitrag von **kratznich** » Dienstag 18. März 2003, 13:36

ein Log habe ich momentan leider nicht parat, da ich im Büro sitze...

Allerdings gibt es dort auch nichts wirklich spannendes zu sehen. Alles sieht gut aus, bis auf

LCD init error -1

Ach ja, das Kabel habe ich auch schon nachgedrückt und lcd_test auch schon ausgeführt - leider ohne Erfolg. Ich habe auch mal ein anderes LCD angeschlossen, das eigentlich funktioniert. Auch das ging an meiner Box nicht (daher auch meine BL Vermutung).

Warum eigentlich ist vom schreiben des BL anzuraten? Ist das ein kritischer Vorgang? Und gibt es wirklich niemanden, bei dem das neuschreiben des BL geholfen hat bei diesem Problem?

schönen Gruss

Beitrag von **doc** » Dienstag 18. März 2003, 19:36

Warum eigentlich ist vom schreiben des BL anzuraten? Ist das ein kritischer Vorgang?

Eigentlich schon! Weil wenn hier was schief geht dann hat man erst mal ein Problem!

Der Spruch: "Never change a running system!" kommt schlieslich nicht von irgendwoher. Gibt im Bereich des BLs nur wenige Leute die Wissen was Sie gerade machen. ;-)

Das LCD wird auch nicht vom Bl initialisiert sondern vom Frontprozessor, also dürfte das Prob dann eher bei diesem liegen.

Der SoLaLa oder MHC dürfen mich nartürlich berichtigen wenn ich hier falsch liege!!

Ich habe deine Versuchsreihe auch schon durchgespielt mit so einer Box. Aber die Fehlermeldung bleibt bei mir auch immer stehen!
Man müßte vieleicht die Routinen eines funktionierenden FP mit denen einer solchen "defekten" Box mal vergleichen.
Allerdings bleibt für mich das Problem wie man den auslesen kann. Eine Steckleiste ist ja da. Aber welche Schnittstelle???

Beitrag von **Zahni** » Dienstag 18. März 2003, 21:09

Der Bootload ist an die jeweilige Hardware angepasst. Eine andere Version bringt absolut 0,nix . Hoechtens Probleme. Es sicher argerlich, dass bei 2xI mit Bmon 1.0 der Schreibschutz i.d.R. nicht aktiviert ist/wird.
Mit "bekannten" Images sollte das aber kein Problem sein.

-Zahni

Beitrag von **Stobi** » Mittwoch 19. März 2003, 13:46

also folgendes hat sich zugetragen bekomme keine Netzwerkverbindung mehr über die 10 mbit variante com is ok der loader loopt zwischen betares und bmon v1.0 gibts ne variante die box wieder zu resetten oder ähnliches um sie da raus zu holen? Ich weis net mehr weiter HIIILLLFFEE!

Beitrag von **DieMade** » Mittwoch 19. März 2003, 13:52

Was tut sich denn noch im COM-Log?

Beitrag von **Stobi** » Mittwoch 19. März 2003, 14:00

Also dieses und das so oft man will!

debug: B/Ex/Fl(MB) 32/00/08

WATCHDOG reset enabled
dbox2:root> debug: DDF: Calibrating delay loop... debug: DDF: 67.79 BogoMIPS
debug: WATCHDOG RESET
debug: BMon V1.0 mID 01
debug: feID 7a gtxID 0b
debug: fpID 5a dsID 01-e4.b6.18.07.00.00-45
debug: HWrev X5 SWrev 0.81
debug: B/Ex/Fl(MB) 32/00/08
WATCHDOG reset enabled
dbox2:root> debug: DDF: Calibrating delay loop... debug: DDF: 67.79 BogoMIPS
debug: WATCHDOG RESET
debug: BMon V1.0 mID 01
debug: feID 7a gtxID 0b
debug: fpID 5a dsID 01-e4.b6.18.07.00.00-45
debug: HWrev X5 SWrev 0.81
debug: B/Ex/Fl(MB) 32/00/08
WATCHDOG reset enabled
dbox2:root> debug: DDF: Calibrating delay loop... debug: DDF: 67.79

Beitrag von **DieMade** » Mittwoch 19. März 2003, 14:05

Hmm, wie haste das denn jetzt hinbekommen? Anfangs lief die Box ja noch

Beitrag von **Stobi** » Mittwoch 19. März 2003, 14:11

DieMade hat geschrieben:Hmm, wie haste das denn jetzt hinbekommen? Anfangs lief die Box ja noch

Haste ne Idee ? das die anfangs noch lief weis ich auch

Beitrag von **Liontamer** » Mittwoch 19. März 2003, 14:20

Was hast du denn seit dem gemacht /verändert?

Beitrag von **kratznich** » Mittwoch 19. März 2003, 14:32

naja, dann werde ich wohl ohne LCD weiterleben, was ja auch problemlos funktioniert

Vielen Dabk für Eure antworten!

Beitrag von **SoLaLa** » Donnerstag 20. März 2003, 01:12

ääääähm,
Stobi <==> kratznich?

um die Verwirrung mal n bissi aufzulösen wärs vielleicht sinnvoll sich dazu zu äußern ob es hier um eine oder um 2 Boxen geht

@kratznich:
Du kannst ja trotz dunklem Display den bootloader auslesen und müßtest den einfach nur mit einer intakten box vergleichen... da wird sich dann mit ziemlicher Sicherheit zeigen, daß der (wie Liontamer schon anmerkte) 100% ok ist.

Beitrag von **MHC** » Donnerstag 20. März 2003, 02:02

SoLaLa hat geschrieben:ääääähm,
Stobi <==> kratznich?

mhhh

@Stobi
tja Verwirrung ausgelöst ... das passiert, wenn man meint ein Ähnliches Problem zu haben
... neues Posting wär da besser gewesen ...
drück mal die 'up' taste am Gerät (ist die rechte), damit wir ein kleiner Selbstest ausgelöst ....
und poste mal das Log ...

Beitrag von **Stobi** » Donnerstag 20. März 2003, 12:48

@MHC
Also hier das log mit selbsttest kann dem aber nix entnehmen

bdebug: DDF: Calibrating delay loop... debug: DDF: 67.79 BogoMIPS
debug: BMon V1.0 mID 01
debug: feID 7a gtxID 0b
debug: fpID 5a dsID 01-e4.b6.18.07.00.00-45
debug: HWrev X5 SWrev 0.81
debug: B/Ex/Fl(MB) 32/00/08
WATCHDOG reset enabled
debug: &_text 0x10000, &_etext 0x26160, &_data 0x26160, &_edata 0x29c50
debug: &_end 0x347dc, &__stack 0x400000
debug: Memory tests (0x400000 -- 0x2000000)
debug: NumberTest: debug: passed
debug: MarchTest: debug: DDF: Calibrating delay loop... debug: DDF: 67.79 BogoM
IPS
debug: WATCHDOG RESET
debug: BMon V1.0 mID 01
debug: feID 7a gtxID 0b
debug: fpID 5a dsID 01-e4.b6.18.07.00.00-45
debug: HWrev X5 SWrev 0.81
debug: B/Ex/Fl(MB) 32/00/08
WATCHDOG reset enabled
debug: &_text 0x10000, &_etext 0x26160, &_data 0x26160, &_edata 0x29c50
debug: &_end 0x347dc, &__stack 0x400000
debug: Memory tests (0x400000 -- 0x2000000)
debug: NumberTest: debug: passed
debug: MarchTest: debug: DDF: Calibrating delay loop... debug: DDF: 67.79 BogoM
IPS
debug: WATCHDOG RESET
debug: BMon V1.0 mID 01
debug: feID 7a gtxID 0b
debug: fpID 5a dsID 01-e4.b6.18.07.00.00-45
debug: HWrev X5 SWrev 0.81
debug: B/Ex/Fl(MB) 32/00/08
WATCHDOG reset enabled
debug: &_text 0x10000, &_etext 0x26160, &_data 0x26160, &_edata 0x29c50
debug: &_end 0x347dc, &__stack 0x400000
debug: Memory tests (0x400000 -- 0x2000000)
debug: NumberTest:@

Beitrag von **doc** » Donnerstag 20. März 2003, 21:46

@MHC
Kannst du diese Zeilen für Unwissende mal übersetzten?

Code: Alles auswählen

debug: &_text 0x10000, &_etext 0x26160, &_data 0x26160, &_edata 0x29c50
debug: &_end 0x347dc, &__stack 0x400000

Danke!! (Wenn dies dir möglich ist.

)

Ich kann mir bis heute keinen richtigen Reim darauf machen in Form wo jetzt was getestet wird! Wird bei diesem test nur der Ram oder auch der Ram des Avia getestet?

Beitrag von **MHC** » Donnerstag 20. März 2003, 21:57

@stobi
mhh ...
sieht nach einem RAM-Fehler aus
der Number-test war noch okay
aber beim March-test greift der Watchdog zu ...
könnte aber auch Zufall sein ... der Wachtdog ist ja Timerabhängig
... um einen Rep.-Service wirst du wohl nicht drumherumkommen ...

@doc
getestet wird nur Ram
... Memory tests (0x400000 -- 0x2000000)
und die Zahlen da sind nur adressen, wo der Loader was ablegt

Beitrag von **SoLaLa** » Donnerstag 20. März 2003, 22:01

na das laß ich mal MHC ruhig dokumentieren

obwohl die grauen Zellen sagen, daß da halt irgendwelche Initalisierungen stattfinden (bei edata +offset 0x10 liegt ja die variable für den temporären debug, da werden die anderen sachen auch nur irgendwelche Pointer sein)

@stobi:
wieso kannst dem nix entnehmen:

debug: Memory tests (0x400000 -- 0x2000000)
debug: NumberTest: debug: passed
debug: MarchTest: debug: DDF: Calibrating delay loop... debug: DDF: 67.79 BogoM

???
da ist das RAM defekt, zumindest läuft der Test nicht durch und die Box resettet

Beitrag von **SoLaLa** » Donnerstag 20. März 2003, 22:03

ups... MHC

...so früh?
bist krank oder hast Urlaub?

Beitrag von **MHC** » Freitag 21. März 2003, 03:55

SoLaLa hat geschrieben:ups... MHC ...so früh?
bist krank oder hast Urlaub?

nein und nein ... jobless

Beitrag von **doc** » Freitag 21. März 2003, 21:54

Thx MHC!

Aber ich meine eben den Text vor den Speicherzellen in der Ausgabe.
Also &_text und &_etext und so weiter. Müssen ja irgendwas bedeuten.

Beitrag von **MHC** » Samstag 22. März 2003, 03:07

doc hat geschrieben:Thx MHC!

Aber ich meine eben den Text vor den Speicherzellen in der Ausgabe.
Also &_text und &_etext und so weiter. Müssen ja irgendwas bedeuten.

nichts besonderes eigentlich ...
stack/pointer/variablen ... alles was der loader zum arbeiten eben braucht ..

Beitrag von **doc** » Samstag 22. März 2003, 20:16

Aha!

Muß man ja eben erst mal wissen!

THX nochmal!

Beitrag von **Stobi** » Sonntag 23. März 2003, 14:57

THX A lot @all habt ihr vielleicht noch nen Tip wem man das ding schicken könnte (zum reparieren)

Tuxbox-Board

Bootloader neu flahen ohne löten?!

Bootloader neu flahen ohne löten?!

Hi Leuts wer kennt sich aus wenn der bootloader mal loopt

Also das steht drin!

THX LOT @all