Openmoko - User contributions [en]

Qi

2009-03-14T17:43:44Z

Peterpall:

[[image:Screenshot-Qi.png|frame|Qi Boot messages]] Qi ( [[http://zh.wikipedia.org/wiki/气| '''氣''' ]] ) is a lightweight replacement for the [[Uboot|uBoot]] bootloader with everything that doesn't assist "loading" and "booting" Linux stripped out.

Its advantages comparing to [[Uboot|u-boot]] are:
* actively developed (u-boot on GTA02 is deprecated)
* easier configuration, more robust and predictable
* SD and SDHC cards supported properly with partitions of any size
* kernel size is detected by checking the start of the kernel image, so large (>2M) kernels are supported without tweaking or loading more than needed
* Very fast, simple boot direct to Linux

==About Qi==
===Requirements===
There is a [[Neo1973|GTA01]] build of Qi, but using it without a debug board is not recommended because Qi itself does not support DFU, so updating or going back to U-Boot is a difficult process.

[[Freerunner|GTA02 Hardware]] has NOR U-Boot always available to update Qi so it's safe to try it out.

===Features===
* booting from primary SD partitions (1st, 2nd or 3rd) in /boot directory
* booting from NAND (compatible with U-Boot's dynparts scheme)
* configuration per rootfs, by files in /boot in the rootfs
* automatically choose correct kernel for device hardware so rootfs can be used on multiple device types
* automatically tell kernel correct root= for rootfs kernel image came from, simplifying update
* ext2/3 are supported
* symlinks are supported
* parses identity partition and appends kernel commandline with device identity information
* zero "environment" or private persistent state - operation is completely deterministic

===Limitations===
* no DFU-Mode - USB is not initialized at all
* no boot menu
* FAT partitions are ignored

Both the lack of DFU and the boot menu are planned to be addressed by the backup / recovery rootfs.

FAT is not supported because it can't provide a rootfs, and Qi wants the kernel to come from the rootfs.

===Defaults===
If the kernel is found on uSD, Qi assumes the rootfs to be on the same partition as the kernel. In case of boot from NAND, it assumes that rootfs is also on NAND (just as u-boot does). See [[#/boot-Partition|below]] for help with an extra /boot-partition. The default rootdelay is 1 second.

===Files===
; /boot/uImage-GTA0[123].bin
: Kernel images, Qi will look for (can be in either uImage (u-boot image) or zImage format, file name should still be uImage-GTA0[123].bin)
; /boot/append-GTA0[123]
: Additional kernel arguments. All arguments should be on the first and the only line separated by spaces, for example: "<tt>loglevel=8 rootdelay=5 </tt>" . Make sure you have an extra space after the last argument (space is no longer needed if the version is from 31 Jan or older)!
; /boot/noboot-GTA0[123]
: make Qi skip this partition

===Speed up kernel resume for SHR===
Since SHR (and perhaps other distributions as well) ouput log messages during resume which slow down the resume process by ca. 3 seconds it make sense there to append the following settings to /boot/append-GTA0[123]:
: loglevel=1 quiet
The disadvantage of this speedup is that you won't see any lifesign of your phone until it starts the graphical user interface after adding these files, though.
===Boot Order===
[[image:Qi-drawings-bootsequence.png|frame|Qi GTA02 Booting order]]
# SD Partition 1
# SD Partition 2
# SD Partition 3
# NAND
# Memory Test

Qi will try to mount each SD partition as ext2 / 3, if that succeeds it will look for the kernel as /boot/uImage-GTA02.bin. If that is found, it'll be fetched, its CRC is checked and then it's booted into with a generated kernel commandline.

===Kernel Commandline Generation===
[[image:Qi-commandline-composition.png‎|frame|Qi commandline composition]]
Because Qi has no private stored state, it infers and composes a suitable kernel commandline on each boot.

One of its tasks is to scan NAND memory using the U-Boot dynparts rules to determine the start offset
of the NAND partitions on this device, from that it forms the mtdparts kernel parameter that sets Linux's
view of NAND partitioning.

The other thing it does is mount the "identity" partition and get from there the globally unique MAC
address for the USB over Ethernet function instead of the random one that is otherwise used.

===LED and Vibrator Signals===
* AUX LED is turned on either on:
** Successful partition mount
** Successful kernel pull
** Successful initramfs pull
* AUX LED is turned off and vibrator runs briefly either on:
** Fail of kernel pull
** Fail of initramfs pull
** Fail of mount partition
** Skipping of current boot possibility
* AUX LED is turned off either on:
** Start of the kernel
** Start of the mem test
** Start of the kernel pull
** Start of the initramfs pull
* One Blue shine every ~10 second: did not find any valid kernel to boot
* About four RED shines per second: kernel panic.

===Booting===
A short press on the power button is enough to make Qi start booting. In a few seconds the backlight will be lit, but the kernel will not spew any console messages unless something is wrong. It may take up to 2 minutes (depends on distribution) until X is started during which there will be no visual feedback. Please be patient.

You can force debug messages on the LCM console by holding in the power button before Linux starts.

===Choosing a Kernel===
If a user presses the AUX button after successful partition mount and
before start of the kernel pull (that is, while the red LED is on),
this boot possibility is skipped (and GTA02 owners can feel
vibration).

On versions newer than Jan 18 if a user holds the POWER button just before start of the kernel,
debugging parameters are added to the kernel command line and a lot of information is output to the screen.

===Boot Menu===
Qi's concept is to leave everything possible to Linux, that includes even the video init. Therefore Qi does NOT provide a boot menu. This should rather be implemented by a minimal Kernel, initramfs and menu system. It may be more comfortable for some users and may get them to switch from uboot to Qi. This does not exist yet (it's already implemented for some Angstrom-supported devices and for Zaurus, so porting should be relatively easy).

===Download and installation===
The daily download is a ''qi-s3cXXXX-andy_somenumber.udfu'' file at http://people.openmoko.org/andy/ .
Use the file appropriate to your device:
*GTA01 -> qi-s3c2410
*GTA02 -> qi-s3c2442
*GTA03 -> qi-s3c6410

The installation should be flashing like (do it in DFU mode of NOR u-boot):
# dfu-util -a u-boot -R -D qi-s3c6410-andy_8589b40295653557.udfu

===Source code===
git://git.openmoko.org/git/qi.git , http://git.openmoko.org/?p=qi.git;a=summary .
One can also just use strings(1) on the .udfu file to get an idea of where Qi currently looks for files.

===README===
The latest README file can be found in the git as well:http://git.openmoko.org/?p=qi.git;a=blob;f=README;hb=HEAD

==Tips, Tricks, Tweaks==
===General troubleshooting===
Qi does not bring up the LCD backlight. If the backlight is lit, it means you have succeeded to boot into Linux.

If nothing else is happening or there is a panic, enable debugging messages as described below.

===Enabling console messages===

You can just hold in the power button, this automatically appends verbose debugging to the kernel commandline (loglevel=8).

If you always want verbose "dmesg" type debugging messages, you can do it like this:

[http://lists.openmoko.org/pipermail/openmoko-kernel/2008-November/006812.html]
If it's SD Card boot, just create a text file, e.g., for a [[GTA02]] use
/boot/append-GTA02
on the rootfs in question, put in there
loglevel=8
and you'll see the messages on boot. If it's NAND right now you need to edit the default commandline in Qi for gta02.

===/boot-Partition===
If you have a separate partition for /boot, so that your kernel and rootfs are not in fact on the same partition, you will need to append a root= entry on the kernel commandline to override the default action of trying to use the partition where the kernel came from as the rootfs.

Add this in /boot/append-GTA0[123]:
root=/dev/mmcblk0p2
for a rootfs on the second partition.

Note that a default Debian installation puts the kernel straight in the root of /dev/mmcblk0p1, not in a boot subdirectory, expecting u-boot to mount it as /boot. In order for Qi to recognise this, create a boot subdirectory with a symlink to the kernel.

===SD Initialisation===
If you don't specify loglevel=8 in append-GTAXX, and booting fails with a "VFS: Cannot open root device "mmcblk0p1" or unknown-block(2,0)", the SD card needs a little bit more time to initialise.

Put a "rootdelay=5" in append-GTAXX like so:
rootdelay=5

== Testing speed improvements ==

Stopwatch results on Qi (error is approx ±1/2 second):

Booting SHR image with uBoot:
* 0:00 power button held down
* 0:07 splash screen appears
* 0:15 drops to console showing kernel messages scrolling by for ~1 minute
* 1:18 Openmoko 'please wait' splash
* 1:31 desktop animated splash
* 2:38 finished booting

Booting identical setup with Qi flashed over uBoot:
* 0:00 power button held down
* 0:06 backlit black
* 0:13 please wait booting... (only this text on console for next 38 seconds)
* 0:51 Angstrom console message (at the end of kernel output with uBoot, but ONLY text display to appear throughout this stage with Qi)
* 0:54 Openmoko 'please wait' splash
* 1:05 desktop animated splash
* 1:54 finished booting

So for this particular configuration, it reduced time-to-desktop by about 28%, about 44 seconds. Surprisingly, the later segments of booting (desktop) were also noticeably faster than with uBoot - One would have expected just the fist stages up until init (kernel finished establishing itself) to be faster.

[[Category:System Developers]]

Qi

2009-03-14T17:01:08Z

Peterpall: /* Speed up resume */

[[image:Screenshot-Qi.png|frame|Qi Boot messages]] Qi ( [[http://zh.wikipedia.org/wiki/气| '''氣''' ]] ) is a lightweight replacement for the [[Uboot|uBoot]] bootloader with everything that doesn't assist "loading" and "booting" Linux stripped out.

Its advantages comparing to [[Uboot|u-boot]] are:
* actively developed (u-boot on GTA02 is deprecated)
* easier configuration, more robust and predictable
* SD and SDHC cards supported properly with partitions of any size
* kernel size is detected by checking the start of the kernel image, so large (>2M) kernels are supported without tweaking or loading more than needed
* Very fast, simple boot direct to Linux

==About Qi==
===Requirements===
There is a [[Neo1973|GTA01]] build of Qi, but using it without a debug board is not recommended because Qi itself does not support DFU, so updating or going back to U-Boot is a difficult process.

[[Freerunner|GTA02 Hardware]] has NOR U-Boot always available to update Qi so it's safe to try it out.

===Features===
* booting from primary SD partitions (1st, 2nd or 3rd) in /boot directory
* booting from NAND (compatible with U-Boot's dynparts scheme)
* configuration per rootfs, by files in /boot in the rootfs
* automatically choose correct kernel for device hardware so rootfs can be used on multiple device types
* automatically tell kernel correct root= for rootfs kernel image came from, simplifying update
* ext2/3 are supported
* symlinks are supported
* parses identity partition and appends kernel commandline with device identity information
* zero "environment" or private persistent state - operation is completely deterministic

===Limitations===
* no DFU-Mode - USB is not initialized at all
* no boot menu
* FAT partitions are ignored

Both the lack of DFU and the boot menu are planned to be addressed by the backup / recovery rootfs.

FAT is not supported because it can't provide a rootfs, and Qi wants the kernel to come from the rootfs.

===Defaults===
If the kernel is found on uSD, Qi assumes the rootfs to be on the same partition as the kernel. In case of boot from NAND, it assumes that rootfs is also on NAND (just as u-boot does). See [[#/boot-Partition|below]] for help with an extra /boot-partition. The default rootdelay is 1 second.

===Files===
; /boot/uImage-GTA0[123].bin
: Kernel images, Qi will look for (can be in either uImage (u-boot image) or zImage format, file name should still be uImage-GTA0[123].bin)
; /boot/append-GTA0[123]
: Additional kernel arguments. All arguments should be on the first and the only line separated by spaces, for example: "<tt>loglevel=8 rootdelay=5 </tt>" . Make sure you have an extra space after the last argument (space is no longer needed if the version is from 31 Jan or older)!
; /boot/noboot-GTA0[123]
: make Qi skip this partition

Note that setting the loglevel some low value (must be >=1, though!) makes resume about 3 seconds faster than it is without: Without setting this parameter the kernel produces loads of log information on resume which is output on a console with very slow scrolling.
===Boot Order===
[[image:Qi-drawings-bootsequence.png|frame|Qi GTA02 Booting order]]
# SD Partition 1
# SD Partition 2
# SD Partition 3
# NAND
# Memory Test

Qi will try to mount each SD partition as ext2 / 3, if that succeeds it will look for the kernel as /boot/uImage-GTA02.bin. If that is found, it'll be fetched, its CRC is checked and then it's booted into with a generated kernel commandline.

===Kernel Commandline Generation===
[[image:Qi-commandline-composition.png‎|frame|Qi commandline composition]]
Because Qi has no private stored state, it infers and composes a suitable kernel commandline on each boot.

One of its tasks is to scan NAND memory using the U-Boot dynparts rules to determine the start offset
of the NAND partitions on this device, from that it forms the mtdparts kernel parameter that sets Linux's
view of NAND partitioning.

The other thing it does is mount the "identity" partition and get from there the globally unique MAC
address for the USB over Ethernet function instead of the random one that is otherwise used.

===LED and Vibrator Signals===
* AUX LED is turned on either on:
** Successful partition mount
** Successful kernel pull
** Successful initramfs pull
* AUX LED is turned off and vibrator runs briefly either on:
** Fail of kernel pull
** Fail of initramfs pull
** Fail of mount partition
** Skipping of current boot possibility
* AUX LED is turned off either on:
** Start of the kernel
** Start of the mem test
** Start of the kernel pull
** Start of the initramfs pull
* One Blue shine every ~10 second: did not find any valid kernel to boot
* About four RED shines per second: kernel panic.

===Booting===
A short press on the power button is enough to make Qi start booting. In a few seconds the backlight will be lit, but the kernel will not spew any console messages unless something is wrong. It may take up to 2 minutes (depends on distribution) until X is started during which there will be no visual feedback. Please be patient.

You can force debug messages on the LCM console by holding in the power button before Linux starts.

===Choosing a Kernel===
If a user presses the AUX button after successful partition mount and
before start of the kernel pull (that is, while the red LED is on),
this boot possibility is skipped (and GTA02 owners can feel
vibration).

On versions newer than Jan 18 if a user holds the POWER button just before start of the kernel,
debugging parameters are added to the kernel command line and a lot of information is output to the screen.

===Boot Menu===
Qi's concept is to leave everything possible to Linux, that includes even the video init. Therefore Qi does NOT provide a boot menu. This should rather be implemented by a minimal Kernel, initramfs and menu system. It may be more comfortable for some users and may get them to switch from uboot to Qi. This does not exist yet (it's already implemented for some Angstrom-supported devices and for Zaurus, so porting should be relatively easy).

===Download and installation===
The daily download is a ''qi-s3cXXXX-andy_somenumber.udfu'' file at http://people.openmoko.org/andy/ .
Use the file appropriate to your device:
*GTA01 -> qi-s3c2410
*GTA02 -> qi-s3c2442
*GTA03 -> qi-s3c6410

The installation should be flashing like (do it in DFU mode of NOR u-boot):
# dfu-util -a u-boot -R -D qi-s3c6410-andy_8589b40295653557.udfu

===Source code===
git://git.openmoko.org/git/qi.git , http://git.openmoko.org/?p=qi.git;a=summary .
One can also just use strings(1) on the .udfu file to get an idea of where Qi currently looks for files.

===README===
The latest README file can be found in the git as well:http://git.openmoko.org/?p=qi.git;a=blob;f=README;hb=HEAD

==Tips, Tricks, Tweaks==
===General troubleshooting===
Qi does not bring up the LCD backlight. If the backlight is lit, it means you have succeeded to boot into Linux.

If nothing else is happening or there is a panic, enable debugging messages as described below.

===Enabling console messages===

You can just hold in the power button, this automatically appends verbose debugging to the kernel commandline (loglevel=8).

If you always want verbose "dmesg" type debugging messages, you can do it like this:

[http://lists.openmoko.org/pipermail/openmoko-kernel/2008-November/006812.html]
If it's SD Card boot, just create a text file, e.g., for a [[GTA02]] use
/boot/append-GTA02
on the rootfs in question, put in there
loglevel=8
and you'll see the messages on boot. If it's NAND right now you need to edit the default commandline in Qi for gta02.

===/boot-Partition===
If you have a separate partition for /boot, so that your kernel and rootfs are not in fact on the same partition, you will need to append a root= entry on the kernel commandline to override the default action of trying to use the partition where the kernel came from as the rootfs.

Add this in /boot/append-GTA0[123]:
root=/dev/mmcblk0p2
for a rootfs on the second partition.

Note that a default Debian installation puts the kernel straight in the root of /dev/mmcblk0p1, not in a boot subdirectory, expecting u-boot to mount it as /boot. In order for Qi to recognise this, create a boot subdirectory with a symlink to the kernel.

===SD Initialisation===
If you don't specify loglevel=8 in append-GTAXX, and booting fails with a "VFS: Cannot open root device "mmcblk0p1" or unknown-block(2,0)", the SD card needs a little bit more time to initialise.

Put a "rootdelay=5" in append-GTAXX like so:
rootdelay=5

== Testing speed improvements ==

Stopwatch results on Qi (error is approx ±1/2 second):

Booting SHR image with uBoot:
* 0:00 power button held down
* 0:07 splash screen appears
* 0:15 drops to console showing kernel messages scrolling by for ~1 minute
* 1:18 Openmoko 'please wait' splash
* 1:31 desktop animated splash
* 2:38 finished booting

Booting identical setup with Qi flashed over uBoot:
* 0:00 power button held down
* 0:06 backlit black
* 0:13 please wait booting... (only this text on console for next 38 seconds)
* 0:51 Angstrom console message (at the end of kernel output with uBoot, but ONLY text display to appear throughout this stage with Qi)
* 0:54 Openmoko 'please wait' splash
* 1:05 desktop animated splash
* 1:54 finished booting

So for this particular configuration, it reduced time-to-desktop by about 28%, about 44 seconds. Surprisingly, the later segments of booting (desktop) were also noticeably faster than with uBoot - One would have expected just the fist stages up until init (kernel finished establishing itself) to be faster.

[[Category:System Developers]]

OpenMooCow

2009-01-19T06:07:52Z

Peterpall: */ New release. */

{{ApplicationBox|
Name=OpenMooCow|
Screenshot=Moocow1.png|
Description=OpenMooCow reads information out of your accelerometers. Now, if you turn the phone upside down and back again, it "moos" like one of the little toys you might know...|
Homepage=http://www.srcf.ucam.org/~taw27/openmoko/openmoocow/|
TestedOn=Om 2008.8|
PackageName=OpenMooCow
}}
'''Source Code released:http://www.srcf.ucam.org/~taw27/openmoko/openmoocow/'''

==Introduction==
OpenMooCow reads information out of your accelerometers. Now, if you turn the phone upside down and back again, it "moos" like one of the little toys you might know...

Nevertheless, it's great fun to try it out!FreeRunner mooes on flip.

==Installation==
Package and source download from http://www.srcf.ucam.org/~taw27/openmoko/openmoocow/

For install:
opkg install http://www.srcf.ucam.org/~taw27/openmoko/openmoocow/openmoocow_0.3_armv4t.ipk

==Video==
http://www.youtube.com/watch?v=k6-tuZp6J3w

[[category:Gaming]]

Mokoko

2008-12-17T19:09:31Z

Peterpall: /* Release information */

Mokoko is a mediaplayer program develop by OM software engineers.
You can download ipk from [http://om-mediaplayer.googlecode.com/files/mokoko_0.1_svnr119_r0_armv4t.opk here]

[http://code.google.com/p/om-mediaplayer/wiki/Mokoko Project's home wiki].

===Release information===
* Date: 20081022

* SVN revision: 119

The release from december the 1st won't install on shr since some dependencies cannot be matched, --- but the files that mokoko needs are core gtk files and clearly there. A
opkg install --force-depends http://om-mediaplayer.googlecode.com/files/mokoko_0.1_svnr127-r1_armv4t.opk

did therefore install a working version of it.

===Documentation===
We used doxygen to generate documentation from source code. You can generate it by yourself. Install doxygen first and use the script we provide.

The script is placed in

<blahblah>/om-mediaplayer/mokoko/gendoc

Or you can see it online. I put it in Here Download and Install

* get mokoko opk file and upload it to Neo.(Get it here)

* opkg install mokoko

the dependency suppose be installed automatically.

Mokoko.conf

We didn't implement Song Select yet. please add .mokoko.conf to your home direcotory.

$cat ~/.mokoko.conf

# This file defines the setting of momoko
# Features will be stored as string sep is ';'
# If there are no such Feature NULL will returns
PATH="/home/foo/mp3;/media/card/mp3"
SUPPORT_MIME="mp3;ogg"
PAUSE_WHEN_RING_EVENT="true"
RESTART_WHEN_CALL_END_EVENT="false

{{ApplicationBox|
Name=[[Mokoko]]|
Description=Mokoko is a media player program, you can use it to play mp3 and ogg files on Neo.|
Screenshot=Mokoko.png|
Homepage=http://code.google.com/p/om-mediaplayer/|
TestedOn=|
PackageName=http://om-mediaplayer.googlecode.com/files/mokoko_0.1_svnr119_r0_armv4t.opk
}}

[[Category:Audio Applications]]

Mokoko

2008-12-17T19:08:47Z

Peterpall: /* Release information: How to make the current release work. */

Mokoko is a mediaplayer program develop by OM software engineers.
You can download ipk from [http://om-mediaplayer.googlecode.com/files/mokoko_0.1_svnr119_r0_armv4t.opk here]

[http://code.google.com/p/om-mediaplayer/wiki/Mokoko Project's home wiki].

===Release information===
* Date: 20081022

* SVN revision: 119

The release from december the 1st won't install on shr since some dependencies cannot be matched, --- but the files that mokoko needs are core gtk files and clearly there. A
opkg install --force-depends http://om-mediaplayer.googlecode.com/files/mokoko_0.1_svnr127-r1_armv4t.opk

===Documentation===
We used doxygen to generate documentation from source code. You can generate it by yourself. Install doxygen first and use the script we provide.

The script is placed in

<blahblah>/om-mediaplayer/mokoko/gendoc

Or you can see it online. I put it in Here Download and Install

* get mokoko opk file and upload it to Neo.(Get it here)

* opkg install mokoko

the dependency suppose be installed automatically.

Mokoko.conf

We didn't implement Song Select yet. please add .mokoko.conf to your home direcotory.

$cat ~/.mokoko.conf

# This file defines the setting of momoko
# Features will be stored as string sep is ';'
# If there are no such Feature NULL will returns
PATH="/home/foo/mp3;/media/card/mp3"
SUPPORT_MIME="mp3;ogg"
PAUSE_WHEN_RING_EVENT="true"
RESTART_WHEN_CALL_END_EVENT="false

{{ApplicationBox|
Name=[[Mokoko]]|
Description=Mokoko is a media player program, you can use it to play mp3 and ogg files on Neo.|
Screenshot=Mokoko.png|
Homepage=http://code.google.com/p/om-mediaplayer/|
TestedOn=|
PackageName=http://om-mediaplayer.googlecode.com/files/mokoko_0.1_svnr119_r0_armv4t.opk
}}

[[Category:Audio Applications]]

Booting the Neo FreeRunner from SD via U-Boot

2008-12-02T18:38:04Z

Peterpall: /* Add uboot boot entry: The read only flag ('ro') breaks current versions of openmoko, so I removed it.*/

{{Languages}}
This page explains how to boot a FreeRunner from the [[Supported_microSD_cards|(micro-)SD card]] rather than from the built-in NAND flash memory. The SD card shares a bus with the GPU, so it may not perform as well, but it is another option.

{{Warning | Booting from SDHC may cause problems at this time (see below).}}

== Booting from SDHC / suspend problems ==

First, a warning. There is a longstanding bug, probably somewhere in the Linux kernel, that tends to eat the partition table of high-capacity SD cards when the system suspends. This is ticket [https://docs.openmoko.org/trac/ticket/1802 #1802]. See [http://thread.gmane.org/gmane.comp.handhelds.openmoko.community/19154/focus=19281| this thread] for explanation of the partition table removal on suspend and maybe other problems related to using high capacity SD cards. A safety net is to keep a written copy of the partition table on paper, just in case one needs to recreate it.

== How it Works ==

On the Neo, [[u-boot]] performs a similar role to the 'grub' bootloader on a PC. U-boot loads a kernel image into memory and then passes a list of parameters to the kernel. These parameters specify, among other things, the device on which the root filesystem is located.

As the kernel boots, it initializes the hardware and then mounts the root filesystem. The kernel then runs "/sbin/init", which handles the rest of the boot-up sequence (such as displaying the splash screen and progress bar).

This sequence is the same whether the device is booting from built-in Flash or from the SD card. The differences are how the kernel is loaded, and which device is mounted as the root filesystem.

The following sections provide additional details.

=== Menu Entries ===

U-boot menu entries are defined by environment variables named "menu_X" (where X is a number). The value of the environment variable is a string "<label>:<commands>", where <label> is the text shown on the screen, and <commands> is a sequence of u-boot commands (delimited by ';' characters) to be executed when the menu item is selected. When entering a string of commands, the ';' and '$' characters must be backslash-escaped ("\;" and "\$").

=== Loading the Kernel ===

A pair of u-boot commands must be used to load the kernel from SD. First is "mmcinit", which will cause u-boot to detect the card. Next is a command to load a file into memory - either "fatload" or "ext2load" depending on whether the kernel is on a FAT filesytem or an ext2/ext3 filesystem.

The command syntax is:

fatload mmc 1: 0x32000000 <filepath>
ext2load mmc 1: 0x32000000 <filepath>

where is the partition number, and <filepath> is the path to the file that is to be loaded.

{{Note| The "ext2load" command is broken on u-boot binary earlier than "20080723", including the one shipped with the first batch of FreeRunners, are affected by bug [http://docs.openmoko.org/trac/ticket/799 #799]. If you update your U-Boot and kernel packages you can use direct ext2 / 3 boot all in one partition.}}

{{Warning | Be careful when updating u-boot on a Neo1973 as there is a risk of bricking the device (unless you have a debug board). This is not an issue for the FreeRunner as it has a protected copy of u-boot in the NOR flash }}

{{Note| U-Boot supports SDHC protocol on the FreeRunner only: on the Neo1973, u-boot is unable to access SDHC cards (4G or larger). The kernel does have SDHC support on Neo1973, so it is possible to have the root filesystem on SDHC and the kernel on NAND flash to work around it. }}

=== Root Filesystem Parameters ===

The contents of the "bootargs" environment variable are passed to the kernel. Bootargs is a space-delimited list of "name=value" definitions. The items relevant to SD-booting are "root", "rootfstype", and "rootdelay".

For example, the following parameters would tell the kernel to mount the third partition of the SD-card as an ext3 filesystem:

root=/dev/mmcblk0p3 rootfstype=ext3 rootdelay=5

The "rootdelay" parameter allows time for the card to be properly initialized before it is accessed.

Note that the kernel must have built-in support (i.e. not a module) for the filesystem specified in "rootfstype". The default Openmoko kernel configs as of [http://git.openmoko.org/?p=kernel.git;a=commit;h=642cbda5f3b7e7a61512426e1d30a41ab4691123| 2008-07-17] have built-in support for both ext2 and ext3. You can check the available filesystems with the Linux command

less /proc/filesystems

It is not possible to use VFAT for the root filesystem.

==== ext2 vs. ext3 ====

Opinion is divided on whether it is better to use ext2 or ext3 for the root filesystem. Ext3 in general is a superior choice, because it is a journalled filesystem and so does not require a long 'fsck' (file system check) after an unclean shutdown. However, if used on a flash device that does not support wear-leveling then ext3 may cause premature wear on the blocks of the card where the journal is stored. SD cards are supposed to support wear leveling, but this can not be guaranteed for all vendors.

== Acquiring a tarfile rootfs ==

There are two ways of acquiring an rootfs image as a tar archive. You can either build it on your own using the OpenEmbedded Distribution. Or download it from the openmoko buildhost.

=== Possibility 1: Downloading the rootfs/kernel tar from the Openmoko buildhost ===

Choose and find the rootfs/kernel combo you would like to install at [[Latest Images]].

=== Possibility 2: Building a tarfile distribution using OpenEmbedded ===

Another possibility to get a tar archive of your rootfs is to build it on your own with the OpenEmbedded environment.

To build OM-2007.2 you need to add "tar" to the image types in your ''local.conf'':

IMAGE_FSTYPES = "jffs2 tar"

After that build a new image by issuing:

bitbake openmoko-devel-image

or if you are using the MokoMakefile:

make openmoko-devel-image

After the process finished there will be a ''Openmoko-....tar'' in the deploy directory, which is your newly created rootfs archive

=== Possibility 3 : Convert a jff2 image to a tarfile ===

See [[Userspace root image]] for more details on how to access contents of a jffs2 image.

== Prepare the SD card ==

=== Partioning the SD card ===

u-boot pre-2008-07-23 can only boot from FAT filesystems; if you update u-boot, you can boot from FAT or ext2.
This example shows how to do an example partition using the fdisk utility. Feel free to use the partitioning utility of your liking for this task.

fdisk /dev/mmcblk0

'''''Note:''''' The device file might differ on your system. If you are not sure about it, you may check your kernel message log by calling ''dmesg'' to find the correct device.

We will now create a 8 MB partition for our kernel and another one for the rootfs which will take up all the remaining space.

Command (m for help): d
Selected partition 1
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-983, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-983, default 983): +8M
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (18-983, default 18):
Using default value 18
Last cylinder or +size or +sizeM or +sizeK (18-983, default 983):
Using default value 983
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.

''Should probably need to change type of first partition to FAT 16 too ?''

''(type "t" in fdisk, choose the partition 1 and type "6" for FAT16. Check with "p", then type "w" to write)''

''How about a swap partition also?''

if it exits with something like

Calling ioctl() to re-read partition table
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy

do

umount /dev/mmcblk0p1

on another shell and try again.

=== Formatting the SD card ===

Just issue the following command to create at FAT filesystem:

mkfs.vfat /dev/mmcblk0p1
{{Note|if you do not have mkfs.vfat you must find and install the "dosfstools" package. This package does not seem to be in the official feeds, but an unofficial build may be downloaded from http://members.shaw.ca/mmontour/neo/dosfstools_2.11-r0_armv4t.ipk}}

The second partition is about to be formatted with ext3 (for ext2 to work you need to make sure you compiled the kernel with the correct configuration):

mkfs.ext3 /dev/mmcblk0p2

== Populate SD card ==

Your sd card is now ready to be filled up with the rootfs and the needed kernel to boot.

Mount the second partition of your SD card somewhere and put the image on it:

mount /dev/mmcblk0p2 /mnt/moko
tar -C /mnt/moko/ -xzvf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar.gz

'''''Note:''''' As always in this guide the device name as well as the rootfs name needs to be adjusted to your device and filename structure

'''''Note:''''' There's a nice gotcha to take care about if you use your host OS automount. Some hosts mount these removable devices with "nodev" option by default for security. If the image you are unpacking has a populated /dev directory, the nodes will fail to create as devices then. If automounting the SD on your host, confirm there are no unexpected mount options by using "mount" command alone to list the mounts.

The next step is to mount the first partition of the sd card and install the kernel on it.

mount /dev/mmcblk0p1 /mnt/mokokernel
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uImage.bin

Or, for some versions of NOR u-boot:

mount /dev/mmcblk0p1 /mnt/mokokernel
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uimage

(Yes, lower case i and no extension.)

Make sure your kernel is called ''uImage.bin'' (or ''uimage'' for some versions of NOR u-boot). If the u-boot doesn't find the kernel image during boot, [[Bootloader#Using usbtty from Linux|log into the bootloader]] with ''[http://www.airs.com/ian/uucp.html cu]'', mount the partition with mmcinit and check the presence and the name of the kernel image with ''fatls mmc 1:1'' for FAT filesystem or ''ext2ls mmc 1:1'' for ext2 filesystem. Compare this carefully with the result of ''printenv sd_image_name''. Remember that you can modify the environment in NAND FLASH, but not in NOR FLASH, so if you plan to boot from NOR FLASH you have to modify the file name to match the environment variable.

Unmount both the rootfs partition and the kernel partition and make sure all remaining buffers are written to it:

umount /mnt/moko
umount /mnt/mokokernel
sync

== Add uboot boot entry ==
*See also" [[Qi]]

Depending on the revision of the phone and the partition type (ext2/ext3) you are using, it might be necessary to add an entry to the bootmenu to be able to boot the system off your SD card.
If you are using a FreeRunner and have created an FAT kernel/ext2 rootfs partition you should be able to boot from the card right out of the box, because a boot menu entry for this should already exist in the NOR/NAND boot menu.
In any other case you should at least make sure the needed entry exists in your menu before proceeding.
You will need to enter the uboot shell of the NAND boot menu for this. A description on how to connect to the uboot loader shell can be found in this article: [[Uboot#Bootloader_prompt]]. Details on howto get into the NAND boot menu can be found [[Booting#Log_into_U-Boot_in_the_NAND_Flash|here]].

After you read these two references you should be connected to your NAND uboot shell right now. The first thing to do is to set the boot menu timeout to a really high value. Unfortunately if you don't do this, the boot loader will continue booting after the default timeout (60 seconds) even if you are connected to the uboot shell. Just enter the following command to the menu prompt:

<pre>
setenv boot_menu_timeout 99999
</pre>

This will set the timeout to 99999 seconds which should definitely enough time for us finish whatever work we want accomplish in the boot loader shell.

Now we will make sure a appropriate menu item for booting from sd exists, or create it otherwise. You can print the defined boot loader environment by issuing the command:

<pre>
printenv
</pre>

If it shows a line beginning with ''menu_'' followed by the commands which are just to follow in this guide, you do not need to create a new menu entry. In any other case please proceed with the following.

Please make sure you are using the correct configuration based on the decisions you made earlier. For more information on the uboot prompt, see
* help
* help <command>
* and [[Bootloader]] and [[Bootloader commands]].

{{Note| The backslashes (\) are important for uboot to set the command as new environment variable (menu_9) instead of just executing them as soon as enter is pressed.}}

{{Note| Copy and paste may not work depending on your terminal emulator. Commi just works or you can use [[NeoCon|neocon]] terminal emulator and add a per-character delay. Otherwise, you will have to type in the commandline manually.}}

It is important to distinguish between FAT or ext2 kernel partitions and ext2 or ext3 root partitions at this point.

Please watch partition numbers in the following commands. In particular, you may need to change some of
<pre>
root=/dev/mmcblk0p#
fatload mmc#
ext2load mmc#
</pre>
depending on which partition number your root and kernel, respectively, are located. Number starts from unity.

'''Boot entry for FAT kernel+ext3 rootfs partitions:'''

<pre>
setenv menu_9 Boot from microSD (FAT+ext3): setenv bootargs \${bootargs_base} rootfstype=ext3 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts}\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000
</pre>

'''Boot entry for FAT kernel+ext2 rootfs partitions:'''

<pre>
setenv menu_9 Boot from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts}\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000
</pre>

or: with additional 'init=/sbin/init' kernel parameter (may be needed for some images):

<pre>
setenv menu_9 Boot 200808 from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} init=/sbin/init\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000
</pre>

'''Boot entry for ext2 kernel+ext2 rootfs partitions: (requires newer u-boot)'''

<pre>
setenv menu_2 Boot from microSD part2 (ext2+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts}\; mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000
</pre>

'''Boot entry for kernel and rootfs on same ext2 partition (tested with Qtopia/requires newer u-boot)'''

<pre>
setenv menu_3 QTopia: setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p1 rootdelay=5 \${mtdparts}\; mmcinit\; ext2load mmc 1:1 0x32000000 \${sd_image_name}\; bootm 0x32000000
</pre>

You are nearly done. Just issue a

<pre>
printenv
</pre>

and verify that your newly created entry is correctly displayed (This time the backslashes are not displayed anymore).

If everything looks fine enter

<pre>
saveenv
</pre>

into the prompt and press enter. The new configuration should now be saved to the NAND.

Shutdown your neo with the following command:

<pre>
neo1973 power-off
</pre>

After you restarted the Neo and got back to the NAND boot menu you should be able to select your newly created menu entry and successfully boot into the rootfs from your SD card.

If you got error when loading kernel, add sleep to boot entry.

Before:
<pre>
mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\;
</pre>
After:
<pre>
mmcinit\; sleep 1\; ext2load mmc 1 0x32000000 \${sd_image_name}\;
</pre>

----

See also [[Moving current system from flash to SD]] which shows how to move the running system currently running in flash to an SD card, in order to keep a backup system on SD on which to boot from.

----

== Appendix ==

=== Boot from SDHC ===

{{Note|the following text was written for the Neo1973. SDHC and SD should both work in a FreeRunner if you have u-boot from 2008-07-23 or later.}}

As SDHC is not supported in older u-boot versions you can't use the Booting from SD guide.
But there's a kind of workaround that is a good option to have at least your rootfs on the microSDHC:

First you can follow Step 1 to get an kernel-image with mmc- and ext2-support. But instead of copying the image to the rootfs you will have to flash it to the Neo's internal NAND-Flash (using [[Dfu-util]]).
Now you can continue with Step 2 (like mentioned before you do not have to copy your uImage to the rootfs) and follow the instructions to Step 3.
Instead of the setenv commands in Step 3 you have to enter the following:

GTA01Bv4 # setenv menu_5 Boot from SDHC: setenv bootargs root=/dev/mmcblk0p1 console=tty0 rootdelay=5 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

And that's it!
Now you can use the newly created menu option "Boot from SDHC" to boot the internal kernel, using the root-filesystem on the microSDHC.

=== Autoboot from SDHC ===

Maybe you want to Boot automatically from SDHC:
Set a new Bootmenu Entry for booting from NAND first

GTA01Bv4 # setenv menu_6 Boot from NAND: setenv bootargs \${bootargs_base} \${mtdparts}\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

then Power-off, and enter the Bootmenu to test the new Entry.If you can boot from NAND, shutdown, enter Boot menu, connect to bootloader and set the (auto)bootcmd for boot from SDHC:

GTA01Bv4 # setenv bootcmd setenv bootargs root=/dev/mmcblk0p1 rootdelay=10 console=tty0 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Now you boot from SDHC everytime you press the Power-Button or reboot and if you like to boot from NAND -just use the bootmenu.

=== Fixing udev automount ===

Udev automatically mounts the SD Card in /media/mmcblk0p1/ you can disable this with

echo /dev/mmcblk >> /etc/udev/mount.blacklist

=== Remarks on Kernel Parameters ===

==== loglevel ====

Some people suggested adding:

loglevel=8

to the kernel command line. IF you also have "console=tty0" on your kernel commandline this makes the boot process extremely slow because the framebuffer (the neo display in text mode) has to print out tons of lines of debug messages like:

s3c2410-sdi s3c2410-sdi: ......
mmc0: ....

{{Languages|Booting_from_SD}}

[[Category:Advanced End User]]
[[Category:Flashing Openmoko]]
[[Category:System Developers]]

Openmoko-mediaplayer2

2008-11-20T00:55:37Z

Peterpall: /* Introduction */

{{ApplicationBox|
Name=[[Openmoko-mediaplayer2]]|
Description=Media player originally written for Om 2007.2.|
Screenshot=No-screenshot.png|
Homepage=http://abraxa.dyndns.org:81/random/openmoko-mediaplayer-theme.tar.bz2|
TestedOn=Om 2008.8|
PackageName=openmoko-mediaplayer2
}}

Source code: '''http://abraxa.dyndns.org:81/random/openmoko-mediaplayer-theme.tar.bz2'''

==Introduction==
Openmoko-mediaplayer2 is a program for play MP3.
Sice this media player currently is based on the pulseaudio sound server --- and this sound server breaks all phone applications using sound as soon as the phone goes into power saving mode it is unwise to install this application at this time.

If you have already install this application you have to uninstall pulseaudio, as well, to get your phone working as a phone again.

This Media Player is basically useless due to the default theme, to. To install with a better theme run:
<pre>
opkg install openmoko-mediaplayer2
wget http://abraxa.dyndns.org:81/random/openmoko-mediaplayer-theme.tar.bz2
tar xjf openmoko-mediaplayer-theme.tar.bz2 -C /usr/share/themes/Moko/gtk-2.0
rm openmoko-mediaplayer-theme.tar.bz2
</pre>
If you wonder where you have to put the media files so openmoko-mediaplayer2 will be able to find them --- it's /media/card or /home/root/Documents.
[[Category:Audio Applications]]

Zhone

2008-11-15T16:09:18Z

Peterpall: /* Zen Phone */

{{FSO}}

==Zen Phone==

Screenshots: [[FSO UI Tutorial]]

Zhone is often told to be a demo application for the free softphone framework (FSO). But it actually is a quite usable phone program that allows to send and receive calls, SMS messages and tells you your gps coordinates. The FSO automagically detects when the gps coordinates are no more shown and shuts down the GPS hardware as long as it is not needed.

Since it mainly only sends commands over dbus to the daemons that actually do the work it is rather stable and even able to do multitasking like allowing you to read an SMS whilst using the phone.

==Installing Zhone on Ubuntu ==

{{Warning|Adding those repositories (or the zhone installation?) may lead to problems on a Kubuntu 8.04 Hardy Heron.
Many packages update are done at the same time (200+ changes), and something break the upgrade.
Removing repositories and launching an "apt-get -f install" fix the problem.
}}

*Add this to your /etc/apt/sources.lst :
deb http://pkg-fso.alioth.debian.org/debian/ unstable main
deb-src http://pkg-fso.alioth.debian.org/debian/ unstable main
deb http://ftp.debian.org/debian/ experimental main
deb http://e17.dunnewind.net/ubuntu hardy e17
*Execute:
sudo apt-get update
sudo apt-get install zhone
* remove this from your /etc/apt/sources.lst
deb http://ftp.debian.org/debian/ experimental main
* Now you can finally execute:
zhone

== Developing Zhone ==
* Install Zhone see [[Zhone#Installing Zhone on Ubuntu]]
* apt-get source zhone

[[Category:FSO]]

Om 2008 Guide

2008-09-14T09:44:18Z

Peterpall: /* = =opkg install qtopia-phone-x11-mediaplayer: Was a typo. */

{{Om 2008.8}}

This documents quickly some key usability bits about [[Om 2008.8]] and initial setup.

=== Interface ===

'''New Keyboard'''

More details at : [[Om2008.8 Keyboard]]

'''Installer'''

The button to run the Installer is now on the bottom of the homescreen.
The plus signs are placeholders for the graphical buttons to be added later.

'''Top Menu'''

The top menu is now your task switcher and is activated by touching the down arrow.
Press "remove" to close currently focused application.

=== Things to know ===

''' Commands '''

These commands may be used in the terminal application (or in a remote SSH connection). Minimal shell usage skills may be required for Unix newcomers.

*'''"ifconfig"''' - Displays network information.

*'''"opkg update"''' - Updates list of available software.

*'''"opkg install"''' - Install software.

*'''"opkg upgrade"''' - Updates your software.

*'''"killall packagekitd"''' - Quits any package manager which could be running. (Run this command if you get the "Could not obtain administrative lock" error message while running opkg commands)

*'''"shutdown -r now"''' or '''"reboot"'''- Reboots your phone.

=== Configuring Om 2008.8 ===

==== Internet ====

===== Connecting your FR through USB to an internet-connected computer =====

Follow this [http://support.microsoft.com/kb/306126 guide (Windows Users)]to share your internet with your phone.

To share your internet connection on a Linux host follow this [[USB_Networking|USB networking guide]].

*If you are also behind a router you may have to change your LAN IP range in your router to avoid using 192.168.0.* as this is the same IP range as what your phone and ICS uses. (If you don't there will be an IP conflict) (see below for a workaround)

After you install and run [[http://wiki.openmoko.org/wiki/Om2008.8#Download Om 2008.8 ]] for the first time you have to restart to get the USB working. Once you have done that you have to ssh into your phone (192.168.0.202) to edit your /etc/network/interfaces so you can access the internet through USB to install software and updates.

Edit the USB section to look like this:

# Ethernet/RNDIS gadget (g_ether)
# ... or on host side, usbnet and random hwaddr
auto usb0
iface usb0 inet static
address 192.168.0.202
netmask 255.255.255.0
network 192.168.0.0
gateway 192.168.0.1
up echo nameserver 208.67.222.222 > /etc/resolv.conf
up echo nameserver 208.67.220.220 >> /etc/resolv.conf
#up echo nameserver 192.168.0.200 > /etc/resolv.conf

If you have a 192.168.0.* network, with .200 to .203 ip not used, you can do the following on FR:

auto usb0
iface usb0 inet static
address 192.168.0.202
netmask 255.255.255.252
network 192.168.0.200
gateway 192.168.0.201

and set your host ip to 201. Don't forget to modify routing and check [[USB_Networking|USB networking guide]] for a DNS MASQ using 192.168.0.201 as FR DNS. --[[User:Femto|Femto]] 00:34, 1 September 2008 (UTC)

===== Wireless =====

See [[Neo FreeRunner Wifi]] for details on how to use Wifi to connect your FR to the internet.

==== Advanced power management ====
If you decide not to install the Unofficial Zecke updates you should install "illume-config" to can gain access to more advanced power management features and to change the look of the GUI through the wrench that will now appear in the top bar. (Restart your phone)

==== Mediaplayer ====

There are 2 media players available for the 2008.8 device.

===== opkg install qtopia-phone-x11-mediaplayer =====
Seems to be a very nice application, although I haven't found out yet where to put the music I want to play.

Install it using the "install" application or by typing:
opkg install qtopia-phone-x11-mediaplayer

===== openmoko-mediaplayer2 =====
Sice this media player currently is based on the pulseaudio sound server --- and this sound server breaks all phone applications using sound as soon as the phone goes into power saving mode it is unwise to install this application at this time.

If you have already install this application you have to uninstall pulseaudio, as well, to get your phone working as a phone again.

This Media Player is basically useless due to the default theme, to. To install with a better theme run:

opkg install openmoko-mediaplayer2
wget http://abraxa.dyndns.org:81/random/openmoko-mediaplayer-theme.tar.bz2
tar xjf openmoko-mediaplayer-theme.tar.bz2 -C /usr/share/themes/Moko/gtk-2.0
rm openmoko-mediaplayer-theme.tar.bz2

=== Bugs/Fixes ===

{{todo|Link to bugreports and check if some of them might be fixed in newer updates}}

*The Media Player is basically unusable because of the skin. And is also very buggy.
*Battery meter always says its charging. Installing a terminal and running "apm" will display the proper battery status. (Appears to now work with the latest updates -- [[User:Tkep|Tkep]]

*Your phone will go into standby after 30 seconds EVEN when connected to your computer or wall charger. (Disable this under the settings menu)

*The wifi doesn't work too well right now. (well, works now with 2008.8 updates, I think -- [[User:OlivierBerger|OlivierBerger]] 14:25, 31 August 2008 (UTC))

*Accelerometers have alpha support via [[Gestures]]

*If you only want the rotate screen effect you can give a [[rotate|try to this one]]

*If you let the battery completely drain you will have problems booting it up. Plug it into the wall charger for a few hours and then plug it into your computer and press power.
*BUT, '''if you have another charged battery''', such as from the [http://us.direct.openmoko.com/products/spares-pack Spares pack], you can boot the Neo with the good battery, plug in wall-charger, and hot-swap the drained battery while booted. This allows you to immediately start "fast-charging" with the wall-charger. (Neo needs to be booted to recognize charger and switch to fast-charging)

*You'll have to install "illume-config" to have more control over power management, scrolling speeds, keyboard options, and to change how the interface looks.

*Some software that you install by command-line may appear in in the settings menu (wrench) that you unlock after installing "illume-config".

[[Category:Om 2008.8]]

Om 2008 Guide

2008-09-14T09:43:26Z

Peterpall: /* Mediaplayer: The old mediaplayer breaks the new phone ;-( */

{{Om 2008.8}}

This documents quickly some key usability bits about [[Om 2008.8]] and initial setup.

=== Interface ===

'''New Keyboard'''

More details at : [[Om2008.8 Keyboard]]

'''Installer'''

The button to run the Installer is now on the bottom of the homescreen.
The plus signs are placeholders for the graphical buttons to be added later.

'''Top Menu'''

The top menu is now your task switcher and is activated by touching the down arrow.
Press "remove" to close currently focused application.

=== Things to know ===

''' Commands '''

These commands may be used in the terminal application (or in a remote SSH connection). Minimal shell usage skills may be required for Unix newcomers.

*'''"ifconfig"''' - Displays network information.

*'''"opkg update"''' - Updates list of available software.

*'''"opkg install"''' - Install software.

*'''"opkg upgrade"''' - Updates your software.

*'''"killall packagekitd"''' - Quits any package manager which could be running. (Run this command if you get the "Could not obtain administrative lock" error message while running opkg commands)

*'''"shutdown -r now"''' or '''"reboot"'''- Reboots your phone.

=== Configuring Om 2008.8 ===

==== Internet ====

===== Connecting your FR through USB to an internet-connected computer =====

Follow this [http://support.microsoft.com/kb/306126 guide (Windows Users)]to share your internet with your phone.

To share your internet connection on a Linux host follow this [[USB_Networking|USB networking guide]].

*If you are also behind a router you may have to change your LAN IP range in your router to avoid using 192.168.0.* as this is the same IP range as what your phone and ICS uses. (If you don't there will be an IP conflict) (see below for a workaround)

After you install and run [[http://wiki.openmoko.org/wiki/Om2008.8#Download Om 2008.8 ]] for the first time you have to restart to get the USB working. Once you have done that you have to ssh into your phone (192.168.0.202) to edit your /etc/network/interfaces so you can access the internet through USB to install software and updates.

Edit the USB section to look like this:

# Ethernet/RNDIS gadget (g_ether)
# ... or on host side, usbnet and random hwaddr
auto usb0
iface usb0 inet static
address 192.168.0.202
netmask 255.255.255.0
network 192.168.0.0
gateway 192.168.0.1
up echo nameserver 208.67.222.222 > /etc/resolv.conf
up echo nameserver 208.67.220.220 >> /etc/resolv.conf
#up echo nameserver 192.168.0.200 > /etc/resolv.conf

If you have a 192.168.0.* network, with .200 to .203 ip not used, you can do the following on FR:

auto usb0
iface usb0 inet static
address 192.168.0.202
netmask 255.255.255.252
network 192.168.0.200
gateway 192.168.0.201

and set your host ip to 201. Don't forget to modify routing and check [[USB_Networking|USB networking guide]] for a DNS MASQ using 192.168.0.201 as FR DNS. --[[User:Femto|Femto]] 00:34, 1 September 2008 (UTC)

===== Wireless =====

See [[Neo FreeRunner Wifi]] for details on how to use Wifi to connect your FR to the internet.

==== Advanced power management ====
If you decide not to install the Unofficial Zecke updates you should install "illume-config" to can gain access to more advanced power management features and to change the look of the GUI through the wrench that will now appear in the top bar. (Restart your phone)

==== Mediaplayer ====

There are 2 media players available for the 2008.8 device.

===== =opkg install qtopia-phone-x11-mediaplayer ====
Seems to be a very nice application, although I haven't found out yet where to put the music I want to play.

Install it using the "install" application or by typing:
opkg install qtopia-phone-x11-mediaplayer

===== openmoko-mediaplayer2 =====
Sice this media player currently is based on the pulseaudio sound server --- and this sound server breaks all phone applications using sound as soon as the phone goes into power saving mode it is unwise to install this application at this time.

If you have already install this application you have to uninstall pulseaudio, as well, to get your phone working as a phone again.

This Media Player is basically useless due to the default theme, to. To install with a better theme run:

opkg install openmoko-mediaplayer2
wget http://abraxa.dyndns.org:81/random/openmoko-mediaplayer-theme.tar.bz2
tar xjf openmoko-mediaplayer-theme.tar.bz2 -C /usr/share/themes/Moko/gtk-2.0
rm openmoko-mediaplayer-theme.tar.bz2

=== Bugs/Fixes ===

{{todo|Link to bugreports and check if some of them might be fixed in newer updates}}

*The Media Player is basically unusable because of the skin. And is also very buggy.
*Battery meter always says its charging. Installing a terminal and running "apm" will display the proper battery status. (Appears to now work with the latest updates -- [[User:Tkep|Tkep]]

*Your phone will go into standby after 30 seconds EVEN when connected to your computer or wall charger. (Disable this under the settings menu)

*The wifi doesn't work too well right now. (well, works now with 2008.8 updates, I think -- [[User:OlivierBerger|OlivierBerger]] 14:25, 31 August 2008 (UTC))

*Accelerometers have alpha support via [[Gestures]]

*If you only want the rotate screen effect you can give a [[rotate|try to this one]]

*If you let the battery completely drain you will have problems booting it up. Plug it into the wall charger for a few hours and then plug it into your computer and press power.
*BUT, '''if you have another charged battery''', such as from the [http://us.direct.openmoko.com/products/spares-pack Spares pack], you can boot the Neo with the good battery, plug in wall-charger, and hot-swap the drained battery while booted. This allows you to immediately start "fast-charging" with the wall-charger. (Neo needs to be booted to recognize charger and switch to fast-charging)

*You'll have to install "illume-config" to have more control over power management, scrolling speeds, keyboard options, and to change how the interface looks.

*Some software that you install by command-line may appear in in the settings menu (wrench) that you unlock after installing "illume-config".

[[Category:Om 2008.8]]

Om 2008.8

2008-09-14T09:26:30Z

Peterpall: /* Known Issues */

{{Languages|Om 2008.8}}
{{Om 2008.8}}

{{Distributions|Om 2008.8}}

== Summary ==

'''Om 2008.8''' is the successor to [[Om 2007.2]] and had '''ASU''' as a codename. It was [http://lists.openmoko.org/pipermail/community/2008-August/025619.html released] on '''August 08, 2008''' (+ update "stable" releases starting from '''August 26, 2008'''). Om 2008.8 uses EFL for the launcher, custom UI applications and [[QtopiaOnX11|Qtopia on X11]] for telephony. The distribution is the first step from GTK+ on x11 to using multiple toolkits in combination.

== What's New ? ==

Compared to 2007.2 that has a longer development history, Om 2008.8 is definitely a .0 major release. So think KDE 4.0 vs. 3.5, not Linux 2.6.23 vs. 2.6.22. There are daily updates, some good some bad. If you want the stability level required to use the FreeRunner as your main phone, it is suggested for now to keep 2007.2 in the phone's flash memory and test 2008.8 on a removable SD card.

The main user-visible changes:

* The user interface has been fully revised with a new window manager [[illume]]. It is visually much richer, and can be customized further by using your own [[Edje]] files.
* '''[[Om2008.8_Installer|A graphical installer]]''' allows to add easily new applications, themes and functionality.
* A new [[Om2008.8_Locations|Locations]] application is provided, to save your favorite spots and share them with friends via sms.
* Power management has been improved: The Aux button now locks the screen, the Power button suspends and the red LED behind the Aux button lights up when charging.
* The [[Om2008.8_Keyboard| keyboard]] is now the Qtopia one (whether this is an improvement has been [[Keyboard_Debate|hotly debated]]).

For developers, the main changes are:
* Multiple toolkits: '''Om 2008.8''' supports [http://www.enlightenment.org/ EFL], [http://trolltech.com/products/qtopia Qtopia] and [http://www.gtk.org GTK+] applications.
* A [[CommunityRepository| Community Repository]] has been set up, it is integrated in the ([[Om2008.8_Installer|Installer]]).
* '''Source Codes''' are publicly available, allowing for customization all the way down to low level systems.

For more details, see the [[Om 2008.8 Guide]] and the [[Om2008.8 Feature Plan|Om 2008.8 Feature Plan]].

{| class="wikitable" cellspacing="2" cellpadding="2" style="padding: 0%; margin:0em 0em 1em 0em; border:1px solid #c0c0c0; background:#eeeeee; width:100%;floating="center"; "
! style="background:#fcfcfc;border-left:1px solid #9999cc;border-right:1px ; border-top:2px solid 75d806; border:1px solid #222222; width:33% " |
[[Image:Om2008 home.png|200px|center]]
! style="background:#fcfcfc;border-left:1px solid #9999cc;border-right:1px ; border-top:2px solid 75d806; border:1px solid #222222; width:33% " |
[[Image:Installer4.png|200px|center]]
! style="background:#fcfcfc;border-left:1px solid #9999cc;border-right:1px ; border-top:2px solid 75d806; border:1px solid #222222; width:33% " |
[[Image:Om2008 installer1.png|200px|center]]
|-

! style="background:#fcfcfc;border-left:1px solid #9999cc;border-right:1px ; border-top:2px solid 75d806; border:1px solid #222222; width:33% " |
[[Image:Main.png|200px|center]]
! style="background:#fcfcfc;border-left:1px solid #9999cc;border-right:1px ; border-top:2px solid 75d806; border:1px solid #222222; width:33% " |
[[Image:Edit1.png|200px|center]]
! style="background:#fcfcfc;border-left:1px solid #9999cc;border-right:1px ; border-top:2px solid 75d806; border:1px solid #222222; width:33% " |
[[Image:Om locations4.png|200px|center]]
|}




== Installation ==

To install the Om2008.8 stable distribution on the Neo FreeRunner, download the Root Filesystem and the Kernel image files from [[Download]] page and install according to [[Flashing the Neo FreeRunner]]. Note that flashing the smartphone will overwrite all your existing data and software.

== Known Issues ==

This is only a subset, and some of the bits reported below may have been fixed by stable updates (see [http://onlinedev.blogspot.com/search/label/om2008.8%20review Alasal's test reports] as well as the "Updates" section below). See [http://docs.openmoko.org/trac/search?q=2008.8 all tickets with 2008.8] in the bug tracker.

'''Suspend'''

Builds from the last days of August tend to suspend after 30s no matter what you set in settings. Switching the screensaver off with `xset s off' disables suspend completely. Note that this command must be typed into the terminal application on the phone itself; if you try to run it from an ssh session it fails with the error `xset: unable to open display ""'. This is because ssh sessions change the display settings expecting you might want X11 forwarding. In fact if you are using X11 forwarding with ssh -Y, the command won't fail over ssh, but it still won't do what you expect, as xset will assume you're talking about the forwarded X11 session, and thus doesn't affect the X11 session on the phone. Therefore if you use a ssh session you need to enter `xset -display :0 s off'.

Alex reportedly solved the problem going into Illume Settings, then Power, and setting to OFF the 2 parameters. He still gets the screensaver, but can reactivate easily just by touching.

If resume breaks audio (the ringing of the phone or for calling someone) a very probable reason is that the pulseaudio sound server is installed. This happens e.G. when openmoko-mediaplayer2 is installed. There seems to be [http://lists.openmoko.org/pipermail/openmoko-kernel/2008-August/004877.html activity to fix this application] already, though.

'''GSM'''

* [http://docs.openmoko.org/trac/ticket/1766 Cannot make calls or receive SMS messages]
* [http://docs.openmoko.org/trac/ticket/1662 GSM not working properly after x hours]

'''WiFi'''

* [http://docs.openmoko.org/trac/ticket/1929 WiFi can only connect once]

'''Audio quality'''

* [http://docs.openmoko.org/trac/ticket/1640 Improve overall audio]

'''System Software'''

* [http://docs.openmoko.org/trac/ticket/1736 Boot screen goes into sleep and never wake up if not touch during booting]
* [http://docs.openmoko.org/trac/ticket/1597 After long suspend, kernel thread events]
* [http://docs.openmoko.org/trac/ticket/1315 xglamo: performance decreases after a while]
* [http://docs.openmoko.org/trac/ticket/1682 Neo turns off before reaching x]

'''QPE high cpu usage'''
* qpe does scan whole filesystem ( including SD card ) for documents , mp3 files , etc . if you don't want it you can edit Storage.conf ( under /opt filesystem ) and disable Sd Card scanning ( overwrite 1 by 0 )

'''Networking'''
* No Updates/Installation are possible or pings to domains because DNS is not working. This problem occurs because the /etc/resolv.conf is empty by default.
Add these lines in /etc/network/interfaces:

up echo nameserver 208.67.222.222 > /etc/resolv.conf
up echo nameserver 208.67.220.220 >> /etc/resolv.conf
This is to be inserted below gateway address and above the bluetooth networking. After this it will be set on every reboot.

For resolving DNS without restarting, run the following commands:

echo nameserver 208.67.222.222 > /etc/resolv.conf
echo nameserver 208.67.220.220 >> /etc/resolv.conf
This should solve most of your moko side networking issues. If you need any other help please refer to [[USB Networking]]

{{note| [http://en.wikipedia.org/wiki/Resolvconf resolvconf] is installed so should probably be used

'''Problem''': parts of resolvconf are missing: without the scripts under /etc/network/if-{up,down}.d, and /etc/resolvconf/run/enable-updates and /lib/resolvconf/list-records it does nothing, and even then, /etc/resolvconf/run should probably be a symlink to /var/run, or /etc/resolv.conf needs to be pointed at /etc/resolvconf/run/resolv.conf -- once all that's done, it seems to work as long as you add something like this to /etc/network/interfaces at the end of the usb0 stanza:

dns-nameservers 192.168.0.200
dns-search example.com

and add <tt>usb*</tt> above <tt>eth*</tt> in <tt>/etc/resolvconf/interface-order</tt>

}}

{{Note| '''Solution:''' Steps to add missing resolvconf script: 
<code>touch /etc/resolvconf/run/enable-updates</code> 
<code>cd /etc ; rm resolv.conf ; ln -s /etc/resolvconf/run/resolv.conf .</code> 
<code>mkdir /lib/resolvconf/ ; cd /lib/resolvconf/</code> 
<code><nowiki>wget http://87.227.108.179/list-records</nowiki></code> 
<code>chmod +x list-records</code> 
Edit <code>/etc/network/interfaces</code> and remove the lines: 
<code> network 192.168.0.0</code> 
<code> gateway 192.168.0.200</code> 
If we need to use the usb network more then just locally from the computer in the other end of the USB-cable, login with ssh and add a default route like this: 
<code>route add default gateway 192.168.0.200</code>
}}

* Usb-networking will not work until rebooted after initial boot.

'''Usability'''

* The Pin-Dialog by default just shows letters. You have to slide your finger up/down over the keyboard to make the numbers/uppercase/special characters appear.
* The installer app doesn't release administrative rights which results in not being able to use opkg. Solution: run "killall packagekitd" (on the freerunner or when ssh'ed in).
* The installer app doesn't release administrative rights which results in not being able to use opkg. Alternate Solution: On the FreeRunner, use the drop-down menu to close all open applications.
* The keyboard may not be adapted for all uses. See [[Keyboard Debate]] for a full discussion and options.

== Updates for Om 2008.8 ==

Posterior to the Om2008.8 release made on 2008/08/08, development has been [http://lists.openmoko.org/pipermail/community/2008-August/026491.html split in two branches] aiming respectively at the next minor and major releases.

Support for 2008.8 occurs on the ''org.openmoko.asu.stable'' branch, with the short term goal to improve stability and useability, keeping the same features set. Changes to that branch are described in [http://git.openmoko.org/?p=openmoko.git;a=log;h=org.openmoko.asu.stable the Om 2008.8 stable changelog], and official updates are available (as of 2008/08/26) in two forms (see [http://lists.openmoko.org/pipermail/community/2008-August/027997.html see this message] for the announcement) :
* in the http://downloads.openmoko.org/repository/Om2008.8/ opkg feeds. Since these are already configured in 2008.8, using 'opkg update; opkg upgrade' is sufficient to get these.
* as flash-able images in http://downloads.openmoko.org/releases/Om2008.8-update/
As always, update often only if you like to be on the leading edge with the associated risks. Otherwise ask around on IRC before you jump or simply wait for an official announce that the branch is in a good state. Rumours are that this branch should flower every few weeks. There has even been signs that the next [http://en.wikipedia.org/wiki/Point_release point release] could be named 2008.9.

The long-term development branch is named ''org.openmoko.dev''. This branch has refocused on the base system functionalities (applications will not be installed by default), and started by catching up with upstream. Critical bugfixes from that branch should percolate to the ''.asu.stable'' branch after an unspecified delay. Using binaries updates from that branch (or any other non-2008.8 repository) on a 2008.8 stable base is likely to send you in [http://en.wikipedia.org/wiki/Dependency_hell Dependency Hell], you have been warned.

== Dedication ==

<pre>
From: Openmoko
To: openmoko-community mailing list

Om 2008.8 was designed to be empty, for the very purpose of showcasing your ideas.

Think of our products as galleries. We're building the environment.
Each one different from the next. You'll get all the free art supplies
you could imagine because we want you to add your own meaning.
You choose: consume, create, or both.

Either way you create your own meaning. It's about you.
</pre>

[[Category:Om 2008.8| ]]

U-Boot

2008-07-28T04:39:15Z

Peterpall: /* What if I borked my bootloader environment and don't get a prompt anymore? */

{{Languages|Bootloader}}

{{Bootloader}}
[[Image:GTA01-U-Boot.JPG|thumb|300px|u-boot menu on Neo1973]] [[Image:Neo1973 uboot splash closeup.jpg|thumb|300px|u-boot splash screen on Neo1973]]

The bootloader on the [[Neo1973]], '''U-Boot''', takes care of device functionality until [[Openmoko]] is booted. This includes [[USB DFU]] for [[flashing Openmoko]], a splash screen, a boot menu, a console for [[bootloader commands]], configuration via [[bootloader environment]], and loading a [[kernel]].

There are various [[bootloader versions]] available.

== Phase0 Quick Start ==
* Make sure that your phone has had the battery and USB cable removed for at least 30 seconds.
* Connect the Neo (ie not Debug Board) to a Linux host with the USB cable.
* Hold in the AUX button on power-up to access the boot menu.
* Set the console to USB.
* Connect to /dev/ttyACM0 with a terminal program on the Linux host (you might need to chown uucp.uucp /dev/ttyACM0 )
* Note that the cdc_acm /dev/ttyACM0 access disappears as soon as the Neo boots, and is replaced by the cdc_ether usb0 network access.
* You're now at the bootloader prompt.
* Set the bootdelay uboot environment variable to -1 if you want it to always halt at the bootloader on power-up.

== General ==

The GTA01 uses the [http://u-boot.sourceforge.net/ u-boot] bootloader.

More information on u-boot can be found at
* http://www.denx.de/wiki/DULG
* http://www.gumstix.org/tikiwiki/tiki-index.php?page=U-Boot
* http://linuxdevices.com/articles/AT5085702347.html

Additions to the vanilla u-boot already implemented include:
* Support for boot from NAND flash using [[S3C2410 Steppingstone]]
* Support for S3C2410 NAND flash
* Support for downloading programs via S3C2410 USB Device Controller
* Support to display bootup logo / status on S3C2410 Framebuffer

However, u-boot still doesn't support many of the features that GTA01 needs, such as
* Support for reading kernel/initrd from SD/Transflash

[[User:HaraldWelte|HaraldWelte]] is working on those issues, and in fact most of them have already been implemented.

== Bootloader source code ==

The current bootloader source can be found at http://git.openmoko.org/?p=u-boot.git;a=shortlog;h=stable .

To get u-boot by subversion:

svn co https://svn.openmoko.org/ openmoko/u-boot

To build u-boot:
* Clone the git tree and check out the stable branch
* Set the CROSS_COMPILE environment variable to specify the prefix to your toolchain binaries
* Run "make gta02v5_config" (or gta01bv4_config, or whatever hardware revision you have)
* Run "make u-boot.udfu". This will give you an image which you can install with dfu-util, or which you can upload into memory via JTAG (with a debug board)

== Bootloader binary ==

The latest bootloader binary builds can be found under http://buildhost.openmoko.org/snapshots in the subdirectory 200X.XX/images/. It should be written to the NAND flash address 0x00000000 (size 0x30000) (the first [[partition]]).

== Bootloader development ==

=== QT2410 ===
If you want to do bootloader development on the QT2410, it's easier to work with a bootloader image that can be downloaded via USB into RAM instead of flashing.

To do so, you need to edit the u-boot/include/configs/qt2410.h file, and change the "if 0" in Line 32 into a "if 1", then recompile with "make".

The resulting "u-boot.bin" is _NOT SUITABLE_ for NAND flash, but only for direct execution from within ram, e.g. by using the [[s3c2410_boot_usb]] program.

=== GTA01 ===

Doing bootloader development on the GTA01 is a bit more tricky. first, we don't have any NOR flash. Second, there is no other way to boot _but_ from NAND. Therefore, we also don't have a USB downloader like the QT2410.

The main problem is: The [[S3C2410 Steppingstone]] unconditionally copies the first 4k of flash into its internal SRAM. That SRAM segment stays unconditionally mapped at physical address zero. How do we get around this

=== GTA02 ===

The first block holds a little 4KByte RAM buffer that is auto-filled
from NAND by CPU hardware, called "steppingstone" when we boot from
NAND, or the NOR is mapped in there.

nCS0: 00000000 07FFFFFF 4K steppingstone or NOR (Aux held down) 
nCS1: 08000000 0FFFFFFF Glamo 
nCS2: 10000000 17FFFFFF nothing mapped 
nCS3: 18000000 1FFFFFFF NOR 
nCS4: 20000000 17FFFFFF nothing mapped 
nCS5: 28000000 2FFFFFFF nothing mapped 
nCS6: 30000000 37FFFFFF on-MCP SDRAM 128MB 
nCS7: 38000000 3FFFFFFF external SDRAM 128MB 

==== Using JTAG to boot from RAM ====

So how can we boot from RAM? We use JTAG / OpenOCD to

* Reset and halt the cpu at PC=0
<pre>
> reset halt
target halted in ARM state due to debug request, current mode: Supervisor
cpsr: 0x400000d3 pc: 0x00000000
MMU: disabled, D-Cache: disabled, I-Cache: disabled
</pre>

* Download a small piece of code for low-level SDRAM timing initialization (overwrite 4k SRAM of steppingstone)
<pre>
> load_binary /space/misc/gta01/u-boot.git/board/gta01/lowlevel_foo.bin 0
downloaded 332 byte in 0s 21899us
</pre>

* Assert a break point at address 0x33f80000 (which indicates that the low-level code has finished)
<pre>
> bp 0x33f80000 4 hw
breakpoint added at address 0x33f80000
</pre>

* Run the code up to the break point
<pre>
> resume
Target 0 resumed
> Target 0 halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x600000d3 pc: 0x33f80000
MMU: disabled, D-Cache: disabled, I-Cache: enabled
</pre>

* Download the u-boot RAM image to 0x33f80000
<pre>
> load_binary /space/misc/gta01/u-boot.git/u-boot.bin 0x33f80000
downloaded 135692 byte in 6s 567264us
</pre>

* Resume processing
<pre>
> resume
Target 0 resumed
</pre>

At this point, the display backlight gets bright and we see the following familiar prompt on the serial console:
<pre>
U-Boot 1.1.6 (Jan 13 2007 - 23:44:23)

DRAM: 128 MB
NAND: 64 MiB
*** Warning - bad CRC or NAND, using default environment

In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
GTA01Bv2 #
</pre>

== Creating bootable images ==

u-boot needs bootable images (such as kernels, but also initrd and others) in form of a so-called ''uImage''. In order to create a ''uImage'' from e.g. a ''vmlinux'' kernel image, you can proceed as follows:

<pre>
objcopy -O binary -R .note -R .comment -S vmlinux linux.bin
gzip -9 linux.bin
u-boot/tools/mkimage -A arm -O linux -T kernel -C gzip -a 30008000 -e 30008000 -n "Kernel Image QT2410" -d linux.bin.gz uImage
</pre>

== Boot menu ==
[[Image:Neo1973 uboot menu.jpg|thumb|400px|u-boot boot menu on Neo1973]]

As of the Phase-0 release, our u-boot version now features an on-screen boot menu. The items are defined by [[bootloader environment#menu|menu entries in the environment]].

=== Accessing the boot menu ===

You can access the boot menu by pressing and holding the [[Neo1973 AUX Button]] together with the power button while switching the phone on.

=== Using the boot menu ===

By pressing the [[Neo1973 AUX Button]] you can cycle through the menu items. Use the ''POWER'' button to select one item.

== Bootloader prompt ==

=== Accessing the bootloader prompt ===
The bootloader prompt is available either on the serial console (via [[Debug Board]]), or as virtual USB Serial device (USB CDC_ACM).
Whether the serial port or usb is used depends on the u-boot environment variables '''stdin''', '''stdout''' and '''stderr'''.

Whether or not you use usbtty, the first couple of messages will always be displayed on the serial console.

The bootloader is currently configured to wait for three seconds. If a key press on the '''stdin''' is received within those three seconds, auto-boot is aborted.

==== Using usbtty from Linux ====

Just by connecting the phone in u-boot mode to your Linux pc should make it detect a [[CDC ACM]] device, and you should get a new tty device called /dev/ttyACM0. If not, enable the CONFIG_USB_ACM (Device Drivers -> USB support -> USB Modem (CDC ACM) support). (Instructions for MacOS users are [[MacOS_X#USB_Serial|here]])

Use your favourite terminal emulator (minicom, cu, zc, screen ...) to access it like any other serial port. If you don't have a favorite, try just: (cu is in the taylor-uucp package, use "apt-get install cu" if it is not yet installed)
cu -l /dev/ttyACM0

You might need to
chown uucp.uucp /dev/ttyACM0

to get the necessary rights (even as root).

A nice alternative for cu is Werner Almesberger's [[NeoCon|neocon]].

First, you should try to check whether the USB device shows up in 'lsusb' while you're running in u-boot mode:

# lsusb -d 1457:5119
Bus 005 Device 079: ID 1457:5119

Second, let's see some more details about the available endpoints and configurations:

<pre>
# lsusb -v -d 1457:5119
Bus 005 Device 079: ID 1457:5119
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 16
idVendor 0x1457
idProduct 0x5119
bcdDevice 0.00
iManufacturer 1 OpenMoko, Inc
iProduct 2 Neo1973 Bootloader U-Boot 1.2.0-g6c7cac8c-dirty-moko3
iSerial 3 0000000
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 85
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 4 TTY via USB
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 6 Control Interface
CDC Header:
bcdCDC 0.6e
CDC Call Management:
bmCapabilities 0x00
bDataInterface 1
CDC ACM:
bmCapabilities 0x00
CDC Union:
bMasterInterface 0
bSlaveInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 255
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 5 Bulk Data Interface
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 255
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 255
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 254 Application Specific Interface
bInterfaceSubClass 1 Device Firmware Update
bInterfaceProtocol 1
iInterface 7 USB Device Firmware Upgrade
Device Status: 0x0001
Self Powered
</pre>

Next, you can access it using your favourite terminal program.

Then, if the environment is not set correctly, you will need to use the current console (e.g. serial console) to change the [[bootloader environment#console|console entries in the environment]]:
<pre>
GTA01Bv2 # setenv stderr usbtty
GTA01Bv2 # setenv stdout usbtty
GTA01Bv2 # setenv stdin usbtty
</pre>

==== Typical u-boot prompt ====

<pre>
U-Boot 1.2.0-moko1 (Feb 16 2007 - 00:36:13)

DRAM: 128 MB
NAND: 64 MiB
Found Environment offset in OOB..
Video: 640x480x8 31kHz 59Hz
USB: S3C2410 USB Deviced
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
GTA01Bv3 #
</pre>

=== Commands on the bootloader prompt ===

:''See [[bootloader commands]].''

=== What if I borked my bootloader environment and don't get a prompt anymore? ===
Found a solution here:
[[http://markmail.org/message/gqypwiohdet6x4am?q=almesberger+partition&page=1&refer=xbamkzwwsaobv7wa]]

It works the following way:
* Get the devirginator:
svn co http://svn.openmoko.org/trunk/src/host/devirginator
cd devirginator
* Read the u-boot environment from the device:
dfu-util -a u-boot_env -R -U env.in
* Create a file that contains everything you want to change in your u-boot environment or get it by issuing the following command:
wget http://svn.openmoko.org/trunk/src/host/devirginator/environment.in
* Now let devirginator generate a new u-boot_env partition for us, - that contains the partition table from our u-boot_env, - and all changes we wanted to make; Note that the -D GTA02 is needed for the neo Freeruner only.
./envedit.pl -i env.in -f environment.in -o env.out -D GTA02
* On my box the partition layout didn't seem to match the idea of envedit.pl, so it issued 2 warnings:
warning: environment is 262144 bytes, expected 16384
CRC error: expected 0xc33e35fc, got 0x93097bfb
* In this case jut add a additional argument to the command line - that has to be the 1st argument, though, and that contains the size information we got from the warning:
./envedit.pl -s 262144 -i env.in -D GTA02 -f environment.in -o env.out
* Now the perl script should no more output anything but write a new u-boot_env partition that we can upload to the device by:
dfu-util -a u-boot_env -R -D env.out

== Device Firmware Upgrade ==

Our version of u-boot also implements [[USB DFU]]. This can be useful to
load files and kernel for quick testing.

To find out whether your version of u-boot supports this, use the output of
$ lsusb -v -d 1457:5119
while the phone is in u-boot mode.

If it supports DFU, you should see the following snippet towards the end of the output:
<pre>
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 254 Application Specific Interface
bInterfaceSubClass 1 Device Firmware Update
bInterfaceProtocol 1
iInterface 0
</pre>

For information on how to do firmware upgrades, please see [[dfu-util]].

=== Booting files over DFU ===

To load a file at memory address 0x32000000:
<pre>
dfu-util -a 0 -D fileToLoad -R
</pre>

After that, send 'bootm 0x32000000' to u-boot or 'bootelf 0x32000000' if
its an elf file.

Simple python script that can boot an ELF image - avoiding a ACM bug that breaks on large packets.

<pre>
#!/usr/bin/python
import sys
import os
import time

cmd1 = "neo backlight off\n"
cmd2 = "bootelf 0x32000000\n"

def output(tty, str):
for x in str:
tty.write(x)
tty.flush()

if len(sys.argv) == 2:
print "Loading %s..." % sys.argv[1]

loadfile = "dfu-util -a 0 -D %s -R" % sys.argv[1]

os.system(loadfile)

time.sleep(3)

tty = open("/dev/ttyACM0", "a")

output(tty, cmd1)
output(tty, cmd2)

tty.close()
else:
print "Usage: %s elffile" % sys.argv[0]
print ""
sys.exit(2)
</pre>

== Troubleshooting ==

=== USB connectivity problems ===

I once got errors like this (in dmesg or /var/log/messages) on the host side while connecting the neo in u-boot:

usb 2-1: device descriptor read/64, error -110
usb usb2: Controller not stopped yet!

or

hub 4-0:1.0: port 1 disabled by hub (EMI?), re-enabling...
usb 4-1: USB disconnect, address 2

A possible solution is given below. Please note that if you have a usb keyboard or mouse then the command might cause trouble.

rmmod uhci_hcd ; modprobe uhci_hcd

Another option is to plug the FR into a different USB port on the host, preferably one on the Motherboard not the hub.

Disconnecting the Neo's USB while powering up may prevent this problem in the future.

See [[Flashing Openmoko]]

[[Category:System Developers]]
[[Category:Flashing Openmoko]]

U-Boot

2008-07-28T04:38:32Z

Peterpall: /* How to unbork a u-boot_env */

{{Languages|Bootloader}}

{{Bootloader}}
[[Image:GTA01-U-Boot.JPG|thumb|300px|u-boot menu on Neo1973]] [[Image:Neo1973 uboot splash closeup.jpg|thumb|300px|u-boot splash screen on Neo1973]]

The bootloader on the [[Neo1973]], '''U-Boot''', takes care of device functionality until [[Openmoko]] is booted. This includes [[USB DFU]] for [[flashing Openmoko]], a splash screen, a boot menu, a console for [[bootloader commands]], configuration via [[bootloader environment]], and loading a [[kernel]].

There are various [[bootloader versions]] available.

== Phase0 Quick Start ==
* Make sure that your phone has had the battery and USB cable removed for at least 30 seconds.
* Connect the Neo (ie not Debug Board) to a Linux host with the USB cable.
* Hold in the AUX button on power-up to access the boot menu.
* Set the console to USB.
* Connect to /dev/ttyACM0 with a terminal program on the Linux host (you might need to chown uucp.uucp /dev/ttyACM0 )
* Note that the cdc_acm /dev/ttyACM0 access disappears as soon as the Neo boots, and is replaced by the cdc_ether usb0 network access.
* You're now at the bootloader prompt.
* Set the bootdelay uboot environment variable to -1 if you want it to always halt at the bootloader on power-up.

== General ==

The GTA01 uses the [http://u-boot.sourceforge.net/ u-boot] bootloader.

More information on u-boot can be found at
* http://www.denx.de/wiki/DULG
* http://www.gumstix.org/tikiwiki/tiki-index.php?page=U-Boot
* http://linuxdevices.com/articles/AT5085702347.html

Additions to the vanilla u-boot already implemented include:
* Support for boot from NAND flash using [[S3C2410 Steppingstone]]
* Support for S3C2410 NAND flash
* Support for downloading programs via S3C2410 USB Device Controller
* Support to display bootup logo / status on S3C2410 Framebuffer

However, u-boot still doesn't support many of the features that GTA01 needs, such as
* Support for reading kernel/initrd from SD/Transflash

[[User:HaraldWelte|HaraldWelte]] is working on those issues, and in fact most of them have already been implemented.

== Bootloader source code ==

The current bootloader source can be found at http://git.openmoko.org/?p=u-boot.git;a=shortlog;h=stable .

To get u-boot by subversion:

svn co https://svn.openmoko.org/ openmoko/u-boot

To build u-boot:
* Clone the git tree and check out the stable branch
* Set the CROSS_COMPILE environment variable to specify the prefix to your toolchain binaries
* Run "make gta02v5_config" (or gta01bv4_config, or whatever hardware revision you have)
* Run "make u-boot.udfu". This will give you an image which you can install with dfu-util, or which you can upload into memory via JTAG (with a debug board)

== Bootloader binary ==

The latest bootloader binary builds can be found under http://buildhost.openmoko.org/snapshots in the subdirectory 200X.XX/images/. It should be written to the NAND flash address 0x00000000 (size 0x30000) (the first [[partition]]).

== Bootloader development ==

=== QT2410 ===
If you want to do bootloader development on the QT2410, it's easier to work with a bootloader image that can be downloaded via USB into RAM instead of flashing.

To do so, you need to edit the u-boot/include/configs/qt2410.h file, and change the "if 0" in Line 32 into a "if 1", then recompile with "make".

The resulting "u-boot.bin" is _NOT SUITABLE_ for NAND flash, but only for direct execution from within ram, e.g. by using the [[s3c2410_boot_usb]] program.

=== GTA01 ===

Doing bootloader development on the GTA01 is a bit more tricky. first, we don't have any NOR flash. Second, there is no other way to boot _but_ from NAND. Therefore, we also don't have a USB downloader like the QT2410.

The main problem is: The [[S3C2410 Steppingstone]] unconditionally copies the first 4k of flash into its internal SRAM. That SRAM segment stays unconditionally mapped at physical address zero. How do we get around this

=== GTA02 ===

The first block holds a little 4KByte RAM buffer that is auto-filled
from NAND by CPU hardware, called "steppingstone" when we boot from
NAND, or the NOR is mapped in there.

nCS0: 00000000 07FFFFFF 4K steppingstone or NOR (Aux held down) 
nCS1: 08000000 0FFFFFFF Glamo 
nCS2: 10000000 17FFFFFF nothing mapped 
nCS3: 18000000 1FFFFFFF NOR 
nCS4: 20000000 17FFFFFF nothing mapped 
nCS5: 28000000 2FFFFFFF nothing mapped 
nCS6: 30000000 37FFFFFF on-MCP SDRAM 128MB 
nCS7: 38000000 3FFFFFFF external SDRAM 128MB 

==== Using JTAG to boot from RAM ====

So how can we boot from RAM? We use JTAG / OpenOCD to

* Reset and halt the cpu at PC=0
<pre>
> reset halt
target halted in ARM state due to debug request, current mode: Supervisor
cpsr: 0x400000d3 pc: 0x00000000
MMU: disabled, D-Cache: disabled, I-Cache: disabled
</pre>

* Download a small piece of code for low-level SDRAM timing initialization (overwrite 4k SRAM of steppingstone)
<pre>
> load_binary /space/misc/gta01/u-boot.git/board/gta01/lowlevel_foo.bin 0
downloaded 332 byte in 0s 21899us
</pre>

* Assert a break point at address 0x33f80000 (which indicates that the low-level code has finished)
<pre>
> bp 0x33f80000 4 hw
breakpoint added at address 0x33f80000
</pre>

* Run the code up to the break point
<pre>
> resume
Target 0 resumed
> Target 0 halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x600000d3 pc: 0x33f80000
MMU: disabled, D-Cache: disabled, I-Cache: enabled
</pre>

* Download the u-boot RAM image to 0x33f80000
<pre>
> load_binary /space/misc/gta01/u-boot.git/u-boot.bin 0x33f80000
downloaded 135692 byte in 6s 567264us
</pre>

* Resume processing
<pre>
> resume
Target 0 resumed
</pre>

At this point, the display backlight gets bright and we see the following familiar prompt on the serial console:
<pre>
U-Boot 1.1.6 (Jan 13 2007 - 23:44:23)

DRAM: 128 MB
NAND: 64 MiB
*** Warning - bad CRC or NAND, using default environment

In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
GTA01Bv2 #
</pre>

== Creating bootable images ==

u-boot needs bootable images (such as kernels, but also initrd and others) in form of a so-called ''uImage''. In order to create a ''uImage'' from e.g. a ''vmlinux'' kernel image, you can proceed as follows:

<pre>
objcopy -O binary -R .note -R .comment -S vmlinux linux.bin
gzip -9 linux.bin
u-boot/tools/mkimage -A arm -O linux -T kernel -C gzip -a 30008000 -e 30008000 -n "Kernel Image QT2410" -d linux.bin.gz uImage
</pre>

== Boot menu ==
[[Image:Neo1973 uboot menu.jpg|thumb|400px|u-boot boot menu on Neo1973]]

As of the Phase-0 release, our u-boot version now features an on-screen boot menu. The items are defined by [[bootloader environment#menu|menu entries in the environment]].

=== Accessing the boot menu ===

You can access the boot menu by pressing and holding the [[Neo1973 AUX Button]] together with the power button while switching the phone on.

=== Using the boot menu ===

By pressing the [[Neo1973 AUX Button]] you can cycle through the menu items. Use the ''POWER'' button to select one item.

== Bootloader prompt ==

=== Accessing the bootloader prompt ===
The bootloader prompt is available either on the serial console (via [[Debug Board]]), or as virtual USB Serial device (USB CDC_ACM).
Whether the serial port or usb is used depends on the u-boot environment variables '''stdin''', '''stdout''' and '''stderr'''.

Whether or not you use usbtty, the first couple of messages will always be displayed on the serial console.

The bootloader is currently configured to wait for three seconds. If a key press on the '''stdin''' is received within those three seconds, auto-boot is aborted.

==== Using usbtty from Linux ====

Just by connecting the phone in u-boot mode to your Linux pc should make it detect a [[CDC ACM]] device, and you should get a new tty device called /dev/ttyACM0. If not, enable the CONFIG_USB_ACM (Device Drivers -> USB support -> USB Modem (CDC ACM) support). (Instructions for MacOS users are [[MacOS_X#USB_Serial|here]])

Use your favourite terminal emulator (minicom, cu, zc, screen ...) to access it like any other serial port. If you don't have a favorite, try just: (cu is in the taylor-uucp package, use "apt-get install cu" if it is not yet installed)
cu -l /dev/ttyACM0

You might need to
chown uucp.uucp /dev/ttyACM0

to get the necessary rights (even as root).

A nice alternative for cu is Werner Almesberger's [[NeoCon|neocon]].

First, you should try to check whether the USB device shows up in 'lsusb' while you're running in u-boot mode:

# lsusb -d 1457:5119
Bus 005 Device 079: ID 1457:5119

Second, let's see some more details about the available endpoints and configurations:

<pre>
# lsusb -v -d 1457:5119
Bus 005 Device 079: ID 1457:5119
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 16
idVendor 0x1457
idProduct 0x5119
bcdDevice 0.00
iManufacturer 1 OpenMoko, Inc
iProduct 2 Neo1973 Bootloader U-Boot 1.2.0-g6c7cac8c-dirty-moko3
iSerial 3 0000000
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 85
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 4 TTY via USB
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 6 Control Interface
CDC Header:
bcdCDC 0.6e
CDC Call Management:
bmCapabilities 0x00
bDataInterface 1
CDC ACM:
bmCapabilities 0x00
CDC Union:
bMasterInterface 0
bSlaveInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 255
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 5 Bulk Data Interface
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 255
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 255
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 254 Application Specific Interface
bInterfaceSubClass 1 Device Firmware Update
bInterfaceProtocol 1
iInterface 7 USB Device Firmware Upgrade
Device Status: 0x0001
Self Powered
</pre>

Next, you can access it using your favourite terminal program.

Then, if the environment is not set correctly, you will need to use the current console (e.g. serial console) to change the [[bootloader environment#console|console entries in the environment]]:
<pre>
GTA01Bv2 # setenv stderr usbtty
GTA01Bv2 # setenv stdout usbtty
GTA01Bv2 # setenv stdin usbtty
</pre>

==== Typical u-boot prompt ====

<pre>
U-Boot 1.2.0-moko1 (Feb 16 2007 - 00:36:13)

DRAM: 128 MB
NAND: 64 MiB
Found Environment offset in OOB..
Video: 640x480x8 31kHz 59Hz
USB: S3C2410 USB Deviced
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
GTA01Bv3 #
</pre>

=== Commands on the bootloader prompt ===

:''See [[bootloader commands]].''

=== What if I borked my bootloader environment and don't get a prompt anymore? ===
Found a solution here:
[[http://markmail.org/message/gqypwiohdet6x4am?q=almesberger+partition&page=1&refer=xbamkzwwsaobv7wa]]

It works the following way:
* Get the devirginator:
svn co http://svn.openmoko.org/trunk/src/host/devirginator
cd devirginator
* Read the u-boot environment from the device:
dfu-util -a u-boot_env -R -U env.in
* Create a file that contains everything you want to change in your u-boot environment or get it with the following command:
wget http://svn.openmoko.org/trunk/src/host/devirginator/environment.in
* Now let devirginator generate a new u-boot_env partition for us, - that contains the partition table from our u-boot_env, - and all changes we wanted to make; Note that the -D GTA02 is needed for the neo Freeruner only.
./envedit.pl -i env.in -f environment.in -o env.out -D GTA02
* On my box the partition layout didn't seem to match the idea of envedit.pl, so it issued 2 warnings:
warning: environment is 262144 bytes, expected 16384
CRC error: expected 0xc33e35fc, got 0x93097bfb
* In this case jut add a additional argument to the command line - that has to be the 1st argument, though, and that contains the size information we got from the warning:
./envedit.pl -s 262144 -i env.in -D GTA02 -f environment.in -o env.out
* Now the perl script should no more output anything but write a new u-boot_env partition that we can upload to the device by:
dfu-util -a u-boot_env -R -D env.out

== Device Firmware Upgrade ==

Our version of u-boot also implements [[USB DFU]]. This can be useful to
load files and kernel for quick testing.

To find out whether your version of u-boot supports this, use the output of
$ lsusb -v -d 1457:5119
while the phone is in u-boot mode.

If it supports DFU, you should see the following snippet towards the end of the output:
<pre>
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 254 Application Specific Interface
bInterfaceSubClass 1 Device Firmware Update
bInterfaceProtocol 1
iInterface 0
</pre>

For information on how to do firmware upgrades, please see [[dfu-util]].

=== Booting files over DFU ===

To load a file at memory address 0x32000000:
<pre>
dfu-util -a 0 -D fileToLoad -R
</pre>

After that, send 'bootm 0x32000000' to u-boot or 'bootelf 0x32000000' if
its an elf file.

Simple python script that can boot an ELF image - avoiding a ACM bug that breaks on large packets.

<pre>
#!/usr/bin/python
import sys
import os
import time

cmd1 = "neo backlight off\n"
cmd2 = "bootelf 0x32000000\n"

def output(tty, str):
for x in str:
tty.write(x)
tty.flush()

if len(sys.argv) == 2:
print "Loading %s..." % sys.argv[1]

loadfile = "dfu-util -a 0 -D %s -R" % sys.argv[1]

os.system(loadfile)

time.sleep(3)

tty = open("/dev/ttyACM0", "a")

output(tty, cmd1)
output(tty, cmd2)

tty.close()
else:
print "Usage: %s elffile" % sys.argv[0]
print ""
sys.exit(2)
</pre>

== Troubleshooting ==

=== USB connectivity problems ===

I once got errors like this (in dmesg or /var/log/messages) on the host side while connecting the neo in u-boot:

usb 2-1: device descriptor read/64, error -110
usb usb2: Controller not stopped yet!

or

hub 4-0:1.0: port 1 disabled by hub (EMI?), re-enabling...
usb 4-1: USB disconnect, address 2

A possible solution is given below. Please note that if you have a usb keyboard or mouse then the command might cause trouble.

rmmod uhci_hcd ; modprobe uhci_hcd

Another option is to plug the FR into a different USB port on the host, preferably one on the Motherboard not the hub.

Disconnecting the Neo's USB while powering up may prevent this problem in the future.

See [[Flashing Openmoko]]

[[Category:System Developers]]
[[Category:Flashing Openmoko]]

Backup

2008-07-27T11:55:10Z

Peterpall: /* We should backupp te other 3 partitions as well. */

You will need the [[Dfu-util]] to make a backup of your existing image.

As when [[Flashing_the_Neo_FreeRunner|flashing]], you will need to be in [[Booting_the_Neo_FreeRunner#Log_into_U-Boot_in_the_NOR_Flash|U-Boot in the NOR Flash]]. Log into the NOR uBoot menu and select ''Set console to USB''. Now you will be able to flash, make backups of your Freerunner or query the Freerunner with [[Dfu-util|dfu-util]].

{{note|On a Windows host, omit the "./" or "sudo ./" that precedes the commands listed on this page}}

THIS WILL TAKE AWHILE. The rootfs will take significantly longer than the kernel.

<pre>
./dfu-util -a kernel -R -U good-kernel.bin
./dfu-util -a rootfs -R -U good-rootfs.jffs2
./dfu-util -a u-boot_env -R -U good-u-boot_env.bin
./dfu-util -a splash -R -U good-splash.bin
./dfu-util -a u-boot -R -U good-u-boot.bin

</pre>

Here is what my successful output looked like...

on the host PC:
<pre>
$ sudo ./dfu-util -a kernel -R -U good-kernel.img
dfu-util - (C) 2007 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

Opening USB Device 0x0000:0x0000...
Claiming USB DFU Runtime Interface...
Determining device status: state = appIDLE, status = 0
Device really in Runtime Mode, send DFU detach request...
Resetting USB...
Opening USB Device...
Found Runtime: [0x1d50:0x5119] devnum=12, cfg=0, intf=0, alt=3, name="kernel"
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x1000
Resetting USB to switch back to runtime mode
$ sudo ./dfu-util -a rootfs -R -U good-rootfs.jffs2
dfu-util - (C) 2007 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

Opening USB Device 0x0000:0x0000...
Found Runtime: [0x1d50:0x5119] devnum=16, cfg=0, intf=0, alt=6, name="rootfs"
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuERROR, status = 14
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x1000
Resetting USB to switch back to runtime mode
</pre>

Despite the fact that there was a device status with state=dfuERROR, everything seems to have worked.

on the FreeRunner:
<pre>
DFU: Switching to DFU Mode
DEVICE_CONFIGURED: 1
Starting DFU Upload of partition 'kernel'
DEVICE_CONFIGURED: 1
Starting DFU Upload of partition 'rootfs'
</pre>

I could backup the kernel of my GTA02 but trying to use this method to backup the rootfs failed several times....
dfu-util - (C) 2007 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

Opening USB Device 0x0000:0x0000...
Claiming USB DFU Runtime Interface...
Determining device status: state = appIDLE, status = 0
Device really in Runtime Mode, send DFU detach request...
Resetting USB...
Opening USB Device...
Found Runtime: [0x1d50:0x5119] devnum=20, cfg=0, intf=0, alt=6, name="rootfs"
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x1000
dfu_upload error -110

In demsg I get this error
usb 5-2: usbfs: USBDEVFS_CONTROL failed cmd dfu-util rqt 161 rq 2 len 4096 ret -110

I have not been able to backup rootfs using this method.
[[category:Software]]
[[category:Technical]]

Flashing the Neo 1973

2008-07-27T11:47:12Z

Peterpall: /* IMPORTANT NOTEs FOR EARLY ADOPTERS: */

{{Languages|Flashing Openmoko}}
This describes how to update your Neo1973 to the latest software. We'll update the kernel, the root filesystem and optionally u-boot [[partitions]] in the internal flash memory.

{{Note|
* MacOS X users: please refer to [[MacOS_X]].
* Users without Linux please refer to [[No_Linux]] for the moment.

You may prefer to read directly :
* [[Flashing the Neo FreeRunner]]
}}

{{warning|If you're updating u-boot and don't have a [[Debug Board]], you might render your unit unusable if the flashing procedure is interrupted}}

{{warning|If you have U-boot from before 2008 and upload a rootfs image that is smaller than the previous one, or if you have written to the rootfs, just flashing may not work - you may need to run a "[[Nand_erase|nand erase rootfs]]" before you then upload your rootfs (details [[Bootloader#Accessing_the_bootloader_prompt|here]]). Running "nand erase rootfs" before flashing a new rootfs, is quick and saves you the time of a second rootfs upload. Attention: If you [[Nand_erase|erase NAND]] without mentioning the partition to be erased, u-boot will be wiped out and the Neo will be bricked}}

== Files to download ==

The rootfs & kernel images you download need to match. The loadable modules for the kernel are in /lib/modules/ on the rootfs [[partition]] - if you get the wrong combination, you will get some error messages during bootup that it cannot access /lib/modules/x.y.z-moko123 - in this case swap either the kernel or the rootfs to match the other's version. Unfortunately the rootfs filename does not seem to tell what kernel version it is compatible with, you just have to try a few. '''NOTE:''' At least some combinations seem to boot up fine even if the module versions mismatch so be sure to check the console while it's booting after flashing.

The "moko123" in the error message example above indicates the openmoko patchset version.

Necessary files are at:
*http://buildhost.openmoko.org/OM2007.2/tmp/deploy/glibc/images/neo1973/?C=M;O=D

*http://buildhost.openmoko.org/daily/neo1973/deploy/glibc/images/neo1973/?C=M;O=D (Daily unstable builds)

*http://buildhost.automated.it/OM2007.2/?M=D (Location of more current unofficial builds.)

A list of download locations can be found at [[Repositories]]. See [[Phase 1 Software Testing]] for a list of tested images.

Changelogs can be found at:
*http://cia.vc/stats/project/openembedded/.rss

*http://cia.vc/stats/project/openmoko/.rss

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

== Preparing the device for DFU mode ==

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

* Unplug all usb devices from the host.
* Hold the phone's [[Neo1973 AUX Button | AUX button]] and then press the phone's [[Neo1973 Power Button | POWER button]].
** You'll need to hold the POWER button for about 4 seconds before the device will turn on. Otherwise the screen will only flash white for a second and the phone won't power up.
* The u-boot menu should appear:
<pre>
U-Boot ..

=== BOOT MENU ===

BOOT
Set console to USB
Set console to serial
Power off
Boot from SD
Factory reset

Press [AUX] to select, [POWER] to execute.
</pre>

* Plug Neo1973 into host with supplied USB cable. (Plug the phone directly into the host not via a hub.)

'''Note:''' If the bootloader remains inactive for about 30 seconds, that is no keypresses or no use of the serial console, the device will automatically power down.
You can prevent this by just pressing the AUX button every 30 seconds or so or by telling the bootloader to not exhibit this behaviour.
To do so, please connect to the bootloader:

<pre>
cu -l /dev/ttyACM0
GTA01Bv4 # setenv boot_menu_timeout 65000
GTA01Bv4 # saveenv
</pre>
For those that are unfamiliar with cu, to exit you need to press "~."

(You may have to install the uucp package to have access to cu, and maybe also "<code>chown uucp:uucp /dev/ttyACM0</code>" as root before it will work)

No further navigation is needed in u-boot - the device will automatically start flashing the images when told to do so by dfu-util below. After flashing all the files, you can choose the "Boot" option to boot the newly flashed stuff.

== Actually flashing things into the device ==

Double check that u-boot matches your hardware version. First determine what hardware revision you have [[finding hardware revision]], so that you can download and install the correct bootloader.

You'll probably only want to update u-boot if you have the [[debug board]] for fixing failed u-boot updates. You can also check the current [[partitions]].

Note: It may be necessary to run the application as root (at least in Ubuntu and Debian).

Note: In case there are more than one available usb devices use -d 0x1457:0x5119 option.

To update u-boot:

{{Warning|Do not update u-boot unless you have [[debug board]] or are really sure about what you are doing. Flashing a wrong u-boot image will brick your device!}}

I you own a FreeRunner don't be too scared, though: Unlike nearly any other deviceon the market the Freerunner contains a second bootloader on a write protected chip - that is still there, even if flashing the original bootloader goes horribly wrong. You can always make the phone use this bootloader instead by pressing the power button whilst pressing the Aux button - and get a second and any sucessive try to flash the u-boot loader the right way. In theory it should therefore be impossible to brick your phone completely enough by flashing the bootloader that a debug board is needed to unbrick it.
* Download the newest uBoot binary from http://downloads.openmoko.org/releases/Freerunner/
* start the cellular phone by pressing power whilst pressing the aux button.
* Run the following command, but Note especially that the image used in the line below is for GTA02_v5.

dfu-util -a u-boot -R -D uboot-gta02v5-latest.bin

The u-boot of a GTA01B_v03 (And only of a GTA01B_V03, not for example a GTA01B_v04) can be flashed with the following image:
./dfu-util -a u-boot -R -D u-boot-gta01bv3-latest.bin

* The device is now flashed:
dfu-util - (C) 2007 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

Opening USB Device 0x0000:0x0000...
Claiming USB DFU Runtime Interface...
Determining device status: state = appIDLE, status = 0
Device really in Runtime Mode, send DFU detach request...
Resetting USB...
Opening USB Device...
Found Runtime: [0x1d50:0x5119] devnum=9, cfg=0, intf=0, alt=1, name="u-boot"
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x1000
bytes_per_hash=4316
Starting download: [##################################################] finished!
state(2) = dfuIDLE, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode
* The last message (status(0)) tells us everything just worked fine - at the next boot the device will be started by the newest uboot loader.

To update the kernel:
./dfu-util -a kernel -R -D ./uImage-2.6.21.1-moko10-r0_0_1883_0-fic-gta01.bin
Flashing the kernel will probably take less than 1 minute. If you're having trouble, you may want to compare the output that you see to a "known good" [[Flashing openmoko/Known good kernel flash U-Boot output | U-Boot]]/[[Flashing openmoko/Known good kernel flash dmesg output | dmesg]]/[[Flashing openmoko/Known good kernel flash dfu-util output | dfu-util]] output. The phone display should show "Starting DFU DOWNLOAD to partition 'kernel'.

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

Flashing the root filesystem will probably take around 13 minutes. Note that it can take over an hour if you are using a XEN VM for doing the flash.

Here is some "known good" output from [[Flashing openmoko/Known good rootfs flash U-Boot output | U-Boot]], [[Flashing openmoko/Known good rootfs flash dmesg output | dmesg]], and [[Flashing openmoko/Known good rootfs flash dfu-util output | dfu-util]]. The phone display should show "Starting DFU DOWNLOAD to partition 'rootfs'.

Notice that it's not normally necessary to update the modules anymore. It's just for people with special needs.

...now, you'll end up with system that boots, but does not see audio/SD card. You'll need to download corresponding modules.tgz and copy them over to openmoko. - UPDATE: GTA01 phones appear to not need this step, as long as you have installed a kernel that matches the version of the modules contained in the root image ('uname -r' will show the kernel version, and 'ls /lib/modules/' will show the modules that are present).

=== Important Notes for early adopters: ===
Some old U-Boot versions are very buggy:

For U-Boot versions until somewhere in 2007 if you uploaded your rootfs image that is smaller that previous one it wouldn't work - you needed to attach to the u-boot bootloader first, erase NAND partition that would contain the rootfs later and then upload your rootfs:

<pre>
cu -l /dev/ttyACM0
GTA01Bv3 # nand erase rootfs
</pre>

Note, that it might be wise to type, not drag-and-drop the "nand erase rootfs" line since when characters arrived too fast u-boot versions until mid-2008 tended to "eat" characters.

Also you may have to press the AUX button every 25 seconds or so to prevent the phone from going to sleep while being flashed. Very early versions of U-Boot also did not erase the rootfs before flashing it at all... to do that, do minicom /dev/ttyACM0, then nand erase rootfs, like written above.

Good luck!

== Where to go from here ==

So, now you have one of the more recent kernel and rootfs images, or one of the (semi)official ones, whats next?

You probably want to set up [[USB_Networking]] and then configure your Neo1973 some more.

Do not forget to update your Neo1973 using

ipkg update && ipkg upgrade

or (newer versions)

opkg update && opkg upgrade

and have a look at additional ipkg [[repositories]].

Question to anybody who knows: The kernel the openmoko boots from is in a different partition than the root file system in most setups right now. In former times there always was a warning that ipkg updates /boot/uImage - the location where the kernel that matches the current rootfs can be found - but didn't update the partition the kernel is loaded from in the default setup. The following line manually updates the kernel on this partition:
cat /boot/uImage >/dev/mtdblock3

Is typing this line still necessary?
[[User:Peterpall]]

== Troubleshooting notes ==

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

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

This message can also occur if you connect the usb cable before you are in the bootloader menu. You must carefully follow the sequence described at the beginning of this article and not connect the USB cable too early.

dfu-util does not seem to be able to download files if run from linux running under
VMWare on a Windows OS host.

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

[[Category:Flashing Openmoko| ]]

Flashing the Neo 1973

2008-07-27T11:43:35Z

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

{{Languages|Flashing Openmoko}}
This describes how to update your Neo1973 to the latest software. We'll update the kernel, the root filesystem and optionally u-boot [[partitions]] in the internal flash memory.

{{Note|
* MacOS X users: please refer to [[MacOS_X]].
* Users without Linux please refer to [[No_Linux]] for the moment.

You may prefer to read directly :
* [[Flashing the Neo FreeRunner]]
}}

{{warning|If you're updating u-boot and don't have a [[Debug Board]], you might render your unit unusable if the flashing procedure is interrupted}}

{{warning|If you have U-boot from before 2008 and upload a rootfs image that is smaller than the previous one, or if you have written to the rootfs, just flashing may not work - you may need to run a "[[Nand_erase|nand erase rootfs]]" before you then upload your rootfs (details [[Bootloader#Accessing_the_bootloader_prompt|here]]). Running "nand erase rootfs" before flashing a new rootfs, is quick and saves you the time of a second rootfs upload. Attention: If you [[Nand_erase|erase NAND]] without mentioning the partition to be erased, u-boot will be wiped out and the Neo will be bricked}}

== Files to download ==

The rootfs & kernel images you download need to match. The loadable modules for the kernel are in /lib/modules/ on the rootfs [[partition]] - if you get the wrong combination, you will get some error messages during bootup that it cannot access /lib/modules/x.y.z-moko123 - in this case swap either the kernel or the rootfs to match the other's version. Unfortunately the rootfs filename does not seem to tell what kernel version it is compatible with, you just have to try a few. '''NOTE:''' At least some combinations seem to boot up fine even if the module versions mismatch so be sure to check the console while it's booting after flashing.

The "moko123" in the error message example above indicates the openmoko patchset version.

Necessary files are at:
*http://buildhost.openmoko.org/OM2007.2/tmp/deploy/glibc/images/neo1973/?C=M;O=D

*http://buildhost.openmoko.org/daily/neo1973/deploy/glibc/images/neo1973/?C=M;O=D (Daily unstable builds)

*http://buildhost.automated.it/OM2007.2/?M=D (Location of more current unofficial builds.)

A list of download locations can be found at [[Repositories]]. See [[Phase 1 Software Testing]] for a list of tested images.

Changelogs can be found at:
*http://cia.vc/stats/project/openembedded/.rss

*http://cia.vc/stats/project/openmoko/.rss

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

== Preparing the device for DFU mode ==

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

* Unplug all usb devices from the host.
* Hold the phone's [[Neo1973 AUX Button | AUX button]] and then press the phone's [[Neo1973 Power Button | POWER button]].
** You'll need to hold the POWER button for about 4 seconds before the device will turn on. Otherwise the screen will only flash white for a second and the phone won't power up.
* The u-boot menu should appear:
<pre>
U-Boot ..

=== BOOT MENU ===

BOOT
Set console to USB
Set console to serial
Power off
Boot from SD
Factory reset

Press [AUX] to select, [POWER] to execute.
</pre>

* Plug Neo1973 into host with supplied USB cable. (Plug the phone directly into the host not via a hub.)

'''Note:''' If the bootloader remains inactive for about 30 seconds, that is no keypresses or no use of the serial console, the device will automatically power down.
You can prevent this by just pressing the AUX button every 30 seconds or so or by telling the bootloader to not exhibit this behaviour.
To do so, please connect to the bootloader:

<pre>
cu -l /dev/ttyACM0
GTA01Bv4 # setenv boot_menu_timeout 65000
GTA01Bv4 # saveenv
</pre>
For those that are unfamiliar with cu, to exit you need to press "~."

(You may have to install the uucp package to have access to cu, and maybe also "<code>chown uucp:uucp /dev/ttyACM0</code>" as root before it will work)

No further navigation is needed in u-boot - the device will automatically start flashing the images when told to do so by dfu-util below. After flashing all the files, you can choose the "Boot" option to boot the newly flashed stuff.

== Actually flashing things into the device ==

Double check that u-boot matches your hardware version. First determine what hardware revision you have [[finding hardware revision]], so that you can download and install the correct bootloader.

You'll probably only want to update u-boot if you have the [[debug board]] for fixing failed u-boot updates. You can also check the current [[partitions]].

Note: It may be necessary to run the application as root (at least in Ubuntu and Debian).

Note: In case there are more than one available usb devices use -d 0x1457:0x5119 option.

To update u-boot:

{{Warning|Do not update u-boot unless you have [[debug board]] or are really sure about what you are doing. Flashing a wrong u-boot image will brick your device!}}

I you own a FreeRunner don't be too scared, though: Unlike nearly any other deviceon the market the Freerunner contains a second bootloader on a write protected chip - that is still there, even if flashing the original bootloader goes horribly wrong. You can always make the phone use this bootloader instead by pressing the power button whilst pressing the Aux button - and get a second and any sucessive try to flash the u-boot loader the right way. In theory it should therefore be impossible to brick your phone completely enough by flashing the bootloader that a debug board is needed to unbrick it.
* Download the newest uBoot binary from http://downloads.openmoko.org/releases/Freerunner/
* start the cellular phone by pressing power whilst pressing the aux button.
* Run the following command, but Note especially that the image used in the line below is for GTA02_v5.

dfu-util -a u-boot -R -D uboot-gta02v5-latest.bin

The u-boot of a GTA01B_v03 (And only of a GTA01B_V03, not for example a GTA01B_v04) can be flashed with the following image:
./dfu-util -a u-boot -R -D u-boot-gta01bv3-latest.bin

* The device is now flashed:
dfu-util - (C) 2007 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

Opening USB Device 0x0000:0x0000...
Claiming USB DFU Runtime Interface...
Determining device status: state = appIDLE, status = 0
Device really in Runtime Mode, send DFU detach request...
Resetting USB...
Opening USB Device...
Found Runtime: [0x1d50:0x5119] devnum=9, cfg=0, intf=0, alt=1, name="u-boot"
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x1000
bytes_per_hash=4316
Starting download: [##################################################] finished!
state(2) = dfuIDLE, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode
* The last message (status(0)) tells us everything just worked fine - at the next boot the device will be started by the newest uboot loader.

To update the kernel:
./dfu-util -a kernel -R -D ./uImage-2.6.21.1-moko10-r0_0_1883_0-fic-gta01.bin
Flashing the kernel will probably take less than 1 minute. If you're having trouble, you may want to compare the output that you see to a "known good" [[Flashing openmoko/Known good kernel flash U-Boot output | U-Boot]]/[[Flashing openmoko/Known good kernel flash dmesg output | dmesg]]/[[Flashing openmoko/Known good kernel flash dfu-util output | dfu-util]] output. The phone display should show "Starting DFU DOWNLOAD to partition 'kernel'.

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

Flashing the root filesystem will probably take around 13 minutes. Note that it can take over an hour if you are using a XEN VM for doing the flash.

Here is some "known good" output from [[Flashing openmoko/Known good rootfs flash U-Boot output | U-Boot]], [[Flashing openmoko/Known good rootfs flash dmesg output | dmesg]], and [[Flashing openmoko/Known good rootfs flash dfu-util output | dfu-util]]. The phone display should show "Starting DFU DOWNLOAD to partition 'rootfs'.

Notice that it's not normally necessary to update the modules anymore. It's just for people with special needs.

...now, you'll end up with system that boots, but does not see audio/SD card. You'll need to download corresponding modules.tgz and copy them over to openmoko. - UPDATE: GTA01 phones appear to not need this step, as long as you have installed a kernel that matches the version of the modules contained in the root image ('uname -r' will show the kernel version, and 'ls /lib/modules/' will show the modules that are present).

== IMPORTANT NOTEs FOR EARLY ADOPTERS: ==
Some ols U-Boot versions are very buggy:

For U-Boot versions until somewhere in 2007 if you uploaded your rootfs image that is smaller that previous one it wouldn't work - you needed to attach to the u-boot bootloader first, erase NAND partition that would contain the rootfs later and then upload your rootfs:

<pre>
cu -l /dev/ttyACM0
GTA01Bv3 # nand erase rootfs
</pre>

Also you may have to press the AUX button every 25 seconds or so to prevent the phone from going to sleep while being flashed. Very early versions also does not erase the rootfs before flashing it... to do that, do minicom /dev/ttyACM0, then nand erase rootfs, like written above.

Good luck!

== Where to go from here ==

So, now you have one of the more recent kernel and rootfs images, or one of the (semi)official ones, whats next?

You probably want to set up [[USB_Networking]] and then configure your Neo1973 some more.

Do not forget to update your Neo1973 using

ipkg update && ipkg upgrade

or (newer versions)

opkg update && opkg upgrade

and have a look at additional ipkg [[repositories]].

Question to anybody who knows: The kernel the openmoko boots from is in a different partition than the root file system in most setups right now. In former times there always was a warning that ipkg updates /boot/uImage - the location where the kernel that matches the current rootfs can be found - but didn't update the partition the kernel is loaded from in the default setup. The following line manually updates the kernel on this partition:
cat /boot/uImage >/dev/mtdblock3

Is typing this line still necessary?
[[User:Peterpall]]

== Troubleshooting notes ==

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

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

This message can also occur if you connect the usb cable before you are in the bootloader menu. You must carefully follow the sequence described at the beginning of this article and not connect the USB cable too early.

dfu-util does not seem to be able to download files if run from linux running under
VMWare on a Windows OS host.

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

[[Category:Flashing Openmoko| ]]

Flashing the Neo 1973

2008-07-27T11:31:24Z

Peterpall: /* Where to go from here */

{{Languages|Flashing Openmoko}}
This describes how to update your Neo1973 to the latest software. We'll update the kernel, the root filesystem and optionally u-boot [[partitions]] in the internal flash memory.

{{Note|
* MacOS X users: please refer to [[MacOS_X]].
* Users without Linux please refer to [[No_Linux]] for the moment.

You may prefer to read directly :
* [[Flashing the Neo FreeRunner]]
}}

{{warning|If you're updating u-boot and don't have a [[Debug Board]], you might render your unit unusable if the flashing procedure is interrupted}}

{{warning|If you have U-boot from before 2008 and upload a rootfs image that is smaller than the previous one, or if you have written to the rootfs, just flashing may not work - you may need to run a "[[Nand_erase|nand erase rootfs]]" before you then upload your rootfs (details [[Bootloader#Accessing_the_bootloader_prompt|here]]). Running "nand erase rootfs" before flashing a new rootfs, is quick and saves you the time of a second rootfs upload. Attention: If you [[Nand_erase|erase NAND]] without mentioning the partition to be erased, u-boot will be wiped out and the Neo will be bricked}}

== Files to download ==

The rootfs & kernel images you download need to match. The loadable modules for the kernel are in /lib/modules/ on the rootfs [[partition]] - if you get the wrong combination, you will get some error messages during bootup that it cannot access /lib/modules/x.y.z-moko123 - in this case swap either the kernel or the rootfs to match the other's version. Unfortunately the rootfs filename does not seem to tell what kernel version it is compatible with, you just have to try a few. '''NOTE:''' At least some combinations seem to boot up fine even if the module versions mismatch so be sure to check the console while it's booting after flashing.

The "moko123" in the error message example above indicates the openmoko patchset version.

Necessary files are at:
*http://buildhost.openmoko.org/OM2007.2/tmp/deploy/glibc/images/neo1973/?C=M;O=D

*http://buildhost.openmoko.org/daily/neo1973/deploy/glibc/images/neo1973/?C=M;O=D (Daily unstable builds)

*http://buildhost.automated.it/OM2007.2/?M=D (Location of more current unofficial builds.)

A list of download locations can be found at [[Repositories]]. See [[Phase 1 Software Testing]] for a list of tested images.

Changelogs can be found at:
*http://cia.vc/stats/project/openembedded/.rss

*http://cia.vc/stats/project/openmoko/.rss

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

== Preparing the device for DFU mode ==

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

* Unplug all usb devices from the host.
* Hold the phone's [[Neo1973 AUX Button | AUX button]] and then press the phone's [[Neo1973 Power Button | POWER button]].
** You'll need to hold the POWER button for about 4 seconds before the device will turn on. Otherwise the screen will only flash white for a second and the phone won't power up.
* The u-boot menu should appear:
<pre>
U-Boot ..

=== BOOT MENU ===

BOOT
Set console to USB
Set console to serial
Power off
Boot from SD
Factory reset

Press [AUX] to select, [POWER] to execute.
</pre>

* Plug Neo1973 into host with supplied USB cable. (Plug the phone directly into the host not via a hub.)

'''Note:''' If the bootloader remains inactive for about 30 seconds, that is no keypresses or no use of the serial console, the device will automatically power down.
You can prevent this by just pressing the AUX button every 30 seconds or so or by telling the bootloader to not exhibit this behaviour.
To do so, please connect to the bootloader:

<pre>
cu -l /dev/ttyACM0
GTA01Bv4 # setenv boot_menu_timeout 65000
GTA01Bv4 # saveenv
</pre>
For those that are unfamiliar with cu, to exit you need to press "~."

(You may have to install the uucp package to have access to cu, and maybe also "<code>chown uucp:uucp /dev/ttyACM0</code>" as root before it will work)

No further navigation is needed in u-boot - the device will automatically start flashing the images when told to do so by dfu-util below. After flashing all the files, you can choose the "Boot" option to boot the newly flashed stuff.

== Actually flashing things into the device ==

Double check that u-boot matches your hardware version. First determine what hardware revision you have [[finding hardware revision]], so that you can download and install the correct bootloader.

You'll probably only want to update u-boot if you have the [[debug board]] for fixing failed u-boot updates. You can also check the current [[partitions]].

Note: It may be necessary to run the application as root (at least in Ubuntu and Debian).

Note: In case there are more than one available usb devices use -d 0x1457:0x5119 option.

To update u-boot:

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

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

This is simple - even if I find it somehow scary to flash the bootloader of a device. Don't be too scared, though: Unlike any other device I know the Freerunner contains a second bootloader on a write protected chip - that is still there, even if flashing the original bootloader goes horribly wrong. You can always make the phone use this bootloader instead by pressing the power button whilst pressing the Aux button. In theory it should therefore be impossible to brick your phone completely enough by flashing the bootloader that a debug board is needed to unbrick it.
* Download the newest uBoot binary from http://downloads.openmoko.org/releases/Freerunner/
* start the cellular phone by pressing power whilst pressing the aux button.
* Run the following command:
dfu-util -a u-boot -R -D uboot-gta02v5-latest.bin
* The device is now flashed:
dfu-util - (C) 2007 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

Opening USB Device 0x0000:0x0000...
Claiming USB DFU Runtime Interface...
Determining device status: state = appIDLE, status = 0
Device really in Runtime Mode, send DFU detach request...
Resetting USB...
Opening USB Device...
Found Runtime: [0x1d50:0x5119] devnum=9, cfg=0, intf=0, alt=1, name="u-boot"
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x1000
bytes_per_hash=4316
Starting download: [##################################################] finished!
state(2) = dfuIDLE, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode
* The last message (status(0)) tells us everything just worked fine - at the next boot the device will be started by the newest uboot loader.

To update the kernel:
./dfu-util -a kernel -R -D ./uImage-2.6.21.1-moko10-r0_0_1883_0-fic-gta01.bin
Flashing the kernel will probably take less than 1 minute. If you're having trouble, you may want to compare the output that you see to a "known good" [[Flashing openmoko/Known good kernel flash U-Boot output | U-Boot]]/[[Flashing openmoko/Known good kernel flash dmesg output | dmesg]]/[[Flashing openmoko/Known good kernel flash dfu-util output | dfu-util]] output. The phone display should show "Starting DFU DOWNLOAD to partition 'kernel'.

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

Flashing the root filesystem will probably take around 13 minutes. Note that it can take over an hour if you are using a XEN VM for doing the flash.

Here is some "known good" output from [[Flashing openmoko/Known good rootfs flash U-Boot output | U-Boot]], [[Flashing openmoko/Known good rootfs flash dmesg output | dmesg]], and [[Flashing openmoko/Known good rootfs flash dfu-util output | dfu-util]]. The phone display should show "Starting DFU DOWNLOAD to partition 'rootfs'.

Notice that it's not normally necessary to update the modules anymore. It's just for people with special needs.

...now, you'll end up with system that boots, but does not see audio/SD card. You'll need to download corresponding modules.tgz and copy them over to openmoko. - UPDATE: GTA01 phones appear to not need this step, as long as you have installed a kernel that matches the version of the modules contained in the root image ('uname -r' will show the kernel version, and 'ls /lib/modules/' will show the modules that are present).

VERY IMPORTANT NOTE (I would consider that as a design flaw - either dfu-util should do it automatically): If you upload rootfs image that is smaller that previous one it won't work - you need to attach to the u-boot bootloader, erase NAND first and then upload your rootfs:

<pre>
cu -l /dev/ttyACM0
GTA01Bv3 # nand erase rootfs
</pre>

Old versions of u-boot are buggy: You may have to press the AUX button every 25 seconds or so to prevent the phone from going to sleep while being flashed. It also does not erase rootfs before flashing it... to do that, do minicom /dev/ttyACM0, then nand erase rootfs.

Good luck!

== Where to go from here ==

So, now you have one of the more recent kernel and rootfs images, or one of the (semi)official ones, whats next?

You probably want to set up [[USB_Networking]] and then configure your Neo1973 some more.

Do not forget to update your Neo1973 using

ipkg update && ipkg upgrade

or (newer versions)

opkg update && opkg upgrade

and have a look at additional ipkg [[repositories]].

Question to anybody who knows: The kernel the openmoko boots from is in a different partition than the root file system in most setups right now. In former times there always was a warning that ipkg updates /boot/uImage - the location where the kernel that matches the current rootfs can be found - but didn't update the partition the kernel is loaded from in the default setup. The following line manually updates the kernel on this partition:
cat /boot/uImage >/dev/mtdblock3

Is typing this line still necessary?
[[User:Peterpall]]

== Troubleshooting notes ==

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

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

This message can also occur if you connect the usb cable before you are in the bootloader menu. You must carefully follow the sequence described at the beginning of this article and not connect the USB cable too early.

dfu-util does not seem to be able to download files if run from linux running under
VMWare on a Windows OS host.

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

[[Category:Flashing Openmoko| ]]

Getting Started with your Neo FreeRunner

2008-07-20T16:26:38Z

Peterpall: /* Installing multimedia, web browsing and other applications */ Needed to split up 2 commands to make them work.

{{Languages|Getting Started with your Neo FreeRunner}}

{| class="wikitable" cellspacing="2" cellpadding="2" style="padding: 0%; margin:0em 0em 1em 0em; background:#eeeeee; width:100%;floating="center"; "
! style="background:#fcfcfc; width:75% " |

Thank you for purchasing this Developer release of Neo FreeRunner. The [[Neo FreeRunner]] phone is the second hardware platform to take advantage of [[Openmoko]]. This guide will help you get to know your Neo FreeRunner and how to start using your Neo FreeRunner.
! style="background:#fcfcfc; width:25% " |
[[Image:Freerunner box.png|200px|thumb|Neo FreeRunner Package]]
|}

== Package Contents ==

[[Image:GTA02ALL.png|left|400px|thumb|Inside the package]]
 
: [[Image:Circle２.gif|10px]] Neo FreeRunner
: [[Image:Circle２.gif|10px]] Stylus
: [[Image:Circle２.gif|10px]] Battery
: [[Image:Circle２.gif|10px]] Charger
: [[Image:Circle２.gif|10px]] USB Cable (A -> Mini-B 5-pole)
: [[Image:Circle２.gif|10px]] microSD Card 512MB & SD adapter

<div style="clear: both"> </div>

== Setting up the hardware, getting to know the Neo FreeRunner physically ==

===Installing the Micro-SD card, the SIM card, and the Battery ===

<div align-center>
<table width="80%" style="clear: both; border: 1px solid #ffffff; border-collapse: collapse; padding: 0.2em; margin: 0; font-size: 100%; margin: 0 1px;">
<tr valign="top" style="background: #ffffff">
<td style="width: 50%; white-space: nowrap; padding: 4px 1em 0 0.5em; border-right: 1px solid #ffffff;">[[Image:menu13.jpg|233px|thumb|Open the case like this.|center]]</td>
<td style="padding: 1px 1em 0; background: #ffffff;">[[Image:menu14.jpg|250px|thumb|Opening !|center]]</td>
</tr>
<tr valign="top" style="background: #ffffff">
<td style="padding: 1px 1em 0; background: #ffffff;">[[Image:menu11.jpg|260px|thumb|Put the SIM card and SD card here.|center]]</td>
<td style="width: 50%; white-space: nowrap; padding: 4px 1em 0 0.5em; border-right: 1px solid #ffffff;">[[Image:menu12.jpg|233px|thumb|Finally, put in the battery.|center]]</td>
</tr></table>
</div>

# Remove the rear cover of the Neo FreeRunner by first holding the Neo FreeRunner on the side and then use your fingernail to prise off the rear cover at the slot on top of the device.
# Now you should be able to locate the combined SIM and Micro-SD card holder at the bottom of the battery compartment.
# Unlock the SIM card holder by sliding the metal clip down, towards the USB socket, with your fingernail. Use caution, as these parts are delicate and could be damaged by forcing them in the wrong direction.
# Lift up on the SIM card holder.
# The Micro-SD card holder is held in place by a latch on either side. It is easiest to open the Micro-SD card holder by releasing these latches one at a time rather than by lifting from the middle, as lifting from the middle tends to increase the latching pressure. A small screwdriver or knife can be used for this.
# Insert the Micro-SD card into the Micro-SD card holder. Note that on the inside of metal part of the holder there are little holding tabs for the card. Slide the card in these holders (on the metal part) before closing the card holder. Note that the electrical contacts should face down and towards the edge of the Neo Freerunner.
# Close the Micro-SD card holder, making sure that both latches of the holder are securely fastened.
# Insert the SIM card into the SIM card holder, taking care to slide inside the two metal tabs in the cover. Note that the electrical contacts should face down and that the cut corner should be closest to the external GPS Antenna Socket.
# Close the SIM card holder and lock it by sliding the metal clip towards the external GPS Antenna Socket on the FreeRunner.
# Insert the battery into the battery compartment, aligning the electrical contacts on the battery with the electrical contacts in the battery compartment. Insert the side with the electrical contacts first.
# Replace the rear cover on the FreeRunner.

[[Image:FR_SIM_SD_open.jpg|457px|thumb|SIM and SD holders open, with cards in place|center]]

[[http://video.google.de/videoplay?docid=-8343770443102960945 A short video]] is also available. It was shot using the previous version of the Neo, but the installation procedures remains the same.

===Charging the Neo FreeRunner===

When using the Neo FreeRunner for the first time, you should charge the battery completely. The battery can be charged using the provided charger (at 1000mA) or from a powered USB port capable of providing 500mA worth of current. Most computers will be able to charge the FreeRunner without any problems.

Charging an empty battery at 100mA takes 12~15 hours, at 500mA takes 2,5~3,5 hours, and at 1000mA takes 1.5~2.5 hours. (90%~100%) [to be confirmed]

Make sure that the battery never discharges completely. This is an issue because the internal charging circuitry can not be turned on until the FreeRunner has booted, and booting through USB power alone does not work. Should the battery become completely discharged, your options are:
- Use external stand-alone charger (compatible with the Nokia BL-5C battery)
- Boot the FreeRunner with an alternative battery, or with a spare GTA01 or GTA02 battery, plug USB power, then switch to the empty battery.
- Boot the FreeRunner with a 4.5VDC external power source (steady hand and great care involved), plug USB power, then insert the empty battery.

===Buttons and connectors===

<table width="80%" style="clear: both; border-collapse: collapse" valign="top">
<tr>
<td style="width: 25px"> </td>
<td style="width: 370px">[[Image:menu9.jpg|370px|thumb|Power Button, USB and external GPS Antenna (left to right)|center]]</td>
<td style="width: 25px"> </td>
<td style="width: 370px">[[Image:menu8.jpg|370px|thumb|AUX Button and phone jack (left to right)|center]]</td>
</tr>
<tr>
<td></td>
<td>'''Power'''
Tapping the power button exits the current application.

Holding the power button brings up a menu allowing you to:
* Power on and off the GPS, wifi, GSM, and bluetooth antennae
* Change power management mode to:
** Dim first then lock
** Dim only, don't lock
** Disabled
* Lock the screen
* Shutdown the device.</td>
<td></td>
<td>'''Aux'''

Holding the Aux button brings up a menu allowing you to:

* Hide and show the title bar (Fullscreen toggle)
* Alternate wide or tall display modes (Swap Orientation)
* Save the content of the screen as an image file (Screenshot)
</td>
</tr>
</table>

===Unlocking the screen===

When the screen is locked, you should see a Matrix-style green graphic with the Openmoko symbol in the middle of the bottom of the screen along with lock and unlock symbols. If you drag the Openmoko symbol to the unlock symbol at the top then the screen will become unlocked.

== Navigating menus and applications ==

''Note:'' this section describes the interface used by the "2007.2" image, which is the current default image for Openmoko.

====Today Page====
Openmoko starts by displaying the "Today" page, which is your home page. Icons in the top row indicate the status of the phone. The bottom row consists of three tabs. The tab with a home on the left lead to the "Today" page you're viewing now. The central tab lead to the "Launch Task" page, which is the main menu used to start applications. The tab with gears on the right lead to the "Running Tasks" page, which is used to deal with currently open windows and applications.

The "Today" page is empty for now. It won't remain so for long. Keep reading to turn on the "full view". In the full view, a second row of icons give quick links to commonly-used applications such as the dialer, and the main body of the screen displays a clock and other useful information. See [[Today/2007.2]] for more information about the Today page and customization.


 

====Launch Task Page====

{{stub}}

This page displays a menu of available applications. You may choose a category of applications to display to simplify the screen, or choose to display them all.

Current categories are [[PIM Suite]], [[Applications]], [[Games]], [[Utilities]], and All.

====Running Tasks Page====

{{stub}}

This page displays currently-running tasks. Any individual task may be terminated by selecting it and then clicking on the garbage-can icon to close it. All tasks may be terminated by clicking on any one of them and then clicking on the "folder" icon in the upper right (expect this to change in future releases). Any task may be rejoined by selecting it and then selecting the "return" icon at the middle top.

====Exiting an Application====

Any time an application is running, you can simply click the device's power button and the application will exit, returning you to the Today page.

Alternatively, you can switch tasks at any time by clicking the menu of tasks at the far upper-left of the screen, which will display a list of running tasks, allowing you to select one.

(''Note:'' If the task menu is not shown, use the [[#Aux|Aux]] button to bring up the Aux menu, and select "Toggle Fullscreen".)

== Using the terminal ==

To start a console from "Today" page, click the middle tab at the bottom of the screen to display the "Launch applications" page, then select the X term. The terminal application has a multitap keyboard that slides up and down from the bottom of the screen.

===Setting date and time===

As of this writing, I have not found a way to setup the date and time graphically. Open the terminal application and issue one of the following commands:

date -s ''MMDDhhmm''
date -s ''MMDDhhmmYYYY''
date -s ''MMDDhhmmYYYY.ss''

where ''MM'' is the month, 01-12; ''DD'' is the day, 01-31; ''hhmm'' is the time, 0000-2359; ''YYYY'' is the optional year, and ''.ss'' is the optional seconds. See [[Setting_Date_and_Time]] for more discussion.

===Adjusting the Volume===

As of this writing, there is no way to adjust the volume from the screen.

For now, run the terminal application or [[Getting_Started_with_your_Neo_FreeRunner#Connect_to_the_Neo_FreeRunner_By_USB_Networking|log in via usb]], and run the [[alsamixer]] application. The mixer is simpler than it looks. Just use the left and right arrow keys to select "headphone" or "PCM" and use the up and down arrow keys to adjust the volume. You can also adjust your microphone volume with the "mic2" adjustment. Press ESC when finished. Then exit the terminal application or log out of the USB login.

You may need to update configuration files in /usr/share/openmoko/scenarios/ to make the microphone setting permanent. Use
alsactl -f ''path-to-statefile'' store
to do this.

The default files are as follows (in /usr/share/openmoko/scenarios/):
:gsmhandset.state
:gsmheadset.state
:gsmspeakerout.state
:headset.state
:stereoout.state

These correspond to the various Sound Profiles accessible in the Debug Tool under Applications.

One way to increase the volume of the microphone is to do the following:
# ssh into your Freerunner
# vi /usr/share/openmoko/scenarios/gsmhandset.state
# search for "Mic2"
# change to "value 3"
[[Freerunner_Hardware_Issues]]

=== Accessing the microSD card ===

Mounted at /media/card by default.

If you have multiple partitions on the card, the first (/dev/mmcblk0p1) will be mounted at /media/card, the second at /media/mmcblk0p2, the third at /media/mmcblk0p3 etc.

== Set up USB-based networking and update ==

===Connect with and log in the Neo FreeRunner===

Connect the Neo FreeRunner to your Linux computer using the standard mini-USB to USB cable provided.

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

1. ping the Neo with
# ping -I usb0 192.168.0.202
2. add a route to your Neo (adjust your firewall if necessary):
# /sbin/route add -host 192.168.0.202/32 dev usb0
3 log in to the Neo with empty password
# ssh root@192.168.0.202

You will eventually want to setup your computer so that it automatically connects the Neo FreeRunner to the Internet when it is plugged in. This is discussed in the [[USB_Networking]] section, which you should see if the procedure above fails.

===Setup DNS===

In order to use the package manager, a DNS server should be defined. To achieve this, ssh into the Neo FreeRunner and create a file /etc/resolv.conf with at least one line reading:

nameserver xxx.xxx.xxx.xxx

e.g. nameserver 192.168.1.1

If you are unsure as to which nameserver IP address to use, a valid IP is typically available in the /etc/resolv.conf file of your host system. You will eventually want to setup the Neo so that it automatically finds a DNS server. This is discussed in the [[USB_Networking]] section.

===Use the package manager===

There are three layers to the software on the FreeRunner:

* uBoot: Think of u-boot as a combination of the BIOS and Grub on a PC.
* Kernel: The Linux kernel
* Root Filesystem: The rest of the system

In order to keep the FreeRunner up-to-date with the latest features and bug-fixes, it is advisable update the software at regular intervals. There are two main methods of doing this: using the package manager opkg (discussed in this section) or [[Flashing the Neo FreeRunner|flashing the device]].

uboot, the kernel and the root filesystem can all be flashed to update them. For uboot, this is the only possibility. The advantage of flashing the kernel, rather than using opkg seems to be speed. The disadvantage of flashing the root file system is that it wipes out all local modifications, including /home. If /home is moved to the SD disk, this is no longer a problem.

Assuming that your FreeRunner can access the internet (see above), the kernel and other packages can be updated with

# opkg update
# opkg upgrade

The first updates the repository information, telling opkg what packages are available. The second upgrades all packages for which a newer version is available. '''At the moment, some signature files are missing (404 errors), which opkg complains about, but this is cosmetic.''' The repositories will still update with the missing signature files.

Note that running opkg upgrade on a factory-fresh phone will upgrade dropbear (the ssh software) and various xserver packages, and neither upgrades elegantly while in use, so either upgrade dropbear from the FreeRunner's terminal and then upgrade the rest via ssh, or upgrade the xserver packages via ssh and then upgrade the rest from the FreeRunner's terminal. For example, go to the FreeRunner terminal and type:

# opkg install dropbear

which will upgrade it to the latest version. Then connect to the FreeRunner via ssh and type:

# opkg upgrade

If you do your first upgrade in two installments like this, it will go more smoothly.

It will be possible in the future to update uboot with opkg, but this has not yet been implemented

=== Installing multimedia, web browsing and other applications ===

There are many applications you can install - check out the [[Repositories]] for a list of packages.

The calendar can be installed with

opkg install openmoko-dates2

For a Media Player:

opkg install openmoko-mediaplayer2
wget http://abraxa.dyndns.org:81/random/openmoko-mediaplayer-theme.tar.bz2
tar xjf openmoko-mediaplayer-theme.tar.bz2 -C /usr/share/themes/Moko/gtk-2.0
rm openmoko-mediaplayer-theme.tar.bz2

If you want a basic image viewer, have a look at the one from the gpe suite:

opkg install gpe-icons
opkg install gpe-gallery

To obtain the standard web browser, use:

opkg install openmoko-browser2

An alternative browser, minimo, offers many more features.
First download and unpack it on your GNU/Linux host:

wget http://www.ginguppin.de/files/minimo.tar.bz2
tar jvxf minimo.tar.bz2

Copy it over to the FreeRunner:
scp minimo_* root@openmoko:/tmp

Then on the FreeRunner:
opkg install /tmp/minimo_0.02\+cvs20070626-r0_armv4t.ipk

You'll probably also want to [[Switching Keyboards|change the keyboard]] including the [[Switching Keyboards#How_to_add_a_keyboard_toggle_button|keyboard toggle applet]]

=== Importing contacts ===

If you can export your contacts to VCard format, either multiple files or single file containing all of them, you may use the script on [[Import Vcf Contacts]] page to bring them to Neo.

==The next steps==

Congratulations for setting up your Neo FreeRunner. There are many more ressources to help free your phone:

===Customize the interface: clock, keyboard...===

The stock [[Openmoko2007.2]] image flashed onto the Neo FreeRunner is really just the bare bones. For example, you don't have the clock and the quick-launch icons showing. Here's how you can change that:

# dbus-launch gconftool-2 -t boolean -s /desktop/poky/interface/reduced false
# /etc/init.d/xserver-nodm restart

If you rather have a regular clock instead of the digital one, do this instead:

# dbus-launch gconftool-2 -t boolean -s /desktop/poky/interface/reduced false
# dbus-launch gconftool-2 -t boolean -s /desktop/poky/interface/digital_clock false
# /etc/init.d/xserver-nodm restart

More information about today screen customization at [[Today/2007.2]].

With either clock, you may wish to set the correct [[Date]] and [[Timezone]].

Also, if you prefer having a full keyboard, using matchbox's qwerty keybord, see [http://www.ginguppin.de/node/15 these instructions]. Then you may also see [http://lists.openmoko.org/pipermail/community/2008-July/021296.html these], which describe a way to add an applet allowing the showing/hiding of that keyboard.

===GPS, GPRS and WLAN===

See [[GTA02 WLAN]] about wifi. See [[Manually using GPRS]].

Simple guide to get going with GPS:

# opkg install gpsd
# echo "GPS_DEV=\"/dev/ttySAC1\"" > /etc/default/gpsd

and restart gpsd, the gps daemon, with

# /etc/init.d/gpsd restart

To test GPS, you can use agpsui:

# opkg install openmoko-agpsui

For a nice map, try tangoGPS:

# opkg install http://www.tangogps.org/downloads/tangogps_0.9.2-r1_armv4t.ipk

More information on [[GPS]] page.

According to some [http://lists.openmoko.org/pipermail/support/2008-July/000003.html posts], GPRS might be broken currently (2007.2), though. There are also critical [[GPS Problems]]. To install the updates when they become available, you will probably want to learn about [[Booting the Neo FreeRunner]] and [[Flashing the Neo FreeRunner]].

=== The community ===
==== Mailing lists ====

There are several [[http://lists.openmoko.org/mailman/listinfo/ Mailing lists]]

There is an active community mailing list.
You may ask for help on the support mailing list : more details at https://lists.openmoko.org/mailman/listinfo/support

An excellent tool for searching all the openmoko mailing lists is http://openmoko.markmail.org/

==== The wiki ====

If you want to know more about the Neo FreeRunner then you can get more information in the following topics:

* [[GTA02 Openness]]
* [[Neo FreeRunner]]
* [[Neo FreeRunner GTA02 Hardware]]
* [[FreeRunner/Buttons and LEDs]]
* [[Latest Images]]
* [[Distributions]]

To search this wiki with Google, use the following search term:

<search term> site:http://wiki.openmoko.org/wiki/

==== Blogs ====

The [http://planet.openmoko.org/ collection of blogs on OpenMoko].

==== Other documents ====

* http://quickstart.openmoko.org/

[[Category:GTA02 Hardware]]
[[Category:Guides]]
[[Category:User Guides]]

MokoMakefile

2008-07-17T19:35:28Z

Peterpall: /* Developing with MokoMakefile */

{{Languages|MokoMakefile}}

MokoMakefile is a Makefile which saves lots of work when setting up an Openmoko build environment.
By automating the setup process of a new Openmoko build environment, it provides an environment which is configured the same for all the existing developers and should therefore be preferred over manual procedures or individual setup procedures.
It brings the same repeatability to build environment creation and maintenance as that which the BitBake scripts bring to [[OpenEmbedded]] ease and standardize the process of building OpenEmbedded.

Unlike the manual process described at [[Building Openmoko from scratch]], MokoMakefile does not install anything into your system (it can and should be started as normal user).
MokoMakefile is a wrapper around all that is required to make it easy to set up and maintain a development environment that fully complies with the setup instructions published by Openmoko.

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

The MokoMakefile is able to build both OM-2007.2 and QTopia-X11 images.

MokoMakefile also builds the QEMU-based Neo1973 emulator as part of the build process and has make targets to install the Openmoko images into it and run it. These commands can also be used without downloading and building the whole Openmoko OpenEmbedded distribution. This part is described in [[Using QEMU with MokoMakefile]].

== Requirements for building Openmoko ==
Independent on whether MokoMakefile or a manual process is used to setup an Openmoko build environment, there are several requirements which must be fulfilled in order for the Openmoko build to succeed:

* RAM: The build host needs to have at least 512MB of RAM, and about the same amount of swap. Some packages built by OpenEmbedded like busybox are built by compiling all source files into one binary which causes gcc to grow beyond 300MB of size and no part of this memory may be on swap for the compile to finish in predictable time. For busybox, this can be turned off, but turning this off means that busybox will not as well optimized by gcc.

* Disk space: You need about 12 GB of available disk space for the Openmoko build to succeed (see below for a tip on how to reduce this).

* Time: The initial build takes at least 5 hours (on 2GHz core2duo without multiprocessor optimization) and may take several days on slower machines.

=== Required software ===

Some distribution specific hints on preparing your build host for building OpenEmbedded are on http://wiki.openembedded.net/index.php/OEandYourDistro but they may be outdated, incomplete and do not cover everything which Openmoko needs to build.

A good guide is [[Building Openmoko from scratch#Build host prerequisites|the section on build host prerequisites]] in [[Building Openmoko from scratch]]

If you forgot anything which OE needs itself, OE will tell you shortly after you start building, but it does not check build dependencies of Openmoko, so you either have to install them before starting or install them after the build failed. OpenEmbedded will continue where it stopped when you restart the build afterwards.

==== Package requirements by distribution ====
Your distribution needs to provide these commands in order for OpenEmbedded to start building:
subversion texi2html texinfo help2man

Openmoko needs the development packages (with header files, development libraries and tools) in order to finish building:
ncurses zlib (or libz) OpenSSL GTK++

Because there are bugs in the interaction of QEMU and GCC-4, you'll need a copy of gcc-3.x installed as well.

===== Debian / Ubuntu =====
apt-get install subversion build-essential help2man diffstat texi2html texinfo cvs gawk cogito

apt-get install libncurses5-dev zlib1g-dev libssl-dev libgtk2.0-dev
# To prevent errors in host validation
apt-get install ca-certificates
# For Openmoko 2007.2 using BitBake-1.8.8:
apt-get install python-pysqlite2 sqlite3 sqlite3-doc python-pysqlite2-dbg
# For building faster
apt-get install quilt python-psyco ccache
# For qemu, install a second compiler for bug avoidance; MokoMakefile knows to look for it.
apt-get install gcc-3.4 g++-3.4 libsdl1.2-dev lynx netpbm dosfstools

# On Ubuntu 8.04, the following was required instead of cogito:
apt-get install git-core

===== SuSE =====
For building Openmoko on 10.3, you need
gcc-c++ ncurses-devel zlib-devel libopenssl-devel gtk2-devel subversion diffstat texinfo help2man
For MokoMakefile to not fail on compiling qemu-user, you need to use gcc33:
wget download.opensuse.org/repositories/devel:/tools:/gcc/openSUSE_Factory/i586/{cpp,gcc}33-3.3.3-41.8.i586.rpm
rpm -Uhv {cpp,gcc}33-3.3.3-41.8.i586.rpm

See also the [[Talk:MokoMakefile#Building_on_SuSE_Linux_10.3-AMD64|Talk page on Building on SuSE Linux 10.3-AMD64]]

10.1 and 10.2: same packages as 10.3, but install <code>openssl-devel</code> instead of libopenssl-devel.

==== For all distributions ====
As the QEMU-based neo1973 emulator is also built as part of the build process started by MokoMakefile, so you need gcc-3.3 and other packages for building QEMU installed. See [[Using QEMU with MokoMakefile#Build requirements|the build requirements section]] in [[Using QEMU with MokoMakefile]] for information on the required software.

If you are having problems compiling QEMU and do not need it, you can disable building of QEMU by adding following line to build/conf/local.conf file:
ENABLE_BINARY_LOCALE_GENERATION = "0"

===== Proxy =====
Users behind a proxy should ensure that their proxy is configured in their wgetrc file as the http_proxy environment variable is unset by MokoMakefile.

== Building Openmoko with MokoMakefile ==

=== Preparations ===
Create your $OMDIR directory (note that you can change ~/moko to any directory you like. If you have your ~moko dir mounted from a different file system, be sure to edit /etc/mtab to add the 'exec' permission to the file system, else bitbake will fail with error messages stating that /usr/bin/env is an invalid interpreter):
mkdir ~/moko ; cd ~/moko

=== MokoMakefile ===
Grab MokoMakefile:
wget http://www.rwhitby.net/files/openmoko/Makefile

If that doesn't work, try

wget http://svn.projects.openmoko.org/svnroot/mokomakefile/trunk/Makefile

{{note|MokoMakefile uses BitBake 1.8.8 which requires python-sqlite2 and sqlite-3.3 or later. Users of SUSE Linux 10.1 can update to [http://download.opensuse.org/pub/opensuse/distribution/10.2/repo/oss/suse/i586/sqlite-3.3.8-14.i586.rpm the version of openSUSE 10.2]}}

=== Environment ===
Set up the environment:

make setup

If you want to make the ASU or FSO instead of the OM2007.2, see [[Distributions]], you need to edit your Makefile. Change OM_GIT_BRANCH to one of the following:
OM_GIT_BRANCH := org.openmoko.dev # OM2007.2
OM_GIT_BRANCH := org.openmoko.asu.dev # ASU
OM_GIT_BRANCH := org.openmoko.asu.stable # ASU stable
OM_GIT_BRANCH := org.openembedded.dev # FSO

=== Buiding ===
Before starting a lengthy make process, check the Tips section below for how to make Make multicore aware. You may want to modify the build/conf/local.conf file for your target (emulation/chroot) environment:
make openmoko-devel-image
(or use "make openmoko-qtopia-x11-image" if you're building the ASU)
(or use "make fso-image" if you're building the FSO)

''Hint:'' The images build with this command can be found under {$OMDIR}/build/tmp/deploy/images/neo1973

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

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

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

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

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

3 - To update the Openmoko repository checkout and the MokoMakefile patches to the latest version:
make update

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

==Build issues==
First, make sure that the problem is reproducible after running

make update-makefile && make setup && make update

then run

make clean-package-<foo>

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

and finally

make openmoko-devel-image

With luck - you should now have images in your $omdir/build/tmp/deploy/glibc/images/neo1973/ directory.
You can then [[Flashing openmoko||flash these.]]

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

If you have chronic build problems, cleaning your environment variables and re-running the build from scratch may help. The following script should remove all non-essential variables; you should also manually trim your path to the minimum.
`env | grep -Ev '^SHELL=|^TERM=|^OLDPWD=|^USER=|^USERNAME=|^PATH=|^EDITOR=|^LANG=|^HOME=|^DISPLAY=|^_=' | sed 's/^$.*$=.*/unset \1/'`

(you must include the backtics).
Note that on some boxes it is necessary to call "make" by typing "/usr/bin/make" afterwards.

On current ubuntu boxes another trick is necessary:
glibc_2.6.1 fails to build since it is unable to generate the necessary locales until you type in the following line:
sudo sysctl -w vm.mmap_min_addr=0
Note that this temporarily disables a new security vulnerability check that has entered /etc/sysctrl - but that makes problems with loads of applications.
To re-enable this check do the following:
sudo sysctl -w vm.mmap_min_addr=65536
See the talk page of this article for more details on this solution.

===Known MokoMakefile errors ===

===Fixes for distribution/environment-specific or isolated issues===

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

==Tips==
*Make sure umask is set to 0022 before you run "make setup"

*You can reduce the amount of consumed disk space significantly by adding
INHERIT += "rm_work"
in your local.conf (e.g. ~/moko/build/conf/local.conf). This will remove the contents of each build/tmp/work/*/<package> directory after the corresponding package builds correctly. As of 10/16/07, this appears to be present in local.conf by default.

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

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

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

* I have some problem with the parallel building, mkfs.jffs failed to build the image because the directory was modify while the building of the fs. [[User:Patrick.hetu|patrick.hetu]] 02:19, 27 May 2008 (UTC)

* If you encounter an error related with the qemu-native package and not compiling for the qemu, you can edit the build/conf/local.conf file and add ENABLE_BINARY_LOCALE_GENERATION = "0" line to avoid the error.

* To prevent building tons of locales, add a line like this to local.conf:
GLIBC_GENERATE_LOCALES = "en_US.UTF-8 nl_NL.UTF-8"

* To not build any binary locales at all, add this to local.conf:
ENABLE_BINARY_LOCALE_GENERATION = "0"

* If you want to rebuild the package indexes (for instance, after compiling a new version of a package) without building <code>openmoko-devel-image</code>, run <code>make build-package-package-index</code>.

[[User:Wurp]] will update this to be a little more comprehensible, but maybe it can help someone as-is in the meantime:
* If MokoMakefile always fails on some fetch in zlib, just find the binary somewhere, add it to the downloads or sources directory manually (create the .md5 matching file if necessary), and retry.

=== Useful commands ===
Here is the list (not complete) of useful MokoMakefile commands (actually make targets) and a short description of each one. These should be run inside $OMDIR directory.

; make openmoko-devel-image : build the full development image

; make openmoko-devel-tools : build statically-linked [[dfu-util]] and [[openocd]] binaries

; make openmoko-toolchain : builds [[toolchain]]

; make qemu : builds qemu, downloads flash images from official repository, flashes qemu emulated Neo1973 and runs emulator (see also [[Openmoko under QEMU]]).

; make qemu-local : same as ''make qemu'', but uses locally built images instead of official ones.

; make run-qemu : runs qemu with usb keyboard ''(note: qemu must first be built!)''. This target starts the emulator with some predefined set of options. If you need to start it with other options (enable telnet, etc), see [[QEMU_command_line]].

; make build-package-<package name> : buids ''<package name>'' package

; make update-makefile : updates MokoMakefile

; make clean-package-<foo>: cleans the "<foo>" package

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

; make update : to update the Openmoko repository checkout and the MokoMakefile patches to the latest version

==Developing with MokoMakefile==

{{note|If using MokoMakefile with OM2007.2 then references to $OMDIR/openmoko should be replaced with $OMDIR/openembedded. Also references to tmp/work/armv4t-linux should be replaced with tmp/work/fic-gta01-angstrom-linux-gnueabi}}

For the following explanations $OMDIR is the directory where there Makefile puts all the stuff.

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

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

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

To build the changes and have them used by qemu:

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

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

cd $OMDIR/build
. ../setup-env
bitbake -c unpack openmoko-messages
cd tmp/work/armv4t-linux/openmoko-messages-0.0.1+svnnow-r2_2276/openmoko-messages/
''...make the changes...''
cd -
bitbake openmoko-messages

Then continue with MokoMakefile usage.

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

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

inherit autotools

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

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

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

Now run
quilt refresh
cd ..
make update openmoko-devel-image

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

=== Hello World application ===

There is a [[Building a hello world application|Hello World!]] tutorial available too.

==Testimonials==
MokoMakefile is recommended by 4 out of 4 new developers on #openmoko, with testimonials such as "For some reason last night I couldn't get my manual install of everything to work (bb complained about my bbpath I think) ... but with your makefile, it works great!", "MokoMakefile rocks!", "Wow this build system is nice - it just seems more polished than my gumstix toolchain buildroot system", and "make openmoko-devel-image :) - no magic there".

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

[[Category:Openmoko]]
[[Category:Applications]]
[[Category:Application Developer]]

MokoMakefile

2008-07-17T17:29:40Z

Peterpall: /* Known MokoMakefile errors */

{{Languages|MokoMakefile}}

MokoMakefile is a Makefile which saves lots of work when setting up an Openmoko build environment.
By automating the setup process of a new Openmoko build environment, it provides an environment which is configured the same for all the existing developers and should therefore be preferred over manual procedures or individual setup procedures.
It brings the same repeatability to build environment creation and maintenance as that which the BitBake scripts bring to [[OpenEmbedded]] ease and standardize the process of building OpenEmbedded.

Unlike the manual process described at [[Building Openmoko from scratch]], MokoMakefile does not install anything into your system (it can and should be started as normal user).
MokoMakefile is a wrapper around all that is required to make it easy to set up and maintain a development environment that fully complies with the setup instructions published by Openmoko.

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

The MokoMakefile is able to build both OM-2007.2 and QTopia-X11 images.

MokoMakefile also builds the QEMU-based Neo1973 emulator as part of the build process and has make targets to install the Openmoko images into it and run it. These commands can also be used without downloading and building the whole Openmoko OpenEmbedded distribution. This part is described in [[Using QEMU with MokoMakefile]].

== Requirements for building Openmoko ==
Independent on whether MokoMakefile or a manual process is used to setup an Openmoko build environment, there are several requirements which must be fulfilled in order for the Openmoko build to succeed:

* RAM: The build host needs to have at least 512MB of RAM, and about the same amount of swap. Some packages built by OpenEmbedded like busybox are built by compiling all source files into one binary which causes gcc to grow beyond 300MB of size and no part of this memory may be on swap for the compile to finish in predictable time. For busybox, this can be turned off, but turning this off means that busybox will not as well optimized by gcc.

* Disk space: You need about 12 GB of available disk space for the Openmoko build to succeed (see below for a tip on how to reduce this).

* Time: The initial build takes at least 5 hours (on 2GHz core2duo without multiprocessor optimization) and may take several days on slower machines.

=== Required software ===

Some distribution specific hints on preparing your build host for building OpenEmbedded are on http://wiki.openembedded.net/index.php/OEandYourDistro but they may be outdated, incomplete and do not cover everything which Openmoko needs to build.

A good guide is [[Building Openmoko from scratch#Build host prerequisites|the section on build host prerequisites]] in [[Building Openmoko from scratch]]

If you forgot anything which OE needs itself, OE will tell you shortly after you start building, but it does not check build dependencies of Openmoko, so you either have to install them before starting or install them after the build failed. OpenEmbedded will continue where it stopped when you restart the build afterwards.

==== Package requirements by distribution ====
Your distribution needs to provide these commands in order for OpenEmbedded to start building:
subversion texi2html texinfo help2man

Openmoko needs the development packages (with header files, development libraries and tools) in order to finish building:
ncurses zlib (or libz) OpenSSL GTK++

Because there are bugs in the interaction of QEMU and GCC-4, you'll need a copy of gcc-3.x installed as well.

===== Debian / Ubuntu =====
apt-get install subversion build-essential help2man diffstat texi2html texinfo cvs gawk cogito

apt-get install libncurses5-dev zlib1g-dev libssl-dev libgtk2.0-dev
# To prevent errors in host validation
apt-get install ca-certificates
# For Openmoko 2007.2 using BitBake-1.8.8:
apt-get install python-pysqlite2 sqlite3 sqlite3-doc python-pysqlite2-dbg
# For building faster
apt-get install quilt python-psyco ccache
# For qemu, install a second compiler for bug avoidance; MokoMakefile knows to look for it.
apt-get install gcc-3.4 g++-3.4 libsdl1.2-dev lynx netpbm dosfstools

# On Ubuntu 8.04, the following was required instead of cogito:
apt-get install git-core

===== SuSE =====
For building Openmoko on 10.3, you need
gcc-c++ ncurses-devel zlib-devel libopenssl-devel gtk2-devel subversion diffstat texinfo help2man
For MokoMakefile to not fail on compiling qemu-user, you need to use gcc33:
wget download.opensuse.org/repositories/devel:/tools:/gcc/openSUSE_Factory/i586/{cpp,gcc}33-3.3.3-41.8.i586.rpm
rpm -Uhv {cpp,gcc}33-3.3.3-41.8.i586.rpm

See also the [[Talk:MokoMakefile#Building_on_SuSE_Linux_10.3-AMD64|Talk page on Building on SuSE Linux 10.3-AMD64]]

10.1 and 10.2: same packages as 10.3, but install <code>openssl-devel</code> instead of libopenssl-devel.

==== For all distributions ====
As the QEMU-based neo1973 emulator is also built as part of the build process started by MokoMakefile, so you need gcc-3.3 and other packages for building QEMU installed. See [[Using QEMU with MokoMakefile#Build requirements|the build requirements section]] in [[Using QEMU with MokoMakefile]] for information on the required software.

If you are having problems compiling QEMU and do not need it, you can disable building of QEMU by adding following line to build/conf/local.conf file:
ENABLE_BINARY_LOCALE_GENERATION = "0"

===== Proxy =====
Users behind a proxy should ensure that their proxy is configured in their wgetrc file as the http_proxy environment variable is unset by MokoMakefile.

== Building Openmoko with MokoMakefile ==

=== Preparations ===
Create your $OMDIR directory (note that you can change ~/moko to any directory you like. If you have your ~moko dir mounted from a different file system, be sure to edit /etc/mtab to add the 'exec' permission to the file system, else bitbake will fail with error messages stating that /usr/bin/env is an invalid interpreter):
mkdir ~/moko ; cd ~/moko

=== MokoMakefile ===
Grab MokoMakefile:
wget http://www.rwhitby.net/files/openmoko/Makefile

If that doesn't work, try

wget http://svn.projects.openmoko.org/svnroot/mokomakefile/trunk/Makefile

{{note|MokoMakefile uses BitBake 1.8.8 which requires python-sqlite2 and sqlite-3.3 or later. Users of SUSE Linux 10.1 can update to [http://download.opensuse.org/pub/opensuse/distribution/10.2/repo/oss/suse/i586/sqlite-3.3.8-14.i586.rpm the version of openSUSE 10.2]}}

=== Environment ===
Set up the environment:

make setup

If you want to make the ASU or FSO instead of the OM2007.2, see [[Distributions]], you need to edit your Makefile. Change OM_GIT_BRANCH to one of the following:
OM_GIT_BRANCH := org.openmoko.dev # OM2007.2
OM_GIT_BRANCH := org.openmoko.asu.dev # ASU
OM_GIT_BRANCH := org.openmoko.asu.stable # ASU stable
OM_GIT_BRANCH := org.openembedded.dev # FSO

=== Buiding ===
Before starting a lengthy make process, check the Tips section below for how to make Make multicore aware. You may want to modify the build/conf/local.conf file for your target (emulation/chroot) environment:
make openmoko-devel-image
(or use "make openmoko-qtopia-x11-image" if you're building the ASU)
(or use "make fso-image" if you're building the FSO)

''Hint:'' The images build with this command can be found under {$OMDIR}/build/tmp/deploy/images/neo1973

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

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

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

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

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

3 - To update the Openmoko repository checkout and the MokoMakefile patches to the latest version:
make update

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

==Build issues==
First, make sure that the problem is reproducible after running

make update-makefile && make setup && make update

then run

make clean-package-<foo>

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

and finally

make openmoko-devel-image

With luck - you should now have images in your $omdir/build/tmp/deploy/glibc/images/neo1973/ directory.
You can then [[Flashing openmoko||flash these.]]

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

If you have chronic build problems, cleaning your environment variables and re-running the build from scratch may help. The following script should remove all non-essential variables; you should also manually trim your path to the minimum.
`env | grep -Ev '^SHELL=|^TERM=|^OLDPWD=|^USER=|^USERNAME=|^PATH=|^EDITOR=|^LANG=|^HOME=|^DISPLAY=|^_=' | sed 's/^$.*$=.*/unset \1/'`

(you must include the backtics).
Note that on some boxes it is necessary to call "make" by typing "/usr/bin/make" afterwards.

On current ubuntu boxes another trick is necessary:
glibc_2.6.1 fails to build since it is unable to generate the necessary locales until you type in the following line:
sudo sysctl -w vm.mmap_min_addr=0
Note that this temporarily disables a new security vulnerability check that has entered /etc/sysctrl - but that makes problems with loads of applications.
To re-enable this check do the following:
sudo sysctl -w vm.mmap_min_addr=65536
See the talk page of this article for more details on this solution.

===Known MokoMakefile errors ===

===Fixes for distribution/environment-specific or isolated issues===

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

==Tips==
*Make sure umask is set to 0022 before you run "make setup"

*You can reduce the amount of consumed disk space significantly by adding
INHERIT += "rm_work"
in your local.conf (e.g. ~/moko/build/conf/local.conf). This will remove the contents of each build/tmp/work/*/<package> directory after the corresponding package builds correctly. As of 10/16/07, this appears to be present in local.conf by default.

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

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

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

* I have some problem with the parallel building, mkfs.jffs failed to build the image because the directory was modify while the building of the fs. [[User:Patrick.hetu|patrick.hetu]] 02:19, 27 May 2008 (UTC)

* If you encounter an error related with the qemu-native package and not compiling for the qemu, you can edit the build/conf/local.conf file and add ENABLE_BINARY_LOCALE_GENERATION = "0" line to avoid the error.

* To prevent building tons of locales, add a line like this to local.conf:
GLIBC_GENERATE_LOCALES = "en_US.UTF-8 nl_NL.UTF-8"

* To not build any binary locales at all, add this to local.conf:
ENABLE_BINARY_LOCALE_GENERATION = "0"

* If you want to rebuild the package indexes (for instance, after compiling a new version of a package) without building <code>openmoko-devel-image</code>, run <code>make build-package-package-index</code>.

[[User:Wurp]] will update this to be a little more comprehensible, but maybe it can help someone as-is in the meantime:
* If MokoMakefile always fails on some fetch in zlib, just find the binary somewhere, add it to the downloads or sources directory manually (create the .md5 matching file if necessary), and retry.

=== Useful commands ===
Here is the list (not complete) of useful MokoMakefile commands (actually make targets) and a short description of each one. These should be run inside $OMDIR directory.

; make openmoko-devel-image : build the full development image

; make openmoko-devel-tools : build statically-linked [[dfu-util]] and [[openocd]] binaries

; make openmoko-toolchain : builds [[toolchain]]

; make qemu : builds qemu, downloads flash images from official repository, flashes qemu emulated Neo1973 and runs emulator (see also [[Openmoko under QEMU]]).

; make qemu-local : same as ''make qemu'', but uses locally built images instead of official ones.

; make run-qemu : runs qemu with usb keyboard ''(note: qemu must first be built!)''. This target starts the emulator with some predefined set of options. If you need to start it with other options (enable telnet, etc), see [[QEMU_command_line]].

; make build-package-<package name> : buids ''<package name>'' package

; make update-makefile : updates MokoMakefile

; make clean-package-<foo>: cleans the "<foo>" package

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

; make update : to update the Openmoko repository checkout and the MokoMakefile patches to the latest version

==Developing with MokoMakefile==

{{note|If using MokoMakefile with OM2007.2 then references to $OMDIR/openmoko should be replaced with $OMDIR/openembedded. Also references to tmp/work/armv4t-linux should be replaced with tmp/work/fic-gta01-angstrom-linux-gnueabi}}

For the following explanations $OMDIR is the directory where there Makefile puts all the stuff.

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

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

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

To build the changes and have them used by qemu:

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

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

cd $OMDIR/build
. ../setup-env
bitbake -c unpack openmoko-messages
cd tmp/work/armv4t-linux/openmoko-messages-0.0.1+svnnow-r2_2276/openmoko-messages/
''...make the changes...''
cd -
bitbake openmoko-messages

Then continue with MokoMakefile usage.

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

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

inherit autotools

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

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

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

Now run
quilt refresh
cd ..
make update openmoko-devel-image

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

=== Hello World application ===

There is a [[Building a hello world application|Hello World!]] tutorial available too.

==Testimonials==
MokoMakefile is recommended by 4 out of 4 new developers on #openmoko, with testimonials such as "For some reason last night I couldn't get my manual install of everything to work (bb complained about my bbpath I think) ... but with your makefile, it works great!", "MokoMakefile rocks!", "Wow this build system is nice - it just seems more polished than my gumstix toolchain buildroot system", and "make openmoko-devel-image :) - no magic there".

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

[[Category:Openmoko]]
[[Category:Applications]]
[[Category:Application Developer]]

MokoMakefile

2008-07-17T17:29:08Z

Peterpall: /* Build issues */

{{Languages|MokoMakefile}}

MokoMakefile is a Makefile which saves lots of work when setting up an Openmoko build environment.
By automating the setup process of a new Openmoko build environment, it provides an environment which is configured the same for all the existing developers and should therefore be preferred over manual procedures or individual setup procedures.
It brings the same repeatability to build environment creation and maintenance as that which the BitBake scripts bring to [[OpenEmbedded]] ease and standardize the process of building OpenEmbedded.

Unlike the manual process described at [[Building Openmoko from scratch]], MokoMakefile does not install anything into your system (it can and should be started as normal user).
MokoMakefile is a wrapper around all that is required to make it easy to set up and maintain a development environment that fully complies with the setup instructions published by Openmoko.

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

The MokoMakefile is able to build both OM-2007.2 and QTopia-X11 images.

MokoMakefile also builds the QEMU-based Neo1973 emulator as part of the build process and has make targets to install the Openmoko images into it and run it. These commands can also be used without downloading and building the whole Openmoko OpenEmbedded distribution. This part is described in [[Using QEMU with MokoMakefile]].

== Requirements for building Openmoko ==
Independent on whether MokoMakefile or a manual process is used to setup an Openmoko build environment, there are several requirements which must be fulfilled in order for the Openmoko build to succeed:

* RAM: The build host needs to have at least 512MB of RAM, and about the same amount of swap. Some packages built by OpenEmbedded like busybox are built by compiling all source files into one binary which causes gcc to grow beyond 300MB of size and no part of this memory may be on swap for the compile to finish in predictable time. For busybox, this can be turned off, but turning this off means that busybox will not as well optimized by gcc.

* Disk space: You need about 12 GB of available disk space for the Openmoko build to succeed (see below for a tip on how to reduce this).

* Time: The initial build takes at least 5 hours (on 2GHz core2duo without multiprocessor optimization) and may take several days on slower machines.

=== Required software ===

Some distribution specific hints on preparing your build host for building OpenEmbedded are on http://wiki.openembedded.net/index.php/OEandYourDistro but they may be outdated, incomplete and do not cover everything which Openmoko needs to build.

A good guide is [[Building Openmoko from scratch#Build host prerequisites|the section on build host prerequisites]] in [[Building Openmoko from scratch]]

If you forgot anything which OE needs itself, OE will tell you shortly after you start building, but it does not check build dependencies of Openmoko, so you either have to install them before starting or install them after the build failed. OpenEmbedded will continue where it stopped when you restart the build afterwards.

==== Package requirements by distribution ====
Your distribution needs to provide these commands in order for OpenEmbedded to start building:
subversion texi2html texinfo help2man

Openmoko needs the development packages (with header files, development libraries and tools) in order to finish building:
ncurses zlib (or libz) OpenSSL GTK++

Because there are bugs in the interaction of QEMU and GCC-4, you'll need a copy of gcc-3.x installed as well.

===== Debian / Ubuntu =====
apt-get install subversion build-essential help2man diffstat texi2html texinfo cvs gawk cogito

apt-get install libncurses5-dev zlib1g-dev libssl-dev libgtk2.0-dev
# To prevent errors in host validation
apt-get install ca-certificates
# For Openmoko 2007.2 using BitBake-1.8.8:
apt-get install python-pysqlite2 sqlite3 sqlite3-doc python-pysqlite2-dbg
# For building faster
apt-get install quilt python-psyco ccache
# For qemu, install a second compiler for bug avoidance; MokoMakefile knows to look for it.
apt-get install gcc-3.4 g++-3.4 libsdl1.2-dev lynx netpbm dosfstools

# On Ubuntu 8.04, the following was required instead of cogito:
apt-get install git-core

===== SuSE =====
For building Openmoko on 10.3, you need
gcc-c++ ncurses-devel zlib-devel libopenssl-devel gtk2-devel subversion diffstat texinfo help2man
For MokoMakefile to not fail on compiling qemu-user, you need to use gcc33:
wget download.opensuse.org/repositories/devel:/tools:/gcc/openSUSE_Factory/i586/{cpp,gcc}33-3.3.3-41.8.i586.rpm
rpm -Uhv {cpp,gcc}33-3.3.3-41.8.i586.rpm

See also the [[Talk:MokoMakefile#Building_on_SuSE_Linux_10.3-AMD64|Talk page on Building on SuSE Linux 10.3-AMD64]]

10.1 and 10.2: same packages as 10.3, but install <code>openssl-devel</code> instead of libopenssl-devel.

==== For all distributions ====
As the QEMU-based neo1973 emulator is also built as part of the build process started by MokoMakefile, so you need gcc-3.3 and other packages for building QEMU installed. See [[Using QEMU with MokoMakefile#Build requirements|the build requirements section]] in [[Using QEMU with MokoMakefile]] for information on the required software.

If you are having problems compiling QEMU and do not need it, you can disable building of QEMU by adding following line to build/conf/local.conf file:
ENABLE_BINARY_LOCALE_GENERATION = "0"

===== Proxy =====
Users behind a proxy should ensure that their proxy is configured in their wgetrc file as the http_proxy environment variable is unset by MokoMakefile.

== Building Openmoko with MokoMakefile ==

=== Preparations ===
Create your $OMDIR directory (note that you can change ~/moko to any directory you like. If you have your ~moko dir mounted from a different file system, be sure to edit /etc/mtab to add the 'exec' permission to the file system, else bitbake will fail with error messages stating that /usr/bin/env is an invalid interpreter):
mkdir ~/moko ; cd ~/moko

=== MokoMakefile ===
Grab MokoMakefile:
wget http://www.rwhitby.net/files/openmoko/Makefile

If that doesn't work, try

wget http://svn.projects.openmoko.org/svnroot/mokomakefile/trunk/Makefile

{{note|MokoMakefile uses BitBake 1.8.8 which requires python-sqlite2 and sqlite-3.3 or later. Users of SUSE Linux 10.1 can update to [http://download.opensuse.org/pub/opensuse/distribution/10.2/repo/oss/suse/i586/sqlite-3.3.8-14.i586.rpm the version of openSUSE 10.2]}}

=== Environment ===
Set up the environment:

make setup

If you want to make the ASU or FSO instead of the OM2007.2, see [[Distributions]], you need to edit your Makefile. Change OM_GIT_BRANCH to one of the following:
OM_GIT_BRANCH := org.openmoko.dev # OM2007.2
OM_GIT_BRANCH := org.openmoko.asu.dev # ASU
OM_GIT_BRANCH := org.openmoko.asu.stable # ASU stable
OM_GIT_BRANCH := org.openembedded.dev # FSO

=== Buiding ===
Before starting a lengthy make process, check the Tips section below for how to make Make multicore aware. You may want to modify the build/conf/local.conf file for your target (emulation/chroot) environment:
make openmoko-devel-image
(or use "make openmoko-qtopia-x11-image" if you're building the ASU)
(or use "make fso-image" if you're building the FSO)

''Hint:'' The images build with this command can be found under {$OMDIR}/build/tmp/deploy/images/neo1973

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

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

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

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

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

3 - To update the Openmoko repository checkout and the MokoMakefile patches to the latest version:
make update

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

==Build issues==
First, make sure that the problem is reproducible after running

make update-makefile && make setup && make update

then run

make clean-package-<foo>

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

and finally

make openmoko-devel-image

With luck - you should now have images in your $omdir/build/tmp/deploy/glibc/images/neo1973/ directory.
You can then [[Flashing openmoko||flash these.]]

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

If you have chronic build problems, cleaning your environment variables and re-running the build from scratch may help. The following script should remove all non-essential variables; you should also manually trim your path to the minimum.
`env | grep -Ev '^SHELL=|^TERM=|^OLDPWD=|^USER=|^USERNAME=|^PATH=|^EDITOR=|^LANG=|^HOME=|^DISPLAY=|^_=' | sed 's/^$.*$=.*/unset \1/'`

(you must include the backtics).
Note that on some boxes it is necessary to call "make" by typing "/usr/bin/make" afterwards.

On current ubuntu boxes another trick is necessary:
glibc_2.6.1 fails to build since it is unable to generate the necessary locales until you type in the following line:
sudo sysctl -w vm.mmap_min_addr=0
Note that this temporarily disables a new security vulnerability check that has entered /etc/sysctrl - but that makes problems with loads of applications.
To re-enable this check do the following:
sudo sysctl -w vm.mmap_min_addr=65536
See the talk page of this article for more details on this solution.

===Known MokoMakefile errors ===

===Fixes for distribution/environment-specific or isolated issues===>

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

==Tips==
*Make sure umask is set to 0022 before you run "make setup"

*You can reduce the amount of consumed disk space significantly by adding
INHERIT += "rm_work"
in your local.conf (e.g. ~/moko/build/conf/local.conf). This will remove the contents of each build/tmp/work/*/<package> directory after the corresponding package builds correctly. As of 10/16/07, this appears to be present in local.conf by default.

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

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

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

* I have some problem with the parallel building, mkfs.jffs failed to build the image because the directory was modify while the building of the fs. [[User:Patrick.hetu|patrick.hetu]] 02:19, 27 May 2008 (UTC)

* If you encounter an error related with the qemu-native package and not compiling for the qemu, you can edit the build/conf/local.conf file and add ENABLE_BINARY_LOCALE_GENERATION = "0" line to avoid the error.

* To prevent building tons of locales, add a line like this to local.conf:
GLIBC_GENERATE_LOCALES = "en_US.UTF-8 nl_NL.UTF-8"

* To not build any binary locales at all, add this to local.conf:
ENABLE_BINARY_LOCALE_GENERATION = "0"

* If you want to rebuild the package indexes (for instance, after compiling a new version of a package) without building <code>openmoko-devel-image</code>, run <code>make build-package-package-index</code>.

[[User:Wurp]] will update this to be a little more comprehensible, but maybe it can help someone as-is in the meantime:
* If MokoMakefile always fails on some fetch in zlib, just find the binary somewhere, add it to the downloads or sources directory manually (create the .md5 matching file if necessary), and retry.

=== Useful commands ===
Here is the list (not complete) of useful MokoMakefile commands (actually make targets) and a short description of each one. These should be run inside $OMDIR directory.

; make openmoko-devel-image : build the full development image

; make openmoko-devel-tools : build statically-linked [[dfu-util]] and [[openocd]] binaries

; make openmoko-toolchain : builds [[toolchain]]

; make qemu : builds qemu, downloads flash images from official repository, flashes qemu emulated Neo1973 and runs emulator (see also [[Openmoko under QEMU]]).

; make qemu-local : same as ''make qemu'', but uses locally built images instead of official ones.

; make run-qemu : runs qemu with usb keyboard ''(note: qemu must first be built!)''. This target starts the emulator with some predefined set of options. If you need to start it with other options (enable telnet, etc), see [[QEMU_command_line]].

; make build-package-<package name> : buids ''<package name>'' package

; make update-makefile : updates MokoMakefile

; make clean-package-<foo>: cleans the "<foo>" package

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

; make update : to update the Openmoko repository checkout and the MokoMakefile patches to the latest version

==Developing with MokoMakefile==

{{note|If using MokoMakefile with OM2007.2 then references to $OMDIR/openmoko should be replaced with $OMDIR/openembedded. Also references to tmp/work/armv4t-linux should be replaced with tmp/work/fic-gta01-angstrom-linux-gnueabi}}

For the following explanations $OMDIR is the directory where there Makefile puts all the stuff.

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

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

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

To build the changes and have them used by qemu:

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

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

cd $OMDIR/build
. ../setup-env
bitbake -c unpack openmoko-messages
cd tmp/work/armv4t-linux/openmoko-messages-0.0.1+svnnow-r2_2276/openmoko-messages/
''...make the changes...''
cd -
bitbake openmoko-messages

Then continue with MokoMakefile usage.

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

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

inherit autotools

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

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

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

Now run
quilt refresh
cd ..
make update openmoko-devel-image

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

=== Hello World application ===

There is a [[Building a hello world application|Hello World!]] tutorial available too.

==Testimonials==
MokoMakefile is recommended by 4 out of 4 new developers on #openmoko, with testimonials such as "For some reason last night I couldn't get my manual install of everything to work (bb complained about my bbpath I think) ... but with your makefile, it works great!", "MokoMakefile rocks!", "Wow this build system is nice - it just seems more polished than my gumstix toolchain buildroot system", and "make openmoko-devel-image :) - no magic there".

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

[[Category:Openmoko]]
[[Category:Applications]]
[[Category:Application Developer]]

U-Boot

2008-07-15T04:53:06Z

Peterpall: /* Flashing your Freerunner with the newest u-boot binary */

{{Languages|Bootloader}}

{{Bootloader}}
[[Image:GTA01-U-Boot.JPG|thumb|300px|u-boot menu on Neo1973]] [[Image:Neo1973 uboot splash closeup.jpg|thumb|300px|u-boot splash screen on Neo1973]]

The bootloader on the [[Neo1973]], '''U-Boot''', takes care of device functionality until [[Openmoko]] is booted. This includes [[USB DFU]] for [[flashing Openmoko]], a splash screen, a boot menu, a console for [[bootloader commands]], configuration via [[bootloader environment]], and loading a [[kernel]].

There are various [[bootloader versions]] available.

== Phase0 Quick Start ==
* Make sure that your phone has had the battery and USB cable removed for at least 30 seconds.
* Connect the Neo (ie not Debug Board) to a Linux host with the USB cable.
* Hold in the AUX button on power-up to access the boot menu.
* Set the console to USB.
* Connect to /dev/ttyACM0 with a terminal program on the Linux host (you might need to chown uucp.uucp /dev/ttyACM0 )
* Note that the cdc_acm /dev/ttyACM0 access disappears as soon as the Neo boots, and is replaced by the cdc_ether usb0 network access.
* You're now at the bootloader prompt.
* Set the bootdelay uboot environment variable to -1 if you want it to always halt at the bootloader on power-up.

== General ==

The GTA01 uses the [http://u-boot.sourceforge.net/ u-boot] bootloader.

More information on u-boot can be found at
* http://www.denx.de/wiki/DULG
* http://www.gumstix.org/tikiwiki/tiki-index.php?page=U-Boot
* http://linuxdevices.com/articles/AT5085702347.html

Additions to the vanilla u-boot already implemented include:
* Support for boot from NAND flash using [[S3C2410 Steppingstone]]
* Support for S3C2410 NAND flash
* Support for downloading programs via S3C2410 USB Device Controller
* Support to display bootup logo / status on S3C2410 Framebuffer

However, u-boot still doesn't support many of the features that GTA01 needs, such as
* Support for reading kernel/initrd from SD/Transflash

[[User:HaraldWelte|HaraldWelte]] is working on those issues, and in fact most of them have already been implemented.

== Bootloader source code ==

The current bootloader patches can be found at http://svn.openmoko.org/trunk/src/target/u-boot/patches/.

Untar the sources, apply the patch, run "make gta01bv3_config" (or gta01bv2_config, or whatever hardware revision you have), run "make". You will get a resulting "u-boot.bin" image, which you can directly flash (either using existing bootloader or [[sjf2410-linux]]) into NAND.

== Bootloader binary ==

The latest bootloader binary builds can be found under http://buildhost.openmoko.org/snapshots in the subdirectory 200X.XX/images/. It should be written to the NAND flash address 0x00000000 (size 0x30000) (the first [[partition]]).

== Bootloader development ==

=== QT2410 ===
If you want to do bootloader development on the QT2410, it's easier to work with a bootloader image that can be downloaded via USB into RAM instead of flashing.

To do so, you need to edit the u-boot/include/configs/qt2410.h file, and change the "if 0" in Line 32 into a "if 1", then recompile with "make".

The resulting "u-boot.bin" is _NOT SUITABLE_ for NAND flash, but only for direct execution from within ram, e.g. by using the [[s3c2410_boot_usb]] program.

=== GTA01 ===

Doing bootloader development on the GTA01 is a bit more tricky. first, we don't have any NOR flash. Second, there is no other way to boot _but_ from NAND. Therefore, we also don't have a USB downloader like the QT2410.

The main problem is: The [[S3C2410 Steppingstone]] unconditionally copies the first 4k of flash into its internal SRAM. That SRAM segment stays unconditionally mapped at physical address zero. How do we get around this

=== GTA02 ===

The first block holds a little 4KByte RAM buffer that is auto-filled
from NAND by CPU hardware, called "steppingstone" when we boot from
NAND, or the NOR is mapped in there.

nCS0: 00000000 07FFFFFF 4K steppingstone or NOR (Aux held down) 
nCS1: 08000000 0FFFFFFF Glamo 
nCS2: 10000000 17FFFFFF nothing mapped 
nCS3: 18000000 1FFFFFFF NOR 
nCS4: 20000000 17FFFFFF nothing mapped 
nCS5: 28000000 2FFFFFFF nothing mapped 
nCS6: 30000000 37FFFFFF on-MCP SDRAM 128MB 
nCS7: 38000000 3FFFFFFF external SDRAM 128MB 

==== Using JTAG to boot from RAM ====

So how can we boot from RAM? We use JTAG / OpenOCD to

* Reset and halt the cpu at PC=0
<pre>
> reset halt
target halted in ARM state due to debug request, current mode: Supervisor
cpsr: 0x400000d3 pc: 0x00000000
MMU: disabled, D-Cache: disabled, I-Cache: disabled
</pre>

* Download a small piece of code for low-level SDRAM timing initialization (overwrite 4k SRAM of steppingstone)
<pre>
> load_binary /space/misc/gta01/u-boot.git/board/gta01/lowlevel_foo.bin 0
downloaded 332 byte in 0s 21899us
</pre>

* Assert a break point at address 0x33f80000 (which indicates that the low-level code has finished)
<pre>
> bp 0x33f80000 4 hw
breakpoint added at address 0x33f80000
</pre>

* Run the code up to the break point
<pre>
> resume
Target 0 resumed
> Target 0 halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x600000d3 pc: 0x33f80000
MMU: disabled, D-Cache: disabled, I-Cache: enabled
</pre>

* Download the u-boot RAM image to 0x33f80000
<pre>
> load_binary /space/misc/gta01/u-boot.git/u-boot.bin 0x33f80000
downloaded 135692 byte in 6s 567264us
</pre>

* Resume processing
<pre>
> resume
Target 0 resumed
</pre>

At this point, the display backlight gets bright and we see the following familiar prompt on the serial console:
<pre>
U-Boot 1.1.6 (Jan 13 2007 - 23:44:23)

DRAM: 128 MB
NAND: 64 MiB
*** Warning - bad CRC or NAND, using default environment

In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
GTA01Bv2 #
</pre>

== Creating bootable images ==

u-boot needs bootable images (such as kernels, but also initrd and others) in form of a so-called ''uImage''. In order to create a ''uImage'' from e.g. a ''vmlinux'' kernel image, you can proceed as follows:

<pre>
objcopy -O binary -R .note -R .comment -S vmlinux linux.bin
gzip -9 linux.bin
u-boot/tools/mkimage -A arm -O linux -T kernel -C gzip -a 30008000 -e 30008000 -n "Kernel Image QT2410" -d linux.bin.gz uImage
</pre>

== Boot menu ==
[[Image:Neo1973 uboot menu.jpg|thumb|400px|u-boot boot menu on Neo1973]]

As of the Phase-0 release, our u-boot version now features an on-screen boot menu. The items are defined by [[bootloader environment#menu|menu entries in the environment]].

=== Accessing the boot menu ===

You can access the boot menu by pressing and holding the [[Neo1973 AUX Button]] together with the power button while switching the phone on.

=== Using the boot menu ===

By pressing the [[Neo1973 AUX Button]] you can cycle through the menu items. Use the ''POWER'' button to select one item.

== Bootloader prompt ==

=== Accessing the bootloader prompt ===
The bootloader prompt is available either on the serial console (via [[Debug Board]]), or as virtual USB Serial device (USB CDC_ACM).
Whether the serial port or usb is used depends on the u-boot environment variables '''stdin''', '''stdout''' and '''stderr'''.

Whether or not you use usbtty, the first couple of messages will always be displayed on the serial console.

The bootloader is currently configured to wait for three seconds. If a key press on the '''stdin''' is received within those three seconds, auto-boot is aborted.

==== Using usbtty from Linux ====

Just by connecting the phone in u-boot mode to your Linux pc should make it detect a [[CDC ACM]] device, and you should get a new tty device called /dev/ttyACM0. If not, enable the CONFIG_USB_ACM (Device Drivers -> USB support -> USB Modem (CDC ACM) support). (Instructions for MacOS users are [[MacOS_X#USB_Serial|here]])

Use your favourite terminal emulator (minicom, cu, zc, screen ...) to access it like any other serial port. If you don't have a favorite, try just: (cu is in the taylor-uucp package, use "apt-get install cu" if it is not yet installed)
cu -l /dev/ttyACM0

You might need to
chown uucp.uucp /dev/ttyACM0

to get the necessary right (even as root).

A nice alternative for cu is Werner Almesberger's [[NeoCon|neocon]].

First, you should try to check whether the USB device shows up in 'lsusb' while you're running in u-boot mode:

# lsusb -d 1457:5119
Bus 005 Device 079: ID 1457:5119

Second, lets see some more details about the available endpoints and configurations:

<pre>
# lsusb -v -d 1457:5119
Bus 005 Device 079: ID 1457:5119
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 16
idVendor 0x1457
idProduct 0x5119
bcdDevice 0.00
iManufacturer 1 OpenMoko, Inc
iProduct 2 Neo1973 Bootloader U-Boot 1.2.0-g6c7cac8c-dirty-moko3
iSerial 3 0000000
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 85
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 4 TTY via USB
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 6 Control Interface
CDC Header:
bcdCDC 0.6e
CDC Call Management:
bmCapabilities 0x00
bDataInterface 1
CDC ACM:
bmCapabilities 0x00
CDC Union:
bMasterInterface 0
bSlaveInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 255
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 5 Bulk Data Interface
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 255
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 255
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 254 Application Specific Interface
bInterfaceSubClass 1 Device Firmware Update
bInterfaceProtocol 1
iInterface 7 USB Device Firmware Upgrade
Device Status: 0x0001
Self Powered
</pre>

Next, you can access it using your favourite terminal program.

Then, if the environment is not set correctly, you will need to use the current console (e.g. serial console) to change the [[bootloader environment#console|console entries in the environment]]:
<pre>
GTA01Bv2 # setenv stderr usbtty
GTA01Bv2 # setenv stdout usbtty
GTA01Bv2 # setenv stdin usbtty
</pre>

==== Typical u-boot prompt ====

<pre>
U-Boot 1.2.0-moko1 (Feb 16 2007 - 00:36:13)

DRAM: 128 MB
NAND: 64 MiB
Found Environment offset in OOB..
Video: 640x480x8 31kHz 59Hz
USB: S3C2410 USB Deviced
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
GTA01Bv3 #
</pre>

=== Commands on the bootloader prompt ===

:''See [[bootloader commands]].''

== Device Firmware Upgrade ==

Our version of u-boot also implements [[USB DFU]]. This can be useful to
load files and kernel for quick testing.

To find out whether your version of u-boot supports this, use the output of
$ lsusb -v -d 1457:5119
while the phone is in u-boot mode.

If it supports DFU, you should see the following snippet towards the end of the output:
<pre>
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 254 Application Specific Interface
bInterfaceSubClass 1 Device Firmware Update
bInterfaceProtocol 1
iInterface 0
</pre>

For information on how to do firmware upgrades, please see [[dfu-util]].

=== Booting files over DFU ===

To load a file at memory address 0x32000000:
<pre>
dfu-util -a 0 -D fileToLoad -R
</pre>

After that, send 'bootm 0x32000000' to u-boot or 'bootelf 0x32000000' if
its an elf file.

Simple python script that can boot an ELF image - avoiding a ACM bug that breaks on large packets.

<pre>
#!/usr/bin/python
import sys
import os
import time

cmd1 = "neo backlight off\n"
cmd2 = "bootelf 0x32000000\n"

def output(tty, str):
for x in str:
tty.write(x)
tty.flush()

if len(sys.argv) == 2:
print "Loading %s..." % sys.argv[1]

loadfile = "dfu-util -a 0 -D %s -R" % sys.argv[1]

os.system(loadfile)

time.sleep(3)

tty = open("/dev/ttyACM0", "a")

output(tty, cmd1)
output(tty, cmd2)

tty.close()
else:
print "Usage: %s elffile" % sys.argv[0]
print ""
sys.exit(2)
</pre>

== Troubleshooting ==

=== USB connectivity problems ===

I once got errors like this (in dmesg or /var/log/messages) on the host side while connecting the neo in u-boot:

usb 2-1: device descriptor read/64, error -110
usb usb2: Controller not stopped yet!

The problem disappeared at least for me by the command below on the host side. Please note that if you have usb keyboard or mouse then the command might cause trouble.. I only have PS/2 so I couldn't test it.

rmmod uhci_hcd ; modprobe uhci_hcd

=== Flashing your Freerunner with the newest u-boot binary ===
This is simple - even if I find it somehow scary to flash the bootloader of a device. Don't be too scared, though: Unlike any other device I know the Freerunner contains a second bootloader on a write protected chip - that is still there, even if flashing the original bootloader goes horribly wrong. You can always make the phone use this bootloader instead by pressing the power button whilst pressing the Aux button. In theory it should therefore be impossible to brick your phone completely enough by flashing the bootloader that a debug board is needed to unbrick it.
* Download the newest uBoot binary from http://downloads.openmoko.org/releases/Freerunner/
* start the cellular phone by pressing power whilst pressing the aux button.
* Run the following command:
dfu-util -a u-boot -R -D uboot-gta02v5-latest.bin
* The device is now flashed:
dfu-util - (C) 2007 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

Opening USB Device 0x0000:0x0000...
Claiming USB DFU Runtime Interface...
Determining device status: state = appIDLE, status = 0
Device really in Runtime Mode, send DFU detach request...
Resetting USB...
Opening USB Device...
Found Runtime: [0x1d50:0x5119] devnum=9, cfg=0, intf=0, alt=1, name="u-boot"
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x1000
bytes_per_hash=4316
Starting download: [##################################################] finished!
state(2) = dfuIDLE, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode
* The last message (status(0)) tells us everything just worked fine - at the next boot the device will be started by the newest uboot loader.

[[Category:System Developers]]
[[Category:Flashing Openmoko]]

Snapshot review/2008-07-12

2008-07-15T04:48:47Z

Peterpall: Did

===Snapshot History and Overview===
Latest reviewed image: [[Snapshot_review/2008-07-12]]

Latest Recommended image: [[Snapshot_review/2008-04-21]]

Link to all [[:Category:SnapshotReview|previous snapshot reviews]].

The latest kernel and root image recommended in these reviews will always be available [http://downloads.openmoko.org/recommended/ here]

===Openmoko Snapshot Review Criteria===

Date: 2008-07-12

Rootfs Snapshot name:
Openmoko-openmoko-devel-image-glibc-ipk-P1-Snapshot-20080712-om-gta02.rootfs.jffs2

Kernel snapshot name:
uImage-2.6.24+git20080424-om-gta02.bin

uBoot Snapshot name:
u-boot-gta02v5-1.3.1+svnr4297+gitb29661fc1151077776454288051bc9a488351ce8-r3.bin

Device type:
Freerunner (GTA02v5)

==Boot==
*Speed - (No measured test.)
*Error Messages - (No measured test.)
*Failures - (No measured test.)

==Phone Functionality==

'''Incoming Calls'''

# Can receive - Yes
# Kinetic alert (vibrate) - Yes
# Auditory alert (sound) - Yes
# Call quality - Fine. The annoying echo heard by the caller has gone, even if was reproducible with the firmware from April 24 using the same phone. (Tested twice with both firmwares.)
# Missed calls display on OM-today2 - Yes
# Calls recorded in call log - Yes
# Stability - The phone sometimes seems to abort calls after a few minutes. Calling again immediately afterwards works, though.

'''Outgoing Calls'''
# Can make - Yes
# Call quality - Yes
# Calls recorded in call log - Yes
# Stability - The phone sometimes seems to abort calls after a few minutes. Calling again immediately afterwards works, though.

==Messaging Functionality==
'''Incoming SMS'''
# Can receive - Yes
# Kinetic alert (vibrate) - Yes
# Auditory Altert (sound) - Yes
# Sender identified if applicable - Yes
# Is message readable - Yes
# OM today2 displays new messages - Yes
# Communication logged - Yes
# Stability - Incoming SMS messages aren't matched against Contact list if entered using local format. [http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1345 Bug #1345 Reported]

'''Outgoing SMS'''
# Can send - Yes
# Message readable - Yes
# Delivery notification works - (No measured test.)
# Communication logged - Yes
# Stability - Good

==Person Information Management==
'''Contacts'''
# Can add - Yes
# Can create groups - Yes
# Can modify - Yes

'''Calendar'''
# Can add events - Yes
# Can view events - Yes
# Can remove events - Yes
# Events appear on openmoko-today2 - Yes
# Events trigger kinetic alarm - Yes
# Events trigger auditory alarm - Yes

==Media Player==
'''Music'''
# Mp3 - Yes; Can even seek now.
# Vorbis - Yes; Can even seek now.

'''Video'''
# Theora Playback - (No measured test.)
# Theora Pause - (No measured test.)

==GPS==
- Can turn on - Yes
- Can turn off - Yes

==Bluetooth==
# Can turn Bluetooth on - (No measured test.)
# Can turn Bluetooth off - (No measured test.)

==Battery Life==
About 8 hours with heavy use (The 1st days with my phone...) - which was to be expected since the device was virtually never in suspend mode (see the Suspend section.)

==Software Keyboard==
# Keyboard type - Multi-tap
# Displays correctly - Yes
# Usability - Poor: Multi-tap input's lack of CTRL keys harms terminal use. But at least predictive. It is easy to install a better keyboard, though using opkg.

==Suspend==
# Suspend / Resume works: Many times fails to suspend; Sometimes won't resume again.
# All features work after suspend / resume cycle: If the phone does come up again, Yes
# Can receive incoming calls or sms while in suspend: Yes

==User Feedback==
Please provide feedback on how to improve these reviews. Also, please identify yourself when making changes.

[[category:SnapshotReview]]

Talk:Booting the Neo FreeRunner from SD via U-Boot

2008-07-13T09:17:34Z

Peterpall: /* = Booting the Freerunner from a SD card */

== Booting the Freerunner from a SD card ==
My Freerunner came with a "boot from SD card" option already installed in uBoot. I just needed a SD (Not HDMC) card with the following layout:
* Partition 1 is a primary partition with a FAT filesystem containing the uImage - which has to be named uImage.bin
* Partiton 2 is a Filesystem containing the root partition. According to the uBoot environment it should be an ext2 partiton, - but it seems like the standrd kernels from the buildhost don't support this. Will try to change the uBoot environemt variable so I can boot from ext3 - which should be supported by the kernel one day.
My hardware setup is:
* Latest uBoot (July 12, 2008)
* Freerunner (GTA02V5, 1st batch that could be regularily ordered from the openmoko online shop.)
The uBoot environment variable that should allow booting from my card reads:
menu_1=Boot from microSD (FAT+ext2): setenv bootargs ${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 ${mtdparts} ro; mmcinit; fatload mmc 1 0x32000000 ${sd_image_name}; bootm 0x32000000
As far as I know it should be changed after logging into uBoot by
setenv menu_1 Boot from microSD (FAT+ext3): setenv bootargs ${bootargs_base} root=/dev/mmcblk0p2 rootdelay=5 ${mtdparts}ro\; mmcinit\; fatload mmc 1 0x32000000 ${sd_image_name}\; bootm 0x32000000
if we want to boot a stock kernel from sd card.

But I have not been able to test it until now, though.

Talk:Booting the Neo FreeRunner from SD via U-Boot

2008-07-13T09:17:10Z

Peterpall:

== Booting the Freerunner from a SD card =
My Freerunner came with a "boot from SD card" option already installed in uBoot. I just needed a SD (Not HDMC) card with the following layout:
* Partition 1 is a primary partition with a FAT filesystem containing the uImage - which has to be named uImage.bin
* Partiton 2 is a Filesystem containing the root partition. According to the uBoot environment it should be an ext2 partiton, - but it seems like the standrd kernels from the buildhost don't support this. Will try to change the uBoot environemt variable so I can boot from ext3 - which should be supported by the kernel one day.
My hardware setup is:
* Latest uBoot (July 12, 2008)
* Freerunner (GTA02V5, 1st batch that could be regularily ordered from the openmoko online shop.)
The uBoot environment variable that should allow booting from my card reads:
menu_1=Boot from microSD (FAT+ext2): setenv bootargs ${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 ${mtdparts} ro; mmcinit; fatload mmc 1 0x32000000 ${sd_image_name}; bootm 0x32000000
As far as I know it should be changed after logging into uBoot by
setenv menu_1 Boot from microSD (FAT+ext3): setenv bootargs ${bootargs_base} root=/dev/mmcblk0p2 rootdelay=5 ${mtdparts}ro\; mmcinit\; fatload mmc 1 0x32000000 ${sd_image_name}\; bootm 0x32000000
if we want to boot a stock kernel from sd card.

But I have not been able to test it until now, though.

Talk:Booting the Neo FreeRunner from SD via U-Boot

2008-07-13T09:01:01Z

Peterpall:

= Simpler way of booting from a SD card =
My freerunner came with a "boot from SD card" option already installed in uBoot. I just needed a SD (Not HDMC) card with the following layout:
* Partition 1 is a primary partition with a FAT filesystem containing the uImage - which has to be named uImage.bin
* Partiton 2 is a Filesystem containing the root partition. According to the uBoot environment it should be an ext2 partiton, - but it seems like the standrd kernels from the buildhost don't support this. Will try to change the uBoot environemt variable so I can boot from ext3 - which should be supported by the kernel one day.
My hardware setup is:
* Latest uBoot (July 12, 2008)
* Freerunner (GTA02V5, 1st batch that could be regularily ordered from the openmoko online shop.)
The uBoot environment variable that should allow booting from my card reads:
menu_1=Boot from microSD (FAT+ext2): setenv bootargs ${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 ${mtdparts} ro; mmcinit; fatload mmc 1 0x32000000 ${sd_image_name}; bootm 0x32000000

Talk:Booting the Neo FreeRunner from SD via U-Boot

2008-07-13T08:50:07Z

Peterpall:

= Simpler way of booting from a SD card =
My freerunner came with a "boot from SD card" option already installed in uBoot. I just needed a SD (Not HDMC) card with the following layout:
* Partition 1 is a primary partition with a FAT filesystem containing the uImage - which has to be named uImage.bin
* Partiton 2 is a Filesystem containing the root partition. According to the uBoot environment it should be an ext2 partiton, - but it seems like the standrd kernels from the buildhost don't support this.
My hardware setup is:
* Latest uBoot (July 12, 2008)
* Freerunner (GTA02V5)
The uBoot environment variable reads:
menu_1=Boot from microSD (FAT+ext2): setenv bootargs ${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 ${mtdparts} ro; mmcinit; fatload mmc 1 0x32000000 ${sd_image_name}; bootm 0x32000000

Talk:Booting the Neo FreeRunner from SD via U-Boot

2008-07-12T10:55:42Z

Peterpall: /* Needed a different partition layout for my SD card */

Talk:Booting the Neo FreeRunner from SD via U-Boot

2008-07-12T08:14:27Z

Peterpall: /* Neede a different partition layout */

= Needed a different partition layout for my SD card =
I needed a SD (Not HDMC) card and needed the following layout:
* Partition 1 is a primary partition with a FAT filesystem containing the uImage
* Partiton 2 is a Ext3 Filesystem containing the root filesystem. Since the uImage from this partition is never used - it is not really important keeping it up-to-date.

My hardware setup is:
* Latest uBoot (July 12, 2008)
* Freerunner (GTA02V5)

U-Boot

2008-07-12T06:16:27Z

Peterpall: /* Flashing your Freerunner with the newest u-boot binary */

{{Languages|Bootloader}}

{{Bootloader}}
[[Image:GTA01-U-Boot.JPG|thumb|300px|u-boot menu on Neo1973]] [[Image:Neo1973 uboot splash closeup.jpg|thumb|300px|u-boot splash screen on Neo1973]]

The bootloader on the [[Neo1973]], '''U-Boot''', takes care of device functionality until [[Openmoko]] is booted. This includes [[USB DFU]] for [[flashing Openmoko]], a splash screen, a boot menu, a console for [[bootloader commands]], configuration via [[bootloader environment]], and loading a [[kernel]].

There are various [[bootloader versions]] available.

== Phase0 Quick Start ==
* Make sure that your phone has had the battery and USB cable removed for at least 30 seconds.
* Connect the Neo (ie not Debug Board) to a Linux host with the USB cable.
* Hold in the AUX button on power-up to access the boot menu.
* Set the console to USB.
* Connect to /dev/ttyACM0 with a terminal program on the Linux host (you might need to chown uucp.uucp /dev/ttyACM0 )
* Note that the cdc_acm /dev/ttyACM0 access disappears as soon as the Neo boots, and is replaced by the cdc_ether usb0 network access.
* You're now at the bootloader prompt.
* Set the bootdelay uboot environment variable to -1 if you want it to always halt at the bootloader on power-up.

== General ==

The GTA01 uses the [http://u-boot.sourceforge.net/ u-boot] bootloader.

More information on u-boot can be found at
* http://www.denx.de/wiki/DULG
* http://www.gumstix.org/tikiwiki/tiki-index.php?page=U-Boot
* http://linuxdevices.com/articles/AT5085702347.html

Additions to the vanilla u-boot already implemented include:
* Support for boot from NAND flash using [[S3C2410 Steppingstone]]
* Support for S3C2410 NAND flash
* Support for downloading programs via S3C2410 USB Device Controller
* Support to display bootup logo / status on S3C2410 Framebuffer

However, u-boot still doesn't support many of the features that GTA01 needs, such as
* Support for reading kernel/initrd from SD/Transflash

[[User:HaraldWelte|HaraldWelte]] is working on those issues, and in fact most of them have already been implemented.

== Bootloader source code ==

The current bootloader patches can be found at http://svn.openmoko.org/trunk/src/target/u-boot/patches/.

Untar the sources, apply the patch, run "make gta01bv3_config" (or gta01bv2_config, or whatever hardware revision you have), run "make". You will get a resulting "u-boot.bin" image, which you can directly flash (either using existing bootloader or [[sjf2410-linux]]) into NAND.

== Bootloader binary ==

The latest bootloader binary builds can be found under http://buildhost.openmoko.org/snapshots in the subdirectory 200X.XX/images/. It should be written to the NAND flash address 0x00000000 (size 0x30000) (the first [[partition]]).

== Bootloader development ==

=== QT2410 ===
If you want to do bootloader development on the QT2410, it's easier to work with a bootloader image that can be downloaded via USB into RAM instead of flashing.

To do so, you need to edit the u-boot/include/configs/qt2410.h file, and change the "if 0" in Line 32 into a "if 1", then recompile with "make".

The resulting "u-boot.bin" is _NOT SUITABLE_ for NAND flash, but only for direct execution from within ram, e.g. by using the [[s3c2410_boot_usb]] program.

=== GTA01 ===

Doing bootloader development on the GTA01 is a bit more tricky. first, we don't have any NOR flash. Second, there is no other way to boot _but_ from NAND. Therefore, we also don't have a USB downloader like the QT2410.

The main problem is: The [[S3C2410 Steppingstone]] unconditionally copies the first 4k of flash into its internal SRAM. That SRAM segment stays unconditionally mapped at physical address zero. How do we get around this

=== GTA02 ===

The first block holds a little 4KByte RAM buffer that is auto-filled
from NAND by CPU hardware, called "steppingstone" when we boot from
NAND, or the NOR is mapped in there.

nCS0: 00000000 07FFFFFF 4K steppingstone or NOR (Aux held down) 
nCS1: 08000000 0FFFFFFF Glamo 
nCS2: 10000000 17FFFFFF nothing mapped 
nCS3: 18000000 1FFFFFFF NOR 
nCS4: 20000000 17FFFFFF nothing mapped 
nCS5: 28000000 2FFFFFFF nothing mapped 
nCS6: 30000000 37FFFFFF on-MCP SDRAM 128MB 
nCS7: 38000000 3FFFFFFF external SDRAM 128MB 

==== Using JTAG to boot from RAM ====

So how can we boot from RAM? We use JTAG / OpenOCD to

* Reset and halt the cpu at PC=0
<pre>
> reset halt
target halted in ARM state due to debug request, current mode: Supervisor
cpsr: 0x400000d3 pc: 0x00000000
MMU: disabled, D-Cache: disabled, I-Cache: disabled
</pre>

* Download a small piece of code for low-level SDRAM timing initialization (overwrite 4k SRAM of steppingstone)
<pre>
> load_binary /space/misc/gta01/u-boot.git/board/gta01/lowlevel_foo.bin 0
downloaded 332 byte in 0s 21899us
</pre>

* Assert a break point at address 0x33f80000 (which indicates that the low-level code has finished)
<pre>
> bp 0x33f80000 4 hw
breakpoint added at address 0x33f80000
</pre>

* Run the code up to the break point
<pre>
> resume
Target 0 resumed
> Target 0 halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x600000d3 pc: 0x33f80000
MMU: disabled, D-Cache: disabled, I-Cache: enabled
</pre>

* Download the u-boot RAM image to 0x33f80000
<pre>
> load_binary /space/misc/gta01/u-boot.git/u-boot.bin 0x33f80000
downloaded 135692 byte in 6s 567264us
</pre>

* Resume processing
<pre>
> resume
Target 0 resumed
</pre>

At this point, the display backlight gets bright and we see the following familiar prompt on the serial console:
<pre>
U-Boot 1.1.6 (Jan 13 2007 - 23:44:23)

DRAM: 128 MB
NAND: 64 MiB
*** Warning - bad CRC or NAND, using default environment

In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
GTA01Bv2 #
</pre>

== Creating bootable images ==

u-boot needs bootable images (such as kernels, but also initrd and others) in form of a so-called ''uImage''. In order to create a ''uImage'' from e.g. a ''vmlinux'' kernel image, you can proceed as follows:

<pre>
objcopy -O binary -R .note -R .comment -S vmlinux linux.bin
gzip -9 linux.bin
u-boot/tools/mkimage -A arm -O linux -T kernel -C gzip -a 30008000 -e 30008000 -n "Kernel Image QT2410" -d linux.bin.gz uImage
</pre>

== Boot menu ==
[[Image:Neo1973 uboot menu.jpg|thumb|400px|u-boot boot menu on Neo1973]]

As of the Phase-0 release, our u-boot version now features an on-screen boot menu. The items are defined by [[bootloader environment#menu|menu entries in the environment]].

=== Accessing the boot menu ===

You can access the boot menu by pressing and holding the [[Neo1973 AUX Button]] together with the power button while switching the phone on.

=== Using the boot menu ===

By pressing the [[Neo1973 AUX Button]] you can cycle through the menu items. Use the ''POWER'' button to select one item.

== Bootloader prompt ==

=== Accessing the bootloader prompt ===
The bootloader prompt is available either on the serial console (via [[Debug Board]]), or as virtual USB Serial device (USB CDC_ACM).
Whether the serial port or usb is used depends on the u-boot environment variables '''stdin''', '''stdout''' and '''stderr'''.

Whether or not you use usbtty, the first couple of messages will always be displayed on the serial console.

The bootloader is currently configured to wait for three seconds. If a key press on the '''stdin''' is received within those three seconds, auto-boot is aborted.

==== Using usbtty from Linux ====

Just by connecting the phone in u-boot mode to your Linux pc should make it detect a [[CDC ACM]] device, and you should get a new tty device called /dev/ttyACM0. If not, enable the CONFIG_USB_ACM (Device Drivers -> USB support -> USB Modem (CDC ACM) support). (Instructions for MacOS users are [[MacOS_X#USB_Serial|here]])

Use your favourite terminal emulator (minicom, cu, zc, screen ...) to access it like any other serial port. If you don't have a favorite, try just: (cu is in the taylor-uucp package, use "apt-get install cu" if it is not yet installed)
cu -l /dev/ttyACM0

You might need to
chown uucp.uucp /dev/ttyACM0

to get the necessary right (even as root).

A nice alternative for cu is Werner Almesberger's [[NeoCon|neocon]].

First, you should try to check whether the USB device shows up in 'lsusb' while you're running in u-boot mode:

# lsusb -d 1457:5119
Bus 005 Device 079: ID 1457:5119

Second, lets see some more details about the available endpoints and configurations:

<pre>
# lsusb -v -d 1457:5119
Bus 005 Device 079: ID 1457:5119
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 16
idVendor 0x1457
idProduct 0x5119
bcdDevice 0.00
iManufacturer 1 OpenMoko, Inc
iProduct 2 Neo1973 Bootloader U-Boot 1.2.0-g6c7cac8c-dirty-moko3
iSerial 3 0000000
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 85
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 4 TTY via USB
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 6 Control Interface
CDC Header:
bcdCDC 0.6e
CDC Call Management:
bmCapabilities 0x00
bDataInterface 1
CDC ACM:
bmCapabilities 0x00
CDC Union:
bMasterInterface 0
bSlaveInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 255
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 5 Bulk Data Interface
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 255
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 255
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 254 Application Specific Interface
bInterfaceSubClass 1 Device Firmware Update
bInterfaceProtocol 1
iInterface 7 USB Device Firmware Upgrade
Device Status: 0x0001
Self Powered
</pre>

Next, you can access it using your favourite terminal program.

Then, if the environment is not set correctly, you will need to use the current console (e.g. serial console) to change the [[bootloader environment#console|console entries in the environment]]:
<pre>
GTA01Bv2 # setenv stderr usbtty
GTA01Bv2 # setenv stdout usbtty
GTA01Bv2 # setenv stdin usbtty
</pre>

==== Typical u-boot prompt ====

<pre>
U-Boot 1.2.0-moko1 (Feb 16 2007 - 00:36:13)

DRAM: 128 MB
NAND: 64 MiB
Found Environment offset in OOB..
Video: 640x480x8 31kHz 59Hz
USB: S3C2410 USB Deviced
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
GTA01Bv3 #
</pre>

=== Commands on the bootloader prompt ===

:''See [[bootloader commands]].''

== Device Firmware Upgrade ==

Our version of u-boot also implements [[USB DFU]]. This can be useful to
load files and kernel for quick testing.

To find out whether your version of u-boot supports this, use the output of
$ lsusb -v -d 1457:5119
while the phone is in u-boot mode.

If it supports DFU, you should see the following snippet towards the end of the output:
<pre>
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 254 Application Specific Interface
bInterfaceSubClass 1 Device Firmware Update
bInterfaceProtocol 1
iInterface 0
</pre>

For information on how to do firmware upgrades, please see [[dfu-util]].

=== Booting files over DFU ===

To load a file at memory address 0x32000000:
<pre>
dfu-util -a 0 -D fileToLoad -R
</pre>

After that, send 'bootm 0x32000000' to u-boot or 'bootelf 0x32000000' if
its an elf file.

Simple python script that can boot an ELF image - avoiding a ACM bug that breaks on large packets.

<pre>
#!/usr/bin/python
import sys
import os
import time

cmd1 = "neo backlight off\n"
cmd2 = "bootelf 0x32000000\n"

def output(tty, str):
for x in str:
tty.write(x)
tty.flush()

if len(sys.argv) == 2:
print "Loading %s..." % sys.argv[1]

loadfile = "dfu-util -a 0 -D %s -R" % sys.argv[1]

os.system(loadfile)

time.sleep(3)

tty = open("/dev/ttyACM0", "a")

output(tty, cmd1)
output(tty, cmd2)

tty.close()
else:
print "Usage: %s elffile" % sys.argv[0]
print ""
sys.exit(2)
</pre>

== Troubleshooting ==

=== USB connectivity problems ===

I once got errors like this (in dmesg or /var/log/messages) on the host side while connecting the neo in u-boot:

usb 2-1: device descriptor read/64, error -110
usb usb2: Controller not stopped yet!

The problem disappeared at least for me by the command below on the host side. Please note that if you have usb keyboard or mouse then the command might cause trouble.. I only have PS/2 so I couldn't test it.

rmmod uhci_hcd ; modprobe uhci_hcd

=== Flashing your Freerunner with the newest u-boot binary ===
This is simple - even if I find it somehow scary to flash the bootloader of a device.
* Download the newest uBoot binary from http://downloads.openmoko.org/releases/Freerunner/
* start the cellular phone by pressing power whilst pressing the aux button.
* Run the following command:
dfu-util -a u-boot -R -D uboot-gta02v5-latest.bin
* The device is now flashed:
dfu-util - (C) 2007 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

Opening USB Device 0x0000:0x0000...
Claiming USB DFU Runtime Interface...
Determining device status: state = appIDLE, status = 0
Device really in Runtime Mode, send DFU detach request...
Resetting USB...
Opening USB Device...
Found Runtime: [0x1d50:0x5119] devnum=9, cfg=0, intf=0, alt=1, name="u-boot"
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x1000
bytes_per_hash=4316
Starting download: [##################################################] finished!
state(2) = dfuIDLE, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode
* The last message (status(0)) tells us everything just worked fine - at the next boot the device will be started by the newest uboot loader.
[[Category:Software (non openmoko)]]
[[Category:Kernel]]
[[Category:Guides]]

U-Boot

2008-07-12T06:12:19Z

Peterpall: /* USB connectivity problems */

{{Languages|Bootloader}}

{{Bootloader}}
[[Image:GTA01-U-Boot.JPG|thumb|300px|u-boot menu on Neo1973]] [[Image:Neo1973 uboot splash closeup.jpg|thumb|300px|u-boot splash screen on Neo1973]]

The bootloader on the [[Neo1973]], '''U-Boot''', takes care of device functionality until [[Openmoko]] is booted. This includes [[USB DFU]] for [[flashing Openmoko]], a splash screen, a boot menu, a console for [[bootloader commands]], configuration via [[bootloader environment]], and loading a [[kernel]].

There are various [[bootloader versions]] available.

== Phase0 Quick Start ==
* Make sure that your phone has had the battery and USB cable removed for at least 30 seconds.
* Connect the Neo (ie not Debug Board) to a Linux host with the USB cable.
* Hold in the AUX button on power-up to access the boot menu.
* Set the console to USB.
* Connect to /dev/ttyACM0 with a terminal program on the Linux host (you might need to chown uucp.uucp /dev/ttyACM0 )
* Note that the cdc_acm /dev/ttyACM0 access disappears as soon as the Neo boots, and is replaced by the cdc_ether usb0 network access.
* You're now at the bootloader prompt.
* Set the bootdelay uboot environment variable to -1 if you want it to always halt at the bootloader on power-up.

== General ==

The GTA01 uses the [http://u-boot.sourceforge.net/ u-boot] bootloader.

More information on u-boot can be found at
* http://www.denx.de/wiki/DULG
* http://www.gumstix.org/tikiwiki/tiki-index.php?page=U-Boot
* http://linuxdevices.com/articles/AT5085702347.html

Additions to the vanilla u-boot already implemented include:
* Support for boot from NAND flash using [[S3C2410 Steppingstone]]
* Support for S3C2410 NAND flash
* Support for downloading programs via S3C2410 USB Device Controller
* Support to display bootup logo / status on S3C2410 Framebuffer

However, u-boot still doesn't support many of the features that GTA01 needs, such as
* Support for reading kernel/initrd from SD/Transflash

[[User:HaraldWelte|HaraldWelte]] is working on those issues, and in fact most of them have already been implemented.

== Bootloader source code ==

The current bootloader patches can be found at http://svn.openmoko.org/trunk/src/target/u-boot/patches/.

Untar the sources, apply the patch, run "make gta01bv3_config" (or gta01bv2_config, or whatever hardware revision you have), run "make". You will get a resulting "u-boot.bin" image, which you can directly flash (either using existing bootloader or [[sjf2410-linux]]) into NAND.

== Bootloader binary ==

The latest bootloader binary builds can be found under http://buildhost.openmoko.org/snapshots in the subdirectory 200X.XX/images/. It should be written to the NAND flash address 0x00000000 (size 0x30000) (the first [[partition]]).

== Bootloader development ==

=== QT2410 ===
If you want to do bootloader development on the QT2410, it's easier to work with a bootloader image that can be downloaded via USB into RAM instead of flashing.

To do so, you need to edit the u-boot/include/configs/qt2410.h file, and change the "if 0" in Line 32 into a "if 1", then recompile with "make".

The resulting "u-boot.bin" is _NOT SUITABLE_ for NAND flash, but only for direct execution from within ram, e.g. by using the [[s3c2410_boot_usb]] program.

=== GTA01 ===

Doing bootloader development on the GTA01 is a bit more tricky. first, we don't have any NOR flash. Second, there is no other way to boot _but_ from NAND. Therefore, we also don't have a USB downloader like the QT2410.

The main problem is: The [[S3C2410 Steppingstone]] unconditionally copies the first 4k of flash into its internal SRAM. That SRAM segment stays unconditionally mapped at physical address zero. How do we get around this

=== GTA02 ===

The first block holds a little 4KByte RAM buffer that is auto-filled
from NAND by CPU hardware, called "steppingstone" when we boot from
NAND, or the NOR is mapped in there.

nCS0: 00000000 07FFFFFF 4K steppingstone or NOR (Aux held down) 
nCS1: 08000000 0FFFFFFF Glamo 
nCS2: 10000000 17FFFFFF nothing mapped 
nCS3: 18000000 1FFFFFFF NOR 
nCS4: 20000000 17FFFFFF nothing mapped 
nCS5: 28000000 2FFFFFFF nothing mapped 
nCS6: 30000000 37FFFFFF on-MCP SDRAM 128MB 
nCS7: 38000000 3FFFFFFF external SDRAM 128MB 

==== Using JTAG to boot from RAM ====

So how can we boot from RAM? We use JTAG / OpenOCD to

* Reset and halt the cpu at PC=0
<pre>
> reset halt
target halted in ARM state due to debug request, current mode: Supervisor
cpsr: 0x400000d3 pc: 0x00000000
MMU: disabled, D-Cache: disabled, I-Cache: disabled
</pre>

* Download a small piece of code for low-level SDRAM timing initialization (overwrite 4k SRAM of steppingstone)
<pre>
> load_binary /space/misc/gta01/u-boot.git/board/gta01/lowlevel_foo.bin 0
downloaded 332 byte in 0s 21899us
</pre>

* Assert a break point at address 0x33f80000 (which indicates that the low-level code has finished)
<pre>
> bp 0x33f80000 4 hw
breakpoint added at address 0x33f80000
</pre>

* Run the code up to the break point
<pre>
> resume
Target 0 resumed
> Target 0 halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x600000d3 pc: 0x33f80000
MMU: disabled, D-Cache: disabled, I-Cache: enabled
</pre>

* Download the u-boot RAM image to 0x33f80000
<pre>
> load_binary /space/misc/gta01/u-boot.git/u-boot.bin 0x33f80000
downloaded 135692 byte in 6s 567264us
</pre>

* Resume processing
<pre>
> resume
Target 0 resumed
</pre>

At this point, the display backlight gets bright and we see the following familiar prompt on the serial console:
<pre>
U-Boot 1.1.6 (Jan 13 2007 - 23:44:23)

DRAM: 128 MB
NAND: 64 MiB
*** Warning - bad CRC or NAND, using default environment

In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
GTA01Bv2 #
</pre>

== Creating bootable images ==

u-boot needs bootable images (such as kernels, but also initrd and others) in form of a so-called ''uImage''. In order to create a ''uImage'' from e.g. a ''vmlinux'' kernel image, you can proceed as follows:

<pre>
objcopy -O binary -R .note -R .comment -S vmlinux linux.bin
gzip -9 linux.bin
u-boot/tools/mkimage -A arm -O linux -T kernel -C gzip -a 30008000 -e 30008000 -n "Kernel Image QT2410" -d linux.bin.gz uImage
</pre>

== Boot menu ==
[[Image:Neo1973 uboot menu.jpg|thumb|400px|u-boot boot menu on Neo1973]]

As of the Phase-0 release, our u-boot version now features an on-screen boot menu. The items are defined by [[bootloader environment#menu|menu entries in the environment]].

=== Accessing the boot menu ===

You can access the boot menu by pressing and holding the [[Neo1973 AUX Button]] together with the power button while switching the phone on.

=== Using the boot menu ===

By pressing the [[Neo1973 AUX Button]] you can cycle through the menu items. Use the ''POWER'' button to select one item.

== Bootloader prompt ==

=== Accessing the bootloader prompt ===
The bootloader prompt is available either on the serial console (via [[Debug Board]]), or as virtual USB Serial device (USB CDC_ACM).
Whether the serial port or usb is used depends on the u-boot environment variables '''stdin''', '''stdout''' and '''stderr'''.

Whether or not you use usbtty, the first couple of messages will always be displayed on the serial console.

The bootloader is currently configured to wait for three seconds. If a key press on the '''stdin''' is received within those three seconds, auto-boot is aborted.

==== Using usbtty from Linux ====

Just by connecting the phone in u-boot mode to your Linux pc should make it detect a [[CDC ACM]] device, and you should get a new tty device called /dev/ttyACM0. If not, enable the CONFIG_USB_ACM (Device Drivers -> USB support -> USB Modem (CDC ACM) support). (Instructions for MacOS users are [[MacOS_X#USB_Serial|here]])

Use your favourite terminal emulator (minicom, cu, zc, screen ...) to access it like any other serial port. If you don't have a favorite, try just: (cu is in the taylor-uucp package, use "apt-get install cu" if it is not yet installed)
cu -l /dev/ttyACM0

You might need to
chown uucp.uucp /dev/ttyACM0

to get the necessary right (even as root).

A nice alternative for cu is Werner Almesberger's [[NeoCon|neocon]].

First, you should try to check whether the USB device shows up in 'lsusb' while you're running in u-boot mode:

# lsusb -d 1457:5119
Bus 005 Device 079: ID 1457:5119

Second, lets see some more details about the available endpoints and configurations:

<pre>
# lsusb -v -d 1457:5119
Bus 005 Device 079: ID 1457:5119
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 16
idVendor 0x1457
idProduct 0x5119
bcdDevice 0.00
iManufacturer 1 OpenMoko, Inc
iProduct 2 Neo1973 Bootloader U-Boot 1.2.0-g6c7cac8c-dirty-moko3
iSerial 3 0000000
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 85
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 4 TTY via USB
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 6 Control Interface
CDC Header:
bcdCDC 0.6e
CDC Call Management:
bmCapabilities 0x00
bDataInterface 1
CDC ACM:
bmCapabilities 0x00
CDC Union:
bMasterInterface 0
bSlaveInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 255
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 5 Bulk Data Interface
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 255
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 255
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 254 Application Specific Interface
bInterfaceSubClass 1 Device Firmware Update
bInterfaceProtocol 1
iInterface 7 USB Device Firmware Upgrade
Device Status: 0x0001
Self Powered
</pre>

Next, you can access it using your favourite terminal program.

Then, if the environment is not set correctly, you will need to use the current console (e.g. serial console) to change the [[bootloader environment#console|console entries in the environment]]:
<pre>
GTA01Bv2 # setenv stderr usbtty
GTA01Bv2 # setenv stdout usbtty
GTA01Bv2 # setenv stdin usbtty
</pre>

==== Typical u-boot prompt ====

<pre>
U-Boot 1.2.0-moko1 (Feb 16 2007 - 00:36:13)

DRAM: 128 MB
NAND: 64 MiB
Found Environment offset in OOB..
Video: 640x480x8 31kHz 59Hz
USB: S3C2410 USB Deviced
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
GTA01Bv3 #
</pre>

=== Commands on the bootloader prompt ===

:''See [[bootloader commands]].''

== Device Firmware Upgrade ==

Our version of u-boot also implements [[USB DFU]]. This can be useful to
load files and kernel for quick testing.

To find out whether your version of u-boot supports this, use the output of
$ lsusb -v -d 1457:5119
while the phone is in u-boot mode.

If it supports DFU, you should see the following snippet towards the end of the output:
<pre>
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 254 Application Specific Interface
bInterfaceSubClass 1 Device Firmware Update
bInterfaceProtocol 1
iInterface 0
</pre>

For information on how to do firmware upgrades, please see [[dfu-util]].

=== Booting files over DFU ===

To load a file at memory address 0x32000000:
<pre>
dfu-util -a 0 -D fileToLoad -R
</pre>

After that, send 'bootm 0x32000000' to u-boot or 'bootelf 0x32000000' if
its an elf file.

Simple python script that can boot an ELF image - avoiding a ACM bug that breaks on large packets.

<pre>
#!/usr/bin/python
import sys
import os
import time

cmd1 = "neo backlight off\n"
cmd2 = "bootelf 0x32000000\n"

def output(tty, str):
for x in str:
tty.write(x)
tty.flush()

if len(sys.argv) == 2:
print "Loading %s..." % sys.argv[1]

loadfile = "dfu-util -a 0 -D %s -R" % sys.argv[1]

os.system(loadfile)

time.sleep(3)

tty = open("/dev/ttyACM0", "a")

output(tty, cmd1)
output(tty, cmd2)

tty.close()
else:
print "Usage: %s elffile" % sys.argv[0]
print ""
sys.exit(2)
</pre>

== Troubleshooting ==

=== USB connectivity problems ===

I once got errors like this (in dmesg or /var/log/messages) on the host side while connecting the neo in u-boot:

usb 2-1: device descriptor read/64, error -110
usb usb2: Controller not stopped yet!

The problem disappeared at least for me by the command below on the host side. Please note that if you have usb keyboard or mouse then the command might cause trouble.. I only have PS/2 so I couldn't test it.

rmmod uhci_hcd ; modprobe uhci_hcd

=== Flashing your Freerunner with the newest u-boot binary ===
This is simple - even if I find it somehow scary to flash the
- start the cellular phone by pressing power whilst pressing the aux button.
- Run the following command:
dfu-util -a u-boot -R -D uboot-gta02v5-latest.bin
- The device is now flashed:
dfu-util - (C) 2007 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

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

The last message (status(0)) tells us everything just worked fine - at the next boot the device will be started by the newest uboot loader.
[[Category:Software (non openmoko)]]
[[Category:Kernel]]
[[Category:Guides]]

Talk:MokoMakefile

2008-07-11T07:15:47Z

Peterpall: /* The lib64 issue */

== MokoMakefile won't work on Ubuntu Hardy Heron ==
Hello, there!

Since my upgrade to Hardy Heron MokoMakefile seems to be broken on my ubuntu box. I already tried several times to download a new Makefile into a fresh directory - without success. What I get is always:

:~/moko$ make image
( cd build && . ../setup-env && \
( bitbake openmoko-devel-image u-boot-openmoko ) )
ERROR: Openembedded's config sanity checker detected a potential misconfiguration.
Either fix the cause of this error or at your own risk disable the checker (see sanity.conf).
Following is the list of potential problems / advisories:

/proc/sys/vm/mmap_min_addr is not 0. This will cause problems with qemu so please fix the value (as root).

make: *** [openmoko-devel-image] Error 1

For another report on this problem see also: http://lists.openmoko.org/pipermail/community/2008-May/017545.html

When trying to compile the april software update (ASU) this error doesn't occour, though.

=== solution ===

<pre>
$ sudoedit /etc/sysctl.conf
</pre>

And add 'vm.mmap_min_addr = 0' (without quotes) to that file.

== The paths that are mentioned on this page are partially wrong ==
I am not sure enough what the paths should be, but - two things have changed since the section "developing with mokomakefile/How to add your own shiny new application" of this page was created:
- The path where the packages are kept, and
- Where to add the information that we have added a new package.

== Ubuntu Edgy: Update git-1.4.x to 1.5.x! ==
With old git-1.4.x, fetching uboot does not work: Use 1.5.x:
<pre>
NOTE: package uboot-gta01-1.2.0+svnnow-r4_14da5f7675bbb427c469e3f45006e027b6e21db9_0_1811: task do_fetch: started
fatal: corrupted pack file .git/objects/pack/pack-a146bcbc18f4826d6bf2a7f63be5dd77bbb5b2f5.pack
</pre>

== Fails on a 32bit machine - try again without ccache? ==

<pre>/bin/sh ./libtool --mode=compile ccache gcc -DHAVE_CONFIG_H -I.... -W... -O2 -c -o libbfd.lo build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17/bfd/libbfd.c
ccache gcc -DHAVE_CONFIG_H -I... -W... -O2 -c /usr/local/oe/build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17/bfd/libbfd.c -o t shift count >= width of type
make[5]: *** [libbfd.lo] Error 1
</pre>

Any insight here? --[[User:Adam|Adam]] 23:10, 15 May 2007 (CEST)
: Try without ccache (did you get it compiled meanwhile or can we remove this?) --[[User:BernhardKaindl|BernhardKaindl]] 23:05, 19 September 2007 (CEST)

== Facing Problems with ogg libraries ==
just get the path and delete the .bb file that causes the problem
== Building on Fedora Core 6 ==

Install stuff needed for OpenMoko:
# yum install python m4 make wget curl ftp cvs monotone subversion \
tar bzip2 gzip unzip python-psyco ccache perl texinfo texi2html \
diffstat openjade docbook-style-dsssl docbook-style-xsl docbook-dtds \
docbook-utils sed bison bc glibc-devel gcc binutils pcre pcre-devel git \
quilt groff linuxdoc-tools patch compat-gcc-34 lynx netpbm
(notice ''compat-gcc-34'' wich was needed for FC6 (gcc 4 installed), and ''lynx'' which is needed by ''qemu'' (no fallback to ''wget'', ''curl'', or ''links'' at the moment and no check for it, resulting in strange "sleep" errors when trying to build without ''lynx'').

Build it:
$ make setup
$ make openmoko-devel-image
$ unset LD_LIBRARY_PATH
$ make update-makefile && make update && make setup && make openmoko-devel-image

I have also done a
$ unset LD_LIBRARY_PATH; make update-makefile && nice make update && nice make setup && nice make all
(This takes several hours)

Build qemu:
$ make qemu

Run it:
# echo 1024 > /proc/sys/dev/rtc/max-user-freq
$ make run-qemu
This will bring up the OpenMoko :) Use SPACE for AUX and ENTER for POWER.
Not quite the same as holding a Neo1973 in your hands I would guess, but this is the best we can do for now. Thanks!

== Building on Ubuntu Feisty ==

MokoMakefile requires more than 512 MB of RAM + Swap space (around 1GB?).

If you need swap, please '''check that its size under Feisty is not null'''!

[https://bugs.launchpad.net/ubuntu/+bug/105490 Bug #105490] describes the current issue and offers a workaround (23 Jul 07).

== Fails trying to build bluez-utils ==
on Gentoo Linux, it fails compiling bluez-utils (I've tried also "make clean-package-bluez-utils" before the following command)

do a "make build-package-libusb; make clean-package-bluez-utils" and it should continue (the bluez-utils .bb is missing the libusb dependency)

== openSUSE 10.1 and 10.2 workarounds ==

ltrace package fails to build with error:
<pre>
...
checking for pid_t... yes
checking for getopt... yes
checking for getopt_long... yes
checking gelf.h usability... no
checking gelf.h presence... no
checking for gelf.h... no
configure: error: ***** gelf.h not found *****
FATAL: oe_runconf failed
</pre>

'''FIX: '''
edit ''/home/moko/build/tmp/work/armv4t-linux/ltrace-0.4-r0/ltrace-0.4/configure.ac''
at line 44: remove the following block:
<pre>
for path in /usr/include/elfutils /usr/local/include/elfutils \
/usr/include/libelf /usr/local/include/libelf; do
if test -f ${path}/gelf.h; then
CPPFLAGS="$CPPFLAGS -I ${path}"
fi
done
</pre>
( it adds /usr/include/elfutils to path, which causes cross-compile badness error )

=== QEMU build fails to compile USB code ===
<pre>
/usr/include/linux/usbdevice_fs.h:116: error: variable or field `__user' declared void
/usr/include/linux/usbdevice_fs.h:116: error: syntax error before '*' token
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c: In function `usb_host_handle_control':
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:103: error: invalid application of `sizeof' to incomplete type `usbdevfs_ctrltran
sfer'
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c: In function `usb_host_handle_data':
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:120: error: storage size of 'bt' isn't known
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:132: error: invalid application of `sizeof' to incomplete type `usbdevfs_bulktran
sfer'
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:120: warning: unused variable `bt'
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c: In function `usb_host_device_open':
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:199: error: storage size of 'ctrl' isn't known
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:202: error: invalid application of `sizeof' to incomplete type `usbdevfs_ioctl'
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:199: warning: unused variable `ctrl'
make[2]: *** [usb-linux.o] Error 1
</pre>

'''FIX: '''
edit ''/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c''
at line 29 add the following (before ''#include <linux/usbdevice_fs.h>'')
<pre>
#include <linux/compiler.h>
</pre>
hint: there is a copy of the file in ''/home/moko/build/tmp/work/i686-linux/qemu-native-0.9.0+cvs20070613-r5/qemu/usb-linux.c''

''see: http://osdir.com/ml/emulators.kvm.devel/2007-01/msg00101.html''

== Cannot satisfy fstests ==
<pre>
make openmoko-devel-image
...
| Collected errors:
| ERROR: Cannot satisfy the following dependencies for task-openmoko-debug:
| fstests
NOTE: Task failed: /no-backup/Moko/build/tmp/work/fic-gta01-linux/openmoko-devel-image-1.0-r0/temp/log.do_rootfs.25036
NOTE: package openmoko-devel-image-1.0-r0: task do_rootfs: failed
ERROR: TaskFailed event exception, aborting
</pre>
Failed on debian etch 2007-07-20
Solution from mailing list post from hardskinone, report of an irc chat
<pre>
I got help in IRC channel. I do following steps
* remove fstest from oe/packages/tasks/task-openmoko.bb ,
* increase PR field by one
* make openmoko-devel-image
</pre>

== conflicting types for 'futimens' ==

if you encounter the following error:

| In file included from utimecmp.c:40:
| utimens.h:2: error: conflicting types for 'futimens'
| /usr/include/sys/stat.h:370: error: previous declaration of 'futimens' was here

a patch is needed because your glibc is too new. grab & enable the patch as follows

cd openembedded/packages/coreutils
mv coreutils_5.3.0.bb coreutils_5.3.0.orig
wget http://www.openembedded.org/repo/org.openembedded.dev/packages/coreutils/coreutils_5.3.0.bb
cd -
cd openembedded/packages/coreutils/coreutils-5.3.0
wget http://www.openembedded.org/repo/org.openembedded.dev/packages/coreutils/coreutils-5.3.0/futimens.patch
cd -

== Workaround for problems compiling mtd-utils ==

Change the line on <code>openembedded/packages/mtd/mtd-utils_1.0.0+git.bb</code> which reads:

SRC_URI = "git://git.infradead.org/mtd-utils.git;protocol=git;tag=master \

to:

SRC_URI = "git://git.infradead.org/mtd-utils.git;protocol=git;tag=a6fa706fe9e7696b4b2045edf9698c3bac07e3e3 \

which forces the recipe to use an older revision (the one which worked last time I built the image on my computer).

Be sure to remember to undo the change later, or else you will not get any new changes to that package. --[[User:CesarB|CesarB]] 04:48, 25 July 2007 (CEST)

Note: these patches should be updated - the lzo patch is included in the current version, so backing off to the previous version and repatching seems silly. I was able to make it through this part of the build by applying the remaining patches manually. --[[User:Mellon|Ted Lemon]] 15:44, 29 July 2007 (CDT)

== Monotone segfaulting on Ubuntu Feisty Fawn/PPC ==
If you are running Ubuntu Feisty Fawn on a PowerPC computer you will experience problems running monotone. To fix this issue you need to install monotone as well as the libboost packages from Gutsy. The easiest way to accomplish this is to add the gutsy repositories to your sources.list
and change the preferences to look like this:

Package: *
Pin: release a=feisty
Pin-Priority: 700

Package: *
Pin: release a=gutsy
Pin-Priority: -100

Package: libc6 libc6-dev tzdata util-linux libgcc1 libstdc++6 monotone
Pin: release a=gutsy
Pin-Priority: 800

Package: libboost-*
Pin: release a=gutsy
Pin-Priority: 800

After doing this install monotone in this way:
apt-get -t gutsy install monotone.
That should install monotone 0.35 with updated (and working) boost libraries.

== Fails on ncurses install in Fedora 7 with a "tic -x" message ==
Adjust the following command to your system, then run it:
export LD_LIBRARY_PATH=/home/moko/build/tmp/work/x86_64-linux/ncurses-native-5.4-r8/ncurses-5.4/lib
Then start make again and it should pick up where it left off.

You can get a list of potential paths to use with the following command from you main moko directory:
find . | grep libncurses

The basic problem is that it is linking against your main system libraries instead of the OpenEmbedded ones.

There's probably a cleaner way of handling this - please update this entry if you know it.

This has been fixed in Openembedded, see [http://bugs.openembedded.org/show_bug.cgi?id=2554 Openembedded Bug #2554] for further details.

== uboot-gta01 fails to build ==
Changes in the GIT of U-Boot make the OpenMoko patches unapplyable. For the use of Revision ''cc3023b9f95d7ac959a764471a65001062aecf41'' and everything will be fine for now.

== Perl fails to build ==
After following every bit of advice I can find to 'make clean' and nuke the perl build directories, every build comes up with:

| make[1]: Entering directory `/src/openmoko/build/tmp/work/i686-linux/perl-native-5.8.7-r3/perl-5.8.7'
| make[1]: *** No rule to make target `<command-line>', needed by `miniperlmain.o'. Stop.
| make[1]: Leaving directory `/src/openmoko/build/tmp/work/i686-linux/perl-native-5.8.7-r3/perl-5.8.7'
| FATAL: oe_runmake failed
NOTE: Task failed: /src/openmoko/build/tmp/work/i686-linux/perl-native-5.8.7-r3/temp/log.do_compile.19531
NOTE: package perl-native-5.8.7-r3: task do_compile: failed

Solution turned out to be editing
/src/openmoko/build/tmp/work/i686-linux/perl-native-5.8.7-r3/perl-5.8.7/makedepend.SH and at line 169 change the regexp to eat references to "<command.line>" to catch what was leaking through.

== Gettext fails to build ==
Gettext's build is broken unless you have emacs installed. Crazy though it seems. You will see an error like:

<pre>

| WARNING: Warnings can be ignored. :-)
| if test "no" != no; then \
| set x; \
| list='po-mode.el po-compat.el'; for p in $list; do \
| if test -f "$p"; then d=; else d="./"; fi; \
| set x "$@" "$d$p"; shift; \
| done; \
| shift; \
| EMACS="no" /bin/bash ../../config/elisp-comp "$@" || exit 1; \
| if test "no" != no; then \
| set x; \
| list='po-mode.el po-compat.el'; for p in $list; do \
| if test -f "$p"; then d=; else d="./"; fi; \
| set x "$@" "$d$p"; shift; \
| done; \
| shift; \
| EMACS="no" /bin/bash ../../config/elisp-comp "$@" || exit 1; \
| else : ; fi
| mv: cannot move `elc-temp' to `elc-stamp': No such file or directory
| make[5]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools/misc'
| make[5]: *** [elc-stamp] Error 1
| make[5]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools/misc'
| make[4]: *** [po-mode.elc] Error 2
| make[4]: *** Waiting for unfinished jobs....
| make[4]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools/misc'
| make[3]: *** [all-recursive] Error 1
| make[3]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools'
| make[2]: *** [all] Error 2
| make[2]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools'
| make[1]: *** [all-recursive] Error 1
| make[1]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1'
| FATAL: oe_runmake failed

</pre>

The solution is simple - install emacs (example below for debian/ubuntu) and try again:

<pre>

sudo apt-get install emacs
make clean-package-gettext-native-0.14.1-r5
make openmoko-devel-image

</pre>

== Building OpenMoko with chroot ==

There may be hundreds of issues which may cause that OpenMoko fails to build on your system, so it might be more straightforward to just install a standardized build environment in which the openmoko build runs in chroot, independent of your distribution.

There is now a (not fully working) script which is able to set up a 32-bit openSUSE 10.3 build environment for building OpenMoko posted on distro-devel: [http://lists.openmoko.org/pipermail/distro-devel/2007-November/000076.html]

On gentoo and debian-like distribution, you can use debootstrap to quickly setup a base chroot.

Please note that in addition to the common /dev, /sys and /proc, /dev/shm should also be mounted with --bind option. It is at least required to build a qtopia-x11 image. (Otherwise you will get some semaphore 'function not implemented' errors at qtopia-x11 installation stage).

== Fails compiling binutils-cross on Gentoo/AMD64 and openSUSE/x86_64 ==

make setup works fine, but when running make openmoko-devel-image it fails with the following:

<pre>
| make[4]: Entering directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi/libiberty/testsuite'
| make[4]: Nothing to be done for `install'.
| make[4]: Leaving directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi/libiberty/testsuite'
| make[3]: Leaving directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi/libiberty'
| make[2]: Nothing to be done for `install-target'.
| make[2]: Leaving directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi'
| make[1]: Leaving directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi'
| rmdir: build/tmp/cross//home/techiem2/Moko/build/tmp/cross/lib/gcc-lib: No such file or directory
| rmdir: build/tmp/cross//home/techiem2/Moko/build/tmp/cross/lib: No such file or directory
| rmdir: build/tmp/cross//home/techiem2/Moko/build/tmp/cross: No such file or directory
| mv: cannot stat `build/tmp/cross/lib/libiberty.a': No such file or directory
NOTE: Task failed: build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/temp/log.do_stage.9730
NOTE: package binutils-cross-2.18-r0: task do_populate_staging: failed
ERROR: TaskFailed event exception, aborting
NOTE: package binutils-cross-2.18: failed
ERROR: Build of openembedded/packages/binutils/binutils-cross_2.18.bb do_populate_staging failed
ERROR: Task 1641 (openembedded/packages/binutils/binutils-cross_2.18.bb, do_populate_staging) failed
NOTE: Tasks Summary: Attempted 107 tasks of which 107 didn't need to be rerun and 1 failed.
ERROR: 'openembedded/packages/binutils/binutils-cross_2.18.bb' failed
make: *** [openmoko-devel-image] Error 1
</pre>

The final reason why the build cannot continue is:
mv: cannot stat `/home/techiem2/Moko/build/tmp/cross/lib/libiberty.a': No such file or directory

=== The lib64 issue ===

Likely, Gentoo/AMD64 uses lib64 instead of lib as the library directory for x86_64 libraries. It's l likey that many (or all?) AMD64 distributions do for their 64-bit binaries. On openSUSE-x86_64, the same happens. Debian/x86-64 seems to either not use lib64 or is somehow supported by the openmoko distribution.

On multilib/lib64 platforms like Gentoo/x86_64 and openSUSE-x86_64, the openmoko build runs into a final problem at the end of build: It tries to use fakeroot which uses LD_PRELOAD to fake a different root directory and in the final stages, after hours of compiling, fakeroot execution causes warning messages because on multilib/lib64 systems as they have two versions of many libraries, the 64-bit libraries are in /lib64, /usr/lib64 and oder lib64 paths, while the 32-bit libraries are in /lib, /usr/lib and other lib paths. Some tool on these lib64 distributions are adapted to install 64-bit libraries to lib64, but this seems to fail when cross-compiling.

At least on openSUSE-10.3 the missing libiberty.a was installed to build/tmp/cross/lib64/libiberty.a, which looks wrong, and it is if this libiberty.a file contains 32-bit arm objects. If it contains 64-bit x86_64 objects, it's fine, but openembedded/openmoko is not expecting it in a lib64 directory. I am not sure what is the case.

The lib64 fakeroot issue requires to change the openembedded build scripts, which is doable. But it's not very easy to find the correct script and patch it correctly. If you feel adventourus, go ahead and try to build openmoko on a lib64 distribution, but it's easyer to set up a complete 32-bit chroot environment and run a normal build in it.

After seeing this, I assumed that openmoko/openembedded was clearly not tested with lib64 build hosts and since that would mean that even if I'd fix that error, many others could follow, and as I was not interested to fix the lib64 bugs but rather wanted to see something running first, I decided to make openmoko/openembedded think that it was running on a normal 32-bit non-lib64 machine.

There are several ways to do that:
* You install an 32bit x86-Linux somewhere and use that for building:
** Do a native install and dual-boot the 32bit x86-linux (That's for dummies which do not know the other tricks)
** Install 32bit x86-Linux in a virtual machine (Takes powerful hardware and has some overhead too). Use [http://gentoo-wiki.com/VirtualBox VirtualBox], for example.
* you can install a 32-bit development system in to a chroot jail and compile there (also quite some setup and inconvinience). See [http://www.gentoo.org/proj/en/base/amd64/howtos/chroot.xml the gentoo guide]

=== Building on SuSE Linux 10.3-AMD64 with -m32 (not finished) ===

Install the following packages for the 32-bit C/C++ compiler target option -m32 to work and to compile what is needed

gcc42-32bit gcc42libgcc42-32bit glibc-devel-32bit libstdc++-devel-32bit ncurses-devel-32bit zlib-devel-32bit (maybe also gtk2-devel-32bit)

The openSUSE 10.3-AMD64 has no libopenssl-devel-32bit, but you can install the 32-bit rpm from the i586 10.3 rpm tree:

libopenssl-devel

You should also make sure that gdbm-devel is not installed.
The multilib support in ld has an issue which surfaces when it is called from perl's Configure script to complile a test program with -Lgdbm. If gdbm-devel is installed, it finds /usr/lib64/libgdbm.so, but since it's not compatible with 32-bit, it skips it, but also does not search the specified -Lpath where the OpenEmbedded-built libgdbm.so is already installed. To work around this, uninstall /usr/lib64/libgdbm.so with:
rpm -e gdbm-devel

Note these need to be the 32-bit cpp33 and gcc33 rpms as the 64-bit gcc33 rpms for openSUSE do not support the 32-bit target.

To make the OpenMoko build think that its running on 32-bit i686, use linux32 (changes uname -m to i686 in the new shell):

linux32 bash

And set up gcc scripts which force the use of gcc-3.3 (it can only generate 32-bit assembly) for all compilation:

mkdir bin;cd bin
echo '/usr/bin/${0##*/}-3.3 -m32 "$@"' >gcc
echo '/usr/bin/${0##*/} -m elf_i386 "$@"' >ld
echo '/usr/bin/${0##*/} --32 "$@"' >gas
sed -i '1i#!/bin/sh' gcc gas ld
chmod 755 gcc gas ld
ln -s gcc cc
ln -s gcc c++
ln -s gcc g++
ln -s gas as
echo PATH=\""$PWD":\$PATH\" >.setup-gcc-m32
cd -

Then set the path and test it:

source bin/.setup-gcc-m32
type gcc

== More package requirements ==

On my system (Kubuntu 6.10) build failed with message "ERROR: QEMU requires SDL or Cocoa for graphical output" because package <tt>libsdl-image1.2-dev</tt> was missing. Use <tt>apt-get install libsdl-image1.2-dev</tt> to install. Additionally I had to install packages <tt>cvs</tt> and <tt>diffstat</tt>. I was also asked to install Psyco JIT Compiler (package <tt>python-psyco</tt>) to increase performance. Nevertheless <tt>make flash-qemu-local</tt> took some hours, but now I finally can get an impression of the phone that I am looking for! -- [[User:Nichtich|Nichtich]] 00:26, 20 September 2007 (CEST)

== pango-directfb failed to build due to missing Glib 2.14.x ==

The latest(as of Sept. 25, 2007) build started to fail with the following error:

| checking for GLIB... no
| configure: error:
| *** Glib 2.14.0 or better is required. The latest version of
| *** Glib is always available from ftp://ftp.gtk.org/.
| FATAL: oe_runconf failed
NOTE: Task failed:
/media/sdc1/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/\
pango-directfb-1.18.1-r0/temp/log.do_configure.19927
NOTE: package pango-directfb-1.18.1-r0: task do_configure: failed
ERROR: TaskFailed event exception, aborting
NOTE: package pango-directfb-1.18.1: failed
ERROR: Build of /media/sdc1/moko/openembedded/packages/pango/\
pango-directfb_1.18.1.bb do_configure failed

The Glib included in the build tree seems to be only 2.12.12, so looks like something
is broken in term of dependency.

This had happened on both of Fedora 7 and Debian Etch. I am running the latest
MokoMakefile with OM-2007.2. The funny thing is that the build had worked only
couple nights ago. Any idea? I will update anything I find here and also on my blog(see my user profile).
[[User:ttz|ttz]] Wed Sep 26 12:17:33 CDT 2007

pango-directfb had been removed from OE for now due to the report of it breaking builds like OpenMoko.

[[User:ttz|ttz]] Thu Oct 4 10:20:12 CDT 2007

== uicmoc4 failes to compile ==

This is solved by installing libz-dev

Or, look at [http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=747 Bug #747]

== svn: REPORT request failed on '/repos/tasks/!svn/vcc/default' ==

osiris$ make update
...
Fetching external item into 'trunk/src/target/OM-2007.2/applications/openmoko-today2/libkoto'
svn: REPORT request failed on '/repos/tasks/!svn/vcc/default'
svn: REPORT of '/repos/tasks/!svn/vcc/default': 200 OK (http://svn.o-hand.com)
make: *** [update-openmoko] Error 1

osiris$ cd openmoko/trunk/src/target/OM-2007.2/applications/openmoko-today2//libkoto/
osiris$ svn up -r HEAD
svn: REPORT request failed on '/repos/tasks/!svn/vcc/default'
svn: REPORT of '/repos/tasks/!svn/vcc/default': 200 OK (http://svn.o-hand.com)

Anyone know about this one?
--[[User:Blackh|Blackh]] 00:11, 12 October 2007 (CEST)

== bootparam_prot.h fails to install in glibc-intermediate-2.5 package (Debian sid) ==

| install: cannot stat
`/home/blackh/src/openmoko/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/
glibc-intermediate-2.5-r7/glibc-2.5/sunrpc/rpcsvc/bootparam_prot.h'
No such file or directory
NOTE: Task failed: /home/blackh/src/openmoko/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/
glibc-intermediate-2.5-r7/temp/log.do_stage.3940

For some reason, on Debian, the rpcgen command needs "-Y /usr/bin" added to the end of it or it won't work ("cannot find any C preprocessor (cpp)"). This can be fixed by hand...

cd /home/blackh/src/openmoko/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/
glibc-intermediate-2.5-r7/glibc-2.5/sunrpc/rpcsvc
for f in *.x ; do rpcgen -h $f -o ${f%%.x}.h -Y /usr/bin ; done

This command will generate the right files and you can resume the build with

make openmoko-devel-image

Here is a better fix - put this script, calling it rpcgen, somewhere in your PATH before /usr/bin:

#!/bin/sh
exec /usr/bin/rpcgen -Y /usr/bin "$@"

--[[User:Blackh|Blackh]] 05:17, 12 October 2007 (CEST)

== Cannot find SVN openmoko-terminal2 ==
I'm having an issue when building MokoMakeFile where it is unable to find http://svn.openmoko.org/trunk/src/target/OM-2007.2/applications/openmoko-terminal2. Any ideas on how to fix this?

--[[User:cartera|cartera]]

== problem with make openmoko-devel-image ==

when i try to do my first make openmoko-devel-image I obtain this error:

<pre>
NOTE: Running task 844 of 5445 (ID: 671, /home/xraver/moko/openembedded/packages/linux/linux-openmoko_2.6.24+git.bb, do_fetch)
NOTE: package linux-openmoko-2.6.24+git20080422: started
NOTE: package linux-openmoko-1_2.6.24+git20080422-r0: task do_fetch: started
NOTE: fetch http://downloads.openmoko.org/sources/git_git.openmoko.org.git.kernel.git_4194.tar.gz
--08:47:41-- http://downloads.openmoko.org/sources/git_git.openmoko.org.git.kernel.git_4194.tar.gz
=> `/home/xraver/moko/sources/git_git.openmoko.org.git.kernel.git_4194.tar.gz'
Risoluzione di downloads.openmoko.org in corso... 88.198.93.219
Connessione a downloads.openmoko.org|88.198.93.219:80... connesso.
HTTP richiesta inviata, aspetto la risposta... 404 Not Found
08:47:41 ERRORE 404: Not Found.
</pre>

In this location http://downloads.openmoko.org/sources/ the file git_git.openmoko.org.git.kernel.git_4194.tar.gz does not exist.
Any solutions?

--[[User:xraver|Giorgio Ravera]]

Talk:Wishlist/Wikipedia Mirror

2008-07-10T10:44:25Z

Peterpall: /* A possible place to seach in for a possible size reduction boost */

= Modified zLib =
Since size is a big concern - maybe I have at least the idea in which direction to search for a possible solution.

In the times everything had still to be downloaded from sunsite and compiled by hand there was a bible browser that used a modified zlib that made use of a modified zlib, - that compressed the text of the bible - but - as far as I understood - compressed every verse by itselves - which allowed for a very fast seeking - at the cost of compression ratio, since gzip no longer could learn from the past verses.

Two years ago I stumbled over this library again on my ubuntu box so it might still be alive.

Wishlist/Wikipedia Mirror

2008-07-10T10:30:03Z

Peterpall: /* Why we need SDHC support */

{{Wishlist}}
__TOC__
A local copy of wikipedia that you can browse anywhere without incurring bandwidth costs. It's already been done for the iPod (see [http://encyclopodia.sourceforge.net encyclopodia]), but I think we can do better on the Neo. For starters, it has a much nicer screen, and a real UI toolkit to play with, and can run multiple apps simultaneously etc.

--[[User:HEx|HEx]] 07:22, 5 May 2007 (CEST)

== Size ==
This is the real problem. A recent bzipped article-only dump of enwiki comes in at 2.1Gb. Encyclopodia's download seems to be about 1.7Gb. It seems likely that even with some optimization, a full copy of wikipedia is going to be over 1Gb. Thus it would seem that a complete copy is probably going to be impractical for most people (assuming they want to store other things on their Neo too), so it would be worth finding out what bits can be discarded with relatively little loss.

On the compression front, lzma would seem to be the way to go. Clearly the input needs to be divided into blocks for random access, but the choice of which articles go into which block I think could affect the compression ratio greatly. Maybe if each category is a folder and each letter (article initial) of a category is an archive.

[http://cs.fit.edu/~mmahoney/compression/text.html] has some interesting benchmarks for wikipedia compression. I still think lzma would be best as it does quite well while not using much CPU and memory (plus it's already in OpenEmbedded).

To save space, we could provide smaller sections of the main Wikipedia (eg Music, Science, Literature) and download anything else on demand. It needs to be clear what's local and remote, however, as data charges can be expensive.

From the other side, we could simply count on 8 Gb Micro SD card. Such card could store not just the article texts but maybe even images, if they are resized in advance to the small size, suitable for OpenMoko screen.

== Integration ==
It would be interesting to integrate Wikipedia with the GPS device, allowing a query about the articles, describing objects that are located nearby. There are many articles about cities and other objects with known locations in Wikipedia, and some uniform coordinate representation system seems also present.

== Format ==
This is a tough one. Despite the fact that MediaWiki's markup format is notoriously underspecified and hard to interpret, it's also widespread and human-readable and space-efficient, and, while a custom markup format could possibly be more space-efficient and easier to parse, the world really doesn't need any more markup formats. Thus I'm tending towards just rendering MediaWiki markup directly on the Neo, which would have the plus of being able to view the source if and when rendering goes horribly awry.

Of the possibilities at the [http://meta.wikimedia.org/wiki/Alternative_parsers list of parsers], [http://svn.wikimedia.org/svnroot/mediawiki/trunk/flexbisonparse/ flexbisonparse] looks the most promising.

HTML or XML as an intermediate step would be a possibility, and there's sure to be a web browser available, but just dumping the output to a GtkTextView would probably be simpler and more efficient.

== Other E-book software ==

Since there's bound to be other, similar software being developed or ported, it would make sense to see if this could usefully be part of a larger project. (The alternative, "do one thing, do it well", also has some appeal though.)

== The Mokopedia Way ==

This section is about my [[Mokopedia]] project.

=== Why it isn't using Wikitext ===

Wikitext is horribly difficult to parse - just look at how tables are defined in wikitext and what thousands of possibilities you have! It would be overkill to write another wikitext Interpreter. Xhtml instead is simply parsed and can also be embedded easily in the gtkhtml widget.
Another reason: if the wikimedia software changes anything on its wikitext 'specification' the parser has to be changed. Its useless to use something in a program, that is no standart and is likely to change without notice.
Wikitext is more lightweight? right.

=== Why we need SDHC support ===

Size is only a problem for the english wikipedia. I managed to run the entire german wikipedia UNCOMPRESSED on my Nokia E70 Symbian phone. It had to be uncompressed because the articles were viewed with the Nokia browser from a local Raccoon install with a little Python script to search the articles. For more infos about my optimizations on the mediawiki html dump to get this running see [http://www.johannes-schauer.de/viewforum.php?f=47] (German)
If I compress everything with bzip2 it shrinks to 19% of it's former size but this will not help for an offline version since seeking for a special file in such a big archive will cost an enormous amount of computing power. So the only options are to either pack every file separately or to pack a few files together in chunks of several kB. But this will reduce our compression ratio enormously (~30% compression with bz2) but is unavoidable for fast access.

Conclusion: our only hope is to hope for SDHC support. I verified that the (second largest) german wiki will fit on a 2GB non-SDHC SD-Card with every file compressed separately. With my optimizations the english wikipedia will need 2.8GB so we need 4GB SDHC media for that.

On the [[Booting_from_SD]] page there seems to be a way to make the OpenMoko use SDHC cards. Seems like the kernel supports it already so if uboot loads the kernel from NAND using a SDHC card will work. The way of archieving this is still ugly (console work involved) - but if it does work it seems to be doable for the time.

Talk:MokoMakefile

2008-07-05T09:19:21Z

Peterpall: /* MokoMakefile won't work on Ubuntu Hardy Heron */

== MokoMakefile won't work on Ubuntu Hardy Heron ==
Hello, there!

Since my upgrade to Hardy Heron MokoMakefile seems to be broken on my ubuntu box. I already tried several times to download a new Makefile into a fresh directory - without success. What I get is always:

:~/moko$ make image
( cd build && . ../setup-env && \
( bitbake openmoko-devel-image u-boot-openmoko ) )
ERROR: Openembedded's config sanity checker detected a potential misconfiguration.
Either fix the cause of this error or at your own risk disable the checker (see sanity.conf).
Following is the list of potential problems / advisories:

/proc/sys/vm/mmap_min_addr is not 0. This will cause problems with qemu so please fix the value (as root).

make: *** [openmoko-devel-image] Error 1

For another report on this problem see also: http://lists.openmoko.org/pipermail/community/2008-May/017545.html

When trying to compile the april software update (ASU) this error doesn't occour, though.

=== solution ===

<pre>
$ sudoedit /etc/sysctl.conf
</pre>

And add 'vm.mmap_min_addr = 0' (without quotes) to that file.

== The paths that are mentioned on this page are partially wrong ==
I am not sure enough what the paths should be, but - two things have changed since the section "developing with mokomakefile/How to add your own shiny new application" of this page was created:
- The path where the packages are kept, and
- Where to add the information that we have added a new package.

== Ubuntu Edgy: Update git-1.4.x to 1.5.x! ==
With old git-1.4.x, fetching uboot does not work: Use 1.5.x:
<pre>
NOTE: package uboot-gta01-1.2.0+svnnow-r4_14da5f7675bbb427c469e3f45006e027b6e21db9_0_1811: task do_fetch: started
fatal: corrupted pack file .git/objects/pack/pack-a146bcbc18f4826d6bf2a7f63be5dd77bbb5b2f5.pack
</pre>

== Fails on a 32bit machine - try again without ccache? ==

<pre>/bin/sh ./libtool --mode=compile ccache gcc -DHAVE_CONFIG_H -I.... -W... -O2 -c -o libbfd.lo build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17/bfd/libbfd.c
ccache gcc -DHAVE_CONFIG_H -I... -W... -O2 -c /usr/local/oe/build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17/bfd/libbfd.c -o t shift count >= width of type
make[5]: *** [libbfd.lo] Error 1
</pre>

Any insight here? --[[User:Adam|Adam]] 23:10, 15 May 2007 (CEST)
: Try without ccache (did you get it compiled meanwhile or can we remove this?) --[[User:BernhardKaindl|BernhardKaindl]] 23:05, 19 September 2007 (CEST)

== Facing Problems with ogg libraries ==
just get the path and delete the .bb file that causes the problem
== Building on Fedora Core 6 ==

Install stuff needed for OpenMoko:
# yum install python m4 make wget curl ftp cvs monotone subversion \
tar bzip2 gzip unzip python-psyco ccache perl texinfo texi2html \
diffstat openjade docbook-style-dsssl docbook-style-xsl docbook-dtds \
docbook-utils sed bison bc glibc-devel gcc binutils pcre pcre-devel git \
quilt groff linuxdoc-tools patch compat-gcc-34 lynx netpbm
(notice ''compat-gcc-34'' wich was needed for FC6 (gcc 4 installed), and ''lynx'' which is needed by ''qemu'' (no fallback to ''wget'', ''curl'', or ''links'' at the moment and no check for it, resulting in strange "sleep" errors when trying to build without ''lynx'').

Build it:
$ make setup
$ make openmoko-devel-image
$ unset LD_LIBRARY_PATH
$ make update-makefile && make update && make setup && make openmoko-devel-image

I have also done a
$ unset LD_LIBRARY_PATH; make update-makefile && nice make update && nice make setup && nice make all
(This takes several hours)

Build qemu:
$ make qemu

Run it:
# echo 1024 > /proc/sys/dev/rtc/max-user-freq
$ make run-qemu
This will bring up the OpenMoko :) Use SPACE for AUX and ENTER for POWER.
Not quite the same as holding a Neo1973 in your hands I would guess, but this is the best we can do for now. Thanks!

== Building on Ubuntu Feisty ==

MokoMakefile requires more than 512 MB of RAM + Swap space (around 1GB?).

If you need swap, please '''check that its size under Feisty is not null'''!

[https://bugs.launchpad.net/ubuntu/+bug/105490 Bug #105490] describes the current issue and offers a workaround (23 Jul 07).

== Fails trying to build bluez-utils ==
on Gentoo Linux, it fails compiling bluez-utils (I've tried also "make clean-package-bluez-utils" before the following command)

do a "make build-package-libusb; make clean-package-bluez-utils" and it should continue (the bluez-utils .bb is missing the libusb dependency)

== openSUSE 10.1 and 10.2 workarounds ==

ltrace package fails to build with error:
<pre>
...
checking for pid_t... yes
checking for getopt... yes
checking for getopt_long... yes
checking gelf.h usability... no
checking gelf.h presence... no
checking for gelf.h... no
configure: error: ***** gelf.h not found *****
FATAL: oe_runconf failed
</pre>

'''FIX: '''
edit ''/home/moko/build/tmp/work/armv4t-linux/ltrace-0.4-r0/ltrace-0.4/configure.ac''
at line 44: remove the following block:
<pre>
for path in /usr/include/elfutils /usr/local/include/elfutils \
/usr/include/libelf /usr/local/include/libelf; do
if test -f ${path}/gelf.h; then
CPPFLAGS="$CPPFLAGS -I ${path}"
fi
done
</pre>
( it adds /usr/include/elfutils to path, which causes cross-compile badness error )

=== QEMU build fails to compile USB code ===
<pre>
/usr/include/linux/usbdevice_fs.h:116: error: variable or field `__user' declared void
/usr/include/linux/usbdevice_fs.h:116: error: syntax error before '*' token
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c: In function `usb_host_handle_control':
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:103: error: invalid application of `sizeof' to incomplete type `usbdevfs_ctrltran
sfer'
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c: In function `usb_host_handle_data':
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:120: error: storage size of 'bt' isn't known
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:132: error: invalid application of `sizeof' to incomplete type `usbdevfs_bulktran
sfer'
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:120: warning: unused variable `bt'
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c: In function `usb_host_device_open':
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:199: error: storage size of 'ctrl' isn't known
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:202: error: invalid application of `sizeof' to incomplete type `usbdevfs_ioctl'
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:199: warning: unused variable `ctrl'
make[2]: *** [usb-linux.o] Error 1
</pre>

'''FIX: '''
edit ''/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c''
at line 29 add the following (before ''#include <linux/usbdevice_fs.h>'')
<pre>
#include <linux/compiler.h>
</pre>
hint: there is a copy of the file in ''/home/moko/build/tmp/work/i686-linux/qemu-native-0.9.0+cvs20070613-r5/qemu/usb-linux.c''

''see: http://osdir.com/ml/emulators.kvm.devel/2007-01/msg00101.html''

== Cannot satisfy fstests ==
<pre>
make openmoko-devel-image
...
| Collected errors:
| ERROR: Cannot satisfy the following dependencies for task-openmoko-debug:
| fstests
NOTE: Task failed: /no-backup/Moko/build/tmp/work/fic-gta01-linux/openmoko-devel-image-1.0-r0/temp/log.do_rootfs.25036
NOTE: package openmoko-devel-image-1.0-r0: task do_rootfs: failed
ERROR: TaskFailed event exception, aborting
</pre>
Failed on debian etch 2007-07-20
Solution from mailing list post from hardskinone, report of an irc chat
<pre>
I got help in IRC channel. I do following steps
* remove fstest from oe/packages/tasks/task-openmoko.bb ,
* increase PR field by one
* make openmoko-devel-image
</pre>

== conflicting types for 'futimens' ==

if you encounter the following error:

| In file included from utimecmp.c:40:
| utimens.h:2: error: conflicting types for 'futimens'
| /usr/include/sys/stat.h:370: error: previous declaration of 'futimens' was here

a patch is needed because your glibc is too new. grab & enable the patch as follows

cd openembedded/packages/coreutils
mv coreutils_5.3.0.bb coreutils_5.3.0.orig
wget http://www.openembedded.org/repo/org.openembedded.dev/packages/coreutils/coreutils_5.3.0.bb
cd -
cd openembedded/packages/coreutils/coreutils-5.3.0
wget http://www.openembedded.org/repo/org.openembedded.dev/packages/coreutils/coreutils-5.3.0/futimens.patch
cd -

== Workaround for problems compiling mtd-utils ==

Change the line on <code>openembedded/packages/mtd/mtd-utils_1.0.0+git.bb</code> which reads:

SRC_URI = "git://git.infradead.org/mtd-utils.git;protocol=git;tag=master \

to:

SRC_URI = "git://git.infradead.org/mtd-utils.git;protocol=git;tag=a6fa706fe9e7696b4b2045edf9698c3bac07e3e3 \

which forces the recipe to use an older revision (the one which worked last time I built the image on my computer).

Be sure to remember to undo the change later, or else you will not get any new changes to that package. --[[User:CesarB|CesarB]] 04:48, 25 July 2007 (CEST)

Note: these patches should be updated - the lzo patch is included in the current version, so backing off to the previous version and repatching seems silly. I was able to make it through this part of the build by applying the remaining patches manually. --[[User:Mellon|Ted Lemon]] 15:44, 29 July 2007 (CDT)

== Monotone segfaulting on Ubuntu Feisty Fawn/PPC ==
If you are running Ubuntu Feisty Fawn on a PowerPC computer you will experience problems running monotone. To fix this issue you need to install monotone as well as the libboost packages from Gutsy. The easiest way to accomplish this is to add the gutsy repositories to your sources.list
and change the preferences to look like this:

Package: *
Pin: release a=feisty
Pin-Priority: 700

Package: *
Pin: release a=gutsy
Pin-Priority: -100

Package: libc6 libc6-dev tzdata util-linux libgcc1 libstdc++6 monotone
Pin: release a=gutsy
Pin-Priority: 800

Package: libboost-*
Pin: release a=gutsy
Pin-Priority: 800

After doing this install monotone in this way:
apt-get -t gutsy install monotone.
That should install monotone 0.35 with updated (and working) boost libraries.

== Fails on ncurses install in Fedora 7 with a "tic -x" message ==
Adjust the following command to your system, then run it:
export LD_LIBRARY_PATH=/home/moko/build/tmp/work/x86_64-linux/ncurses-native-5.4-r8/ncurses-5.4/lib
Then start make again and it should pick up where it left off.

You can get a list of potential paths to use with the following command from you main moko directory:
find . | grep libncurses

The basic problem is that it is linking against your main system libraries instead of the OpenEmbedded ones.

There's probably a cleaner way of handling this - please update this entry if you know it.

This has been fixed in Openembedded, see [http://bugs.openembedded.org/show_bug.cgi?id=2554 Openembedded Bug #2554] for further details.

== uboot-gta01 fails to build ==
Changes in the GIT of U-Boot make the OpenMoko patches unapplyable. For the use of Revision ''cc3023b9f95d7ac959a764471a65001062aecf41'' and everything will be fine for now.

== Perl fails to build ==
After following every bit of advice I can find to 'make clean' and nuke the perl build directories, every build comes up with:

| make[1]: Entering directory `/src/openmoko/build/tmp/work/i686-linux/perl-native-5.8.7-r3/perl-5.8.7'
| make[1]: *** No rule to make target `<command-line>', needed by `miniperlmain.o'. Stop.
| make[1]: Leaving directory `/src/openmoko/build/tmp/work/i686-linux/perl-native-5.8.7-r3/perl-5.8.7'
| FATAL: oe_runmake failed
NOTE: Task failed: /src/openmoko/build/tmp/work/i686-linux/perl-native-5.8.7-r3/temp/log.do_compile.19531
NOTE: package perl-native-5.8.7-r3: task do_compile: failed

Solution turned out to be editing
/src/openmoko/build/tmp/work/i686-linux/perl-native-5.8.7-r3/perl-5.8.7/makedepend.SH and at line 169 change the regexp to eat references to "<command.line>" to catch what was leaking through.

== Gettext fails to build ==
Gettext's build is broken unless you have emacs installed. Crazy though it seems. You will see an error like:

<pre>

| WARNING: Warnings can be ignored. :-)
| if test "no" != no; then \
| set x; \
| list='po-mode.el po-compat.el'; for p in $list; do \
| if test -f "$p"; then d=; else d="./"; fi; \
| set x "$@" "$d$p"; shift; \
| done; \
| shift; \
| EMACS="no" /bin/bash ../../config/elisp-comp "$@" || exit 1; \
| if test "no" != no; then \
| set x; \
| list='po-mode.el po-compat.el'; for p in $list; do \
| if test -f "$p"; then d=; else d="./"; fi; \
| set x "$@" "$d$p"; shift; \
| done; \
| shift; \
| EMACS="no" /bin/bash ../../config/elisp-comp "$@" || exit 1; \
| else : ; fi
| mv: cannot move `elc-temp' to `elc-stamp': No such file or directory
| make[5]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools/misc'
| make[5]: *** [elc-stamp] Error 1
| make[5]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools/misc'
| make[4]: *** [po-mode.elc] Error 2
| make[4]: *** Waiting for unfinished jobs....
| make[4]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools/misc'
| make[3]: *** [all-recursive] Error 1
| make[3]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools'
| make[2]: *** [all] Error 2
| make[2]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools'
| make[1]: *** [all-recursive] Error 1
| make[1]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1'
| FATAL: oe_runmake failed

</pre>

The solution is simple - install emacs (example below for debian/ubuntu) and try again:

<pre>

sudo apt-get install emacs
make clean-package-gettext-native-0.14.1-r5
make openmoko-devel-image

</pre>

== Building OpenMoko with chroot ==

There may be hundreds of issues which may cause that OpenMoko fails to build on your system, so it might be more straightforward to just install a standardized build environment in which the openmoko build runs in chroot, independent of your distribution.

There is now a (not fully working) script which is able to set up a 32-bit openSUSE 10.3 build environment for building OpenMoko posted on distro-devel: [http://lists.openmoko.org/pipermail/distro-devel/2007-November/000076.html]

On gentoo and debian-like distribution, you can use debootstrap to quickly setup a base chroot.

Please note that in addition to the common /dev, /sys and /proc, /dev/shm should also be mounted with --bind option. It is at least required to build a qtopia-x11 image. (Otherwise you will get some semaphore 'function not implemented' errors at qtopia-x11 installation stage).

== Fails compiling binutils-cross on Gentoo/AMD64 and openSUSE/x86_64 ==

make setup works fine, but when running make openmoko-devel-image it fails with the following:

<pre>
| make[4]: Entering directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi/libiberty/testsuite'
| make[4]: Nothing to be done for `install'.
| make[4]: Leaving directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi/libiberty/testsuite'
| make[3]: Leaving directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi/libiberty'
| make[2]: Nothing to be done for `install-target'.
| make[2]: Leaving directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi'
| make[1]: Leaving directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi'
| rmdir: build/tmp/cross//home/techiem2/Moko/build/tmp/cross/lib/gcc-lib: No such file or directory
| rmdir: build/tmp/cross//home/techiem2/Moko/build/tmp/cross/lib: No such file or directory
| rmdir: build/tmp/cross//home/techiem2/Moko/build/tmp/cross: No such file or directory
| mv: cannot stat `build/tmp/cross/lib/libiberty.a': No such file or directory
NOTE: Task failed: build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/temp/log.do_stage.9730
NOTE: package binutils-cross-2.18-r0: task do_populate_staging: failed
ERROR: TaskFailed event exception, aborting
NOTE: package binutils-cross-2.18: failed
ERROR: Build of openembedded/packages/binutils/binutils-cross_2.18.bb do_populate_staging failed
ERROR: Task 1641 (openembedded/packages/binutils/binutils-cross_2.18.bb, do_populate_staging) failed
NOTE: Tasks Summary: Attempted 107 tasks of which 107 didn't need to be rerun and 1 failed.
ERROR: 'openembedded/packages/binutils/binutils-cross_2.18.bb' failed
make: *** [openmoko-devel-image] Error 1
</pre>

The final reason why the build cannot continue is:
mv: cannot stat `/home/techiem2/Moko/build/tmp/cross/lib/libiberty.a': No such file or directory

=== The lib64 issue ===

Likely, Gentoo/AMD64 uses lib64 instead of lib as the library directory for x86_64 libraries. It's l likey that may (or all?) AMD64 distributions do for their 64-bit binaries. On openSUSE-x86_64, the same happens. Debian/x86-64 seems to either not use lib64 or is somehow supported by the openmoko distribution.

On multilib/lib64 platforms like Gentoo/x86_64 and openSUSE-x86_64, the openmoko build runs into a final problem at the end of build: It tries to use fakeroot which uses LD_PRELOAD to fake a different root directory and in the final stages, after hours of compiling, fakeroot execution causes warning messages because on multilib/lib64 systems as they have two versions of many libraries, the 64-bit libraries are in /lib64, /usr/lib64 and oder lib64 paths, while the 32-bit libraries are in /lib, /usr/lib and other lib paths. Some tool on these lib64 distributions are adapted to install 64-bit libraries to lib64, but this seems to fail when cross-compiling.

At least on openSUSE-10.3 the missing libiberty.a was installed to build/tmp/cross/lib64/libiberty.a, which looks wrong, and it is if this libiberty.a file contains 32-bit arm objects. If it contains 64-bit x86_64 objects, it's fine, but openembedded/openmoko is not expecting it in a lib64 directory. I am not sure what is the case.

The lib64 fakeroot issue requires to change the openembedded build scripts, which is doable. But it's not very easy to find the correct script and patch it correctly. If you feel adventourus, go ahead and try to build openmoko on a lib64 distribution, but it's easyer to set up a complete 32-bit chroot environment and run a normal build in it.

After seeing this, I assumed that openmoko/openembedded was clearly not tested with lib64 build hosts and since that would mean that even if I'd fix that error, many others could follow, and as I was not interested to fix the lib64 bugs but rather wanted to see something running first, I decided to make openmoko/openembedded think that it was running on a normal 32-bit non-lib64 machine.

There are several ways to do that:
* You install an IA32-Linux somewhere and use that for building:
** Do a native install and dual-boot the IA32-linux (That's for dummies which do not know the other tricks)
** Install IA32-Linux in a virtual machine (Quite some setup and has some overhead too)
* you can install a 32-bit development system in to a chroot jail and compile there (also quite some setup and inconvinience)
* Or you can install a 32-bit development system on the 64-bit host (suppored on openSUSE, should be possible with Gentoo/AMD64 too)

=== Building on SuSE Linux 10.3-AMD64 with -m32 (not finished) ===

Install the following packages for the 32-bit C/C++ compiler target option -m32 to work and to compile what is needed

gcc42-32bit gcc42libgcc42-32bit glibc-devel-32bit libstdc++-devel-32bit ncurses-devel-32bit zlib-devel-32bit (maybe also gtk2-devel-32bit)

The openSUSE 10.3-AMD64 has no libopenssl-devel-32bit, but you can install the 32-bit rpm from the i586 10.3 rpm tree:

libopenssl-devel

You should also make sure that gdbm-devel is not installed.
The multilib support in ld has an issue which surfaces when it is called from perl's Configure script to complile a test program with -Lgdbm. If gdbm-devel is installed, it finds /usr/lib64/libgdbm.so, but since it's not compatible with 32-bit, it skips it, but also does not search the specified -Lpath where the OpenEmbedded-built libgdbm.so is already installed. To work around this, uninstall /usr/lib64/libgdbm.so with:
rpm -e gdbm-devel

Note these need to be the 32-bit cpp33 and gcc33 rpms as the 64-bit gcc33 rpms for openSUSE do not support the 32-bit target.

To make the OpenMoko build think that its running on 32-bit i686, use linux32 (changes uname -m to i686 in the new shell):

linux32 bash

And set up gcc scripts which force the use of gcc-3.3 (it can only generate 32-bit assembly) for all compilation:

mkdir bin;cd bin
echo '/usr/bin/${0##*/}-3.3 -m32 "$@"' >gcc
echo '/usr/bin/${0##*/} -m elf_i386 "$@"' >ld
echo '/usr/bin/${0##*/} --32 "$@"' >gas
sed -i '1i#!/bin/sh' gcc gas ld
chmod 755 gcc gas ld
ln -s gcc cc
ln -s gcc c++
ln -s gcc g++
ln -s gas as
echo PATH=\""$PWD":\$PATH\" >.setup-gcc-m32
cd -

Then set the path and test it:

source bin/.setup-gcc-m32
type gcc

== More package requirements ==

On my system (Kubuntu 6.10) build failed with message "ERROR: QEMU requires SDL or Cocoa for graphical output" because package <tt>libsdl-image1.2-dev</tt> was missing. Use <tt>apt-get install libsdl-image1.2-dev</tt> to install. Additionally I had to install packages <tt>cvs</tt> and <tt>diffstat</tt>. I was also asked to install Psyco JIT Compiler (package <tt>python-psyco</tt>) to increase performance. Nevertheless <tt>make flash-qemu-local</tt> took some hours, but now I finally can get an impression of the phone that I am looking for! -- [[User:Nichtich|Nichtich]] 00:26, 20 September 2007 (CEST)

== pango-directfb failed to build due to missing Glib 2.14.x ==

The latest(as of Sept. 25, 2007) build started to fail with the following error:

| checking for GLIB... no
| configure: error:
| *** Glib 2.14.0 or better is required. The latest version of
| *** Glib is always available from ftp://ftp.gtk.org/.
| FATAL: oe_runconf failed
NOTE: Task failed:
/media/sdc1/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/\
pango-directfb-1.18.1-r0/temp/log.do_configure.19927
NOTE: package pango-directfb-1.18.1-r0: task do_configure: failed
ERROR: TaskFailed event exception, aborting
NOTE: package pango-directfb-1.18.1: failed
ERROR: Build of /media/sdc1/moko/openembedded/packages/pango/\
pango-directfb_1.18.1.bb do_configure failed

The Glib included in the build tree seems to be only 2.12.12, so looks like something
is broken in term of dependency.

This had happened on both of Fedora 7 and Debian Etch. I am running the latest
MokoMakefile with OM-2007.2. The funny thing is that the build had worked only
couple nights ago. Any idea? I will update anything I find here and also on my blog(see my user profile).
[[User:ttz|ttz]] Wed Sep 26 12:17:33 CDT 2007

pango-directfb had been removed from OE for now due to the report of it breaking builds like OpenMoko.

[[User:ttz|ttz]] Thu Oct 4 10:20:12 CDT 2007

== uicmoc4 failes to compile ==

This is solved by installing libz-dev

Or, look at [http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=747 Bug #747]

== svn: REPORT request failed on '/repos/tasks/!svn/vcc/default' ==

osiris$ make update
...
Fetching external item into 'trunk/src/target/OM-2007.2/applications/openmoko-today2/libkoto'
svn: REPORT request failed on '/repos/tasks/!svn/vcc/default'
svn: REPORT of '/repos/tasks/!svn/vcc/default': 200 OK (http://svn.o-hand.com)
make: *** [update-openmoko] Error 1

osiris$ cd openmoko/trunk/src/target/OM-2007.2/applications/openmoko-today2//libkoto/
osiris$ svn up -r HEAD
svn: REPORT request failed on '/repos/tasks/!svn/vcc/default'
svn: REPORT of '/repos/tasks/!svn/vcc/default': 200 OK (http://svn.o-hand.com)

Anyone know about this one?
--[[User:Blackh|Blackh]] 00:11, 12 October 2007 (CEST)

== bootparam_prot.h fails to install in glibc-intermediate-2.5 package (Debian sid) ==

| install: cannot stat
`/home/blackh/src/openmoko/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/
glibc-intermediate-2.5-r7/glibc-2.5/sunrpc/rpcsvc/bootparam_prot.h'
No such file or directory
NOTE: Task failed: /home/blackh/src/openmoko/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/
glibc-intermediate-2.5-r7/temp/log.do_stage.3940

For some reason, on Debian, the rpcgen command needs "-Y /usr/bin" added to the end of it or it won't work ("cannot find any C preprocessor (cpp)"). This can be fixed by hand...

cd /home/blackh/src/openmoko/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/
glibc-intermediate-2.5-r7/glibc-2.5/sunrpc/rpcsvc
for f in *.x ; do rpcgen -h $f -o ${f%%.x}.h -Y /usr/bin ; done

This command will generate the right files and you can resume the build with

make openmoko-devel-image

Here is a better fix - put this script, calling it rpcgen, somewhere in your PATH before /usr/bin:

#!/bin/sh
exec /usr/bin/rpcgen -Y /usr/bin "$@"

--[[User:Blackh|Blackh]] 05:17, 12 October 2007 (CEST)

== Cannot find SVN openmoko-terminal2 ==
I'm having an issue when building MokoMakeFile where it is unable to find http://svn.openmoko.org/trunk/src/target/OM-2007.2/applications/openmoko-terminal2. Any ideas on how to fix this?

--[[User:cartera|cartera]]

== problem with make openmoko-devel-image ==

when i try to do my first make openmoko-devel-image I obtain this error:

<pre>
NOTE: Running task 844 of 5445 (ID: 671, /home/xraver/moko/openembedded/packages/linux/linux-openmoko_2.6.24+git.bb, do_fetch)
NOTE: package linux-openmoko-2.6.24+git20080422: started
NOTE: package linux-openmoko-1_2.6.24+git20080422-r0: task do_fetch: started
NOTE: fetch http://downloads.openmoko.org/sources/git_git.openmoko.org.git.kernel.git_4194.tar.gz
--08:47:41-- http://downloads.openmoko.org/sources/git_git.openmoko.org.git.kernel.git_4194.tar.gz
=> `/home/xraver/moko/sources/git_git.openmoko.org.git.kernel.git_4194.tar.gz'
Risoluzione di downloads.openmoko.org in corso... 88.198.93.219
Connessione a downloads.openmoko.org|88.198.93.219:80... connesso.
HTTP richiesta inviata, aspetto la risposta... 404 Not Found
08:47:41 ERRORE 404: Not Found.
</pre>

In this location http://downloads.openmoko.org/sources/ the file git_git.openmoko.org.git.kernel.git_4194.tar.gz does not exist.
Any solutions?

--[[User:xraver|Giorgio Ravera]]

Building OpenMoko 2007.1 from scratch

2008-07-03T06:38:40Z

Peterpall: Got this one wrong. Reverting the page again.

#REDIRECT [[Building_Openmoko_2007.1_from_scratch]]

Building OpenMoko 2007.1 from scratch

2008-07-03T06:37:11Z

Peterpall: The Redirect to an instruction how to build the currend image went still to a old page.

#REDIRECT [[Openmoko2007.2]]

Talk:Neo 1973 Battery Charging Logic

2008-06-26T07:53:50Z

Peterpall: /* Added a question about a link that references informations on a page that no more contains them. */

==Link to the Fast Charger UBOOT entry?==
The link given on this page that should tell how to add an fast-charge UBOOT entry goes to the UBOOT-page - which no longer contains the referenced information.
==Time to pre-charge a deep discharged battery?==
[[User:Speedevil|Speedevil]]'s article suggested pre-charging for 1 hour. The suggestions in this article (before I imported those from Speedevil) suggested to pre-charge for 2-4 hours. Is there a way to choose the most effective time, and if so, is there clearer way to explain this to users? --[[User:Dcorking|Dcorking]] 15:01, 20 August 2007 (CEST)

Basically, 1 hour was an educated guess.
At 40mA (measured input power) an hours charge is 40mAh, or 3% charge.
This is plenty to boot and run for >5 minutes.
This lets you login to u-boot and setup fast-charge, or have time for it to boot and bring up cdc-ether drivers, so that the PC can turn on fast-charge.
--[[User:Speedevil|Speedevil]] 22:37, 21 August 2007 (CEST)

==48 kΩ trick work?==
On IRC, people have said the 48 kΩ trick mentioned on the page to enable fast charge doesn't actually work on the Neo. I don't want to edit it out since I don't have personal information on the matter; anyone?
--[[User:Mjr|Mjr]] 21:13, 21 August 2007 (CEST)

Diddn't work when I tried it.
Edited out.
--[[User:Speedevil|Speedevil]] 22:33, 21 August 2007 (CEST)

Wish List

2008-06-13T07:20:36Z

Peterpall: /* Speaker-phone/crappy alternative */

This article is a place to collect various thoughts about the future of the [[OpenMoko]] software platform. Most wish list ideas have been linked from this page, but you may also wish to check all pages [[:Category:Ideas|that have a category of 'Ideas']].

== Development ==
=== Painless SDK installation & Setup ===
Our goal should be a completely painless setup for somebody wanting to develop using [[OpenMoko]]

* one command for installation (apt-get install openmoko)
* one command to start Xnest (openmoko-xephyr?)
* one command to start an i386 shell (openmoko-386-shell)
* one command to start an armel shell (openmoko-armel-shell)

No extra configuration required.

==== IDE Plugins ====
People like to see plugins for
* [http://anjuta.sourceforge.net Anjuta]
* [http://www.eclipse.org Eclipse] (some things are possible - see [[Development with Eclipse]].
* [http://www.netbeans.org NetBeans]
* Game engine - Game Creation plugins
evaluate eclipse project [http://www.eclipse.org/dsdp/index.php Device Software Development Platform Project from eclipse] and subproject [http://www.eclipse.org/proposals/tml/ Tool for Mobile Linux]
* [http://www.kdevelop.org KDevelop]
* [http://developer.apple.com/tools/xcode/ XCode]
* [http://www.monodevelop.com MonoDevelop]
* [http://msdn.microsoft.com/vstudio/ Microsoft Visual Studio 2005]

==== UI Designer ====
Glade code generation is deprecated, so we don't want to use it. The Gtk+ powers told me that the plan is to have gtk 2.12 (out early 2007) with support for GtkBuilder, a libglade derivative which breaks a bit the XML definition in order to support all the new widgets and properties; as soon as it's in the other ui builders will add support for this format. See also [http://bugzilla.gnome.org/show_bug.cgi?id=172535 the relevant bug entry]
* Possibly a Landscape (rotated) view for the screen (480x640 *or* 640x480)?

==== Built-in Scripting Language ====
{{Main|Wishlist:BuiltInScriptingLanguage}}
There was a [http://lists.openmoko.org/pipermail/community/2007-January/001909.html fruitful discussion about a built-in scripting language on the mailing list in January.] Many people feel that it is very important for OpenMoko to choose a scripting language to ship as default in the standard OpenMoko firmware.
==== Easy build of the existing autotools - based packages ====
In the ideal case OpenMoko should exist on the top of the usual ./configure - make workflow which is typical for the majority of the C/C++ based open source projects. It should not require to rewrite or even replace the existing Makefile.am files of the project being ported, and it should allow to pass the needed parameters to the project configure script. Maybe OpenMoko project could be a bigger project having one or more (if some are libraries) autotools - based packages in its separate folders and include the proper documentation how to "wire" the standard autotools based package to the OpenMoko infrastructure.

===Foreign Widget Set Bindings ===
==== Qt Integration ====
The Trolltech folks have a great widget library. I'd like to interface OpenMoko with Qt4, so that we can write Qt4 applications for the phone which don't look alienated.

==== Maemo Integration ====
The Maemo folks have created a successful standard for Webpad applications. I'd like to have a set of MaemoMoko and MokoMaemo wrapper classes that allow me add support for running OpenMoko applications on Maemo and vice versa. Perhaps we can get help from the Nokia OSS folks for that.

==== wxWidgets Integration ====
wxWidgets is a cross-platform application framework that's very popular (I'd say, #3 after Qt and Gtk+). On Linux, wxWidgets uses Gtk+ to implement the widgets. It shouldn't be hard to add support for the additional OpenMoko classes to wxWidgets hence supporting the native OpenMoko look and feel for wxWidgets applications.

wxWidgets team wants OpenMoko classes too and we (wxWidgets) plan to include this project as one of our ideas for [http://google-code-updates.blogspot.com/2007/02/speaking-of-summer.html GSoC 2007]

==== SDL Integration ====
SDL is ''the'' game developer library. There are tons of SDL games out there. We should add OpenMoko support into SDL.

==== Cocoa / GNUstep ====
Allows to use MacOS X as a development platform.

=== Software: Language bindings ===
==== Python bindings ====
Python bindings seem to be a commonly requested feature.

[[User:Mickey]] says, "They are kind of usable on the [http://www.maemo.org Nokia 770], but it's at the lower end of being bearable. We should keep this in mind -- Gtk+ already comes with Python Bindings, so we "just" would need to wrap libmoko*. I would prefer to leave this to the community do though, since it doesn't make sense to start wrapping the API until we have a stable API -- and I can imagine it will take us a couple of months after going open until we can start with stabilizing the libmoko API."

==== C++ bindings ====
There is a whole skilled C++ community coming from the [http://qtopia.net Qtopia] and [http://opie.handhelds.org Opie] projects. If we would consider basing OpenMoko C++ Bindings on [http://www.gtkmm.org/ Gtkmm], then we could drag these guys in.

==== Ruby bindings ====
Ruby and ruby-(gtk|glade) already ported to OpenMoko according to [http://lists.openmoko.org/pipermail/openmoko-apps/2007-May/000040.html this ] and [http://groups.google.de/group/comp.lang.ruby/browse_thread/thread/6bee9970cf055504 this] mesages. It just have to be included to distribution (only 4.9 MB!)

==== Java bindings ====
People who concentrate on Java programming would like to have the OpenMoko port of some java virtual machine. GNU Classpath team a lot of great work in the past creating easily portable implementation. Sun's recently open sourced code could also be ported.
==== Other bindings ====
* Perl
* C#
* I think you could skip a bunch of these by binding to Dbus; most languages already have Dbus bindings

== Community Support ==

=== [http://projects.openmoko.org projects.openmoko.org] ===
Infrastructure for developers with
* One bugzilla for all projects (makes moving bugs forth and backwards between projects ''very'' easy)
* One mailing list for project

== Platform ==
=== Community Images ===
In the future there could be complete, unofficial "product images" that are created by the community, for example maybe one that incorporates only free software (in the GNU or OSI sense). Or images build with a particular niche market in mind -- a student for example.

=== Wishlist voting ===
There could be a kind of voting system like they have at one of those big computer manufacturers homepage. Then the community could vote for the ideas that are most important to them. This would especially make sense for the hardware wishlist, because the hardware is still the part which can't be done by the community that easily.

Here: [http://www.fevote.com/openmoko OpenMoko suggestion board]

== Software: Additional features ==

===PDA Mode===

There are times when you wish to power up the device and not power up the gsm/cellphone portion of the phone. For example in meetings you might wish to access the PDA side with wifi as is the case for example on an aircraft. On booting some method of booting to pda mode would be good - several other phones offer this feature.

===Driving Mode===

It may be forbidden in many countries, but many people use their cell phones while driving. With the touchscreen phones
this is very dangerous: You have to stare at the tiny numbers on the screen and try to hit them with your thumb or try to decipher tiny script of contacts, while steering with the other hand. There should be a configurable driving mode where the interface has a reduced functionality (e.g. only contacts and dialing) with HUGE interface buttons that are easy to use with limited attention.

Idea: insted of using GPS for speed measurement, number of handovers (other word: cell switches) shall be measured - as one traveling a car switches cells more often than walkers)

===Calling===

==== Mask ID based on dialed numbers ====
It would be nice if my number only showed up when I call people in my address book and was otherwise masked. The phone I have now either always shows my number or never or can be set on a per call basis. Having it done automatically based on the number dialed would be good.

==== Use calling cards and similar routing techniques for lower-cost calling ====
Many people use calling cards, low-cost numbers and similar ways of reducing the costs of their calls. It would be nice to have a single panel that would allow you to configure the rules of dialing a number taking in to account such systems.

==== Outgoing black/white lists ====
The ability to allow or deny outoging calls to certain numbers can be useful in a number of situations (e.g. the holder of the 'phone is a child, untrusted, etc.). This could be related to entries in the contact list, for example a user is only allowed to call people who are in their contact list.

Also lists for incoming calls? Some friends always come through, unknown numbers get rejected automatically.

==== Time-based blocking/unblocking of calls ====
Allowing or disallowing outgoing calls at certain times of the day could be useful, e.g. blocking a business phone from making calls outside of business hours.

====Speaker-phone====
* A speaker-phone is more than simply connecting the speakers to GSM audio, it's also echo cancellation, and eliminating the feedback that will otherwise happen between the speakers and the mic. This software has not been written. 
The problem of speaker-phones is that the microphone "hears" what the speaker outputs - directly and every reflection in the surroundings of the telephone. Since the telephone line will allow noise from the microphone to pass to the speaker again - if the speaker is loud enough and the microphone sensitive enough we have a feedback loop producing echos or even a very loud beep. 
A very crappy alternative that is used by some companies that just want to be able to print a feature on the front cover without needing to bring this feature to a useful state first now is the following: 
Turn either the Microphone sensitivity or the speaker volume down alternatively depending on what the telephone thinks might be better in this second.

Sounds as crappy, as this sounds, though, - and tends to make people very angry.

====Advanced Airtime Tracking====
Many phone users have complicated plans, things like unlimited incoming, 100 anytime minutes, 1000 evening minutes, etc. It would be nice if a user could input the various monthly airtime chunks their plan gives them, and then the phone could track how much is left in each chunk, i.e. How much anytime minutes are left this month? Optionally, the software could warn when someone is close to the monthly limit, to help avoid bigger bills.
On (at least some) prepaid [http://en.wikipedia.org/wiki/Unstructured_Supplementary_Service_Data USSD] can be used to check current balance.

* Call duration should consider billing increments and show the durations according to accounting period

==== Anti-stutter software ====
Delayed Auditory Feedback (DAF) has shown to reduce stuttering in individuals by 70%. By using the microphone, it should be pretty simple to implement this on the OpenMoko. The DAF functionality should also be present during phone calls. See http://en.wikipedia.org/wiki/Delayed_auditory_feedback for more information.

====Minimize In-Call mode (check address book while in call)====
On my locked phones I always find it annoying that one can not use other features while a call is in progress. In particular, I'd like to access the address book so that we can (1) give a caller someone else's phone number (or other info) and (2) lookup a phone number when using a calling card or some other proxy.

Similar request when using the browser (lookup passwords, todo list, etc).

====Hold Music (Ringback Tone)====
On some cellphone networks you can pay to change the normal [http://en.wikipedia.org/wiki/Ringback_tone Ringback Tone] that the caller hears when ringing, to a customised sound.
This can partially be implemented on the phone.
Issues are:
*In countries where callers pay, this will make you unpopular.
*In countries where the called party pays, it will use your minutes, or cost you money.
**A list of people to activate this function for would alleviate this.
*[[GPRS]] internet connection will stall while the hold music is being played.
*Extra battery used when playing music.

Also see [[Answering Machine]].

====Play sound clips over the air====
Dialer could have a tab with big buttons which, when push, send sound clips over GSM to the person on the other end of the call. This feature is included in GizmoProject and is called sound blasts: http://support.gizmoproject.com/index.php?_a=knowledgebase&_j=questiondetails&_i=104
The buttons can have default sounds, but also have the ability to be customized.

It would also be useful for notifying people why you can't talk (for example, having an "I can't talk tight now - I'm in the library - this is a pre-recorded message" would be good. Also perhaps you could loop a pre-recorded sound in the background so you can lie about where you are, and have the ability to simulate a really bad connection.

==== DTMF Landline Dialing ====
The ability to hold the Neo near the microphone of a landline handset and have the Neo dial the landline by sounding DTMF tones. The DTMF tones could be generated in software or be pre-recorded files.

Graphically this could be done by adding a 'DTFM dial' button to a context menu. The user would select a contact then presses the 'DTMF dial' button to start the process. A small delay could also be added to allow time to put the Neo near the landline handset.

For the Neo to know which area code to use (or not use) the current or last GPS coordinates could be utilised.

==== Conversation Recorder ====

An option to record phone conversations. Would be helpful to have the device always recording for every call, with the sound data encoded to low quality Ogg Vorbis or SPEEX and stored in RAM. At the end of the conversation the user would have the option to save to flash or discard the conversation. This idea could also be applied to voicemail so you could save voicemails locally.

====Unlicensed Mobile Access (UMA)====
T-Mobile recently rolled out a UMA service that hands off calls between the GSM network and WiFi access points. Only a few phones support it right now, this could be a rather unique feature if OpenMoko can implement it.

This can be combined with a GPS map to show where local free hubs are.

==== Ignore-Call Button ====
{{Main|Wishlist:Ignore Call Button}}

Shut up a ringing phone, without accepting or rejecting the call.

Another alternative might be to use microphone to recognize when the user gives an audible "Shhh!" command. This could prove difficult to determine with the simultaneous ringing, and possible in-pocket shuffling noises.

A really usable feature is to "reject with SMS/text message" - letting the user reply the caller choosing a previously setup template or typical response: "I'm in a meeting - I'll call you later" or "Can't take your call now, please call back in 10 minutes". This feature typically is a much better way to get your co-workers (ie boss) to back off, than to silently ignore the call.

The accelerometers could be queried while the phone is ringing to detect a firm tap on the phone. This would avoid the delays of fumbling to remove the phone from one's pocket to silence the ringer when you've forgotten to set it to silent mode. Just firmly tap the phone through your pocket, and the ringer will silence, like some Motorola pagers. Maybe single tap = silence; double tap = (activate voicemail or preset SMS).

==== Voice Mailbox ====
{{Main|Voice Mailbox}}
On-Phone voice mailbox that records calls on the phone and retrieves voice messages from your mobile service provider's voice mailbox and saves them locally.
Can act profile-dependent.

==== Hold Button ====

Similar to mute, but plays a sound file for the user on the other end while they wait. The sound file could be chosen in some setup beforehand.

==== Unanswered Call, Fast Call ====

In Greece because of the various bill programs some people call a mobile phone, rings one time and then hangup.
Then the user of the mobile phone calls the other user(using the CallerID recognition).

===Audio===

==== Ambient Noise Detection ====
{{Main|Wishlist:Software:Ambient Noise Detection}}

Using the microphone to detect ambient noise the ringtone volume could be adjusted automatically.

If the ambient noise exceeds a preset threshold, the ring vibrator could be activated. This is good for when people forget to enable vibrate mode when entering noisy environments.

Detection of ambient noise could also be used to subtract the noise from the audio signal. However this approach is best performed using two Microphones, one for the voice and the other to detect the noise.

==== Active noise control ====

Using the microphone to do [http://en.wikipedia.org/wiki/Anti-noise active noise control] on media player playback or telephone calls. This should be an independent module/library which can be used by any application which might require this feature. also provide a way to easily alter the parameters of the active noise control.

==== Hear Impaired Mode ====

Hearing impaired people need louder speaker(but with less volume than hands free) and equalized sound, based on their hearing problems(example 20dB hearing loss from 2KHz to 4KHz).
Older people 50+ years old need slower speech rate(time stretch, cut the big speech gups) and cleaner voice.

Please note also the Hearing Aid Compatibility regulations in the US. I have tried to summarize and clarify them [http://quux.wiki.zoho.com/WhereAreHACphones.html here]. I haven't yet discovered whether the FIC device is M or T rated. For many hearing impaired users, a tcoil coupling to their hearing aid (t3/T4 rating) would be preferable to manipulating sound output in other ways.

==== Mute Button ====

Button to temporarily disable microphone while talking for applications such as telephone, audio recording and (when available) movie recording.

===Web Browser===

==== Full-page Zoom Support ====
Full page zoom is a very good feature. If possible, people would want to browse the internet with normal layout than a distorted one. It's best if I could double-tap a text or image block and zoom to a fit size.

The [[BigPageWidget]] proposal suggests 'Full Page Zoom' should be implemented as a widget available to all applications.

* If the processor and memory could afford, it is good to just use [http://www.mozilla.org/projects/firefox/3.0a8/releasenotes/ Firefox 3] in OpenMoko. It has implemented latest gecko's full-page-zoom ability. With certain modification, we could do the same zoom like iPhone's Safari.
* Firefox 3 may be a big eater. A cut-down version of it may be good enough.
* If this is not practical, Minimo with full-page-zoom ability is good.

==== Plugins Support ====
* While an extensive browser plugin system would be costly to the efficacy of the platform four particular browser plugins as poplularized by Mozilla firefox should be adapted to the web-browser, namely: [http://noscript.net/ noscript], [http://adblockplus.org/en/ adblock plus], [http://www.greasespot.net/ greasemonkey] and [http://www.foxmarks.com/ foxmarks].
* Careful use of these can dramatically reduce bandwidth, page space, and rendering costs even if it comes at the risk of some hard drive space in the form of block lists.
* Greasemonkey, in particular, gives users control to set up scripts for commonly traveled pages to further reduce unnecessary or unwanted content.

==== Widget support ====
Built-in browser with the ability to install widget shortcuts (aka links) in the main phone menu, also some apis for interfacing with the other functionality of the phone like adding contacts, reading contacts, reading gps-psoition etc.. (maybe there is some defacto widget standard that could be used)

There is a [http://www.w3.org/TR/widgets/ W3C spec] being developed, which may not be exactly what the original proposal had in mind, but it is about writing simple applications with HTML, SVG and JavaScript. It is mainly Opera's work, and while most [http://widgets.opera.com/ developed widgets are not very useful], there are some that are, and it creates a very nice development platform, especially for mobile devices. So, I think it makes an awful lot of sense for OpenMoko to support this spec.

===Media===
====Music/Video Software====
A real good programming area for competition with the iPhone, a singular video/music player would be great for multimedia. A seamless integration system, a la iTunes and iPod, would be extremely popular.

Using the Wi-Fi connectivity, a separate music program that supports wireless music sharing/ streaming (similar to what can be done when two computer running iTunes that are both on the same network) and that also supports internet radio.

It would also be nice to have some kind of "announce your musical taste" mode. This could be implemented using last.fm profiles, such that when e.g. in a crowded place a user nearby has a similar musical taste, both users get notified so they can share their music files with each other (perhaps using a photo for id). Great for discovering new music - and making friends!

- Possible copyright issues sharing music files?

Sure, but that's the user's concern, not the developer's. There's no way for us to know which audio files the user is permitted/not permitted to share.

==== Reading Support ====
It would be really great to be able to read :

*PDF
*Open Document files
*Text / RTF files
*fb2 files (fbreader)
*MS Office files
*Aportis Doc (pdb)
*DjVu
*...

In both landscape and portrait

==== Wikipedia Mirror ====
{{Main|Wishlist:Wikipedia_Mirror}}

==== Blog ScribblePad ====

Draw an image (and maybe add some text), then post to your blog.

==== E-Book Reader ====
* Neos brilliant ultra-sharp screen makes for a very good e-book reading device. All it takes is a good e-book reader with touch-screen page turning / scrolling (see the [[BigPageWidget]] proposal). FBReader could probably be adjusted easily by an experienced GTK hacker. Note that e-book reading is different to pure text/pdf displaying as it requires at least auto-bookmarking of the last read page, proper text and image scaling and text formatting.

==== Personal Wiki ====
{{Main|Wishlist:PersonalWiki}}

Display the notes database as a Wiki. Inspiration: [http://www.acrocat.com/AcroWiki/default.asp?lang=en AcroWiki].

[http://www.didiwiki.org/ Didiwiki]

==== Dictionary, thesaurus, translator and flashcards ====
Native lookup dictionary and thesaurus and foreign translation dictionaries, also with support for Asian languages. Optional custom configurable (though preconfigured) interface with on-line versions of dictionaries, thesaurus and translation services.

'''Dictionary'''
Something like [http://www-user.tu-chemnitz.de/~fri/ding/ ding]:

advantages:
* small
* very efficient + useful
* only limited to really needed functions

Support for vocabulary training with flashcard system (also usable for other content than foreign language words!)

==== Flickr uploader ====
A simply, drag & drop uploader, tagger and organizer to upload images on phone to [http://flickr.com Flickr], with support for various languages. A good base could be the cross-platform uploader [http://juploadr.org/ jUploadr], written in Java and working on Windows, Mac and Linux. But, most of all, the best '''GPL''' program which actually do this work is '''[http://mobilepushr.jottit.com/ Mobile Pushr]''', written in C and Cocoa for iPhone, must be probably ported in python to work on OpenMoko.

===PIM (Personal Information Managment)===
====Context Sensitivity====
Any email or sms message or application that contains a telephone number should be click to dial, eg [http://123567890 1234567890]. Addresses link to mapping software too?

==== Notes ====

Something for taking notes would be a nice feature:
[http://www.gnome.org/projects/tomboy/ Tomboy] has some nice syncing features and is gtk based.

Some Screenshots are [http://www.gnome.org/projects/tomboy/images/ here].

==== Calendar ====

A nice calendar application should be implemented in OpenMoko. This tool should have a syncing feature with your desktop computer.
The tool should have a reminder feature and other features like other mobile phones already have.

I think synchronization sould be handled by computer with opensync+syncml based tool, not by calendar itself. --[[User:Antono|Antono]] 12:25, 7 January 2008 (CET)

* If this cellphone is thought also as a PDA, of course it needs a calendar. But I would like to see something better than just a calendar, I was thinking that there could be some application using "fisheye" view. Just like [http://www.cs.umd.edu/hcil/datelens/], though that example seem a bit chaotic. --[[User:Yprum|Yprum]] 22:27, 21 February 2008 (CEST)

==== Address Book ====

* Option to search not just the stored list of addresses, but one or more of the online phonebooks. Probably should be modular to make adding/changing phonebook sites easy. Also allows for future integration with LDAP
servers or whatever.
* Also the possibility to search all info on the contact, like number, email, postal address and so on, in case someone asks you to identify a known number.
* Web-based map-lookup. 'How do I get there from here? (here = current GPS location)' This could also be done
by integrating with whatever on-phone GPS mapping software the Neo ends up using.
* Random text input 'notes' about a contact
* Overall, this should more resemble a Palm-pilot's address-book than your average cellphone's
* Automated Daily backup of phone book to a website archive (similar to Verizon's Back-up Assistant
*Ability to integrate address book with web-based email (such as gmail) account, for those who use web based email as their primary account
* '''[[Wishlist:Tagging|Tagging]]''' Place tags for contacts. Enhance message application to send messages to all contacts tagged with ... . Enhance other application(GPS, ...) with tags.
* Support for:
**[http://en.wikipedia.org/wiki/SyncML SyncML]
**[http://abook.sourceforge.net/ abook] a text-based addressbook program
**[http://en.wikipedia.org/wiki/Ldap LDAP] address book
**[http://en.wikipedia.org/wiki/LDIF LDIF], [http://en.wikipedia.org/wiki/Xml XML] and [http://en.wikipedia.org/wiki/Comma-separated_values CSV] export and import (when possible).
*Store Bluetooth IDs of friends and notify (configurable only on this device or on both devices) when a one of these Bluetooth ID has been detected (this is more a separate application but has requirements on the address book. Should also be able to create an address book entry from a Bluetooth ID. Could be used as a nice tool to detect people who you're avoiding.
* Support for family relations (explained further on the [[Talk:Wish_List#Address_book:_Support_for_family_relations|talk page]]).

==== Database/List Display/Edit ====
{{Main|Wishlist:PilotDB}}

One of the most useful apps on my Palm Pilot for me is [http://pilot-db.sourceforge.net/ pilot-db]. It's GPL'd.

==== To-Do lists ====

* It'd be nice to have something like [http://www.joesgoals.com Joe's Goals] always available, like my phone is, even when I'm disconnected from the net.
* I would like to be able update my [http://todotxt.com/ todo.txt] which is stored on a personal server from the phone.

==== Context based To-Do list ====
{{Main|Wishlist:context based to-do list}}

If I arrive home and there are "@home" things in the to-do list, the Context based to-do list reminds me of that.

==== Workout ====

Use your phone instead of your notebook while at the gym, and get pretty graphs to admire after you're done.

==== Shopping List ====
keep Track of Prices in different shops and the products you have/don't have. Ideally using a barcode reader and gps.
If it was made aware of recipes it could even tell you what to buy without entering a shoppinglist manually.

==== [[Fuel Log]] ====
File data about fueling your car (date/time, liters, price, mileage, ...) and display some information (costs per month, average consumption, ...).
Advanced features could include:
* Automatically storing the GPS coordinates of the place where the car has been fueled (can be deactivated)
* Sending the data to a central server which collects the information ( spritmonitor.de, anything else ?)
* Let the OpenMoko receive fuel logs per SMS (e.g. if my wife with a non-openmoko mobile fuels the car and wants to file the data using her mobile phone)
* Let the OpenMoko device act as SMS gateway for non-openmoko devices to easily send the data to the central server
* Also support for air log for divers. Not that you will take this device under water but for the crew at the surface.

==== Keep in touch reminder ====
A background application which keeps track of your friends and reminds you when you have not talked, SMS, IM or mailed a person for more than # days.

==== Menstruation period timer ====
Fill in statistics and compute probabilities for menstruation, fertility, mood.
See http://www.getjar.com/products/48/MyGirls

==== Tagging ====
{{Main|Wishlist:Tagging}}
Tags can be used by various applications. Requirement is interoperability for further enhancement.
Tags should be applied to contacts, calendar events, mail/sms, calls, places(GPS) and files.
http://tracker-project.org has all needed tagging-and-searching functionality and ready to be used on low-resourced devices.

==== Exchange Integration ====

Once there is good TCP/IP connectivity on this phone, integration with corporate email/calendar/to do/contacts/etc servers would be a big advantage... near-real-time automatic email downloads and automatic bi-directional syncing are productivity boosters that you have to experience to appreciate. It turns your phone from a 'nice gadget to fiddle with' to a natural-feeling extension of your day-to-day life.

* Is the time right to name names ? Add as your liking...
** Plugin/integration to & from Kontact
** Same with Evolution - Thunderbird - Seamonkey
** ?? Google Calendars ?? (this one is tough)
** Ms Exchange

==== An electronic wallet ====

A database which stores securely PIN codes, login data, bank and email accounts, membership informations, and other valuable and private data. Entries can be ordered in a folder-like manner. Access to the database is given by a master password. The database as well as the master password are stored with strong encryption. For security reasons, the program asks again for entry of the master password after a certain period of inactivity. The database can be synchronized with a PC application (ideally written in Java for cross platform compatibility).

Examples: KWallet [http://docs.kde.org/stable/en/kdeutils/kwallet/index.html], Viskeeper [http://www.sfr-software.de/cms/EN/pocketpc/viskeeperpro/index.html], KeePass [http://keepass.info/], KMyMoney2

==== Easy business card sharing for a small group (in the same room) over bluetooth or WIFI ====

Six Neo1973 owners are having a chat in a cafe. They agree to split but meet later. They want to exchange their numbers with each other before they go.... The normal way to do this is for a rather longwinded repeating of numbers to each other, or half the people manually inputting numbers before phoning/texting the other half to complete the process. All in all its a fair number of button presses to get it sorted.

Instead the NEO could have a small app where the phones link up in a small peer to peer Bluetooth network and share automatically with one person initiating a request and the other detected NEOS agreeing/acknowledging the share. The initiating NEO would then sync the mini-group automatically by interrogating each phone and then sending the table of results. The NEOs would have to be clever about checking for duplicates in the address book and offering a choice to the user if there are any conflicts.

PROS:
*genuine saving in time for social and business situations

CONS:
*I am sure there are some security hassles to be pondered....
*not going to be used every day... definitely not an immediate priority.....
*only at geek conferences will all have a neo....

==== SMS Counter ====

An application which shows on the today-screen how many SMS i've already sent in this actual month. Some have for example 150 free SMS to write each month. With that program you can see all the time how many SMS are left until the end of the period. As an alternative it could be a counter which counts backwards from a predefined number over a defined period.

==== Data Storage ====

Store all the data about communications with a contact (SMS, MMS, phone calls, emails, IM, etc) in a database and make them available in one list or one timeline.
Make this list available through the address book.
This would be great for people who are switching between one or more communication channels frequently

===Profiles===
{{Main|Wishlist:Profiles}}

The Wishlist:Profiles page documents many possible profiles - ways to configure the phone. Including ways to respond to calls, wifi and GPS events.
And how to automatically switch between them.

===Text Messaging===
For '''Text Input related ideas''' see [[Wishlist:Text_Input]]. Bear in mind that T9 can not be included
For current development status of the messaging-app see: [[Messages]].

There are many useful options that now can be used to full capacity:

* '''Instant Messaging'''
Bringing a new GTK gui or a resized Qt gui out for the serverless Instant Messenger http://Retroshare.sf.net

* '''Acknowledge/status SMS'''
In GSM networks so-called acknowledge-SMS are sent back to the SMS's dispatcher in order to indicate that the primal sms was received (as message delivery is only best effort and is not guaranteed). So in the SMS dialog there could be equal sized buttons with captions as 'send only', 'send and receive delivery status message' and 'send and notify (e.g. ring) when delivery succeeded'.

** '''Special handling of status-SMS'''
Related to the previous entry, these acknowledgment-sms' should be handled in a different way than normal SMS'. Most Motorola do this, while Samsung SGH series don't & clog the inbox, warn of a "new" message upon Status notification: Delivery Status Messages should be stored in a separate menu so they don't bloat the received-folder and you are able to quickly review the status of the messages you had sent.
* '''SMS at time/date''' You could be able to set up messages that are sent at a certain time/date
* '''Binary SMS''' Send binary SMS. Could be used to feign WAP pushes. [http://en.wikipedia.org/wiki/Multimedia_Messaging_Service] See:
** Resource for SMS encoding: [http://web.archive.org/web/20021016104345/www.dreamfabric.com/sms/] [http://web.archive.org/web/20060411222332/] [http://home.student.utwente.nl/s.p.ekkebus/portfolio/resource/sms_pdu.html] [http://www.ihub.com/Binary%20Messages.htm]
** [http://www.gammu.org www.gammu.org] - you can use Gammu/Gammu+ source for this software and/or understanding various SMS formats including EMS, WAP, Nokia Smart Messaging, Siemens & Alcatel encoding ([[User:Marcin|I could]] eventually help)
** Resource for SMS encoding (German): http://de.wikipedia.org/wiki/SMS-Kodierung
** The infamous pocketpc-attack: http://www.mulliner.org/pocketpc/
* '''Profile-override-SMS''' SMS that start with a certain code word override the silent profile and have the phone ring. So someone could alert you in case of some emergency.
* '''Codeword-SMS''' An expansion of the above: check for code words and allow selectable tones for matches. E.g. "Server Down!" has a loud klaxon, "Disk Warning" has a quiet chirp.
* '''(De-)Abreviation-script''' Implement a script that de-abbreviates: "hi m8 u k?-sry i 4gt 2 cal u lst nyt-y dnt we go c film 2moz" becomes "Hi mate. Are you okay? I am sorry that I forgot to call you last night. Why don't we go and see a film tomorrow?" (taken from: [http://en.wikipedia.org/wiki/SMS_language])
** Implement a script that abbreviates :-)
* '''Anti-Spam''' ...feature for SMS. May be it's possible to port some Bayesian based application like bogofilter.
* '''Rule based authorizations''' ...for received messages. For example, delete messages from one source between 9h00 and 18h00 (workday) allow them otherwise (to get alerting messages).
* '''Enable chat-like SMS-viewing''' SMS-Email-like: retain SMS app, but store 'conversations' rather than pile-up. Group/archive conversations by Caller Group (Work / Friends / Home / any user-defined Caller Group). Show appropriate icon from either Caller Group or Caller ID at the source of conversations panel
* '''Searching''' allow full-text search or string search.
* '''Massive SMS Deletion''' based on Conversation, author, before-date-xx.xx.xxxx, caller group, [[Wishlist:Tagging|tags]]...
* '''Call Back''' Prompt 'Call Back' alongside other first-line options (Delete, Save number,.. this kind of options) that appear when reading an SMS.
* '''Non-destructive deletion''', deleted messages goes to trash, and are recoverable.
* '''SMS-EMail-Gateway'''
SMS comes in, gets forward to your inbox, like any other piece of mail. Appropriate alerts and etc occur - again, just like for email. A simple SMTPD running on 127.0.0.1 that is hooked to an email-to-SMS translator that will send email addressed to 'SMS@localhost' (or whatever special address) out via SMS
* '''SMS-filter chain''', for stuff like Codeword-SMS above, Theft-mode activation, auto-response (reply with gsm-position for "Where are you?"), auto-substitution (like replace $POS with gsm-position in outgoing SMS).
* '''SCROOGE-SMS''' This is an intelligent SMS router. When you write your SMS you get the option of how to send it
** By standard carrier SMS - cost 10cents
** By OpenMoko SCROOGE SERVER - this will send your SMS to the OpenMoko Community SCROOGE SERVER next time you have WiFi - the phone will remind you to turn on WiFi when it knows you are in places where you have WiFi access. The person you are sending to picks up when they come into WiFi Range. This comes with an intelligent reminder that tells you that message has still not been delivered in 24 hours and would you now like to send it by a paymethod. This is better than IM because both parties do not have to have WiFi at the same time. - cost FREE
** By email/Wifi - cost FREE
** By email/GPRS - cost ?
** Too many options!!!
** Alternatively SCROOGE SERVER could auto launch IM client if it detects both parties have WiFi at the same time (Status kept on SCROOGE SERVER?) to allow instant reply..... Person who receives has the option to reply in SMS or in IM or in VOIP phone.

=== Text input ===
{{Main|Wishlist:Text Input}}
There are many good suggestions for text input on the specific text input ideas page.

=== More/Custom Input Method Widgets ===
{{Main|Wishlist:More/Custom_Input_Method_Widgets}}
Additional and customizable Input Method Widgets (similar to virtual keyboard).
This could add soft-key functionality to games or other applications such as:
*D-Pads
*buttons
*virtual trackballs
*...
Personalized layouts could be associated with each application.

=== Games ===
{{Main|Wishlist:Games}}

=== Mesh Networking ===
{{Main|Wishlist:Mesh Networking}}

=== Printing Support ===
It would be really neat to be able to print over either bluetooth, Wifi, or USB. I can imagine wanting to print:

* Notes
* Maps
* Email
* Calendars
* ...

Cups contains a bluetooth printing backend, so (in theory) once you have your data in postscript format, you could hand it to cups and it'll do the rest. In practice, it depends on

# GTK+'s printing support
# Making cups run on a really small system

{{note| GTK+'s printing support seems to be very immature in 2.6 (which we need to use for some time). Gtk+ 2.10 contains much better printing support -- once we can use this, it should be more easy.}}

There's always the possibility to render postscript ourselves, but this is not a piece of cake -- in general, printing is much harder than one would imagine.

Further details:
* [http://groups.osdl.org/apps/group_public/download.php/2205/print-summit-gtk.pdf#search=%22gtk%2B%20printing%20API%22 osdl.org]
* [http://www.gnome.org/~alexl/presentations/guadec2006-printing.pdf#search=%22gtk%2B%20printing%20API%22 gnome.org]
* [http://www.j5live.com/?p=204 j5live.com]

===Misc Software===
====Clocks/timers/Activity meters====
===== Sport tracker =====
{{Main|Wishlist:Sport_tracker}}
Sport tracker can be used to measure the distance/velocity from point A to point B (or it could have several intermediate stopping points) using GPS. This would be extremely useful for running, biking, hiking, etc.

===== Standby clock =====
{{Main|Wishlist:Standby_clock}}
A quick way to see what time it is.

===== Egg Timer =====
{{Main|Wishlist:EggTimer}}

Very simple (one click) count up / count down timers are very useful.

===== Cycle Computer =====
As already mentioned by [http://wiki.openmoko.org/wiki/User_talk:Technil Technil], a cycle computer could be created using gps. The sensor at the bike's wheel could transmit data via bluetooth or some cable that would be attached to an openmoko device. In order to save power, one could switch off the gps and only use the bike's sensor.
* Just another idea that came to me: Why don't have sensor's transmit cable plug into the headphone/microphone plug? A tool reads the signals created by the induction of the passing magnet, then gives them to the cycle-computer-app :) --[[User:Minime|Minime]] 19:50, 12 April 2007 (CEST)

===== NTP Server =====

Run the [http://www.ntp.org NTP] daemon using the GPS chipset as a reference clock, so that the Neo would have a very accurate time-of-day clock and would be able to serve time to other networked devices.

I don't know what it would take to implement this. Items to consider would be the availability of a 1 pulse-per-second hardware signal, the accuracy of timestamps delivered in NMEA messags, etc. Dealing with power-management issues (such as the device going to sleep) would also be challenging.

===== Find Keys/locate stuff =====

This would require an additional accessory: a tag which transmits a signal that the Openmoko device can pick up. The tag could for example be attached with a ring loop to your keys, put in your wallet, or be attached with high strength adhesive strips to your remotely controlled aircraft. Whenever you can't find back your keys, wallet, RC aircraft,... you activate this application. When the device picks up the signal of the tag, it translates it to clear audio and visual prompts to guide you in the right direction.

A commercial device that offers this functionality is the [http://loc8tor.com/ loc8tor]. Having this in the Openmoko phone would obliviate the need for a separate device. Murphy's law dictates that you'll only loose your keys when you don't know any more where you've put the loc8tor tracking device. But you're bound to always have your phone with you.

Additionally, you could also set a safety perimeter. Whenever a tagged item moves more then X meters from the phone, a signal will be given.

For a related idea, see [[Wishlist#Dude.2C_Where.27s_My_Car.3F|Dude, Where's my car]].

===== Reality check reminder =====
{{Main|Wishlist:Reality check reminder}}

A tool to [http://www.phrack.org/issues.html?issue=64&id=16 hack your brain]

===== Automatic timezone changing (GPS) =====

Check the timezone with GPS and adapt them.

====Calculators====
===== A Universal Unit Converter Tool =====

One never knows when one may have to convert acre-feet into deciliters. A unit conversion tool makes all engineers and engineer wannabes much happier. And not only the engineers.

Ideas what kind of conversions a converter tool could do:

Length
- Acceleration
- Angle
- Angular Velocity
- Area
- Capacitance
- Radioactivity
- Currency
- Charge
- Computer Memory
- Conductance
- Density
- Energy
- Illumination
- Power
- Force
- Flow
- Pressure
- Speed
- Temperature
- Time
- Torque
- Viscosity
- Volume
- Weight

Roman Numerals
- ASCII, Hex
- Cooking
- BMI
- Clothing Sizes

Money Converter based on current rates from Internet...
e. g. Dollar <-> Euro

Physical and Mathematical Constants
GPS conversions

- link to or integration of a scientific calculator
- link to or integration of a simple calculator

A good basis for such a converter tool could be the Palm program "units" from
François Pessaux [http://francois.pessaux.neuf.fr/files/units1_11.tgz]. The GPL'd program comes with full documentation.

For GPS conversions see gpsbabel [http://www.gpsbabel.org]

===== An Postfix Notation (RPN) calculator =====

Many engineers, computer scientists and other groups who have grown to enjoy the simplicity and ease of an postfix notation calculator will miss them when they give up other platforms to move to OpenMoko. A RPN calculator will increase adoption by providing one of the tools that other platforms have provided for many years.

==== Windows CE Emulator ====

On ARM machine, Windows CE API emulator, like Wine on x86 machines.

==== PalmOS Emulator ====

The Access group is probably coming out with their Linux platform any time soon. One of the components is a PalmOS emulator which I'd like to see working on OpenMoko as well. There are literally thousands of PalmOS apps.

I'd like to see a Windows CE Emulator with active sync support.

==== Chumby Emulator ====

Would be very cool if the neo can act as a chumby. see http://chumby.com for more details about a chumby.

==== TV Guide ====
Display a TV guide using [http://xmltv.org xmltv].
Something like [http://mtvg.sourceforge.net/ Maxemum TV-Guide] (QT)

==== Alcohol meter ====
Give the phone some info about your body (gender, size, weigth) and when/what you drink and it will compute an approximation of the amount of alcohol in your blood. Updates automatically, could have an alarm, when you are probably sober again.
See, for example (German text) http://www.misterio-online.de/promille.htm

==== Interaction with LEGO Mindstorm ====
With the accelerometers, GPS and good CPU, the phone could be used to control/serve as input with robots built with LEGO Mindstorm, which can be accessed by USB and Bluetooth.

==== Flashlight ====
Simple finger application that makes every pixel on the entire screen white to be as bright as possible until you tap the screen again to turn it off. This way, you can use your Neo as a (short term) flashlight!

==== Wii Controller Emulator ====
Use the accelerometers and buttons on screen to work as a Wii controller via Bluetooth.

==== FUSE support ====
Ability to use FUSE to mount larger file systems over wireless. (even gmailfs, sshfs, etc.)

=== Accessibility ===
Accessibility features for the visually impaired.
* High Contrast Themes.
* Screen Magnifier. Features should include automatic cursor tracking when navigating menus and entereing text and provide manual controls to zoom in on other section of the screen.
* Text to speech. The software should read out menu item ,contact lists ,text messages etc. Would also be useful for operating the phone while driving. see: [[Wishlist:Speech synthesis]]

==== VOIP ====
* [[Dialer]] should be able to use SIP.
Ability to use the phone for VOIP over wi-fi such as Vonage. They currently have 2 different pieces of software for pc . Basically software creates a mac address which is paired with your Vonage account. Skype could also be implemented but I prefer Vonage. Only available when connected to wi-fi with a good connection. Phone treats calls the same as a cellular call, could keep a separate log of minutes, ability to record conversations, etc. Option to use VOIP if connection is available automaticly or manually. Small icon to show when call is using VOIP.
* A standard SIP client would probably fit better into the "free and open" philosophy.
* Ideally a SIP client that includes ZRTP/SRTP for secure communications.
(Note: Vonage will not give you your SIP credentials, so you cannot log into their network with a non-approved softphone. Other VoIP providers have different policies.)

''This seems very similar to what [http://en.wikipedia.org/wiki/Generic_Access_Network UMA] offers.''

Asterisk is a great communication platform that can run on small devices. I have an Asterisk server running on a Nokia 770 and I read about running Asterisk on an iPhone. With the crosscompiler available it sould be possible to compile it and run Asterisk on an openmoko phone and let it take care of almost everything on the wishlist below.
Edw/

==== Power Meter ====
If the power bar is clicked on it will show time left on charge and if charging it will show time until full.

Also a rrdtool type of configurable timespan/frequency graphical overview would be very cool and usefull to some people?

=== Accelerometer wishes ===
==== Flick interface ====
Ability to "flick" the phone for page up/down by simply and rapidly tilting the phone back-and-forth for up and forth-and-back for down. The same motion can be implemented for sideways motion. This will take advantage of the 2 3d accelerators.

Sensitivity of the scrolling should be configurable and a test option provided.

==== Reading navigation of documents enhanced by accelerometers ====
If the two accelerometers in Neo1973 allows it, it will be nice if when you're reading, give a newspaper, you can move up, down, left and to the right the viewing of the document just moving the phones to the corresponding direction.

I don't know if this is possible (haven't seen the project in detail yet) but this feature could be very attractive for final users (and this is good). (sorry for my english but i'm italian)

==== Wand UI ====
In keeping with the requests to think outside of the box... the dual 3d accelerometers should enable a 'magic wand'-style UI for certain uses. Macros could be recorded and edited, or presets could be used. For example, flipping the device playfully could initiate a game mode or could signal the end of the work day.
==== Panning interface ====
Some applications display underlying data that is larger than the screen. Typically they let you pan across the data using scroll bars.

In cases where the data is only (say) 3 or 4 screens wide or high, it may be very intuitive to just shift the hand held device a few centimeters to the left or right, up or down to pan in that direction. The screen would appear to be a hole into the world of the data, and you're just moving the hole to look at something else.

When the underlying data is very large, you obviously wouldn't want to use this mechanism unaltered; you'd have to walk to the next room to see the data 100 screens away. Instead different accelerations can be used for different panning sizes. This is the same adaption used for accelerated mouse pointers typical on touch pads. A quick flick moves the mouse pointer fast and far. A slower drag over the same area on a touch pad moves the pointer slower and with more precision.

==== Shake-to-Wake ====
Giving the phone a shake enables voice commands for a few seconds.
Usage Examples:

* {Shake} "Call" ''ContactName'' ''PhoneType''
* {Shake} "Call John Mobile" (Calls John's mobile)
* {Shake} ''ApplicationName''
* {Shake} "Reader" (Opens the e-book application)

Would require a method of inputting voice tags for applications and contacts and obviously will only work for P2 (accelerometers)
But lets get voice command functionality working before P2 (just by pressing a button on the screen instead of shaking)

I think that is possibly to replace "Shake" with double hit with finger in the side of phone. Proper algorithms(with accelerometers) should recognize any similar activities.

==== Emergency call ====
When the accelerometer detects a great acceleration (i.e. 5G) start a countdown sequence, if it is not stopped make a call to a preconfigured emergency number. If the data from the GPS is accurate give it.

A first version could use a recorded message (an audio file). In next version it could use a synthesizer, so it can give more information (add GPS information when it is ready).

:I would worry that most such events would be false positives, and hard to distinguish from the real thing. A user dropping their phone (an event very common in the life of any cellphone) is far more likely than a user being in a car accident with their phone, and the clatter of a cell phone on asphalt could reach 5G. Additionally, it has to be very hard to distinguish hitting pavement from hitting a windshield, as from a physics standpoint the two are the same thing. [[User:Hashbrowncipher|Hashbrowncipher]] 02:06, 26 October 2007 (CEST)
::It could use the gps data to calculate the speed it is traveling with. Let's say it has been moving for more than 50 km/h for more than 10 seconds. Then it could activate the "emergency call if more than 5g" function. Aside from the countdown timer, it could increase the volume to max and warn the user that an automatic emergency call will take place in x seconds. While it is counting down it could listen for "Never mind, I'm fine, phone" and stop the countdown in case it hears that. It could also output the warning sound to the attached bluetooth headset and let the user talk to emergency services if the user is still conscious. [[User:Tommy|Tommy]] 17:48, 8 January 2008 (CET)
:::Perhaps have the phone yell loudly that it's about to do the emergency call for a decent amount of time, disabled by touching the screen or entering the pin number. In the case of any bluetooth device attached to the user, the phone could check to see if it's in range before calling. [[User:sin|sin]]

==== Movement detection ====
By detecting that the owner is walking a user defined profile can be activated with a specific set of notification settings. For example you may wish to use a cheap old sounding ringtone so you don't attract attention from muggers. Or you may wish to have a louder ringtone if you carry your phone in a bag where it can't be so easily heard.

==== Games ====
Imagine a first person shooter that you look around by turning your body.

==== Sloshing battery indicator ====
Shaking the phone will produce a sloshing sound, as if it contained a liquid. As the battery loses charge, so the sound produced on being shaken, will replicate a decreasingly empty container. [http://mobile.slashdot.org/article.pl?sid=07/11/28/1342248] for an example.
==== Steady screen ====
It may be hard to read the screen when the device is shaking from some source of vibration. E.g.
* being mounted inside a vehicle
* during certain sports
* while the internal vibrator is activated (perhaps)
The accelerometers could be used to determine the frequency of the shaking and to make the screen appear to be steady by offsetting the contents at the same frequency in the opposite direction. If this was handled by the graphics processor it might not even be an intensive operation or produce significant battery usage.

At slower movements, (say just being held in an older unsteady hand) the accelerometer data could be fed directly into the screen offset. This would allow you to compensate for unpredictable movements.

Such a mode would cancel out shaking, producing what would appear to be a slightly smaller but steady screen. (Smaller because pixels at the edge of the screen may have ''any'' screen in the same location in the next fraction of the vibration). Gross movements that move the screen to an entirely different position would not be cancelled, effectively 'panning' to keep up with the large movement.

In situations where the hand is not experiencing the same source of vibration that the screen is, the areas of touch sensitivity should be offset at the same time as the screen. So a steady hand touching a vibrating screen isn't interpretted by the application software as a vibrating hand.

These features would best be implemented in the rendering and touch libraries so they could be activated for all applications.

==== Taping as input ====
If I understand correctly the accelerometer should be capable to be used as a simple input. When OpenMoko is in the pocket, simple taps against the pocket should be possible to use as input. For example when there is an incoming call and the user is notified using a headset then one tap would accept the call and two concurrent taps against the pocket would cancel it. This can also be used for lot more.
==== Pedometer ====
The accelerometers should be able to detect each step and record it. If the time when the step is recorded you would then be able to determine the time used walking, the distance traveled and approximate the energy used. Acording to [http://en.wikipedia.org/wiki/Pedometer Wikipedia] this has been done in other devices.
==== Others ====
Also see the pages[[Wishlist:Auto Align Map]], [[Wishlist:Determine Position]], [[Distance Measuring]], [[Wishlist:Computer Mouse]], [[Wishlist:Dynamic Screen Orientation]].

=== Connectivity ===

==== VNC ====
A good, stylus friendly VNC client/host combo would be easy to add and terribly useful.

==== Networked X-Windows ====

Whether it's running true X-Windowing over the network, or your bog-standard VNC connection as mentioned above, the ability to have your phone's screen available on your laptop or palmtop would be most desirable.

==== NX client ====

A form of X-windows forwarding optimized for performance over slow, or high-latency links, which could prove extremely useful. Capable of streaming a good quality, full desktop session over modem speeds. The protocol and at least one implementation is gpl'd. [http://en.wikipedia.org/wiki/NX_technology wikipedia]

==== OpenOffice Presenter Control ====

I Think it is a good idea to control your OO Presentation with Openmoko about WLAN or Bluetooth.
I think it needs some buttons to go back or forward and control the mouse to show something and take normal mouse clicks.
But with the mouse clicks I think that we need a short time between the clicks in example 1 second. Because when you make a mouse
click than to fast than you must go back.

Some similar functionality will be implemented during SoC 08. More info at [[OpenMoko Bluetooth remote controller]]

==== Amarok and other Media Player remote control ====

Control Amarok or any other Media Player with OpenMoko (as a remote control). Bluetooth or WLAN could be used as protocol to send and receive the data. Maybe a WebInterface of Amarok is a start. Can be used on parties for a mobile music management.

==== Read informations with SMS ====
Send a SMS with Code to the OpenMoko (from a specific number).
For example to send get the GPS coordinates from a stolen Neo (or if you don't know where your Neo is).

=== Security ===

==== General Filesystem Encryption ====

If anyone wants to get your private data saved on your OpenMoko device, he should have to get through a high security mechanism like dm-crypt. The question is how much CPU power would be needed.
Would it be an idea to encrypt only the private data like phone numbers, preferences, address book etc. (like /home/$USER).

http://luks.endorphin.org

==== My Account ====
{{Main|My Account}}
A way to securely store information about the phone, and ensure that a phone you may be considering purchasing is not stolen.

Can we keep a serial number/user registry here on the OM wiki? Not really secure, but something most thieves wouldn't know about.

==== [http://zfoneproject.com/ Zfone] or similar ====

Something that allows the user to speak with another person securely.

==== GSM Encryption ====

This software application would allow GSM encrypted calls to be made using the GSM Data Call Channel.

[[OSvS]]

==== My Voice is my Passport ====
Use voice recognition to unlock the phone. "Hi. My name is ... My voice is my passport. Verify me."

==== Firewall ====
A network firewall

==== Full Mac Support ====
Full mac support, preferably with full software and full sync capabilities with iCal and iMail

==== Anti Theft Application ====

This application would enter the phone into an [[Anti-Theft Mode]] which activates particular security features to reduce the risk of theft and also to ensure a higher probability of recovery of a stolen handset.

Hmm, if you're away from your home for more than a few days (via GPS), it starts sending its coordinates home.

====RFID based personal alerts====
Assuming an RFID reader is available: You'd put an RFID tag on your keys, wallet, etc and train a program on the phone to give you a soft or hard alert when one of them leaves detection range. That way, if you're walking away from one of them, the phone could alert you.

Actually there is a RFID reader available. Take a look at this: http://www.wdi.ca/ We only need driver for that thing. .... Well, never mind. I think it doesn't work because of the size. Anyway an interesting idea.

====OpenVPN Client====
This application allows to configure the device as an OpenVPN client using the GUI including support for X.509 certificates.

=== Integrated Help System ===

A help system that is either on or off. It could be activated and deactivated by a [[five-second-press]] on a button, for example the AUX button. When the help system is activated, it will explain the use of any item you touch on screen (with stylus or finger). Example: if you touch the battery icon, it will explain that this shows battery level / remaining time. If you touch the date / time icon, it will explain that this icon shows date and time, and that if you press it, you can set date and time. Primarily, this help system should be able to explain all user interface elements in the main screen, but if it proves popular, it could be expanded to cover other applications as well.

===Performance optimisation===
==== Use DMA engine in CPU for blitter ====
The DMA engine in the CPU can substantially speed up moving of large areas of screen in some cases.

==== Use virtual screen to optimise scrolling ====
In some other cases, the hardware supported virtual screen may also speed it up.
===Reusable Display/UI Widgets===
====Use BigPage for full page zoom, scroll, scale in many apps====
The [[BigPageWidget]] Page decribes a widget that could bring full natural page viewing, scaling, scrolling to the OM platform - allowing all applications to make intuitive UIs. A good way to read documents of any type without reformatting them massively increases the utility of a device with a small screen

==Bluetooth==

=== Voice Dialing ===

Dial by voice commands.
 Dial by dictating phone number. This way we can voice dial any number even if not in our contact list.

=== Music through Bluetooth Headset ===

Music can be played through a Bluetooth headset, but would stop playing when a call comes in.

=== Walkie Talkie ===

Let OpenMoko devices connect to one another via bluetooth or another connection method (GPRS for long distance but high latency, probably Wifi on P2), and hold a conversation.

Features for this applications can be:
* Push To Talk (PTT) button
* Voice Activated Control (VAC) which will set it in transmit mode when input has is detected above a certain predefined level.
* Optionally a full duplex mode
* Different channels to choose from
* Monitor different (preselected or all) channels for traffic.
* Content encryption
* Active noise control
* Allow zero config use (units can talk without any access point helping)
* Overview of all connected people trough sending GPS data to everyone who is in the Walkie Talkie channel

Local (non-GPRS) use cases include chatting while biking
or motorcycling in a group; perhaps also in a car caravan.
This application could also be used as a baby-phone to monitor your siblings.

This would be more useful if the Neo had Class 1 bluetooth, though probable Wifi on P2 will also offer more range.

(One thumbs up from me) Jackcday

See also [[Wish_List#WiFi_Walkie_Talkie|WiFi Walkie Talkie]] and perhaps construct one application that can handle both Bleutooth and Wifi.

=== Automatic Sync ===

Automatically synchronize with desktop computer (or with any [http://en.wikipedia.org/wiki/SyncML SyncML] server) when within range based on user profile. This may require the use of a secure data transfer.

=== GPS Assisted Bluetooth Management ===

Allow Bluetooth to automatically turn off after loosing connectivity and to automatically turn back on based upon GPS location.

A Bluetooth device is configured for automatic reacquisition based on the following profiles:
* Manual - only when Bluetooth is on
* Non-mobile - the target device is not mobile, periodically attempt reacquisition when in the general area of the device.
* Mobile - the target device is mobile, periodically attempt reacquisition when in the general area of the device.

Each target device is configured as follows:
* Automatic acquisition at last known location: enable/disable
* Automatic acquisition at these locations: list of nickname + coordinates + range

==== Non-mobile devices ====

Examples devices include: computers

The location and range of the target device is determined via training. Periodically, the current GPS coordinates and Bluetooth signal strength are logged. Additionally, connectivity loss events are logged. An algorithm uses these logs to determine the device location and range.

Connection attempts are made when in a configurable proximity to the device. The first attempt when entering the proximity and further attempts at a configurable interval.

==== Mobile devices ====

Example devices include: automobiles

Mobile devices are configured to have two types of locations:
# Last known location
# Non-mobile locations (homes)

===== Last known location =====

A car is mobile, ideally, when you leave your car, the phone should note the car's location when connectivity is lost and then attempt to reacquire the car when you return to the location of the car.

===== Non-mobile locations (homes) =====

As mobile devices may have multiple users, it is not sufficient to always use the last known location. In this case, the device may additionally have multiple homes. For example, a car might have as its homes: home garage and work parking lot.

=== Bluetooth neighbor detection and multiuser apps ===

Like the [http://en.wikipedia.org/wiki/One_laptop_per_child one laptop per child] (OLPC) interface, keep a number in the status bar that represents a count of other openmoko or compatible bluetooth devices in the area. Allow for the spontaneous initiation of a chatroom or multiplayer game or file trading with any moko in the area.

=== Bluetooth environment detection ===

Capability to detect when a predetermined bt device enters/leaves bt range and launch a system-wide event accordingly. This would feed not only the "Neighbour detection" idea described above, but also the "Profiles", "Context based TO-DO list" and "Location-based reminders" ideas. Reminders could be set to trigger in the presence of a specific person X (with BT device Y). Profiles can take into account which devices are present around the phone (car kit, for ex.). To-do list could also change according to present devices.

=== Remote control ===

==== Wireless presenter ====
Use the phone to run your OpenOffice.org Impress presentation remotely using Bluetooth. Cool features:
* Display the text notes for the presenter on the phone's display and update it whenever the slide is changing.
** OO.org has implemented support for [http://www.openoffice.org/issues/show_bug.cgi?id=12719 dual monitor]/[http://www.openoffice.org/issues/show_bug.cgi?id=18486 presenter mode] that can be used as a starting point
* A small timer showing the time passed (and perhaps remaining if the presentation app supports such a feature).
* If you want to be super-cool, you give a preview of the notes of the next slide in the show.
* At the end of a presentation, a "navigator" could allow to easily jump to any slide in the presentation by clicking on it on the phone.
** When you right-click in a running OO.org Impress presentation, you can choose "got o slide..." and select any slide to jump to.

Some similar functionality will be implemented during SoC 08. More info at [[OpenMoko Bluetooth remote controller]]

==== Initiated from another device ====
Remote control over Bluetooth from other devices to control media player (play, pause, next, previous, volume control), camera (capture image), etc.
==== Directed at another device ====
Remote control over Bluetooth to other devices to control media player, lights in your house, etc.

[http://mjr.iki.fi/software/remote-0.9.0.tar.gz Remote] is my draft of a python-based remote control app that allows you to define button sets and commands to run on the local or a remote host (through ssh, for instance). Error handling and command interface need work.--[[User:Mjr|Mjr]] 11:14, 18 October 2007 (CEST)

Z-wave uses web-browser control of devices that is said to be compatible with mobile phone browsers so should work with openmoko browser. [http://www.z-wave.com www.z-wave.com]

=== Bluetooth Car Connection ===

Have a deeper connection to the car than just handsfree speakerphone. For instance a transceiver with challenge/response systems to open, possibly even start the car. Possibly go as far as OBD connection to monitor car status on screen/log for later.

Could be done with a port of [https://garage.maemo.org/projects/carman/ Carman] or similar that can connect to an OBD2 adapter via USB or Bluetooth and display various information collect from the car, GPS, and accelerometers. --[http://wiki.openmoko.org/wiki/User:Bmk789 bmk789]

==== Dude, Where's My Car? ====

When in range of the car navigation system, remember the position (perhaps check with the car GPS). When not in range, assumme that you are not in the car, and offer the opportunity to navigate to the car's last known position. That way, you can find your car e.g. on a large parking lot.

=== [[Bluetooth powered Multi-SIM support]] ===

As the Neo1971 does not come with dual-SIM support this could be solved by joining your old bluetooth-enabled mobile to your OpenMoko-phone.

Let SIM card A be in your OpenMoko-phone and SIM card B in your old mobile:
* Incoming call on SIM card B - the OpenMoko-phone acts as a headset(Bluetooth Headset profile)
* Calling out via SIM card B - the OpenMoko-phone acts again as a headset
* Same for Short Messages/MMS/Internet
This way you'd have your old phone switched silent and connected to your OpenMoko-phone that handles all the calls and one can select which SIM card to use.
Advantage: No 'switching' between cards
Disadvantage: Second mobile needs to be in range(e.g. handbag) and charged every once in a while.

===Internet Gateway===

If the device could function as a Bluetooth router/gateway to the internet via the GPRS/data connector, then you could use it to get network connectivity from your laptop and other devices while on the road. Many smartphones can be configured as modems via Bluetooth for use as Dial-Up Networking connectors, and that should be the minimum target. Ideally, if the WiFi functionality was used so the OpenMoko could be an 802.11 router or peer to peer gateway for a laptop, this would be even better. The full bandwidth of GPRS or whatever network is available would then be available.

=== Social Networking ===

Anybody running the social networking app will be broadcasting a profile, and when certain keywords are matched with other users who are also running the application, an alert is sounded. Each mokoid can be added as a hexstring to a profile page, and xml filters can be developed for each social service to convert various keywords and interests to moko-friendly format.

=== Give userspace api control over bluetooth signal strength ===

I have tried bluetooth handsfree sets with other phones and don't get perfect reception due to low signal strength. I suppose the reason the signal is so weak is because the manufacturer wants the battery to last long on its latest charge. Can you please make the strength setting configurable by the user of the phone through an api and perhaps even through the phones gui? I would gladly waste some battery time in exchange for stronger bluetooth signal strength.

=== UMTS tether mode ===

Support UMTS via tether mode over Bluetooth (see [[UMTS]] for detailed information).

== USB ==

=== UMTS tether mode ===

Support UMTS via tether mode over USB (see [[UMTS]] for detailed information).

== WiFi ==

=== Industrial grade Wifi management ===
One annoyance I've had with Wifi enabled gadgets is that they simply keep the connections in a dumb list. What I'd like to see is more granular connection management, which enables me to specify whether a given connection is friend & family (mom's place), professional client (joe's copies and coffee), commercially available (panera), onetime use, or anything else, as well as managing router config backups, firmware images, and security keys.

: [[User:lally|Lally]] 13:01 12 May 2008 (EST) -- Profiles of connections. Mac OS (9 & X) have 'Locations', which do exactly that. A UI for setting up/choosing them is nice, plus maybe some GPS-driven autoselection.

=== Captive portal auto-login support ===
Having a nice front-end to some sort of script that checks the authenticity of a captive portal login page (SSL cert), then passes your username and password login information to automatically log you into your account would be very nice as well. This can be done with curl, but it is difficult to make it work on all captive portals out there. Perhaps just a field that you can specify "once I am connected to this AP, run this script: ".

=== WiFi Walkie Talkie ===
Provide walktie talkie functionality like http://www.domain17.net/walkietalkie/index.html See also [[Wish_List#Walkie_Talkie|Bluetooth Walkie Talkie]] and perhaps construct one application that can handle both Bleutooth and Wifi.

=== UMTS tether mode ===

Support UMTS via tether mode over WiFi (see [[UMTS]] for detailed information).

== Wireless Piggyback ==

HSDPA support and the like, so that users can connect directly with the internet with G3/G4 mobile service providers at speeds at or above 3.6 Mb/s.

== Other ==

=== Auto Update ===

A small tool which is configurable to download the latest OpenMoko and OpenMoko related software. Maybe if any internet connection is available or a minimum of bandwith is available then the auto update would download only security related or the whole system etc. .

=== Vibrate Pattern Recorder ===

An application that would allow the user to define their own vibration patterns, and possibly link them to audio files. Recording would be done in real time initiated with a "Record" button, optionally playing the associated sound file in sync with recording). While recording, the user would press and hold a button to define the timing and duration of vibration. The user would press "Stop" when finished. Vibration patterns would have the option of being looped(would terminate at some global ringtone length maximum).

One simple suggested vibration file format would be a sort of run-length encoding: First byte defines the length of a "time-slice" in milliseconds, which would determine the overall tempo(actually the inverse of tempo). The next byte would define the number of time-slices to leave the vibration on, and then another byte for how long to pause after. Continue alternating these on/off bytes until the entire pattern is defined.

- or just use MIDI, using a separate channel for the vibrator.

An implementation of RTTL could also be used to define vibration patterns.

=== PC Input Device ===

Provide a method to use the touchscreen as input device for a nearby desktop machine. Could connect over USB or bluetooth.

Could emulate a pointer device (mouse) or even keyboard using standard bluetooth/USB interfaces for such a device.

Use case: Alice is lazing on a couch and doesn't want to get up to do some minor interaction with the computer. She can see the screen and uses the OpenMoko device as a mouse and/or keyboard to interact with the computer.

=== Advanced Notification And Ringtone Manager ===
{{Main|Wishlist-ANARM}}

ANARM would be an application for handling all event-based audible notifications from an OpenMoko device.

=== Location based reminders ===
{{Main|Wishlist:Location_based_reminders}}
Location based reminders can be used to notify users of various events or reminders that are location based.

=== Synergy Client ===
A synergy client would enable the user to place the device next to a desktop PC and share the desktop`s mouse, keyboard and clipboard over a TCP/IP network. [http://synergy2.sourceforge.net/ Synergy]

=== Next device ===
List features for your fantasy device to come from FIC (or anyone else, for that matter). Define the GTA03 here ;-)

==== There is no device ====
From [http://wurp.blogspot.com/2008/01/teh-future.html Wurp's blog]:

Clearly the Next Big Thing has to be for the device to go away altogether. I know the basic idea for wearables has been around forever, but it seems to me that the time has come.

I wanna wear a bluetooth earpiece and cool shades, possibly with [ here's where my imagination is failing me :-( ] gloves, or fingerless gloves, or (ew) wristbands, and let any surface, including my hand, or no surface, be my interface. Tap the earpiece when you get a phone call, see a dial pad on your palm and tap out the number with the other hand, watch movies on a giant screen hovering in the air...

(equipment list: bluetooth earpiece, some brick in my pocket or on my belt, glasses w/ minute camera, painted video display, & variable darkness lenses, and gloves)

Why the hell do I want to dig out a device every time I want mindless entertainment or superficial conversation?

Ideally, you could then sell any little doohickey with whatever interface you want (switches, knobs, g-spots, ...) and all it needs to do is network with some software on the brick to be anything at all...

A rubberized shell, like some of the other new phones. Helps me not drop it, especially when drunken wardriving. [anon ;-)]

== GPS Software ==
* implement "Cheap GPS" as demonstrated in the image, may be useful for geocaching.
[[Image:Cheap_gps.png|right|300px|From xkcd.com :-)]]
*Providing GPS Support also for outdoor users in addition to ordinary street navigation features
** Overlay of satellite images with existing streetmaps
** Incorporating SRTM digital elevation model: for example using the VRML/X3D as data format (see http://www.ai.sri.com/geovrml/) which is interesting for e.g. mountaineering: using a 3d browser rendering VRML/X3D Model, displaying the current position and track (possibly also other gps-tracks of the different routes to a summit downloaded before could be mapped onto the 3d model), (what about 3d hardware support? there is nothing written in the hardware specs about graphics: thinking of OpenGL for embedded systems (see http://www.khronos.org/opengles/)
** Using sth like a tracking mode to allow certain people to determine the current position and track (for rescue missions - like they have for example at http://www.steiger-stiftung.de (a German beneficence for rescue issues) There you can register your mobile phone so the rescue service is able to track you immediately if necessary. The interesting thing: It seems like some mobile phones with GPS have special support for this issue. If your phone is registered, the rescue service is able to get your GPS coordinates directly from the phone without any user assistance. Openmoko should also support this! )
* Implementation of 3dTracking's (http://free.3dtracking.net/) tracking software or equivalent.
* "Geomark" function: if you have to save the current time with your current location, only hit one button...
** You also should be able to navigate with a small "compass" and the distance should be displayed to your saved point (maybe where you parked your car on a big car parking area)...
* '''Measure the distance between two points (air line or walked way) -> no need for a tape measure'''
**I think it would be good if you could either use Bluetooth, GPRS or AdHoc Wifi, and see near Neo1972 on the GPS map so you could see where your friends are, e.g "You want to know if you friend is on the bus behind" You would need a strong wifi and GPRS would be too expensive.
*A bicycle sat-nav would be cool, speciayl designed for bicycles, e.g. cycle routes
* A user friendly app to collect data for the open street map project. http://www.openstreetmap.org/
 [[Community Based Traffic Information]]

== Hardware ==
{{Main|Wish List - Hardware}}

It could be use for beepway Online service too
[http://www.beepway.com]

=== Dedicated Power / Charger Pinout ===

Having not yet seen a physical Neo device, I haven't been able to examine any of the IOs to see if there already is a dedicated power / charger input. However, I can imagine that it might be very tempting to have the device charge solely via USB. For any device that is capable of USB-host, that is a '''horrible''' idea.

Since the device is able to run in USB host mode, it might be a good idea to allow for an alternate power supply, if say, a USB keyboard was being used for several hours. Rather than drain the battery, one could just supply power via the wall outlet while still providing endless hours of USB-host enjoyment for those hard-coders on the go.

The main question is just deciding on where to take power from if in USB-client mode and the power cable is inserted, but really, that's not too big of a deal and can be solved with very minimal circuitry.

This might sound extraneous at first, but when the device shuts down in the middle of an important USB file transfer, or right before that great piece of code was saved, you can bet that those users will be saying "Hmm... a separate power adapter would have really come in handy right now".

I suggest a tiny 3mm, dedicated +5V power input (something a la Nokia).

=== Inductive charging ===

[http://en.wikipedia.org/wiki/Inductive_charging Inductive charging] is the sort of charging where you place the device in a cradle, and a coil in the cradle induces a current in a coil inside the device, allowing it to recharge without wires. This should eliminate proprietary power connections.

=== Tactile feedback via buzzer ===
Assuming the hardware has a vibrator/buzzer for silent calls, use a lightly pulsed version of that to simulate tactile feedback when dragging finger across buttons on-screen. Implemented properly, it would almost feel as if the buttons were real.
: 25 ms bump on the buzzer feels about right. Does this harm the vibrator motor? --[[User:Sagacis|Sagacis]] 05:15, 2 October 2007 (CEST)
:: Created a patch to do this [[User:Sagacis/ForceFeedback]] --[[User:Sagacis|Sagacis]] 05:05, 3 October 2007 (CEST)

=== Detachable keyboard ===
Hardware keyboard that can be attached with magnets to a future version of the Neo.

A bluetooth mini-qwerty keyboard that straps to my wrist!

: A BT keyboard would be nice, but do you need openmoko to provide it? [[http://www.intomobile.com/2007/11/07/targus-bluetooth-mobile-tumbpad-when-the-tiny-keyboard-on-your-smartphone-just-doesnt-cut-it.html Targus bluetooth keyboard]]

=== SD Card Slot ===
I think the Neo1973 should have a normal SD card slot as the micro is too small, and the SDs have more space. [unknown author]

SD Cards now support 32GB. Their storage density will always be multiples ahead of microSD (now at only 2GB). An SD Card slot will:
* Provide enough storage to '''turn an OpenMoko into a music (MP3) jukebox''' large enough for entire music collections, like an iPod with Bluetooth for the car.
* Enable '''storage''' of:
** podcasts, full-length movies, or large photo collections
** photo and video from an on-board high-res camera
** entire email database at your fingertips, even in poor phone signal areas
** more detailed maps and charts
** encrypted work databases that are not available online
* Have easy '''external access''', without requiring battery removal like the microSD card
* Support '''SDIO''' accessories
* Enable '''transfer''' of data from an external camera's full SD memory to:
** a portable USB hard drive, offsetting the need to travel with a notebook PC
** the internet, via wifi or phone network
* Enable editing of videos and photos obtained from external cameras

Without an easily accessible higher storage SD Card slot, many users will soon be playing the juggling game of which data to delete from the much smaller and harder to swap microSD card. This is especially true for OpenMoko users, who are more likely to be power users than is the average mobile phone carrying population. Why carry an OpenMoko and an iPod, when you can simply add an SD Card slot?
--[[User:Pedro|Pedro]] 20:06, 17 March 2008 (CET)

: This is not true. Now you can find 2GB micros at the price of 20-30 euros. Too small for what?? --[[User:V0n0|V0n0]] 22:06, 28 December 2007 (CET)

: Think of putting a few '''movies''' on that SD memory card. It could really help if it was a little bigger (8GB, 16GB, 32GB). Also think of going '''offline''' for 1-2 weeks, far away from any computer you can access and then wanting to listen to some music. What you get in turn with a 2 GB memory slot is the same music over and over. Or you have to switch memory a cards a lot.

: This situation is far more common than one would think: going in the mountains, going offshore (on a cruise ship). Or simply you may want to store many types of music, and '''share''' your device with friends. --[[User:Bogdanbiv|Bogdanbiv]] 13:47, 10 January 2008 (EEST)

: Well, it can be micro SD, but why to put it so deep inside, under the battery and even under the SIM card? I would suggest to have a simple slot on the side where we could insert/remove the SD card equally easily as we swap CD's in computer. [[User:AudriusA|AudriusA]] 16:36, 12 January 2008 (CET)

[[User:Cfriedt|Cfriedt]] 12:40, 24 February 2008 (CET) -- I completely agree with a more accessible SD card slot. It should be made external for quick removal / insertion. I realize that would mean program data shouldn't reside on the SD, but really 256 MB of on-board flash is plenty. Micro or normally-sized, a regular-sized SD is still trivial to implement in terms of solder pads and traces.

: Sorry, but this looks like useless chat. Micro-SD cards are perfect for mobile devices as they don't get too much space on the pcb. Also, we can find micro-sd up to 8gb, if you want more space just wait a while and they'll produce a bigger one in a few months :-p. Really, almost every single phone that has a sd slot has in its micro version, why would we need a full-sized, huge normal sd slot ? It gets too much space on the pcb it's not only about sw configuration or pin soldering, it's more regarding pcb layout.

: What about something like this adapter[http://linitx.com/viewproduct.php?prodid=11922]? Is there any place in the case left to put this into? Nevertheless there is a 12GB microSD card announced from SanDisk and a 8GB card costs about 40€ or 15€ for 4GB. (But a 8GB SD card costs only about 25€) --[[user:kelvan|Kelvan]]

: Maybe just an additional microSD that is easily accessible and hot-swappable. I imagine replacing the huge lanyard hole could help with this. --[[User:Sin|Sin]] 02:30, 4 May 2008 (CEST)

: My thoughts exactly. Two slots: 1 internal microSD for our storage, and a second external one for more immediate expansion. My thoughts are more towards hardware expansion. For example, some of us could put in a second wifi card that does have promiscuous mode. External VGA connections, etc would also be possible. The external slot should be chosen by availability of hardware expansions as well as memory availability/price. --[[User:lally|Lally]] 13:01 12 May 2008 (EST)

=== IR port ===
Remote control applications

Would be great to use openmoko as a Harmony remote controller.

:I'd like to add that i fully support this. An IR port on future openmoko devices capable of controlling set-top boxes like TV/DVD/Stereo is necessary to make the device as universal as possible. A cellphone should be your window to the world and allow you to interact with it in as many ways as possible.

:Care must be taken to use the correct type of IR chipset/controller in the phone. Most IR ports you find on devices like computers, some cellphones etc. Are for high speed data communication and CAN'T control TVs/DVDplayers/Stereos etc.

:In order to reduce cost it maybe possible to use the sound chipset in the phone to generate the waveform sent to the IR led. IR remotes work at ~38Khz which is within the range of the sound chipset. The sound output could be internally switched between the IR led or the speakers.

[[Category:User]]
[[Category:Ideas| ]]

Talk:MokoMakefile

2008-06-10T05:04:45Z

Peterpall: /* A new section about Hardy Heron */

== MokoMakefile won't work on Ubuntu Hardy Heron ==
Hello, there!

Since my upgrade to Hardy Heron MokoMakefile seems to be broken on my ubuntu box. I already tried several times to download a new Makefile into a fresh directory - without success. What I get is always:

:~/moko$ make image
( cd build && . ../setup-env && \
( bitbake openmoko-devel-image u-boot-openmoko ) )
ERROR: Openembedded's config sanity checker detected a potential misconfiguration.
Either fix the cause of this error or at your own risk disable the checker (see sanity.conf).
Following is the list of potential problems / advisories:

/proc/sys/vm/mmap_min_addr is not 0. This will cause problems with qemu so please fix the value (as root).

make: *** [openmoko-devel-image] Error 1

For another report on this problem see also: http://lists.openmoko.org/pipermail/community/2008-May/017545.html

== The paths that are mentioned on this page are partially wrong ==
I am not sure enough what the paths should be, but - two things have changed since the section "developing with mokomakefile/How to add your own shiny new application" of this page was created:
- The path where the packages are kept, and
- Where to add the information that we have added a new package.

== Ubuntu Edgy: Update git-1.4.x to 1.5.x! ==
With old git-1.4.x, fetching uboot does not work: Use 1.5.x:
<pre>
NOTE: package uboot-gta01-1.2.0+svnnow-r4_14da5f7675bbb427c469e3f45006e027b6e21db9_0_1811: task do_fetch: started
fatal: corrupted pack file .git/objects/pack/pack-a146bcbc18f4826d6bf2a7f63be5dd77bbb5b2f5.pack
</pre>

== Fails on a 32bit machine - try again without ccache? ==

<pre>/bin/sh ./libtool --mode=compile ccache gcc -DHAVE_CONFIG_H -I.... -W... -O2 -c -o libbfd.lo build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17/bfd/libbfd.c
ccache gcc -DHAVE_CONFIG_H -I... -W... -O2 -c /usr/local/oe/build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17/bfd/libbfd.c -o t shift count >= width of type
make[5]: *** [libbfd.lo] Error 1
</pre>

Any insight here? --[[User:Adam|Adam]] 23:10, 15 May 2007 (CEST)
: Try without ccache (did you get it compiled meanwhile or can we remove this?) --[[User:BernhardKaindl|BernhardKaindl]] 23:05, 19 September 2007 (CEST)

== Facing Problems with ogg libraries ==
just get the path and delete the .bb file that causes the problem
== Building on Fedora Core 6 ==

Install stuff needed for OpenMoko:
# yum install python m4 make wget curl ftp cvs monotone subversion \
tar bzip2 gzip unzip python-psyco ccache perl texinfo texi2html \
diffstat openjade docbook-style-dsssl docbook-style-xsl docbook-dtds \
docbook-utils sed bison bc glibc-devel gcc binutils pcre pcre-devel git \
quilt groff linuxdoc-tools patch compat-gcc-34 lynx netpbm
(notice ''compat-gcc-34'' wich was needed for FC6 (gcc 4 installed), and ''lynx'' which is needed by ''qemu'' (no fallback to ''wget'', ''curl'', or ''links'' at the moment and no check for it, resulting in strange "sleep" errors when trying to build without ''lynx'').

Build it:
$ make setup
$ make openmoko-devel-image
$ unset LD_LIBRARY_PATH
$ make update-makefile && make update && make setup && make openmoko-devel-image

I have also done a
$ unset LD_LIBRARY_PATH; make update-makefile && nice make update && nice make setup && nice make all
(This takes several hours)

Build qemu:
$ make qemu

Run it:
# echo 1024 > /proc/sys/dev/rtc/max-user-freq
$ make run-qemu
This will bring up the OpenMoko :) Use SPACE for AUX and ENTER for POWER.
Not quite the same as holding a Neo1973 in your hands I would guess, but this is the best we can do for now. Thanks!

== Building on Ubuntu Feisty ==

MokoMakefile requires more than 512 MB of RAM + Swap space (around 1GB?).

If you need swap, please '''check that its size under Feisty is not null'''!

[https://bugs.launchpad.net/ubuntu/+bug/105490 Bug #105490] describes the current issue and offers a workaround (23 Jul 07).

== Fails trying to build bluez-utils ==
on Gentoo Linux, it fails compiling bluez-utils (I've tried also "make clean-package-bluez-utils" before the following command)

do a "make build-package-libusb; make clean-package-bluez-utils" and it should continue (the bluez-utils .bb is missing the libusb dependency)

== openSUSE 10.1 and 10.2 workarounds ==

ltrace package fails to build with error:
<pre>
...
checking for pid_t... yes
checking for getopt... yes
checking for getopt_long... yes
checking gelf.h usability... no
checking gelf.h presence... no
checking for gelf.h... no
configure: error: ***** gelf.h not found *****
FATAL: oe_runconf failed
</pre>

'''FIX: '''
edit ''/home/moko/build/tmp/work/armv4t-linux/ltrace-0.4-r0/ltrace-0.4/configure.ac''
at line 44: remove the following block:
<pre>
for path in /usr/include/elfutils /usr/local/include/elfutils \
/usr/include/libelf /usr/local/include/libelf; do
if test -f ${path}/gelf.h; then
CPPFLAGS="$CPPFLAGS -I ${path}"
fi
done
</pre>
( it adds /usr/include/elfutils to path, which causes cross-compile badness error )

=== QEMU build fails to compile USB code ===
<pre>
/usr/include/linux/usbdevice_fs.h:116: error: variable or field `__user' declared void
/usr/include/linux/usbdevice_fs.h:116: error: syntax error before '*' token
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c: In function `usb_host_handle_control':
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:103: error: invalid application of `sizeof' to incomplete type `usbdevfs_ctrltran
sfer'
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c: In function `usb_host_handle_data':
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:120: error: storage size of 'bt' isn't known
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:132: error: invalid application of `sizeof' to incomplete type `usbdevfs_bulktran
sfer'
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:120: warning: unused variable `bt'
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c: In function `usb_host_device_open':
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:199: error: storage size of 'ctrl' isn't known
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:202: error: invalid application of `sizeof' to incomplete type `usbdevfs_ioctl'
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:199: warning: unused variable `ctrl'
make[2]: *** [usb-linux.o] Error 1
</pre>

'''FIX: '''
edit ''/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c''
at line 29 add the following (before ''#include <linux/usbdevice_fs.h>'')
<pre>
#include <linux/compiler.h>
</pre>
hint: there is a copy of the file in ''/home/moko/build/tmp/work/i686-linux/qemu-native-0.9.0+cvs20070613-r5/qemu/usb-linux.c''

''see: http://osdir.com/ml/emulators.kvm.devel/2007-01/msg00101.html''

== Cannot satisfy fstests ==
<pre>
make openmoko-devel-image
...
| Collected errors:
| ERROR: Cannot satisfy the following dependencies for task-openmoko-debug:
| fstests
NOTE: Task failed: /no-backup/Moko/build/tmp/work/fic-gta01-linux/openmoko-devel-image-1.0-r0/temp/log.do_rootfs.25036
NOTE: package openmoko-devel-image-1.0-r0: task do_rootfs: failed
ERROR: TaskFailed event exception, aborting
</pre>
Failed on debian etch 2007-07-20
Solution from mailing list post from hardskinone, report of an irc chat
<pre>
I got help in IRC channel. I do following steps
* remove fstest from oe/packages/tasks/task-openmoko.bb ,
* increase PR field by one
* make openmoko-devel-image
</pre>

== conflicting types for 'futimens' ==

if you encounter the following error:

| In file included from utimecmp.c:40:
| utimens.h:2: error: conflicting types for 'futimens'
| /usr/include/sys/stat.h:370: error: previous declaration of 'futimens' was here

a patch is needed because your glibc is too new. grab & enable the patch as follows

cd openembedded/packages/coreutils
mv coreutils_5.3.0.bb coreutils_5.3.0.orig
wget http://www.openembedded.org/repo/org.openembedded.dev/packages/coreutils/coreutils_5.3.0.bb
cd -
cd openembedded/packages/coreutils/coreutils-5.3.0
wget http://www.openembedded.org/repo/org.openembedded.dev/packages/coreutils/coreutils-5.3.0/futimens.patch
cd -

== Workaround for problems compiling mtd-utils ==

Change the line on <code>openembedded/packages/mtd/mtd-utils_1.0.0+git.bb</code> which reads:

SRC_URI = "git://git.infradead.org/mtd-utils.git;protocol=git;tag=master \

to:

SRC_URI = "git://git.infradead.org/mtd-utils.git;protocol=git;tag=a6fa706fe9e7696b4b2045edf9698c3bac07e3e3 \

which forces the recipe to use an older revision (the one which worked last time I built the image on my computer).

Be sure to remember to undo the change later, or else you will not get any new changes to that package. --[[User:CesarB|CesarB]] 04:48, 25 July 2007 (CEST)

Note: these patches should be updated - the lzo patch is included in the current version, so backing off to the previous version and repatching seems silly. I was able to make it through this part of the build by applying the remaining patches manually. --[[User:Mellon|Ted Lemon]] 15:44, 29 July 2007 (CDT)

== Monotone segfaulting on Ubuntu Feisty Fawn/PPC ==
If you are running Ubuntu Feisty Fawn on a PowerPC computer you will experience problems running monotone. To fix this issue you need to install monotone as well as the libboost packages from Gutsy. The easiest way to accomplish this is to add the gutsy repositories to your sources.list
and change the preferences to look like this:

Package: *
Pin: release a=feisty
Pin-Priority: 700

Package: *
Pin: release a=gutsy
Pin-Priority: -100

Package: libc6 libc6-dev tzdata util-linux libgcc1 libstdc++6 monotone
Pin: release a=gutsy
Pin-Priority: 800

Package: libboost-*
Pin: release a=gutsy
Pin-Priority: 800

After doing this install monotone in this way:
apt-get -t gutsy install monotone.
That should install monotone 0.35 with updated (and working) boost libraries.

== Fails on ncurses install in Fedora 7 with a "tic -x" message ==
Adjust the following command to your system, then run it:
export LD_LIBRARY_PATH=/home/moko/build/tmp/work/x86_64-linux/ncurses-native-5.4-r8/ncurses-5.4/lib
Then start make again and it should pick up where it left off.

You can get a list of potential paths to use with the following command from you main moko directory:
find . | grep libncurses

The basic problem is that it is linking against your main system libraries instead of the OpenEmbedded ones.

There's probably a cleaner way of handling this - please update this entry if you know it.

This has been fixed in Openembedded, see [http://bugs.openembedded.org/show_bug.cgi?id=2554 Openembedded Bug #2554] for further details.

== uboot-gta01 fails to build ==
Changes in the GIT of U-Boot make the OpenMoko patches unapplyable. For the use of Revision ''cc3023b9f95d7ac959a764471a65001062aecf41'' and everything will be fine for now.

== Perl fails to build ==
After following every bit of advice I can find to 'make clean' and nuke the perl build directories, every build comes up with:

| make[1]: Entering directory `/src/openmoko/build/tmp/work/i686-linux/perl-native-5.8.7-r3/perl-5.8.7'
| make[1]: *** No rule to make target `<command-line>', needed by `miniperlmain.o'. Stop.
| make[1]: Leaving directory `/src/openmoko/build/tmp/work/i686-linux/perl-native-5.8.7-r3/perl-5.8.7'
| FATAL: oe_runmake failed
NOTE: Task failed: /src/openmoko/build/tmp/work/i686-linux/perl-native-5.8.7-r3/temp/log.do_compile.19531
NOTE: package perl-native-5.8.7-r3: task do_compile: failed

Solution turned out to be editing
/src/openmoko/build/tmp/work/i686-linux/perl-native-5.8.7-r3/perl-5.8.7/makedepend.SH and at line 169 change the regexp to eat references to "<command.line>" to catch what was leaking through.

== Gettext fails to build ==
Gettext's build is broken unless you have emacs installed. Crazy though it seems. You will see an error like:

<pre>

| WARNING: Warnings can be ignored. :-)
| if test "no" != no; then \
| set x; \
| list='po-mode.el po-compat.el'; for p in $list; do \
| if test -f "$p"; then d=; else d="./"; fi; \
| set x "$@" "$d$p"; shift; \
| done; \
| shift; \
| EMACS="no" /bin/bash ../../config/elisp-comp "$@" || exit 1; \
| if test "no" != no; then \
| set x; \
| list='po-mode.el po-compat.el'; for p in $list; do \
| if test -f "$p"; then d=; else d="./"; fi; \
| set x "$@" "$d$p"; shift; \
| done; \
| shift; \
| EMACS="no" /bin/bash ../../config/elisp-comp "$@" || exit 1; \
| else : ; fi
| mv: cannot move `elc-temp' to `elc-stamp': No such file or directory
| make[5]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools/misc'
| make[5]: *** [elc-stamp] Error 1
| make[5]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools/misc'
| make[4]: *** [po-mode.elc] Error 2
| make[4]: *** Waiting for unfinished jobs....
| make[4]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools/misc'
| make[3]: *** [all-recursive] Error 1
| make[3]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools'
| make[2]: *** [all] Error 2
| make[2]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools'
| make[1]: *** [all-recursive] Error 1
| make[1]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1'
| FATAL: oe_runmake failed

</pre>

The solution is simple - install emacs (example below for debian/ubuntu) and try again:

<pre>

sudo apt-get install emacs
make clean-package-gettext-native-0.14.1-r5
make openmoko-devel-image

</pre>

== Building OpenMoko with chroot ==

There may be hundreds of issues which may cause that OpenMoko fails to build on your system, so it might be more straightforward to just install a standardized build environment in which the openmoko build runs in chroot, independent of your distribution.

There is now a (not fully working) script which is able to set up a 32-bit openSUSE 10.3 build environment for building OpenMoko posted on distro-devel: [http://lists.openmoko.org/pipermail/distro-devel/2007-November/000076.html]

On gentoo and debian-like distribution, you can use debootstrap to quickly setup a base chroot.

== Fails compiling binutils-cross on Gentoo/AMD64 and openSUSE/x86_64 ==

make setup works fine, but when running make openmoko-devel-image it fails with the following:

<pre>
| make[4]: Entering directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi/libiberty/testsuite'
| make[4]: Nothing to be done for `install'.
| make[4]: Leaving directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi/libiberty/testsuite'
| make[3]: Leaving directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi/libiberty'
| make[2]: Nothing to be done for `install-target'.
| make[2]: Leaving directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi'
| make[1]: Leaving directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi'
| rmdir: build/tmp/cross//home/techiem2/Moko/build/tmp/cross/lib/gcc-lib: No such file or directory
| rmdir: build/tmp/cross//home/techiem2/Moko/build/tmp/cross/lib: No such file or directory
| rmdir: build/tmp/cross//home/techiem2/Moko/build/tmp/cross: No such file or directory
| mv: cannot stat `build/tmp/cross/lib/libiberty.a': No such file or directory
NOTE: Task failed: build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/temp/log.do_stage.9730
NOTE: package binutils-cross-2.18-r0: task do_populate_staging: failed
ERROR: TaskFailed event exception, aborting
NOTE: package binutils-cross-2.18: failed
ERROR: Build of openembedded/packages/binutils/binutils-cross_2.18.bb do_populate_staging failed
ERROR: Task 1641 (openembedded/packages/binutils/binutils-cross_2.18.bb, do_populate_staging) failed
NOTE: Tasks Summary: Attempted 107 tasks of which 107 didn't need to be rerun and 1 failed.
ERROR: 'openembedded/packages/binutils/binutils-cross_2.18.bb' failed
make: *** [openmoko-devel-image] Error 1
</pre>

The final reason why the build cannot continue is:
mv: cannot stat `/home/techiem2/Moko/build/tmp/cross/lib/libiberty.a': No such file or directory

=== The lib64 issue ===

Likely, Gentoo/AMD64 uses lib64 instead of lib as the library directory for x86_64 libraries. It's l likey that may (or all?) AMD64 distributions do for their 64-bit binaries. On openSUSE-x86_64, the same happens. Debian/x86-64 seems to either not use lib64 or is somehow supported by the openmoko distribution.

On multilib/lib64 platforms like Gentoo/x86_64 and openSUSE-x86_64, the openmoko build runs into a final problem at the end of build: It tries to use fakeroot which uses LD_PRELOAD to fake a different root directory and in the final stages, after hours of compiling, fakeroot execution causes warning messages because on multilib/lib64 systems as they have two versions of many libraries, the 64-bit libraries are in /lib64, /usr/lib64 and oder lib64 paths, while the 32-bit libraries are in /lib, /usr/lib and other lib paths. Some tool on these lib64 distributions are adapted to install 64-bit libraries to lib64, but this seems to fail when cross-compiling.

At least on openSUSE-10.3 the missing libiberty.a was installed to build/tmp/cross/lib64/libiberty.a, which looks wrong, and it is if this libiberty.a file contains 32-bit arm objects. If it contains 64-bit x86_64 objects, it's fine, but openembedded/openmoko is not expecting it in a lib64 directory. I am not sure what is the case.

The lib64 fakeroot issue requires to change the openembedded build scripts, which is doable. But it's not very easy to find the correct script and patch it correctly. If you feel adventourus, go ahead and try to build openmoko on a lib64 distribution, but it's easyer to set up a complete 32-bit chroot environment and run a normal build in it.

After seeing this, I assumed that openmoko/openembedded was clearly not tested with lib64 build hosts and since that would mean that even if I'd fix that error, many others could follow, and as I was not interested to fix the lib64 bugs but rather wanted to see something running first, I decided to make openmoko/openembedded think that it was running on a normal 32-bit non-lib64 machine.

There are several ways to do that:
* You install an IA32-Linux somewhere and use that for building:
** Do a native install and dual-boot the IA32-linux (That's for dummies which do not know the other tricks)
** Install IA32-Linux in a virtual machine (Quite some setup and has some overhead too)
* you can install a 32-bit development system in to a chroot jail and compile there (also quite some setup and inconvinience)
* Or you can install a 32-bit development system on the 64-bit host (suppored on openSUSE, should be possible with Gentoo/AMD64 too)

=== Building on SuSE Linux 10.3-AMD64 with -m32 (not finished) ===

Install the following packages for the 32-bit C/C++ compiler target option -m32 to work and to compile what is needed

gcc42-32bit gcc42libgcc42-32bit glibc-devel-32bit libstdc++-devel-32bit ncurses-devel-32bit zlib-devel-32bit (maybe also gtk2-devel-32bit)

The openSUSE 10.3-AMD64 has no libopenssl-devel-32bit, but you can install the 32-bit rpm from the i586 10.3 rpm tree:

libopenssl-devel

You should also make sure that gdbm-devel is not installed.
The multilib support in ld has an issue which surfaces when it is called from perl's Configure script to complile a test program with -Lgdbm. If gdbm-devel is installed, it finds /usr/lib64/libgdbm.so, but since it's not compatible with 32-bit, it skips it, but also does not search the specified -Lpath where the OpenEmbedded-built libgdbm.so is already installed. To work around this, uninstall /usr/lib64/libgdbm.so with:
rpm -e gdbm-devel

Note these need to be the 32-bit cpp33 and gcc33 rpms as the 64-bit gcc33 rpms for openSUSE do not support the 32-bit target.

To make the OpenMoko build think that its running on 32-bit i686, use linux32 (changes uname -m to i686 in the new shell):

linux32 bash

And set up gcc scripts which force the use of gcc-3.3 (it can only generate 32-bit assembly) for all compilation:

mkdir bin;cd bin
echo '/usr/bin/${0##*/}-3.3 -m32 "$@"' >gcc
echo '/usr/bin/${0##*/} -m elf_i386 "$@"' >ld
echo '/usr/bin/${0##*/} --32 "$@"' >gas
sed -i '1i#!/bin/sh' gcc gas ld
chmod 755 gcc gas ld
ln -s gcc cc
ln -s gcc c++
ln -s gcc g++
ln -s gas as
echo PATH=\""$PWD":\$PATH\" >.setup-gcc-m32
cd -

Then set the path and test it:

source bin/.setup-gcc-m32
type gcc

== More package requirements ==

On my system (Kubuntu 6.10) build failed with message "ERROR: QEMU requires SDL or Cocoa for graphical output" because package <tt>libsdl-image1.2-dev</tt> was missing. Use <tt>apt-get install libsdl-image1.2-dev</tt> to install. Additionally I had to install packages <tt>cvs</tt> and <tt>diffstat</tt>. I was also asked to install Psyco JIT Compiler (package <tt>python-psyco</tt>) to increase performance. Nevertheless <tt>make flash-qemu-local</tt> took some hours, but now I finally can get an impression of the phone that I am looking for! -- [[User:Nichtich|Nichtich]] 00:26, 20 September 2007 (CEST)

== pango-directfb failed to build due to missing Glib 2.14.x ==

The latest(as of Sept. 25, 2007) build started to fail with the following error:

| checking for GLIB... no
| configure: error:
| *** Glib 2.14.0 or better is required. The latest version of
| *** Glib is always available from ftp://ftp.gtk.org/.
| FATAL: oe_runconf failed
NOTE: Task failed:
/media/sdc1/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/\
pango-directfb-1.18.1-r0/temp/log.do_configure.19927
NOTE: package pango-directfb-1.18.1-r0: task do_configure: failed
ERROR: TaskFailed event exception, aborting
NOTE: package pango-directfb-1.18.1: failed
ERROR: Build of /media/sdc1/moko/openembedded/packages/pango/\
pango-directfb_1.18.1.bb do_configure failed

The Glib included in the build tree seems to be only 2.12.12, so looks like something
is broken in term of dependency.

This had happened on both of Fedora 7 and Debian Etch. I am running the latest
MokoMakefile with OM-2007.2. The funny thing is that the build had worked only
couple nights ago. Any idea? I will update anything I find here and also on my blog(see my user profile).
[[User:ttz|ttz]] Wed Sep 26 12:17:33 CDT 2007

pango-directfb had been removed from OE for now due to the report of it breaking builds like OpenMoko.

[[User:ttz|ttz]] Thu Oct 4 10:20:12 CDT 2007

== uicmoc4 failes to compile ==

This is solved by installing libz-dev

Or, look at [http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=747 Bug #747]

== svn: REPORT request failed on '/repos/tasks/!svn/vcc/default' ==

osiris$ make update
...
Fetching external item into 'trunk/src/target/OM-2007.2/applications/openmoko-today2/libkoto'
svn: REPORT request failed on '/repos/tasks/!svn/vcc/default'
svn: REPORT of '/repos/tasks/!svn/vcc/default': 200 OK (http://svn.o-hand.com)
make: *** [update-openmoko] Error 1

osiris$ cd openmoko/trunk/src/target/OM-2007.2/applications/openmoko-today2//libkoto/
osiris$ svn up -r HEAD
svn: REPORT request failed on '/repos/tasks/!svn/vcc/default'
svn: REPORT of '/repos/tasks/!svn/vcc/default': 200 OK (http://svn.o-hand.com)

Anyone know about this one?
--[[User:Blackh|Blackh]] 00:11, 12 October 2007 (CEST)

== bootparam_prot.h fails to install in glibc-intermediate-2.5 package (Debian sid) ==

| install: cannot stat
`/home/blackh/src/openmoko/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/
glibc-intermediate-2.5-r7/glibc-2.5/sunrpc/rpcsvc/bootparam_prot.h'
No such file or directory
NOTE: Task failed: /home/blackh/src/openmoko/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/
glibc-intermediate-2.5-r7/temp/log.do_stage.3940

For some reason, on Debian, the rpcgen command needs "-Y /usr/bin" added to the end of it or it won't work ("cannot find any C preprocessor (cpp)"). This can be fixed by hand...

cd /home/blackh/src/openmoko/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/
glibc-intermediate-2.5-r7/glibc-2.5/sunrpc/rpcsvc
for f in *.x ; do rpcgen -h $f -o ${f%%.x}.h -Y /usr/bin ; done

This command will generate the right files and you can resume the build with

make openmoko-devel-image

Here is a better fix - put this script, calling it rpcgen, somewhere in your PATH before /usr/bin:

#!/bin/sh
exec /usr/bin/rpcgen -Y /usr/bin "$@"

--[[User:Blackh|Blackh]] 05:17, 12 October 2007 (CEST)

== Cannot find SVN openmoko-terminal2 ==
I'm having an issue when building MokoMakeFile where it is unable to find http://svn.openmoko.org/trunk/src/target/OM-2007.2/applications/openmoko-terminal2. Any ideas on how to fix this?

--[[User:cartera|cartera]]

== problem with make openmoko-devel-image ==

when i try to do my first make openmoko-devel-image I obtain this error:

<pre>
NOTE: Running task 844 of 5445 (ID: 671, /home/xraver/moko/openembedded/packages/linux/linux-openmoko_2.6.24+git.bb, do_fetch)
NOTE: package linux-openmoko-2.6.24+git20080422: started
NOTE: package linux-openmoko-1_2.6.24+git20080422-r0: task do_fetch: started
NOTE: fetch http://downloads.openmoko.org/sources/git_git.openmoko.org.git.kernel.git_4194.tar.gz
--08:47:41-- http://downloads.openmoko.org/sources/git_git.openmoko.org.git.kernel.git_4194.tar.gz
=> `/home/xraver/moko/sources/git_git.openmoko.org.git.kernel.git_4194.tar.gz'
Risoluzione di downloads.openmoko.org in corso... 88.198.93.219
Connessione a downloads.openmoko.org|88.198.93.219:80... connesso.
HTTP richiesta inviata, aspetto la risposta... 404 Not Found
08:47:41 ERRORE 404: Not Found.
</pre>

In this location http://downloads.openmoko.org/sources/ the file git_git.openmoko.org.git.kernel.git_4194.tar.gz does not exist.
Any solutions?

--[[User:xraver|Giorgio Ravera]]

User:Peterpall

2008-05-08T07:08:54Z

Peterpall: New page: I'm the maintainer of the [http://projects.openmoko.org/projects/audiorec audiorec] project that has started about when the first GTA01 cellular phones came around. Even if I programmed a...

I'm the maintainer of the [http://projects.openmoko.org/projects/audiorec audiorec] project that has started about when the first GTA01 cellular phones came around.

Even if I programmed a lot till now (I am a Hardware/software design engineer) this project was the first time I actually tried to access gnome from the C side.

Getting Started with your Neo FreeRunner

2008-05-04T11:50:18Z

Peterpall: /* More automatic. */

{{Languages|Getting Started with your Neo FreeRunner}}

Thank you for purchasing this Developer release of Neo FreeRunner.
This guide will help you know your Neo FreeRunner and explain how to:

*Flash new kernel
*Flash new root filesystem
*Connect to Neo FreeRunner

==Contents==
*What Is In The Box
*Getting To Know Neo FreeRunner
*Turning On Neo FreeRunner
*Flashing Neo FreeRunner
*Connect To Neo FreeRunner By USB Networking

==What Is In The Box==
*Neo FreeRunner
*Stylus
*Battery
*Charger
*USB Cable
*microSD Card 512MB

==Getting To Know Neo FreeRunner==
===Turning On Neo FreeRunner===
There are three ways to boot your Neo FreeRunner. You can power up into an Openmoko Image directly.
Alternately, you may also boot into U-Boot via NAND Flash or NOR Flash, which will allow you to update the kernel and root filesystem.

====Log in Openmoko Image====
Press and hold Power button until Openmoko splash screen turns up. You may now release the Power button, and Neo FreeRunner will continue to boot into Openmoko Image.

====Log in U-Boot in NAND Flash====
Press and hold Power button, then press and hold AUX button. You can see BOOT MENU for NAND Flash.

You can download the connection tool from : http://svn.openmoko.org/developers/werner/neocon

Connect Neo FreeRunner to Linux host with USB cable and key in the command in the terminal of Linux host.

./neocon /dev/ttyACM0

[Open]
In: usbtty
Out: usbtty
Err: usbtty
PCB rev: 0x000
switching led 2 0
switching led 2 1
switching led 2 0
DEVICE_CONFIGURED: 1
GTA02v5#

====Log in U-Boot in NOR Flash====
Press and hold AUX button, then press and hold Power button. Release AUX button. You can see BOOT MENU for NOR Flash.

You can download the connection tool from : http://svn.openmoko.org/developers/werner/neocon

Connect Neo FreeRunner to Linux host with USB cable and key in the command in the terminal of Linux host.

./neocon /dev/ttyACM0

[Open]
##Executing script at 18050100
mtdparts mtdparts=physmap-flash:-(nor);neo1973-nand:0x00040000(u-boot),0x00040000(u-boot_env),
0x00800000(kernel),0x000a0000(splash),0x00040000(factory),0x0f6a0000(rootfs)
Ready.
DEVICE_CONFIGURED: 1
GTA02v5#

===Flashing Neo FreeRunner===
As Openmoko development continues, Openmoko regularly releases updated versions of the Openmoko root filesystem, the kernel, and the U-Boot. These may be programmed into the Flash memory of Neo FreeRunner. You can use the USB cable and Openmoko provided tool to flash Neo FreeRunner.

Neo FreeRunner needs to boot into U-Boot when flashing.

You can download the flashing tool from:
http://buildhost.openmoko.org/daily/neo1973/deploy/glibc/images/neo1973/dfu-util

====Flashing Kernel====
You can download the latest kernel from :
http://buildhost.openmoko.org/daily/neo1973/deploy/glibc/images/neo1973/

Key in the command in the terminal of Linux host.

./dfu-util -a kernel -R -D uImage-2.6.24+svnr4082-r4055-r3-neo1973.bin

When flashing succeeds

status(0) = No error condition is present 
Done!

====Flashing Root Filesystem====
You can download the latest root filesystem from :
http://buildhost.openmoko.org/daily/neo1973/deploy/glibc/images/neo1973/

Key in the command in the terminal of Linux host.

./dfu-util -a rootfs -R -D openmoko-devel-image-fic-gta02.jffs2

When flashing succeeds

status(0) = No error condition is present 
Done!

====Connect To Neo FreeRunner By USB Networking====

Connect Neo FreeRunner to Linux host with USB cable. After booting into Openmoko image, there will be a new interface, usb0, in your Linux host.

=====Manual Method=====
Key in the command in the terminal of Linux host.

ifconfig usb0 192.168.0.200 netmask 255.255.255.0
ssh root@192.168.0.202

Press Enter to pass the password.

=====Automatic Method=====
*Ubuntu
Edit /etc/network/interfaces

auto usb0
iface usb0 inet static
address 192.168.0.200
netmask 255.255.255.0

Restart the networking service and key in the command in the terminal of Linux host.

ssh root@192.168.0.202

Press Enter to pass the password.
=====Making things even more automatic=====
If you don't want to remember the IP number of your phone you can create an alias by adding the following line to your /etc/hosts:

192.168.0.202 openmoko

Now it should immediately be possible to connect your phone using the following command line:

ssh root@openmoko

[[Category:Software]]
[[Category:Documentation]]

Building a hello world application

2008-05-04T11:10:16Z

Peterpall: /* The configuration of the autotools */

=== Preparation ===
This guide assumes that you have performed the steps in [[Building_OpenMoko_from_scratch]]

=== The commandline program ===
Store the following more or less standard hello world code in hello.c

#include <stdio.h>

int main()
{
printf ("Hello World\n");
return 0;
}

=== Compiling it the ''wrong'' / easy way ===
Assuming your current working directory is '''/home/moko''', and that you stored the code in '''/home/moko/hello.c''' it should now be possible to compile the application using
./build/tmp/cross/arm-linux/bin/gcc -o hello hello.c

==== Testing it ====
Assuming you have followed [[OpenMoko_under_QEMU#Setting_up_USB_connection|Setting up USB connection]] and you have a working network connection to either a qemu Neo or a real Neo.
scp hello root@192.168.0.202:/tmp/
ssh root@192.168.0.202 /tmp/hello
This sequence of commands ought to give you a nice ''Hello World'', btw. the default root password is blank, just press return.

=== GDK the Wrong / Easy Way ===
Building a GDK application the wrong way is slightly more complex, but is still fun to try. It requires using pkg-config to specify including and linking with the ARM header files and libraries.

Given the following program as main.c:

#include <gtk/gtk.h>

gchar *hello = "Howdy";
gchar *world = "World";
GtkWidget *label;
gchar *labeltext;

void buttoncb(GtkWidget *widget, gpointer data)
{
if (labeltext == hello)
{
labeltext = world;
gtk_label_set_text(GTK_LABEL(label), labeltext);
}
else if (labeltext == world)
gtk_main_quit();
}

int main(int argc, char *argv[])
{
GtkWidget *window;
GtkWidget *button;

gtk_init(&argc, &argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
button = gtk_button_new();
labeltext = hello;
label = gtk_label_new(labeltext);
gtk_container_add(GTK_CONTAINER(button), label);
g_signal_connect(G_OBJECT(button), "clicked", G_CALLBACK(buttoncb), NULL);
gtk_container_add(GTK_CONTAINER(window), button);
gtk_widget_show_all(window);
gtk_main();

return 0;
}

You must first point pkg-config to the proper directory:

export PKG_CONFIG_PATH=/home/username/moko/build/tmp/staging/arm-linux/lib/pkgconfig

And set up an environment variable to make things easier:

export OMDIR=/home/username/moko

The compile/link line is rather long - you will only want to do this once before you decide to create a shell script or make file:

$OMDIR/build/tmp/cross/arm-angstrom-linux-gnueabi/bin/gcc -L $OMDIR/build/tmp/staging/arm-angstrom-linux-gnueabi/lib/ \
-Wl, rpath-link, $OMDIR/build/tmp/staging/arm-angstrom-linux-gnueabi/lib/ -Wl, -O1 -g -o hw main.c \
'$OMDIR/build/tmp/staging/i686-linux/bin/pkg-config --cflags --libs openmoko-libs gtk+-2.0'

Then copy and run as in the original hello world command line program above.

===== Why was it the ''wrong'' way? =====
OpenMoko provides a precompiled [[Toolchain]] package for that. It also comes with some scripts that make your life much easier. Besides, you don't need [[OpenEmbedded]] to build applications. If you ''do'' want to customize your complete distribution, then read on how to use bitbake when building stuff. In any way, at least you now know that you can easily cross compile for OpenMoko.

=== The Right Way: Using the gnome build system ===
Even if I am no expert in this - somebody had to make a start so I'll write down everything I still believe to remember from my 1st 'real' gnome application that used the autotools and all: I have never been able to find a good tutorial for making a "canonical" gnome application - and such a tutorial is urgently needed.

Since I know that many of these things will be missing or even inaccurate in the 1st step - if You find out to make it work better or at all - please document how to do this.

===== Creating the necessary documentation files and directory structure =====
First of all go into the directory you want to be the topmost application of yout new application, and create the following files:
{|
AUTHORS||A list of all authors that took part in developing this project
COPYING||The copyright notice. Favourably the GPL
INSTALL||This file should contain the information how to build and install this program
README||This file should contain all important information about the program including what the program was written for.
NEWS||The name of this file should be self-describing
TODO||The wishlist of your project
Changelog||A list of the major changes to your project
|}
I remember that some of these files were mandatory - it's better create them all

Then create a directory named '''src'' - and copy the source code of the program there.

===== The configuration of the autotools =====
What is to be said to this section is that I included some requirements like gnome-vfs to the requirements not because our application actually needs these packages but because it was very hard to find out how to do so - and I therefore wanted to document how to add them.

If anybody doesn't like this approach - feel free to edit this wiki.
====== autogen.sh ======
This file is a shell script that calls all autotools in the right order and with the right parameters so they will in the end generate the standard configure script that will detect how to build our program.

#! /bin/sh
#
# Most if not all of the contents of this file was taken from the openmoko
# sample application as it was shipped with the openmoko toolchain on
# January 31st, 2008
#

srcdir=`dirname $0`
test -z "$srcdir" && srcdir=.

PKG_NAME="hello"

(test -f $srcdir/configure.ac) || {
echo -n "**Error**: Directory "\`$srcdir\'" does not look like the"
echo " top-level $PKG_NAME directory"
exit 1
}

which gnome-autogen.sh || {
echo "You need to install gnome-common from the GNOME CVS"
exit 1
}

REQUIRED_AUTOMAKE_VERSION=1.7 USE_GNOME2_MACROS=0 REQUIRED_GETTEXT_VERSION=0.10.36 . gnome-autogen.sh

====== configure.ac ======
This file tells what the configure script has to do - and which parts of the intelligence delivered with the tools that generate the configure script we need.

I documented every line of which I found out what it actually does. The first line is for to tell the emacs text editor that it has to treat this file as an autoconf file.
# -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.

# Tell autoconf to check what version of autoconf we need.
AC_PREREQ(2.61)

# Initialize autoconf and tell it what program we wrote, the version
# of our program, and the address bug reports have to be sent to.
AC_INIT([audiorec],[0.2],[audiorec.projects.openmoko.org])

# tell autoconf where to put the temporary files it generates
AC_CONFIG_AUX_DIR([build-aux])

# This one is thaken from the "Migrationg to gnome Documentation Build
# utilities". No Idea, what it does.
AC_CONFIG_MACRO_DIR([m4])

# give autoconf the name of a file whose existence is a hint that
# autoconf has been started from the right directory.
AC_CONFIG_SRCDIR([src/diskusagemeter.c])

# Tell autoconf where to put the output file that contains all
# definitions our C program will need
AC_CONFIG_HEADER([src/config.h:src/config.hin])

# Initialize automake, and tell it to tell the C compiler to output as
# many warnings as it can
AM_INIT_AUTOMAKE([-Wall foreign])

# The GNU Gettext version we used for internationalization of our
# program...
AM_GNU_GETTEXT_VERSION([0.16.1])
# ...Or alternatively the local gnu gettext installation
AM_GNU_GETTEXT([external])

# Check for a C compiler
AC_PROG_CC

# Include all m4 macros that have to do with the language C
AC_LANG_C

# ???
AC_ISC_POSIX

# ???
AC_HEADER_STDC

# Checks for programs.
AC_PROG_CC

# We need the following type definitions from autoconf - or somebody else.
AC_TYPE_INT8_T
AC_TYPE_INT16_T
AC_TYPE_INT32_T

# AC_CHECK_LIB(libgnome-2.0, gnome_help_display_uri, [AC_DEFINE(HAVE_LIBGNOME, 1)])

# Prepare building the gnome documentation of this program
#GNOME_DOC_INIT

# Checks for libraries.
dnl Checking for the required libraries.
GTK_REQUIRED_VERSION=2.0.0
LIBGNOMEUI_REQUIRED_VERSION=2.0.0
GCONF_REQUIRED_VERSION=2.0.0
GNOMEVFS_REQUIRED_VERSION=2.0.0
ALSA_REQUIRED_VERSION=1.0.0
OGG_REQUIRED_VERSION=1.0.0
VORBIS_REQUIRED_VERSION=1.0.0
VORBISENC_REQUIRED_VERSION=1.0.0
PKG_CHECK_MODULES(DEPEND, gtk+-2.0 >= $GTK_REQUIRED_VERSION gconf-2.0 >= $GCONF_REQUIRED_VERSION gnome-vfs-2.0 >= $GNOMEVFS_REQUIRED_VERSION libgnomeui-2.0 >= $LIBGNOMEUI_REQUIRED_VERSION alsa >= $ALSA_REQUIRED_VERSION ogg >= $OGG_REQUIRED_VERSION vorbis >= $VORBIS_REQUIRED_VERSION vorbisenc >= $VORBISENC_REQUIRED_VERSION)

AC_SUBST(DEPEND_CFLAGS)
AC_SUBST(DEPEND_LIBS)

# Gettext wants to know the path to the top directory and such things...
top_builddir=`pwd`
AC_SUBST(top_builddir)
AC_SUBST(PACKAGE)
AC_SUBST(LOCALEDIR)

# Checks for the header files we include.
AC_HEADER_STDC
AC_CHECK_HEADERS([fcntl.h stdlib.h string.h sys/vfs.h])

# Checks for typedefs, structures, and compiler characteristics.
AC_C_CONST

# Checks for library functions that we really need.
AC_FUNC_MALLOC

# A list of all configuration files we have to generate
AC_CONFIG_FILES([Makefile src/Makefile src/images/Makefile po/Makefile.in]) #help/Makefile

# Tell autoconf to start outputting whatever it has to.
AC_OUTPUT

===== Makefile.am =====
This file is a template top-level-Makefile that will be filled with life by the configure script.

One thing that is added to the standard Makefile is code for automatically generate the '''_control'''-file mentioned above on a '''make dist'''
# A list of all subdirectories.
SUBDIRS = src po # help

# Allow automake to interpret m4 macros (needed for interpreting
# gettext's makefile.in
ACLOCAL_AMFLAGS = -I m4
# Files that aren't source files and still have to be in the tarball
EXTRA_DIST = @PACKAGE_NAME@_control

# An (currently unused) extension to the "install" target
install-data-local:

@PACKAGE_NAME@_control: Makefile.am configure.ac
echo "Package: @PACKAGE_NAME@">$@
echo "Version: @PACKAGE_VERSION@">>$@
echo "Description: An voice recorder that can stop recording during silence">>$@
echo "Section: openmoko/applications">>$@
echo "Priority: optional">>$@
echo "Maintainer: your_name">>$@
echo "Architecture: armv4t">>$@
echo "Homepage: (The homepage of this project)">>$@
echo "Depends: gtk+ alsa-lib libogg libvorbis gnome-vfs libgnomeui">>$@
echo "Source: \$${SRC}">>$@

===== src/Makefile.am =====
This file is a template Makefile that when filled with life by the configure script will compile our code.

The most important step here is to tell which files our program consists of.
AM_CFLAGS = $(DEPEND_CFLAGS) -Wall

AM_LDFLAGS = $(DEPEND_LIBS)

LDADD = $(LIBINTL)

bin_PROGRAMS = hello
hello_SOURCES = hello.c
{{Languages|Building_a_hello_world_application}}
[[Category:Software]]
[[Category:Guides]]
===== Internationalization =====
Now the instructions on how to generate a gnome build system for our application should be nearly working. In order to generate a .tar.gz- archieve of the complete project that contains the full build system just type the following two lines:
./autogen.sh
make dist

What still has to be done is internationalization: A very fine feature of open-source software is that it is possible to translate them to nearlly all languages - and normally sooner or later somebody will have done this.

The only thing that has to be done so our program can easily be internationalized is the following:
* get a '''gettext.h''' file and copy it to your src directory
* add an '''#include gettext,h''' to all source files that contain text that can be translated.
* add an '''_(''' in front of all strings that might be translated and an ''')''' after the string.

Our source file looks now like this:
#include <stdio.h>
#include "gettext.h"

int main()
{
printf (_("Hello World\n"));
return 0;
}

==== Building our new package ====
I never used the offical openmoko toolchain, so no documentation for this for now - even if I don't think there is any magic there. Since the documentation of the MokoMakefile is rather good, I will document this approach - that I actually used - neither.

Building a hello world application

2008-05-04T11:06:10Z

Peterpall: /* Formatting, the 2nd try. */

=== Preparation ===
This guide assumes that you have performed the steps in [[Building_OpenMoko_from_scratch]]

=== The commandline program ===
Store the following more or less standard hello world code in hello.c

#include <stdio.h>

int main()
{
printf ("Hello World\n");
return 0;
}

=== Compiling it the ''wrong'' / easy way ===
Assuming your current working directory is '''/home/moko''', and that you stored the code in '''/home/moko/hello.c''' it should now be possible to compile the application using
./build/tmp/cross/arm-linux/bin/gcc -o hello hello.c

==== Testing it ====
Assuming you have followed [[OpenMoko_under_QEMU#Setting_up_USB_connection|Setting up USB connection]] and you have a working network connection to either a qemu Neo or a real Neo.
scp hello root@192.168.0.202:/tmp/
ssh root@192.168.0.202 /tmp/hello
This sequence of commands ought to give you a nice ''Hello World'', btw. the default root password is blank, just press return.

=== GDK the Wrong / Easy Way ===
Building a GDK application the wrong way is slightly more complex, but is still fun to try. It requires using pkg-config to specify including and linking with the ARM header files and libraries.

Given the following program as main.c:

#include <gtk/gtk.h>

gchar *hello = "Howdy";
gchar *world = "World";
GtkWidget *label;
gchar *labeltext;

void buttoncb(GtkWidget *widget, gpointer data)
{
if (labeltext == hello)
{
labeltext = world;
gtk_label_set_text(GTK_LABEL(label), labeltext);
}
else if (labeltext == world)
gtk_main_quit();
}

int main(int argc, char *argv[])
{
GtkWidget *window;
GtkWidget *button;

gtk_init(&argc, &argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
button = gtk_button_new();
labeltext = hello;
label = gtk_label_new(labeltext);
gtk_container_add(GTK_CONTAINER(button), label);
g_signal_connect(G_OBJECT(button), "clicked", G_CALLBACK(buttoncb), NULL);
gtk_container_add(GTK_CONTAINER(window), button);
gtk_widget_show_all(window);
gtk_main();

return 0;
}

You must first point pkg-config to the proper directory:

export PKG_CONFIG_PATH=/home/username/moko/build/tmp/staging/arm-linux/lib/pkgconfig

And set up an environment variable to make things easier:

export OMDIR=/home/username/moko

The compile/link line is rather long - you will only want to do this once before you decide to create a shell script or make file:

$OMDIR/build/tmp/cross/arm-angstrom-linux-gnueabi/bin/gcc -L $OMDIR/build/tmp/staging/arm-angstrom-linux-gnueabi/lib/ \
-Wl, rpath-link, $OMDIR/build/tmp/staging/arm-angstrom-linux-gnueabi/lib/ -Wl, -O1 -g -o hw main.c \
'$OMDIR/build/tmp/staging/i686-linux/bin/pkg-config --cflags --libs openmoko-libs gtk+-2.0'

Then copy and run as in the original hello world command line program above.

===== Why was it the ''wrong'' way? =====
OpenMoko provides a precompiled [[Toolchain]] package for that. It also comes with some scripts that make your life much easier. Besides, you don't need [[OpenEmbedded]] to build applications. If you ''do'' want to customize your complete distribution, then read on how to use bitbake when building stuff. In any way, at least you now know that you can easily cross compile for OpenMoko.

=== The Right Way: Using the gnome build system ===
Even if I am no expert in this - somebody had to make a start so I'll write down everything I still believe to remember from my 1st 'real' gnome application that used the autotools and all: I have never been able to find a good tutorial for making a "canonical" gnome application - and such a tutorial is urgently needed.

Since I know that many of these things will be missing or even inaccurate in the 1st step - if You find out to make it work better or at all - please document how to do this.

===== Creating the necessary documentation files and directory structure =====
First of all go into the directory you want to be the topmost application of yout new application, and create the following files:
{|
AUTHORS||A list of all authors that took part in developing this project
COPYING||The copyright notice. Favourably the GPL
INSTALL||This file should contain the information how to build and install this program
README||This file should contain all important information about the program including what the program was written for.
NEWS||The name of this file should be self-describing
TODO||The wishlist of your project
Changelog||A list of the major changes to your project
|}
I remember that some of these files were mandatory - it's better create them all

Then create a directory named '''src'' - and copy the source code of the program there.

===== The configuration of the autotools =====
====== autogen.sh ======
This file is a shell script that calls all autotools in the right order and with the right parameters so they will in the end generate the standard configure script that will detect how to build our program.

#! /bin/sh
#
# Most if not all of the contents of this file was taken from the openmoko
# sample application as it was shipped with the openmoko toolchain on
# January 31st, 2008
#

srcdir=`dirname $0`
test -z "$srcdir" && srcdir=.

PKG_NAME="hello"

(test -f $srcdir/configure.ac) || {
echo -n "**Error**: Directory "\`$srcdir\'" does not look like the"
echo " top-level $PKG_NAME directory"
exit 1
}

which gnome-autogen.sh || {
echo "You need to install gnome-common from the GNOME CVS"
exit 1
}

REQUIRED_AUTOMAKE_VERSION=1.7 USE_GNOME2_MACROS=0 REQUIRED_GETTEXT_VERSION=0.10.36 . gnome-autogen.sh

====== configure.ac ======
This file tells what the configure script has to do - and which parts of the intelligence delivered with the tools that generate the configure script we need.

I documented every line of which I found out what it actually does. The first line is for to tell the emacs text editor that it has to treat this file as an autoconf file.
# -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.

# Tell autoconf to check what version of autoconf we need.
AC_PREREQ(2.61)

# Initialize autoconf and tell it what program we wrote, the version
# of our program, and the address bug reports have to be sent to.
AC_INIT([audiorec],[0.2],[audiorec.projects.openmoko.org])

# tell autoconf where to put the temporary files it generates
AC_CONFIG_AUX_DIR([build-aux])

# This one is thaken from the "Migrationg to gnome Documentation Build
# utilities". No Idea, what it does.
AC_CONFIG_MACRO_DIR([m4])

# give autoconf the name of a file whose existence is a hint that
# autoconf has been started from the right directory.
AC_CONFIG_SRCDIR([src/diskusagemeter.c])

# Tell autoconf where to put the output file that contains all
# definitions our C program will need
AC_CONFIG_HEADER([src/config.h:src/config.hin])

# Initialize automake, and tell it to tell the C compiler to output as
# many warnings as it can
AM_INIT_AUTOMAKE([-Wall foreign])

# The GNU Gettext version we used for internationalization of our
# program...
AM_GNU_GETTEXT_VERSION([0.16.1])
# ...Or alternatively the local gnu gettext installation
AM_GNU_GETTEXT([external])

# Check for a C compiler
AC_PROG_CC

# Include all m4 macros that have to do with the language C
AC_LANG_C

# ???
AC_ISC_POSIX

# ???
AC_HEADER_STDC

# Checks for programs.
AC_PROG_CC

# We need the following type definitions from autoconf - or somebody else.
AC_TYPE_INT8_T
AC_TYPE_INT16_T
AC_TYPE_INT32_T

# AC_CHECK_LIB(libgnome-2.0, gnome_help_display_uri, [AC_DEFINE(HAVE_LIBGNOME, 1)])

# Prepare building the gnome documentation of this program
#GNOME_DOC_INIT

# Checks for libraries.
dnl Checking for the required libraries.
GTK_REQUIRED_VERSION=2.0.0
LIBGNOMEUI_REQUIRED_VERSION=2.0.0
GCONF_REQUIRED_VERSION=2.0.0
GNOMEVFS_REQUIRED_VERSION=2.0.0
ALSA_REQUIRED_VERSION=1.0.0
OGG_REQUIRED_VERSION=1.0.0
VORBIS_REQUIRED_VERSION=1.0.0
VORBISENC_REQUIRED_VERSION=1.0.0
PKG_CHECK_MODULES(DEPEND, gtk+-2.0 >= $GTK_REQUIRED_VERSION gconf-2.0 >= $GCONF_REQUIRED_VERSION gnome-vfs-2.0 >= $GNOMEVFS_REQUIRED_VERSION libgnomeui-2.0 >= $LIBGNOMEUI_REQUIRED_VERSION alsa >= $ALSA_REQUIRED_VERSION ogg >= $OGG_REQUIRED_VERSION vorbis >= $VORBIS_REQUIRED_VERSION vorbisenc >= $VORBISENC_REQUIRED_VERSION)

AC_SUBST(DEPEND_CFLAGS)
AC_SUBST(DEPEND_LIBS)

# Gettext wants to know the path to the top directory and such things...
top_builddir=`pwd`
AC_SUBST(top_builddir)
AC_SUBST(PACKAGE)
AC_SUBST(LOCALEDIR)

# Checks for the header files we include.
AC_HEADER_STDC
AC_CHECK_HEADERS([fcntl.h stdlib.h string.h sys/vfs.h])

# Checks for typedefs, structures, and compiler characteristics.
AC_C_CONST

# Checks for library functions that we really need.
AC_FUNC_MALLOC

# A list of all configuration files we have to generate
AC_CONFIG_FILES([Makefile src/Makefile src/images/Makefile po/Makefile.in]) #help/Makefile

# Tell autoconf to start outputting whatever it has to.
AC_OUTPUT
===== Makefile.am =====
This file is a template top-level-Makefile that will be filled with life by the configure script.

One thing that is added to the standard Makefile is code for automatically generate the '''_control'''-file mentioned above on a '''make dist'''
# A list of all subdirectories.
SUBDIRS = src po # help

# Allow automake to interpret m4 macros (needed for interpreting
# gettext's makefile.in
ACLOCAL_AMFLAGS = -I m4
# Files that aren't source files and still have to be in the tarball
EXTRA_DIST = @PACKAGE_NAME@_control

# An (currently unused) extension to the "install" target
install-data-local:

@PACKAGE_NAME@_control: Makefile.am configure.ac
echo "Package: @PACKAGE_NAME@">$@
echo "Version: @PACKAGE_VERSION@">>$@
echo "Description: An voice recorder that can stop recording during silence">>$@
echo "Section: openmoko/applications">>$@
echo "Priority: optional">>$@
echo "Maintainer: your_name">>$@
echo "Architecture: armv4t">>$@
echo "Homepage: (The homepage of this project)">>$@
echo "Depends: gtk+ alsa-lib libogg libvorbis gnome-vfs libgnomeui">>$@
echo "Source: \$${SRC}">>$@

===== src/Makefile.am =====
This file is a template Makefile that when filled with life by the configure script will compile our code.

The most important step here is to tell which files our program consists of.
AM_CFLAGS = $(DEPEND_CFLAGS) -Wall

AM_LDFLAGS = $(DEPEND_LIBS)

LDADD = $(LIBINTL)

bin_PROGRAMS = hello
hello_SOURCES = hello.c
{{Languages|Building_a_hello_world_application}}
[[Category:Software]]
[[Category:Guides]]
===== Internationalization =====
Now the instructions on how to generate a gnome build system for our application should be nearly working. In order to generate a .tar.gz- archieve of the complete project that contains the full build system just type the following two lines:
./autogen.sh
make dist

What still has to be done is internationalization: A very fine feature of open-source software is that it is possible to translate them to nearlly all languages - and normally sooner or later somebody will have done this.

The only thing that has to be done so our program can easily be internationalized is the following:
* get a '''gettext.h''' file and copy it to your src directory
* add an '''#include gettext,h''' to all source files that contain text that can be translated.
* add an '''_(''' in front of all strings that might be translated and an ''')''' after the string.

Our source file looks now like this:
#include <stdio.h>
#include "gettext.h"

int main()
{
printf (_("Hello World\n"));
return 0;
}

==== Building our new package ====
I never used the offical openmoko toolchain, so no documentation for this for now - even if I don't think there is any magic there. Since the documentation of the MokoMakefile is rather good, I will document this approach - that I actually used - neither.

Building a hello world application

2008-05-04T11:05:21Z

Peterpall: /* Tried to get the formatting right. */

=== Preparation ===
This guide assumes that you have performed the steps in [[Building_OpenMoko_from_scratch]]

=== The commandline program ===
Store the following more or less standard hello world code in hello.c

#include <stdio.h>

int main()
{
printf ("Hello World\n");
return 0;
}

=== Compiling it the ''wrong'' / easy way ===
Assuming your current working directory is '''/home/moko''', and that you stored the code in '''/home/moko/hello.c''' it should now be possible to compile the application using
./build/tmp/cross/arm-linux/bin/gcc -o hello hello.c

==== Testing it ====
Assuming you have followed [[OpenMoko_under_QEMU#Setting_up_USB_connection|Setting up USB connection]] and you have a working network connection to either a qemu Neo or a real Neo.
scp hello root@192.168.0.202:/tmp/
ssh root@192.168.0.202 /tmp/hello
This sequence of commands ought to give you a nice ''Hello World'', btw. the default root password is blank, just press return.

=== GDK the Wrong / Easy Way ===
Building a GDK application the wrong way is slightly more complex, but is still fun to try. It requires using pkg-config to specify including and linking with the ARM header files and libraries.

Given the following program as main.c:

#include <gtk/gtk.h>

gchar *hello = "Howdy";
gchar *world = "World";
GtkWidget *label;
gchar *labeltext;

void buttoncb(GtkWidget *widget, gpointer data)
{
if (labeltext == hello)
{
labeltext = world;
gtk_label_set_text(GTK_LABEL(label), labeltext);
}
else if (labeltext == world)
gtk_main_quit();
}

int main(int argc, char *argv[])
{
GtkWidget *window;
GtkWidget *button;

gtk_init(&argc, &argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
button = gtk_button_new();
labeltext = hello;
label = gtk_label_new(labeltext);
gtk_container_add(GTK_CONTAINER(button), label);
g_signal_connect(G_OBJECT(button), "clicked", G_CALLBACK(buttoncb), NULL);
gtk_container_add(GTK_CONTAINER(window), button);
gtk_widget_show_all(window);
gtk_main();

return 0;
}

You must first point pkg-config to the proper directory:

export PKG_CONFIG_PATH=/home/username/moko/build/tmp/staging/arm-linux/lib/pkgconfig

And set up an environment variable to make things easier:

export OMDIR=/home/username/moko

The compile/link line is rather long - you will only want to do this once before you decide to create a shell script or make file:

$OMDIR/build/tmp/cross/arm-angstrom-linux-gnueabi/bin/gcc -L $OMDIR/build/tmp/staging/arm-angstrom-linux-gnueabi/lib/ \
-Wl, rpath-link, $OMDIR/build/tmp/staging/arm-angstrom-linux-gnueabi/lib/ -Wl, -O1 -g -o hw main.c \
'$OMDIR/build/tmp/staging/i686-linux/bin/pkg-config --cflags --libs openmoko-libs gtk+-2.0'

Then copy and run as in the original hello world command line program above.

===== Why was it the ''wrong'' way? =====
OpenMoko provides a precompiled [[Toolchain]] package for that. It also comes with some scripts that make your life much easier. Besides, you don't need [[OpenEmbedded]] to build applications. If you ''do'' want to customize your complete distribution, then read on how to use bitbake when building stuff. In any way, at least you now know that you can easily cross compile for OpenMoko.

=== The Right Way: Using the gnome build system ===
Even if I am no expert in this - somebody had to make a start so I'll write down everything I still believe to remember from my 1st 'real' gnome application that used the autotools and all: I have never been able to find a good tutorial for making a "canonical" gnome application - and such a tutorial is urgently needed.

Since I know that many of these things will be missing or even inaccurate in the 1st step - if You find out to make it work better or at all - please document how to do this.

===== Creating the necessary documentation files and directory structure =====
First of all go into the directory you want to be the topmost application of yout new application, and create the following files:
{|
AUTHORS||A list of all authors that took part in developing this project
COPYING||The copyright notice. Favourably the GPL
INSTALL||This file should contain the information how to build and install this program
README||This file should contain all important information about the program including what the program was written for.
NEWS||The name of this file should be self-describing
TODO||The wishlist of your project
Changelog||A list of the major changes to your project
|}
I remember that some of these files were mandatory - it's better create them all

Then create a directory named '''src'' - and copy the source code of the program there.

===== The configuration of the autotools =====
====== autogen.sh ======
This file is a shell script that calls all autotools in the right order and with the right parameters so they will in the end generate the standard configure script that will detect how to build our program.

#! /bin/sh
#
# Most if not all of the contents of this file was taken from the openmoko
# sample application as it was shipped with the openmoko toolchain on
# January 31st, 2008
#

srcdir=`dirname $0`
test -z "$srcdir" && srcdir=.

PKG_NAME="hello"

(test -f $srcdir/configure.ac) || {
echo -n "**Error**: Directory "\`$srcdir\'" does not look like the"
echo " top-level $PKG_NAME directory"
exit 1
}

which gnome-autogen.sh || {
echo "You need to install gnome-common from the GNOME CVS"
exit 1
}

REQUIRED_AUTOMAKE_VERSION=1.7 USE_GNOME2_MACROS=0 REQUIRED_GETTEXT_VERSION=0.10.36 . gnome-autogen.sh

====== configure.ac ======
This file tells what the configure script has to do - and which parts of the intelligence delivered with the tools that generate the configure script we need.

I documented every line of which I found out what it actually does. The first line is for to tell the emacs text editor that it has to treat this file as an autoconf file.
# -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.

# Tell autoconf to check what version of autoconf we need.
AC_PREREQ(2.61)

# Initialize autoconf and tell it what program we wrote, the version
# of our program, and the address bug reports have to be sent to.
AC_INIT([audiorec],[0.2],[audiorec.projects.openmoko.org])

# tell autoconf where to put the temporary files it generates
AC_CONFIG_AUX_DIR([build-aux])

# This one is thaken from the "Migrationg to gnome Documentation Build
# utilities". No Idea, what it does.
AC_CONFIG_MACRO_DIR([m4])

# give autoconf the name of a file whose existence is a hint that
# autoconf has been started from the right directory.
AC_CONFIG_SRCDIR([src/diskusagemeter.c])

# Tell autoconf where to put the output file that contains all
# definitions our C program will need
AC_CONFIG_HEADER([src/config.h:src/config.hin])

# Initialize automake, and tell it to tell the C compiler to output as
# many warnings as it can
AM_INIT_AUTOMAKE([-Wall foreign])

# The GNU Gettext version we used for internationalization of our
# program...
AM_GNU_GETTEXT_VERSION([0.16.1])
# ...Or alternatively the local gnu gettext installation
AM_GNU_GETTEXT([external])

# Check for a C compiler
AC_PROG_CC

# Include all m4 macros that have to do with the language C
AC_LANG_C

# ???
AC_ISC_POSIX

# ???
AC_HEADER_STDC

# Checks for programs.
AC_PROG_CC

# We need the following type definitions from autoconf - or somebody else.
AC_TYPE_INT8_T
AC_TYPE_INT16_T
AC_TYPE_INT32_T

# AC_CHECK_LIB(libgnome-2.0, gnome_help_display_uri, [AC_DEFINE(HAVE_LIBGNOME, 1)])

# Prepare building the gnome documentation of this program
#GNOME_DOC_INIT

# Checks for libraries.
dnl Checking for the required libraries.
GTK_REQUIRED_VERSION=2.0.0
LIBGNOMEUI_REQUIRED_VERSION=2.0.0
GCONF_REQUIRED_VERSION=2.0.0
GNOMEVFS_REQUIRED_VERSION=2.0.0
ALSA_REQUIRED_VERSION=1.0.0
OGG_REQUIRED_VERSION=1.0.0
VORBIS_REQUIRED_VERSION=1.0.0
VORBISENC_REQUIRED_VERSION=1.0.0
PKG_CHECK_MODULES(DEPEND, gtk+-2.0 >= $GTK_REQUIRED_VERSION gconf-2.0 >= $GCONF_REQUIRED_VERSION gnome-vfs-2.0 >= $GNOMEVFS_REQUIRED_VERSION libgnomeui-2.0 >= $LIBGNOMEUI_REQUIRED_VERSION alsa >= $ALSA_REQUIRED_VERSION ogg >= $OGG_REQUIRED_VERSION vorbis >= $VORBIS_REQUIRED_VERSION vorbisenc >= $VORBISENC_REQUIRED_VERSION)

AC_SUBST(DEPEND_CFLAGS)
AC_SUBST(DEPEND_LIBS)

# Gettext wants to know the path to the top directory and such things...
top_builddir=`pwd`
AC_SUBST(top_builddir)
AC_SUBST(PACKAGE)
AC_SUBST(LOCALEDIR)

# Checks for the header files we include.
AC_HEADER_STDC
AC_CHECK_HEADERS([fcntl.h stdlib.h string.h sys/vfs.h])

# Checks for typedefs, structures, and compiler characteristics.
AC_C_CONST

# Checks for library functions that we really need.
AC_FUNC_MALLOC

# A list of all configuration files we have to generate
AC_CONFIG_FILES([Makefile src/Makefile src/images/Makefile po/Makefile.in]) #help/Makefile

# Tell autoconf to start outputting whatever it has to.
AC_OUTPUT
===== Makefile.am =====
This file is a template top-level-Makefile that will be filled with life by the configure script.

One thing that is added to the standard Makefile is code for automatically generate the '''_control'''-file mentioned above on a '''make dist'''
# A list of all subdirectories.
SUBDIRS = src po # help

# Allow automake to interpret m4 macros (needed for interpreting
# gettext's makefile.in
ACLOCAL_AMFLAGS = -I m4
# Files that aren't source files and still have to be in the tarball
EXTRA_DIST = @PACKAGE_NAME@_control

# An (currently unused) extension to the "install" target
install-data-local:

@PACKAGE_NAME@_control: Makefile.am configure.ac
echo "Package: @PACKAGE_NAME@">$@
echo "Version: @PACKAGE_VERSION@">>$@
echo "Description: An voice recorder that can stop recording during silence">>$@
echo "Section: openmoko/applications">>$@
echo "Priority: optional">>$@
echo "Maintainer: your_name">>$@
echo "Architecture: armv4t">>$@
echo "Homepage: (The homepage of this project)">>$@
echo "Depends: gtk+ alsa-lib libogg libvorbis gnome-vfs libgnomeui">>$@
echo "Source: \$${SRC}">>$@

===== src/Makefile.am =====
This file is a template Makefile that when filled with life by the configure script will compile our code.

The most important step here is to tell which files our program consists of.
AM_CFLAGS = $(DEPEND_CFLAGS) -Wall

AM_LDFLAGS = $(DEPEND_LIBS)

LDADD = $(LIBINTL)

bin_PROGRAMS = hello
hello_SOURCES = hello.c
{{Languages|Building_a_hello_world_application}}
[[Category:Software]]
[[Category:Guides]]
===== Internationalization =====
Now the instructions on how to generate a gnome build system for our application should be nearly working. In order to generate a .tar.gz- archieve of the complete project that contains the full build system just type the following two lines:
./autogen.sh
make dist

What still has to be done is internationalization: A very fine feature of open-source software is that it is possible to translate them to nearlly all languages - and normally sooner or later somebody will have done this.

The only thing that has to be done so our program can easily be internationalized is the following:
- get a '''gettext.h''' file and copy it to your src directory
- add an '''#include gettext,h''' to all source files that contain text that can be translated.
- add an '''_(''' in front of all strings that might be translated and an ''')''' after the string.

Our source file looks now like this:
#include <stdio.h>
#include "gettext.h"

int main()
{
printf (_("Hello World\n"));
return 0;
}

==== Building our new package ====
I never used the offical openmoko toolchain, so no documentation for this for now - even if I don't think there is any magic there. Since the documentation of the MokoMakefile is rather good, I will document this approach - that I actually used - neither.

Building a hello world application

2008-05-04T11:04:52Z

Peterpall: /* Internationalization */

=== Preparation ===
This guide assumes that you have performed the steps in [[Building_OpenMoko_from_scratch]]

=== The commandline program ===
Store the following more or less standard hello world code in hello.c

#include <stdio.h>

int main()
{
printf ("Hello World\n");
return 0;
}

=== Compiling it the ''wrong'' / easy way ===
Assuming your current working directory is '''/home/moko''', and that you stored the code in '''/home/moko/hello.c''' it should now be possible to compile the application using
./build/tmp/cross/arm-linux/bin/gcc -o hello hello.c

==== Testing it ====
Assuming you have followed [[OpenMoko_under_QEMU#Setting_up_USB_connection|Setting up USB connection]] and you have a working network connection to either a qemu Neo or a real Neo.
scp hello root@192.168.0.202:/tmp/
ssh root@192.168.0.202 /tmp/hello
This sequence of commands ought to give you a nice ''Hello World'', btw. the default root password is blank, just press return.

=== GDK the Wrong / Easy Way ===
Building a GDK application the wrong way is slightly more complex, but is still fun to try. It requires using pkg-config to specify including and linking with the ARM header files and libraries.

Given the following program as main.c:

#include <gtk/gtk.h>

gchar *hello = "Howdy";
gchar *world = "World";
GtkWidget *label;
gchar *labeltext;

void buttoncb(GtkWidget *widget, gpointer data)
{
if (labeltext == hello)
{
labeltext = world;
gtk_label_set_text(GTK_LABEL(label), labeltext);
}
else if (labeltext == world)
gtk_main_quit();
}

int main(int argc, char *argv[])
{
GtkWidget *window;
GtkWidget *button;

gtk_init(&argc, &argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
button = gtk_button_new();
labeltext = hello;
label = gtk_label_new(labeltext);
gtk_container_add(GTK_CONTAINER(button), label);
g_signal_connect(G_OBJECT(button), "clicked", G_CALLBACK(buttoncb), NULL);
gtk_container_add(GTK_CONTAINER(window), button);
gtk_widget_show_all(window);
gtk_main();

return 0;
}

You must first point pkg-config to the proper directory:

export PKG_CONFIG_PATH=/home/username/moko/build/tmp/staging/arm-linux/lib/pkgconfig

And set up an environment variable to make things easier:

export OMDIR=/home/username/moko

The compile/link line is rather long - you will only want to do this once before you decide to create a shell script or make file:

$OMDIR/build/tmp/cross/arm-angstrom-linux-gnueabi/bin/gcc -L $OMDIR/build/tmp/staging/arm-angstrom-linux-gnueabi/lib/ \
-Wl, rpath-link, $OMDIR/build/tmp/staging/arm-angstrom-linux-gnueabi/lib/ -Wl, -O1 -g -o hw main.c \
'$OMDIR/build/tmp/staging/i686-linux/bin/pkg-config --cflags --libs openmoko-libs gtk+-2.0'

Then copy and run as in the original hello world command line program above.

===== Why was it the ''wrong'' way? =====
OpenMoko provides a precompiled [[Toolchain]] package for that. It also comes with some scripts that make your life much easier. Besides, you don't need [[OpenEmbedded]] to build applications. If you ''do'' want to customize your complete distribution, then read on how to use bitbake when building stuff. In any way, at least you now know that you can easily cross compile for OpenMoko.

=== The Right Way: Using the gnome build system ===
Even if I am no expert in this - somebody had to make a start so I'll write down everything I still believe to remember from my 1st 'real' gnome application that used the autotools and all: I have never been able to find a good tutorial for making a "canonical" gnome application - and such a tutorial is urgently needed.

Since I know that many of these things will be missing or even inaccurate in the 1st step - if You find out to make it work better or at all - please document how to do this.

===== Creating the necessary documentation files and directory structure =====
First of all go into the directory you want to be the topmost application of yout new application, and create the following files:
{|
AUTHORS||A list of all authors that took part in developing this project
COPYING||The copyright notice. Favourably the GPL
INSTALL||This file should contain the information how to build and install this program
README||This file should contain all important information about the program including what the program was written for.
NEWS||The name of this file should be self-describing
TODO||The wishlist of your project
Changelog||A list of the major changes to your project
|}
I remember that some of these files were mandatory - it's better create them all

Then create a directory named '''src'' - and copy the source code of the program there.

===== The configuration of the autotools =====
====== autogen.sh ======
This file is a shell script that calls all autotools in the right order and with the right parameters so they will in the end generate the standard configure script that will detect how to build our program.

#! /bin/sh
#
# Most if not all of the contents of this file was taken from the openmoko
# sample application as it was shipped with the openmoko toolchain on
# January 31st, 2008
#

srcdir=`dirname $0`
test -z "$srcdir" && srcdir=.

PKG_NAME="hello"

(test -f $srcdir/configure.ac) || {
echo -n "**Error**: Directory "\`$srcdir\'" does not look like the"
echo " top-level $PKG_NAME directory"
exit 1
}

which gnome-autogen.sh || {
echo "You need to install gnome-common from the GNOME CVS"
exit 1
}

REQUIRED_AUTOMAKE_VERSION=1.7 USE_GNOME2_MACROS=0 REQUIRED_GETTEXT_VERSION=0.10.36 . gnome-autogen.sh

====== configure.ac ======
This file tells what the configure script has to do - and which parts of the intelligence delivered with the tools that generate the configure script we need.

I documented every line of which I found out what it actually does. The first line is for to tell the emacs text editor that it has to treat this file as an autoconf file.
# -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.

# Tell autoconf to check what version of autoconf we need.
AC_PREREQ(2.61)

# Initialize autoconf and tell it what program we wrote, the version
# of our program, and the address bug reports have to be sent to.
AC_INIT([audiorec],[0.2],[audiorec.projects.openmoko.org])

# tell autoconf where to put the temporary files it generates
AC_CONFIG_AUX_DIR([build-aux])

# This one is thaken from the "Migrationg to gnome Documentation Build
# utilities". No Idea, what it does.
AC_CONFIG_MACRO_DIR([m4])

# give autoconf the name of a file whose existence is a hint that
# autoconf has been started from the right directory.
AC_CONFIG_SRCDIR([src/diskusagemeter.c])

# Tell autoconf where to put the output file that contains all
# definitions our C program will need
AC_CONFIG_HEADER([src/config.h:src/config.hin])

# Initialize automake, and tell it to tell the C compiler to output as
# many warnings as it can
AM_INIT_AUTOMAKE([-Wall foreign])

# The GNU Gettext version we used for internationalization of our
# program...
AM_GNU_GETTEXT_VERSION([0.16.1])
# ...Or alternatively the local gnu gettext installation
AM_GNU_GETTEXT([external])

# Check for a C compiler
AC_PROG_CC

# Include all m4 macros that have to do with the language C
AC_LANG_C

# ???
AC_ISC_POSIX

# ???
AC_HEADER_STDC

# Checks for programs.
AC_PROG_CC

# We need the following type definitions from autoconf - or somebody else.
AC_TYPE_INT8_T
AC_TYPE_INT16_T
AC_TYPE_INT32_T

# AC_CHECK_LIB(libgnome-2.0, gnome_help_display_uri, [AC_DEFINE(HAVE_LIBGNOME, 1)])

# Prepare building the gnome documentation of this program
#GNOME_DOC_INIT

# Checks for libraries.
dnl Checking for the required libraries.
GTK_REQUIRED_VERSION=2.0.0
LIBGNOMEUI_REQUIRED_VERSION=2.0.0
GCONF_REQUIRED_VERSION=2.0.0
GNOMEVFS_REQUIRED_VERSION=2.0.0
ALSA_REQUIRED_VERSION=1.0.0
OGG_REQUIRED_VERSION=1.0.0
VORBIS_REQUIRED_VERSION=1.0.0
VORBISENC_REQUIRED_VERSION=1.0.0
PKG_CHECK_MODULES(DEPEND, gtk+-2.0 >= $GTK_REQUIRED_VERSION gconf-2.0 >= $GCONF_REQUIRED_VERSION gnome-vfs-2.0 >= $GNOMEVFS_REQUIRED_VERSION libgnomeui-2.0 >= $LIBGNOMEUI_REQUIRED_VERSION alsa >= $ALSA_REQUIRED_VERSION ogg >= $OGG_REQUIRED_VERSION vorbis >= $VORBIS_REQUIRED_VERSION vorbisenc >= $VORBISENC_REQUIRED_VERSION)

AC_SUBST(DEPEND_CFLAGS)
AC_SUBST(DEPEND_LIBS)

# Gettext wants to know the path to the top directory and such things...
top_builddir=`pwd`
AC_SUBST(top_builddir)
AC_SUBST(PACKAGE)
AC_SUBST(LOCALEDIR)

# Checks for the header files we include.
AC_HEADER_STDC
AC_CHECK_HEADERS([fcntl.h stdlib.h string.h sys/vfs.h])

# Checks for typedefs, structures, and compiler characteristics.
AC_C_CONST

# Checks for library functions that we really need.
AC_FUNC_MALLOC

# A list of all configuration files we have to generate
AC_CONFIG_FILES([Makefile src/Makefile src/images/Makefile po/Makefile.in]) #help/Makefile

# Tell autoconf to start outputting whatever it has to.
AC_OUTPUT
===== Makefile.am =====
This file is a template top-level-Makefile that will be filled with life by the configure script.

One thing that is added to the standard Makefile is code for automatically generate the '''_control'''-file mentioned above on a '''make dist'''
# A list of all subdirectories.
SUBDIRS = src po # help

# Allow automake to interpret m4 macros (needed for interpreting
# gettext's makefile.in
ACLOCAL_AMFLAGS = -I m4
# Files that aren't source files and still have to be in the tarball
EXTRA_DIST = @PACKAGE_NAME@_control

# An (currently unused) extension to the "install" target
install-data-local:

@PACKAGE_NAME@_control: Makefile.am configure.ac
echo "Package: @PACKAGE_NAME@">$@
echo "Version: @PACKAGE_VERSION@">>$@
echo "Description: An voice recorder that can stop recording during silence">>$@
echo "Section: openmoko/applications">>$@
echo "Priority: optional">>$@
echo "Maintainer: your_name">>$@
echo "Architecture: armv4t">>$@
echo "Homepage: (The homepage of this project)">>$@
echo "Depends: gtk+ alsa-lib libogg libvorbis gnome-vfs libgnomeui">>$@
echo "Source: \$${SRC}">>$@

===== src/Makefile.am =====
This file is a template Makefile that when filled with life by the configure script will compile our code.

The most important step here is to tell which files our program consists of.
AM_CFLAGS = $(DEPEND_CFLAGS) -Wall

AM_LDFLAGS = $(DEPEND_LIBS)

LDADD = $(LIBINTL)

bin_PROGRAMS = hello
hello_SOURCES = hello.c
{{Languages|Building_a_hello_world_application}}
[[Category:Software]]
[[Category:Guides]]
===== Internationalization =====
Now the instructions on how to generate a gnome build system for our application should be nearly working. In order to generate a .tar.gz- archieve of the complete project that contains the full build system just type the following two lines:
./autogen.sh
make dist

What still has to be done is internationalization: A very fine feature of open-source software is that it is possible to translate them to nearlly all languages - and normally sooner or later somebody will have done this.

The only thing that has to be done so our program can easily be internationalized is the following:
- get a '''gettext.h''' file and copy it to your src directory
- add an '''#include gettext,h''' to all source files that contain text that can be translated.
- add an '''_(''' in front of all strings that might be translated and an ''')''' after the string.

Our source file looks now like this:
#include <stdio.h>
#include "gettext.h"

int main()
{
printf (_("Hello World\n"));
return 0;
}
==== Building our new package ====
I never used the offical openmoko toolchain, so no documentation for this for now - even if I don't think there is any magic there. Since the documentation of the MokoMakefile is rather good, I will document this approach - that I actually used - neither.

Building a hello world application

2008-05-04T10:48:33Z

Peterpall: /* src/Makefile.am */

=== Preparation ===
This guide assumes that you have performed the steps in [[Building_OpenMoko_from_scratch]]

=== The commandline program ===
Store the following more or less standard hello world code in hello.c

#include <stdio.h>

int main()
{
printf ("Hello World\n");
return 0;
}

=== Compiling it the ''wrong'' / easy way ===
Assuming your current working directory is '''/home/moko''', and that you stored the code in '''/home/moko/hello.c''' it should now be possible to compile the application using
./build/tmp/cross/arm-linux/bin/gcc -o hello hello.c

==== Testing it ====
Assuming you have followed [[OpenMoko_under_QEMU#Setting_up_USB_connection|Setting up USB connection]] and you have a working network connection to either a qemu Neo or a real Neo.
scp hello root@192.168.0.202:/tmp/
ssh root@192.168.0.202 /tmp/hello
This sequence of commands ought to give you a nice ''Hello World'', btw. the default root password is blank, just press return.

=== GDK the Wrong / Easy Way ===
Building a GDK application the wrong way is slightly more complex, but is still fun to try. It requires using pkg-config to specify including and linking with the ARM header files and libraries.

Given the following program as main.c:

#include <gtk/gtk.h>

gchar *hello = "Howdy";
gchar *world = "World";
GtkWidget *label;
gchar *labeltext;

void buttoncb(GtkWidget *widget, gpointer data)
{
if (labeltext == hello)
{
labeltext = world;
gtk_label_set_text(GTK_LABEL(label), labeltext);
}
else if (labeltext == world)
gtk_main_quit();
}

int main(int argc, char *argv[])
{
GtkWidget *window;
GtkWidget *button;

gtk_init(&argc, &argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
button = gtk_button_new();
labeltext = hello;
label = gtk_label_new(labeltext);
gtk_container_add(GTK_CONTAINER(button), label);
g_signal_connect(G_OBJECT(button), "clicked", G_CALLBACK(buttoncb), NULL);
gtk_container_add(GTK_CONTAINER(window), button);
gtk_widget_show_all(window);
gtk_main();

return 0;
}

You must first point pkg-config to the proper directory:

export PKG_CONFIG_PATH=/home/username/moko/build/tmp/staging/arm-linux/lib/pkgconfig

And set up an environment variable to make things easier:

export OMDIR=/home/username/moko

The compile/link line is rather long - you will only want to do this once before you decide to create a shell script or make file:

$OMDIR/build/tmp/cross/arm-angstrom-linux-gnueabi/bin/gcc -L $OMDIR/build/tmp/staging/arm-angstrom-linux-gnueabi/lib/ \
-Wl, rpath-link, $OMDIR/build/tmp/staging/arm-angstrom-linux-gnueabi/lib/ -Wl, -O1 -g -o hw main.c \
'$OMDIR/build/tmp/staging/i686-linux/bin/pkg-config --cflags --libs openmoko-libs gtk+-2.0'

Then copy and run as in the original hello world command line program above.

===== Why was it the ''wrong'' way? =====
OpenMoko provides a precompiled [[Toolchain]] package for that. It also comes with some scripts that make your life much easier. Besides, you don't need [[OpenEmbedded]] to build applications. If you ''do'' want to customize your complete distribution, then read on how to use bitbake when building stuff. In any way, at least you now know that you can easily cross compile for OpenMoko.

=== The Right Way: Using the gnome build system ===
Even if I am no expert in this - somebody had to make a start so I'll write down everything I still believe to remember from my 1st 'real' gnome application that used the autotools and all: I have never been able to find a good tutorial for making a "canonical" gnome application - and such a tutorial is urgently needed.

Since I know that many of these things will be missing or even inaccurate in the 1st step - if You find out to make it work better or at all - please document how to do this.

===== Creating the necessary documentation files and directory structure =====
First of all go into the directory you want to be the topmost application of yout new application, and create the following files:
{|
AUTHORS||A list of all authors that took part in developing this project
COPYING||The copyright notice. Favourably the GPL
INSTALL||This file should contain the information how to build and install this program
README||This file should contain all important information about the program including what the program was written for.
NEWS||The name of this file should be self-describing
TODO||The wishlist of your project
Changelog||A list of the major changes to your project
|}
I remember that some of these files were mandatory - it's better create them all

Then create a directory named '''src'' - and copy the source code of the program there.

===== The configuration of the autotools =====
====== autogen.sh ======
This file is a shell script that calls all autotools in the right order and with the right parameters so they will in the end generate the standard configure script that will detect how to build our program.

#! /bin/sh
#
# Most if not all of the contents of this file was taken from the openmoko
# sample application as it was shipped with the openmoko toolchain on
# January 31st, 2008
#

srcdir=`dirname $0`
test -z "$srcdir" && srcdir=.

PKG_NAME="hello"

(test -f $srcdir/configure.ac) || {
echo -n "**Error**: Directory "\`$srcdir\'" does not look like the"
echo " top-level $PKG_NAME directory"
exit 1
}

which gnome-autogen.sh || {
echo "You need to install gnome-common from the GNOME CVS"
exit 1
}

REQUIRED_AUTOMAKE_VERSION=1.7 USE_GNOME2_MACROS=0 REQUIRED_GETTEXT_VERSION=0.10.36 . gnome-autogen.sh

====== configure.ac ======
This file tells what the configure script has to do - and which parts of the intelligence delivered with the tools that generate the configure script we need.

I documented every line of which I found out what it actually does. The first line is for to tell the emacs text editor that it has to treat this file as an autoconf file.
# -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.

# Tell autoconf to check what version of autoconf we need.
AC_PREREQ(2.61)

# Initialize autoconf and tell it what program we wrote, the version
# of our program, and the address bug reports have to be sent to.
AC_INIT([audiorec],[0.2],[audiorec.projects.openmoko.org])

# tell autoconf where to put the temporary files it generates
AC_CONFIG_AUX_DIR([build-aux])

# This one is thaken from the "Migrationg to gnome Documentation Build
# utilities". No Idea, what it does.
AC_CONFIG_MACRO_DIR([m4])

# give autoconf the name of a file whose existence is a hint that
# autoconf has been started from the right directory.
AC_CONFIG_SRCDIR([src/diskusagemeter.c])

# Tell autoconf where to put the output file that contains all
# definitions our C program will need
AC_CONFIG_HEADER([src/config.h:src/config.hin])

# Initialize automake, and tell it to tell the C compiler to output as
# many warnings as it can
AM_INIT_AUTOMAKE([-Wall foreign])

# The GNU Gettext version we used for internationalization of our
# program...
AM_GNU_GETTEXT_VERSION([0.16.1])
# ...Or alternatively the local gnu gettext installation
AM_GNU_GETTEXT([external])

# Check for a C compiler
AC_PROG_CC

# Include all m4 macros that have to do with the language C
AC_LANG_C

# ???
AC_ISC_POSIX

# ???
AC_HEADER_STDC

# Checks for programs.
AC_PROG_CC

# We need the following type definitions from autoconf - or somebody else.
AC_TYPE_INT8_T
AC_TYPE_INT16_T
AC_TYPE_INT32_T

# AC_CHECK_LIB(libgnome-2.0, gnome_help_display_uri, [AC_DEFINE(HAVE_LIBGNOME, 1)])

# Prepare building the gnome documentation of this program
#GNOME_DOC_INIT

# Checks for libraries.
dnl Checking for the required libraries.
GTK_REQUIRED_VERSION=2.0.0
LIBGNOMEUI_REQUIRED_VERSION=2.0.0
GCONF_REQUIRED_VERSION=2.0.0
GNOMEVFS_REQUIRED_VERSION=2.0.0
ALSA_REQUIRED_VERSION=1.0.0
OGG_REQUIRED_VERSION=1.0.0
VORBIS_REQUIRED_VERSION=1.0.0
VORBISENC_REQUIRED_VERSION=1.0.0
PKG_CHECK_MODULES(DEPEND, gtk+-2.0 >= $GTK_REQUIRED_VERSION gconf-2.0 >= $GCONF_REQUIRED_VERSION gnome-vfs-2.0 >= $GNOMEVFS_REQUIRED_VERSION libgnomeui-2.0 >= $LIBGNOMEUI_REQUIRED_VERSION alsa >= $ALSA_REQUIRED_VERSION ogg >= $OGG_REQUIRED_VERSION vorbis >= $VORBIS_REQUIRED_VERSION vorbisenc >= $VORBISENC_REQUIRED_VERSION)

AC_SUBST(DEPEND_CFLAGS)
AC_SUBST(DEPEND_LIBS)

# Gettext wants to know the path to the top directory and such things...
top_builddir=`pwd`
AC_SUBST(top_builddir)
AC_SUBST(PACKAGE)
AC_SUBST(LOCALEDIR)

# Checks for the header files we include.
AC_HEADER_STDC
AC_CHECK_HEADERS([fcntl.h stdlib.h string.h sys/vfs.h])

# Checks for typedefs, structures, and compiler characteristics.
AC_C_CONST

# Checks for library functions that we really need.
AC_FUNC_MALLOC

# A list of all configuration files we have to generate
AC_CONFIG_FILES([Makefile src/Makefile src/images/Makefile po/Makefile.in]) #help/Makefile

# Tell autoconf to start outputting whatever it has to.
AC_OUTPUT
===== Makefile.am =====
This file is a template top-level-Makefile that will be filled with life by the configure script.

One thing that is added to the standard Makefile is code for automatically generate the '''_control'''-file mentioned above on a '''make dist'''
# A list of all subdirectories.
SUBDIRS = src po # help

# Allow automake to interpret m4 macros (needed for interpreting
# gettext's makefile.in
ACLOCAL_AMFLAGS = -I m4
# Files that aren't source files and still have to be in the tarball
EXTRA_DIST = @PACKAGE_NAME@_control

# An (currently unused) extension to the "install" target
install-data-local:

@PACKAGE_NAME@_control: Makefile.am configure.ac
echo "Package: @PACKAGE_NAME@">$@
echo "Version: @PACKAGE_VERSION@">>$@
echo "Description: An voice recorder that can stop recording during silence">>$@
echo "Section: openmoko/applications">>$@
echo "Priority: optional">>$@
echo "Maintainer: your_name">>$@
echo "Architecture: armv4t">>$@
echo "Homepage: (The homepage of this project)">>$@
echo "Depends: gtk+ alsa-lib libogg libvorbis gnome-vfs libgnomeui">>$@
echo "Source: \$${SRC}">>$@

===== src/Makefile.am =====
This file is a template Makefile that when filled with life by the configure script will compile our code.

The most important step here is to tell which files our program consists of.
AM_CFLAGS = $(DEPEND_CFLAGS) -Wall

AM_LDFLAGS = $(DEPEND_LIBS)

LDADD = $(LIBINTL)

bin_PROGRAMS = hello
hello_SOURCES = hello.c
{{Languages|Building_a_hello_world_application}}
[[Category:Software]]
[[Category:Guides]]

Building a hello world application

2008-05-04T10:45:49Z

Peterpall: /* Will try to make my descriptions canonical. */

=== Preparation ===
This guide assumes that you have performed the steps in [[Building_OpenMoko_from_scratch]]

=== The commandline program ===
Store the following more or less standard hello world code in hello.c

#include <stdio.h>

int main()
{
printf ("Hello World\n");
return 0;
}

=== Compiling it the ''wrong'' / easy way ===
Assuming your current working directory is '''/home/moko''', and that you stored the code in '''/home/moko/hello.c''' it should now be possible to compile the application using
./build/tmp/cross/arm-linux/bin/gcc -o hello hello.c

==== Testing it ====
Assuming you have followed [[OpenMoko_under_QEMU#Setting_up_USB_connection|Setting up USB connection]] and you have a working network connection to either a qemu Neo or a real Neo.
scp hello root@192.168.0.202:/tmp/
ssh root@192.168.0.202 /tmp/hello
This sequence of commands ought to give you a nice ''Hello World'', btw. the default root password is blank, just press return.

=== GDK the Wrong / Easy Way ===
Building a GDK application the wrong way is slightly more complex, but is still fun to try. It requires using pkg-config to specify including and linking with the ARM header files and libraries.

Given the following program as main.c:

#include <gtk/gtk.h>

gchar *hello = "Howdy";
gchar *world = "World";
GtkWidget *label;
gchar *labeltext;

void buttoncb(GtkWidget *widget, gpointer data)
{
if (labeltext == hello)
{
labeltext = world;
gtk_label_set_text(GTK_LABEL(label), labeltext);
}
else if (labeltext == world)
gtk_main_quit();
}

int main(int argc, char *argv[])
{
GtkWidget *window;
GtkWidget *button;

gtk_init(&argc, &argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
button = gtk_button_new();
labeltext = hello;
label = gtk_label_new(labeltext);
gtk_container_add(GTK_CONTAINER(button), label);
g_signal_connect(G_OBJECT(button), "clicked", G_CALLBACK(buttoncb), NULL);
gtk_container_add(GTK_CONTAINER(window), button);
gtk_widget_show_all(window);
gtk_main();

return 0;
}

You must first point pkg-config to the proper directory:

export PKG_CONFIG_PATH=/home/username/moko/build/tmp/staging/arm-linux/lib/pkgconfig

And set up an environment variable to make things easier:

export OMDIR=/home/username/moko

The compile/link line is rather long - you will only want to do this once before you decide to create a shell script or make file:

$OMDIR/build/tmp/cross/arm-angstrom-linux-gnueabi/bin/gcc -L $OMDIR/build/tmp/staging/arm-angstrom-linux-gnueabi/lib/ \
-Wl, rpath-link, $OMDIR/build/tmp/staging/arm-angstrom-linux-gnueabi/lib/ -Wl, -O1 -g -o hw main.c \
'$OMDIR/build/tmp/staging/i686-linux/bin/pkg-config --cflags --libs openmoko-libs gtk+-2.0'

Then copy and run as in the original hello world command line program above.

===== Why was it the ''wrong'' way? =====
OpenMoko provides a precompiled [[Toolchain]] package for that. It also comes with some scripts that make your life much easier. Besides, you don't need [[OpenEmbedded]] to build applications. If you ''do'' want to customize your complete distribution, then read on how to use bitbake when building stuff. In any way, at least you now know that you can easily cross compile for OpenMoko.

=== The Right Way: Using the gnome build system ===
Even if I am no expert in this - somebody had to make a start so I'll write down everything I still believe to remember from my 1st 'real' gnome application that used the autotools and all: I have never been able to find a good tutorial for making a "canonical" gnome application - and such a tutorial is urgently needed.

Since I know that many of these things will be missing or even inaccurate in the 1st step - if You find out to make it work better or at all - please document how to do this.

===== Creating the necessary documentation files and directory structure =====
First of all go into the directory you want to be the topmost application of yout new application, and create the following files:
{|
AUTHORS||A list of all authors that took part in developing this project
COPYING||The copyright notice. Favourably the GPL
INSTALL||This file should contain the information how to build and install this program
README||This file should contain all important information about the program including what the program was written for.
NEWS||The name of this file should be self-describing
TODO||The wishlist of your project
Changelog||A list of the major changes to your project
|}
I remember that some of these files were mandatory - it's better create them all

Then create a directory named '''src'' - and copy the source code of the program there.

===== The configuration of the autotools =====
====== autogen.sh ======
This file is a shell script that calls all autotools in the right order and with the right parameters so they will in the end generate the standard configure script that will detect how to build our program.

#! /bin/sh
#
# Most if not all of the contents of this file was taken from the openmoko
# sample application as it was shipped with the openmoko toolchain on
# January 31st, 2008
#

srcdir=`dirname $0`
test -z "$srcdir" && srcdir=.

PKG_NAME="hello"

(test -f $srcdir/configure.ac) || {
echo -n "**Error**: Directory "\`$srcdir\'" does not look like the"
echo " top-level $PKG_NAME directory"
exit 1
}

which gnome-autogen.sh || {
echo "You need to install gnome-common from the GNOME CVS"
exit 1
}

REQUIRED_AUTOMAKE_VERSION=1.7 USE_GNOME2_MACROS=0 REQUIRED_GETTEXT_VERSION=0.10.36 . gnome-autogen.sh

====== configure.ac ======
This file tells what the configure script has to do - and which parts of the intelligence delivered with the tools that generate the configure script we need.

I documented every line of which I found out what it actually does. The first line is for to tell the emacs text editor that it has to treat this file as an autoconf file.
# -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.

# Tell autoconf to check what version of autoconf we need.
AC_PREREQ(2.61)

# Initialize autoconf and tell it what program we wrote, the version
# of our program, and the address bug reports have to be sent to.
AC_INIT([audiorec],[0.2],[audiorec.projects.openmoko.org])

# tell autoconf where to put the temporary files it generates
AC_CONFIG_AUX_DIR([build-aux])

# This one is thaken from the "Migrationg to gnome Documentation Build
# utilities". No Idea, what it does.
AC_CONFIG_MACRO_DIR([m4])

# give autoconf the name of a file whose existence is a hint that
# autoconf has been started from the right directory.
AC_CONFIG_SRCDIR([src/diskusagemeter.c])

# Tell autoconf where to put the output file that contains all
# definitions our C program will need
AC_CONFIG_HEADER([src/config.h:src/config.hin])

# Initialize automake, and tell it to tell the C compiler to output as
# many warnings as it can
AM_INIT_AUTOMAKE([-Wall foreign])

# The GNU Gettext version we used for internationalization of our
# program...
AM_GNU_GETTEXT_VERSION([0.16.1])
# ...Or alternatively the local gnu gettext installation
AM_GNU_GETTEXT([external])

# Check for a C compiler
AC_PROG_CC

# Include all m4 macros that have to do with the language C
AC_LANG_C

# ???
AC_ISC_POSIX

# ???
AC_HEADER_STDC

# Checks for programs.
AC_PROG_CC

# We need the following type definitions from autoconf - or somebody else.
AC_TYPE_INT8_T
AC_TYPE_INT16_T
AC_TYPE_INT32_T

# AC_CHECK_LIB(libgnome-2.0, gnome_help_display_uri, [AC_DEFINE(HAVE_LIBGNOME, 1)])

# Prepare building the gnome documentation of this program
#GNOME_DOC_INIT

# Checks for libraries.
dnl Checking for the required libraries.
GTK_REQUIRED_VERSION=2.0.0
LIBGNOMEUI_REQUIRED_VERSION=2.0.0
GCONF_REQUIRED_VERSION=2.0.0
GNOMEVFS_REQUIRED_VERSION=2.0.0
ALSA_REQUIRED_VERSION=1.0.0
OGG_REQUIRED_VERSION=1.0.0
VORBIS_REQUIRED_VERSION=1.0.0
VORBISENC_REQUIRED_VERSION=1.0.0
PKG_CHECK_MODULES(DEPEND, gtk+-2.0 >= $GTK_REQUIRED_VERSION gconf-2.0 >= $GCONF_REQUIRED_VERSION gnome-vfs-2.0 >= $GNOMEVFS_REQUIRED_VERSION libgnomeui-2.0 >= $LIBGNOMEUI_REQUIRED_VERSION alsa >= $ALSA_REQUIRED_VERSION ogg >= $OGG_REQUIRED_VERSION vorbis >= $VORBIS_REQUIRED_VERSION vorbisenc >= $VORBISENC_REQUIRED_VERSION)

AC_SUBST(DEPEND_CFLAGS)
AC_SUBST(DEPEND_LIBS)

# Gettext wants to know the path to the top directory and such things...
top_builddir=`pwd`
AC_SUBST(top_builddir)
AC_SUBST(PACKAGE)
AC_SUBST(LOCALEDIR)

# Checks for the header files we include.
AC_HEADER_STDC
AC_CHECK_HEADERS([fcntl.h stdlib.h string.h sys/vfs.h])

# Checks for typedefs, structures, and compiler characteristics.
AC_C_CONST

# Checks for library functions that we really need.
AC_FUNC_MALLOC

# A list of all configuration files we have to generate
AC_CONFIG_FILES([Makefile src/Makefile src/images/Makefile po/Makefile.in]) #help/Makefile

# Tell autoconf to start outputting whatever it has to.
AC_OUTPUT
===== Makefile.am =====
This file is a template top-level-Makefile that will be filled with life by the configure script.

One thing that is added to the standard Makefile is code for automatically generate the '''_control'''-file mentioned above on a '''make dist'''
# A list of all subdirectories.
SUBDIRS = src po # help

# Allow automake to interpret m4 macros (needed for interpreting
# gettext's makefile.in
ACLOCAL_AMFLAGS = -I m4
# Files that aren't source files and still have to be in the tarball
EXTRA_DIST = @PACKAGE_NAME@_control

# An (currently unused) extension to the "install" target
install-data-local:

@PACKAGE_NAME@_control: Makefile.am configure.ac
echo "Package: @PACKAGE_NAME@">$@
echo "Version: @PACKAGE_VERSION@">>$@
echo "Description: An voice recorder that can stop recording during silence">>$@
echo "Section: openmoko/applications">>$@
echo "Priority: optional">>$@
echo "Maintainer: your_name">>$@
echo "Architecture: armv4t">>$@
echo "Homepage: (The homepage of this project)">>$@
echo "Depends: gtk+ alsa-lib libogg libvorbis gnome-vfs libgnomeui">>$@
echo "Source: \$${SRC}">>$@

{{Languages|Building_a_hello_world_application}}
[[Category:Software]]
[[Category:Guides]]

Building a hello world application

2008-05-04T10:42:14Z

Peterpall: /* Makefile.am */

=== Preparation ===
This guide assumes that you have performed the steps in [[Building_OpenMoko_from_scratch]]

=== The commandline program ===
Store the following more or less standard hello world code in hello.c

#include <stdio.h>

int main()
{
printf ("Hello World\n");
return 0;
}

=== Compiling it the ''wrong'' / easy way ===
Assuming your current working directory is '''/home/moko''', and that you stored the code in '''/home/moko/hello.c''' it should now be possible to compile the application using
./build/tmp/cross/arm-linux/bin/gcc -o hello hello.c

==== Testing it ====
Assuming you have followed [[OpenMoko_under_QEMU#Setting_up_USB_connection|Setting up USB connection]] and you have a working network connection to either a qemu Neo or a real Neo.
scp hello root@192.168.0.202:/tmp/
ssh root@192.168.0.202 /tmp/hello
This sequence of commands ought to give you a nice ''Hello World'', btw. the default root password is blank, just press return.

=== GDK the Wrong / Easy Way ===
Building a GDK application the wrong way is slightly more complex, but is still fun to try. It requires using pkg-config to specify including and linking with the ARM header files and libraries.

Given the following program as main.c:

#include <gtk/gtk.h>

gchar *hello = "Howdy";
gchar *world = "World";
GtkWidget *label;
gchar *labeltext;

void buttoncb(GtkWidget *widget, gpointer data)
{
if (labeltext == hello)
{
labeltext = world;
gtk_label_set_text(GTK_LABEL(label), labeltext);
}
else if (labeltext == world)
gtk_main_quit();
}

int main(int argc, char *argv[])
{
GtkWidget *window;
GtkWidget *button;

gtk_init(&argc, &argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
button = gtk_button_new();
labeltext = hello;
label = gtk_label_new(labeltext);
gtk_container_add(GTK_CONTAINER(button), label);
g_signal_connect(G_OBJECT(button), "clicked", G_CALLBACK(buttoncb), NULL);
gtk_container_add(GTK_CONTAINER(window), button);
gtk_widget_show_all(window);
gtk_main();

return 0;
}

You must first point pkg-config to the proper directory:

export PKG_CONFIG_PATH=/home/username/moko/build/tmp/staging/arm-linux/lib/pkgconfig

And set up an environment variable to make things easier:

export OMDIR=/home/username/moko

The compile/link line is rather long - you will only want to do this once before you decide to create a shell script or make file:

$OMDIR/build/tmp/cross/arm-angstrom-linux-gnueabi/bin/gcc -L $OMDIR/build/tmp/staging/arm-angstrom-linux-gnueabi/lib/ \
-Wl, rpath-link, $OMDIR/build/tmp/staging/arm-angstrom-linux-gnueabi/lib/ -Wl, -O1 -g -o hw main.c \
'$OMDIR/build/tmp/staging/i686-linux/bin/pkg-config --cflags --libs openmoko-libs gtk+-2.0'

Then copy and run as in the original hello world command line program above.

===== Why was it the ''wrong'' way? =====
OpenMoko provides a precompiled [[Toolchain]] package for that. It also comes with some scripts that make your life much easier. Besides, you don't need [[OpenEmbedded]] to build applications. If you ''do'' want to customize your complete distribution, then read on how to use bitbake when building stuff. In any way, at least you now know that you can easily cross compile for OpenMoko.

=== The Right Way: Using the gnome build system ===
Even if I am no expert in this - somebody had to make a start so I'll write down everything I still believe to remember from my 1st 'real' gnome application that used the autotools and all: I have never been able to find a good tutorial for making a "canonical" gnome application - and such a tutorial is urgently needed.

Since I know that many of these things will be missing or even inaccurate in the 1st step - if You find out to make it work better or at all - please document how to do this.

===== Creating the necessary documentation files and directory structure =====
First of all go into the directory you want to be the topmost application of yout new application, and create the following files:
{|
AUTHORS||A list of all authors that took part in developing this project
COPYING||The copyright notice. Favourably the GPL
INSTALL||This file should contain the information how to build and install this program
README||This file should contain all important information about the program including what the program was written for.
NEWS||The name of this file should be self-describing
TODO||The wishlist of your project
Changelog||A list of the major changes to your project
|}
I remember that some of these files were mandatory - it's better create them all

Then create a directory named '''src'' - and copy the source code of the program there.

===== The configuration of the autotools =====
====== autogen.sh ======
This file is a shell script that calls all autotools in the right order and with the right parameters so they will in the end generate the standard configure script that will detect how to build our program.

#! /bin/sh
#
# Most if not all of the contents of this file was taken from the openmoko
# sample application as it was shipped with the openmoko toolchain on
# January 31st, 2008
#

srcdir=`dirname $0`
test -z "$srcdir" && srcdir=.

PKG_NAME="helloworld"

(test -f $srcdir/configure.ac) || {
echo -n "**Error**: Directory "\`$srcdir\'" does not look like the"
echo " top-level $PKG_NAME directory"
exit 1
}

which gnome-autogen.sh || {
echo "You need to install gnome-common from the GNOME CVS"
exit 1
}

REQUIRED_AUTOMAKE_VERSION=1.7 USE_GNOME2_MACROS=0 REQUIRED_GETTEXT_VERSION=0.10.36 . gnome-autogen.sh
====== configure.ac ======
This file tells what the configure script has to do - and which parts of the intelligence delivered with the tools that generate the configure script we need.

I documented every line of which I found out what it actually does. The first line is for to tell the emacs text editor that it has to treat this file as an autoconf file.
# -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.

# Tell autoconf to check what version of autoconf we need.
AC_PREREQ(2.61)

# Initialize autoconf and tell it what program we wrote, the version
# of our program, and the address bug reports have to be sent to.
AC_INIT([audiorec],[0.2],[audiorec.projects.openmoko.org])

# tell autoconf where to put the temporary files it generates
AC_CONFIG_AUX_DIR([build-aux])

# This one is thaken from the "Migrationg to gnome Documentation Build
# utilities". No Idea, what it does.
AC_CONFIG_MACRO_DIR([m4])

# give autoconf the name of a file whose existence is a hint that
# autoconf has been started from the right directory.
AC_CONFIG_SRCDIR([src/diskusagemeter.c])

# Tell autoconf where to put the output file that contains all
# definitions our C program will need
AC_CONFIG_HEADER([src/config.h:src/config.hin])

# Initialize automake, and tell it to tell the C compiler to output as
# many warnings as it can
AM_INIT_AUTOMAKE([-Wall foreign])

# The GNU Gettext version we used for internationalization of our
# program...
AM_GNU_GETTEXT_VERSION([0.16.1])
# ...Or alternatively the local gnu gettext installation
AM_GNU_GETTEXT([external])

# Check for a C compiler
AC_PROG_CC

# Include all m4 macros that have to do with the language C
AC_LANG_C

# ???
AC_ISC_POSIX

# ???
AC_HEADER_STDC

# Checks for programs.
AC_PROG_CC

# We need the following type definitions from autoconf - or somebody else.
AC_TYPE_INT8_T
AC_TYPE_INT16_T
AC_TYPE_INT32_T

# AC_CHECK_LIB(libgnome-2.0, gnome_help_display_uri, [AC_DEFINE(HAVE_LIBGNOME, 1)])

# Prepare building the gnome documentation of this program
#GNOME_DOC_INIT

# Checks for libraries.
dnl Checking for the required libraries.
GTK_REQUIRED_VERSION=2.0.0
LIBGNOMEUI_REQUIRED_VERSION=2.0.0
GCONF_REQUIRED_VERSION=2.0.0
GNOMEVFS_REQUIRED_VERSION=2.0.0
ALSA_REQUIRED_VERSION=1.0.0
OGG_REQUIRED_VERSION=1.0.0
VORBIS_REQUIRED_VERSION=1.0.0
VORBISENC_REQUIRED_VERSION=1.0.0
PKG_CHECK_MODULES(DEPEND, gtk+-2.0 >= $GTK_REQUIRED_VERSION gconf-2.0 >= $GCONF_REQUIRED_VERSION gnome-vfs-2.0 >= $GNOMEVFS_REQUIRED_VERSION libgnomeui-2.0 >= $LIBGNOMEUI_REQUIRED_VERSION alsa >= $ALSA_REQUIRED_VERSION ogg >= $OGG_REQUIRED_VERSION vorbis >= $VORBIS_REQUIRED_VERSION vorbisenc >= $VORBISENC_REQUIRED_VERSION)

AC_SUBST(DEPEND_CFLAGS)
AC_SUBST(DEPEND_LIBS)

# Gettext wants to know the path to the top directory and such things...
top_builddir=`pwd`
AC_SUBST(top_builddir)
AC_SUBST(PACKAGE)
AC_SUBST(LOCALEDIR)

# Checks for the header files we include.
AC_HEADER_STDC
AC_CHECK_HEADERS([fcntl.h stdlib.h string.h sys/vfs.h])

# Checks for typedefs, structures, and compiler characteristics.
AC_C_CONST

# Checks for library functions that we really need.
AC_FUNC_MALLOC

# A list of all configuration files we have to generate
AC_CONFIG_FILES([Makefile src/Makefile src/images/Makefile po/Makefile.in]) #help/Makefile

# Tell autoconf to start outputting whatever it has to.
AC_OUTPUT
===== Makefile.am =====
This file is a template top-level-Makefile that will be filled with life by the configure script.

One thing that is added to the standard Makefile is code for automatically generate the '''_control'''-file mentioned above on a '''make dist'''
# A list of all subdirectories.
SUBDIRS = src po # help

# Allow automake to interpret m4 macros (needed for interpreting
# gettext's makefile.in
ACLOCAL_AMFLAGS = -I m4
# Files that aren't source files and still have to be in the tarball
EXTRA_DIST = @PACKAGE_NAME@_control

# An (currently unused) extension to the "install" target
install-data-local:

@PACKAGE_NAME@_control: Makefile.am configure.ac
echo "Package: @PACKAGE_NAME@">$@
echo "Version: @PACKAGE_VERSION@">>$@
echo "Description: An voice recorder that can stop recording during silence">>$@
echo "Section: openmoko/applications">>$@
echo "Priority: optional">>$@
echo "Maintainer: your_name">>$@
echo "Architecture: armv4t">>$@
echo "Homepage: (The homepage of this project)">>$@
echo "Depends: gtk+ alsa-lib libogg libvorbis gnome-vfs libgnomeui">>$@
echo "Source: \$${SRC}">>$@

{{Languages|Building_a_hello_world_application}}
[[Category:Software]]
[[Category:Guides]]

Building a hello world application

2008-05-04T10:34:17Z

Peterpall: /* configure.ac */

=== Preparation ===
This guide assumes that you have performed the steps in [[Building_OpenMoko_from_scratch]]

=== The commandline program ===
Store the following more or less standard hello world code in hello.c

#include <stdio.h>

int main()
{
printf ("Hello World\n");
return 0;
}

=== Compiling it the ''wrong'' / easy way ===
Assuming your current working directory is '''/home/moko''', and that you stored the code in '''/home/moko/hello.c''' it should now be possible to compile the application using
./build/tmp/cross/arm-linux/bin/gcc -o hello hello.c

==== Testing it ====
Assuming you have followed [[OpenMoko_under_QEMU#Setting_up_USB_connection|Setting up USB connection]] and you have a working network connection to either a qemu Neo or a real Neo.
scp hello root@192.168.0.202:/tmp/
ssh root@192.168.0.202 /tmp/hello
This sequence of commands ought to give you a nice ''Hello World'', btw. the default root password is blank, just press return.

=== GDK the Wrong / Easy Way ===
Building a GDK application the wrong way is slightly more complex, but is still fun to try. It requires using pkg-config to specify including and linking with the ARM header files and libraries.

Given the following program as main.c:

#include <gtk/gtk.h>

gchar *hello = "Howdy";
gchar *world = "World";
GtkWidget *label;
gchar *labeltext;

void buttoncb(GtkWidget *widget, gpointer data)
{
if (labeltext == hello)
{
labeltext = world;
gtk_label_set_text(GTK_LABEL(label), labeltext);
}
else if (labeltext == world)
gtk_main_quit();
}

int main(int argc, char *argv[])
{
GtkWidget *window;
GtkWidget *button;

gtk_init(&argc, &argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
button = gtk_button_new();
labeltext = hello;
label = gtk_label_new(labeltext);
gtk_container_add(GTK_CONTAINER(button), label);
g_signal_connect(G_OBJECT(button), "clicked", G_CALLBACK(buttoncb), NULL);
gtk_container_add(GTK_CONTAINER(window), button);
gtk_widget_show_all(window);
gtk_main();

return 0;
}

You must first point pkg-config to the proper directory:

export PKG_CONFIG_PATH=/home/username/moko/build/tmp/staging/arm-linux/lib/pkgconfig

And set up an environment variable to make things easier:

export OMDIR=/home/username/moko

The compile/link line is rather long - you will only want to do this once before you decide to create a shell script or make file:

$OMDIR/build/tmp/cross/arm-angstrom-linux-gnueabi/bin/gcc -L $OMDIR/build/tmp/staging/arm-angstrom-linux-gnueabi/lib/ \
-Wl, rpath-link, $OMDIR/build/tmp/staging/arm-angstrom-linux-gnueabi/lib/ -Wl, -O1 -g -o hw main.c \
'$OMDIR/build/tmp/staging/i686-linux/bin/pkg-config --cflags --libs openmoko-libs gtk+-2.0'

Then copy and run as in the original hello world command line program above.

===== Why was it the ''wrong'' way? =====
OpenMoko provides a precompiled [[Toolchain]] package for that. It also comes with some scripts that make your life much easier. Besides, you don't need [[OpenEmbedded]] to build applications. If you ''do'' want to customize your complete distribution, then read on how to use bitbake when building stuff. In any way, at least you now know that you can easily cross compile for OpenMoko.

=== The Right Way: Using the gnome build system ===
Even if I am no expert in this - somebody had to make a start so I'll write down everything I still believe to remember from my 1st 'real' gnome application that used the autotools and all: I have never been able to find a good tutorial for making a "canonical" gnome application - and such a tutorial is urgently needed.

Since I know that many of these things will be missing or even inaccurate in the 1st step - if You find out to make it work better or at all - please document how to do this.

===== Creating the necessary documentation files and directory structure =====
First of all go into the directory you want to be the topmost application of yout new application, and create the following files:
{|
AUTHORS||A list of all authors that took part in developing this project
COPYING||The copyright notice. Favourably the GPL
INSTALL||This file should contain the information how to build and install this program
README||This file should contain all important information about the program including what the program was written for.
NEWS||The name of this file should be self-describing
TODO||The wishlist of your project
Changelog||A list of the major changes to your project
|}
I remember that some of these files were mandatory - it's better create them all

Then create a directory named '''src'' - and copy the source code of the program there.

===== The configuration of the autotools =====
====== autogen.sh ======
This file is a shell script that calls all autotools in the right order and with the right parameters so they will in the end generate the standard configure script that will detect how to build our program.

#! /bin/sh
#
# Most if not all of the contents of this file was taken from the openmoko
# sample application as it was shipped with the openmoko toolchain on
# January 31st, 2008
#

srcdir=`dirname $0`
test -z "$srcdir" && srcdir=.

PKG_NAME="helloworld"

(test -f $srcdir/configure.ac) || {
echo -n "**Error**: Directory "\`$srcdir\'" does not look like the"
echo " top-level $PKG_NAME directory"
exit 1
}

which gnome-autogen.sh || {
echo "You need to install gnome-common from the GNOME CVS"
exit 1
}

REQUIRED_AUTOMAKE_VERSION=1.7 USE_GNOME2_MACROS=0 REQUIRED_GETTEXT_VERSION=0.10.36 . gnome-autogen.sh
====== configure.ac ======
This file tells what the configure script has to do - and which parts of the intelligence delivered with the tools that generate the configure script we need.

I documented every line of which I found out what it actually does. The first line is for to tell the emacs text editor that it has to treat this file as an autoconf file.
# -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.

# Tell autoconf to check what version of autoconf we need.
AC_PREREQ(2.61)

# Initialize autoconf and tell it what program we wrote, the version
# of our program, and the address bug reports have to be sent to.
AC_INIT([audiorec],[0.2],[audiorec.projects.openmoko.org])

# tell autoconf where to put the temporary files it generates
AC_CONFIG_AUX_DIR([build-aux])

# This one is thaken from the "Migrationg to gnome Documentation Build
# utilities". No Idea, what it does.
AC_CONFIG_MACRO_DIR([m4])

# give autoconf the name of a file whose existence is a hint that
# autoconf has been started from the right directory.
AC_CONFIG_SRCDIR([src/diskusagemeter.c])

# Tell autoconf where to put the output file that contains all
# definitions our C program will need
AC_CONFIG_HEADER([src/config.h:src/config.hin])

# Initialize automake, and tell it to tell the C compiler to output as
# many warnings as it can
AM_INIT_AUTOMAKE([-Wall foreign])

# The GNU Gettext version we used for internationalization of our
# program...
AM_GNU_GETTEXT_VERSION([0.16.1])
# ...Or alternatively the local gnu gettext installation
AM_GNU_GETTEXT([external])

# Check for a C compiler
AC_PROG_CC

# Include all m4 macros that have to do with the language C
AC_LANG_C

# ???
AC_ISC_POSIX

# ???
AC_HEADER_STDC

# Checks for programs.
AC_PROG_CC

# We need the following type definitions from autoconf - or somebody else.
AC_TYPE_INT8_T
AC_TYPE_INT16_T
AC_TYPE_INT32_T

# AC_CHECK_LIB(libgnome-2.0, gnome_help_display_uri, [AC_DEFINE(HAVE_LIBGNOME, 1)])

# Prepare building the gnome documentation of this program
#GNOME_DOC_INIT

# Checks for libraries.
dnl Checking for the required libraries.
GTK_REQUIRED_VERSION=2.0.0
LIBGNOMEUI_REQUIRED_VERSION=2.0.0
GCONF_REQUIRED_VERSION=2.0.0
GNOMEVFS_REQUIRED_VERSION=2.0.0
ALSA_REQUIRED_VERSION=1.0.0
OGG_REQUIRED_VERSION=1.0.0
VORBIS_REQUIRED_VERSION=1.0.0
VORBISENC_REQUIRED_VERSION=1.0.0
PKG_CHECK_MODULES(DEPEND, gtk+-2.0 >= $GTK_REQUIRED_VERSION gconf-2.0 >= $GCONF_REQUIRED_VERSION gnome-vfs-2.0 >= $GNOMEVFS_REQUIRED_VERSION libgnomeui-2.0 >= $LIBGNOMEUI_REQUIRED_VERSION alsa >= $ALSA_REQUIRED_VERSION ogg >= $OGG_REQUIRED_VERSION vorbis >= $VORBIS_REQUIRED_VERSION vorbisenc >= $VORBISENC_REQUIRED_VERSION)

AC_SUBST(DEPEND_CFLAGS)
AC_SUBST(DEPEND_LIBS)

# Gettext wants to know the path to the top directory and such things...
top_builddir=`pwd`
AC_SUBST(top_builddir)
AC_SUBST(PACKAGE)
AC_SUBST(LOCALEDIR)

# Checks for the header files we include.
AC_HEADER_STDC
AC_CHECK_HEADERS([fcntl.h stdlib.h string.h sys/vfs.h])

# Checks for typedefs, structures, and compiler characteristics.
AC_C_CONST

# Checks for library functions that we really need.
AC_FUNC_MALLOC

# Check for doxygen, so we can decide if we create a "doc" make target
# that depends on doxygen-
AC_CHECK_PROG([DOXYGEN], [doxygen], [doc], [])
AC_SUBST(DOXYGEN)

# A list of all configuration files we have to generate
AC_CONFIG_FILES([Makefile src/Makefile src/images/Makefile po/Makefile.in doc/Makefile]) #help/Makefile

# Tell autoconf to start outputting whatever it has to.
AC_OUTPUT

{{Languages|Building_a_hello_world_application}}
[[Category:Software]]
[[Category:Guides]]

Building a hello world application

2008-05-04T10:25:04Z

Peterpall: /* Seems this line was intodruced accidentally- */