[Gta04-owner] We need an Android kernel
Dr. H. Nikolaus Schaller
hns at goldelico.com
Wed Jul 17 11:00:45 CEST 2013
Hi Paul, Marek,
Am 17.07.2013 um 10:12 schrieb Belisko Marek:
> 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).
Hm I have the contrary impression - at least for non-android systems.
Kernel 3.7 (especially our neil-brown-plus) kernel supports almost all
features we want and is running quite well on the DM3730 (maybe except
some special 1 GHz issues). So why not use this (and try to push things
>> 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.
On the other hand TI has a long-term comittment to sell the DM3730 chips
(10 years from introduction which is more than 5 years to go). And these chips
are used in many industrial applications. But maybe these don't care about
the latest kernels (one guy told me about one system still running on Linux 0.99).
>> 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
>>> 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.
Ok, this is good news. So I would prefer adding the missing Android parts
to mainline instead of adding missing board specific features to some
>>> 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.
Yes, this may become a problem - but for the moment I would ignore this
We could even use the SGX blobs for development/debugging purposes
and wait for the FSF PowerVR reverse engineering project to provide some
results. The SGX drivers in kernel space are already included in the
Maybe Replicant and the PowerVR RE together may get more traction than
each one taken alone.
>> 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:
>> 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 
> 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:
> but for versatile express they use 3.10-rc6 kernel:
I did look into the neil-brown sources and we can simply enable some CONFIG_ANDROID
features which are in 'staging'.
-# CONFIG_ANDROID is not set
# CONFIG_PHONE is not set
# CONFIG_USB_WPAN_HCD is not set
# CONFIG_IPACK_BUS is not set
I can't tell if this is complete or has problems, but it compiles fine and the extended kernel
still works with Debian.
I have tried to boot the replicant 4.0 rootfs on this kernel, but it fails because it does
not find the init process. And I was not yet able to find the location of the 'init' binary
in the Replicant roofs to simply make a copy/symlink to /sbin/init (where the mainline
kernel apparently tries to locate it).
> Any ideas why we cannot use latest kernel (e.g. 3.7 or whatever higher?)
Yes, this is what I am wondering as well.
>>> 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"...
So my preference is shifting clearly towards "GTA04-3.7" + "android-features".
Unless there is good reason that it can not work (after investing some debugging
>> 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
That is good, since we don't need specific omap features from the Android
>> 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.
Well, we as being GNU supporters should do it better...
take the generic Linux kernel, grap platform specific patches (neil-brown-plus)
and optimize everything that is still missing - either by upstreaming patches
or by doing our platform specific things.
>> 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.
Ok... This explains the mess why there are rarely the latest upgrades
Because they start over every time.
More information about the Gta04-owner