Openmoko - User contributions [en]

Mac OS X

2007-09-20T20:39:57Z

Eric: /* Using virtualization software */

Welcome to the OpenMoko page devoted to MacOS X users!

Here you can find notes of using Neo1973 (and maybe other OM devices) with Mac.

= Flashing to your device =
To operate the Phase 1 devices, you need to flash a root file system first.

NOTE: you need an Intel Mac to run [[dfu-util]] since it is currently broken on big-endian machines (PowerPC).

Here is a detailed instruction:
# If you don't have Mac OS X 10.4.10 (Apple already ships a more stable CDC ECM driver, and DFU through libusb doesn't need a driver at all):
## download the latest version of AJZaurusUSB from http://www.dsitri.de/wiki.php?page=AJZaurusUSB
## install
## run 'sudo kextload /System/Library/Extensions/AJZaurusUSB.kext' from Terminal (or reboot your Mac as described - but you do not need to configure AJZaurusUSB it before flashing the OpenMoko)
# download the latest version of OpenMoko Flasher from http://www.dsitri.de/wiki.php?page=OpenMoko%20Flasher
# [V1.0 only: create a new Folder at "~/Library/Caches/OpenMoko Flasher"]
# press the Refresh button (which loads the list of packages on the server)
# select and load the rootfs (takes some minutes for approx. 40 MByte)
# [V1.0 and V1.1 only: open the Console application and show the console.log]
# Now, on your OpenMoko, hold the AUX button while pressing the Power button for 5 seconds
# the BOOT menu should appear
# connect the USB cable
# Press the Flash button
# the BOOT menu screen on the OM should show an indication that it has been switched to DFU mode
# if it fails), unplug the OpenMoko shortly and replug and try again (experience shows that it is needed up to three times)
# if it successfully flashed, you should be able to boot the OpenMoko and continue configuring AJZaurusUSB

The dfu-utils tool is included in the OpenMoko Flasher application; you can access it as ''OpenMoko Flasher.app/Contents/MacOS/dfu-util'' ; alternatively, you can compile dfu-util manually as described at http://wiki.openmoko.org/wiki/User:SNMoore

= Connecting to your device =

== USB Serial ==

It is possible to access the U-Boot [[Bootloader]] serial console from a Mac. You can use the Terminal application on Mac OS X, or <tt>minicom</tt> from [http://finkproject.org/ Fink] or [http://www.macports.org/ MacPorts] (formerly Darwin Ports.)

The USB driver creates cu and tty character devices, for example
$ ls -la /dev/tty.usb*
crw-rw-rw- 1 root wheel 10, 18 Aug 23 14:10 /dev/tty.usbmodem00000001
$ ls -la /dev/cu.usb*
crw-rw-rw- 1 root wheel 10, 19 Aug 23 14:10 /dev/cu.usbmodem00000001

=== USB Serial with screen ===

The <code>screen</code> program is included with Mac OS X, and can be used from the terminal command line to connect to the serial console. To do this, simply get to a shell prompt in the terminal and invoke <code>screen</code> as follows:
<pre>
% screen /dev/ttyusbmodem00000001
</pre>

You should find yourself at the U-boot serial console prompt. To get out, type <code>control+a</code> followed by <code>control+backslash</code>.

=== USB Serial with minicom ===

The <tt>minicom</tt> program from the [http://www.macports.org/ MacPorts] collection can be used to access the USB serial port <tt>/dev/cu.usbmodem00000001</tt> (numbering may vary.)

First install the program (assuming you already have MacPorts installed):

sudo port install minicom

Then launch it in configuration mode (the -s flag):

sudo minicom -s

Under "Serial Port Setup", set the Device to "/dev/cu.usbmodem00000001" and set Bps to "115200 8N1". Under "Modem and Dialing", enter empty strings for "Init string", "Reset string", and "Hang-up string". Save the setup as default ("dfl") then Exit.

You should now be able to access the bootloader console. You should exit from Minicom before disconnecting the smartphone, or else you will get an error about unplugging a USB device while it is in use.

=== USB Serial with Terminal ===

The built in Mac Terminal application <tt>Terminal.app</tt> can be used to access the USB serial port <tt>/dev/tty.usbmodem00000001</tt> (numbering may vary.)

An easy way to do this is to configure the terminal with Script Editor, as described in the short article, [http://www.macosxhints.com/article.php?story=20061109133825654 ''Use 'screen' as a serial terminal emulator''](macosxhints.com). Then,

# Press and hold {{aux}} and then press and hold {{power}} for 5 seconds
# Press {{aux}} to select <tt>Set console to USB</tt> in the U-Boot menu, and {{power}} to execute it
# Start the serial terminal application. You should see a U-Boot command line prompt, such as
In: usbtty
Out: usbtty
Err: usbtty
DEVICE_CONFIGURED: 1
Enabling automatic fast charge
GTA01Bv4 #
When you boot Linux on the smartphone, or if the smartphone powers down, Mac OS X will show a USB Device Unplug Notice, "The USB device has been unplugged while an application was still active. This can result in loss of data." This error is probably harmless.

== USB Networking ==

You can telnet, SSH, SMB or do whatever you want if you install software that enables you to set up TCP/IP network over your USB connection.

MacOS X does not provide such a driver for RNDIS/Ethernet Gadget. But you can use an open source (GPL) universal driver http://www.dsitri.de/wiki.php?page=AJZaurusUSB which is developed for handheld devices like iPAQ, Sharp Zaurus, and Motorola A760. Download it and install according to manual found inside of the package.

After reboot, you should have a new Ethernet interface in your System Preferences/Network. Set up the network manually for that interface by using these addresses:
<pre>
IP-V4: manual
IP-Addr: 192.168.0.200
Subnet: 255.255.255.0
Router: 192.168.0.202
</pre>
This might conflict with some WLAN routers which also use the 192.168.0.0 network.

You should be able to connect to your Neo! Try using ping 192.168.0.202 and the roundtrip time should be between 1 and 2 ms.

NOTE: the software is sometimes a bit flaky, and a reboot of the Mac seems to bring it back. It is especially critical about hot unplugging the OM and sleep modes of MacBooks. This may even result in a Kernel Panic.

== Telnet, ssh, SMB ==

To Be Done.

=== ssh ===

After making the USB connection work, start ssh:

ssh -l root 192.168.0.202

If you don't have installed the key, it will ask for a "yes" on the first connection and for a password on each other. This is "root" unless you change it.

MacBook-hns:~ hns$ ssh -l root 192.168.0.202
root@192.168.0.202's password:
root@fic-gta01:~$ hostname
fic-gta01
root@fic-gta01:~$

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.

== Bluetooth ==

To Be Done. See also: [[Bluetooth_Support#PPP_Networking]].

== WiFi ==

To Be Done.

= Synchronizing =

This is not done yet. Possible solutions are SyncML or ZMacSync http://www.dsitri.de/wiki.php?page=ZMacSync

ZMacSync does not yet synchronize but allows more easy access to the OpenMoko through Terminal/ssh.

= Sharing connection =

== Mac as a server ==

Here is described how to enable your Mac to serve as a internet router for your OpenMoko device.

Go to Control Panel, click Sharing and click the Internet tab. Check all the ethernet (en) interfaces you want to enable Internet access for.

SSH into your Neo and create /etc/resolv.conf, specify your Internet router IP address as the name server.

Example:

nameserver 192.168.1.200

=== Bluetooth ===

This could help:

http://wiki.openmoko.org/wiki/Bluetooth_Support#Networking

http://www.macosxhints.com/article.php?story=20051220221237711

=== USB ===

If you install AJZaurusUSB driver you should be able to set up your Mac as a router (not tested).

== Neo1973 as a server ==

To Be Done.

= Developing software =

== Using virtualization software==

You can use Parallels or VMWare to install your favourite Linux distribution and then develop just as on Linux.

There are some drawback since AFAIK dfu-util may not work correctly in such environments.

Don't bother with Parallels Desktop for Mac (<=3), the current USB support is terrible and USB storage keys don't even work so there was no way I would try dfu-util. USB keys work under VMWare Fusion for Mac though I have yet to try dfu-util in an VM under VMWare Fusion as there is OpenMoko Flasher for Mac. -- [[User: Eric|Eric]]

== Natively ==

There are some efforts to get through process of compiling OE and OpenMoko under mac: [[OpenMoko_under_QEMU_on_MacOSX]]

[[Category:Developer software]]

= Other Resources =

== Search Software Repositories ==

[[http://www.versiontracker.com/php/qs.php?action=search&str=openmoko&srchArea=macosx Keyword OpenMoko]] at VersionTracker

== Discussion Fora ==

[[http://www.oesf.org/forums/index.php?showforum=63 Mac Issues Forum]] at Open Embedded Software Foundation (was Zaurus User Group)

Openmoko Local Groups: Montreal

2007-09-10T08:39:44Z

Eric: reorganized, added a meetings section

Welcome to the Montreal OpenMoko Enthusiasts page!

<pre>
Please update this page with any information about local OpenMoko happenings that you might know about.
</pre>

== Meetings ==
The following are a list of past and present meetups and demos in and around Montreal.

=== Future ===

{|border=1
!Date
!Type
!Host
!Location
!Remarks
|-
|2007-10-14
|MeetUp
|[[User:Eric|Eric Preston]]
|Mile End, Montreal
|I'm hosting regular, informal OpenMoko sessions at my apartment in Mile End. I plan to have one at least every month. Goto http://eric.linuxmontreal.com/contact to send me an email asking for directions and to reserve your spot. There is room for about 6-8 people.
|}

=== Past ===

{|border=1
!Date
!Type
!Host
!Location
!Remarks
|-
|2007-09-09
| Meetup
|[[User:Eric|Eric Preston]]
|Mile End, Montreal
|A couple of people met up at Eric's place to check out his Neo1973 GTA01Bv4 kits.
|}

== People ==
The following is a list of people interested in OpenMoko from in and around Montreal.
{|border=1
!Name
!Skills
!Level of Interest
!Location
!Other
|-
|[[User:Eric|Eric Preston]]
|Freelance Developer
|Owner, Neo1973 Advanced, Base
|Montreal
|Organizing meetups as discussed above.
|-
|[[User:Opampca|Richard Lussier]]
|Community networking
|Getting a free phone developped for ISF network
|Montreal
|Part of [http://www.ilesansfil.org/ Ile Sans Fil]
|-
|[[User:Skwid|Benjamin Crulli]]
|Programming
|Developing some apps related to wifi hotspots
|Montreal
|Part of [http://www.ilesansfil.org/ Ile Sans Fil]
|-
|[[User:Youlian|Youlian Troyanov]]
|Programming
|Developing apps
|Montreal
|Mobile c++/java developer
|-
|[[User:Avoine|Patrick Hétu]]
|Programming
|Developing apps
|Montreal
|C/Python developer
|}

See [[Talk:OpenMoko_Local_Groups:_Montreal|discussion]]

[[Category:Community]]

Openmoko Local Groups: Montreal

2007-07-30T18:32:11Z

Eric: contact info

Welcome to the Montreal openmoko page!

Hopefully we'll be able to organise an event for when a few of us get the neos - please also keep the page updated with any interest you get from your local LUGs.

{|border=1
!Name
!Skills
!Level of Interest
!Location
!Other
|-
|[[User:Eric|Eric Preston]]
|Freelance Developer
|Owner, Neo1973 Advanced
|Montreal
|http://www.linuxmontreal.com, Willing to organize event immediately, drop me an email from my website.
|-
|[[User:Opampca|Richard Lussier]]
|Community networking
|Getting a free phone developped for ISF network
|Montreal
|Part of [http://www.ilesansfil.org/ Ile Sans Fil]
|-
|[[User:Skwid|Benjamin Crulli]]
|Programming
|Developing some apps related to wifi hotspots
|Montreal
|Part of [http://www.ilesansfil.org/ Ile Sans Fil]
|-
|[[User:Youlian|Youlian Troyanov]]
|Programming
|Developing apps
|Montreal
|Mobile c++/java developer
|}

See [[Talk:OpenMoko_Local_Groups:_Montreal|discussion]]

[[Category:Community]]

Openmoko Local Groups: Montreal

2007-07-30T18:27:42Z

Eric: got my phone this morning

Welcome to the Montreal openmoko page!

Hopefully we'll be able to organise an event for when a few of us get the neos - please also keep the page updated with any interest you get from your local LUGs.

{|border=1
!Name
!Skills
!Level of Interest
!Location
!Other
|-

|[[User:Eric|Eric Preston]]
|Driver/Developer
|Owner, Neo1973 Advanced
|Montreal
|http://www.linuxmontreal.com, Willing to organize event immediately!}
-
|[[User:Opampca|Richard Lussier]]
|Community networking
|Getting a free phone developped for ISF network
|Montreal
|Part of [http://www.ilesansfil.org/ Ile Sans Fil]
|-
|[[User:Skwid|Benjamin Crulli]]
|Programming
|Developing some apps related to wifi hotspots
|Montreal
|Part of [http://www.ilesansfil.org/ Ile Sans Fil]
|-
|[[User:Youlian|Youlian Troyanov]]
|Programming
|Developing apps
|Montreal
|Mobile c++/java developer
|}

See [[Talk:OpenMoko_Local_Groups:_Montreal|discussion]]

[[Category:Community]]

Building OpenMoko 2007.1 from scratch

2007-07-10T13:44:00Z

Eric: /* OpenEmbedded build */

{|align=right
|__TOC__
|}

{{warning|This is still a preliminary version, which will take some more days until it has all the updates.}}

This is a guide describing how to set up a running OpenMoko
system from scratch.

If you just want to run OpenMoko applications on your PC, just perform the
"Obtaining OpenMoko SVN tree" step below and then go to
[[How to run OpenMoko Apps on PC]]. If you want to autoinstall all required tools and resources, consider using [[MokoMakefile]] -- script developed by Rod Whitby.

Do not treat this as a linear script! There are various configuration items you
need to set (or skip, as it may be), operations that depend on how your
host(s) is/are set up, and also on the hardware revision of the target platform
(i.e., the phone).

Instead, look at each step, read the instructions, copy and paste what
makes sense for you, and adapt what you disagree with. Links to original and
background material in the Wiki are included wherever useful.

== Preparation ==

=== Roles ===

The build process may spread over multiple machines. They have the following
roles:

;'''BUILD''': build host, with quick access to the files and CPU power. Must have Internet access.
;'''LAB''': lab machine connected to the debug board (serial and JTAG) and to USB on the Neo (since this will probably be just a single machine, the roles are not further divided)
;'''CARD''': machine with a USB-attached SD/MMC card reader

All machines are assumed to share the same filesystem layout. At the beginning of
each of the sections below, the respective role is indicated. "('''all''')" is for
settings that apply to all machines, or that - for simplicity - can be
applied to all of them.

=== Directory layout ===
'''(Roles: all)'''

<pre>
$OMDIR (/home/moko) base directory for the whole tree
openmoko/ files from OpenMoko subversion (SVN) repository
openembedded/ files from OpenEmbedded (OE) Monotone repository
sources/ cached downloads of OE
build/ OE build directory
</pre>

=== Environment variables ===
'''(Roles: all)'''

For simplicity, we just set these environment variables on all hosts
involved. If you're not comfortable with this, feel free to weed out the ones
you don't need.

Our base directory (configure this for local arrangements):

export OMDIR=/home/moko

The search path for BitBake files. Note that the order is of vital
importance.

export BBPATH=$OMDIR/build:$OMDIR/openmoko/trunk/oe:$OMDIR/openembedded

=== Permissions ===
'''(Role: BUILD)'''

In order to perform the build process, you have to obtain the following
permissions:

* write access to the OpenMoko SVN repository (in principle, it should be possible to simplify this to read access. For further study.)

=== Build host prerequisites ===
'''(Role: BUILD)'''

There must be at least 7 GB of free space on $OMDIR.

In addition to the traditional development tools (gcc, patch, etc.), the
following packages must be installed on the build host:

;subversion: version control system used by OpenMoko and others.
;quilt: patch management system used by the Linux kernel and others
;monotone: version control system used by OpenEmbedded. This should be a recent version, e.g., 0.32, although also 0.31 should work.
;diffstat: the OE build process wants this
;texi2html: this too
;git: version control system used by the Linux kernel and others. Do not confuse this with the "GNU Interactive Tools"

Furthermore, the following package can be installed optionally:
;psyco: Python just-in-time compiler. Speeds up OpenEmbedded builds (with BitBake) considerably. Strongly recommended.

==== Distro Specific Software Installation ====
;Gentoo: Gentoo users can obtain all this with (note that, at the time of writing, Monotone 0.32 isn't available without setting the ~x86 keyword):
<pre>
echo 'dev-util/monotone ~'`readlink /etc/make.profile | awk -F / '{print $6}'`\
>>/etc/portage/package.keywords
emerge -u subversion quilt monotone diffstat texi2html dev-util/git psyco
</pre>
;Other Distos: [http://www.openembedded.org/wiki/OEandYourDistro Instructions for installing prerequisites in other distributions]

=== Lab host prerequisites ===
'''(Role: LAB)'''

The following package must be installed on the lab host:
;xc: a simple communications program for the serial port

Gentoo users can obtain this with:
emerge -u xc

Note that similar communications programs, such as "cu" or "minicom", may be used as well.

=== Assumptions ===
'''(Roles: LAB, CARD)'''

We make the following assumptions about hardware setup and devices:

* the serial console of the Neo phone is connected to /dev/ttyS0 on '''LAB''' (see [[Debug_Board]])
* the JTAG [[wiggler]] is connected to /dev/parport0 on '''LAB'''. See [[Debug Board]] and [[Connecting_GTA01Bv2_with_Debug_Board]]
* cards inserted in the SD/MMC card reader appear as /dev/uba on '''CARD''' and can be mounted on /mnt/tmp (we'll specify the mount point explicitly, so the directory has to be there, but we don't need to specify the mount point in /etc/fstab). If in doubt,
mkdir -p /mnt/tmp

== Obtaining Sources and build system ==

=== OpenEmbedded build: initial downloads ===

First, we obtain a snapshot of the OpenEmbedded-based tree used by OpenMoko, plus the OE build tool called BitBake.

==== Obtaining OpenMoko SVN tree ====
'''(Role: BUILD)'''

Obtain the latest revision of the OpenMoko tree. Unfortunately, at some places, "current" versions of upstream packages may get included, thus the build may still fail. If it does, you may wish to inform the authorities.

The checkout should take about 45 minutes over an Internet connection with a round-trip time to svn.openmoko.org of 350 ms.

<pre>
cd $OMDIR
svn co http://svn.openmoko.org/ openmoko
</pre>

{{note|If the local user name does not match the user name with which you access SVN, you can put your username in the url you use to checkout:
svn+ssh://joe@stuff.org/svn/stuff
}}

==== Installing BitBake ====
'''(Role: BUILD)'''

Install version 1.6 of BitBake, the build tool of OE. (This is quick.)

<pre>
svn co http://svn.berlios.de/svnroot/repos/bitbake/branches/bitbake-1.6/ bitbake
cd bitbake
./setup.py install
cd ..
</pre>

==== Obtaining OpenEmbedded snapshot ====
'''(Role: BUILD)'''

Obtain a snapshot of the Monotone repository of OpenEmbedded, then update it
to the latest version, and finally check out our "known to be good" revision.
We extract things into $OMDIR/openembedded. OE.mtn.bz2 is about 100 MB.

<pre>
wget http://www.openembedded.org/snapshots/OE.mtn.bz2
bunzip2 OE.mtn.bz2
mtn --db=OE.mtn pull monotone.openembedded.org org.openembedded.dev
mtn --db=OE.mtn checkout --branch=org.openembedded.dev \
-r e2dbb52fe39df7ef786b6068f6178f29508dfded openembedded
</pre>

{{note|For advanced users: if you ever want to update to the latest version of the repository, you would do a "pull" (see above), followed by:
cd $OMDIR/openembedded && mtn update}}

Set up the directories for the cache of upstream files and all material
related to local builds, then put our configuration file there (see also
[[OpenMoko#Setting_up_an_OpenMoko_SDK]]):

<pre>
mkdir -p sources build/conf
cat <<EOF >build/conf/local.conf
MACHINE = "fic-gta01"
DISTRO = "openmoko"
BUILD_ARCH = "`uname -m`"
EOF
</pre>

=== OpenEmbedded build: fixes ===
'''(Role: BUILD)'''

There are unfortunately some problems in the build process.
The following fixes work around them:

cd $OMDIR/sources
mkdir -p ../build/tmp/stamps/armv4t-linux

* upstream moves old packages away, gratuitously breaking downstreams

wget http://ftp.mozilla.org/pub/mozilla.org/js/older-packages/js-1.5.tar.gz
touch ../build/tmp/stamps/armv4t-linux/js-1.5-r0.do_fetch

* us2.samba.org mirror has vanished

wget http://us4.samba.org/samba/ftp/stable/samba-3.0.14a.tar.gz
touch ../build/tmp/stamps/armv4t-linux/samba-3.0.14a-r15.do_fetch

* ghastly patch with CRLF and trailing blanks

perl -pi.orig -e 's/ *$//;s/\r//g' \
../openembedded/packages/gcc/gcc-4.1.1/gcc-4.1.1-pr13685-1.patch

== Building ==

=== OpenEmbedded build ===
'''(Role: BUILD)'''

openmoko/trunk/oe/conf/site.conf expects the OpenMoko-specific OE packages in $OMDIR/oe

cd $OMDIR
ln -s openmoko/trunk/oe ./oe

We're now ready to run the build. This will take a while.

cd $OMDIR/build
bitbake openmoko-devel-image

Note that the build will stop several times to ask for SVN access and whether
to accept certificates. If you're not quick enough to respond, the underlying
session may time out. In this case, just restart "bitbake
openmoko-devel-image" and it will pick up from where it left off.

The whole build process involves numerous downloads, takes about 7 hours
on an Athlon 64 3200+ (about 1.5h of delays were caused by ftp.debian.org not
working properly during this test run), and ends with a message like this:

Build statistics:
Attempted builds: 4

== Installation ==

=== Flash boot loader into NAND ===
'''(Role: LAB)'''

As a first step, we transfer the u-boot bootloader into NAND Flash, through
the JTAG interface. We use JTAG, since this is the most basic way for doing
this, ensuring that we only depend on as little to work on the Neo as
possible.

For this, the u-boot image for the right board version and the desired
build date must be chosen. E.g., an image built for a gta01bv2 board on
February 3, 2007 at 13:40:41 would be called
u-boot_nand-gta01bv2-20070203134041.bin

The name is composed as follows:
;u-boot: the name of the component
;nand: it is it be loaded from NAND (not directly from RAM, see also [[Bootloader#Using_JTAG_to_boot_from_RAM]])
;gta01bv2: the hardware revision of the board
;20070203134041: the build date and time
;.bin: this is a binary suitable for flashing/loading

If this is the first build, there will only be one image for each board
version, thus we can use wildcards. Change the gta01bv2 below to gta01v3 or
gta01v4, if necessary.

See also: [[Sjf2410-linux]]

<pre>
cd $OMDIR/build/tmp/deploy/images

( echo 0; echo 0; echo 0; echo 3; ) |
./sjf2410 -b -f `echo u-boot_nand-gta01bv2-*.bin`
</pre>

This will take approximately 12 minutes.

=== Copy kernel and root FS to microSD card ===
'''(Role: CARD)'''

There are several ways to provide the Neo with its kernel and the root file
system. (See [[Bootloader]] for some of them.)
The most self-contained way is to put everything into NAND Flash.
To transfer the files to the Neo, we first place them on the microSD card.

Memory cards, including microSD, usually come pre-formatted with VFAT. We
prefer ext2 (e.g., because we may want to store a real Linux file system on the
card as well). The following steps are needed to convert the card from VFAT to
ext2:
<pre>
sfdisk -c /dev/uba 1 83
mke2fs -m0 /dev/uba1
tune2fs -c0 -i0 /dev/uba1
</pre>

Next, we copy the kernel uImage and the root file system image to the card.
As discussed in the previous section, we can use wildcards if this is our
first build.
<pre>
cd $OMDIR/build/tmp/deploy/images
mount /dev/uba1 /mnt/tmp
cp uImage-2.6-moko7-r1-fic-gta01-*.bin /mnt/tmp/uImage
cp openmoko-devel-image-fic-gta01-*.rootfs.jffs2 /mnt/tmp/rootfs.jffs2
umount /mnt/tmp
</pre>

Now, insert the microSD card into the Neo, but don't power it on yet.
(If you did anyway, don't worry. We'll power cycle it later.)

=== Serial console ===
'''(Role: LAB)'''

We use a serial console connecting through the debug board. This example uses
"xc", which is a small and simple communications program. Many people prefer
"cu" or the considerably more bloated "minicom", which will work as well.

* Prepare xc configuration
<pre>
cat <<EOF >$HOME/xc.init
set bps 115200
terminal
EOF
</pre>

* Connect to the target
xc -l /dev/ttyS0 -t

=== Start the Neo and enter the boot prompt ===
'''(Role: LAB)'''

Our first interaction with the target. If this doesn't work, please check
that the debug board is connected properly to the serial port.

Disconnect power and USB from the phone, wait a couple of minutes, then connect power.
You may have to press and hold the power button on the Neo for a few seconds to turn it on.
The power button is located next to the USB port.

Some people have observed stability issues if the device was reset without
power cycling or if USB was not disconnected when power cycling, yet details of what is really happening aren't very clear yet.

On the serial console, a message like this should appear:
<pre>
U-Boot 1.2.0 (Feb 3 2007 - 13:07:21)
Press any key to enter the boot prompt:
GTA01Bv2 #
</pre>

Note that the boot prompt changes with the hardware revision you have. If the
message does not appear after a few seconds, try power cycling again.

If xc responds to pressing a button with
"Verify that you are trying to use a valid and operational tty port."
the port may be stuck, waiting for DCD to be asserted. The quickest way to
get out of this situation is to disconnect the serial cable from the debug
board, run the following command
while ! stty -F /dev/ttyS0 clocal; do : ; done

stick something metallic, e.g., a paper clip or a screwdriver, into the plug on the cable,
and keep on fumbling with
it until DCD gets set and the loop above stops spitting out error messages.

=== Flash kernel and root FS into NAND ===
'''(Role: LAB)'''

We now load the kernel and the root FS from the microSD card into memory and
subsequently transfer them to NAND Flash. All this is done by entering
commands at the boot prompt.

Each time we want to write new data to the NAND Flash, we first have to erase
the previous content. We do this individually for each partition. While it would
also be possible to erase some or all relevant partitions in one step, this would
require the user to look up addresses from the partition table and to perform
calculations which are inconvenient at best.

See also: [[U-boot]]

* Initialize the SD/MMC interface. The "Product Name" shown will be just binary garbage. This is expected behaviour.

GTA01Bv2 # mmc

* Load the uImage file into memory. "ext2load" stores the number of bytes read as a hexadecimal number in the environment variable "filesize".

GTA01Bv2 # ext2load mmc 0 0x32000000 uImage

* Erase the kernel partition and write the uImage from memory to NAND Flash

GTA01Bv2 # nand erase kernel
GTA01Bv2 # nand write.e 0x32000000 kernel ${filesize}

* The root file system is next. We need to specify the correct size, which is shown at the end of "ext2load", e.g., "0x1608000)" in this case:

GTA01Bv2 # ext2load mmc 0 0x32000000 rootfs.jffs2
23101440 (0x1608000) bytes read
GTA01Bv2 # nand erase rootfs
GTA01Bv2 # nand write.e 0x32000000 rootfs ${filesize}

=== Configure the boot loader ===
'''(Role: LAB)'''

Last but not least, we have to set up the boot loader to automatically boot
from Flash. For this, we use the default environment settings, which we obtain
by erasing the old content of the environment, and letting u-boot restore the
settings after a restart.

Before touching the environment, you may have to update the environment offset.
Please see [[Migration_to_bad_block_tolerant_builds#Partition_sizing]] for details.
(We may simplify this particularly awkward and error-prone procedure in the
future.)

* First, remove erase the old environment:
GTA01Bv2 # nand erase env

* We reset to force the boot loader to use the default settings.
GTA01Bv2 # reset

Wait until the "U-Boot [...]" message, then hit a key. It will display
*** Warning - bad CRC or NAND, using default environment

* Re-generate the partition information in the environment variable "mtdparts":

GTA01Bv2 # dynpart

* Save the restored settings in NAND
GTA01Bv2 # saveenv

* Power cycle to boot the Neo (see remarks above)

== END ==

'''Congratulations !''' You've just completed level 1 of the OpenMoko adventure.

Building OpenMoko 2007.1 from scratch

2007-07-10T13:18:44Z

Eric: doh, my bad. is still masked.

{|align=right
|__TOC__
|}

{{warning|This is still a preliminary version, which will take some more days until it has all the updates.}}

This is a guide describing how to set up a running OpenMoko
system from scratch.

If you just want to run OpenMoko applications on your PC, just perform the
"Obtaining OpenMoko SVN tree" step below and then go to
[[How to run OpenMoko Apps on PC]]. If you want to autoinstall all required tools and resources, consider using [[MokoMakefile]] -- script developed by Rod Whitby.

Do not treat this as a linear script! There are various configuration items you
need to set (or skip, as it may be), operations that depend on how your
host(s) is/are set up, and also on the hardware revision of the target platform
(i.e., the phone).

Instead, look at each step, read the instructions, copy and paste what
makes sense for you, and adapt what you disagree with. Links to original and
background material in the Wiki are included wherever useful.

== Preparation ==

=== Roles ===

The build process may spread over multiple machines. They have the following
roles:

;'''BUILD''': build host, with quick access to the files and CPU power. Must have Internet access.
;'''LAB''': lab machine connected to the debug board (serial and JTAG) and to USB on the Neo (since this will probably be just a single machine, the roles are not further divided)
;'''CARD''': machine with a USB-attached SD/MMC card reader

All machines are assumed to share the same filesystem layout. At the beginning of
each of the sections below, the respective role is indicated. "('''all''')" is for
settings that apply to all machines, or that - for simplicity - can be
applied to all of them.

=== Directory layout ===
'''(Roles: all)'''

<pre>
$OMDIR (/home/moko) base directory for the whole tree
openmoko/ files from OpenMoko subversion (SVN) repository
openembedded/ files from OpenEmbedded (OE) Monotone repository
sources/ cached downloads of OE
build/ OE build directory
</pre>

=== Environment variables ===
'''(Roles: all)'''

For simplicity, we just set these environment variables on all hosts
involved. If you're not comfortable with this, feel free to weed out the ones
you don't need.

Our base directory (configure this for local arrangements):

export OMDIR=/home/moko

The search path for BitBake files. Note that the order is of vital
importance.

export BBPATH=$OMDIR/build:$OMDIR/openmoko/trunk/oe:$OMDIR/openembedded

=== Permissions ===
'''(Role: BUILD)'''

In order to perform the build process, you have to obtain the following
permissions:

* write access to the OpenMoko SVN repository (in principle, it should be possible to simplify this to read access. For further study.)

=== Build host prerequisites ===
'''(Role: BUILD)'''

There must be at least 7 GB of free space on $OMDIR.

In addition to the traditional development tools (gcc, patch, etc.), the
following packages must be installed on the build host:

;subversion: version control system used by OpenMoko and others.
;quilt: patch management system used by the Linux kernel and others
;monotone: version control system used by OpenEmbedded. This should be a recent version, e.g., 0.32, although also 0.31 should work.
;diffstat: the OE build process wants this
;texi2html: this too
;git: version control system used by the Linux kernel and others. Do not confuse this with the "GNU Interactive Tools"

Furthermore, the following package can be installed optionally:
;psyco: Python just-in-time compiler. Speeds up OpenEmbedded builds (with BitBake) considerably. Strongly recommended.

==== Distro Specific Software Installation ====
;Gentoo: Gentoo users can obtain all this with (note that, at the time of writing, Monotone 0.32 isn't available without setting the ~x86 keyword):
<pre>
echo 'dev-util/monotone ~'`readlink /etc/make.profile | awk -F / '{print $6}'`\
>>/etc/portage/package.keywords
emerge -u subversion quilt monotone diffstat texi2html dev-util/git psyco
</pre>
;Other Distos: [http://www.openembedded.org/wiki/OEandYourDistro Instructions for installing prerequisites in other distributions]

=== Lab host prerequisites ===
'''(Role: LAB)'''

The following package must be installed on the lab host:
;xc: a simple communications program for the serial port

Gentoo users can obtain this with:
emerge -u xc

Note that similar communications programs, such as "cu" or "minicom", may be used as well.

=== Assumptions ===
'''(Roles: LAB, CARD)'''

We make the following assumptions about hardware setup and devices:

* the serial console of the Neo phone is connected to /dev/ttyS0 on '''LAB''' (see [[Debug_Board]])
* the JTAG [[wiggler]] is connected to /dev/parport0 on '''LAB'''. See [[Debug Board]] and [[Connecting_GTA01Bv2_with_Debug_Board]]
* cards inserted in the SD/MMC card reader appear as /dev/uba on '''CARD''' and can be mounted on /mnt/tmp (we'll specify the mount point explicitly, so the directory has to be there, but we don't need to specify the mount point in /etc/fstab). If in doubt,
mkdir -p /mnt/tmp

== Obtaining Sources and build system ==

=== OpenEmbedded build: initial downloads ===

First, we obtain a snapshot of the OpenEmbedded-based tree used by OpenMoko, plus the OE build tool called BitBake.

==== Obtaining OpenMoko SVN tree ====
'''(Role: BUILD)'''

Obtain the latest revision of the OpenMoko tree. Unfortunately, at some places, "current" versions of upstream packages may get included, thus the build may still fail. If it does, you may wish to inform the authorities.

The checkout should take about 45 minutes over an Internet connection with a round-trip time to svn.openmoko.org of 350 ms.

<pre>
cd $OMDIR
svn co http://svn.openmoko.org/ openmoko
</pre>

{{note|If the local user name does not match the user name with which you access SVN, you can put your username in the url you use to checkout:
svn+ssh://joe@stuff.org/svn/stuff
}}

==== Installing BitBake ====
'''(Role: BUILD)'''

Install version 1.6 of BitBake, the build tool of OE. (This is quick.)

<pre>
svn co http://svn.berlios.de/svnroot/repos/bitbake/branches/bitbake-1.6/ bitbake
cd bitbake
./setup.py install
cd ..
</pre>

==== Obtaining OpenEmbedded snapshot ====
'''(Role: BUILD)'''

Obtain a snapshot of the Monotone repository of OpenEmbedded, then update it
to the latest version, and finally check out our "known to be good" revision.
We extract things into $OMDIR/openembedded. OE.mtn.bz2 is about 100 MB.

<pre>
wget http://www.openembedded.org/snapshots/OE.mtn.bz2
bunzip2 OE.mtn.bz2
mtn --db=OE.mtn pull monotone.openembedded.org org.openembedded.dev
mtn --db=OE.mtn checkout --branch=org.openembedded.dev \
-r e2dbb52fe39df7ef786b6068f6178f29508dfded openembedded
</pre>

{{note|For advanced users: if you ever want to update to the latest version of the repository, you would do a "pull" (see above), followed by:
cd $OMDIR/openembedded && mtn update}}

Set up the directories for the cache of upstream files and all material
related to local builds, then put our configuration file there (see also
[[OpenMoko#Setting_up_an_OpenMoko_SDK]]):

<pre>
mkdir -p sources build/conf
cat <<EOF >build/conf/local.conf
MACHINE = "fic-gta01"
DISTRO = "openmoko"
BUILD_ARCH = "`uname -m`"
EOF
</pre>

=== OpenEmbedded build: fixes ===
'''(Role: BUILD)'''

There are unfortunately some problems in the build process.
The following fixes work around them:

cd $OMDIR/sources
mkdir -p ../build/tmp/stamps/armv4t-linux

* upstream moves old packages away, gratuitously breaking downstreams

wget http://ftp.mozilla.org/pub/mozilla.org/js/older-packages/js-1.5.tar.gz
touch ../build/tmp/stamps/armv4t-linux/js-1.5-r0.do_fetch

* us2.samba.org mirror has vanished

wget http://us4.samba.org/samba/ftp/stable/samba-3.0.14a.tar.gz
touch ../build/tmp/stamps/armv4t-linux/samba-3.0.14a-r15.do_fetch

* ghastly patch with CRLF and trailing blanks

perl -pi.orig -e 's/ *$//;s/\r//g' \
../openembedded/packages/gcc/gcc-4.1.1/gcc-4.1.1-pr13685-1.patch

== Building ==

=== OpenEmbedded build ===
'''(Role: BUILD)'''

openmoko/trunk/oe/conf/site.conf expects the OpenMoko-specific OE packages in $OMDIR/oe

cd $OMDIR
ln -s openmoko/trunk/oe .

We're now ready to run the build. This will take a while.

cd $OMDIR/build
bitbake openmoko-devel-image

Note that the build will stop several times to ask for SVN access and whether
to accept certificates. If you're not quick enough to respond, the underlying
session may time out. In this case, just restart "bitbake
openmoko-devel-image" and it will pick up from where it left off.

The whole build process involves numerous downloads, takes about 7 hours
on an Athlon 64 3200+ (about 1.5h of delays were caused by ftp.debian.org not
working properly during this test run), and ends with a message like this:

Build statistics:
Attempted builds: 4

== Installation ==

=== Flash boot loader into NAND ===
'''(Role: LAB)'''

As a first step, we transfer the u-boot bootloader into NAND Flash, through
the JTAG interface. We use JTAG, since this is the most basic way for doing
this, ensuring that we only depend on as little to work on the Neo as
possible.

For this, the u-boot image for the right board version and the desired
build date must be chosen. E.g., an image built for a gta01bv2 board on
February 3, 2007 at 13:40:41 would be called
u-boot_nand-gta01bv2-20070203134041.bin

The name is composed as follows:
;u-boot: the name of the component
;nand: it is it be loaded from NAND (not directly from RAM, see also [[Bootloader#Using_JTAG_to_boot_from_RAM]])
;gta01bv2: the hardware revision of the board
;20070203134041: the build date and time
;.bin: this is a binary suitable for flashing/loading

If this is the first build, there will only be one image for each board
version, thus we can use wildcards. Change the gta01bv2 below to gta01v3 or
gta01v4, if necessary.

See also: [[Sjf2410-linux]]

<pre>
cd $OMDIR/build/tmp/deploy/images

( echo 0; echo 0; echo 0; echo 3; ) |
./sjf2410 -b -f `echo u-boot_nand-gta01bv2-*.bin`
</pre>

This will take approximately 12 minutes.

=== Copy kernel and root FS to microSD card ===
'''(Role: CARD)'''

There are several ways to provide the Neo with its kernel and the root file
system. (See [[Bootloader]] for some of them.)
The most self-contained way is to put everything into NAND Flash.
To transfer the files to the Neo, we first place them on the microSD card.

Memory cards, including microSD, usually come pre-formatted with VFAT. We
prefer ext2 (e.g., because we may want to store a real Linux file system on the
card as well). The following steps are needed to convert the card from VFAT to
ext2:
<pre>
sfdisk -c /dev/uba 1 83
mke2fs -m0 /dev/uba1
tune2fs -c0 -i0 /dev/uba1
</pre>

Next, we copy the kernel uImage and the root file system image to the card.
As discussed in the previous section, we can use wildcards if this is our
first build.
<pre>
cd $OMDIR/build/tmp/deploy/images
mount /dev/uba1 /mnt/tmp
cp uImage-2.6-moko7-r1-fic-gta01-*.bin /mnt/tmp/uImage
cp openmoko-devel-image-fic-gta01-*.rootfs.jffs2 /mnt/tmp/rootfs.jffs2
umount /mnt/tmp
</pre>

Now, insert the microSD card into the Neo, but don't power it on yet.
(If you did anyway, don't worry. We'll power cycle it later.)

=== Serial console ===
'''(Role: LAB)'''

We use a serial console connecting through the debug board. This example uses
"xc", which is a small and simple communications program. Many people prefer
"cu" or the considerably more bloated "minicom", which will work as well.

* Prepare xc configuration
<pre>
cat <<EOF >$HOME/xc.init
set bps 115200
terminal
EOF
</pre>

* Connect to the target
xc -l /dev/ttyS0 -t

=== Start the Neo and enter the boot prompt ===
'''(Role: LAB)'''

Our first interaction with the target. If this doesn't work, please check
that the debug board is connected properly to the serial port.

Disconnect power and USB from the phone, wait a couple of minutes, then connect power.
You may have to press and hold the power button on the Neo for a few seconds to turn it on.
The power button is located next to the USB port.

Some people have observed stability issues if the device was reset without
power cycling or if USB was not disconnected when power cycling, yet details of what is really happening aren't very clear yet.

On the serial console, a message like this should appear:
<pre>
U-Boot 1.2.0 (Feb 3 2007 - 13:07:21)
Press any key to enter the boot prompt:
GTA01Bv2 #
</pre>

Note that the boot prompt changes with the hardware revision you have. If the
message does not appear after a few seconds, try power cycling again.

If xc responds to pressing a button with
"Verify that you are trying to use a valid and operational tty port."
the port may be stuck, waiting for DCD to be asserted. The quickest way to
get out of this situation is to disconnect the serial cable from the debug
board, run the following command
while ! stty -F /dev/ttyS0 clocal; do : ; done

stick something metallic, e.g., a paper clip or a screwdriver, into the plug on the cable,
and keep on fumbling with
it until DCD gets set and the loop above stops spitting out error messages.

=== Flash kernel and root FS into NAND ===
'''(Role: LAB)'''

We now load the kernel and the root FS from the microSD card into memory and
subsequently transfer them to NAND Flash. All this is done by entering
commands at the boot prompt.

Each time we want to write new data to the NAND Flash, we first have to erase
the previous content. We do this individually for each partition. While it would
also be possible to erase some or all relevant partitions in one step, this would
require the user to look up addresses from the partition table and to perform
calculations which are inconvenient at best.

See also: [[U-boot]]

* Initialize the SD/MMC interface. The "Product Name" shown will be just binary garbage. This is expected behaviour.

GTA01Bv2 # mmc

* Load the uImage file into memory. "ext2load" stores the number of bytes read as a hexadecimal number in the environment variable "filesize".

GTA01Bv2 # ext2load mmc 0 0x32000000 uImage

* Erase the kernel partition and write the uImage from memory to NAND Flash

GTA01Bv2 # nand erase kernel
GTA01Bv2 # nand write.e 0x32000000 kernel ${filesize}

* The root file system is next. We need to specify the correct size, which is shown at the end of "ext2load", e.g., "0x1608000)" in this case:

GTA01Bv2 # ext2load mmc 0 0x32000000 rootfs.jffs2
23101440 (0x1608000) bytes read
GTA01Bv2 # nand erase rootfs
GTA01Bv2 # nand write.e 0x32000000 rootfs ${filesize}

=== Configure the boot loader ===
'''(Role: LAB)'''

Last but not least, we have to set up the boot loader to automatically boot
from Flash. For this, we use the default environment settings, which we obtain
by erasing the old content of the environment, and letting u-boot restore the
settings after a restart.

Before touching the environment, you may have to update the environment offset.
Please see [[Migration_to_bad_block_tolerant_builds#Partition_sizing]] for details.
(We may simplify this particularly awkward and error-prone procedure in the
future.)

* First, remove erase the old environment:
GTA01Bv2 # nand erase env

* We reset to force the boot loader to use the default settings.
GTA01Bv2 # reset

Wait until the "U-Boot [...]" message, then hit a key. It will display
*** Warning - bad CRC or NAND, using default environment

* Re-generate the partition information in the environment variable "mtdparts":

GTA01Bv2 # dynpart

* Save the restored settings in NAND
GTA01Bv2 # saveenv

* Power cycle to boot the Neo (see remarks above)

== END ==

'''Congratulations !''' You've just completed level 1 of the OpenMoko adventure.

Building OpenMoko 2007.1 from scratch

2007-07-10T13:01:30Z

Eric: monotone 0.35 is no longer masked ~x86

{|align=right
|__TOC__
|}

{{warning|This is still a preliminary version, which will take some more days until it has all the updates.}}

This is a guide describing how to set up a running OpenMoko
system from scratch.

If you just want to run OpenMoko applications on your PC, just perform the
"Obtaining OpenMoko SVN tree" step below and then go to
[[How to run OpenMoko Apps on PC]]. If you want to autoinstall all required tools and resources, consider using [[MokoMakefile]] -- script developed by Rod Whitby.

Do not treat this as a linear script! There are various configuration items you
need to set (or skip, as it may be), operations that depend on how your
host(s) is/are set up, and also on the hardware revision of the target platform
(i.e., the phone).

Instead, look at each step, read the instructions, copy and paste what
makes sense for you, and adapt what you disagree with. Links to original and
background material in the Wiki are included wherever useful.

== Preparation ==

=== Roles ===

The build process may spread over multiple machines. They have the following
roles:

;'''BUILD''': build host, with quick access to the files and CPU power. Must have Internet access.
;'''LAB''': lab machine connected to the debug board (serial and JTAG) and to USB on the Neo (since this will probably be just a single machine, the roles are not further divided)
;'''CARD''': machine with a USB-attached SD/MMC card reader

All machines are assumed to share the same filesystem layout. At the beginning of
each of the sections below, the respective role is indicated. "('''all''')" is for
settings that apply to all machines, or that - for simplicity - can be
applied to all of them.

=== Directory layout ===
'''(Roles: all)'''

<pre>
$OMDIR (/home/moko) base directory for the whole tree
openmoko/ files from OpenMoko subversion (SVN) repository
openembedded/ files from OpenEmbedded (OE) Monotone repository
sources/ cached downloads of OE
build/ OE build directory
</pre>

=== Environment variables ===
'''(Roles: all)'''

For simplicity, we just set these environment variables on all hosts
involved. If you're not comfortable with this, feel free to weed out the ones
you don't need.

Our base directory (configure this for local arrangements):

export OMDIR=/home/moko

The search path for BitBake files. Note that the order is of vital
importance.

export BBPATH=$OMDIR/build:$OMDIR/openmoko/trunk/oe:$OMDIR/openembedded

=== Permissions ===
'''(Role: BUILD)'''

In order to perform the build process, you have to obtain the following
permissions:

* write access to the OpenMoko SVN repository (in principle, it should be possible to simplify this to read access. For further study.)

=== Build host prerequisites ===
'''(Role: BUILD)'''

There must be at least 7 GB of free space on $OMDIR.

In addition to the traditional development tools (gcc, patch, etc.), the
following packages must be installed on the build host:

;subversion: version control system used by OpenMoko and others.
;quilt: patch management system used by the Linux kernel and others
;monotone: version control system used by OpenEmbedded. This should be a recent version, e.g., 0.32, although also 0.31 should work.
;diffstat: the OE build process wants this
;texi2html: this too
;git: version control system used by the Linux kernel and others. Do not confuse this with the "GNU Interactive Tools"

Furthermore, the following package can be installed optionally:
;psyco: Python just-in-time compiler. Speeds up OpenEmbedded builds (with BitBake) considerably. Strongly recommended.

==== Distro Specific Software Installation ====
;Gentoo: Gentoo users can obtain all this with:
<pre>
emerge -u subversion quilt monotone diffstat texi2html dev-util/git psyco
</pre>

;Other Distos: [http://www.openembedded.org/wiki/OEandYourDistro Instructions for installing prerequisites in other distributions]

=== Lab host prerequisites ===
'''(Role: LAB)'''

The following package must be installed on the lab host:
;xc: a simple communications program for the serial port

Gentoo users can obtain this with:
emerge -u xc

Note that similar communications programs, such as "cu" or "minicom", may be used as well.

=== Assumptions ===
'''(Roles: LAB, CARD)'''

We make the following assumptions about hardware setup and devices:

* the serial console of the Neo phone is connected to /dev/ttyS0 on '''LAB''' (see [[Debug_Board]])
* the JTAG [[wiggler]] is connected to /dev/parport0 on '''LAB'''. See [[Debug Board]] and [[Connecting_GTA01Bv2_with_Debug_Board]]
* cards inserted in the SD/MMC card reader appear as /dev/uba on '''CARD''' and can be mounted on /mnt/tmp (we'll specify the mount point explicitly, so the directory has to be there, but we don't need to specify the mount point in /etc/fstab). If in doubt,
mkdir -p /mnt/tmp

== Obtaining Sources and build system ==

=== OpenEmbedded build: initial downloads ===

First, we obtain a snapshot of the OpenEmbedded-based tree used by OpenMoko, plus the OE build tool called BitBake.

==== Obtaining OpenMoko SVN tree ====
'''(Role: BUILD)'''

Obtain the latest revision of the OpenMoko tree. Unfortunately, at some places, "current" versions of upstream packages may get included, thus the build may still fail. If it does, you may wish to inform the authorities.

The checkout should take about 45 minutes over an Internet connection with a round-trip time to svn.openmoko.org of 350 ms.

<pre>
cd $OMDIR
svn co http://svn.openmoko.org/ openmoko
</pre>

{{note|If the local user name does not match the user name with which you access SVN, you can put your username in the url you use to checkout:
svn+ssh://joe@stuff.org/svn/stuff
}}

==== Installing BitBake ====
'''(Role: BUILD)'''

Install version 1.6 of BitBake, the build tool of OE. (This is quick.)

<pre>
svn co http://svn.berlios.de/svnroot/repos/bitbake/branches/bitbake-1.6/ bitbake
cd bitbake
./setup.py install
cd ..
</pre>

==== Obtaining OpenEmbedded snapshot ====
'''(Role: BUILD)'''

Obtain a snapshot of the Monotone repository of OpenEmbedded, then update it
to the latest version, and finally check out our "known to be good" revision.
We extract things into $OMDIR/openembedded. OE.mtn.bz2 is about 100 MB.

<pre>
wget http://www.openembedded.org/snapshots/OE.mtn.bz2
bunzip2 OE.mtn.bz2
mtn --db=OE.mtn pull monotone.openembedded.org org.openembedded.dev
mtn --db=OE.mtn checkout --branch=org.openembedded.dev \
-r e2dbb52fe39df7ef786b6068f6178f29508dfded openembedded
</pre>

{{note|For advanced users: if you ever want to update to the latest version of the repository, you would do a "pull" (see above), followed by:
cd $OMDIR/openembedded && mtn update}}

Set up the directories for the cache of upstream files and all material
related to local builds, then put our configuration file there (see also
[[OpenMoko#Setting_up_an_OpenMoko_SDK]]):

<pre>
mkdir -p sources build/conf
cat <<EOF >build/conf/local.conf
MACHINE = "fic-gta01"
DISTRO = "openmoko"
BUILD_ARCH = "`uname -m`"
EOF
</pre>

=== OpenEmbedded build: fixes ===
'''(Role: BUILD)'''

There are unfortunately some problems in the build process.
The following fixes work around them:

cd $OMDIR/sources
mkdir -p ../build/tmp/stamps/armv4t-linux

* upstream moves old packages away, gratuitously breaking downstreams

wget http://ftp.mozilla.org/pub/mozilla.org/js/older-packages/js-1.5.tar.gz
touch ../build/tmp/stamps/armv4t-linux/js-1.5-r0.do_fetch

* us2.samba.org mirror has vanished

wget http://us4.samba.org/samba/ftp/stable/samba-3.0.14a.tar.gz
touch ../build/tmp/stamps/armv4t-linux/samba-3.0.14a-r15.do_fetch

* ghastly patch with CRLF and trailing blanks

perl -pi.orig -e 's/ *$//;s/\r//g' \
../openembedded/packages/gcc/gcc-4.1.1/gcc-4.1.1-pr13685-1.patch

== Building ==

=== OpenEmbedded build ===
'''(Role: BUILD)'''

openmoko/trunk/oe/conf/site.conf expects the OpenMoko-specific OE packages in $OMDIR/oe

cd $OMDIR
ln -s openmoko/trunk/oe .

We're now ready to run the build. This will take a while.

cd $OMDIR/build
bitbake openmoko-devel-image

Note that the build will stop several times to ask for SVN access and whether
to accept certificates. If you're not quick enough to respond, the underlying
session may time out. In this case, just restart "bitbake
openmoko-devel-image" and it will pick up from where it left off.

The whole build process involves numerous downloads, takes about 7 hours
on an Athlon 64 3200+ (about 1.5h of delays were caused by ftp.debian.org not
working properly during this test run), and ends with a message like this:

Build statistics:
Attempted builds: 4

== Installation ==

=== Flash boot loader into NAND ===
'''(Role: LAB)'''

As a first step, we transfer the u-boot bootloader into NAND Flash, through
the JTAG interface. We use JTAG, since this is the most basic way for doing
this, ensuring that we only depend on as little to work on the Neo as
possible.

For this, the u-boot image for the right board version and the desired
build date must be chosen. E.g., an image built for a gta01bv2 board on
February 3, 2007 at 13:40:41 would be called
u-boot_nand-gta01bv2-20070203134041.bin

The name is composed as follows:
;u-boot: the name of the component
;nand: it is it be loaded from NAND (not directly from RAM, see also [[Bootloader#Using_JTAG_to_boot_from_RAM]])
;gta01bv2: the hardware revision of the board
;20070203134041: the build date and time
;.bin: this is a binary suitable for flashing/loading

If this is the first build, there will only be one image for each board
version, thus we can use wildcards. Change the gta01bv2 below to gta01v3 or
gta01v4, if necessary.

See also: [[Sjf2410-linux]]

<pre>
cd $OMDIR/build/tmp/deploy/images

( echo 0; echo 0; echo 0; echo 3; ) |
./sjf2410 -b -f `echo u-boot_nand-gta01bv2-*.bin`
</pre>

This will take approximately 12 minutes.

=== Copy kernel and root FS to microSD card ===
'''(Role: CARD)'''

There are several ways to provide the Neo with its kernel and the root file
system. (See [[Bootloader]] for some of them.)
The most self-contained way is to put everything into NAND Flash.
To transfer the files to the Neo, we first place them on the microSD card.

Memory cards, including microSD, usually come pre-formatted with VFAT. We
prefer ext2 (e.g., because we may want to store a real Linux file system on the
card as well). The following steps are needed to convert the card from VFAT to
ext2:
<pre>
sfdisk -c /dev/uba 1 83
mke2fs -m0 /dev/uba1
tune2fs -c0 -i0 /dev/uba1
</pre>

Next, we copy the kernel uImage and the root file system image to the card.
As discussed in the previous section, we can use wildcards if this is our
first build.
<pre>
cd $OMDIR/build/tmp/deploy/images
mount /dev/uba1 /mnt/tmp
cp uImage-2.6-moko7-r1-fic-gta01-*.bin /mnt/tmp/uImage
cp openmoko-devel-image-fic-gta01-*.rootfs.jffs2 /mnt/tmp/rootfs.jffs2
umount /mnt/tmp
</pre>

Now, insert the microSD card into the Neo, but don't power it on yet.
(If you did anyway, don't worry. We'll power cycle it later.)

=== Serial console ===
'''(Role: LAB)'''

We use a serial console connecting through the debug board. This example uses
"xc", which is a small and simple communications program. Many people prefer
"cu" or the considerably more bloated "minicom", which will work as well.

* Prepare xc configuration
<pre>
cat <<EOF >$HOME/xc.init
set bps 115200
terminal
EOF
</pre>

* Connect to the target
xc -l /dev/ttyS0 -t

=== Start the Neo and enter the boot prompt ===
'''(Role: LAB)'''

Our first interaction with the target. If this doesn't work, please check
that the debug board is connected properly to the serial port.

Disconnect power and USB from the phone, wait a couple of minutes, then connect power.
You may have to press and hold the power button on the Neo for a few seconds to turn it on.
The power button is located next to the USB port.

Some people have observed stability issues if the device was reset without
power cycling or if USB was not disconnected when power cycling, yet details of what is really happening aren't very clear yet.

On the serial console, a message like this should appear:
<pre>
U-Boot 1.2.0 (Feb 3 2007 - 13:07:21)
Press any key to enter the boot prompt:
GTA01Bv2 #
</pre>

Note that the boot prompt changes with the hardware revision you have. If the
message does not appear after a few seconds, try power cycling again.

If xc responds to pressing a button with
"Verify that you are trying to use a valid and operational tty port."
the port may be stuck, waiting for DCD to be asserted. The quickest way to
get out of this situation is to disconnect the serial cable from the debug
board, run the following command
while ! stty -F /dev/ttyS0 clocal; do : ; done

stick something metallic, e.g., a paper clip or a screwdriver, into the plug on the cable,
and keep on fumbling with
it until DCD gets set and the loop above stops spitting out error messages.

=== Flash kernel and root FS into NAND ===
'''(Role: LAB)'''

We now load the kernel and the root FS from the microSD card into memory and
subsequently transfer them to NAND Flash. All this is done by entering
commands at the boot prompt.

Each time we want to write new data to the NAND Flash, we first have to erase
the previous content. We do this individually for each partition. While it would
also be possible to erase some or all relevant partitions in one step, this would
require the user to look up addresses from the partition table and to perform
calculations which are inconvenient at best.

See also: [[U-boot]]

* Initialize the SD/MMC interface. The "Product Name" shown will be just binary garbage. This is expected behaviour.

GTA01Bv2 # mmc

* Load the uImage file into memory. "ext2load" stores the number of bytes read as a hexadecimal number in the environment variable "filesize".

GTA01Bv2 # ext2load mmc 0 0x32000000 uImage

* Erase the kernel partition and write the uImage from memory to NAND Flash

GTA01Bv2 # nand erase kernel
GTA01Bv2 # nand write.e 0x32000000 kernel ${filesize}

* The root file system is next. We need to specify the correct size, which is shown at the end of "ext2load", e.g., "0x1608000)" in this case:

GTA01Bv2 # ext2load mmc 0 0x32000000 rootfs.jffs2
23101440 (0x1608000) bytes read
GTA01Bv2 # nand erase rootfs
GTA01Bv2 # nand write.e 0x32000000 rootfs ${filesize}

=== Configure the boot loader ===
'''(Role: LAB)'''

Last but not least, we have to set up the boot loader to automatically boot
from Flash. For this, we use the default environment settings, which we obtain
by erasing the old content of the environment, and letting u-boot restore the
settings after a restart.

Before touching the environment, you may have to update the environment offset.
Please see [[Migration_to_bad_block_tolerant_builds#Partition_sizing]] for details.
(We may simplify this particularly awkward and error-prone procedure in the
future.)

* First, remove erase the old environment:
GTA01Bv2 # nand erase env

* We reset to force the boot loader to use the default settings.
GTA01Bv2 # reset

Wait until the "U-Boot [...]" message, then hit a key. It will display
*** Warning - bad CRC or NAND, using default environment

* Re-generate the partition information in the environment variable "mtdparts":

GTA01Bv2 # dynpart

* Save the restored settings in NAND
GTA01Bv2 # saveenv

* Power cycle to boot the Neo (see remarks above)

== END ==

'''Congratulations !''' You've just completed level 1 of the OpenMoko adventure.

Hardware:Neo1973:Alternate Cases:Steampunk

2007-07-10T10:30:20Z

Eric: /* Interest */

Steampunk influenced case mod for the Neo1973

==Rendered images==

==3D model==

==Materials==
Brass/copper
Felt

==Processes==
[http://steampunkworkshop.com/electroetch.shtml Electrolytic etching]

==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. ||[[User:ScaredyCat|Scaredycat]]
|-
|2. ||[[User:Eric|Eric]]
|-
|}

[[Category:Neo1973_alternate_cases]]

Hardware:Neo1973:Alternate Cases:Steampunk

2007-07-10T10:30:04Z

Eric: /* Interest */

Steampunk influenced case mod for the Neo1973

==Rendered images==

==3D model==

==Materials==
Brass/copper
Felt

==Processes==
[http://steampunkworkshop.com/electroetch.shtml Electrolytic etching]

==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. ||[[User:ScaredyCat|Scaredycat]]
|-
|1. ||[[User:Eric|Eric]]
|-
|}

[[Category:Neo1973_alternate_cases]]

Main Page

2007-07-08T23:56:01Z

Eric: purcased is not purchased

<big>'''Welcome to the [[OpenMoko]] public Wiki'''</big> 
For other languages see the [[#bottom|bottom]] of this page.

[[Image:FIC-neo1973_small.jpg|200px|right|frontside]]
[[OpenMoko]] is an [http://en.wikipedia.org/wiki/Open_source Open Source] project to create the world's first free mobile phone operating system.

The [[OpenMoko]] project is a community that anyone can join, to help design their ideal phone.

The long term goal is that phone software won't be tied to a phone. You can install any OpenMoko software over the whole range of phones, and if you upgrade your phone, you don't lose the software. Bugs fixed on one phone are fixed on all.

Currently it is not suitable for users. The state of the software at the moment is pre-alpha. If you order a Neo1973, DO NOT expect to be able to use it as an everyday phone for several months.

The [[Neo1973]] from [[FIC]] is the first of many phones that [[OpenMoko]] will run on. It can be purchased from [https://direct.openmoko.com/]. To show that OpenMoko the phone stack is not tied to the Neo1973, here is a report from somebody who seems to have OpenMoko [http://blog.mikeasoft.com/2007/07/01/openmoko-on-a-treo-650/ up and limping on the Palm Treo680]!

Please join us in collaborating on the [[OpenMoko | OpenMoko project]] through any of the [[Development resources | project resources]] including the [[Main Page | OpenMoko wiki]]. Please see the [[Help:Contents | wiki editing help page]] for information on making contributions to this wiki. A [[Meet the Core Team | core team of developers funded by FIC, Inc.]] leads the project.

An [[Introduction | introduction page]] is available, with both [[Introduction#Photos|photos]] and [[Introduction#Videos|videos]]. Moreover, the usual [[FAQ | Frequently Asked Questions, FAQ, page]] might be helpful. Developers may find the [[ChangeLog | daily software change log]] an important resource.

The members of the [[OpenMoko]] community would like to thank [[FIC|FIC Inc.]] for showing leadership and initiating the [[OpenMoko]] project.

== [[OpenMoko]] Areas of Interest ==

* [[Basic End-user]] - Information for end users that want basic functionality and no surprises
* [[Advanced End-user]] - Information for advanced end-users that want advanced and experimental functionality but who are not programmers
* [[Development resources | Project Resources]] page provides a centralized location of all resources such as [[Development resources#Mailing_Lists|mailing lists]], [[Development resources#IRC | communication tools]], and other software development oriented resources.
* [[Application Developer]] - Information for application developers, including ideas and specifications for applications, and tools to build them
* [[System Developer]] - Information for system developers, including bootloader, kernel, and libraries
* [[Hardware Developer]] - Information for hardware developers, including hardware specs and debug board
* [[Community Events]] - Information on both [[Community Events#Past Events | past ]] and [[Community Events#Past Events#FIC / OpenMoko at Events | future]] events where FIC or [[OpenMoko]] had or will have a presence.

== Developer's Documentation ==

=== Hands-on Guides ===
* [[Getting Started with your Neo1973]]
* [[MokoMakefile|Building OpenMoko using the MokoMakefile]]
* [[Building OpenMoko from scratch]]
** Old [[Building OpenMoko from scratch (pre-BBT)]]
* [[Migration to bad block tolerant builds]]
* [[Running OpenMoko on PC]]
** [[Getting OpenMoko working on host with Xoo]]
** [[Getting OpenMoko working on host with Xephyr]]
** [[How to run OpenMoko Apps on PC]]
** [[OpenMoko under QEMU]]
* [[Booting from SD]]

=== Hardware Reference Documentation ===
* All [[:Category:Hardware|Hardware]] related documentation and specifications are found on the [[:Category:Hardware|Hardware page]].
* The [[:Category:Neo1973 Hardware|Neo1973 Hardware page]] provides an overview of the hardware components used by the [[:Category:Neo1973 Hardware|Neo1973 hardware platform]]. PCB Photographs are also included. A [[Disassembling Neo1973 | photo disassemble story]] may be an interesting starting place.
* [[:Category:Neo1973 Hardware Debugging | Neo1973 Hardware Debugging]] is assisted with the [[Debug Board | Neo1973 debug board]]. A page discussing [[Connecting Neo1973 with Debug Board v2 | debug board and Neo1973 configurations]] are also provided.

=== Software Reference Documentation ===
* Architectural
** [[OpenMokoFramework]] - The OpenMoko Application Framework
* [[neo1973 host software]]
* Device Software
** Low-Level
*** [[u-boot]] - The bootloader we use, including documentation for our modifications
*** [[kernel]] - The Linux kernel we use, including documentation for our modifications
** Userspace
*** [[binary compatibility]]
*** [[gsmd]] - the GSM daemon managing the GSM Modem
*** [[gpsd]] - the AGPS (Assisted GPS) daemon

=== OpenMoko===
* [[OpenEmbedded]] - The distribution-building framework
* [[Toolchain]] - The toolchain we use for compilation
* [[OpenMoko]] - The OpenMoko distribution
** [[OpenMoko2007]] - The first intended release of it
** [[Userspace root image]]

==== User Interface Related ====
* [[Look & Feel]]
* [[Applications]]
* [[Widgets]]
** [[Widget Inheritance Graph]]

=== Misc. Development Related ===
* [[Freshman todo]]
* [[Templates]]
* [[PIM Storage]]
* [[Coding Guidelines]]
* [[OpenMoko#Setting_up_an_OpenMoko_SDK|How to setup the OpenMoko SDK]]
* [[License]] - How we license our code
* [[Development resources]] - Describes resources for developers (lists, svn, ...)
* [[Neo1973 Phase 0]] -- Information for Phase 0 device owners
* [[Wishlist:Neo1973 P0 Review]] -- Impressions of the Phase 0 hardware device, also the Phase 0 FAQ

== Administrative / Organizational ==

* [[Shipping Notes]] - Information to help FIC figure out how to ship products to you, and how much it might cost.
* [[My Account]] - Ideas for what sort of account-based services FIC should provide with the phone.

== Miscellaneous ==
* [[WiFi support in OpenMoko]]
* [[Neo1973 and Windows]] - If you want to commit that offence ;) (does not work, help!)
* [[Press Coverage]] - What the press says about the OpenMoko project
* [[mFAQ]] - The OpenMoko Misinformation FAQ ('''mFAQ''') - What the press '''''incorrectly''''' says about the OpenMoko project
* [[Wish List]] - A collection of ideas and ideals we'd like to see implemented some day
* [[Wish List - Hardware]] - A collection of ideas we'd like to see in the next Neo release
* [[Wishlist:BuiltInScriptingLanguage|Wish List - Built-in Scripting Language]] - Discussion on a suitable scripting language to be included
* [[Media Content]] - What types of media on the device can we use (that is non-software)?
* [[Testimonials]] - How did you get to OpenMoko?
* [[Buying Interest List]] - (Not official and not a pre-order page) Have you have put money aside for Neo1973? Put your nick here.
* [[iPhone]] - Comparison between Apple iPhone and FIC Neo1973
* [[Translation]] - Translation of OpenMoko
* [[Summer of code]] - Our page with project applications for Googles Summer of Code
* [[SWAG]] - Where to purchase openmoko swag (T-Shirts!)


{{Languages|Main_Page}}

PIM Storage

2007-07-08T23:39:51Z

Eric: /* Unresolved Issues */

== Overview ==
PIM storage describes a means of storing data in an extensible and cross-referencable way.

== Goals & Objectives ==
* Method to exchange data between all applications completely transparent
* Personal data security / encryption
* Great bidirectional sync of personal data
* Easy method for [[Backup|backup]] (ideally this should be automatic)
* Real-time incremental search
* Autocomplete of personal data information

== Use Cases ==
* I would like to attach arbitrary data to a contact (AKA: custom fields)
* I would like some level of integration with automatic switching of profiles. For example, it would be cool to automatically backup my personal data to my desktop PC when I get home.
* I want to type the first few numbers of a phone number and be presented a list of matching contacts.
** I'd rather take a person, choose home/work, choose land-line/mobile and not bother with numbers anymore. Useful when I'm on my way to meet that person, or the person has his/her birthday, i.e. the person is already listed on my screen!
* I want to add a contact to multiple groups (AKA: categories)
* I want to be able to send my contact info to other OpenMoko devices over bluetooth
* I want to be able to two-way sync all calendar, contacts (and tasks) with a GroupDAV server (e.g. Citadel) over-the-air

== Constraints ==
(TBD)

== Implementation Recommendations ==
* This will be based on [http://projects.o-hand.com/eds Embedded EDS], this way we will can directly use Evolution data, get OpenSync for free, and eventually be able to talk to a Microsoft Exchange Server using the Novell Connector.

== Interactions ==
* Embedded EDS needs libglade2, [[dbus]], and libdb.

== Unresolved Issues ==
* Synchronizing w/ Outlook
* Synchronizing w/ MacOS X - most Macs have bluetooth builtin and OSX addressbook supports BT sync.
* Synchronizing w/ Google services

Possible solutions:
* mokod - An OpenMoko daemon to run on host operating systems

== Questions and Answers ==
* Q: When will an Embedded EDS specification be available? i.e. How I can get applications to store and retrieve data from in it, in a compatible way?
* Q: Will it out of the box synchronize with the Kontact PIM suite (KDE)?

User:Eric

2007-07-08T21:05:21Z

Eric:

I'm an embedded linux developer who lives in Montreal, Quebec, Canada.
I'm looking for OpenMoko related work, feel free to contact me.
I go by nickname notserpe on #openmoko.

User:Eric

2007-07-08T21:04:38Z

Eric:

I'm an embedded linux developer who lives in Montreal, Quebec, Canada.
I'm looking for OpenMoko related work, feel free to contact me. 
I go by nickname notserpe on #openmoko.

User:Eric

2007-07-08T21:04:16Z

Eric:

I'm an embedded linux developer who lives in Montreal, Quebec, Canada.
I'm looking for OpenMoko related work, feel free to contact me.
I go by nickname notserpe on #openmoko.

Wishlist/BuiltInScriptingLanguage

2007-07-05T13:51:10Z

Eric: /* Java */

{{Wishlist}}

== Discussion ==

[http://lists.openmoko.org/pipermail/community/2007-January/001909.html There was a discussion on the mailing list about choosing a built-in scripting language.]

Many different scripting languages will be optionally available in the repository. However, developers who choose one of these languages for their applications will not be able to see their applications included in the standard ROM nor available for use by those without an external microSD card.

[http://lists.openmoko.org/pipermail/community/2007-January/001945.html As expressed by Corey]:

''It's true that you have the ability to add anything to the phone.''

''There's another important consideration to remember: OpenMoko is a platform also; an inherent aspect of such a platform is that it always come shipped with X standard api's available for developers. This is why FIC had to select a group of components: gcc, glibc, xorg/kdrive, dbus and gtk, for instance.''

''They may decide that a scripting language would also be a necessary or beneficial feature to include in the base/standard platform''

...

''Choice is good.''

''And so is having a known/standard/default/static api and platform to build from; when I begin writting commercial and/or free software for the OpenMoko, I will design my software according the existing OpenMoko specs, and thereby circumvent the necessity of having to verify that my customers/end users have first installed the necessary scripting language, which would additionally circumvent the probability that your phone will end up with every scripting language known to man.''

''> So having lua on my system would be more or less pointless as I don't use it myself.''

''Less than one meg of space would be potentially wasted, true enough in your case. Know that there is probably plenty of other software on the OpenMoko platform that you, yourself, will not be using.''

''Also realize that though _you_ may not be directly using this hypothetical scripting language, it is more than likely that one or more of the standard apps that ship with the phone will be using it, and that other 3rd party software that you may or may not install may also be using it.''

[http://lists.openmoko.org/pipermail/community/2007-January/001947.html Derek Pressnall also expressed it well:]

''The reason is the same reason the device is being shipped with a given kernel (Linux), a given set of libraries (glibc, gtk), etc. So that when a developer writes an application, it will be known to be able to run on all shipped devices. So, in this light, it may be benificial to included a standard interpreted language that can be a known
target. ''

''The benefits to having an interpreter included (esp. one that has hooks into the gui and other phone functions) are that more apps will be made available -- there are more hackers that can code up quick scripts than ones that will learn & code for a specific gui accessible only from a compiled language. And, the benefit of having a particular interpreter is that when these little apps / scripts are packaged up, you don't have a dependancy nightmare (even though this can be somewhat mitigated by a good package management system, it is only as good as the backend repository, and having self-contained packages are the simplest of all). Also, by settling on a single standard, even if it is one that some developers may have to learn, it makes it more worthwhile to learn a new scripting environment that is widely deployed on your target platform. But for these same reasons, the interpreted language target will need careful consideration, lest we get stuck with something that doesn't adequetly meet most needs.''

''As a secondary issue, if the included interpreter is easily embeddable, then it would be nice to have it as the standard across all the included applets that can use it (i.e., it would be good if the email/sms client, phonebook manager, dialer, etc. were all scriptable).''

''But whatever is decided on (if a single language is picked), a function library should be developed for it that includes access to all the phone specific features (in addition to the gui hooks).''

[[http://lists.openmoko.org/pipermail/community/2007-January/001955.html and Ben Burdette:]]

''That's all well and good when everyone has SPACE for every scripting language known to man. But use 10mb here, 10mb there for scripting languages, and suddenly there's nothing left of my 64mb of flash. ''

''I'm all for allowing people to use whatever scripting language they want. But I'd like the peace of mind of knowing I can write a scripted app that will run on every OpenMoko phone out there, even if they have no memory expansion card. I don't want the situation where the poor user has to unload someone else's app and scripting environment in order to use mine, or vice versa. ''

Bryan Larsen adds:

''It'll be faster for me to develop my apps in Ruby-GTK2 and then port to C once the application stabilizes, since so much of the actual work involves playing with and discarding various ideas. Why should I have to go through the totally unnecessary step of transliterating my code into C just so it can be used by mainstream users? I don't really care if Ruby or Python or even Javascript is chosen, I just want something for rapid development that I can ship without translating!''

For all these reasons, a choice should be made, and it should be made quickly. A scripting language should be chosen and "blessed"; actual implementation on OpenMoko is a much lower priority as most people will likely be (or should be) prototyping their applications on a PC anyways.

== Factors to Consider ==

# '''How popular is it?''' The fewer people that need to learn a new language, the less whining we'll get on the list when it's chosen.
# '''How big is the run time environment?''' This is perhaps the most important question, since we are trying to fit into a very small fraction of the 64MB of space available in the OpenMoko ROM. We only need the run time environment; it is expected that developers will have a PC or microSD card to compile to the intermediate form used by the scripting language. It's also presumed that a stripped down, precompiled standard library will be included.
# '''Is it easy to learn?''' Assuming that the user has already learned some Algol influenced language, (ie pretty much every language in widespread current use except for Lisp and FORTRAN), how easy is it to learn?
# '''How advanced is it?''' We want to include a language that people will use. Specifically I'm going to look for "closures" and "meta-programming" as a measure of how "advanced" the language is. These are very arbitrary choices, but they are something I've found useful. If you have any other pet measures, let me know!
# '''Does it have bindings to GTK2, OpenMoko-libs and D-BUS?''' These three things will be required to write applications that look and feel like OpenMoko apps, as well as interact well with the built-in applications.
# '''How does it perform?''' Performance is usually not a major concern for a scripting language, but due to the limited horsepower available on phones, it is a concern.
# '''Is it embeddable?''' Traditionally in the Unix world, applications were small tools bound together by scripts and pipes. Traditionally in the Windows world, applications were huge monolothic beasts that were scriptable using a built-in scripting language such as Visual Basic for Applications. This model is also used in the Unix world, Emacs being the classic example. A hybrid model has emerged and become popular in modern Unix GUI's such as OSX, Gnome and KDE: applications expose a scripting friendly API via D-BUS, CORBA or Applescript so that external scripts can appear to act as internal scripts. If the scripting language chosen is easily embeddable, all three models become available on OpenMoko. It's expected that the third model will be the most popular, but the second model may have size/overhead advantages.
# '''What major applications of interest''' are available in the language and would be useful on OpenMoko?

== The Languages (already included) ==

=== BASH / Shell scripts ===

# already included, useful for most cases - [http://99-bottles-of-beer.net/language-bash-98.html example]
# Shell is a very popular scripting language.
# There will be a shell of some form available on OpenMoko, therefore it is "free".
# Shell is idiosyncratic, but all Unix developers know it in at least a very limited degree.
# Shell is a full language, but can hardly be compared to languages designed monolithically. :)
# D-BUS is usable from the command line. GTK2 may be used via [http://www.gtk-server.org/index.html gtk-server].

=== AWK ===

# already included, very powerful - [http://99-bottles-of-beer.net/language-awk-53.html example]

=== SED ===

# already included, useful together with bash / awk [http://99-bottles-of-beer.net/language-sed-1087.html example1],[http://www.student.northpark.edu/pemente/sed/sed1line.txt example2]

=== Javascript ===

# Javascript is a very popular scripting language because it's the defacto web user-side scripting language.
# Javascript will be available on whichever web browser is included in the project, therefore it is "free".
# Javascript has a straightforward C-style syntax. Core Javascript is actually a very nice language; it gets a bad rap because of inconsistencies in implementation and bugs in the various browsers.
# Closures are very popular in Javascript. Metaprogramming is possible; JSON is an example of a form of such.
# An incomplete set of bindings for GTK2 are [http://oss.mps.com.sg/GtkJavaScript available here.]. [http://www.gtk-server.org/index.html gtk-server] may be used instead if those bindings are insufficient.

== The Languages (not included) ==

''Warning: opinions ahead''

=== Lua ===

# Lua is a moderately popular scripting language popular in video games and in Brazil.
# It has a tiny footprint: 150K claimed, the run time environment takes up around 400K in OpenZaurus. It's been successfully shoehorned into tiny embedded platforms (<50Kb RAM).
# Lua has a simple syntax and is easy to learn.
# It has first class closures and coroutines (a.k.a. greenthreads). A fundamental building block of Lua is the ability to redefine any defined or undefined aspect of the language; this provides very good runtime metaprogramming ability. [http://metalua.luaforge.net/ metalua] provides full compile-time metaprogramming (a.k.a. Lisp-style macros), if such extremes are needed.
# Bindings are available for GTK2.
# Performance are substantially better than [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua&lang2=python Python's] or [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua Perl's].
# It is very easy to embed: it's designed for seamless integration with C, in both Lua->C and C->Lua directions.

=== Python ===

# Python is an extremely popular scripting language.
# By stripping down the standard libraries to the edge of usability, it can be made to fit within 1MB. (claim unverified). I suspect that 3MB is a more usable number.
# Designed as an educational language, it is easy to learn.
# It has closures, although they were a late addition to the language. Metaprogramming is very difficult.
# Bindings are available for GTK2 and D-BUS. GTK bindings are part of the Gnome project.
# Performance is good. Psyco can make it extremely good, but that is unlikely to be available to OpenMoko.
# Python can be embedded, although not trivially.
# OLPC uses Python heavily and may produce applications suitable for porting to OpenMoko
# Python is the only language besides C / C++ mentioned in GNOME Mobile & Embedded Initiative Mobile Platform
# Python has been successfully used to create well-working and fast programs for the Nokia 770/800 devices, such as [http://konttoristhoughts.blogspot.com/2007/03/uk-media-player-is-nearing-first-public.html this].

=== Ruby ===

# Ruby is a popular scripting language.
# Size is unknown, although comparable to Python, I suspect.
# Ruby is seen by many to be an excellent compromise between the terseness and power of Perl and the readability and ease of learning of Python.
# It has closures. Metaprogramming can be hairy, but Rails is an excellent example of the beautiful results it can acheive.
# Bindings are available for GTK2 and D-BUS.
# Performance is worse than Python or Perl in current versions, although the next version of Ruby is likely to be much better.

=== Perl ===

# Perl is an extremely popular scripting language.
# Sizewise, it is likely to be a little bit smaller than Python or Ruby.
# It is not generally considered an easy language to learn. This is probably mostly due to the idiosyncrasy of typical Perl programs. Perl is generally easier to write than to read or maintain, most other languages are the other way around.
# Perl has first class closures. Perl's metaprogramming abilities lie between that of Python and Ruby.
# Perl has existed for a considerable amount of time in comparison to other scripting languages, which means it is stable and boasts an extensive amount of third-party libraries/modules.
# Bindings are available to GTK2 and D-BUS. Gtk bindings are part of the GNOME project.

=== Lisp/Scheme/Guile ===

# There are a lot of Lisp variants available. It is the second oldest high-level programming language available, yet still retains moderate popularity for new projects.
# Lisp variants have been run on 16K computers. Usable variants are substantially larger, but will be significantly smaller than Python.
# Lisp syntax is very simple, and hated by many. :)
# Modern lisp variants are more "powerful" than every other language listed here.
# GTK2 and D-BUS bindings are available

=== Java ===

# Not a scripting language, but Java does offer garbage collection and a few features that make development slightly faster than C. A J2ME JVM is ubiquitous on competing cell phones so is likely to be included in OpenMoko for purely competitive reasons. (But if we're all lucky, a clear-minded concensus will prevail in everyone's understanding that Java just doesn't belong on an embedded device.)
# A full J2ME implementation takes about 2 Megabytes of space. [http://developers.sun.com/techtopics/mobility/getstart/articles/survey/ (reading in between the lines here. I could be very wrong)]. However since it's likely to be included in the phone for other reasons it can be considered "free".
# Java is very C-like.
# Java is not a scripting language and doesn't support advanced scripting language features. So why is it in this list?
# libswt-gtk provides uses GTK2 to display SWT java apps, and libgtk-java provides a direct binding.

=== JRuby ===

# JRuby is a version of ruby that runs on the JVM. Jython is also available although it appears that JRuby is being more actively supported by Sun.
# If a JVM is on the phone, then JRuby is "free".
# JRuby can use the Java bindings to GTK2.

=== Mono/C# ===

# Not a scripting language, but offers garbage collection and other nice features.
# Already used in a similar setup on Nokia 770/800.
# Nicely cross-platform; same binary could be run on OpenMoko, Nokia 770/800, Linux, Windows (see [http://www.mdk.org.pl/articles/2007/01/28/clone-wars here]).
# Has anyone got a good quote on runtime size? (One package was 1.7M for runtime, 1.3M for GTK#, and a whopping 22M for the full classlib.)

== Summary ==

If the space is available, the most popular choices will be Ruby and Python. Python is currently more popular, however Ruby is gaining ground fast. The choice between the two is political. Neither is wrong; you'll offend people making either choice. However, "both" is a very expensive option, so a choice will have to be made.

If the space is more limited, Lua and Scheme are probably the best choices. Unless your developers include a large number of grey-bearded Lisp hackers, Lua is probably the best choice. This may be unfortunate, but it is so.

If an appropriate amount of manpower is available to bring the bindings up to snuff, the "free" choice of Javascript may be the best choice of all.

JRuby is also an interesting choice. It's very likely that a J2ME JVM will be included in the standard installation for purely competitive reasons, so JRuby is very close to free with a little bit of work.

--[[User:Bryan Larsen|Bryan Larsen]] 21:44, 3 April 2007 (CEST)

Well, my beard is still red, and I prefer Common Lisp. Or Scheme. :) --[[User:hrapd|Dmitri Hrapof]] 18 April 2007

By looking at the [http://www.gnome.org/mobile/ GNOME Mobile & Embedded Initiative] page, I see that there is a picture of the [[Neo1973]] and a picture showing the GNOME Mobile Platform with C, C++ and Python mentioned. Is there a strong reason not to pick Python as the language for the device? --[[User:Nakedible|Nakedible]] 12:30, 30 April 2007 (CEST)

[[Category:Ideas]]

Wish List - Hardware

2007-07-05T10:20:40Z

Eric: /* Barcode Scanner */

This is a page detailing hardware features which some would like to go into future phones similar to the [[Neo1973]].

Openmoko however may run on a large number of devices in the future, some of which may be DVD players, cameras, or convergance devices. Possible features for those devices are listed in [[Wishlist - Hardware - Novel Devices]].

Hardware that is unlikely to appear in any OpenMoko device is listed in [[Wishlist:Unlikely]] - due to it being impossible to fabricate with near-term technology, or other reasons.

Accessories that people would like - initially primarily for the Neo1973 - are listed in [[Wishlist:Accessories]].

==Wireless data networking==

===WiMAX support===
[http://en.wikipedia.org/wiki/Wimax WiMAX] is a high-speed data service, similar to wifi, though longer range and newer. Where service is available, this would complement WiFi. Unfortunately, unlike wifi, frequencies vary worldwide, so global usage may be complex.

===Emerging Protocols===
*[http://en.wikipedia.org/wiki/Near_Field_Communication Near Field Communication] has a few centimeter range, useable for keys, ID badges, pairing bluetooth devices and similar uses. Mentioned in newer bluetooth and SD standards. (No products.)
*[http://en.wikipedia.org/wiki/ZigBee ZigBee] is designed for connecting sensors and switches in buildings, with many options including mesh networks and aggressive power saving compared to bluetooth. (Almost no products available.)
*The [http://en.wikipedia.org/wiki/ANT_%28network%29 ANT network] is for connecting worn devices. Similar to ZigBee, but much simpler and maybe lower power. ([http://www.thisisant.com/?section=9 Short list] of products.)

==Camera==

* A camera that can take reasonable quality video and pictures is something many want. Applications vary from simple snapping, to gesture interfaces, video conferencing, barcode reading, buisness card reading, healthcare, servicing, and more.

* Some people can't take cameras into work - a model without the camera, or some way of removing the camera would be useful.

* See [[Wishlist:Camera]] for a more detailed wishlist.

==Display==
===Multitouch screen===

''Main article: [[Wishlist:Spell_weaving|Spell weaving]]''

See also [http://pogue.blogs.nytimes.com/2007/03/27/the-multi-touch-screen/ this page] containing a link to a video demonstration.

A history of multitouch implementations is [http://billbuxton.com/multitouchOverview.html here] ([http://google.com/search?q=cache:billbuxton.com/multitouchOverview.html google cache version])

===Video acceleration===
Hardware acceleration for video playback.
===3D acceleration===
3D hardware acceleration for 3D games, GUIs, etc. (maybe a PowerVR MBX Lite ?).

===EPD===
Or electronic paper display, EPD is used in many new devices such as the new Motorola motofone, sonys new e-reader and Irex's iliad. The technology provides thin, flexible, power saving screens using new eink technology. This technology could cut the weight of the phone and its power usage. For more info see: [http://www.eink.com eink's website].

===Transreflective===
It would be nice to have (the option of) a transreflective display, which while being less bright, is readable without needing to power the backlight. Then again, it depends on how much power the backlight uses compared to everything else...

==="Slightly" Larger Screen===
43mm x 57mm (2.8inch diagonal) is tiny. A 53mm x 71mm (3.5 inch diagonal) like on the TD035STEE1 would be a nice improvement. A widescreen format at about 53mm x 82.5mminstead of the 3:4 aspect ratio would be even cooler (if one could be found).

==Input devices==

===Just a few more Buttons===

2 buttons more, 3 buttons total, mounted sideways would be enough. You could use them for play/pause and loudness controll while the phone remains in your pocket (display locked, ...), reading mails, rss, ebooks,... without wasting display space and so on.

With 5 buttons in total you could possibly emulate a keyboard (2^5 = 32 combinations) for those who know how to play a flute. Useable onehanded, not wasting display space and faster than t9. (It's not faster than T9 - I've used this system with the microwriter agenda --[[User:Speedevil|Speedevil]] 00:00, 2 July 2007 (CEST)) Hopefully this is not patented already.

===D-Pad and Buttons===
*Adding a D-pad (to the bottom of the phone) and 2 to 4 buttons (to the top) would provide some tactile input controls, in addition to the touchscreen. They could be used as shortcut keys in the menu, or playback control when playing media. When the phone is held sideways, they can be used as games controls. (With touchscreen alone, gameplay options are limited)

Game buttons would be best on both sides of the screen. The larger the buttons, the better. 2x 4 buttons in up-down-left-right configuration + some extra buttons separately a bit lower on the device would be good for many for emulation games.

Here is a concept drawing of a possible neo1973 gaming version:
(This has a 4-way direction pad, 8 way may be better for gaming)
 
[[Image:Neogame90.jpg]]
 
Shoulder buttons would be a great addition, too. It would be interesting if there was a total 4 of them, one for every corner. It would make the phone very flexible for rotating and 2 to 6 players playing on one device.
 

===Thumb keyboard or keyboard attachment accessory===
*Could be slide out or clamshell (hinge on long side) design with an external OLED. The keyboard should be protected when not in use.
*Could be a clip on keyboard that attaches to the serial port or communicates by bluetooth (not preferred for permanent keyboard users).
*Cheap clippable miniusb keyboard
*One of the layouts proposed in [[Hardware:Keyboards]]
* What about virtual keyboard? [[http://www.extremetech.com/article2/0,3973,539778,00.asp Keyboard]]

===Trackball===
A trackball would provide an efficient mouse-like interface in a very compact package. As exemplified in the newer Blackberry® models.
Maybe instead an optical sensor as are used in mice could be used so that the whole phone can be moved over a surface just like a mouse. The same sensor might be usable as a barcode reader

===Analog Joystick===
A joystick, or [http://www.extremetech.com/article2/0,1697,1772689,00.asp Rollermouse]-like device would provide additional control, compared with touchscreen only.

===TV/radio receiver===
[[Digital Television]], [[Digital Radio]] or even normal analogue TV/radio is available widely in the world. Though unfortunately in various different forms. In markets where one standard is widespread, and hardware is suitable, it would be a great extension of the phone to a general entertainment device for when you're away from home. Multi standard devices would be ideal, but may not be small, low-power, or cheap.

===Accelerometer===
This enables the phone to sense which direction 'down' is, and to sense any movements the phone makes.

See [[Accelerometer Fundamentals]] for more information on accelerometers as they may be used in phones.

In some cases integrated gyroscopes may also be needed.

*[[Wishlist:3D Viewport|3D Viewport]]
*[[Wishlist:Computer Mouse|Computer Mouse]]
*[[Wishlist:Determine Position|Determine Position]]
*[[Wishlist:Dynamic Screen Orientation|Dynamic Screen Orientation]]
*Change media player playlist when jogging vs walking.
*Attempt to use to stabilise any future camera.

===Side-Mounted Touch Strip===
Add a "touch strip" sensor onto the side of the phone which can be used to scroll. By having it on the side you can use your thumb to scroll comfortably while holding the phone one-handed. An 8-element capacitive sensor would work wonderfully and be easy to fab using either a Quantum QT411 (http://www.qprox.com/products/qslide_qt411.php) or Analog Devices AD7143 (http://www.analog.com/en/prod/0,2877,AD7143,00.html) controller. The Analog Devices chip seems better suited due to it's smaller allowable element size. With the AD7143 you can have an 8-element (128-position) 25mm long strip - Perfect!.

===Heart Rate Compatibility===

An RF interface to receive data from popular heart rate straps (Polar, Garmin, Sigma, Suunto, etc.). This would go along well with the existing GPS functionality and possible future Accelerometer functionality to make for a full-blown workout tool.

Software can be written to track heart rate along a running, cycling, skiing, swimming loop, to monitor max and min heart rate, to match heart rate data to GPS coordinates and print map data w/ relevant data.

===Digital compass===
A digital compass is useful for orienting maps to the terrain when the user is standing still (regardless of GPS reception) and for following a bearing when GPS reception is poor.

===Thermometer===
An electronic thermometer might become handy for some users.

There are very small [[I2C]] devices available, that could easily integrate to the existing bus. For example [http://focus.ti.com/docs/prod/folders/print/tmp100.html this one from ti].

===Barometer and Variometer===

A Barometer measures air pressure. This can be used to give weather information, and also as a variometer, to sense relative altitude. Variometers are commonly used in flying microlight and ultralight aircraft, to get accurate relative altitude.

See [[Wish List - Hardware - Atmospheric]] for more information.

===Finger print sensor===
A fingerprint sensor gives easy and fast access to the phone, could lock the touchscreen etc. An example of this device can be found at [http://www.sonystyle.com/is-bin/INTERSHOP.enfinity/eCS/Store/en/-/USD/SY_BrowseCatalog-Start?CategoryName=cpu_VAIONotebookComputers_UX_Series&Dept=computers Sony UX17].

Most fingerprint sensors in the embedded market include a navigation mode, where they work similar to either a touch-stick or touch-pad of a laptop.

===Barcode Scanner===
*less cpu intensive and more reliable than camera+ocr
*though, bluetooth-enabled readers are already available.

===Light Sensor===
Ability to sense ambient light, and act accordingly. i.e if it's 3am and LightValue<.1 then Ring Quietly.

==Expansion==

===MMC/SD/SDIO slot (rather than?) miniSD or microSD===
*Cheaper, more durable cards in a widely accepted format.
*Cards are harder to lose
*Wider selection of accessories, including SDIO accessories.
*Make externally available so that larger length SDIO cards can be used (thinking about SDIO WLAN here)

===Two SD slots===
*Micro SD for /home partition.
*Hot swappable mini or normal SD for movie, music etc.

=== USB ===
* USB 2.0
* Powered, to avoid having to carry around a hub for when you want to occasionally plug in a memory stick. Many powered hubs will not recognize a totally unpowered host.
* OTG (is this maybe supported already ?)
* Bootable USB device emulation: the possibility to boot any computer on a bootable flagged partition of the transflash.

===Wireless USB support===
[http://en.wikipedia.org/wiki/Wireless_USB Wireless USB] is the wireless version of USB offering data-rates up to 480 Mbit/s over short distances (<3 meter). Chipsets suitable for a phone are likely to take some time to be available.

===SIR/FIR transceiver (Serial Infrared) / IR remote control ===
*An infrared transceiver is cheap, small, and useful for sync with many laptops and mobile phones.
**FIR would be a nice option, as it's some 40 times faster than SIR.
Other uses.
*Learning infra-red remote control with macros.
*Detecting reflections from inside of a caddy, and switching from active mode.
*FIR would be a nice option, as it's some 40 times faster than SIR.

===I2C breakout===
[[I2C]] is an internal 2-3 wire bus in the phone. It is low powered, and can be daisy-chained. It would be a great candidate to bring out into the [[Expansion Back]] with an additional connector.

Readily available [[I2C]] chips range from temperature sensing, digital input/output chips to 1-wire bridge chips (which is designed for external switches, ID, sensing, ...)

==Output devices==

===LED===
*A blinking LED would be a cheap, low power way to inform the user of new SMS/Email....
**An alternative to this would be for one small part of the LCD to be separately backlit.
**This requires the CPU and LCD to be somewhat active, to keep the LCD refreshed, but gives much more information.

*For example a multicolor LED which pulses yellow for GSM/GPRS transmit, blue for Bluetooth/Wifi, green to indicate non-urgent information - missed call etc, red to indicate battery low or other urgent notices.

**The LED and button ideas could be combined: illuminated buttons.
**It must be possible to completely disable the LED to save power or other personal preferences.

=== Flashlight ===
For finding keys, or any other application. May also optionally pulse in time with ring, to make phone more visible.

=== FM transmitter ===
Small FM transmitter to output to car, and other nearby radios.

==Mobile Communication options==

===Faster/better mobile connectivity.===
[http://en.wikipedia.org/wiki/Gsm GSM]/[http://en.wikipedia.org/wiki/GPRS GPRS] is at best slow. Ideally supporting [http://en.wikipedia.org/wiki/EDGE EDGE ]- which is an evolved form of GPRS. [http://en.wikipedia.org/wiki/UMTS UMTS] - which is widespread in Europe, [http://en.wikipedia.org/wiki/HSDPA HSDPA] (asia) and any other mobile standards would be nice for faster data connectivity and coverage.
It is unlikely that all of these will be supported initially, but it is a goal.
Until that goal is reached, it is likely that some phones will be brought out for various specific markets - Europe, Asia, US.

===Ability to use multiple SIMs/networks===
* External SIM sockets are widely available in China, a dual external socket would be a very good solution.
* [http://www.fonefunshop.co.uk/dualsim/digital.htm Dual SIM card kit] - two SIMs are trimmed and combined, software supportwould be needed, and both can't be used at once...
* Some networks support multiple numbers on one SIM. Unfortunately this won't allow split networks.
* A second/dual GSM module would allow full use of both sims at all times.
* As a hack, [http://wiki.openmoko.org/wiki/Wish_List#Bluetooth_powered_Multi-SIM_support use another mobile via BT].

===PMR446/FRS Radio===
* Include a PMR/FRS Radio.
* A two-way walkie talkie lets you use the phone to communicate with friends without requiring a GSM connection (crowded networks at festivals, at locations with no GSM coverage).

===DECT/GAP===
* Include a DECT/GAP transceiver so you can use your home and/or office PSTN line

==Casing==
===[[Expansion Back]]===
* Replacement backs with additional features ranging from solar power, larger batteries, extra hardware, ...

===Space efficient Lanyard===
The hole at the bottom of the phone takes a lot of space. A Kensington Security Slot could be used instead.

=== Ruggedized version ===
We need something you can drop from 4 feet in to a puddle of dirty water on construction site. You know the big ugly pseudo military version.

=== Transparent ===
Make a transparent, see-through casing. Why do we need a closed casing for open hardware and open software? Show the world it is a truly Free/Open source phone.

==Accessories==
Some of the ideas mentioned below would make great accessories which could be sold separately.

===Special covers===
Different special covers could be made available with features like:
* A standard slip-on or clip-on template (possibly with buttons) to make the touch-screen blind accessible
* Small metal frame for protection (like Siemens M65, only with more style)
* Case with mirror on the back, for putting on makeup/checking appearance or helping with self-portraits with an integrated camera.
* Option to completely design printable case styles, perhaps with engraving. Ability to share these on a 'community' site.
* Solar powered recharger (perhaps as extendable/unfoldable [[Expansion Back]]).
* Rubber protection like available for iPod, of course in different colors and transparency.

===Car kit===
A car kit with a cradle which simultaneously recharges the device.

===Charger conversion connector===
A flexible converter allowing you to recharge the Neo1973 with power from many DC sources such as other devices chargers.
Problems are that it may overload the DC source. It may require sensing of the input voltage, and reducing load if the voltage drops by a factor. Ideally the device should accept input voltage in the range of around 3.3v-28V in either polarity.

==Misc==
===Galileo/GLONASS/GPS receiver===
*A multi-standard satellite positioning module would be nice eventually, it does not seem to be near-term due to chipset availability problems. Galileo is the to be launched (2011) European positioning system. GLONASS is the already existing Russian one.

===X10 RF Remote===
Many PC-based media centers are being equipped with an RF (433 MHz) / X10-based remote control. The [http://en.wikipedia.org/wiki/X10_(industry_standard) X10] protocol also facilitates home automation to control lamps, switches, etc.
The advantages of using RF for control instead of Infra-red this that it also works when furniture, walls, or doors are blocking the path between RF remote and the equipment or device. [http://www.lirc.org/ Lirc] supports X10-based RF remotes (but expects having an USB RF receiver attached to the media center).

===RFID tag/RFID Reader===
* Implementation/Cooperation with: [http://www.rfidguardian.org/ RFID-Guardian]
*An enable-able tag would be of use - for example being able to use the phone to open doors, or cars. Unfortunately, it's moderately hard to do secure programmable tags that are compatible with existing systems, for obvious reasons.

===Standard 3.5mm headphone jack===
The Neo1973 uses a 4-conductor 2.5mm jack for stereo headphones and a microphone. 2.5mm jacks are the commonest headset format.

Adapters to 2.5mm are of course available, but 3.5mm jacks are much more robust.

There is an emerging convention used in the Nokia N800 and some other devices. A 4-conductor 3.5mm jack that can use a microphone with special headsets, but can also be used with off-the-shelf 3.5mm stereo headphones.

Neglecting space limitations, multiple sockets - 2.5mm and 3.5mm would be nice. Probably not practical in a phone.
Other expanded plugs might allow remote controls.

Other uses might be better met using bluetooth, or USB audio.

===Laser Pointer===
Include a built in laser pointer. Everything is better with lasers.

===Completely free hardware===
Consider selling one device with absolutely no non-free components in it, even if that means dropping the GSM support. I believe having one such device available would be good, because then it could be recommended by organizations like the FSF which typically never recommends anything if it has even a little non-free code in it.

=== Consider economy / inexpensive / less featured edition ===
Some people want less features, because they do not need them. Leaving out some features either lets the phone get smaller or possibly enhances battery live.

One big suggestion in this area is a b/w lower res display instead of the big colour display.

User:Eric

2007-07-05T07:59:02Z

Eric:

That's right. It's me.