Jump to content

dbox nokia 2x intel bmon 1.0 debug enabeln


Empfohlene Beiträge

Hallo Leuts,

 

Ich hab schon gesuch im Forum aber keine Lösung für mein problem gefunden.

Ich versuch besagte Box in den Debug zu bekommen, leider ohne Erfolg.

Kurzschluß klapt, pcboot wird übertragen und bei icache kommt die

richtige rückmeldung. Wenn ich aber chorus 800000 ausführe bleibt

die box in einer Resetschleife. Was mache ich falsch ? oder

wie gehts richtig ?

 

MfG

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hmm tut mir leid aber ich kann keinen Fehler entdecken.

Wie gesagt Ablauf ist folgender:

1. Bootmanager mit parametern starten =io

2. Dbox starten , die lädt dann Pcboot und macht resetschleife =io

3. Taste drücken bis zahlen da, dann kurzschluß und 5 Balken bleiben stehen =io

4. ichache probieren rückmeldung da = io

5. chorus 800000 eingeben da kommt im Terminal noch ne Meldung Branding 0x4000 dann fährt die box wieder permanent resets =nicht io

 

was ist an der Reihenfolge falsch ?

 

Danke schon mal für die Hilfe

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 1 year later...

Hallo zusammen

 

ich hänge mich hier mal rein, weil mein problem mit meinem boxchen hier am besten beschrieben ist.

alle bisherigen versuche, die box in den debug zu bekommen waren nicht von erfolg gekrönt.

die in diesem thread beschrieben vorgehensweise führt auch nicht zum gewünschten ziel.

 

bei der letzten eingabe (kopieren des veränderten RAMs ins flash) erhalte ich einen timeout.

 

hier mal das log:

 

icache

icache is on

chorus 800000

Branching to 0x40000

 

 

ppcboot 0.6.4 (Nov 1 2002 - 18:37:07)

 

Initializing...

CPU: PPC823ZTnnA at 67 MHz: 2 kB I-Cache 1 kB D-Cache

*** Warning: CPU Core has Silicon Bugs -- Check the Errata ***

Board: ### No HW ID - assuming TQM8xxL

DRAM: (faked) 32 MB

Ethernet: 00-50-xx-xx-xx-xx

FLASH: 8 MB

LCD driver (KS0713) initialized

Input: serial

Output: serial

 

dbox2-ppcboot> cp 10000000 01000000 1000

dbox2-ppcboot> nm 01000944

01000944: ffffffff ? 00000000

01000944: 00000000 ?

dbox2-ppcboot> prot off 1:0

Un-Protect Flash Sectors 0-0 in Bank # 1

.dbox2-ppcboot> cp 01000000 10000000 1000

Copy to Flash... Timeout writing to Flash

dbox2-ppcboot>

 

 

ich sollte noch dabei sagen, daß die box "defekt" ist --> KEIN SYSTEM

 

mag es sein, daß der/die flashbausteine nicht in ordnung sind oder hat jemand eine andere hilfreiche idee für mich?

 

die klassischen versuche (bootmgr mit "enable debug mit mitflash) scheitern auch daran, daß der

schreibschutz nicht aufgehoben wird.

auch die brücke an RH4/XH4 habe ich erfolglos probiert (schreibschutz).

 

für hilfreiche tips wäre ich dankbar.

 

gruß

 

p.

Link zu diesem Kommentar
Auf anderen Seiten teilen

normalerweise mach ich das bei nokia boxen so:

 

1. dboxbootmanager mit minflsh

2. beim kurzschlußzeitpunkt den flash auf gnd legen

3. kommt antwort auf "help" im rsh-fenster dann gnd wieder aufheben

4. script starten "enable debug mit minflsh"

5. im com-terminal schauen nach "DONE"

 

fertig!

Link zu diesem Kommentar
Auf anderen Seiten teilen

hallo

so wie du beschrieben hast, sah mein erster versuch auch aus.all

erdings erfolglos.

wenn ich es schaffe, lade ich heute nachmittag einen log des terminals ber o.g. variante hoch.

komme gerade von der nachtschicht und gehe nun ins bett.

 

danke schonmal für die hilfe.

 

gruß

 

p.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Bist du sicher das du in der Ausgabe diese Meldung hattest?

 

DebugEnabler © tmbinc, gillem +(sagem,amd,philips) 1.8 beta

bl-version :1.0

product? at :10000944

current state :tmb-locked

flashrom type :2x16 bit? yes. vendor: INTEL

unprotecting :OK! flashing NOW :DONE !

 

Wenn du Die Methode mit den Brücken RH4/XH4 nimmst, hast du die danach auch wieder entfernt?

Ich benutzte immer die Kurzschluss PIN 12 Methode (Achtung!!! Nur für erfahrene!!!).

 

Habe gestern erst eine Box nach dem Schema von zbxyz erfolgreich in den Debug versetzt.

Link zu diesem Kommentar
Auf anderen Seiten teilen

hallo smith

nach der methode habe ich auch schon einige gemacht, nur diese zickt rum.

hier das log des scriptes "debug enable mit minflash":

 

DebugEnabler © tmbinc, gillem +(sagem/13,amd,philips) 1.8beta

bl-version : 1.0

product? at : 10000944

current state : locked

flashrom type : 2x16 bit? yes. vendor: INTEL

engaging gillem-code...

COULDN'T WRITE, IT'S STLL FFFFFFFF

Sorry about that.

 

Please reset now!

 

 

kannst du mir einen link zu infos bez PON12-Methode geben?

 

danke im voraus

 

gruß

 

p.

Link zu diesem Kommentar
Auf anderen Seiten teilen

kannst du mir einen link zu infos bez PON12-Methode geben?

 

danke im voraus

 

gruß

 

p.

 

@Mod ich hoffe das mit dem Link geht i.o

 

http://www.systemengineers.de/dbox2/nokia-debug-mode

 

Bei dem u.g Link hat man leider keine Bilder.

wiki.tuxbox.org/wiki/index.php/Schreibschutz_aufheben

 

Ist schön bebildert mit den Chips.

Wie gesagt bitte mit Vorsicht behandeln!

Ich hoffe du hast Lötkolbenerfahrung sonst ist die Box schnell platt.

 

Aber du schreibst ja das du das schon öfters gemacht hast.

 

Folgende Info habe ich zu deiner Meldung.

Sie bezieht sich zwar auf AMD aber sagt etwas zur möglichen Ursache der Fehlermeldung aus:

 

<Zitat>

Nokia with 2 AMD Flash

 

You have to shorten the jumper XH3 (at the front next to the card reader)

Just connect he contacts if there are no jumper pins.

Connect the contacts firmly for as long as the write protection has to be disabled.

Shortly tipping them is not enough!

 

If there is output in the com-terminal like:

 

COULDN'T WRITE, IT'S STLL FFFFFFFF

 

then please sheck if there really are 9V at XH3.

Unfortunately, some boxes differ from this.

</Zitat>

 

Bezieht sich zwar auf AMD aber dort heisst es auch, dass es auch Ausreißer gibt die sich ggf. anders

verhalten können. Höchstwahrscheinlich ist deine Ursache aber das der Schreibschutz nicht aufgehoben wurde.

 

<Zitat>

Note:

 

Nokia2xI are special: most of these boxes have no working write protection due to bad manufaction.

Just try not to disable the write protection, if you want to know if you have such a box.

</Zitat>

Link zu diesem Kommentar
Auf anderen Seiten teilen

hey smith

danke für den link, aber auch das habe ich in etwa getan:

siehe im wiki die MHC-methode (sowohl MHC für nokia BL1.0 als auch MHC für alle).

PIN12 wird auch als Flash Reset beschrieben.

 

auch hier endet das log wie folgt:

dbox2-ppcboot> prot off 1:0

Un-Protect Flash Sectors 0-0 in Bank # 1

.dbox2-ppcboot> cp 01000000 10000000 1000

Copy to Flash... Timeout writing to Flash

 

sowohl mit verbundenen RH4 und XH6 als auch kurzen masse-impuls an PIN12

 

so langsam habe ich das gefühl, daß die kiste wirklich ein briefbeschwerer ist,

aber der BL scheint in ordnung zu sein von daher gebe ich nur ungerne auf.

diese bastelei an den alten kisten ist und bleibt das, was am meisten spass macht...

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hi, hast du Reset im Display stehen ?

 

Startet nun den Bootmanager und dann die Dbox.

Die Box lädt nun die ppcboot und macht, nachdem diese nicht signiert ist, einen Reset.

 

Wenn Reset im LCD steht, drückt ihr die Pfeil-nach-oben Taste, bis die Zahlenfolge im LCD erscheint.

Verbindet jetzt die Punkte für den
, bis die 5 Balken in der Zahlenfolge erscheinen.

Danach könnt ihr die Kontakte wieder lösen.

 

 

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hi, hast du Reset im Display stehen ?

 

 

[/indent]

 

yes, hat er ;)

nach dem reset, kurz PIN12 an masse und nach ein paar sekunden erhalte ich antwort auf "icache" im terminal.

dann gehe ich nach MHC-anleitung weiter (siehe log weiter oben) aber ohne das gewünschte resultat.

Link zu diesem Kommentar
Auf anderen Seiten teilen

 

auch hier endet das log wie folgt:

dbox2-ppcboot> prot off 1:0

Un-Protect Flash Sectors 0-0 in Bank # 1

.dbox2-ppcboot> cp 01000000 10000000 1000

Copy to Flash... Timeout writing to Flash

 

sowohl mit verbundenen RH4 und XH6 als auch kurzen masse-impuls an PIN12

 

so langsam habe ich das gefühl, daß die kiste wirklich ein briefbeschwerer ist,

aber der BL scheint in ordnung zu sein von daher gebe ich nur ungerne auf.

diese bastelei an den alten kisten ist und bleibt das, was am meisten spass macht...

 

Keine Ursache bin auch leidenschaftlicher Bastler.

 

Gehen wir die Sache noch mal von vorne an.

Du gehst sicher nach folgendem Schema vor.

 

1: Kabel an PIN 12 gelötet und das Ende liegt frei

2: BootManager V3.2.0.354 geladen

3: RARP On, Kurzschlusszeitpunkt anzeigen on,BootP/TFTP auf Minflsh\kernel\os, NFS auf Minflsh Verzeichnis und überall Haken davor

4. Com Port auf 57600, Netzwerkkarte richtig gewählt

6 Box ist mit Netzwerk und Com verbunden und vom Netz

7 Im Bootmanager auf Start drücken und Box ans Netz klemmen

8 Zum richigen Zeitpunkt Pin 12 Kabel ans gehäuse legen und dann isoliert wieder abnehmen

9 Obige Debuganzeige beobachten, ob Daten zur Box übertragen werden. Hier müssen einmal 436 und einmal 1153 Block gesente worden sein

10 Test in RSH mit Help.

11 Nun Execute enable_debug_mit minflsh ausführen

 

Im Com-Terminal sollte dann die Meldung: unprotecting :OK! flashing NOW :DONE ! erscheinen

 

Bei der PIn12 Methode dürfen natuerlich nicht die Jumper gesetzt sein.

 

Stimmt das bis hier mit deiner Methode überein oder gibts da Abweichungen?

Link zu diesem Kommentar
Auf anderen Seiten teilen

 

Keine Ursache bin auch leidenschaftlicher Bastler.

 

Gehen wir die Sache noch mal von vorne an.

Du gehst sicher nach folgendem Schema vor.

 

1: Kabel an PIN 12 gelötet und das Ende liegt frei - in etwa - lack auf dem lötauge entfernt und testnadel ins loch. ende des angelöteten kabels in der hand (wir sind zu zweit)

2: BootManager V3.2.0.354 geladen - yes

3: RARP On, Kurzschlusszeitpunkt anzeigen on,BootP/TFTP auf Minflsh\kernel\os, NFS auf Minflsh Verzeichnis und überall Haken davor - yes

4. Com Port auf 57600, Netzwerkkarte richtig gewählt - yes

6 Box ist mit Netzwerk und Com verbunden und vom Netz - yes

7 Im Bootmanager auf Start drücken und Box ans Netz klemmen - genau so

8 Zum richigen Zeitpunkt Pin 12 Kabel ans gehäuse legen und dann isoliert wieder abnehmen - jawolla

9 Obige Debuganzeige beobachten, ob Daten zur Box übertragen werden. Hier müssen einmal 436 und einmal 1153 Block gesente worden sein - es werden daten übertragen, kann aber im jetzigen moment weder sagen ob es zwei sind, noch ob die blockanzahl stimmt

10 Test in RSH mit Help. - und ob, mit antwort

11 Nun Execute enable_debug_mit minflsh ausführen - yep

 

Im Com-Terminal sollte dann die Meldung: unprotecting :OK! flashing NOW :DONE ! erscheinen -

 

 

 

Bei der PIn12 Methode dürfen natuerlich nicht die Jumper gesetzt sein - bei der pin12 methode von MHC sind auch andere dateien (ppcboot) im spiel und händische eingaben im terminal. aber auch die version mit script und PIN12 ist nicht von erfolg gekrönt.

 

Stimmt das bis hier mit deiner Methode überein oder gibts da Abweichungen?

 

 

ich muss eingestehen, daß ich mir nicht zu 100% sicher bin, daß ich die scriptmethode mit pin12 probiert habe.

heute komme ich auch nicht mehr dazu - vielleicht morgen.

ich meine aber, daß ich das auch schon aus "NOT" probiert habe, als ich im wiki las, daß der flash reset auch den schreibschutz aufhebt.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Wenn ich das richtig verstanden habe hast du es jetzt noch nicht mit der Pin 12 versucht?

 

Wenn dem so ist dann weist du zumindest bei dem RSH Help test ob es erfolgreich war.

 

Was mich bei der Sache allerdings wundert ist der Fehler: COULDN'T WRITE, IT'S STLL FFFFFFFF

Der darf eigentlich nur bei AMD Boxen vorkommen.

 

Wenn die Pin12 Methode nach o.g Schema auch nicht fruchten sollte könnte ich mir höchstens noch

vorstellen das deine Minflsh irgendwo buggy ist. Aber schaun wir erstmal ob es morgen nicht so schon klappt.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Archiviert

Dieses Thema ist jetzt archiviert und für weitere Antworten gesperrt.

  • Wer ist Online   0 Benutzer

    • Keine registrierten Benutzer online.
×
×
  • Neu erstellen...