1

RK29 modding tutorial by wackym v1.0

This tutorial is written to demystify “the art of modding” and help you (the reader) to help yourself and inspire you to share your knowledge and help others… All credit for the tools used in this tutorial goes to their respective authors. I only wrote *.sh scripts to use those tools.

1. Basic requirements

To start developing you need the following: - Ubuntu/Lubuntu/Xubuntu etc. or similar Linux environment (I recommend Lubuntu, since it’s very lightweight

and works fast even in virtual machines)

- tools.tar.bz2 pack installed at ~ /bin mkdir ~/bin

cd ~/bin

tar xvf ~/Downloads/tools.tar.bz2

- make sure the following tools are installed on your Linux distro: awk, grep, gzip, du, find, wc, rsync, head, cpio

or you will get errors running the scripts

- rkusb drivers and RKBatchTool (you get these with the update image) Familiarize yourself with (at least) basic Linux commands like: chmod, chown, mc, cp, mkdir, rm, rsync, grep, mount, umount…and with Linux permissions, especially “set user and set group” permissions. Which are important for proper rooting. And finally, why Linux at all? Because file permissions and ownerships are crucial to modding and they get lost on Windows. You could, however, use Cygwin…

2

2. RK image structure

RK image structure: Outer layer (rk_xyz.img) consists of:

- Inner layer (update.img) consists of o Bootloader.bin (this is the initial “program” which configures hardware to be able to properly load

kernel and RAM file system; WARNING, NEVER change this file in any way! If this stops working then you will end up with a VERY EXPENSIVE paper weight.)

o package-file (contains information about partition to file mappings, if kernel is included in boot.img then it is commented out in this file)

o parameter (contains information about device and most importantly command line (CMDLINE) passed to kernel)

o recover-script (script executed on firmware recovery) o update-script (script executed on firmware update) o Image/boot.img (this image can be packed with kernel or RAM file system by itself) o Image/kernel.img (this image contains kernel – the core “program” which is the advocate between

hardware and applications; it also contains an embedded image – the first one displayed upon device startup)

o Image/recovery.img (this is a safe backup which gets executed if boot.img fails and first time after new firmware update)

o Image/misc.img (this contains a special script which usually formats /data and /sdcard partitions upon flashing of device)

o Image/system.img (contains applications, framework etc. – most of the time you’ll only need to edit this image)

- bootloader location - MD5 checksum

3

3. Unpacking <rk_xyz.img> packed with RockChip tools

Let’s assume you acquired an rk_xyz.img file and copied it into you project directory ~/project1 (by now you should know that “~” represents your home directory on linux fi. /home/userXY). Step 1: Check if the tools are working by running ver.sh. You should get a similar output: user@ubu1004:~/project1$ ver.sh

Usage: /home/user/bin/ver.sh <apk dir>

user@ubu1004:~/ project1$

If you get “command not found” or similar try to open a new shell or do this “export PATH=~ /bin:$PATH” and go to step 1. Step2: Use rkimg.sh to unpack the image: user@ubu1004:~/project1$ rkimg.sh -u rk_xyz.img

****** Cleaning dev folders

****** Unpacking rk_xyz.img to unpack_update/

rom version: 0.2.3

build time: 2012-02-08 17:26:33

chip: 50

checking md5sum....OK

Check file...OK

------- UNPACK -------

package-file 0x00000800 0x0000021C

RK29xxLoader(L)_V2.06.bin 0x00001000 0x00021FDA

parameter 0x00023000 0x00000265

Image/misc.img 0x00023800 0x0000C000

Image/boot.img 0x0002F800 0x007C4000

Image/recovery.img 0x007F3800 0x00960000

Image/system.img 0x01153800 0x14000000

SELF 0x00000000 0x15154804

Skip SELF file.

update-script 0x15153800 0x000003A5

recover-script 0x15154000 0x0000010A

UnPack OK!

****** Done.

user@ubu1004:~/project1$

If you do “ls -la” you will see source_img and unpack_update directories got created. source_img contains all the img files and unpack_update contains all special files.

4

4. Editing system.img

4.1. Mounting system.img

First you need to mount the image. You can do it manually or use sysmount.sh script. Using sysmount.sh: user@ubu1004:~/project1$ sysmount.sh –m # this mounts the system.img in source_img dir

Using manual approach: user@ubu1004:~/project1$ mkdir system # this creates a folder in which we’ll mount our image

user@ubu1004:~/project1$ sudo mount -o loop source_img/system.img system/

[sudo] password for user:

user@ubu1004:~/project1$

By mounting as a loop device we let linux to figure out the type of file system it is mounting. In the case of RK the file system type is usually ext3 (for other SDK’s it could be ext2, yaffs2, cramfs, ext4 etc.). This is also the file system that gets created with rkimg.sh script. After mounting you can use “mc” (Midnight Commander) to easily navigate around system folder. Remember: before packing/moving/copying/<or doing whatever with> system.img you MUST unmount it first or you will risk using a corrupted system.img. When you unmount the image Linux writes back to the image any cached changes that you’ve made while it was mounted.

4.2. Unmounting

Automatic approach: user@ubu1004:~/project1$ sysmount.sh –u # this unmounts the system.img and also performs some

fixes of the “usual” faults (described in tweaks and fixes section below)

Manual approach: user@ubu1004:~/project1$ sudo umount system/ # this unmounts (whichever) img that’s mounted at

system/ directory in current folder

4.3. Folder structure user@ubu1004:~/project1$ cd system/

user@ubu1004:~/project1/system$ ls -la

total 33

drwxr-xr-x 14 root root 1024 2012-02-29 11:31 ./

drwxr-xr-x 5 user user 4096 2012-03-03 13:27 ../

drwxr-xr-x 2 root root 4096 2012-02-29 09:06 app/ # all .apk files that are shipped with firmware

drwxr-xr-x 2 root 2000 5120 2012-02-28 16:22 bin/ # system executables busybox, chmod, chown etc.

drwxr-xr-x 11 root root 1024 2012-02-29 09:06 etc/ # configuration files (mounting, permissions…)

drwxr-xr-x 3 root root 1024 2012-02-28 16:11 fonts/

drwxr-xr-x 2 root root 1024 2012-02-29 09:06 framework/ # basic apks and jars providing API to

other apks

drwxr-xr-x 8 root root 7168 2012-02-29 09:06 lib/ # basic libraries + libs from apks in app

folder (remark: if you do not copy libs from apks you add to app folder then those apps will crash

on startup)

drwx------ 2 root root 1024 2012-02-29 11:31 lost+found/

drwxr-xr-x 3 root root 1024 2012-02-29 09:06 media/ # bootanimation.zip (animation after boot

image), audio (sounds)

drwxr-xr-x 3 root root 1024 2012-02-28 15:55 tts/ # text-to-speech files

drwxr-xr-x 8 root root 1024 2012-02-28 16:07 usr/ # some more configuration files – important:

keylayout (contains mapping from external buttons to functions)

drwxr-xr-x 4 root 2000 1024 2012-02-28 15:55 vendor/ # contains vendor specific stuff and

facelock files

drwxr-xr-x 2 root 2000 1024 2012-02-28 16:21 xbin/ # additional system executables + su

(superuser); su can also be in bin folder (but there may be only one)

-rw-r--r-- 1 root root 2246 2012-02-29 11:10 build.prop # build, version, settings, properties

etc.

Note the root:root (the same as 0:0) or root:2000 (the same as 0:2000) permissions. These permissions are crucial. If you accidently change them your device will most likely not boot (stay in boot animation endlessly).

5

4.4. Permissions and ownerships

I assume you have (at least) basic knowledge of Linux permissions and ownerships…if not then you can learn more about it here:

http://www.tuxfiles.org/linuxhelp/filepermissions.html

http://code.google.com/edu/tools101/linux/ownership_permissions.html All files in system.img must be owned by root (id 0) but the groups can be different to allow access to those files to special system services. That’s why some folders (bin/, xbin/, vendor/) have group set to id 2000 instead of root. When you’re adding a file you should be doing this in superuser mode. As default, every file you add will get root:root ownership. For files in bin/ xbin/ and vendor/ you will probably need to change that to root:2000. If unsure, do “ls -la” in the folder and see what ownerships other files have. To change ownerships use “sudo chown root:2000 <file>” or “sudo chown -R root:2000 <folder>” (this changes ownerships for every file and subfolder in that folder). Permissions for files in executables folders (bin/, xbin/) should always be at least readable and executable for all, and writable for owner and group. Some files require also SETUID and SETGUID permissions (fi. “su”). Adding setuid can be done like so: “sudo chmod u+s <file>”. Adding setgid is similar: “sudo chmod g+s <file>”.

4.5. Editing system.img

A “rule of thumb” is to always make sure you have enough space for what you want to do… To check this you have to mount system.img and use command “df”. It will show you exactly how much space is used inside the image. user@ubu1004:~/project1$ df # this command shows information about all mounted devices

Filesystem 1K-blocks Used Available Use% Mounted on

/dev/sda1 24688764 19455028 3979592 84% /

none 250152 212 249940 1% /dev

none 254384 164 254220 1% /dev/shm

none 254384 88 254296 1% /var/run

none 254384 0 254384 0% /var/lock

none 254384 0 254384 0% /lib/init/rw

.host:/ 732568572 725397128 7171444 100% /mnt/hgfs

/dev/loop0 349991 349887 104 100% /home/user/project1/system

user@ubu1004:~/project1$

Here we see that I have mounted an image (system.img) as loop device to system/ folder and that is has only 104 KB (why KB? Note the 1K-blocks label in the output) space left. Let’s presume you want to add a new apk and you have too little free space. You can either remove the apks you don’t want/need and then add new apks or extract (read: “copy”) the contents from system.img.

4.6. Extracting system.img

Make sure you’ve mounted system.img (see “Mounting system.img”). If you’re unsure check with “mount” command. By now you should have system.img mounted to system/ folder in your current project folder. So, to make a perfect copy of system we’ll use “rsync -a” command. user@ubu1004:~/project1$ sudo rsync -a system/ system_new

[sudo] password for user:

user@ubu1004:~/project1$ ls –la # after rsync you should see a similar output

total 21

drwxr-xr-x 6 user user 4096 2012-03-04 13:30 ./

drwxr-xr-x 16 user user 4096 2012-03-03 10:40 ../

drwxr-xr-x 2 user user 4096 2012-03-03 10:44 source_img/

drwxr-xr-x 14 root root 1024 2012-02-29 11:31 system/

drwxr-xr-x 14 root root 4096 2012-02-29 11:31 system_new/

drwxr-xr-x 2 user user 4096 2012-03-03 10:44 unpack_update/

user@ubu1004:~/project1$

Now unmount system.img (see “Unmounting”) as we don’t need it and we’ll replace it later.

6

4.7. Adding apk(s) to system

The easiest way (at least for me) is to use Midnight Commander (no mouse required ). Make sure you run it as superuser: “sudo mc”. This will allow you to edit system/ or system_new/ and at the same time it will keep ownerships of any files you add as root:root. To add new apk(s) you need to copy them into app/ folder. Then you need to copy all *.so files from lib/ folder inside apk (if the folder is present) to <system>/lib/ folder. Some apk(s) contain libs for multiple architectures – only copy those for ARM architecture (there will be a word “arm” in the subfolder). If it has multiple arm subfolders then use *.so files from armv7. Quick tip: to navigate inside apk(s) just use Midnight Commander. After you add files to app/ make sure they have proper permissions (they should be -rw-r--r-- or 755 in octal). user@ubu1004:~/project1/system_new/app$ ls –l New.apk

-rw-r--r-- 1 root root 11928009 2012-02-29 09:06 New.apk

4.8. Comparing, replacing, removing apk(s)

To compare apks you need their versions. For this I wrote ver.sh script. It creates a list (named appver.txt) of all apks and their versions for the specified directory. user@ubu1004:~/project1$ ver.sh

Usage: ver.sh <apk dir>

user@ubu1004:~/project1$ ver.sh system_new/app/

Created /home/user/project1/appver.txt

You will get a similar output: user@ubu1004:~/project1$ cat appver.txt # print appver.txt to console

Apk versions:

ApplicationsProvider.apk

package: name='com.android.providers.applications' versionCode='15' versionName='4.0.3-

eng.wbx.20120229.121900'

BackupRestoreConfirmation.apk

package: name='com.android.backupconfirm' versionCode='15' versionName='4.0.3-

eng.wbx.20120229.121900'

BooksProvider.apk

package: name='com.android.rk.books' versionCode='400' versionName='4.00'

… With this output you can decide which apk to use… Quick tip: to compare two appver.txt files you can use “meld”. Deciding which apk to keep can be puzzling, so here’s a link to Cynogen’s wiki which has description of most of the “default” apks: http://wiki.cyanogenmod.com/wiki/Barebones Latest (tested) google apps can be found here: http://wiki.rootzwiki.com/Google_Apps When replacing apps take extra care with apks that use special devices like Camera, Bluetooth, etc. These apks are often vendor specific and non-portable to other devices.

4.9. Compressing/creating ext3 system.img

This is needed only if you extracted system.img. To create new system.img use “sysimg.sh” script. user@ubu1004:~/project1$ sysimg.sh

Usage: sysimg.sh <system dir>

user@ubu1004:~/project1$ sysimg.sh system_new/

****** Finding required inode count and required size...

[sudo] password for user:

****** >> Estimated required size of system.img is 351 MB

****** Creating ext3 system.img...

351+0 records in

351+0 records out

368050176 bytes (368 MB) copied, 8.23738 s, 44.7 MB/s

mke2fs 1.41.12 (17-May-2010)

target_img/system.img is not a block special device.

Proceed anyway? (y,n) Filesystem label=system

OS type: Linux

Block size=1024 (log=0)

7

Fragment size=1024 (log=0)

Stride=0 blocks, Stripe width=0 blocks

2112 inodes, 359424 blocks

17971 blocks (5.00%) reserved for the super user

First data block=1

Maximum filesystem blocks=67633152

44 block groups

8192 blocks per group, 8192 fragments per group

48 inodes per group

Superblock backups stored on blocks:

8193, 24577, 40961, 57345, 73729, 204801, 221185

Writing inode tables: done

Creating journal (8192 blocks): done

Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 30 mounts or

180 days, whichever comes first. Use tune2fs -c or -i to override.

****** Disabling auto-checking of system.img

tune2fs 1.41.12 (17-May-2010)

Setting maximal mount count to -1

Setting interval between checks to 0 seconds

****** Copying data...

****** Setting owner...

****** Setting permissions...

****** Unmounting image...

****** Checking and optimizing system.img

e2fsck 1.41.12 (17-May-2010)

Pass 1: Checking inodes, blocks, and sizes

Pass 2: Checking directory structure

Pass 3: Checking directory connectivity

Pass 3A: Optimizing directories

Pass 4: Checking reference counts

Pass 5: Checking group summary information

system: ***** FILE SYSTEM WAS MODIFIED *****

system: 1278/2112 files (4.1% non-contiguous), 352324/359424 blocks

user@ubu1004:~/project1$

This script also fixes permissions and ownerships for app/ directory. Newly created system.img will be put into target_img/ directory. To use this system.img with sysmount.sh or rkimg.sh script you need to move it to source_img/ folder. Remember to always check that system.img is not mounted before you move or copy over it (see Extracting system.img).

8

5. Editing boot.img and recovery.img

WARNING, do not change recovery.img at all! There’s no need to.

5.1. Unpacking

There are two types of boot.img. Some contain kernel and others don’t. This issue is handled automatically by unpack.sh script. user@ubu1004:~/project1$ unpack.sh boot

****** Cleaning dev folders # deletes boot/ and unpack_boot/ folders

****** Unpacking boot.img

>> this image contains ramdisk and kernel # kernel can also be in a separate kernel.img

writing boot image config in bootimg.cfg

extracting kernel in zImage

extracting ramdisk in initrd.img

****** Extracting ramdisk... # extracts initrd.img to boot/

2782 blocks

Doing “ls -la boot/” will show you a similar output. Files of interest are marked orange. user@ubu1004:~/project1$ ls -la boot/

total 656

drwxr-xr-x 9 user user 4096 2012-03-05 13:04 ./

drwxr-xr-x 9 user user 4096 2012-03-05 13:04 ../

drwxrwx--x 2 user user 4096 2012-03-05 13:04 data/

drwxr-xr-x 2 user user 4096 2012-03-05 13:04 dev/

drwxr-xr-x 2 user user 4096 2012-03-05 13:04 proc/

drwxr-xr-x 3 user user 4096 2012-03-05 13:04 res/

drwxr-x--- 2 user user 4096 2012-03-05 13:04 sbin/

drwxr-xr-x 2 user user 4096 2012-03-05 13:04 sys/

drwxr-xr-x 2 user user 4096 2012-03-05 13:04 system/

-rwxr-x--- 1 user user 240612 2012-03-05 13:04 charger*

-rw-r--r-- 1 user user 116 2012-03-05 13:04 default.prop

-rwxr-x--- 1 user user 102816 2012-03-05 13:04 init*

-rwxr-x--- 1 user user 2344 2012-03-05 13:04 init.goldfish.rc* # this is used by

developers

-rwxr-x--- 1 user user 17072 2012-03-05 13:04 init.rc* # init stuff

-rwxr-x--- 1 user user 4091 2012-03-05 13:04 init.rk29board.rc* # vendor specific init

stuff

-rwxr-x--- 1 user user 5692 2012-03-05 13:04 init.rk29board.usb.rc* # PIDs & VIDs for different

usb modes

-rw-r--r-- 1 user user 114479 2012-03-05 13:04 rk29xxnand_ko.ko.2.6.32.27

-rw-r--r-- 1 user user 115596 2012-03-05 13:04 rk29xxnand_ko.ko.3.0.8+ # kernel module for NAND

-rw-r--r-- 1 user user 272 2012-03-05 13:04 ueventd.goldfish.rc

-rw-r--r-- 1 user user 3825 2012-03-05 13:04 ueventd.rc

-rw-r--r-- 1 user user 1785 2012-03-05 13:04 ueventd.rk29board.rc

There’s really no need to edit these files (unless you want to disable boot logo or smth.). But if you decide to edit these files then you already know what you’re doing…

5.2. Packing

Packing is as easy as unpacking. user@ubu1004:~/project1$ pack.sh boot

****** Packing boot/ to boot.img-raw

****** Creating boot.img

>> Kernel is included in boot.img

reading config file unpack_boot/bootimg.cfg

reading kernel from unpack_boot/zImage

reading ramdisk from unpack_boot/initrd.img-new

Writing Boot Image target_img/boot.img

This scripts detects boot.img type by reading original boot.img in source_img folder then uses that information to pack files, kernel, bootcmd to target_img/boot.img. To use this image in final firmware image you have to copy it to source_img folder. user@ubu1004:~/project1$ cp –f target_img/boot.img source_img/boot.img

9

6. Editing firmware parameter file

Parameter file contains information about machine, kernel location in RAM (KERNEL_IMG), kernel command line location in RAM (ATAG) and most important – actual command line (CMDLINE) that is passed to kernel upon boot. This is what a sample parameter file looks like. CMDLINE looks like it’s multiline but in fact it’s a straight line without any newlines. user@ubu1004:~/project1$ cat unpack_update/parameter

FIRMWARE_VER:0.2.3

MACHINE_MODEL:Full AOSP on Rk29sdk

MACHINE_ID:007

MANUFACTURER:RK29SDK

MAGIC: 0x5041524B

ATAG: 0x60000800

MACHINE: 2929

CHECK_MASK: 0x80

KERNEL_IMG: 0x60408000

CMDLINE: quiet console=ttyS1,115200n8n androidboot.console=ttyS1 init=/init

initrd=0x62000000,0x800000

mtdparts=rk29xxnand:0x00002000@0x00002000(misc),0x00004000@0x00004000(kernel),0x00008000@0x00008000

(boot),0x00008000@0x00010000(recovery),0x00100000@0x00018000(backup),0x0003a000@0x00118000(cache),0

x00200000@0x00152000(userdata),0x00002000@0x00352000(kpanic),0x00100000@0x00354000(system),-

@0x00454000(user)

Why is CMDLINE so important? It contains information about flash partitioning (mtdparts=…) aka. how much space is reserved and where is it located.

6.1. Editing “mdtparts”

mtdparts expanded looks like this: <number of sectors>@<location in sector units>(<name of partition>)

0: 0x00002000@0x00002000(misc), 8.192K

1: 0x00004000@0x00004000(kernel), 16.384K

2: 0x00008000@0x00008000(boot), 32.768K

3: 0x00008000@0x00010000(recovery), 32.768K

4: 0x00100000@0x00018000(backup), 524.288K

5: 0x0003a000@0x00118000(cache), 118.784K

6: 0x00200000@0x00152000(userdata), 1.048.576K

7: 0x00002000@0x00352000(kpanic), 8.192K

8: 0x00100000@0x00354000(system), 524.288K

9: -@0x00454000(user) 14.508.032K

Bear in mind that each sector is 512 bytes long… I’ve added sizes in kilobytes for easier reading. Since 1GB (1.048.576K) of userdata space is (for most) too little space for user apps you might want to increase it. In following example I’ll double the space. 0: 0x00002000@0x00002000(misc), 8.192K

1: 0x00004000@0x00004000(kernel), 16.384K

2: 0x00008000@0x00008000(boot), 32.768K

3: 0x00008000@0x00010000(recovery), 32.768K

4: 0x00100000@0x00018000(backup), 524.288K

5: 0x0003a000@0x00118000(cache), 118.784K

6: 0x00400000@0x00152000(userdata), 2.097.152K

7: 0x00002000@0x00552000(kpanic), 8.192K

8: 0x00100000@0x00554000(system), 524.288K

9: -@0x00654000(user) 13.459.456K

Userdata space is now increased by 0x00200000 sectors (or 1GB) and subsequently also all locations of partitions after userdata are moved for same amount of sectors. This increase in userdata space is then finally deducted from “user” partition (minus sign before “@” means that user partition will use all the space left). “user partition” is also the partition that gets mounted as internal SD card and is unfortunately deleted and recreated with every firmware update.

10

7. Creating final firmware image for flashing with RK29BatchTool

Before packing firmware make sure that you:

Unmounted system.img

Copied all img’s (that you’ve created and wish to use) from target_img to source_img

Didn’t delete unpack_update folder or any files in it I also recommend comparing your modded (unpacked) firmware to original (unpacked) firmware. A good tool for this is “meld”. By comparing you can easily spot missing, added, changed files and decide whether this is what you intended or a mistake. To create (pack) final image (firmware) use “rkimg.sh”. user@ubu1004:~/project1$ rkimg.sh -p xyz_mod.img

****** Packing to xyz_mod.img

------ PACKAGE ------

Add file: unpack_update/package-file

Add file: unpack_update/RK29xxLoader(L)_V2.06.bin

Add file: unpack_update/parameter

Add file: unpack_update/Image/misc.img

Add file: unpack_update/Image/boot.img

Add file: unpack_update/Image/recovery.img

Add file: unpack_update/Image/system.img

Add file: unpack_update/update-script

Add file: unpack_update/recover-script

Add CRC...

------ OK ------

Pack OK!

generate image...

append md5sum...

success!

****** Done.

user@ubu1004:~/project1$

This script temporarily moves and renames source_img to unpack_update/Image/ then uses “afptool” to create intermediate update.img. “img_maker” then adds some device info, md5 sum and outputs final firmware to be used with rkbatchtools.

11

8. FAQ

Q: I’ve flashed a new firmware and device shows me a broken robot. What to do? A: This is most likely due to bad boot.img. Press and hold power button until device turns off then repeat the flashing with better firmware. Q: After flashing device is showing only black screen. What to do? A: See previous answer. You will see the difference in screen lighting when device is off. Q: After flashing device is looping endlesly in boot animation. What to do? A: See previous answers. There’s something wrong in system.img. Q: How can I increase application space? A: See “Editing “mdtparts””. Q: I cannot write to external sdcard and/or usb. What to do? A: There’s a permission file (platform.xml) in system.img in folder /etc/permissions/. Sometimes it helps by adding <group gid=”media_rw” /> to EXTERNAL_STORAGE and <group gid=”sdcard_rw” /> to MEDIA_STORAGE. This issue could (possibly) be also solved by editing init*.rc scripts… Q: External SD doesn’t mount at all. What to do? A: Check logs with CatLog or similar app and see if there’s an error while mounting. Perhaps the SD is corrupted. If there’s no error then check file /etc/vold.fstab (in system.img) entries – usb entry might be wrong.

12

9. Useful links/further reading

Linux:

http://linuxreviews.org/beginner/

http://fosswire.com/post/2007/08/unixlinux-command-cheat-sheet/

http://www.tuxfiles.org/linuxhelp/filepermissions.html

http://code.google.com/edu/tools101/linux/ownership_permissions.html Firmware tweaks, google apps, etc.:

http://forum.xda-developers.com/showthread.php?t=1331351

http://wiki.cyanogenmod.com/wiki/Barebones

http://wiki.rootzwiki.com/Google_Apps

http://androtab.info/cyanogenmod/rockchip/ For learning about my scripts/building your own:

http://www.slatedroid.com/topic/26030-cube-u9gt2-flashing-and-customizing-linux-tools/

https://github.com/jhonxie/rk2918_tools

http://www.arctablet.com/wiki/index.php/Rksp_relink

https://github.com/naobsd/rkutils

http://www.slatedroid.com/topic/19808-rk29xx-imagetools-v21/page__st__40 Further development:

http://forum.xda-developers.com/showthread.php?t=1389375

https://github.com/eyecatchup/net.bexton.android.UsbMassStorageToggle

http://codewalkerster.blogspot.com/2012_02_01_archive.html

http://apkmultitool.com/node/7

http://forums.androidcentral.com/hacking/144804-how-compile-ics-aosp-4-0-3-xoom-gnex-nexus-s.html

http://wendal.net/350.html To relax your mind after reading this tutorial :

Music from this page: http://ask.metafilter.com/178886/EpicEmotional-Soundtrack-Music#2573739 For everything else:

http://www.google.com/