View source for Kernel

From Openmoko

Jump to: navigation, search

You do not have permission to edit this page, for the following reasons:

  • The action you have requested is limited to users in the group: Administrators.
  • You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

You can view and copy the source of this page:

Templates used on this page:

Return to Kernel.

Personal tools

(Kernel related)

Things changed

This page will be updated soon. Those are the current Kernel plans.

Is this page meant for you?

This information is mostly useful for developers and power/curious users. If you are looking for a kernel to flash into your GTA01/GTA02 you might want to grab one from the daily builds (scroll down and you'll find it) or get one that ships with one of the Distributions. The good thing with daily builds is that the newest might be the better. The bad thing of daily builds might be that you can get a broken kernel. If you feel way too uncomfortable making decisions about which kernel to try first and you are not willing to spend the time finding out which one works for you, then this page is not meant for you and you should be looking for stable Distributions instead. The distributors make this easier for you. You might want to scroll down for the 'blessed' kernels in the daily builds.


Linux kernel developers from the community and Openmoko Linux kernel developers maintain a working kernel for the Freerunner (Also known as GTA02) and also for the Neo1973 (Aka GTA01).

Right now there is an ongoing effort to reduce the difference between current Linux 2.6 (mainline) and the kernel in the Openmoko repository and thanks to this work we can run the most recent released version of Linux 2.6.

Sister pages

  1. Kernel branches.


The sources of the Openmoko Linux kernel live in a GIT repository. With the WEB interface you can peek at the contents of the repository:;a=summary

GIT is a fast version control system suited for the workflow that many kernel developers use. It is specially useful when you need to send patches for a project (who in turn might need to send them upstream). This is an over-simplification but it gives you the idea in case you did not know.

GIT might seem complicated at first but once it's usage is learned, you will find many ways for it to increase your productivity. For completeness in this page we include the GIT commands which you need in order to build a working kernel.

If you are very new to GIT you might want to read the good manuals that already available.

If you would like to contribute code we also have a page with Hints_on_using_GIT_and_stgit where we all hope to share some cool tips and tricks that can help you. You do not need to learn stgit in order to send patches to the Kernel Mailing List but we have to tell you that once you know git, stgit will make you more productive when you need to send a few patch at once (patchsets).


GIT allow developers to use different branches that help speed up development (and even make it possible). You might have noticed we have a few branches if already you visited the WEB interface (;a=summary).

The andy-tracking branch is the one where most of the action takes place these days.

We have branch policies that explain what each branch is for.

Daily builds

Automatic revisions

Think of a robot that takes whatever kernels are the most recent in GIT, builds them for you and then makes them available here:

Blessed revisions

Another robot but this one only builds the versions picked by our friendly OpenEmbedded developers. Download from:

If you understand OpenEmbedded you will get this: Those versions are tied to a specific GIT revision through conf/distro/include/

Building the 2.6.32 branch

Those are the minimum survival commands.

Get kernel sources from git repository:

$ git clone git:// linux-2.6
$ cd linux-2.6

Next switch to the branch:

$ git checkout --track -b om-gta02-2.6.32 origin/om-gta02-2.6.32

Copy the config for the gta02 to be used:

$ cp arch/arm/configs/gta02_drm_defconfig .config

Now you need a few additional patches for the kernel. You can merge gdrm-2.6.32 or gdrm-for-merging branch directly from Thomas White (;a=summary) or all patches used in SHR kernels ( Gitorious branch is usually rebased on top of origin/om-gta02-2.6.32 when we change SRCREV in recipe (

$ git remote add gitorious git://
$ git remote update
$ git merge gitorious/om-gta02-2.6.32

Now before building this kernel you need to install a cross compiler toolchain like Toolchain from openmoko. Alternatively, feel free to use emdebian toolchain for the deb based systems, or crossdev on gentoo.

Also set two variables for cross compiling (second one is om toolchain specific):

$ export ARCH="arm"
$ export CROSS_COMPILE="arm-angstrom-linux-gnueabi-"

Now you can configure the kernel:

$ make menuconfig


$ make xconfig

To compile the kernel you just do:

$ mkdir GTA02 
$ make
$ make modules_install INSTALL_MOD_PATH=GTA02

The new compiled kernel is now "arch/arm/boot/zImage" and the modules are within the "GTA02" directory. Now you just have to copy the "zImage" file to "/boot/uImage" and also copy the modules from within "GTA02" to the same directory structure on the freerunner (/lib/modules/2.6.32).

Building the andy-tracking branch (obsolete)

Those are the minimum survival commands.

Get kernel sources from

$ wget
$ tar xf -C linux-2.6
$ cd linux-2.6
$ git pull

or clone from a git repository:

$ git clone git:// linux-2.6
$ cd linux-2.6

Next switch to the branch:

$ git checkout --track -b andy-tracking origin/andy-tracking
$ mkdir GTA02 
$ cp ./arch/arm/configs/gta02_moredrivers_defconfig GTA02/.config

Before building this kernel you need install a Toolchain.

$ ./build GTA02

Once the script finishes you will get two files. The first is uImage-GTA02.bin and a second file with a longer name but same contents, for instance uImage-moredrivers-GTA02_andy-tracking_c16287685cb59f91.bin. Please use the second file if you publish your kernel in some server or if you talk about it in public (specially in bugs reports) because it will allow others to know what kernel you were trying (in case you don't have local changes).

In order to build the modules you can:

$ ./build GTA02 dummy

This will create a file called modules-GTA02_andy-tracking-<git hash>.tar.gz. The contents of this file have to be copied to /lib/firmaware and /lib/modules and one way to do it is untarring the file on the root directory of the device.

If you want to update the local copy of the repository so that you get the latest changes, you can type:

$ git pull

Before reporting that the new kernel does not build please first check for changes in the configuration file provided by Openmoko.

kernel building tips

If you are modifying Linux kernel code and building it quite often you really want to be using ccache. It will save you a lot of time.

TODO: submit a patch for the build script that makes ccache use easier. Note: There is a patch being reviewed.

Old troubleshooting information

If it fails with error message "arm-angstrom-linux-gnueabi-ld: unrecognized option '-Wl,-rpath-link,/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/lib'" until /usr/local/openmoko/arm/setup-env is modified. LDFLAGS should be changed from:

export LDFLAGS="-L${OMTOOL_DIR}/arm/arm-angstrom-linux-gnueabi/lib -Wl,-rpath-link,${OMTOOL_DIR}/arm/arm-angstrom-linux-gnueabi/lib -Wl,-O1"


export LDFLAGS="-L${OMTOOL_DIR}/arm/arm-angstrom-linux-gnueabi/lib -rpath-link ${OMTOOL_DIR}/arm/arm-angstrom-linux-gnueabi/lib -O1"

I also had to change the 'build' script to hardcode the path to the compiler.


The development resources Openmoko offers are:

We appreciate your contributions. Check the Open Issues at the end of this page to check where we need more help.

If in doubt ask in the mailing list.


"Verifying Checksum ... Bad Data CRC" with U-boot

U-boot might not be reading the whole kernel. To fix this you need to:

setenv bootcmd 'setenv bootargs ${bootargs_base} ${mtdparts}; nand read.e 0x32000000 kernel 0x300000; bootm 0x32000000'

Could someone please explain this more in detail for example: Login your freerunner with root@

  1. home_pc > root@
  2. freerunner > setenv ...

You might also move to Qi.

What happened to usb0?

Now you will get eth<n> instead of usb0. Check:

Who's Andy and why is he sticking his name in the kernel?

He created the branch and maintained it for a while. It is an usual practice that in kernel development some branches are named after the person who is taking care of them

Check Kernel_branches if you care about the details.

Kernel developers are not polite! They do not even care to say "Hello" when they reply to my emails!

The long version is here: Kernel-developers-are-not-polite.

To the point:

All these opensource programmers are nicer in person (if you don't interrupt them while they are programming). On the internet they might appear to be very rude, but in person things are very different specially over lunch or when sharing a beer.

They just tend to write very short text because they have to read and write a lot every day.

Why does Openmoko cares about sending code upstream instead of (insert your task here)?

There are two very different approaches and both of them would be doomed if we committed all our resources to only one of them.

The first approach is not to care about upstream kernel development efforts and stick to an old kernel while struggling to make it work, ignoring the fact that it is upstream where the people who want to help us improve, maintain and support the code running in our devices, hang out.

The second is to care way too much about upstream to the point that we are not willing to ship a temporary dirty hack that makes users happy and able to better use their phones. We cannot afford that kind of purity.

As with many things in engineering (and life), we have to find a point in the middle that works well - we will try hard to do it.

Known issues

Sysfs paths

Unfortunately we had to update many sysfs paths (see GTA02_sysfs) and since we did it the kernel stopped working properly with some distributions. Unless the distribution is abandoned it will likely catch up with the newest kernel soon.

FSO developers realized that this problem could be prevented from from happening in the future and they decided to code a nice daemon called odeviced.

WSOD with u-boot

There is work in progress to fix this issue that does not happen with Qi. Latest kernel from andy-tracking.

Open Tickets

This report will show the bugs that are a priority for us now.

Please read this report if you wish to know what the current issues are.

If you can help us with one of those issues it would be a great way to help us move forward. If in doubt please write to the Openmoko Kernel Mailing List. Let us link some bugs here without overdoing it because trac is better than a normal wiki for this. If we have more than 10 bugs the following lists then we might be doing it wrong.

Easy bugs

Those are the bugs that active kernel developers believe can be fixed by new kernel programmers that might want to join us. Thus they are leaving them unfixed for some reasonable time while they work on the harder bugs.

TODO: list of bugs linking to trac.

Normal bugs

Those are the bugs that we have not fixed because they might be hard and/or because we have not found the time to fix them. They might end up being Easy Bugs or Evil bugs. We will use trac for them.

This is the complete report with all the bugs (some of them might be invalid).

Hard bugs

Those are the evil bugs that we haven't fixed either because:

  1. We do not know how to do it in reasonable time
  2. The hardware vendor does not want to release documentation or to fix firmware (some of them do that unfortunately / even breaking promises they made to Openmoko about making things easier for developers)
  3. More testing is needed (perhaps a hard-to-reproduce bug)

Here is the list: