{"id":2214,"date":"2011-09-14T09:23:47","date_gmt":"2011-09-14T07:23:47","guid":{"rendered":"http:\/\/glandium.org\/blog\/?p=2214"},"modified":"2011-09-14T09:23:47","modified_gmt":"2011-09-14T07:23:47","slug":"building-a-custom-kernel-for-the-nexus-s","status":"publish","type":"post","link":"https:\/\/glandium.org\/blog\/?p=2214","title":{"rendered":"Building a custom kernel for the Nexus S"},"content":{"rendered":"

There are several reasons why someone would want to build a custom kernel for their Android phone. In my case, this is because I wanted performance counters (those used by the perf tool<\/a> that comes with the kernel source). In Julian Seward<\/a>'s case, he wanted swap support to overcome the limited memory amount on these devices in order to run valgrind. In both cases, the usual suspects (AOSP, CyanogenMod) don't provide the wanted features in prebuilt ROMs.<\/p>\n

There are also several reasons why someone would NOT want to build a complete ROM for their Android phone. In my case, the Nexus S is what I use to work on Firefox Mobile, but it is also my actual mobile phone. It's a quite painful and long process to create a custom ROM, and another long (but arguably less painful thanks to ROM manager) process to backup the phone data, install the ROM, restore the phone data. And if you happen to like or use the proprietary Google Apps that don't come with the AOSP sources, you need to add more steps.<\/p>\n

There are however tricks that allow to build a custom kernel for the Nexus S and use it with the system already on the phone. Please note that the following procedure has only been tested on two Nexus S with a 2.6.35.7-something kernel (one with a stock ROM, but unlocked, and another one with an AOSP build). Also please note that there are various ways to achieve many of the steps in this procedure, but I'll only mention one (or two in a few cases). Finally, please note some steps rely on your device being rooted. There may be ways to do without, but I'm pretty sure it requires an unlocked device at the very least. This post doesn't cover neither rooting nor unlocking.<\/p>\n

Preparing a build environment<\/h2>\n

To build an Android kernel, you need a cross-compiling toolchain. Theoretically, any will do, provided it targets ARM. I just used the one coming in the Android NDK:<\/p>\n

$ wget http:\/\/dl.google.com\/android\/ndk\/android-ndk-r6b-linux-x86.tar.bz2
\n$ tar -jxf android-ndk-r6b-linux-x86.tar.bz2
\n$ export ARCH=arm
\n$ export CROSS_COMPILE=$(pwd)\/android-ndk-r6b\/toolchains\/arm-linux-androideabi-4.4.3\/prebuilt\/linux-x86\/bin\/arm-linux-androideabi-<\/code><\/p><\/blockquote>\n

For the latter, you need to use a directory path containing prefixed versions (such as arm-eabi-gcc<\/code> or arm-linux-androideabi-gcc<\/code>), and include the prefix, but not \"gcc\".<\/p>\n

You will also need the adb<\/code> tool coming from the Android SDK. You can install it this way:<\/p>\n

$ wget http:\/\/dl.google.com\/android\/android-sdk_r12-linux_x86.tgz
\n$ tar -zxf android-sdk_r12-linux_x86.tgz
\n$ android-sdk-linux_x86\/tools\/android update sdk -u -t platform-tool
\n$ export PATH=$PATH:$(pwd)\/android-sdk-linux_x86\/platform-tools<\/code><\/p><\/blockquote>\n

Building the kernel<\/h2>\n

For the Nexus S, one needs to use the Samsung Android kernel tree, which happens to be unavailable at the moment of writing due to the kernel.org outage. Fortunately, there is a clone used for the B2G<\/a> project, which also happens to contain the necessary cherry-picked patch to add support for the PMU registers on the Nexus S CPU that are needed for the performance counters.<\/p>\n

$ git clone -b devrom-2.6.35 https:\/\/github.com\/cgjones\/samsung-android-kernel
\n$ cd samsung-android-kernel<\/code><\/p><\/blockquote>\n

You can then either start from the default kernel configuration:<\/p>\n

$ make herring_defconfig<\/code><\/p><\/blockquote>\n

or use the one from the B2G project, which enables interesting features such as oprofile:<\/p>\n

$ wget -O .config https:\/\/raw.github.com\/cgjones\/B2G\/master\/config\/kernel-nexuss4g<\/code><\/p><\/blockquote>\n

From then, you can use the make menuconfig<\/code> or similar commands to further configure your kernel.<\/p>\n

One of the problems you'd first encounter when booting such a custom kernel image is that the bcm4329 driver module that is shipped in the system partition (and not in the boot image) won't match the kernel, and won't be loaded. The unfortunate consequence is the lack of WiFi support.<\/p>\n

One way to overcome this problem is to overwrite the kernel module in the system partition, but I didn't want to have to deal with switching modules when switching kernels.<\/p>\n

There is however a trick allowing the existing module to be loaded by the kernel: compile a kernel with the same version string as the one already on the phone. Please note this only really works if the kernel is really about the same. If there are differences in the binary interface between the kernel and the modules, it will fail in possibly dangerous ways.<\/p>\n

To use that trick, you first need to know what kernel version is running on your device. Settings > About phone > Kernel version<\/em> will give you that information on the device itself. You can also retrieve that information with the following command:<\/p>\n

$ adb shell cat \/proc\/version<\/code><\/p><\/blockquote>\n

With my stock ROM, this looks like the following:<\/p>\n

Linux version 2.6.35.7-ge382d80 (android-build@apa28.mtv.corp.google.com) (gcc version 4.4.3 (GCC) ) #1 PREEMPT Thu Mar 31 21:11:55 PDT 2011<\/code><\/p><\/blockquote>\n

In the About phone<\/em> information, it looks like:<\/p>\n

2.6.35.7-ge382d80
\nandroid-build@apa28<\/code><\/p><\/blockquote>\n

The important part above is -ge382d80<\/b><\/code>, and that is what we will be using in our kernel build. Make sure the part preceding -ge382d80<\/code> does match the output of the following command:<\/p>\n

$ make kernelversion<\/code><\/p><\/blockquote>\n

The trick is to write that -ge382d80<\/code> in a .scmversion<\/code> file in the kernel source tree (obviously, you need to replace -ge382d80<\/code> with whatever your device has):<\/p>\n

$ echo -ge382d80<\/em> > .scmversion<\/code><\/p><\/blockquote>\n

The kernel can now be built:<\/p>\n

$ make -j$(($(grep -c processor \/proc\/cpuinfo) * 3 \/ 2))<\/code><\/p><\/blockquote>\n

The -j<\/code>... part is the general rule I use when choosing the number of parallel processes make<\/code> can use at the same time. You can pick whatever suits you better.<\/p>\n

Before going further, we need to get back to the main directory:<\/p>\n

$ cd ..<\/code><\/p><\/blockquote>\n

Getting the current boot image<\/h2>\n

The Android boot image living in the device doesn't contain only a kernel. It also contains a ramdisk containing a few scripts and binaries, that starts the system initialization. As we will be using the ramdisk coming with the existing kernel, we need to get that ramdisk from the device flash memory:<\/p>\n

$ adb shell cat \/proc\/mtd | awk -F'[:\"]' '$3 == \"boot\" {print $1}'<\/code><\/p><\/blockquote>\n

The above command will print the mtd device name corresponding to the \"boot\" partition. On the Nexus S, this should be mtd2<\/b><\/code>.<\/p>\n

$ adb shell
\n$ su
\n# dd if=\/dev\/mtd\/mtd2<\/b> of=\/sdcard\/boot.img bs=4096
\n2048+0 records in
\n2048+0 records out
\n8388608 bytes transferred in x.xxx secs (xxxxxxxx bytes\/sec)
\n# exit
\n$ exit<\/code><\/p><\/blockquote>\n

In the above command sequence, replace mtd2<\/em> with whatever the previous command did output for you. Now, you can retrieve the boot image:<\/p>\n

$ adb pull \/sdcard\/boot.img<\/code><\/p><\/blockquote>\n

Creating the new boot image<\/h2>\n

We first want to extract the ramdisk from that boot image. There are various tools to do so, but for convenience, I took unbootimg<\/a>, on github, and modified it slightly to seemlessly support the page size on the Nexus S. For convenience as well, we'll use mkbootimg<\/code> even if fastboot<\/code> is able to create boot images.<\/p>\n

Building unbootimg<\/code>, as well as the other tools rely on the Android build system, but since I didn't want to go through setting it up, I figured a minimalistic way to build the tools: <\/p>\n

$ git clone https:\/\/github.com\/glandium\/unbootimg.git
\n$ git clone git:\/\/git.linaro.org\/android\/platform\/system\/core.git<\/code><\/p><\/blockquote>\n

The latter is a clone of git:\/\/android.git.kernel.org\/platform\/system\/core.git<\/code>, which is down at the moment.<\/p>\n

$ gcc -o unbootimg\/unbootimg unbootimg\/unbootimg.c core\/libmincrypt\/sha.c -Icore\/include -Icore\/mkbootimg
\n$ gcc -o mkbootimg core\/mkbootimg\/mkbootimg.c core\/libmincrypt\/sha.c -Icore\/include
\n$ gcc -o fastboot core\/fastboot\/{protocol,engine,bootimg,fastboot,usb_linux,util_linux}.c core\/libzipfile\/{centraldir,zipfile}.c -Icore\/mkbootimg -Icore\/include -lz<\/code><\/p><\/blockquote>\n

Once the tools are built, we can extract the various data from the boot image:<\/p>\n

$ unbootimg\/unbootimg boot.img
\nsection sizes incorrect
\nkernel 1000 2b1b84
\nramdisk 2b3000 22d55
\nsecond 2d6000 0
\ntotal 2d6000 800000
\n...but we can still continue<\/code><\/p><\/blockquote>\n

Don't worry about the error messages about incorrect section sizes if it tells you \"we can still continue\". The unbootimg<\/code> program creates three files:<\/p>\n