Nokia 2xI geht nich in debug. Im display steht nu Reset...

[hase]

Hi
Ich hab versucht meine Nokia Box in debug zu bekommen. Hab auch schon eine box mehr bearbeitet. Bei dieser klappt alles, nur das halt zum schluß im com terminal nicht "Currrent state" locked oder so steht sondern ein Paar Zahlen und It's strange.
Wenn man die Box wieder hochfährt bleibt die box in so eine art schleife hängen. Da steht dann nur Reset... und dann gehts wieder weg und so weiter.

Was hab ich falsch gemacht?

Danke im Voraus

[Gorcon]

Hi
ließ mal dies hier scheint so als ob die Box schon mal im Debug war und falsch wieder Disabled wurde.
Gruß Gorcon

[hase]

Das ist die Box von einem Bekannten. Sie war noch nie im Debug Modus.
Wenn es aber so wäre, gibt es denn die Möglichkeit, das wieder rückgängig zu machen?

Wo und wann muß ich eigentlich den Befehl "setenv product? -1" eingeben?

Vielen Dank

[zexma]

Das ist die Box von einem Bekannten. Sie war noch nie im Debug Modus.
Wenn es aber so wäre, gibt es denn die Möglichkeit, das wieder rückgängig zu machen?
Wo und wann muß ich eigentlich den Befehl "setenv product? -1" eingeben?
Vielen Dank

Hier stehts doch genau beschrieben:
http://www.noernet.de/dbox2/howto/debugdisableFAQ.txt
"Serielles Nullmodemkabel an die Box anschliessen und Terminal auf 9600,n,8,1 einstellen.
Beim booten der box einfach den BR-Bootloader mit "Enter" unterbrechen. (SOFORT BEIM EINSCHALTEN DRUECKEN)
Es erscheint ein Prompt."

[SoLaLa]

hi zexma und die anderen
ihr redet hier n bissi aneinander vorbei
-hase hat da ne box bei der die tuner.so meldet "thats strange", diese box ist somit NICHT im debugmodus und ist auch mit herkömmlichen mitteln nicht dahinzubewegen.
-Gorcon liegt wohl richtig mit seiner vermutung daß die box mal im debug war und der falsch disablet wurde, und deshalb schlägt jetzt das enablen fehl.
-das mit dem debugdisablen anhand des setenv befehls funktioniert aber nur wenn man dem bootloader über die serielle befehle erteilen kann: was braucht man dafür? genau, ne box die sich im debugmodus befindet.
-insofern ist zexmas hinweis auf das debugdisablefaq natürlich unsinnig, weil die box erstmal wieder in den debugmodus muß um dem faq entsprechend verfahren zu können, aber wer will das dann noch?

und @hase:
falsch gemacht hast du garnix, im gegenteil, es dürfte alles richtig gelaufen sein, nur daß halt die tuner.so den schreibvorgang auf den bootloader nicht ausführt weil in der product variablen offenbar was undefinierbares drinsteht. deshalb wird das debugenablen abgebrochen

[zexma]

Mhhh, okay das seh e ich ein. Da hab ich wohl nicht aufmerksam genug gelesen. Hört sich plausibel an. Aber damit ist ihm (=hase) natürlich auch nicht geholfen. Die Frage ist natürlich wie bekommt man denn so eine verhunzte Box nun doch noch in den debug?

[SoLaLa]

es geht
--->pn

[Gorcon]

Na das wüsste ich aber auch gern. Man weis ja nie.
Gruß Gorcon

[Ozymandias]

Es soll da so eine tuner.so geben, die den gespeicherten Wert vor dem ändern nicht prüft. Die Prüfung geschieht ja nur aus Sicherheitsgründen. Nicht auszudenken, wenn ausversehen eine falsche Stelle im Speicher geändert würde.

[zexma]

es geht
--->pn

Hi SoLaLa:
Nochmals danke für Deine PN. Ich denke wir sollten Deine Erkenntnisse auch hier ins Forum posten/pasten, oder nicht? Könnte doch auch Anderen helfen

[SoLaLa]

hi gorcon und zexma,
naja, die "erkenntnisse" sind eigentlich keine, sondern nur das bissi was derget hier mal gepostet hatte und mir auf nachfrage (bin ja neugierig ) netterweise auch erklärt hat:
diese nichts-überprüfende tuner.so gibts natürlich, aber sie ist nirgends offen verlinkt, weil die benutzung auch recht gefährlich ist, denn wenn
beispielsweise nur n kleines kurzschlüßchen zwischen den flashpins sone "thats strange" meldung erzeugt, und man dann mit dieser nichtsüberprüfenden tuner.so den bootloader neu schreibt, dann ist danach mit 1000%iger sicherheit nur noch müll im bootloader (weil ja aufgrund des hardwarefehlers kein einziges byte korrekt geschrieben wird). hier muß ich zum verständnis gleich nochmal dazusagen: beim debugenablen wird zwar nur die productvariable geändert, aber es werden die KOMPLETTEN ersten 4 sektoren des bootloaders gelöscht und dann neu geschrieben.
vor der benutzung muß daher erstmal exakt abgeklärt werden ob die fehlermeldung nicht ne andere ursache haben könnte.
anders siehts aus, wenn jemand den debug falsch disablet hat (statt minus 1 zum beispiel 1 eingegeben, oder true) da ist dann völlig klar woher die meldung kommt, nämlich daher daß in der product variablen was anderes
als FFFFFFFF drinsteht --->"thats strange"

[MHC]

Hi,

-das mit dem debugdisablen anhand des setenv befehls funktioniert aber nur wenn man dem bootloader über die serielle befehle erteilen kann: was braucht man dafür? genau, ne box die sich im debugmodus befindet.

bist du dir da sooo sicher ?
man kann (ab BL1.2) mit nur Nullmodemkabel den Debug enablen (ganz ohne Netzwerk)

hier muß ich zum verständnis gleich nochmal dazusagen: beim debugenablen wird zwar nur die productvariable geändert, aber es werden die KOMPLETTEN ersten 4 sektoren des bootloaders gelöscht und dann neu geschrieben

falsch beim 'enablen' werden die Bits reduziert (von 0xff auf 0) und dazu
ist vorheriges löschen nicht nötig !!!

beim 'disablen' wird vorher gelöscht, aber nur der Sektor, wo die
jeweilige Variable drinsteht (zb bei 2xI Sektor 3: 0x8000-0xbfff)


bye

[SoLaLa]

hallöle MHC,
also das interessiert mich jetzt: wie machst du das ne box mit nem BMon1.2 nur mit nem nullmodemkabel in den debugmodus zu versetzen?
wir könnten tausende geschrotteter boxen retten wenn du uns das verrätst

was die 4 sektoren angeht, da bezieh ich mich auf ne aussage von derget bezüglich der tuner.so die da halt die ersten 4 sektoren schreibt... vielleicht hab ich das aber auch in den falschen hals bekommen. allerdings versteh ich dann nicht warum um den schreibschutz son großes gezeter gemacht wird, denn wenn nur die productvariable beschrieben wird, dann ist das mit dem sicheren kontakt zum schreibschutzdisablen völlig egal, totaler blödsinn, es könnte nix kaputtgeschrieben werden, man müßte einfach nur solange rumstochern bis es mal geklappt hat. wozu dann der ganze aufwand?

[MHC]

hi,

wir könnten tausende geschrotteter boxen retten wenn du uns das verrätst

der Bootloader muss 100% funktionieren sonst wird das auch nichts ...
... ich beschreibs ma ganz kurz, ist eh nix für Otto-Normal
Selftest auslösen,während Test läuft Flash 'verschwinden' lassen,
Loader bleibt stehen und über seriell sind blinde Eingaben möglich
(Answer gibst nur bei icache,dcache,seteth)
Flash wieder auftauchen lassen (je nach Typ noch Schreibschutz disablen)
setenv product? 0
kurz warten (da ja keine Meldung kommt) .... Reset und hoffen
wenn dann nicht, am besten sein lassen

denn wenn nur die productvariable beschrieben wird, dann ist das mit dem sicheren kontakt zum schreibschutzdisablen völlig egal, totaler blödsinn, es könnte nix kaputtgeschrieben werden, man müßte einfach nur solange rumstochern bis es mal geklappt hat. wozu dann der ganze aufwand?

aber wenn sich das Programm falsch entscheidet, da die Variable
je nach Boxtyp und BL-Version woanders liegt, kann diese 4 mal 00
fatale Folgen für den Loader haben und deshalb schreibt
das Programm nichts, wenn da andere Werte drinstehen
Gültige Werte:
bei 1xI 0xFFFFFFFF
bei anderen durch Interlace
0xFFFF 0xFFFF
0xFFFF 0x0000 oder
0x0000 0xFFFF

cu

[SoLaLa]

hallo MHC
woher weißt n du das alles?
weil: es geht, es geht sogar bestens
und was noch viel besser ist: beim disablen/wieder enablen mit minflash ist die sache ja um einiges schwieriger wenn n linuximage auf der box ist. und das ist nach wieder enablen des debug grundsätzlich sowieso hinüber weil das BNos ja versucht das angeblich kaputte filesystem wiederherzustellen.
mit deiner methode bleibt das linuximage vollkommen intakt... klar nach dem disablen ist kein system da, aber nach wieder enablen ist alles wieder so wie es vorher war.

daß der bootloader für den vorgang 100% ok sein muß seh ich allerdings nicht so, denn ich hab das hier mal auf meiner spielbox probiert mit nem BMon1.2 ohne korrekte checksumme (die letzten 4 byte) und das funktioniert dropsdem .
wo wir gerade dabei sind: weißt du ob die letzten 4byte tatsächlich ne funktion erfüllen, soll heißen werden die wirklich irgendwo überprüft?

[MHC]

Hi,

hallo MHC
woher weißt n du das alles?

wo wir gerade dabei sind: weißt du ob die letzten 4byte tatsächlich ne funktion erfüllen, soll heißen werden die wirklich irgendwo überprüft?

1. von niemand ... selbst draufgstossen

2. keine Ahnung
ich hatte hier zum Beispiel mal ne Nokia mit ungeschützten Flash und
BL1.0, die hab ich zu ner 1.2 umgebastelt und die 1.2 lief wunderbar
damit mir die Box dabei nicht flöten geht, hab ich sie so umgebaut,
dass ich A20 Leitung auftrennen und auf high legen konnte ...
so hab ich immer oberhalb probiert

... dass dies nicht immer gut geht iss auch klar, denn seit paar
Wochen ist der Flash komplett leer

da ich in diese Kiste aber kein Geld reinstecken will
werde ich selber versuchen sie zum laufen zu bringen und
zwar ohne auslöten der Flash ....
mein Gedanke ist ein Eprom dranzubammeln mit 8Bit Datenbus
denn 32Bit sind mir zu viel Leitungen
es blieben dann nur noch 30 Leitungen gesamt übrig zum einlöten
wenn ich mal wieder Zeit hab mache ich das, mal sehen ob klappt ...

cu

[SoLaLa]

hihi,
na dann bin ich ja froh daß ich meine spielbox hab (gesockelter tuner und gesockelte flashs)
ich hatte gerad in den letzten tagen mal sonen gedanken wie man das rumpfuschen im flash noch sicherer machen kann und hab mir überlegt ob ich in ner anderen box noch 2 flashs "huckepack" draufsetze und dann nur den CE# oder sowas per dipschalter zum selektieren nehme.
da wär dann immer n Backup in der box das sich problemlos booten oder wieder auf die anderen flashs kopieren ließe wenn die denn mal garnicht mehr wollen oder eben irgendwie auf einmal plötzlich und unerwartet leer sind

[doc]

Is schon eigenartig!

hab mir überlegt ob ich in ner anderen box noch 2 flashs "huckepack" draufsetze und dann nur den CE# oder sowas per dipschalter zum selektieren nehme.

Genau diese Idee hatte ich dies Tage auch schon. man könnte so eigentlich, nachdem die Box gestartet hat, die internen Flashs absschaltem und dann die "Huckepack" Flashs zum Beispiel mit dem PPCBOOT einen BL versehen. Ohne das man einen tueren Flasher benötigt. Also rein theoretisch mal angenommen!!

[rmaerte1]

es geht
--->pn

Ich ahne, was es ist ;o)

[SoLaLa]

hi doc,
so etwa denk ichs mir ja auch, aber nicht des flashens wegen, das ist mit der oben beschriebenen spielbox kein problem, die starte ich einfach mit nem ordentlichen flash und dem darin befindlichen ppcboot. und wenn ich dann nen promt hab arbeitet die box eh im ram, da kann ich dann ruhigen gemüts die flashs aus den sockeln nehmen und andere reinsetzen und neu flashen, das geht.
die huckepacklösung kam mir in den kopp wegen der "pfuscherei" im bootloader
da wäre son backup-flash zum booten eines gecrashten systems doch wirklich was feines
Du hast da doch gerade noch diese verglühte box in arbeit wo du nen abgesetzten flash einbaust, sone lösung wäre auch denkbar, die TSOPadapterplatinen haben ja n 2,54Rastermaß, da könntest ohne weiteres 2 bzw 4 platinen mit stiftleisten stapeln und dann das CE# über nen megasimplen kippschalter führen.

[doc]

Danke SoLaLa, habe mit so einem Gedanken gespielt!!
Nur sind diese Flashadapter wirklich nicht billig, ööhhh
Emulation baut bzw. vertreibt die Dinger. In Deutschland bei http://www.synatron.de zu beziehen. Aber wie gesagt ist nicht billig. Die gesamte Auswahl entsprechender TSOP Flashadapter bei EMULATION TECHNOLOGY. Ausehen tut das Dingen so

Infos habe ich bei Synatronauf jeden Fall mal angefordert.

Wenn du Interesse hast dann kann man das ja mal näher verfolgen!

[Liontamer]

@SoLaLa
Gibt es mittlerweile schon neue Erkenntnisse, ob das "huckepack" auflöten eines 2. Flash es funktioniert? Ich hab sa so kleine Zweifel, daß das Umschalten Problemlos geht.

*mehrinfosbrauch*