disable Debug w/o Schreibschutz aufheben?

[zexma]

Ich habe aus Interesse anhand der Anleitung http://www.noernet.de/dbox2/howto/debugdisableFAQ.txt
den Debug-Mode bei einer NokiaSAT/AVIA600/BMon1.2 disabled.
Dies ehat auch mit der einfachen Methode "setenv product? -1" problemlos funktioniert. Was ich allerdings bemerkenswert fand war die Tatsache, dass das "Debug-Disablen" OHNE(!) das Aufheben des Schreibschutzes funktionierte! Dabei habe ich den Vorgang zum Verifizieren 2x wiederholt.
Da derget bzw. McClean in der Anleitung ("Nun den schreibschutzt wie beim debug enablen disablen") dediziert darauf Hinweisen, frage ich mich:
Wie ist das möglich?

P.S.: Übrigens ist es ratsam VOR dem "Debug-Disable" die Original BN/BR Software wieder zu flashen (also KEIN Linux drauf lassen -> naja eigentlich logisch) , ansonsten endet das Ganze mit ner "Reset"-Schleife . Dieser Hinweis fehlt m.E. in der Anleitung.
Diese Erfahrung beantwortet aber so auch gleich die Frage, ob es möglich ist den Debug zu disablen und hierbei Linux auf der dBox weiter zu betreiben. Nämlich: NEIN (ich weiss: ist eigentlich auch logisch )

*Nachtrag:* Vergass ich zu erwähnen: Diese Nokia (AVIA600,BMon1.2) hat definitiv einen Schreibschutz. Diesen musste ich beim"Debug-Enable" mittels XH4&XH6 disablen.

[BOFH]

Die Nokias haben z.T keinen Schreibschutz.
Kann schon mal gefährlich werden. Aber wenn man's weis, kann man sich das öffnen der Kiste sparen.

[zexma]

Die Nokias haben z.T keinen Schreibschutz.
Kann schon mal gefährlich werden. Aber wenn man's weis, kann man sich das öffnen der Kiste sparen.

Vergass ich zu erwähnen: Diese Nokia (AVIA600,BMon1.2) hat definitiv einen Schreibschutz.

[BOFH]

Ups...
Dann warten wir mal auf SoLaLa. Der hat ein sehr gutes Verhältnis zum Flash

[SoLaLa]

hallöle...
und ich dachte schon ich wär der einzige, bei dem das so war .
war bei meiner einen nokia (die bei der ich das setenv mal probiert hab) auch so. debug mußte ich schreibschutz aufheben, setenv hat aber einfach so funktioniert.
kleine anomalien hatte ich danach beim erneuten debugenablen (das lag aber eher daran, daß ich die Linux auf der box draufgelassen hab, die war übrigens nach dem erneuten debugenablen hinüber, weil wohl das minflsh-os da noch n bissi drin rumwütet)
beim debugenablen hab ich das script erst ohne schreibschutz aufheben durchlaufen lassen (arun initactor... ist bei mir eh auskommentiert) da kam dann auch das 920092 und nach disblen an pin12 funktionierte das arun initactor anstandslos... DONE!
da werfen sich jetzt verschiedene überlegungen auf:
ab wann ist der schreibschutz überhaupt gesetzt??
warum wollte das minflsh-os so schlecht auf help antworten (im flash war ganz bestimmt nix BR-ähnliches drin )??
ich werd das ganze wohl nochmal probieren mit nem ganz leeren flash... oder ich laß da nur das ppcboot drin... müßte doch auch gehen

[MHC]

Hi,

war bei meiner einen nokia (die bei der ich das setenv mal probiert hab) auch so. debug mußte ich schreibschutz aufheben, setenv hat aber einfach so funktioniert.

... das bestätigt nun wieder meine damalige Vermutung, dass bei den Intel-Flashes sich der Bootloader selbst schützen muss (per lockdown-Befehl) ...

bei den 1xIntel bleiben die LOCK-Bits gesetzt, deshalb geht da die 'RESET' Methode nicht
(beim Flash-Reset der 'Lock-down' State zurückgesetzt wird)

... bei den 'ungeschützten' Nokias liegt es daran, dass der Bootloader den Flash nicht erkennen kann ...
mit PPCboot könnte der Flash geschützt werden,da fällt mir ein, dass ich das mal vor 1 1/2 Jahren machen wollte *duck* ...



bei AMD sieht es da auch ander aus

WP#/ACC input pin
— Write protect (WP#) function allows protection of two
outermost boot sectors, regardless of sector protect
status

Sector protection
— Hardware method of locking a sector, either
in-system or using programming equipment, to
prevent any program or erase operation within that
sector
— Temporary Sector Unprotect allows changing data in
protected sectors in-system

cu

[zexma]

hier stand Blödsinn...

[SoLaLa]

... das bestätigt nun wieder meine damalige Vermutung, dass bei den Intel-Flashes sich der Bootloader selbst schützen muss (per lockdown-Befehl) ...

hallo MHC, aber das ist ja gerade der punkt!!! wenn wir mit nem normalen prompt
dbox2:root>
mit setenv noch was ändern können, dann ist doch der bootloader schon ziemlich weit durchgelaufen, aber immer noch nix geschützt. und erst dann wenn ne ppcboot oder halt n BNos geladen wird, erst dann wird der Bootloader geschützt. wesentlich sinnvoller wäre es ja wenn der Bootloader sich schon in den ersten paar taktzyklen schützt (jedenfalls hätt ichs so programmiert wenn ich son bootloader schreiben sollte)

[MHC]

HI,

dann teste mal folgendes:

lade ppcboot und mach go 10000100
da wird der BR-Bootlader wieder gestartet, dann teste mal mit setenv, ob der Flash sich beschreiben lässt oder nicht ...
... der BR-Loader läuft sehr schnell durch, am besten 'down' Taste am Gerät gedrückt halten, damit 'Prompt' stehen bleibt


Bye

[micha_picha]

Hi,

also ich habe eine Reihe von Nokias und Philips mit "setenv product? -1" OHNE den Schreibschutz aufzuheben wieder in den Originalzustand versetzt - schlicht und ergreifend weil ich beim ersten mal die Zeile überlesen hatte (ja, ja, wer lesen kann ist klar im Vorteil) und danach immer auf die selbe Art und Weise vorgegangen bin.

Bye

[hubs125]

was ist denn nun mit den nokia boxen, die hardwareseitig keinen schreibschutz haben? Da war ja nie was protected. Wie soll das gehen, irgendwas zu protecten?

Gruß hub

[SoLaLa]

das ginge schon, wäre kein großes problem...
da müßte sich nur jemand finden der den lockdown-befehl ins ppcboot mit einbaut