<?xml version="1.0"?>
<?xml-stylesheet type="text/css" href="http://wiki.openmoko.org/skins/common/feed.css?303"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
		<id>http://wiki.openmoko.org/api.php?action=feedcontributions&amp;user=Arhuaco&amp;feedformat=atom</id>
		<title>Openmoko - User contributions [en]</title>
		<link rel="self" type="application/atom+xml" href="http://wiki.openmoko.org/api.php?action=feedcontributions&amp;user=Arhuaco&amp;feedformat=atom"/>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Special:Contributions/Arhuaco"/>
		<updated>2013-05-21T12:34:35Z</updated>
		<subtitle>User contributions</subtitle>
		<generator>MediaWiki 1.19.6</generator>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel</id>
		<title>Kernel</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel"/>
				<updated>2009-09-22T21:07:21Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: Add Bad Data CRC U-boot FAQ.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Kernel}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Things changed ==&lt;br /&gt;
&lt;br /&gt;
This page will be updated soon. Those are the current [[Kernel_Plans|Kernel plans]].&lt;br /&gt;
&lt;br /&gt;
== Is this page meant for you? ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Sister pages ===&lt;br /&gt;
&lt;br /&gt;
# [[Kernel branches]].&lt;br /&gt;
&lt;br /&gt;
== Sources ==&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
&lt;br /&gt;
http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
&lt;br /&gt;
[http://git-scm.com 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
If you are very new to GIT you might want to read [http://git.or.cz/course/ the good manuals that already available].&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
=== Branches ===&lt;br /&gt;
&lt;br /&gt;
GIT allow developers to use different [[Kernel_branches|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 (http://git.openmoko.org/?p=kernel.git;a=summary).&lt;br /&gt;
&lt;br /&gt;
The ''andy-tracking'' branch is the one where most of the action takes place these days. &lt;br /&gt;
&lt;br /&gt;
We have [[Kernel_branches|branch policies]] that explain what each branch is for.&lt;br /&gt;
&lt;br /&gt;
=== Daily builds ===&lt;br /&gt;
&lt;br /&gt;
==== Automatic revisions ====&lt;br /&gt;
&lt;br /&gt;
Think of a robot that takes whatever kernels are the most recent in GIT, builds them for you and then makes them available here:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/experimental/&lt;br /&gt;
&lt;br /&gt;
==== Blessed revisions ====&lt;br /&gt;
&lt;br /&gt;
Another robot but this one only builds the versions picked by our friendly [[OpenEmbedded]] developers. Download from:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/unstable/&lt;br /&gt;
&lt;br /&gt;
If you understand OpenEmbedded you will get this: Those versions are tied to a specific GIT revision through conf/distro/include/sane-srcrevs.bb.&lt;br /&gt;
&lt;br /&gt;
=== Building the andy-tracking branch ===&lt;br /&gt;
&lt;br /&gt;
Those are the minimum survival commands:&lt;br /&gt;
&lt;br /&gt;
 $ git clone git://git.openmoko.org/git/kernel.git linux-2.6&lt;br /&gt;
 $ cd linux-2.6&lt;br /&gt;
 $ git-checkout --track -b andy-tracking origin/andy-tracking&lt;br /&gt;
 $ mkdir GTA02 &lt;br /&gt;
 $ cp ./arch/arm/configs/gta02_moredrivers_defconfig GTA02/.config&lt;br /&gt;
&lt;br /&gt;
Before building this kernel you need install a [http://wiki.openmoko.org/wiki/Toolchain#Downloading_and_installing Toolchain].&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
In order to build the modules you can:&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02 dummy&lt;br /&gt;
&lt;br /&gt;
This will create a file called modules-GTA02_andy-tracking-&amp;lt;git hash&amp;gt;.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.&lt;br /&gt;
&lt;br /&gt;
If you want to update the local copy of the repository so that you get the latest changes, you can type:&lt;br /&gt;
&lt;br /&gt;
 $ git-pull&lt;br /&gt;
&lt;br /&gt;
Before reporting that the new kernel does not build please first check for changes in the configuration file provided by Openmoko.&lt;br /&gt;
&lt;br /&gt;
=== kernel building tips ===&lt;br /&gt;
&lt;br /&gt;
If you are modifying Linux kernel code and building it quite often you really want to be using [http://ccache.samba.org ccache]. It will save you a lot of time.&lt;br /&gt;
&lt;br /&gt;
TODO: submit a patch for the build script that makes ccache use easier. '''Note''': There is a [http://lists.openmoko.org/pipermail/openmoko-kernel/2009-March/009139.html patch being reviewed].&lt;br /&gt;
&lt;br /&gt;
== Contributing ==&lt;br /&gt;
&lt;br /&gt;
The development resources Openmoko offers are:&lt;br /&gt;
&lt;br /&gt;
* Git repository: http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
* [http://lists.openmoko.org/mailman/listinfo/openmoko-kernel Mailing list] ([http://lists.openmoko.org/pipermail/openmoko-kernel/ Online Archive])&lt;br /&gt;
&lt;br /&gt;
We appreciate your contributions. Check the Open Issues at the end of this page to check where we need more help.&lt;br /&gt;
&lt;br /&gt;
If in doubt ask in the mailing list.&lt;br /&gt;
&lt;br /&gt;
== FAQ ==&lt;br /&gt;
&lt;br /&gt;
=== &amp;quot;Verifying Checksum ... Bad Data CRC&amp;quot; with U-boot ===&lt;br /&gt;
&lt;br /&gt;
U-boot might not be reading the whole kernel. To fix this you need to:&lt;br /&gt;
&lt;br /&gt;
 setenv bootcmd setenv bootargs \${bootargs_base} \${mtdparts}\; nand read.e 0x32000000 kernel 0x300000\; bootm 0x32000000&lt;br /&gt;
 saveenv&lt;br /&gt;
&lt;br /&gt;
You might also move to [[Qi]].&lt;br /&gt;
&lt;br /&gt;
=== What happened to usb0? ===&lt;br /&gt;
&lt;br /&gt;
Now you will get eth&amp;lt;n&amp;gt; instead of usb0. Check:&lt;br /&gt;
&lt;br /&gt;
http://lists.openmoko.org/pipermail/devel/2009-April/005384.html&lt;br /&gt;
&lt;br /&gt;
=== Who's Andy and why is he sticking his name in the kernel? ===&lt;br /&gt;
&lt;br /&gt;
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&lt;br /&gt;
&lt;br /&gt;
Check [[Kernel_branches]] if you care about the details.&lt;br /&gt;
&lt;br /&gt;
=== Kernel developers are not polite! They do not even care to say &amp;quot;Hello&amp;quot; when they reply to my emails! ===&lt;br /&gt;
&lt;br /&gt;
The long version is here: [[Kernel-developers-are-not-polite]].&lt;br /&gt;
&lt;br /&gt;
To the point:&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
They just tend to write very short text because they have to read and write a lot every day.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Why does Openmoko cares about sending code upstream instead of (insert your task here)? ===&lt;br /&gt;
&lt;br /&gt;
There are two very different approaches and both of them would be doomed if we committed all our resources to only one of them.&lt;br /&gt;
&lt;br /&gt;
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 [http://www.kernel.org upstream] where the people who want to help us improve, maintain and support the code running in our devices, hang out.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
== Known issues ==&lt;br /&gt;
&lt;br /&gt;
=== Sysfs paths ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[FSO]] developers realized that this problem could be prevented from from happening in the future and they decided to code a nice daemon called [http://www.freesmartphone.org/index.php/Implementations/OpenDeviceDaemon odeviced].&lt;br /&gt;
&lt;br /&gt;
=== WSOD with u-boot ===&lt;br /&gt;
&lt;br /&gt;
There is work in progress to fix this issue that does not happen with Qi. Latest kernel from andy-tracking.&lt;br /&gt;
&lt;br /&gt;
== Open Tickets ==&lt;br /&gt;
&lt;br /&gt;
'''This&lt;br /&gt;
[http://docs.openmoko.org/trac/query?status=in_testing&amp;amp;status=reopened&amp;amp;status=assigned&amp;amp;status=new&amp;amp;status=accepted&amp;amp;group=status&amp;amp;milestone=stable-kernel-2009.1 report] will show the bugs that are a priority for us now'''.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Please read [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component this report]''' if you wish to know what the current issues are.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Easy bugs ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
TODO: list of bugs linking to trac.&lt;br /&gt;
&lt;br /&gt;
=== Normal bugs ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
'''This is the complete [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component report]''' with all the bugs (some of them might be invalid).&lt;br /&gt;
&lt;br /&gt;
=== Hard bugs ===&lt;br /&gt;
&lt;br /&gt;
Those are the evil bugs that we haven't fixed either because:&lt;br /&gt;
&lt;br /&gt;
# We do not know how to do it in reasonable time&lt;br /&gt;
# 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)&lt;br /&gt;
# More testing is needed (perhaps a hard-to-reproduce bug)&lt;br /&gt;
&lt;br /&gt;
Here is the list:&lt;br /&gt;
&lt;br /&gt;
* [https://docs.openmoko.org/trac/ticket/2235 #2235 : Monochrome display on resume]&lt;br /&gt;
&lt;br /&gt;
{{Languages|Kernel}}&lt;br /&gt;
&lt;br /&gt;
[[Category:Kernel| ]]&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Community_transition</id>
		<title>Community transition</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Community_transition"/>
				<updated>2009-06-25T22:37:14Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: /* How will the kernel be maintained ? */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== History ==&lt;br /&gt;
&lt;br /&gt;
Sean Moss-Pultz (CEO of Openmoko Inc.) decided that the best path forward for the phone business is to turn the future of the Freerunner over to the community. (See the [http://lists.openmoko.org/pipermail/community/2009-June/048903.html announcement] for details)&lt;br /&gt;
&lt;br /&gt;
In brief :&lt;br /&gt;
* The Neo Freerunner development is now fully performed by the [[Gta02-core]] project&lt;br /&gt;
* The community has permission to use the Openmoko brand/trademark for their efforts&lt;br /&gt;
* Openmoko Inc. will continue to provide funding for operating the infrastructure (Wiki, GIT, Trac, Planet, ...)&lt;br /&gt;
&lt;br /&gt;
== Wish List ==&lt;br /&gt;
&lt;br /&gt;
List here for what kinds of things OM can do to smooth this transition.&lt;br /&gt;
* continue to funding the infrastructure&lt;br /&gt;
* promote and sell the Freerunner&lt;br /&gt;
* create the Openmoko foundation ?&lt;br /&gt;
&lt;br /&gt;
== Todo ==&lt;br /&gt;
&lt;br /&gt;
With the transition alot of work is awaiting the community. This list gathers all neccessary tasks to keep the freerunner alive. If you want to serve the community, here is the place to find out what help is needed.&lt;br /&gt;
&lt;br /&gt;
=== Community Core Development ===&lt;br /&gt;
&lt;br /&gt;
* FSO team is developing the middleware, they need c/vala experts, funding :)&lt;br /&gt;
* Mirko is working on Paroli, help is needed to create a a good wifi manager plugin&lt;br /&gt;
* Angus is working on om2009, openembedded experts are welcome&lt;br /&gt;
* Nelson, Luca, etc. is working on kernel, some guru needed or donate a debug board (debug board maybe being donated by Tuxbrain)&lt;br /&gt;
* Thomas, Andreas etc. is working on xorg glamo, drm/dri experts are welcome&lt;br /&gt;
* xxx, yyy maintains the server infrastructure, gforge experts needed&lt;br /&gt;
&lt;br /&gt;
=== Community Other Development ===&lt;br /&gt;
&lt;br /&gt;
* c_c is working on audio/video mediaplayer&lt;br /&gt;
* xxx is working on bluetooth manager&lt;br /&gt;
* yyy is adapting linphone UI for small devices&lt;br /&gt;
* zzz and www is testing qlwm for arm and writing qt applications to create a new and complete qt/x11 gui phone stack over fso, every qt developer is welcome&lt;br /&gt;
* xxx is working to support wpa2/enterprise in connman&lt;br /&gt;
* &amp;quot;&amp;quot; shr&lt;br /&gt;
* &amp;quot;&amp;quot; debian&lt;br /&gt;
* &amp;quot;&amp;quot; hackable:1&lt;br /&gt;
* &amp;quot;&amp;quot; neovento&lt;br /&gt;
* &amp;quot;&amp;quot; gentoo&lt;br /&gt;
* &amp;quot;&amp;quot; qtmoko/qtimproved&lt;br /&gt;
&lt;br /&gt;
=== Community Documentation ===&lt;br /&gt;
&lt;br /&gt;
* Maintain the wiki&lt;br /&gt;
* Provide Community Updates&lt;br /&gt;
&lt;br /&gt;
=== Discussion Boards ===&lt;br /&gt;
&lt;br /&gt;
* how to use better the aux and power buttons&lt;br /&gt;
* killing freezed x11 fullscreen applications&lt;br /&gt;
* the wanted systray support&lt;br /&gt;
* windows manager status&lt;br /&gt;
* x11 server over qtimproved&lt;br /&gt;
* improving the user interaction with accelerometers&lt;br /&gt;
* long term architecture for om2010&lt;br /&gt;
&lt;br /&gt;
== FAQ ==&lt;br /&gt;
&lt;br /&gt;
=== I'm using OM2008/2009 now. Will this distribution still be maintained ? Should I switch ? How ? What will change, what do I have to learn/unlearn ? ===&lt;br /&gt;
&lt;br /&gt;
=== What will happen with FSO ? Will development continue ? Will a distribution carry it ? ===&lt;br /&gt;
&lt;br /&gt;
=== What will happen with Paroli ? Will development continue ? Will a distribution carry it ? ===&lt;br /&gt;
&lt;br /&gt;
=== How will the kernel be maintained ? ===&lt;br /&gt;
&lt;br /&gt;
The kernel will be maintained by a group of volunteers. They have received commit rights to the kernel repository.&lt;br /&gt;
&lt;br /&gt;
These are the [https://docs.openmoko.org/trac/milestone/stable-kernel-2009.1 most important bugs] that need to be fixed now.&lt;br /&gt;
&lt;br /&gt;
'''This is the complete [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component report]''' with all the bugs (some of them might be invalid, please ask on IRC or in the mailing list before trying to fix one).&lt;br /&gt;
&lt;br /&gt;
There is a current ongoing effort to get basic GTA02 support in the mainstream Linux kernel, the patches have been sent. Once this basic support is ready other drivers can be submitted as well. Many of the drivers need additional work to be suitable for upstream inclusion.&lt;br /&gt;
&lt;br /&gt;
=== Will Openmoko continue selling FreeRunners ? For how long ? ===&lt;br /&gt;
&lt;br /&gt;
There are still Freerunners available for purchase.  According to [http://lists.openmoko.org/pipermail/community/2009-June/048903.html Sean's email] there are plenty of the A7 in stock.&lt;br /&gt;
&lt;br /&gt;
=== I have a purchase/return/warranty/etc. in progress with Openmoko Inc. or a distributor. What will happen ? ===&lt;br /&gt;
&lt;br /&gt;
=== I have buzz/#1024/no bass/etc. Can I still get it fixed ? How ? ===&lt;br /&gt;
&lt;br /&gt;
For North Americans experiencing the buzz on their phones, SDG Systems will be running a buzz repair service.  The phones must be sent to SDG no later than July 15th, 2009.  See [http://lists.openmoko.org/pipermail/community/2009-June/049041.html this email] for details.&lt;br /&gt;
&lt;br /&gt;
=== Will the Openmoko Internet resources, Wiki, mailing lists, SVN, git, downloads, people, trac, etc., be shut down ? ===&lt;br /&gt;
&lt;br /&gt;
No.  Openmoko Inc. has committed to continuing to support the community by funding the resources available on openmoko.org.  &lt;br /&gt;
&lt;br /&gt;
From Sean's email [http://lists.openmoko.org/pipermail/community/2009-June/048903.html announcement]: ''&amp;quot;Openmoko Inc. then will act as the sponsor of this effort. We will continue to fund all necessary server infrastructure...&amp;quot;''&lt;br /&gt;
&lt;br /&gt;
=== Will &amp;quot;project B&amp;quot; continue ? ===&lt;br /&gt;
&lt;br /&gt;
=== What's the future of Open phone hardware without Openmoko Inc. ? ===&lt;br /&gt;
&lt;br /&gt;
Discussions have started to create an organization of Openmoko community members to continue the work started by the company.&lt;br /&gt;
&lt;br /&gt;
== Community Organization ==&lt;br /&gt;
&lt;br /&gt;
''(This is all pre-alpha.  Feel free to get involved by changing things up and making additions.)''&lt;br /&gt;
&lt;br /&gt;
In order for development to continue on the Freerunner and any potential successors, the community needs to create an organization that can facilitate the project.  We need an organization that will:&lt;br /&gt;
&lt;br /&gt;
* provide an organizational structure for projects&lt;br /&gt;
* host and maintain community infrastructure such as mailing lists&lt;br /&gt;
* arrange financing for projects&lt;br /&gt;
* promote and raise awareness of the ideals, projects and products of the community&lt;br /&gt;
&lt;br /&gt;
Jon 'maddog' Hall has [http://lists.openmoko.org/pipermail/community/2009-June/049177.html offered] for the Openmoko community to operate as a sub-group of Linux International.  The offer has already received some support on the mailing list.&lt;br /&gt;
&lt;br /&gt;
=== Projects ===&lt;br /&gt;
==== GTA02-core ====&lt;br /&gt;
&lt;br /&gt;
The [[Gta02-core]] team is currently working on an improved version of the Freerunner.&lt;br /&gt;
&lt;br /&gt;
GTA02-core needs an organization that can finance and arrange for production.&lt;br /&gt;
&lt;br /&gt;
==== Paroli and OM2009? ====&lt;br /&gt;
&lt;br /&gt;
[[Paroli]] and [[Om2009]] were both lead directly by Openmoko Inc.  The community organization could take over as sponsor of these projects.&lt;br /&gt;
&lt;br /&gt;
=== Process and Structure ===&lt;br /&gt;
&lt;br /&gt;
Part of creating a new organization is developing a structure and set of processes for how decisions will be made.  Developing the structure entails creating positions, board(s) and committees that will have authority over various parts of the organization.  Processes should cover:&lt;br /&gt;
&lt;br /&gt;
* how people will be selected to fill positions and sit on boards or committees&lt;br /&gt;
* how decisions will be made on boards, committees and for the organization as a whole&lt;br /&gt;
* what various projects, committees and other sub-groups will be responsible for&lt;br /&gt;
&lt;br /&gt;
Process and structure are like the source code for an organization.  Ideally we will develop processes that give all members opportunity to provide input, and do not become an obstacle to getting work done.  It's important to remember right from the start that our goal is to foster development, not burden it down with bureaucracy!&lt;br /&gt;
&lt;br /&gt;
[http://lists.openmoko.org/pipermail/community/2009-June/049317.html This email] from Jon on the openmoko-community mailing list contains some notes and advice on developing an organization that are well worth reading.&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Who_is_Who</id>
		<title>Who is Who</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Who_is_Who"/>
				<updated>2009-06-22T21:08:19Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: Fix Lindi-'s nick.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;If you subscribe to a mailing list or join an IRC channel, you will see people speaking, answering some questions, but you may ask:&lt;br /&gt;
* Who is who?&lt;br /&gt;
* Who can I trust when they say something?&lt;br /&gt;
This page should serve as a list of community members and their areas of expertise.&lt;br /&gt;
&lt;br /&gt;
= Community members =&lt;br /&gt;
&lt;br /&gt;
IRC nicknames are in brackets after each name.&lt;br /&gt;
&lt;br /&gt;
== Kernel ==&lt;br /&gt;
&lt;br /&gt;
* Luca Capello&lt;br /&gt;
* Mike Westerhof (mwester)&lt;br /&gt;
* Nelson Castillo (Arhuaco)&lt;br /&gt;
* Paul Fertser (PaulFertser)&lt;br /&gt;
* Timo Juhani Lindfors (lindi-)&lt;br /&gt;
* Rod Whitby (rwhitby)&lt;br /&gt;
* Werner Almesberger (wpwrak)&lt;br /&gt;
&lt;br /&gt;
== FSO (freesmartphone.org) ==&lt;br /&gt;
* Michael Lauer (Mickey)&lt;br /&gt;
* Jan Luebbe (Shoragan)&lt;br /&gt;
* Daniel Willmann (Alphaone)&lt;br /&gt;
* Stefan Schmidt&lt;br /&gt;
&lt;br /&gt;
== Om2009 ==&lt;br /&gt;
* Angus Ainslie (nytowl)&lt;br /&gt;
&lt;br /&gt;
== SHR ==&lt;br /&gt;
* David Kozub (dent)&lt;br /&gt;
* Klaus Kurzmann (mrmoku)&lt;br /&gt;
* Wolfgang Kroener (azog)&lt;br /&gt;
* Hire&lt;br /&gt;
* David Wagner (deubeuliou)  &lt;br /&gt;
* Montgoss&lt;br /&gt;
* Dolf                       &lt;br /&gt;
* Quickdev (RIP)&lt;br /&gt;
* Sebastian Spaeth (spaetz)  &lt;br /&gt;
* Cameron Frazier (Toaster)&lt;br /&gt;
* Didier (ptitjes)       &lt;br /&gt;
* Yorick (yoyo)&lt;br /&gt;
* Tom (Tasn)               &lt;br /&gt;
* Morphis&lt;br /&gt;
* Hiciu                      &lt;br /&gt;
* Sebastian Krzyszkowiak (dos)&lt;br /&gt;
* Stian Skjelstad (mywave)  &lt;br /&gt;
* Tilman Sauerbeck (tilman)&lt;br /&gt;
* Mike Westerhof (mwester)    &lt;br /&gt;
* Bobby Martin (wurp2)&lt;br /&gt;
&lt;br /&gt;
== Paroli ==&lt;br /&gt;
* Mirko Lindner (mirko)&lt;br /&gt;
&lt;br /&gt;
== X.org / Glamo (Graphics subsystem) ==&lt;br /&gt;
* Lars-Peter Clausen (larsc)&lt;br /&gt;
* Thomas White (Weiss)&lt;br /&gt;
* Andreas Pokorny (DieMumiee)&lt;br /&gt;
* Timo Juhani Lindfors (lindi-)&lt;br /&gt;
&lt;br /&gt;
== QtMoko ==&lt;br /&gt;
* Lorn Potter (lpotter)&lt;br /&gt;
* Radekp&lt;br /&gt;
* Franky Van Liedekerke (liedekef)&lt;br /&gt;
* Fabio Alessandro Locati (fale)&lt;br /&gt;
&lt;br /&gt;
== MokoMakefile ==&lt;br /&gt;
* Rod Whitby (rwhitby)&lt;br /&gt;
&lt;br /&gt;
== gta02-core ==&lt;br /&gt;
(community project to create a new hardware revision of the gta02 hardware)&lt;br /&gt;
* Werner Almesberger (wpwrak)&lt;br /&gt;
&lt;br /&gt;
= Officials members of the Openmoko Team =&lt;br /&gt;
&lt;br /&gt;
''Note: This is severly outdated. Most of the people listed here as officials do not work for Openmoko anymore.''&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable sortable&amp;quot; style=&amp;quot;margin: 0em &amp;quot; cellspacing=&amp;quot;0&amp;quot; cellpadding=&amp;quot;5&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
! Name !! email !! Wiki username !! IRC nickname !! Position&lt;br /&gt;
|-&lt;br /&gt;
| Allen Chang || || {{user|allen_chang}} || || GTA Hardware Engineer ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Andy Green || ''andy'' at openmoko dot ''com'' || {{user|warmcat}} || agreen || Software Developer/kernel maintainer ('''Left Openmoko'''. Here for archives.)&lt;br /&gt;
|-&lt;br /&gt;
| Anthony Chang || || || || Software Developer ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Candy Chou || || {{user|candy_chou}} || || GTA/HXD Hardware Engineer ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Dkay Chen || || {{user|dkay_chen}} || || GTA/HXD Hardware Engineer ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Jeremy Chang || || || || Software Developer ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Jollen Chen || || || ||  Marketing('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Tick Chen || || || || Software Developer('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Guillaume 'Charlie' Chereau || ''charlie'' at openmoko dot ''org'' || || || ('''Left Openmoko'''. Here for archives.)&lt;br /&gt;
|-&lt;br /&gt;
| Julian Chu || ''julian_chu'' at openmoko dot ''com'' || || || Software Developer ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Holger 'Zecke' Freyther || ''zecke'' at openmoko dot ''org'' || || || Software Developer ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Graeme Gregory || ''graeme'' at openmoko dot ''org'' || || XorA || ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Carsten Haitzler || ''raster'' at openmoko dot ''org'' || || raster || ('''Left Openmoko'''. Here for archives.)&lt;br /&gt;
|-&lt;br /&gt;
| Matt Hsu || || {{user|Matt}} || || Software Developer ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Wendy Hung || || || || Testing ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Regina Kim || || || || Testing ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| William Lai || ''will'' at openmoko dot ''com'' || || || Design Team Project Manager&lt;br /&gt;
|-&lt;br /&gt;
| Michael 'Mickey' Lauer || || {{user|Mickey}} || || Software Developer ('''Left Openmoko'''. Freelancer - maintains FSO.)&lt;br /&gt;
|-&lt;br /&gt;
| John Lee || || || || Software Developer ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Tim Lee || || {{user|Tim}} || || Hardware Manager&lt;br /&gt;
|-&lt;br /&gt;
| Marek Lindner || ''marek'' at openmoko dot ''com'' || || || Software Developer ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Xiangfu Liu || ''xiangfu'' at openmoko dot ''org'' || {{user|liuxf}} || || Software Developer ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Jan 'Shoragan' Luebbe || || || || Openmoko student (part-time) ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Steven Mosher || || {{user|steve}} || || Vice President of Marketing ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Sean Moss-Pultz || || {{user|Sean}} || || CEO&lt;br /&gt;
|-&lt;br /&gt;
| Shawn Lin || || {{user|shawn_lin}} || || RF Engineer('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Joerg Reisenweber || || {{user|jOERG}} || || Hardware Engineer ('''Left Openmoko'''. Here for archives.)&lt;br /&gt;
|-&lt;br /&gt;
| Michael Shiloh || ''michael'' at openmoko dot ''org'' || {{user|Michaelshiloh}} || || Head of Developer Relations ('''Left Openmoko'''. Here for archives.)&lt;br /&gt;
|-&lt;br /&gt;
| Werner Almesberger || ''werner'' at openmoko dot ''org'' || || || ('''Left Openmoko'''.  Here for archives.)&lt;br /&gt;
|-&lt;br /&gt;
| Wolfgang Spraul || ''wolfgang'' at openmoko dot ''com'' || || || Vice President of Engineering ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Joachim Steiger || ''roh'' at openmoko dot ''org'' || {{user|Roh}} || roh || Central Services ('''Left Openmoko'''.  Here for archives.)&lt;br /&gt;
|-&lt;br /&gt;
| Teenie Hung || || {{user|teenie_hung}} || || Operations Head ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Harry Tsai || ''tsaiharry'' at gmail dot ''com'' || || || long time ago he was Vice President of Sales in Openmoko, but that is past. ('''Left Openmoko'''. Here for archives.)&lt;br /&gt;
|-&lt;br /&gt;
| Neng-Yu 'Tony' Tu || || {{user|Tony Tu}} || || Project manager (gta01/02), software developer ('''Left Openmoko'''. Here for archives.) &lt;br /&gt;
|-&lt;br /&gt;
| Brenda Wang || ''brenda_wang'' at openmoko dot ''com'' || {{user|Coolcat}} || || Used to Wiki editor . volunteer now. ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Harald Welte || ''laforge'' at openmoko dot ''org'' || {{user|HaraldWelte}} || LaF0rge || ('''Left Openmoko'''. Here for archives.)&lt;br /&gt;
|-&lt;br /&gt;
| Daniel 'Alphaone' Willmann || || {{user|DanielWillmann}} || || Software Developer ('''Left Openmoko'''. Here for archives.)&lt;br /&gt;
|-&lt;br /&gt;
| Thomas Wood || || {{user|ThomasWood}} || || Was hired as part of OpenedHand. ('''No longer employed by Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| OLV Wu || ''olv'' at openmoko dot ''org'' || || || Software Developer ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Erin Yeh || ''erin_yueh'' at openmoko dot ''org''||{{user|erin}} || || Software Developer ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Mirko Lindner || ''mirko'' at openmoko dot ''com''||{{user|Vegyraupe}} || mirko-paroli || Software Developer (om2009/paroli) ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Angus Ainslie || ''nytowl'' at openmoko dot ''org''||{{user|Nytowl}} || nytowl || Distribution maintainer (om2009) ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Ray Chao || ''ray_chao'' at openmoko dot ''org''||{{user|Ray}} || jc || System Administrator ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Chelsea Wei || ''chelsea'' at openmoko dot ''com''||{{user|Chelsea}} || || ('''Left Openmoko''')&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
[[Category:Openmoko Inc]]&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Who_is_Who</id>
		<title>Who is Who</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Who_is_Who"/>
				<updated>2009-06-22T16:19:40Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: Alphabetic order, added IRC nicks, aded -lindi who reports many bugs and suggest solutions.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;If you subscribe to a mailing list or join an IRC channel, you will see people speaking, answering some questions, but you may ask:&lt;br /&gt;
* Who is who?&lt;br /&gt;
* Who can I trust when they say something?&lt;br /&gt;
This page should serve as a list of community members and their areas of expertise.&lt;br /&gt;
&lt;br /&gt;
= Community members =&lt;br /&gt;
&lt;br /&gt;
IRC nicknames are in brackets after each name.&lt;br /&gt;
&lt;br /&gt;
== Kernel ==&lt;br /&gt;
&lt;br /&gt;
* Luca Capello&lt;br /&gt;
* Mike Westerhof (mwester)&lt;br /&gt;
* Nelson Castillo (Arhuaco)&lt;br /&gt;
* Paul Fertser (PaulFertser)&lt;br /&gt;
* Timo Juhani Lindfors (-lindi)&lt;br /&gt;
* Rod Whitby (rwhitby)&lt;br /&gt;
* Werner Almesberger (wpwrak)&lt;br /&gt;
&lt;br /&gt;
== FSO (freesmartphone.org) ==&lt;br /&gt;
* Michael Lauer (Mickey)&lt;br /&gt;
* Jan Luebbe (Shoragan)&lt;br /&gt;
* Daniel Willmann (Alphaone)&lt;br /&gt;
* Stefan Schmidt&lt;br /&gt;
&lt;br /&gt;
== Om2009 ==&lt;br /&gt;
* Angus Ainslie (nytowl)&lt;br /&gt;
&lt;br /&gt;
== SHR ==&lt;br /&gt;
* David Kozub (dent)&lt;br /&gt;
* Klaus Kurzmann (mrmoku)&lt;br /&gt;
* Wolfgang Kroener (azog)&lt;br /&gt;
* Hire&lt;br /&gt;
* David Wagner (deubeuliou)  &lt;br /&gt;
* Montgoss&lt;br /&gt;
* Dolf                       &lt;br /&gt;
* Quickdev (RIP)&lt;br /&gt;
* Sebastian Spaeth (spaetz)  &lt;br /&gt;
* Cameron Frazier (Toaster)&lt;br /&gt;
* Didier (ptitjes)       &lt;br /&gt;
* Yorick (yoyo)&lt;br /&gt;
* Tom (Tasn)               &lt;br /&gt;
* Morphis&lt;br /&gt;
* Hiciu                      &lt;br /&gt;
* Sebastian Krzyszkowiak (dos)&lt;br /&gt;
* Stian Skjelstad (mywave)  &lt;br /&gt;
* Tilman Sauerbeck (tilman)&lt;br /&gt;
* Mike Westerhof (mwester)    &lt;br /&gt;
* Bobby Martin (wurp2)&lt;br /&gt;
&lt;br /&gt;
== Paroli ==&lt;br /&gt;
* Mirko Lindner (mirko)&lt;br /&gt;
&lt;br /&gt;
== X.org / Glamo (Graphics subsystem) ==&lt;br /&gt;
* Lars-Peter Clausen (larsc)&lt;br /&gt;
* Thomas White (Weiss)&lt;br /&gt;
* Andreas Pokorny (DieMumiee)&lt;br /&gt;
* Timo Juhani Lindfors (lindi-)&lt;br /&gt;
&lt;br /&gt;
== QtMoko ==&lt;br /&gt;
* Lorn Potter (lpotter)&lt;br /&gt;
* Radekp&lt;br /&gt;
* Franky Van Liedekerke (liedekef)&lt;br /&gt;
* Fabio Alessandro Locati (fale)&lt;br /&gt;
&lt;br /&gt;
== MokoMakefile ==&lt;br /&gt;
* Rod Whitby (rwhitby)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Officials members of the Openmoko Team =&lt;br /&gt;
&lt;br /&gt;
''Note: This is severly outdated. Most of the people listed here as officials do not work for Openmoko anymore.''&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable sortable&amp;quot; style=&amp;quot;margin: 0em &amp;quot; cellspacing=&amp;quot;0&amp;quot; cellpadding=&amp;quot;5&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
! Name !! email !! Wiki username !! IRC nickname !! Position&lt;br /&gt;
|-&lt;br /&gt;
| Allen Chang || || {{user|allen_chang}} || || GTA Hardware Engineer ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Andy Green || ''andy'' at openmoko dot ''com'' || {{user|warmcat}} || agreen || Software Developer/kernel maintainer ('''Left Openmoko'''. Here for archives.)&lt;br /&gt;
|-&lt;br /&gt;
| Anthony Chang || || || || Software Developer ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Candy Chou || || {{user|candy_chou}} || || GTA/HXD Hardware Engineer ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Dkay Chen || || {{user|dkay_chen}} || || GTA/HXD Hardware Engineer ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Jeremy Chang || || || || Software Developer ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Jollen Chen || || || ||  Marketing('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Tick Chen || || || || Software Developer('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Guillaume 'Charlie' Chereau || ''charlie'' at openmoko dot ''org'' || || || ('''Left Openmoko'''. Here for archives.)&lt;br /&gt;
|-&lt;br /&gt;
| Julian Chu || ''julian_chu'' at openmoko dot ''com'' || || || Software Developer ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Holger 'Zecke' Freyther || ''zecke'' at openmoko dot ''org'' || || || Software Developer ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Graeme Gregory || ''graeme'' at openmoko dot ''org'' || || XorA || ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Carsten Haitzler || ''raster'' at openmoko dot ''org'' || || raster || ('''Left Openmoko'''. Here for archives.)&lt;br /&gt;
|-&lt;br /&gt;
| Matt Hsu || || {{user|Matt}} || || Software Developer ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Wendy Hung || || || || Testing ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Regina Kim || || || || Testing ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| William Lai || ''will'' at openmoko dot ''com'' || || || Design Team Project Manager&lt;br /&gt;
|-&lt;br /&gt;
| Michael 'Mickey' Lauer || || {{user|Mickey}} || || Software Developer ('''Left Openmoko'''. Freelancer - maintains FSO.)&lt;br /&gt;
|-&lt;br /&gt;
| John Lee || || || || Software Developer ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Tim Lee || || {{user|Tim}} || || Hardware Manager&lt;br /&gt;
|-&lt;br /&gt;
| Marek Lindner || ''marek'' at openmoko dot ''com'' || || || Software Developer ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Xiangfu Liu || ''xiangfu'' at openmoko dot ''org'' || {{user|liuxf}} || || Software Developer ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Jan 'Shoragan' Luebbe || || || || Openmoko student (part-time) ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Steven Mosher || || {{user|steve}} || || Vice President of Marketing&lt;br /&gt;
|-&lt;br /&gt;
| Sean Moss-Pultz || || {{user|Sean}} || || CEO&lt;br /&gt;
|-&lt;br /&gt;
| Shawn Lin || || {{user|shawn_lin}} || || RF Engineer('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Joerg Reisenweber || || {{user|jOERG}} || || Hardware Engineer ('''Left Openmoko'''. Here for archives.)&lt;br /&gt;
|-&lt;br /&gt;
| Michael Shiloh || ''michael'' at openmoko dot ''org'' || {{user|Michaelshiloh}} || || Head of Developer Relations ('''Left Openmoko'''. Here for archives.)&lt;br /&gt;
|-&lt;br /&gt;
| Werner Almesberger || ''werner'' at openmoko dot ''org'' || || || ('''Left Openmoko'''.  Here for archives.)&lt;br /&gt;
|-&lt;br /&gt;
| Wolfgang Spraul || ''wolfgang'' at openmoko dot ''com'' || || || Vice President of Engineering ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Joachim Steiger || ''roh'' at openmoko dot ''org'' || {{user|Roh}} || roh || Central Services ('''Left Openmoko'''.  Here for archives.)&lt;br /&gt;
|-&lt;br /&gt;
| Teenie Hung || || {{user|teenie_hung}} || || Operations Head ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Harry Tsai || ''tsaiharry'' at gmail dot ''com'' || || || long time ago he was Vice President of Sales in Openmoko, but that is past. ('''Left Openmoko'''. Here for archives.)&lt;br /&gt;
|-&lt;br /&gt;
| Neng-Yu 'Tony' Tu || || {{user|Tony Tu}} || || Project manager (gta01/02), software developer ('''Left Openmoko'''. Here for archives.) &lt;br /&gt;
|-&lt;br /&gt;
| Brenda Wang || ''brenda_wang'' at openmoko dot ''com'' || {{user|Coolcat}} || || Used to Wiki editor . volunteer now. ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Harald Welte || ''laforge'' at openmoko dot ''org'' || {{user|HaraldWelte}} || LaF0rge || ('''Left Openmoko'''. Here for archives.)&lt;br /&gt;
|-&lt;br /&gt;
| Daniel 'Alphaone' Willmann || || {{user|DanielWillmann}} || || Software Developer ('''Left Openmoko'''. Here for archives.)&lt;br /&gt;
|-&lt;br /&gt;
| Thomas Wood || || {{user|ThomasWood}} || || Was hired as part of OpenedHand. ('''No longer employed by Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| OLV Wu || ''olv'' at openmoko dot ''org'' || || || Software Developer ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Erin Yeh || ''erin_yueh'' at openmoko dot ''org''||{{user|erin}} || || Software Developer ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Mirko Lindner || ''mirko'' at openmoko dot ''com''||{{user|Vegyraupe}} || mirko-paroli || Software Developer (om2009/paroli) ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Angus Ainslie || ''nytowl'' at openmoko dot ''org''||{{user|Nytowl}} || nytowl || Distribution maintainer (om2009) ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Ray Chao || ''ray_chao'' at openmoko dot ''org''||{{user|Ray}} || jc || System Administrator ('''Left Openmoko''')&lt;br /&gt;
|-&lt;br /&gt;
| Chelsea Wei || ''chelsea'' at openmoko dot ''com''||{{user|Chelsea}} || || ('''Left Openmoko''')&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
[[Category:Openmoko Inc]]&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Community_transition</id>
		<title>Community transition</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Community_transition"/>
				<updated>2009-06-06T19:18:32Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: /* How will the kernel be maintained ? */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== History ==&lt;br /&gt;
&lt;br /&gt;
Sean Moss-Pultz (CEO of Openmoko Inc.) decided that the best path foreword for the phone business is to turn the future of the Freerunner over to the community. (See the [http://lists.openmoko.org/pipermail/community/2009-June/048903.html announce] for all details)&lt;br /&gt;
&lt;br /&gt;
In brief :&lt;br /&gt;
* The Neo Freerunner developpment is now fully holded by the [[Gta02-core]] project&lt;br /&gt;
* The community has permission to use the Openmoko brand/trademark for their efforts&lt;br /&gt;
* Openmoko Inc. will continue to provide funding for operating the infrastructure (Wiki, GIT, Trac, Planet, ...)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Wish List ==&lt;br /&gt;
&lt;br /&gt;
List here for what kinds of things OM can do to smooth this transition.&lt;br /&gt;
* continue to funding the infrastructure&lt;br /&gt;
* promote and sell the Freerunner&lt;br /&gt;
* create the Openmoko foundation ?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== FAQ ==&lt;br /&gt;
&lt;br /&gt;
=== I'm using OM2008/2009 now. Will this distribution still be maintained ? Should I switch ? How ? What will change, what do I have to learn/unlearn ? ===&lt;br /&gt;
''please answer here'' (Om2008 hadn't maintained for a while before that announcement. Now only maintained distro by Openmoko is Om2009)&lt;br /&gt;
&lt;br /&gt;
=== What will happen with FSO ? Will development continue ? Will a distribution carry it ? ===&lt;br /&gt;
''please answer here''&lt;br /&gt;
&lt;br /&gt;
=== What will happen with Paroli ? Will development continue ? Will a distribution carry it ? ===&lt;br /&gt;
''please answer here''&lt;br /&gt;
&lt;br /&gt;
=== How will the kernel be maintained ? ===&lt;br /&gt;
&lt;br /&gt;
The kernel will be maintained by a group of volunteers. The main change now is that more than one person will be able to commit. The list of committers will be published soon.&lt;br /&gt;
&lt;br /&gt;
These are the [https://docs.openmoko.org/trac/milestone/stable-kernel-2009.1 most important bugs] that need to be fixed now.&lt;br /&gt;
&lt;br /&gt;
'''This is the complete [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component report]''' with all the bugs (some of them might be invalid, please ask on IRC or in the mailing list before trying to fix one).&lt;br /&gt;
&lt;br /&gt;
There is a current ongoing effort to get basic GTA02 support in the mainstream Linux kernel, the patches have been sent. Once this basic support is ready other drivers can be submitted as well. Many of the drivers need additional work to be suitable for upstream inclusion.&lt;br /&gt;
&lt;br /&gt;
=== Will Openmoko continue selling FreeRunners ? For how long ? ===&lt;br /&gt;
''please answer here''&lt;br /&gt;
&lt;br /&gt;
=== I have a purchase/return/warranty/etc. in progress with Openmoko Inc. or a distributor. What will happen ? ===&lt;br /&gt;
''please answer here''&lt;br /&gt;
&lt;br /&gt;
=== I have buzz/#1024/no bass/etc. Can I still get it fixed ? How ? ===&lt;br /&gt;
''please answer here''&lt;br /&gt;
&lt;br /&gt;
=== Will the Openmoko Internet resources, Wiki, mailing lists, SVN, git, downloads, people, trac, etc., be shut down ? ===&lt;br /&gt;
''please answer here''&lt;br /&gt;
&lt;br /&gt;
=== Will &amp;quot;project B&amp;quot; continue ? ===&lt;br /&gt;
''please answer here''&lt;br /&gt;
&lt;br /&gt;
=== What's the future of Open phone hardware without Openmoko Inc. ? ===&lt;br /&gt;
''please answer here''&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/User:Arhuaco</id>
		<title>User:Arhuaco</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/User:Arhuaco"/>
				<updated>2009-05-02T23:24:41Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: Fix.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Only edit to correct a spelling or grammar mistakes'''.&lt;br /&gt;
&lt;br /&gt;
== Current Priorities ==&lt;br /&gt;
&lt;br /&gt;
* Help with the [https://docs.openmoko.org/trac/milestone/stable-kernel-2009.1 stable-kernel-2009.1] milestone.&lt;br /&gt;
* Help include support for the GTA02/[[Freerunner]] into the upstream Linux Kernel.&lt;br /&gt;
&lt;br /&gt;
== Currently working on ==&lt;br /&gt;
&lt;br /&gt;
== Patches ==&lt;br /&gt;
&lt;br /&gt;
I keep a backup of the patches I work on in a public [http://nelson-patches.googlecode.com/svn/trunk/openmoko/kernel/ subversion repository]. The main purpose of this repository is backup in case of disaster.&lt;br /&gt;
&lt;br /&gt;
== About ==&lt;br /&gt;
&lt;br /&gt;
[[Image:Nelson-lightsaber.jpg|right]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
I am Nelson Castillo -- a Digital Alchemist.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
* My goal is to turn all the difficult issues I have to deal with into working code (silver).&lt;br /&gt;
* When the code is also beautiful then it is better than gold.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 Caminante, son tus huellas&lt;br /&gt;
 el camino y nada más;&lt;br /&gt;
 caminante, no hay camino,&lt;br /&gt;
 se hace camino al andar.&lt;br /&gt;
 &lt;br /&gt;
 Al andar se hace camino&lt;br /&gt;
 y al volver la vista atrás&lt;br /&gt;
 se ve la senda que nunca&lt;br /&gt;
 se ha de volver a pisar.&lt;br /&gt;
 &lt;br /&gt;
 Caminante no hay camino&lt;br /&gt;
 sino estelas en la mar...&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Whole thing [http://www.poemas-del-alma.com/antonio-machado-caminante-no-hay-camino.htm here].&lt;br /&gt;
&lt;br /&gt;
== Contact ==&lt;br /&gt;
&lt;br /&gt;
If you have a kernel issue you should write to [http://lists.openmoko.org/mailman/listinfo/openmoko-kernel the mailing list].&lt;br /&gt;
&lt;br /&gt;
I'm usually on IRC (Freenode #openmoko-cdevel) using the nick Arhuaco.&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel</id>
		<title>Kernel</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel"/>
				<updated>2009-04-24T13:22:44Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: /* FAQ */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Kernel}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Things changed ==&lt;br /&gt;
&lt;br /&gt;
This page will be updated soon. Those are the current [[Kernel_Plans|Kernel plans]].&lt;br /&gt;
&lt;br /&gt;
== Is this page meant for you? ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Sister pages ===&lt;br /&gt;
&lt;br /&gt;
# [[Kernel branches]].&lt;br /&gt;
&lt;br /&gt;
== Sources ==&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
&lt;br /&gt;
http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
&lt;br /&gt;
[http://git-scm.com 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
If you are very new to GIT you might want to read [http://git.or.cz/course/ the good manuals that already available].&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
=== Branches ===&lt;br /&gt;
&lt;br /&gt;
GIT allow developers to use different [[Kernel_branches|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 (http://git.openmoko.org/?p=kernel.git;a=summary).&lt;br /&gt;
&lt;br /&gt;
The ''andy-tracking'' branch is the one where most of the action takes place these days. &lt;br /&gt;
&lt;br /&gt;
We have [[Kernel_branches|branch policies]] that explain what each branch is for.&lt;br /&gt;
&lt;br /&gt;
=== Daily builds ===&lt;br /&gt;
&lt;br /&gt;
==== Automatic revisions ====&lt;br /&gt;
&lt;br /&gt;
Think of a robot that takes whatever kernels are the most recent in GIT, builds them for you and then makes them available here:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/experimental/&lt;br /&gt;
&lt;br /&gt;
==== Blessed revisions ====&lt;br /&gt;
&lt;br /&gt;
Another robot but this one only builds the versions picked by our friendly [[OpenEmbedded]] developers. Download from:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/unstable/&lt;br /&gt;
&lt;br /&gt;
If you understand OpenEmbedded you will get this: Those versions are tied to a specific GIT revision through conf/distro/include/sane-srcrevs.bb.&lt;br /&gt;
&lt;br /&gt;
=== Building the andy-tracking branch ===&lt;br /&gt;
&lt;br /&gt;
Those are the minimum survival commands:&lt;br /&gt;
&lt;br /&gt;
 $ git clone git://git.openmoko.org/git/kernel.git linux-2.6&lt;br /&gt;
 $ cd linux-2.6&lt;br /&gt;
 $ git-checkout --track -b andy-tracking origin/andy-tracking&lt;br /&gt;
 $ mkdir GTA02 &lt;br /&gt;
 $ cp ./arch/arm/configs/gta02_moredrivers_defconfig GTA02/.config&lt;br /&gt;
&lt;br /&gt;
Before building this kernel you need install a [http://wiki.openmoko.org/wiki/Toolchain#Downloading_and_installing Toolchain].&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
In order to build the modules you can:&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02 dummy&lt;br /&gt;
&lt;br /&gt;
This will create a file called modules-GTA02_andy-tracking-&amp;lt;git hash&amp;gt;.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.&lt;br /&gt;
&lt;br /&gt;
If you want to update the local copy of the repository so that you get the latest changes, you can type:&lt;br /&gt;
&lt;br /&gt;
 $ git-pull&lt;br /&gt;
&lt;br /&gt;
Before reporting that the new kernel does not build please first check for changes in the configuration file provided by Openmoko.&lt;br /&gt;
&lt;br /&gt;
=== kernel building tips ===&lt;br /&gt;
&lt;br /&gt;
If you are modifying Linux kernel code and building it quite often you really want to be using [http://ccache.samba.org ccache]. It will save you a lot of time.&lt;br /&gt;
&lt;br /&gt;
TODO: submit a patch for the build script that makes ccache use easier. '''Note''': There is a [http://lists.openmoko.org/pipermail/openmoko-kernel/2009-March/009139.html patch being reviewed].&lt;br /&gt;
&lt;br /&gt;
== Contributing ==&lt;br /&gt;
&lt;br /&gt;
The development resources [[Openmoko]] offers are:&lt;br /&gt;
&lt;br /&gt;
* Git repository: http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
* [http://lists.openmoko.org/mailman/listinfo/openmoko-kernel Mailing list] ([http://lists.openmoko.org/pipermail/openmoko-kernel/ Online Archive])&lt;br /&gt;
&lt;br /&gt;
We appreciate your contributions. Check the Open Issues at the end of this page to check where we need more help.&lt;br /&gt;
&lt;br /&gt;
If in doubt ask in the mailing list.&lt;br /&gt;
&lt;br /&gt;
== FAQ ==&lt;br /&gt;
&lt;br /&gt;
=== What happened to usb0? ===&lt;br /&gt;
&lt;br /&gt;
Now you will get eth&amp;lt;n&amp;gt; instead of usb0. Check:&lt;br /&gt;
&lt;br /&gt;
http://lists.openmoko.org/pipermail/devel/2009-April/005384.html&lt;br /&gt;
&lt;br /&gt;
=== Who's Andy and why is he sticking his name in the kernel? ===&lt;br /&gt;
&lt;br /&gt;
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&lt;br /&gt;
&lt;br /&gt;
Check [[Kernel_branches]] if you care about the details.&lt;br /&gt;
&lt;br /&gt;
=== Kernel developers are not polite! They do not even care to say &amp;quot;Hello&amp;quot; when they reply to my emails! ===&lt;br /&gt;
&lt;br /&gt;
The long version is here: [[Kernel-developers-are-not-polite]].&lt;br /&gt;
&lt;br /&gt;
To the point:&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
They just tend to write very short text because they have to read and write a lot every day.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Why does Openmoko cares about sending code upstream instead of (insert your task here)? ===&lt;br /&gt;
&lt;br /&gt;
There are two very different approaches and both of them would be doomed if we committed all our resources to only one of them.&lt;br /&gt;
&lt;br /&gt;
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 [http://www.kernel.org upstream] where the people who want to help us improve, maintain and support the code running in our devices, hang out.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
== Known issues ==&lt;br /&gt;
&lt;br /&gt;
=== Sysfs paths ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[FSO]] developers realized that this problem could be prevented from from happening in the future and they decided to code a nice daemon called [http://www.freesmartphone.org/index.php/Implementations/OpenDeviceDaemon odeviced].&lt;br /&gt;
&lt;br /&gt;
=== WSOD with u-boot ===&lt;br /&gt;
&lt;br /&gt;
There is work in progress to fix this issue that does not happen with Qi. Latest kernel from andy-tracking.&lt;br /&gt;
&lt;br /&gt;
== Open Tickets ==&lt;br /&gt;
&lt;br /&gt;
'''This&lt;br /&gt;
[http://docs.openmoko.org/trac/query?status=in_testing&amp;amp;status=reopened&amp;amp;status=assigned&amp;amp;status=new&amp;amp;status=accepted&amp;amp;group=status&amp;amp;milestone=stable-kernel-2009.1 report] will show the bugs that are a priority for us now'''.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Please read [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component this report]''' if you wish to know what the current issues are.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Easy bugs ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
TODO: list of bugs linking to trac.&lt;br /&gt;
&lt;br /&gt;
=== Normal bugs ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
'''This is the complete [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component report]''' with all the bugs (some of them might be invalid).&lt;br /&gt;
&lt;br /&gt;
=== Hard bugs ===&lt;br /&gt;
&lt;br /&gt;
Those are the evil bugs that we haven't fixed either because:&lt;br /&gt;
&lt;br /&gt;
# We do not know how to do it in reasonable time&lt;br /&gt;
# 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)&lt;br /&gt;
# More testing is needed (perhaps a hard-to-reproduce bug)&lt;br /&gt;
&lt;br /&gt;
Here is the list:&lt;br /&gt;
&lt;br /&gt;
* [https://docs.openmoko.org/trac/ticket/2235 #2235 : Monochrome display on resume]&lt;br /&gt;
&lt;br /&gt;
{{Languages|Kernel}}&lt;br /&gt;
&lt;br /&gt;
[[Category:Kernel]]&lt;br /&gt;
[[Category:System Developers]]&lt;br /&gt;
[[Category:Application Developer]]&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Howto_compile_Openmoko_kernel_for_Neo_Freerunner</id>
		<title>Howto compile Openmoko kernel for Neo Freerunner</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Howto_compile_Openmoko_kernel_for_Neo_Freerunner"/>
				<updated>2009-04-24T13:06:31Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: Delete this duplicated page and redirect to the new one.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Use  [http://wiki.openmoko.org/wiki/Kernel#Building_the_andy-tracking_branch these instructions] instead.'''&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Howto_compile_Openmoko_kernel_for_Neo_Freerunner</id>
		<title>Howto compile Openmoko kernel for Neo Freerunner</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Howto_compile_Openmoko_kernel_for_Neo_Freerunner"/>
				<updated>2009-04-24T13:03:44Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: Fix.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Languages|Howto compile Openmoko kernel for Neo Freerunner}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''This isn't working. Use these instructions [http://wiki.openmoko.org/wiki/Kernel#Building_the_andy-tracking_branch] instead'''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;strong&amp;gt;Note: This is a translation of a [http://www.jollen.org/blog/2009/02/compile_neo_freerunner_kernel.html blog post] in Chinese. It might contain errors introduced in the translation.&lt;br /&gt;
&amp;lt;/strong&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''This isn't working. Use these instructions [http://wiki.openmoko.org/wiki/Kernel#Building_the_andy-tracking_branch] instead'''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
See also : [http://wiki.openmoko.org/wiki/Toolchain#Building_Openmoko_Kernel_from_git_repo_using_Toolchain Building Openmoko Kernel from git repo using Toolchain]&lt;br /&gt;
&lt;br /&gt;
How does one compile Openmoko's kernel for the Neo Freerunner? Just follow the steps outlined below.&lt;br /&gt;
&lt;br /&gt;
=Get the Neo Freerunner's kernel source code=&lt;br /&gt;
All source code of the Openmoko project is kept at git.openmoko.org. Under the kernel source code directory you can find both the complete kernel and the branch under development. First issue the following command, which will retreive all the kernel source code.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
$ git clone git://git.openmoko.org/git/kernel.git linux-2.6&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The source code is all put in the linux-2.6/ directory.&lt;br /&gt;
&lt;br /&gt;
=Get Andy's branch=&lt;br /&gt;
Andy is Openmoko's kernel developer. We want to use the development version, so we need to get Andy's branch. Openmoko's kernel developer can at any time add new code to the development version. Openmoko's kernel can also merge with the mainline kernel. [Translator note: I'm note sure if he means that Openmoko will follow changes in mainline, or that mainline will incorporate Openmoko's patches. (Openmoko 的 kernel 也會與 mainline 的 kernel 做合併（patch merge）的動作)]&lt;br /&gt;
Get Andy's branch with the following commands:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
$ cd linux-2.6&lt;br /&gt;
$ git checkout origin/andy-tracking&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=Get the GTA02 kernel configuration file=&lt;br /&gt;
Openmoko provides kernel configuration files for GTA01/GTA02/GTA03. Simply using the GTA02 (Neo Freerunner) configuration file will do. You don't need to configure the kernel options yourself.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
$ cp arch/arm/configs/gta02-moredrivers-defconfig .config&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=Get the Openmoko toolchain=&lt;br /&gt;
To compile the kernel you'll need the 'cross toolchain'. Openmoko provides a ARM9 toolchain that's set up in advance. Pleaes download it from [http://downloads.openmoko.org/developer/toolchains/]. Download the 20080916 version, for example openmoko-i686-20080916-arm-linux-gnueabi-toolchain.tar.bz2 .&lt;br /&gt;
&lt;br /&gt;
To install the toolchain, go to the root directory and uncompress the package.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
$ cd /&lt;br /&gt;
$ sudo tar jxf /openmoko-i686-20080916-arm-linux-gnueabi-toolchain.tar.bz2&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
After unpacking, you will find the toolchain in /usr/local/openmoko .&lt;br /&gt;
&lt;br /&gt;
=Download build-kernel.sh/build-image.sh/mkimage=&lt;br /&gt;
From [http://people.openmoko.org/jollen/openmoko-kernel/] download the two scripts as well as mkimage tool. Place them in the kernel source directory. Don't forget to make them executable.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
$ chmod a+x build-*.sh&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Additionally, after setting the executable bit on mkimage, move it to the system's standard location.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
$ chmod a+x mkimage&lt;br /&gt;
$ sudo mv mkimage /usr/sbin&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Neo Freerunner uses the U-boot boot loader, so we have to use mkimage to pack the kernel image in the U-boot format. The source code of this tool can be found in the U-boot sources.&lt;br /&gt;
&lt;br /&gt;
=Start compiling the kernel=&lt;br /&gt;
First isue build-kernel.sh to compile the kernel:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
$ ./build-kernel.sh&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
After the compile finishes, run build-image.sh to produce the final image:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
$ ./build-image.sh&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When it finishes you can find the file 'uImage-GTA02.bin' in the kernel source directory. &lt;br /&gt;
This is a kernel image that supports the Neo Freerunner. All that's left to do is flash it to your Neo using dfu-util.&lt;br /&gt;
&lt;br /&gt;
If you have any questions about the above instructions you can pose your questions at the [http://openmoko-tw.net/ Traditional Chinese Openmoko Site].&lt;br /&gt;
&lt;br /&gt;
[[Category:Advanced End User]]&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel</id>
		<title>Kernel</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel"/>
				<updated>2009-04-20T19:42:48Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: /* Known issues */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Kernel}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Things changed ==&lt;br /&gt;
&lt;br /&gt;
This page will be updated soon. Those are the current [[Kernel_Plans|Kernel plans]].&lt;br /&gt;
&lt;br /&gt;
== Is this page meant for you? ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Sister pages ===&lt;br /&gt;
&lt;br /&gt;
# [[Kernel branches]].&lt;br /&gt;
&lt;br /&gt;
== Sources ==&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
&lt;br /&gt;
http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
&lt;br /&gt;
[http://git-scm.com 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
If you are very new to GIT you might want to read [http://git.or.cz/course/ the good manuals that already available].&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
=== Branches ===&lt;br /&gt;
&lt;br /&gt;
GIT allow developers to use different [[Kernel_branches|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 (http://git.openmoko.org/?p=kernel.git;a=summary).&lt;br /&gt;
&lt;br /&gt;
The ''andy-tracking'' branch is the one where most of the action takes place these days. &lt;br /&gt;
&lt;br /&gt;
We have [[Kernel_branches|branch policies]] that explain what each branch is for.&lt;br /&gt;
&lt;br /&gt;
=== Daily builds ===&lt;br /&gt;
&lt;br /&gt;
==== Automatic revisions ====&lt;br /&gt;
&lt;br /&gt;
Think of a robot that takes whatever kernels are the most recent in GIT, builds them for you and then makes them available here:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/experimental/&lt;br /&gt;
&lt;br /&gt;
==== Blessed revisions ====&lt;br /&gt;
&lt;br /&gt;
Another robot but this one only builds the versions picked by our friendly [[OpenEmbedded]] developers. Download from:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/unstable/&lt;br /&gt;
&lt;br /&gt;
If you understand OpenEmbedded you will get this: Those versions are tied to a specific GIT revision through conf/distro/include/sane-srcrevs.bb.&lt;br /&gt;
&lt;br /&gt;
=== Building the andy-tracking branch ===&lt;br /&gt;
&lt;br /&gt;
Those are the minimum survival commands:&lt;br /&gt;
&lt;br /&gt;
 $ git clone git://git.openmoko.org/git/kernel.git linux-2.6&lt;br /&gt;
 $ cd linux-2.6&lt;br /&gt;
 $ git-checkout --track -b andy-tracking origin/andy-tracking&lt;br /&gt;
 $ mkdir GTA02 &lt;br /&gt;
 $ cp ./arch/arm/configs/gta02_moredrivers_defconfig GTA02/.config&lt;br /&gt;
&lt;br /&gt;
Before building this kernel you need install a [http://wiki.openmoko.org/wiki/Toolchain#Downloading_and_installing Toolchain].&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
In order to build the modules you can:&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02 dummy&lt;br /&gt;
&lt;br /&gt;
This will create a file called modules-GTA02_andy-tracking-&amp;lt;git hash&amp;gt;.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.&lt;br /&gt;
&lt;br /&gt;
If you want to update the local copy of the repository so that you get the latest changes, you can type:&lt;br /&gt;
&lt;br /&gt;
 $ git-pull&lt;br /&gt;
&lt;br /&gt;
Before reporting that the new kernel does not build please first check for changes in the configuration file provided by Openmoko.&lt;br /&gt;
&lt;br /&gt;
=== kernel building tips ===&lt;br /&gt;
&lt;br /&gt;
If you are modifying Linux kernel code and building it quite often you really want to be using [http://ccache.samba.org ccache]. It will save you a lot of time.&lt;br /&gt;
&lt;br /&gt;
TODO: submit a patch for the build script that makes ccache use easier. '''Note''': There is a [http://lists.openmoko.org/pipermail/openmoko-kernel/2009-March/009139.html patch being reviewed].&lt;br /&gt;
&lt;br /&gt;
== Contributing ==&lt;br /&gt;
&lt;br /&gt;
The development resources [[Openmoko]] offers are:&lt;br /&gt;
&lt;br /&gt;
* Git repository: http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
* [http://lists.openmoko.org/mailman/listinfo/openmoko-kernel Mailing list] ([http://lists.openmoko.org/pipermail/openmoko-kernel/ Online Archive])&lt;br /&gt;
&lt;br /&gt;
We appreciate your contributions. Check the Open Issues at the end of this page to check where we need more help.&lt;br /&gt;
&lt;br /&gt;
If in doubt ask in the mailing list.&lt;br /&gt;
&lt;br /&gt;
== FAQ ==&lt;br /&gt;
&lt;br /&gt;
=== Why does Openmoko cares about sending code upstream instead of (insert your task here)? ===&lt;br /&gt;
&lt;br /&gt;
There are two very different approaches and both of them would be doomed if we committed all our resources to only one of them.&lt;br /&gt;
&lt;br /&gt;
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 [http://www.kernel.org upstream] where the people who want to help us improve, maintain and support the code running in our devices, hang out.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Who's Andy and why is he sticking his name in the kernel? ===&lt;br /&gt;
&lt;br /&gt;
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&lt;br /&gt;
&lt;br /&gt;
Check [[Kernel_branches]] if you care about the details.&lt;br /&gt;
&lt;br /&gt;
=== Kernel developers are not polite! They do not even care to say &amp;quot;Hello&amp;quot; when they reply to my emails! ===&lt;br /&gt;
&lt;br /&gt;
The long version is here: [[Kernel-developers-are-not-polite]].&lt;br /&gt;
&lt;br /&gt;
To the point:&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
They just tend to write very short text because they have to read and write a lot every day.&lt;br /&gt;
&lt;br /&gt;
== Known issues ==&lt;br /&gt;
&lt;br /&gt;
=== Sysfs paths ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[FSO]] developers realized that this problem could be prevented from from happening in the future and they decided to code a nice daemon called [http://www.freesmartphone.org/index.php/Implementations/OpenDeviceDaemon odeviced].&lt;br /&gt;
&lt;br /&gt;
=== WSOD with u-boot ===&lt;br /&gt;
&lt;br /&gt;
There is work in progress to fix this issue that does not happen with Qi. Latest kernel from andy-tracking.&lt;br /&gt;
&lt;br /&gt;
== Open Tickets ==&lt;br /&gt;
&lt;br /&gt;
'''This&lt;br /&gt;
[http://docs.openmoko.org/trac/query?status=in_testing&amp;amp;status=reopened&amp;amp;status=assigned&amp;amp;status=new&amp;amp;status=accepted&amp;amp;group=status&amp;amp;milestone=stable-kernel-2009.1 report] will show the bugs that are a priority for us now'''.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Please read [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component this report]''' if you wish to know what the current issues are.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Easy bugs ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
TODO: list of bugs linking to trac.&lt;br /&gt;
&lt;br /&gt;
=== Normal bugs ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
'''This is the complete [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component report]''' with all the bugs (some of them might be invalid).&lt;br /&gt;
&lt;br /&gt;
=== Hard bugs ===&lt;br /&gt;
&lt;br /&gt;
Those are the evil bugs that we haven't fixed either because:&lt;br /&gt;
&lt;br /&gt;
# We do not know how to do it in reasonable time&lt;br /&gt;
# 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)&lt;br /&gt;
# More testing is needed (perhaps a hard-to-reproduce bug)&lt;br /&gt;
&lt;br /&gt;
Here is the list:&lt;br /&gt;
&lt;br /&gt;
* [https://docs.openmoko.org/trac/ticket/2235 #2235 : Monochrome display on resume]&lt;br /&gt;
&lt;br /&gt;
{{Languages|Kernel}}&lt;br /&gt;
&lt;br /&gt;
[[Category:Kernel]]&lt;br /&gt;
[[Category:System Developers]]&lt;br /&gt;
[[Category:Application Developer]]&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel_branches</id>
		<title>Kernel branches</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel_branches"/>
				<updated>2009-04-17T15:12:37Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: /* Introduction */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
&lt;br /&gt;
This page explains how we take advantage of GIT branches for kernel development at Openmoko. The [[Kernel]] page is the sister of this page.&lt;br /&gt;
&lt;br /&gt;
'''Note''': At the moment we are only using the andy-tracking branch. This will change soon.&lt;br /&gt;
&lt;br /&gt;
=== How we use GIT History ===&lt;br /&gt;
&lt;br /&gt;
The branches whose names end in -tracking have a history in GIT. This history allows us to go back and to check who did what and when it happened.&lt;br /&gt;
&lt;br /&gt;
Committed patches appear directly on the branch they were&lt;br /&gt;
committed on.  If a patch goes into stable-tracking it will appear&lt;br /&gt;
there as normal, but what appears in the downstream branches rebasing&lt;br /&gt;
off that is a single MERGE commit that contains whatever the diff is&lt;br /&gt;
between the unrebased and rebased version of that branch. Since Andy&lt;br /&gt;
rebases very often, it will not be unusual that the MERGE version used&lt;br /&gt;
downstream is just the one added upstream patch content, but it can also&lt;br /&gt;
be typical that the MERGE commit will contain the changes from dozens or&lt;br /&gt;
hundreds of patches when the Linus tree updates or example.&lt;br /&gt;
&lt;br /&gt;
The reason for this new way is that it gives the public -tracking&lt;br /&gt;
branches a linear history that you can rewind, despite that they are&lt;br /&gt;
being hard rebased constantly.&lt;br /&gt;
&lt;br /&gt;
== andy-tracking ==&lt;br /&gt;
&lt;br /&gt;
We will fork stable kernels from this branch.&lt;br /&gt;
&lt;br /&gt;
Think of this as the branch where most of the action takes place (at least for most of us).&lt;br /&gt;
If you simply target andy-tracking for patches, the resulting patch will&lt;br /&gt;
automatically be ready for either andy-tracking, pending-tracking&lt;br /&gt;
(usually) or stable-tracking depending on what it touched.&lt;br /&gt;
&lt;br /&gt;
If in doubt ask in the [http://lists.openmoko.org/mailman/listinfo/openmoko-kernel mailing list].&lt;br /&gt;
&lt;br /&gt;
== pending-tracking ==&lt;br /&gt;
&lt;br /&gt;
We can end up with a bunch of patches from several&lt;br /&gt;
directions heading into various upstreams if we're lucky.&lt;br /&gt;
&lt;br /&gt;
We have a &amp;quot;pending-tracking&amp;quot; that fits in between stable-tracking and&lt;br /&gt;
andy-tracking, to temporarily hold all the patches that are expected to&lt;br /&gt;
come from upstream eventually.  Balaji-tracking feeds into this now, but&lt;br /&gt;
there's other stuff like Matt's patches headed for s3c64xx upstream too.&lt;br /&gt;
&lt;br /&gt;
This allows for Balaji's patches being rebased without writing&lt;br /&gt;
in balaji-tracking, and it also allows Andy to track changes from&lt;br /&gt;
balaji-tracking and elsewhere in one place too.&lt;br /&gt;
&lt;br /&gt;
== Some patch work-flow before introducing stable-trackig ==&lt;br /&gt;
&lt;br /&gt;
Patch belongs in upstream, eg, Linus or Ben Dooks tree --&amp;gt;&lt;br /&gt;
pending-tracking.  It's kept segregated because we expect it to turn up&lt;br /&gt;
by upstream rebase path; if it changes on the way we can adapt it in&lt;br /&gt;
pending-tracking and rebase&lt;br /&gt;
&lt;br /&gt;
Patch bases on stuff in pending-tracking, eg uses Balaji regulator&lt;br /&gt;
things  ---&amp;gt;  andy-tracking.  It's kept segregated because &amp;quot;it lives in&lt;br /&gt;
the future&amp;quot; where the pending upstream patches arrived upstream.&lt;br /&gt;
&lt;br /&gt;
Neither of the above ---&amp;gt; stable-tracking&lt;br /&gt;
&lt;br /&gt;
== stable-tracking ==&lt;br /&gt;
&lt;br /&gt;
All patches end up in this branch, that's what it expects.&lt;br /&gt;
&lt;br /&gt;
Stuff temporarily in pending-tracking will eventually turn up from&lt;br /&gt;
upstream pulls, at that time it's no longer pending and is part of what&lt;br /&gt;
stable-tracking rebased against.  The now duplicate patch in&lt;br /&gt;
pending-tracking is then removed.  The patch ended up in stable-tracking.&lt;br /&gt;
&lt;br /&gt;
Once the pending-tracking patch became part of stable-tracking, there is&lt;br /&gt;
no reason for the patches modifying or depending on it held until now in&lt;br /&gt;
andy-tracking not to merge back into stable-tracking either.  So patches&lt;br /&gt;
in andy-tracking gravitate to stable-tracking as soon as possible too.&lt;br /&gt;
&lt;br /&gt;
== More patch work-flow ==&lt;br /&gt;
&lt;br /&gt;
Because andy-tracking is &amp;quot;living in the future&amp;quot; with latest pending&lt;br /&gt;
upstream patches included, it makes sense to take the advantage from&lt;br /&gt;
these even at the risk the patches will be rejected upstream.&lt;br /&gt;
&lt;br /&gt;
== proposed ==&lt;br /&gt;
&lt;br /&gt;
This is a temporal branch with no history. We use it as a temporal playground so that we can get patches ready for upstream.&lt;br /&gt;
&lt;br /&gt;
== Credits ==&lt;br /&gt;
&lt;br /&gt;
This page started as an improvement of [http://lists.openmoko.org/pipermail/openmoko-kernel/2008-November/006945.html this email] sent by Andy Green to the [[Openmoko]] kernel list.&lt;br /&gt;
&lt;br /&gt;
{{Languages|Kernel_branches}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Category:Kernel]]&lt;br /&gt;
[[Category:System Developers]]&lt;br /&gt;
[[Category:Application Developer]]&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel</id>
		<title>Kernel</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel"/>
				<updated>2009-04-14T08:20:31Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: /* Normal bugs */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Kernel}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Things changed ==&lt;br /&gt;
&lt;br /&gt;
This page will be updated soon. Those are the current [[Kernel_Plans|Kernel plans]].&lt;br /&gt;
&lt;br /&gt;
== Is this page meant for you? ==&lt;br /&gt;
&lt;br /&gt;
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 for you. You might want to scroll down for the for the blessed kernels in the daily builds.&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Sister pages ===&lt;br /&gt;
&lt;br /&gt;
# [[Kernel_branches]].&lt;br /&gt;
&lt;br /&gt;
== Sources ==&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
&lt;br /&gt;
http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
&lt;br /&gt;
[http://git-scm.com 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
If you are very new to GIT you might want to read [http://git.or.cz/course/ the good manuals that already available].&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
=== Branches ===&lt;br /&gt;
&lt;br /&gt;
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 (http://git.openmoko.org/?p=kernel.git;a=summary).&lt;br /&gt;
&lt;br /&gt;
The ''andy-tracking'' branch is the one where most of the action takes place these days. &lt;br /&gt;
&lt;br /&gt;
We have [[Kernel_branches|branch policies]] that explain what each branch is for.&lt;br /&gt;
&lt;br /&gt;
=== Daily builds ===&lt;br /&gt;
&lt;br /&gt;
==== Automatic revisions ====&lt;br /&gt;
&lt;br /&gt;
Think of a robot that takes whatever kernels are the most recent in GIT, builds them for you and then makes them available here:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/experimental/&lt;br /&gt;
&lt;br /&gt;
==== Blessed revisions ====&lt;br /&gt;
&lt;br /&gt;
Another robot but this one only builds the versions picked by our friendly [[OpenEmbedded]] developers. Download from:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/unstable/&lt;br /&gt;
&lt;br /&gt;
If you understand OpenEmbedded you will get this: Those versions are tied to a specific GIT revision through conf/distro/include/sane-srcrevs.bb.&lt;br /&gt;
&lt;br /&gt;
=== Building the andy-tracking branch ===&lt;br /&gt;
&lt;br /&gt;
Those are the minimum survival commands:&lt;br /&gt;
&lt;br /&gt;
 $ git clone git://git.openmoko.org/git/kernel.git linux-2.6&lt;br /&gt;
 $ cd linux-2.6&lt;br /&gt;
 $ git-checkout --track -b andy-tracking origin/andy-tracking&lt;br /&gt;
 $ mkdir GTA02 &lt;br /&gt;
 $ cp ./arch/arm/configs/gta02_moredrivers_defconfig GTA02/.config&lt;br /&gt;
&lt;br /&gt;
Before building this kernel you need install a [http://wiki.openmoko.org/wiki/Toolchain#Downloading_and_installing Toolchain].&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
In order to build the modules you can:&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02 dummy&lt;br /&gt;
&lt;br /&gt;
This will create a file called modules-GTA02_andy-tracking-&amp;lt;git hash&amp;gt;.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.&lt;br /&gt;
&lt;br /&gt;
If you want to update the local copy of the repository so that you get the latest changes, you can type:&lt;br /&gt;
&lt;br /&gt;
 $ git-pull&lt;br /&gt;
&lt;br /&gt;
Before reporting that the new kernel does not build please first check for changes in the configuration file provided by Openmoko.&lt;br /&gt;
&lt;br /&gt;
=== kernel building tips ===&lt;br /&gt;
&lt;br /&gt;
If you are modifying Linux kernel code and building it quite often you really want to be using [http://ccache.samba.org ccache]. It will save you a lot of time.&lt;br /&gt;
&lt;br /&gt;
TODO: submit a patch for the build script that makes ccache use easier. '''Note''': There is a [http://lists.openmoko.org/pipermail/openmoko-kernel/2009-March/009139.html patch being reviewed].&lt;br /&gt;
&lt;br /&gt;
== Contributing ==&lt;br /&gt;
&lt;br /&gt;
The development resources [[Openmoko]] offers are:&lt;br /&gt;
&lt;br /&gt;
* Git repository: http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
* [http://lists.openmoko.org/mailman/listinfo/openmoko-kernel Mailing list] ([http://lists.openmoko.org/pipermail/openmoko-kernel/ Online Archive])&lt;br /&gt;
&lt;br /&gt;
We appreciate your contributions. Check the Open Issues at the end of this page to check where we need more help.&lt;br /&gt;
&lt;br /&gt;
If in doubt ask in the mailing list.&lt;br /&gt;
&lt;br /&gt;
== FAQ ==&lt;br /&gt;
&lt;br /&gt;
=== Why does Openmoko cares about sending code upstream instead of (insert your task here)? ===&lt;br /&gt;
&lt;br /&gt;
There are two very different approaches and both of them would be doomed if we stuck all our resources to only one of to them.&lt;br /&gt;
&lt;br /&gt;
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 [http://www.kernel.org upstream] where the people who want to help us improve, maintain and support the code running in our devices hang out.&lt;br /&gt;
&lt;br /&gt;
The second is to care way '''too much''' about upstream to the point that we are not willing to ship a temporal dirty hack that make users happy and able to better use their phones. We cannot afford that kind of purity.&lt;br /&gt;
&lt;br /&gt;
As many things in engineering we have to find a point in the middle that works well -- we will try hard to do it.&lt;br /&gt;
&lt;br /&gt;
=== Who's Andy and why is he sticking his name in the kernel? ===&lt;br /&gt;
&lt;br /&gt;
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&lt;br /&gt;
&lt;br /&gt;
Check [[Kernel_branches]] if you care about the details.&lt;br /&gt;
&lt;br /&gt;
=== Kernel developers are not polite! They do not even care to say &amp;quot;Hello&amp;quot; when they reply to my emails! ===&lt;br /&gt;
&lt;br /&gt;
The long version is here: [[Kernel-developers-are-not-polite]].&lt;br /&gt;
&lt;br /&gt;
To the point:&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
They just tend to write very short text because they have to read and write a lot every day.&lt;br /&gt;
&lt;br /&gt;
== Known issues ==&lt;br /&gt;
&lt;br /&gt;
=== Sysfs paths ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[FSO]] developers realized that this problem could be prevented from from happening in the future and they decided to code a nice daemon called [http://www.freesmartphone.org/index.php/Implementations/OpenDeviceDaemon odeviced].&lt;br /&gt;
&lt;br /&gt;
== Open Tickets ==&lt;br /&gt;
&lt;br /&gt;
'''This&lt;br /&gt;
[http://docs.openmoko.org/trac/query?status=in_testing&amp;amp;status=reopened&amp;amp;status=assigned&amp;amp;status=new&amp;amp;status=accepted&amp;amp;group=status&amp;amp;milestone=stable-kernel-2009.1 report] will show the bugs that are a priority for us now'''.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Please read [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component this report]''' if you wish to know what the current issues are.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Easy bugs ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
TODO: list of bugs linking to trac.&lt;br /&gt;
&lt;br /&gt;
=== Normal bugs ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
'''This is the complete [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component report]''' with all the bugs (some of them might be invalid).&lt;br /&gt;
&lt;br /&gt;
=== Hard bugs ===&lt;br /&gt;
&lt;br /&gt;
Those are the evil bugs that we haven't fixed either because:&lt;br /&gt;
&lt;br /&gt;
# We do not know how to do it in reasonable time&lt;br /&gt;
# 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)&lt;br /&gt;
# More testing is needed (perhaps a hard-to-reproduce bug)&lt;br /&gt;
&lt;br /&gt;
Here is the list:&lt;br /&gt;
&lt;br /&gt;
* [https://docs.openmoko.org/trac/ticket/2235 #2235 : Monochrome display on resume]&lt;br /&gt;
&lt;br /&gt;
{{Languages|Kernel}}&lt;br /&gt;
&lt;br /&gt;
[[Category:Kernel]]&lt;br /&gt;
[[Category:System Developers]]&lt;br /&gt;
[[Category:Application Developer]]&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel</id>
		<title>Kernel</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel"/>
				<updated>2009-04-14T08:19:51Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: /* Open Tickets */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Kernel}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Things changed ==&lt;br /&gt;
&lt;br /&gt;
This page will be updated soon. Those are the current [[Kernel_Plans|Kernel plans]].&lt;br /&gt;
&lt;br /&gt;
== Is this page meant for you? ==&lt;br /&gt;
&lt;br /&gt;
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 for you. You might want to scroll down for the for the blessed kernels in the daily builds.&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Sister pages ===&lt;br /&gt;
&lt;br /&gt;
# [[Kernel_branches]].&lt;br /&gt;
&lt;br /&gt;
== Sources ==&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
&lt;br /&gt;
http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
&lt;br /&gt;
[http://git-scm.com 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
If you are very new to GIT you might want to read [http://git.or.cz/course/ the good manuals that already available].&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
=== Branches ===&lt;br /&gt;
&lt;br /&gt;
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 (http://git.openmoko.org/?p=kernel.git;a=summary).&lt;br /&gt;
&lt;br /&gt;
The ''andy-tracking'' branch is the one where most of the action takes place these days. &lt;br /&gt;
&lt;br /&gt;
We have [[Kernel_branches|branch policies]] that explain what each branch is for.&lt;br /&gt;
&lt;br /&gt;
=== Daily builds ===&lt;br /&gt;
&lt;br /&gt;
==== Automatic revisions ====&lt;br /&gt;
&lt;br /&gt;
Think of a robot that takes whatever kernels are the most recent in GIT, builds them for you and then makes them available here:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/experimental/&lt;br /&gt;
&lt;br /&gt;
==== Blessed revisions ====&lt;br /&gt;
&lt;br /&gt;
Another robot but this one only builds the versions picked by our friendly [[OpenEmbedded]] developers. Download from:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/unstable/&lt;br /&gt;
&lt;br /&gt;
If you understand OpenEmbedded you will get this: Those versions are tied to a specific GIT revision through conf/distro/include/sane-srcrevs.bb.&lt;br /&gt;
&lt;br /&gt;
=== Building the andy-tracking branch ===&lt;br /&gt;
&lt;br /&gt;
Those are the minimum survival commands:&lt;br /&gt;
&lt;br /&gt;
 $ git clone git://git.openmoko.org/git/kernel.git linux-2.6&lt;br /&gt;
 $ cd linux-2.6&lt;br /&gt;
 $ git-checkout --track -b andy-tracking origin/andy-tracking&lt;br /&gt;
 $ mkdir GTA02 &lt;br /&gt;
 $ cp ./arch/arm/configs/gta02_moredrivers_defconfig GTA02/.config&lt;br /&gt;
&lt;br /&gt;
Before building this kernel you need install a [http://wiki.openmoko.org/wiki/Toolchain#Downloading_and_installing Toolchain].&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
In order to build the modules you can:&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02 dummy&lt;br /&gt;
&lt;br /&gt;
This will create a file called modules-GTA02_andy-tracking-&amp;lt;git hash&amp;gt;.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.&lt;br /&gt;
&lt;br /&gt;
If you want to update the local copy of the repository so that you get the latest changes, you can type:&lt;br /&gt;
&lt;br /&gt;
 $ git-pull&lt;br /&gt;
&lt;br /&gt;
Before reporting that the new kernel does not build please first check for changes in the configuration file provided by Openmoko.&lt;br /&gt;
&lt;br /&gt;
=== kernel building tips ===&lt;br /&gt;
&lt;br /&gt;
If you are modifying Linux kernel code and building it quite often you really want to be using [http://ccache.samba.org ccache]. It will save you a lot of time.&lt;br /&gt;
&lt;br /&gt;
TODO: submit a patch for the build script that makes ccache use easier. '''Note''': There is a [http://lists.openmoko.org/pipermail/openmoko-kernel/2009-March/009139.html patch being reviewed].&lt;br /&gt;
&lt;br /&gt;
== Contributing ==&lt;br /&gt;
&lt;br /&gt;
The development resources [[Openmoko]] offers are:&lt;br /&gt;
&lt;br /&gt;
* Git repository: http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
* [http://lists.openmoko.org/mailman/listinfo/openmoko-kernel Mailing list] ([http://lists.openmoko.org/pipermail/openmoko-kernel/ Online Archive])&lt;br /&gt;
&lt;br /&gt;
We appreciate your contributions. Check the Open Issues at the end of this page to check where we need more help.&lt;br /&gt;
&lt;br /&gt;
If in doubt ask in the mailing list.&lt;br /&gt;
&lt;br /&gt;
== FAQ ==&lt;br /&gt;
&lt;br /&gt;
=== Why does Openmoko cares about sending code upstream instead of (insert your task here)? ===&lt;br /&gt;
&lt;br /&gt;
There are two very different approaches and both of them would be doomed if we stuck all our resources to only one of to them.&lt;br /&gt;
&lt;br /&gt;
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 [http://www.kernel.org upstream] where the people who want to help us improve, maintain and support the code running in our devices hang out.&lt;br /&gt;
&lt;br /&gt;
The second is to care way '''too much''' about upstream to the point that we are not willing to ship a temporal dirty hack that make users happy and able to better use their phones. We cannot afford that kind of purity.&lt;br /&gt;
&lt;br /&gt;
As many things in engineering we have to find a point in the middle that works well -- we will try hard to do it.&lt;br /&gt;
&lt;br /&gt;
=== Who's Andy and why is he sticking his name in the kernel? ===&lt;br /&gt;
&lt;br /&gt;
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&lt;br /&gt;
&lt;br /&gt;
Check [[Kernel_branches]] if you care about the details.&lt;br /&gt;
&lt;br /&gt;
=== Kernel developers are not polite! They do not even care to say &amp;quot;Hello&amp;quot; when they reply to my emails! ===&lt;br /&gt;
&lt;br /&gt;
The long version is here: [[Kernel-developers-are-not-polite]].&lt;br /&gt;
&lt;br /&gt;
To the point:&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
They just tend to write very short text because they have to read and write a lot every day.&lt;br /&gt;
&lt;br /&gt;
== Known issues ==&lt;br /&gt;
&lt;br /&gt;
=== Sysfs paths ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[FSO]] developers realized that this problem could be prevented from from happening in the future and they decided to code a nice daemon called [http://www.freesmartphone.org/index.php/Implementations/OpenDeviceDaemon odeviced].&lt;br /&gt;
&lt;br /&gt;
== Open Tickets ==&lt;br /&gt;
&lt;br /&gt;
'''This&lt;br /&gt;
[http://docs.openmoko.org/trac/query?status=in_testing&amp;amp;status=reopened&amp;amp;status=assigned&amp;amp;status=new&amp;amp;status=accepted&amp;amp;group=status&amp;amp;milestone=stable-kernel-2009.1 report] will show the bugs that are a priority for us now'''.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Please read [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component this report]''' if you wish to know what the current issues are.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Easy bugs ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
TODO: list of bugs linking to trac.&lt;br /&gt;
&lt;br /&gt;
=== Normal bugs ===&lt;br /&gt;
&lt;br /&gt;
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. Please do not add a list &lt;br /&gt;
&lt;br /&gt;
'''This is the complete [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component report]''' with all the bugs (some of them might be invalid).&lt;br /&gt;
&lt;br /&gt;
=== Hard bugs ===&lt;br /&gt;
&lt;br /&gt;
Those are the evil bugs that we haven't fixed either because:&lt;br /&gt;
&lt;br /&gt;
# We do not know how to do it in reasonable time&lt;br /&gt;
# 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)&lt;br /&gt;
# More testing is needed (perhaps a hard-to-reproduce bug)&lt;br /&gt;
&lt;br /&gt;
Here is the list:&lt;br /&gt;
&lt;br /&gt;
* [https://docs.openmoko.org/trac/ticket/2235 #2235 : Monochrome display on resume]&lt;br /&gt;
&lt;br /&gt;
{{Languages|Kernel}}&lt;br /&gt;
&lt;br /&gt;
[[Category:Kernel]]&lt;br /&gt;
[[Category:System Developers]]&lt;br /&gt;
[[Category:Application Developer]]&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel</id>
		<title>Kernel</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel"/>
				<updated>2009-04-14T08:19:19Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: /* Normal bugs */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Kernel}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Things changed ==&lt;br /&gt;
&lt;br /&gt;
This page will be updated soon. Those are the current [[Kernel_Plans|Kernel plans]].&lt;br /&gt;
&lt;br /&gt;
== Is this page meant for you? ==&lt;br /&gt;
&lt;br /&gt;
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 for you. You might want to scroll down for the for the blessed kernels in the daily builds.&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Sister pages ===&lt;br /&gt;
&lt;br /&gt;
# [[Kernel_branches]].&lt;br /&gt;
&lt;br /&gt;
== Sources ==&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
&lt;br /&gt;
http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
&lt;br /&gt;
[http://git-scm.com 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
If you are very new to GIT you might want to read [http://git.or.cz/course/ the good manuals that already available].&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
=== Branches ===&lt;br /&gt;
&lt;br /&gt;
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 (http://git.openmoko.org/?p=kernel.git;a=summary).&lt;br /&gt;
&lt;br /&gt;
The ''andy-tracking'' branch is the one where most of the action takes place these days. &lt;br /&gt;
&lt;br /&gt;
We have [[Kernel_branches|branch policies]] that explain what each branch is for.&lt;br /&gt;
&lt;br /&gt;
=== Daily builds ===&lt;br /&gt;
&lt;br /&gt;
==== Automatic revisions ====&lt;br /&gt;
&lt;br /&gt;
Think of a robot that takes whatever kernels are the most recent in GIT, builds them for you and then makes them available here:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/experimental/&lt;br /&gt;
&lt;br /&gt;
==== Blessed revisions ====&lt;br /&gt;
&lt;br /&gt;
Another robot but this one only builds the versions picked by our friendly [[OpenEmbedded]] developers. Download from:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/unstable/&lt;br /&gt;
&lt;br /&gt;
If you understand OpenEmbedded you will get this: Those versions are tied to a specific GIT revision through conf/distro/include/sane-srcrevs.bb.&lt;br /&gt;
&lt;br /&gt;
=== Building the andy-tracking branch ===&lt;br /&gt;
&lt;br /&gt;
Those are the minimum survival commands:&lt;br /&gt;
&lt;br /&gt;
 $ git clone git://git.openmoko.org/git/kernel.git linux-2.6&lt;br /&gt;
 $ cd linux-2.6&lt;br /&gt;
 $ git-checkout --track -b andy-tracking origin/andy-tracking&lt;br /&gt;
 $ mkdir GTA02 &lt;br /&gt;
 $ cp ./arch/arm/configs/gta02_moredrivers_defconfig GTA02/.config&lt;br /&gt;
&lt;br /&gt;
Before building this kernel you need install a [http://wiki.openmoko.org/wiki/Toolchain#Downloading_and_installing Toolchain].&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
In order to build the modules you can:&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02 dummy&lt;br /&gt;
&lt;br /&gt;
This will create a file called modules-GTA02_andy-tracking-&amp;lt;git hash&amp;gt;.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.&lt;br /&gt;
&lt;br /&gt;
If you want to update the local copy of the repository so that you get the latest changes, you can type:&lt;br /&gt;
&lt;br /&gt;
 $ git-pull&lt;br /&gt;
&lt;br /&gt;
Before reporting that the new kernel does not build please first check for changes in the configuration file provided by Openmoko.&lt;br /&gt;
&lt;br /&gt;
=== kernel building tips ===&lt;br /&gt;
&lt;br /&gt;
If you are modifying Linux kernel code and building it quite often you really want to be using [http://ccache.samba.org ccache]. It will save you a lot of time.&lt;br /&gt;
&lt;br /&gt;
TODO: submit a patch for the build script that makes ccache use easier. '''Note''': There is a [http://lists.openmoko.org/pipermail/openmoko-kernel/2009-March/009139.html patch being reviewed].&lt;br /&gt;
&lt;br /&gt;
== Contributing ==&lt;br /&gt;
&lt;br /&gt;
The development resources [[Openmoko]] offers are:&lt;br /&gt;
&lt;br /&gt;
* Git repository: http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
* [http://lists.openmoko.org/mailman/listinfo/openmoko-kernel Mailing list] ([http://lists.openmoko.org/pipermail/openmoko-kernel/ Online Archive])&lt;br /&gt;
&lt;br /&gt;
We appreciate your contributions. Check the Open Issues at the end of this page to check where we need more help.&lt;br /&gt;
&lt;br /&gt;
If in doubt ask in the mailing list.&lt;br /&gt;
&lt;br /&gt;
== FAQ ==&lt;br /&gt;
&lt;br /&gt;
=== Why does Openmoko cares about sending code upstream instead of (insert your task here)? ===&lt;br /&gt;
&lt;br /&gt;
There are two very different approaches and both of them would be doomed if we stuck all our resources to only one of to them.&lt;br /&gt;
&lt;br /&gt;
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 [http://www.kernel.org upstream] where the people who want to help us improve, maintain and support the code running in our devices hang out.&lt;br /&gt;
&lt;br /&gt;
The second is to care way '''too much''' about upstream to the point that we are not willing to ship a temporal dirty hack that make users happy and able to better use their phones. We cannot afford that kind of purity.&lt;br /&gt;
&lt;br /&gt;
As many things in engineering we have to find a point in the middle that works well -- we will try hard to do it.&lt;br /&gt;
&lt;br /&gt;
=== Who's Andy and why is he sticking his name in the kernel? ===&lt;br /&gt;
&lt;br /&gt;
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&lt;br /&gt;
&lt;br /&gt;
Check [[Kernel_branches]] if you care about the details.&lt;br /&gt;
&lt;br /&gt;
=== Kernel developers are not polite! They do not even care to say &amp;quot;Hello&amp;quot; when they reply to my emails! ===&lt;br /&gt;
&lt;br /&gt;
The long version is here: [[Kernel-developers-are-not-polite]].&lt;br /&gt;
&lt;br /&gt;
To the point:&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
They just tend to write very short text because they have to read and write a lot every day.&lt;br /&gt;
&lt;br /&gt;
== Known issues ==&lt;br /&gt;
&lt;br /&gt;
=== Sysfs paths ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[FSO]] developers realized that this problem could be prevented from from happening in the future and they decided to code a nice daemon called [http://www.freesmartphone.org/index.php/Implementations/OpenDeviceDaemon odeviced].&lt;br /&gt;
&lt;br /&gt;
== Open Tickets ==&lt;br /&gt;
&lt;br /&gt;
'''Please read [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component this report]''' if you wish to know what the current issues are.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Easy bugs ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
TODO: list of bugs linking to trac.&lt;br /&gt;
&lt;br /&gt;
=== Normal bugs ===&lt;br /&gt;
&lt;br /&gt;
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. Please do not add a list &lt;br /&gt;
&lt;br /&gt;
'''This is the complete [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component report]''' with all the bugs (some of them might be invalid).&lt;br /&gt;
&lt;br /&gt;
=== Hard bugs ===&lt;br /&gt;
&lt;br /&gt;
Those are the evil bugs that we haven't fixed either because:&lt;br /&gt;
&lt;br /&gt;
# We do not know how to do it in reasonable time&lt;br /&gt;
# 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)&lt;br /&gt;
# More testing is needed (perhaps a hard-to-reproduce bug)&lt;br /&gt;
&lt;br /&gt;
Here is the list:&lt;br /&gt;
&lt;br /&gt;
* [https://docs.openmoko.org/trac/ticket/2235 #2235 : Monochrome display on resume]&lt;br /&gt;
&lt;br /&gt;
{{Languages|Kernel}}&lt;br /&gt;
&lt;br /&gt;
[[Category:Kernel]]&lt;br /&gt;
[[Category:System Developers]]&lt;br /&gt;
[[Category:Application Developer]]&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel</id>
		<title>Kernel</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel"/>
				<updated>2009-04-14T08:17:57Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: /* Open Tickets */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Kernel}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Things changed ==&lt;br /&gt;
&lt;br /&gt;
This page will be updated soon. Those are the current [[Kernel_Plans|Kernel plans]].&lt;br /&gt;
&lt;br /&gt;
== Is this page meant for you? ==&lt;br /&gt;
&lt;br /&gt;
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 for you. You might want to scroll down for the for the blessed kernels in the daily builds.&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Sister pages ===&lt;br /&gt;
&lt;br /&gt;
# [[Kernel_branches]].&lt;br /&gt;
&lt;br /&gt;
== Sources ==&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
&lt;br /&gt;
http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
&lt;br /&gt;
[http://git-scm.com 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
If you are very new to GIT you might want to read [http://git.or.cz/course/ the good manuals that already available].&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
=== Branches ===&lt;br /&gt;
&lt;br /&gt;
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 (http://git.openmoko.org/?p=kernel.git;a=summary).&lt;br /&gt;
&lt;br /&gt;
The ''andy-tracking'' branch is the one where most of the action takes place these days. &lt;br /&gt;
&lt;br /&gt;
We have [[Kernel_branches|branch policies]] that explain what each branch is for.&lt;br /&gt;
&lt;br /&gt;
=== Daily builds ===&lt;br /&gt;
&lt;br /&gt;
==== Automatic revisions ====&lt;br /&gt;
&lt;br /&gt;
Think of a robot that takes whatever kernels are the most recent in GIT, builds them for you and then makes them available here:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/experimental/&lt;br /&gt;
&lt;br /&gt;
==== Blessed revisions ====&lt;br /&gt;
&lt;br /&gt;
Another robot but this one only builds the versions picked by our friendly [[OpenEmbedded]] developers. Download from:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/unstable/&lt;br /&gt;
&lt;br /&gt;
If you understand OpenEmbedded you will get this: Those versions are tied to a specific GIT revision through conf/distro/include/sane-srcrevs.bb.&lt;br /&gt;
&lt;br /&gt;
=== Building the andy-tracking branch ===&lt;br /&gt;
&lt;br /&gt;
Those are the minimum survival commands:&lt;br /&gt;
&lt;br /&gt;
 $ git clone git://git.openmoko.org/git/kernel.git linux-2.6&lt;br /&gt;
 $ cd linux-2.6&lt;br /&gt;
 $ git-checkout --track -b andy-tracking origin/andy-tracking&lt;br /&gt;
 $ mkdir GTA02 &lt;br /&gt;
 $ cp ./arch/arm/configs/gta02_moredrivers_defconfig GTA02/.config&lt;br /&gt;
&lt;br /&gt;
Before building this kernel you need install a [http://wiki.openmoko.org/wiki/Toolchain#Downloading_and_installing Toolchain].&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
In order to build the modules you can:&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02 dummy&lt;br /&gt;
&lt;br /&gt;
This will create a file called modules-GTA02_andy-tracking-&amp;lt;git hash&amp;gt;.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.&lt;br /&gt;
&lt;br /&gt;
If you want to update the local copy of the repository so that you get the latest changes, you can type:&lt;br /&gt;
&lt;br /&gt;
 $ git-pull&lt;br /&gt;
&lt;br /&gt;
Before reporting that the new kernel does not build please first check for changes in the configuration file provided by Openmoko.&lt;br /&gt;
&lt;br /&gt;
=== kernel building tips ===&lt;br /&gt;
&lt;br /&gt;
If you are modifying Linux kernel code and building it quite often you really want to be using [http://ccache.samba.org ccache]. It will save you a lot of time.&lt;br /&gt;
&lt;br /&gt;
TODO: submit a patch for the build script that makes ccache use easier. '''Note''': There is a [http://lists.openmoko.org/pipermail/openmoko-kernel/2009-March/009139.html patch being reviewed].&lt;br /&gt;
&lt;br /&gt;
== Contributing ==&lt;br /&gt;
&lt;br /&gt;
The development resources [[Openmoko]] offers are:&lt;br /&gt;
&lt;br /&gt;
* Git repository: http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
* [http://lists.openmoko.org/mailman/listinfo/openmoko-kernel Mailing list] ([http://lists.openmoko.org/pipermail/openmoko-kernel/ Online Archive])&lt;br /&gt;
&lt;br /&gt;
We appreciate your contributions. Check the Open Issues at the end of this page to check where we need more help.&lt;br /&gt;
&lt;br /&gt;
If in doubt ask in the mailing list.&lt;br /&gt;
&lt;br /&gt;
== FAQ ==&lt;br /&gt;
&lt;br /&gt;
=== Why does Openmoko cares about sending code upstream instead of (insert your task here)? ===&lt;br /&gt;
&lt;br /&gt;
There are two very different approaches and both of them would be doomed if we stuck all our resources to only one of to them.&lt;br /&gt;
&lt;br /&gt;
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 [http://www.kernel.org upstream] where the people who want to help us improve, maintain and support the code running in our devices hang out.&lt;br /&gt;
&lt;br /&gt;
The second is to care way '''too much''' about upstream to the point that we are not willing to ship a temporal dirty hack that make users happy and able to better use their phones. We cannot afford that kind of purity.&lt;br /&gt;
&lt;br /&gt;
As many things in engineering we have to find a point in the middle that works well -- we will try hard to do it.&lt;br /&gt;
&lt;br /&gt;
=== Who's Andy and why is he sticking his name in the kernel? ===&lt;br /&gt;
&lt;br /&gt;
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&lt;br /&gt;
&lt;br /&gt;
Check [[Kernel_branches]] if you care about the details.&lt;br /&gt;
&lt;br /&gt;
=== Kernel developers are not polite! They do not even care to say &amp;quot;Hello&amp;quot; when they reply to my emails! ===&lt;br /&gt;
&lt;br /&gt;
The long version is here: [[Kernel-developers-are-not-polite]].&lt;br /&gt;
&lt;br /&gt;
To the point:&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
They just tend to write very short text because they have to read and write a lot every day.&lt;br /&gt;
&lt;br /&gt;
== Known issues ==&lt;br /&gt;
&lt;br /&gt;
=== Sysfs paths ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[FSO]] developers realized that this problem could be prevented from from happening in the future and they decided to code a nice daemon called [http://www.freesmartphone.org/index.php/Implementations/OpenDeviceDaemon odeviced].&lt;br /&gt;
&lt;br /&gt;
== Open Tickets ==&lt;br /&gt;
&lt;br /&gt;
'''Please read [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component this report]''' if you wish to know what the current issues are.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Easy bugs ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
TODO: list of bugs linking to trac.&lt;br /&gt;
&lt;br /&gt;
=== Normal bugs ===&lt;br /&gt;
&lt;br /&gt;
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. Please do not add a list of bugs here.&lt;br /&gt;
&lt;br /&gt;
'''This&lt;br /&gt;
[http://docs.openmoko.org/trac/query?status=in_testing&amp;amp;status=reopened&amp;amp;status=assigned&amp;amp;status=new&amp;amp;status=accepted&amp;amp;group=status&amp;amp;milestone=stable-kernel-2009.1 report] will show the bugs that are a priority now for us'''.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''This is the complete [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component report]''' with all the bugs (some of them might be invalid).&lt;br /&gt;
&lt;br /&gt;
=== Hard bugs ===&lt;br /&gt;
&lt;br /&gt;
Those are the evil bugs that we haven't fixed either because:&lt;br /&gt;
&lt;br /&gt;
# We do not know how to do it in reasonable time&lt;br /&gt;
# 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)&lt;br /&gt;
# More testing is needed (perhaps a hard-to-reproduce bug)&lt;br /&gt;
&lt;br /&gt;
Here is the list:&lt;br /&gt;
&lt;br /&gt;
* [https://docs.openmoko.org/trac/ticket/2235 #2235 : Monochrome display on resume]&lt;br /&gt;
&lt;br /&gt;
{{Languages|Kernel}}&lt;br /&gt;
&lt;br /&gt;
[[Category:Kernel]]&lt;br /&gt;
[[Category:System Developers]]&lt;br /&gt;
[[Category:Application Developer]]&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel</id>
		<title>Kernel</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel"/>
				<updated>2009-04-14T08:15:26Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: /* Who's Andy and why is he sticking his name in the kernel? */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Kernel}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Things changed ==&lt;br /&gt;
&lt;br /&gt;
This page will be updated soon. Those are the current [[Kernel_Plans|Kernel plans]].&lt;br /&gt;
&lt;br /&gt;
== Is this page meant for you? ==&lt;br /&gt;
&lt;br /&gt;
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 for you. You might want to scroll down for the for the blessed kernels in the daily builds.&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Sister pages ===&lt;br /&gt;
&lt;br /&gt;
# [[Kernel_branches]].&lt;br /&gt;
&lt;br /&gt;
== Sources ==&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
&lt;br /&gt;
http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
&lt;br /&gt;
[http://git-scm.com 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
If you are very new to GIT you might want to read [http://git.or.cz/course/ the good manuals that already available].&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
=== Branches ===&lt;br /&gt;
&lt;br /&gt;
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 (http://git.openmoko.org/?p=kernel.git;a=summary).&lt;br /&gt;
&lt;br /&gt;
The ''andy-tracking'' branch is the one where most of the action takes place these days. &lt;br /&gt;
&lt;br /&gt;
We have [[Kernel_branches|branch policies]] that explain what each branch is for.&lt;br /&gt;
&lt;br /&gt;
=== Daily builds ===&lt;br /&gt;
&lt;br /&gt;
==== Automatic revisions ====&lt;br /&gt;
&lt;br /&gt;
Think of a robot that takes whatever kernels are the most recent in GIT, builds them for you and then makes them available here:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/experimental/&lt;br /&gt;
&lt;br /&gt;
==== Blessed revisions ====&lt;br /&gt;
&lt;br /&gt;
Another robot but this one only builds the versions picked by our friendly [[OpenEmbedded]] developers. Download from:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/unstable/&lt;br /&gt;
&lt;br /&gt;
If you understand OpenEmbedded you will get this: Those versions are tied to a specific GIT revision through conf/distro/include/sane-srcrevs.bb.&lt;br /&gt;
&lt;br /&gt;
=== Building the andy-tracking branch ===&lt;br /&gt;
&lt;br /&gt;
Those are the minimum survival commands:&lt;br /&gt;
&lt;br /&gt;
 $ git clone git://git.openmoko.org/git/kernel.git linux-2.6&lt;br /&gt;
 $ cd linux-2.6&lt;br /&gt;
 $ git-checkout --track -b andy-tracking origin/andy-tracking&lt;br /&gt;
 $ mkdir GTA02 &lt;br /&gt;
 $ cp ./arch/arm/configs/gta02_moredrivers_defconfig GTA02/.config&lt;br /&gt;
&lt;br /&gt;
Before building this kernel you need install a [http://wiki.openmoko.org/wiki/Toolchain#Downloading_and_installing Toolchain].&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
In order to build the modules you can:&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02 dummy&lt;br /&gt;
&lt;br /&gt;
This will create a file called modules-GTA02_andy-tracking-&amp;lt;git hash&amp;gt;.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.&lt;br /&gt;
&lt;br /&gt;
If you want to update the local copy of the repository so that you get the latest changes, you can type:&lt;br /&gt;
&lt;br /&gt;
 $ git-pull&lt;br /&gt;
&lt;br /&gt;
Before reporting that the new kernel does not build please first check for changes in the configuration file provided by Openmoko.&lt;br /&gt;
&lt;br /&gt;
=== kernel building tips ===&lt;br /&gt;
&lt;br /&gt;
If you are modifying Linux kernel code and building it quite often you really want to be using [http://ccache.samba.org ccache]. It will save you a lot of time.&lt;br /&gt;
&lt;br /&gt;
TODO: submit a patch for the build script that makes ccache use easier. '''Note''': There is a [http://lists.openmoko.org/pipermail/openmoko-kernel/2009-March/009139.html patch being reviewed].&lt;br /&gt;
&lt;br /&gt;
== Contributing ==&lt;br /&gt;
&lt;br /&gt;
The development resources [[Openmoko]] offers are:&lt;br /&gt;
&lt;br /&gt;
* Git repository: http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
* [http://lists.openmoko.org/mailman/listinfo/openmoko-kernel Mailing list] ([http://lists.openmoko.org/pipermail/openmoko-kernel/ Online Archive])&lt;br /&gt;
&lt;br /&gt;
We appreciate your contributions. Check the Open Issues at the end of this page to check where we need more help.&lt;br /&gt;
&lt;br /&gt;
If in doubt ask in the mailing list.&lt;br /&gt;
&lt;br /&gt;
== FAQ ==&lt;br /&gt;
&lt;br /&gt;
=== Why does Openmoko cares about sending code upstream instead of (insert your task here)? ===&lt;br /&gt;
&lt;br /&gt;
There are two very different approaches and both of them would be doomed if we stuck all our resources to only one of to them.&lt;br /&gt;
&lt;br /&gt;
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 [http://www.kernel.org upstream] where the people who want to help us improve, maintain and support the code running in our devices hang out.&lt;br /&gt;
&lt;br /&gt;
The second is to care way '''too much''' about upstream to the point that we are not willing to ship a temporal dirty hack that make users happy and able to better use their phones. We cannot afford that kind of purity.&lt;br /&gt;
&lt;br /&gt;
As many things in engineering we have to find a point in the middle that works well -- we will try hard to do it.&lt;br /&gt;
&lt;br /&gt;
=== Who's Andy and why is he sticking his name in the kernel? ===&lt;br /&gt;
&lt;br /&gt;
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&lt;br /&gt;
&lt;br /&gt;
Check [[Kernel_branches]] if you care about the details.&lt;br /&gt;
&lt;br /&gt;
=== Kernel developers are not polite! They do not even care to say &amp;quot;Hello&amp;quot; when they reply to my emails! ===&lt;br /&gt;
&lt;br /&gt;
The long version is here: [[Kernel-developers-are-not-polite]].&lt;br /&gt;
&lt;br /&gt;
To the point:&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
They just tend to write very short text because they have to read and write a lot every day.&lt;br /&gt;
&lt;br /&gt;
== Known issues ==&lt;br /&gt;
&lt;br /&gt;
=== Sysfs paths ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[FSO]] developers realized that this problem could be prevented from from happening in the future and they decided to code a nice daemon called [http://www.freesmartphone.org/index.php/Implementations/OpenDeviceDaemon odeviced].&lt;br /&gt;
&lt;br /&gt;
== Open Tickets ==&lt;br /&gt;
&lt;br /&gt;
'''Please read [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component this report]''' if you wish to know what the current issues are.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Easy bugs ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
TODO: list of bugs linking to trac.&lt;br /&gt;
&lt;br /&gt;
=== Normal bugs ===&lt;br /&gt;
&lt;br /&gt;
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. Please do not add a list of bugs here.&lt;br /&gt;
&lt;br /&gt;
'''Read this [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component report]''' to find out more about them.&lt;br /&gt;
&lt;br /&gt;
=== Hard bugs ===&lt;br /&gt;
&lt;br /&gt;
Those are the evil bugs that we haven't fixed either because:&lt;br /&gt;
&lt;br /&gt;
# We do not know how to do it in reasonable time&lt;br /&gt;
# 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)&lt;br /&gt;
# More testing is needed (perhaps a hard-to-reproduce bug)&lt;br /&gt;
&lt;br /&gt;
Here is the list:&lt;br /&gt;
&lt;br /&gt;
* [https://docs.openmoko.org/trac/ticket/2235 #2235 : Monochrome display on resume]&lt;br /&gt;
&lt;br /&gt;
{{Languages|Kernel}}&lt;br /&gt;
&lt;br /&gt;
[[Category:Kernel]]&lt;br /&gt;
[[Category:System Developers]]&lt;br /&gt;
[[Category:Application Developer]]&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel_Plans</id>
		<title>Kernel Plans</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel_Plans"/>
				<updated>2009-04-14T08:12:40Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: Adding category.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This document explains the current kernel plan for the GTA01/GTA02 kernel. The idea is to share the motivations behind the actual decisions.&lt;br /&gt;
&lt;br /&gt;
== Current priority ==&lt;br /&gt;
&lt;br /&gt;
The current priority is to make the andy-tracking branch stable.&lt;br /&gt;
&lt;br /&gt;
See: https://docs.openmoko.org/trac/milestone/stable-kernel-2009.1&lt;br /&gt;
&lt;br /&gt;
== Patch review process ==&lt;br /&gt;
&lt;br /&gt;
If the patch has not issues that we can tell and it is relevant it will be applied. If we can tell it is a good patch right away or that it is a critical fix we will just apply the patch.&lt;br /&gt;
&lt;br /&gt;
Otherwise we will allow for two days before applying non-trivial patches to allow for community feedback and for feedback from subsystem maintainers. In the ideal case we would get ACKs from other developers (like &amp;quot;i like this patch&amp;quot;) but we don't know if we can count on this.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Use tags and not forks for stable kernels ==&lt;br /&gt;
&lt;br /&gt;
The next stable kernel will be stable-kernel-2009.1. This is [http://docs.openmoko.org/trac/query?status=in_testing&amp;amp;status=reopened&amp;amp;status=assigned&amp;amp;status=new&amp;amp;status=accepted&amp;amp;group=status&amp;amp;milestone=stable-kernel-2009.1 the list of the bugs that need to be fixed] for it to happen.&lt;br /&gt;
&lt;br /&gt;
We hope that developers actually care about the development branch. If they care, they will helps us reject patches that will likely cause trouble because it will break things. We will also get more testing.&lt;br /&gt;
&lt;br /&gt;
We will tag stable kernels in the repository.&lt;br /&gt;
&lt;br /&gt;
We know that people like forks and code that does not change often, but the linear model is working with upstream kernel (with a lot more people involved of course).&lt;br /&gt;
&lt;br /&gt;
If the tagging approach fails for us we'll create a stable branch but let's delay this action until we actually need it.&lt;br /&gt;
&lt;br /&gt;
== Upstream Linux kernel ==&lt;br /&gt;
&lt;br /&gt;
For the next merge window we wish to send:&lt;br /&gt;
&lt;br /&gt;
* Basic GTA02 support&lt;br /&gt;
* Touchscreen Driver and filters&lt;br /&gt;
&lt;br /&gt;
See:&lt;br /&gt;
&lt;br /&gt;
* http://lists.openmoko.org/pipermail/openmoko-kernel/2009-March/009740.html&lt;br /&gt;
* http://lists.openmoko.org/pipermail/openmoko-kernel/2009-March/009450.html + http://nelson-patches.googlecode.com/svn/trunk/openmoko/kernel/ts-with-s3c-adc/&lt;br /&gt;
&lt;br /&gt;
== Issues to solve ==&lt;br /&gt;
&lt;br /&gt;
=== Define how to keep track of the upstream kernel ===&lt;br /&gt;
&lt;br /&gt;
How to up-level the kernel to latest upstream version? (We can delay this decision).&lt;br /&gt;
&lt;br /&gt;
=== Make a better use of trac ===&lt;br /&gt;
&lt;br /&gt;
There are many bugs that might be invalid. If you reported a bug and/or you know it is no longer valid please ask us to close it (this can be done in the same bug report).&lt;br /&gt;
&lt;br /&gt;
We'll use milestones to filter the noise and to be able to focus on the important bugs.&lt;br /&gt;
&lt;br /&gt;
=== Patchwork ===&lt;br /&gt;
&lt;br /&gt;
We have a patchwork installation ( http://patchwork.openmoko.org ) requested by Angus but it still have some issues. It would be nice to use it in the future.&lt;br /&gt;
&lt;br /&gt;
See:&lt;br /&gt;
&lt;br /&gt;
* http://ozlabs.org/~jk/projects/patchwork/ (Patchwork)&lt;br /&gt;
* http://patchwork.ozlabs.org (Patchwork in use)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Category:Kernel]]&lt;br /&gt;
[[Category:System Developers]]&lt;br /&gt;
[[Category:Application Developer]]&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel_Plans</id>
		<title>Kernel Plans</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel_Plans"/>
				<updated>2009-04-14T08:11:21Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: Fix.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This document explains the current kernel plan for the GTA01/GTA02 kernel. The idea is to share the motivations behind the actual decisions.&lt;br /&gt;
&lt;br /&gt;
== Current priority ==&lt;br /&gt;
&lt;br /&gt;
The current priority is to make the andy-tracking branch stable.&lt;br /&gt;
&lt;br /&gt;
See: https://docs.openmoko.org/trac/milestone/stable-kernel-2009.1&lt;br /&gt;
&lt;br /&gt;
== Patch review process ==&lt;br /&gt;
&lt;br /&gt;
If the patch has not issues that we can tell and it is relevant it will be applied. If we can tell it is a good patch right away or that it is a critical fix we will just apply the patch.&lt;br /&gt;
&lt;br /&gt;
Otherwise we will allow for two days before applying non-trivial patches to allow for community feedback and for feedback from subsystem maintainers. In the ideal case we would get ACKs from other developers (like &amp;quot;i like this patch&amp;quot;) but we don't know if we can count on this.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Use tags and not forks for stable kernels ==&lt;br /&gt;
&lt;br /&gt;
The next stable kernel will be stable-kernel-2009.1. This is [http://docs.openmoko.org/trac/query?status=in_testing&amp;amp;status=reopened&amp;amp;status=assigned&amp;amp;status=new&amp;amp;status=accepted&amp;amp;group=status&amp;amp;milestone=stable-kernel-2009.1 the list of the bugs that need to be fixed] for it to happen.&lt;br /&gt;
&lt;br /&gt;
We hope that developers actually care about the development branch. If they care, they will helps us reject patches that will likely cause trouble because it will break things. We will also get more testing.&lt;br /&gt;
&lt;br /&gt;
We will tag stable kernels in the repository.&lt;br /&gt;
&lt;br /&gt;
We know that people like forks and code that does not change often, but the linear model is working with upstream kernel (with a lot more people involved of course).&lt;br /&gt;
&lt;br /&gt;
If the tagging approach fails for us we'll create a stable branch but let's delay this action until we actually need it.&lt;br /&gt;
&lt;br /&gt;
== Upstream Linux kernel ==&lt;br /&gt;
&lt;br /&gt;
For the next merge window we wish to send:&lt;br /&gt;
&lt;br /&gt;
* Basic GTA02 support&lt;br /&gt;
* Touchscreen Driver and filters&lt;br /&gt;
&lt;br /&gt;
See:&lt;br /&gt;
&lt;br /&gt;
* http://lists.openmoko.org/pipermail/openmoko-kernel/2009-March/009740.html&lt;br /&gt;
* http://lists.openmoko.org/pipermail/openmoko-kernel/2009-March/009450.html + http://nelson-patches.googlecode.com/svn/trunk/openmoko/kernel/ts-with-s3c-adc/&lt;br /&gt;
&lt;br /&gt;
== Issues to solve ==&lt;br /&gt;
&lt;br /&gt;
=== Define how to keep track of the upstream kernel ===&lt;br /&gt;
&lt;br /&gt;
How to up-level the kernel to latest upstream version? (We can delay this decision).&lt;br /&gt;
&lt;br /&gt;
=== Make a better use of trac ===&lt;br /&gt;
&lt;br /&gt;
There are many bugs that might be invalid. If you reported a bug and/or you know it is no longer valid please ask us to close it (this can be done in the same bug report).&lt;br /&gt;
&lt;br /&gt;
We'll use milestones to filter the noise and to be able to focus on the important bugs.&lt;br /&gt;
&lt;br /&gt;
=== Patchwork ===&lt;br /&gt;
&lt;br /&gt;
We have a patchwork installation ( http://patchwork.openmoko.org ) requested by Angus but it still have some issues. It would be nice to use it in the future.&lt;br /&gt;
&lt;br /&gt;
See:&lt;br /&gt;
&lt;br /&gt;
* http://ozlabs.org/~jk/projects/patchwork/ (Patchwork)&lt;br /&gt;
* http://patchwork.ozlabs.org (Patchwork in use)&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel</id>
		<title>Kernel</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel"/>
				<updated>2009-04-09T21:38:43Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: Fix.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Kernel}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Things changed ==&lt;br /&gt;
&lt;br /&gt;
This page will be updated soon. Those are the current [[Kernel_Plans|Kernel plans]].&lt;br /&gt;
&lt;br /&gt;
== Is this page meant for you? ==&lt;br /&gt;
&lt;br /&gt;
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 for you. You might want to scroll down for the for the blessed kernels in the daily builds.&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Sister pages ===&lt;br /&gt;
&lt;br /&gt;
# [[Kernel_branches]].&lt;br /&gt;
&lt;br /&gt;
== Sources ==&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
&lt;br /&gt;
http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
&lt;br /&gt;
[http://git-scm.com 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
If you are very new to GIT you might want to read [http://git.or.cz/course/ the good manuals that already available].&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
=== Branches ===&lt;br /&gt;
&lt;br /&gt;
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 (http://git.openmoko.org/?p=kernel.git;a=summary).&lt;br /&gt;
&lt;br /&gt;
The ''andy-tracking'' branch is the one where most of the action takes place these days. &lt;br /&gt;
&lt;br /&gt;
We have [[Kernel_branches|branch policies]] that explain what each branch is for.&lt;br /&gt;
&lt;br /&gt;
=== Daily builds ===&lt;br /&gt;
&lt;br /&gt;
==== Automatic revisions ====&lt;br /&gt;
&lt;br /&gt;
Think of a robot that takes whatever kernels are the most recent in GIT, builds them for you and then makes them available here:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/experimental/&lt;br /&gt;
&lt;br /&gt;
==== Blessed revisions ====&lt;br /&gt;
&lt;br /&gt;
Another robot but this one only builds the versions picked by our friendly [[OpenEmbedded]] developers. Download from:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/unstable/&lt;br /&gt;
&lt;br /&gt;
If you understand OpenEmbedded you will get this: Those versions are tied to a specific GIT revision through conf/distro/include/sane-srcrevs.bb.&lt;br /&gt;
&lt;br /&gt;
=== Building the andy-tracking branch ===&lt;br /&gt;
&lt;br /&gt;
Those are the minimum survival commands:&lt;br /&gt;
&lt;br /&gt;
 $ git clone git://git.openmoko.org/git/kernel.git linux-2.6&lt;br /&gt;
 $ cd linux-2.6&lt;br /&gt;
 $ git-checkout --track -b andy-tracking origin/andy-tracking&lt;br /&gt;
 $ mkdir GTA02 &lt;br /&gt;
 $ cp ./arch/arm/configs/gta02_moredrivers_defconfig GTA02/.config&lt;br /&gt;
&lt;br /&gt;
Before building this kernel you need install a [http://wiki.openmoko.org/wiki/Toolchain#Downloading_and_installing Toolchain].&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
In order to build the modules you can:&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02 dummy&lt;br /&gt;
&lt;br /&gt;
This will create a file called modules-GTA02_andy-tracking-&amp;lt;git hash&amp;gt;.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.&lt;br /&gt;
&lt;br /&gt;
If you want to update the local copy of the repository so that you get the latest changes, you can type:&lt;br /&gt;
&lt;br /&gt;
 $ git-pull&lt;br /&gt;
&lt;br /&gt;
Before reporting that the new kernel does not build please first check for changes in the configuration file provided by Openmoko.&lt;br /&gt;
&lt;br /&gt;
=== kernel building tips ===&lt;br /&gt;
&lt;br /&gt;
If you are modifying Linux kernel code and building it quite often you really want to be using [http://ccache.samba.org ccache]. It will save you a lot of time.&lt;br /&gt;
&lt;br /&gt;
TODO: submit a patch for the build script that makes ccache use easier. '''Note''': There is a [http://lists.openmoko.org/pipermail/openmoko-kernel/2009-March/009139.html patch being reviewed].&lt;br /&gt;
&lt;br /&gt;
== Contributing ==&lt;br /&gt;
&lt;br /&gt;
The development resources [[Openmoko]] offers are:&lt;br /&gt;
&lt;br /&gt;
* Git repository: http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
* [http://lists.openmoko.org/mailman/listinfo/openmoko-kernel Mailing list] ([http://lists.openmoko.org/pipermail/openmoko-kernel/ Online Archive])&lt;br /&gt;
&lt;br /&gt;
We appreciate your contributions. Check the Open Issues at the end of this page to check where we need more help.&lt;br /&gt;
&lt;br /&gt;
If in doubt ask in the mailing list.&lt;br /&gt;
&lt;br /&gt;
== FAQ ==&lt;br /&gt;
&lt;br /&gt;
=== Why does Openmoko cares about sending code upstream instead of (insert your task here)? ===&lt;br /&gt;
&lt;br /&gt;
There are two very different approaches and both of them would be doomed if we stuck all our resources to only one of to them.&lt;br /&gt;
&lt;br /&gt;
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 [http://www.kernel.org upstream] where the people who want to help us improve, maintain and support the code running in our devices hang out.&lt;br /&gt;
&lt;br /&gt;
The second is to care way '''too much''' about upstream to the point that we are not willing to ship a temporal dirty hack that make users happy and able to better use their phones. We cannot afford that kind of purity.&lt;br /&gt;
&lt;br /&gt;
As many things in engineering we have to find a point in the middle that works well -- we will try hard to do it.&lt;br /&gt;
&lt;br /&gt;
=== Who's Andy and why is he sticking his name in the kernel? ===&lt;br /&gt;
&lt;br /&gt;
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. He makes sure that the kernel still builds when Linus and his friends feel like it is time to update the upstream kernel and believe us: it is not as fun as it might sound and it happens often.&lt;br /&gt;
&lt;br /&gt;
Check [[Kernel_branches]] if you care about the details.&lt;br /&gt;
&lt;br /&gt;
=== Kernel developers are not polite! They do not even care to say &amp;quot;Hello&amp;quot; when they reply to my emails! ===&lt;br /&gt;
&lt;br /&gt;
The long version is here: [[Kernel-developers-are-not-polite]].&lt;br /&gt;
&lt;br /&gt;
To the point:&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
They just tend to write very short text because they have to read and write a lot every day.&lt;br /&gt;
&lt;br /&gt;
== Known issues ==&lt;br /&gt;
&lt;br /&gt;
=== Sysfs paths ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[FSO]] developers realized that this problem could be prevented from from happening in the future and they decided to code a nice daemon called [http://www.freesmartphone.org/index.php/Implementations/OpenDeviceDaemon odeviced].&lt;br /&gt;
&lt;br /&gt;
== Open Tickets ==&lt;br /&gt;
&lt;br /&gt;
'''Please read [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component this report]''' if you wish to know what the current issues are.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Easy bugs ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
TODO: list of bugs linking to trac.&lt;br /&gt;
&lt;br /&gt;
=== Normal bugs ===&lt;br /&gt;
&lt;br /&gt;
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. Please do not add a list of bugs here.&lt;br /&gt;
&lt;br /&gt;
'''Read this [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component report]''' to find out more about them.&lt;br /&gt;
&lt;br /&gt;
=== Hard bugs ===&lt;br /&gt;
&lt;br /&gt;
Those are the evil bugs that we haven't fixed either because:&lt;br /&gt;
&lt;br /&gt;
# We do not know how to do it in reasonable time&lt;br /&gt;
# 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)&lt;br /&gt;
# More testing is needed (perhaps a hard-to-reproduce bug)&lt;br /&gt;
&lt;br /&gt;
Here is the list:&lt;br /&gt;
&lt;br /&gt;
* [https://docs.openmoko.org/trac/ticket/2235 #2235 : Monochrome display on resume]&lt;br /&gt;
&lt;br /&gt;
{{Languages|Kernel}}&lt;br /&gt;
&lt;br /&gt;
[[Category:Kernel]]&lt;br /&gt;
[[Category:System Developers]]&lt;br /&gt;
[[Category:Application Developer]]&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel_Plans</id>
		<title>Kernel Plans</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel_Plans"/>
				<updated>2009-04-09T21:36:29Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: Fix.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This document explains the current kernel plan for the GTA01/GTA02 kernel. The idea is to share the motivations behind the actual decisions. This is a draft, and the relevant suggestions will be incorporated into it.&lt;br /&gt;
&lt;br /&gt;
We would like to try this model for one or two months and if we find we are doing something wrong we will update the plans.&lt;br /&gt;
&lt;br /&gt;
== Patch review process ==&lt;br /&gt;
&lt;br /&gt;
If the patch has not issues that we can tell and it is relevant it will be applied. If we can tell it is a good patch right away or that it is a critical fix we will just apply the patch.&lt;br /&gt;
&lt;br /&gt;
Otherwise we will allow for two days before applying non-trivial patches to allow for community feedback and for feedback from subsystem maintainers. In the ideal case we would get ACKs from other developers (like &amp;quot;i like this patch&amp;quot;) but we don't know if we can count on this.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Use tags and not forks for stable kernels ==&lt;br /&gt;
&lt;br /&gt;
The next stable kernel will be stable-kernel-2009.1. This is [http://docs.openmoko.org/trac/query?status=in_testing&amp;amp;status=reopened&amp;amp;status=assigned&amp;amp;status=new&amp;amp;status=accepted&amp;amp;group=status&amp;amp;milestone=stable-kernel-2009.1 the list of the bugs that need to be fixed] for it to happen.&lt;br /&gt;
&lt;br /&gt;
We hope that developers actually care about the development branch. If they care, they will helps us reject patches that will likely cause trouble because it will break things. We will also get more testing.&lt;br /&gt;
&lt;br /&gt;
We will tag stable kernels in the repository.&lt;br /&gt;
&lt;br /&gt;
We know that people like forks and code that does not change often, but the linear model is working with upstream kernel (with a lot more people involved of course).&lt;br /&gt;
&lt;br /&gt;
== Upstream Linux kernel ==&lt;br /&gt;
&lt;br /&gt;
We should have very basic GTA02 support upstream soon. Once we get to reach this milestone we will check what drivers can be included.&lt;br /&gt;
&lt;br /&gt;
== Issues to solve ==&lt;br /&gt;
&lt;br /&gt;
=== Define how to keep track of the upstream kernel ===&lt;br /&gt;
&lt;br /&gt;
How to up-level the kernel to latest upstream version? (We can delay this decision for a few days).&lt;br /&gt;
&lt;br /&gt;
=== Patchwork ===&lt;br /&gt;
&lt;br /&gt;
We have a patchwork installation ( http://patchwork.openmoko.org ) requested by Angus but it still have some issues. It would be nice to use it in the future.&lt;br /&gt;
&lt;br /&gt;
See:&lt;br /&gt;
&lt;br /&gt;
* http://ozlabs.org/~jk/projects/patchwork/ (Patchwork)&lt;br /&gt;
* http://patchwork.ozlabs.org (Patchwork in use)&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel_Plans</id>
		<title>Kernel Plans</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel_Plans"/>
				<updated>2009-04-05T05:32:47Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: Fix.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This document explains the current kernel plan for the GTA01/GTA02 kernel. The idea is to share the motivations behind the actual decisions. This is a draft, and the relevant suggestions will be incorporated into it.&lt;br /&gt;
&lt;br /&gt;
We would like to try this model for one or two months and if we find we are doing something wrong we will update the plans.&lt;br /&gt;
&lt;br /&gt;
== Patch review process ==&lt;br /&gt;
&lt;br /&gt;
If the patch has not issues that we can tell and it is relevant it will be applied. If we can tell it is a good patch right away or that it is a critical fix we will just apply the patch.&lt;br /&gt;
&lt;br /&gt;
Otherwise we will allow for two days before applying non-trivial patches to allow for community feedback and for feedback from subsystem maintainers. In the ideal case we would get ACKs from other developers (like &amp;quot;i like this patch&amp;quot;) but we don't know if we can count on this.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Use tags and not forks for stable kernels ==&lt;br /&gt;
&lt;br /&gt;
We hope that developers actually care about the development branch. If they care, they will helps us reject patches that will likely cause trouble because it will break things. We will also get more testing.&lt;br /&gt;
&lt;br /&gt;
We will tag stable kernels in the repository.&lt;br /&gt;
&lt;br /&gt;
We know that people like forks and code that does not change often, but the linear model is working with upstream kernel (with a lot more people involved of course).&lt;br /&gt;
&lt;br /&gt;
We could fork the current Andy-tracking into a stable kernel. But, should we really do it? People could fork a stable tree and cherry-pick changes.&lt;br /&gt;
&lt;br /&gt;
== Upstream Linux kernel ==&lt;br /&gt;
&lt;br /&gt;
We should have very basic GTA02 support upstream soon. Once we get to reach this milestone we will check what drivers can be included.&lt;br /&gt;
&lt;br /&gt;
== Issues to solve ==&lt;br /&gt;
&lt;br /&gt;
=== Define how to keep track of the upstream kernel ===&lt;br /&gt;
&lt;br /&gt;
How to up-level the kernel to latest upstream version? (We can delay this decision for a few days).&lt;br /&gt;
&lt;br /&gt;
=== Patchwork ===&lt;br /&gt;
&lt;br /&gt;
We have a patchwork installation ( http://patchwork.openmoko.org ) requested by Angus but it still have some issues. It would be nice to use it in the future.&lt;br /&gt;
&lt;br /&gt;
See:&lt;br /&gt;
&lt;br /&gt;
* http://ozlabs.org/~jk/projects/patchwork/ (Patchwork)&lt;br /&gt;
* http://patchwork.ozlabs.org (Patchwork in use)&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel_Plans</id>
		<title>Kernel Plans</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel_Plans"/>
				<updated>2009-04-05T02:52:51Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: /* Patchwork */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This document explains the current kernel plan for the GTA01/GTA02 kernel. The idea is to share the motivations behind the actual decisions. This is a draft, and the relevant suggestions will be incorporated into it.&lt;br /&gt;
&lt;br /&gt;
We would like to try this model for one or two months and if we find we are doing something wrong we will update the plans.&lt;br /&gt;
&lt;br /&gt;
== Patch review process ==&lt;br /&gt;
&lt;br /&gt;
If the patch has not issues that we can tell and it is relevant it will be applied. If we can tell it is a good patch right away or that it is a critical fix we will just apply the patch.&lt;br /&gt;
&lt;br /&gt;
Otherwise we will allow for two days before applying non-trivial patches to allow for community feedback and for feedback from subsystem maintainers. In the ideal case we would get ACKs from other developers (like &amp;quot;i like this patch&amp;quot;) but we don't know if we can count on this.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Use tags and not forks for stable kernels ==&lt;br /&gt;
&lt;br /&gt;
We hope that developers actually care about the development branch. If they care, they will helps us reject patches that will likely cause trouble because it will break things. We will also get more testing.&lt;br /&gt;
&lt;br /&gt;
We will tag stable kernels in the repository.&lt;br /&gt;
&lt;br /&gt;
We know that people like forks and code that does not change often, but the linear model is working with upstream kernel (with a lot more people involved of course).&lt;br /&gt;
&lt;br /&gt;
We could fork the current Andy-tracking into a stable kernel. But, should we really do it? People could fork a stable tree and cherry-pick changes.&lt;br /&gt;
&lt;br /&gt;
== Upstream Linux kernel ==&lt;br /&gt;
&lt;br /&gt;
We should have very basic GTA02 support upstream soon. Once we get to reach this milestone we will check what drivers can be included.&lt;br /&gt;
&lt;br /&gt;
== Issues to solve ==&lt;br /&gt;
&lt;br /&gt;
=== Define how to keep track of the upstream kernel ===&lt;br /&gt;
&lt;br /&gt;
How to up-level the kernel to latest upstream version? (We can delay this decision for a few days).&lt;br /&gt;
&lt;br /&gt;
=== Patchwork ===&lt;br /&gt;
&lt;br /&gt;
Patchwork is a nice system. http://patchwork.kernel.org It does not replace a mailing list but it helps keep track of pending patches. We should use it. (Not a priority right now).&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel_Plans</id>
		<title>Kernel Plans</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel_Plans"/>
				<updated>2009-04-05T02:52:24Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: /* Issues to solve */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This document explains the current kernel plan for the GTA01/GTA02 kernel. The idea is to share the motivations behind the actual decisions. This is a draft, and the relevant suggestions will be incorporated into it.&lt;br /&gt;
&lt;br /&gt;
We would like to try this model for one or two months and if we find we are doing something wrong we will update the plans.&lt;br /&gt;
&lt;br /&gt;
== Patch review process ==&lt;br /&gt;
&lt;br /&gt;
If the patch has not issues that we can tell and it is relevant it will be applied. If we can tell it is a good patch right away or that it is a critical fix we will just apply the patch.&lt;br /&gt;
&lt;br /&gt;
Otherwise we will allow for two days before applying non-trivial patches to allow for community feedback and for feedback from subsystem maintainers. In the ideal case we would get ACKs from other developers (like &amp;quot;i like this patch&amp;quot;) but we don't know if we can count on this.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Use tags and not forks for stable kernels ==&lt;br /&gt;
&lt;br /&gt;
We hope that developers actually care about the development branch. If they care, they will helps us reject patches that will likely cause trouble because it will break things. We will also get more testing.&lt;br /&gt;
&lt;br /&gt;
We will tag stable kernels in the repository.&lt;br /&gt;
&lt;br /&gt;
We know that people like forks and code that does not change often, but the linear model is working with upstream kernel (with a lot more people involved of course).&lt;br /&gt;
&lt;br /&gt;
We could fork the current Andy-tracking into a stable kernel. But, should we really do it? People could fork a stable tree and cherry-pick changes.&lt;br /&gt;
&lt;br /&gt;
== Upstream Linux kernel ==&lt;br /&gt;
&lt;br /&gt;
We should have very basic GTA02 support upstream soon. Once we get to reach this milestone we will check what drivers can be included.&lt;br /&gt;
&lt;br /&gt;
== Issues to solve ==&lt;br /&gt;
&lt;br /&gt;
=== Define how to keep track of the upstream kernel ===&lt;br /&gt;
&lt;br /&gt;
How to up-level the kernel to latest upstream version? (We can delay this decision for a few days).&lt;br /&gt;
&lt;br /&gt;
=== Patchwork ===&lt;br /&gt;
&lt;br /&gt;
Patchwork is a nice system. http://patchwork.kernel.org It does not replace a mailing list but it helps keep track of pending patches. We should use it.&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel_Plans</id>
		<title>Kernel Plans</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel_Plans"/>
				<updated>2009-04-05T02:52:02Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: /* Patchwork */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This document explains the current kernel plan for the GTA01/GTA02 kernel. The idea is to share the motivations behind the actual decisions. This is a draft, and the relevant suggestions will be incorporated into it.&lt;br /&gt;
&lt;br /&gt;
We would like to try this model for one or two months and if we find we are doing something wrong we will update the plans.&lt;br /&gt;
&lt;br /&gt;
== Patch review process ==&lt;br /&gt;
&lt;br /&gt;
If the patch has not issues that we can tell and it is relevant it will be applied. If we can tell it is a good patch right away or that it is a critical fix we will just apply the patch.&lt;br /&gt;
&lt;br /&gt;
Otherwise we will allow for two days before applying non-trivial patches to allow for community feedback and for feedback from subsystem maintainers. In the ideal case we would get ACKs from other developers (like &amp;quot;i like this patch&amp;quot;) but we don't know if we can count on this.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Use tags and not forks for stable kernels ==&lt;br /&gt;
&lt;br /&gt;
We hope that developers actually care about the development branch. If they care, they will helps us reject patches that will likely cause trouble because it will break things. We will also get more testing.&lt;br /&gt;
&lt;br /&gt;
We will tag stable kernels in the repository.&lt;br /&gt;
&lt;br /&gt;
We know that people like forks and code that does not change often, but the linear model is working with upstream kernel (with a lot more people involved of course).&lt;br /&gt;
&lt;br /&gt;
We could fork the current Andy-tracking into a stable kernel. But, should we really do it? People could fork a stable tree and cherry-pick changes.&lt;br /&gt;
&lt;br /&gt;
== Upstream Linux kernel ==&lt;br /&gt;
&lt;br /&gt;
We should have very basic GTA02 support upstream soon. Once we get to reach this milestone we will check what drivers can be included.&lt;br /&gt;
&lt;br /&gt;
== Issues to solve ==&lt;br /&gt;
&lt;br /&gt;
=== Define how to keep track of the upstream kernel ===&lt;br /&gt;
&lt;br /&gt;
How to up-level the kernel to latest upstream version? (We can delay this decision for a few days).&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel_Plans</id>
		<title>Kernel Plans</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel_Plans"/>
				<updated>2009-04-05T02:49:37Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: /* Define how to keep track of the upstream kernel */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This document explains the current kernel plan for the GTA01/GTA02 kernel. The idea is to share the motivations behind the actual decisions. This is a draft, and the relevant suggestions will be incorporated into it.&lt;br /&gt;
&lt;br /&gt;
We would like to try this model for one or two months and if we find we are doing something wrong we will update the plans.&lt;br /&gt;
&lt;br /&gt;
== Patch review process ==&lt;br /&gt;
&lt;br /&gt;
If the patch has not issues that we can tell and it is relevant it will be applied. If we can tell it is a good patch right away or that it is a critical fix we will just apply the patch.&lt;br /&gt;
&lt;br /&gt;
Otherwise we will allow for two days before applying non-trivial patches to allow for community feedback and for feedback from subsystem maintainers. In the ideal case we would get ACKs from other developers (like &amp;quot;i like this patch&amp;quot;) but we don't know if we can count on this.&lt;br /&gt;
&lt;br /&gt;
=== Patchwork ===&lt;br /&gt;
&lt;br /&gt;
Patchwork is a nice system. http://patchwork.kernel.org It does not replace a mailing list but it helps keep track of pending patches. We should use it.&lt;br /&gt;
&lt;br /&gt;
== Use tags and not forks for stable kernels ==&lt;br /&gt;
&lt;br /&gt;
We hope that developers actually care about the development branch. If they care, they will helps us reject patches that will likely cause trouble because it will break things. We will also get more testing.&lt;br /&gt;
&lt;br /&gt;
We will tag stable kernels in the repository.&lt;br /&gt;
&lt;br /&gt;
We know that people like forks and code that does not change often, but the linear model is working with upstream kernel (with a lot more people involved of course).&lt;br /&gt;
&lt;br /&gt;
We could fork the current Andy-tracking into a stable kernel. But, should we really do it? People could fork a stable tree and cherry-pick changes.&lt;br /&gt;
&lt;br /&gt;
== Upstream Linux kernel ==&lt;br /&gt;
&lt;br /&gt;
We should have very basic GTA02 support upstream soon. Once we get to reach this milestone we will check what drivers can be included.&lt;br /&gt;
&lt;br /&gt;
== Issues to solve ==&lt;br /&gt;
&lt;br /&gt;
=== Define how to keep track of the upstream kernel ===&lt;br /&gt;
&lt;br /&gt;
How to up-level the kernel to latest upstream version? (We can delay this decision for a few days).&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel_Plans</id>
		<title>Kernel Plans</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel_Plans"/>
				<updated>2009-04-05T02:42:14Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: /* Use tags and not forks for stable kernels */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This document explains the current kernel plan for the GTA01/GTA02 kernel. The idea is to share the motivations behind the actual decisions. This is a draft, and the relevant suggestions will be incorporated into it.&lt;br /&gt;
&lt;br /&gt;
We would like to try this model for one or two months and if we find we are doing something wrong we will update the plans.&lt;br /&gt;
&lt;br /&gt;
== Patch review process ==&lt;br /&gt;
&lt;br /&gt;
If the patch has not issues that we can tell and it is relevant it will be applied. If we can tell it is a good patch right away or that it is a critical fix we will just apply the patch.&lt;br /&gt;
&lt;br /&gt;
Otherwise we will allow for two days before applying non-trivial patches to allow for community feedback and for feedback from subsystem maintainers. In the ideal case we would get ACKs from other developers (like &amp;quot;i like this patch&amp;quot;) but we don't know if we can count on this.&lt;br /&gt;
&lt;br /&gt;
=== Patchwork ===&lt;br /&gt;
&lt;br /&gt;
Patchwork is a nice system. http://patchwork.kernel.org It does not replace a mailing list but it helps keep track of pending patches. We should use it.&lt;br /&gt;
&lt;br /&gt;
== Use tags and not forks for stable kernels ==&lt;br /&gt;
&lt;br /&gt;
We hope that developers actually care about the development branch. If they care, they will helps us reject patches that will likely cause trouble because it will break things. We will also get more testing.&lt;br /&gt;
&lt;br /&gt;
We will tag stable kernels in the repository.&lt;br /&gt;
&lt;br /&gt;
We know that people like forks and code that does not change often, but the linear model is working with upstream kernel (with a lot more people involved of course).&lt;br /&gt;
&lt;br /&gt;
We could fork the current Andy-tracking into a stable kernel. But, should we really do it? People could fork a stable tree and cherry-pick changes.&lt;br /&gt;
&lt;br /&gt;
== Upstream Linux kernel ==&lt;br /&gt;
&lt;br /&gt;
We should have very basic GTA02 support upstream soon. Once we get to reach this milestone we will check what drivers can be included.&lt;br /&gt;
&lt;br /&gt;
== Issues to solve ==&lt;br /&gt;
&lt;br /&gt;
=== Define how to keep track of the upstream kernel ===&lt;br /&gt;
&lt;br /&gt;
How to up-level the kernel to latest upstream version?&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel</id>
		<title>Kernel</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel"/>
				<updated>2009-04-05T02:37:00Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: Fix. Link later.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Kernel}}&lt;br /&gt;
&lt;br /&gt;
== Is this page meant for you? ==&lt;br /&gt;
&lt;br /&gt;
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 for you. You might want to scroll down for the for the blessed kernels in the daily builds.&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Sister pages ===&lt;br /&gt;
&lt;br /&gt;
# [[Kernel_branches]].&lt;br /&gt;
&lt;br /&gt;
== Sources ==&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
&lt;br /&gt;
http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
&lt;br /&gt;
[http://git-scm.com 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
If you are very new to GIT you might want to read [http://git.or.cz/course/ the good manuals that already available].&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
=== Branches ===&lt;br /&gt;
&lt;br /&gt;
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 (http://git.openmoko.org/?p=kernel.git;a=summary).&lt;br /&gt;
&lt;br /&gt;
The ''andy-tracking'' branch is the one where most of the action takes place these days. &lt;br /&gt;
&lt;br /&gt;
We have [[Kernel_branches|branch policies]] that explain what each branch is for.&lt;br /&gt;
&lt;br /&gt;
=== Daily builds ===&lt;br /&gt;
&lt;br /&gt;
==== Automatic revisions ====&lt;br /&gt;
&lt;br /&gt;
Think of a robot that takes whatever kernels are the most recent in GIT, builds them for you and then makes them available here:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/experimental/&lt;br /&gt;
&lt;br /&gt;
==== Blessed revisions ====&lt;br /&gt;
&lt;br /&gt;
Another robot but this one only builds the versions picked by our friendly [[OpenEmbedded]] developers. Download from:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/unstable/&lt;br /&gt;
&lt;br /&gt;
If you understand OpenEmbedded you will get this: Those versions are tied to a specific GIT revision through conf/distro/include/sane-srcrevs.bb.&lt;br /&gt;
&lt;br /&gt;
=== Building the andy-tracking branch ===&lt;br /&gt;
&lt;br /&gt;
Those are the minimum survival commands:&lt;br /&gt;
&lt;br /&gt;
 $ git clone git://git.openmoko.org/git/kernel.git linux-2.6&lt;br /&gt;
 $ cd linux-2.6&lt;br /&gt;
 $ git-checkout --track -b andy-tracking origin/andy-tracking&lt;br /&gt;
 $ mkdir GTA02 &lt;br /&gt;
 $ cp ./arch/arm/configs/gta02_moredrivers_defconfig GTA02/.config&lt;br /&gt;
&lt;br /&gt;
Before building this kernel you need install a [http://wiki.openmoko.org/wiki/Toolchain#Downloading_and_installing Toolchain].&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
In order to build the modules you can:&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02 dummy&lt;br /&gt;
&lt;br /&gt;
This will create a file called modules-GTA02_andy-tracking-&amp;lt;git hash&amp;gt;.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.&lt;br /&gt;
&lt;br /&gt;
If you want to update the local copy of the repository so that you get the latest changes, you can type:&lt;br /&gt;
&lt;br /&gt;
 $ git-pull&lt;br /&gt;
&lt;br /&gt;
Before reporting that the new kernel does not build please first check for changes in the configuration file provided by Openmoko.&lt;br /&gt;
&lt;br /&gt;
=== kernel building tips ===&lt;br /&gt;
&lt;br /&gt;
If you are modifying Linux kernel code and building it quite often you really want to be using [http://ccache.samba.org ccache]. It will save you a lot of time.&lt;br /&gt;
&lt;br /&gt;
TODO: submit a patch for the build script that makes ccache use easier. '''Note''': There is a [http://lists.openmoko.org/pipermail/openmoko-kernel/2009-March/009139.html patch being reviewed].&lt;br /&gt;
&lt;br /&gt;
== Contributing ==&lt;br /&gt;
&lt;br /&gt;
The development resources [[Openmoko]] offers are:&lt;br /&gt;
&lt;br /&gt;
* Git repository: http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
* [http://lists.openmoko.org/mailman/listinfo/openmoko-kernel Mailing list] ([http://lists.openmoko.org/pipermail/openmoko-kernel/ Online Archive])&lt;br /&gt;
&lt;br /&gt;
We appreciate your contributions. Check the Open Issues at the end of this page to check where we need more help.&lt;br /&gt;
&lt;br /&gt;
If in doubt ask in the mailing list.&lt;br /&gt;
&lt;br /&gt;
== FAQ ==&lt;br /&gt;
&lt;br /&gt;
=== Why does Openmoko cares about sending code upstream instead of (insert your task here)? ===&lt;br /&gt;
&lt;br /&gt;
There are two very different approaches and both of them would be doomed if we stuck all our resources to only one of to them.&lt;br /&gt;
&lt;br /&gt;
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 [http://www.kernel.org upstream] where the people who want to help us improve, maintain and support the code running in our devices hang out.&lt;br /&gt;
&lt;br /&gt;
The second is to care way '''too much''' about upstream to the point that we are not willing to ship a temporal dirty hack that make users happy and able to better use their phones. We cannot afford that kind of purity.&lt;br /&gt;
&lt;br /&gt;
As many things in engineering we have to find a point in the middle that works well -- we will try hard to do it.&lt;br /&gt;
&lt;br /&gt;
=== Who's Andy and why is he sticking his name in the kernel? ===&lt;br /&gt;
&lt;br /&gt;
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. He makes sure that the kernel still builds when Linus and his friends feel like it is time to update the upstream kernel and believe us: it is not as fun as it might sound and it happens often.&lt;br /&gt;
&lt;br /&gt;
Check [[Kernel_branches]] if you care about the details.&lt;br /&gt;
&lt;br /&gt;
=== Kernel developers are not polite! They do not even care to say &amp;quot;Hello&amp;quot; when they reply to my emails! ===&lt;br /&gt;
&lt;br /&gt;
The long version is here: [[Kernel-developers-are-not-polite]].&lt;br /&gt;
&lt;br /&gt;
To the point:&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
They just tend to write very short text because they have to read and write a lot every day.&lt;br /&gt;
&lt;br /&gt;
== Known issues ==&lt;br /&gt;
&lt;br /&gt;
=== Sysfs paths ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[FSO]] developers realized that this problem could be prevented from from happening in the future and they decided to code a nice daemon called [http://www.freesmartphone.org/index.php/Implementations/OpenDeviceDaemon odeviced].&lt;br /&gt;
&lt;br /&gt;
== Open Tickets ==&lt;br /&gt;
&lt;br /&gt;
'''Please read [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component this report]''' if you wish to know what the current issues are.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Easy bugs ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
TODO: list of bugs linking to trac.&lt;br /&gt;
&lt;br /&gt;
=== Normal bugs ===&lt;br /&gt;
&lt;br /&gt;
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. Please do not add a list of bugs here.&lt;br /&gt;
&lt;br /&gt;
'''Read this [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component report]''' to find out more about them.&lt;br /&gt;
&lt;br /&gt;
=== Hard bugs ===&lt;br /&gt;
&lt;br /&gt;
Those are the evil bugs that we haven't fixed either because:&lt;br /&gt;
&lt;br /&gt;
# We do not know how to do it in reasonable time&lt;br /&gt;
# 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)&lt;br /&gt;
# More testing is needed (perhaps a hard-to-reproduce bug)&lt;br /&gt;
&lt;br /&gt;
Here is the list:&lt;br /&gt;
&lt;br /&gt;
* [https://docs.openmoko.org/trac/ticket/2235 #2235 : Monochrome display on resume]&lt;br /&gt;
&lt;br /&gt;
{{Languages|Kernel}}&lt;br /&gt;
&lt;br /&gt;
[[Category:Kernel]]&lt;br /&gt;
[[Category:System Developers]]&lt;br /&gt;
[[Category:Application Developer]]&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel</id>
		<title>Kernel</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel"/>
				<updated>2009-04-05T02:30:43Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: Fix.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Kernel}}&lt;br /&gt;
&lt;br /&gt;
== Is this page meant for you? ==&lt;br /&gt;
&lt;br /&gt;
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 for you. You might want to scroll down for the for the blessed kernels in the daily builds.&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
This page might change soon. See the current [[Kernel-plans]].&lt;br /&gt;
&lt;br /&gt;
=== Sister pages ===&lt;br /&gt;
&lt;br /&gt;
# [[Kernel_branches]].&lt;br /&gt;
&lt;br /&gt;
== Sources ==&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
&lt;br /&gt;
http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
&lt;br /&gt;
[http://git-scm.com 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
If you are very new to GIT you might want to read [http://git.or.cz/course/ the good manuals that already available].&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
=== Branches ===&lt;br /&gt;
&lt;br /&gt;
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 (http://git.openmoko.org/?p=kernel.git;a=summary).&lt;br /&gt;
&lt;br /&gt;
The ''andy-tracking'' branch is the one where most of the action takes place these days. &lt;br /&gt;
&lt;br /&gt;
We have [[Kernel_branches|branch policies]] that explain what each branch is for.&lt;br /&gt;
&lt;br /&gt;
=== Daily builds ===&lt;br /&gt;
&lt;br /&gt;
==== Automatic revisions ====&lt;br /&gt;
&lt;br /&gt;
Think of a robot that takes whatever kernels are the most recent in GIT, builds them for you and then makes them available here:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/experimental/&lt;br /&gt;
&lt;br /&gt;
==== Blessed revisions ====&lt;br /&gt;
&lt;br /&gt;
Another robot but this one only builds the versions picked by our friendly [[OpenEmbedded]] developers. Download from:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/unstable/&lt;br /&gt;
&lt;br /&gt;
If you understand OpenEmbedded you will get this: Those versions are tied to a specific GIT revision through conf/distro/include/sane-srcrevs.bb.&lt;br /&gt;
&lt;br /&gt;
=== Building the andy-tracking branch ===&lt;br /&gt;
&lt;br /&gt;
Those are the minimum survival commands:&lt;br /&gt;
&lt;br /&gt;
 $ git clone git://git.openmoko.org/git/kernel.git linux-2.6&lt;br /&gt;
 $ cd linux-2.6&lt;br /&gt;
 $ git-checkout --track -b andy-tracking origin/andy-tracking&lt;br /&gt;
 $ mkdir GTA02 &lt;br /&gt;
 $ cp ./arch/arm/configs/gta02_moredrivers_defconfig GTA02/.config&lt;br /&gt;
&lt;br /&gt;
Before building this kernel you need install a [http://wiki.openmoko.org/wiki/Toolchain#Downloading_and_installing Toolchain].&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
In order to build the modules you can:&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02 dummy&lt;br /&gt;
&lt;br /&gt;
This will create a file called modules-GTA02_andy-tracking-&amp;lt;git hash&amp;gt;.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.&lt;br /&gt;
&lt;br /&gt;
If you want to update the local copy of the repository so that you get the latest changes, you can type:&lt;br /&gt;
&lt;br /&gt;
 $ git-pull&lt;br /&gt;
&lt;br /&gt;
Before reporting that the new kernel does not build please first check for changes in the configuration file provided by Openmoko.&lt;br /&gt;
&lt;br /&gt;
=== kernel building tips ===&lt;br /&gt;
&lt;br /&gt;
If you are modifying Linux kernel code and building it quite often you really want to be using [http://ccache.samba.org ccache]. It will save you a lot of time.&lt;br /&gt;
&lt;br /&gt;
TODO: submit a patch for the build script that makes ccache use easier. '''Note''': There is a [http://lists.openmoko.org/pipermail/openmoko-kernel/2009-March/009139.html patch being reviewed].&lt;br /&gt;
&lt;br /&gt;
== Contributing ==&lt;br /&gt;
&lt;br /&gt;
The development resources [[Openmoko]] offers are:&lt;br /&gt;
&lt;br /&gt;
* Git repository: http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
* [http://lists.openmoko.org/mailman/listinfo/openmoko-kernel Mailing list] ([http://lists.openmoko.org/pipermail/openmoko-kernel/ Online Archive])&lt;br /&gt;
&lt;br /&gt;
We appreciate your contributions. Check the Open Issues at the end of this page to check where we need more help.&lt;br /&gt;
&lt;br /&gt;
If in doubt ask in the mailing list.&lt;br /&gt;
&lt;br /&gt;
== FAQ ==&lt;br /&gt;
&lt;br /&gt;
=== Why does Openmoko cares about sending code upstream instead of (insert your task here)? ===&lt;br /&gt;
&lt;br /&gt;
There are two very different approaches and both of them would be doomed if we stuck all our resources to only one of to them.&lt;br /&gt;
&lt;br /&gt;
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 [http://www.kernel.org upstream] where the people who want to help us improve, maintain and support the code running in our devices hang out.&lt;br /&gt;
&lt;br /&gt;
The second is to care way '''too much''' about upstream to the point that we are not willing to ship a temporal dirty hack that make users happy and able to better use their phones. We cannot afford that kind of purity.&lt;br /&gt;
&lt;br /&gt;
As many things in engineering we have to find a point in the middle that works well -- we will try hard to do it.&lt;br /&gt;
&lt;br /&gt;
=== Who's Andy and why is he sticking his name in the kernel? ===&lt;br /&gt;
&lt;br /&gt;
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. He makes sure that the kernel still builds when Linus and his friends feel like it is time to update the upstream kernel and believe us: it is not as fun as it might sound and it happens often.&lt;br /&gt;
&lt;br /&gt;
Check [[Kernel_branches]] if you care about the details.&lt;br /&gt;
&lt;br /&gt;
=== Kernel developers are not polite! They do not even care to say &amp;quot;Hello&amp;quot; when they reply to my emails! ===&lt;br /&gt;
&lt;br /&gt;
The long version is here: [[Kernel-developers-are-not-polite]].&lt;br /&gt;
&lt;br /&gt;
To the point:&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
They just tend to write very short text because they have to read and write a lot every day.&lt;br /&gt;
&lt;br /&gt;
== Known issues ==&lt;br /&gt;
&lt;br /&gt;
=== Sysfs paths ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[FSO]] developers realized that this problem could be prevented from from happening in the future and they decided to code a nice daemon called [http://www.freesmartphone.org/index.php/Implementations/OpenDeviceDaemon odeviced].&lt;br /&gt;
&lt;br /&gt;
== Open Tickets ==&lt;br /&gt;
&lt;br /&gt;
'''Please read [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component this report]''' if you wish to know what the current issues are.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Easy bugs ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
TODO: list of bugs linking to trac.&lt;br /&gt;
&lt;br /&gt;
=== Normal bugs ===&lt;br /&gt;
&lt;br /&gt;
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. Please do not add a list of bugs here.&lt;br /&gt;
&lt;br /&gt;
'''Read this [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component report]''' to find out more about them.&lt;br /&gt;
&lt;br /&gt;
=== Hard bugs ===&lt;br /&gt;
&lt;br /&gt;
Those are the evil bugs that we haven't fixed either because:&lt;br /&gt;
&lt;br /&gt;
# We do not know how to do it in reasonable time&lt;br /&gt;
# 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)&lt;br /&gt;
# More testing is needed (perhaps a hard-to-reproduce bug)&lt;br /&gt;
&lt;br /&gt;
Here is the list:&lt;br /&gt;
&lt;br /&gt;
* [https://docs.openmoko.org/trac/ticket/2235 #2235 : Monochrome display on resume]&lt;br /&gt;
&lt;br /&gt;
{{Languages|Kernel}}&lt;br /&gt;
&lt;br /&gt;
[[Category:Kernel]]&lt;br /&gt;
[[Category:System Developers]]&lt;br /&gt;
[[Category:Application Developer]]&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel_Plans</id>
		<title>Kernel Plans</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel_Plans"/>
				<updated>2009-04-05T02:28:21Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: /* Define how to keep track of the upstream kernel */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This document explains the current kernel plan for the GTA01/GTA02 kernel. The idea is to share the motivations behind the actual decisions. This is a draft, and the relevant suggestions will be incorporated into it.&lt;br /&gt;
&lt;br /&gt;
We would like to try this model for one or two months and if we find we are doing something wrong we will update the plans.&lt;br /&gt;
&lt;br /&gt;
== Patch review process ==&lt;br /&gt;
&lt;br /&gt;
If the patch has not issues that we can tell and it is relevant it will be applied. If we can tell it is a good patch right away or that it is a critical fix we will just apply the patch.&lt;br /&gt;
&lt;br /&gt;
Otherwise we will allow for two days before applying non-trivial patches to allow for community feedback and for feedback from subsystem maintainers. In the ideal case we would get ACKs from other developers (like &amp;quot;i like this patch&amp;quot;) but we don't know if we can count on this.&lt;br /&gt;
&lt;br /&gt;
=== Patchwork ===&lt;br /&gt;
&lt;br /&gt;
Patchwork is a nice system. http://patchwork.kernel.org It does not replace a mailing list but it helps keep track of pending patches. We should use it.&lt;br /&gt;
&lt;br /&gt;
== Use tags and not forks for stable kernels ==&lt;br /&gt;
&lt;br /&gt;
We hope that developers actually care about the development branch. If they care, they will helps us reject patches that will likely cause trouble. We will also get more testing.&lt;br /&gt;
&lt;br /&gt;
We will tag stable kernels in the repository.&lt;br /&gt;
&lt;br /&gt;
We know that people like forks and code that does not change often, but the linear model is working with upstream kernel (with a lot more people involved of course).&lt;br /&gt;
&lt;br /&gt;
Of course if you want to create a stable tree you do not need us. You can fork and cherry-pick changes. That's why the current Linux model works.&lt;br /&gt;
&lt;br /&gt;
== Upstream Linux kernel ==&lt;br /&gt;
&lt;br /&gt;
We should have very basic GTA02 support upstream soon. Once we get to reach this milestone we will check what drivers can be included.&lt;br /&gt;
&lt;br /&gt;
== Issues to solve ==&lt;br /&gt;
&lt;br /&gt;
=== Define how to keep track of the upstream kernel ===&lt;br /&gt;
&lt;br /&gt;
How to up-level the kernel to latest upstream version?&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel_Plans</id>
		<title>Kernel Plans</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel_Plans"/>
				<updated>2009-04-05T02:02:17Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: Fix.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This document explains the current kernel plan for the GTA01/GTA02 kernel. The idea is to share the motivations behind the actual decisions. This is a draft, and the relevant suggestions will be incorporated into it.&lt;br /&gt;
&lt;br /&gt;
We would like to try this model for one or two months and if we find we are doing something wrong we will update the plans.&lt;br /&gt;
&lt;br /&gt;
== Patch review process ==&lt;br /&gt;
&lt;br /&gt;
If the patch has not issues that we can tell and it is relevant it will be applied. If we can tell it is a good patch right away or that it is a critical fix we will just apply the patch.&lt;br /&gt;
&lt;br /&gt;
Otherwise we will allow for two days before applying non-trivial patches to allow for community feedback and for feedback from subsystem maintainers. In the ideal case we would get ACKs from other developers (like &amp;quot;i like this patch&amp;quot;) but we don't know if we can count on this.&lt;br /&gt;
&lt;br /&gt;
=== Patchwork ===&lt;br /&gt;
&lt;br /&gt;
Patchwork is a nice system. http://patchwork.kernel.org It does not replace a mailing list but it helps keep track of pending patches. We should use it.&lt;br /&gt;
&lt;br /&gt;
== Use tags and not forks for stable kernels ==&lt;br /&gt;
&lt;br /&gt;
We hope that developers actually care about the development branch. If they care, they will helps us reject patches that will likely cause trouble. We will also get more testing.&lt;br /&gt;
&lt;br /&gt;
We will tag stable kernels in the repository.&lt;br /&gt;
&lt;br /&gt;
We know that people like forks and code that does not change often, but the linear model is working with upstream kernel (with a lot more people involved of course).&lt;br /&gt;
&lt;br /&gt;
Of course if you want to create a stable tree you do not need us. You can fork and cherry-pick changes. That's why the current Linux model works.&lt;br /&gt;
&lt;br /&gt;
== Upstream Linux kernel ==&lt;br /&gt;
&lt;br /&gt;
We should have very basic GTA02 support upstream soon. Once we get to reach this milestone we will check what drivers can be included.&lt;br /&gt;
&lt;br /&gt;
== Issues to solve ==&lt;br /&gt;
&lt;br /&gt;
=== Define how to keep track of the upstream kernel ===&lt;br /&gt;
&lt;br /&gt;
How to move the kernel when new upstream versions are released.&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel_Plans</id>
		<title>Kernel Plans</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel_Plans"/>
				<updated>2009-04-05T01:56:30Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: /* Patch review process */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This document explains the current kernel plan for the GTA01/GTA02 kernel. The idea is to share the motivations behind the actual decisions. This is a draft, and the relevant suggestions will be incorporated into it.&lt;br /&gt;
&lt;br /&gt;
We would like to try this model for one or two months and if we find we are doing something wrong we will update the plans.&lt;br /&gt;
&lt;br /&gt;
== Patch review process ==&lt;br /&gt;
&lt;br /&gt;
If the patch has not issues that we can tell and it is relevant it will be applied. If we can tell it is a good patch right away or that it is a critical fix we will just apply the patch.&lt;br /&gt;
&lt;br /&gt;
Otherwise we will allow for two days before applying non-trivial patches to allow for community feedback and for feedback from subsystem maintainers. In the ideal case we would get ACKs from other developers (like &amp;quot;i like this patch&amp;quot;) but we don't know if we can count on this.&lt;br /&gt;
&lt;br /&gt;
=== Patchwork ===&lt;br /&gt;
&lt;br /&gt;
Patchwork is a nice system. http://patchwork.kernel.org It does not replace a mailing list but it helps keep track of pending patches. We should use it.&lt;br /&gt;
&lt;br /&gt;
== Use tags and not forks for stable kernels ==&lt;br /&gt;
&lt;br /&gt;
We hope that developers actually care about the development branch. If they care, they will helps us reject patches that will likely cause trouble. We will also get more testing.&lt;br /&gt;
&lt;br /&gt;
We will tag stable kernels in the repository.&lt;br /&gt;
&lt;br /&gt;
We know that people like forks and code that does not change often, but the linear model is working with upstream kernel (with a lot more people involved of course).&lt;br /&gt;
&lt;br /&gt;
Of course if you want to create a stable tree you do not need us. You can fork and cherry-pick changes. That's why the current Linux model works.&lt;br /&gt;
&lt;br /&gt;
== Upstream Linux kernel ==&lt;br /&gt;
&lt;br /&gt;
We should have very basic GTA02 support upstream soon. Once we get to reach this milestone we will check what drivers can be included.&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel_Plans</id>
		<title>Kernel Plans</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel_Plans"/>
				<updated>2009-04-05T01:54:17Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: /* Patch review process */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This document explains the current kernel plan for the GTA01/GTA02 kernel. The idea is to share the motivations behind the actual decisions. This is a draft, and the relevant suggestions will be incorporated into it.&lt;br /&gt;
&lt;br /&gt;
We would like to try this model for one or two months and if we find we are doing something wrong we will update the plans.&lt;br /&gt;
&lt;br /&gt;
== Patch review process ==&lt;br /&gt;
&lt;br /&gt;
If the patch has not issues that we can tell and it is relevant it will be applied. If we can tell it is a good patch right away or a critical fix we will just apply the patch.&lt;br /&gt;
&lt;br /&gt;
Allow two days before applying non-trivial patches to allow for community feedback and for feedback from subsystem maintainers.&lt;br /&gt;
&lt;br /&gt;
=== Patchwork ===&lt;br /&gt;
&lt;br /&gt;
Patchwork is a nice system. http://patchwork.kernel.org It does not replace a mailing list but it helps keep track of pending patches. We should use it.&lt;br /&gt;
&lt;br /&gt;
== Use tags and not forks for stable kernels ==&lt;br /&gt;
&lt;br /&gt;
We hope that developers actually care about the development branch. If they care, they will helps us reject patches that will likely cause trouble. We will also get more testing.&lt;br /&gt;
&lt;br /&gt;
We will tag stable kernels in the repository.&lt;br /&gt;
&lt;br /&gt;
We know that people like forks and code that does not change often, but the linear model is working with upstream kernel (with a lot more people involved of course).&lt;br /&gt;
&lt;br /&gt;
Of course if you want to create a stable tree you do not need us. You can fork and cherry-pick changes. That's why the current Linux model works.&lt;br /&gt;
&lt;br /&gt;
== Upstream Linux kernel ==&lt;br /&gt;
&lt;br /&gt;
We should have very basic GTA02 support upstream soon. Once we get to reach this milestone we will check what drivers can be included.&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel_Plans</id>
		<title>Kernel Plans</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel_Plans"/>
				<updated>2009-04-05T01:51:56Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: Fix.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This document explains the current kernel plan for the GTA01/GTA02 kernel. The idea is to share the motivations behind the actual decisions. This is a draft, and the relevant suggestions will be incorporated into it.&lt;br /&gt;
&lt;br /&gt;
We would like to try this model for one or two months and if we find we are doing something wrong we will update the plans.&lt;br /&gt;
&lt;br /&gt;
== Patch review process ==&lt;br /&gt;
&lt;br /&gt;
If the patch has not issues that we can tell and it is relevant it will be applied. If we can tell it is a good patch right away or a critical fix we will just apply the patch.&lt;br /&gt;
&lt;br /&gt;
Allow two days before applying non-trivial patches to allow for community feedback and for feedback from subsystem maintainers.&lt;br /&gt;
&lt;br /&gt;
== Use tags and not forks for stable kernels ==&lt;br /&gt;
&lt;br /&gt;
We hope that developers actually care about the development branch. If they care, they will helps us reject patches that will likely cause trouble. We will also get more testing.&lt;br /&gt;
&lt;br /&gt;
We will tag stable kernels in the repository.&lt;br /&gt;
&lt;br /&gt;
We know that people like forks and code that does not change often, but the linear model is working with upstream kernel (with a lot more people involved of course).&lt;br /&gt;
&lt;br /&gt;
Of course if you want to create a stable tree you do not need us. You can fork and cherry-pick changes. That's why the current Linux model works.&lt;br /&gt;
&lt;br /&gt;
== Upstream Linux kernel ==&lt;br /&gt;
&lt;br /&gt;
We should have very basic GTA02 support upstream soon. Once we get to reach this milestone we will check what drivers can be included.&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel_Plans</id>
		<title>Kernel Plans</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel_Plans"/>
				<updated>2009-04-05T01:30:00Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: Fix.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This document explains the current kernel plan for the GTA01/GTA02 kernel. The idea is to share&lt;br /&gt;
the motivations behind the actual decisions. This is a draft, and the relevant suggestions will be incorporated into it.&lt;br /&gt;
&lt;br /&gt;
We would like to try this model for one or two months and if we find we are doing something wrong we will update the plans.&lt;br /&gt;
&lt;br /&gt;
== Patch review process ==&lt;br /&gt;
&lt;br /&gt;
Allow 2 days before applying non-trivial patches to allow for community feedback and for feedback from subsystem maintainers. If the patch has not issues that we can tell and it is relevant it will be applied. If we can tell it is a good patch right away or a critical fix it we will just apply the patch.&lt;br /&gt;
&lt;br /&gt;
== Use tags and not forks for stable kernels ==&lt;br /&gt;
&lt;br /&gt;
We hope that developers actually care about the development branch. If they care, they will helps us reject patches that will likely cause trouble. We will also get more testing.&lt;br /&gt;
&lt;br /&gt;
We will tag stable kernels in the repository.&lt;br /&gt;
&lt;br /&gt;
We know that people like forks and code that does not change often, but the linear model is working with upstream kernel (with a lot more people involved of course).&lt;br /&gt;
&lt;br /&gt;
== Upstream Linux kernel ==&lt;br /&gt;
&lt;br /&gt;
We should have very basic GTA02 support upstream soon. Once we get to reach this milestone we will check what drivers can be included.&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel_Plans</id>
		<title>Kernel Plans</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel_Plans"/>
				<updated>2009-04-05T01:28:04Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This document explains the current kernel plan for the GTA01/GTA02 kernel. The idea is to share&lt;br /&gt;
the motivations behind the actual decisions. This is a draft, and the relevant suggestions will be incorporated into it.&lt;br /&gt;
&lt;br /&gt;
We would like to try this model for one or two months and if we find we are doing something wrong we will update the plans.&lt;br /&gt;
&lt;br /&gt;
== Path review process ==&lt;br /&gt;
&lt;br /&gt;
Allow 2 days before applying non-trivial patches to allow for community feedback and for feedback from subsystem maintainers. If the patch has not issues that we can tell and it is relevant it will be applied.&lt;br /&gt;
&lt;br /&gt;
== Use tags and not forks for stable kernels ==&lt;br /&gt;
&lt;br /&gt;
We hope that developers actually care about the development branch. If they care, they will helps us reject patches that will likely cause trouble. We will also get more testing.&lt;br /&gt;
&lt;br /&gt;
We will tag stable kernels in the repository.&lt;br /&gt;
&lt;br /&gt;
We know that people like forks and code that does not change often, but the linear model is working with upstream kernel (with a lot more people involved of course).&lt;br /&gt;
&lt;br /&gt;
== Upstream Linux kernel ==&lt;br /&gt;
&lt;br /&gt;
We should have very basic GTA02 support upstream soon. Once we get to reach this milestone we will check what drivers can be included.&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel_Plans</id>
		<title>Kernel Plans</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel_Plans"/>
				<updated>2009-04-05T01:25:48Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: Fix&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;his document explain the current kernel plan for the GTA01/GTA02 kernel. The idea is to share&lt;br /&gt;
the motivations behind current decisions and the actual decisions. This is a draft, and&lt;br /&gt;
suggestions might be incorporated to it.&lt;br /&gt;
&lt;br /&gt;
We would like to try this model for one or two months and if we find we are doing something wrong we will update the plans.&lt;br /&gt;
&lt;br /&gt;
== Path review process ==&lt;br /&gt;
&lt;br /&gt;
Allow 2 days before applying non-trivial patches to allow for community feedback and for feedback from subsystem maintainers. If the patch has not issues that we can tell and it is relevant it will be applied.&lt;br /&gt;
&lt;br /&gt;
== Use tags and not forks for stable kernels ==&lt;br /&gt;
&lt;br /&gt;
We hope that developers actually care about the development branch. If they care, they will helps us reject patches that will likely cause trouble. We will also get more testing.&lt;br /&gt;
&lt;br /&gt;
We will tag stable kernels in the repository.&lt;br /&gt;
&lt;br /&gt;
We know that people like forks and code that does not change often, but the linear model is working with upstream kernel (with a lot more people involved of course).&lt;br /&gt;
&lt;br /&gt;
== Upstream Linux kernel ==&lt;br /&gt;
&lt;br /&gt;
We should have very basic GTA02 support upstream soon. Once we get to reach this milestone we will check what drivers can be included.&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel_Plans</id>
		<title>Kernel Plans</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel_Plans"/>
				<updated>2009-04-05T01:23:55Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: /* Path review process */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;his document explain the current kernel plan for the GTA01/GTA02 kernel. The idea is to share&lt;br /&gt;
the motivations behind current decisions and the actual decisions. This is a draft, and&lt;br /&gt;
suggestions might be incorporated to it.&lt;br /&gt;
&lt;br /&gt;
We would like to try this model for one or two and if we find we are doing something wrong we will update the plans.&lt;br /&gt;
&lt;br /&gt;
== Path review process ==&lt;br /&gt;
&lt;br /&gt;
Allow 2 days before applying non-trivial patches to allow for community feedback and for feedback from subsystem maintainers. If the patch has not issues that we can tell and it is relevant it will be applied.&lt;br /&gt;
&lt;br /&gt;
== Use tags and not forks for stable kernels ==&lt;br /&gt;
&lt;br /&gt;
We hope that developers actually care about the development branch. If they care, they will helps us reject patches that will likely cause trouble. We will also get more testing.&lt;br /&gt;
&lt;br /&gt;
We will tag stable kernels in the repository.&lt;br /&gt;
&lt;br /&gt;
We know that people like forks and code that does not change often, but the linear model is working with upstream kernel (with a lot more people involved of course).&lt;br /&gt;
&lt;br /&gt;
== Upstream Linux kernel ==&lt;br /&gt;
&lt;br /&gt;
We should have very basic GTA02 support upstream soon. Once we get to reach this milestone we will check what drivers can be included.&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel_Plans</id>
		<title>Kernel Plans</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel_Plans"/>
				<updated>2009-04-05T01:23:39Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: First verision&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;his document explain the current kernel plan for the GTA01/GTA02 kernel. The idea is to share&lt;br /&gt;
the motivations behind current decisions and the actual decisions. This is a draft, and&lt;br /&gt;
suggestions might be incorporated to it.&lt;br /&gt;
&lt;br /&gt;
We would like to try this model for one or two and if we find we are doing something wrong we will update the plans.&lt;br /&gt;
&lt;br /&gt;
== Path review process ==&lt;br /&gt;
&lt;br /&gt;
 Allow 2 days before applying non-trivial patches to allow for community feedback and for feedback from subsystem maintainers. If the patch has not issues that we can tell and it is relevant it will be applied.&lt;br /&gt;
&lt;br /&gt;
== Use tags and not forks for stable kernels ==&lt;br /&gt;
&lt;br /&gt;
We hope that developers actually care about the development branch. If they care, they will helps us reject patches that will likely cause trouble. We will also get more testing.&lt;br /&gt;
&lt;br /&gt;
We will tag stable kernels in the repository.&lt;br /&gt;
&lt;br /&gt;
We know that people like forks and code that does not change often, but the linear model is working with upstream kernel (with a lot more people involved of course).&lt;br /&gt;
&lt;br /&gt;
== Upstream Linux kernel ==&lt;br /&gt;
&lt;br /&gt;
We should have very basic GTA02 support upstream soon. Once we get to reach this milestone we will check what drivers can be included.&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Hints_on_using_GIT_and_stgit</id>
		<title>Hints on using GIT and stgit</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Hints_on_using_GIT_and_stgit"/>
				<updated>2009-03-31T16:52:52Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: The quotes are useful in case of names with more of one word. I got bit by this when using the stg-send-email script.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Overview: stgit and git=&lt;br /&gt;
Linus Torvalds invented git and uses it heavily in Linux development, most people would take that as an impressive suggestion it might be useful in kernel and similar development work.&lt;br /&gt;
&lt;br /&gt;
* '''git''' is a lightweight distributed revision control system.  In practical terms, it adds a ./.git directory in the top level of your project, git stores everything in there about your project including all the revisions.  The commands all start &amp;quot;git &amp;lt;something&amp;gt;&amp;quot;.  ''Nice feature: if you create tarball of your project directory, you will also capture all your project history as it will archive ./.git''&lt;br /&gt;
&lt;br /&gt;
* '''stgit''' does a similar job to quilt, using the same kind of verbs like top, push, pop, refresh and so on, but it is internally completely aware it is running on top of git, and it too stores all its files down ./.git so you backup stgit's state completely with tar too.  The commands all start &amp;quot;stg &amp;lt;something&amp;gt;&amp;quot;.  ''Nice feature: while quilt makes you do &amp;quot;quilt add&amp;quot; before you modify a file, stgit does not need it: it knows what you changed without being told by checking because of its integration with git.  (You still have to do &amp;quot;stg add&amp;quot; if you created a new file though; that also adds it to git.)''&lt;br /&gt;
&lt;br /&gt;
'''Your stgit patch stack appears in your local git repo in a synchronized way, without explicit commits''' -- as you add, edit and remove patches in stgit your git repo is making the same moves, without losing the patch stack.&lt;br /&gt;
&lt;br /&gt;
When you use the two together, you have a fast and flexible system for dealing with many branches of large source trees, rebasing them in a controlled way, and generating and managing patches to export elsewhere.&lt;br /&gt;
&lt;br /&gt;
=Setting up your development box=&lt;br /&gt;
You just need to install the '''git''' and '''stgit''' packages for your distribution.  There are GUI tools like '''qgit''' that can be helpful to navigate projects that you can install too.&lt;br /&gt;
&lt;br /&gt;
You can optionally edit your ~/.bashrc to define some environment variables to control your commit identity for git&lt;br /&gt;
&lt;br /&gt;
* export GIT_AUTHOR_NAME=&amp;quot;yourhandle&amp;quot;&lt;br /&gt;
* export GIT_COMMITTER_NAME=&amp;quot;yourhandle&amp;quot;&lt;br /&gt;
* export GIT_AUTHOR_EMAIL=&amp;quot;your@email&amp;quot;&lt;br /&gt;
* export GIT_COMMITTER_EMAIL=&amp;quot;your@email&amp;quot;&lt;br /&gt;
&lt;br /&gt;
=Beginning with git and stgit=&lt;br /&gt;
&lt;br /&gt;
==Adding git and stgit to an existing project of your own==&lt;br /&gt;
# cd to the top level of your project&lt;br /&gt;
# '''git init''' -- this creates an empty ./.git tree with a &amp;quot;master&amp;quot; branch only&lt;br /&gt;
# '''make distclean''' -- or equivalent - clean out all generated files&lt;br /&gt;
# '''git add *''' -- prepares to make an initial commit of all your stuff&lt;br /&gt;
# '''git commit''' -- takes a commit message (like, &amp;quot;initial commit&amp;quot;) in vi and stores all the added files into the repo&lt;br /&gt;
# '''stg init''' -- initializes the stgit state for the new branch&lt;br /&gt;
&lt;br /&gt;
The git init command should have created a default ''.gitignore'' file at the top level directory of your project -- you can edit this to ensure that any generated files other than the default *.o and so on are ignored by git if you need to, normally the default ones are enough.&lt;br /&gt;
&lt;br /&gt;
==Cloning a remote git repo and adding stgit==&lt;br /&gt;
If you want to work on a tree that already existed in a remote repo, the first move is to '''clone''' it.  This is different than &amp;quot;checking it out&amp;quot;, when you clone it you are not just getting HEAD but *all revisions* of the project.  (If the remote repo lost everything about that project tomorrow, what you cloned would be a full replacement for what it had.)&lt;br /&gt;
&lt;br /&gt;
# '''git clone git://git.openmoko.org/git/kernel.git linux-2.6''' -- this example shows how to pull the 2.6 tracking project into a new local directory called &amp;quot;linux-2.6&amp;quot;&lt;br /&gt;
# '''git branch -a''' -- list all the branches available in the repo we just pulled&lt;br /&gt;
# '''git checkout origin/andy''' -- configures the source files in the directory to reflect the state of the origin/andy branch instead of the default master branch.  The &amp;quot;origin/&amp;quot; part is added in your local copy of the repo only for branches coming from upstream.&lt;br /&gt;
# '''git checkout -b fix-andys-bugs''' -- create a local branch based on origin/andy so you can do work on top of it&lt;br /&gt;
# '''stg init''' -- prepare your fix-andys-bugs branch to be used with stgit&lt;br /&gt;
&lt;br /&gt;
What you end up there is a local branch fix-andys-bugs which has no patch stack, but is at exactly the state of origin/andy.  So when you add local patches, they are against current origin/andy.&lt;br /&gt;
&lt;br /&gt;
==Safe experimentation==&lt;br /&gt;
Don't forget to tarball up your project directory before doing an experiment with git and stgit, until you are used to it.  The tarball will fully capture and restore the project and git / stgit state, so you can try things without worrying about how to &amp;quot;hit undo&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
=Workflow=&lt;br /&gt;
==Basic stgit Workflow==&lt;br /&gt;
Using stgit is a great deal like using quilt.&lt;br /&gt;
&lt;br /&gt;
* '''stg new my-patch-description.patch''' -- adds a new empty patch to the top of the stack and opens vi to add a description for the patch -- you need to ensure the first line of the description is &amp;quot;my-patch-description.patch&amp;quot;, to avoid the patch filename getting lost if the patch is later pulled from git directly&lt;br /&gt;
&lt;br /&gt;
* '''stg series''' lets you see the patch stack and where you are on it&lt;br /&gt;
&lt;br /&gt;
* '''stg top''' lets you see the current top patch you would be modifying&lt;br /&gt;
&lt;br /&gt;
* Then you just start editing files.  If you create any new files, you should do '''stg add &amp;lt;filepath&amp;gt;''' which adds the file to git and the current stgit patch.  If you deleted a file from the project as part of this patch, you can do '''stg rm &amp;lt;filepath&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
* If you are worried about ensuring that you included any new files with stg add, you can do '''stg status''' at any time to see if there are files around that git does not know about&lt;br /&gt;
&lt;br /&gt;
* '''stg refresh''' -- regenerates the top patch by finding all the edits you made&lt;br /&gt;
&lt;br /&gt;
* '''stg show''' -- displays the top patch in vi&lt;br /&gt;
&lt;br /&gt;
* '''stg pop''' and '''stg push''' move up and down the patch stack&lt;br /&gt;
&lt;br /&gt;
* '''stg pop --all''' and '''stg push --all''' pop or push to the start or end of the series in one action&lt;br /&gt;
&lt;br /&gt;
* '''stg goto &amp;lt;patchname&amp;gt;''' is a nice feature that pushes or pops as needed to get the requested patch to be the current top one.  &amp;lt;patchname&amp;gt; is a name that appears in the series, eg, my-patch.patch&lt;br /&gt;
&lt;br /&gt;
* '''stg delete &amp;lt;patchname&amp;gt;''' or, eg '''stg delete `stg top`''' will pop and delete the given patch (or the current top patch in the second example).&lt;br /&gt;
&lt;br /&gt;
==Clearing merge problems==&lt;br /&gt;
If you experience a genuine merge problem during an stg push for example, stgit will tell you about which source file had the problem, and where it put a copy of the merge diff.  When you cleared the problem, you must run&lt;br /&gt;
&lt;br /&gt;
'''stg resolved &amp;lt;filepath&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
to tell stgit that you have resolved the merge problem in &amp;lt;filepath&amp;gt;.  Then you will be able to do&lt;br /&gt;
&lt;br /&gt;
'''stg refresh'''&lt;br /&gt;
&lt;br /&gt;
to capture the changes under that patch and go on about your business.&lt;br /&gt;
&lt;br /&gt;
==Exporting patches==&lt;br /&gt;
Exporting patches is super easy&lt;br /&gt;
&lt;br /&gt;
'''stg export'''&lt;br /&gt;
&lt;br /&gt;
will very rapidly export your whole patch stack in a directory ./patches-&amp;lt;branch&amp;gt; and create a series file in there as well.  If you append a patch name to stg export, it just exports that one to the same directory.&lt;br /&gt;
&lt;br /&gt;
==Importing patches==&lt;br /&gt;
You can import individual patches with&lt;br /&gt;
&lt;br /&gt;
'''stg import &amp;lt;path to patch&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
or a whole series at a time by pointing it to the series&lt;br /&gt;
&lt;br /&gt;
'''stg import -i -s &amp;lt;path to series file&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
The patches are imported to be above the current applied patch top, which doesn't have to be the top of your patch series.&lt;br /&gt;
&lt;br /&gt;
BUT stgit is picky about patch formatting on import.&lt;br /&gt;
&lt;br /&gt;
* The first line of the patch file should be the patch's own filename, eg, my-patch.patch should have a first line of my-patch.patch.  This is so that later recovery of the patch from git into stgit will result in the same filename used for the patch, and a consistent name is shown in gitweb (the web interface for git repos as used in git.openmoko.org)&lt;br /&gt;
&lt;br /&gt;
* It will spew warnings about whitespace problems in the patch according to kernel rules, then quench them and report the total (thousands in the case of the YAFFS patch...).  Kernel folks take the whitespace rules seriously, but the import will proceed okay.&lt;br /&gt;
&lt;br /&gt;
* A serious one -- stgit has a bug at the moment where it will fail to recognize some diff headers sometimes.  The workaround is to add a line&lt;br /&gt;
&lt;br /&gt;
:''Index: blah''&lt;br /&gt;
&lt;br /&gt;
:after the patch description and the first patch header, which allows it to match.  You have to watch closely for this one because you only get a warning &amp;quot;''Warning: No diff found, creating empty patch''&amp;quot;, and stgit has imported the whole patch silently as a long description with no diff!  The diff appears in the description though so if you didn't know about the problem, it looks like a diff is in there!  However, you can find these bad imports easily enough -- do an stg pop --all, then stg push one at a time.  If a patch had this problem on import, the stg push will give a result like this&lt;br /&gt;
&lt;br /&gt;
:''Pushing patch &amp;quot;gta01-no_nand_partitions.patch&amp;quot; ... done (empty patch)''&lt;br /&gt;
&lt;br /&gt;
:You should do an '''stg remove `stg top`''', edit the patch to add the &amp;quot;Index: blah&amp;quot; workaround, and then re-import with '''stg import &amp;lt;path to patch&amp;gt;'''.  You can then go on with pushing the other patches.&lt;br /&gt;
&lt;br /&gt;
:Patches that are produced by git should be fine -- they have the Index: line already attached.  I guess the stgit guys are only using patches from other git users and that is why this bug survives.&lt;br /&gt;
&lt;br /&gt;
* Another serious one -- no fuzz is allowed in the incoming patch matching by default.  It means that an incoming patch that will apply with the patch utility will claim to be a failure during '''stg import'''.  The procedure to cope with this is to iteratively '''stg import -i -s &amp;lt;path to series file&amp;gt;''', and when you have a failure due to fuzz&lt;br /&gt;
&lt;br /&gt;
::a=&amp;lt;path to patches dir&amp;gt;/`stg top`; patch -p1 &amp;lt;$a &amp;amp;&amp;amp; if [ ! -z &amp;quot;`grep -- \-\-\-\ \/dev\/null $a`&amp;quot; ] ; then stg add `cat $a | sed -n '/\-\-\-\ \/dev\/null/{n;p;}' | cut -d' ' -f2 | cut -f1 | cut -d'/' -f2-` ; fi &amp;amp;&amp;amp; stg refresh&lt;br /&gt;
&lt;br /&gt;
:then resume the series import by repeating that command.  If the patch itself really didn't apply fully, you can either merge it by hand if it is a genuine issue, or you can back out that import and fully recover by '''stg refresh''' then '''stg delete `stg top`''' and you can try to fix the patch and re-import it again.&lt;br /&gt;
&lt;br /&gt;
Typically you are importing external patches once, but if you need to accept patches on a continuing basis you should export any patches that caused trouble from stgit once they are imported, and provide these versions back to where your imported patches came from so that ongoing patch updates will go in without difficulty next time.  Most times you are in fact removing fuzz from the patches by doing this.&lt;br /&gt;
&lt;br /&gt;
==Identifying patches that changed a file==&lt;br /&gt;
Sometimes you see there is a problem in a source file you need to fix, but you want to make sure the fix goes in the right patch and you don't know which is the right one.&lt;br /&gt;
&lt;br /&gt;
'''stg patches &amp;lt;file&amp;gt;''' will list all the patches ''in the current branch patch stack'' that modfied &amp;lt;file&amp;gt;.  You can then use '''stg goto &amp;lt;patch name&amp;gt;''' to move to that patch in the patch stack and make the edit in that context.&lt;br /&gt;
&lt;br /&gt;
=Branches and rebasing=&lt;br /&gt;
==Introducing branches==&lt;br /&gt;
You can make hierarchies of branched versions in git/stgit really easily with minimal disturbance.  The main thing you have to watch is that your &amp;quot;current working directory&amp;quot; as it were, the current branch you are in, is the one you think it is.  You can check that with&lt;br /&gt;
&lt;br /&gt;
* '''git branch''' or '''stg branch''' if the branch is initialized with stgit&lt;br /&gt;
&lt;br /&gt;
You can move to an existing stgit-initialized branch with&lt;br /&gt;
&lt;br /&gt;
* '''stg branch mybranch'''&lt;br /&gt;
&lt;br /&gt;
:what this does is literally add, delete and modify the files in the project directory so they correspond to the state you left the &amp;quot;mybranch&amp;quot; branch at.  Because of that, stgit takes care to first check there are no un-refreshed changes in the current branch before allowing the move to the different branch.&lt;br /&gt;
&lt;br /&gt;
:It also configures stgit with ''that branch's'' patch stack, leaving the patch stack for whatever branch you were on safely with that branch.&lt;br /&gt;
&lt;br /&gt;
* '''git branch mynewbranch'''&lt;br /&gt;
* '''stg branch mynewbranch'''&lt;br /&gt;
* '''stg init'''&lt;br /&gt;
&lt;br /&gt;
:creates a new branch if the branch &amp;quot;mynewbranch&amp;quot; didn't already exist -- this new branch is &amp;quot;based on&amp;quot; the branch you were on when you created it.&lt;br /&gt;
&lt;br /&gt;
* '''git branch -d myoldbranch''' deletes myoldbranch when you're finished with it&lt;br /&gt;
&lt;br /&gt;
==Rebasing==&lt;br /&gt;
The branching stuff initially sounds like it can be a can of worms, because once you made these easy, cheap branches, what do you do when the thing you based it on gets new patches and commits?  Your stuff is still based on the parent's version at the time you branched it, right?  Isn't it just a big mess?&lt;br /&gt;
&lt;br /&gt;
It's true that your branch will stay at the parent's version at the time it was branched, even if new commits come into the parent branch -- until you '''rebase''' it.  Git and stgit together make rebasing almost as easy as spawning the new branch.  Let's say we had the default &amp;quot;master&amp;quot; branch and we made a new branch from it&lt;br /&gt;
&lt;br /&gt;
* '''stg branch master''' -- go to the master branch&lt;br /&gt;
* '''git branch newbranch''' -- create a branch off of master called newbranch&lt;br /&gt;
* '''stg branch newbranch''' -- move stgit to the new child branch&lt;br /&gt;
* '''stg init''' -- prepare newbranch to work with stgit&lt;br /&gt;
* '''stg series''' -- observe there are no patches yet in the new child branch&lt;br /&gt;
&lt;br /&gt;
Then we did lots of work on newbranch&lt;br /&gt;
&lt;br /&gt;
* '''stg new my-super-patch.patch'''&lt;br /&gt;
* &amp;lt;edits&amp;gt;&lt;br /&gt;
* '''stg refresh'''&lt;br /&gt;
* '''stg new another-awesome-patch.patch'''&lt;br /&gt;
* &amp;lt;edits&amp;gt;&lt;br /&gt;
* '''stg refresh'''&lt;br /&gt;
&lt;br /&gt;
But then we decided we needed to update master (in this example master pulls from a remote repo to get updates) perhaps to get a bugfix&lt;br /&gt;
&lt;br /&gt;
* '''stg branch master''' -- go to the master branch&lt;br /&gt;
* '''git pull''' -- collect any new commits&lt;br /&gt;
* '''stg branch newbranch''' -- go back to newbranch (it's unchanged)&lt;br /&gt;
&lt;br /&gt;
and we wanted those updates on newbranch too.  Easy (we are in newbranch again remember)&lt;br /&gt;
&lt;br /&gt;
* '''stg pop --all''' -- pop all our newbranch patches&lt;br /&gt;
* '''git reset --hard origin/stable''' -- reset our branch to current origin/stable&lt;br /&gt;
* '''stg push --all''' -- push all our newbranch patches back on&lt;br /&gt;
&lt;br /&gt;
So we are able to update master and reset newbranch to start from the new master HEAD without disturbing the patch series associated with newbranch, except we have to push them back on and deal with any failures to merge due to conflicting edits in the new patches... but that's what we have to do anyway, and we can do it inside the patch stack system.&lt;br /&gt;
&lt;br /&gt;
==Practical use for branches==&lt;br /&gt;
The kernel trees in git currently use branches in a structured way to allow staged rebasing.  &lt;br /&gt;
&lt;br /&gt;
* The default '''master''' branch is just the vanilla kernel.org kernel, either tracking git or at a fixed stable version.&lt;br /&gt;
&lt;br /&gt;
* A '''mokopatches''' branch off master contains the current Openmoko kernel patchset for the kernel&lt;br /&gt;
&lt;br /&gt;
* A '''development''' (or some other names) branch(es) off '''mokopatches''' then contains just the patch stack that is being worked on in that branch for whatever reason&lt;br /&gt;
&lt;br /&gt;
This allows master to be pulled from kernel.org or otherwise updated when needed, separately the moko patchset can be updated when needed and lastly the working branches can be rebased as described above when needed&lt;br /&gt;
&lt;br /&gt;
=stgit and branch history=&lt;br /&gt;
==stgit uses git history to track applied patches==&lt;br /&gt;
stgit has a very tight coupling to git commits -- when you stg pop a patch the patch is undone on the files and the commit history for the patch is '''erased''', not reverted.  This works great for local use, since the patch stack retains the information needed to bring the patch back with stg push again and you didn't care about tracking your history of pushing and popping patches from the stack since you do it all the time randomly.  The git 'history' in the local case is just reflecting the currently applied patchset rather than any actual 'history'.&lt;br /&gt;
&lt;br /&gt;
==Public trees use git history as history to sync against==&lt;br /&gt;
The problems start when another repo, say a public repo you push to, or pull from, will have its own commit history for that project.  If you clone the remote repo locally and then use stgit directly on the branches, say to stg uncommit and then stg delete a patch, your git history for that branch is no longer an unbroken thread in agreement with the origin: the uncommit snipped a bit of the history off on your version.  You won't be able to push any more to the other repo: git will give you an error.&lt;br /&gt;
&lt;br /&gt;
==Either: 1: Only use stgit on local-only or temporary branches==&lt;br /&gt;
The only way to maintain a consistent public history for people to work with is to never erase history with stgit on those shared branches.  It means that you have to work on a temporary branch and export the patches, importing them into your stable branch in a single action without using stgit... but if you have to remove a patch that was committed to the stable branch, use '''git revert''' to issue an anti-patch.&lt;br /&gt;
&lt;br /&gt;
==Or: 2: Your public repo branch is a &amp;quot;mirror&amp;quot;==&lt;br /&gt;
The other way to deal with this is to accept that the public repo isn't there to maintain a project history but to make public your branch in a &amp;quot;snapshot&amp;quot; kind of mode.&lt;br /&gt;
&lt;br /&gt;
You do this by pushing your local branch using this syntax:&lt;br /&gt;
&lt;br /&gt;
'''git push ssh://git@git.openmoko.org/&amp;lt;projectname&amp;gt; +&amp;lt;remote-branch-name&amp;gt;:&amp;lt;local-branch-name&amp;gt;;'''&lt;br /&gt;
&lt;br /&gt;
...this will overwrite &amp;lt;remote-branch-name&amp;gt; with the contents of &amp;lt;local-branch-name&amp;gt;.  So when you want to expose a snapshot of your branch state on the public repo, you run the line above to force the remote branch into sync with yours.&lt;br /&gt;
&lt;br /&gt;
=Making your tree public on git.openmoko.org=&lt;br /&gt;
# go to http://admin-trac.openmoko.org and open a ticket&lt;br /&gt;
# attach your public key to the ticket and also add some descriptions.&lt;br /&gt;
&lt;br /&gt;
=Useful scripts=&lt;br /&gt;
&lt;br /&gt;
== Create a new patch ==&lt;br /&gt;
&lt;br /&gt;
 #!/bin/sh&lt;br /&gt;
 NAME=&amp;quot;Britney Spears&amp;quot;&lt;br /&gt;
 EMAIL=&amp;quot;britney@spears&amp;quot;&lt;br /&gt;
 if [ -z &amp;quot;$1&amp;quot; ] ; then&lt;br /&gt;
  echo &amp;quot;Usage: $0 patch-name.patch&amp;quot;&lt;br /&gt;
  exit 1&lt;br /&gt;
 fi&lt;br /&gt;
 PATCHNAME=$1&lt;br /&gt;
 stg new --author &amp;quot;$NAME &amp;lt;$EMAIL&amp;gt;&amp;quot; --commname=&amp;quot;$NAME&amp;quot; --commemail=&amp;quot;$EMAIL&amp;quot; --sign --message=&amp;quot;$PATCHNAME&amp;quot; $PATCHNAME&lt;br /&gt;
&lt;br /&gt;
==Check a patch for correctness==&lt;br /&gt;
&lt;br /&gt;
 #!/bin/sh&lt;br /&gt;
 PATCH=$1&lt;br /&gt;
 echo `pwd`&lt;br /&gt;
 if [ -z &amp;quot;$1&amp;quot; ] ; then&lt;br /&gt;
  stg refresh&lt;br /&gt;
  PATCH=`stg top`&lt;br /&gt;
  echo &amp;quot;*** checking top patch $PATCH&amp;quot;&lt;br /&gt;
 fi&lt;br /&gt;
 while [ ! -f ./scripts/checkpatch.pl ]; do&lt;br /&gt;
   cd ..&lt;br /&gt;
   echo looking for checkpatch.pl, cd `pwd`&lt;br /&gt;
 done&lt;br /&gt;
 if [ -f ./scripts/checkpatch.pl ]; then&lt;br /&gt;
   stg export $PATCH &amp;amp;&amp;amp; \&lt;br /&gt;
   ./scripts/checkpatch.pl -strict patches-`stg branch`/$PATCH&lt;br /&gt;
 else&lt;br /&gt;
   echo &amp;quot;./scripts/checkpatch.pl not found.&amp;quot;&lt;br /&gt;
   echo &amp;quot;Please cd to the kernel tree!&amp;quot;&lt;br /&gt;
 fi&lt;br /&gt;
&lt;br /&gt;
==Sending a set of patches==&lt;br /&gt;
&lt;br /&gt;
Send a patch using a gmail account. You have to find a way to make this work for you with another provider.&lt;br /&gt;
&lt;br /&gt;
 OPT=&lt;br /&gt;
 #TO=linux-kernel@vger.kernel.org # mainline!&lt;br /&gt;
 #TO=openmoko-kernel@lists.openmoko.org # OM people&lt;br /&gt;
 TO=new_kernel_hacker@gmail.com # Send these first for yourself and check!&lt;br /&gt;
 &lt;br /&gt;
 echo &amp;quot;pass:&amp;quot;&lt;br /&gt;
 read -s PASS&lt;br /&gt;
 #OPT=-e # Edit first message&lt;br /&gt;
 OPT=-E # Edit each patch before sending it, do not get used to this.&lt;br /&gt;
 &lt;br /&gt;
 GMAIL_USER_NAME=new_kernel_hacker&lt;br /&gt;
 &lt;br /&gt;
 # this will disclose your password to ps! I am the only user in my machine&lt;br /&gt;
 # thus I don't care much. A better way to do this?&lt;br /&gt;
 stg mail $OPT -a --to $TO --smtp-server smtp.gmail.com:587 -u $GMAIL_USER_NAME -p $PASS -T $OPT&lt;br /&gt;
&lt;br /&gt;
{{Languages|Hints_on_using_GIT_and_stgit}}&lt;br /&gt;
&lt;br /&gt;
[[Category:System Developers]]&lt;br /&gt;
[[Category:Application Developer]]&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/User:Arhuaco</id>
		<title>User:Arhuaco</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/User:Arhuaco"/>
				<updated>2009-03-11T08:58:25Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: Updated...&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Only edit to correct a spelling or grammar mistakes'''.&lt;br /&gt;
&lt;br /&gt;
== Current Priority ==&lt;br /&gt;
&lt;br /&gt;
Help include support for the GTA02/[[Freerunner]] into the upstream Linux Kernel.&lt;br /&gt;
&lt;br /&gt;
== Currently working on ==&lt;br /&gt;
&lt;br /&gt;
* Send GTA02 basic support upstream (so that we can start sending drivers)&lt;br /&gt;
** I started from this work done [http://lists.openmoko.org/pipermail/openmoko-kernel/2009-February/008925.html by Andy].&lt;br /&gt;
* Get touchscreen driver upstream&lt;br /&gt;
** Apply all the Andew Morton's suggestion for the touchsceen filters  ('''Almost done''').&lt;br /&gt;
** Get rid of a sort call Morton did not like. [[User:Werner|Werner]] and I came up with a much better algorithm. Its worst performance only happens when we actually have a hardware problem (too much noise) and if the Hardware does well it is much faster and requires less points. '''Working on this one now'''.&lt;br /&gt;
** Adapt the touchscreen driver to use s3c-adc&lt;br /&gt;
&lt;br /&gt;
== TODO List ==&lt;br /&gt;
&lt;br /&gt;
[https://docs.openmoko.org/trac/ticket/2208 #2208] : consider sending touchscreen release event on resume?&lt;br /&gt;
&lt;br /&gt;
== Patches ==&lt;br /&gt;
&lt;br /&gt;
I keep a backup of the patches I work on in a public [http://nelson-patches.googlecode.com/svn/trunk/openmoko/kernel/ subversion repository]. The main purpose of this repository is backup in case of disaster.&lt;br /&gt;
&lt;br /&gt;
== About ==&lt;br /&gt;
&lt;br /&gt;
[[Image:Nelson-lightsaber.jpg|right]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
I am Nelson Castillo -- a Digital Alchemist.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
* My goal is to turn all the difficult issues I have to deal with into working code (silver).&lt;br /&gt;
* When the code is also beautiful then it is better than gold.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 Caminante, son tus huellas&lt;br /&gt;
 el camino y nada más;&lt;br /&gt;
 caminante, no hay camino,&lt;br /&gt;
 se hace camino al andar.&lt;br /&gt;
 &lt;br /&gt;
 Al andar se hace camino&lt;br /&gt;
 y al volver la vista atrás&lt;br /&gt;
 se ve la senda que nunca&lt;br /&gt;
 se ha de volver a pisar.&lt;br /&gt;
 &lt;br /&gt;
 Caminante no hay camino&lt;br /&gt;
 sino estelas en la mar...&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Whole thing [http://www.poemas-del-alma.com/antonio-machado-caminante-no-hay-camino.htm here].&lt;br /&gt;
&lt;br /&gt;
== Contact ==&lt;br /&gt;
&lt;br /&gt;
If you have a kernel issue you should write to [http://lists.openmoko.org/mailman/listinfo/openmoko-kernel the mailing list].&lt;br /&gt;
&lt;br /&gt;
I'm usually on IRC (Freenode #openmoko-cdevel) using the nick Arhuaco in order to communicate with developers when we need to talk about important issues. I'm way too busy, old and ugly for casual chat such as a/s/l.&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/User:Arhuaco</id>
		<title>User:Arhuaco</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/User:Arhuaco"/>
				<updated>2009-03-05T01:56:18Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: Fix.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Only edit to correct a spelling or grammar mistakes'''.&lt;br /&gt;
&lt;br /&gt;
== Current Priority ==&lt;br /&gt;
&lt;br /&gt;
Help include support for the GTA02/[[Freerunner]] into the upstream Linux Kernel.&lt;br /&gt;
&lt;br /&gt;
== Currently working on ==&lt;br /&gt;
&lt;br /&gt;
* Send GTA02 basic support upstream (so that we can start sending drivers)&lt;br /&gt;
** I started from this work done [http://lists.openmoko.org/pipermail/openmoko-kernel/2009-February/008925.html by Andy].&lt;br /&gt;
* Get touchscreen driver upstream&lt;br /&gt;
** Apply all the Andew Morton's suggestion for the touchsceen filters&lt;br /&gt;
** Get rid of a sort call Morton did not like. [[User:Werner|Werner]] and I came up with a much better algorithm. Its worst performance only happens when we actually have a hardware problem (too much noise) and if the Hardware does well it is much faster and requires less points.&lt;br /&gt;
&lt;br /&gt;
== TODO List ==&lt;br /&gt;
&lt;br /&gt;
[https://docs.openmoko.org/trac/ticket/2208 #2208] : consider sending touchscreen release event on resume?&lt;br /&gt;
&lt;br /&gt;
== Patches ==&lt;br /&gt;
&lt;br /&gt;
I keep a backup of the patches I work on in a public [http://nelson-patches.googlecode.com/svn/trunk/openmoko/kernel/ subversion repository]. The main purpose of this repository is backup in case of disaster.&lt;br /&gt;
&lt;br /&gt;
== About ==&lt;br /&gt;
&lt;br /&gt;
[[Image:Nelson-lightsaber.jpg|right]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
I am Nelson Castillo -- a Digital Alchemist.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
* My goal is to turn all the difficult issues I have to deal with into working code (silver).&lt;br /&gt;
* When the code is also beautiful then it is better than gold.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 Caminante, son tus huellas&lt;br /&gt;
 el camino y nada más;&lt;br /&gt;
 caminante, no hay camino,&lt;br /&gt;
 se hace camino al andar.&lt;br /&gt;
 &lt;br /&gt;
 Al andar se hace camino&lt;br /&gt;
 y al volver la vista atrás&lt;br /&gt;
 se ve la senda que nunca&lt;br /&gt;
 se ha de volver a pisar.&lt;br /&gt;
 &lt;br /&gt;
 Caminante no hay camino&lt;br /&gt;
 sino estelas en la mar...&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Whole thing [http://www.poemas-del-alma.com/antonio-machado-caminante-no-hay-camino.htm here].&lt;br /&gt;
&lt;br /&gt;
== Contact ==&lt;br /&gt;
&lt;br /&gt;
If you have a kernel issue you should write to [http://lists.openmoko.org/mailman/listinfo/openmoko-kernel the mailing list].&lt;br /&gt;
&lt;br /&gt;
I'm usually on IRC (Freenode #openmoko-cdevel) using the nick Arhuaco in order to communicate with developers when we need to talk about important issues. I'm way too busy, old and ugly for casual chat such as a/s/l.&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel</id>
		<title>Kernel</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel"/>
				<updated>2009-03-04T12:37:26Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: /* Building the andy-tracking branch */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Kernel}}&lt;br /&gt;
== Is this page meant for you? ==&lt;br /&gt;
&lt;br /&gt;
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 for you. You might want to scroll down for the for the blessed kernels in the daily builds.&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Sister pages ===&lt;br /&gt;
&lt;br /&gt;
# [[Kernel_branches]].&lt;br /&gt;
&lt;br /&gt;
== Sources ==&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
&lt;br /&gt;
http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
&lt;br /&gt;
[http://git-scm.com 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
If you are very new to GIT you might want to read [http://git.or.cz/course/ the good manuals that already available].&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
=== Branches ===&lt;br /&gt;
&lt;br /&gt;
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 (http://git.openmoko.org/?p=kernel.git;a=summary).&lt;br /&gt;
&lt;br /&gt;
The ''andy-tracking'' branch is the one where most of the action takes place these days. &lt;br /&gt;
&lt;br /&gt;
We have [[Kernel_branches|branch policies]] that explain what each branch is for.&lt;br /&gt;
&lt;br /&gt;
=== Daily builds ===&lt;br /&gt;
&lt;br /&gt;
==== Automatic revisions ====&lt;br /&gt;
&lt;br /&gt;
Think of a robot that takes whatever kernels are the most recent in GIT, builds them for you and then makes them available here:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/experimental/&lt;br /&gt;
&lt;br /&gt;
==== Blessed revisions ====&lt;br /&gt;
&lt;br /&gt;
Another robot but this one only builds the versions picked by our friendly [[OpenEmbedded]] developers. Download from:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/unstable/&lt;br /&gt;
&lt;br /&gt;
If you understand OpenEmbedded you will get this: Those versions are tied to a specific GIT revision through conf/distro/include/sane-srcrevs.bb.&lt;br /&gt;
&lt;br /&gt;
=== Building the andy-tracking branch ===&lt;br /&gt;
&lt;br /&gt;
Those are the minimum survival commands:&lt;br /&gt;
&lt;br /&gt;
 $ git clone git://git.openmoko.org/git/kernel.git linux-2.6&lt;br /&gt;
 $ cd linux-2.6&lt;br /&gt;
 $ git-checkout --track -b andy-tracking origin/andy-tracking&lt;br /&gt;
 $ mkdir GTA02 &lt;br /&gt;
 $ cp ./arch/arm/configs/gta02_moredrivers_defconfig GTA02/.config&lt;br /&gt;
&lt;br /&gt;
Before building this kernel you need install a [http://wiki.openmoko.org/wiki/Toolchain#Downloading_and_installing Toolchain].&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
In order to build the modules you can:&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02 dummy&lt;br /&gt;
&lt;br /&gt;
This will create a file called modules-GTA02_andy-tracking-&amp;lt;git hash&amp;gt;.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.&lt;br /&gt;
&lt;br /&gt;
If you want to update the local copy of the repository so that you get the latest changes, you can type:&lt;br /&gt;
&lt;br /&gt;
 $ git-pull&lt;br /&gt;
&lt;br /&gt;
Before reporting that the new kernel does not build please first check for changes in the configuration file provided by Openmoko.&lt;br /&gt;
&lt;br /&gt;
=== kernel building tips ===&lt;br /&gt;
&lt;br /&gt;
If you are modifying Linux kernel code and building it quite often you really want to be using [http://ccache.samba.org ccache]. It will save you a lot of time.&lt;br /&gt;
&lt;br /&gt;
TODO: submit a patch for the build script that makes ccache use easier. '''Note''': There is a [http://lists.openmoko.org/pipermail/openmoko-kernel/2009-March/009139.html patch being reviewed].&lt;br /&gt;
&lt;br /&gt;
== Contributing ==&lt;br /&gt;
&lt;br /&gt;
The development resources [[Openmoko]] offers are:&lt;br /&gt;
&lt;br /&gt;
* Git repository: http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
* [http://lists.openmoko.org/mailman/listinfo/openmoko-kernel Mailing list] ([http://lists.openmoko.org/pipermail/openmoko-kernel/ Online Archive])&lt;br /&gt;
&lt;br /&gt;
We appreciate your contributions. Check the Open Issues at the end of this page to check where we need more help.&lt;br /&gt;
&lt;br /&gt;
If in doubt ask in the mailing list.&lt;br /&gt;
&lt;br /&gt;
== FAQ ==&lt;br /&gt;
&lt;br /&gt;
=== Why does Openmoko cares about sending code upstream instead of (insert your task here)? ===&lt;br /&gt;
&lt;br /&gt;
There are two very different approaches and both of them would be doomed if we stuck all our resources to only one of to them.&lt;br /&gt;
&lt;br /&gt;
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 [http://www.kernel.org upstream] where the people who want to help us improve, maintain and support the code running in our devices hang out.&lt;br /&gt;
&lt;br /&gt;
The second is to care way '''too much''' about upstream to the point that we are not willing to ship a temporal dirty hack that make users happy and able to better use their phones. We cannot afford that kind of purity.&lt;br /&gt;
&lt;br /&gt;
As many things in engineering we have to find a point in the middle that works well -- we will try hard to do it.&lt;br /&gt;
&lt;br /&gt;
=== Who's Andy and why is he sticking his name in the kernel? ===&lt;br /&gt;
&lt;br /&gt;
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. He makes sure that the kernel still builds when Linus and his friends feel like it is time to update the upstream kernel and believe us: it is not as fun as it might sound and it happens often.&lt;br /&gt;
&lt;br /&gt;
Check [[Kernel_branches]] if you care about the details.&lt;br /&gt;
&lt;br /&gt;
=== Kernel developers are not polite! They do not even care to say &amp;quot;Hello&amp;quot; when they reply to my emails! ===&lt;br /&gt;
&lt;br /&gt;
The long version is here: [[Kernel-developers-are-not-polite]].&lt;br /&gt;
&lt;br /&gt;
To the point:&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
They just tend to write very short text because they have to read and write a lot every day.&lt;br /&gt;
&lt;br /&gt;
== Known issues ==&lt;br /&gt;
&lt;br /&gt;
=== Sysfs paths ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[FSO]] developers realized that this problem could be prevented from from happening in the future and they decided to code a nice daemon called [http://www.freesmartphone.org/index.php/Implementations/OpenDeviceDaemon odeviced].&lt;br /&gt;
&lt;br /&gt;
== Open Tickets ==&lt;br /&gt;
&lt;br /&gt;
'''Please read [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component this report]''' if you wish to know what the current issues are.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Easy bugs ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
TODO: list of bugs linking to trac.&lt;br /&gt;
&lt;br /&gt;
=== Normal bugs ===&lt;br /&gt;
&lt;br /&gt;
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. Please do not add a list of bugs here.&lt;br /&gt;
&lt;br /&gt;
'''Read this [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component report]''' to find out more about them.&lt;br /&gt;
&lt;br /&gt;
=== Hard bugs ===&lt;br /&gt;
&lt;br /&gt;
Those are the evil bugs that we haven't fixed either because:&lt;br /&gt;
&lt;br /&gt;
# We do not know how to do it in reasonable time&lt;br /&gt;
# 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)&lt;br /&gt;
# More testing is needed (perhaps a hard-to-reproduce bug)&lt;br /&gt;
&lt;br /&gt;
Here is the list:&lt;br /&gt;
&lt;br /&gt;
* [https://docs.openmoko.org/trac/ticket/2235 #2235 : Monochrome display on resume]&lt;br /&gt;
&lt;br /&gt;
{{Languages|Kernel}}&lt;br /&gt;
&lt;br /&gt;
[[Category:Kernel]]&lt;br /&gt;
[[Category:System Developers]]&lt;br /&gt;
[[Category:Application Developer]]&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel</id>
		<title>Kernel</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel"/>
				<updated>2009-03-01T18:58:31Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: Ccache patch under review.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Kernel}}&lt;br /&gt;
== Is this page meant for you? ==&lt;br /&gt;
&lt;br /&gt;
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 for you. You might want to scroll down for the for the blessed kernels in the daily builds.&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Sister pages ===&lt;br /&gt;
&lt;br /&gt;
# [[Kernel_branches]].&lt;br /&gt;
&lt;br /&gt;
== Sources ==&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
&lt;br /&gt;
http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
&lt;br /&gt;
[http://git-scm.com 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
If you are very new to GIT you might want to read [http://git.or.cz/course/ the good manuals that already available].&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
=== Branches ===&lt;br /&gt;
&lt;br /&gt;
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 (http://git.openmoko.org/?p=kernel.git;a=summary).&lt;br /&gt;
&lt;br /&gt;
The ''andy-tracking'' branch is the one where most of the action takes place these days. &lt;br /&gt;
&lt;br /&gt;
We have [[Kernel_branches|branch policies]] that explain what each branch is for.&lt;br /&gt;
&lt;br /&gt;
=== Daily builds ===&lt;br /&gt;
&lt;br /&gt;
==== Automatic revisions ====&lt;br /&gt;
&lt;br /&gt;
Think of a robot that takes whatever kernels are the most recent in GIT, builds them for you and then makes them available here:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/experimental/&lt;br /&gt;
&lt;br /&gt;
==== Blessed revisions ====&lt;br /&gt;
&lt;br /&gt;
Another robot but this one only builds the versions picked by our friendly [[OpenEmbedded]] developers. Download from:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/unstable/&lt;br /&gt;
&lt;br /&gt;
If you understand OpenEmbedded you will get this: Those versions are tied to a specific GIT revision through conf/distro/include/sane-srcrevs.bb.&lt;br /&gt;
&lt;br /&gt;
=== Building the andy-tracking branch ===&lt;br /&gt;
&lt;br /&gt;
Those are the minimum survival commands:&lt;br /&gt;
&lt;br /&gt;
 $ git clone git://git.openmoko.org/git/kernel.git linux-2.6&lt;br /&gt;
 $ cd linux-2.6&lt;br /&gt;
 $ git-checkout --track -b andy-tracking origin/andy-tracking&lt;br /&gt;
 $ mkdir GTA02 &lt;br /&gt;
 $ cp ./arch/arm/configs/gta02_moredrivers_defconfig GTA02/.config&lt;br /&gt;
&lt;br /&gt;
Before building this kernel you need install a [http://wiki.openmoko.org/wiki/Toolchain#Downloading_and_installing Toolchain].&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
In order to build the modules you can:&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02 dummy&lt;br /&gt;
&lt;br /&gt;
This will create a file called modules-GTA02_andy-tracking-&amp;lt;git hash&amp;gt;.tar.gz. You need to untar this on the root directory of the FR.&lt;br /&gt;
&lt;br /&gt;
If you want to update the local copy of the repository so that you get the latest changes, you can type:&lt;br /&gt;
&lt;br /&gt;
 $ git-pull&lt;br /&gt;
&lt;br /&gt;
Before reporting that the new kernel does not build please first check for changes in the configuration file provided by Openmoko.&lt;br /&gt;
&lt;br /&gt;
=== kernel building tips ===&lt;br /&gt;
&lt;br /&gt;
If you are modifying Linux kernel code and building it quite often you really want to be using [http://ccache.samba.org ccache]. It will save you a lot of time.&lt;br /&gt;
&lt;br /&gt;
TODO: submit a patch for the build script that makes ccache use easier. '''Note''': There is a [http://lists.openmoko.org/pipermail/openmoko-kernel/2009-March/009139.html patch being reviewed].&lt;br /&gt;
&lt;br /&gt;
== Contributing ==&lt;br /&gt;
&lt;br /&gt;
The development resources [[Openmoko]] offers are:&lt;br /&gt;
&lt;br /&gt;
* Git repository: http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
* [http://lists.openmoko.org/mailman/listinfo/openmoko-kernel Mailing list] ([http://lists.openmoko.org/pipermail/openmoko-kernel/ Online Archive])&lt;br /&gt;
&lt;br /&gt;
We appreciate your contributions. Check the Open Issues at the end of this page to check where we need more help.&lt;br /&gt;
&lt;br /&gt;
If in doubt ask in the mailing list.&lt;br /&gt;
&lt;br /&gt;
== FAQ ==&lt;br /&gt;
&lt;br /&gt;
=== Why does Openmoko cares about sending code upstream instead of (insert your task here)? ===&lt;br /&gt;
&lt;br /&gt;
There are two very different approaches and both of them would be doomed if we stuck all our resources to only one of to them.&lt;br /&gt;
&lt;br /&gt;
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 [http://www.kernel.org upstream] where the people who want to help us improve, maintain and support the code running in our devices hang out.&lt;br /&gt;
&lt;br /&gt;
The second is to care way '''too much''' about upstream to the point that we are not willing to ship a temporal dirty hack that make users happy and able to better use their phones. We cannot afford that kind of purity.&lt;br /&gt;
&lt;br /&gt;
As many things in engineering we have to find a point in the middle that works well -- we will try hard to do it.&lt;br /&gt;
&lt;br /&gt;
=== Who's Andy and why is he sticking his name in the kernel? ===&lt;br /&gt;
&lt;br /&gt;
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. He makes sure that the kernel still builds when Linus and his friends feel like it is time to update the upstream kernel and believe us: it is not as fun as it might sound and it happens often.&lt;br /&gt;
&lt;br /&gt;
Check [[Kernel_branches]] if you care about the details.&lt;br /&gt;
&lt;br /&gt;
=== Kernel developers are not polite! They do not even care to say &amp;quot;Hello&amp;quot; when they reply to my emails! ===&lt;br /&gt;
&lt;br /&gt;
The long version is here: [[Kernel-developers-are-not-polite]].&lt;br /&gt;
&lt;br /&gt;
To the point:&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
They just tend to write very short text because they have to read and write a lot every day.&lt;br /&gt;
&lt;br /&gt;
== Known issues ==&lt;br /&gt;
&lt;br /&gt;
=== Sysfs paths ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[FSO]] developers realized that this problem could be prevented from from happening in the future and they decided to code a nice daemon called [http://www.freesmartphone.org/index.php/Implementations/OpenDeviceDaemon odeviced].&lt;br /&gt;
&lt;br /&gt;
== Open Tickets ==&lt;br /&gt;
&lt;br /&gt;
'''Please read [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component this report]''' if you wish to know what the current issues are.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Easy bugs ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
TODO: list of bugs linking to trac.&lt;br /&gt;
&lt;br /&gt;
=== Normal bugs ===&lt;br /&gt;
&lt;br /&gt;
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. Please do not add a list of bugs here.&lt;br /&gt;
&lt;br /&gt;
'''Read this [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component report]''' to find out more about them.&lt;br /&gt;
&lt;br /&gt;
=== Hard bugs ===&lt;br /&gt;
&lt;br /&gt;
Those are the evil bugs that we haven't fixed either because:&lt;br /&gt;
&lt;br /&gt;
# We do not know how to do it in reasonable time&lt;br /&gt;
# 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)&lt;br /&gt;
# More testing is needed (perhaps a hard-to-reproduce bug)&lt;br /&gt;
&lt;br /&gt;
Here is the list:&lt;br /&gt;
&lt;br /&gt;
* [https://docs.openmoko.org/trac/ticket/2235 #2235 : Monochrome display on resume]&lt;br /&gt;
&lt;br /&gt;
{{Languages|Kernel}}&lt;br /&gt;
&lt;br /&gt;
[[Category:Kernel]]&lt;br /&gt;
[[Category:System Developers]]&lt;br /&gt;
[[Category:Application Developer]]&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel</id>
		<title>Kernel</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel"/>
				<updated>2009-03-01T17:02:36Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: /* Easy bugs */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Kernel}}&lt;br /&gt;
== Is this page meant for you? ==&lt;br /&gt;
&lt;br /&gt;
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 for you. You might want to scroll down for the for the blessed kernels in the daily builds.&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Sister pages ===&lt;br /&gt;
&lt;br /&gt;
# [[Kernel_branches]].&lt;br /&gt;
&lt;br /&gt;
== Sources ==&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
&lt;br /&gt;
http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
&lt;br /&gt;
[http://git-scm.com 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
If you are very new to GIT you might want to read [http://git.or.cz/course/ the good manuals that already available].&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
=== Branches ===&lt;br /&gt;
&lt;br /&gt;
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 (http://git.openmoko.org/?p=kernel.git;a=summary).&lt;br /&gt;
&lt;br /&gt;
The ''andy-tracking'' branch is the one where most of the action takes place these days. &lt;br /&gt;
&lt;br /&gt;
We have [[Kernel_branches|branch policies]] that explain what each branch is for.&lt;br /&gt;
&lt;br /&gt;
=== Daily builds ===&lt;br /&gt;
&lt;br /&gt;
==== Automatic revisions ====&lt;br /&gt;
&lt;br /&gt;
Think of a robot that takes whatever kernels are the most recent in GIT, builds them for you and then makes them available here:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/experimental/&lt;br /&gt;
&lt;br /&gt;
==== Blessed revisions ====&lt;br /&gt;
&lt;br /&gt;
Another robot but this one only builds the versions picked by our friendly [[OpenEmbedded]] developers. Download from:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/unstable/&lt;br /&gt;
&lt;br /&gt;
If you understand OpenEmbedded you will get this: Those versions are tied to a specific GIT revision through conf/distro/include/sane-srcrevs.bb.&lt;br /&gt;
&lt;br /&gt;
=== Building the andy-tracking branch ===&lt;br /&gt;
&lt;br /&gt;
Those are the minimum survival commands:&lt;br /&gt;
&lt;br /&gt;
 $ git clone git://git.openmoko.org/git/kernel.git linux-2.6&lt;br /&gt;
 $ cd linux-2.6&lt;br /&gt;
 $ git-checkout --track -b andy-tracking origin/andy-tracking&lt;br /&gt;
 $ mkdir GTA02 &lt;br /&gt;
 $ cp ./arch/arm/configs/gta02_moredrivers_defconfig GTA02/.config&lt;br /&gt;
&lt;br /&gt;
Before building this kernel you need install a [http://wiki.openmoko.org/wiki/Toolchain#Downloading_and_installing Toolchain].&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
In order to build the modules you can:&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02 dummy&lt;br /&gt;
&lt;br /&gt;
This will create a file called modules-GTA02_andy-tracking-&amp;lt;git hash&amp;gt;.tar.gz. You need to untar this on the root directory of the FR.&lt;br /&gt;
&lt;br /&gt;
If you want to update the local copy of the repository so that you get the latest changes, you can type:&lt;br /&gt;
&lt;br /&gt;
 $ git-pull&lt;br /&gt;
&lt;br /&gt;
Before reporting that the new kernel does not build please first check for changes in the configuration file provided by Openmoko.&lt;br /&gt;
&lt;br /&gt;
=== kernel building tips ===&lt;br /&gt;
&lt;br /&gt;
If you are modifying Linux kernel code and building it quite often you really want to be using [http://ccache.samba.org ccache]. It will save you a lot of time.&lt;br /&gt;
&lt;br /&gt;
TODO: submit a patch for the build script that makes ccache use easier.&lt;br /&gt;
&lt;br /&gt;
== Contributing ==&lt;br /&gt;
&lt;br /&gt;
The development resources [[Openmoko]] offers are:&lt;br /&gt;
&lt;br /&gt;
* Git repository: http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
* [http://lists.openmoko.org/mailman/listinfo/openmoko-kernel Mailing list] ([http://lists.openmoko.org/pipermail/openmoko-kernel/ Online Archive])&lt;br /&gt;
&lt;br /&gt;
We appreciate your contributions. Check the Open Issues at the end of this page to check where we need more help.&lt;br /&gt;
&lt;br /&gt;
If in doubt ask in the mailing list.&lt;br /&gt;
&lt;br /&gt;
== FAQ ==&lt;br /&gt;
&lt;br /&gt;
=== Why does Openmoko cares about sending code upstream instead of (insert your task here)? ===&lt;br /&gt;
&lt;br /&gt;
There are two very different approaches and both of them would be doomed if we stuck all our resources to only one of to them.&lt;br /&gt;
&lt;br /&gt;
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 [http://www.kernel.org upstream] where the people who want to help us improve, maintain and support the code running in our devices hang out.&lt;br /&gt;
&lt;br /&gt;
The second is to care way '''too much''' about upstream to the point that we are not willing to ship a temporal dirty hack that make users happy and able to better use their phones. We cannot afford that kind of purity.&lt;br /&gt;
&lt;br /&gt;
As many things in engineering we have to find a point in the middle that works well -- we will try hard to do it.&lt;br /&gt;
&lt;br /&gt;
=== Who's Andy and why is he sticking his name in the kernel? ===&lt;br /&gt;
&lt;br /&gt;
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. He makes sure that the kernel still builds when Linus and his friends feel like it is time to update the upstream kernel and believe us: it is not as fun as it might sound and it happens often.&lt;br /&gt;
&lt;br /&gt;
Check [[Kernel_branches]] if you care about the details.&lt;br /&gt;
&lt;br /&gt;
=== Kernel developers are not polite! They do not even care to say &amp;quot;Hello&amp;quot; when they reply to my emails! ===&lt;br /&gt;
&lt;br /&gt;
The long version is here: [[Kernel-developers-are-not-polite]].&lt;br /&gt;
&lt;br /&gt;
To the point:&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
They just tend to write very short text because they have to read and write a lot every day.&lt;br /&gt;
&lt;br /&gt;
== Known issues ==&lt;br /&gt;
&lt;br /&gt;
=== Sysfs paths ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[FSO]] developers realized that this problem could be prevented from from happening in the future and they decided to code a nice daemon called [http://www.freesmartphone.org/index.php/Implementations/OpenDeviceDaemon odeviced].&lt;br /&gt;
&lt;br /&gt;
== Open Tickets ==&lt;br /&gt;
&lt;br /&gt;
'''Please read [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component this report]''' if you wish to know what the current issues are.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Easy bugs ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
TODO: list of bugs linking to trac.&lt;br /&gt;
&lt;br /&gt;
=== Normal bugs ===&lt;br /&gt;
&lt;br /&gt;
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 Esasy Bugs or Evil bugs. We will use trac for them. Please do not add a list of bugs here.&lt;br /&gt;
&lt;br /&gt;
'''Read this [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component report]''' to find out more about them.&lt;br /&gt;
&lt;br /&gt;
=== Hard bugs ===&lt;br /&gt;
&lt;br /&gt;
Those are the evil bugs that we haven't fixed either because:&lt;br /&gt;
&lt;br /&gt;
# We do not know how to do it in reasonable time&lt;br /&gt;
# 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)&lt;br /&gt;
# More testing is needed (perhaps a hard-to-reproduce bug)&lt;br /&gt;
&lt;br /&gt;
Here is the list:&lt;br /&gt;
&lt;br /&gt;
* [https://docs.openmoko.org/trac/ticket/2235 #2235 : Monochrome display on resume]&lt;br /&gt;
&lt;br /&gt;
{{Languages|Kernel}}&lt;br /&gt;
&lt;br /&gt;
[[Category:Kernel]]&lt;br /&gt;
[[Category:System Developers]]&lt;br /&gt;
[[Category:Application Developer]]&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel</id>
		<title>Kernel</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel"/>
				<updated>2009-03-01T16:58:00Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: /* Hard bugs */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Kernel}}&lt;br /&gt;
== Is this page meant for you? ==&lt;br /&gt;
&lt;br /&gt;
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 for you. You might want to scroll down for the for the blessed kernels in the daily builds.&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Sister pages ===&lt;br /&gt;
&lt;br /&gt;
# [[Kernel_branches]].&lt;br /&gt;
&lt;br /&gt;
== Sources ==&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
&lt;br /&gt;
http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
&lt;br /&gt;
[http://git-scm.com 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
If you are very new to GIT you might want to read [http://git.or.cz/course/ the good manuals that already available].&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
=== Branches ===&lt;br /&gt;
&lt;br /&gt;
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 (http://git.openmoko.org/?p=kernel.git;a=summary).&lt;br /&gt;
&lt;br /&gt;
The ''andy-tracking'' branch is the one where most of the action takes place these days. &lt;br /&gt;
&lt;br /&gt;
We have [[Kernel_branches|branch policies]] that explain what each branch is for.&lt;br /&gt;
&lt;br /&gt;
=== Daily builds ===&lt;br /&gt;
&lt;br /&gt;
==== Automatic revisions ====&lt;br /&gt;
&lt;br /&gt;
Think of a robot that takes whatever kernels are the most recent in GIT, builds them for you and then makes them available here:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/experimental/&lt;br /&gt;
&lt;br /&gt;
==== Blessed revisions ====&lt;br /&gt;
&lt;br /&gt;
Another robot but this one only builds the versions picked by our friendly [[OpenEmbedded]] developers. Download from:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/unstable/&lt;br /&gt;
&lt;br /&gt;
If you understand OpenEmbedded you will get this: Those versions are tied to a specific GIT revision through conf/distro/include/sane-srcrevs.bb.&lt;br /&gt;
&lt;br /&gt;
=== Building the andy-tracking branch ===&lt;br /&gt;
&lt;br /&gt;
Those are the minimum survival commands:&lt;br /&gt;
&lt;br /&gt;
 $ git clone git://git.openmoko.org/git/kernel.git linux-2.6&lt;br /&gt;
 $ cd linux-2.6&lt;br /&gt;
 $ git-checkout --track -b andy-tracking origin/andy-tracking&lt;br /&gt;
 $ mkdir GTA02 &lt;br /&gt;
 $ cp ./arch/arm/configs/gta02_moredrivers_defconfig GTA02/.config&lt;br /&gt;
&lt;br /&gt;
Before building this kernel you need install a [http://wiki.openmoko.org/wiki/Toolchain#Downloading_and_installing Toolchain].&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
In order to build the modules you can:&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02 dummy&lt;br /&gt;
&lt;br /&gt;
This will create a file called modules-GTA02_andy-tracking-&amp;lt;git hash&amp;gt;.tar.gz. You need to untar this on the root directory of the FR.&lt;br /&gt;
&lt;br /&gt;
If you want to update the local copy of the repository so that you get the latest changes, you can type:&lt;br /&gt;
&lt;br /&gt;
 $ git-pull&lt;br /&gt;
&lt;br /&gt;
Before reporting that the new kernel does not build please first check for changes in the configuration file provided by Openmoko.&lt;br /&gt;
&lt;br /&gt;
=== kernel building tips ===&lt;br /&gt;
&lt;br /&gt;
If you are modifying Linux kernel code and building it quite often you really want to be using [http://ccache.samba.org ccache]. It will save you a lot of time.&lt;br /&gt;
&lt;br /&gt;
TODO: submit a patch for the build script that makes ccache use easier.&lt;br /&gt;
&lt;br /&gt;
== Contributing ==&lt;br /&gt;
&lt;br /&gt;
The development resources [[Openmoko]] offers are:&lt;br /&gt;
&lt;br /&gt;
* Git repository: http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
* [http://lists.openmoko.org/mailman/listinfo/openmoko-kernel Mailing list] ([http://lists.openmoko.org/pipermail/openmoko-kernel/ Online Archive])&lt;br /&gt;
&lt;br /&gt;
We appreciate your contributions. Check the Open Issues at the end of this page to check where we need more help.&lt;br /&gt;
&lt;br /&gt;
If in doubt ask in the mailing list.&lt;br /&gt;
&lt;br /&gt;
== FAQ ==&lt;br /&gt;
&lt;br /&gt;
=== Why does Openmoko cares about sending code upstream instead of (insert your task here)? ===&lt;br /&gt;
&lt;br /&gt;
There are two very different approaches and both of them would be doomed if we stuck all our resources to only one of to them.&lt;br /&gt;
&lt;br /&gt;
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 [http://www.kernel.org upstream] where the people who want to help us improve, maintain and support the code running in our devices hang out.&lt;br /&gt;
&lt;br /&gt;
The second is to care way '''too much''' about upstream to the point that we are not willing to ship a temporal dirty hack that make users happy and able to better use their phones. We cannot afford that kind of purity.&lt;br /&gt;
&lt;br /&gt;
As many things in engineering we have to find a point in the middle that works well -- we will try hard to do it.&lt;br /&gt;
&lt;br /&gt;
=== Who's Andy and why is he sticking his name in the kernel? ===&lt;br /&gt;
&lt;br /&gt;
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. He makes sure that the kernel still builds when Linus and his friends feel like it is time to update the upstream kernel and believe us: it is not as fun as it might sound and it happens often.&lt;br /&gt;
&lt;br /&gt;
Check [[Kernel_branches]] if you care about the details.&lt;br /&gt;
&lt;br /&gt;
=== Kernel developers are not polite! They do not even care to say &amp;quot;Hello&amp;quot; when they reply to my emails! ===&lt;br /&gt;
&lt;br /&gt;
The long version is here: [[Kernel-developers-are-not-polite]].&lt;br /&gt;
&lt;br /&gt;
To the point:&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
They just tend to write very short text because they have to read and write a lot every day.&lt;br /&gt;
&lt;br /&gt;
== Known issues ==&lt;br /&gt;
&lt;br /&gt;
=== Sysfs paths ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[FSO]] developers realized that this problem could be prevented from from happening in the future and they decided to code a nice daemon called [http://www.freesmartphone.org/index.php/Implementations/OpenDeviceDaemon odeviced].&lt;br /&gt;
&lt;br /&gt;
== Open Tickets ==&lt;br /&gt;
&lt;br /&gt;
'''Please read [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component this report]''' if you wish to know what the current issues are.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Easy bugs ===&lt;br /&gt;
&lt;br /&gt;
Those are the bugs that active kernel developers believe can be fixed by 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.&lt;br /&gt;
&lt;br /&gt;
TODO: list of bugs linking to trac.&lt;br /&gt;
&lt;br /&gt;
=== Normal bugs ===&lt;br /&gt;
&lt;br /&gt;
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 Esasy Bugs or Evil bugs. We will use trac for them. Please do not add a list of bugs here.&lt;br /&gt;
&lt;br /&gt;
'''Read this [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component report]''' to find out more about them.&lt;br /&gt;
&lt;br /&gt;
=== Hard bugs ===&lt;br /&gt;
&lt;br /&gt;
Those are the evil bugs that we haven't fixed either because:&lt;br /&gt;
&lt;br /&gt;
# We do not know how to do it in reasonable time&lt;br /&gt;
# 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)&lt;br /&gt;
# More testing is needed (perhaps a hard-to-reproduce bug)&lt;br /&gt;
&lt;br /&gt;
Here is the list:&lt;br /&gt;
&lt;br /&gt;
* [https://docs.openmoko.org/trac/ticket/2235 #2235 : Monochrome display on resume]&lt;br /&gt;
&lt;br /&gt;
{{Languages|Kernel}}&lt;br /&gt;
&lt;br /&gt;
[[Category:Kernel]]&lt;br /&gt;
[[Category:System Developers]]&lt;br /&gt;
[[Category:Application Developer]]&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel</id>
		<title>Kernel</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel"/>
				<updated>2009-03-01T16:57:29Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: /* Hard bugs */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Kernel}}&lt;br /&gt;
== Is this page meant for you? ==&lt;br /&gt;
&lt;br /&gt;
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 for you. You might want to scroll down for the for the blessed kernels in the daily builds.&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Sister pages ===&lt;br /&gt;
&lt;br /&gt;
# [[Kernel_branches]].&lt;br /&gt;
&lt;br /&gt;
== Sources ==&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
&lt;br /&gt;
http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
&lt;br /&gt;
[http://git-scm.com 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
If you are very new to GIT you might want to read [http://git.or.cz/course/ the good manuals that already available].&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
=== Branches ===&lt;br /&gt;
&lt;br /&gt;
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 (http://git.openmoko.org/?p=kernel.git;a=summary).&lt;br /&gt;
&lt;br /&gt;
The ''andy-tracking'' branch is the one where most of the action takes place these days. &lt;br /&gt;
&lt;br /&gt;
We have [[Kernel_branches|branch policies]] that explain what each branch is for.&lt;br /&gt;
&lt;br /&gt;
=== Daily builds ===&lt;br /&gt;
&lt;br /&gt;
==== Automatic revisions ====&lt;br /&gt;
&lt;br /&gt;
Think of a robot that takes whatever kernels are the most recent in GIT, builds them for you and then makes them available here:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/experimental/&lt;br /&gt;
&lt;br /&gt;
==== Blessed revisions ====&lt;br /&gt;
&lt;br /&gt;
Another robot but this one only builds the versions picked by our friendly [[OpenEmbedded]] developers. Download from:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/unstable/&lt;br /&gt;
&lt;br /&gt;
If you understand OpenEmbedded you will get this: Those versions are tied to a specific GIT revision through conf/distro/include/sane-srcrevs.bb.&lt;br /&gt;
&lt;br /&gt;
=== Building the andy-tracking branch ===&lt;br /&gt;
&lt;br /&gt;
Those are the minimum survival commands:&lt;br /&gt;
&lt;br /&gt;
 $ git clone git://git.openmoko.org/git/kernel.git linux-2.6&lt;br /&gt;
 $ cd linux-2.6&lt;br /&gt;
 $ git-checkout --track -b andy-tracking origin/andy-tracking&lt;br /&gt;
 $ mkdir GTA02 &lt;br /&gt;
 $ cp ./arch/arm/configs/gta02_moredrivers_defconfig GTA02/.config&lt;br /&gt;
&lt;br /&gt;
Before building this kernel you need install a [http://wiki.openmoko.org/wiki/Toolchain#Downloading_and_installing Toolchain].&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
In order to build the modules you can:&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02 dummy&lt;br /&gt;
&lt;br /&gt;
This will create a file called modules-GTA02_andy-tracking-&amp;lt;git hash&amp;gt;.tar.gz. You need to untar this on the root directory of the FR.&lt;br /&gt;
&lt;br /&gt;
If you want to update the local copy of the repository so that you get the latest changes, you can type:&lt;br /&gt;
&lt;br /&gt;
 $ git-pull&lt;br /&gt;
&lt;br /&gt;
Before reporting that the new kernel does not build please first check for changes in the configuration file provided by Openmoko.&lt;br /&gt;
&lt;br /&gt;
=== kernel building tips ===&lt;br /&gt;
&lt;br /&gt;
If you are modifying Linux kernel code and building it quite often you really want to be using [http://ccache.samba.org ccache]. It will save you a lot of time.&lt;br /&gt;
&lt;br /&gt;
TODO: submit a patch for the build script that makes ccache use easier.&lt;br /&gt;
&lt;br /&gt;
== Contributing ==&lt;br /&gt;
&lt;br /&gt;
The development resources [[Openmoko]] offers are:&lt;br /&gt;
&lt;br /&gt;
* Git repository: http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
* [http://lists.openmoko.org/mailman/listinfo/openmoko-kernel Mailing list] ([http://lists.openmoko.org/pipermail/openmoko-kernel/ Online Archive])&lt;br /&gt;
&lt;br /&gt;
We appreciate your contributions. Check the Open Issues at the end of this page to check where we need more help.&lt;br /&gt;
&lt;br /&gt;
If in doubt ask in the mailing list.&lt;br /&gt;
&lt;br /&gt;
== FAQ ==&lt;br /&gt;
&lt;br /&gt;
=== Why does Openmoko cares about sending code upstream instead of (insert your task here)? ===&lt;br /&gt;
&lt;br /&gt;
There are two very different approaches and both of them would be doomed if we stuck all our resources to only one of to them.&lt;br /&gt;
&lt;br /&gt;
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 [http://www.kernel.org upstream] where the people who want to help us improve, maintain and support the code running in our devices hang out.&lt;br /&gt;
&lt;br /&gt;
The second is to care way '''too much''' about upstream to the point that we are not willing to ship a temporal dirty hack that make users happy and able to better use their phones. We cannot afford that kind of purity.&lt;br /&gt;
&lt;br /&gt;
As many things in engineering we have to find a point in the middle that works well -- we will try hard to do it.&lt;br /&gt;
&lt;br /&gt;
=== Who's Andy and why is he sticking his name in the kernel? ===&lt;br /&gt;
&lt;br /&gt;
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. He makes sure that the kernel still builds when Linus and his friends feel like it is time to update the upstream kernel and believe us: it is not as fun as it might sound and it happens often.&lt;br /&gt;
&lt;br /&gt;
Check [[Kernel_branches]] if you care about the details.&lt;br /&gt;
&lt;br /&gt;
=== Kernel developers are not polite! They do not even care to say &amp;quot;Hello&amp;quot; when they reply to my emails! ===&lt;br /&gt;
&lt;br /&gt;
The long version is here: [[Kernel-developers-are-not-polite]].&lt;br /&gt;
&lt;br /&gt;
To the point:&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
They just tend to write very short text because they have to read and write a lot every day.&lt;br /&gt;
&lt;br /&gt;
== Known issues ==&lt;br /&gt;
&lt;br /&gt;
=== Sysfs paths ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[FSO]] developers realized that this problem could be prevented from from happening in the future and they decided to code a nice daemon called [http://www.freesmartphone.org/index.php/Implementations/OpenDeviceDaemon odeviced].&lt;br /&gt;
&lt;br /&gt;
== Open Tickets ==&lt;br /&gt;
&lt;br /&gt;
'''Please read [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component this report]''' if you wish to know what the current issues are.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Easy bugs ===&lt;br /&gt;
&lt;br /&gt;
Those are the bugs that active kernel developers believe can be fixed by 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.&lt;br /&gt;
&lt;br /&gt;
TODO: list of bugs linking to trac.&lt;br /&gt;
&lt;br /&gt;
=== Normal bugs ===&lt;br /&gt;
&lt;br /&gt;
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 Esasy Bugs or Evil bugs. We will use trac for them. Please do not add a list of bugs here.&lt;br /&gt;
&lt;br /&gt;
'''Read this [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component report]''' to find out more about them.&lt;br /&gt;
&lt;br /&gt;
=== Hard bugs ===&lt;br /&gt;
&lt;br /&gt;
Those are the evil bugs that we haven't fixed either because:&lt;br /&gt;
&lt;br /&gt;
# We do not know how to do it in reasonable time&lt;br /&gt;
# The hardware vendor does not want to release documentation (some of them do that unfortunately / even breaking promises they made to Openmoko about making things easier for developers)&lt;br /&gt;
# More testing is needed (perhaps a hard-to-reproduce bug)&lt;br /&gt;
&lt;br /&gt;
Here is the list:&lt;br /&gt;
&lt;br /&gt;
* [https://docs.openmoko.org/trac/ticket/2235 #2235 : Monochrome display on resume]&lt;br /&gt;
&lt;br /&gt;
{{Languages|Kernel}}&lt;br /&gt;
&lt;br /&gt;
[[Category:Kernel]]&lt;br /&gt;
[[Category:System Developers]]&lt;br /&gt;
[[Category:Application Developer]]&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/User:Arhuaco</id>
		<title>User:Arhuaco</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/User:Arhuaco"/>
				<updated>2009-03-01T14:54:06Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: Fix.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Only edit to correct a spelling or grammar mistakes'''.&lt;br /&gt;
&lt;br /&gt;
== Current Priority ==&lt;br /&gt;
&lt;br /&gt;
Help include support for the GTA02/[[Freerunner]] into the upstream Linux Kernel.&lt;br /&gt;
&lt;br /&gt;
== Currently working on ==&lt;br /&gt;
&lt;br /&gt;
* Send GTA02 basic support upstream (so that we can start sending drivers)&lt;br /&gt;
** I started from this work done [http://lists.openmoko.org/pipermail/openmoko-kernel/2009-February/008925.html by Andy].&lt;br /&gt;
* Get touchscreen driver upstream&lt;br /&gt;
** Apply all the Andew Morton's suggestion for the touchsceen filters&lt;br /&gt;
** Get rid of a sort call Morton did not like. [[User:Werner|Werner]] and I came up with a much better algorithm. Its worst performance only happens when we actually have a hardware problem (too much noise) and if the Hardware does well it is much faster and requires less points.&lt;br /&gt;
&lt;br /&gt;
== TODO List ==&lt;br /&gt;
&lt;br /&gt;
[https://docs.openmoko.org/trac/ticket/2208 #2208] : consider sending touchscreen release event on resume?&lt;br /&gt;
&lt;br /&gt;
== About ==&lt;br /&gt;
&lt;br /&gt;
[[Image:Nelson-lightsaber.jpg|right]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
I am Nelson Castillo -- a Digital Alchemist.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
* My goal is to turn all the difficult issues I have to deal with into working code (silver).&lt;br /&gt;
* When the code is also beautiful then it is better than gold.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 Caminante, son tus huellas&lt;br /&gt;
 el camino y nada más;&lt;br /&gt;
 caminante, no hay camino,&lt;br /&gt;
 se hace camino al andar.&lt;br /&gt;
 &lt;br /&gt;
 Al andar se hace camino&lt;br /&gt;
 y al volver la vista atrás&lt;br /&gt;
 se ve la senda que nunca&lt;br /&gt;
 se ha de volver a pisar.&lt;br /&gt;
 &lt;br /&gt;
 Caminante no hay camino&lt;br /&gt;
 sino estelas en la mar...&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Whole thing [http://www.poemas-del-alma.com/antonio-machado-caminante-no-hay-camino.htm here].&lt;br /&gt;
&lt;br /&gt;
== Contact ==&lt;br /&gt;
&lt;br /&gt;
If you have a kernel issue you should write to [http://lists.openmoko.org/mailman/listinfo/openmoko-kernel the mailing list].&lt;br /&gt;
&lt;br /&gt;
I'm usually on IRC (Freenode #openmoko-cdevel) using the nick Arhuaco in order to communicate with developers when we need to talk about important issues. I'm way too busy, old and ugly for casual chat such as a/s/l.&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/User:Arhuaco</id>
		<title>User:Arhuaco</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/User:Arhuaco"/>
				<updated>2009-02-27T12:49:18Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: This will not be useful to me now. Let's remove it.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Only edit to correct a spelling or grammar mistakes'''.&lt;br /&gt;
&lt;br /&gt;
== Current Priority ==&lt;br /&gt;
&lt;br /&gt;
Help include support for the GTA02/[[Freerunner]] into the upstream Linux Kernel.&lt;br /&gt;
&lt;br /&gt;
== Currently working on ==&lt;br /&gt;
&lt;br /&gt;
* Send GTA02 basic support upstream (so that we can start sending drivers)&lt;br /&gt;
** I started from this work done [http://lists.openmoko.org/pipermail/openmoko-kernel/2009-February/008925.html by Andy].&lt;br /&gt;
* Get touchscreen driver upstream&lt;br /&gt;
** Apply all the Andew Morton's suggestion for the touchsceen filters&lt;br /&gt;
** Get rid of a sort call Morton did not like. [[User:Werner|Werner]] and I came up with a much better algorithm. Its worst performance only happens when we actually have a hardware problem (too much noise) and if the Hardware does well it is much faster and requires less points.&lt;br /&gt;
&lt;br /&gt;
== TODO List ==&lt;br /&gt;
&lt;br /&gt;
[https://docs.openmoko.org/trac/ticket/2208 #2208] : consider sending touchscreen release event on resume?&lt;br /&gt;
&lt;br /&gt;
== Contact ==&lt;br /&gt;
&lt;br /&gt;
If you have a kernel issue you should write to [http://lists.openmoko.org/mailman/listinfo/openmoko-kernel the mailing list].&lt;br /&gt;
&lt;br /&gt;
I'm usually on IRC (Freenode #openmoko-cdevel) using the nick Arhuaco in order to communicate with developers when we need to talk about important issues. I'm way too busy, old and ugly for casual chat such as a/s/l.&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/Kernel</id>
		<title>Kernel</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/Kernel"/>
				<updated>2009-02-27T11:36:09Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: Removed list of peope. Don't ask me why.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Kernel}}&lt;br /&gt;
== Is this page meant for you? ==&lt;br /&gt;
&lt;br /&gt;
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 for you. You might want to scroll down for the for the blessed kernels in the daily builds.&lt;br /&gt;
&lt;br /&gt;
== Introduction ==&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Sister pages ===&lt;br /&gt;
&lt;br /&gt;
# [[Kernel_branches]].&lt;br /&gt;
&lt;br /&gt;
== Sources ==&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
&lt;br /&gt;
http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
&lt;br /&gt;
[http://git-scm.com 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
If you are very new to GIT you might want to read [http://git.or.cz/course/ the good manuals that already available].&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
=== Branches ===&lt;br /&gt;
&lt;br /&gt;
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 (http://git.openmoko.org/?p=kernel.git;a=summary).&lt;br /&gt;
&lt;br /&gt;
The ''andy-tracking'' branch is the one where most of the action takes place these days. &lt;br /&gt;
&lt;br /&gt;
We have [[Kernel_branches|branch policies]] that explain what each branch is for.&lt;br /&gt;
&lt;br /&gt;
=== Daily builds ===&lt;br /&gt;
&lt;br /&gt;
==== Automatic revisions ====&lt;br /&gt;
&lt;br /&gt;
Think of a robot that takes whatever kernels are the most recent in GIT, builds them for you and then makes them available here:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/experimental/&lt;br /&gt;
&lt;br /&gt;
==== Blessed revisions ====&lt;br /&gt;
&lt;br /&gt;
Another robot but this one only builds the versions picked by our friendly [[OpenEmbedded]] developers. Download from:&lt;br /&gt;
&lt;br /&gt;
 http://downloads.openmoko.org/distro/unstable/&lt;br /&gt;
&lt;br /&gt;
If you understand OpenEmbedded you will get this: Those versions are tied to a specific GIT revision through conf/distro/include/sane-srcrevs.bb.&lt;br /&gt;
&lt;br /&gt;
=== Building the andy-tracking branch ===&lt;br /&gt;
&lt;br /&gt;
Those are the minimum survival commands:&lt;br /&gt;
&lt;br /&gt;
 $ git clone git://git.openmoko.org/git/kernel.git linux-2.6&lt;br /&gt;
 $ cd linux-2.6&lt;br /&gt;
 $ git-checkout --track -b andy-tracking origin/andy-tracking&lt;br /&gt;
 $ mkdir GTA02 &lt;br /&gt;
 $ cp ./arch/arm/configs/gta02_moredrivers_defconfig GTA02/.config&lt;br /&gt;
&lt;br /&gt;
Before building this kernel you need install a [http://wiki.openmoko.org/wiki/Toolchain#Downloading_and_installing Toolchain].&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
In order to build the modules you can:&lt;br /&gt;
&lt;br /&gt;
 $ ./build GTA02 dummy&lt;br /&gt;
&lt;br /&gt;
This will create a file called modules-GTA02_andy-tracking-&amp;lt;git hash&amp;gt;.tar.gz. You need to untar this on the root directory of the FR.&lt;br /&gt;
&lt;br /&gt;
If you want to update the local copy of the repository so that you get the latest changes, you can type:&lt;br /&gt;
&lt;br /&gt;
 $ git-pull&lt;br /&gt;
&lt;br /&gt;
Before reporting that the new kernel does not build please first check for changes in the configuration file provided by Openmoko.&lt;br /&gt;
&lt;br /&gt;
=== kernel building tips ===&lt;br /&gt;
&lt;br /&gt;
If you are modifying Linux kernel code and building it quite often you really want to be using [http://ccache.samba.org ccache]. It will save you a lot of time.&lt;br /&gt;
&lt;br /&gt;
TODO: submit a patch for the build script that makes ccache use easier.&lt;br /&gt;
&lt;br /&gt;
== Contributing ==&lt;br /&gt;
&lt;br /&gt;
The development resources [[Openmoko]] offers are:&lt;br /&gt;
&lt;br /&gt;
* Git repository: http://git.openmoko.org/?p=kernel.git;a=summary&lt;br /&gt;
* [http://lists.openmoko.org/mailman/listinfo/openmoko-kernel Mailing list] ([http://lists.openmoko.org/pipermail/openmoko-kernel/ Online Archive])&lt;br /&gt;
&lt;br /&gt;
We appreciate your contributions. Check the Open Issues at the end of this page to check where we need more help.&lt;br /&gt;
&lt;br /&gt;
If in doubt ask in the mailing list.&lt;br /&gt;
&lt;br /&gt;
== FAQ ==&lt;br /&gt;
&lt;br /&gt;
=== Why does Openmoko cares about sending code upstream instead of (insert your task here)? ===&lt;br /&gt;
&lt;br /&gt;
There are two very different approaches and both of them would be doomed if we stuck all our resources to only one of to them.&lt;br /&gt;
&lt;br /&gt;
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 [http://www.kernel.org upstream] where the people who want to help us improve, maintain and support the code running in our devices hang out.&lt;br /&gt;
&lt;br /&gt;
The second is to care way '''too much''' about upstream to the point that we are not willing to ship a temporal dirty hack that make users happy and able to better use their phones. We cannot afford that kind of purity.&lt;br /&gt;
&lt;br /&gt;
As many things in engineering we have to find a point in the middle that works well -- we will try hard to do it.&lt;br /&gt;
&lt;br /&gt;
=== Who's Andy and why is he sticking his name in the kernel? ===&lt;br /&gt;
&lt;br /&gt;
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. He makes sure that the kernel still builds when Linus and his friends feel like it is time to update the upstream kernel and believe us: it is not as fun as it might sound and it happens often.&lt;br /&gt;
&lt;br /&gt;
Check [[Kernel_branches]] if you care about the details.&lt;br /&gt;
&lt;br /&gt;
=== Kernel developers are not polite! They do not even care to say &amp;quot;Hello&amp;quot; when they reply to my emails! ===&lt;br /&gt;
&lt;br /&gt;
The long version is here: [[Kernel-developers-are-not-polite]].&lt;br /&gt;
&lt;br /&gt;
To the point:&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
They just tend to write very short text because they have to read and write a lot every day.&lt;br /&gt;
&lt;br /&gt;
== Known issues ==&lt;br /&gt;
&lt;br /&gt;
=== Sysfs paths ===&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[FSO]] developers realized that this problem could be prevented from from happening in the future and they decided to code a nice daemon called [http://www.freesmartphone.org/index.php/Implementations/OpenDeviceDaemon odeviced].&lt;br /&gt;
&lt;br /&gt;
== Open Tickets ==&lt;br /&gt;
&lt;br /&gt;
'''Please read [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component this report]''' if you wish to know what the current issues are.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=== Easy bugs ===&lt;br /&gt;
&lt;br /&gt;
Those are the bugs that active kernel developers believe can be fixed by 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.&lt;br /&gt;
&lt;br /&gt;
TODO: list of bugs linking to trac.&lt;br /&gt;
&lt;br /&gt;
=== Normal bugs ===&lt;br /&gt;
&lt;br /&gt;
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 Esasy Bugs or Evil bugs. We will use trac for them. Please do not add a list of bugs here.&lt;br /&gt;
&lt;br /&gt;
'''Read this [https://docs.openmoko.org/trac/query?status=accepted&amp;amp;status=assigned&amp;amp;status=in_testing&amp;amp;status=new&amp;amp;status=reopened&amp;amp;component=System+Software&amp;amp;order=priority&amp;amp;col=id&amp;amp;col=summary&amp;amp;col=status&amp;amp;col=type&amp;amp;col=priority&amp;amp;col=milestone&amp;amp;col=component report]''' to find out more about them.&lt;br /&gt;
&lt;br /&gt;
=== Hard bugs ===&lt;br /&gt;
&lt;br /&gt;
Those are the evil bugs that we haven't fixed either because:&lt;br /&gt;
&lt;br /&gt;
# We do not know how to it in reasonable time&lt;br /&gt;
# Hardware vendor doesn't want to release documentation (some of them do that unfortunately / perhaps breaking promises they made to Openmoko about making things easier for developers)&lt;br /&gt;
# More testing is needed (perhaps a hard-to reproduce bug)&lt;br /&gt;
&lt;br /&gt;
Ok, here is the list:&lt;br /&gt;
&lt;br /&gt;
* [https://docs.openmoko.org/trac/ticket/2235 #2235 : Monochrome display on resume]&lt;br /&gt;
&lt;br /&gt;
{{Languages|Kernel}}&lt;br /&gt;
&lt;br /&gt;
[[Category:Kernel]]&lt;br /&gt;
[[Category:System Developers]]&lt;br /&gt;
[[Category:Application Developer]]&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/User:Arhuaco</id>
		<title>User:Arhuaco</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/User:Arhuaco"/>
				<updated>2009-02-27T11:15:28Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: /* Contact */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Only edit to correct a spelling or grammar mistakes'''.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Current Priority ==&lt;br /&gt;
&lt;br /&gt;
Help include support for the GTA02/[[Freerunner]] into the upstream Linux Kernel.&lt;br /&gt;
&lt;br /&gt;
== Currently working on ==&lt;br /&gt;
&lt;br /&gt;
* Send GTA02 basic support upstream (so that we can start sending drivers)&lt;br /&gt;
** I started from this work done [http://lists.openmoko.org/pipermail/openmoko-kernel/2009-February/008925.html by Andy].&lt;br /&gt;
* Get touchscreen driver upstream&lt;br /&gt;
** Apply all the Andew Morton's suggestion for the touchsceen filters&lt;br /&gt;
** Get rid of a sort call Morton did not like. [[User:Werner|Werner]] and I came up with a much better algorithm. Its worst performance only happens when we actually have a hardware problem (too much noise) and if the Hardware does well it is much faster and requires less points.&lt;br /&gt;
&lt;br /&gt;
== TODO List ==&lt;br /&gt;
&lt;br /&gt;
[https://docs.openmoko.org/trac/ticket/2208 #2208] : consider sending touchscreen release event on resume?&lt;br /&gt;
&lt;br /&gt;
== About ==&lt;br /&gt;
&lt;br /&gt;
[[Image:Nelson-lightsaber.jpg|right]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
I am Nelson Castillo -- a Digital Alchemist.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
* My goal is to turn all the difficult issues I have to deal with into working code (silver).&lt;br /&gt;
* When the code is also beautiful then it is better than gold.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Please do never treat me as an entity who does not know how to think. Otherwise I will avoid talking to you and I  will ignore you whenever I can afford it, no matter who you are. The president of any country and whoever I pay to help me clean the room have the same value as persons to me.&lt;br /&gt;
&lt;br /&gt;
== Contact ==&lt;br /&gt;
&lt;br /&gt;
If you have a kernel issue you should write to [http://lists.openmoko.org/mailman/listinfo/openmoko-kernel the mailing list].&lt;br /&gt;
&lt;br /&gt;
I'm usually on IRC (Freenode #openmoko-cdevel) using the nick Arhuaco in order to communicate with developers when we need to talk about important issues. I'm way too busy, old and ugly for casual chat such as a/s/l.&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	<entry>
		<id>http://wiki.openmoko.org/wiki/User:Arhuaco</id>
		<title>User:Arhuaco</title>
		<link rel="alternate" type="text/html" href="http://wiki.openmoko.org/wiki/User:Arhuaco"/>
				<updated>2009-02-27T11:14:32Z</updated>
		
		<summary type="html">&lt;p&gt;Arhuaco: /* Current Priority */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Only edit to correct a spelling or grammar mistakes'''.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Current Priority ==&lt;br /&gt;
&lt;br /&gt;
Help include support for the GTA02/[[Freerunner]] into the upstream Linux Kernel.&lt;br /&gt;
&lt;br /&gt;
== Currently working on ==&lt;br /&gt;
&lt;br /&gt;
* Send GTA02 basic support upstream (so that we can start sending drivers)&lt;br /&gt;
** I started from this work done [http://lists.openmoko.org/pipermail/openmoko-kernel/2009-February/008925.html by Andy].&lt;br /&gt;
* Get touchscreen driver upstream&lt;br /&gt;
** Apply all the Andew Morton's suggestion for the touchsceen filters&lt;br /&gt;
** Get rid of a sort call Morton did not like. [[User:Werner|Werner]] and I came up with a much better algorithm. Its worst performance only happens when we actually have a hardware problem (too much noise) and if the Hardware does well it is much faster and requires less points.&lt;br /&gt;
&lt;br /&gt;
== TODO List ==&lt;br /&gt;
&lt;br /&gt;
[https://docs.openmoko.org/trac/ticket/2208 #2208] : consider sending touchscreen release event on resume?&lt;br /&gt;
&lt;br /&gt;
== About ==&lt;br /&gt;
&lt;br /&gt;
[[Image:Nelson-lightsaber.jpg|right]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
I am Nelson Castillo -- a Digital Alchemist.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
* My goal is to turn all the difficult issues I have to deal with into working code (silver).&lt;br /&gt;
* When the code is also beautiful then it is better than gold.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Please do never treat me as an entity who does not know how to think. Otherwise I will avoid talking to you and I  will ignore you whenever I can afford it, no matter who you are. The president of any country and whoever I pay to help me clean the room have the same value as persons to me.&lt;br /&gt;
&lt;br /&gt;
== Contact ==&lt;br /&gt;
&lt;br /&gt;
If you have a kernel issue you should write to [http://lists.openmoko.org/mailman/listinfo/openmoko-kernel the mailing list].&lt;br /&gt;
&lt;br /&gt;
I'm usually on IRC (Freenode #openmoko-cdevel) using the nick Arhuaco in order to communicate with developers when we need to talk about important issues. I'm way too ugly, old and busy for casual chat such as a/s/l.&lt;/div&gt;</summary>
		<author><name>Arhuaco</name></author>	</entry>

	</feed>