Kernel

From Openmoko

(Difference between revisions)
Jump to: navigation, search
(add vibrator and backlight docs)
(added compile info for 2.6.39 (copied the 2.6.32 section and modified it))
 
(112 intermediate revisions by 22 users not shown)
Line 1: Line 1:
== General ==
+
{{Kernel}}
  
The Kernel on the GTA01 is based on a vanilla 2.6.21.3 Linux kernel from [http://www.kernel.org/ kernel.org].
 
  
Some additional patches are required for
+
== Things changed ==
* S3C2410 Usb Device Controller
+
** We use the driver from iPaq H1940 linux project
+
* S3C2410 SD Card Controller
+
** We use the driver from the [http://www.tomtom.com/gpl.php TomTom GO kernel]
+
* [[QT2410]] machine support
+
** This is just some glue that puts all pieces together
+
* S3C2410 touch screen driver
+
** Again from iPaq H1940 linux project
+
* GTA01 machine support
+
** Some glue/configuration to pull all pieces together
+
* [[GSM Communication Infrastructure]]
+
** The kernel-level part (TS07.10 line discipline, GPRS line discipline)
+
  
== Kernel Patchset ==
+
This page will be updated soon. Those are the current [[Kernel_Plans|Kernel plans]].
  
The latest patchset against the abovementioned vanilla kernel can be found at https://svn.openmoko.org/trunk/src/target/kernel/patches/. This is a so-called "[http://savannah.nongnu.org/projects/quilt quilt] patchset".  In order to apply it, you have to download it into a "patches" directory below the "linux-2.6.x" directory, and then call "quilt push -a", which pushes all patches onto the kernel.
+
== Is this page meant for you? ==
  
For example, after unpacking the 2.6.21.1 kernel tarball, you might type the following commands:
+
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.
    cd linux-2.6.21.1
+
    svn co https://svn.openmoko.org/trunk/src/target/kernel/patches
+
    quilt push -a
+
to apply the latest patchset to that kernel. Note that 2.6.21.1 may not be the correct kernel to build against - see previous section to determine just which kernel version to download and patch.
+
  
== Kernel Configuration ==
+
== Introduction ==
  
The latest kernel configuration file can be found at https://svn.openmoko.org/trunk/oe/packages/linux/linux-gta01/.  Just copy the config file corresponding to the correct kernel version to the linux-2.6.x/.config file.
+
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).
  
== Kernel building ==
+
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.
  
The kernel build is executed as normal.  We actually only need the "vmlinux" target, not the "zImage".
+
=== Sister pages ===
  
== Prebuilt kernel images ==
+
# [[Kernel branches]].
  
Prebuilt bootable kernel images called ''uImage*'' are available from:
+
== Sources ==
* http://buildhost.openmoko.org/OM2007.1/tmp/deploy/images/
+
* http://buildhost.openmoko.org/OM2007.2/tmp/deploy/glibc/images/fic-gta01/
+
  
For full operation on the currently supported platforms you need some modules inside the rootfs. You can either get a ''modules*'' archive from the above mentioned location (with the same version number) which contains many more modules then you might need.
+
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:
  
Alternatively you can check the following location
+
http://git.openmoko.org/?p=kernel.git;a=summary
for prepackaged modules for the kernel version and install them using ipkg:
+
* http://buildhost.openmoko.org/OM2007.1/tmp/deploy/ipk/fic-gta01/
+
* http://buildhost.openmoko.org/OM2007.2/tmp/deploy/glibc/ipk/fic-gta01/
+
=== Modules for the Neo1973 GTA01 ===
+
  
On the Neo1973 the following modules should be added to support most of the hardware:
+
[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.
* snd-soc-neo1973-wm8753 snd-soc-s3c24xx-i2s snd-soc-s3c24xx snd-soc-wm8753
+
* ohci-hcd
+
* bluetooth hci-usb
+
* fat vfat msdos nsl-base nls_iso8859_1 nls_cp437
+
  
These really should be in the unmodified root image to start with. See bug 580.
+
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.
  
You'll probably have to put these in a file in /etc/modutils/ and run update-modules to get them to work automatically.
+
If you are very new to GIT you might want to read [http://git.or.cz/course/ the good manuals that already available].
  
* hci_usb
+
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).
* s3cmci
+
* snd-soc-neo1973-wm8753
+
  
== Creating a bootable kernel image ==
+
=== Branches ===
u-boot needs all images (such as kernel, initrd, ...) in the form of an uImage.  This is basically just a special header adding CRC protection, version information, etc. Please see [[u-boot]] for details.
+
  
== Kernel Boot Parameters ==
+
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).
  
Since the [[QT2410]] can be used with different liquid crystal modules (LCMs), the kernel images for the QT2410 have a boot parameter "tft":
+
The ''andy-tracking'' branch is the one where most of the action takes place these days.  
* If you boot without any tft= parameter, the 'stock' qt2410 240x320 TFT panel is assumed.
+
* If you boot with "tft=b" ('b' for big), the timings for the SHARP 8" 640x480 TFT panel are used.
+
* If you boot with "tft=p" ('p' for production), the timings for the 2.8" 480x640 TFT panel are used.
+
  
== Kernel Subsystems ==
+
We have [[Kernel_branches|branch policies]] that explain what each branch is for.
  
In this section we will outline a couple of the GTA01 specific kernel drivers / features / subsystems
+
=== Daily builds ===
  
=== GSM ===
+
==== Automatic revisions ====
  
==== Power Management ====
+
Think of a robot that takes whatever kernels are the most recent in GIT, builds them for you and then makes them available here:
  
The '''gta01_pm_gsm''' driver implements GSM power management (this means, if this is compiled as a module, you have to load the gta01_pm_gsm.ko module first)
+
http://downloads.openmoko.org/distro/experimental/
  
It exports the following sysfs based interface
+
==== Blessed revisions ====
<pre>
+
root@fic-gta01:/$ ls -l /sys/bus/platform/devices/gta01-pm-gsm.0/
+
-rw-r--r--    1 root    root        4096 Feb  1 09:58 download
+
-rw-r--r--    1 root    root        4096 Feb  1 09:58 power_on
+
-rw-r--r--    1 root    root        4096 Feb  1 09:58 reset
+
</pre>
+
  
===== Powering up/down =====
+
Another robot but this one only builds the versions picked by our friendly [[OpenEmbedded]] developers. Download from:
<pre>
+
root@fic-gta01:~$ echo "1" > /sys/bus/platform/devices/gta01-pm-gsm.0/power_on
+
gta01-pm-gsm gta01-pm-gsm.0: powering up GSM, thus disconnecting serial console
+
  
root@fic-gta01:~$ echo "0" > /sys/bus/platform/devices/gta01-pm-gsm.0/power_on
+
http://downloads.openmoko.org/distro/unstable/
gta01-pm-gsm gta01-pm-gsm.0: powered down GSM, thus enabling serial console
+
</pre>
+
  
Note that powering up GSM <b>disables</b> the console.
+
If you understand OpenEmbedded you will get this: Those versions are tied to a specific GIT revision through conf/distro/include/sane-srcrevs.bb.
  
===== Resetting =====
+
=== Building the 2.6.32 branch ===
<pre>
+
root@fic-gta01:~$ echo "1" > /sys/bus/platform/devices/gta01-pm-gsm.0/reset
+
root@fic-gta01:~$ echo "0" > /sys/bus/platform/devices/gta01-pm-gsm.0/reset
+
</pre>
+
  
===== Activating GSM baseband download mode =====
+
Those are the minimum survival commands.
<pre>
+
root@fic-gta01:~$ echo "1" > /sys/bus/platform/devices/gta01-pm-gsm.0/download
+
</pre>
+
  
===== De-activating GSM baseband download mode =====
+
Get kernel sources from git repository:
<pre>
+
root@fic-gta01:~$ echo "0" > /sys/bus/platform/devices/gta01-pm-gsm.0/download
+
</pre>
+
  
=== GPS ===
+
$ git clone git://git.openmoko.org/git/kernel.git linux-2.6
 +
$ cd linux-2.6
  
==== Power Management ====
+
Next switch to the branch:
  
The gta01_pm_gps kernel driver offers a sysfs based interface:
+
$ git checkout --track -b om-gta02-2.6.32 origin/om-gta02-2.6.32
<pre>
+
root@fic-gta01:~$ ls -l /sys/bus/platform/devices/gta01-pm-gps.0/    
+
-rw-r--r--    1 root    root        4096 Feb  1 09:14 power_avdd_3v
+
-rw-r--r--    1 root    root        4096 Feb  1 09:14 power_lp_io_3v3
+
-rw-r--r--    1 root    root        4096 Feb  1 09:14 power_pll_core_2v5
+
-rw-r--r--    1 root    root            0 Feb  1 09:14 power_sequence
+
-rw-r--r--    1 root    root        4096 Feb  1 09:14 power_vtxco_2v8
+
-rw-r--r--    1 root    root        4096 Feb  1 09:14 pwron
+
-rw-r--r--    1 root    root        4096 Feb  1 09:14 reset
+
</pre>
+
  
The power_avdd_3v, power_lp_io_3v3, power_pll_core_2v5, power_vtxco_2v8, pwron and reset files represent the state of the respective signal.
+
Copy the config for the gta02 to be used:
  
The <b>power_sequence</b> file implements power-up/power-down sequence in accordance with the GlobalLocate data sheet.
+
$ cp arch/arm/configs/gta02_drm_defconfig .config
  
===== Powering up =====
+
Now you need a few additional patches for the kernel.
root@fic-gta01:~$ echo "power_up" > /sys/bus/platform/devices/gta01-pm-gps.0/power_sequence
+
You can merge gdrm-2.6.32 or gdrm-for-merging branch directly from Thomas White (http://git.bitwiz.org.uk/?p=kernel.git;a=summary) or all patches used in SHR kernels
===== Powering down =====
+
(http://gitorious.org/~jama/htc-msm-2-6-32/openmoko-kernel/commits/om-gta02-2.6.32). Gitorious branch is usually rebased on top of origin/om-gta02-2.6.32 when we change SRCREV in linux-openmoko-2.6.32_git.bb recipe (http://git.openembedded.org/cgit.cgi/openembedded/log/recipes/linux/linux-openmoko-2.6.32_git.bb)
root@fic-gta01:~$ echo "power_down" > /sys/bus/platform/devices/gta01-pm-gps.0/power_sequence
+
  
=== Asound driver ===
+
$ git remote add gitorious git://gitorious.org/~jama/htc-msm-2-6-32/openmoko-kernel.git
 +
$ git remote update
 +
$ git merge gitorious/om-gta02-2.6.32
  
==== High-level requirements ====
+
Now before building this kernel you need to install a cross compiler toolchain like [[Toolchain]] from openmoko. Alternatively, feel free to use emdebian toolchain for the deb based systems, or crossdev on gentoo.
  
The GTA01 audio subsystem is fairly complex, even though the high-level requirements for the sound driver are simple.
+
Also set two variables for cross compiling (second one is om toolchain specific):
The features we need to support
+
  
* voice call support
+
$ export ARCH="arm"
** passing through the microphone signal to the GSM Modem
+
$ export CROSS_COMPILE="arm-angstrom-linux-gnueabi-"
** passing through the GSM Modem audio output to the integrated speaker(s)
+
** the microphone input mixer gain will be statically configured according to the dynamic requirements
+
** the audio volume that is sent to the GSM modem can be adjusted via line out level
+
** the audio volume incoming (from GSM modem -> codec) can be adjusted via speaker out level
+
* voice call recording support
+
** the user is able to record phone conversations on digital storage inside the phone. Format will be ogg (not important to driver)
+
** ideally, the user can choose between recording only incoming or outgoing signal, or both.
+
** for both, we'd need to mix both microphone and line-in signals before recording. is this possible?
+
* voice call playback support
+
** the user is able to playback recorded files during a conversation.  this means that PCM playback needs to be mixed with mic input before being passed to line-out (and to the GSM modem)
+
* media playback support
+
** an audio player can play back mp3/ogg/flac/... files and output sound via integrated speakers or headphone
+
* headphone jack switch
+
** this is connected to a GPIO of the S3C2410. How to best integrate this with the sound driver? It should just be handled like any other headphone jack reporting of e.g. laptop computers.
+
  
For more details see [[Neo1973 Audio Subsystem]]
+
Now you can configure the kernel:
  
=== Bluetooth ===
+
$ make menuconfig
  
We're using the stock bluez implementation of the linux kernel.
+
or
  
==== Power Management ====
+
$ make xconfig
  
The bluetooth basically has the following preconditions
+
To compile the kernel you just do:
* BT_EN being set
+
* The Voltage regulator set up properly
+
* The ohci-hcd driver being loaded
+
  
The gta01_pm_bt driver implements the following files:
+
$ mkdir GTA02
<pre>
+
  $ make
root@fic-gta01:/$ ls -l /sys/bus/platform/devices/gta01-pm-bt.0
+
  $ make modules_install INSTALL_MOD_PATH=GTA02
-rw-r--r--    1 root    root        4096 Feb 1 09:52 power_on
+
-rw-r--r--    1 root    root        4096 Feb 1 09:52 reset
+
</pre>
+
  
===== Powering up the device =====
+
The new compiled kernel is now "arch/arm/boot/zImage" and the modules are within the "GTA02" directory. Now you just have to copy the "zImage" file to "/boot/uImage" and also copy the modules from within "GTA02" to the same directory structure on the freerunner (/lib/modules/2.6.32).
  
<pre>
+
=== Building the 2.6.39 branch ===
root@fic-gta01:/$ echo "1" > /sys/bus/platform/devices/gta01-pm-bt.0/power_on
+
usb 1-1: new full speed USB device using s3c2410-ohci and address 4
+
usb 1-1: configuration #1 chosen from 1 choice
+
</pre>
+
  
===== Powering down the device =====
+
Get kernel sources from git repository:
<pre>
+
root@fic-gta01:/$ echo "0" > /sys/bus/platform/devices/gta01-pm-bt.0/power_on
+
usb 1-1: USB disconnect, address 3
+
</pre>
+
  
===== Asserting reset (low-active) =====
+
$ git clone git://git.openmoko.org/git/kernel.git linux-2.6
<pre>
+
$ cd linux-2.6
root@fic-gta01:/$ echo "0" >  /sys/bus/platform/devices/gta01-pm-bt.0/reset
+
root@fic-gta01:/$ usb 1-1: USB disconnect, address 2
+
</pre>
+
  
===== De-asserting reset (low-active) =====
+
Next switch to the branch:
<pre>
+
root@fic-gta01:/$ echo "1" >  /sys/bus/platform/devices/gta01-pm-bt.0/reset
+
s3c2410-ohci s3c2410-ohci: wakeup
+
usb 1-1: new full speed USB device using s3c2410-ohci and address 3
+
usb 1-1: configuration #1 chosen from 1 choice
+
</pre>
+
  
==== Getting started ====
+
$ git checkout --track -b om-gta02-2.6.39 origin/om-gta02-2.6.39
  
<pre>
+
The real issue with this branch (at time of writing) is finding a working defconfig.
root@fic-gta01:~$ hciconfig hci0 up
+
My thanks go to PaulFertser who pointed me to OpenEmbedded git and their [http://cgit.openembedded.org/cgit.cgi/openembedded/plain/recipes/linux/linux-2.6.39/om-gta02/defconfig?h=org.openembedded.dev defconfig].
root@fic-gta01:~$ hcitool  scan
+
Don't be alarmed that many options appear as 'NEW' when you build it. When I simply left the default values alone it booted fine for me on the Freerunner.
Scanning ...
+
        00:14:9A:77:A2:02      A780
+
root@fic-gta01:~$ hcitool inq 00:14:9A:77:A2:02
+
Inquiring ...
+
        00:14:9A:77:A2:02      clock offset: 0x55df    class: 0x502204
+
root@fic-gta01:~$ hcitool cc 00:14:9A:77:A2:02
+
root@fic-gta01:~$ hcitool con               
+
Connections:
+
        < ACL 00:14:9A:77:A2:02 handle 42 state 1 lm MASTER
+
root@fic-gta01:~$ hcitool info 00:14:9A:77:A2:02
+
Requesting information ...
+
        BD Address:  00:14:9A:77:A2:02
+
        Device Name: A780
+
        LMP Version: 1.1 (0x1) LMP Subversion: 0x700
+
        Manufacturer: Broadcom Corporation (15)
+
        Features: 0xff 0xff 0x0d 0x00 0x00 0x00 0x00 0x00
+
                <3-slot packets> <5-slot packets> <encryption> <slot offset>
+
                <timing accuracy> <role switch> <hold mode> <sniff mode>
+
                <park state> <RSSI> <channel quality> <SCO link> <HV2 packets>
+
                <HV3 packets> <u-law log> <A-law log> <CVSD> <power control>
+
                <transparent SCO>
+
</pre>
+
  
=== AUX Button ===
+
Copy the downloaded file into the linux-2.6 directory and rename it to .config.
  
The AUX button (formerly 911 button) is supported via the "gta01kbd" driver in the kernel (drivers/input/keyboard/gta01kbd.c).
+
Now before building this kernel you need to install a cross compiler toolchain like [[Toolchain]] from openmoko. Alternatively, feel free to use emdebian toolchain for the deb based systems, or crossdev on gentoo.
  
It creates an input event device that only issues "KEY_PHONE" press/unpress events.
+
Also set two variables for cross compiling (second one is om toolchain specific):
  
=== Power Management Unit (PMU) ===
+
$ export ARCH="arm"
 +
$ export CROSS_COMPILE="arm-angstrom-linux-gnueabi-"
  
The PMU is supported via the "pcf50606" driver in the kernel (drivers/i2c/chips/pcf50606.c).
+
Now you can configure the kernel:
  
This driver provides a number of userspace interfaces for the various bits and pieces of the PMU
+
$ make menuconfig
  
==== Power Button, Charger insertion ====
+
or
  
The PMU creates an input device that supports the following keys:
+
$ make xconfig
* KEY_POWER: power button of GTA01
+
* KEY_POWER2: USB power supply insert/remove
+
* KEY_BATTERY: Charger insert/remove
+
  
==== RTC ====
+
To compile the kernel you just do:
  
The real-time clock, including the alarm feature, is implemented as standard RTC (/dev/rtc).
+
$ mkdir GTA02
 +
$ make
 +
$ make modules_install INSTALL_MOD_PATH=GTA02
  
==== Watchdog ====
+
The new compiled kernel is now "arch/arm/boot/zImage" and the modules are within the "GTA02" directory. Now you just have to copy the "zImage" file to "/boot/uImage" and also copy the modules from within "GTA02" to the same directory structure on the freerunner (/lib/modules/2.6.32).
  
The PMU-integrated watchdog is implemented using the standard watchdog character device.
+
=== Building the andy-tracking branch (obsolete) ===
  
==== Voltage Regulators ====
+
Those are the minimum survival commands.
  
The voltage regulators are exported to userspace using sysfs, much like lm_sensors.
+
Get kernel sources from build.shr-project.org:
  
Every regulator can be read (and written!)The format is ASCII in millivolts.
+
$ wget http://downloads.openmoko.org/developer/sources/git_git.openmoko.org.git.kernel.git.tar.gz
 +
  $ tar xf git_git.openmoko.org.git.kernel.git.tar.gz -C linux-2.6
 +
$ cd linux-2.6
 +
$ git pull
  
<pre>
+
or clone from a git repository:
root@fic-gta01:/sys/devices/platform/s3c2410-i2c/i2c-0/0-0008$ ls -l /sys/bus/i2c/devices/0-0008/voltage_*
+
-rw-r--r--    1 root    root        4096 Sep  3 11:55 /sys/bus/i2c/devices/0-0008/voltage_d1reg
+
-rw-r--r--    1 root    root        4096 Sep  3 11:55 /sys/bus/i2c/devices/0-0008/voltage_d2reg
+
-rw-r--r--    1 root    root        4096 Sep  3 11:55 /sys/bus/i2c/devices/0-0008/voltage_d3reg
+
-rw-r--r--    1 root    root        4096 Sep  3 11:55 /sys/bus/i2c/devices/0-0008/voltage_dcd
+
-rw-r--r--    1 root    root        4096 Sep  3 11:55 /sys/bus/i2c/devices/0-0008/voltage_dcde
+
-rw-r--r--    1 root    root        4096 Sep  3 11:55 /sys/bus/i2c/devices/0-0008/voltage_dcud
+
-rw-r--r--    1 root    root        4096 Sep  3 11:55 /sys/bus/i2c/devices/0-0008/voltage_lpreg
+
-rw-r--r--    1 root    root        4096 Sep  3 11:55 /sys/bus/i2c/devices/0-0008/voltage_ioreg
+
root@fic-gta01:/sys/devices/platform/s3c2410-i2c/i2c-0/0-0008$ cat voltage_dcd
+
1300
+
</pre>
+
  
==== Battery Voltage ====
+
$ git clone git://git.openmoko.org/git/kernel.git linux-2.6
 +
$ cd linux-2.6
  
The battery voltage (in millivolts) can be read via sysfs
+
Next switch to the branch:
  
<pre>
+
$ git checkout --track -b andy-tracking origin/andy-tracking
root@fic-gta01:~$ cat /sys/bus/i2c/devices/0-0008/battvolt
+
$ mkdir GTA02
3767
+
$ cp ./arch/arm/configs/gta02_moredrivers_defconfig GTA02/.config
</pre>
+
  
==== Battery charging current ====
+
Before building this kernel you need install a [http://wiki.openmoko.org/wiki/Toolchain#Downloading_and_installing Toolchain].
  
The battery charging current (in milliamperes) can be read via sysfs
+
$ ./build GTA02
  
<pre>
+
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).
root@fic-gta01:~$ cat /sys/bus/i2c/devices/0-0008/chgcur
+
0
+
</pre>
+
  
==== Battery temperature ====
+
In order to build the modules you can:
  
The battery temperature (in centigrades) can be read via sysfs
+
$ ./build GTA02 dummy
  
<pre>
+
This will create a file called modules-GTA02_andy-tracking-<git hash>.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.
root@fic-gta01:~$ cat /sys/bus/i2c/devices/0-0008/battemp
+
25
+
</pre>
+
  
=== Backlight ===
+
If you want to update the local copy of the repository so that you get the latest changes, you can type:
  
We provide a driver that supports the linux kernel standard backlight API. You can find the respective sysfs files in /sys/class/backlight/
+
$ git pull
  
=== Vibrator ===
+
Before reporting that the new kernel does not build please first check for changes in the configuration file provided by Openmoko.
  
The vibrator driver is implemented as a LED driver.  You can find the respective sysfs files in /sys/class/led/.
+
=== kernel building tips ===
The vibrator classdev name is '''gta01:vibrator'''.
+
  
Please note, depending on the kernel version, the driver only supports on/off or PWM of the vibrator device.  If you want to run the vibrator at full power, use
+
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.
<pre>
+
root@fic-gta01:~$ echo "255" > /sys/class/leds/gta01\:vibrator/brightness
+
</pre>
+
  
== Kernel TODO ==
+
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].
  
=== Various ===
+
=== Old troubleshooting information ===
* speed up in-kernel boot process
+
** delay calibration
+
** framebuffer takes ages
+
  
===  TS07.10 multiplex ===
+
If it fails with error message "arm-angstrom-linux-gnueabi-ld: unrecognized option '-Wl,-rpath-link,/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/lib'" until /usr/local/openmoko/arm/setup-env is modified. LDFLAGS should be changed from:
  
=== PCF50606 ===
+
export LDFLAGS="-L${OMTOOL_DIR}/arm/arm-angstrom-linux-gnueabi/lib -Wl,-rpath-link,${OMTOOL_DIR}/arm/arm-angstrom-linux-gnueabi/lib -Wl,-O1"
* check conversion table for temperature
+
* implement 'persistent alarm setting' (see mail from mickey)
+
  
=== USB device driver ===
+
to:
* test switching between usb host and usb device
+
  
== Mailing list ==
+
export LDFLAGS="-L${OMTOOL_DIR}/arm/arm-angstrom-linux-gnueabi/lib -rpath-link ${OMTOOL_DIR}/arm/arm-angstrom-linux-gnueabi/lib -O1"
  
OpenMoko related kernel development discussions happen on the [http://lists.openmoko.org/mailman/listinfo/openmoko-kernel openmoko-kernel@lists.openmoko.org] mailing list.
+
I also had to change the 'build' script to hardcode the path to the compiler.
 +
 
 +
== Contributing ==
 +
 
 +
The development resources Openmoko offers are:
 +
 
 +
* Git repository: http://git.openmoko.org/?p=kernel.git;a=summary
 +
* [http://lists.openmoko.org/mailman/listinfo/openmoko-kernel Mailing list] ([http://lists.openmoko.org/pipermail/openmoko-kernel/ Online Archive])
 +
 
 +
We appreciate your contributions. Check the Open Issues at the end of this page to check where we need more help.
 +
 
 +
If in doubt ask in the mailing list.
 +
 
 +
== FAQ ==
 +
 
 +
=== "Verifying Checksum ... Bad Data CRC" with U-boot ===
 +
 
 +
U-boot might not be reading the whole kernel. To fix this you need to:
 +
 
 +
setenv bootcmd 'setenv bootargs ${bootargs_base} ${mtdparts}; nand read.e 0x32000000 kernel 0x300000; bootm 0x32000000'
 +
saveenv
 +
 
 +
Could someone please explain this more in detail for example:
 +
Login your freerunner with root@192.168.0.202
 +
#home_pc > root@192.168.0.202
 +
#freerunner > setenv ...
 +
 
 +
You might also move to [[Qi]].
 +
 
 +
=== What happened to usb0? ===
 +
 
 +
Now you will get eth<n> instead of usb0. Check:
 +
 
 +
http://lists.openmoko.org/pipermail/devel/2009-April/005384.html
 +
 
 +
=== Who's Andy and why is he sticking his name in the kernel? ===
 +
 
 +
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
 +
 
 +
Check [[Kernel_branches]] if you care about the details.
 +
 
 +
=== Kernel developers are not polite! They do not even care to say "Hello" when they reply to my emails! ===
 +
 
 +
The long version is here: [[Kernel-developers-are-not-polite]].
 +
 
 +
To the point:
 +
 
 +
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.
 +
 
 +
They just tend to write very short text because they have to read and write a lot every day.
 +
 
 +
 
 +
=== Why does Openmoko cares about sending code upstream instead of (insert your task here)? ===
 +
 
 +
There are two very different approaches and both of them would be doomed if we committed all our resources to only one of them.
 +
 
 +
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.
 +
 
 +
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.
 +
 
 +
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.
 +
 
 +
== Known issues ==
 +
 
 +
=== Sysfs paths ===
 +
 
 +
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.
 +
 
 +
[[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].
 +
 
 +
=== WSOD with u-boot ===
 +
 
 +
There is work in progress to fix this issue that does not happen with Qi. Latest kernel from andy-tracking.
 +
 
 +
== Open Tickets ==
 +
 
 +
'''This
 +
[http://docs.openmoko.org/trac/query?status=in_testing&status=reopened&status=assigned&status=new&status=accepted&group=status&milestone=stable-kernel-2009.1 report] will show the bugs that are a priority for us now'''.
 +
 
 +
 
 +
'''Please read [https://docs.openmoko.org/trac/query?status=accepted&status=assigned&status=in_testing&status=new&status=reopened&component=System+Software&order=priority&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component this report]''' if you wish to know what the current issues are.
 +
 
 +
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.
 +
 
 +
=== Easy bugs ===
 +
 
 +
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.
 +
 
 +
TODO: list of bugs linking to trac.
 +
 
 +
=== Normal bugs ===
 +
 
 +
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.
 +
 
 +
'''This is the complete [https://docs.openmoko.org/trac/query?status=accepted&status=assigned&status=in_testing&status=new&status=reopened&component=System+Software&order=priority&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component report]''' with all the bugs (some of them might be invalid).
 +
 
 +
=== Hard bugs ===
 +
 
 +
Those are the evil bugs that we haven't fixed either because:
 +
 
 +
# We do not know how to do it in reasonable time
 +
# 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)
 +
# More testing is needed (perhaps a hard-to-reproduce bug)
 +
 
 +
Here is the list:
 +
 
 +
* [https://docs.openmoko.org/trac/ticket/2235 #2235 : Monochrome display on resume]
  
 
{{Languages|Kernel}}
 
{{Languages|Kernel}}
  
[[Category:Software]]
+
[[Category:Kernel| ]]

Latest revision as of 17:52, 17 August 2011

Kernel

(Kernel related)



Contents

[edit] Things changed

This page will be updated soon. Those are the current Kernel plans.

[edit] Is this page meant for you?

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.

[edit] Introduction

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).

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.

[edit] Sister pages

  1. Kernel branches.

[edit] Sources

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:

http://git.openmoko.org/?p=kernel.git;a=summary

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.

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.

If you are very new to GIT you might want to read the good manuals that already available.

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).

[edit] Branches

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).

The andy-tracking branch is the one where most of the action takes place these days.

We have branch policies that explain what each branch is for.

[edit] Daily builds

[edit] Automatic revisions

Think of a robot that takes whatever kernels are the most recent in GIT, builds them for you and then makes them available here:

http://downloads.openmoko.org/distro/experimental/

[edit] Blessed revisions

Another robot but this one only builds the versions picked by our friendly OpenEmbedded developers. Download from:

http://downloads.openmoko.org/distro/unstable/

If you understand OpenEmbedded you will get this: Those versions are tied to a specific GIT revision through conf/distro/include/sane-srcrevs.bb.

[edit] Building the 2.6.32 branch

Those are the minimum survival commands.

Get kernel sources from git repository:

$ git clone git://git.openmoko.org/git/kernel.git linux-2.6
$ cd linux-2.6

Next switch to the branch:

$ git checkout --track -b om-gta02-2.6.32 origin/om-gta02-2.6.32

Copy the config for the gta02 to be used:

$ cp arch/arm/configs/gta02_drm_defconfig .config

Now you need a few additional patches for the kernel. You can merge gdrm-2.6.32 or gdrm-for-merging branch directly from Thomas White (http://git.bitwiz.org.uk/?p=kernel.git;a=summary) or all patches used in SHR kernels (http://gitorious.org/~jama/htc-msm-2-6-32/openmoko-kernel/commits/om-gta02-2.6.32). Gitorious branch is usually rebased on top of origin/om-gta02-2.6.32 when we change SRCREV in linux-openmoko-2.6.32_git.bb recipe (http://git.openembedded.org/cgit.cgi/openembedded/log/recipes/linux/linux-openmoko-2.6.32_git.bb)

$ git remote add gitorious git://gitorious.org/~jama/htc-msm-2-6-32/openmoko-kernel.git
$ git remote update
$ git merge gitorious/om-gta02-2.6.32

Now before building this kernel you need to install a cross compiler toolchain like Toolchain from openmoko. Alternatively, feel free to use emdebian toolchain for the deb based systems, or crossdev on gentoo.

Also set two variables for cross compiling (second one is om toolchain specific):

$ export ARCH="arm"
$ export CROSS_COMPILE="arm-angstrom-linux-gnueabi-"

Now you can configure the kernel:

$ make menuconfig

or

$ make xconfig

To compile the kernel you just do:

$ mkdir GTA02 
$ make
$ make modules_install INSTALL_MOD_PATH=GTA02

The new compiled kernel is now "arch/arm/boot/zImage" and the modules are within the "GTA02" directory. Now you just have to copy the "zImage" file to "/boot/uImage" and also copy the modules from within "GTA02" to the same directory structure on the freerunner (/lib/modules/2.6.32).

[edit] Building the 2.6.39 branch

Get kernel sources from git repository:

$ git clone git://git.openmoko.org/git/kernel.git linux-2.6
$ cd linux-2.6

Next switch to the branch:

$ git checkout --track -b om-gta02-2.6.39 origin/om-gta02-2.6.39

The real issue with this branch (at time of writing) is finding a working defconfig. My thanks go to PaulFertser who pointed me to OpenEmbedded git and their defconfig. Don't be alarmed that many options appear as 'NEW' when you build it. When I simply left the default values alone it booted fine for me on the Freerunner.

Copy the downloaded file into the linux-2.6 directory and rename it to .config.

Now before building this kernel you need to install a cross compiler toolchain like Toolchain from openmoko. Alternatively, feel free to use emdebian toolchain for the deb based systems, or crossdev on gentoo.

Also set two variables for cross compiling (second one is om toolchain specific):

$ export ARCH="arm"
$ export CROSS_COMPILE="arm-angstrom-linux-gnueabi-"

Now you can configure the kernel:

$ make menuconfig

or

$ make xconfig

To compile the kernel you just do:

$ mkdir GTA02 
$ make
$ make modules_install INSTALL_MOD_PATH=GTA02

The new compiled kernel is now "arch/arm/boot/zImage" and the modules are within the "GTA02" directory. Now you just have to copy the "zImage" file to "/boot/uImage" and also copy the modules from within "GTA02" to the same directory structure on the freerunner (/lib/modules/2.6.32).

[edit] Building the andy-tracking branch (obsolete)

Those are the minimum survival commands.

Get kernel sources from build.shr-project.org:

$ wget http://downloads.openmoko.org/developer/sources/git_git.openmoko.org.git.kernel.git.tar.gz
$ tar xf git_git.openmoko.org.git.kernel.git.tar.gz -C linux-2.6
$ cd linux-2.6
$ git pull

or clone from a git repository:

$ git clone git://git.openmoko.org/git/kernel.git linux-2.6
$ cd linux-2.6

Next switch to the branch:

$ git checkout --track -b andy-tracking origin/andy-tracking
$ mkdir GTA02 
$ cp ./arch/arm/configs/gta02_moredrivers_defconfig GTA02/.config

Before building this kernel you need install a Toolchain.

$ ./build GTA02

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).

In order to build the modules you can:

$ ./build GTA02 dummy

This will create a file called modules-GTA02_andy-tracking-<git hash>.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.

If you want to update the local copy of the repository so that you get the latest changes, you can type:

$ git pull

Before reporting that the new kernel does not build please first check for changes in the configuration file provided by Openmoko.

[edit] kernel building tips

If you are modifying Linux kernel code and building it quite often you really want to be using ccache. It will save you a lot of time.

TODO: submit a patch for the build script that makes ccache use easier. Note: There is a patch being reviewed.

[edit] Old troubleshooting information

If it fails with error message "arm-angstrom-linux-gnueabi-ld: unrecognized option '-Wl,-rpath-link,/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/lib'" until /usr/local/openmoko/arm/setup-env is modified. LDFLAGS should be changed from:

export LDFLAGS="-L${OMTOOL_DIR}/arm/arm-angstrom-linux-gnueabi/lib -Wl,-rpath-link,${OMTOOL_DIR}/arm/arm-angstrom-linux-gnueabi/lib -Wl,-O1"

to:

export LDFLAGS="-L${OMTOOL_DIR}/arm/arm-angstrom-linux-gnueabi/lib -rpath-link ${OMTOOL_DIR}/arm/arm-angstrom-linux-gnueabi/lib -O1"

I also had to change the 'build' script to hardcode the path to the compiler.

[edit] Contributing

The development resources Openmoko offers are:

We appreciate your contributions. Check the Open Issues at the end of this page to check where we need more help.

If in doubt ask in the mailing list.

[edit] FAQ

[edit] "Verifying Checksum ... Bad Data CRC" with U-boot

U-boot might not be reading the whole kernel. To fix this you need to:

setenv bootcmd 'setenv bootargs ${bootargs_base} ${mtdparts}; nand read.e 0x32000000 kernel 0x300000; bootm 0x32000000'
saveenv

Could someone please explain this more in detail for example: Login your freerunner with root@192.168.0.202

  1. home_pc > root@192.168.0.202
  2. freerunner > setenv ...

You might also move to Qi.

[edit] What happened to usb0?

Now you will get eth<n> instead of usb0. Check:

http://lists.openmoko.org/pipermail/devel/2009-April/005384.html

[edit] Who's Andy and why is he sticking his name in the kernel?

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

Check Kernel_branches if you care about the details.

[edit] Kernel developers are not polite! They do not even care to say "Hello" when they reply to my emails!

The long version is here: Kernel-developers-are-not-polite.

To the point:

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.

They just tend to write very short text because they have to read and write a lot every day.


[edit] Why does Openmoko cares about sending code upstream instead of (insert your task here)?

There are two very different approaches and both of them would be doomed if we committed all our resources to only one of them.

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 upstream where the people who want to help us improve, maintain and support the code running in our devices, hang out.

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.

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.

[edit] Known issues

[edit] Sysfs paths

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.

FSO developers realized that this problem could be prevented from from happening in the future and they decided to code a nice daemon called odeviced.

[edit] WSOD with u-boot

There is work in progress to fix this issue that does not happen with Qi. Latest kernel from andy-tracking.

[edit] Open Tickets

This report will show the bugs that are a priority for us now.


Please read this report if you wish to know what the current issues are.

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.

[edit] Easy bugs

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.

TODO: list of bugs linking to trac.

[edit] Normal bugs

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.

This is the complete report with all the bugs (some of them might be invalid).

[edit] Hard bugs

Those are the evil bugs that we haven't fixed either because:

  1. We do not know how to do it in reasonable time
  2. 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)
  3. More testing is needed (perhaps a hard-to-reproduce bug)

Here is the list:

Personal tools

General

The Kernel on the GTA01 is based on a vanilla 2.6.21.3 Linux kernel from kernel.org.

Some additional patches are required for

  • S3C2410 Usb Device Controller
    • We use the driver from iPaq H1940 linux project
  • S3C2410 SD Card Controller
  • QT2410 machine support
    • This is just some glue that puts all pieces together
  • S3C2410 touch screen driver
    • Again from iPaq H1940 linux project
  • GTA01 machine support
    • Some glue/configuration to pull all pieces together
  • GSM Communication Infrastructure
    • The kernel-level part (TS07.10 line discipline, GPRS line discipline)

Kernel Patchset

The latest patchset against the abovementioned vanilla kernel can be found at https://svn.openmoko.org/trunk/src/target/kernel/patches/. This is a so-called "quilt patchset". In order to apply it, you have to download it into a "patches" directory below the "linux-2.6.x" directory, and then call "quilt push -a", which pushes all patches onto the kernel.

For example, after unpacking the 2.6.21.1 kernel tarball, you might type the following commands:

   cd linux-2.6.21.1
   svn co https://svn.openmoko.org/trunk/src/target/kernel/patches
   quilt push -a

to apply the latest patchset to that kernel. Note that 2.6.21.1 may not be the correct kernel to build against - see previous section to determine just which kernel version to download and patch.

Kernel Configuration

The latest kernel configuration file can be found at https://svn.openmoko.org/trunk/oe/packages/linux/linux-gta01/. Just copy the config file corresponding to the correct kernel version to the linux-2.6.x/.config file.

Kernel building

The kernel build is executed as normal. We actually only need the "vmlinux" target, not the "zImage".

Prebuilt kernel images

Prebuilt bootable kernel images called uImage* are available from:

For full operation on the currently supported platforms you need some modules inside the rootfs. You can either get a modules* archive from the above mentioned location (with the same version number) which contains many more modules then you might need.

Alternatively you can check the following location for prepackaged modules for the kernel version and install them using ipkg:

Modules for the Neo1973 GTA01

On the Neo1973 the following modules should be added to support most of the hardware:

  • snd-soc-neo1973-wm8753 snd-soc-s3c24xx-i2s snd-soc-s3c24xx snd-soc-wm8753
  • ohci-hcd
  • bluetooth hci-usb
  • fat vfat msdos nsl-base nls_iso8859_1 nls_cp437

These really should be in the unmodified root image to start with. See bug 580.

You'll probably have to put these in a file in /etc/modutils/ and run update-modules to get them to work automatically.

  • hci_usb
  • s3cmci
  • snd-soc-neo1973-wm8753

Creating a bootable kernel image

u-boot needs all images (such as kernel, initrd, ...) in the form of an uImage. This is basically just a special header adding CRC protection, version information, etc. Please see u-boot for details.

Kernel Boot Parameters

Since the QT2410 can be used with different liquid crystal modules (LCMs), the kernel images for the QT2410 have a boot parameter "tft":

  • If you boot without any tft= parameter, the 'stock' qt2410 240x320 TFT panel is assumed.
  • If you boot with "tft=b" ('b' for big), the timings for the SHARP 8" 640x480 TFT panel are used.
  • If you boot with "tft=p" ('p' for production), the timings for the 2.8" 480x640 TFT panel are used.

Kernel Subsystems

In this section we will outline a couple of the GTA01 specific kernel drivers / features / subsystems

GSM

Power Management

The gta01_pm_gsm driver implements GSM power management (this means, if this is compiled as a module, you have to load the gta01_pm_gsm.ko module first)

It exports the following sysfs based interface

root@fic-gta01:/$ ls -l /sys/bus/platform/devices/gta01-pm-gsm.0/
-rw-r--r--    1 root     root         4096 Feb  1 09:58 download
-rw-r--r--    1 root     root         4096 Feb  1 09:58 power_on
-rw-r--r--    1 root     root         4096 Feb  1 09:58 reset
Powering up/down
root@fic-gta01:~$ echo "1" > /sys/bus/platform/devices/gta01-pm-gsm.0/power_on 
gta01-pm-gsm gta01-pm-gsm.0: powering up GSM, thus disconnecting serial console

root@fic-gta01:~$ echo "0" > /sys/bus/platform/devices/gta01-pm-gsm.0/power_on 
gta01-pm-gsm gta01-pm-gsm.0: powered down GSM, thus enabling serial console

Note that powering up GSM disables the console.

Resetting
root@fic-gta01:~$ echo "1" > /sys/bus/platform/devices/gta01-pm-gsm.0/reset 
root@fic-gta01:~$ echo "0" > /sys/bus/platform/devices/gta01-pm-gsm.0/reset 
Activating GSM baseband download mode
root@fic-gta01:~$ echo "1" > /sys/bus/platform/devices/gta01-pm-gsm.0/download
De-activating GSM baseband download mode
root@fic-gta01:~$ echo "0" > /sys/bus/platform/devices/gta01-pm-gsm.0/download

GPS

Power Management

The gta01_pm_gps kernel driver offers a sysfs based interface:

root@fic-gta01:~$ ls -l /sys/bus/platform/devices/gta01-pm-gps.0/     
-rw-r--r--    1 root     root         4096 Feb  1 09:14 power_avdd_3v
-rw-r--r--    1 root     root         4096 Feb  1 09:14 power_lp_io_3v3
-rw-r--r--    1 root     root         4096 Feb  1 09:14 power_pll_core_2v5
-rw-r--r--    1 root     root            0 Feb  1 09:14 power_sequence
-rw-r--r--    1 root     root         4096 Feb  1 09:14 power_vtxco_2v8
-rw-r--r--    1 root     root         4096 Feb  1 09:14 pwron
-rw-r--r--    1 root     root         4096 Feb  1 09:14 reset

The power_avdd_3v, power_lp_io_3v3, power_pll_core_2v5, power_vtxco_2v8, pwron and reset files represent the state of the respective signal.

The power_sequence file implements power-up/power-down sequence in accordance with the GlobalLocate data sheet.

Powering up
root@fic-gta01:~$ echo "power_up" > /sys/bus/platform/devices/gta01-pm-gps.0/power_sequence 
Powering down
root@fic-gta01:~$ echo "power_down" > /sys/bus/platform/devices/gta01-pm-gps.0/power_sequence

Asound driver

High-level requirements

The GTA01 audio subsystem is fairly complex, even though the high-level requirements for the sound driver are simple. The features we need to support

  • voice call support
    • passing through the microphone signal to the GSM Modem
    • passing through the GSM Modem audio output to the integrated speaker(s)
    • the microphone input mixer gain will be statically configured according to the dynamic requirements
    • the audio volume that is sent to the GSM modem can be adjusted via line out level
    • the audio volume incoming (from GSM modem -> codec) can be adjusted via speaker out level
  • voice call recording support
    • the user is able to record phone conversations on digital storage inside the phone. Format will be ogg (not important to driver)
    • ideally, the user can choose between recording only incoming or outgoing signal, or both.
    • for both, we'd need to mix both microphone and line-in signals before recording. is this possible?
  • voice call playback support
    • the user is able to playback recorded files during a conversation. this means that PCM playback needs to be mixed with mic input before being passed to line-out (and to the GSM modem)
  • media playback support
    • an audio player can play back mp3/ogg/flac/... files and output sound via integrated speakers or headphone
  • headphone jack switch
    • this is connected to a GPIO of the S3C2410. How to best integrate this with the sound driver? It should just be handled like any other headphone jack reporting of e.g. laptop computers.

For more details see Neo1973 Audio Subsystem

Bluetooth

We're using the stock bluez implementation of the linux kernel.

Power Management

The bluetooth basically has the following preconditions

  • BT_EN being set
  • The Voltage regulator set up properly
  • The ohci-hcd driver being loaded

The gta01_pm_bt driver implements the following files:

root@fic-gta01:/$ ls -l /sys/bus/platform/devices/gta01-pm-bt.0
-rw-r--r--    1 root     root         4096 Feb  1 09:52 power_on
-rw-r--r--    1 root     root         4096 Feb  1 09:52 reset
Powering up the device
root@fic-gta01:/$ echo "1" > /sys/bus/platform/devices/gta01-pm-bt.0/power_on
usb 1-1: new full speed USB device using s3c2410-ohci and address 4
usb 1-1: configuration #1 chosen from 1 choice
Powering down the device
root@fic-gta01:/$ echo "0" > /sys/bus/platform/devices/gta01-pm-bt.0/power_on 
usb 1-1: USB disconnect, address 3
Asserting reset (low-active)
root@fic-gta01:/$ echo "0" >  /sys/bus/platform/devices/gta01-pm-bt.0/reset 
root@fic-gta01:/$ usb 1-1: USB disconnect, address 2
De-asserting reset (low-active)
root@fic-gta01:/$ echo "1" >  /sys/bus/platform/devices/gta01-pm-bt.0/reset 
s3c2410-ohci s3c2410-ohci: wakeup
usb 1-1: new full speed USB device using s3c2410-ohci and address 3
usb 1-1: configuration #1 chosen from 1 choice

Getting started

root@fic-gta01:~$ hciconfig hci0 up
root@fic-gta01:~$ hcitool  scan
Scanning ...
        00:14:9A:77:A2:02       A780
root@fic-gta01:~$ hcitool inq 00:14:9A:77:A2:02 
Inquiring ...
        00:14:9A:77:A2:02       clock offset: 0x55df    class: 0x502204
root@fic-gta01:~$ hcitool cc 00:14:9A:77:A2:02 
root@fic-gta01:~$ hcitool con                 
Connections:
        < ACL 00:14:9A:77:A2:02 handle 42 state 1 lm MASTER 
root@fic-gta01:~$ hcitool info 00:14:9A:77:A2:02
Requesting information ...
        BD Address:  00:14:9A:77:A2:02
        Device Name: A780
        LMP Version: 1.1 (0x1) LMP Subversion: 0x700
        Manufacturer: Broadcom Corporation (15)
        Features: 0xff 0xff 0x0d 0x00 0x00 0x00 0x00 0x00
                <3-slot packets> <5-slot packets> <encryption> <slot offset> 
                <timing accuracy> <role switch> <hold mode> <sniff mode> 
                <park state> <RSSI> <channel quality> <SCO link> <HV2 packets> 
                <HV3 packets> <u-law log> <A-law log> <CVSD> <power control> 
                <transparent SCO> 

AUX Button

The AUX button (formerly 911 button) is supported via the "gta01kbd" driver in the kernel (drivers/input/keyboard/gta01kbd.c).

It creates an input event device that only issues "KEY_PHONE" press/unpress events.

Power Management Unit (PMU)

The PMU is supported via the "pcf50606" driver in the kernel (drivers/i2c/chips/pcf50606.c).

This driver provides a number of userspace interfaces for the various bits and pieces of the PMU

Power Button, Charger insertion

The PMU creates an input device that supports the following keys:

  • KEY_POWER: power button of GTA01
  • KEY_POWER2: USB power supply insert/remove
  • KEY_BATTERY: Charger insert/remove

RTC

The real-time clock, including the alarm feature, is implemented as standard RTC (/dev/rtc).

Watchdog

The PMU-integrated watchdog is implemented using the standard watchdog character device.

Voltage Regulators

The voltage regulators are exported to userspace using sysfs, much like lm_sensors.

Every regulator can be read (and written!). The format is ASCII in millivolts.

root@fic-gta01:/sys/devices/platform/s3c2410-i2c/i2c-0/0-0008$ ls -l /sys/bus/i2c/devices/0-0008/voltage_*
-rw-r--r--    1 root     root         4096 Sep  3 11:55 /sys/bus/i2c/devices/0-0008/voltage_d1reg
-rw-r--r--    1 root     root         4096 Sep  3 11:55 /sys/bus/i2c/devices/0-0008/voltage_d2reg
-rw-r--r--    1 root     root         4096 Sep  3 11:55 /sys/bus/i2c/devices/0-0008/voltage_d3reg
-rw-r--r--    1 root     root         4096 Sep  3 11:55 /sys/bus/i2c/devices/0-0008/voltage_dcd
-rw-r--r--    1 root     root         4096 Sep  3 11:55 /sys/bus/i2c/devices/0-0008/voltage_dcde
-rw-r--r--    1 root     root         4096 Sep  3 11:55 /sys/bus/i2c/devices/0-0008/voltage_dcud
-rw-r--r--    1 root     root         4096 Sep  3 11:55 /sys/bus/i2c/devices/0-0008/voltage_lpreg
-rw-r--r--    1 root     root         4096 Sep  3 11:55 /sys/bus/i2c/devices/0-0008/voltage_ioreg
root@fic-gta01:/sys/devices/platform/s3c2410-i2c/i2c-0/0-0008$ cat voltage_dcd
1300

Battery Voltage

The battery voltage (in millivolts) can be read via sysfs

root@fic-gta01:~$ cat /sys/bus/i2c/devices/0-0008/battvolt 
3767

Battery charging current

The battery charging current (in milliamperes) can be read via sysfs

root@fic-gta01:~$ cat /sys/bus/i2c/devices/0-0008/chgcur 
0

Battery temperature

The battery temperature (in centigrades) can be read via sysfs

root@fic-gta01:~$ cat /sys/bus/i2c/devices/0-0008/battemp
25

Backlight

We provide a driver that supports the linux kernel standard backlight API. You can find the respective sysfs files in /sys/class/backlight/

Vibrator

The vibrator driver is implemented as a LED driver. You can find the respective sysfs files in /sys/class/led/. The vibrator classdev name is gta01:vibrator.

Please note, depending on the kernel version, the driver only supports on/off or PWM of the vibrator device. If you want to run the vibrator at full power, use

root@fic-gta01:~$ echo "255" > /sys/class/leds/gta01\:vibrator/brightness

Kernel TODO

Various

  • speed up in-kernel boot process
    • delay calibration
    • framebuffer takes ages

TS07.10 multiplex

PCF50606

  • check conversion table for temperature
  • implement 'persistent alarm setting' (see mail from mickey)

USB device driver

  • test switching between usb host and usb device

Mailing list

OpenMoko related kernel development discussions happen on the openmoko-kernel@lists.openmoko.org mailing list.