More fun with our Openmoko phones

I decided to upgrade to 2008.08, as a new stable release had just been made. This is a followup to my earlier writeup. My later writeup, concerning 2008.12, can be found here.

Version $Id: openmoko-2.html,v 1.29 2009/01/06 14:21:07 madhatta Exp $ .

Old boot environment New boot environment! The iphone 2008.08 interface
Thanks, flamma!

Fast links to the sections:

Upgrading the OS (to 2008.08)

The main instructions are at

Got dfu-util from This is now in risby:~/openmoko .

Got 2008.08 latest-stable images from (jffs and uImage).

As root:

[root@risby tmp]# ./dfu-util --list
dfu-util - (C) 2007 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

Found Runtime: [0x1d50:0x5119] devnum=15, cfg=0, intf=2, alt=0, name="USB Device Firmware Upgrade"

Upload the root fs image:

[root@risby tmp]# ./dfu-util -a rootfs -R -D /home/madhatta/tmp/20080827-asu-stable-rootfs.jffs2 
dfu-util - (C) 2007 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

Opening USB Device 0x0000:0x0000...
Claiming USB DFU Runtime Interface...
Determining device status: state = appIDLE, status = 0
Device really in Runtime Mode, send DFU detach request...
Resetting USB...
Opening USB Device...
Found Runtime: [0x1d50:0x5119] devnum=11, cfg=0, intf=0, alt=6, name="rootfs"
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x1000
Starting download: [##################################################]
state(2) = dfuIDLE, status(0) = No error condition is present
Resetting USB to switch back to runtime mode
Upload the new kernel image:
[root@risby tmp]# ./dfu-util -a kernel -R -D 20080826-asu-stable-uImage.bin 
dfu-util - (C) 2007 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

Opening USB Device 0x0000:0x0000...
Claiming USB DFU Runtime Interface...
Determining device status: state = appIDLE, status = 0
Device really in Runtime Mode, send DFU detach request...
Resetting USB...
Opening USB Device...
Found Runtime: [0x1d50:0x5119] devnum=13, cfg=0, intf=0, alt=3, name="kernel"
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x1000
Starting download: [##################################################]
state(2) = dfuIDLE, status(0) = No error condition is present
Resetting USB to switch back to runtime mode

Then I did an opkg update, which populated a bunch of necessary cache files and did no updating (let's face it, the OS was only released today) (Note from later: I seem to have misunderstood the update command; it only gets the cache files; opkg upgrade is used to actually update the OS. Blame it on my yum background, where yum update gives you the latest packages for your current OS, and yum upgrade is used when going from one major OS version to another) . Then I could do an opkg install midori, to get a web browser, and use opkg and/or the graphical installer to take things from there.


I got my contacts off my old phone by using gnokii to extract my contacts from my Nokia 6230i as a vcard file, editing the vcard file so that it didn't upset the addressbook vcard import, and following XXX need URL for instructions here XXX

XXX also need gnokii incantation XXX

Later: the 2008.08 had an implicit search in it, in which a character typed into the qwerty keyboard would cause a zoom to the first entry starting with that letter. This disappeared in 2008.09.

But it turns out from this email that there is a better search facility in the 2008.09 contact manager, but it's not turned on by default. The FDOMizer (which can currently be found here) shows how this is done, and I reproduced the fix on my openmoko: in the file /home/root/.config/Trolltech/Contacts.conf, in the section [default], I put the line
and a nice "binocular" search bar appeared as the last contact on the screen.


Following this encouraging list email and following the outline instructions on the wiki, I got my WiFi working.

Specifically: I checked that I had wpa-supplicant installed (opkg list_installed|grep wpa-supplicant should return at least one package - no output is bad). I made a stub /etc/wpa_supplicant/wpa_supplicant.conf which looks like this (my WiFi is open, but not unprotected; you can read more details about that in this technote):


# Open:

In /etc/network/interfaces, after the line
iface eth0 inet dhcp
I added the line

	wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

(don't forget to start the line with a TAB), then ifup eth0 did everything I needed it to:
root@tom-gta02:/etc/network# ifup eth0
sed: unrecognized option `--quiet'
BusyBox v1.9.1 (2008-08-07 10:36:49 CST) multi-call binary

Usage: sed [-efinr] pattern [files...]

WPA: Configuring Interface
ioctl[SIOCSIWENCODEEXT]: Operation not supported
ioctl[SIOCSIWENCODEEXT]: Operation not supported
ioctl[SIOCSIWENCODEEXT]: Operation not supported
ioctl[SIOCSIWENCODEEXT]: Operation not supported
udhcpc (v1.9.1) started
Sending discover...
Sending select for
Lease of obtained, lease time 3600
run-parts: /etc/udhcpc.d/00avahi-autoipd exited with return code 1
adding dns

Getting a decent keyboard

this suggestion from the lists has got me a decent keyboard. The only mild fly is that I have to manually click on the "keyboard" launcher after each reboot or X restart; but only once per restart, after that the keyboard service is running in the background and pops up when needed or when the qwerty icon is tapped.

A new desktop app

To get a new launcher on the desktop, put a file like this
[Desktop Entry]
Name=Tom's App
Comment=Command Line Interface Terminal
in /usr/share/applications, and a corresponding icon image tomsapp.png, which should be an 80x80 PNG, in /usr/share/pixmaps . This one just launches another copy of terminal, but if I had anything more exciting for it to do, I could wire it in in the Exec line. The launcher appears immediately on the desktop; there's no need to restart the X server.


No brainer, here. Turned the GPS on under Settings, installed the test GUI (opkg install openmoko-agpsui), started that up and pressed "Power on". I was standing outside, in my tiny garden; TTFF (time to first fix) was 160s, so 3 minutes should hopefully see you lock in (though note
interference issues with the SD clock signal). Mine seems to have the capacitor hardware fix in already (phew!).

So, now off to try TangoGPS. Installation instructions for Openmoko are at 30/8: the instructions work verbatim. What a cool tool; thank you, Marcus!

Audio to other mobiles

We noticed that our mobiles were very, very poor when speaking to other people using mobiles; specifically, they could hardly hear us unless we shouted, but they nearly blew our ears out. I often found myself holding the speaker end of the phone several inches from my head, but holding the microphone end right to my lips, and cupping my hand around it to keep as much of my sound as possible going into the mic. Not good.

Following the recommendations of Daniel Selinger in this email, I tweaked his gsmhandset.state a little further, to crank my microphone gain even more (as he says, and it's odd, mic gain on the handset is controlled by Mono Playback Volume), and found my optimal settings. This is my /usr/share/openmoko/scenarios/gsmhandset.state file. Tests to various listeners said there was no echo on either end, they can hear me much better than before, and they don't blow my ears out. If anything, I hear them a little too quietly.

I tried to crank the speaker volume (Speaker Playback Volume) higher, but even values as gently increased as 105 produced echo. I understand from this list email that hardware echo-cancellation is now understood, and may be turned on in the standard distro any day now. If I get that turned on, I may well try cranking the speaker volume and seeing if the hardware echo-cancel will allow me more sound without more echo.


The basic skills are outlined in this wiki entry. I decided to try option 3, but once the ppp session buggered my voice comms so badly that I had to reboot the 'phone, I decided that multiplexing was the way to go. I'm trying not to fill up my root FS with too many avoidable packages, so decided to try option 2, with multiplexing but without a GUI.

What option 2 doesn't mention is that you still need to follow most of the instructions in part 1, to get the working GSM MUX daemon. I found the best instructions as part of Florian Hackenberger's guide to echo cancellation (which I shall complete shortly, I hope).

So, following Florian's excellent instructions, I installed the four packages (libdbus, libgcc1, libglib and gsm0710muxd). I linked in the daemon to /etc/rc5.d and made the change to 89qtopia (so that the GSM phone service uses the MUXer as well, I presume). I then shamelessly stole the connection files from my laptop, which I was previously using on my O2 SIM in my old phone (see this technote, though it's a bit out of date) and integrated them with suggestions from option 2 in the wiki document we started with.

The files needed are /etc/ppp/peers/gprs, /etc/ppp/chat-gprs, /etc/ppp/chap-secrets (there are no actual secrets in here, but my remote peer tries to authenticate using CHAP and won't establish a link until it's given a chance to do so, even though it doesn't care what you say - so I needed to provide a default null secret), and /home/root/pppd-start.

That last file, pppd-start, is what I run to bring up the ppp connection. It contacts the MUXing service to request an ephemeral MUX'ed connection to the GSM modem, and passes that to pppd. When I run it, I get the following in my /var/log/pppd.log (some IP addresses have been slightly obscured):

Serial connection established.
using channel 7
Using interface ppp0
Connect: ppp0 <--> /dev/pts/3
rcvd [LCP ConfReq id=0x13    ]
sent [LCP ConfReq id=0x1    ]
sent [LCP ConfAck id=0x13    ]
rcvd [LCP ConfRej id=0x1 ]
sent [LCP ConfReq id=0x2   ]
rcvd [LCP ConfAck id=0x2   ]
rcvd [CHAP Challenge id=0x21 <384c8137ee2312bcef513ee8e0e64b53905e4eb0b0af45ba5211f4dc248f80a36952cce4bba897ac82d752>, name = ""]
sent [CHAP Response id=0x21 <8ef72e084940c7ad5f6a7148ccf4c7b3>, name = "tom-gta02"]
rcvd [CHAP Success id=0x21 ""]
CHAP authentication succeeded
sent [CCP ConfReq id=0x1   ]
sent [IPCP ConfReq id=0x1  ]
rcvd [LCP ProtRej id=0x3 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
rcvd [IPCP ConfReq id=0x7]
sent [IPCP ConfNak id=0x7 ]
rcvd [IPCP ConfRej id=0x1 ]
sent [IPCP ConfReq id=0x2 ]
rcvd [IPCP ConfReq id=0x8]
sent [IPCP ConfAck id=0x8]
rcvd [IPCP ConfNak id=0x2 ]
sent [IPCP ConfReq id=0x3 ]
rcvd [IPCP ConfAck id=0x3 ]
Could not determine remote IP address: defaulting to
replacing old default route to usb0 []
local  IP address
remote IP address
Script /etc/ppp/ip-up started (pid 1845)
Script /etc/ppp/ip-up finished (pid 1845), status = 0x0
and the following interface appears:
root@tom-gta02:~# ifconfig ppp0
ppp0      Link encap:Point-to-Point Protocol  
          inet  P-t-P:  Mask:
          RX packets:5 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:38 (38.0 B)  TX bytes:65 (65.0 B)
When I put a sensible DNS server in /etc/resolv.conf, I have full internet connectivity:
root@tom-gta02:/usr/share/applications# ping
PING ( 56 data bytes
64 bytes from seq=0 ttl=46 time=1408.198 ms
64 bytes from seq=1 ttl=46 time=1781.489 ms
64 bytes from seq=2 ttl=46 time=861.490 ms
And killall -15 pppd takes it gracefully down and puts the default route via usb0 back. Job done!

When I have the GPRS up, I can still call out; the connection is temporarily suspended but recovers when I hang up the 'phone. However, calls in sometimes ring the 'phone and sometimes get shunted straight to voice mail. After some very helpful discussion, this list email is where Mickey Lauer clarifies what ought to happen, and here is my followup confirming that I can receive calls while pppd is up, provided there's little or no IP traffic going across the link. Thanks to Timo and Mickey for their help!

Custom ringtone

It's very traditional to customise the ringtone of a phone. The stock ringtone is /opt/Qtopia/etc/SystemRingTones/phonering.wav. It's a 44.1kHz stereo WAV file, 16-bit.

I decided I wanted a traditional old BT phone, and I found an audio clip of one on the web (I think it was here). It is an 8-bit 16kHz mono clip, called 706_ring.wav. It sounded awful when I moved it into place on the 'phone; very distorted and hissy. I re-codec'ed it on my desktop, using

mplayer 706_ring.wav -ao pcm -srate 44100 -af-add volume=-20

which created a file audiodump.wav, having the right sampling frequency (-srate 44100) and being slightly quieter (volume=-20 being the drop in dB) Being quieter, the distortion wasn't as bad and so it didn't make me jump out of my skin when the 'phone rang. I put this into place as openmoko:/opt/Qtopia/etc/SystemRingTones/phonering.wav (saving the old file first) and now I have my custom ringtone. You can get my phonering.wav directly, if you want to.

QPE process eats hours and hours of CPU

I noticed, esp. after today's (2008-09-17) upgrade, that QPE was eating lots and lots of CPU; hours, in some cases. Others noticed, and posted to the support list. Yaroslav Halchenko, in this email, gave a vital pointer to this earlier email, which explains how qpe wants to index the media card on each startup, and if you have, say, lots of tiny files on it (like OSM image tiles for tangoGPS), this can take a long time. It also makes the phone very sluggish and uses a lot of battery.

So I edited my /opt/Qtopia/etc/default/Trolltech/Storage.conf file, changing the last section to read

Name[] = SD Card
Removable = 1
Applications = 0
Documents = 0
ContentDatabase = 0
Now when I restart X (and thus qtopia), qpe settles down almost instantly.

Later: it turns out my cheerfulness was premature. QPE still ate an awful lot of CPU in a seemingly-endless tight loop. I think I really have fixed it now, by removing the config file that was causing me such trouble. I posted to the list, you can read the details here.


I found an iptables package in one of the non-standard repositories, but I can no longer find it. Once I had it installed, I could trivially add firewall rules. Here's one to masquerade traffic out the ppp0 interface, so that when I'm out and about I can share my GPRS connection with my usb-connected laptop:
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
and on the laptop
route add default gw
I'd recommend that you find the package in a proper repository, but if you can't you can get a copy of the one I use

The wrench (spanner, dammit!)

The famous configuration wrench simply didn't happen for me, despite having the illume-config-illume package installed. I finally found it by doing an rm -rf ~/.e/e/config/illume as recommended by the rasterman
here. My spanner now appears at the top of my pull-down "what windows are currently open" bar, and under that I can enter Power and turn Suspend after Blank off. Now, my phone doesn't keep going to sleep the moment after I wake it up.

The "bouncing calypso" problem

My GSM modem kept on unregistering and re-registering itself; it couldn't stay registered for more than a minute when the phone was on. When the phone was asleep, it almost never picked up first ring; I changed my answering machine message to ask people to keep ringing.

This turns out to be a known bug with the firmware on the GSM modem, which is described in some detail in bug #1024. Following the discussion there, I found that doing an AT%SLEEP=2 after every reboot solved the problem. I even wrote a little script that I can invoke from terminal to do it. An updated version can be found here, which uses chat and requires this chat script to be installed as /home/root/ It also requires gsm muxd to be installed, so don't use it if you've not done that.

Using my headset

I was lucky enough to get a 'moko that had the headset included, not that I ever seemed to be able to use it.

Thanks to this email from Matthias Apitz (good man!) I have been able to hijack the control he found. Once you have made a call (ie, ringing or answered), the "options" tab at the bottom of the screen, on the left, contains (amongst other things) an option for "speakerphone". This I have hijacked, with

cd /usr/share/openmoko/scenarios
mv gsmspeakerout.state gsmspeakerout.state-
ln -s gsmheadset.state gsmspeakerout.state 
So when I select the "speakerphone" radio button, my headset goes live. Yes, I have noticed that there's a "headset" control that appears once the call is fully-established, but it's less-easy to access than "speakerphone" and anyway it doesn't work as well. Perhaps it loads headset.state instead of gsmheadset.state?

Backing up the phone

It is written in the doco that dfu-util can be used to back up the 'phone. However, it doesn't work for me (or for some other people; see
this bug for examples, and this bug for an unverified fix).

That said, the mailing list has another way:

The rootfs and kernel images thus created can be restored with dfu-util just as shown at the top of this page. I have just now (2008-12-22) tested this as part of installing, then backing-out, Om2008.12, and it works fine.

Not currently working

Back to Technotes index
Back to main page