[Gta04-owner] We need an Android kernel

[Dr. H. Nikolaus Schaller]

Hi Paul,

Am 16.07.2013 um 19:36 schrieb Paul Kocialkowski:

> I'm starting to feel desperate as we still don't have any working
> Android kernel.

Yes, I agree! The current situation is quite insufficient and I am still hesitating
how much work I should put into the kernel, since I don't know if it is the
right way.

> What is really important to get properly is
> suspend/resume. Most of the rest can be added on pretty much any kernel
> (at least I think I can do it). I am not qualified enough to debug
> suspend/resume, so we can either have someone working on it or we find a
> kernel where it already works.
> 
> Here is a list of some of the combinations I tried:

Great. I was just planning to do some research, but of course you are
faster and have already experimented.

> * Using the Rowboat 2.6.37 kernel with gta04 board, defconfig and some
> drivers on top
> 
> Suspend/resume pretty much works but there is a screen flickering issue
> after resume, which I can't solve. This may be because of the lcd panel
> driver that does not suspend/resume the panel properly or because of
> omapdss suspend/resume. It does this with both PWM and GPIO backlight.

Flickering might also be some frame refresh clock not being restored correctly.

> 
> * Using the android-3.0 common kernel with gta04 board, defconfig and
> some drivers on top
> 
> Suspend/resume doesn't work and needs to be debugged and correctly
> fixed.
> 
> * Using an omap4 (such as the android-omap-3.0 android omap kernel)
> 
> Kernel causes problems with DSS: I couldn't get the display to work and
> it prevents the kernel from booting it seems: I dont have anything on
> serial when I register DSS platform data.
> Suspend/resume seemed not to work either

I think that there were some changes in the DSS system around kernel 3.0.

> 
> * Using the android-omap3-3.0 omapzoom kernel
> 
> Suspend/resume works but there is a major issue that causes lost IRQs.
> 
> I think it is better to use a 3.0 or maybe 3.4 kernel because:
> * Older kernels (2.6.37 for instance) don't have the new kernel
> interfaces for Android USB Gadget, which makes it difficult to use USB
> Mass Storage or MTP.
> * Newer kernels are not seriously used by anyone: every Android device
> uses 3.0 (ICS) or 3.4 (JB). Thus, they lack support for a lot of Android
> pieces (earlysuspend/earlyresume is not implemented in drivers for
> instance);
> * 3.0 and 3.4 are actually used, there is active development on these
> versions for Android
> 
> Now the problem seems to be that nobody bothered to add Android support
> to a BeagleBoard kernel (and I mean one with complete omap3 support, not
> just mainline) after 2.6.37. TI teams are very clear: they won't port
> omap3 devices to any newer kernel. The only exception being the omapzoom
> android-omap-3.0 kernel.

I think we should try to focus on the mainline kernels since we can't depend
on a single company to support it. They may anytime decide to unplug
development - like they did for OMAP4/5.

> Also, please, don't try to find fixes for the 3.2 kernel: it was a quick
> and dirty kernel we set up for the purpose of showing Replicant 2.3.
> It is a pure waste of time and we will anyway reject that as a stable
> kernel for the future.
> 
> So now, what do we do ? I can't do magic and solve the huge issues I am
> facing everytime and at the very least, I need help from competent
> people. I can definitely handle the Android/Replicant userspace part,
> also some easy driver bits of the kernel but I need a stable,
> fully-featured base. Else I can keep going with any of the kernels I
> tried that offer the least minimum to develop the userspace, but it will
> all be wasted time if we don't have a real kernel at some point.
> 
> I think we need to do this now or just forget about the idea of having
> Android/Replicant running on GTA04. Please, help me out!

Since I also don't want to give up the idea of a really good Android/Replicant
system for the GTA04, let's think a little about goals and coming back from the
future.

I.e. we have to discuss and decide a strategy before starting to code.

First of all we (i.e. GTA04 business) needs the most modern kernel we
can get. One that is maintained and close to the newest kernels, or we
risk the problem that drivers will run out of sync and we need more and
more time to maintain an ageing system. And users want to see the
latest and greatest...

The next thing to consider is that we don't have very many kernel developers
so we can't maintain three or four different kernels. In an ideal world there
were only a single kernel used by all different distributions. And that one
would be available for download from kernel.org.

Let's draw some vision:

Going approx. 2 years into the future, Android 5.0 will use Linux 4.0
and all required kernel features are mainline :) Then, we will simply
have a single 4.0 kernel for Replicant, QtMoko, SHR, Debian, ...

So coming back to fill the gap between now and this expectation (well,
I know that open source projects hate to do the obvious :), I think
we should focus to get as close as possible to the latest Android
that is available (i.e. JB 4.3). Everything else is IMHO wasting efforts
in view of the limited capacity we have.

If JB uses Linux 3.4 we are IMHO in a quite good situation since Neil Brown
did start with Linux 3.4 to integrate the suspend/resume things to bring
down power consumption:

http://git.neil.brown.name/?p=gta04.git;a=shortlog;h=refs/heads/3.4-gta04

So it should be possible to backport all patches introduced up to the latest
neil-brown-3.7 kernel.

On the other hand I researched that most special features of Android kernels
(e.g. wakelocks) are either implemented in kernel driver modules or are
already available in 3.7 and newer kernels. Maybe implemented in a different
way or API than Google intended (the usual discussions when trying to
upstream radically new features)...

So we still have to decide if we should do a "GTA04-3.7" + "android-features"
or a "3.4-android" + "missing features like hardware adaptation"...

Since the goal should be to do the one with least efforts, much of this
depends on how fast the Android kernel will come close to the Linux kernels
in the future.

To come to a decision about this question, I think we should understand:

* how different are mainline-3.4 and android-3.4 kernels?
* what is the overall strategy of Google and Linux for this question?
* what features are missing in the neil-brown-3.7 kernel to run an Android user space?

BR,
Nikolaus