Porting ClockworkMod Recovery to a New Device

ClockworkMod, commonly abbreviated as CWM, is a popular custom recovery for Android phones and tablets developed by Koushik Dutta (Koush), a well-known name in the Android dev community. This recovery image allows you to perform many advanced tasks like flashing, backups, restoration and other maintenance tasks on your android device which the stockrecovery cannot do.
Thus ClockWorkMod (also known as CWM) is a very popular custom recovery.

Setup the build environment. Guide on that can be found here : Building from Source
Please note that we will be compiling the latest version of CWM recovery.

The source for CWM comes bundled with the CyanogenMod source code. So you will have to sync the CyanogenMod source.
In this guide, we use the source of CyanogenMod 10 to build CWM 6.

At this stage make sure that you have synced the source, updated it and setup the build environment. Now lets proceed to the actual compiling part.

Step 1 : Open the terminal and change the directory to the top of your source. Then run the command

“ make -j4 otatools ”

This command will create all the necessary tools and files for the recovery compilation. Here -j# signifies the number of processes to start. It is generally based on the number of processors in your computer. This process generally requires 5-7 minutes on a reasonably fast desktop computer.

Step 2 : Now that the otatools are ready, we need to get a dump of our current boot.img. To do this, use ‘adb shell’ and launch this command

“ dump_image boot /sdcard/boot.img “

This command will dump the boot partition as a image file named boot.img to your sdcard. Now pull this image to your local directory using adb pull or any other method.

Step 3 : Now we need to set up the makefiles for this device. Generally this is a long and tedious process. But since we are only compiling a recovery, it will be a lot easier.

From the root of your source directory, run the command

“ . build/envsetup.sh “ or “ source /build/envsetup.sh “

This command will prepare all the necessary files required for compiling (initialize the build environment).

Once it is done, run the command,

“ build/tools/device/mkvendor.sh device_manufacturer_name device_name /your/path/to/the/boot.img “

This will open the boot image and extract all the necessary files in the device/manufacturer/device_name path.

Step 4 : Now that we have extracted the files from the boot.img, we need to edit them to suit our device. Generally this shouldn’t be necessary, but we need  to be sure about that or else we can brick our devices. The only files which are to be edited are ‘BoardConfig.mk’ and ‘recovery.fstab’. The main things that you will need to add is custom partitions (if your device doesn’t support named partitions).

If you change the contents of the BoardConfig.mk file, you will have to run ‘make clobber’ or the changes won’t get picked.

As the name suggests, BoardConfig.mk contains the config about the board used in your device. This is a very important file and a single error or incorrect value can result in a brick. So be cautious while editing this file

Next file is the recovery.fstab. This file lists all the partitions of a device and its paths. If you see any incorrect partition in this file, please change it. You don’t want your boot.img flashed on thebootloader partition, do you ?

I cannot help you with the actual editing as each device has different partitions and different formats.

Step 5 : Once the files are ready, we start the compiling. Run the following command to prepare the system for a compile.

“ . build/envsetup.sh “

Step 6 : Once the system is ready, lets move on to the compile process.

Run the command,

“ lunch full_’device_name’-eng “

For e.g : if you have a device names cooper, the command will be,

“ lunch full_cooper-eng “

This will prepare the files of cooper for compiling.

Step 7 : Now that we have all files setup, run the command

“ make -j4 recoveryimage “

This command builds the recovery in the form of an image file. If you want a fakeflash for testing purpose, then run,

“ make -j4 recoveryzip “

The entire building process takes around 15 minutes.

Once complete, you will get the resulting recovery.img in the ‘out/target/product/device’ path. You can flash the recovery using a flashable zip or from adb using flash_image.

how to add overclocking support and much more for an kernel

Adding features to your kernel

Adding features to your kernel

The kernel is probably one of the most important parts of the Android system, the whole system relies on the kernel, the performance, stability, smoothness, etc.
Considering the kernel as the most important part, you want it to be optimized, making your system run smooth and performing above standards, also the battery life may not suffer when gaining these improvements. In this tutorial I will explain how to add CPU Governors,  how to add I/O Schedulers and a global sight on how to add Overclocking support for your kernel.

Chapters:
1. Github
2. Governors
3. I/O Schedulers
4. Overclocking

Chapter 1. GithubI will not explain how to use Github in general, also I’m not trying to advertise for Github. I just want to say that you really “need” to use Github in order to get a clear overview of the changes you made.
Believe me, without a commit system and thousands of changes in your source, you will definitely forget what you actually did to the source.
Github helps you keeping track of the changes you made. Easily done by commits added by the developer.

If you want to build a (custom) kernel form source and you want to customize it, you must use Github! Not just for the overview of changes but also to make sure you don’t  violate the GPL law!
Since the android kernels are open source and protected by the GPL law, you need to share your source with the world. (same thing counts for manufacturers!)

Enough about Github, let’s start with customizing.

Chapter 2. GovernorsWhat is a governor, why is it important to have custom governors and how to add governors to your kernel? These 3 questions are very important to know.

What is a governor:  A governor is actually nothing more then a behavior profile for your CPU, the governor will tell the CPU exactly what to do in what situation. The term ‘governor’ has nothing to do with it’s function, imagine it was called CPU Presidents! sounds strange but it’s as normal as using the word Governor.

Why is it important to have custom governors: The default governors added to kernels are “ondemand, powersave, performance, conservative” and optionally “userspace”, all these governors are pretty basic and not optimized for usage/battery whatsoever. a list of default governors with a small description:

- ondemand, the overall default CPU governor worldwide. Basically just ramps up your CPU speed to max freq when just pushing the screen once, then lowering it back to the minimal cpu freq (somewhat smart, but not optimized at all).
- performance just stays at the max CPU freq all the time (horrible for your battery).
- powersave stays at the min CPU freq all the time (resulting over the top lag).
- conservative is somewhat adjusted to use less power, but that’s also very notable in performance.
- userspace is a governor that needs to be completely configured manually, the default setting is the same as powersave, it will stay at your min CPU freq when not configured. (this governor is rarely used)

Because the stock CPU Governors are just plain boring and do not improve your device whatsoever, you want to add custom CPU Governors, making your device smoother, more stable and less battery consuming.

How to add a CPU Governor:
The CPU governor itself is just 1 C file, which is located in  kernel_source/drivers/cpufreq/,  for example: cpufreq_smartass2.c. You are responsible yourself for find the governor (look in an existing kernel repo for your device)
But in order to successfully call and compile this file into your kernel you will have to make the following changes:

1. Copy your governor file (cpufreq_govname.c) and browse to  kernel_source/drivers/cpufreq, now paste it.
2.  and open Kconfig (this is the interface of the config menu layout) when adding a kernel, you want it to show up in your config. You can do that by adding the choice of governor.

1 2 3 4 5

config CPU_FREQ_GOV_GOVNAMEHERE tristate "'gov_name_lowercase' cpufreq governor" depends on CPU_FREQ help governor' - a custom governor!

for example, for smartassV2.

1 2 3 4 5

config CPU_FREQ_GOV_SMARTASS2 tristate "'smartassV2' cpufreq governor" depends on CPU_FREQ help 'smartassV2' - a "smart" optimized governor!

next to adding the choice, you also must declare the possibility that the governor gets chosen as default governor.

1 2 3 4 5

config CPU_FREQ_DEFAULT_GOV_GOVNAMEHERE bool "gov_name_lowercase" select CPU_FREQ_GOV_GOVNAMEHERE help Use the CPUFreq governor 'govname' as default.

for example, for smartassV2.

1 2 3 4 5

config CPU_FREQ_DEFAULT_GOV_SMARTASS2 bool "smartass2" select CPU_FREQ_GOV_SMARTASS2 help Use the CPUFreq governor 'smartassV2' as default.

- can’t find the right place to put it? Just search for  “CPU_FREQ_GOV_CONSERVATIVE”,  and place the code beneath, same thing counts for “CPU_FREQ_DEFAULT_GOV_CONSERVATIVE”

Now that Kconfig is finished you can save and close the file.
3. While still in the /drivers/cpufreq folder, open Makefile.
In Makefile, add the line corresponding to your CPU Governor. for example:

1	obj-$(CONFIG_CPU_FREQ_GOV_SMARTASS2)    += cpufreq_smartass2.o

Be ware that you do not call the native C file, but the O file! which is the compiled C file. Save the file.
4. Move to:  kernel_source/includes/linux.  now open cpufreq.h
Scroll down until you see something like:

1 2 3

#elif defined(CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND) extern struct cpufreq_governor cpufreq_gov_ondemand; #define CPUFREQ_DEFAULT_GOVERNOR    (&cpufreq_gov_ondemand)

(other cpu governors are also listed there)

Now add your entry with the selected CPU Governor, example:

1 2 3

#elif defined(CONFIG_CPU_FREQ_DEFAULT_GOV_SMARTASS2) extern struct cpufreq_governor cpufreq_gov_smartass2; #define CPUFREQ_DEFAULT_GOVERNOR (&cpufreq_gov_smartass2)

Save the file and close it.
The initial CPU Governor setup is now complete. when you’ve done all steps successfully, you should be able to choose your governor from the menu (menuconfig, xconfig, gconfig, nconfig). Once checked in the menu it will be included to the kernel.

Commit that is nearly the same as above instructions:  “add smartassV2 and lulzactive governor commit”

Chapter 3.  I/O SchedulersNext to adding custom CPU governors, you can also enhance your kernel by adding new I/O Schedulers if needed. Globally Governors and Schedulers are the same, they both provide a way how the system should work. but on Schedulers it’s all about the Input/Output datastream except the CPU settings. the I/O Schedulers decide how the upcoming I/O activity is being scheduled.
The standard schedulers such as “noop” or “cfq” are pretty decent actually. They perform very reasonable.

Anyways, you can add more I/O Schedulers if you like to, think of “deadline/sio/row/vr”  for example
I will explain how to add a I/O Scheduler, it’s just a bit easier then adding a CPU Governor.

I/O Schedulers can be found in kernel_source/block.

1. Copy your I/O Scheduler file (example sio-iosched.c)  and browse to kernel_source/block, now paste it.
2. Now open Kconfig.iosched, and add the choice to the Kconfig, example for SIO

1 2 3 4 5 6 7 8 9

config IOSCHED_SIO tristate "Simple I/O scheduler" default y ---help--- The Simple I/O scheduler is an extremely simple scheduler, based on noop and deadline, that relies on deadlines to ensure fairness. The algorithm does not do any sorting but basic merging, trying to keep a minimum overhead. It is aimed mainly for aleatory access devices (eg: flash devices).

3. and the default choice option:

1	default "sio" if DEFAULT_SIO

Save the file, and move on to the Makefile of kernel_source/block/
4. Simply add this line, for SIO:

1	obj-$(CONFIG_IOSCHED_SIO)    += sio-iosched.o

Save the file and you’re done! The I/O Schedulers should now popup at the menu config.

Commit that is nearly the same as above instructions:  “add simple I/O scheduler commit”
Chapter 4. Adding OverclockingUnfortunately there is no solution ALL-IN-ONE solution available regarding overclocking, every device has a different OC, making it very important to use the right one!

The target file depends on your chipset type and chipset revision.
for example: on the Galaxy S Plus (which has a QualComm MSM Chipset, (msm7x30) the target file would be:

kernel_source/arch/arm/mach-msm/acpuclock-7×30.c

Once you got your acpuclock file, it’s time to take a look at how overclocking actually works.
Basically overclocking is nothing more then extending an array of frequencies and matching voltages.

Example show’n below is only an example, please find existing kernel with OC for your phone on Github, and study the changes that are made to OC the kernel!

Stock Settings:

1 2 3 4 5 6

static struct pll pll2_tbl[] = { { 42, 0, 1, 0 }, /* 806 MHz */ { 53, 1, 3, 0 }, /* 1024 MHz */ { 125, 0, 1, 1 }, /* 1200 MHz */ { 73, 0, 1, 0 }, /* 1401 MHz */ };

Along with:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

static struct clkctl_acpu_speed acpu_freq_tbl[] = {     { 0, 24576,  LPXO, 0, 0,  30720000,  900, VDD_RAW(900) },     { 0, 61440,  PLL_3,    5, 11, 61440000,  900, VDD_RAW(900) },     { 1, 122880, PLL_3,    5, 5,  61440000,  900, VDD_RAW(900) },     { 0, 184320, PLL_3,    5, 4,  61440000,  900, VDD_RAW(900) },     { 0, MAX_AXI_KHZ, AXI, 1, 0, 61440000, 900, VDD_RAW(900) },     { 1, 245760, PLL_3,    5, 2,  61440000,  900, VDD_RAW(900) },     { 1, 368640, PLL_3,    5, 1,  122800000, 900, VDD_RAW(900) },     /* AXI has MSMC1 implications. See above. */     { 1, 768000, PLL_1,    2, 0,  153600000, 1050, VDD_RAW(1050) },     /*      * AXI has MSMC1 implications. See above.      */     { 1, 806400,  PLL_2, 3, 0, UINT_MAX, 1100, VDD_RAW(1100), &pll2_tbl[0]},     { 1, 1024000, PLL_2, 3, 0, UINT_MAX, 1200, VDD_RAW(1200), &pll2_tbl[1]},     { 1, 1200000, PLL_2, 3, 0, UINT_MAX, 1200, VDD_RAW(1200), &pll2_tbl[2]},     { 1, 1401600, PLL_2, 3, 0, UINT_MAX, 1250, VDD_RAW(1250), &pll2_tbl[3]},     { 0 } };

OC Settings:

1 2 3 4 5 6 7 8 9 10 11 12 13

static struct pll pll2_tbl[] = {     {42, 0, 1, 0 },        /*  806 MHz */     {53, 1, 3, 0 },        /* 1024 MHz */     {58, 1, 3, 0 },     /* 1113 MHz */ /*    {125,0, 1, 1 },     /  1200 MHz */     {63, 1, 3, 0 },     /* 1209 MHz */       {68, 1, 3, 0 },     /* 1305 MHz */     {73, 0, 1, 0 },     /* 1401 MHz */     {78, 1, 3, 0 },        /* 1516 MHz */     {83, 1, 3, 0 },        /* 1612 MHz */     {88, 1, 3, 0 },        /* 1708 MHz */     {93, 1, 3, 0 },        /* 1804 MHz */ };

along with:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

static struct clkctl_acpu_speed acpu_freq_tbl[] = {     { 0, 24576,  LPXO,       0, 0,  30720000,  800, VDD_RAW(800) },     { 0, 61440,  PLL_3,    5, 11, 61440000,  800, VDD_RAW(800) },     { 1, 122880, PLL_3,    5, 5,  61440000,  800, VDD_RAW(800) },     { 0, 184320, PLL_3,    5, 4,  61440000,  800, VDD_RAW(800) },     { 1, 192000, PLL_3,    5, 3,  61440000,  800, VDD_RAW(800) },     { 1, 245760, PLL_3,    5, 2,  61440000,  800, VDD_RAW(800) },     { 1, 368640, PLL_3,    5, 1,  122800000, 850, VDD_RAW(850) },     { 1, 568000, PLL_3,    5, 1,  137800000, 900, VDD_RAW(900) },     /* AXI has MSMC1 implications. See above. */     { 1, 768000, PLL_1,    2, 0,  153600000, 1000, VDD_RAW(1000) },     /*      * AXI has MSMC1 implications. See above.      */     { 1, 806400,  PLL_2, 3, 0, UINT_MAX, 1025, VDD_RAW(1025), &pll2_tbl[0]},     { 1, 1024000, PLL_2, 3, 0, UINT_MAX, 1100, VDD_RAW(1100), &pll2_tbl[1]},     { 1, 1113600, PLL_2, 3, 0, UINT_MAX, 1125, VDD_RAW(1125), &pll2_tbl[2]},     { 1, 1209600, PLL_2, 3, 0, UINT_MAX, 1150, VDD_RAW(1150), &pll2_tbl[3]},     { 1, 1305600, PLL_2, 3, 0, UINT_MAX, 1175, VDD_RAW(1175), &pll2_tbl[4]},     { 1, 1401600, PLL_2, 3, 0, UINT_MAX, 1200, VDD_RAW(1200), &pll2_tbl[5]},     { 1, 1516800, PLL_2, 3, 0, UINT_MAX, 1250, VDD_RAW(1250), &pll2_tbl[6]},     { 1, 1612800, PLL_2, 3, 0, UINT_MAX, 1275, VDD_RAW(1275), &pll2_tbl[7]},     { 1, 1708800, PLL_2, 3, 0, UINT_MAX, 1300, VDD_RAW(1300), &pll2_tbl[8]},     { 1, 1804800, PLL_2, 3, 0, UINT_MAX, 1325, VDD_RAW(1325), &pll2_tbl[9]},     { 0 } };

Handle the CPU with care! Keep in mention that you’re playing with the voltages of your phone. Only raise the voltages by 25 max per try. When your phone doesn’t get enough power when requested it will turn off.
No big deal luckily, but a WARNING to you that you shouldn’t raise the voltage anymore (in the matter of fact you need to lower it by 25 when your device goes off)