[Diskussion] CyanogenMod 7 mit 2ndboot für das Milestone (CM7)

  • 688 Antworten
  • Letztes Antwortdatum
hellfire schrieb:
Das heißt in diesem Fall wäre das auch der Index 4, richtig?

Genauso ist es! Du kannst also das Kommando aus meinem letzten Posting unverändert übernehmen. vsel=56 sollte auch hoch genug sein, aber nicht zu hoch. Du kannst aber auch deinen bereits erprobten vsel-Wert für die Frequenz 800 MHz nehmen.

hellfire schrieb:
Also du meinst ich sollte mal ein "wipe system" durchführen? Und danach dann noch mal CM7 flashen und die gapps? Bleiben die Einstellungen von CM7 dann erhalten?

Ja, die liegen nicht in der System-Partition. Wenn du keine custom_backup_list hast, kann "wipe system" nichts anrichten. Danach einfach CM7 flashen und das gapps-Paket. Ich benutze immer das gapps-gb-20111216-signed.zip mit 9.096.912 Bytes. Trotzdem empfehle ich - natürlich - vorher mal schnell ein nandroid zu machen! Sollte man immer tun, wenn man irgendwas neu aufsetzt.

hellfire schrieb:
edit: Okay, ich hatte letztens die Google Tastatur von Android 4 mit Swype-Funktion über Apply Update in der OR installiert, die bei mir aber nicht funktioniert hat (Ich denke man braucht Android 4 dafür). Habe die .apk jetzt mal gelöscht, die war immerhin 10MB groß.

Aua haua! Das wird sicher der Übeltäter gewesen sein :). Ein paar Bytes freier Platz in der System-Partition schaden nicht. Denn manch einer möchte da schon noch hin und wieder ein paar schnöde Bytes an Daten ablegen. Wenns nicht geht, kann es sogar zu unerklärlichen Problemen kommen.
 
Zuletzt bearbeitet:
Bei einem nandroid wird die ext-Partition auch mitgesichert oder? Ich lass den Akku erst mal leer laufen um die Daten von setCPU und BatteryMix zu analysieren, aber dann teste ich das mal mit den 650Mhz!

Die gleichen gapps nehme ich auch immer, bis auf den Unterschied das ich diese Apps hier immer lösche:

CarHomeGoogle.apk
CarHomeLauncher.apk
FOTAKill.apk
Talk.apk

:)
 
hellfire schrieb:
Bei einem nandroid wird die ext-Partition auch mitgesichert oder?

Wenn du ein volles nandroid machst, ja. Das ist eine 1:1 Kopie deines gesamten Systems. Nur die FAT32-Partition der SD-Karte wird natürlich nicht gesichert.

hellfire schrieb:
Ich lass den Akku erst mal leer laufen um die Daten von setCPU und BatteryMix zu analysieren, aber dann teste ich das mal mit den 650Mhz!

Ich bin gespannt auf das Ergebnis! Übrigens schicken 805 MHz mein Gerät noch zuverlässiger ins Nirvana, als 650 MHz. :D
 
Zuletzt bearbeitet:
Wollte das mit dem "wipe system" jetzt mal ausprobieren, allerdings bekomme ich die Meldung "command not found" wenn ich "wipe system" eingebe. Wie genau lautet denn der Befehl?

edit: So, ich habe jetzt mal den Befehl
echo "4 650000000 56" > /proc/overclock/mpu_opps
ausgeführt, wollte dann zum Soldid Explorer wechseln und der ist dann abgestürzt. Kurze Zeit später bekam ich die Modem-Absturz Meldung. Ich kann also bestätigen dass die 650MHz Frequenz Fehler verursacht!

Das bestätigt also deine Theorie der "forbidden frequencies".
 
Zuletzt bearbeitet:
  • Danke
Reaktionen: fipsy
@fipsy
Ich glaube, so bald du Battery Mix installiert hast, fliegt in der internen Akkuverbrauchsanalyse das AndroidOS raus, ist bei mir auch nicht zu sehen. Kann das sein?

Gesendet von meinem Milestone mit der Android-Hilfe.de App
 
Nein, ich habe ja auch BatteryMix installiert und AndroidOS wird bei mir angezeigt. ;)
 
hellfire schrieb:
Wollte das mit dem "wipe system" jetzt mal ausprobieren, allerdings bekomme ich die Meldung "command not found" wenn ich "wipe system" eingebe. Wie genau lautet denn der Befehl?

Du hast das schon richtig gemacht (siehe Screenshot unten). Es wundert mich aber, dass wipe bei dir nicht vorhanden ist. Was ist denn, wenn du in der Konsole nur "wipe" eingibst?

hellfire schrieb:
Das bestätigt also deine Theorie der "forbidden frequencies".

SUPER! Ganz herzlichen Dank! Da bin ich aber froh, dass ich nicht falsch gelegen habe. Da haben wir ja doch eine recht wichtige Sache herausbekommen. Vor allem wissen wir jetzt, woher die Modemfehler kommen, von denen viele ja immer wieder berichten. Auch nadlabak war im Hinblick auf den Modemfehler ja schon erfolglos investigativ tätig. Interessant ist auch, dass manche Frequenzen totsicher und schnell zu einem Fehler führen, während andere (z.B. 150 MHz) nur zu "leichten Störungen" führen, wie z.B. dem "frequency stuck" Problem.
 

Anhänge

  • screenshot-20130321-214733.png
    screenshot-20130321-214733.png
    2,2 KB · Aufrufe: 168
Zuletzt bearbeitet:
paysano schrieb:
Ich glaube, so bald du Battery Mix installiert hast, fliegt in der internen Akkuverbrauchsanalyse das AndroidOS raus, ist bei mir auch nicht zu sehen. Kann das sein?

Hehe! Diese Vermutung hatte ich auch schon, habe mich nur nicht getraut, sie öffentlich zu äußern, weil sie mir etwas "abstrus" vorkam. ;) Scheint ja auch nicht so zu sein, wenn ich hellfires Beitrag lese. Trotzdem schon sehr merkwürdig, dass bei den einen das Android OS angezeigt wird und bei anderen nicht. :confused2:
 
Also ich hab in der OR in die Console "wipe system" eingetippt. Muss das irgendwie "wipe /system" oder so heißen? Oder muss ich das über das Android Terminal machen?
 
hellfire schrieb:
Also ich hab in der OR in die Console "wipe system" eingetippt. Muss das irgendwie "wipe /system" oder so heißen? Oder muss ich das über das Android Terminal machen?

OOOOH! Sorry, ich hatte gar nicht dran gedacht, dass in der OR-Console gar kein Path gesetzt ist und wipe in /system/bin liegt. Also du musst eingeben:

/system/bin/wipe system

Sorry!
 
Kein Problem. ;) Also der Befehl wipe befindet sich in /system/bin? Habe ich das so richtig verstanden?
 
hellfire schrieb:
Also der Befehl wipe befindet sich in /system/bin? Habe ich das so richtig verstanden?

Ja, genau. Kannst natürlich auch erst nach /system/bin wechseln und dort dann nur wipe eingeben.
 
Ok danke für die Erklärung. ;)

edit: Hatte den Befehl gestern Abend noch ausgeführt, allerdings habe ich da errors bekommen, von wegen "system/etc is not empty". Naja hab dann nochmal CM7 und die gapps installiert und das hat bei mir schlussendlich nochmal 2MB unter /system gebracht. :) Haben oder nicht haben sag ich mal. :D
 
Zuletzt bearbeitet:
hellfire schrieb:
Hatte den Befehl gestern Abend noch ausgeführt, allerdings habe ich da errors bekommen, von wegen "system/etc is not empty".

Hat wipe selbst diesen Fehler gemeldet?

Das wäre sehr seltsam! Bei mir hat das einwandfrei funktioniert. Habe es allerdings auch erst einmal gemacht. Ein wipe mit Superuser-Rechten sollte eigentlich keine Fragen offen lassen und einfach die Datei-Zuordnungstabelle komplett löschen. Es könnte allerdings sein, dass es Probleme gibt, wenn du wipe im Verzeichnis /system/bin ausführst, weil das Verzeichnis dann offen ist. Ich würde es deshalb immer von der Root / Stammverzeichnis (/) ausführen.

hellfire schrieb:
:) Haben oder nicht haben sag ich mal. :D

Wenn du die gapps installierst, ohne vorher in dem Paket was rauszulöschen, sollten noch ca. 2,6 MB auf /system frei sein.
 
Zuletzt bearbeitet:
Wie gesagt, ich habe ja sowohl im CM7 Paket als auch in den gapps mehrere Apps gelöscht. Habe unter /system jetzt 163,2/175,6 belegt.

Wer den Fehler da jetzt gemeldet hat weiß ich nicht mehr genau, denke aber dass es wipe war. Hattest du den /system Ordner dann auch in der OR gelöscht? Im laufenden System geht es ja nicht denke ich.

edit: Ich wollte jetzt mal ein paar andere Taktraten mit entsprechenden vsel Werten ausprobieren. Wenn jetzt eine vsel Spannung zu niedrig gewählt ist, und es dauernd zu Restarts kommen würde, kommt man mit den OC Werten dann eigentlich noch in die OR? Oder werden da stabile Werte benutzt?
 
Zuletzt bearbeitet:
hellfire schrieb:
Wie gesagt, ich habe ja sowohl im CM7 Paket als auch in den gapps mehrere Apps gelöscht. Habe unter /system jetzt 163,2/175,6 belegt.

Okay, aber normalerweise braucht man nicht viel freien Speicherplatz auf der Systempartition. So 1-2 MB reichen aus.

hellfire schrieb:
Hattest du den /system Ordner dann auch in der OR gelöscht? Im laufenden System geht es ja nicht denke ich.

Nee, da geht das nicht :). Das musst du schon von der OR aus machen.

hellfire schrieb:
Ich wollte jetzt mal ein paar andere Taktraten mit entsprechenden vsel Werten ausprobieren. Wenn jetzt eine vsel Spannung zu niedrig gewählt ist, und es dauernd zu Restarts kommen würde, kommt man mit den OC Werten dann eigentlich noch in die OR? Oder werden da stabile Werte benutzt?

Ja, die OR lässt das Handy m.W. auf 550 MHz mit den Standardwerten laufen. Diese werden ja ohnehin immer beim Booten benutzt, bis die Init-Scripts in init.d (10overclock) ausgeführt wurden. Erst dann gehts mit anderen Frequenzen und vsels weiter.

Die vsel-Werte verhalten sich ziemlich linear zur Frequenz. Wenn du dich mit Excel ein bisschen auskennst, suchst du dir einen stabilen vsel-Wert für eine niedrige Frequenz (z.B. 250 MHz) und einen für eine hohe Frequenz (800 MHz), trägst diese in die Excel-Tabelle ein und lässt ein Diagramm mit linearer Interpolation zeichnen. Die vsel-Werte für beliebige, andere Frequenzen kannst du dann im Diagramm ablesen. Übrigens haben meine Tests ergeben, dass ungerade vsel-Werte einfach ignoriert und auf den nächsten geraden Wert erniedrigt werden. Deshalb sollte man nur gerade vsel-Werte verwenden (also z.B. 32, 46, 54 etc.).
 
Zuletzt bearbeitet:
Okay, aber normalerweise braucht man nicht viel freien Speicherplatz auf der Systempartition. So 1-2 MB reichen aus.
Ja stimmt. Obwohl letztens hatte ich ja auch diese Tastatur App die man nur über "Apply Update" installieren konnte, und die war immerhin 10MB groß. Und ich mein so Apps wie den Filemanager braucht man ja nicht, wenn man zum Beispiel den Solid Explorer hat.

Ja, die OR lässt das Handy m.W. auf 550 MHz mit den Standardwerten laufen.
Gut, so etwas ähnliches habe ich schon vermutet. :)

Wenn du dich mit Excel ein bisschen auskennst, suchst du dir einen stabilen vsel-Wert für eine niedrige Frequenz (z.B. 250 MHz) und eine für eine hohe Frequenz (800 MHz)
Genau so wollte ich es auch machen. :)

edit: Nochmal zurück zu dem SManager, welche Rechte braucht das Script? Ich würde sagen Root, für den Zugriff auf /system und Boot, damit das Log nach dem Booten auf die SD-Karte geschrieben wird. Richtig so?

Hat es einen tieferen Sinn, dass die reboot.log Datei unsichtbar auf die SD-Karte geschrieben wird? (.reboot.log)
 
Zuletzt bearbeitet:
hellfire schrieb:
Nochmal zurück zu dem SManager, welche Rechte braucht das Script? Ich würde sagen Root, für den Zugriff auf /system und Boot, damit das Log nach dem Booten auf die SD-Karte geschrieben wird. Richtig so?

Jein, das Script muss nur ausführbar sein. Wenn du es auf die SD-Karte kopierst, ist es das automatisch. Im SManager musst du für das Script nur "Boot" setzen. Superuser-Rechte (su) braucht es nicht. Du willst doch nur einen Timestamp in die Logdatei auf der SD-Karte schreiben. Dazu brauchst du keine Superuser-Rechte. Aber vielleicht hast du in dem Script noch mehr vor? Ich weiß es nicht, weil du sagst, du willst auf /system zugreifen?!

hellfire schrieb:
Hat es einen tieferen Sinn, dass die reboot.log Datei unsichtbar auf die SD-Karte geschrieben wird? (.reboot.log)

Nö, hat es nicht. Du kannst den Punkt am Anfang auch weglassen, wenn du die Datei gern sehen möchtest. :)
 
Zuletzt bearbeitet:
Was bewirkt denn diese Zeile genau?
Ja ich habe den Punkt weggelassen. :)

Ich kenne mich leider mit den Linux-Befehlen etc. gar nicht aus wie man sieht. ;)
 
hellfire schrieb:
Was bewirkt denn diese Zeile genau?

Die teilt dem Script-Handler mit, welche Shell zur Ausführung dieses Scripts benutzt werden soll. Da es verschiedene Shells gibt, die eine unterschiedliche Syntax haben, muss man das vorher mitteilen.
 

Ähnliche Themen

-FuFu-
Antworten
60
Aufrufe
18.197
paysano
paysano
Darks
Antworten
10
Aufrufe
2.733
Darks
Darks
-FuFu-
Antworten
3
Aufrufe
11.957
Varroc
Varroc
Zurück
Oben Unten