TODO: spellcheck and check grammar.
This page might eventually replace the Kernel page.
This page 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 check the Distributions page instead or scroll down for the daily builds we make.
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.
The sources of the Openmoko Linux kernel live in a GIT repository.
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 might 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 you learn to use it you will find many ways to increase your productivity by using it. For completeness in this page we include the GIT commands that you need in order to build a working kernel.
If you are very new to git you might want to read good manuals 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 allows for different branches that developers use to speed up development. You might have noticed we have a few of them if you visited the web interface (http://git.openmoko.org/?p=kernel.git;a=summary).
The andy-tracking branch is the one where most of the action takes place these days.
If you just need the last version of the kernel you can download from the daily builds.
Pegged (TODO: Make clear what pegged means):
Building the andy-tracking branch
Those are the minimum survival commands:
$ git clone git://git.openmoko.org/git/kernel.git linux-2.6 $ cd linux-2.6 $ git-checkout --track -b andy-tracking origin/andy-tracking $ cp ./arch/arm/configs/gta02_moredrivers_defconfig .config
Before building this kernel you need install a Toolchain.
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... TODO: fill.
If you want to update the local copy of the repository so that you get the latest changes, you can type:
Before reporting that the new kernel does not build please first check for changes in the configuration file.
kernel building tips
If you are touching 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.
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.
Why does Openmoko cares about sending code upstream instead of (insert your task here)?
There are two approaches -- both of them doomed if you stick all your resources to them.
The first is not to care about upstream kernel and stick to an old kernel - even if upstream is where the people who will help us improve, maintain and support the code running in our devices are.
The second is to care way too much about upstream (too much purity) the point that we won't ship a temporal dirty hack that make users happy and able to better use their phones.
As many things in engineering we have to find a point in the middle that works well and we will try hard to.
Who's Andy and why is he sticking his name in the kernel?
He takes some credit and most the blame. It is an usual practice that in kernel development some branches are named after the person who is taking care of them. For instance he takes the work of making sure things still build when Linus and his friends update the upstream kernel and believe us: it is not as fun as it might sound.
Some issues might be very difficult because of lack of (correct) documentation from the hardware makers or because not many people are used to dealing with them. If you can help us with one of those issues it would be great.
TODO: make a list with important open tickets