[GUIDA] Anatomia della rom RK29xx

[eldiau]

Attenzione: molte delle informazioni che sto per scrivere sono dedotte analizzando la rom e leggendo guide, forum ecc.. ecc.. quindi potrebbero essere imprecise o sbagliate! Mandatemi eventuali correzioni o aggiunte qui nel thread ma anche in messaggio privato dove e' piu' probabile che le veda al volo, cosi' posso integrarle nella quida.

Per chi: Questa guida e' pensata per dev/cuochi/testers/rom-maniaci con un minimo di conoscenza di linux e dei concetti di boot di un computer

Per iniziare a sviluppare e compilare rom fortemente customizzate ma anche per cucinare e' necessario avere ben chiaro come e' strutturata la nostra "rom" e come lo smartpad esegue il boot. Quindi prima di compilare kernel o cyanogen vediamo le "basi"...

I dispositivi RockChip sono degli android atipici e si discostano a volte pesantemente dal tipico telefono, un esempio e' la boot.img che in una android "normale" e' costituita da un kernel accodato da una archivio cpio di boot, su rockchip e' un solo archivio cpio e il kernel vive separatamente.

Il tablet possiede 4Gb Flash NAND, questa memoria viene utilizzata come un hardisk "partizionato" per accogliere le varie parti di sistema operativo

La rom viene distribuita sotto forma di un unico file che di solito si chiama update.img, la versione ufficiale si trova sul sito a questo indirizzo Driver e supporto - Mediacom per flasharla occorre utilizzare windows, spegnere il tablet NON collegato al caricabatteria e tenere premuto il tasto volume- mentre lo si collega alla porta usb del computer, in questo modo il tablet esegue un "microboot" partendo con un firmware interno non modificabile (paragonabile al BIOS di un PC) che non fa altro che attendere comandi e dati sulla porta usb per scrivere la flash, per "parlare" col tablet occorre prima installare i driver per windows che si trovano nello stesso archivio e poi utilizzare il programma RKBatchTool.

Questo microfirmware in altri android si chiama fastboot non e' riscrivibile, quindi in caso di errori di flash con rom non funzionanti dovrebbe sempre essere possibile entrare in modalita' fastboot e flashare un altra rom funzionante, rendendo qausi impossibile brickare il pad. (scordatevi questa ultima frase, non assicuro assolutamente che non ci sia modo di render il pad un fermacarte! ma sono confidente che sia quantomeno molto difficile!)

In realta' il file update.img e' una pacchetto che contiene una serie di file, si puo' scompattare utilizzando gli rk29xxImageTools di wendal scaricabile qui Rk29xx ImageTools V2.1 - SlateDroid.com basta nominarla "wendal.img", copiarla nella cartella dei tool e lanciare il runme.bat lo script permettera' di scompattare l'immagine nelle sue componenti in Temp/Image inoltre scompattera' la system.img nella cartella system per poterla modificare oltre a copiarci dentro system/bin/su e system/app/superuser.apk, lo stesso script permette di ricompattare system.img e di ricreare la update.img. Questo metodo permette il modding classico della rom dove tipicamente si vanno a cambiare gli apk presenti in system/app inoltre grazie a su e superuser.apk permette di acquisire il root sul dispositivo ma con alcune limitazioni dovute al fatto che nella rom stadard system e' un immagine di tipo cramfs che un filesystem compresso read only quindi anche avendo i diritti di root, una volta caricato android non si potranno fare modifice ai file presenti in /system.
Bisogna inoltre fare attenzione se si usano le rom mediacom successive dove il cromfs e' stato modificato (immagino per impedire il modding della rom) e quindi bisogna usare la versione dei tools che o modificato io tempo fa per scompattare la nuova versione di system.img

Per il modding "classico" ci si potrebbe fermare qui le informazioni e i tool sono sufficienti per creare rom customizzate, ma l'idea e' di andare piu' a fondo e magari compilarci noi una rom dai sorgenti cyanogen quindi vediamo meglio i file che compongono la update.img:


update-script
E' uno script che dice al programma di flash RKBatchTool cosa fare se si preme il tasto upgrade: riscrive tutte le immagini, il bootloader e il file parameters inoltre formatta le partizioni data (dove ci sono le app installate) e cache (i file ci cache di dalvik, la java machine che fa girare le app di android)

recover-script
E' uno script che dice al programma di flash RKBatchTool cosa fare se si preme il tasto restore: riscrive solo l'immagine di system, il resto rimane uguale e formatta data e cache

package-file
la lista del contenuto del file update.img

RK29xxLoader(L)_DDR3_400Mhz_V1.65.bin
I loader e' il corrispettivo di GRUB o LILO nel modo linux per PC, in pratica e' il primo prgramma che viene caricato dal firmware del tablet e si occupa di caricare in memoria il kernel passandogli il contenuto del campo CMDLINE nel file parameter

parameter
Viene scritto da "qualche parte" nella flash e viene letto dal loader. Oltre al gia' citato campo CMDLINE, contiene altre informazioni, come l'indirizzo offset in flash dal quale caricare il kernel (parametro KERNEL_IMG ) la combinazione di tasti da premere per entrare in recovery (COMBINATION_KEY ?forse?) e altre info che non sono riuscito a intuire

kernel.img
E' il kernel di linux con in testa un magic (KRNL) qualche byte che da la lunghezza della parte kerbel e in coda un crc e la system.map quindi occhio a sostituire questo file con un semplice kernel in fromato vmlinux... non sara' possibile eseguire il boot.

boot.img
Questa immagine viene caricata come root (/) filesystem dal kernel di linux, e' il corrispettivo di initrd nel mondo in linux per PC, contiene principalemnte init che e' il primo prgramma eseguito dal kernel il cui scopo e' configuarare il sistem e caricare i vari servizi e init.rc che e il file di configurazione che init legge per sapere cosa fare. init.rc e' diviso in sezioni, alcune sezioni vengono eseguite in momenti particolari inoltre ogni sezione puo' avere dei parametri che ne determinano il comportamento come per esempio disabled (non viene eseguita). In maniera grossolana ha la funzione sia del vecchio autoexec.bat del dos piu' la gestione servizi di windows. Init prepara le variabili di sistema, monta i filesystem system, data e cache, crea varie cartelle, sostituisce boot.img come root filesystem (/) ricoprendosi con un rootfs (un filesystem che gira in ram e serve a "simulare" /) che prende il suo posto quindi quando facciamo "ls /" a sistema caricato non vediamo piu' il contenuto di boot.img ma un "ramdisk", lancia alcuni servizi importanti come vold che si occupa in montare la sdcard e le chiavette usb e infine lancia il comando /system/bin/app_process. app_process una volta in memoria si cambia il nome in zygote, zygote e' il processo che "da vita" ad android, in pratica e la viartual machine java (o piu' precisamente dalvik) che si occupa di caricare i vari apk fra cui il launcher che ci mostra il desktop di android

recovery.img
Questa immagine viene caricata come root dal kernel al posto di boot.img se si tengono premuti i tasti di recovery, di nuovo, e' paragonabile ad un initrd. E' simile ha boot.img sel senso che anche qui viene lanciato init pero' l'init.rc e' molto piu semplice, non monta nessun altro filesystem ma lancia il comando "/sbin/recovery". reovery mostra un meno e premette qualche operazione come formattare le altre partizioni o scrivere una immagine di rom. Il comando "/sbin/recovery" e quello che viene customizzato con la famoza clockworkmod recovery e che permette i backup nandroid, che non sono altro che dei dd (device dump) della partizione system!

misc.img
Questo file e' lungo 48Kbyte contiene circa 16Kbyte di zeri poi i codici ascii della stringa "boot-recovery", 48byte di zeri e e la stringa "recovery --wipe_all" e poi un altra 20ina di Kbyte di zeri. ?Penso? che venga letto dal bootloader per decidere cosa fare al prossimo boot, infatti dopo aver flashato la rom il tablet viene reboottato, entra in recovery ed esegue un wipe totale dei dati a questo punto azzera misc.img, non ho provato sperimentalmente ma scommeto che se la si edita con un editor esadecimale (io su linux uso oktet) e si azzerano le locazioni con le stringhe si puo' flashare senza il wipe.

system.img
Questa e' l'immagine della partizione che contiene il cuore del sistema, e in particolare la cartella /system/app (la cartella piu' amata dai cuochi :-) ) in cui ci sono tutti gli apk delle app preinstallate ma soprattutto gli apk che costituiscono il framework dell'ambiente android.


[continua]

[eldiau]

Le varie immagini possono essere flashate separamente in maniera molto piu' comoda, specialemte durante lo sviluppo, senza ricompattarle in un file unico con un altro tool (RKAndroid_v1.29 MEGAUPLOAD - The leading online storage and file delivery service) in particolare e' molto utile flashare boot.img e system.img che sono il cuore del sistema. Il programma e' immediato da utilizzare ma occorre verificare che la colonna degli offset rispecchi corretamente gli offset riportati nel parametro mtdparts nella riga CMDLINE del file parameter perche' altrimenti il kernel non trovera' i file systems che gli avete amorevolmente preparato (inoltre se avete cambiato l'mtbparts rispetto all'ultimo flash dovete prima fare un "Erase IDB" sempre dal tool RKAndroid).

Infatti la flash viene vista dal kernel come partizionata logicamente grazie al parametro mtdparts.
mtdparts e' in pratica una partition table per le flash NAND e NOR (mtd sta per memory technology devices).
Di fatto si comporta esattamente con una partition table msdos sull'hard disk di un pc, quindi e' possibile spippolare questi numeri per cambiare il partizionamento della flash, considerando che il significato dei parametri e' dimensione, offset di inizio e nome partizione; esempio estratto dai parameters standard:

0x00004000@0x0000A000(recovery)
0x00080000@0x0000E000(system)

significa che la "partizione" di nome system ha dimensioni 0x80000 (il numero va diviso per due: 0x40000, trasformato da esadecimale a decimale: 262144 e si trova la dimensione in kbyte che divisa per 1024 da esattamente 256Mb) e inizia alla locazione 0xE000, cioe' dove la partizione precedente (recovery) termina (recovery inizia a 0xA000 + 0x4000 di lunghezza = 0xE000)

Il kernel o piu' precisamente meglio udev crea poi special file in /dev/block per ogni partizione partendo da /dev/block/mtdblock0 e salendo nell'ordine con cui vengono listate in mtdparts.
Se si cambia il layout delle partizioni, ridimensionandole o spostandole di ordine occore fare attenzione che le rispettive immagini che verranno flashate sulle partizioni modificate non devono essere di dimensioni superiori allo spazio disponibuile e ribadisco che andranno rispecchiate nella colonna degli offset su RKAndroid al momento del flash.


Ok, dopo questa maratona scrivero' una guida veloce al modding, una su come compilare cyanogen e un altra su come compilare il kernel dai sorgenti... abbiate pazienza spero di aver scritto il tutto per il weekend! A questo punto, con chi e' rimasto in vita :-) dalla noia possiamo partire nel provare a piazzare cyanogen sullo smartpad!

Diego.

[morfances]

Complimenti !!un po di cultura non fa male:-)

[Samhain]

Grande eldiau!!

[markpn]

complimenti veramente per l'impegno e la chiarezza

[ManuCE]

Bravissimo...grazie x la chiarezza !!

[dsmobile2009]

6 1 grande!
Ho un'infarinatura di IT e mi interessava, a grandi linee, conoscere le basi del cook del nostro SP.
Grazie,
DSmobile

---*---*---
sto convertendo tutti i miei amici e parenti ad Android perchè il futuro è lì!
---*---*---

[purplebaron]

Grande Eldiau! Ottimo lavoro. Potresti mettere anche qualche sito di riferimento per approfondire gli argomenti trattati?

[housepabldroid]

davvero un ottimo lavoro.. per me che android e linux sono "arabo", questa discussione è di grande aiuto..

[jacock]

Quindi cyanogen incooming?