• Wiki-Page des Overclock Tools von tiagosousa alias mirage: hier
• Und hier gibts das OC-Tool als .apk zum Download: hier
• SPENDENLINK für Tiago alias miracle als Danke fürs Overclocking
• Zur Info: Alle einstellbaren CPU-Frequenzen im Überblick: hier

• Inzwischen sind alle wichtigen Mod-ROMs mit OC versehen. Die eigenen OC-Werte können meist in einer eigenen Datei (10_overclock.sh bspw.) angepasst werden. Siehe weiter unten.
• Wichtige Vertreter wären: Cronos, CyanogenMod, MIUI

• Hier sind inzwischen fast alle Open Recoveries geeignet. Bspw. Androidiani OR, GOT OR, oder FuFu's OR SE.
• Die Open Recovery nach den entsprechenden, oben verlinkten Anleitungen starten und per Optionen "Apply/Install Overclock" auswählen.

• Vorraussetzung: root (per obiger Open Recovery kein Problem)
• App "Milestone Overclock" im Market suchen, installieren und starten
• Per Settings gewünschte Werte für custom max_rate und custom max_vsel einstellen (siehe Tabelle weiter unten), zurück in den Anfangsschirm
• Schieberegler nach ganz rechts und auf "Apply"

                      [max_vsel]
[frequ.] [stable] [possibly unstable] [probably unstable]
            >=                                <=
   550      56 (original setup)      
   800      48          46 .. 44              42
   1000     60          58 .. 56              54
   1100     64          62 .. 60              58
*  1200     76          74 .. 70              68
*  1330                   84

*: Always unstable in some CPU's! Will damage CPU on prolonged use.
According to OMAP3430 datasheet, max_vsel up to 66 should be acceptable.
Above 80 will certainly severly damage the CPU on long-term scale.
The most appropriate and stable settings seem to be
either 800 MHz or 1000 MHz at max_vsel of 56 to 60.

• Vorraussetzung: root (klar), App "Root Explorer" oder Ähnliches
• Navigiert nach /system/bin
• Dort findet Ihr eines von folgenden Szenarien vor:
  • Verzeichnis "boot_script": Alle folgenden Änderungen beziehen sich auf die Datei /system/bin/boot_script/71_overclock.sh
  • Wenn Ihr es NICHT findet: Alle folgenden Änderungen beziehen sich auf die Datei /system/bin/mot_boot_mode *oder* (bei FuFus OR Script) mot_boot_mode.71.oc - je nachdem, welche Ihr findet.
  • Wenn Ihr dort keine korrekten Einträge findet (also keine, die wie unten aussehen): /system/etc/init.d/10overclock
  • (LETZTERES ist heute am Häufigsten anzutreffen)
• Öffnet die entsprechende Datei und durchsucht sie nach einem Eintrag der ungefähr so aussieht:
  
  Code:

  echo 56 > /proc/overclock/max_vsel
  echo 800000 > /proc/overclock/max_rate

• Nun könnt Ihr in obigen Beispiel die Werte für max_vsel und max_rate so einstellen, wie Ihr es (anhand von vorherigem Ausprobieren) für gut findet.
• Obiges Beispiel würde nach der Anpassung folgendermaßen aussehen:
  Code:

  echo 60 > /proc/overclock/max_vsel
  echo 1000000 > /proc/overclock/max_rate

HOW TO: VSEL FÜR ALLE FREQUENZEN

Seit overclock.ko Ver. 1.2 ist es möglich, für jede Frequenz im Stein eine eigene vsel zu definieren. Man kann dies ausnutzen, um den Prozessor bei jeder möglichen Frequenz möglichst effizient (in Bezug auf Spannung und Akkuverbrauch) fahren zu lassen.
Vorteile: Optimales Spannungslevel, Lebensdauer der CPU sicher erhöht, Akkuverbrauch etwas gesenkt ("Android OS" und "Android System" typ. unter 10%).
Nachteile: Eventuell instabileres System bei schlechten Werten für vsel.

Wie auch sonst gilt hier heute ebenfalls: In den meisten Mod-ROMs bereits enthalten. (Ein Luxus ist das heute... )

1. In einem Terminal (bspw. Better Terminal Emulator) folgende Befehle nacheinander ausführen. Die ersten beiden Befehle dienen dazu, den momentanen Stand abzufragen, denn: Man muss nur die Einträge in mpu_opps ändern, die auch in freq_table auftauchen. Dann die echos entsprechend anpassen (Syntax: echo "[Index] [Frequenz in Hz] [vsel]" > ...).

Mein Beispiel hier gilt für meine Einstellung, in der ich als max_vsel 58 und max_rate 1 GHz vorab gewählt habe. Über den letzten Befehl könnt Ihr nochmal prüfen, ob alles korrekt eingetragen wurde.

Code:

su
cat /proc/overclock/mpu_opps
cat /proc/overclock/freq_table
echo "1 125000000 18" > /proc/overclock/mpu_opps
echo "2 250000000 28" > /proc/overclock/mpu_opps
echo "3 500000000 36" > /proc/overclock/mpu_opps
cat /proc/overclock/mpu_opps

WICHTIG: Die Werte für vsel, die ihr oben seht, sollten funktionieren, müssen aber nicht!!! Das sind die Werte, die bei MEINEM Stein stolze 8 - 10 Punkte vom sofortigen Reboot entfernt sind und bei vielen Usern einwandfrei laufen. Also wahrscheinlich auf der sehr sicheren Seite. Falls bei Euch trotzdem etwas schief geht, setzt alle Werte um 2 rauf, bis alles rund läuft. Womit wir bei Punkt ...

2. ... wären. Testen. Testen, ausprobieren, rumspielen. Das Handy mal ein paar Stunden im StandBy liegen lassen. Bei vielen Usern reagiert der Stein vor Allem bei Nutzung der Kamera empfindlich (anscheinend wird sehr oft rauf/runtergerampt und daher ein perfekter Test für obige Einstellungen). Sollten keine spontanen Reboots auftauchen: Herzlichen Glückwunsch! Wenn Ihr lustig seid, könnt Ihr zum Test alle vsels um 2 Punkte runtersetzen. Falls doch: vsel für alle Raten um 2 Punkte raufsetzen.

3. NUR, WENN IHR !WOLLT! und Euch SEHR SICHER seid, dass Ihr stabile Werte gefunden habt, könnt Ihr die folgenden Zeilen am Ende der mot_boot_mode bzw. der 71_overclock.sh bzw. der 10overclock (ob die eine oder andere: Siehe oben unter "Overclock beim Boot") einsetzen bzw. modifizieren, damit die Spannungen beim Boot gleich eingepflegt werden (die ersten drei Zeilen dienen dem Laden der overclock.ko beim Booten und sind schon vorhanden):

Code:

insmod /data/data/pt.com.darksun.milestoneoverclock/files/overclock.ko
echo 60 > /proc/overclock/max_vsel
echo 1000000 > /proc/overclock/max_rate
echo "4 500000000 36" > /proc/overclock/mpu_opps
echo "3 250000000 28" > /proc/overclock/mpu_opps
echo "2 125000000 18" > /proc/overclock/mpu_opps
echo "1 500000" > proc/overclock/freq_table
echo "2 250000" > proc/overclock/freq_table
echo "3 125000" > proc/overclock/freq_table

Dabei wieder alle Werte für max_vsel, max_rate und die mpu_opps entsprechend Eures Steins anpassen.

Ein letzter Hinweis am Rande: Da der Stein hier *sehr* weit am unteren Limit gefahren wird (bei nur 85% - 90% der Originalspannung) kann es sein, dass der CPU mit dem Alter höhere Spannungen benötigen wird. Leider haben wir hierzu noch nicht allzu viel Langzeiterfahrung. Aber behaltet das bitte im Hinterkopf, wenn Euer Stein in einem halben Jahr oder später mal das Spinnen anfangen sollte.

Vergleich vsel Einstellungen original, Datenblatt OMAP3530 und Mod:

Code:

                            Werte für vsel
MHz   MS orig.   OMAP3530 Stand.   OMAP3530 Min.   Mod-Werte
125     32             31               27            18
250     39             37               33            28
500     50             48               44            36

PS: Es ist zwar schon länger nicht mehr vorgekommen, aber als Hinweis: Es gab mal einen Kamera-Freeze-Bug bei zu niedrigen vsels für 125 MHz. Sollte Euer Stein nach einem Schnappschuss und *anschließendem StandBy* einfrieren: Erhöht die vsel für 125 MHz um 4 - 8 und Ihr solltet Ruhe haben. Kommt heut aber nur noch sehr selten vor.

• Durch Übertakten wird der CPU evtl heißer, was aber NICHTS ausmacht. Der OMAP3430 ist bis auf 90°C spezifiziert! Da gibt der Akku sehr viel früher den Geist auf. Wichtiger sind Elektromigration (=Lebensdauer niedriger) und erhöhter Akkuverbrauch aufgrund größerer Versorgungsspannung.
• Der Temperatursensor im Stein überwacht den AKKU und NICHT den CPU. Der OMAP3430 hat zwar einen integrierten Temp.sensor, dieser wird im jetzigen Kernel aber nicht ausgelesen. Dazu wäre ein Custom Kernel nötig (welchen es für den Droid bereits gibt).
• Der OMAP ist *offiziell* bei Taktraten von 550 MHz und drüber auf eine Spannung von 1,35 V spezifiziert (also vsel = 60). Laut Datenblatt sind bei 1,35 V 720 MHz Taktrate möglich. Datenblatt OMAP3530 - der 3530 ist zum 3430 nahezu baugleich. Als maximale Spannung sind laut Datenblatt 1,425 Volt möglich (also vsel = 66). Siehe hierzu Tabellen 3-3 und 4-15. Über 1,42 Volt bzw. 720 MHz ist man nicht mehr in den Specs und beschädigt eventuell den OMAP. Bereits bei 720 MHz garantiert TI keinen fehlerfreien, aber einen schädigungsfreien Betrieb.
• Nochmal zum Thema Unterspannung (max_vsel gleich oder unter 55): Nach bisherigen Kenntnissstand können Unterspannungen den CPU nicht beschädigen. Das gilt aber nur dann, wenn eine Unterspannung NICHT völlig sinnfrei für eine viel zu hohe Frequenz gewählt wurde (bspw. max_vsel 20 bei max_rate 1330 - das wäre Schwachsinn). In einem solchen Fall können in sehr, sehr seltenen Fällen anscheinend Schäden am Flash Speicher entstehen.
• Bezüglich der Umrechnung von max_vsel in die tatsächliche Spannung: Tatsächliche Spannung = 0,6 Volt + (vsel * 0,0125 Volt)

• Zur Akku-Laufzeit siehe dieser Thread (Zusammenfassung: vsel wirkt sich linear aus, cpu_rate wirkt sich linear aus. Die kombinierte Erhöhung von vsel und cpu_rate, die ja beim OC Pflicht ist, wirkt sich in Summe also wieder quadratisch aus): Milestone Akku: Infos, Ladekurven, Leistungsverbraucher ...
• Die Erhöhung der Taktfrequenz *alleine* (ohne max_vsel zu verändern): Die Lebensdauer der CPU ist davon kaum beeinflusst (zumindest nicht so sehr, dass es einem innerhalb der typischen Handylebensdauer auffallen wird)! Es wird lediglich nicht garantiert, das fehlerfreie Berechnungen durchgeführt werden.
• Ganz anders die Erhöhung der Spannung (max_vsel): Hier schlägt sich der Wert DIREKT auf Lebensdauer der CPU nieder. Die Elektromigration (also das Ausdünnen der Leiterbahnen auf den Chips - umgangssparachlich "ausbrennen") schlägt ebenfalls voll zu.
• Laut Datenblatt sind Werte für max_vsel zwischen 56 und 66 noch voll in der Spec und werden daher weder die Laufzeit noch die Lebensdauer entscheidend beeinflussen. Ich persönlich würde sogar 110% der Nennspannung (max_vsel = 71) noch als sicher betrachten. Das Datenblatt von TI gibt als absolute Obergrenze 1,6 V an (max_vsel = 80). Aus dem Desktop-Bereich ist bekannt, dass eine Spannung über 125% der Nennspannung zu einem recht flotten Durchbrennen der CPU führen kann. In unserem Falle sind das max_vsel = 85 und höher. Diese Werte würde ich tunlichst vermeiden, eventuell halbiert (oder schlimmer) man damit die Lebensdauer des Steins.

• UserSpace: Hier kann man wahrscheinlich irgendwie einen eigenen Algorithmus einpflegen. Bisher gibt es aber keine Infos, wie das Ganze genau ausschauen soll. Daher einfach ignorieren.
• Performance: Der CPU läuft immer auf max. Frequenz. Sehr schlecht für die Laufzeit des Steins. Für Benchmarks allerdings super.
• Conservative: Das ist ein Governor, der nachträglich installiert werden muss (über das Modul conservative.ko), siehe diese Page. Wer nicht weiß, wie das geht, einfach die Finger davon lassen. Der Conservative Governor regelt die CPU-Frequenz durchgängig schrittweise. Und zwar so, dass die CPU-Last immer zwischen eine "Up Threshold" und "Down Threshold" liegt. D.h. ist die CPU-Last über "Up-Threshold" wird bspw. 125 -> 250 -> 500 -> 1000 gerampt und umgekehrt bei Unterschreitung von "Down Threhold" 1000 -> 500 -> ... das Ganze passiert minmal alle 125000 µs "Refresh Rate", also alle 125 ms. Im schlechtesten Fall heißt das, der CPU ist nach 375 ms auf maximaler Rate.
• Interactive: Ebenfalls ein Governor, der nachträglich installiert werden kann, siehe hier. Der Governor ist in so mancher OR bereits integriert. Der Interactive Governor funktioniert ähnlich wie OnDemand (siehe nächster Punkt), mit zwei kleinen, aber sehr feinen Unterschieden: Kommt der Stein aus dem Sleep-Modus wird der CPU "vorsichtshalber" erst einmal auf volle Bulle gefahren (ohne Überprüfung). Das ist sehr sinnvoll, da man ja typischerweise eine hohe Belastung dann zu tragen hat. Und zweitens: Statt die Belastung *nach* einer Zeitspanne zu messen (wie bei ondemand oder conservative) wird hier die sog. workqueue abgefragt - sprich, wieviel liegt *jetzt* gerade an Aufgaben an. Einziger Nachteil: Interactive "überschätzt" sehr gerne mal und saugt daher etwas mehr Akku als andere Governor.
• Smartass: Ein recht neuer Governor der prinzipiell ähnlich zum interactive läuft, allerdings bei bestimmten Vorgängen vorsichtshalber auf volle Bulle schaltet (daher auch das "smart"). Dazu gehören bspw. Display On oder auch offensichtliche Überlastungen der CPU. Genaue Infos gibts wie immer bei nadlabak, dem Gott der Governor. Ist momentan der beliebteste, weil ausgeglichenste Governor. Wer ihn sich mal ganz genau zu Gemüte führen will: Hier
• OnDemand: Der On-Demand Governor funktioniert etwas simpler wie der Conservative und ist bei Android Standard. Überschreitet die CPU-Last die "Up-Threshold" wird sofort auf maximale CPU-Frequenz geregelt (125 -> 1000). Anschließend wird die CPU-Frequenz schrittweise so zurück geregelt, dass die CPU-Last "Up Threshold" nicht überschreitet (1000 -> 500 -> 250 -> 125). Hier ist die minimale "Refresh Rate" 15625 µs, also etwa 16 ms. Es gibt noch die Parameter "PowerSave Bias" und "Nice load". Beide sind in Android recht unwichtig und können auf 0 gesetzt werden. Wer genaueres dazu erfahren will, kann sich diese beiden Links anschauen: Einmal Zweimal

• max_rate: 1,33 GHz
• max_vsel: 84
• SetCPU 250/1,33GHz (ondemant)
• Lief 4 Stunden stabil alledings hohe wärmeentwicklung beim Spielen (snes emulator)

• max_rate: 1,4 GHz
• max_vsel: 88
• SetCPU 250/1,4GHz (ondemant)
• Lief 30 Minuten stabil alledings sehr hohe wärmeentwicklung beim Spielen (snes emulator) und totaler absturz nach 20 Minuten ist wohl einfach zuviel

• max_rate: 1,2 GHz
• max_vsel: 80
• SetCPU 250/1,2GHz (ondemant)
• Lief 4 Stunden stabil wärmeentwicklung geht so beim Spielen (snes emulator)

• max_rate: 800 mHz
• max_vsel: 68
• SetCPU 125/800 mHz
• Hab das Gestern eingestellt und hatte seitdem einen FC. Muss aber nicht an der Taktung liegen.

• max_rate: 800 MHz
• max_vsel: 62
• SetCPU 250/800 MHz
• SetCPU sleep 125/125 MHz
• //Edit gelegentliche freezes

• max_rate: 800 MHz
• max_vsel: 62
• Overclock Widget 125/800 mHz
• Overclock Widget sleep 125/250 mHz
• keine Probleme

• max_rate: 800 MHz
• max_vsel: 62
• OverclockWidget 250/800 MHz
• Lief 1 Tag stabil

• max_rate: 1000 MHz
• max_vsel: 70
  
• OverclockWidget 250/1000 MHz
• Läuft seit 6h stabil

• max_rate: 1000MHz
• max_vsel:66
  
• SetCPU 250/1000MHz
• SetCPU sleep 125/125 MHz
• Noch keine FCs in den letzten 3h, Musik & zocken alles okay. Weiß nicht, ob manchmal kleine Ruckler durch die niedrige Spannung auftretetn. Ansonsten aber Fazit: Kein merklicher Unterschied zu 74

• max_rate: 1000 MHz
• max_vsel: 69
• OverclockWidget 250/1000 MHz
• Lief 1/2 Tag stabil
• Battery verbrauch ca. 10%

• max_rate: 1200 MHz
• max_vsel: 75
  
• OverclockWidget 250/1200 MHz
• Läuft seit 8 h stabil
• Battery verbrauch ca. 15% - 20%

• max_rate: 1000 MHz
• max_vsel: 72
  
• Lief 1/2 Tag stabil
• Battery verbrauch ca. 10%

• max_rate: 1000 MHz
• max_vsel: 69
  
• Läuft seit 1 h stabil