I’ve installed android on my freerunner. I’ve to say that it works ! very nice and functional interface, finger friendly, voice, sms, wifi work out of the box. I’m very impressed.

Following the lead from http://lackingrhoticity.blogspot.com/2010/02/how-to-build-adb-android-debugger.html I’ve decided to build adb to connect to my phone without downloading the precompiled sdk and without checking-out the entire android git repository. It’s actually very easy, and I’m sure with a minimal effort, it should be possible to create a debian package. The android instructions give some hints regarding the cross-compilation of android on a x64 machine.

Cutting and pasting from Lacking Rhoticity blog you need to :

$ sudo apt-get install build-essential libncurses5-dev
$ git clone git://android.git.kernel.org/platform/system/core.git system/core
$ git clone git://android.git.kernel.org/platform/build.git build
$ git clone git://android.git.kernel.org/platform/external/zlib.git external/zlib
$ git clone git://android.git.kernel.org/platform/bionic.git bionic
$ echo "include build/core/main.mk" >Makefile

Now edit build/core/main.mk and comment out the parts labelled

# Check for the correct version of java

and

# Check for the correct version of javac

Since adb doesn’t need Java, these checks are unnecessary.

Also edit build/target/product/sdk.mk and comment out the “include” lines after

# include available languages for TTS in the system image

Now, since we are one a x64 machine we need to install the rest of the libraries to cross compile abd. I think this is the minimum you need to successfully build adb

sudo apt-get install libc6-dev-i386 lib32ncurses5-dev ia32-libs g++-multilib

The result should be something like this :

$make out/host/linux-x86/bin/adb
============================================
PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=2.1-update1
TARGET_PRODUCT=generic
TARGET_BUILD_VARIANT=eng
TARGET_SIMULATOR=
TARGET_BUILD_TYPE=release
TARGET_ARCH=arm
HOST_ARCH=x86
HOST_OS=linux
HOST_BUILD_TYPE=release
BUILD_ID=ECLAIR
============================================
find: `frameworks/base/api': No such file or directory
[ ... ]
host Executable: adb (out/host/linux-x86/obj/EXECUTABLES/adb_intermediates/adb)
true
host C: acp <= build/tools/acp/acp.c
host C++: libhost <= build/libs/host/pseudolocalize.cpp
host C: libhost <= build/libs/host/CopyFile.c
host StaticLib: libhost (out/host/linux-x86/obj/STATIC_LIBRARIES/libhost_intermediates/libhost.a)
ar crs  out/host/linux-x86/obj/STATIC_LIBRARIES/libhost_intermediates/libhost.a out/host/linux-x86/obj/STATIC_LIBRARIES/libhost_intermediates/pseudolocalize.o out/host/linux-x86/obj/STATIC_LIBRARIES/libhost_intermediates/CopyFile.o
host Executable: acp (out/host/linux-x86/obj/EXECUTABLES/acp_intermediates/acp)
true
Install: out/host/linux-x86/bin/acp
Notice file: system/core/adb/NOTICE -- out/host/linux-x86/obj/NOTICE_FILES/src//bin/adb.txt
Notice file: system/core/libzipfile/NOTICE -- out/host/linux-x86/obj/NOTICE_FILES/src//lib/libzipfile.a.txt
Notice file: external/zlib/NOTICE -- out/host/linux-x86/obj/NOTICE_FILES/src//lib/libunz.a.txt
Notice file: system/core/liblog/NOTICE -- out/host/linux-x86/obj/NOTICE_FILES/src//lib/liblog.a.txt
Notice file: system/core/libcutils/NOTICE -- out/host/linux-x86/obj/NOTICE_FILES/src//lib/libcutils.a.txt
Install: out/host/linux-x86/bin/adb

Running abd :

$out/host/linux-x86/bin/adb      
Android Debug Bridge version 1.0.25
[...]

Now something very important that made me wonder for a while. By default android does not allow any connection with adb. To use it you must enable it on the phone. Then go Applications then Development. Under here you want to switch on Stay awake so that your screen stays visible while connected to your main system.

Finally, you can talk to your phone. Success !

$ADBHOST=192.168.0.202 ./out/host/linux-x86/bin/adb devices
* daemon not running. starting it now *
* daemon started successfully *
List of devices attached 
emulator-5554   device

This is an extract from a thread about the audio you can get on the latest shr-testing while calling and receiving calls. I put it here for reference.

I’ve changed in /etc/frameworkd.conf

ti_calypso_dsp_mode = long-aec+nr

and in /etc/freesmartphone/alsa/default/gsmhandset

4:'Speaker Playback Volume':2:115,115

—— was 127,127 (this affect the handset speaker)

then following http://wiki.openmoko.org/wiki/Neo_Freerunner_audio_subsystem#Alsamixer_channel_controls

I’ve changed :

5:'Mono Playback Volume':1:105

—— was 110

12:'Mono Sidetone Playback Volume':1:5

—— was 7

48:'Mic2 Capture Volume':1:2

—- was 3

My guess is that the two most important defaults are ti_calypso_dsp_mode and the control 12 .

Update

Very interesting thread on this subject. And this page (in french).

This morning I spent sometimes trying to understand how the GPS subsystem on the freerunner works. I’m using SHR unstable. These information might be incomplete or wrong, so just use them with a grain of salt.

Ok, at the beginning the clients where connecting to the GPS device either directly : serial device -> client or using gpsd serial device-> gpsd-> client

so far so good. In the end an application like tangogps or navit only needed to have a fix that is not that difficult to obtain from the raw device input.

But what if I want to handle and gather information from multiple GPS devices ? the idea here is to add an additional layer of indirection to make like easier to clients. On top of it, since the freerunner used dbus to communicate and frameworkd as a communication broker we have now two different players. * gps -> ogpsd -> fso-gpsd -> tangogps

From [2], this is the story: gpsd - this is our good old friend from http://gpsd.berlios.de/ “True gpsd” someone called it. ogpsd - this is a subsystem of FSO’s frameworkd. It replaces gpsd it implements the Gypsy API communicating with applications via dbus fso-gpsd - is a compatibility shim to translate Gypsy messages for applications that expect gpsd clients …

What is gypsy [3] ? Gypsy is a GPS multiplexing daemon/protocol which allows multiple clients to access GPS data from multiple GPS sources concurrently.

Now, my point was to use the GPS information collected by these two fantastic projects opencellid [5] and cellhunter [6]. In order to do that I would need to add a “fake” gps device to feed ogpsd with information retrieved from the cell database.

If the architecture I’ve described here is correct, it should not be to difficult to add the missing bit in ogpsd [4] …

UPDATE: It seems that there is already an implementation [8,9] of agps fetching data from agps.u-blox.com and based on gllin [7] , but you will need a data connection to use this one.

[8] http://www.opkg.org/package_127.html [9] http://lists.openmoko.org/pipermail/community/2008-June/018680.html

http://gpsd.berlios.de/NMEA.txt

[2] http://kerneltrap.org/index.php?q=mailarchive/openmoko-community/2008/9/24/3395094

[3] http://gypsy.freedesktop.org/wiki/

[4] http://git.freesmartphone.org/?p=framework.git;a=tree;f=framework/subsystems/ogpsd;hb=HEAD

[5] http://www.opencellid.org/

[6] http://78.47.116.33/~hole/cellhunter/

[7] http://wiki.openmoko.org/wiki/Gllin

This week I got myself a sim card and I started doing a more appropriate use of my freerunner. For a start I’ve flushed it with the latest SHR distribution. The SHR is based on FSO and I’ve the feeling that is stable enough for daily use. After struggling a bit I’ve also installed debian. The installer script is still a bit broken and, in particular in this period, is very fragile because of the state of flush of debian unstable. Nonetheless, after a couple of restart I managed to get it going.

I’ve also flushed the FR with QI, the new boot loader, that is seems faster then u-boot. It is also more strict about the kernel location and naming, but nothing I can’t handle :)

Last but not least, I flushed the new GSM firmware using the image that is provided by OM. It worked straightaway, nothing much to report here.

All in all, I’m pretty happy with the state of things. I received and made phone calls as well as sms. Sometimes there are small usability quirks that make it more difficult to use the phone that what it should. I’ve seen a lot of bug reports and suggestions and I’m sure we’re going to solve everything soon.

Not very much of a technical post. Maybe I’ll collect few links later on…

The other day I got a new, shiny freerunner. This is my dream mobile phone/ wearable computer. The HW spec can be found here [1] . Reading the wiki I pleasantly discovered that two HW problem were fixed in my phone release, namely the battery problem and the GPS problem. I can boot my freerunner without the battery. Before because the charging circuitry wasn’t activated but after the boot, it was impossible to boot the phone without a battery, or with a dry battery. Now this problem seems gone. This is the reference [2] . The second problem is related to an bad interaction between the sd card and the GPS chip. The fix is to add a small resistor. From a visual inspection of my phone, the resitor seems already in place. I haven’t try it yet, but I hope this is the case. Reference [3]

I think my freerunner is the GTA02v6

[1] http://wiki.openmoko.org/wiki/Neo_FreeRunner_GTA02_Hardware

[2] http://wiki.openmoko.org/wiki/Freerunner_Hardware_Issues#PMU.2FCharger_Issue

[3] http://wiki.openmoko.org/wiki/GPS_Problems