[Gta04-owner] We need an Android kernel

Wed Jul 17 10:12:21 CEST 2013

Hi All,

On Tue, Jul 16, 2013 at 11:30 PM, Paul Kocialkowski <paulk at paulk.fr> wrote:
> Le mardi 16 juillet 2013 à 20:54 +0200, Dr. H. Nikolaus Schaller a
> écrit :
>> > * 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.
>
> Yes indeed. Though I don't have the required equipment (not any
> oscilloscope around) to check what is going on precisely.
>
>> 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.
>
> As far as I know, mainline is far from offering complete support for
> DM37x, which is why there are so many platform-specific kernels out
> there (such as rowboat). I guess they just don't have time to wait for
> everything to be upstream and need to release the code early so that
> they can sell devices without waiting and enable other to do so.
> Moreover, some stuff will obviously never be uspstream, such as the
> powervr drivers.
>
> So that's the problem with upstream. Now the issue with the other way is
> the one you're talking about: we shouldn't rely on TI or another company
> to provide DM37x kernels. They seem to have dropped the idea long ago
> anyway, as they decided not to add DM37x support to newer (than 2.6.37)
> kernels. I think that's why we're stuck. Then maybe our best chances are
> indeed taking a recent mainline (or close) kernel, that we can assume to
> have gathered more and more DM37x features over time. Maybe 3.4 would be
> a good fit since Android support is easy to integrate too.
>
>> 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...
>
> My point is that users won't really care whether they have 3.0, 3.4 or
> 3.10 as long as the kernel runs fine with the operating system and that
> we merge stability/security fixes along with new versions.
>
>> 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, ...
>
> That would be great, but I think we need a concrete solution that works
> now (in the next few weeks) so that we can release images with decent
> support and attract new users / customers for gta04.
>
>> 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.
>
> The latest Android version is Jellybean 4.2 and the latest Replicant is
> 4.0. I will probably port all the currently-supported devices to 4.2 by
> the end of August if there is nothing else to do, but frankly, I prefer
> to add new features (hardware support) in 4.0 rather than porting the
> devices to 4.2 with the same status (which is a big task).
>
> Moreover, regarding the kernel, Jellybean 4.2 is known to work fine with
> both 3.0 kernels from Ice Cream Sandwich 4.0 and 3.4 kernels that were
> introduced with Jellybean 4.2. So I think if we get a working kernel for
> Replicant 4.0, it'll be reusable for 4.2 and perhaps the next version
> with very little work. I can handle moving the user-space from 4.0 to
> 4.2 without much trouble, though our biggest fear is the possibility of
> using new versions of Android without the PowerVR blobs. We tricked 4.0
> to deal with it and the result is fine, but we can't guarantee it'll be
> the same on newer versions. So for now it's safer to keep going with 4.0
> as this ensures that we'll be able to release usable images soon while
> leading the path towards 4.2 and newer versions since most of the stuff
> written for 4.0 is reusable in 4.2 and probably in newer versions with
> vert little changes.
>
>> 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
>
> I will start working on a 3.4 kernel in the next few days. I'll report
> here about the issues I'm facing.
I'm bit confused about kernel versions and I'm not very much familiar
with android kernel.
I believe google is using old versions of kernel ( > 3.0 ) because compatibility
with android userspace. Weird is that I was doing some research about
porting android on am33xx platform and according [1]
stock 3.8 kernel + enabled staging android drivers work on that
platform out of the box (android 4.2).

Linaro android builds is using for pandaboard (which is omap4) kernel
3.2 and they have suspend/resume working with 13.06 release:
https://docs.google.com/spreadsheet/ccc?key=0AkxwyUNxNaAadGVWd3pZazdaRUU0MnRnWmgwbVhTR0E#gid=17

but for versatile express they use 3.10-rc6 kernel:
https://docs.google.com/spreadsheet/ccc?key=0AkxwyUNxNaAadExQdHNxTnR5SFZCQzJnN1ZtQ2ZhWkE#gid=5

Any ideas why we cannot use latest kernel (e.g. 3.7 or whatever higher?)
>
>> 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"...
>
> Basically as I said, the > 3.4 Android kernels are all marked as
> experimental and nobody actually use them on devices, so it seems like a
> really poor choice in terms of stability. It is also highly likely that
> the Android-specific kernel interfaces were changed to comply with
> mainline rules and thus that using them with 4.0 or 4.2 userspace will
> draw compatibility issues.
>
>> 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?
>
> Basically, android-3.4 is the mainline 3.4 with android patches on top,
> and they rebase the stability/security updates on top once in a while.
> Though, the android patches don't add any particular omap-specific
> features. There are TI Android kernels for 3.4 but they target omap4 so
> we have very little interest in using them and it seems like they have
> broken some omap3 support there and there (I remember trying one of
> these on gta04, with terrible results).
>
>> * what is the overall strategy of Google and Linux for this question?
>
> The strategy of Android device manufacturers in general is that they
> take the generic android kernel (say 3.4 for recent devices) and grab
> platform-specific optimizations on top so that it works perfectly.
> Usually, when they upgrade to a new version (that requires a new kernel,
> for instance when switching from Android 2.3 to Android 4.0), they start
> over again with a more recent kernel and often rewrite big portions of
> code in another way. Very clearly, they don't try to reuse the code they
> wrote for older kernels, or just use it as reference.
> Sometimes, they just refuse to upgrade to a new kernel version and let
> the device sitting around with an old kernel, which makes Android
> developers communities furious since they can't port the device to newer
> Android versions anymore.
> Google does the same for the Nexus line of Android phones.
>
> _______________________________________________
> Gta04-owner mailing list
> Gta04-owner at goldelico.com
> http://lists.goldelico.com/mailman/listinfo/gta04-owner

[1]: http://icculus.org/~hendersa/android/

Marek

--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com