How to build mainline Linux kernel for Xperia devices

This guide describes the basic steps to build the mainline kernel for an Xperia device.

1. Get the source code

The Linux kernel can be downloaded in various forms from https://www.kernel.org. Individual releases are made in tar.xz packages, but the preferred method of downloading the kernel is with the help of “git”.

To download Linus’ official kernel tree, execute the following command

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

This git contains Linus Torvalds’ master branch, where new code is being merged for the next upcoming release of the Linux kernel.

It is strongly recommended to build and test kernels from specific tags, for example to have a known version when reporting bugs. To have tags listed, execute the command:

git tag

To check out a specific version or tag, use git checkout. For example, to get the source code for Linux version 4.3, issue:

git checkout v4.3

Add the project “linux-next” to your Linux clone by executing:

git remote add linux-next git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
git fetch linux-next

The “linux-next” tree git project is important in the development flow of the Linux kernel, since this is where new code for the next future release is integration-tested – before it’s sent to Linus for integration in the main Linux branch. This is an important tree for contributors, but can also include some upcoming gems that you might find interesting

2. Install a cross compiler

To build the Linux kernel for ARM based devices we must install an ARM-compiler. Other guides here describe how to install the 4.8 version, but this is blacklisted in modern kernel versions, due to a serious compiler bug.

AOSP also provides version 4.7 of gcc, so we can use this for our compilation. Download this compiler from AOSP, by executing:

git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.7

3. Build a kernel image

With the mainline kernel downloaded, we can configure and build our kernel image. This is done with the help of make, but as we’re cross-compiling (building a kernel for ARM on a PC), we need to specify two flags:

export CROSS_COMPILE="$HOME/arm-eabi-4.7/bin/arm-eabi-"
export ARCH=arm

This will make the kernel build system utilize our specific ARM compiler we downloaded and will make sure we’re building from the architecture living under “arch/arm” in the kernel source tree.

A good configuration file to start our kernel work is the “qcom_defconfig”, select this by executing:

make qcom_defconfig

This gives a good set of basic options for Qualcomm-based devices. Further options can be selected by executing:

make menuconfig

After selecting your configuration options (or using the defaults from “qcom_defconfig”), the kernel can be compiled by simply issuing:

make

This will after some time output the file arch/arm/boot/zImage and a set of “dtb” files under arch/arm/boot/dts.

4. Package and flash your image

Once you have the zImage, a Device Tree blob and a ramdisk (Android or Linux ramdisk is not part of this build guide), you need to package those as an Android boot image.

Build “mkbootimg” from AOSP by issuing:

make mkbootimg

With “mkbootimg” available we can piece together the “boot.img”, for example for Honami (Xperia Z1), by executing:

cat arch/arm/boot/zImage \
arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dtb > \
arch/arm/boot/zImage-dtbmkbootimg \
--kernel arch/arm/boot/zImage-dtb \
--cmdline "clk_ignore_unused console=ttyMSM0,115200,n8" \
--ramdisk rootfs.cpio \
--base 0x00000000 \
--pagesize 2048 \
--ramdisk_offset 0x02000000 \
--tags_offset 0x01e00000 \
--output boot.img \
--board honami

The same zImage is to be used for all devices, but pick the dtb that matches the product you’re working on.

Flash the boot image by executing:

fastboot flash boot boot.img
fastboot reboot

Contributing to the mainline kernel

The Linux kernel contribution process is mainly based on series of patch files sent via email to mailing lists for each individual area of the code. A large collection of these mailing lists can be found at http://vger.kernel.org/vger-lists.html.

The first step in making contributions is to subscribe to one or more of the mailing lists, read other people’s patches, spend time to get a feel for how others do this and start contributing by commenting on other people’s work. This gives you a feeling of what’s expected by the community and is a great way to contribute! Note that all emails should be plain text and you should never top-post.

When you feel comfortable to send your first patch the steps are as follow:

Read Documentation/SubmittingPatches
Test the patch on a recent tag from Linus tree
Preferably test the patch against a recent linux-next tag (to make sure it’s still applicable)
Use “git format-patch” to prepare the patch
Run “./scripts/checkpatch.pl” on the patch files and correct any reported issues
Use “./scripts/get_maintainer.pl” on the patch files to extract information about what recipients you should have for your patch. Add these by editing the patch files and adding “To: “ and “Cc: “ fields among the headers.
Use “git send-email” for sending the patches to the various recipients (hint, use –dry-run to verify the recipients list)
Make sure to answer any feedback promptly and most importantly, listen to the feedback.