Timo Jyrinki
2010-10-18 07:53:24 UTC
Hi,
During the weekend I did a few cross-builds, emulated native builds
and finally native builds of the 2.6.34 Openmoko kernel for Debian.
It's now available at the pkg-fso repository [1]. It's basically
identical in code and configuration to Radek's qtmoko-v27 git branch
[2], with the added compilation of LED/vibration support. Debian
packaging [3] is virtually the same as with 2.6.29, only minimal
needed changes to bring it to 2.6.34 time. Huge thanks to Radek of
QtMoko fame and SHR people for dwelling through the git trees and
patching up on top of the git.openmoko.org trees to create an usable
kernel.
[1] http://pkg-fso.nomeata.de/sid/linux-image-2.6.34-openmoko-gta02
[2] http://github.com/radekp/linux-2.6/tree/qtmoko-v27
[3] http://git.debian.org/?p=pkg-fso/linux-2.6-openmoko.git;a=shortlog;h=refs/heads/debian-2.6.34
I think the 2.6.34 is a great step forwards, although with a few
caveats for existing Debian w/ 2.6.29 users:
- ALSA switches have changed names. You need to update your state
files manually for now. Some reference can be found at
http://users.tkk.fi/~tajyrink/moko/2.6.34/ for a) phone calls and b)
so that also alerts are heard. I also hacked the headphones out
profile but didn't put it there. Those are probably not optimal, but
work. Updated state files should of course started to be offered by
us, Debian's FSO team.
- Many SYS paths have changed. I've "om gsm power 1" in /etc/rc.local
as one easy workaround for GSM functionality, and I have also been
using the om tool (from omhacks) also otherwise. Newest omhacks is in
pkg-fso repository, and yet more 2.6.34 fixes for it coming reportedly
soon from lindi & co. Most programs probably also don't know anymore
how to control the vibrator, since its path has also changed.
- X.org auto-configuration is in troubles compared to 2.6.29 kernel
(where at least I used xorg.conf with only glamo driver section). I
didn't have time to look at it, so I've just rm /dev/input/event{3,4}
/dev/input/js{0,1} /dev/input/mouse0 in /etc/rc.local for now...
But with those caveats / upgrade problems everything seems to work:
GSM, GPS, Bluetooth, WLAN, LEDs, suspend/resume, and reportedly also
power consumption under suspend is ok...
Note that of course this is not the correct way to do the kernel in
the long term, but I was just willing to spend some of my limited free
time on offering this 2.6.34 branch to the Debian users. What is
really needed to be done (yet again re-iterated) is upstreaming the
rest of the code needed by FreeRunner [4] and helping official s3c24xx
support in the Debian installer / kernel [5]. It is however noticeable
how huge improvement this is over the old 2.6.29 branch. The 2.6.29
kernel was based on _rc3_ of Linus' 2.6.29. There was a rc8 before the
stable 2.6.29 release and six stable updates. After the rc3 however
the git.openmoko.org:s "andy-tracking" tree was patched over the
following 1.5 years without merges from the stable tree. Compared to
that, with the current 2.6.34 tree [6] we're able to see stable/final
2.6.34 commit by Torvalds already on the second page of the commit
log.
[4] http://lists.openmoko.org/pipermail/openmoko-kernel/2010-September/011205.html
[5] http://git.debian.org/?p=pkg-fso/kernel.git;a=shortlog;h=refs/heads/s3c24xx
[6] http://git.debian.org/?p=pkg-fso/linux-2.6-openmoko.git;a=shortlog;h=refs/heads/debian-2.6.34
As a final note, Radek didn't yet include Glamo KMS/DRM support in the
2.6.34 (I think a bit more KMS/DRM problems have been seen with 2.6.34
than 2.6.32), and I didn't start doing it either. Naturally that's the
biggest omission we now don't yet have regarding the work done on
FreeRunner kernels during last and this year. The KMS support is
available in Thomas' branch [7] and SHR's patches [8] - I don't know
what's the delta between them.
[7] http://git.bitwiz.org.uk/?p=kernel.git;a=shortlog;h=refs/heads/gdrm-2.6.34
[8] http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/linux/linux-openmoko-2.6.34
-Timo
During the weekend I did a few cross-builds, emulated native builds
and finally native builds of the 2.6.34 Openmoko kernel for Debian.
It's now available at the pkg-fso repository [1]. It's basically
identical in code and configuration to Radek's qtmoko-v27 git branch
[2], with the added compilation of LED/vibration support. Debian
packaging [3] is virtually the same as with 2.6.29, only minimal
needed changes to bring it to 2.6.34 time. Huge thanks to Radek of
QtMoko fame and SHR people for dwelling through the git trees and
patching up on top of the git.openmoko.org trees to create an usable
kernel.
[1] http://pkg-fso.nomeata.de/sid/linux-image-2.6.34-openmoko-gta02
[2] http://github.com/radekp/linux-2.6/tree/qtmoko-v27
[3] http://git.debian.org/?p=pkg-fso/linux-2.6-openmoko.git;a=shortlog;h=refs/heads/debian-2.6.34
I think the 2.6.34 is a great step forwards, although with a few
caveats for existing Debian w/ 2.6.29 users:
- ALSA switches have changed names. You need to update your state
files manually for now. Some reference can be found at
http://users.tkk.fi/~tajyrink/moko/2.6.34/ for a) phone calls and b)
so that also alerts are heard. I also hacked the headphones out
profile but didn't put it there. Those are probably not optimal, but
work. Updated state files should of course started to be offered by
us, Debian's FSO team.
- Many SYS paths have changed. I've "om gsm power 1" in /etc/rc.local
as one easy workaround for GSM functionality, and I have also been
using the om tool (from omhacks) also otherwise. Newest omhacks is in
pkg-fso repository, and yet more 2.6.34 fixes for it coming reportedly
soon from lindi & co. Most programs probably also don't know anymore
how to control the vibrator, since its path has also changed.
- X.org auto-configuration is in troubles compared to 2.6.29 kernel
(where at least I used xorg.conf with only glamo driver section). I
didn't have time to look at it, so I've just rm /dev/input/event{3,4}
/dev/input/js{0,1} /dev/input/mouse0 in /etc/rc.local for now...
But with those caveats / upgrade problems everything seems to work:
GSM, GPS, Bluetooth, WLAN, LEDs, suspend/resume, and reportedly also
power consumption under suspend is ok...
Note that of course this is not the correct way to do the kernel in
the long term, but I was just willing to spend some of my limited free
time on offering this 2.6.34 branch to the Debian users. What is
really needed to be done (yet again re-iterated) is upstreaming the
rest of the code needed by FreeRunner [4] and helping official s3c24xx
support in the Debian installer / kernel [5]. It is however noticeable
how huge improvement this is over the old 2.6.29 branch. The 2.6.29
kernel was based on _rc3_ of Linus' 2.6.29. There was a rc8 before the
stable 2.6.29 release and six stable updates. After the rc3 however
the git.openmoko.org:s "andy-tracking" tree was patched over the
following 1.5 years without merges from the stable tree. Compared to
that, with the current 2.6.34 tree [6] we're able to see stable/final
2.6.34 commit by Torvalds already on the second page of the commit
log.
[4] http://lists.openmoko.org/pipermail/openmoko-kernel/2010-September/011205.html
[5] http://git.debian.org/?p=pkg-fso/kernel.git;a=shortlog;h=refs/heads/s3c24xx
[6] http://git.debian.org/?p=pkg-fso/linux-2.6-openmoko.git;a=shortlog;h=refs/heads/debian-2.6.34
As a final note, Radek didn't yet include Glamo KMS/DRM support in the
2.6.34 (I think a bit more KMS/DRM problems have been seen with 2.6.34
than 2.6.32), and I didn't start doing it either. Naturally that's the
biggest omission we now don't yet have regarding the work done on
FreeRunner kernels during last and this year. The KMS support is
available in Thomas' branch [7] and SHR's patches [8] - I don't know
what's the delta between them.
[7] http://git.bitwiz.org.uk/?p=kernel.git;a=shortlog;h=refs/heads/gdrm-2.6.34
[8] http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/linux/linux-openmoko-2.6.34
-Timo