brummer Geschrieben 28. März 2010 Melden Share Geschrieben 28. März 2010 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 More sharing options...
Don de Deckelwech Geschrieben 28. März 2010 Melden Share Geschrieben 28. März 2010 Hi, Kurzschluß klapt, pcboot wird übertragen Das ist aber nicht die richtige Reihenfolge... Lies nochmal genau nach: http://wiki.dbox2-tuning.net/wiki/index.php/MHC_2xIntel_bmon1.0 Ciao, DdD. Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
brummer Geschrieben 28. März 2010 Autor Melden Share Geschrieben 28. März 2010 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 More sharing options...
Trusty Geschrieben 28. März 2010 Melden Share Geschrieben 28. März 2010 Hast du die Verbindung für den Flashreset nach Punkt 3 auch wieder getrennt? Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
brummer Geschrieben 28. März 2010 Autor Melden Share Geschrieben 28. März 2010 ja hab ich sonst geht ja nichts ! Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Don de Deckelwech Geschrieben 28. März 2010 Melden Share Geschrieben 28. März 2010 Hi, ist das die richtige ppcboot? Die muss genau 211.472 Byte gross sein... Ciao, DdD. Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
brummer Geschrieben 28. März 2010 Autor Melden Share Geschrieben 28. März 2010 die größe ist 211.368 also offensichtlich eine andere. wo bekomme ich die "richtige" her? Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Don de Deckelwech Geschrieben 28. März 2010 Melden Share Geschrieben 28. März 2010 Hi, oben mein Link in der Anleitung... Ciao, DdD. Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
brummer Geschrieben 29. März 2010 Autor Melden Share Geschrieben 29. März 2010 danke für die Tips ! nun hat es gefunzt ! mfg Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
plaehboy Geschrieben 15. August 2011 Melden Share Geschrieben 15. August 2011 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 More sharing options...
Admin Gandalf Geschrieben 15. August 2011 Admin Melden Share Geschrieben 15. August 2011 Wenn die Meldung "Kein System" kommt dann ist kein Image oder ein defektes Image auf der Box, flash doch einfach mal ein neues Image drauf und wenn es dann noch immer Fehler gibt melde dich wieder. Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
plaehboy Geschrieben 15. August 2011 Melden Share Geschrieben 15. August 2011 hallo gandal da die probleme auftreten beim versetzen der box in den debug, klappt es mit dem neuen image noch nicht wirklich. die box lässt sich einfach nicht in den debug versetzen. gruß p. Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
zbxyz Geschrieben 15. August 2011 Melden Share Geschrieben 15. August 2011 Biete kostenlose Hilfe wenn Du vorbeikommst, PLZ-Bereich 44xxx. Bei Interesse PN. Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
plaehboy Geschrieben 15. August 2011 Melden Share Geschrieben 15. August 2011 danke für das angebot, pn ist raus. allerdings würde ich es gerne selbst hinbekommen und die community wird es danken, wenn hier lösungswege ausgezeigt werden. vielleicht hast du ja nen heissen tip für mich...? lg p. Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
zbxyz Geschrieben 15. August 2011 Melden Share Geschrieben 15. August 2011 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 More sharing options...
plaehboy Geschrieben 16. August 2011 Melden Share Geschrieben 16. August 2011 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 More sharing options...
smith007 Geschrieben 16. August 2011 Melden Share Geschrieben 16. August 2011 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 More sharing options...
plaehboy Geschrieben 16. August 2011 Melden Share Geschrieben 16. August 2011 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 More sharing options...
smith007 Geschrieben 16. August 2011 Melden Share Geschrieben 16. August 2011 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 More sharing options...
plaehboy Geschrieben 16. August 2011 Melden Share Geschrieben 16. August 2011 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 More sharing options...
sammy909 Geschrieben 16. August 2011 Melden Share Geschrieben 16. August 2011 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 Flashreset , 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 More sharing options...
plaehboy Geschrieben 16. August 2011 Melden Share Geschrieben 16. August 2011 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 More sharing options...
smith007 Geschrieben 16. August 2011 Melden Share Geschrieben 16. August 2011 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 More sharing options...
plaehboy Geschrieben 16. August 2011 Melden Share Geschrieben 16. August 2011 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 - NÖ 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 More sharing options...
smith007 Geschrieben 16. August 2011 Melden Share Geschrieben 16. August 2011 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 More sharing options...
Empfohlene Beiträge
Archiviert
Dieses Thema ist jetzt archiviert und für weitere Antworten gesperrt.