Openmoko - User contributions [en]

USB Networking

2008-01-25T01:58:27Z

Chooseopen: /* Name resolution */

= Neo1973 side =

== Name resolution ==

By default Neo1973 has usb0 interface working due to Ethernet gadget (g_ether) compiled into kernel.

On the Neo, if you want to reach out to the internets using full qualified hostnames, you need to define your DNS server. Create a file /etc/resolv.conf with at least one line saying

nameserver xxx.xxx.xxx.xxx

e.g. nameserver 192.168.1.1

Then you can also easily update your 2007.2 OpenMoko packages with "ipkg update && ipkg upgrade" on the Neo.
 
A better approach is it edit: /etc/network/interfaces and modify the line: 
<code>
up echo nameserver 192.168.0.200 >/etc/resolv.conf
</code> 
to specify your preferred DNS server instead of 192.168.0.200.
 
example: <code>up echo nameserver 4.2.2.2 >/etc/resolv.conf</code>

Another approach is to symlink (NOW OBSOLETE?)

ln -s /var/run/resolv.conf /etc/resolv.conf

and fill the file at bootup with a script /etc/network/if-up.d/08setupdns containing:

#!/bin/sh -e
echo nameserver 192.168.0.200 > /var/run/resolv.conf

this way the file is correctly handled from ppp package when dialing into gprs.

== Routing ==

You need a additional route for traffic to the internet. This traffic can be routed through your pc (see below) if the pc is the default route destination. you can achieve this by adding

gateway 192.168.0.200

to your /etc/network/interfaces in the usb0 section.

= Desktop side =

== Manual method ==

With the device connected, modprobe usbnet module and configure usb0 interface (as root):
<pre>
ifconfig usb0 192.168.0.200 netmask 255.255.255.0
</pre>
If your eth0 interface is also in the same 'range' (e.g. 192.168.0.105) then you can do the following:

1. ping the Neo with
# ping -I usb0 192.168.0.202
2. add a route to your Neo:
# /sbin/route add -host 192.168.0.202/32 dev usb0
3 log in to the Neo
# ssh root@192.168.0.202

If you don't have the necessary modules to get usb0 going, make sure you have the following kernel options enabled:
* CONFIG_USB_USBNET
* CONFIG_USB_NET_CDCETHER
Both options are available in the Device Drivers -> USB support -> USB Network Adapters. For more info see the [http://www.linux-usb.org/usbnet/ usbnet driver homepage].

== Automatic method ==

Took from [http://blog.haerwu.biz/2007/03/22/hotpluging-usbnet/ Hotplugging usbnet] post by Marcin 'Hrw' Juszkiewicz.

=== Debian or similar ===
Edit /etc/network/interfaces:
<pre>
allow-hotplug usb0
iface usb0 inet static
address 192.168.0.200
netmask 255.255.255.0
network 192.168.0.0
post-up iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24
post-up echo 1 > /proc/sys/net/ipv4/ip_forward
post-up iptables -P FORWARD ACCEPT
</pre>

=== Ubuntu (Tested with Feisty and Gutsy) ===
Edit /etc/network/interfaces:
<pre>
auto usb0
iface usb0 inet static
address 192.168.0.200
netmask 255.255.255.0
network 192.168.0.0
up iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24 &
up echo 1 > /proc/sys/net/ipv4/ip_forward &
up iptables -P FORWARD ACCEPT &
down iptables -D POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24 &
</pre>

If you are doing the echo 1 > /proc/... command manually, sudo may not be enough, then you will have to execute it from a sudo bash.

Ubuntu Feisty and Gutsy appear to have a bug where ifdown is not run when the interface is unplugged, meaning this only works once after the system is booted.
One can patch /etc/udev/rules.d/85-ifupdown.rules, editing the two lines at the end of the file:
<pre>
SUBSYSTEM=="net", DRIVERS=="?*", GOTO="net_start"
GOTO="net_end"

LABEL="net_start"

# Bring devices up and down only if they're marked auto.
# Use start-stop-daemon so we don't wait on dhcp
ACTION=="add", RUN+="/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifup -- --allow auto $env{INTERFACE}"

LABEL="net_end"

ACTION=="remove", RUN+="/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifdown -- --allow auto $env{INTERFACE}"
</pre>

the bug is that the LABEL="net_end" is at the wrong position
=== SuSE ===
/etc/sysconfig/network/ifcfg-usb0
# USB configuration for PDAs (openmoko)
IPADDR=192.168.0.200
NETMASK=255.255.255.0
STARTMODE=onboot
=== Fedora (Tested with FC8) ===
/etc/sysconfig/network-scripts/ifcfg-usb0
<pre>
# USB configuration for PDAs (openmoko)
# from http://www.handhelds.org/moin/moin.cgi/UsbNet
DEVICE=usb0
BOOTPROTO=none
IPADDR=192.168.0.200
NETMASK=255.255.255.0
ONBOOT=yes
</pre>

=== Red Hat or similar ===
Edit /etc/sysconfig/network-scripts/net.hotplug:

After this command
<pre>
case $INTERFACE in
# interfaces that are registered after being "up" (?)
</pre>
add
<pre>
usb0)
ifconfig usb0 192.168.0.200 netmask 255.255.255.0
route add 192.168.0.202 usb0
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24
echo 1 > /proc/sys/net/ipv4/ip_forward
exit 0
;;
</pre>
=== Gentoo ===
* Open /etc/conf.d/net and add:
# Neo1973
config_usb0=( "192.168.0.200 netmask 255.255.255.0" )
routes_usb0=( "192.168.0.202/32 via 192.168.0.200" )
* Create a new init script:
cd /etc/init.d
ln -s net.lo net.usb0
* Put iptables into use:
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT
iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24
* Store them
/etc/init.d/iptables save
* If you want the routing by default:
rc-update add iptables default
* You must also inform the kernel, to start forwarding. One way to automate this is to create /etc/conf.d/net.usb0 as follows

preup() {
echo 1 > /proc/sys/net/ipv4/ip_forward
return 0
}

postdown() {
echo 0 > /proc/sys/net/ipv4/ip_forward
return 0
}

This way, packet forwarding will be turned on when Neo is plugged in, and off when it's not.

=== MacOS X ===
See the [[MacOS_X#USB_Networking|USB Networking section in the MacOS X article]].

= Mobile development =

== Proxying DNS requests ==

If, like me, you move about quite a lot, connecting to various networks as you go and getting your ip via dhcp, you'll probably be annoyed at having to constantly update your resolv.conf on the Neo 1973.

To get round this, as part of my setup script, I run a proxy dns on the ip address the neo comes in on at the usb0 port. This means that my Neo /etc/resolv.conf only contains:

nameserver 192.168.0.200

and my laptop will proxy all dns requests based on it's own /etc/resolv.conf

'''note that we only run the dns proxy on the usb0 interface so that we don't break any other networking'''

=== Proxying with dnrd ===

The script is designed to use [http://dnrd.sourceforge.net/ dnrd] as the dns proxy. The [http://buildhost.automated.it/gta01 script] and a copy of [http://buildhost.automated.it/dnrd-2.20.3.tar.gz dnrd] are available from my site. The script also performs the initial setup of the connection as per the [[USB_Networking#Manual_method]] above.

=== Proxying with a UDP forwarder ===
Another easy setup is using a udp forwarder like the one from http://www.tapor.com/udpf/ - is use it with the command

udpf-elf\
-p=53\
-f=`cat /etc/resolv.conf|awk '$1 == "nameserver"{print $2; exit(0);}'`:53

=== Proxying with iptables ===
Its is possible to forward DNS requests with iptables using the DNAT target

iptables -t nat -A PREROUTING -p tcp -s 192.168.0.202 -d 192.168.0.200 --dport domain -j DNAT --to-destination 192.168.0.1
iptables -t nat -A PREROUTING -p udp -s 192.168.0.202 -d 192.168.0.200 --dport domain -j DNAT --to-destination 192.168.0.1

where <tt>192.168.0.1</tt> is the IP of your residential gateway (router). This is the easiest method, but its not recommended if you have a direct connection to the Internet as ISP DNS servers can change, and this does no load-balancing.

= Connecting to phone =

Then <tt>ssh root@192.168.0.202</tt> with empty password to get into phone.

NOTE: the ssh daemon (dropbear 0.49) on the OpenMoko appears to have a bug when sending the exit status back to the client. From time to time you receive an exit status of 255.

===SSH Extras===

If you get fed up with typing root@192.168.0.202, on your PC edit /etc/hosts and add an entry for 'phone'

192.168.0.202 phone

then edit ~/.ssh/config (or create it) and add

host phone
user root

then all you need to do is type

# ssh phone

To avoid ssh added a new line for every ssh host-key to you known_hosts you can add the following to the phone section in ~/.ssh/config

UserKnownHostsFile /dev/null

You might want to use keys to bypass the login prompt too.

===SSH Keys===
====From host to phone====

To generate ssh keys for use as a login mechanism type

ssh-keygen -t rsa

when prompted for a password either hit enter for no password (''not really a good idea'') or enter a password for this key. ssh into the phone and create ~/.ssh

# mkdir ~/.ssh

then from your PC copy the '''.pub''' file to the phone.

# scp ~/.ssh/id_rsa.pub phone:.ssh/authorized_keys

You should now be able to ssh directly into the phone.

To disable password logins ('''after setting up key access''') edit /etc/init.d/dropbear and change the following line:

DROPBEAR_EXTRA_ARGS=

to

DROPBEAR_EXTRA_ARGS="-s"

You will need to restart dropbear for this to take effect.

====From phone to host====
Generate the key

dropbearkey -t rsa -f id_rsa

The output will look something like this:

Will output 1024 bit rsa secret key to 'id_rsa'
Generating key, this may take a while...
Public key portion is:
ssh-rsa AAAAB3Nza[...]
Fingerprint: md5 ca:e8:f0:b7:f6:7b:c2:b6:b9:71:e4:45:86:a9:ff:b8

Copy and paste the one line (in this example, starting with 'ssh-rsa' onto the end of the host's authorized_keys file (often in ~/.ssh/).

From the phone, ssh with -i:

ssh -i id_rsa user@host

This works for me. I ripped off these instructions from: [[http://forum.openwrt.org/viewtopic.php?pid=53705]]

===GUI on desktop through SSH===

If you need to get the GUI on the phone onto the desktop via usb, you can use ssh as follows

ssh -l root -X -v 192.168.0.202

Login, and run openmoko-finger-demo for example, and it will open up on the desktop. To get landscape view, just resize the GUI window on the desktop.

===Remote apps on neo===

To get desktop apps to show up on your neo, first log in to the phone

ssh -l root 192.168.0.202

Then once inside, run:

DISPLAY=:0 xhost +192.168.0.200

After this you can close the ssh session. Back on the desktop computer, run:

DISPLAY=moko:0 xclock

Note that the xhost command will allow remote applications on 192.168.0.200 to access the X server. It will allow anyone on the desktop machine to access the X server of the neo, including snooping anything you type on it. To disallow remote applications again, run this in the neo:

DISPLAY=:0 xhost -192.168.0.200


{{Languages|USB Networking}}

[[Category:Hardware]]
[[Category:Implemented]]

Manually using Bluetooth

2008-01-20T01:49:52Z

Chooseopen: /* Being able to use HID devices */

{{InProgress}}
Bluetooth is one of the core functions of the Neo1973, however it is basically unimplemented on the software side at the moment.
Hardware problems in the P1 phone mean that the CPU has to be active in order to wake on external bluetooth events, which will reduce the battery life to some 2 days at best in standby.

This page details how to use bluetooth from the command line.
We have quite a lot of plans about what exactly Bluetooth should be used for.

== Power it up ==

Power up the adapter by clicking on the bluetooth icon in the top bar and selecting power on.

The old way to do it is a shell command:

root@fic-gta01:~$ echo "1" > /sys/bus/platform/devices/gta01-pm-bt.0/power_on

At the shell, "hciconfig" should print information about the adapter if it powered up properly:

hciconfig

The devices should show as UP. If not you can use

hciconfig <device> up

== Bluetooth Functions ==

===Configuring Bluetooth on OpenMoko 2007.2 (August 27 snapshot with kernel 2.6.21.6-moko11) ===

In file /etc/bluetooth/hcid.conf you should change the passkey from BlueZ to something numeric. For testing you may use "0000". Also, you can set the name to "Neo (%d)".

=== Scanning for bluetooth devices ===

hcitool scan

This will list the addresses of any discoverable bluetooth devices in the vicinity

=== passkey agent example ===

There should be a passkey agent built into openmoko, but for now you can start up the example passkey agent and set the pin code there. This will allow for new pairings to be made when you attempt a connection.

passkey-agent --default 0000 &

Note: the passkey-agent is not required in OpenMoko 2007.2 with kernel 2.6.21.6 as of at least since August 27 (maybe earlier).

=== HID (Human Input Device) ===

==== Being able to use HID devices ====

We want to be able to use a bluetooth keyboard to type into the various applications of our Neo1973.
To use a Bluetooth Keyboard type: (11:22:33:44:55:66 is the Address of your BT-Keyboard)

hidd --connect 11:22:33:44:55:66

and press "Connect" on your BT-KB. Alternately, if you know that only one BT-Keyboard is within range, you can just:

hidd --search

to find and connect to any BT-Keyboard.

Tested on:
* [http://www.logitech.com/index.cfm/products/details/US/EN,CRID=2166,CONTENTID=10717 Logitech Dinovo Edge]
* [http://www.logitech.com/index.cfm/keyboards/keyboard_mice_combos/devices/164&cl=us,en Logitech Dinovo Media Desktop (keyboard)]
* [http://www.nokia.es/A4181580 Nokia SU-8W]. Switched on the BT keyboard, scanned for BT address and ran the connect statement above. Works fine.
* [http://blog.russnelson.com/chordite Chordite]. This keyboard uses the Broadcom BCM2042 BT keyboard controller along with a custom driver.
* [http://www.apple.com/keyboard/ Apple's Aluminum Keyboard]. You may have to add 'auth enable; encrypt enable;' to device {} in hcid.conf. Run the passkey agent the first time. --search works to pair and every time after.
* The freedom keyboard from freedominput.com and its many rebranded models (they look like this: [http://rabenfrost.net/openmoko/keyboard.jpg]) need 'modprobe uinput' to circumvent the 'Can't open input device: No such file or directory (2)' error of 'hidd --search' but it still not works on openmoko but on my ubuntu box - maybe another kernel module is missing?

==== Acting as HID device ====

We want to be able to use the Neo1973 as a HID device, being able to use it as controller for presentations.

=== RFCOMM ===

Here's how to connect to an external Bluetooth GPS and read NMEA data (Tested with a Holux GPSSlim236 and a Nokia LD-3W ).

First, switch on the GPS and identify the BT address:

hcitool scan

Then, edit /etc/bluetooth/rfcomm.conf, which by default has all settings commented out, to something like this:

rfcomm0 {
# Automatically bind the device at startup
bind no;
# Bluetooth address of the device
device 00:11:22:33:44:55;
# RFCOMM channel for the connection (check your GPS docs for details)
channel 1;
# Description of the connection
comment "Bluetooth GPS";
}

Restart the BT services:

root@neo:~$ /etc/init.d/bluetooth stop
root@neo:~$ /etc/init.d/bluetooth start

You should now be able to bind the GPS to /dev/rfcomm0, like this:

root@neo:~$ rfcomm bind 0

Confirm the connect:

root@neo:~$ rfcomm
rfcomm0: 00:11:22:33:44:55 channel 1 clean

... and watch the NMEA strings coming from your GPS:

root@neo:~$ cat /dev/rfcomm0
$GPGGA,111748.000,5907.6964,N,01121.1787,E,1,06,1.2,57.7,M,40.1,M,,0000*6F
$GPRMC,111748.000,A,5907.6964,N,01121.1787,E,0.00,94.94,160807,,,A*50
$GPVTG,94.94,T,,M,0.00,N,0.0,K,A*3D

If you have nothing better to do, you can now pinpoint my office :-).

=== OBEX ===

=== Networking ===

=== Bluetooth networking with a Linux system ===

Bluetooth should behave just like our usbnet and provide full TCP/IP access to the phone. BNEP has to be used.

On the laptop

* Start bluetooth
elara /home/alphaone # /etc/init.d/bluetooth start

* Start pand as server
elara /home/alphaone # pand -s

* As soon as pand is started on the phone configure your IP address
elara /home/alphaone # ip a add 10.0.0.1/24 dev bnep0
elara /home/alphaone # ip l set bnep0 up

* Configure IP forwarding and masquerading to your liking (see [[USB_Networking]]). You can even set up Udev rules to do this for you once the bnep0 interface appears.

On the Neo

* Power on bluetooth (see above)

* Scan for the laptop
root@fic-gta01:~$ hcitool scan
Scanning ...
00:0E:6D:C0:0l:6A Sho
00:20:E0:5A:FE:C8 BlueZ (0)

* Connect to the laptop pand
root@fic-gta01:~$ pand -c 00:20:E0:5A:FE:C8

* Configure your IP address
ip a add 10.0.0.2/24 dev bnep0
ip r add default via 10.0.0.1

* Enjoy

=== Bluetooth networking with a MacOS X system ===

Please refer to [[MacOS_X#Bluetooth_2]]

=== Bluetooth networking with a Windows XP system ===

This was tested with a Windows XP SP2 on a IBM Thinkpad T41 with the Widcomm BT stack

* Start bluetooth on Windows XP

* Enable "Network Access" in the Bluetooth configuration

* Scan for the Neo and pair with the Neo (right click, select pair)

On the Neo

* Enable PAN support on the Neo by changing Autostart from false to true in /etc/bluetooth/network.service

* Power on bluetooth (see above)

* Scan for the laptop
root@fic-gta01:~$ hcitool scan
Scanning ...
<laptop_bt_address> Thinkpad
...

* Connect to the laptop pand
pand -c <laptop_bt_address> -r PANU -d NAP -e bnep0 -A -E -S
(add '-n' to see the pand status messages until you get it right)

For some reason, I was not able to initiate PAN connections from the Neo, I got 'Permission denied (13)' even when I had explicitly allowed the Neo to connect (right click on Neo icon, set properties, on Authorization tab). But initiating 'PAN User' from Windows worked when executing on Neo:
pand -l -r PANU -d NAP -e bnep0 -A -E -S
(add '-n' to see the pand status messages until you get it right)

* Configure your IP address. It should work like when connecting to Linux:
ip a add 10.0.0.2/24 dev bnep0
ip r add default via 10.0.0.1
If this does not work, the IP stacks may have auto-assigned network addresses to themselves. You can look this up with 'ifconfig' on the Neo and with 'ipconfig' on Windows.

* You should now be able to ssh/putty from Windows to your Neo. Enjoy!
By setting up the Windows Bluetooth connection properly, it should also be possible to share the Internet Connection of the Windows box with the Neo.

=== PPP Networking ===

If you are unable to use the 'BNEP' method described above, you may be able to use [[PPP]] and a DUN (dialup-networking) emulation mode. On the Neo:

* Edit the /etc/default/bluetooth file and set the following options:
RFCOMM_ENABLE=true
DUND_ENABLE=true
DUND_OPTIONS="--listen --persist call dun"

* Create an /etc/ppp/peers/dun file with options like the following:
115200
192.168.2.202:192.168.2.200
passive
local
noipdefault
noauth
nodefaultroute

* Restart bluetooth (/etc/init.d/bluetooth stop ; /etc/init.d/bluetooth start)

To connect from a MacOS 10.3 client:

* Open "Applications/Utilities/Bluetooth Serial Utility"

* Click on "New"

* Choose a name, then click "Choose Device"

* Locate your Neo, then select the "LAN Access Point" service. If your device is not found, or if this service does not show up, then you will need to troubleshoot and fix that before continuing. Bluetooth is designed for short-range communication, so make sure that the devices are physically close to each other.

* Select "Port type: RS-232" and "Show in Network Preferences". Click OK.

* Open the Network Preferences page then "Show: Network Port Configurations". Enable the new device that you defined in the previous step and drag it to the bottom of the device list (so that it will not interfere with your other network connections)

* Choose "Show: <your-device-name>", then click "Modem"

* Select "Null Modem 115200" from the list of available devices. Uncheck "Wait for dial tone" and "Enable error correction and compression in modem". Optionally check "Show modem status in menu bar".

* Click "Connect". If everything worked, you will end up with a 'ppp0' device on your Mac with a local address of 192.168.2.200 and you will be able to access your Neo at 192.168.2.202.

=== A2DP quickie ===

It's now possible (if a little hackish) to stream mp3 to a bluetooth headset. It's a known problem that the playback rate changes (pitch varies). Timing issues are also likely the reason for gaps in playback.

If the bluez packages are recent enough, you can use a shortcut. I'll document it here and leave the longer version below (the long version also demonstrates the API used by the GUI to manage headsets)

Create /etc/asound.conf with your bluetooth headset's address filled in:

pcm.!default {
type bluetooth
device "xx:xx:xx:xx:xx:xx"
}

then play a song

madplay /media/card/song.mp3 --sample-rate=44100 --output=wave:- | aplay

or for smoother results...

madplay /media/card/song.mp3 --sample-rate=44100 --output=wave:song.wav
aplay song.wav

=== A2DP ===

If that doesn't work... all the more hackish... install required packages:

echo "src/gz python http://www.angstrom-distribution.org/unstable/feed/armv4t/python/" >> /etc/ipkg/angstrom-python.conf
echo "src/gz base http://www.angstrom-distribution.org/unstable/feed/armv4t/base/" >> /etc/ipkg/angstrom-base.conf
ipkg update ; ipkg install python-core python-xml python-dbus bluez-utils bluez-utils-alsa

Create /etc/asound.conf:

pcm.!default {
type bluetooth
}
ctl.!default {
type bluetooth
}
pcm.bluetooth {
type bluetooth
}
ctl.bluetooth {
type bluetooth
}

Run the passkey agent (see above in this page)

Fill in your bluetooth headset address below and execute the python script (with your headset turned on)

#!/usr/bin/python
import dbus
bus = dbus.SystemBus()
manager = dbus.Interface(bus.get_object('org.bluez', '/org/bluez'), 'org.bluez.Manager')
conn = manager.ActivateService('audio')
audio = dbus.Interface(bus.get_object(conn, '/org/bluez/audio'), 'org.bluez.audio.Manager')
path = audio.CreateDevice('00:0D:3C:44:33:22')
audio.ChangeDefaultDevice(path)
sink = dbus.Interface(bus.get_object(conn, path), 'org.bluez.audio.Sink')
sink.Connect()

FINALLY: play a song

madplay /media/card/song.mp3 --sample-rate=44100 --output=wave:- | aplay

=== Headset Audio ===

[[Neo1973_Audio_Subsystem]] has detail about alsa settings and a proposal for audio scenario management.

To try this out, follow the instructions in the a2dp section to install software and run the passkey agent.

Remove or disable the stuff you put in asound.conf. When using a voice headset, the application uses the regular system audio device and it gets routed to bluetooth in the codec.

Put the headset in pairing mode. Replace the bluetooth address below with your headset's and run the python script:

#!/usr/bin/python
import dbus
bus = dbus.SystemBus()
manager = dbus.Interface(bus.get_object('org.bluez', '/org/bluez'), 'org.bluez.Manager')
conn = manager.ActivateService('audio')
audio = dbus.Interface(bus.get_object(conn, '/org/bluez/audio'), 'org.bluez.audio.Manager')
path = audio.CreateHeadset('00:0B:2E:39:33:22')
audio.ChangeDefaultHeadset(path)
headset = dbus.Interface (bus.get_object(conn, path), 'org.bluez.audio.Headset')
headset.Connect()
headset.Play()

Now place a call and try to route it to bluetooth (after it's in progress):

alsactl -f /etc/gsmbluetooth.state restore

You may also be able to listen to system audio given the right state file:

alsactl -f /etc/systembluetooth.state restore
madplay song.mp3

=== Bluetooth networking with a Linux system - More secure way ===

''Check this, probably needs some corrections''

Bluetooth should behave just like our usbnet and provide full TCP/IP access to the phone. BNEP has to be used.

On the laptop

* check these options in /etc/bluetooth/hcid.conf
security auto;
passkey "your pin";
lm master;

* Start bluetooth
# /etc/init.d/bluetooth start

* Start pand as server
pand --listen --role NAP --encrypt

* Add in /etc/network/interfaces (see [[USB_Networking]])
auto bnep0
iface bnep0 inet static
address 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0
post-up iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.1.0/24
post-up echo 1 > /proc/sys/net/ipv4/ip_forward
post-up iptables -P FORWARD ACCEPT

On the Neo

* Power on bluetooth (see above)

* Scan for the laptop
root@fic-gta01:~$ hcitool scan
Scanning ...
00:20:E0:5A:FE:C8 laptop

* Set pin
root@fic-gta01:~$ passkey-agent 'your pin' 00:20:E0:5A:FE:C8 &

* Connect to the laptop pand
root@fic-gta01:~$ pand -c 00:20:E0:5A:FE:C8

* Configure your IP address
root@fic-gta01:~$ ifconfig bnep0 192.168.1.2
root@fic-gta01:~$ route add default gateway 192.168.1.1

* Enjoy

== Further reading ==

http://www.holtmann.org/papers/bluetooth/ols2006_slides.pdf
http://wiki.bluez.org/wiki/Audio#org.bluez.Audio

{{Languages|Manually_using_Bluetooth}}
[[Category:Neo1973 Hardware]]
[[Bluetooth]]

Users Repositories

2007-10-11T00:28:38Z

Chooseopen: /* Repositories */

=== Repositories ===
here you can find prebuilt kernels and root file systems.

* official downloads
::http://buildhost.openmoko.org/OM2007.1/tmp/deploy/images/?C=M;O=D
::http://buildhost.openmoko.org/OM2007.2/tmp/deploy/glibc/images/fic-gta01/?C=M;O=D
:* the 2007.08 snapshot, as announced by Sean on August 19
:::http://buildhost.openmoko.org/snapshots/2007.08/images/
* [[User:ChooseOpen|ChooseOpen]] unofficial builds:
::http://chooseopen.com:81/openmoko/build/2007.1/?M=D
::http://chooseopen.com:81/openmoko/build/2007.2/?M=D
::http://chooseopen.com:81/openmoko/build/qtopia/?M=D (Qtopia)
* [[User:ScaredyCat|ScaredyCat]] unofficial builds:
::http://buildhost.automated.it/OM2007.1/?M=D
::http://buildhost.automated.it/OM2007.2/?M=D

::ScaredyCat also has a ipkg repository for 2007.2 where e.g. gpe-filemanager and a lot more (e.g. ntpd) can be installed from. On the Neo do:

cd /etc/ipkg
wget http://buildhost.automated.it/OM2007.2/packages/scaredycat.conf
ipkg update
ipkg install gpe-filemanager
ipkg install gpe-timesheet
ipkg install gpe-todo
ipkg install mysql
ipkg install mtpaint
ipkg install sqlite
ipkg install ntp
#(you get the idea)
/etc/init.d/xserver-nodm restart # to make the new applications appear in the menu

* - (2007.2)
::http://ipkg.nslu2-linux.org/feeds/openmoko/images/?C=M;O=D
* - (2007.2)
::http://www.totalueberwachung.de/~alphaone/openmoko-build/glibc/images/fic-gta01/?C=M;O=D
* - (2007.2)
::http://celtune.morb-design.com/images/fic-gta01/?C=M;O=D
::http://celtune.morb-design.com/ipk/
::Celtune offers Standard-Builds (.jffs2, .tar, .bin, .ipk)

cd /etc/ipkg && wget http://celtune.morb-design.com/celtune.conf

If you want to add a link, it would be nice to enforce a standard format of these feeds so that they can be browsed automatically.

Neo 1973 audio subsystem

2007-07-28T04:05:08Z

Chooseopen: /* Phase0 Quick Start */ Streaming Radio

=== Phase0 Quick Start ===

In my experience this works but what comes out is not stereo and it comes out the speaker and headphones.

alsactl -f /etc/alsa/stereoout.state restore
madplay myfavoritesong.mp3

Another simple test (assuming you have USB networking configured) is to listen to a radio stream:

wget -O - http://radioparadise.steadyhost.com:8050 | madplay -

If for some reason you're missing stereoout.state, try getting a similar copy (a couple of volume levels are different is all)

wget http://opensource.wolfsonmicro.com/~gg/neo1973/stereoout.state

=== Voice Calls ===

neo uses http://wolfson.co.uk/products/WM8753/ , picture of its internal signal routing is at http://wolfson.co.uk/uploads/images/en//WM8753_BlockDiagram.gif .

==== using phone-internal microphone and speaker ====

This is the default case.

* microphone path
** input: built in microphone attached to wolfson MIC2/MIC2N
** routed from wolfson MIC2/MIC2N to MONO1/MONO2
** arrives at GSM Modem input MICIP/MICIN
* speaker path
** input: GSM Modem attached to wolfson RXN/RXP
** routed from wolfson RXN/RXP to ROUT1/LOUT1
** arrives on LM4857 RIN/LIN
** routed on LM4856 to EP+/EP-

===== Internal Codec Route =====

Neo Mode is GSM Handset
Amp Mode is Call Speaker

* audio path Mic -> GSM
** MIC2/MIC2N
** Mic2 Volume
** ALC Micer Mic2
** Left PGA
** Mic Sidetone Mux [Left PGA]
** Mono Sidetone Volume
** Mono Mixer Sidetone Playback Switch
** Mono Volume
** Mono 2 Mux [Inverted Mono 1]

* audio path GSM -> Speaker
** RXP/RXN
** Rx Mixer [RXP - RXN]
** Line Left Mux [Rx Mix]/Line Right Mux [Rx Mix]
** Left Mixer Bypass Playback Switch/Right Mixer Bypass Playback Switch
** Headphone Volume

===== Driver Status =====

This should be supported by ASoC 0.13rc3 (-moko7 kernel) on.

ASoC 0.13.3 should have same functionality but has renamed the soundcard to neo1973.

===== asound.state =====

https://people.openmoko.org/laforge/gta01/gta01b_v2/alsa/gsmhandset.state

For ASoC 0.13.3 http://opensource.wolfsonmicro.com/~gg/neo1973/gsmhandset.state

==== using analog (4pin 2.5mm) headset ====

This is also a quite common case, since we ship the headset with the
phone

Headset Detection is done via GPIO on S3C2410

* microphone path
** input: headset mic vial HS_MIC attached to wolfson MIC1
** routed from wolfson MIC1 to MONO1/MONO2
** arrives at GSM Modem input MICIP/MICIN
* speaker path
** input: GSM Modem attached to wolfson RXN/RXP
** routed from wolfson RXN/RXP to ROUT1/LOUT1
** arrives on LM4857 RIN/LIN
** routed on LM4856 to LHP/RHP

===== Internal Codec Route =====

Neo Mode is GSM Headset
Amp Mode is Headphones

* audio path Mic -> GSM
** MIC1
** Mic Selection Mux [Mic 1]
** ALC Mixer Mic1
** Left PGA
** Mic Sidetone Mux [Left PGA]
** Mono Sidetone Volume
** Mono Mixer Sidetone Playback Switch
** Mono Volume
** Mono 2 Mux [Inverted Mono 1]

* Audio path GSM -> Headphones
** RXP/RXN
** Rx Mixer [RXP - RXN]
** Line Left Mux [Rx Mix]/Line Right Mux [Rx Mix]
** Left Mixer Bypass Playback Switch/Right Mixer Bypass Playback Switch
** Headphone Volume

===== Driver Status =====

Supported in ASoC 0.13.3

===== asound.state =====

http://opensource.wolfsonmicro.com/~gg/neo1973/gsmheadset.state

==== using Bluetooth headset with GSM ====

Headset detection via software

* microphone path
** input: from bluetooth via PCM interface to wolfson
** wolfson: DAC
** wolfson routes analog signal to MONO1/MONO2
** arrives at GSM Modem input MICIP/MICIN
* speaker path
** input: GSM Modem attached to wolfson RXN/RXP
** wolfson: ADC
** wolfson: routes digital signal to PCM
** arrives on bluetooth chip via PCM

===== Internal Codec Route =====

Neo Mode is GSM Bluetooth
Amp Mode is Off

* audio path BT -> GSM
** Vx DAC
** Mono Voice Volume
** Mono Mixer Voice Playback Switch
** Mono Volume
** Mono 2 Mux [Inverted Mono 1]

* audio path GSM -> BT
** RXP/RXN
** Rx Mixer [RXP - RXN]
** ALC Mixer Rx
** Left PGA
** Capture Mixer Mux [PGA]
** Capture Left Mixer [Analogue Mix Left]
** Left ADC

===== Driver Status =====

Should be support by ASoC 0.13.3

Example of how to setup PCM->BT link.

http://opensource.wolfsonmicro.com/~gg/bluetooth-pcm/bluetooth_pcm.c

===== asound.state =====

http://opensource.wolfsonmicro.com/~gg/neo1973/gsmbluetooth.state

==== using Bluetooth headset with system audio ====

For example, using a voip app on the phone with a bt voice headset. This would also be a good way to work on the bluetooth driver without requiring a working GSM and placing a lot of calls.

See ticket 583 for a state file that should route system audio *out* to the headset. The codec does not allow for duplex system audio connected to a headset, so audio in is still using the mic.

=== Multimedia ===

==== sound playback to speakers ====

This is an important mode since it is also required for ringtone
playback

* speaker path
** input: from S3C2410 via IIS interface to wolfson
** wolfson: DAC
** wolfson: route to ROUT1/LOUT1
** LM4857: arrives on RIN/LIN
** LM4857: route to LLS+-/RLS+-

===== Driver Status =====

This is working since ASoC 0.13rc2 (-moko6 kernel)

This should also work on ASoC 0.13.3

===== asound.state =====

https://people.openmoko.org/laforge/gta01/gta01b_v2/alsa/stereoout.state

For ASoC 0.13.3 http://opensource.wolfsonmicro.com/~gg/neo1973/stereoout.state

==== sound playback to headphone ====

* speaker path
** input: from S3C2410 via IIS interface to wolfson
** wolfson: DAC
** wolfson: route to ROUT1/LOUT1
** LM4857: arrives on RIN/LIN
** routed on LM4856 to LHP/RHP

===== Driver Status =====

This is working since ASoC 0.13rc2 (-moko6 kernel)

==== sound playback via A2DP ====

One way to do this is to use a pulse plugin for bluetooth audio. Pulse would be routed either to the plugin or the default route to the codec. The plugin would watch for headset connect/disconnect events generated by a bluez audio daemon to keep the list of available output devices current.

===== Driver Status =====

There is early work on the bluez daemon to handle this. It has been combined with an alsa plugin in the bluez tree but the alsa plugin probably will not be sufficient for neo.

==== voice recording ====

This is mainly used to record notes

* microphone path
** can be from built-in mic
** or from headset
** or bluetooth headset

===== Driver Status =====

UNKNOWN

=== Call recording ===

This is a nice wishlist item. The user should be able to receive the
full-duplex audio from the wolfson codec, and record it using the
S3C2410 IIS.

==== recording ====

FIXME
===== Driver Status =====

UNKNOWN
==== playback ====

FIXME
===== Driver Status =====

UNKNOWN

== Userspace Sound Control Daemon ==

The userspace sound control deamon might be a separate process or (more likely) part of some larger general hardware management daemon.

It will provide the following features:

=== audio playback ===

In order to provide the desired functionality, the daemon first needs to be capable of doing audio playback.

* supported formats
** mp3 (libmad)
** ogg/vorbis (libtremor)
** mod (mikmod)
** sid (sidplay)
* supported functionality
** start and stop playback
** interrupt previous sound to play new sound
** enqueue new sound at end of previous sound
** smooth fade-in/fade-out

=== audio event management ===
* manage a set of events (basically just a name for each event)
* manage a set of audio themes
** each theme contains list of event->audio_file_name mappings
** themes stored/managed via gconf
* manage event sources
** built-in event sources, e.g. touchscreen/button press
** external event sources (e.g. gsmd, dbus, ...)

=== audio scenario management ===
* e.g. dialer or even gsmd can request audio subsystem to switch to voicecall mode
* this mainly affects codec/amplifier analog audio routing
* integrated with bluetooth in case of BT headset or A2DP use
* How is this management performed currently?

== Important issues/pitfalls ==

=== Ringtone while headset playback ===

If the user is listening to music on the headset, do we want to mix the
ring tones only into the headset audio, or actually interrupt and play it
on the speaker?

[[Category:Neo1973 Hardware]]

User:ChooseOpen

2007-07-26T16:46:41Z

Chooseopen:

[[Image:Gollum-OpenMoko.jpg]]

Openmoko Local Groups: Chicago

2007-07-26T15:31:41Z

Chooseopen: Added myself

Welcome to the Chicago Openmoko page!

This group is for anyone in Chicago and surrounding areas. Hopefully we'll be able to organize an event for when a few of us get the Neo1973s.

[[Category:Community]]

*Jason Elwell [ChooseOpen] - jason *at*chooseopen.com

Getting Started with your Neo 1973

2007-07-26T04:58:43Z

Chooseopen: /* Hardware */ Need to re-flash

Some first steps guide for those who have just received their first Neo1973 hardware

== Hardware ==

=== Inserting the battery ===

See [[Disassembling Neo1973]].

=== Powering up the phone ===
[[Image:Neo1973_uboot_splash.jpg|200px|thumb|bootloader splash screen]]
Just hitting the power button (depending on your [[u-boot]] version you have to press for >= 5 seconds) should get the phone first into the bootloader, then boot the kernel, and get into X/OpenMoko.

Once you have pressed the power button sufficiently long, the vibrator makes a short pulse and the screen backlight turns on. You can now release the power button and watch the phone booting.

If the battery is not sufficiently charged, the phone will not turn on, even if the usb cable is plugged in.

=== Flashing the Neo1973 GTA01v4 ===
The GTA01v4 devices that are currently shipping do not boot out of the box. Flashing the phone with the latest kernel and supporting file system ("rootfs") is required before the phone will successfully boot.

Read more information at about [[Flashing openmoko]].

=== Powering down the phone ===

==== While in bootloader mode, or if the phone has crashed ====

If you press the power button for 9 seconds, the phone will switch off. You can notice this by the backlight going dark.

==== While running a full linux system with userspace ====

In this mode, a power-button press of 5 seconds will be sufficient. After this, the init process will take care of safely shutting down the phone, which might take up to 20 extra seconds. The X server should get killed, you should drop back to a (garbled) console, and it should finally switch off - much like a regular Linux PC.

=== Battery charging ===

The [[Neo1973]] supports two charging modes: One 100mA charge mode (called pre-charge) and 500mA (called fast charge). Charging is always done via the USB socket. You can use any USB-A to USB-mini-B cable to connect the phone to any USB host.

==== While in u-boot ====

While you are in u-boot mode, the phone only charges with 100mA by default. (This will change in one of the future revisions).

However, using the u-boot console you can manually enable fast charging. See [[U-boot#Battery_charger_related]] for more information.

==== While in Linux ====

As soon as the phone is connected via USB cable, it will charge. However, the default charging current is only 100mA, way too little if you want to operate the phone and charge at the same time.

If your USB upstream port is capable of supplying 500mA, then it will configure the Neo1973 accordingly and use 500mA charging mode. You can notice this by the following line in the kernel log
usb0: full speed config #1: 500 mA, Ethernet Gadget, using CDC Ethernet

=== Inserting the SIM card (optional) ===

The slot is found just under the battery. The card holder has arrows indicating which way to push it to unlock it - make sure you don't open it with force when it's locked or it may break. Insert the SIM so that the pads make contact and push the holder firmly until it makes a click, then lock it - otherwise the card will not be detected.

To check if the SIM card is inserted correctly in Linux, you can have a look in gsmd logs or use the instructions detailed in the [[Manually using GSM]] page and issue the ''AT+CIMI'' command.

== Getting shell access on the phone ==

=== By using the terminal emulator and on-screen keyboard ===

"Click" (using a stylus) the top-left arrow icon to get a drop-down menu with "Media", "Settings", "Utilities" and "Desktop". Choose "Utilities->Panel->Input Manager", and a keyboard icon will appear on the top bar. You can get an on-screen keyboard at any time by choosing it.

With newer images, the keyboard comes up when you tap the white box in the top bar.

From the desktop, choose "Active tasks->rxvt" to get a root shell.

Terminal is in the top level menu in recent images.

=== By using Ethernet emulation over a USB cable ===

The standard Neo1973 Linux [[kernel]] has support for the "cdc_ether USB gadget", i.e. a standard implementation of how to emulate an Ethernet device over USB.

As soon as the kernel is up and running, and you have the phone connected via USB, you should get a '''usb0''' device on your host.

The Phone will have the IPv4 address 192.168.0.202/24. You can run `ifconfig` in the terminal on the phone to verify this (this is optional, just check it if it doesn't work given the instructions below)

If you plug a USB cable into a laptop running Linux, you'll likely see the "cdc_ether" kernel module being loaded and a usb0 network interface appear.

On the '''host PC''', you should then configure your interface to 192.168.0.200 by using
# ifconfig usb0 192.168.0.200 netmask 255.255.255.0

Then you should be able to
# ping 192.168.0.202

and last, but not least
# ssh root@192.168.0.202

Once you press 'enter' (empty password), you should now have a root login.

See [[USB_Networking]] for more details, including instructions on how to automatically setup masquerading so that your phone can get access to the internet through the host PC.

=== By using the debug board/serial/JTAG ===

Please see [[Debug Board#Usage_Instructions]]

== Getting access to the bootloader console ==

Please see [[u-boot#Using_usbtty_from_Linux]]

== Useful commands in Linux ==

=== Suspending ===

Writing "mem" into ''/sys/power/state'' tells Linux to suspend - it will enter a low power mode where only the GSM and RAM are powered up and the CPU sleeps. It will persist in this state until a wake-up event arrives. Some currently enabled wake-up events are: AUX or POWER key press, USB cable detect.

If you're connected over ssh, sshd will stop responding when the OS suspends, so to avoid locking up your ssh client, use the command
# (sleep 1; echo mem > /sys/power/state) & exit

=== Initial backup ===

After getting your new Neo1973 booted for the first time you might want to make a back up of the original flash chip contents on your PC, before you overwrite the flash with a custom image or just update to a newer build. This is a good idea because there are parts in the root filesystem that can't be distributed over internet so they are only found in the shipped ROM (see the [[GPS]] driver). One easy way to back up all of the Flash, that doesn't require installing any special software, is with ''netcat'' over the [[USB Networking|USB ethernet]]. The following commands can be used for that.
{|
! On the host !! On the target
|-
|<pre>
$ netcat -l -p 20000 > mtdblock0
$ netcat -l -p 20000 > mtdblock1
$ netcat -l -p 20000 > mtdblock2
$ netcat -l -p 20000 > mtdblock3
$ netcat -l -p 20000 > mtdblock4
</pre>
|<pre>
# cat /dev/mtdblock0 | nc 192.168.0.200 20000
# cat /dev/mtdblock1 | nc 192.168.0.200 20000
# cat /dev/mtdblock2 | nc 192.168.0.200 20000
# cat /dev/mtdblock3 | nc 192.168.0.200 20000
# cat /dev/mtdblock4 | nc 192.168.0.200 20000
</pre>
|}

This stores the five NAND partitions in files named mtdblock*. Knowing the partition layout (u-boot "mtdparts" command or Linux dmesg) you can restore the whole flash with it.

=== Where to from here ===

You'll probably want to play with some of the interesting hardware in this device. Obviously, you can explore the applications available through the touch-screen interface. But for those who prefer doing things more in the raw from a shell prompt, you can [[Manually_using_GSM | manually use GSM]] or you can start playing with the [[GPS]].

{{Languages|Getting_Started_with_your_Neo1973}}

[[Category:Documentation]]
[[Category:Neo1973_Phase_1_related]]

Flashing the Neo 1973

2007-07-26T02:19:58Z

Chooseopen: /* Putting the device into DFU mode */ Updated for GTA01BV4

This describes how to update your openmoko to the latest software. We'll update the kernel, the root filesystem and optionally u-boot (new uboot is only recommended for Phase0 phones, because otherwise you get kernel crashes later; you should probably not flash uboot on a Phase 1 phone without a very good reason).

== Files to download ==

Necessary files are at:
*http://buildhost.openmoko.org/tmp/deploy/images/

*http://chooseopen.com/openmoko/build/ (Unofficial, temporary location of more current builds.)

Get:
* [[dfu-util]] (the precompiled binary on http://buildhost.openmoko.org is for Linux/i386)
* openmoko-devel-image-fic-gta01-2007********.rootfs.jffs2
* uImage-2.6.21.*-moko10-r*_0_****_0-fic-gta01.bin
* for phase 0 (Bv03) phones:
** Tested by a few people: u-boot-gta01bv3-r8_70124c2602ae2d4c5d3dba05b482d91548242de8_0_2040.bin MD5SUM: 60c5aeba1bd6642b05b3a5e6f2dafe83
** Tested by hrw: u-boot-gta01bv3-r8_70124c2602ae2d4c5d3dba05b482d91548242de8_0_2062.bin MD5SUM: 716f1eba9b0f2be4a0a3be4a56724935
* for phase 1 phones, uboot update should not be necessary.

== Putting the device into DFU mode ==

You'll need to boot your openmoko into uboot menu. To do this:

*Unplug all usb devices from the host.
*Hold AUX button while pressing POWER button.
*The uboot menu should appear.
*Plug Neo1973 into host with supplied USB cable. (Plug the phone directly into the host not via a hub.)

Note: Some devices have been reported to turn off after a short period of inactivity while on the uboot menu. To avoid this, simply press the AUX button every 30 seconds or so.

== Actually flashing things into the device ==

Double check that u-boot matches your hardware version. Flashing u-boot is really a critical part. You probably only want to do that on phase0 phones.

To update u-boot:

Warning: Do not update u-boot unless you have debug board or are really sure about what you are doing. Flashing wrong u-boot image will brick your device! Note especially that image below is for GTA01B_v03, not GTA01B_v04

./dfu-util -a 1 -R -D u-boot-gta01bv3-r8_70124c2602ae2d4c5d3dba05b482d91548242de8_0_2040.bin

To update the kernel:
./dfu-util -a 3 -R -D ./uImage-2.6.21.1-moko10-r0_0_1883_0-fic-gta01.bin

To update the root filesystem:
./dfu-util -a 5 -R -D ./openmoko-devel-image-fic-gta01-20070501054014.rootfs.jffs2

...now, you'll end up with system that boots, but does not see audio/SD card. You'll need to download corresponding modules.tgz and copy them over to openmoko. - UPDATE: GTA01 phones appear to not need this step.

Old versions of uboot are buggy: You may have to press the aux button few times so that machine does not sleep while flashing. It also does not erase rootfs before flashing it... to do that, do minicom /dev/ttyACM0, then nand erase clean rootfs . Unfortunately, old versions of uboot are not really usable, because they fail to enable high 64MB of RAM, and you get nasty crashes after kernel boots.

Good luck!

== Troubleshooting notes ==

If you're facing errors in seemingly random places during the flashing of images, most likely the USB hub or cable through which your Neo1973 is connected, is of too poor quality. It is recommended that you always connect the phone directly to the host when using dfu-util.

If dfu-util reports a message like the following, before it starts flashing:<pre>
Resetting USB...
not at least 2 device changes found ?!?
Lost device after RESET?</pre> just retry the command - it should work on a second run.

See other notes on [[Dfu-util]] page.

[[Category:Platform| ]]

Flashing the Neo 1973

2007-07-26T02:11:40Z

Chooseopen: /* Files to download */ Updated for GTA01BV4

This describes how to update your openmoko to the latest software. We'll update the kernel, the root filesystem and optionally u-boot (new uboot is only recommended for Phase0 phones, because otherwise you get kernel crashes later; you should probably not flash uboot on a Phase 1 phone without a very good reason).

== Files to download ==

Necessary files are at:
*http://buildhost.openmoko.org/tmp/deploy/images/

*http://chooseopen.com/openmoko/build/ (Unofficial, temporary location of more current builds.)

Get:
* [[dfu-util]] (the precompiled binary on http://buildhost.openmoko.org is for Linux/i386)
* openmoko-devel-image-fic-gta01-2007********.rootfs.jffs2
* uImage-2.6.21.*-moko10-r*_0_****_0-fic-gta01.bin
* for phase 0 (Bv03) phones:
** Tested by a few people: u-boot-gta01bv3-r8_70124c2602ae2d4c5d3dba05b482d91548242de8_0_2040.bin MD5SUM: 60c5aeba1bd6642b05b3a5e6f2dafe83
** Tested by hrw: u-boot-gta01bv3-r8_70124c2602ae2d4c5d3dba05b482d91548242de8_0_2062.bin MD5SUM: 716f1eba9b0f2be4a0a3be4a56724935
* for phase 1 phones, uboot update should not be necessary.

== Putting the device into DFU mode ==

You'll need to boot your openmoko into uboot menu (hold AUX button while pressing power button). Unplug all other usb devices from the host. Plug the phone directly into the host not via a hub.

It also seems that once you've booted your openmoko into the uboot menu, you then should plug it into the USB port. It should show a status message when you do so in terms of "Switching to DFU mode".

== Actually flashing things into the device ==

Double check that u-boot matches your hardware version. Flashing u-boot is really a critical part. You probably only want to do that on phase0 phones.

To update u-boot:

Warning: Do not update u-boot unless you have debug board or are really sure about what you are doing. Flashing wrong u-boot image will brick your device! Note especially that image below is for GTA01B_v03, not GTA01B_v04

./dfu-util -a 1 -R -D u-boot-gta01bv3-r8_70124c2602ae2d4c5d3dba05b482d91548242de8_0_2040.bin

To update the kernel:
./dfu-util -a 3 -R -D ./uImage-2.6.21.1-moko10-r0_0_1883_0-fic-gta01.bin

To update the root filesystem:
./dfu-util -a 5 -R -D ./openmoko-devel-image-fic-gta01-20070501054014.rootfs.jffs2

...now, you'll end up with system that boots, but does not see audio/SD card. You'll need to download corresponding modules.tgz and copy them over to openmoko. - UPDATE: GTA01 phones appear to not need this step.

Old versions of uboot are buggy: You may have to press the aux button few times so that machine does not sleep while flashing. It also does not erase rootfs before flashing it... to do that, do minicom /dev/ttyACM0, then nand erase clean rootfs . Unfortunately, old versions of uboot are not really usable, because they fail to enable high 64MB of RAM, and you get nasty crashes after kernel boots.

Good luck!

== Troubleshooting notes ==

If you're facing errors in seemingly random places during the flashing of images, most likely the USB hub or cable through which your Neo1973 is connected, is of too poor quality. It is recommended that you always connect the phone directly to the host when using dfu-util.

If dfu-util reports a message like the following, before it starts flashing:<pre>
Resetting USB...
not at least 2 device changes found ?!?
Lost device after RESET?</pre> just retry the command - it should work on a second run.

See other notes on [[Dfu-util]] page.

[[Category:Platform| ]]

Flashing the Neo 1973

2007-07-25T22:59:53Z

Chooseopen: /* Actually flashing things into the device */

This describes how to update your openmoko to the latest software. We'll update the kernel, the root filesystem and optionally u-boot (new uboot is only recommended for Phase0 phones, because otherwise you get kernel crashes later; you should probably not flash uboot on a Phase 1 phone without a very good reason).

== Files to download ==

Neccessary files are at http://buildhost.openmoko.org/tmp/deploy/images/ (the precompiled [[dfu-util]] binary there is for Linux/i386, you may need to compile your own for other platforms).

Get:
* [[dfu-util]]
* openmoko-devel-image-fic-gta01-20070501054014.rootfs.jffs2
* uImage-2.6.21.1-moko10-r0_0_1883_0-fic-gta01.bin
* for phase 0 (Bv03) phones:
** Tested by a few people: u-boot-gta01bv3-r8_70124c2602ae2d4c5d3dba05b482d91548242de8_0_2040.bin MD5SUM: 60c5aeba1bd6642b05b3a5e6f2dafe83
** Tested by hrw: u-boot-gta01bv3-r8_70124c2602ae2d4c5d3dba05b482d91548242de8_0_2062.bin MD5SUM: 716f1eba9b0f2be4a0a3be4a56724935
* for phase 1 phones, uboot update should not be neccessary.

You may want to take the latest versions.

== Putting the device into DFU mode ==

You'll need to boot your openmoko into uboot menu (hold AUX button while pressing power button). Unplug all other usb devices from the host. Plug the phone directly into the host not via a hub.

It also seems that once you've booted your openmoko into the uboot menu, you then should plug it into the USB port. It should show a status message when you do so in terms of "Switching to DFU mode".

== Actually flashing things into the device ==

Double check that u-boot matches your hardware version. Flashing u-boot is really a critical part. You probably only want to do that on phase0 phones.

To update u-boot:

Warning: Do not update u-boot unless you have debug board or are really sure about what you are doing. Flashing wrong u-boot image will brick your device! Note especially that image below is for GTA01B_v03, not GTA01B_v04

./dfu-util -a 1 -R -D u-boot-gta01bv3-r8_70124c2602ae2d4c5d3dba05b482d91548242de8_0_2040.bin

To update the kernel:
./dfu-util -a 3 -R -D ./uImage-2.6.21.1-moko10-r0_0_1883_0-fic-gta01.bin

To update the root filesystem:
./dfu-util -a 5 -R -D ./openmoko-devel-image-fic-gta01-20070501054014.rootfs.jffs2

...now, you'll end up with system that boots, but does not see audio/SD card. You'll need to download corresponding modules.tgz and copy them over to openmoko. - UPDATE: GTA01 phones appear to not need this step.

Old versions of uboot are buggy: You may have to press the aux button few times so that machine does not sleep while flashing. It also does not erase rootfs before flashing it... to do that, do minicom /dev/ttyACM0, then nand erase clean rootfs . Unfortunately, old versions of uboot are not really usable, because they fail to enable high 64MB of RAM, and you get nasty crashes after kernel boots.

Good luck!

== Troubleshooting notes ==

If you're facing errors in seemingly random places during the flashing of images, most likely the USB hub or cable through which your Neo1973 is connected, is of too poor quality. It is recommended that you always connect the phone directly to the host when using dfu-util.

If dfu-util reports a message like the following, before it starts flashing:<pre>
Resetting USB...
not at least 2 device changes found ?!?
Lost device after RESET?</pre> just retry the command - it should work on a second run.

See other notes on [[Dfu-util]] page.

[[Category:Platform| ]]

User:Chooseopen

2007-07-22T02:32:23Z

Chooseopen:

[[Image:Gollum-OpenMoko.jpg]]

File:Gollum-OpenMoko.jpg

2007-07-22T02:31:44Z

Chooseopen: OpenMoko developer portrait

OpenMoko developer portrait

UI Improvements

2007-07-14T18:52:23Z

Chooseopen: Left-handed Mode for UI

==Introduction==

Obviously the tools are in the wild to build interfaces that could rival
(or better IMO) anything Apple comes up with. We just need to organize
this stuff. This would need hardware that can support dynamic
interfaces. I can help here, too.
sean@openmoko.com

In fact, this place shall be dedicated to human-machine interactions improvements discussion;

Human-machine interaction can be separated into several aspects:
* the physical contact/input device: the mono-touch touchscreen
* the graphics:
** accelerated rendering can add more consistency to zooming user interfaces, which seem to be quite an interesting concept for embedded scrensize-limited devices
** adding physics "look and feel" to (ex: menu's) behaviours can add coherence too
* the input methods
** the virtual keyboard
** handgestures

==Finding inspiration ...==

===Seen Live===

'''Multi-touch'''
*[http://www.youtube.com/watch?v=89sz8ExZndc Multi-Touchscreen experiments video @youtube]
*[http://www.youtube.com/watch?v=nPqqfVLQ_qY iPhone UI features demo @youtube]

'''Zooming user interfaces'''
*[http://www.zenzui.com/products.html ZenZui], a [http://en.wikipedia.org/wiki/ZUI ZUI (zooming user interface)]
*[http://labs.live.com/Deepfish/videos.aspx Microsoft Bluefish's ZUI] (new mobile webbrowser)
*[http://googlesystem.blogspot.com/2007/04/opera-920-more-homepages-at-your.html Opera speed dial]

'''Graphics'''
*[http://www.rasterman.com/files/eem.avi EEM], Rasterman's EFL libs on handelds proof of concept (doesn't DO anything, just showing off the EFLs on a handeld)
*[http://www.youtube.com/watch?v=8kLFPfaxQ6U&eurl= Nvidia's cutting-edge techno], an [http://www.khronos.org/openkode/ Openkode] demo.

'''Science fiction'''
*[http://www.youtube.com/watch?v=G_FS2TiK3AI UPMC Future?]

'''Links:'''
*[http://elevate.sourceforge.net/links.html elevate project's links] sums up quite greatly the latest innovations in the desktop area
*[http://nooface.net/ Nooface] is a human-machine news site
*Asus-Intel's [http://www.hothardware.com/articles/Hands_on_with_the_ASUS_Eee/?page=2 Eee]'s interface

===Clever hacks===

It's been said that having no multitouch screen allows less freedom for innovation. Maybe we could get something out of our touchscreen drivers.

Why ? Think of apple's scroll up/down feature on macbooks touchpads (which '''aren't multi touch''', it's a [http://iscroll2.sourceforge.net/ clever driver hack, iscroll2]):

To scroll, just place two fingers on your trackpad instead of one. Both fingers
need to be placed next to each other horizontally (not vertically, the trackpad
cannot detect that). Some people get better results with their finger spaced a
little bit apart, while others prefer having the fingers right next to each other.

iScroll2 provides two scrolling modes: Linear and circular scrolling.

For linear scrolling, move the two fingers up/down or left/right in a straight
line, respectively, to scroll in that direction.

Circular scrolling works in a way similar to the iPod's scroll wheel: Move the two
fingers in a circle to scroll up or down, depending on whether you move in a
clockwise or counterclockwise direction.

Maybe we can port/adapt/get inspiration from this macintosh driver.

===n-D navigation: the polyhedra inspiration===

When we want to navigate files, mp3s in an mp3 player, etc... Every control that the application needs is a button. What about looking at the polyhedrons? We could find one for each usage, with as many surrounding subzones that way be used as controls. Ex: you need 5 buttons, let's take a pentagon with 5 surrounding zones all around. That way, it's always optimized...

http://en.wikipedia.org/wiki/Polyhedra
http://en.wikipedia.org/wiki/List_of_uniform_polyhedra

===Our weapons===

We can't improve the human-machine interface without knowing the strenghts / weaknesses of our hardware; some of the weaknesses might turn out as exploitable features, some strengths as limiting constraints.

====The touchscreen====

Question:

What exactly does the touchscreen see when you touch the screen with 2 fingers
at the same time, when you move them, when you move only one of the 2, etc. I'm
also interested in knowing how precise the touchscreen is (ex: refresh rate,
possible pressure indication, ...)?

Answer:

* The output is the center of the bounding box of the touched area
* The touch point skips instantly on double touch
* Pressure has almost no effect on a single touch, but not so on a double touch. The relative pressures will cause a significant skewing effect towards the harder touch. You can easily move the pointer along the line between your two fingers by changing the relative pressure.

Conclusions:
* we can detect double touch as jumps, and that's all
* no pressure
* This could be an interesting input method for games - e.g. holding the Neo in landscape view, letting each thumb rest on a specific input area; probably needs to be checked for usability with a real device

Question:

What does one see when sliding two fingers in parallel up(L,R)->down(L,R)?

Answer:

* In theory you see a slide along the center line between your two fingers. In practice, you can't keep the pressure equal, so you will see some kind of zig-zag line somewhere between the two pressure points in the direction of your slide.

Question:

What does one see when narrowing two fingers in slide (=zoom effect on iphone)?

Answer:

* In theory you see the pointer stay at the center of the zoom movement. In practice, you can't keep the pressure equal for both fingers, so the pointer will move towards one of the two pressure points.

====Graphics and computational capabilities====

It would be good to report what performance the current hardware allows:
* There was no pure X11 benchmarking done (AFAIK) (how many fps at full VGA scrolling, ex: 1024*480 image scrolling?)
* what about the lcd reactivity? What if we don't see anything but blur while moving items fast?

Please report here your impressions.

==Areas of improvement==

* OpenGL for fluid zooming interfaces (2D: the infinite sphere model, 1D: the infinite wheel of fortune/ribbon model, exposé)
* HandGestures
* Physics-model based improvements: inertia and friction
* multi touch screen for natural handgestures
* improved virtual keyboard
* switching to another GUI toolkit (EFLs)

===Physics-inspired animation a.k.a. "Digital Physics"===

If we want to add eye candy & usability to the UI (such as smooth realistic list scrolling, as seen in apple's
iphone demo on contacts lists for instance), we'll need a physics engine, so that moves & animations aren't all linear.

The following aticle explains the [http://www.readwriteweb.com/archives/the_physics_of_iphone.php Digital Physics] term from the iPhone example.

The most used technique for calculating trajectories and systems of related geometrical objects seems to be [http://en.wikipedia.org/wiki/Verlet_integration verlet integration] implementation; it is an alternative to Euler's integration method, using fast approximation.

We may have no need for such a mathematical method at first, but perhaps there are other use cases. For instance, it may be useful to gesture recognition (i'm not aware if existing gesture recognition engines measure speed, acceleration...).

====Open Dynamics Engine====

ODE is an open source, high performance library for simulating rigid body dynamics. It is fully featured, stable, mature and platform independent with an easy to use C/C++ API. It has advanced joint types and integrated collision detection with friction. ODE is useful for simulating vehicles, objects in virtual reality environments and virtual creatures. It is currently used in many computer games, 3D authoring tools and simulation tools.

http://www.ode.org/

====Libakamaru====

The [http://people.freedesktop.org/~krh/akamaru.git/ akamaru library] is the code behind [http://www.youtube.com/watch?v=VekgyKQoTeM kiba dock]'s fun and dynamic behaviour. It's dependencies are light (needs just GLib). It takes elasticity, friction, gravity into account.

If you want to take a quick look at the code:
svn co http://svn.kiba-dock.org/akamaru/ akamaru

The only (AFAIK) application using this library is kiba-dock, a *fun* app launcher, but we may find another use to it in the future.

As suggested on the mailing list, it is mostly overkill for the uses we intend to have, but this library may be optimized already, the API can spare some time for too. Furthermore, ''Qui peut le plus, peut le moins''.

====Verlet integration implementation from e17====

There's an undergoing verlet integration implementation into the e17 project (by rephorm) see http://rephorm.com/news/tag/physics , so we may see some UI physics integration into e17 someday.

====Robert Pernner's easy equations====

http://www.robertpenner.com/easing/

See the demo: implements non linear behaviour (actionscript), but may give inspiration

===Extending the touchscreen capabilities and input methods===

* '''Multitouchscreen emulation'''

If we got it right, when touching the screen on a second place, the cursor oscillates between the two points depending on relative pressure distribution. Using averaging algorithms, we may have the opportunity to detect peculiar behaviours.

We need raw data (x,y,t) from the real hardware for the following behaviours:
* slide two fingers in parallel - vertical up/down (scroll)
* turn the two fingers around (rotate)
* slide two fingers towards each other (zoom-)
* slide two fingers apart (zoom+)

When touching the screen with two fingers at the same time, we necessarily see the two points, or are able to extrapolate the position of the second one. This solution can add feature, but will probably be little erratic...

* '''Touchscreen kernel module hacking'''

We may correct the "half distance" phenomenon on double touch: if double touch is detected, then assimilate the cursor as twice further than the first touch. It would allow finer control, but higher instability.

The double touch detection may be implemented in the driver itself, as well as stabilization.

* '''Other detectable behaviours'''

The warping can be used in the 4 diagonals, plus the up/down/right/left cross:

---------------- ---------------- ---------------- ----------------
- 1 - - 1 2 - - 1 - - 2 -
- - - - - - - -
- - - - - - - -
- - - - - - - -
- - - - - - - -
- - - - - - - -
- 2- - - - 2 - - 1 -
---------------- ---------------- ---------------- ----------------

It's not double touch, but two sequential presses with a short time in between (~0.5 s)

===Improved virtual keyboard===

One nice idea for virtual input is [http://www.micropp.se/openmoko/ finger-splash]

Yet, optimization does not only apply to the plain one-letter-at-a-time input. We need some sort of T9 (dictionary-based input help). When typing a word, the first letter determines the next possible ones. Therefore, we may let disappear the less-probable following letters. Ex: type an L, there's no way an X follows...

Hints:
* ZIP's huffmann compression applied to SMSs/mails for detecting the most used characters/words/sentences.
* html tag-couds, one-letter tag clouds ; font size proportional to the probability of being used

The most critical point is the initial disposition of the letters, before any letter is typed. We may also want to use horizontal two-parts keyboard (with the neo in hands like a psp..)

The [http://www.strout.net/info/ideas/hexinput.html hexinput] concept is interesting. What about hiding the less probable letters and increasing the remaining ones during typing?

===Choosing the right GUI toolkit===

There are [http://www.hbmobile.org/wiki/index.php?title=GUI_Frameworks lots of possible GUI frameworks] with various software architectures that can be used for OpenMoko.

GTA01 hardware uses GTK+/matchbox without hardware acceleration, and it's not enough: this is a first that a mobile linux device has such a high DPI resolution.

Benchmarking will be needed to compare the different alternatives: qt, directfbgtk, ...

====Switching to the Enlightenment Foundation Libraries====

''Moved [[E17|here]]''

====Distant future: OpenGL compositing====

Compositing seems to give zooming interfaces reality (at last!).

Well, considering recent changes in destkop applications, opengl has a definite future. For instance, the expose (be it apple's or beryl's) is a very interesting and usable feature. Using compositing allows the physics metaphore: '''the human brain doesn't like "gaps"/jumps (for instance while scrolling a text), it needs continuity''', which can be provided by opengl. When you look at apple's iphone prototype, it's not just eye candy, it's maybe the most natural/human way of navigating, because it's sufficiently
realistic for the brain to forget the non-physical nature of what's inside.

So, opengl hardware will be needed in a more or less distant hardware,
for 100% fluid operation.

How cool will solid-based (polygons, as seen in beryl) interfaces be? :) Real ZUIs...

====Clutter Toolkit====

Clutter, an openedhand project, is an open source software library for creating fast, visually rich graphical user interfaces. The most obvious example of potential usage is in media center type applications. We hope however it can be used for a lot more.

http://clutter-project.org/

Clutter uses OpenGL (and optionally '''OpenGL ES''') for rendering but with an API which hides the underlying GL complexity from the developer. The Clutter API is intended to be easy to use, efficient and flexible.

From the [http://en.wikipedia.org/wiki/OpenGL_ES wikipedia article], OpenGL ES (OpenGL for Embedded Systems) is a subset of the OpenGL 3D graphics API designed for embedded devices such as mobile phones, PDAs, and video game consoles.

==Improvement ideas==

Please add here any idea that seems of relevance.

===1D list scrolling: looped physics-driven item list===

====Description====

Take an item list (ex: adress book), print it on a ribbon of paper, and glue it on a wheel (on the tire). You're looking in the front of it, so when you want to go from the A to Z, you touch the wheel and drag it up. When you let the wheel go, it goes furter, taken by it's inertia. Stop the wheel when you got your contact. Got the idea? That's why we may speak of an "infinite wheel", so that the surface is flat. For our case here, we always want to display square content, so the [http://en.wikipedia.org/wiki/Uniform_prism n-sided uniform prism] analogy is mathematically more exact.

Important features:
* '''weight''': the biggest the item list, the faster it scrolls; that way, you don't have to wait too long for big lists, and you don't miss your item on shorter lists
* '''friction''': there is friction where the wheel is fixed, so that the wheel doesn't turn infinitely; more friction on short lists, less on big ones
* the '''initial speed and acceleration vector''' you give it determines it's futher rotation
* it's "round"/cyclic, so you can '''browse the list in two directions'''
* we may want to add a "progression indicator", ex the current alphabetical letter, with a font size adequate to the proportion of the number of entries in the letter subcategory, or a reduced map of the distribution of the first letters...

We can add "parallel wheels", symbolizing different sorting methods. Slide long to the left / right to look at a different wheel = items organization.

====Controls====

* Sliding up/down = Single click + maintained for a minimal distance

Effect: scroll in an inverted/negated fashion (slide down = scroll up, slide up = scroll down)

When finger is released (i.e. touchscreen doesn't detect any press):
if (last_speed_seen > 0 ) then keep this speed and acceleration, with friction
else stop scrolling

Scrolling here is seen as unidimensional, but can apply to bidimensional situations (ex: zoomed image) too

* Action = quick double tap

* Details/select = short single tap

* Right click = long tap

* Sliding left/right: switch sorting method

====Parts to modify====

''Having a scroll that isn't a 1:1 map to the user's action isn't hard. It's just an extra calculation in the scroll code.''

<---- Where is the scroll code? :)

* libmokoui
** [[Stylus_Scrolling | Stylus scrolling widget]]
** [[Finger_Scrolling | Finger scrolling wheel widget]]
* gtk
** [http://www.gtk.org/api/2.6/gtk/GtkVScrollbar.html GtkVScrollbar]

The best would be to add the feature for both finger and stylus scrolling.

TODO:
* make the entire list a "scrolling zone", i.e. an overlay transparent scrolling widget?
* define controls
* add the inertia feature

===1D Scrolling: inertia friction integration into openmoko's finger wheel===

The same, but for the wheel. It can be very short to do: you don't have 1:1 anymore, but, for example, 1/4 wheel turn = 1 item. It's demultiplicated, but has inertia.

===Left-handed UI Support===

====Description====
A discussion on the community list identified a desire to have the ability to switch the OpenMoko UI into "left-handed" mode.

The main problem is scrollbars, when they're on the right dragging
the scrollbar left handed results in your hand covering the screen so
you can't see what you are doing. So having the option of scrollbars
on the left would be useful.

I don't think the whole screen should be mirrored! There are some elements
that should remain..like the main top bar with the status icons and such.
Scrollbars are the main thing I can think of right now.

===Handgesture recognition proposals===

====Using simple, localized warp as modifier key====

As discussed on community list:

If you hold down one finger and tap the other one, the mouse pops over and back
again. If you keep your second finger touching, the cursor follows it. When you
release it, cursor goes back to first finger position. This could be a way to
set a bounding box or turn on the mode. So the second finger can do something
like rotating around the first, or increase or lower the distance to the first.

* the so-called "first touch" can be done on the mokowheel zone itself: put your left thumb on the black area; if you touch the screen with another finger, there is a '''warp'''; the warp is detectable and allows to enter "fake multi-touchscreen mode"
* afterwards,
* slide your right-hand finger down, it scrolls up
* slide your right-hand finger up, it scrolls down
* slide it left, next page/item
* slide it right, previous page/item
* do a circle: rotation
* narrow towards the black circle: zoom -
* go away: zoom +
* if you had kept your first finger on the black quarter circle, you can continue issuing other gestures

The advantages of using simple origin-driven cursor warping as double touch detection criteria is that:
* you don't have to use the wheel as button, which would slow things down and generate errors (false button presses)
* simpler detection algorithms that can pass by the fluctuation due to pressure relative distribution
* the space taken by the wheel itself is "useless" (i.e. displays no information); using it as modifier allows to keep the screen clean for reading
* the origin of this zone lets use maximum surface of the screen, allowing more fine controlling

[[Image:Fake_multitouch_rotate_right.png]]

[[Image:Fake_multitouch_scroll_previous.png]]

[[Image:Fake_multitouch_scroll_down.png]]

[[Image:Fake_multitouch_zoom-.png]]

*Pros:
** who said we need multi-touch hardware?
** this may be the easiest way (in terms of design/implementation complexity, reliability)
*Cons:
** no matter what we'll invent, we'll need two hands for on-the-move controlling
** what about left-handed people?

====What is to modify ?====

We need to emulate key presses. We need to work at a layer where we can get raw cursor coordinates. <---- X server layer?

====Full multi-touch emulation====

Doable, but tricky...

==Open questions==

* will the neo/openmoko graphics system be powerful enough for such uses? I apple uses an OpenGL ES acceleration on this device (as well as on recent iPods), which is on the way with GTA02
* how does the touchscreen behave? We need a detailed touchscreen wiki information page, with visual traces. How hardware-specific is it?
* is multi touch really that awesome? I guess not.

[[Category:User Interfaces]]

Openmoko Local Groups: Chicago

2007-07-13T22:26:28Z

Chooseopen:

Welcome to the Chicago Openmoko page!

This group is for anyone in Chicago and surrounding areas. Hopefully we'll be able to organize an event for when a few of us get the Neo1973s.

Openmoko Local Groups: Chicago

2007-07-13T22:24:58Z

Chooseopen:

Are there any other OpenMoko community members located in the Chicago area?

Openmoko Local Groups

2007-07-13T22:24:19Z

Chooseopen: /* USA */ Added Chicago, IL

__TOC__
'''OpenMoko Local Groups...'''

* can be used for developers to meet and get to know each other
* can be used for developing
* may provide the room for real-life discussions away from mailinglists/wiki
* can support early support handling their GTA01Bv4 and exchange experiences
* fasten the community's cohesion
* give motivation

==EU==

=== Austria ===
==== [[OpenMoko_Local_Groups: Vienna|Vienna]] ====

=== Finland ===
==== [[OpenMoko_Local_Groups: Helsinki|Helsinki]] ====

=== Germany ===
==== [[OpenMoko_Local_Groups: Berlin|Berlin]] ====

=== Poland ===
==== [[OpenMoko_Local_Groups: Warsaw|Warsaw]] ====

=== Spain ===
==== [[OpenMoko_Local_Groups: Madrid|Madrid]] ====

=== Sweden ===
==== [[OpenMoko_Local_Groups: Gothenburg|Gothenburg]] ====

===UK===
==== [[OpenMoko_Local_Groups: Birmingham|Birmingham]] ====
==== [[OpenMoko_Local_Groups: London|London]] ====

==USA==
===Oregon===
==== [[OpenMoko_Local_Groups: Eugene|Eugene]] ====
[[Category:Community]]
[[Category:Neo1973 Phase 1 related]]
===California===
==== [[OpenMoko_Local_Groups: San Diego|San Diego]] ====
==== [[OpenMoko_Local_Groups: San Francisco|San Francisco]] ====
[[Category:Community]]
[[Category:Neo1973 Phase 1 related]]
===Illinois===
==== [[OpenMoko_Local_Groups: Chicago|Chicago]] ====
[[Category:Community]]
[[Category:Neo1973 Phase 1 related]]
===Michigan===
==== [[OpenMoko_Local_Groups: Detroit|Detroit]] ====
[[Category:Community]]
[[Category:Neo1973 Phase 1 related]]
===Ohio===
==== [[OpenMoko_Local_Groups: Cleveland|Cleveland]] ====
[[Category:Community]]
[[Category:Neo1973 Phase 1 related]]
===Texas===
==== [[OpenMoko_Local_Groups: North Texas|North Texas]] ====
[[Category:Community]]
[[Category:Neo1973 Phase 1 related]]

==CANADA==
===Quebec===
==== [[OpenMoko_Local_Groups: Montreal|Montreal]] ====

MokoMakefile

2007-07-13T13:08:38Z

Chooseopen: /* QEMU */ Added 'sdl' dependency

==MokoMakefile==
MokoMakefile is a fully automated way of setting up an OpenMoko development environment. It is an invaluable tool for getting new developers up and running with a build environment which is configured the same as all the other existing developers. It brings the same repeatability to build environment creation and maintenance as that which OpenEmbedded brings to the main task of actually building embedded software distributions.

Note that MokoMakefile does *not* replace bitbake, or svn, or monotone, or openembedded, or qmake, or anything else. It is a wrapper around all that to make it easy to set up and maintain a development environment that fully complies with the setup instructions published by OpenMoko. Note that you need about 7 GB of available disk space for MokoMakefile to succeed.

MokoMakefile is developed by [[User:RodWhitby|Rod Whitby]] - it is not an official product of OpenMoko (although I would be happy for them to pick it up and use it internally). If there is any discrepancy between the [[Building_OpenMoko_from_scratch|official OpenMoko build instructions]], and the operation of the MokoMakefile, then you should consider the official instructions to be correct.

=== Before you begin ===
'''Check that your /bin/sh (ls -l /bin/sh) is not linked to dash rather than bash.''' Using dash will cause you pain. This is true for a standard install of Ubuntu 7.04 (at least when installing from Live CD). If your /bin/sh points to /bin/dash, correct it with (as root):
ln -sf /bin/bash /bin/sh

If you have previously built with dash as your sh shell then your perl compile is probably broken. One symptom is that the build will error and whine about an 'Unterminated quote string' another symptom is a message that says 'You haven't done a "make depend" yet!' If you get these then you need to:
make clean-package-perl
make clean-package-perl-native
and rebuild.

If all else fails then just rm -rf the perl work dir and the perl stamps here's an i686 host example:
rm -rf build/tmp/work/i686-linux/perl-native-5.8.7-r3
rm -f build/tmp/stamps/i686-linux/perl*

As of r99, MokoMakefile has patches which should make it build correctly with dash.

=== Installation ===
Here are the steps to use it:

1 - Make sure your build host is set up according to:
http://www.openembedded.org/wiki/OEandYourDistro
2 - Create your $OMDIR directory:
mkdir /home/moko ; cd /home/moko
3 - Grab MokoMakefile:
wget http://www.rwhitby.net/files/openmoko/Makefile
4 - Set up the environment:
make setup
5 - Start building. Before starting a lenghty make process, check in Tips section about how to make Make multicore aware. You may want to modify the build/conf/local.conf file for your target (emulation/chroot) enviroment:
make openmoko-devel-image

This will set up the recommended directory structure as described in [[Building OpenMoko from scratch]], will download all the required software (from the right places with the right versions), and will immediately start building an image.

Once you have done this, you can choose to continue using the MokoMakefile to initiate your subsequent builds, or you can go into the build directory and run bitbake commands manually. The choice is yours.

===Updating the environment===
For easy maintenance of your build environment the following commands are available.

1 - To update the MokoMakefile to the latest version:
make update-makefile

2 - To update the OpenMoko repository checkout and the MokoMakefile patches to the latest version:
make update

3 - To make sure that any recent changes to the build directory structure have been applied:
make setup

A quick way to rebuild a new image with the latest updates:
make update-makefile && make update setup openmoko-devel-image

===Reporting Problems===

First, make sure that the problem is reproducable after running

make update-makefile ; make update ; make setup

then running

make clean-package-<foo>

(where you replace <foo> with the name of the package which is failing)

then running

make all

If you can get the error to occur three times in a row after running that sequence of commands three times, then feel free to report it to rwhitby in #openmoko on [http://wiki.openmoko.org/wiki/Development_resources#IRC IRC].

===Work-arounds===

Work-arounds for temporary or isolated problems should be added to the [[Talk:MokoMakefile|Discussion page]] which is associated with this page. As they are fixed, they will be removed from that page.

===Tips===
*You can reduce the amount of consumed disk space significantly by adding
INHERIT += "rm_work"
in your local.conf (e.g. /home/moko/build/conf/local.conf). This will remove the contents of each build/tmp/work/*/<package> directory after the corresponding package builds correctly.

*If you an encounter an error with monotone similar to the following:
mtn: misuse: database /home/moko/OE.mtn is laid out according to an old schema
Then you need to upgrade OE.mtn Use the following command while in /home/moko:
# mtn --db OE.mtn db migrate

*If a certain package does not build due to corrupted download or some such try to remove the sources and rebuild it.
rm sources/<package>*
cd build
. ../setup-env
bitbake -crebuild <package>
after that your build might just work again.

*For people with multiple CPU's (or dual-core ones) this small patch might be useful to build things faster.
Edit the local.conf and add the following lines:
PARALLEL_MAKE = "-j 4"
BB_NUMBER_THREADS = "4"

Change the PARALLEL_MAKE and BB_NUMBER_THREADS values to something that suits better if it chokes your machine.

*For amd64 host users you need the patch from http://bugs.openembedded.org/show_bug.cgi?id=1765 to build db3-native

===QEMU===
The MokoMakefile now has support for automatically building, flashing, and running [[OpenMoko under QEMU|the new Neo1973 emulator]] (which is based on QEMU).

Dependencies:

*lynx ('apt-get install lynx' in Ubuntu 7.04)
*netpbm ('apt-get install netpbm' in Ubuntu 7.04)
*sdl-devel ('apt-get install libsdl1.2-dev in Ubuntu .704')

“make qemu” will build qemu-neo1973, download the latest official OpenMoko images, flash the images into the virtual NAND flash, and run the emulator (you still need to install the makefile as mentioned above, however).

Other targets are “make download-images” (to download the latest official images), “make flash-qemu-official” (to flash those images) and “make flash-qemu-local” (which will flash your latest locally built images), which can then be followed by “make run-qemu” or “make run-qemu-snapshot” to run the emulator with the most recently flashed images.

Make sure you have the “lynx” and “netpbm” packages installed on your build host first.

You're also invited to read more about how to run [[OpenMoko under QEMU]] in the article dedicated to this subject.

===Developing with MokoMakefile===

To make in-tree changes and have them built and used by qemu:

cd /home/moko/openmoko
quilt new descriptive-patch-name.patch
quilt add trunk/src/name-of-file-to-change # do this for every file you are about to modify
...make the changes...
quilt refresh # this creates a file in /home/moko/patches/openmoko-HEAD/ and updates the quilt series file there

Note: Do '''NOT''' use absolute paths as this confuses quilt and will get you a diff of the file against /dev/null!

To build the changes and have them used by qemu:

make build-qemu
make flash-qemu-local
make run-qemu

If you want to modify applications instead of the openmoko toolchain, this is what you have to do (example: openmoko-messages):

/usr/src/openmoko# . ./setup-env
/usr/src/openmoko# cd openmoko/
/usr/src/openmoko/openmoko# bitbake -c unpack openmoko-messages
/usr/src/openmoko/openmoko# cd \
../build/tmp/work/armv4t-linux/openmoko-messages-0.0.1+svnnow-r2_2276/openmoko-messages/
/usr/src/openmoko/build/tmp/work/armv4t-linux/openmoko-messages-0.0.1+svnnow-r2_2276/openmoko-messages# \
vim src/detail-area.c
/usr/src/openmoko/build/tmp/work/armv4t-linux/openmoko-messages-0.0.1+svnnow-r2_2276/openmoko-messages# \
cd -
/usr/src/openmoko/openmoko# bitbake openmoko-messages

Then continue with MokoMakefile usage.

If you want to add an application to your openmoko distribution, do this:
All file edits should be done using quilt as described above. That way a patch can easily be submitted to the openmoko project.
First, create a directory that will correspond to your package and edit a '''.bb''' file in there:
/usr/src/openmoko# cd openmoko/
/usr/src/openmoko/openmoko# quilt new mycoolpackage.patch
/usr/src/openmoko/openmoko# mkdir trunk/oe/packages/mycoolpackage
/usr/src/openmoko/openmoko# quilt add trunk/oe/packages/mycoolpackage/mycoolpackage_1.bb
/usr/src/openmoko/openmoko# quilt edit trunk/oe/packages/mycoolpackage/mycoolpackage_1.bb

The file should have the following content:
DESCRIPTION = "This is a cool package"
SECTION = "username/mycoolpackage"
PV = "1"

inherit autotools

SRC_URI = "http://www.example.com/download/mycoolpackage-1.tar.gz"

Explanation:
* DESCRIPTION - Just a short text explaining the package
* SECTION - I have no clue, but I'll use username/mycoolpackage for now
* PV - Package Version
* inherit autotools - The package can be compiled by './configure && make && make install' so we tell MokoMakefile to do it this way.
* SRC_URI = ... - This is the download location of the package source. It's imperative that the tar.gz contains a directory called '''packagename-packageversion''' (in this case: mycoolpackage-1) so that MokoMakefile can find it automatically or the build will fail.

This is not all. We also need to tell MokoMakfile that it needs to build and include the package in the image. To do this, do
/usr/src/openmoko/openmoko# quilt edit trunk/oe/packages/tasks/task-openmoko.bb
Here, increase the value '''PR''' by one and add '''mycoolpackage \''' (with the backslash!) just before the line reading '''# update-alternatives \'''.

Now run
/usr/src/openmoko/openmoko# quilt refresh
/usr/src/openmoko/openmoko# cd ..
/usr/src/openmoko# make update all

And if everything's alright you should now have an OpenMoko image to flash to your phone or run in qemu as described above.

===Testimonials===
MokoMakefile is recommended by 4 out of 4 new developers on #openmoko, with testimonials such as "For some reason last night I couldn't get my manual install of everything to work (bb complained about my bbpath I think) ... but with your makefile, it works great!", and "MokoMakefile rocks!".

Project page:
http://mokomakefile.projects.openmoko.org/

{{Languages|MokoMakefile}}

Modular phone

2007-07-13T03:16:55Z

Chooseopen: typos

A number of manufacturers produce modular components suitabel for embedded systems. Some of these components are suitable for a hobbyist to put together a modular phone. This page is intended as a starting-point for building an OpenMoko compatible phone.

==Component Suppliers==
[http://www.sparkfun.com/commerce/categories.php Spark Fun] 
[http://gumstix.com/ Gumstix]

MokoMakefile

2007-07-12T23:32:54Z

Chooseopen: /* QEMU */

==MokoMakefile==
MokoMakefile is a fully automated way of setting up an OpenMoko development environment. It is an invaluable tool for getting new developers up and running with a build environment which is configured the same as all the other existing developers. It brings the same repeatability to build environment creation and maintenance as that which OpenEmbedded brings to the main task of actually building embedded software distributions.

Note that MokoMakefile does *not* replace bitbake, or svn, or monotone, or openembedded, or qmake, or anything else. It is a wrapper around all that to make it easy to set up and maintain a development environment that fully complies with the setup instructions published by OpenMoko. Note that you need about 7 GB of available disk space for MokoMakefile to succeed.

MokoMakefile is developed by [[User:RodWhitby|Rod Whitby]] - it is not an official product of OpenMoko (although I would be happy for them to pick it up and use it internally). If there is any discrepancy between the [[Building_OpenMoko_from_scratch|official OpenMoko build instructions]], and the operation of the MokoMakefile, then you should consider the official instructions to be correct.

=== Before you begin ===
'''Check that your /bin/sh (ls -l /bin/sh) is not linked to dash rather than bash.''' Using dash will cause you pain. This is true for a standard install of Ubuntu 7.04 (at least when installing from Live CD). If your /bin/sh points to /bin/dash, correct it with (as root):
ln -sf /bin/bash /bin/sh

If you have previously built with dash as your sh shell then your perl compile is probably broken. One symptom is that the build will error and whine about an 'Unterminated quote string' another symptom is a message that says 'You haven't done a "make depend" yet!' If you get these then you need to:
make clean-package-perl
make clean-package-perl-native
and rebuild.

If all else fails then just rm -rf the perl work dir and the perl stamps here's an i686 host example:
rm -rf build/tmp/work/i686-linux/perl-native-5.8.7-r3
rm -f build/tmp/stamps/i686-linux/perl*

As of r99, MokoMakefile has patches which should make it build correctly with dash.

=== Installation ===
Here are the steps to use it:

1 - Make sure your build host is set up according to:
http://www.openembedded.org/wiki/OEandYourDistro
2 - Create your $OMDIR directory:
mkdir /home/moko ; cd /home/moko
3 - Grab MokoMakefile:
wget http://www.rwhitby.net/files/openmoko/Makefile
4 - Set up the environment:
make setup
5 - Start building. Before starting a lenghty make process, check in Tips section about how to make Make multicore aware. You may want to modify the build/conf/local.conf file for your target (emulation/chroot) enviroment:
make openmoko-devel-image

This will set up the recommended directory structure as described in [[Building OpenMoko from scratch]], will download all the required software (from the right places with the right versions), and will immediately start building an image.

Once you have done this, you can choose to continue using the MokoMakefile to initiate your subsequent builds, or you can go into the build directory and run bitbake commands manually. The choice is yours.

===Updating the environment===
For easy maintenance of your build environment the following commands are available.

1 - To update the MokoMakefile to the latest version:
make update-makefile

2 - To update the OpenMoko repository checkout and the MokoMakefile patches to the latest version:
make update

3 - To make sure that any recent changes to the build directory structure have been applied:
make setup

A quick way to rebuild a new image with the latest updates:
make update-makefile && make update setup openmoko-devel-image

===Reporting Problems===

First, make sure that the problem is reproducable after running

make update-makefile ; make update ; make setup

then running

make clean-package-<foo>

(where you replace <foo> with the name of the package which is failing)

then running

make all

If you can get the error to occur three times in a row after running that sequence of commands three times, then feel free to report it to rwhitby in #openmoko on [http://wiki.openmoko.org/wiki/Development_resources#IRC IRC].

===Work-arounds===

Work-arounds for temporary or isolated problems should be added to the [[Talk:MokoMakefile|Discussion page]] which is associated with this page. As they are fixed, they will be removed from that page.

===Tips===
*You can reduce the amount of consumed disk space significantly by adding
INHERIT += "rm_work"
in your local.conf (e.g. /home/moko/build/conf/local.conf). This will remove the contents of each build/tmp/work/*/<package> directory after the corresponding package builds correctly.

*If you an encounter an error with monotone similar to the following:
mtn: misuse: database /home/moko/OE.mtn is laid out according to an old schema
Then you need to upgrade OE.mtn Use the following command while in /home/moko:
# mtn --db OE.mtn db migrate

*If a certain package does not build due to corrupted download or some such try to remove the sources and rebuild it.
rm sources/<package>*
cd build
. ../setup-env
bitbake -crebuild <package>
after that your build might just work again.

*For people with multiple CPU's (or dual-core ones) this small patch might be useful to build things faster.
Edit the local.conf and add the following lines:
PARALLEL_MAKE = "-j 4"
BB_NUMBER_THREADS = "4"

Change the PARALLEL_MAKE and BB_NUMBER_THREADS values to something that suits better if it chokes your machine.

*For amd64 host users you need the patch from http://bugs.openembedded.org/show_bug.cgi?id=1765 to build db3-native

===QEMU===
The MokoMakefile now has support for automatically building, flashing, and running [[OpenMoko under QEMU|the new Neo1973 emulator]] (which is based on QEMU).

Dependencies:

*lynx ('apt-get install lynx' in Ubuntu 7.04)
*netpbm ('apt-get install netpbm' in Ubuntu 7.04)

“make qemu” will build qemu-neo1973, download the latest official OpenMoko images, flash the images into the virtual NAND flash, and run the emulator (you still need to install the makefile as mentioned above, however).

Other targets are “make download-images” (to download the latest official images), “make flash-qemu-official” (to flash those images) and “make flash-qemu-local” (which will flash your latest locally built images), which can then be followed by “make run-qemu” or “make run-qemu-snapshot” to run the emulator with the most recently flashed images.

Make sure you have the “lynx” and “netpbm” packages installed on your build host first.

You're also invited to read more about how to run [[OpenMoko under QEMU]] in the article dedicated to this subject.

===Developing with MokoMakefile===

To make in-tree changes and have them built and used by qemu:

cd /home/moko/openmoko
quilt new descriptive-patch-name.patch
quilt add trunk/src/name-of-file-to-change # do this for every file you are about to modify
...make the changes...
quilt refresh # this creates a file in /home/moko/patches/openmoko-HEAD/ and updates the quilt series file there

Note: Do '''NOT''' use absolute paths as this confuses quilt and will get you a diff of the file against /dev/null!

To build the changes and have them used by qemu:

make build-qemu
make flash-qemu-local
make run-qemu

If you want to modify applications instead of the openmoko toolchain, this is what you have to do (example: openmoko-messages):

/usr/src/openmoko# . ./setup-env
/usr/src/openmoko# cd openmoko/
/usr/src/openmoko/openmoko# bitbake -c unpack openmoko-messages
/usr/src/openmoko/openmoko# cd \
../build/tmp/work/armv4t-linux/openmoko-messages-0.0.1+svnnow-r2_2276/openmoko-messages/
/usr/src/openmoko/build/tmp/work/armv4t-linux/openmoko-messages-0.0.1+svnnow-r2_2276/openmoko-messages# \
vim src/detail-area.c
/usr/src/openmoko/build/tmp/work/armv4t-linux/openmoko-messages-0.0.1+svnnow-r2_2276/openmoko-messages# \
cd -
/usr/src/openmoko/openmoko# bitbake openmoko-messages

Then continue with MokoMakefile usage.

If you want to add an application to your openmoko distribution, do this:
All file edits should be done using quilt as described above. That way a patch can easily be submitted to the openmoko project.
First, create a directory that will correspond to your package and edit a '''.bb''' file in there:
/usr/src/openmoko# cd openmoko/
/usr/src/openmoko/openmoko# quilt new mycoolpackage.patch
/usr/src/openmoko/openmoko# mkdir trunk/oe/packages/mycoolpackage
/usr/src/openmoko/openmoko# quilt add trunk/oe/packages/mycoolpackage/mycoolpackage_1.bb
/usr/src/openmoko/openmoko# quilt edit trunk/oe/packages/mycoolpackage/mycoolpackage_1.bb

The file should have the following content:
DESCRIPTION = "This is a cool package"
SECTION = "username/mycoolpackage"
PV = "1"

inherit autotools

SRC_URI = "http://www.example.com/download/mycoolpackage-1.tar.gz"

Explanation:
* DESCRIPTION - Just a short text explaining the package
* SECTION - I have no clue, but I'll use username/mycoolpackage for now
* PV - Package Version
* inherit autotools - The package can be compiled by './configure && make && make install' so we tell MokoMakefile to do it this way.
* SRC_URI = ... - This is the download location of the package source. It's imperative that the tar.gz contains a directory called '''packagename-packageversion''' (in this case: mycoolpackage-1) so that MokoMakefile can find it automatically or the build will fail.

This is not all. We also need to tell MokoMakfile that it needs to build and include the package in the image. To do this, do
/usr/src/openmoko/openmoko# quilt edit trunk/oe/packages/tasks/task-openmoko.bb
Here, increase the value '''PR''' by one and add '''mycoolpackage \''' (with the backslash!) just before the line reading '''# update-alternatives \'''.

Now run
/usr/src/openmoko/openmoko# quilt refresh
/usr/src/openmoko/openmoko# cd ..
/usr/src/openmoko# make update all

And if everything's alright you should now have an OpenMoko image to flash to your phone or run in qemu as described above.

===Testimonials===
MokoMakefile is recommended by 4 out of 4 new developers on #openmoko, with testimonials such as "For some reason last night I couldn't get my manual install of everything to work (bb complained about my bbpath I think) ... but with your makefile, it works great!", and "MokoMakefile rocks!".

Project page:
http://mokomakefile.projects.openmoko.org/

{{Languages|MokoMakefile}}

MokoMakefile

2007-07-12T23:31:46Z

Chooseopen: /* QEMU */

==MokoMakefile==
MokoMakefile is a fully automated way of setting up an OpenMoko development environment. It is an invaluable tool for getting new developers up and running with a build environment which is configured the same as all the other existing developers. It brings the same repeatability to build environment creation and maintenance as that which OpenEmbedded brings to the main task of actually building embedded software distributions.

Note that MokoMakefile does *not* replace bitbake, or svn, or monotone, or openembedded, or qmake, or anything else. It is a wrapper around all that to make it easy to set up and maintain a development environment that fully complies with the setup instructions published by OpenMoko. Note that you need about 7 GB of available disk space for MokoMakefile to succeed.

MokoMakefile is developed by [[User:RodWhitby|Rod Whitby]] - it is not an official product of OpenMoko (although I would be happy for them to pick it up and use it internally). If there is any discrepancy between the [[Building_OpenMoko_from_scratch|official OpenMoko build instructions]], and the operation of the MokoMakefile, then you should consider the official instructions to be correct.

=== Before you begin ===
'''Check that your /bin/sh (ls -l /bin/sh) is not linked to dash rather than bash.''' Using dash will cause you pain. This is true for a standard install of Ubuntu 7.04 (at least when installing from Live CD). If your /bin/sh points to /bin/dash, correct it with (as root):
ln -sf /bin/bash /bin/sh

If you have previously built with dash as your sh shell then your perl compile is probably broken. One symptom is that the build will error and whine about an 'Unterminated quote string' another symptom is a message that says 'You haven't done a "make depend" yet!' If you get these then you need to:
make clean-package-perl
make clean-package-perl-native
and rebuild.

If all else fails then just rm -rf the perl work dir and the perl stamps here's an i686 host example:
rm -rf build/tmp/work/i686-linux/perl-native-5.8.7-r3
rm -f build/tmp/stamps/i686-linux/perl*

As of r99, MokoMakefile has patches which should make it build correctly with dash.

=== Installation ===
Here are the steps to use it:

1 - Make sure your build host is set up according to:
http://www.openembedded.org/wiki/OEandYourDistro
2 - Create your $OMDIR directory:
mkdir /home/moko ; cd /home/moko
3 - Grab MokoMakefile:
wget http://www.rwhitby.net/files/openmoko/Makefile
4 - Set up the environment:
make setup
5 - Start building. Before starting a lenghty make process, check in Tips section about how to make Make multicore aware. You may want to modify the build/conf/local.conf file for your target (emulation/chroot) enviroment:
make openmoko-devel-image

This will set up the recommended directory structure as described in [[Building OpenMoko from scratch]], will download all the required software (from the right places with the right versions), and will immediately start building an image.

Once you have done this, you can choose to continue using the MokoMakefile to initiate your subsequent builds, or you can go into the build directory and run bitbake commands manually. The choice is yours.

===Updating the environment===
For easy maintenance of your build environment the following commands are available.

1 - To update the MokoMakefile to the latest version:
make update-makefile

2 - To update the OpenMoko repository checkout and the MokoMakefile patches to the latest version:
make update

3 - To make sure that any recent changes to the build directory structure have been applied:
make setup

A quick way to rebuild a new image with the latest updates:
make update-makefile && make update setup openmoko-devel-image

===Reporting Problems===

First, make sure that the problem is reproducable after running

make update-makefile ; make update ; make setup

then running

make clean-package-<foo>

(where you replace <foo> with the name of the package which is failing)

then running

make all

If you can get the error to occur three times in a row after running that sequence of commands three times, then feel free to report it to rwhitby in #openmoko on [http://wiki.openmoko.org/wiki/Development_resources#IRC IRC].

===Work-arounds===

Work-arounds for temporary or isolated problems should be added to the [[Talk:MokoMakefile|Discussion page]] which is associated with this page. As they are fixed, they will be removed from that page.

===Tips===
*You can reduce the amount of consumed disk space significantly by adding
INHERIT += "rm_work"
in your local.conf (e.g. /home/moko/build/conf/local.conf). This will remove the contents of each build/tmp/work/*/<package> directory after the corresponding package builds correctly.

*If you an encounter an error with monotone similar to the following:
mtn: misuse: database /home/moko/OE.mtn is laid out according to an old schema
Then you need to upgrade OE.mtn Use the following command while in /home/moko:
# mtn --db OE.mtn db migrate

*If a certain package does not build due to corrupted download or some such try to remove the sources and rebuild it.
rm sources/<package>*
cd build
. ../setup-env
bitbake -crebuild <package>
after that your build might just work again.

*For people with multiple CPU's (or dual-core ones) this small patch might be useful to build things faster.
Edit the local.conf and add the following lines:
PARALLEL_MAKE = "-j 4"
BB_NUMBER_THREADS = "4"

Change the PARALLEL_MAKE and BB_NUMBER_THREADS values to something that suits better if it chokes your machine.

*For amd64 host users you need the patch from http://bugs.openembedded.org/show_bug.cgi?id=1765 to build db3-native

===QEMU===
The MokoMakefile now has support for automatically building, flashing, and running [[OpenMoko under QEMU|the new Neo1973 emulator]] (which is based on QEMU).

Dependencies:

*lynx ('apt-get install lynx' in Ubuntu 7.04) /n
*netpbm ('apt-get install netpbm' in Ubuntu 7.04)

“make qemu” will build qemu-neo1973, download the latest official OpenMoko images, flash the images into the virtual NAND flash, and run the emulator (you still need to install the makefile as mentioned above, however).

Other targets are “make download-images” (to download the latest official images), “make flash-qemu-official” (to flash those images) and “make flash-qemu-local” (which will flash your latest locally built images), which can then be followed by “make run-qemu” or “make run-qemu-snapshot” to run the emulator with the most recently flashed images.

Make sure you have the “lynx” and “netpbm” packages installed on your build host first.

You're also invited to read more about how to run [[OpenMoko under QEMU]] in the article dedicated to this subject.

===Developing with MokoMakefile===

To make in-tree changes and have them built and used by qemu:

cd /home/moko/openmoko
quilt new descriptive-patch-name.patch
quilt add trunk/src/name-of-file-to-change # do this for every file you are about to modify
...make the changes...
quilt refresh # this creates a file in /home/moko/patches/openmoko-HEAD/ and updates the quilt series file there

Note: Do '''NOT''' use absolute paths as this confuses quilt and will get you a diff of the file against /dev/null!

To build the changes and have them used by qemu:

make build-qemu
make flash-qemu-local
make run-qemu

If you want to modify applications instead of the openmoko toolchain, this is what you have to do (example: openmoko-messages):

/usr/src/openmoko# . ./setup-env
/usr/src/openmoko# cd openmoko/
/usr/src/openmoko/openmoko# bitbake -c unpack openmoko-messages
/usr/src/openmoko/openmoko# cd \
../build/tmp/work/armv4t-linux/openmoko-messages-0.0.1+svnnow-r2_2276/openmoko-messages/
/usr/src/openmoko/build/tmp/work/armv4t-linux/openmoko-messages-0.0.1+svnnow-r2_2276/openmoko-messages# \
vim src/detail-area.c
/usr/src/openmoko/build/tmp/work/armv4t-linux/openmoko-messages-0.0.1+svnnow-r2_2276/openmoko-messages# \
cd -
/usr/src/openmoko/openmoko# bitbake openmoko-messages

Then continue with MokoMakefile usage.

If you want to add an application to your openmoko distribution, do this:
All file edits should be done using quilt as described above. That way a patch can easily be submitted to the openmoko project.
First, create a directory that will correspond to your package and edit a '''.bb''' file in there:
/usr/src/openmoko# cd openmoko/
/usr/src/openmoko/openmoko# quilt new mycoolpackage.patch
/usr/src/openmoko/openmoko# mkdir trunk/oe/packages/mycoolpackage
/usr/src/openmoko/openmoko# quilt add trunk/oe/packages/mycoolpackage/mycoolpackage_1.bb
/usr/src/openmoko/openmoko# quilt edit trunk/oe/packages/mycoolpackage/mycoolpackage_1.bb

The file should have the following content:
DESCRIPTION = "This is a cool package"
SECTION = "username/mycoolpackage"
PV = "1"

inherit autotools

SRC_URI = "http://www.example.com/download/mycoolpackage-1.tar.gz"

Explanation:
* DESCRIPTION - Just a short text explaining the package
* SECTION - I have no clue, but I'll use username/mycoolpackage for now
* PV - Package Version
* inherit autotools - The package can be compiled by './configure && make && make install' so we tell MokoMakefile to do it this way.
* SRC_URI = ... - This is the download location of the package source. It's imperative that the tar.gz contains a directory called '''packagename-packageversion''' (in this case: mycoolpackage-1) so that MokoMakefile can find it automatically or the build will fail.

This is not all. We also need to tell MokoMakfile that it needs to build and include the package in the image. To do this, do
/usr/src/openmoko/openmoko# quilt edit trunk/oe/packages/tasks/task-openmoko.bb
Here, increase the value '''PR''' by one and add '''mycoolpackage \''' (with the backslash!) just before the line reading '''# update-alternatives \'''.

Now run
/usr/src/openmoko/openmoko# quilt refresh
/usr/src/openmoko/openmoko# cd ..
/usr/src/openmoko# make update all

And if everything's alright you should now have an OpenMoko image to flash to your phone or run in qemu as described above.

===Testimonials===
MokoMakefile is recommended by 4 out of 4 new developers on #openmoko, with testimonials such as "For some reason last night I couldn't get my manual install of everything to work (bb complained about my bbpath I think) ... but with your makefile, it works great!", and "MokoMakefile rocks!".

Project page:
http://mokomakefile.projects.openmoko.org/

{{Languages|MokoMakefile}}

MokoMakefile

2007-07-12T23:28:54Z

Chooseopen: /* QEMU */

==MokoMakefile==
MokoMakefile is a fully automated way of setting up an OpenMoko development environment. It is an invaluable tool for getting new developers up and running with a build environment which is configured the same as all the other existing developers. It brings the same repeatability to build environment creation and maintenance as that which OpenEmbedded brings to the main task of actually building embedded software distributions.

Note that MokoMakefile does *not* replace bitbake, or svn, or monotone, or openembedded, or qmake, or anything else. It is a wrapper around all that to make it easy to set up and maintain a development environment that fully complies with the setup instructions published by OpenMoko. Note that you need about 7 GB of available disk space for MokoMakefile to succeed.

MokoMakefile is developed by [[User:RodWhitby|Rod Whitby]] - it is not an official product of OpenMoko (although I would be happy for them to pick it up and use it internally). If there is any discrepancy between the [[Building_OpenMoko_from_scratch|official OpenMoko build instructions]], and the operation of the MokoMakefile, then you should consider the official instructions to be correct.

=== Before you begin ===
'''Check that your /bin/sh (ls -l /bin/sh) is not linked to dash rather than bash.''' Using dash will cause you pain. This is true for a standard install of Ubuntu 7.04 (at least when installing from Live CD). If your /bin/sh points to /bin/dash, correct it with (as root):
ln -sf /bin/bash /bin/sh

If you have previously built with dash as your sh shell then your perl compile is probably broken. One symptom is that the build will error and whine about an 'Unterminated quote string' another symptom is a message that says 'You haven't done a "make depend" yet!' If you get these then you need to:
make clean-package-perl
make clean-package-perl-native
and rebuild.

If all else fails then just rm -rf the perl work dir and the perl stamps here's an i686 host example:
rm -rf build/tmp/work/i686-linux/perl-native-5.8.7-r3
rm -f build/tmp/stamps/i686-linux/perl*

As of r99, MokoMakefile has patches which should make it build correctly with dash.

=== Installation ===
Here are the steps to use it:

1 - Make sure your build host is set up according to:
http://www.openembedded.org/wiki/OEandYourDistro
2 - Create your $OMDIR directory:
mkdir /home/moko ; cd /home/moko
3 - Grab MokoMakefile:
wget http://www.rwhitby.net/files/openmoko/Makefile
4 - Set up the environment:
make setup
5 - Start building. Before starting a lenghty make process, check in Tips section about how to make Make multicore aware. You may want to modify the build/conf/local.conf file for your target (emulation/chroot) enviroment:
make openmoko-devel-image

This will set up the recommended directory structure as described in [[Building OpenMoko from scratch]], will download all the required software (from the right places with the right versions), and will immediately start building an image.

Once you have done this, you can choose to continue using the MokoMakefile to initiate your subsequent builds, or you can go into the build directory and run bitbake commands manually. The choice is yours.

===Updating the environment===
For easy maintenance of your build environment the following commands are available.

1 - To update the MokoMakefile to the latest version:
make update-makefile

2 - To update the OpenMoko repository checkout and the MokoMakefile patches to the latest version:
make update

3 - To make sure that any recent changes to the build directory structure have been applied:
make setup

A quick way to rebuild a new image with the latest updates:
make update-makefile && make update setup openmoko-devel-image

===Reporting Problems===

First, make sure that the problem is reproducable after running

make update-makefile ; make update ; make setup

then running

make clean-package-<foo>

(where you replace <foo> with the name of the package which is failing)

then running

make all

If you can get the error to occur three times in a row after running that sequence of commands three times, then feel free to report it to rwhitby in #openmoko on [http://wiki.openmoko.org/wiki/Development_resources#IRC IRC].

===Work-arounds===

Work-arounds for temporary or isolated problems should be added to the [[Talk:MokoMakefile|Discussion page]] which is associated with this page. As they are fixed, they will be removed from that page.

===Tips===
*You can reduce the amount of consumed disk space significantly by adding
INHERIT += "rm_work"
in your local.conf (e.g. /home/moko/build/conf/local.conf). This will remove the contents of each build/tmp/work/*/<package> directory after the corresponding package builds correctly.

*If you an encounter an error with monotone similar to the following:
mtn: misuse: database /home/moko/OE.mtn is laid out according to an old schema
Then you need to upgrade OE.mtn Use the following command while in /home/moko:
# mtn --db OE.mtn db migrate

*If a certain package does not build due to corrupted download or some such try to remove the sources and rebuild it.
rm sources/<package>*
cd build
. ../setup-env
bitbake -crebuild <package>
after that your build might just work again.

*For people with multiple CPU's (or dual-core ones) this small patch might be useful to build things faster.
Edit the local.conf and add the following lines:
PARALLEL_MAKE = "-j 4"
BB_NUMBER_THREADS = "4"

Change the PARALLEL_MAKE and BB_NUMBER_THREADS values to something that suits better if it chokes your machine.

*For amd64 host users you need the patch from http://bugs.openembedded.org/show_bug.cgi?id=1765 to build db3-native

===QEMU===
The MokoMakefile now has support for automatically building, flashing, and running [[OpenMoko under QEMU|the new Neo1973 emulator]] (which is based on QEMU).

Dependencies:
lynx ('apt-get install lynx' in Ubuntu 7.04)
netpbm ('apt-get install netpbm' in Ubuntu 7.04)

“make qemu” will build qemu-neo1973, download the latest official OpenMoko images, flash the images into the virtual NAND flash, and run the emulator (you still need to install the makefile as mentioned above, however).

Other targets are “make download-images” (to download the latest official images), “make flash-qemu-official” (to flash those images) and “make flash-qemu-local” (which will flash your latest locally built images), which can then be followed by “make run-qemu” or “make run-qemu-snapshot” to run the emulator with the most recently flashed images.

Make sure you have the “lynx” and “netpbm” packages installed on your build host first.

You're also invited to read more about how to run [[OpenMoko under QEMU]] in the article dedicated to this subject.

===Developing with MokoMakefile===

To make in-tree changes and have them built and used by qemu:

cd /home/moko/openmoko
quilt new descriptive-patch-name.patch
quilt add trunk/src/name-of-file-to-change # do this for every file you are about to modify
...make the changes...
quilt refresh # this creates a file in /home/moko/patches/openmoko-HEAD/ and updates the quilt series file there

Note: Do '''NOT''' use absolute paths as this confuses quilt and will get you a diff of the file against /dev/null!

To build the changes and have them used by qemu:

make build-qemu
make flash-qemu-local
make run-qemu

If you want to modify applications instead of the openmoko toolchain, this is what you have to do (example: openmoko-messages):

/usr/src/openmoko# . ./setup-env
/usr/src/openmoko# cd openmoko/
/usr/src/openmoko/openmoko# bitbake -c unpack openmoko-messages
/usr/src/openmoko/openmoko# cd \
../build/tmp/work/armv4t-linux/openmoko-messages-0.0.1+svnnow-r2_2276/openmoko-messages/
/usr/src/openmoko/build/tmp/work/armv4t-linux/openmoko-messages-0.0.1+svnnow-r2_2276/openmoko-messages# \
vim src/detail-area.c
/usr/src/openmoko/build/tmp/work/armv4t-linux/openmoko-messages-0.0.1+svnnow-r2_2276/openmoko-messages# \
cd -
/usr/src/openmoko/openmoko# bitbake openmoko-messages

Then continue with MokoMakefile usage.

If you want to add an application to your openmoko distribution, do this:
All file edits should be done using quilt as described above. That way a patch can easily be submitted to the openmoko project.
First, create a directory that will correspond to your package and edit a '''.bb''' file in there:
/usr/src/openmoko# cd openmoko/
/usr/src/openmoko/openmoko# quilt new mycoolpackage.patch
/usr/src/openmoko/openmoko# mkdir trunk/oe/packages/mycoolpackage
/usr/src/openmoko/openmoko# quilt add trunk/oe/packages/mycoolpackage/mycoolpackage_1.bb
/usr/src/openmoko/openmoko# quilt edit trunk/oe/packages/mycoolpackage/mycoolpackage_1.bb

The file should have the following content:
DESCRIPTION = "This is a cool package"
SECTION = "username/mycoolpackage"
PV = "1"

inherit autotools

SRC_URI = "http://www.example.com/download/mycoolpackage-1.tar.gz"

Explanation:
* DESCRIPTION - Just a short text explaining the package
* SECTION - I have no clue, but I'll use username/mycoolpackage for now
* PV - Package Version
* inherit autotools - The package can be compiled by './configure && make && make install' so we tell MokoMakefile to do it this way.
* SRC_URI = ... - This is the download location of the package source. It's imperative that the tar.gz contains a directory called '''packagename-packageversion''' (in this case: mycoolpackage-1) so that MokoMakefile can find it automatically or the build will fail.

This is not all. We also need to tell MokoMakfile that it needs to build and include the package in the image. To do this, do
/usr/src/openmoko/openmoko# quilt edit trunk/oe/packages/tasks/task-openmoko.bb
Here, increase the value '''PR''' by one and add '''mycoolpackage \''' (with the backslash!) just before the line reading '''# update-alternatives \'''.

Now run
/usr/src/openmoko/openmoko# quilt refresh
/usr/src/openmoko/openmoko# cd ..
/usr/src/openmoko# make update all

And if everything's alright you should now have an OpenMoko image to flash to your phone or run in qemu as described above.

===Testimonials===
MokoMakefile is recommended by 4 out of 4 new developers on #openmoko, with testimonials such as "For some reason last night I couldn't get my manual install of everything to work (bb complained about my bbpath I think) ... but with your makefile, it works great!", and "MokoMakefile rocks!".

Project page:
http://mokomakefile.projects.openmoko.org/

{{Languages|MokoMakefile}}

Hardware:Neo1973:Alternate Cases:Removal of free space

2007-07-11T05:25:50Z

Chooseopen: /* Interest */

=Concept==
There is unnecessary free space within the case - this variant would remove that, possibly with some re-arrangement of components, to make the phone slightly smaller.

==Rendered images==

==3D model==

==Materials==

==Processes==
Stereolithography

==Components==

==Interest==
Leave your nickname here if you are interested in having one made. This is not an order form, but is intended to gauge interest before effort is expended designing the case. 

{|
!No !! Nick !!
|-
|1. Chooseopen
|-
|2.
|}

[[Category:Neo1973_alternate_cases]]

Hardware:Neo1973:Alternate Cases:Removal of free space

2007-07-11T05:25:16Z

Chooseopen: