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 .
another weekly report about RC bugs I've fixed, this time mostly by applying
patches from ubuntu:
Just a quick note to remind everyone that the
Today, German politicians decided, that Germany be liable for up
to 211 billion Euros for the debts of other EU countries. Or, put
differently: the politicians put the money of the current and
future generations on the line for a country that lived way above
its capabilities for too many years.
When the EU was founded, it was explicitly stated that no
country needs ever be liable for any other. I understand that
politics is hard, and letting Greece (and others) fall down might
carry heavy, unforeseen consequences. Also, I understand that the
Greek people are mostly innocent in all this and that the fault
lies with their politicians and other corrupt entities in the
nation.
However, what s happening these days is beyond the
comprehensible.
If I were in a non-Germany EU country, I d rejoice and continue
making debts. It is likely that this won t be the last time that
our politicians cave in to pressure by other nations who have a
lesser understanding of budgeting and saving.
Since I am German, I can only shake my head, look to Berlin and
ask myself whether this is the final straw that broke the camel s
back. How the heck do the people over there ever want to regain the
trust of their people? Politics has become the game of pleasing
each other, who cares about the people? And the German politicians
are (once again, remember credit default swaps?) at the forefront
of this stupidity.
To me, there is only one solution to Greece s debts: make sure
that what happened can never happen again, and then cut the debts,
or slice them in half. Let the banks carry the weight, for it was
them who gave out the loans too liberally. And if this forces a
bank or two to default, let it happen, for fuck s sake. The
consequences might be dire, but they ll subside. And that s surely
better than trying to pretend that we can keep juggling this
heavily inflated financial system.
Instead, the executives, elected to carry the trust of the
people, are setting precedents for other countries to follow
Greece, for it is likely that they wil be bailed out. By us. That
is not the way to teach anyone the basics of economy: you can only
spend as much as you earn, without exceptions. Debts will only come
around to hurt you. I could puke.
NP: 
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 
Hope a few of my readers got it from the title of this blog post.
And maybe many others didn't. So let's talk about "Stop Making Sense".
You're warned: nothing to do with free software...or running, this
time. This is all about music.
Music from the 80's.
"Stop Making Sense" is indeed, in my opinion, one of the best achieved
musical movie. It is simple: it features a gig by the Talking Heads,
back in 1983, when this band was among the most innovative ones that
ever appeared in the late 70's.
And I finally managed to take time to actually buy the DVD and see it
again as I didn't see it since 1985.
For many people, Talking Heads is the incredible person that's David
Byrne. That's certainly true for some parts (and this is what lead to
their split in 1991), but the movie really gives credit to all members
of the band, either the "regular" ones (Tina Weymouth, Chris Frantz,
Jerry Harrison) or the tour musicians (Bernie Worrell, Alex Weir,
Steven Scales, Lynn Mabry, Edna Holt).
The construction of the movie is simple: it just starts with Byrne
bringing a music box on an empty stage, with his acoustic guitar and
playing an incredible tense "Psycho Killer" (there are so many
different version of that mythical piece but this one is among the
best). Then Tina joins for a not-so-often played "Heaven" and brings
her so inimitable bass line (I count Tina among my very favourite bass
player, immediately after Tony Levin). At the end of the piece, the
crew quietly brings a full drum set, then Chris Frantz joins, smiling
as ever, and the rhythm increases with "Thank you for sending me an
angel".
Then Jerry Harrison joins, to make the original Heads line-up for a
really funky "Found a Job", where Jerry shows that he was THE Heads
lead guitar (and Tina is still keeping the foundations so strong).
Continuing the increasing tension, the rest of the musicians join for
Slippery People, then Burning Down the House ("Who's got a
match?"). All this culmminates in a crazy joggin on stage during "Life
During Wartime" and Byrne performing incredible and stellar movements
on stage. THis one surely makes the band entirely exhausted. How can
they survive this?
The few next songs are a little bit less stunning (oh, well, "Making
Flippy Floppy" still features a dream bass line)...until
a really special "Once in a Lifetime" that...has just to be seen (SAME
AS IT EVER WAS), then
a break
where....the Tom Tom Club (namely Chris, Tina and the rest of the
band) perform a giant "Genius of Love", so funky.
All this is indeed meant for Byrne to prepare for his top appearance,
in "Girlfriend is Better", in a giant suit, that makes his head over
his long neck yet more...strange. This leads to a crazy "Take me to
the River" which has always been the top of the Heads shows during the
80's and a tireless encore on "Crosseyed and Painless".
The movie ends up and you nearly never had a breath. So, yes, if you
think you enjoy the Heads music and have never seen that movie, just
try doing it once. That's how music was in the 80's..and, doh, these
folks were so good! By the way, all parts of the movie can be seen on
YouTube in case you just want to see what *I* enjoy.
Ah, and yes I share the love of the Heads with Danese "we never meet
often enough" Cooper, by the
way. We once made a promise ourselves to sing Psycho Killer in karaoke
if we're happy (and drunk) enough to meet again before we're too old for
this..:-).
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 
Every once in a while I try out latest Debian/sid 
Fixing the Sandbrige MacBook Air display initialization
We left our hero with Debian installed on the MacBook Air, but with
the display getting scrambled as soon as the i915 driver loaded.
As was reported to Matthew, the problem is as simple as a lack of
the right mode for the eDP panel in the machine. This mode is supposed
to come from the panel EDID data, but for some reason the driver
wasn t able to query the EDID data, and so it decided to try some
random panel timings it dug out of the VBT tables, which are generally
supposed to be used by LVDS panels. Apple helpfully stuck valid data
there, but for some other panel one that is 1280x800 pixels instead
of the 1366x768 pixel panel in the MacBook Air.
I heard rumors that some machines would get a black screen when the
i915 driver loaded. I was fortunate my machine simply displayed a
1366x768 subset of the programmed 1280x800 mode. A bit of garbage on
the right side, and a few scanlines missing at the bottom. Quite
workable, especially after I ran fbset -yres 768 to keep the console
in the visible portion of the screen.
DDC failure
Looking through the kernel logs, the Intel driver tries to access the
EDID data and times out, as if DDC is just completely broken. This is
rather unexpected; the eDP spec says that the panel is required to
support DDC and provide EDID. Now, we ve seen a lot of panels which
don t quite live up to the rigorous eDP specifications, but it s a bit
surprising from Apple, who generally do VESA stuff pretty well.
We ve heard reports about panels reporting invalid EDID data, or EDID
data which didn t actually match the panel (causing us to prefer the
VBT data on LVDS machines). But I ve not heard of an eDP panel which
didn t have anything hanging off of the DDC channel.
But X works fine?
During early debugging, I happened to start X up. Much to my surprise,
X came up at the native 1366x768 mode. Digging through the kernel logs
after that, I discovered that EDID was successfully fetched from the
eDP panel while X started up.
At this point, I knew it was all downhill the EDID data was
present, it just wasn t getting picked up during the early part of the
driver initialization when the console mode is initialized.
eDP power management
The CPU is given complete control over the power management of the eDP
panel; sequencing through various power states and waiting appropriate
amounts of time when things change. Given the goal of keeping power
usage as low as possible, this makes a huge amount of sense.
The eDP spec is quite clear though, without power, the panel will not
respond to anything over the aux channel, and that includes EDID
data. The eDP panel power hardware in the Sandybridge chip has a special
mode for dealing with this requirement. If the panel is not displaying
data, you can supply power for the aux channel stuff by setting a
magic bit in the panel power registers.
When initializing the frame buffer, the kernel driver turns off the
panel completely so that it has all of the hardware in a known state
(yeah, this is not optimal, but that s another bug). When X started,
the panel was already running with the console mode.
Given the difference between these two states EDID querying with
the panel off failed, while EDID querying with the panel on worked, it
seemed pretty clear that the panel power wasn t getting managed
correctly. So, it seemed pretty clear that the magic power the panel
bit wasn t getting turned on at the right times.
Getting the power turned on.
I stuck a check inside all of the aux channel communication functions
to see where things were broken. This pointed out several places
missing the panel power calls. This wasn t quite sufficient to get
EDID data flowing. The remaining problem was that the code wasn t
waiting long enough after turning the panel power on before starting
the aux channel communication. A few msleep calls and huzzah! EDID at
boot time and the console had the right mode.
Making it faster
However, it turns out that the driver does this a lot, and the msleeps
required were fairly long the eDP panel wants a 500ms delay from
turning the panel power off before you can turn it back on.
I fix this by simply delaying the panel power off until things were
idle for a long time. Now mode setting goes zipping through, and a
few seconds later, the bit to force panel power on gets turned off.
Getting these bits for yourself
I ve pushed out the code to my (temporary) kernel repository
git://people.freedesktop.org/~keithp/linux
in the fix-edp-vdd-power branch. I d love to hear if you ve tried this
on either a MacBook Air or any other eDP machine from Ironlake onwards.
I used to know guys who would take old computer hardware out in the desert
and shoot it up. I never went, and I've never gratuitously destroyed
a computer in 2 decades of working with the things. Until yesterday when
I picked one up by the monitor and introduced it to the floor.
My regret isn't that I violently destroyed a computer, but that it was my
Mom's computer, and I did it right in front of her, and without even a
story-worthy reason, just out of garden variety frustration. And perhaps
there's some regret that I was actually unsucessful in destroying anything
other than the monitor and some speakers. The computer was salvaged, and my
mom has a new monitor and a working system again.
Sorry Mom & Maggie. To make up for it, I'll humiliate myself with
this recording of "broke mom's computer blues", which will only be
available for a very limited time:
Is there a syscall to ask the system whether a file is sparse in a
particular region? I.e., if I say dd if=/dev/zero of=./foo seek=10
count=10, then I should get a "yes" for the first half of the file,
but a "no" for the second half.
Case in point: I need to write a test for the newly-implemented