Android Kernel: Prime linee guida [overclock]

Salve cari lettori,

colgo l'occasione per salutarvi tutti e con tanto affetto mi presento: sono Diego Stamigni (aka Lord Osiris), nuovo acquisto di casa AndroidWorld e, bando alle ciance, come primo articolo ho deciso di deliziarvi con delle piccole chicche.

Non voglio parlarvi di me, ma posso accennarvi che quello che leggerete sarà prettamente il mio campo qui; ma ora basta, via.

Qualcuno di voi forse ha provato nella sua vita, o magari già lo fa abitualmente, a sfruttare l'OpenSource, mettendo mani nei sorgenti e smanettando a destra e a manca, magari rompendo tutto.

Ah, senza che andiate via a fare altro, stiamo per portare il Nexus One a oltre 2ghz; non credo ci sia mai arrivato nessuno realmente, e di fatto, nessuno ha mai spiegato come fare.

Well, oggi sfrutteremo l'opportunità che ci ha dato mamma Google di frugare nei sorgenti del kernel di Android e in particolare di ricompilare il kernel e overclockarlo; per tanto, baserò la mia guida sul mio Nexus One.

. Happy hacking.

Proprio ieri di prima mattina, appena svegliato, ho deciso di scriverMI (sisi, **era** per me xD) un tool che mi facilitasse la compilazione del kernel, senza perdere troppo tempo in checkin, checkout, push e pull. Quel tool lo trovate qui: scaricatelo e mettetelo da parte, ci servirà. Piccola parentesi, è scritto per funzionare su linux/mac ed in continuo aggiornamento e miglioramento; cercherò di renderlo completamente funzionante per ogni terminale, ma per adesso ne garantisco il funzionamento solo per Nexus One.

I requisiti veramente importanti sono l'essere in possesso dei Sorgenti Android compilati e l'SDK configurato correttamente e funzionante. Inoltre, se volete testare il kernel generato nel vostro smartphone, dovete avere un Nexus One rootato.

Il kernel di Android è un Linux patchato per avere supporto completo ad architettura ARM, ma sopratutto, corredato di moduli più o meno implementabili, per supportare l' hardware più svariato.

In molti di voi magari utilizzano Mod particolari, magari avete cambiato kernel, installando ad esempio uno fra tanti, il pershoot, che vi avrà colpito grazie alla possibilità di incrementare la frequenza del processore fino a 1.1ghz da 0.99ghz di default.

Com'è possibile ciò ? Come possiamo overclockare a modo nostro ?

Bhè l'operazione in se non è molto complicata, ma rimane comunque molto pericoloso superare un certo range di overclock. Questo perchè anche se si può toccare delle frequenze elevatissime, non è detto che il processore sia in grado di sostenerle a lungo termine.

Ciò che faremo assieme oggi è aggiungere valori in grado di far salire la frequenza fino a 2.4ghz, ma questo non vuol dire che li useremo: potremmo starcene al sicuro sui 0.99ghz di casa, ma avremo imparato come farlo.

PREMESSA: non c'è bisogno di alcun Backup o affini, in quanto NON installeremo niente nel dispositivo ma testeremo il kernel in modalità boot-reboot, cioè avvieremo il cellulare con il nuovo kernel attraverso fastboot così che al successivo spegnimento e riaccensione (o riavvio) non ci sia traccia del kernel modificato, ma sia tutto tornato alla normalità: un piccolo brivido insomma (questo non vuol dire che non possiate successivamente flashare il file immagine creato con una qualsiasi recovery, tipo Amon RA).

Bene, scarichiamo lo script:

git clone git://github.com/diegostamigni/andkercomp.git

Bene, ora colleghiamo il nostro terminale alla porta USB ricordando di impostare la modalità Debug USB da Impostazioni -> Applicazioni -> Sviluppo.

Avviamo il nostro script:

cd andkercom && chmod +x andkercom.sh && ./andkercom.sh

Ci verrano poste delle domande abbastanza semplici, consiglio di premere Invio poichè di Default sono selezionate le impostazioni ottimali (verrà scaricato il kernel 2.6.34-test1).

Ci vorrà un po per scaricare i sorgenti che troveremo nella dir experimental/ creata, aspettiamo, magari addolcendo l'attesa assaporando qualche dolcetto ricevuto nella calza della befana.

Bene, posati i Kinder, veniamo a noi: ora non ci resta che proseguire; una volta scaricati i sorgenti, lo script provvederà a controllare che tutte le dipendenze siano corrette, inoltre provvederà a prelevare dal nostro cellulare una configurazione valida da assegnare alla compilazione del kernel (il famoso .config).

Faccio ciò, vi troverete a dover rispondere a un bel po di domande: per ora non ci interessa sapere cosa chiedono, l'importante è assegnare la risposta di default e premere Enter finchè non finiranno (dai siamo bravi almeno in questo! cit.

Bill Gates).

In realtà quelle domande sono dei diff tra la config che abbiamo prelevato dal nostro terminale e le novità nel kernel che stiamo per compilare: ci vengono proposte delle scelte per quanto riguarda l'abilitazione di novità rispetto alla versione installata, ma a noi interessa il Default almeno per ora.

Sperando che tutto vada per il meglio, mangiamo, e aspettiamo.

Fatto ciò arriveremo alla fatidica domanda:

Should I compile your kernel, Sir ? [y/n]:

Fermi, non fate niente, congeliamo per ora questa domanda: che hittiate Enter o "y" non ha importanza poichè parte ugualmente; per ora non dobbiamo fare niente del genere: ora dobbiamo modificare un file del sorgente per aggiungere alla tabella delle frequenze, l'overclock. Apriamo altrove con un file-editor (tipo gedit, o vim o quello che volete) il file in

experimental/arch/arm/mach-msm/acpuclock-scorpion.c

e raggiungiamo la riga 94, dovremmo vedere qualcosa del tipo

{ 998400, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x1A, 0, 1275 },

bene, 998400 è la frequenza massima di mamma Google, il resto sono opzioni di clock e core sources, 0x1A è l'indirizzamento mentre 1275 è l'amperaggio, siamo a 1275mA.

aggiungiamo questi valori, prima della chiusura della struct:

{ 1036800, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x1B, 0, 1275 },
{ 1075200, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x1C, 0, 1275 },
{ 1113600, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x1D, 0, 1275 },
{ 1228800, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x1E, 0, 1275 },
{ 1451520, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x1F, 0, 1275 },
{ 1639680, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x20, 0, 1275 },
{ 2019072, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x21, 0, 1275 },
{ 2401344, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x22, 0, 1275 },

così da avere la struttura in questo modo:

struct clkctl_acpu_speed acpu_freq_tbl[] = {
{ 19200, CCTL(CLK_TCXO, 1), SRC_RAW, 0, 0, 1050 },
{ 128000, CCTL(CLK_TCXO, 1), SRC_AXI, 0, 0, 1050 },
{ 245000, CCTL(CLK_MODEM_PLL, 1), SRC_RAW, 0, 0, 1050 },
{ 256000, CCTL(CLK_GLOBAL_PLL, 3), SRC_RAW, 0, 0, 1050 },
{ 384000, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x0A, 0, 1050 },
{ 422400, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x0B, 0, 1050 },
{ 460800, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x0C, 0, 1050 },
{ 499200, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x0D, 0, 1075 },
{ 537600, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x0E, 0, 1100 },
{ 576000, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x0F, 0, 1100 },
{ 614400, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x10, 0, 1125 },
{ 652800, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x11, 0, 1150 },
{ 691200, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x12, 0, 1175 },
{ 729600, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x13, 0, 1200 },
{ 768000, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x14, 0, 1200 },
{ 806400, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x15, 0, 1225 },
{ 844800, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x16, 0, 1250 },
{ 883200, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x17, 0, 1275 },
{ 921600, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x18, 0, 1275 },
{ 960000, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x19, 0, 1275 },
{ 998400, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x1A, 0, 1275 },
{ 1036800, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x1B, 0, 1275 },
{ 1075200, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x1C, 0, 1275 },
{ 1113600, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x1D, 0, 1275 },
{ 1228800, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x1E, 0, 1275 },
{ 1451520, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x1F, 0, 1275 },
{ 1639680, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x20, 0, 1275 },
{ 2019072, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x21, 0, 1275 },
{ 2401344, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x22, 0, 1275 },
{ 0 },
};

Ebbene sì, questo è quanto: si capisce come mai ci si sia stabiliti nel range che va da 0.99ghz a 1.1ghz. I kernel undervolted [UV] dovrebbero consumare poca batteria (che poi, mica tanto), ma quel piccolo overclock presente è come se non ci fosse; si dovrebbero aumentare i voltaggi, così da mettere a rischio la batteria, e la struttura hardware dell'intero terminale.

Bene, salviamo il file e chiudiamo, torniamo alla nostra domanda sulla compilazione, e diamo un bel Enter; possiamo riprendere le caramelle e le cioccolate.

Piccola particolarità da sottolineare: lo script, se abilitato (di default lo è), provvederà a modificare nel .config una variabile settandola alla frequenza voluta:

# da overclock
cp .config .config.old
cat .config.old | sed -e 's/998400/2401344/g' > .config

che opera quindi una semplice sostituzione alla riga

CONFIG_MSM_CPU_FREQ_MAX=998400

in

CONFIG_MSM_CPU_FREQ_MAX=2401344

se ci fate caso, è la stessa frequenza impostata nella struttura poc'anzi, difatti essa setta la massima frequenza disponibile e raggiungibile.

Proseguendo, se tutto andrà bene, ci apparirà qualcosa del genere:

Oh good.. all sounds good.. would you like to try the new kernel without install anything ? [y/n]:

La famosa funzione testing che vi avevo accennato: questa eseguirà questi due comandi:

fastboot boot arch/arm/boot/zImage &
adb reboot bootloader

che caricheranno temporaneamente la zImage compilata e riavvieranno il terminale per il caricamento, dopodiché vedremo il nostro bel Nexus avviarsi con il nuovo kernel.

Utilizzeremo successivamente SetCPU per settare la frequenza tra quelle indicate prima nel sorgente del kernel.

NOTE: l'utilizzo dello smartphone sopra 1.4ghz è ALTAMENTE sconsigliato.

Bhe, abbiamo appreso diverse cose ora, perchè ridendo e scherzando abbiamo compilato un nuovo kernel per il nostro terminale, lo abbiamo modificato e quindi caricato "per finta".

Spero vi sia piaciuto questo piccolo viaggio nei meandri dell'Android Hacking, prometto nei prossimi articoli di farvici avvicinare ancora maggiormente e con più impatto. Vi aspetto nei commenti.

---

Disclaimer (ci vuole, purtroppo): ogni cosa di cui vi ho parlato è stata testata da me in persona ma non mi assumo nessuna responsabilità di eventuali danni da voi creati sui vostri dispositivi.