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 .
Yesterday, I uploaded NBD 2.9.24-1 to Debian. The big new feature in
that release is that it now has an 'includedir' global configuration
variable, with which it supports a conf.d-style directory. This feature
was implemented by request of Vagrant Cascadian, of LTSP fame.
Only it didn't
build on kFreeBSD. The reason? The particular test that I added for
that new feature failed.
It turned out to be a simple bug in the code, which just didn't
trigger on Linux but which was a bug none the less. I hadn't noticed,
since my main development machine runs Linux; this is why I added a test
suite to the code.
Bug fixed, new package is in incoming. Whee.
A summary of my FusionForge-ish activities this month:
Session reuse is one of the most important mechanism to
To avoid a full 
Two mechanisms can be used to accomplish an abbreviated handshake:
It is difficult to get extensive results this way since you need to
install a lot of browsers to get something valuable. Surprisingly,
Android 2.3.4 browser (as shipped by Cyanogen Mod) does not support
any session resume.
Another way to check if a browser supports session resume is to use a
sniffer and to spot Client Hello messages. If a client tries to
resume a session, it will use an appropriate session identifier or
send a ticket. A simple 
The program will try to establish five consecutive 
There's something brewing, moving in Jalisco (a state in Mexico's West, where our second largest city, Guadalajara, is located). And it seems we have an opportunity to participate, hopefully to be taken into account for the future.
Ten days ago, I was contacted by phone by the staff of 
quick overview over my RC bug activities during the last week:
Thanks to the tireless efforts of the
Every once in a while I try out latest Debian/sid 
Our friend Susan was going to be in Chicago for a conference, and as we hadn't
seen Chicago yet, and it was on the list of cities we wanted to visit, we made
the semi-spur of the moment decision to have a three day weekend there last
weekend.
We got the Virgin America red-eye flight from SFO, which left on Friday at
around 5pm, and got into Chicago at around 11:30pm, local time. Zoe didn't do
as well as she has previously, and didn't sleep very well on the flight
over, despite us getting lucky and scoring an empty seat between us on an
otherwise fairly full flight. I think she's getting too big to comfortably
sleep in the Ergo baby carrier (or isn't keen on sleeping vertically any
more).
We stayed at the 
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):
Hot on the heels of the 
The blog is back. We ve moved it to our new blog hosting (please