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 that comes with the kernel source). In
Julian Seward 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.
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.
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.
Preparing a build environment
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:
$ wget http://dl.google.com/android/ndk/android-ndk-r6b-linux-x86.tar.bz2
$ tar -jxf android-ndk-r6b-linux-x86.tar.bz2
$ export ARCH=arm
$ export CROSS_COMPILE=$(pwd)/android-ndk-r6b/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-
For the latter, you need to use a directory path containing prefixed versions (such as
arm-eabi-gcc or
arm-linux-androideabi-gcc), and include the prefix, but not gcc .
You will also need the
adb tool coming from the Android SDK. You can install it this way:
$ wget http://dl.google.com/android/android-sdk_r12-linux_x86.tgz
$ tar -zxf android-sdk_r12-linux_x86.tgz
$ android-sdk-linux_x86/tools/android update sdk -u -t platform-tool
$ export PATH=$PATH:$(pwd)/android-sdk-linux_x86/platform-tools
Building the kernel
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 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.
$ git clone -b devrom-2.6.35 https://github.com/cgjones/samsung-android-kernel
$ cd samsung-android-kernel
You can then either start from the default kernel configuration:
$ make herring_defconfig
or use the one from the B2G project, which enables interesting features such as oprofile:
$ wget -O .config https://raw.github.com/cgjones/B2G/master/config/kernel-nexuss4g
From then, you can use the
make menuconfig or similar commands to further configure your kernel.
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.
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.
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.
To use that trick, you first need to know what kernel version is running on your device.
Settings > About phone > Kernel version will give you that information on the device itself. You can also retrieve that information with the following command:
$ adb shell cat /proc/version
With my stock ROM, this looks like the following:
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
In the
About phone information, it looks like:
2.6.35.7-ge382d80
android-build@apa28
The important part above is
-ge382d80, and that is what we will be using in our kernel build. Make sure the part preceding
-ge382d80 does match the output of the following command:
$ make kernelversion
The trick is to write that
-ge382d80 in a
.scmversion file in the kernel source tree (obviously, you need to replace
-ge382d80 with whatever your device has):
$ echo -ge382d80 > .scmversion
The kernel can now be built:
$ make -j$(($(grep -c processor /proc/cpuinfo) * 3 / 2))
The
-j part is the general rule I use when choosing the number of parallel processes
make can use at the same time. You can pick whatever suits you better.
Before going further, we need to get back to the main directory:
$ cd ..
Getting the current boot image
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:
$ adb shell cat /proc/mtd awk -F'[:"]' '$3 == "boot" print $1 '
The above command will print the mtd device name corresponding to the boot partition. On the Nexus S, this should be
mtd2.
$ adb shell
$ su
# dd if=/dev/mtd/mtd2 of=/sdcard/boot.img bs=4096
2048+0 records in
2048+0 records out
8388608 bytes transferred in x.xxx secs (xxxxxxxx bytes/sec)
# exit
$ exit
In the above command sequence, replace
mtd2 with whatever the previous command did output for you. Now, you can retrieve the boot image:
$ adb pull /sdcard/boot.img
Creating the new boot image
We first want to extract the ramdisk from that boot image. There are various tools to do so, but for convenience, I took
unbootimg, on github, and modified it slightly to seemlessly support the page size on the Nexus S. For convenience as well, we ll use
mkbootimg even if
fastboot is able to create boot images.
Building
unbootimg, 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:
$ git clone https://github.com/glandium/unbootimg.git
$ git clone git://git.linaro.org/android/platform/system/core.git
The latter is a clone of
git://android.git.kernel.org/platform/system/core.git, which is down at the moment.
$ gcc -o unbootimg/unbootimg unbootimg/unbootimg.c core/libmincrypt/sha.c -Icore/include -Icore/mkbootimg
$ gcc -o mkbootimg core/mkbootimg/mkbootimg.c core/libmincrypt/sha.c -Icore/include
$ gcc -o fastboot core/fastboot/ protocol,engine,bootimg,fastboot,usb_linux,util_linux .c core/libzipfile/ centraldir,zipfile .c -Icore/mkbootimg -Icore/include -lz
Once the tools are built, we can extract the various data from the boot image:
$ unbootimg/unbootimg boot.img
section sizes incorrect
kernel 1000 2b1b84
ramdisk 2b3000 22d55
second 2d6000 0
total 2d6000 800000
...but we can still continue
Don t worry about the error messages about incorrect section sizes if it tells you we can still continue . The
unbootimg program creates three files:
boot.img-mk, containing the mkbootimg options required to produce a working boot image,boot.img-kernel, containing the kernel image,boot.img-ramdisk.cpio.gz, containing the gzipped ramdisk, which we will reuse as-is.
All that is left to do is to generate the new boot image:
$ eval ./mkbootimg $(sed s,boot.img-kernel,samsung-android-kernel/arch/arm/boot/zImage, boot.img-mk)
Booting the image
There are two ways you can use the resulting boot image: one-time boot or flash. If you want to go for the latter, it is best to actually do both, starting with the one-time boot, to be sure you won t be leaving your phone useless (though recovery is there to the rescue, but is not covered here).
First, you need to get your device in the fastboot mode, a.k.a. boot-loader:
$ adb reboot bootloader
Alternatively, you can power it off, and power it back on while pressing the volume up button.
Once you see the boot-loader screen, you can test the boot image with a one-time boot:
$ ./fastboot boot boot.img
downloading 'boot.img'...
OKAY [ 0.xxxs]
booting...
OKAY [ 0.xxxs]
finished. total time: 0.xxxs
As a side note, if
fastboot sits waiting for device , it either means your device is not in fastboot mode (or is not connected), or that you have permissions issues on the corresponding USB device in /dev.
Your device should now be starting up, and eventually be usable under your brand new kernel (and WiFi should be working, too). Congratulations.
If you want to use that kernel permanently, you can now flash it after going back in the bootloader:
$ adb reboot bootloader
$ ./fastboot flash boot boot.img
sending 'boot' (2904 KB)...
OKAY [ 0.xxxs]
writing 'boot'...
OKAY [ 0.xxxs]
finished. total time: 0.xxxs
$ ./fastboot reboot
Voil .
Matthias Klose, the tireless force behind the Debian / Ubuntu gcc, python,
and what have you packages, sent me a minimal patch to let littler build when
the 
In this screencast, I implement a new feature in 
As people on 
It's quite some time since I haven't nagged fellow translators about
Debian Installer translation status.
D-I development, these days, has ups and down. The team is quite loose
and activity has not been that high after Debconf. Still, enough
changes took place since squeeze for localization completeness to drop
to about 93% for languages that were previously 100% when we released
squeeze.
So, this week, I felt the need to send a call for translation
updates. As usual, this woke up several translators and a bunch of
updates were committed. I suspect that more will come over the next
days.
Sadly, as usual, the call for translation lead to several translators
sending me their updates directly instead of committing them to
SVN. This is unfortunately something I probably have to live with even
though I keep explaining and documenting how to do things. I suspect
that nobody really imagines the hassle it is when you have to check
and commit files and files and files and files.....
Any, here's the status for D-I level 1 (core D-I files):
Our 
It took me longer than expected!
Continuing my 
I love to use 
Hot on the heels of the 
For the longest time, I went by the nick "Yoe" when I went on IRC.
When I chose this nick for myself, I was sixteen, and the Internet
computer at the local public library had an IRC client installed that I
tried out. Obviously, my first choice of nick -- "wouter", a fairly
common first name in Dutch-speaking regions -- was already chosen, so I
had to come up with something else. If I'd realized that I'd still be
using this nick today, seventeen years later, I might have
chosen that nick with a bit more care...
Over the years, some people have asked me what the nickname meant,
where it came from. I've never really told anyone the entire story,
mainly because it was somewhat embarrasing. But hey, we've all been 16,
right?
In the early nineties, there was a show on TV called "Het huis van
wantrouwen". On this show, they had a running joke involving a short
clip of Belgian members of parliament informally voting on a subject by
raising hands (literally); the joke was that this clip was dubbed with a
bunch of people saying "Yoe, de manne" -- which is dutch for something
along the lines of "Yo, guys".
As a young geeky teenager, I found this joke way more funny than it
actually was; and as such, a few years later, during one of the more
weird episodes of my life, I started pranking people by sneaking up to
them from behind and shouting "Yoe, de manne" right next to their ears.
I even managed to do this to one of our teachers who was walking on the
playground.
This was just around the time when I first tried out this "IRC"
thing. It didn't take me too long to realize I was the only
person who thought this "joke" was funny; but somehow the nick stuck,
and here we are, 17 years later, I'm still using it.
Or, well, I was. As of today, if you want to catch me on
IRC, you'll find me going by "wouter" instead of "Yoe". Of course
someone had registered that nick several years ago, but then he hadn't
been using it in years, and so after a quick request to the
OFTC admins they made it available for me.
Whee.