Openmoko - User contributions [en]

MokoMakefile

2009-02-11T11:28:47Z

RodWhitby: /* 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.

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 [[http://downloads.openmoko.org/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 the stable, testing and unstable versions of the FSO distribution images.

MokoMakefile no longer builds the QEMU-based Neo1973 emulator.

== 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:

<pre>ncurses zlib (or libz) OpenSSL GTK++</pre>

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 =====

<pre>sudo apt-get install subversion build-essential help2man diffstat texi2html texinfo cvs gawk zip unzip cogito bzip2
sudo apt-get install libncurses5-dev zlib1g-dev libssl-dev libgtk2.0-dev
# To prevent errors in host validation
sudo apt-get install ca-certificates
# For Openmoko 2007.2 using BitBake-1.8.8:
sudo apt-get install python-pysqlite2 sqlite3 sqlite3-doc python-pysqlite2-dbg
# For building faster
sudo apt-get install quilt python-psyco ccache
# For qemu, install a second compiler for bug avoidance; MokoMakefile knows to look for it.
sudo apt-get install gcc-3.4 g++-3.4 libsdl1.2-dev lynx netpbm dosfstools

# On Ubuntu 8.04 and and Debian testing/unstable, the following was required instead of cogito
sudo apt-get install git-core
# Ubuntu links /bin/sh to /bin/dash, but some scripts fail because they use pushd and popd, which dash does not support
sudo dpkg-reconfigure dash
# Select No when it asks you to install dash as /bin/sh.

# This may be needed only for ASU
sudo apt-get install libxtst-dev</pre>

===== SuSE =====
For building Openmoko on 10.3, you need

<pre>gcc-c++ ncurses-devel zlib-devel libopenssl-devel gtk2-devel subversion diffstat texinfo help2man</pre>

For MokoMakefile to not fail on compiling qemu-user, you need to use gcc33:

wget [http://download.opensuse.org/repositories/devel:/tools:/gcc/openSUSE_Factory/i586/{cpp,gcc}33-3.3.3-41.8.i586.rpm http://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.

===== Mandriva =====

<pre>urpmi git help2man diffstat texi2html texinfo</pre>

(Tested with Mandriva 2009.0. <tt>kernel-desktop-devel</tt> of the current kernel is installed in advance, which installs compilers, binutils and many other general compilation tools.)

==== 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:

<pre>ENABLE_BINARY_LOCALE_GENERATION = "0"</pre>

===== 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):

<pre>mkdir ~/moko ; cd ~/moko</pre>

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.
If you ever want to move your $OMDIR to another location, you must run

<pre>make clobber ; make setup</pre>

to reinitialize the environment. Yes, this will take a long time, so choose $OMDIR carefully.

=== MokoMakefile ===

Grab MokoMakefile:

wget [http://downloads.freesmartphone.org/Makefile http://downloads.freesmartphone.org/Makefile]

{{note|MokoMakefile uses BitBake 1.8.x 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 with:

<pre>make setup</pre>

=== Building ===

Before starting a lengthy make process, check the [[#Tips|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.

<pre>make fso-gta02-testing-image</pre>

or

<pre>make fso-gta01-testing-image</pre>

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

This will set up the recommended directory structure, 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 fso-testing directory and run bitbake commands manually. The choice is yours.

With luck - you should now have images in your ${OMDIR}/fso-testing/tmp/deploy/glibc/images/ directory. You can then [[Flashing the Neo FreeRunner|flash these]].

==Updating the environment==

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

1 - To update the MokoMakefile to the latest version:

<pre>make update-common</pre>

Be aware that any changes you previously made to the Makefile are lost when executing ''update-makefile''.

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

<pre>make setup</pre>

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

<pre>make update</pre>

A quick way to rebuild a new image with the latest updates:

<pre>make update-common && make setup update fso-gta02-testing-image</pre>

==Build issues==

First, make sure that the problem is reproducible after running

<pre>make update-common && make setup && make update</pre>

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 in the Openmoko development Trac at https://docs.openmoko.org/trac/wiki/NewTicket or in #openmoko on [[Development_resources#IRC|IRC]]. If bitbake has started to run, then it's almost guaranteed that the problem is in the OE build recipes, *not* in the MokoMakefile itself (which is just a convenience wrapper around the OpenEmbedded build system). Please do not report build recipe errors to the MokoMakefile author.

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.

<pre>`env | grep -Ev '^(SHELL|TERM|OLDPWD|USER|USERNAME|PATH|EDITOR|LANG|HOME|DISPLAY|_)=' \
| sed 's/^$.*$=.*/unset \1/'`</pre>

(you must include the backticks).

Note that on some boxes it is necessary to call "make" by typing "/usr/bin/make" afterwards.

On current Ubuntu/Debian unstable/testing 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:

<pre>sudo sysctl -w vm.mmap_min_addr=0</pre>

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:

<pre>sudo sysctl -w vm.mmap_min_addr=65536</pre>

See the talk page of this article for more details on this solution.

===Known MokoMakefile errors ===

==== SVN Server Certificate Errors ====

If you get an error like the following:

<pre>NOTE: Fetch svn://svn.projects.openmoko.org/svnroot/;module=assassin;proto=https
Error validating server certificate for 'https://svn.projects.openmoko.org:443':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
Certificate information:
- Hostname: projects.openmoko.org
- Valid: from Thu, 05 Jun 2008 01:02:42 GMT until Tue, 02 Dec 2008 01:02:42 GMT
- Issuer: http://www.cacert.org, Root CA
- Fingerprint: a5:7d:4e:37:e8:94:ee:ba:c1:e8:e9:4b:33:cb:34:91:a9:6d:d3:84
(R)eject, accept (t)emporarily or accept (p)ermanently?
svn: OPTIONS of 'https://svn.projects.openmoko.org/svnroot/assassin':
Server certificate verification failed: issuer is not trusted (https://svn.projects.openmoko.org)</pre>

It means you haven't yet accepted the server certificate for the SVN server. To remedy this, execute the following commands, and hit "p" (to permanently accept the certificate) when prompted:

<pre>cd /tmp
svn co https://svn.projects.openmoko.org/svnroot/assassin
rm -rf assassin
cd -</pre>

==== exposure_svn and Subversion 1.5.0 ====

If you get an error like this:

<code>"NameError: global name 'log' is not defined"</code>

There's a bug with subversion 1.5.0 -- downgrade to 1.4.x (or check out the latest subversion sources and use those as they're fixed) and re-fetch the sources.

=== 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"
* If a certain package does not build due to corrupted download or some such try to remove the sources and rebuild it.
<pre>rm sources/<package>*
cd fso-testing
. ./setup-env
bitbake -crebuild <package></pre>
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:
<pre>PARALLEL_MAKE = "-j 4"
BB_NUMBER_THREADS = "4"</pre>

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:
<pre>GLIBC_GENERATE_LOCALES = "en_US.UTF-8 nl_NL.UTF-8"</pre>

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

* If you want to rebuild the package indexes (for instance, after compiling a new version of a package) without building the whole <code>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.

* Make sure you do not have . in your PATH, this causes an "unrecognized option -Qy" error when building g++spec

=== 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 fso-gta02-testing-image : build the full development image

; make fso-gta02-unstable-image : build the unstable bleeding edge image (it often will not build or run)

; make update-common : updates MokoMakefile

; 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 ==

You are not advised to use MokoMakefile for application development. Openmoko distributes a stand-alone toolchain for that purpose.

== 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", "make openmoko-devel-image :) - no magic there", and "I have never been able to get a build to complete in the pure OE environment, whereas Mokomakefile for some reason builds fine."

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

[[Category:Application Developer]]
[[Category:System Developers]]

MokoMakefile

2009-02-11T11:26:40Z

RodWhitby: Updated to match the new MokoMakefile which corresponds to the latest Openmoko build instructions.

{{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.

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 [[http://downloads.openmoko.org/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 the stable, testing and unstable versions of the FSO distribution images.

MokoMakefile no longer builds the QEMU-based Neo1973 emulator.

== 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:

<pre>ncurses zlib (or libz) OpenSSL GTK++</pre>

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 =====

<pre>sudo apt-get install subversion build-essential help2man diffstat texi2html texinfo cvs gawk zip unzip cogito bzip2
sudo apt-get install libncurses5-dev zlib1g-dev libssl-dev libgtk2.0-dev
# To prevent errors in host validation
sudo apt-get install ca-certificates
# For Openmoko 2007.2 using BitBake-1.8.8:
sudo apt-get install python-pysqlite2 sqlite3 sqlite3-doc python-pysqlite2-dbg
# For building faster
sudo apt-get install quilt python-psyco ccache
# For qemu, install a second compiler for bug avoidance; MokoMakefile knows to look for it.
sudo apt-get install gcc-3.4 g++-3.4 libsdl1.2-dev lynx netpbm dosfstools

# On Ubuntu 8.04 and and Debian testing/unstable, the following was required instead of cogito
sudo apt-get install git-core
# Ubuntu links /bin/sh to /bin/dash, but some scripts fail because they use pushd and popd, which dash does not support
sudo dpkg-reconfigure dash
# Select No when it asks you to install dash as /bin/sh.

# This may be needed only for ASU
sudo apt-get install libxtst-dev</pre>

===== SuSE =====
For building Openmoko on 10.3, you need

<pre>gcc-c++ ncurses-devel zlib-devel libopenssl-devel gtk2-devel subversion diffstat texinfo help2man</pre>

For MokoMakefile to not fail on compiling qemu-user, you need to use gcc33:

wget [http://download.opensuse.org/repositories/devel:/tools:/gcc/openSUSE_Factory/i586/{cpp,gcc}33-3.3.3-41.8.i586.rpm http://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.

===== Mandriva =====

<pre>urpmi git help2man diffstat texi2html texinfo</pre>

(Tested with Mandriva 2009.0. <tt>kernel-desktop-devel</tt> of the current kernel is installed in advance, which installs compilers, binutils and many other general compilation tools.)

==== 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:

<pre>ENABLE_BINARY_LOCALE_GENERATION = "0"</pre>

===== 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):

<pre>mkdir ~/moko ; cd ~/moko</pre>

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.
If you ever want to move your $OMDIR to another location, you must run

<pre>make clobber ; make setup</pre>

to reinitialize the environment. Yes, this will take a long time, so choose $OMDIR carefully.

=== MokoMakefile ===

Grab MokoMakefile:

wget [http://www.rwhitby.net/files/openmoko/Makefile http://www.rwhitby.net/files/openmoko/Makefile]

If that doesn't work, try

wget [http://downloads.freesmartphone.org/Makefile http://downloads.freesmartphone.org/Makefile]

{{note|MokoMakefile uses BitBake 1.8.x 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 with:

<pre>make setup</pre>

=== Building ===

Before starting a lengthy make process, check the [[#Tips|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.

<pre>make fso-gta02-testing-image</pre>

or

<pre>make fso-gta01-testing-image</pre>

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

This will set up the recommended directory structure, 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 fso-testing directory and run bitbake commands manually. The choice is yours.

With luck - you should now have images in your ${OMDIR}/fso-testing/tmp/deploy/glibc/images/ directory. You can then [[Flashing the Neo FreeRunner|flash these]].

==Updating the environment==

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

1 - To update the MokoMakefile to the latest version:

<pre>make update-common</pre>

Be aware that any changes you previously made to the Makefile are lost when executing ''update-makefile''.

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

<pre>make setup</pre>

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

<pre>make update</pre>

A quick way to rebuild a new image with the latest updates:

<pre>make update-common && make setup update fso-gta02-testing-image</pre>

==Build issues==

First, make sure that the problem is reproducible after running

<pre>make update-common && make setup && make update</pre>

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 in the Openmoko development Trac at https://docs.openmoko.org/trac/wiki/NewTicket or in #openmoko on [[Development_resources#IRC|IRC]]. If bitbake has started to run, then it's almost guaranteed that the problem is in the OE build recipes, *not* in the MokoMakefile itself (which is just a convenience wrapper around the OpenEmbedded build system). Please do not report build recipe errors to the MokoMakefile author.

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.

<pre>`env | grep -Ev '^(SHELL|TERM|OLDPWD|USER|USERNAME|PATH|EDITOR|LANG|HOME|DISPLAY|_)=' \
| sed 's/^$.*$=.*/unset \1/'`</pre>

(you must include the backticks).

Note that on some boxes it is necessary to call "make" by typing "/usr/bin/make" afterwards.

On current Ubuntu/Debian unstable/testing 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:

<pre>sudo sysctl -w vm.mmap_min_addr=0</pre>

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:

<pre>sudo sysctl -w vm.mmap_min_addr=65536</pre>

See the talk page of this article for more details on this solution.

===Known MokoMakefile errors ===

==== SVN Server Certificate Errors ====

If you get an error like the following:

<pre>NOTE: Fetch svn://svn.projects.openmoko.org/svnroot/;module=assassin;proto=https
Error validating server certificate for 'https://svn.projects.openmoko.org:443':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
Certificate information:
- Hostname: projects.openmoko.org
- Valid: from Thu, 05 Jun 2008 01:02:42 GMT until Tue, 02 Dec 2008 01:02:42 GMT
- Issuer: http://www.cacert.org, Root CA
- Fingerprint: a5:7d:4e:37:e8:94:ee:ba:c1:e8:e9:4b:33:cb:34:91:a9:6d:d3:84
(R)eject, accept (t)emporarily or accept (p)ermanently?
svn: OPTIONS of 'https://svn.projects.openmoko.org/svnroot/assassin':
Server certificate verification failed: issuer is not trusted (https://svn.projects.openmoko.org)</pre>

It means you haven't yet accepted the server certificate for the SVN server. To remedy this, execute the following commands, and hit "p" (to permanently accept the certificate) when prompted:

<pre>cd /tmp
svn co https://svn.projects.openmoko.org/svnroot/assassin
rm -rf assassin
cd -</pre>

==== exposure_svn and Subversion 1.5.0 ====

If you get an error like this:

<code>"NameError: global name 'log' is not defined"</code>

There's a bug with subversion 1.5.0 -- downgrade to 1.4.x (or check out the latest subversion sources and use those as they're fixed) and re-fetch the sources.

=== 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"
* If a certain package does not build due to corrupted download or some such try to remove the sources and rebuild it.
<pre>rm sources/<package>*
cd fso-testing
. ./setup-env
bitbake -crebuild <package></pre>
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:
<pre>PARALLEL_MAKE = "-j 4"
BB_NUMBER_THREADS = "4"</pre>

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:
<pre>GLIBC_GENERATE_LOCALES = "en_US.UTF-8 nl_NL.UTF-8"</pre>

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

* If you want to rebuild the package indexes (for instance, after compiling a new version of a package) without building the whole <code>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.

* Make sure you do not have . in your PATH, this causes an "unrecognized option -Qy" error when building g++spec

=== 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 fso-gta02-testing-image : build the full development image

; make fso-gta02-unstable-image : build the unstable bleeding edge image (it often will not build or run)

; make update-common : updates MokoMakefile

; 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 ==

You are not advised to use MokoMakefile for application development. Openmoko distributes a stand-alone toolchain for that purpose.

== 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", "make openmoko-devel-image :) - no magic there", and "I have never been able to get a build to complete in the pure OE environment, whereas Mokomakefile for some reason builds fine."

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

[[Category:Application Developer]]
[[Category:System Developers]]

Building FSO

2009-02-07T13:28:25Z

RodWhitby:

{{FSO}}

The freesmartphone.org (FSO) image is based on the OpenEmbedded distribution. OpenEmbedded is not part of Openmoko, and targets many different devices.

FSO's source tree, documentation and bug tracker are not hosted at openmoko.org. This wiki page simply points to the relevant portions of OpenEmbedded's documentation. Openembedded.org and freesmartphone.org contain more complete documentation.

= FsoMakefile =

There are two ways to build an FSO image.

The first approach uses FsoMakefile to automatically download and configure the build environment, and is the easiest way to build an image:
<pre>
wget http://downloads.freesmartphone.org/Makefile
make fso-gta02-testing-image
</pre>
This is the process used by the build servers to create new images.

Ubuntu can throw up errors [[Talk:MokoMakefile]]

See http://downloads.freesmartphone.org/ for more information. Note that FsoMakefile and [[MokoMakefile]] are separate entities, and target different images.

You can access the FsoMakefile directly from the git repository with this command (there is no difference between this and the above once the build starts):
<pre>
git clone git://git.freesmartphone.org/fso-makefile common
ln -s common/Makefile Makefile
make fso-gta02-testing-image
</pre>
You can also use [[Alternative FSO GIT repository|alternative FSO git repository]]

= Building manually =

While convenient, building with FsoMakefile does not tell you much about what is going on under the hood. FsoMakefile automatically downloads an OpenEmbedded build tree, configures it to build FSO and then builds the image.

{{Note|The output from running the FsoMakefile is *exactly* the same output you get from running bitbake commands manually. And the configuration files produced by the 'setup' target in the FsoMakefile are *exactly* the same configuration files you would create manually. So I just don't get why people say that using a Makefile doesn't tell you much about what is going on under the hood. I think the difference is whether someone actually cares to look at what is going on or not. - RodWhitby}}

OpenEmbedded's manual build directions at http://wiki.openembedded.net/index.php/Getting_Started describe the process in more detail. They also explain how to build individual packages, and describe bitbake, which manages OpenEmbedded builds.

OpenEmbedded targets a number of devices, and their package database can produce a number of different images. Therefore, as you follow their directions, you will need to modify them to build FSO for your device.

First, when you edit the targets in local.conf, you need to set it to build an Openmoko distribution.

If you wanted to build FSO for a Neo1973, you would write this:
<pre>
BBFILES = "/stuff/org.openembedded.dev/packages/*/*.bb"
DISTRO = "openmoko"
MACHINE = "om-gta01"
</pre>

To build FSO for a FreeRunner, you would write this:
<pre>
BBFILES = "/stuff/org.openembedded.dev/packages/*/*.bb"
DISTRO = "openmoko"
MACHINE = "om-gta02"
</pre>
If you want to build FSO's unstable branch then include the following two lines at the end of local.conf:
<pre>
require conf/distro/include/fso-autorev.inc
require conf/distro/include/moko-autorev.inc
</pre>
These two .inc files tell bitbake to use the most recent versions of each package, instead of the (hopefully tested) preferred versions.

Once you've finished setting up the build environment, you can build the FSO image with the command:
<pre>
cd /stuff/build && bitbake fso-image
</pre>
{{Note|If you want to run manual bitbake commands after setting things up using the FsoMakefile, then don't forget to source the setup-env file first.}}

= Configuration =
{{Note|This section should be it's own page...}}
== GTK ==

Currently GTK is not well supported in the FSO build. To use GTK applications you'll most likely have to install the gtk library, and the Openmoko theme.

'''Step 1) Install the ipk-packages'''
<pre>
opkg install openmoko-icon-theme-standard2 moko-gtk-engine
</pre>
'''Step 2) Enable Theme'''
<pre>
nano /etc/gtk-2.0/gtkrc
</pre>
Add this line to the top:
<pre>
include "/usr/share/themes/Moko/gtk-2.0/gtkrc"
</pre>
'''Step 3) Set icon theme'''
<pre>
nano /etc/gtk-2.0/gtkrc
</pre>
Add the line:<pre>
gtk-icon-theme-name="openmoko-standard"
</pre>
'''Step 4) Third party themes (optional)'''

Add one line per 'third-party' gtk theme you've installed. For example, openmoko-mediaplayer is not packaged with FSO:
<pre>
include "/usr/share/themes/Moko/gtk-2.0/openmoko-mediaplayer"
</pre>
'''Step 5) Other tweaks

To get "2007.2-style" icons (no text, smaller), so that all the terminal buttons fit on the screen at once:
<pre>
gtk-toolbar-style = GTK_TOOLBAR_ICONS
gtk-icon-sizes = "gtk-button=32,32:gtk-small-toolbar=16,16:gtk-large-toolbar=24,24"
</pre>
And make any other changes you like. I don't like double arrows on the tops and bottoms of sliders:
<pre>
GtkScrollbar::has_secondary_backward_stepper = 0
GtkScrollbar::has_secondary_forward_stepper = 0
</pre>
Look at existing gtkrc files for more options (if you find the manual, add a link).

[[Category:FSO]]

MokoMakefile

2008-12-03T13:11:59Z

RodWhitby: /* 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.

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 Om2008.8 (org.openmoko.asu.stable, openmoko-asu-image) and "Bleeding Edge" (org.openmoko.dev, openmoko-base-image) 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:

<pre>ncurses zlib (or libz) OpenSSL GTK++</pre>

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 =====

<pre>sudo apt-get install subversion build-essential help2man diffstat texi2html texinfo cvs gawk zip unzip cogito bzip2
sudo apt-get install libncurses5-dev zlib1g-dev libssl-dev libgtk2.0-dev
# To prevent errors in host validation
sudo apt-get install ca-certificates
# For Openmoko 2007.2 using BitBake-1.8.8:
sudo apt-get install python-pysqlite2 sqlite3 sqlite3-doc python-pysqlite2-dbg
# For building faster
sudo apt-get install quilt python-psyco ccache
# For qemu, install a second compiler for bug avoidance; MokoMakefile knows to look for it.
sudo apt-get install gcc-3.4 g++-3.4 libsdl1.2-dev lynx netpbm dosfstools

# On Ubuntu 8.04 and and Debian testing/unstable, the following was required instead of cogito
sudo apt-get install git-core
# Ubuntu links /bin/sh to /bin/dash, but some scripts fail because they use pushd and popd, which dash does not support
sudo dpkg-reconfigure dash
# Select No when it asks you to install dash as /bin/sh.

# This may be needed only for ASU
sudo apt-get install libxtst-dev</pre>

===== SuSE =====
For building Openmoko on 10.3, you need

<pre>gcc-c++ ncurses-devel zlib-devel libopenssl-devel gtk2-devel subversion diffstat texinfo help2man</pre>

For MokoMakefile to not fail on compiling qemu-user, you need to use gcc33:

<pre>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</pre>

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.

===== Mandriva =====

<pre>urpmi git help2man diffstat texi2html texinfo</pre>

(Tested with Mandriva 2009.0. <tt>kernel-desktop-devel</tt> of the current kernel is installed in advance, which installs compilers, binutils and many other general compilation tools.)

==== 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:

<pre>ENABLE_BINARY_LOCALE_GENERATION = "0"</pre>

===== 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):

<pre>mkdir ~/moko ; cd ~/moko</pre>

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.
If you ever want to move your $OMDIR to another location, you must run

<pre>make clobber ; make setup</pre>

to reinitialize the environment. Yes, this will take a long time, so choose $OMDIR carefully.

=== MokoMakefile ===

Grab MokoMakefile:

<pre>wget http://www.rwhitby.net/files/openmoko/Makefile</pre>

If that doesn't work, try

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

{{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 ===

If you want to make the "Bleeding Edge" (org.openmoko.dev, openmoko-base-image) image instead of the Om2008.8 image, see [[Distributions]], you need to edit your Makefile. Read the top of the Makefile for details.

Note that if you want to build FSO, you should use the FSO Makefile at http://downloads.freesmartphone.org rather than the MokoMakefile.

Set up the environment with:

<pre>make setup</pre>

If you are building for the Neo1973 GTA01, then also do this

<pre>make setup-machine-om-gta01</pre>

If you are building for the FreeRunner GTA02, then also do this

<pre>make setup-machine-om-gta02</pre>

=== Building ===

Before starting a lengthy make process, check the [[#Tips|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.

<pre>make image</pre>

''Hint:'' The images build with this command can be found under {$OMDIR}/build/tmp/deploy/glibc/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:

<pre>make update-makefile</pre>

Be aware that any changes you previously made to the Makefile (like the git branch to use) are lost when executing ''update-makefile''.

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

<pre>make setup</pre>

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

<pre>make update</pre>

A quick way to rebuild a new image with the latest updates:

<pre>make update-makefile && make setup update image</pre>

==Build issues==

First, make sure that the problem is reproducible after running

<pre>make update-makefile && make setup && make update</pre>

then run

<pre>make clean-package-<foo></pre>

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

and finally

<pre>make image</pre>

With luck - you should now have images in your $omdir/build/tmp/deploy/glibc/images/neo1973/ directory. You can then [[Flashing the Neo FreeRunner|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 in the Openmoko development Trac at https://docs.openmoko.org/trac/wiki/NewTicket or in #openmoko on [[Development_resources#IRC|IRC]]. If bitbake has started to run, then it's almost guaranteed that the problem is in the OE build recipes, *not* in the MokoMakefile itself (which is just a convenience wrapper around the OpenEmbedded build system). Please do not report build recipe errors to the MokoMakefile author.

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.

<pre>`env | grep -Ev '^(SHELL|TERM|OLDPWD|USER|USERNAME|PATH|EDITOR|LANG|HOME|DISPLAY|_)=' \
| sed 's/^$.*$=.*/unset \1/'`</pre>

(you must include the backticks).

Note that on some boxes it is necessary to call "make" by typing "/usr/bin/make" afterwards.

On current Ubuntu/Debian unstable/testing 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:

<pre>sudo sysctl -w vm.mmap_min_addr=0</pre>

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:

<pre>sudo sysctl -w vm.mmap_min_addr=65536</pre>

See the talk page of this article for more details on this solution.

===Known MokoMakefile errors ===

==== SVN Server Certificate Errors ====

If you get an error like the following:

<pre>NOTE: Fetch svn://svn.projects.openmoko.org/svnroot/;module=assassin;proto=https
Error validating server certificate for 'https://svn.projects.openmoko.org:443':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
Certificate information:
- Hostname: projects.openmoko.org
- Valid: from Thu, 05 Jun 2008 01:02:42 GMT until Tue, 02 Dec 2008 01:02:42 GMT
- Issuer: http://www.cacert.org, Root CA
- Fingerprint: a5:7d:4e:37:e8:94:ee:ba:c1:e8:e9:4b:33:cb:34:91:a9:6d:d3:84
(R)eject, accept (t)emporarily or accept (p)ermanently?
svn: OPTIONS of 'https://svn.projects.openmoko.org/svnroot/assassin':
Server certificate verification failed: issuer is not trusted (https://svn.projects.openmoko.org)</pre>

It means you haven't yet accepted the server certificate for the SVN server. To remedy this, execute the following commands, and hit "p" (to permanently accept the certificate) when prompted:

<pre>cd /tmp
svn co https://svn.projects.openmoko.org/svnroot/assassin
rm -rf assassin
cd -</pre>

==== exposure_svn and Subversion 1.5.0 ====

If you get an error like this:

<code>"NameError: global name 'log' is not defined"</code>

There's a bug with subversion 1.5.0 -- downgrade to 1.4.x (or check out the latest subversion sources and use those as they're fixed) and re-fetch the sources.

=== 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"
* If a certain package does not build due to corrupted download or some such try to remove the sources and rebuild it.
<pre>rm sources/<package>*
cd build
. ../setup-env
bitbake -crebuild <package></pre>
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:
<pre>PARALLEL_MAKE = "-j 4"
BB_NUMBER_THREADS = "4"</pre>

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:
<pre>GLIBC_GENERATE_LOCALES = "en_US.UTF-8 nl_NL.UTF-8"</pre>

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

* If you want to rebuild the package indexes (for instance, after compiling a new version of a package) without building the whole <code>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.

* Make sure you do not have . in your PATH, this causes an "unrecognized option -Qy" error when building g++spec

=== 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 image : build the full development image

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

; make 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

; make setup-machine-om-gta01 : setup for GTA01 version of Neo1973

; make setup-machine-om-gta02 : setup for GTA02 version of FreeRunner

; make build-package-package-index : Rebuild the package index

== Developing with MokoMakefile ==

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:

<pre>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</pre>

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:

<pre>make build-qemu
make flash-qemu-local
make run-qemu</pre>

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

<pre>cd $OMDIR/build
. ../setup-env
bitbake -c patch openmoko-messages
cd tmp/work/armv4t-linux/openmoko-messages-0.0.1+svnnow-r2_2276/openmoko-messages/
''...make the changes...''
cd -
bitbake -c compile openmoko-messages
bitbake -c build openmoko-messages</pre>

Note: The compile step is only necessary if you already had the package compiled before patching it.

Note: if you just use <tt>bitbake openmoko-messages</tt> it will remove the sources after building!

Note: You can use the '-f' switch to force a command to be run (e.g. ''bitbake -f -c compile openmoko-messages'' to force a compile run.

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:

<pre>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</pre>

The file should have the following content:

<pre>DESCRIPTION = "This is a cool package"
SECTION = "username/mycoolpackage"
PV = "1"

inherit autotools

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

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

<pre>$OMDIR/openmoko $ quilt edit trunk/openembedded/packages/tasks/task-openmoko.bb</pre>

Here, increase the value '''PR''' by one and add '''mycoolpackage \''' (with the backslash!) just before the line reading '''# update-alternatives \'''.

Now run

<pre>quilt refresh
cd ..
make update image</pre>

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", "make openmoko-devel-image :) - no magic there", and "I have never been able to get a build to complete in the pure OE environment, whereas Mokomakefile for some reason builds fine."

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

[[Category:Application Developer]]
[[Category:System Developers]]

User talk:RodWhitby

2008-10-09T13:49:54Z

RodWhitby:

Hi Rod,

Duplicate mail are very annoying, but coolcat and I don't think that they really make frontpage material. Do you see any specific reason not to move this link to the FAQ and the "Community ressources" page ?

Cordially, Minh

Hi Minh,

No problem at all. Feel free to move it.

-- Rod

MokoMakefile

2008-09-13T00:54:54Z

RodWhitby:

{{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.

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 Om2008.8 (org.openmoko.asu.stable, openmoko-asu-image) and "Bleeding Edge" (org.openmoko.dev, openmoko-base-image) 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 =====
sudo apt-get install subversion build-essential help2man diffstat texi2html texinfo cvs gawk zip unzip cogito

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

# On Ubuntu 8.04 and and Debian testing/unstable, the following was required instead of cogito
sudo apt-get install git-core
# Ubuntu links /bin/sh to /bin/dash, but some scripts fail because they use pushd and popd, which dash does not support
sudo rm /bin/sh
sudo ln -s /bin/bash /bin/sh

# This may be needed only for ASU
sudo apt-get install libxtst-dev

===== 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):
mkdir ~/moko ; cd ~/moko
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.
If you ever want to move your $OMDIR to another location, you must run
make clobber ; make setup
to reinitialize the environment. Yes, this will take a long time, so choose $OMDIR carefully.

=== 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 ===
If you want to make the "Bleeding Edge" (org.openmoko.dev, openmoko-base-image) image instead of the Om2008.8 image, see [[Distributions]], you need to edit your Makefile. Read the top of the Makefile for details.

Note that if you want to build FSO, you should use the FSO Makefile at http://shr.bearstech.com rather than the MokoMakefile.

Set up the environment with:

make setup

If you are building for the Neo1973 GTA01, then also do this
make setup-machine-om-gta01
If you are building for the FreeRunner GTA02, then also do this
make setup-machine-om-gta02

=== Building ===
Before starting a lengthy make process, check the [[#Tips|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 image

''Hint:'' The images build with this command can be found under {$OMDIR}/build/tmp/deploy/glibc/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

Be aware that any changes you previously made to the Makefile (like the git branch to use) are lost when executing ''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 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 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 [[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 backticks).
Note that on some boxes it is necessary to call "make" by typing "/usr/bin/make" afterwards.

On current Ubuntu/Debian unstable/testing 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 ===
==== SVN Server Certificate Errors ====
If you get an error like the following:
<pre>
NOTE: Fetch svn://svn.projects.openmoko.org/svnroot/;module=assassin;proto=https
Error validating server certificate for 'https://svn.projects.openmoko.org:443':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
Certificate information:
- Hostname: projects.openmoko.org
- Valid: from Thu, 05 Jun 2008 01:02:42 GMT until Tue, 02 Dec 2008 01:02:42 GMT
- Issuer: http://www.cacert.org, Root CA
- Fingerprint: a5:7d:4e:37:e8:94:ee:ba:c1:e8:e9:4b:33:cb:34:91:a9:6d:d3:84
(R)eject, accept (t)emporarily or accept (p)ermanently? svn: OPTIONS of 'https://svn.projects.openmoko.org/svnroot/assassin': Server certificate verification failed: issuer is not trusted (https://svn.projects.openmoko.org)
</pre>

It means you haven't yet accepted the server certificate for the SVN server. To remedy this, execute the following commands, and hit "p" (to permanently accept the certificate) when prompted:
<pre>
cd /tmp
svn co https://svn.projects.openmoko.org/svnroot/assassin
rm -rf assassin
cd -
</pre>

==== exposure_svn and Subversion 1.5.0 ====

If you get an error like this:

<code>
"NameError: global name 'log' is not defined"
</code>

There's a bug with subversion 1.5.0 -- downgrade to 1.4.x (or check out the latest subversion sources and use those as they're fixed) and re-fetch the sources.

===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"

*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 the whole <code>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.

* Make sure you do not have . in your PATH, this causes an "unrecognized option -Qy" error when building g++spec

=== 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 image : build the full development image

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

; make 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

; make setup-machine-om-gta01 : setup for GTA01 version of Neo1973

; make setup-machine-om-gta02 : setup for GTA02 version of FreeRunner

; make build-package-package-index : Rebuild the package index

==Developing with MokoMakefile==

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 patch openmoko-messages
cd tmp/work/armv4t-linux/openmoko-messages-0.0.1+svnnow-r2_2276/openmoko-messages/
''...make the changes...''
cd -
bitbake -c compile openmoko-messages
bitbake -c build openmoko-messages

Note: The compile step is only necessary if you already had the package compiled before patching it.

Note: if you just use <tt>bitbake openmoko-messages</tt> it will remove the sources after building!

Note: You can use the '-f' switch to force a command to be run (e.g. ''bitbake -f -c compile openmoko-messages'' to force a compile run.

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 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", "make openmoko-devel-image :) - no magic there", and "I have never been able to get a build to complete in the pure OE environment, whereas Mokomakefile for some reason builds fine."

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

[[Category:Application Developer]]
[[Category:System Developers]]

Mailing List Duplicates

2008-09-11T23:46:44Z

RodWhitby:

Q: How long has there been duplicates on the Openmoko mailing lists?

A: Since the list got so big that sita.openmoko.org can't handle it.

Q: How long has that been?

A: At least a year, maybe more.

Q: Has Openmoko done anything about it?

A: Doesn't seem so. Must be a hard problem.

Q: Is Openmoko likely to fix it?

A: If they haven't fixed it by now, then chances are they probably won't.

Q: What should I do about it?

A: Don't email the list about - we all know already.

Q: How can I fix it locally for me?

A: Get a mail reader that understands that a message with a duplicate Message-Id header field doesn't need to be displayed to the user.

Mailing List Duplicates

2008-09-11T23:46:29Z

RodWhitby: New page: Q: How long has there been duplicates on the Openmoko mailing lists? A: Since the list got so big that sita.openmoko.org can't handle it. Q: How long has that been? A: At least a year, ...

Q: How long has there been duplicates on the Openmoko mailing lists?

A: Since the list got so big that sita.openmoko.org can't handle it.

Q: How long has that been?

A: At least a year, maybe more.

Q: Has Openmoko done anything about it?

A: Doesn't seem so. Must be a hard problem.

Q: Is Openmoko likely to fix it?

A: If they haven't fixed it by now, then chances are they probably won't.

Q: What should I do about it?

A: Don't email the list about - we all know already.

Q: How can I fix it locally for me?

A: Get a mail reader that understands that a message with a duplicate
Message-Id header field doesn't need to be displayed to the user.

Main Page

2008-09-11T23:45:57Z

RodWhitby:

{{Languages|Main Page}}
__NOTOC__
__NOEDITSECTION__ [[Image:Freerunner02.gif|thumb|150px|right|Neo FreeRunners]]

<div style="padding: 2.5ex; text-align: center; font: bold x-large sans">Openmoko™ - Open. Mobile. Free.</div>

Openmoko™ is a project dedicated to delivering mobile phones with an open source software stack. Openmoko is currently selling the [[Neo FreeRunner]] phone to advanced users and will start selling it to the general public as soon as the software is more developed.

The Openmoko stack, which includes a full X server, allows users and developers to transform mobile hardware platforms into unique products. Our license gives developers and users freedom to cosmetically customize their device or radically remix it; change the wallpaper or rebuild the entire house! It grants them the freedom, for example, to transform a phone into a medical device or point of sale device or the freedom to simply install their own favourite software. Beyond freeing the software on our devices we have also released our CAD files under Creative Commons. And at Linux world 2008, we announced the release of the schematics for our products.

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

<table class="wikitable" cellspacing="4" cellpadding="6" width="100%" style="color:white">
<tr style="background:#ff6600; text-align:center; font-weight:bold">
<td width="50%">News and events</td>
<td width="50%">New to Openmoko?</td>
</tr>
<tr valign="top" style="background:#333333">
<td>
* 11/9: The framework team releases [http://downloads.openmoko.org/framework/milestone3/ milestone 3] of the FSO distribution.
* 28/8: Trolltech [http://n2.nabble.com/qtopia-4.3.2-release-tp789148p789148.html released] Qtopia 4.3.2.
* 26/8: Openmoko [http://lists.openmoko.org/pipermail/community/2008-August/027997.html updates] [[Om 2008.8]] distribution.
* 15/8: [[Debian]] on the FreeRunner [http://n2.nabble.com/Debian-on-the-FreeRunner----now-official-td726410.html announced] (instructions for [http://wiki.debian.org/DebianOnFreeRunner FreeRunner] and [http://wiki.debian.org/DebianOnNeo1973 Neo1973]).
* 8/8: Openmoko team [http://lists.openmoko.org/pipermail/community/2008-August/025602.html releases] distribution formerly called ASU as [[Om 2008.8]] .
* 30/7: The FSO distribution releases [http://downloads.openmoko.org/framework/milestone2/ milestone 2]
* [[Weekly Engineering News|Openmoko Weekly Engineering News]]
* [[News Archive|(news archive)]]
</td>
<td>
===<font color=white>About Openmoko</font>===
* [[Introduction]]
* [[Why Openmoko]]
* [[Neo FreeRunner|Neo FreeRunner phone]]
* [[Supported Hardware]]
* [[FAQ]]

===<font color=white>Getting Openmoko</font>===
* [[Getting Openmoko]]
* [http://www.openmoko.com Openmoko Inc.]

</td>
</tr>
<tr style="background:#ff6600; text-align:center; font-weight:bold">
<td width="50%">for Users</td>
<td width="50%">for Developers</td>
</tr>
<tr valign="top" style="background:#333333">
<td>
===<font color=white>Getting started</font>===
* [[Getting Started with your Neo FreeRunner | Neo FreeRunner getting started guide]]
* [[Applications]]

===<font color=white>Distributions</font>===
* [[Distributions|Features comparison table]]
* [[Om 2008.8|Om 2008.8 (ASU)]] - [[Om 2007.2|Om 2007.2 (old stable)]]
* [[OpenmokoFramework|FSO]] - [[Qtopia_on_FreeRunner|Qtopia]] - [[Debian|Debian]] - [[Gentoo|Gentoo]]

===<font color=white>Openmoko community</font>===
* [[Mailing List Duplicates| Mailing List Duplicates]]
* [[Discussion_Forums| Discussion Forums]]
* [[CommunityRepository|Community repository]]
* [[Development resources | Development resources]]
</td>
<td>
===<font color=white>Applications development</font>===
* [[Openmoko developer guide]]
* [[Toolchain|The toolchain]]

* [[Python|Introduction to Python]]
* [http://projects.openmoko.org/ Projects hosted in our GForge]

===<font color=white>Integration and distributions</font>===
* [[OpenEmbedded|The OpenEmbedded distribution building framework]]
* [[MokoMakefile|Building Openmoko using the MokoMakefile ]]
* [[Opkg|The Opkg package manager]]

===<font color=white>Emulation</font>===
* [[Openmoko under QEMU]]
</td>
</tr>
</table>

Browse articles by [[:Category:Categories|Categories]].

Building FSO

2008-09-08T12:31:52Z

RodWhitby: /* Building manually */

{{FSO}}

The freesmartphone.org (FSO) image is based on the OpenEmbedded distribution. OpenEmbedded is not part of Openmoko, and targets many different devices.

FSO's source tree, documentation and bug tracker are not hosted at openmoko.org. This wiki page simply points to the relevant portions of OpenEmbedded's documentation. Openembedded.org and freesmartphone.org contain more complete documentation.

= FsoMakefile =

There are two ways to build an FSO image.

The first approach uses FsoMakefile to automatically download and configure the a build environment, and is the easiest way to build an image:

wget http://shr.bearstech.com/Makefile
make fso-testing-image

This is the process used by the build servers to create new images.

See http://shr.bearstech.com/README for more information. Note that FsoMakefile and [[MokoMakefile]] are separate entities, and target different images.

If shr.bearstech.com is not accessible for some reason, you can access the FsoMakefile directly from the git repository with this command (there is no difference between this and the above once the build starts):

git clone git://git.freesmartphone.org/fso-makefile common
ln -s common/Makefile Makefile
make fso-testing-image

= Building manually =

While convenient, building with FsoMakefile does not tell you much about what is going on under the hood. FsoMakefile automatically downloads an OpenEmbedded build tree, configures it to build FSO and then builds the image.

OpenEmbedded's manual build directions at http://wiki.openembedded.net/index.php/Getting_Started describe the process in more detail. They also explain how to build individual packages, and describe bitbake, which manages OpenEmbedded builds.

OpenEmbedded targets a number of devices, and their package database can produce a number of different images. Therefore, as you follow their directions, you will need to modify them to build FSO for your device.

First, when you edit the targets in local.conf, you need to set it to build an openmoko distribution.

If you wanted to build FSO for a Neo1973, you would write this:

BBFILES = "/stuff/org.openembedded.dev/packages/*/*.bb"
DISTRO = "openmoko"
MACHINE = "om-gta01"

To build FSO for a Freerunner, you would write this:

BBFILES = "/stuff/org.openembedded.dev/packages/*/*.bb"
DISTRO = "openmoko"
MACHINE = "om-gta02"

If you want to build FSO's unstable branch then include the following two lines at the end of local.conf:

require conf/distro/include/fso-autorev.inc
require conf/distro/include/moko-autorev.inc

These two .inc files tell bitbake to use the most recent versions of each package, instead of the (hopefully tested) preferred versions.

Once you've finished setting up the build environment, you can build the FSO image with the command:

cd /stuff/build && bitbake fso-image

[[category:Technical]]
[[Category:Software (non openmoko)]]
[[category:FSO]]

= Configuration =
{{Note|This section should be it's own page...}}
== GTK ==

Currently GTK is not well supported in the FSO build. To use GTK applications you'll most likely have to install the gtk library, and the Openmoko theme.

'''Step 1) Install the ipk-packages'''

opkg install moko-gtk-theme
opkg install openmoko-icon-theme-standard2
opkg install moko-gtk-engine

'''Step 2) Enable Theme'''

vi /etc/gtk-2.0/gtkrc

Add this line to the top:

include "/usr/share/themes/Moko/gtk-2.0/gtkrc"

'''Step 3) Set icon theme'''

vi /etc/gtk-2.0/gtkrc

Add the line:
gtk-icon-theme-name="openmoko-standard"

'''Step 4) Third party themes (optional)'''

Add one line per 'third-party' gtk theme you've installed. For example, openmoko-mediaplayer is not packaged with FSO:

include "/usr/share/themes/Moko/gtk-2.0/openmoko-mediaplayer"

'''Step 5) Other tweaks

To get "2007.2-style" icons (no text, smaller), so that all the terminal buttons fit on the screen at once:

gtk-toolbar-style = GTK_TOOLBAR_ICONS
gtk-icon-sizes = "gtk-button=32,32:gtk-small-toolbar=16,16:gtk-large-toolbar=24,24"

And make any other changes you like. I don't like double arrows on the tops and bottoms of sliders:

GtkScrollbar::has_secondary_backward_stepper = 0
GtkScrollbar::has_secondary_forward_stepper = 0

Look at existing gtkrc files for more options (if you find the manual, add a link).

Building FSO

2008-09-08T12:30:19Z

RodWhitby: /* FsoMakefile */

{{FSO}}

The freesmartphone.org (FSO) image is based on the OpenEmbedded distribution. OpenEmbedded is not part of Openmoko, and targets many different devices.

FSO's source tree, documentation and bug tracker are not hosted at openmoko.org. This wiki page simply points to the relevant portions of OpenEmbedded's documentation. Openembedded.org and freesmartphone.org contain more complete documentation.

= FsoMakefile =

There are two ways to build an FSO image.

The first approach uses FsoMakefile to automatically download and configure the a build environment, and is the easiest way to build an image:

wget http://shr.bearstech.com/Makefile
make fso-testing-image

This is the process used by the build servers to create new images.

See http://shr.bearstech.com/README for more information. Note that FsoMakefile and [[MokoMakefile]] are separate entities, and target different images.

If shr.bearstech.com is not accessible for some reason, you can access the FsoMakefile directly from the git repository with this command (there is no difference between this and the above once the build starts):

git clone git://git.freesmartphone.org/fso-makefile common
ln -s common/Makefile Makefile
make fso-testing-image

= Building manually =

While convenient, building with FsoMakefile does not tell you much about what is going on under the hood. FsoMakefile automatically downloads an OpenEmbedded build tree, configures it to build FSO and then builds the image.

OpenEmbedded's manual build directions at http://wiki.openembedded.net/index.php/Getting_Started describe the process in more detail. They also explain how to build individual packages, and describe bitbake, which manages OpenEmbedded builds.

OpenEmbedded targets a number of devices, and their package database can produce a number of different images. Therefore, as you follow their directions, you will need to modify them to build FSO for your device.

First, when you edit the targets in local.conf, you should need to set it to build an openmoko distrbution. If you wanted to build the angstrom distribution for a Neo1973, you would write this:

BBFILES = "/stuff/org.openembedded.dev/packages/*/*.bb"
DISTRO = "angstrom-2008.1"
MACHINE = "om-gta01"

To build FSO for a Freerunner, you would write this:

BBFILES = "/stuff/org.openembedded.dev/packages/*/*.bb"
DISTRO = "openmoko"
MACHINE = "om-gta02"

If you want to build FSO's unstable branch then include the following two lines at the end of local.conf:

require conf/distro/include/fso-autorev.inc
require conf/distro/include/moko-autorev.inc

these two .inc files tell bitbake to use the most recent versions of each package, instead of the (hopefully tested) preferred versions.

Once you've finished setting up the build environment, you can build the FSO image with the command:

cd /stuff/build && bitbake fso-image

[[category:Technical]]
[[Category:Software (non openmoko)]]
[[category:FSO]]

= Configuration =
{{Note|This section should be it's own page...}}
== GTK ==

Currently GTK is not well supported in the FSO build. To use GTK applications you'll most likely have to install the gtk library, and the Openmoko theme.

'''Step 1) Install the ipk-packages'''

opkg install moko-gtk-theme
opkg install openmoko-icon-theme-standard2
opkg install moko-gtk-engine

'''Step 2) Enable Theme'''

vi /etc/gtk-2.0/gtkrc

Add this line to the top:

include "/usr/share/themes/Moko/gtk-2.0/gtkrc"

'''Step 3) Set icon theme'''

vi /etc/gtk-2.0/gtkrc

Add the line:
gtk-icon-theme-name="openmoko-standard"

'''Step 4) Third party themes (optional)'''

Add one line per 'third-party' gtk theme you've installed. For example, openmoko-mediaplayer is not packaged with FSO:

include "/usr/share/themes/Moko/gtk-2.0/openmoko-mediaplayer"

'''Step 5) Other tweaks

To get "2007.2-style" icons (no text, smaller), so that all the terminal buttons fit on the screen at once:

gtk-toolbar-style = GTK_TOOLBAR_ICONS
gtk-icon-sizes = "gtk-button=32,32:gtk-small-toolbar=16,16:gtk-large-toolbar=24,24"

And make any other changes you like. I don't like double arrows on the tops and bottoms of sliders:

GtkScrollbar::has_secondary_backward_stepper = 0
GtkScrollbar::has_secondary_forward_stepper = 0

Look at existing gtkrc files for more options (if you find the manual, add a link).

MokoMakefile

2008-09-07T22:52:35Z

RodWhitby: Added warning about moving $OMDIR

{{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.

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 =====
sudo apt-get install subversion build-essential help2man diffstat texi2html texinfo cvs gawk zip unzip cogito

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

# On Ubuntu 8.04 and and Debian testing/unstable, the following was required instead of cogito
sudo apt-get install git-core
# Ubuntu links /bin/sh to /bin/dash, but some scripts fail because they use pushd and popd, which dash does not support
sudo rm /bin/sh
sudo ln -s /bin/bash /bin/sh

# This may be needed only for ASU
sudo apt-get install libxtst-dev

===== 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):
mkdir ~/moko ; cd ~/moko
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.
If you ever want to move your $OMDIR to another location, you must run
make clobber ; make setup
to reinitialize the environment. Yes, this will take a long time, so choose $OMDIR carefully.

=== 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 ===
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 (enabled by default)
OM_GIT_BRANCH := org.openmoko.asu.stable # ASU stable
OM_GIT_BRANCH := org.openembedded.dev # FSO

Note that if you want to build FSO, you should change OM_GIT_SITE to git.openembedded.net as well, since FSO is developed in the OpenEmbedded repository, not the Openmoko repository.

Set up the environment with:

make setup

If you are building for the Neo1973 GTA01, then also do this
make setup-machine-neo
If you are building for the FreeRunner GTA02, then also do this
make setup-machine-freerunner

=== Building ===
Before starting a lengthy make process, check the [[#Tips|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

Be aware that any changes you previously made to the Makefile (like the git branch to use) are lost when executing ''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 [[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 backticks).
Note that on some boxes it is necessary to call "make" by typing "/usr/bin/make" afterwards.

On current Ubuntu/Debian unstable/testing 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 ===
==== SVN Server Certificate Errors ====
If you get an error like the following:
<pre>
NOTE: Fetch svn://svn.projects.openmoko.org/svnroot/;module=assassin;proto=https
Error validating server certificate for 'https://svn.projects.openmoko.org:443':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
Certificate information:
- Hostname: projects.openmoko.org
- Valid: from Thu, 05 Jun 2008 01:02:42 GMT until Tue, 02 Dec 2008 01:02:42 GMT
- Issuer: http://www.cacert.org, Root CA
- Fingerprint: a5:7d:4e:37:e8:94:ee:ba:c1:e8:e9:4b:33:cb:34:91:a9:6d:d3:84
(R)eject, accept (t)emporarily or accept (p)ermanently? svn: OPTIONS of 'https://svn.projects.openmoko.org/svnroot/assassin': Server certificate verification failed: issuer is not trusted (https://svn.projects.openmoko.org)
</pre>

It means you haven't yet accepted the server certificate for the SVN server. To remedy this, execute the following commands, and hit "p" (to permanently accept the certificate) when prompted:
<pre>
cd /tmp
svn co https://svn.projects.openmoko.org/svnroot/assassin
rm -rf assassin
cd -
</pre>

==== exposure_svn and Subversion 1.5.0 ====

If you get an error like this:

<code>
"NameError: global name 'log' is not defined"
</code>

There's a bug with subversion 1.5.0 -- downgrade to 1.4.x (or check out the latest subversion sources and use those as they're fixed) and re-fetch the sources.

===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.

* Make sure you do not have . in your PATH, this causes an "unrecognized option -Qy" error when building g++spec

=== 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

; make setup-machine-neo : setup for GTA01 version of Neo1973

; make setup-machine-freerunner : setup for GTA02 version of FreeRunner

; make build-package-package-index : Rebuild the package index

==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 patch openmoko-messages
cd tmp/work/armv4t-linux/openmoko-messages-0.0.1+svnnow-r2_2276/openmoko-messages/
''...make the changes...''
cd -
bitbake -c compile openmoko-messages
bitbake -c build openmoko-messages

Note: The compile step is only necessary if you already had the package compiled before patching it.

Note: if you just use <tt>bitbake openmoko-messages</tt> it will remove the sources after building!

Note: You can use the '-f' switch to force a command to be run (e.g. ''bitbake -f -c compile openmoko-messages'' to force a compile run.

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", "make openmoko-devel-image :) - no magic there", and "I have never been able to get a build to complete in the pure OE environment, whereas Mokomakefile for some reason builds fine."

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

[[Category:Application Developer]]
[[Category:System Developers]]

Building FSO

2008-09-05T22:53:52Z

RodWhitby:

{{FSO}}

{{Note|The easiest way to build FSO is:

wget http://shr.bearstech.com/Makefile

make fso-testing-image

-- Rod Whitby
}}

''This information is taken as is from [http://wiki.openembedded.net/index.php/OEandYourDistro#Using_OpenEmbedded_on_Linux_systems OpenEmbedded Wiki]. Some commentaries are voluntarily stripped in order to keep this page simple, please look on OE Wiki for more information.''

{{Note|WHY, OH, WHY, DO PEOPLE DUPLICATE INFORMATION ON HOW TO BUILD OPENEMBEDDED ON YET ANOTHER WIKI PAGE. Just point to the OE pages, or to the MokoMakefile page.}}

= Getting Open Embedded =

== Mandatory Packages ==

=== Deb-based distributions ===

apt-get install ccache sed wget cvs subversion git-core monotone coreutils \
unzip texi2html texinfo libsdl1.2-dev docbook-utils gawk

=== Mandriva-based distributions ===

urpmi python python-devel python-psyco ccache patch m4 sed bison make wget bzip2 \
cvs gawk glibc-devel gcc-c++ subversion sharutils coreutils docbook-utils openjade \
quilt pcre-devel unzip

=== SuSE (9.1/9.2) instructions ===
Install [http://linux01.gwdg.de/apt4rpm/ apt4rpm], then follow Debian instructions.

python-dev and python-spyco are not in suse apt repository. python-spyco is not mandatory, so one can ignore it.
I suppose python-devel (suse) is python-dev (debian).

=== Fedora Core 2/3 ===

yum install python patch m4 sed make docbook* openjade glibc-devel xmlto

=== Fedora Core 4 ===

Apart from the usual (native) development packages like gcc and binutils, you should check that you have the following RPM's installed:

* bison
* ccache (not required, but advised to speed up building)
* docbook* packages
* libpcre
* m4
* make
* openjade
* patch
* PyQt
* python
* python-psyco
* sed
* xmlto
* quilt (not required as OE builds it by itself, but install it if you want to use gquilt)

Use apt, synaptic, up2date or yum to automagically retrieve these packages or download and install them manually (lots of work).

=== Fedora Core 5/6 ===

Commands I used to install OE pre-requisites on FC5/6

This long command will ensure all pre-requisites are installed (patch is 2.5.4, not 2.5.9, but appears to work).

su -c "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 gcc gcc-c++ python-sqlite2 help2man"

or download the metapackage http://www.openembedded.org/dl/packages/rpm/openembedded-essential-1.1-1.noarch.rpm (may be out of date).

then do

su -c "yum localinstall openembedded-essential-1.1-1.noarch.rpm"

=== Fedora 7 ===

This long command will ensure all pre-requisites are installed (patch is 2.5.4, not 2.5.9, but appears to work).

su -c "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 linuxdoc-tools gcc gcc-c++ help2man"

=== CentOS 4.4 / Red Hat Enterprise Linux 4 ===

yum install bison ccache coreutils cvs docbook-utils gawk git-core monotone \
python quilt rpmlib sed subversion tetex texinfo unzip wget

=== Gentoo instructions ===

emerge -n bitbake psyco ccache patch make sed dev-lang/python m4 bison cvs openjade \
quilt sgmltools-lite docbook-xml-dtd docbook-dsssl-stylesheets xmlto docbook-sgml-utils \
libpcre boost subversion monotone texi2html pysqlite diffstat

=== Ark Linux 2007.1 ===

apt-get install devel-core diffstat texi2html cvs subversion git texinfo psyco monotone \
python-devel python-encodings python-sqlite

=== Arch Linux (Duke) ===

sudo pacman -S psyco ccache patch make sed python m4 bison cvs quilt sgmltools-lite \
docbook-xml xmlto pcre boost monotone jade git texinfo

In Arch Linux the install command is in /bin/install. Since most of Linux distribution assume that install is located in /usr/bin/install, you have to create a symlink:

sudo ln -s /bin/install /usr/bin/install

You can build BitBake by using this PKGBUILD:
pkgname=bitbake
pkgver=1.8.4
pkgrel=1
pkgdesc="A simple tool for task execution derived from Gentoo's portage"
url="http://developer.berlios.de/projects/bitbake/"
arch=('i686')
license=('GPL' 'custom')
depends=('python')
source=(http://download.berlios.de/bitbake/${pkgname}-${pkgver}.tar.gz)
md5sums=('508d9a61c635d469be8facc95151158b')

build() {
cd ${startdir}/src/${pkgname}-${pkgver}
python setup.py install --root=${startdir}/pkg

# Install vim extensions
install -D -m644 ${startdir}/src/${pkgname}-${pkgver}/contrib/vim/ftdetect/bitbake.vim \
${startdir}/pkg/usr/share/vim/ftplugin/bitbake.vim
install -D -m644 ${startdir}/src/${pkgname}-${pkgver}/contrib/vim/syntax/bitbake.vim \
${startdir}/pkg/usr/share/vim/syntax/bitbake.vim

# Handle MIT license
install -D -m644 ${startdir}/src/${pkgname}-${pkgver}/doc/COPYING.MIT \
${startdir}/pkg/usr/share/licenses/${pkgname}/COPYING.MIT
}

= Repository Checkout =

== Bitbake ==

Go to the base directory of your [[OpenEmbedded]] environment and checkout bitbake:
<pre><nowiki>
$ cd /stuff/
$ svn co svn://svn.berlios.de/bitbake/branches/bitbake-1.8/ bitbake</nowiki></pre>
'''NOTE:''' for proxy handling, see [http://subversion.tigris.org/faq.html#proxy SVN FAQ]

== Open Embedded ==

=== Obtaining OpenEmbedded ===
Next, you'll need to obtain the actual Openembedded database. The OE database store all the OE metadata: build classes, configuration files, and packages. Then you can extract from this database the development branch(es) you want.

The Openembedded database is a [http://www.venge.net/monotone/ Monotone] database, which is the current SCM (Source Code Management) system for Openembedded. You can find monotone binaries and documentation at [http://www.venge.net/monotone/ Monotone official site].

To obtain Openembedded:
# Go to the base directory of your Openembedded environment
$ cd /stuff/
# Download and bunzip2 the OE database snapshot. '''Note: Unfortunately some monotone versions differ in database format. Check [http://www.openembedded.org/snapshots Snapshots] and download the one matching your monotone version.'''
$ wget http://www.openembedded.org/snapshots/OE.mtn.bz2
$ bunzip2 -d OE.mtn.bz2
This is the database you'll be using for all the work.

If you run into a problem at this stage, check to make sure you have version 0.32 (or newer) of monotone installed.

If you get further troubles in using monotone, there are two ways out:

* use the [http://openembedded.org/snapshots/ latest OE snapshot]
* use a static monotone image

Then you can checkout your local copy of the Openembedded tree.
$ cd /stuff
$ mtn --db=/stuff/OE.mtn checkout --branch=org.openembedded.dev
This extracts directories and files relating to the selected branch from the OE.mtn database and places them under <nowiki>/stuff/branchname</nowiki> (i.e. in <nowiki>/stuff/org.openembedded.dev</nowiki> in this guide)

IMPORTANT NOTE ! If mtn complains about an outdated database, you can migrate it using the following command :

<pre><nowiki>
mtn db migrate --db=/stuff/OE.mtn
</nowiki></pre>

You'll then have to do the checkout.
=== Create local configuration ===
It's now time to create your local configuration.
While you could copy the default local.conf.sample like that:

<pre><nowiki>
$ cd /stuff/
$ cp org.openembedded.dev/conf/local.conf.sample build/conf/local.conf
$ vi build/conf/local.conf
</nowiki></pre>

It is actually recommended to start smaller and keep local.conf.sample in the background and add entries from there step-by-step as you understand and need them. Please, do not just edit build/conf/local.conf.sample but actually READ it.

For building a .dev branch, in your <nowiki>local.conf</nowiki> file, you should have at least the following three entries. Example for the Angstrom distribution and the Openmoko gta01 machine:
<pre><nowiki>
BBFILES = "/stuff/org.openembedded.dev/packages/*/*.bb"
DISTRO = "angstrom-2008.1"
MACHINE = "om-gta01"
</nowiki></pre>

For a FreeRunner, using an openmoko distro, you'll do that :

<pre><nowiki>
BBFILES = "/stuff/org.openembedded.dev/packages/*/*.bb"
DISTRO = "openmoko"
MACHINE = "om-gta02"
</nowiki></pre>

Don't forget to include the two following files :

<pre><nowiki>
require conf/distro/include/fso-autorev.inc
require conf/distro/include/moko-autorev.inc
</nowiki></pre>

=== Setup the environment ===
One of the four command sets below will need to be run every time you open a terminal for development. (You can automate this in ~/.profile, /etc/profile, or perhaps use a script to set the necessary variables for using [[BitBake]].)

If you followed the recommendation above to use an uninstalled [[BitBake]]:
<pre><nowiki>
$ export PATH=/stuff/bitbake/bin:$PATH
$ export BBPATH=/stuff/build:/stuff/org.openembedded.dev
</nowiki></pre>

If you installed [[BitBake]]:
<pre><nowiki>
$ export BBPATH=/stuff/build:/stuff/org.openembedded.dev
</nowiki></pre>

Alternative syntax for those using the tcsh shell (e.g FreeBSD):
<pre><nowiki>
$ setenv PATH "/stuff/bitbake/bin:"$PATH
$ setenv BBPATH "/stuff/build:/stuff/org.openembedded.dev:"$BBPATH
</nowiki></pre>

= Start building =

<pre><nowiki>
cd /stuff/build && bitbake fso-image
</nowiki></pre>
[[category:Technical]]
[[Category:Software (non openmoko)]]
[[category:FSO]]

= Configuration =

== GTK ==

Currently GTK is not well supported in the FSO build. To use GTK applications you'll most likely have to install the gtk library, and the Openmoko theme.

'''Step 1) Install the ipk-packages'''

opkg install moko-gtk-theme
opkg install openmoko-icon-theme-standard2
opkg install moko-gtk-engine

'''Step 2) Enable Theme'''

vi /etc/gtk-2.0/gtkrc

Add this line to the top:

include "/usr/share/themes/Moko/gtk-2.0/gtkrc"

'''Step 3) Set icon theme'''

vi /etc/gtk-2.0/gtkrc

Add the line:
gtk-icon-theme-name="openmoko-standard"

'''Step 4) Third party themes (optional)'''

Add one line per 'third-party' gtk theme you've installed. For example, openmoko-mediaplayer is not packaged with FSO:

include "/usr/share/themes/Moko/gtk-2.0/openmoko-mediaplayer"

'''Step 5) Other tweaks

To get "2007.2-style" icons (no text, smaller), so that all the terminal buttons fit on the screen at once:

gtk-toolbar-style = GTK_TOOLBAR_ICONS
gtk-icon-sizes = "gtk-button=32,32:gtk-small-toolbar=16,16:gtk-large-toolbar=24,24"

And make any other changes you like. I don't like double arrows on the tops and bottoms of sliders:

GtkScrollbar::has_secondary_backward_stepper = 0
GtkScrollbar::has_secondary_forward_stepper = 0

Look at existing gtkrc files for more options (if you find the manual, add a link).

Manually using Bluetooth

2008-08-21T04:26:38Z

RodWhitby: /* Power it up */

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

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

== Power it up ==

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

The old way to do it is a shell command (for kernels before 2.6.24):

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

For kernel 2.6.24 (or later) use

root@om-gta02:~# echo 1 > /sys/bus/platform/devices/neo1973-pm-bt.0/power_on

and on the GTA02 *only* (i.e. not on the GTA01) also use

root@om-gta02:~# echo 0 > /sys/bus/platform/devices/neo1973-pm-bt.0/reset

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

hciconfig

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

hciconfig <device> up

== Bluetooth Functions ==

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

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

=== Scanning for bluetooth devices ===

hcitool scan

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

=== passkey agent example ===

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

passkey-agent --default 0000 &

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

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

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

Using a bluetooth keyboard with the built-in terminal is a little funky... I can only type into the console using the bt keyboard if the onscreen keyboard is visible. Also, pressing "p" twice on the bt keyboard actually gives you a "q".

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

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

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

hidd --search

to find and connect to any BT-Keyboard.

Tested on:
* [http://www.logitech.com/index.cfm/products/details/US/EN,CRID=2166,CONTENTID=10717 Logitech Dinovo Edge]
* [http://www.logitech.com/index.cfm/keyboards/keyboard_mice_combos/devices/164&cl=us,en Logitech Dinovo Media Desktop (keyboard)]
* [http://www.nokia.es/A4181580 Nokia SU-8W]. Switched on the BT keyboard, scanned for BT address and ran the connect statement above. Works fine.
* [http://blog.russnelson.com/chordite Chordite]. This keyboard uses the Broadcom BCM2042 BT keyboard controller along with a custom driver.
* [http://www.apple.com/keyboard/ Apple's Aluminum Keyboard]. You may have to add 'auth enable; encrypt enable;' to device {} in hcid.conf. Run the passkey agent the first time. --search works to pair and every time after. (Might be obvious for those who have used BT in other spots, but you have to type in y our passkey on the keyboard as the connect is happening, otherwise pairing doesn't take place. I don't think there is a prompt on the Neo for this)
* [http://www.apple.com/support/keyboard/ Apple's white "Wireless Keyboard (original)"] - details may be the same as above. (tested some time ago)
* [http://www.frogpad.com/ FrogPad] - as above
* [http://freedominput.com The freedom keyboard] and its many rebranded models (they look like this: [http://rabenfrost.net/openmoko/keyboard.jpg]) need 'modprobe uinput' to circumvent the 'Can't open input device: No such file or directory (2)' error of 'hidd --search'. It works as of february 7th 2008.
* [http://www.nextag.com/Playstation-3-Logitech-Cordless-564345667/prices-html?nxtg=f8320a24052a-7789F8FE732FF6E3 Logitech Playstation 3 Keyboard] Works well, Mouse pad works.
* [http://corporate.igo.com/product_details.aspx?id=16 iGo Stowaway UltraSlim] (which was apparently discontinued early 2008, but can still be bought in some places) (with the last updates august 5th: not working even if hidd is connected to it) ([[user:ChristW]] I have 2008.8 on it, and using hidd --search to connect to the iGo works perfectly. I also used it to edit a new contact, dial a number and edit a settings text box in [[TangoGPS]]. So far, no problems...)

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

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

=== RFCOMM ===

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

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

hcitool scan

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

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

Restart the BT services:

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

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

root@neo:~$ rfcomm bind 0

Confirm the connect:

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

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

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

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

=== OBEX ===

=== Networking ===

==== Using PC's connection from Neo ====

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

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

'''On the laptop'''

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

* Start pand as server
pand -s

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

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

'''On the Neo'''

* There is a little script that does the steps below (and retries the pand -c command; I had issues with it not working the first time every time) at [[Bt-net-script]] You shouldn't need the other steps below if you use the script.

* Power on bluetooth (see above)

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

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

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

* Sometimes you may need to bring up the bnep0 on the phone as well:
ip l set bnep0 up
* Enjoy

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

Please refer to [[MacOS_X#Bluetooth_2]]

For using the Neo as a dialup Bluetooth server and the Mac as the client, please see below at [[Manually_using_Bluetooth#PPP_Networking]]

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

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

* Start bluetooth on Windows XP

* Enable "Network Access" in the Bluetooth configuration

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

On the Neo

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

* Power on bluetooth (see above)

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

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

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

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

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

===== PPP Networking =====

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

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

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

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

To connect from a MacOS 10.3 client:

* Open "Applications/Utilities/Bluetooth Serial Utility"

* Click on "New"

* Choose a name, then click "Choose Device"

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

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

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

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

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

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

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

''Check this, probably needs some corrections''

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

On the laptop

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

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

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

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

On the Neo

* Power on bluetooth (see above)

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

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

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

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

* Enjoy

==== Using Neo's connection from PC ====

This section not written yet. Has someone set it up?

===== Calling Neo's GPRS modem via Bluetooth =====

In this mode, Neo would behave like any other phone which can be used from a PC to get a network connection.

===== Sharing existing Neo's connection =====

In this mode, Neo would already have a network connection (GPRS, WLAN, ...), and it should get shared to the PC.

=== A2DP quickie ===

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

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

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

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

then play a song

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

or for smoother results...

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

=== A2DP ===

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

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

Create /etc/asound.conf:

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

Run the passkey agent (see above in this page)

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

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

FINALLY: play a song

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

=== Headset Audio ===

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

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

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

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

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

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

alsactl -f /etc/gsmbluetooth.state restore

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

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

== Further reading ==

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

{{Languages|Manually_using_Bluetooth}}
[[Category:Technical]]
[[Category:Documentation]]
[[Category:Bluetooth| ]]
[[Category:Networking]]

SHR Development

2008-08-20T09:11:47Z

RodWhitby: /* Run bitbake */

{{SHR}}
== Building openmoko-dialer3 ==
Currently this is the only package of any size being developed for SHR, and it's the only one with any instructions. If you start another SHR project (please check with [[User:Wurp|Bobby]] before starting one), put instructions for working on the project here!

=== Before beginning ===
You must build openembedded before you can build SHR packages. The easiest way is to go to http://wiki.openmoko.org/wiki/Mokomakefile and build using the instructions for FSO.

* Note: if building FSO fails using MokoMakefile (zhone! or no dbus show up on the top of the newly booted image), try using this
method: http://wiki.openmoko.org/wiki/FSO

The rest of these instructions are written assuming that you used Mokomakefile and that the directory you downloaded the base Makefile into (using wget) is $MOKO.

You must also download the SHR code using subversion. See http://projects.openmoko.org/projects/shr. We will refer to the directory to which you downloaded the project as $SHRSVN. (This directory should contain $SHRSVN/packages/openmoko-dialer3.bb)

=== Set up your BBPATH ===

export BBPATH=.:$MOKO/openembedded/:$MOKO/bitbake/:$MOKO/:$SHRSVN/trunk/packages/

=== Set up the CACHE ===

export CACHE=tmp/cache

=== Set up your local.conf ===
Cd to $MOKO/openembedded

Append the following lines to $MOKO/build/conf/local.conf:
BBFILES += "$SHRSVN/trunk/packages/*.bb $MOKO/openembedded/packages/*/*.bb"
SELECTED_OPTIMIZATION = "-Os -g"

''Note: Spaces are important in your bitbake conf files! You must have spaces before & after the = or +=''

=== Set up your openmoko.conf (if using 2007.2) ===

edit $MOKO/openembedded/conf/distro/openmoko.conf

and make sure that these Gtk+ options are set:

# Select package versions we want to use.
PREFERRED_PROVIDER_gtk+ = "gtk+-fastscaling"
PREFERRED_VERSION_gtk+-fastscaling = "2.10.14"

=== Add your cross-compiler to your PATH ===

export PATH=$MOKO/build/tmp/cross/bin/:$MOKO/build/tmp/staging/x86_64-linux/usr/bin:$PATH

=== Run bitbake ===

(Don't forget to source the setup-env file in the shell before running bitbake)

bitbake openmoko-dialer3

After the first time you build successfully, you can build with

bitbake -b openmoko-dialog3_svn

which is much faster.

=== To recompile, and only recompile ===

bitbake -c compile -b $SHRSVN/trunk/packages/openmoko-dialer3.bb

=== Troubleshooting ===

==== General ====
One thing to try is to unset all environment variables not listed in this page. LIBPATH and INCLUDE can be particularly troublesome.

[[Category:Openmoko]]
[[Category:Community]]
[[Category:SHR]]
[[Category:SHR Devel]]

SHR Development

2008-08-20T09:10:45Z

RodWhitby: /* Set up your local.conf */

{{SHR}}
== Building openmoko-dialer3 ==
Currently this is the only package of any size being developed for SHR, and it's the only one with any instructions. If you start another SHR project (please check with [[User:Wurp|Bobby]] before starting one), put instructions for working on the project here!

=== Before beginning ===
You must build openembedded before you can build SHR packages. The easiest way is to go to http://wiki.openmoko.org/wiki/Mokomakefile and build using the instructions for FSO.

* Note: if building FSO fails using MokoMakefile (zhone! or no dbus show up on the top of the newly booted image), try using this
method: http://wiki.openmoko.org/wiki/FSO

The rest of these instructions are written assuming that you used Mokomakefile and that the directory you downloaded the base Makefile into (using wget) is $MOKO.

You must also download the SHR code using subversion. See http://projects.openmoko.org/projects/shr. We will refer to the directory to which you downloaded the project as $SHRSVN. (This directory should contain $SHRSVN/packages/openmoko-dialer3.bb)

=== Set up your BBPATH ===

export BBPATH=.:$MOKO/openembedded/:$MOKO/bitbake/:$MOKO/:$SHRSVN/trunk/packages/

=== Set up the CACHE ===

export CACHE=tmp/cache

=== Set up your local.conf ===
Cd to $MOKO/openembedded

Append the following lines to $MOKO/build/conf/local.conf:
BBFILES += "$SHRSVN/trunk/packages/*.bb $MOKO/openembedded/packages/*/*.bb"
SELECTED_OPTIMIZATION = "-Os -g"

''Note: Spaces are important in your bitbake conf files! You must have spaces before & after the = or +=''

=== Set up your openmoko.conf (if using 2007.2) ===

edit $MOKO/openembedded/conf/distro/openmoko.conf

and make sure that these Gtk+ options are set:

# Select package versions we want to use.
PREFERRED_PROVIDER_gtk+ = "gtk+-fastscaling"
PREFERRED_VERSION_gtk+-fastscaling = "2.10.14"

=== Add your cross-compiler to your PATH ===

export PATH=$MOKO/build/tmp/cross/bin/:$MOKO/build/tmp/staging/x86_64-linux/usr/bin:$PATH

=== Run bitbake ===

bitbake openmoko-dialer3

After the first time you build successfully, you can build with

bitbake -b openmoko-dialog3_svn

which is much faster.

=== To recompile, and only recompile ===

bitbake -c compile -b $SHRSVN/trunk/packages/openmoko-dialer3.bb

=== Troubleshooting ===

==== General ====
One thing to try is to unset all environment variables not listed in this page. LIBPATH and INCLUDE can be particularly troublesome.

[[Category:Openmoko]]
[[Category:Community]]
[[Category:SHR]]
[[Category:SHR Devel]]

Distributions

2008-08-19T12:42:18Z

RodWhitby: /* FSO - freesmartphone.org */

{{Languages|Distributions}}

{| class="wikitable" style="float:right;width:200px;background-color:#FF6600;text-align:center;border-collapse:collapse;font-weight:bold"
|<font color=white>Distributions</font>
|-
! style='background-color:#333333;color:#FFFFFF'|
<div align=left>
* <font color='#BBBBBB'>Openmoko (official)</font>
** [[Om 2008.8]]
** [[Om 2007.2]]
** [[Om 2007.1]]
** [[OpenmokoFramework|FSO]]
* <font color='#BBBBBB'>Community</font>
** [[SHR]]
* <font color='#BBBBBB'>Other</font>
** [[Qtopia]]
** [[Debian]]
</div>
|-
|}<noinclude>[[Category:Templates]]</noinclude>

Openmoko distributions are designed to run on various mobile devices, with the primary aim of Openmoko Inc.'s [[Neo 1973]] and [[Neo FreeRunner]] phones. They are similar to Linux distributions; complete operating systems with user applications. You can install any of them on your phone or even have a multiboot system with two distributions installed.

While the Openmoko distributions will run on [[Supported devices|other mobile devices]] too, some other software distributions will also run on the Openmoko Inc. phones (see below).

For downloads see [[Latest Images]], for installation instructions see [[Flashing the Neo FreeRunner]].

== About distributions ==

To be technically precise, 2007.2, 2008.8, FSO and SHR of these are not directly independent distributions, but different 'release targets'. They are built out of different branches of the [[OpenEmbedded]] metadistribution source tree, e.g. 2007.2 and 2008.8 are to each other like Ubuntu Gutsy is to Kubuntu Hardy.

One should only use feeds from packages of the same source-branch, else 'stuff will break', similar to like using .debs from Hardy on a Gutsy base system. Also note that there is NO supported upgrade path between these at the moment, thus updating by changing the feeds will most likely end in broken packages or even a unbootable system. Thus please always use [[dfu-util]] to switch between the different 'distributions' for now or install them in a dual-boot setup (e.g. via sdcard or NFS).

== Openmoko Inc. driven release targets ==

=== Om 2007.2 (GTK) ===

[[Om 2007.2]] is for people who are familiar with the [http://www.gnome.org/mobile/ GNOME Mobile] initiative and who want to write applications that run on multiple devices running (parts of) GNOME Mobile. This includes Maemo, which runs on the Nokia Internet Tablets. The strength of the GTK+ stack is a UI and programming environment similar to what you run on your Linux desktop, if you’re into GNOME. The GTK+ has PIM applications based on the Evolution Data Server and runs the gsmd phone server. Although you can use them, the applications are still pretty rough und unfinished. Some people have problems with the stability of the phone server.

* [[Om 2007.2]]
* Availabilty: [http://buildhost.openmoko.org/daily/ Official Buildhost] and [[MokoMakefile]] support for development builds
* [[Downloads#Openmoko_2007.2_images_.28GTK.29|Download]]
* Several videos of this stack by [http://uk.youtube.com/user/freeyourphone Youtube user freeyourphone] and [http://uk.youtube.com/watch?v=U05kZfURPig&NR=1 video review by BVB Tech]
This is the base-system which is installed on Freerunner when it leaves the factory.

2007.2 development driven by openmoko inc. has basically stopped and resources are allocated in favor of 2008.8, while the community currently does the effort to 'rescue' the 2007.2 telephony apps and pull them to the future middleware from FSO (see SHR).
thus patches are still welcome, especially if they help development of SHR.

=== Om 2008.8 (ASU, April/August Software Update) ===

Om 2008.8 has been started to integrate the [http://trolltech.com/products/qtopia Qtopia] stack - on X11 - with a new set of graphically pleasing applications based on the Enlightenment Foundation Libraries. ASU is the internal name and is known as Om 2008.8 upon its release on August 8, 2008. Qtopia is a more mature product than the GNOME Mobile stack and you can expect all the standard feature phone applications to work in a solid way. It uses the Qtopia phone server. Since - contrary to standard Qtopia - it does not directly use the framebuffer, non-Qt applications can safely share the screen with Qt applications.

* [[Om2008.8|Om 2008.8]]
* [[Downloads#Openmoko_2008.8_images_.28ASU.29|Download]]

=== FSO - freesmartphone.org ===

FSO has been started to overcome the deficiencies both of the 2007.2 and the 2008.8 stack, namely to come up with an extensible framework that gives developers the infrastructure they need to create solid and exciting software products based on the Openmoko platform. An infrastructure that supports competing UIs while we can collaborate on developing services, making the framework strong . Here, the focus is on stable highlevel services that you can access from whatever language or UI that supports [http://dbus.freesmartphone.org/ dbus]. People report that despite its infancy, e.g. the phone server part in FSO is already more solid than anywhere else.

It is not really intended as future release-target, but used as a 'vessel' or 'container' for the development and testing of the new, future middleware.<br>
The applications installed are intended as test-tools for the new middleware and not as fully featured, end user oriented applications. (even if it looks that way sometimes)

* [[FSO]]
* [http://trac.freesmartphone.org:8000/trac-example Development tracker]
* [http://downloads.openmoko.org/framework/milestone2/ Download milestone 2]
* [http://freesmartphone.org freesmartphone.org]
* [http://shr.bearstech.com/ fso-testing and fso-unstable images and feeds] (maintained by Rod Whitby, MokoMakefile author)

== Openmoko Community driven release targets ==

=== SHR - Stable Hybrid Release ===

Stable Hybrid Release is a combination of the middleware from FSO, some of the 2007.2 GTK software (telephony-ui, pim), and Om2008.8 that provides all of the functionality of the 2007.2 software, but with the stability of the FSO.

* [[Stable Hybrid Release]]

== Non-Openmoko distributions ==

These are not Openmoko (and OE) based distributions. These are an alternatives you can run on your Openmoko phones.

=== Qtopia ===

The Qtopia distribution from [http://www.trolltech.com Trolltech], it aims to provide a ready-to use image for Openmoko devices.

* [[Qtopia]]
* Download: [http://www.qtopia.net/modules/mydownloads/viewcat.php?cid=6 Qtopia.net]

=== Debian ===

Debian Linux, the whole distribution, on a mobile phone.

* [[Debian]]

== Features by distribution/release target ==

=== Connectivity ===

{| border=1 width=100% |
| width=14%| || width=14%|2007.2 || width=14%|FSO || width=14%|Om2008.8 || width=14%|SHR || width=14%|Qtopia || Debian
|-
| Telephony || style="background:lightgreen;" | Yes || style="background:lightgreen;" | Yes || style="background:lightgreen;" | Yes || N/A || style="background:lightgreen;" | Yes || style="background:lightgreen;" | Yes
|-
| SMS || style="background:lightgreen;" | Yes || style="background:lightgreen;" | Yes || style="background:lightgreen;" | Yes || N/A || style="background:lightgreen;" | Yes || style="background:lightgreen;" | Yes
|-
| GPRS || Not through UI || Not through UI || Not through UI || N/A || No (3) || style="background:lightgreen;" | Yes
|-
| WiFi || style="background:lightgreen;" | Yes || Not through UI || style="background:lightgreen;" | Yes (*) || N/A || style="background:lightgreen;" | Yes ||style="background:lightgreen;" | Yes
|-
| VoIP || ?? || ?? || ?? || ?? || ?? || style="background:lightgreen;" | Yes
|-
| Bluetooth || style="background:lightgreen;" | Yes || No || style="background:lightgreen;" | Yes || N/A || style="background:lightgreen;" | Yes || style="background:lightgreen;" | Yes
|-
| GPS || style="background:lightgreen;" | Yes (1) || style="background:lightgreen;" | Yes || style="background:lightgreen;" | Yes (1) || N/A || No || style="background:lightgreen;" | Yes
|-
|}

=== User Interaction ===

{| border=1 width=100% |
| width=14%| || width=14%|2007.2 || width=14%|FSO || width=14%|Om2008.8 || width=14%|SHR || width=14%|Qtopia || Debian
|-
| Stylus friendly || style="background:lightgreen;" | Yes || style="background:lightgreen;" | Yes || style="background:lightgreen;" | Yes || N/A || style="background:lightgreen;" | Yes || style="background:lightgreen;" | Yes
|-
| Finger friendly || Partially || Partially || Partially || N/A || style="background:lightgreen;" | Yes || No
|-
| Accelerometer || No || No || No || N/A || No || No
|-
|}

=== Applications ===

{| border=1 width=100% |
| width=14%| || width=14%|2007.2 || width=14%|FSO || width=14%|Om2008.8 || width=14%|SHR || width=14%|Qtopia || Debian
|-
| Terminal || Basic (2) || style="background:lightgreen;" | Yes || style="background:lightgreen;" | Yes (1) || N/A || style="background:lightgreen;" | Yes || style="background:lightgreen;" | Yes
|-
| PIM || style="background:lightgreen;" | Yes || No || style="background:lightgreen;" | Yes || N/A || style="background:lightgreen;" | Yes || style="background:lightgreen;" | Yes
|-
| Phonebook || style="background:lightgreen;" | Yes || style="background:lightgreen;" | Yes || style="background:lightgreen;" | Yes || N/A || style="background:lightgreen;" | Yes || style="background:lightgreen;" | Yes
|-
| Dialer || style="background:lightgreen;" | Yes || style="background:lightgreen;" | Yes || style="background:lightgreen;" | Yes || N/A || style="background:lightgreen;" | Yes || style="background:lightgreen;" | Yes
|-
| Web Browser || style="background:lightgreen;" | Yes (1) || ? || style="background:lightgreen;" | Yes (1) || ? || No || style="background:lightgreen;" | Yes
|-
| Mail Client || ? || ? || ? || ? || style="background:lightgreen;" | Yes || style="background:lightgreen;" | Yes
|-
| XMPP Client || style="background:lightgreen;" | Yes (1) || ? || ? || ? || No || style="background:lightgreen;" | Yes
|-
| Media Player || ? || ? || ? || ? || ? || ?
|-
|}

=== Toolkits / Runtimes ===
{| border=1 width=100% |
| width=14%| || width=14%|2007.2 || width=14%|FSO || width=14%|Om2008.8 || width=14%|SHR || width=14%|Qtopia || Debian
|-
| GTK+ || style="background:lightgreen;" | Yes || style="background:lightgreen;" | Yes || style="background:lightgreen;" | Yes || style="background:lightgreen;" | Yes || No || style="background:lightgreen;" | Yes
|-
| QT/Qtopia || No || style="background:lightgreen;" | Yes? || style="background:lightgreen;" | Yes || style="background:lightgreen;" | Yes? || style="background:lightgreen;" | Yes || style="background:lightgreen;" | Yes
|-
| Middleware || gsmd/neod || freesmartphone.org || qtopia-x11 || freesmartphone.org || qtopia || freesmartphone.org
|-
| [[Java]] || Jalimo || Jalimo || Jalimo || ? || ? || No
|-
| [[Python]] || style="background:lightgreen;" | Yes || style="background:lightgreen;" | Yes || style="background:lightgreen;" | Yes || ? || style="background:lightgreen;" | Yes || style="background:lightgreen;" | Yes
|-
|}

Footnotes:

(1) works, but need additional software to be installed

(2) unusable due to lack of certain keyboard characters (unless you [[Switching_Keyboards#Matchbox_keyboard|install matchbox-keyboard]])

(3) there is a UI but it crashes the device when used.

(*) unstable

== External links ==

Original distribution descriptions are from Mickey Lauer's [http://www.vanille-media.de/site/index.php/2008/06/28/gtk-asu-fso-tmtla/ GTK, ASU, FSO, TMTLA!].

[[Category:Distributions| ]]
[[Category:Documentation]]

Om 2008.8

2008-08-13T15:35:08Z

RodWhitby: /* Updates */

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

{{Distributions|Om 2008.8}}

=Introduction=
'''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 launched] on '''August 08, 2008'''. Om 2008.8 uses EFL for the launcher, custom UI applications and [[QtopiaOnX11|Qtopia on X11]] for telephony. It is the first step from GTK+ on x11 to using multiple toolkits in combination. '''Om 2008.8''' now supports [http://www.enlightenment.org/ EFL], [http://trolltech.com/products/qtopia Qtopia] and [http://www.gtk.org GTK+] applications.

''To see how it all got started go to'' [[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:25% " |
[[Image:Om2008 uboot.png|200px|center]]
! style="background:#fcfcfc;border-left:1px solid #9999cc;border-right:1px ; border-top:2px solid 75d806; border:1px solid #222222; width:25% " |
[[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:25% " |
[[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:25% " |
[[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:25% " |
[[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:25% " |
[[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:25% " |
[[Image:Om locations4.png|200px|center]]
! style="background:#fcfcfc;border-left:1px solid #9999cc;border-right:1px ; border-top:2px solid 75d806; border:1px solid #222222; width:25% " |
[[Image:List.png|200px|center]]
|}

== What's New ==
'''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.

=== Customize ===
'''Om 2008.8''' allows you to customize your Neo in many aspects.

* '''Use the [[Om2008.8_Installer|Installer]]''' to find apps and modifications for your Neo.
* '''Re-design themes''' by customizing your own [[Edje]] files.
* '''Source Codes''' are publicly available, allowing for customization all the way down to low level sytems.

=== Share ===
* share your locations ([[Om2008.8_Locations|Locations]])
:you can use '''Locations''' to save your favorite spots and even send it to friends via sms. How cool is that?!
* share your applications ([[Om2008.8_Installer|Installer]])
:share your ideas with the world by adding packages to the [http://wiki.openmoko.org/wiki/CommunityRepository Community Repository]. It is a great database for all things openmoko and can easily be accessed by any user through the [[Om2008.8 Installer|Installer]].

=== Om 2008.8 Guide ===
A guide for getting to know Om 2008.8 : [[Om 2008.8 Guide]]

= Download =

== Flash Om 2008.8 images ==

'''Download Om 2008.8 images'''

These images are to be flashed to the NAND memory of the FreeRunner :
* [http://downloads.openmoko.org/releases/Om2008.8/Om2008.8.rootfs.jffs2 Om2008.8.rootfs.jffs2] (root filesystem image)
* [http://downloads.openmoko.org/releases/Om2008.8/Om2008.8.uImage.bin Om2008.8.uimage.bin] (kernel)

'''Install'''

* For instructions on how to flash your device, please refer to [[Flashing the Neo FreeRunner]].

== Alternative : running from microSD card ==

You may install this distribution on the microSD card, in order to [[Boot from sd card|boot from microSD card]]. Tarfiles available here: [http://downloads.openmoko.org/releases/Om2008.8/]. That allows you to keep another distribution installed in NAND (for instance to test 2008.08 while still having 2007.2 for default boot).

= Known Issues =
'''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]
* [https://docs.openmoko.org/trac/ticket/1765 No Pin-Dialog is showing up and so GSM is not usable at all]

'''WiFi'''

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

'''Audio quality'''

* [http://docs.openmoko.org/trac/ticket/1721 QT-Dialer Sometimes can not hear anything durring connecting call]
* [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]

'''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 this line in /etc/network/interfaces:

up echo nameserver 192.168.0.200 >/etc/resolv.conf
This is to be inserted below gateway address and above the bluetooth networking. After this rebooting is required. Then go to /etc/resolv.conf and fill it manually by just using the content of this file on your local machine, or DNS address.

This should solve most off 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 }}

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

'''Usabillity'''
* 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. Sollution: run "killall packagekitd" (on the freerunner or when ssh'ed in).

== Updates ==

There should be some official updates for 2008.8 setup soon, but in the meantime, you'll have to wait.

There are *NO* updates available for 2008.08 anywhere on buildhost.openmoko.org - the daily-feeds directory is incompatible with 2008.08 and will corrupt your software configuration if you use it.

[[Category:Openmoko]]
[[Category:Om 2008.8]]

Building FSO

2008-08-13T06:31:46Z

RodWhitby:

{{FSO}}

''This information is taken as is from [http://wiki.openembedded.net/index.php/OEandYourDistro#Using_OpenEmbedded_on_Linux_systems OpenEmbedded Wiki]. Some commentaries are voluntarily stripped in order to keep this page simple, please look on OE Wiki for more information.''

WHY, OH, WHY, DO PEOPLE DUPLICATE INFORMATION ON HOW TO BUILD OPENEMBEDDED ON YET ANOTHER WIKI PAGE. Just point to the OE pages, or to the MokoMakefile page.

= Getting Open Embedded =

== Mandatory Packages ==

=== Deb-based distributions ===

apt-get install ccache sed wget cvs subversion git-core monotone coreutils \
unzip texi2html texinfo libsdl1.2-dev docbook-utils gawk

=== Mandriva-based distributions ===

urpmi python python-devel python-psyco ccache patch m4 sed bison make wget bzip2 \
cvs gawk glibc-devel gcc-c++ subversion sharutils coreutils docbook-utils openjade \
quilt pcre-devel unzip

=== SuSE (9.1/9.2) instructions ===
Install [http://linux01.gwdg.de/apt4rpm/ apt4rpm], then follow Debian instructions.

python-dev and python-spyco are not in suse apt repository. python-spyco is not mandatory, so one can ignore it.
I suppose python-devel (suse) is python-dev (debian).

=== Fedora Core 2/3 ===

yum install python patch m4 sed make docbook* openjade glibc-devel xmlto

=== Fedora Core 4 ===

Apart from the usual (native) development packages like gcc and binutils, you should check that you have the following RPM's installed:

* bison
* ccache (not required, but advised to speed up building)
* docbook* packages
* libpcre
* m4
* make
* openjade
* patch
* PyQt
* python
* python-psyco
* sed
* xmlto
* quilt (not required as OE builds it by itself, but install it if you want to use gquilt)

Use apt, synaptic, up2date or yum to automagically retrieve these packages or download and install them manually (lots of work).

=== Fedora Core 5/6 ===

Commands I used to install OE pre-requisites on FC5/6

This long command will ensure all pre-requisites are installed (patch is 2.5.4, not 2.5.9, but appears to work).

su -c "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 gcc gcc-c++ python-sqlite2 help2man"

or download the metapackage http://www.openembedded.org/dl/packages/rpm/openembedded-essential-1.1-1.noarch.rpm (may be out of date).

then do

su -c "yum localinstall openembedded-essential-1.1-1.noarch.rpm"

=== Fedora 7 ===

This long command will ensure all pre-requisites are installed (patch is 2.5.4, not 2.5.9, but appears to work).

su -c "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 linuxdoc-tools gcc gcc-c++ help2man"

=== CentOS 4.4 / Red Hat Enterprise Linux 4 ===

yum install bison ccache coreutils cvs docbook-utils gawk git-core monotone \
python quilt rpmlib sed subversion tetex texinfo unzip wget

=== Gentoo instructions ===

emerge -n bitbake psyco ccache patch make sed dev-lang/python m4 bison cvs openjade \
quilt sgmltools-lite docbook-xml-dtd docbook-dsssl-stylesheets xmlto docbook-sgml-utils \
libpcre boost subversion monotone texi2html pysqlite diffstat

=== Ark Linux 2007.1 ===

apt-get install devel-core diffstat texi2html cvs subversion git texinfo psyco monotone \
python-devel python-encodings python-sqlite

=== Arch Linux (Duke) ===

sudo pacman -S psyco ccache patch make sed python m4 bison cvs quilt sgmltools-lite \
docbook-xml xmlto pcre boost monotone jade git texinfo

In Arch Linux the install command is in /bin/install. Since most of Linux distribution assume that install is located in /usr/bin/install, you have to create a symlink:

sudo ln -s /bin/install /usr/bin/install

You can build BitBake by using this PKGBUILD:
pkgname=bitbake
pkgver=1.8.4
pkgrel=1
pkgdesc="A simple tool for task execution derived from Gentoo's portage"
url="http://developer.berlios.de/projects/bitbake/"
arch=('i686')
license=('GPL' 'custom')
depends=('python')
source=(http://download.berlios.de/bitbake/${pkgname}-${pkgver}.tar.gz)
md5sums=('508d9a61c635d469be8facc95151158b')

build() {
cd ${startdir}/src/${pkgname}-${pkgver}
python setup.py install --root=${startdir}/pkg

# Install vim extensions
install -D -m644 ${startdir}/src/${pkgname}-${pkgver}/contrib/vim/ftdetect/bitbake.vim \
${startdir}/pkg/usr/share/vim/ftplugin/bitbake.vim
install -D -m644 ${startdir}/src/${pkgname}-${pkgver}/contrib/vim/syntax/bitbake.vim \
${startdir}/pkg/usr/share/vim/syntax/bitbake.vim

# Handle MIT license
install -D -m644 ${startdir}/src/${pkgname}-${pkgver}/doc/COPYING.MIT \
${startdir}/pkg/usr/share/licenses/${pkgname}/COPYING.MIT
}

= Repository Checkout =

== Bitbake ==

Go to the base directory of your [[OpenEmbedded]] environment and checkout bitbake:
<pre><nowiki>
$ cd /stuff/
$ svn co svn://svn.berlios.de/bitbake/branches/bitbake-1.8/ bitbake</nowiki></pre>
'''NOTE:''' for proxy handling, see [http://subversion.tigris.org/faq.html#proxy SVN FAQ]

== Open Embedded ==

=== Obtaining OpenEmbedded ===
Next, you'll need to obtain the actual Openembedded database. The OE database store all the OE metadata: build classes, configuration files, and packages. Then you can extract from this database the development branch(es) you want.

The Openembedded database is a [http://www.venge.net/monotone/ Monotone] database, which is the current SCM (Source Code Management) system for Openembedded. You can find monotone binaries and documentation at [http://www.venge.net/monotone/ Monotone official site].

To obtain Openembedded:
# Go to the base directory of your Openembedded environment
$ cd /stuff/
# Download and bunzip2 the OE database snapshot. '''Note: Unfortunately some monotone versions differ in database format. Check [http://www.openembedded.org/snapshots Snapshots] and download the one matching your monotone version.'''
$ wget http://www.openembedded.org/snapshots/OE.mtn.bz2
$ bunzip2 -d OE.mtn.bz2
This is the database you'll be using for all the work.

If you run into a problem at this stage, check to make sure you have version 0.32 (or newer) of monotone installed.

If you get further troubles in using monotone, there are two ways out:

* use the [http://openembedded.org/snapshots/ latest OE snapshot]
* use a static monotone image

Then you can checkout your local copy of the Openembedded tree.
$ cd /stuff
$ mtn --db=/stuff/OE.mtn checkout --branch=org.openembedded.dev
This extracts directories and files relating to the selected branch from the OE.mtn database and places them under <nowiki>/stuff/branchname</nowiki> (i.e. in <nowiki>/stuff/org.openembedded.dev</nowiki> in this guide)

IMPORTANT NOTE ! If mtn complains about an outdated database, you can migrate it using the following command :

<pre><nowiki>
mtn db migrate --db=/stuff/OE.mtn
</nowiki></pre>

You'll then have to do the checkout.
=== Create local configuration ===
It's now time to create your local configuration.
While you could copy the default local.conf.sample like that:

<pre><nowiki>
$ cd /stuff/
$ cp org.openembedded.dev/conf/local.conf.sample build/conf/local.conf
$ vi build/conf/local.conf
</nowiki></pre>

It is actually recommended to start smaller and keep local.conf.sample in the background and add entries from there step-by-step as you understand and need them. Please, do not just edit build/conf/local.conf.sample but actually READ it.

For building a .dev branch, in your <nowiki>local.conf</nowiki> file, you should have at least the following three entries. Example for the Angstrom distribution and the Openmoko gta01 machine:
<pre><nowiki>
BBFILES = "/stuff/org.openembedded.dev/packages/*/*.bb"
DISTRO = "angstrom-2008.1"
MACHINE = "om-gta01"
</nowiki></pre>

For a Freerunner, using an openmoko distro, you'll do that :

<pre><nowiki>
BBFILES = "/stuff/org.openembedded.dev/packages/*/*.bb"
DISTRO = "openmoko"
MACHINE = "om-gta02"
</nowiki></pre>

Don't forget to include the two following files :

<pre><nowiki>
require conf/distro/include/fso-autorev.inc
require conf/distro/include/moko-autorev.inc
</nowiki></pre>

=== Setup the environment ===
One of the four command sets below will need to be run every time you open a terminal for development. (You can automate this in ~/.profile, /etc/profile, or perhaps use a script to set the necessary variables for using [[BitBake]].)

If you followed the recommendation above to use an uninstalled [[BitBake]]:
<pre><nowiki>
$ export PATH=/stuff/bitbake/bin:$PATH
$ export BBPATH=/stuff/build:/stuff/org.openembedded.dev
</nowiki></pre>

If you installed [[BitBake]]:
<pre><nowiki>
$ export BBPATH=/stuff/build:/stuff/org.openembedded.dev
</nowiki></pre>

Alternative syntax for those using the tcsh shell (e.g FreeBSD):
<pre><nowiki>
$ setenv PATH "/stuff/bitbake/bin:"$PATH
$ setenv BBPATH "/stuff/build:/stuff/org.openembedded.dev:"$BBPATH
</nowiki></pre>

= Start building =

<pre><nowiki>
cd /stuff/build && bitbake fso-image
</nowiki></pre>
[[category:Technical]]
[[Category:Software (non openmoko)]]
[[category:FSO]]

= Configuration =

== GTK ==

Currently GTK is not well supported in the FSO build. To use GTK applications you'll most likely have to install the gtk library, and the Openmoko theme.

'''Step 1) Install the ipk-packages'''

opkg install moko-gtk-theme
opkg install openmoko-icon-theme-standard2

'''Step 2) Enable Theme'''

ln -s /usr/share/themes/Moko/gtk-2.0/gtkrc /etc/gtk-2.0/gtkrc

'''Step 3) Adjust fontsize and set icon theme'''

vi /etc/gtk-2.0/gtkrc

Add the two lines:
gtk-font-name = "Sans 5"
gtk-icon-theme-name="openmoko-standard"

(Thanks to [[User:Jtickle | Jtickle]] for pointing out how to set the font size on the [[Getting_Started_FAQ]]-Page)

MokoMakefile

2008-08-12T07:37:12Z

RodWhitby: /* Environment */

{{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 =====
sudo apt-get install subversion build-essential help2man diffstat texi2html texinfo cvs gawk zip unzip cogito

sudo apt-get install libncurses5-dev zlib1g-dev libssl-dev libgtk2.0-dev
# To prevent errors in host validation
sudo apt-get install ca-certificates
# For Openmoko 2007.2 using BitBake-1.8.8:
sudo apt-get install python-pysqlite2 sqlite3 sqlite3-doc python-pysqlite2-dbg
# For building faster
sudo apt-get install quilt python-psyco ccache
# For qemu, install a second compiler for bug avoidance; MokoMakefile knows to look for it.
sudo 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
sudo apt-get install git-core
# Ubuntu links /bin/sh to /bin/dash, but some scripts fail because they use pushd and popd, which dash does not support
sudo rm /bin/sh
sudo ln -s /bin/bash /bin/sh

# This may be needed only for ASU
sudo apt-get install libxtst-dev

===== 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 ===
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 (enabled by default)
OM_GIT_BRANCH := org.openmoko.asu.dev # ASU bleeding edge
OM_GIT_BRANCH := org.openmoko.asu.testing # ASU testing
OM_GIT_BRANCH := org.openmoko.asu.stable # ASU stable
OM_GIT_BRANCH := org.openembedded.dev # FSO

Note that if you want to build FSO, you should change OM_GIT_SITE to git.openembedded.net as well, since FSO is developed in the OpenEmbedded repository, not the Openmoko repository.

Set up the environment with:

make setup

If you are building for the Neo1973 GTA01, then also do this
make setup-machine-neo
If you are building for the Freerunner GTA02, then also do this
make setup-machine-freerunner

=== Building ===
Before starting a lengthy make process, check the [[#Tips|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 [[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 backticks).
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 ===
==== SVN Server Certificate Errors ====
If you get an error like the following:
<pre>
NOTE: Fetch svn://svn.projects.openmoko.org/svnroot/;module=assassin;proto=https
Error validating server certificate for 'https://svn.projects.openmoko.org:443':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
Certificate information:
- Hostname: projects.openmoko.org
- Valid: from Thu, 05 Jun 2008 01:02:42 GMT until Tue, 02 Dec 2008 01:02:42 GMT
- Issuer: http://www.cacert.org, Root CA
- Fingerprint: a5:7d:4e:37:e8:94:ee:ba:c1:e8:e9:4b:33:cb:34:91:a9:6d:d3:84
(R)eject, accept (t)emporarily or accept (p)ermanently? svn: OPTIONS of 'https://svn.projects.openmoko.org/svnroot/assassin': Server certificate verification failed: issuer is not trusted (https://svn.projects.openmoko.org)
</pre>

It means you haven't yet accepted the server certificate for the SVN server. To remedy this, execute the following commands, and hit "p" (to permanently accept the certificate) when prompted:
<pre>
cd /tmp
svn co https://svn.projects.openmoko.org/svnroot/assassin
rm -rf assassin
cd -
</pre>

==== exposure_svn and Subversion 1.5.0 ====

If you get an error like this:

<code>
"NameError: global name 'log' is not defined"
</code>

There's a bug with subversion 1.5.0 -- downgrade to 1.4.x (or check out the latest subversion sources and use those as they're fixed) and re-fetch the sources.

===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.

* Make sure you do not have . in your PATH, this causes an "unrecognized option -Qy" error when building g++spec

=== 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

; make setup-machine-neo : setup for GTA01 version of Neo1973

; make setup-machine-freerunner : setup for GTA02 version of Freerunner

==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 patch openmoko-messages
cd tmp/work/armv4t-linux/openmoko-messages-0.0.1+svnnow-r2_2276/openmoko-messages/
''...make the changes...''
cd -
bitbake -c build openmoko-messages

Note: if you just use <tt>bitbake openmoko-messages</tt> it will remove the sources after building!

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", "make openmoko-devel-image :) - no magic there", and "I have never been able to get a build to complete in the pure OE environment, whereas Mokomakefile for some reason builds fine."

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

[[Category:Openmoko]]
[[Category:Applications]]
[[Category:Application Developer]]

MokoMakefile

2008-08-12T07:36:36Z

RodWhitby: /* Environment */

{{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 =====
sudo apt-get install subversion build-essential help2man diffstat texi2html texinfo cvs gawk zip unzip cogito

sudo apt-get install libncurses5-dev zlib1g-dev libssl-dev libgtk2.0-dev
# To prevent errors in host validation
sudo apt-get install ca-certificates
# For Openmoko 2007.2 using BitBake-1.8.8:
sudo apt-get install python-pysqlite2 sqlite3 sqlite3-doc python-pysqlite2-dbg
# For building faster
sudo apt-get install quilt python-psyco ccache
# For qemu, install a second compiler for bug avoidance; MokoMakefile knows to look for it.
sudo 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
sudo apt-get install git-core
# Ubuntu links /bin/sh to /bin/dash, but some scripts fail because they use pushd and popd, which dash does not support
sudo rm /bin/sh
sudo ln -s /bin/bash /bin/sh

# This may be needed only for ASU
sudo apt-get install libxtst-dev

===== 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 ===
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 (enabled by default)
OM_GIT_BRANCH := org.openmoko.asu.dev # ASU
OM_GIT_BRANCH := org.openmoko.asu.stable # ASU stable
OM_GIT_BRANCH := org.openembedded.dev # FSO

Note that if you want to build FSO, you should change OM_GIT_SITE to git.openembedded.net as well, since FSO is developed in the OpenEmbedded repository, not the Openmoko repository.

Set up the environment with:

make setup

If you are building for the Neo1973 GTA01, then also do this
make setup-machine-neo
If you are building for the Freerunner GTA02, then also do this
make setup-machine-freerunner

=== Building ===
Before starting a lengthy make process, check the [[#Tips|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 [[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 backticks).
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 ===
==== SVN Server Certificate Errors ====
If you get an error like the following:
<pre>
NOTE: Fetch svn://svn.projects.openmoko.org/svnroot/;module=assassin;proto=https
Error validating server certificate for 'https://svn.projects.openmoko.org:443':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
Certificate information:
- Hostname: projects.openmoko.org
- Valid: from Thu, 05 Jun 2008 01:02:42 GMT until Tue, 02 Dec 2008 01:02:42 GMT
- Issuer: http://www.cacert.org, Root CA
- Fingerprint: a5:7d:4e:37:e8:94:ee:ba:c1:e8:e9:4b:33:cb:34:91:a9:6d:d3:84
(R)eject, accept (t)emporarily or accept (p)ermanently? svn: OPTIONS of 'https://svn.projects.openmoko.org/svnroot/assassin': Server certificate verification failed: issuer is not trusted (https://svn.projects.openmoko.org)
</pre>

It means you haven't yet accepted the server certificate for the SVN server. To remedy this, execute the following commands, and hit "p" (to permanently accept the certificate) when prompted:
<pre>
cd /tmp
svn co https://svn.projects.openmoko.org/svnroot/assassin
rm -rf assassin
cd -
</pre>

==== exposure_svn and Subversion 1.5.0 ====

If you get an error like this:

<code>
"NameError: global name 'log' is not defined"
</code>

There's a bug with subversion 1.5.0 -- downgrade to 1.4.x (or check out the latest subversion sources and use those as they're fixed) and re-fetch the sources.

===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.

* Make sure you do not have . in your PATH, this causes an "unrecognized option -Qy" error when building g++spec

=== 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

; make setup-machine-neo : setup for GTA01 version of Neo1973

; make setup-machine-freerunner : setup for GTA02 version of Freerunner

==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 patch openmoko-messages
cd tmp/work/armv4t-linux/openmoko-messages-0.0.1+svnnow-r2_2276/openmoko-messages/
''...make the changes...''
cd -
bitbake -c build openmoko-messages

Note: if you just use <tt>bitbake openmoko-messages</tt> it will remove the sources after building!

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", "make openmoko-devel-image :) - no magic there", and "I have never been able to get a build to complete in the pure OE environment, whereas Mokomakefile for some reason builds fine."

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

[[Category:Openmoko]]
[[Category:Applications]]
[[Category:Application Developer]]

MokoMakefile

2008-08-12T07:35:29Z

RodWhitby: Another testimonial

{{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 =====
sudo apt-get install subversion build-essential help2man diffstat texi2html texinfo cvs gawk zip unzip cogito

sudo apt-get install libncurses5-dev zlib1g-dev libssl-dev libgtk2.0-dev
# To prevent errors in host validation
sudo apt-get install ca-certificates
# For Openmoko 2007.2 using BitBake-1.8.8:
sudo apt-get install python-pysqlite2 sqlite3 sqlite3-doc python-pysqlite2-dbg
# For building faster
sudo apt-get install quilt python-psyco ccache
# For qemu, install a second compiler for bug avoidance; MokoMakefile knows to look for it.
sudo 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
sudo apt-get install git-core
# Ubuntu links /bin/sh to /bin/dash, but some scripts fail because they use pushd and popd, which dash does not support
sudo rm /bin/sh
sudo ln -s /bin/bash /bin/sh

# This may be needed only for ASU
sudo apt-get install libxtst-dev

===== 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 ===
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 (enabled by default)
OM_GIT_BRANCH := org.openmoko.asu.dev # ASU
OM_GIT_BRANCH := org.openmoko.asu.stable # ASU stable
OM_GIT_BRANCH := org.openembedded.dev # FSO

Set up the environment with:

make setup

If you are building for the Neo1973 GTA01, then also do this
make setup-machine-neo
If you are building for the Freerunner GTA02, then also do this
make setup-machine-freerunner

=== Building ===
Before starting a lengthy make process, check the [[#Tips|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 [[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 backticks).
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 ===
==== SVN Server Certificate Errors ====
If you get an error like the following:
<pre>
NOTE: Fetch svn://svn.projects.openmoko.org/svnroot/;module=assassin;proto=https
Error validating server certificate for 'https://svn.projects.openmoko.org:443':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
Certificate information:
- Hostname: projects.openmoko.org
- Valid: from Thu, 05 Jun 2008 01:02:42 GMT until Tue, 02 Dec 2008 01:02:42 GMT
- Issuer: http://www.cacert.org, Root CA
- Fingerprint: a5:7d:4e:37:e8:94:ee:ba:c1:e8:e9:4b:33:cb:34:91:a9:6d:d3:84
(R)eject, accept (t)emporarily or accept (p)ermanently? svn: OPTIONS of 'https://svn.projects.openmoko.org/svnroot/assassin': Server certificate verification failed: issuer is not trusted (https://svn.projects.openmoko.org)
</pre>

It means you haven't yet accepted the server certificate for the SVN server. To remedy this, execute the following commands, and hit "p" (to permanently accept the certificate) when prompted:
<pre>
cd /tmp
svn co https://svn.projects.openmoko.org/svnroot/assassin
rm -rf assassin
cd -
</pre>

==== exposure_svn and Subversion 1.5.0 ====

If you get an error like this:

<code>
"NameError: global name 'log' is not defined"
</code>

There's a bug with subversion 1.5.0 -- downgrade to 1.4.x (or check out the latest subversion sources and use those as they're fixed) and re-fetch the sources.

===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.

* Make sure you do not have . in your PATH, this causes an "unrecognized option -Qy" error when building g++spec

=== 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

; make setup-machine-neo : setup for GTA01 version of Neo1973

; make setup-machine-freerunner : setup for GTA02 version of Freerunner

==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 patch openmoko-messages
cd tmp/work/armv4t-linux/openmoko-messages-0.0.1+svnnow-r2_2276/openmoko-messages/
''...make the changes...''
cd -
bitbake -c build openmoko-messages

Note: if you just use <tt>bitbake openmoko-messages</tt> it will remove the sources after building!

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", "make openmoko-devel-image :) - no magic there", and "I have never been able to get a build to complete in the pure OE environment, whereas Mokomakefile for some reason builds fine."

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

[[Category:Openmoko]]
[[Category:Applications]]
[[Category:Application Developer]]

MokoMakefile

2008-05-21T08:17:00Z

RodWhitby: Removed all trace of monotone.

{{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 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://www.openembedded.org/wiki/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

===== 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"

== Building Openmoko with MokoMakefile ==

1 - 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
2 - 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]}}

3 - Set up the environment:
make setup
4 - Start building. 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

''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].

===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==
*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.

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

* 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 [http://wiki.openmoko.org/wiki/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:Software]]
[[Category:Applications]]
[[Category:Application Developer]]

Community Member of the Week

2008-03-31T11:47:52Z

RodWhitby: /* Week 1: Monday, 31 March */

=Purpose=

Michael Shiloh proposed in a [http://lists.openmoko.org/pipermail/community/2008-March/014580.html mail] to make a poll for the Openmoko "Community Member of the Week".

"The intent is clearly to identify and appreciate those of you who have
made and continue to make substantial contributions, and also to
encourage that extra bit of work required to turn a good application
into an excellent one, with a nicely polished GUI, a well written user
guide, etc."

I'm not sure, how the voting should be handled. However, I want to start with a nomination.

=Nomination=
== Week 1: Monday, 31 March ==
{| border="1"
! Nominator !! Nominee !! Reason !! Votes
|-
| [[User:Avanc|Sven]]
| [[User:Kevin_Dean|Kevin]]
| Kevin writes the (almost) daily [[Snapshot_review|Snapshot review]] and reports on the progress and problems of the current software. Since I'm not an owner of a GTA01, I can't test the software by myself. Therefore any information about Openmoko makes the waiting for the Freerunner less bitter. I'm reading the different mailing lists very carefully and come to know of solved bugs and new features. However, Kevin gives with his reviews an impression of the software from a users point of view. And when the Freerunner is released, I hope Kevin will continue with his reviews so I always know what snapshot is safe to use.
|2
|-
| [[User:Cb22|Cb22]]
| [[User:JoSch|Josch]]
| Josch has done the really cool hack of getting a full [[debian]] installation, complete with XOrg and touch screen support, up and running on a Neo 1973.
|0
|-
|}

If you run out of votes in any week, you could look at [[Community_nominees_for_GTA02_P0]] for ideas ...

[[category:Community]]

Community Member of the Week

2008-03-31T11:47:40Z

RodWhitby: /* Week 1: Monday, 31 March */

=Purpose=

Michael Shiloh proposed in a [http://lists.openmoko.org/pipermail/community/2008-March/014580.html mail] to make a poll for the Openmoko "Community Member of the Week".

"The intent is clearly to identify and appreciate those of you who have
made and continue to make substantial contributions, and also to
encourage that extra bit of work required to turn a good application
into an excellent one, with a nicely polished GUI, a well written user
guide, etc."

I'm not sure, how the voting should be handled. However, I want to start with a nomination.

=Nomination=
== Week 1: Monday, 31 March ==
{| border="1"
! Nominator !! Nominee !! Reason !! Votes
|-
| [[User:Avanc|Sven]]
| [[User:Kevin_Dean|Kevin]]
| Kevin writes the (almost) daily [[Snapshot_review|Snapshot review]] and reports on the progress and problems of the current software. Since I'm not an owner of a GTA01, I can't test the software by myself. Therefore any information about Openmoko makes the waiting for the Freerunner less bitter. I'm reading the different mailing lists very carefully and come to know of solved bugs and new features. However, Kevin gives with his reviews an impression of the software from a users point of view. And when the Freerunner is released, I hope Kevin will continue with his reviews so I always know what snapshot is safe to use.
|2
|-
| [[User:Cb22|Cb22]]
| [[User:JoSch|Josch]]
| Josch has done the really cool hack of getting a full [[debian]] installation, complete with XOrg and touch screen support, up and running on a Neo 1973.
|0
|-
|}

If you run out of votes in any week, you could look at Community_nominees_for_GTA02_P0 for ideas ...

[[category:Community]]

MokoMakefile

2008-03-24T09:27:17Z

RodWhitby: /* Building OpenMoko with 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 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 either OM-2007.1 or OM-2007.2 images. The core team chooses the default, but you can select one or the other at the top of the Makefile.

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 ===
The version control system used by OpenEmbedded is [http://monotone.ca monotone], it is not downloaded and installed by MokoMakefile. If your distribution does not provide a package, you can download and install a static binary from http://monotone.ca

Some distribution specific hints on preparing your build host for building OpenEmbedded are on http://www.openembedded.org/wiki/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 monotone build-essential help2man diffstat texi2html texinfo cvs gawk

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

===== SuSE =====
For building OpenMoko on 10.3, you need
gcc-c++ ncurses-devel zlib-devel libopenssl-devel gtk2-devel subversion diffstat texinfo help2man and [http://download.opensuse.org/repositories/devel:/tools:/scm/openSUSE_Factory/repodata/repoview/Development.Tools.group.html monotone]
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. Use monotone for [http://download.opensuse.org/repositories/devel:/tools:/scm/openSUSE_10.2/repodata/repoview/Development.Tools.group.html 10.2] or [http://download.opensuse.org/repositories/devel:/tools:/scm/SUSE_Linux_10.1/repodata/repoview/Development.Tools.group.html 10.1]

==== 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"

== Building OpenMoko with MokoMakefile ==

1 - 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
2 - 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: If you want to compile for the old version 2007.1 instead of the new
version edit the top of the Makefile. Edit the lines at the top to
look like this:
OPENMOKO_GENERATION = 2007.1
#OPENMOKO_GENERATION = 2007.2

{{note|For building 2007.2, 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]}}

3 - Set up the environment:
make setup
4 - Start building. 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

''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

If 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].

===Known MokoMakefile errors ===
If you experience the following after changing from OM-2007.1 to OM-2007.2:

Patch bitbake-1.6.6-om3.patch does not apply (enforce with -f)

then type "make clobber-patches" to fix it. There was a period of 24 hours when there was a bug in the MokoMakefile which causes this problem. Once the patches have been clobbered, they will re-download and the problem will not reoccur.

If you see:

ERROR: No providers of build target u-boot-openmoko (for [])

then look back in the log to see if you encountered an earlier error while building the openmoko-devel-image target. The above error is a side-effect of MokoMakefile's logic to handle the re-naming of "uboot-openmoko" to "u-boot-openmoko".

===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==
*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 you an encounter an error with monotone similar to the following:
mtn: misuse: database /home/''username''/moko/OE.mtn is laid out according to an old schema
Then you need to upgrade OE.mtn Use the following command while in ~/moko:
# mtn --db OE.mtn db migrate

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

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

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

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

* 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 [http://wiki.openmoko.org/wiki/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/

{{Languages|MokoMakefile}}
[[Category:Software]]
[[Category:Applications]]
[[Category:Developer]]
[[Category:Guides]]

MokoMakefile

2008-01-14T10:27:44Z

RodWhitby: /* Testimonials */

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 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 either OM-2007.1 or OM-2007.2 images. The core team chooses the default, but you can select one or the other at the top of the Makefile.

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 ===
The version control system used by OpenEmbedded is [http://monotone.ca monotone], it is not downloaded and installed by MokoMakefile. If your distribution does not provide a package, you can download and install a static binary from http://monotone.ca

Some distribution specific hints on preparing your build host for building OpenEmbedded are on http://www.openembedded.org/wiki/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 monotone build-essential help2man
diffstat texi2html texinfo cvs gawk
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

===== SuSE =====
For building OpenMoko on 10.3, you need
gcc-c++ ncurses-devel zlib-devel libopenssl-devel gtk2-devel subversion diffstat texinfo help2man and [http://download.opensuse.org/repositories/devel:/tools:/scm/openSUSE_Factory/repodata/repoview/Development.Tools.group.html monotone]
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. Use monotone for [http://download.opensuse.org/repositories/devel:/tools:/scm/openSUSE_10.2/repodata/repoview/Development.Tools.group.html 10.2] or [http://download.opensuse.org/repositories/devel:/tools:/scm/SUSE_Linux_10.1/repodata/repoview/Development.Tools.group.html 10.1]

==== 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.

== Building OpenMoko with MokoMakefile ==

1 - Create your $OMDIR directory (note that you can change ~/moko to any directory you like):
mkdir ~/moko ; cd ~/moko
2 - Grab MokoMakefile:
wget http://www.rwhitby.net/files/openmoko/Makefile

If that doesn't work, try

wget http://svn.nslu2-linux.org/svnroot/mokomakefile/trunk/Makefile

note: If you want to compile for the old version 2007.1 instead of the new
version edit the top of the Makefile. Edit the lines at the top to
look like this:
OPENMOKO_GENERATION = 2007.1
#OPENMOKO_GENERATION = 2007.2

{{note|For building 2007.2, 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]}}

3 - Set up the environment:
make setup
4 - Start building. 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

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

If 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].

===Known MokoMakefile errors ===
If you experience the following after changing from OM-2007.1 to OM-2007.2:

Patch bitbake-1.6.6-om3.patch does not apply (enforce with -f)

then type "make clobber-patches" to fix it. There was a period of 24 hours when there was a bug in the MokoMakefile which causes this problem. Once the patches have been clobbered, they will re-download and the problem will not reoccur.

If you see:

ERROR: No providers of build target u-boot-openmoko (for [])

then look back in the log to see if you encountered an earlier error while building the openmoko-devel-image target. The above error is a side-effect of MokoMakefile's logic to handle the re-naming of "uboot-openmoko" to "u-boot-openmoko".

===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==
*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 you an encounter an error with monotone similar to the following:
mtn: misuse: database /home/''username''/moko/OE.mtn is laid out according to an old schema
Then you need to upgrade OE.mtn Use the following command while in ~/moko:
# mtn --db OE.mtn db migrate

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

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

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

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

* 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 ../build/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 [http://wiki.openmoko.org/wiki/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/

{{Languages|MokoMakefile}}

[[Category:Developer]]
[[Category:Guides]]

Neo 1973 GPS

2007-10-13T16:37:13Z

RodWhitby: add a link to the new GPS chip

The Neo1973 device contains an integrated GPS. The particular device
is marketed as an AGPS, and there is some [[Hardware:AGPS |
discussion]] available as to what significance that "A" might have.

Note that the GTA02 device (not yet available) contains a different GPS chip (see http://www.u-blox.com/products/atr0635.html for specs).

All purchased phones do not include the GPS binary driver. [http://lists.openmoko.org/pipermail/community/2007-July/008466.html]

In the very early shipment to 50 Phase 1 developers, a binary-only program for talking to the the GPS was accidentally included
in /home/root/DM2/gps, (and presumably, the same binary would function on a P0 device).
This binary is called gllin and it is a oabi binary, i.e. it will only work in the 2007.1 OpenMoko environment. There is now a eabi binary, which works with 2007.2, but it does not work very well and has not been released yet (as of end of September).

There is an ongoing effort to write a Free Software
program that could be used instead of this binary-only program.

See
[[Hammerhead/Protocol]] for details and the latest status.

Some scripts for those with the binary are on [[GPS_scripts]]

=== Possible GPS programs ===

As people develop more sophisticated GPS applications, please note them here.

Here are some ideas for possibilities:

* Cairo-based mapping
* Routing
* [[Openstreetmap]] a map viewer, annotation, and editing system.
* [[GPS-Trail]] a simple trail logger.
* [[GPS_Navigation#roadmap|roadmap]] mapping system using freely available maps (census tiger, DGLib, shapefiles).
* [[Geocaching]] paper chase for advanced users

* [http://lists.openmoko.org/pipermail/community/2007-July/007252.html collection of ideas]

[[Category:GPS]]

Neo 1973 and Windows

2007-09-10T15:16:57Z

RodWhitby: Add the windows internet connection sharing method

This page tries to collect some information on how to use your Neo1973 together with a computer running a Microsoft(R) Windows(TM) series operating system.

Please note that this is not really supported, and that the OpenMoko developers themselves only use Linux for testing.

== Connecting to the phone ==

=== Bluetooth connection ===

How to connect to Windows XP via Bluetooth is described here: [[Manually_using_Bluetooth#Bluetooth_networking_with_a_Windows_XP_system]]

=== USB Ethernet emulation ===
{{note|As of Kernel 2.6.22.5-moko11, USB RNDIS networking ''finally works'' in Windows XP using the procedure described below.}}

# Download http://privat.wmo.de/~c_schweers/NeoRndis.inf to somewhere convenient on your Windows machine.
# Connect the Neo1973 USB port to the Windows machine, using a standard USB-A to USB-mini-B cable.
# Assuming the new drivers have been installed as above, Windows should detect the Neo1973 and prompt you for a driver for the USB device. Select to specify your own driver, and then choose the NeoRndis.inf file you downloaded earlier. This file tells Windows XP to use its own built-in RNDIS driver for the device.
# Windows may complain of "reduced network connectivity". This is because it expects to be able to get an address automatically from the Neo1973 and it doesn't provide one in the default setup. To fix this, see the next step.
# Go into the Windows network configuration for the new USB networking adapter and set the IP address of the interface to 192.168.0.200.

You should now be able to connect to your Neo1973 on 192.168.0.202 via ssh (e.g. putty)

=== Setting up routing ===

If you want to connect to the internet from your Neo via Windows XP, e.g. for doing ipkg update/upgrade, you need to set up IP forwarding and routing properly.

An easy way to do this is to use Windows Internet Connection Sharing.

To do this, you need to create a network bridge which contains the usb connection to the neo.

Then you tell windows to share the WAN connection with the new bridge.

Then you manually set the IP address of the bridge to 192.168.0.200

After you have done all this, the Neo will be able to route through the windows machine out to the internet. DNS queries will also be proxied by the windows machine.

An alternative way is to do it manually:

In the Windows registry, go to:
Hkey_Local_Machine\System\CurrentControlSet\Services\Tcpip\Parameters
and set
REG_DWORD: "IPEnableRouter" to "1"
Be aware that IP Forwarding can be a security risk.

If there is a router between your Windows XP system and the internet, you also need to tell the router how to get back to your Neo, so you need to set a route on it for 192.168.0.0/255.255.255.0 to your Windows XP LAN interface IP address. Windows will then forward the packets to the Neo.

=== Further references ===
* http://www.microsoft.com/whdc/device/network/NDIS/rndis.mspx
* http://maemo.org/maemowiki/USBnetworkingWinXP
* http://docwiki.gumstix.org/Setting_up_USBnet
* http://handhelds.org/moin/moin.cgi/WindowsXpUsbNetworkHowTo

[[Category:Documentation]]
[[Category:Guides]]

Flashing the Neo 1973

2007-09-09T01:49:41Z

RodWhitby: Always use the named arguments to -a

This describes how to update your openmoko to the latest software. We'll update the kernel, the root filesystem and optionally u-boot.

{{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 upload a rootfs image that is smaller than the previous one it won't work - you need to attach to bootloader, [[Nand_erase|erase NAND]] and then upload your rootfs first}}

== Files to download ==

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

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/fic-gta01/

*http://chooseopen.com/openmoko/build/ (Unofficial, temporary location of more current 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:<BR>u-boot-gta01bv3-r8_70124c2602ae2d4c5d3dba05b482d91548242de8_0_2040.bin<BR>MD5SUM: 60c5aeba1bd6642b05b3a5e6f2dafe83
** Tested by hrw:<BR>u-boot-gta01bv3-r8_70124c2602ae2d4c5d3dba05b482d91548242de8_0_2062.bin<BR>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.
* Plug Neo1973 into host with supplied USB cable. (Plug the phone directly into the host not via a hub.)

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

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. You'll probably only want to update u-boot on phase0 phones.

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

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

To update u-boot:

<b>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</b>

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

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.

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. 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]].

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 and then upload your rootfs first:

<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 clean rootfs . Unfortunately, old versions of u-boot are not really usable, because they fail to enable the high 64MB of RAM, and you get nasty crashes after kernel boots.

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

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

== 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:OpenMoko| ]]

MokoMakefile

2007-09-03T22:07:22Z

RodWhitby: /* Developing with MokoMakefile */

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

Note that MokoMakefile does *not* replace bitbake, or svn, or monotone, or openembedded, or qmake, or anything else. It is a wrapper around all that to make it easy to set up and maintain a development environment that fully complies with the setup instructions published by OpenMoko. Note that you need about 12 GB of available disk space for MokoMakefile to succeed (see below for a tip on how to reduce this to . Please check that your RAM + swap partition space is greater than 512 MB (around 1GB?). Note that the initial build can take 5 hours (on 2GHz core2duo without multiprocessor optimization) to several days.

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

The MokoMakefile is able to build either OM-2007.1 or OM-2007.2 images. The core team chooses the default, but you can select one or the other at the top of the Makefile.

=== Installation ===

==== With Qemu ====
This is an easy and good way to install a local version of openmoko on your linux computer(ubuntu). This is mostly the fastest way to get things working (approximatly 15 min)

see [[MokoMakefile#QEMU]]

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

1 - Make sure your build host is set up according to:
http://www.openembedded.org/wiki/OEandYourDistro
2 - Create your $OMDIR directory (note that you can change ~/moko to any directory you like):
mkdir ~/moko ; cd ~/moko
3 - Grab MokoMakefile:
wget http://www.rwhitby.net/files/openmoko/Makefile

If that doesn't work, try

wget http://svn.nslu2-linux.org/svnroot/mokomakefile/trunk/Makefile

note: If you want to compile for the old version 2007.1 instead of the new
version edit the top of the Makefile. Edit the lines at the top to
look like this:
OPENMOKO_GENERATION = 2007.1
#OPENMOKO_GENERATION = 2007.2
On kubuntu and Debian Etch I also had to apt-get install help2man

4 - Set up the environment:
make setup
5 - Start building. Before starting a lengthy make process, check in Tips section about how to make Make multicore aware. You may want to modify the build/conf/local.conf file for your target (emulation/chroot) environment:
make openmoko-devel-image

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

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

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

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

2 - To 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

===Reporting Problems===

First, make sure that the problem is reproducible after running

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

then running

make clean-package-<foo>

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

then running

make openmoko-devel-image

If 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].

===Known MokoMakefile errors===

If you experience the following after changing from OM-2007.1 to OM-2007.2:

Patch bitbake-1.6.6-om3.patch does not apply (enforce with -f)

then type "make clobber-patches" to fix it. There was a period of 24 hours when there was a bug in the MokoMakefile which causes this problem. Once the patches have been clobbered, they will re-download and the problem will not reoccur.

===Work-arounds===

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

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

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

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

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

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

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

* 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"

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

====Install in Ubuntu (7.04)====
Make sure your build host is set up according to:
http://www.openembedded.org/wiki/OEandYourDistro
make a new directory:
mkdir openmoko
cd openmoko
install the dependencies:
sudo apt-get install gcc-3.4 lynx netpbm libsdl1.2-dev dosfstools
get the openmokofile:
wget http://www.rwhitby.net/files/openmoko/Makefile
build it for Qemu:
make qemu
This will build openmoko for Qemu. Once that is completed, it will automatic run it into the emulator. After you have closed it and want to run openmoko again, you should use the following command:
make run-qemu

remark: If you want to calibrate your screen,
look at http://onlinedev.blogspot.com/2007/08/calibrating-openmoko-v20072.html

====Others====

Dependencies:

*gcc 3.4 or 3.3 ('apt-get install gcc-3.4' in Ubuntu 7.04)
*lynx ('apt-get install lynx' in Ubuntu 7.04)
*netpbm ('apt-get install netpbm' in Ubuntu 7.04)
*sdl-devel ('apt-get install libsdl1.2-dev' in Ubuntu .704)
*mkdosfs ('apt-get install dosfstools' in Debian 4.0)

“'''make qemu'''” will build qemu-neo1973, download the latest official OpenMoko images, flash the images into the virtual NAND flash, create an empty virtual SD card, and run the emulator (you still need to install the makefile as mentioned above, however). If this is all you want to do, then you don't even need monotone installed on the machine, and you don't need to download the OpenEmbedded monotone database. Just make sure you don't type "make setup" (as that will invoke all the monotone and openembedded stuff).

Other targets are “'''make download-images'''” (to download the latest official images), “'''make flash-qemu-official'''” (to flash those images) and “'''make flash-qemu-local'''” (which will flash your latest locally built images), which can then be followed by “''''make run-qemu'''” or “'''make run-qemu-snapshot'''” to run the emulator with the most recently flashed images. You can also use “''''make qemu-copy-package-''foo'''''” to copy the <code>.ipk</code> file for package ''foo'' to the virtual SD card, and later use “''''ipkg install /media/mmcblk0/''file'''''” from within the emulated Neo1973 to install the package.

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

===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 ../build/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 [http://wiki.openmoko.org/wiki/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!", and "Wow this build system is nice - it just seems more polished than my gumstix toolchain buildroot system".

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

{{Languages|MokoMakefile}}

[[Category:Developer]]
[[Category:Guides]]

MokoMakefile

2007-09-03T22:06:18Z

RodWhitby: /* Reporting Problems */

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

Note that MokoMakefile does *not* replace bitbake, or svn, or monotone, or openembedded, or qmake, or anything else. It is a wrapper around all that to make it easy to set up and maintain a development environment that fully complies with the setup instructions published by OpenMoko. Note that you need about 12 GB of available disk space for MokoMakefile to succeed (see below for a tip on how to reduce this to . Please check that your RAM + swap partition space is greater than 512 MB (around 1GB?). Note that the initial build can take 5 hours (on 2GHz core2duo without multiprocessor optimization) to several days.

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

The MokoMakefile is able to build either OM-2007.1 or OM-2007.2 images. The core team chooses the default, but you can select one or the other at the top of the Makefile.

=== Installation ===

==== With Qemu ====
This is an easy and good way to install a local version of openmoko on your linux computer(ubuntu). This is mostly the fastest way to get things working (approximatly 15 min)

see [[MokoMakefile#QEMU]]

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

1 - Make sure your build host is set up according to:
http://www.openembedded.org/wiki/OEandYourDistro
2 - Create your $OMDIR directory (note that you can change ~/moko to any directory you like):
mkdir ~/moko ; cd ~/moko
3 - Grab MokoMakefile:
wget http://www.rwhitby.net/files/openmoko/Makefile

If that doesn't work, try

wget http://svn.nslu2-linux.org/svnroot/mokomakefile/trunk/Makefile

note: If you want to compile for the old version 2007.1 instead of the new
version edit the top of the Makefile. Edit the lines at the top to
look like this:
OPENMOKO_GENERATION = 2007.1
#OPENMOKO_GENERATION = 2007.2
On kubuntu and Debian Etch I also had to apt-get install help2man

4 - Set up the environment:
make setup
5 - Start building. Before starting a lengthy make process, check in Tips section about how to make Make multicore aware. You may want to modify the build/conf/local.conf file for your target (emulation/chroot) environment:
make openmoko-devel-image

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

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

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

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

2 - To 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

===Reporting Problems===

First, make sure that the problem is reproducible after running

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

then running

make clean-package-<foo>

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

then running

make openmoko-devel-image

If 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].

===Known MokoMakefile errors===

If you experience the following after changing from OM-2007.1 to OM-2007.2:

Patch bitbake-1.6.6-om3.patch does not apply (enforce with -f)

then type "make clobber-patches" to fix it. There was a period of 24 hours when there was a bug in the MokoMakefile which causes this problem. Once the patches have been clobbered, they will re-download and the problem will not reoccur.

===Work-arounds===

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

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

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

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

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

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

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

* 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"

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

====Install in Ubuntu (7.04)====
Make sure your build host is set up according to:
http://www.openembedded.org/wiki/OEandYourDistro
make a new directory:
mkdir openmoko
cd openmoko
install the dependencies:
sudo apt-get install gcc-3.4 lynx netpbm libsdl1.2-dev dosfstools
get the openmokofile:
wget http://www.rwhitby.net/files/openmoko/Makefile
build it for Qemu:
make qemu
This will build openmoko for Qemu. Once that is completed, it will automatic run it into the emulator. After you have closed it and want to run openmoko again, you should use the following command:
make run-qemu

remark: If you want to calibrate your screen,
look at http://onlinedev.blogspot.com/2007/08/calibrating-openmoko-v20072.html

====Others====

Dependencies:

*gcc 3.4 or 3.3 ('apt-get install gcc-3.4' in Ubuntu 7.04)
*lynx ('apt-get install lynx' in Ubuntu 7.04)
*netpbm ('apt-get install netpbm' in Ubuntu 7.04)
*sdl-devel ('apt-get install libsdl1.2-dev' in Ubuntu .704)
*mkdosfs ('apt-get install dosfstools' in Debian 4.0)

“'''make qemu'''” will build qemu-neo1973, download the latest official OpenMoko images, flash the images into the virtual NAND flash, create an empty virtual SD card, and run the emulator (you still need to install the makefile as mentioned above, however). If this is all you want to do, then you don't even need monotone installed on the machine, and you don't need to download the OpenEmbedded monotone database. Just make sure you don't type "make setup" (as that will invoke all the monotone and openembedded stuff).

Other targets are “'''make download-images'''” (to download the latest official images), “'''make flash-qemu-official'''” (to flash those images) and “'''make flash-qemu-local'''” (which will flash your latest locally built images), which can then be followed by “''''make run-qemu'''” or “'''make run-qemu-snapshot'''” to run the emulator with the most recently flashed images. You can also use “''''make qemu-copy-package-''foo'''''” to copy the <code>.ipk</code> file for package ''foo'' to the virtual SD card, and later use “''''ipkg install /media/mmcblk0/''file'''''” from within the emulated Neo1973 to install the package.

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

===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 ../build/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 all

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

=== Hello World application ===

There is a [http://wiki.openmoko.org/wiki/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!", and "Wow this build system is nice - it just seems more polished than my gumstix toolchain buildroot system".

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

{{Languages|MokoMakefile}}

[[Category:Developer]]
[[Category:Guides]]

OpenMoko2007.2

2007-08-25T07:55:03Z

RodWhitby: Using the nslu2-linux MasterMakefile is not a supported way of building OpenMoko, so should not be on the OpenMoko wiki.

'''OM 2007.2''' is the second version of the OpenMoko distribution. Development began on 2007-07-26.

Goals of the new version are an improved set of PIM applications, improved theming that fixes a lot of the usability problems of the 1st generation design, more formalized UI guidelines and a number of changes in the build system. The latter should introduce more recent software by staying closer in sync with upstream org.openembedded.dev.

An official announcement was made by Sean Moss-Pultz on August 20:
* http://lists.openmoko.org/pipermail/announce/2007-August/000018.html

(Initially this was named OM-2008 in SVN but renamed shortly after that.)

==FAQ==

=== Q: What are differences between 2007.1 and 2007.2? ===

* UI redesigned for small and recessed screen
* Simplified visuals for performance
* Simplified UI
* More interactions including finger scrolling
* [[Today|openmoko-today]] rewritten; supports AUX and POWER buttons for navigation
* Updated upstream packages

=== Q: Where to get snapshot images? ===

* [[OpenMoko2007.2#Pre-built_snapshot_images|Unofficial images]] listed at the bottom of this article

* Official snapshots and ipkg repository:
** http://buildhost.openmoko.org/snapshots/2007.08/

=== Q: Where are official releases? ===

No official releases yet, just official snapshots. The first release is targetted for October, 2007.

=== Q: My mrxvt (terminal) fonts are huge. ===

Edit src/feature.h to set MIN_XFT_FONT_SIZE to lower value:
#define MIN_XFT_FONT_SIZE (2)
and rebuild mrxvt & openmoko-devel-image.

End edit /etc/mrxvt/mrxvt.conf
Mrxvt.xftSize: 4
Mrxvt.xftHint: 1

==Building 2007.2==

=== How to build ===

The MokoMakefile is now able to build OM-2007.2 images. If you use this new version of the MokoMakefile, you can ignore everything below and just continue building OM-2007.2 in the same way that you previously built images (i.e. according to http://wiki.openmoko.org/wiki/MokoMakefile). Make sure you set the generation correctly at the top of the file.

Follow the [http://www.openembedded.org/wiki/GettingStarted getting started] steps of OpenEmbedded. It is suggested to use Bitbake 1.8.8 at least.

Put the following in your local.conf

BBFILES = "${HOME}/oe/org.openembedded.dev/packages/*/*.bb"

MACHINE = "fic-gta01"
DISTRO = "openmoko"

ENABLE_BINARY_LOCALE_GENERATION = "1"
GLIBC_GENERATE_LOCALES = "en_GB.UTF-8"

Replace "${HOME}/oe" with the path to where your "org.openembeded.dev" folder lives. For the other entries have a look at ''conf/local.conf.sample'' about their meaning.

Run ''bitbake <package name>'' (e.g. openmoko-devel-image).

=== Build issues ===

==== Wrong certificate ====
You may get something like this while the bitbake recipes are parsed:

Error validating server certificate for 'https://libw100.svn.sf.net:443':
- The certificate hostname does not match.
Certificate information:
- Hostname: *.svn.sourceforge.net
- Valid: from Fri, 27 Oct 2006 12:05:58 GMT until Sun, 28 Oct 2007 13:05:58 GMT
- Issuer: Equifax Secure Certificate Authority, Equifax, US
- Fingerprint: f2:6c:fe:bb:82:92:30:09:72:dd:1c:b3:e7:56:69:c7:7a:df:67:3e

That is an issue in a bitbake file. One should not use the short-name for sourceforge (sf.net) when certificates are only for exact host names. Accept the certificate and everything is fine for now.

==== openmoko-libs FTBFS ====
Some applications have not been fully modified to build with the new libraries of OpenMoko and still need the old-style ''openmoko-libs'' package. ''libmokogsm'' which is needed for ''openmoko-libs'' then fails to build. As a workaround you can remove the not yet ported applications that need ''openmoko-libs'' making it unneccessary itself. To do this edit ''packages/tasks/openmoko-taks.bb'' and find the following lines:

.
.
.
openmoko-terminal \
matchbox-panel-2 \
matchbox-panel-2-applets \
matchbox-applet-inputmanager \
# openmoko-appmanager \
matchbox-keyboard \
matchbox-stroke \
openmoko-keyboard \
.
.
.

Now put a hash (''#'') before ''openmoko-terminal'' and ''openmoko-keyboard''. You can verify that ''openmoko-libs'' is not needed any more by issuing ''bitbake -g openmoko-devel-image'' (= creates a dependency graph). There should be no mentioning of ''openmoko-libs'' in the file ''task-depends.dot''. '''Please note that the graphicall terminal and the virtual keyboard will be missing now.''' You can still have terminal access by following the [[USB Networking]] guide. For keyboard input in Qemu add the ''-usbdevice keyboard'' switch.

==== gtk+ fails building w/ gtkcombobox.c ====

If you get these errors:

gtkcombobox.c: In function 'gtk_combo_box_size_request':
gtkcombobox.c:1859: warning: unused variable 'font_desc'
gtkcombobox.c:1858: warning: unused variable 'metrics'
gtkcombobox.c:1857: warning: unused variable 'context'
gtkcombobox.c:1855: warning: unused variable 'arrow_size'
gtkcombobox.c:1854: warning: unused variable 'font_size'
gtkcombobox.c: In function 'gtk_combo_box_size_allocate':
gtkcombobox.c:1962: error: 'arrow_size' undeclared (first use in this function)
gtkcombobox.c:1962: error: (Each undeclared identifier is reported only once
gtkcombobox.c:1962: error: for each function it appears in.)
gtkcombobox.c:1965: error: 'font_desc' undeclared (first use in this function)
gtkcombobox.c:1966: error: 'context' undeclared (first use in this function)
gtkcombobox.c:1967: error: 'metrics' undeclared (first use in this function)
gtkcombobox.c:1969: error: 'font_size' undeclared (first use in this function)

Go to your /build/tmp/work/fic-gta01-angstrom-linux-gnueabi/gtk+-2.10.14-r3/gtk+-2.10.14/gtk directory, and patch gtkcombobox.c with the following:

Thanks to rmoravcik in #openmoko (patch was taken from http://pastebin.ca/654717 )

--- gtkcombobox.c 2007-08-12 20:30:07.000000000 +0200
+++ gtkcombobox.c 2007-08-12 20:29:58.000000000 +0200
@@ -1948,6 +1948,12 @@
gtk_combo_box_size_allocate (GtkWidget *widget,
GtkAllocation *allocation)
{
+ gint font_size;
+ gint arrow_size;
+ PangoContext *context;
+ PangoFontMetrics *metrics;
+ PangoFontDescription *font_desc;
+
GtkComboBox *combo_box = GTK_COMBO_BOX (widget);
gint focus_width, focus_pad;
GtkAllocation child;

==== Building glibc fails with a segfault in QEMU ====

If your build aborts and you see something like this:

NOTE: package glibc-2.5: started
NOTE: package glibc-2.5-r6: task do_package: started
NOTE: preparing tree for binary locale generation
NOTE: generating locale en_US (UTF-8)
qemu: uncaught target signal 11 (Segmentation fault) - exiting

...

NOTE: Tasks Summary: Attempted 271 tasks of which 0 didn't need to be rerun and 1 failed.
ERROR: '/home/moko/oe/org.openembedded.dev/packages/glibc/glibc_2.5.bb' failed

Try editing your local.conf file. Change:

ENABLE_BINARY_LOCALE_GENERATION = "1"

to

ENABLE_BINARY_LOCALE_GENERATION = "0"

and restart the build. This may have some effect on internationalization (you will see a warning indicating that), but at least the build will continue. Thanks to rwhitby for the tip.

Alternatively, as suggested by XorA in #openmoko, if you are running a 64-bit host distribution, try forcing a different QEMU rev, also in local.conf:

PREFERRED_VERSION_qemu-native = "0.9.0+cvs20070701"
SRCDATE_qemu-native = 20070701

==== libxml2-native fails with xmlCatalogPtr errors ====

Go to your build/tmp/work/i686-linux/libxml2-native-2.6.29-r1/libxml2-2.6.29/include/libxml/ directory and patch xmlversion.h with the following:

--- xmlversion.h 2007-08-17 10:45:42.000000000 +0100
+++ xmlversion.h 2007-08-17 10:51:36.000000000 +0100
@@ -219,7 +219,7 @@
*
* Whether the Catalog support is configured in
*/
-#if 0
+#if 1
#define LIBXML_CATALOG_ENABLED
#endif

On my system the libxml2-native-2.6.29-r1 directory is in a directory named i686-linux, yours may be different. I believe this patch to be a workaround to make libxml2-native build. I am not yet sure what the consequences of enabling XML catalogue support are.

== Pre-built snapshot images ==
* http://ipkg.nslu2-linux.org/feeds/openmoko/images/

* http://buildhost.openmoko.org/OM2007.2/tmp/deploy/glibc/images/fic-gta01/

* http://buildhost.openmoko.org/snapshots/2007.08/ (Official snapshots and ipkg repository)

[[Category:OpenMoko2007.2| ]]

== Updating your image ==

Now that you have a functional 2007.2 image on your Neo, you will want to keep it updated. Fortunately, ipkg is already set up to pull updated packages from the openmoko buildhost.

On the phone, in the terminal (or via ssh), if you have a live internet connection and DNS resolution set up in /etc/resolv.conf:

ipkg update && ipkg upgrade

will bring your installed packages up to the most recent versions.

If you are also building your own images and packages, you can also run a simple httpd on your build host and serve your own ipkg files to the Neo.

On the build host, for example:

thttpd -d <path_to_moko/tmp/deploy/glibc/ipk> -p 8080

will serve your packages on port 8080.

Then, on the neo, make a new file at /etc/ipkg/local-feed.conf with these contents:

src/gz local-all http://192.168.0.200:8080/all
src/gz local-armv4t http://192.168.0.200:8080/armv4t
src/gz local-fic-gta01 http://192.168.0.200:8080/fic-gta01

and ipkg on the Neo (update-upgrade) will pick up files from your local build host's repository (assuming its IP address is 192.168.0.200, as is default in the [[USB Networking]] setup) in addition to the openmoko buildhost.

Also if you are building your own packages or packages from the OE database that aren't part of OpenMoko by default, you can install those packages as follows.

On the build host:

bitbake <name_of_package>
bitbake -c rebuild openmoko-devel-image

Then on the Neo:

ipkg update
ipkg install <name_of_package>

(NB: The local package repository is rebuilt as a consequence of the "rebuild openmoko-devel-image" operation, which also makes another rootfs image. There's probably a way to rebuild the repository without rebuilding the image but I don't know what it is -- please feel free to update.)

OpenMoko2007.2

2007-08-25T07:54:10Z

RodWhitby: /* Flashing with MokoMakefile */

'''OM 2007.2''' is the second version of the OpenMoko distribution. Development began on 2007-07-26.

Goals of the new version are an improved set of PIM applications, improved theming that fixes a lot of the usability problems of the 1st generation design, more formalized UI guidelines and a number of changes in the build system. The latter should introduce more recent software by staying closer in sync with upstream org.openembedded.dev.

An official announcement was made by Sean Moss-Pultz on August 20:
* http://lists.openmoko.org/pipermail/announce/2007-August/000018.html

(Initially this was named OM-2008 in SVN but renamed shortly after that.)

==FAQ==

=== Q: What are differences between 2007.1 and 2007.2? ===

* UI redesigned for small and recessed screen
* Simplified visuals for performance
* Simplified UI
* More interactions including finger scrolling
* [[Today|openmoko-today]] rewritten; supports AUX and POWER buttons for navigation
* Updated upstream packages

=== Q: Where to get snapshot images? ===

* [[OpenMoko2007.2#Pre-built_snapshot_images|Unofficial images]] listed at the bottom of this article

* Official snapshots and ipkg repository:
** http://buildhost.openmoko.org/snapshots/2007.08/

=== Q: Where are official releases? ===

No official releases yet, just official snapshots. The first release is targetted for October, 2007.

=== Q: My mrxvt (terminal) fonts are huge. ===

Edit src/feature.h to set MIN_XFT_FONT_SIZE to lower value:
#define MIN_XFT_FONT_SIZE (2)
and rebuild mrxvt & openmoko-devel-image.

End edit /etc/mrxvt/mrxvt.conf
Mrxvt.xftSize: 4
Mrxvt.xftHint: 1

==Building 2007.2==

=== How to build ===

The MokoMakefile is now able to build OM-2007.2 images. If you use this new version of the MokoMakefile, you can ignore everything below and just continue building OM-2007.2 in the same way that you previously built images (i.e. according to http://wiki.openmoko.org/wiki/MokoMakefile). Make sure you set the generation correctly at the top of the file.

Follow the [http://www.openembedded.org/wiki/GettingStarted getting started] steps of OpenEmbedded. It is suggested to use Bitbake 1.8.8 at least.

Put the following in your local.conf

BBFILES = "${HOME}/oe/org.openembedded.dev/packages/*/*.bb"

MACHINE = "fic-gta01"
DISTRO = "openmoko"

ENABLE_BINARY_LOCALE_GENERATION = "1"
GLIBC_GENERATE_LOCALES = "en_GB.UTF-8"

Replace "${HOME}/oe" with the path to where your "org.openembeded.dev" folder lives. For the other entries have a look at ''conf/local.conf.sample'' about their meaning.

Run ''bitbake <package name>'' (e.g. openmoko-devel-image).

=== Build issues ===

==== Wrong certificate ====
You may get something like this while the bitbake recipes are parsed:

Error validating server certificate for 'https://libw100.svn.sf.net:443':
- The certificate hostname does not match.
Certificate information:
- Hostname: *.svn.sourceforge.net
- Valid: from Fri, 27 Oct 2006 12:05:58 GMT until Sun, 28 Oct 2007 13:05:58 GMT
- Issuer: Equifax Secure Certificate Authority, Equifax, US
- Fingerprint: f2:6c:fe:bb:82:92:30:09:72:dd:1c:b3:e7:56:69:c7:7a:df:67:3e

That is an issue in a bitbake file. One should not use the short-name for sourceforge (sf.net) when certificates are only for exact host names. Accept the certificate and everything is fine for now.

==== openmoko-libs FTBFS ====
Some applications have not been fully modified to build with the new libraries of OpenMoko and still need the old-style ''openmoko-libs'' package. ''libmokogsm'' which is needed for ''openmoko-libs'' then fails to build. As a workaround you can remove the not yet ported applications that need ''openmoko-libs'' making it unneccessary itself. To do this edit ''packages/tasks/openmoko-taks.bb'' and find the following lines:

.
.
.
openmoko-terminal \
matchbox-panel-2 \
matchbox-panel-2-applets \
matchbox-applet-inputmanager \
# openmoko-appmanager \
matchbox-keyboard \
matchbox-stroke \
openmoko-keyboard \
.
.
.

Now put a hash (''#'') before ''openmoko-terminal'' and ''openmoko-keyboard''. You can verify that ''openmoko-libs'' is not needed any more by issuing ''bitbake -g openmoko-devel-image'' (= creates a dependency graph). There should be no mentioning of ''openmoko-libs'' in the file ''task-depends.dot''. '''Please note that the graphicall terminal and the virtual keyboard will be missing now.''' You can still have terminal access by following the [[USB Networking]] guide. For keyboard input in Qemu add the ''-usbdevice keyboard'' switch.

==== gtk+ fails building w/ gtkcombobox.c ====

If you get these errors:

gtkcombobox.c: In function 'gtk_combo_box_size_request':
gtkcombobox.c:1859: warning: unused variable 'font_desc'
gtkcombobox.c:1858: warning: unused variable 'metrics'
gtkcombobox.c:1857: warning: unused variable 'context'
gtkcombobox.c:1855: warning: unused variable 'arrow_size'
gtkcombobox.c:1854: warning: unused variable 'font_size'
gtkcombobox.c: In function 'gtk_combo_box_size_allocate':
gtkcombobox.c:1962: error: 'arrow_size' undeclared (first use in this function)
gtkcombobox.c:1962: error: (Each undeclared identifier is reported only once
gtkcombobox.c:1962: error: for each function it appears in.)
gtkcombobox.c:1965: error: 'font_desc' undeclared (first use in this function)
gtkcombobox.c:1966: error: 'context' undeclared (first use in this function)
gtkcombobox.c:1967: error: 'metrics' undeclared (first use in this function)
gtkcombobox.c:1969: error: 'font_size' undeclared (first use in this function)

Go to your /build/tmp/work/fic-gta01-angstrom-linux-gnueabi/gtk+-2.10.14-r3/gtk+-2.10.14/gtk directory, and patch gtkcombobox.c with the following:

Thanks to rmoravcik in #openmoko (patch was taken from http://pastebin.ca/654717 )

--- gtkcombobox.c 2007-08-12 20:30:07.000000000 +0200
+++ gtkcombobox.c 2007-08-12 20:29:58.000000000 +0200
@@ -1948,6 +1948,12 @@
gtk_combo_box_size_allocate (GtkWidget *widget,
GtkAllocation *allocation)
{
+ gint font_size;
+ gint arrow_size;
+ PangoContext *context;
+ PangoFontMetrics *metrics;
+ PangoFontDescription *font_desc;
+
GtkComboBox *combo_box = GTK_COMBO_BOX (widget);
gint focus_width, focus_pad;
GtkAllocation child;

==== Building glibc fails with a segfault in QEMU ====

If your build aborts and you see something like this:

NOTE: package glibc-2.5: started
NOTE: package glibc-2.5-r6: task do_package: started
NOTE: preparing tree for binary locale generation
NOTE: generating locale en_US (UTF-8)
qemu: uncaught target signal 11 (Segmentation fault) - exiting

...

NOTE: Tasks Summary: Attempted 271 tasks of which 0 didn't need to be rerun and 1 failed.
ERROR: '/home/moko/oe/org.openembedded.dev/packages/glibc/glibc_2.5.bb' failed

Try editing your local.conf file. Change:

ENABLE_BINARY_LOCALE_GENERATION = "1"

to

ENABLE_BINARY_LOCALE_GENERATION = "0"

and restart the build. This may have some effect on internationalization (you will see a warning indicating that), but at least the build will continue. Thanks to rwhitby for the tip.

Alternatively, as suggested by XorA in #openmoko, if you are running a 64-bit host distribution, try forcing a different QEMU rev, also in local.conf:

PREFERRED_VERSION_qemu-native = "0.9.0+cvs20070701"
SRCDATE_qemu-native = 20070701

==== libxml2-native fails with xmlCatalogPtr errors ====

Go to your build/tmp/work/i686-linux/libxml2-native-2.6.29-r1/libxml2-2.6.29/include/libxml/ directory and patch xmlversion.h with the following:

--- xmlversion.h 2007-08-17 10:45:42.000000000 +0100
+++ xmlversion.h 2007-08-17 10:51:36.000000000 +0100
@@ -219,7 +219,7 @@
*
* Whether the Catalog support is configured in
*/
-#if 0
+#if 1
#define LIBXML_CATALOG_ENABLED
#endif

On my system the libxml2-native-2.6.29-r1 directory is in a directory named i686-linux, yours may be different. I believe this patch to be a workaround to make libxml2-native build. I am not yet sure what the consequences of enabling XML catalogue support are.

=== How to build using nslu2-linux MasterMakefile (Ubuntu 7.04) ===

'''Note that the normal [[MokoMakefile]] can build OM-2007.2 now, so there is no need to use the procedure below. The nslu2-linux master makefile is designed for building various OE distributions, and is likely to produce something different from the standard OpenMoko images.
'''

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

Note: on http://www.openembedded.org/wiki/OEandYourDistro are better instructions for Ubuntu to make sh be bash.

Create your $OMDIR directory (note that you can change ~/OM-2007.2 to any directory you like):
mkdir ~/OM-2007.2 ; cd ~/OM-2007.2

Grab the nslu2-linux [http://www.nslu2-linux.org/wiki/Development/MasterMakefile MasterMakefile]:
wget http://www.nslu2-linux.org/Makefile

This will make sure you'll have all the required packages:
sudo apt-get install \
autoconf automake automake1.9 \
bison \
ccache cogito \
cvs \
diffstat \
docbook \
flex \
gcc g++ gawk gcj gettext git-core \
help2man \
libc6-dev libglib2.0-dev libtool libxext-dev\
m4 make \
patch pkg-config \
python python-dev python2.4 python2.4-dev python-psyco \
sed \
sharutils \
texinfo texi2html \
unzip \
subversion \
sysutils \
texinfo \
bzip2

Ubuntu 7.04 comes with monotone 0.31. You could just go with that and do a mtn db migrate but this takes hours so the easier way would be to download a suitable mtn db from http://www.openembedded.org/snapshots/ and use this.
mkdir -p monotone
wget http://www.openembedded.org/snapshots/\
OE-this-is-for-mtn-<your mtn version>.mtn.bz2 -O monotone/nslu2-linux.mtn.bz2
bunzip2 monotone/nslu2-linux.mtn.bz2

If you're using MokoMakefile for building OM2007.1 you probably have fresh OE.mtn for version 0.31 already downloaded. So you can just make symlink to the OE.mtn in your OM2007.1 build directory.

(current directory(pwd) is /path/to/OM2007.2)
ln -s /path/to/OM2007.1/OE.mtn monotone/nslu2-linux.mtn

To save even more bandwith you can also use already donwloaded source files from OM2007.1. Just make a symlink to OM2007.1 sources directory. Something like this.

(current directory(pwd) is /path/to/OM2007.2)
ln -s /path/to/OM2007.1/sources downloads

Go build ;)
make openmoko-devel-image

* If you an encounter an error with monotone similar to the following:

mtn: misuse: database monotone/nslu2-linux.mtn is laid out according to an old schema

Then you need to upgrade nslu2-linux.mtn Use the following command:

# mtn --db monotone/nslu2-linux.mtn db migrate

== Pre-built snapshot images ==
* http://ipkg.nslu2-linux.org/feeds/openmoko/images/

* http://buildhost.openmoko.org/OM2007.2/tmp/deploy/glibc/images/fic-gta01/

* http://buildhost.openmoko.org/snapshots/2007.08/ (Official snapshots and ipkg repository)

[[Category:OpenMoko2007.2| ]]

== Updating your image ==

Now that you have a functional 2007.2 image on your Neo, you will want to keep it updated. Fortunately, ipkg is already set up to pull updated packages from the openmoko buildhost.

On the phone, in the terminal (or via ssh), if you have a live internet connection and DNS resolution set up in /etc/resolv.conf:

ipkg update && ipkg upgrade

will bring your installed packages up to the most recent versions.

If you are also building your own images and packages, you can also run a simple httpd on your build host and serve your own ipkg files to the Neo.

On the build host, for example:

thttpd -d <path_to_moko/tmp/deploy/glibc/ipk> -p 8080

will serve your packages on port 8080.

Then, on the neo, make a new file at /etc/ipkg/local-feed.conf with these contents:

src/gz local-all http://192.168.0.200:8080/all
src/gz local-armv4t http://192.168.0.200:8080/armv4t
src/gz local-fic-gta01 http://192.168.0.200:8080/fic-gta01

and ipkg on the Neo (update-upgrade) will pick up files from your local build host's repository (assuming its IP address is 192.168.0.200, as is default in the [[USB Networking]] setup) in addition to the openmoko buildhost.

Also if you are building your own packages or packages from the OE database that aren't part of OpenMoko by default, you can install those packages as follows.

On the build host:

bitbake <name_of_package>
bitbake -c rebuild openmoko-devel-image

Then on the Neo:

ipkg update
ipkg install <name_of_package>

(NB: The local package repository is rebuilt as a consequence of the "rebuild openmoko-devel-image" operation, which also makes another rootfs image. There's probably a way to rebuild the repository without rebuilding the image but I don't know what it is -- please feel free to update.)

OpenMoko2007.2

2007-08-25T07:54:00Z

RodWhitby: flashing with openmoko works for 2007.2

'''OM 2007.2''' is the second version of the OpenMoko distribution. Development began on 2007-07-26.

Goals of the new version are an improved set of PIM applications, improved theming that fixes a lot of the usability problems of the 1st generation design, more formalized UI guidelines and a number of changes in the build system. The latter should introduce more recent software by staying closer in sync with upstream org.openembedded.dev.

An official announcement was made by Sean Moss-Pultz on August 20:
* http://lists.openmoko.org/pipermail/announce/2007-August/000018.html

(Initially this was named OM-2008 in SVN but renamed shortly after that.)

==FAQ==

=== Q: What are differences between 2007.1 and 2007.2? ===

* UI redesigned for small and recessed screen
* Simplified visuals for performance
* Simplified UI
* More interactions including finger scrolling
* [[Today|openmoko-today]] rewritten; supports AUX and POWER buttons for navigation
* Updated upstream packages

=== Q: Where to get snapshot images? ===

* [[OpenMoko2007.2#Pre-built_snapshot_images|Unofficial images]] listed at the bottom of this article

* Official snapshots and ipkg repository:
** http://buildhost.openmoko.org/snapshots/2007.08/

=== Q: Where are official releases? ===

No official releases yet, just official snapshots. The first release is targetted for October, 2007.

=== Q: My mrxvt (terminal) fonts are huge. ===

Edit src/feature.h to set MIN_XFT_FONT_SIZE to lower value:
#define MIN_XFT_FONT_SIZE (2)
and rebuild mrxvt & openmoko-devel-image.

End edit /etc/mrxvt/mrxvt.conf
Mrxvt.xftSize: 4
Mrxvt.xftHint: 1

==Building 2007.2==

=== How to build ===

The MokoMakefile is now able to build OM-2007.2 images. If you use this new version of the MokoMakefile, you can ignore everything below and just continue building OM-2007.2 in the same way that you previously built images (i.e. according to http://wiki.openmoko.org/wiki/MokoMakefile). Make sure you set the generation correctly at the top of the file.

Follow the [http://www.openembedded.org/wiki/GettingStarted getting started] steps of OpenEmbedded. It is suggested to use Bitbake 1.8.8 at least.

Put the following in your local.conf

BBFILES = "${HOME}/oe/org.openembedded.dev/packages/*/*.bb"

MACHINE = "fic-gta01"
DISTRO = "openmoko"

ENABLE_BINARY_LOCALE_GENERATION = "1"
GLIBC_GENERATE_LOCALES = "en_GB.UTF-8"

Replace "${HOME}/oe" with the path to where your "org.openembeded.dev" folder lives. For the other entries have a look at ''conf/local.conf.sample'' about their meaning.

Run ''bitbake <package name>'' (e.g. openmoko-devel-image).

=== Build issues ===

==== Wrong certificate ====
You may get something like this while the bitbake recipes are parsed:

Error validating server certificate for 'https://libw100.svn.sf.net:443':
- The certificate hostname does not match.
Certificate information:
- Hostname: *.svn.sourceforge.net
- Valid: from Fri, 27 Oct 2006 12:05:58 GMT until Sun, 28 Oct 2007 13:05:58 GMT
- Issuer: Equifax Secure Certificate Authority, Equifax, US
- Fingerprint: f2:6c:fe:bb:82:92:30:09:72:dd:1c:b3:e7:56:69:c7:7a:df:67:3e

That is an issue in a bitbake file. One should not use the short-name for sourceforge (sf.net) when certificates are only for exact host names. Accept the certificate and everything is fine for now.

==== openmoko-libs FTBFS ====
Some applications have not been fully modified to build with the new libraries of OpenMoko and still need the old-style ''openmoko-libs'' package. ''libmokogsm'' which is needed for ''openmoko-libs'' then fails to build. As a workaround you can remove the not yet ported applications that need ''openmoko-libs'' making it unneccessary itself. To do this edit ''packages/tasks/openmoko-taks.bb'' and find the following lines:

.
.
.
openmoko-terminal \
matchbox-panel-2 \
matchbox-panel-2-applets \
matchbox-applet-inputmanager \
# openmoko-appmanager \
matchbox-keyboard \
matchbox-stroke \
openmoko-keyboard \
.
.
.

Now put a hash (''#'') before ''openmoko-terminal'' and ''openmoko-keyboard''. You can verify that ''openmoko-libs'' is not needed any more by issuing ''bitbake -g openmoko-devel-image'' (= creates a dependency graph). There should be no mentioning of ''openmoko-libs'' in the file ''task-depends.dot''. '''Please note that the graphicall terminal and the virtual keyboard will be missing now.''' You can still have terminal access by following the [[USB Networking]] guide. For keyboard input in Qemu add the ''-usbdevice keyboard'' switch.

==== gtk+ fails building w/ gtkcombobox.c ====

If you get these errors:

gtkcombobox.c: In function 'gtk_combo_box_size_request':
gtkcombobox.c:1859: warning: unused variable 'font_desc'
gtkcombobox.c:1858: warning: unused variable 'metrics'
gtkcombobox.c:1857: warning: unused variable 'context'
gtkcombobox.c:1855: warning: unused variable 'arrow_size'
gtkcombobox.c:1854: warning: unused variable 'font_size'
gtkcombobox.c: In function 'gtk_combo_box_size_allocate':
gtkcombobox.c:1962: error: 'arrow_size' undeclared (first use in this function)
gtkcombobox.c:1962: error: (Each undeclared identifier is reported only once
gtkcombobox.c:1962: error: for each function it appears in.)
gtkcombobox.c:1965: error: 'font_desc' undeclared (first use in this function)
gtkcombobox.c:1966: error: 'context' undeclared (first use in this function)
gtkcombobox.c:1967: error: 'metrics' undeclared (first use in this function)
gtkcombobox.c:1969: error: 'font_size' undeclared (first use in this function)

Go to your /build/tmp/work/fic-gta01-angstrom-linux-gnueabi/gtk+-2.10.14-r3/gtk+-2.10.14/gtk directory, and patch gtkcombobox.c with the following:

Thanks to rmoravcik in #openmoko (patch was taken from http://pastebin.ca/654717 )

--- gtkcombobox.c 2007-08-12 20:30:07.000000000 +0200
+++ gtkcombobox.c 2007-08-12 20:29:58.000000000 +0200
@@ -1948,6 +1948,12 @@
gtk_combo_box_size_allocate (GtkWidget *widget,
GtkAllocation *allocation)
{
+ gint font_size;
+ gint arrow_size;
+ PangoContext *context;
+ PangoFontMetrics *metrics;
+ PangoFontDescription *font_desc;
+
GtkComboBox *combo_box = GTK_COMBO_BOX (widget);
gint focus_width, focus_pad;
GtkAllocation child;

==== Building glibc fails with a segfault in QEMU ====

If your build aborts and you see something like this:

NOTE: package glibc-2.5: started
NOTE: package glibc-2.5-r6: task do_package: started
NOTE: preparing tree for binary locale generation
NOTE: generating locale en_US (UTF-8)
qemu: uncaught target signal 11 (Segmentation fault) - exiting

...

NOTE: Tasks Summary: Attempted 271 tasks of which 0 didn't need to be rerun and 1 failed.
ERROR: '/home/moko/oe/org.openembedded.dev/packages/glibc/glibc_2.5.bb' failed

Try editing your local.conf file. Change:

ENABLE_BINARY_LOCALE_GENERATION = "1"

to

ENABLE_BINARY_LOCALE_GENERATION = "0"

and restart the build. This may have some effect on internationalization (you will see a warning indicating that), but at least the build will continue. Thanks to rwhitby for the tip.

Alternatively, as suggested by XorA in #openmoko, if you are running a 64-bit host distribution, try forcing a different QEMU rev, also in local.conf:

PREFERRED_VERSION_qemu-native = "0.9.0+cvs20070701"
SRCDATE_qemu-native = 20070701

==== libxml2-native fails with xmlCatalogPtr errors ====

Go to your build/tmp/work/i686-linux/libxml2-native-2.6.29-r1/libxml2-2.6.29/include/libxml/ directory and patch xmlversion.h with the following:

--- xmlversion.h 2007-08-17 10:45:42.000000000 +0100
+++ xmlversion.h 2007-08-17 10:51:36.000000000 +0100
@@ -219,7 +219,7 @@
*
* Whether the Catalog support is configured in
*/
-#if 0
+#if 1
#define LIBXML_CATALOG_ENABLED
#endif

On my system the libxml2-native-2.6.29-r1 directory is in a directory named i686-linux, yours may be different. I believe this patch to be a workaround to make libxml2-native build. I am not yet sure what the consequences of enabling XML catalogue support are.

=== How to build using nslu2-linux MasterMakefile (Ubuntu 7.04) ===

'''Note that the normal [[MokoMakefile]] can build OM-2007.2 now, so there is no need to use the procedure below. The nslu2-linux master makefile is designed for building various OE distributions, and is likely to produce something different from the standard OpenMoko images.
'''

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

Note: on http://www.openembedded.org/wiki/OEandYourDistro are better instructions for Ubuntu to make sh be bash.

Create your $OMDIR directory (note that you can change ~/OM-2007.2 to any directory you like):
mkdir ~/OM-2007.2 ; cd ~/OM-2007.2

Grab the nslu2-linux [http://www.nslu2-linux.org/wiki/Development/MasterMakefile MasterMakefile]:
wget http://www.nslu2-linux.org/Makefile

This will make sure you'll have all the required packages:
sudo apt-get install \
autoconf automake automake1.9 \
bison \
ccache cogito \
cvs \
diffstat \
docbook \
flex \
gcc g++ gawk gcj gettext git-core \
help2man \
libc6-dev libglib2.0-dev libtool libxext-dev\
m4 make \
patch pkg-config \
python python-dev python2.4 python2.4-dev python-psyco \
sed \
sharutils \
texinfo texi2html \
unzip \
subversion \
sysutils \
texinfo \
bzip2

Ubuntu 7.04 comes with monotone 0.31. You could just go with that and do a mtn db migrate but this takes hours so the easier way would be to download a suitable mtn db from http://www.openembedded.org/snapshots/ and use this.
mkdir -p monotone
wget http://www.openembedded.org/snapshots/\
OE-this-is-for-mtn-<your mtn version>.mtn.bz2 -O monotone/nslu2-linux.mtn.bz2
bunzip2 monotone/nslu2-linux.mtn.bz2

If you're using MokoMakefile for building OM2007.1 you probably have fresh OE.mtn for version 0.31 already downloaded. So you can just make symlink to the OE.mtn in your OM2007.1 build directory.

(current directory(pwd) is /path/to/OM2007.2)
ln -s /path/to/OM2007.1/OE.mtn monotone/nslu2-linux.mtn

To save even more bandwith you can also use already donwloaded source files from OM2007.1. Just make a symlink to OM2007.1 sources directory. Something like this.

(current directory(pwd) is /path/to/OM2007.2)
ln -s /path/to/OM2007.1/sources downloads

Go build ;)
make openmoko-devel-image

* If you an encounter an error with monotone similar to the following:

mtn: misuse: database monotone/nslu2-linux.mtn is laid out according to an old schema

Then you need to upgrade nslu2-linux.mtn Use the following command:

# mtn --db monotone/nslu2-linux.mtn db migrate

== Flashing with MokoMakefile ==
Since MokoMakefile has not been adjusted to use the new build layout you cannot use it. As a quick hack to make flashing local built image possible again try this:

Find the following lines in the MokoMakefile:

flash-qemu-local: stamps/qemu stamps/openmoko-devel-image
( cd build/qemu && openmoko/flash.sh ../tmp/deploy/images )

And replace them with:

flash-qemu-local: stamps/qemu
( cd build/qemu && openmoko/flash.sh <MY_NEW_BUILD_DIR>/tmp/deploy/glibc/images/fic-gta01 )

Where you should replace <MY_NEW_BUILD_DIR> with the full path to your build directory (the one where ''conf/local.conf'' lives in). Running the image should work, too. :-)

With this changes kernel and uboot image are picked up correctly. However the name of the root filesystem image has changed in OM-2007.2 and the current scripts will not pick it up any more. Just edit ''$OM_DIR/build/qemu/openmoko/env'' and change the line saying:

rootfs_wildcard="openmoko-*.rootfs.jffs2"

to

rootfs_wildcard="OpenMoko-*.rootfs.jffs2"

Now it will work correctly again.

== Pre-built snapshot images ==
* http://ipkg.nslu2-linux.org/feeds/openmoko/images/

* http://buildhost.openmoko.org/OM2007.2/tmp/deploy/glibc/images/fic-gta01/

* http://buildhost.openmoko.org/snapshots/2007.08/ (Official snapshots and ipkg repository)

[[Category:OpenMoko2007.2| ]]

== Updating your image ==

Now that you have a functional 2007.2 image on your Neo, you will want to keep it updated. Fortunately, ipkg is already set up to pull updated packages from the openmoko buildhost.

On the phone, in the terminal (or via ssh), if you have a live internet connection and DNS resolution set up in /etc/resolv.conf:

ipkg update && ipkg upgrade

will bring your installed packages up to the most recent versions.

If you are also building your own images and packages, you can also run a simple httpd on your build host and serve your own ipkg files to the Neo.

On the build host, for example:

thttpd -d <path_to_moko/tmp/deploy/glibc/ipk> -p 8080

will serve your packages on port 8080.

Then, on the neo, make a new file at /etc/ipkg/local-feed.conf with these contents:

src/gz local-all http://192.168.0.200:8080/all
src/gz local-armv4t http://192.168.0.200:8080/armv4t
src/gz local-fic-gta01 http://192.168.0.200:8080/fic-gta01

and ipkg on the Neo (update-upgrade) will pick up files from your local build host's repository (assuming its IP address is 192.168.0.200, as is default in the [[USB Networking]] setup) in addition to the openmoko buildhost.

Also if you are building your own packages or packages from the OE database that aren't part of OpenMoko by default, you can install those packages as follows.

On the build host:

bitbake <name_of_package>
bitbake -c rebuild openmoko-devel-image

Then on the Neo:

ipkg update
ipkg install <name_of_package>

(NB: The local package repository is rebuilt as a consequence of the "rebuild openmoko-devel-image" operation, which also makes another rootfs image. There's probably a way to rebuild the repository without rebuilding the image but I don't know what it is -- please feel free to update.)

Openmoko Local Groups: Adelaide

2007-08-22T14:39:27Z

RodWhitby:

Welcome to the Adelaide Neo1973 interest group.

{|border=1
!Name
!Skills
!Level of Interest
!Location
!Has Device
!Has Debug Board
|-
|[[User:RodWhitby|RodWhitby]]
|Linux, Kernel, Embedded Devices
|User and developer
|Adelaide
| [[Image: Moko.jpg|center]]
| [[Image: MokoBox.jpg|center]]
|-
|
|
|
|
|
|
|}

I would suggest we meet at the monthly [http://www.linuxsa.org.au/meetings/ LinuxSA] meetings.

[[Category:Community]]

MokoMakefile

2007-08-21T08:20:04Z

RodWhitby: /* QEMU */

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

Note that MokoMakefile does *not* replace bitbake, or svn, or monotone, or openembedded, or qmake, or anything else. It is a wrapper around all that to make it easy to set up and maintain a development environment that fully complies with the setup instructions published by OpenMoko. Note that you need about 12 GB of available disk space for MokoMakefile to succeed (see below for a tip on how to reduce this to . Please check that your RAM + swap partition space is greater than 512 MB (around 1GB?).

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

The MokoMakefile is able to build either OM-2007.1 or OM-2007.2 images. The core team chooses the default, but you can select one or the other at the top of the Makefile.

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

1 - Make sure your build host is set up according to:
http://www.openembedded.org/wiki/OEandYourDistro
2 - Create your $OMDIR directory (note that you can change ~/moko to any directory you like):
mkdir ~/moko ; cd ~/moko
3 - Grab MokoMakefile:
wget http://www.rwhitby.net/files/openmoko/Makefile

If that doesn't work, try

wget http://svn.nslu2-linux.org/svnroot/mokomakefile/trunk/Makefile

note: If you want to compile for 2007.2 instead of the old version edit
the top of the Makefile. Edit the lines at the top to look like this.
#OPENMOKO_GENERATION = 2007.1
OPENMOKO_GENERATION = 2007.2
On kubuntu and Debian Etch I also had to apt-get install help2man

4 - Set up the environment:
make setup
5 - Start building. Before starting a lengthy make process, check in Tips section about how to make Make multicore aware. You may want to modify the build/conf/local.conf file for your target (emulation/chroot) environment:
make openmoko-devel-image

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

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

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

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

2 - To 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

===Reporting Problems===

First, make sure that the problem is reproducible after running

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

then running

make clean-package-<foo>

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

then running

make all

If you can get the error to occur three times in a row after running that sequence of commands (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].

===Known MokoMakefile errors===

If you experience the following after changing from OM-2007.1 to OM-2007.2:

Patch bitbake-1.6.6-om3.patch does not apply (enforce with -f)

then type "make clobber-patches" to fix it. There was a period of 24 hours when there was a bug in the MokoMakefile which causes this problem. Once the patches have been clobbered, they will re-download and the problem will not reoccur.

===Work-arounds===

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

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

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

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

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

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

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

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

Dependencies:

*gcc 3.4 or 3.3 ('apt-get install gcc-3.4' in Ubuntu 7.04)
*lynx ('apt-get install lynx' in Ubuntu 7.04)
*netpbm ('apt-get install netpbm' in Ubuntu 7.04)
*sdl-devel ('apt-get install libsdl1.2-dev' in Ubuntu .704)
*mkdosfs ('apt-get install dosfstools' in Debian 4.0)

“'''make qemu'''” will build qemu-neo1973, download the latest official OpenMoko images, flash the images into the virtual NAND flash, create an empty virtual SD card, and run the emulator (you still need to install the makefile as mentioned above, however). If this is all you want to do, then you don't even need monotone installed on the machine, and you don't need to download the OpenEmbedded monotone database. Just make sure you don't type "make setup" (as that will invoke all the monotone and openembedded stuff).

Other targets are “'''make download-images'''” (to download the latest official images), “'''make flash-qemu-official'''” (to flash those images) and “'''make flash-qemu-local'''” (which will flash your latest locally built images), which can then be followed by “''''make run-qemu'''” or “'''make run-qemu-snapshot'''” to run the emulator with the most recently flashed images. You can also use “''''make qemu-copy-package-''foo'''''” to copy the <code>.ipk</code> file for package ''foo'' to the virtual SD card, and later use “''''ipkg install /media/mmcblk0/''file'''''” from within the emulated Neo1973 to install the package.

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

===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 ../build/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 all

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

=== Hello World application ===

There is a [http://wiki.openmoko.org/wiki/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!", and "Wow this build system is nice - it just seems more polished than my gumstix toolchain buildroot system".

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

{{Languages|MokoMakefile}}

[[Category:Developer]]
[[Category:Guides]]

OpenMoko under QEMU

2007-08-21T08:18:13Z

RodWhitby: /* Using MokoMakefile */

QEMU can basically be used in three ways to run [[OpenMoko]]. Depending on the purpose that you are going to use the emulator for, you should decide on the target platform.

*''PC'' - OpenMoko can be built to run on regular i386 hardware, 32- or 64-bit and this is probably the fastest way to get OpenMoko running if you want to get an impression of how it looks. In this scenario QEMU would only serve for isolating your [[OpenMoko]] installation from your normal system, or, if you're not on a UNIX system, QEMU provides a non-intrusive way to get Linux up quickly. More information can be found in the [[FAQ]] and [[Getting Openmoko working on host with Xoo|here]].

*''Integrator/CP'' - this is the default ARM-based machine that QEMU knows about. This target is used with MACHINE="qemuarm" and it is sufficient to run the original OpenMoko rootfs image, although it doesn't emulate any of the [[:Category:Neo1973 Hardware | Neo1973 Hardware]] except the very CPU core. Read more in the [[FAQ#Q:_Is_there_an_emulator_available_for_OpenMoko.3F|FAQ]].

*''Neo1973'' - the QEMU tree available from OpenMoko repositories is also capable of emulating most of the actual [[Neo1973]] hardware, although not all of it at this moment. It is a work-in-progress and when it's more mature it is going to be submitted for merging to the main QEMU development tree.

== Neo1973 emulation ==

This target will (obviously) run original OpenMoko rootfs images, but then it should also be able to run the original u-boot and kernel images, the same ones that a real Neo1973 uses. Among other differences you will notice between this approach and the Integrator/CP target is you also get correct screen resolution, some (fake) battery readings, and other goodness. Currently missing parts of the emulator are: [[Hardware:AGPS|AGPS]] and [[Bluetooth]] - these things will still be worked on, as well as general usability. Even with these things missing, QEMU should provide substantial help in debugging kernel and u-boot issues to developers.

What QEMU can '''*not*''' be used for, and probably no other emulator can, is speed measures and getting the general feel of OpenMoko performance. Code running in qemu runs with the maximum speed your host computer can provide with an overhead of translating target code to host code, and this overhead is not uniform across different instructions. This means that even if your virtual Neo reports near 100 BogoMIPS (which is the speed of a real Neo), different actions performed in the emulator will not run with the same speed. On most PCs you will notice the virtual Neo running faster than a real one (Audio related operations may be one of the exceptions).

=== What hardware is supported ===

Rough status for each of the components that need emulation, following the outline of [[:Category:Neo1973 Hardware | Neo1973 Hardware]] page.
{|
! Hardware !! Status !! Usage notes
|- style="background-color:#eeeedd;"
! colspan="3"|S3C2410A Processor
|-
|ARM920T core || Works || Already in mainline QEMU.
|-
|Basic guts || Work || This includes GPIO interface, DMA, Interrupt Controller, Timers, NAND controller, MMC/SD host, [[I2C]] and IIS interfaces, Memory & Clock & Power management controllers, RAM.
|-
|Serial ports || Works || Use the "-serial" switch (maybe be specified multiple times) to tell QEMU where serial input/output should go to. GSM module will be connected on UART0.
|-
|RTC || Works || On start QEMU will load it with current time/date - the Neo1973 [[kernel]] doesn't use it for time/date source currently.
|-
|SPI || Works || The guest kernel can drive it using either the SPI interface or raw GPIO bitbanging.
|-
|LCD || Works || The virtual LCD will display as in QEMU window iff "-nographic" is not specified.
|-
|ADC || Works || Mouse events in QEMU window generate what would be touchscreen events on a Neo1973 and are passed to the guest OS through the on-chip ADC.
|-
|OHCI USB || Works || This part is in mainline QEMU. Use the "-usb" switch to enable the controller and "usb_add" in QEMU monitor to attach new virtual or physical USB devices.
|-
|Slave USB || Works || Linux's dummy HCD in conjunction with gadget filesystem API is used to make the virtual Neo appear as a real one connected to the host computer. See [[#Setting up USB connection|Setting up USB connection]] below. (Experimental)
|-
|Watchdog || Works || This is one of the less important on-chip peripherals in S3C2410. It is however used by Linux for rebooting the board.
|- style="background-color:#eeeedd;"
! colspan="3"|[[I2C]] bus peripherals
|-
|[[PCF50606]] || Works || (Aka PMU) Fakes the battery charge level (set at 88%), POWER button, etc. Also contains an RTC, also unused by Linux.
|-
|[[LM4857]] || Works
|-
|[[WM8753L]] || Works || The CODEC is also connect to the CPU's IIS port. Basic [[Neo1973 Audio Subsystem|audio functionality]] is supported - see QEMU documentation on getting audio input/output from the emulator. Volume control has no effects.
|- style="background-color:#eeeedd;"
! colspan="3"|Other peripherals
|-
|NAND Flash || Works || However, some pieces are not confirmed to be completely compatible with the real hardware because of lack thereof. Use "-mtdblock flashimagefilenamehere" switch to point QEMU to your flash image. The file should be at least 69206016 bytes big.
|-
|JBT6K74-AS(PI) || Works || (Aka LCM) Wired to the SPI channel 1
|-
|Buttons || Work || Enter is the AUX button, Space is the POWER button. Wired to on-chip GPIO and PCF50606.
|-
|SD card || Works || This part is already in mainline QEMU. Use the "-sd cardimagegoeshere" switch to point QEMU to the card image. The regular QEMU monitor commands for removable media can also be used. The card works, however the on-chip host controller gave block length errors on heavy I/O despite working as described in specification. I suspect the kernel driver. DMA operation is not tested.
|-
|Bluetooth
|style="background-color:#ffffcc;"|Works
|A generic Bluetooth HCI (just like the BlueCore4 chip) is connected to internal USB hub (just like the Delta DBFM dongle). Currently qemu emulates no other bluetooth devices, so the dongle behaves as if there was no BT-enabled slaves around, being the only device on the piconet, i.e. is not really useful. Likely a Bluetooth keyboard will be emulated. A physical Bluetooth dongle can also be attached to the emulator (see USB documentation in QEMU).
|-
|[[GSM]] || Works || A fake modem is connected to UART0 understanding a (currently quite limited) subset of AT commands. Ultimately it should support as much functionality as possible (basic AT command set, fake GPRS connections, dialing and SMS send/receive). This way all parts of the phone subsystem (CALYPSO, TWL3014, TRF6151) will not have to be emulated. There is a possibility to wire a real GSM modem to QEMU's serial port.
|-
|[[Hardware:AGPS|AGPS]]
|style="background-color:#ffcccc;"|To Do
|There are obvious difficulties emulating the chip, but hopefully it can be made to present the guest OS with some fixed coordinates later when more is known about the chip. Again a real chip could be connected to QEMU's serial port.
|}

Current development is aiming for [[:Category:Neo1973_Hardware#GTA01Bv4 | GTA01Bv4]] compatibility; [[:Category:Neo1973_Hardware#GTA01Bv3 | earlier revisions]] can also be emulated if needed. The differences between the hardware revisions currently only manifest themselves in GPIO wiring. Hardware emulation is implemented in a clean-room manner using official specifications where possible.

== How to get it running ==

=== Using MokoMakefile ===

This is the easiest way of building qemu-neo1973 since you won't need to deal with the compiling and flashing processes yourself. See [[MokoMakefile#QEMU|MokoMakefile]] for details.

If you *just* build QEMU and use the official images by typing "make qemu" only (as opposed to setting up monotone and openembedded and building an entire new image for yourself with MokoMakefile), then the build time takes less time as the manual instructions below (since it's all done automatically).

=== Manual setup ===

To obtain the latest source code for the emulator, you will want to do something like the following:
<pre>
$ svn checkout https://svn.openmoko.org/trunk/src/host/qemu-neo1973
$ cd qemu-neo1973
</pre>
Now, we're going to configure and build the emulator (Note [[#Requirements|Requirements]] below):
<pre>
$ ./configure --target-list=arm-softmmu # GCC 3.x will be required, see --cc=
$ make
</pre>
See other available options for the configure script by appending "--help".
Now you should have a working emulator under the name "arm-softmmu/qemu-system-arm". To run OpenMoko you will also need to somehow install OpenMoko on your virtual phone, which is totally clean of any software at this moment. There are several block devices to choose from, the best option is probably to do exactly what the Neo1973 manufacturer does before it ships the device to the final user. This process is described in [[Bootloader]], [[Kernel]], [[NAND bad blocks]] and [[Devirginator]] but you don't need to know all the details. Two scripts are provided to generate a firmware for your phone, as realistic as possible. First make sure you have lynx installed, then run
<pre>$ openmoko/download.sh</pre>
which will look up the list of latest available OpenMoko snapshot builds from buildhost.openmoko.org and choose the most recent [[u-boot]], Kernel, and root filesystem images, and download the images (unless they are already found in the openmoko/ directory). These binaries will be used by the flash.sh script. First make sure you have the netpbm package installed for some graphics conversion utilities. On Ubuntu this can be done by:
<pre>sudo apt-get install netpbm</pre>
Then run:
<pre>$ openmoko/flash.sh</pre>
which runs the emulator, loads u-boot into it and then uses u-boot's capability to program the Flash memory to install all the necessary parts of the system into the virtual Flash. It will also set up all the bootloading process including a boot menu (ENTER is [AUX] and SPACE is [POWER]), splash, u-boot environment and some default kernel parameters. If everything goes OK, the script should print a command which you can use to start using the emulator.

QEMU has '''*tons*''' of commandline switches and things that can be configured. You can look them up in [http://www.qemu.org/user-doc.html QEMU user docs]. You will probably want to use the "-snapshot" switch, among other ones. Saving and restoring emulation state at any point (unrelated to "-snapshot") should work as per QEMU user docs too. In addition the monitor commands "help" and "info" are of great help. The monitor usually sits in second virtual console, thus ctrl-alt-2 and ctrl-alt-1 switch to monitor and back.

=== Pre-built binaries ===

Win32 binaries shipped with firmware can be downloaded from [http://mdk.linux.org.tw/~jserv/openmoko/openmoko-emulator-win32-bin-20070625.zip openmoko-emulator-win32-bin-20070625.zip]. Tested on MS Windows XP and Vista Business.

== Requirements ==

This QEMU tree has only been tested on GNU/Linux. To get graphical (not counting VNC) and/or audio output from the emulator you will need either SDL or Cocoa installed on your computer. To enable audio, see the available switches to the ./configure script.

The scripts that sit in openmoko/ require lynx, wget, python, netpbm and most GNU base utilities installed in standard locations. The netpbm package contains tools necessary for bootsplash image conversion.

All of the build-time and run-time requirements listed in [http://www.qemu.org/user-doc.html QEMU documentation] apply. This includes zlib, etc. On distributions that use binary packages, remember that you need the packages ending in '''-dev''' or '''-devel'''.

== QEMU and GNU debugger ==

QEMU lets you debug operating system kernels and bootloaders like you debug all other programs. To do this you will need a debugger that speaks the GDB remote debugging protocol - [http://sourceware.org/gdb/ GDB] is the obvious choice. Some cross toolchains come with GDB already set up. Otherwise building cross-GDB yourself is quick and easy (compared to building binutils and cross-gcc).

To debug u-boot, load the file "u-boot" into gdb (not "u-boot.bin") that is produced by "make" when building u-boot. To debug a Linux kernel, load the file "vmlinux" from the main source directory into gdb. These files are in ELF format and contain all the symbol information and are not stripped of debugging data until you run "strip" on them, unlike "u-boot.bin" and "Image"/"zImage"/"uImage". Next, tell QEMU to enable the gdbserver by appending the "-s" switch or issuing "gdbserver" in the monitor. Use the command <pre>(gdb) target remote localhost:1234</pre> to make a connection to the emulator. From there you should be able to use all the usual GDB commands, including stepping instructions, setting breakpoints, watchpoints, inspecting stack, variables, registers and more. If gdb is running in the same directory from which it grabbed the ELF executable, the "edit" command should work so you can jump right to the source line which is executing.

== Setting up USB connection ==

It is possible (although not very straight forward, probably about the complexity of tun-tap networking) to connect the virtual, emulated Neo1973 to the Linux PC on which the emulator is running, and work with it as if a real Neo1973 was plugged into the computer's USB port, but no twiddling with cables is needed. If you're testing your applications on the Neo, it may be worth setting up this kind of connection because it lets you enable normal [[USB_Networking|networking between the PC and the phone and ssh into it]] (which is much more comfortable than typing commands into the OpenMoko's terminal emulator via on-screen keyboard). Here's what you will need in order to get this working:

A Linux host with a 2.6 series kernel. The following drivers compiled-in or in modules: dummy_hcd, gadgetfs, usbnet, cdc_ether. [[Building Gadget USB Module|A detailed guide to building the necessary modules is available (primarily Ubuntu focused).]] Generic instructions follow.

Note that you need root access to perform most actions described here. Here's how to enable the drivers in menuconfig.

Find and enable '''Device Drivers''' -> '''USB support''' -> '''USB Gadget Support''' -> '''Support for USB Gadgets'''

Find '''Device Drivers''' -> '''USB support''' -> '''USB Gadget Support''' -> '''USB Peripheral Controller''' and set it to '''Dummy HCD (DEVELOPMENT)'''

Find and enable '''Device Drivers''' -> '''USB support''' -> '''USB Gadget Support''' -> '''Gadget Filesystem (EXPERIMENTAL)''' (this one is good to have as a module)

Find and enable '''Device Drivers''' -> '''USB support''' -> '''USB Network Adapters''' -> '''Multi-purpose USB Networking Framework'''

Find and enable '''Device Drivers''' -> '''USB support''' -> '''USB Network Adapters''' -> '''Multi-purpose USB Networking Framework''' -> '''CDC Ethernet support (smart devices such as cable modems)'''

These last two drivers are the same [[Getting Started with your Neo1973#By using Ethernet emulation over a USB cable|drivers that you need to work with a real Neo over USB network]]. After you've built the drivers, make sure that the copy of kernel headers in /usr/include/linux is up to date. In particular the file /usr/include/linux/usb_gadgetfs.h needs to be present and if your distribution came with headers older than 2.6.18 or so, then you need tell the package manager to update them, or you can do that manually with
<pre> # cp -a /usr/src/linux/include/linux/* /usr/include/linux/</pre>
(assuming that your kernel sources are in /usr/src/linux). It is important that this is done before building qemu because the build system checks if these headers are functional and in case they aren't found it will disable the USB Slave functionality. Run "grep CONFIG_GADGETFS config-host.h" in qemu source directory to make sure that the detection succeeded.

After building qemu and before running it, make sure that the modules are loaded into the kernel. I found it useful to load gadgetfs with the following command:
<pre> # modprobe gadgetfs default_uid=1000 # assuming my User ID is 1000</pre>
and added the following line to my /etc/fstab:
<pre>gadget /dev/gadget gadgetfs noauto,user,group 0 0</pre>
Make sure that the mountpoint /dev/gadget exists:
<pre> # mkdir -p /dev/gadget</pre>
After that the rest of the procedure can be performed from your regular user account. Mounting gadgetfs is done with:
<pre> $ mount /dev/gadget</pre>
The "default_uid" parameter changes the ownership on all files under /dev/gadget to your own and since the files there are created and destroyed dynamically, there's no easy way to have that performed by ''udev''. Now running qemu as you usually do but appending "-usb -usbgadget" (in the current version of the [[MokoMakefile]] this is not included) should enable the USB Slave functionality. The qemu monitor commands "info usbslave" and "usb_add gadget" will be useful. The former instruction asks the OS running under the emulator (OpenMoko) to describe its slave features (that's what ''lsusb'' does after a Neo1973 is connected to a PC). You can see the available USB configurations in this command's output. Since gadgetfs allows only one configuration, we will need to choose the desired configuration - most device have only one such configuration, in which case you can use just "usb_add gadget" to connect to host; CDC ethernet devices however usually include a second configuration for RNDIS networking (i.e. Ms Windows compatibility) and so does OpenMoko when using the g_ether driver. Hence, to get this right, wait for OpenMoko to fully boot up and execute the following in QEMU monitor:
<pre>
QEMU 0.9.0 monitor - type 'help' for more information
(qemu) info usbslave
USB2.2 device 1457:5122:
Manufacturer: Linux 2.6.20.7-moko8/s3c2410_udc
Product: RNDIS/Ethernet Gadget
Configuration 0: RNDIS
Configuration 1: CDC Ethernet
(qemu)
(qemu) usb_add gadget:1
</pre>
If qemu gives "couldn't add device gadget:1", double-check that it was built against gadgetfs - the file config-host.h must contain the line "#define CONFIG_GADGETFS 1".

The "1" in "usb_add gadget:N" is the number of the USB configuration that we want to use. If everything went correctly - you can check that in dmesg - you should now have a new network interface called ''usb0'' on the PC, through which you can talk to the OpenMoko running in QEMU:
<pre>
$ dmesg | tail
<6>gadgetfs: bound to dummy_udc driver
<7>hub 3-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x101
<6>usb 3-1: new high speed USB device using dummy_hcd and address 3
<6>gadgetfs: connected
<7>usb 3-1: default language 0x0409
<7>usb 3-1: new device strings: Mfr=1, Product=2, SerialNumber=0
<6>usb 3-1: Product: RNDIS/Ethernet Gadget
<6>usb 3-1: Manufacturer: Linux 2.6.20.7-moko8/s3c2410_udc
<6>usb 3-1: configuration #1 chosen from 1 choice
<7>usb 3-1: adding 3-1:1.0 (config #1, interface 0)
<7>usb 3-1:1.0: uevent
<7>cdc_ether 3-1:1.0: usb_probe_interface - got id
<7>cdc_ether 3-1:1.0: status ep3in, 16 bytes period 14
<7>usb 3-1: adding 3-1:1.1 (config #1, interface 1)
<7>usb 3-1:1.1: uevent
$ su -
Password:
# tail /var/log/everything/current
May 8 19:25:32 [kernel] gadgetfs: connected
May 8 19:25:32 [kernel] gadgetfs: disconnected
May 8 19:25:32 [kernel] gadgetfs: configuration #1
May 8 19:25:32 [kernel] usb0: register 'cdc_ether' at usb-dummy_hcd-1, CDC Ethernet Device, 52:e7:eb:76:0a:d0
# lsusb -vvv
Bus 003 Device 003: ID 1457:5122
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1457
idProduct 0x5122
bcdDevice 2.12
iManufacturer 1 Linux 2.6.20.7-moko8/s3c2410_udc
iProduct 2 RNDIS/Ethernet Gadget
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 80
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 7 CDC Ethernet
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 6 Ethernet Networking
bInterfaceProtocol 0
iInterface 5 CDC Communications Control
CDC Header:
bcdCDC 1.10
CDC Union:
bMasterInterface 0
bSlaveInterface 1
CDC Ethernet:
iMacAddress 3 52E7EB760AD0
bmEthernetStatistics 0x00000000
wMaxSegmentSize 1514
wNumberMCFilters 0x0000
bNumberPowerFilters 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 14
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 10 Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 2
bInterfaceClass 10 Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 4 Ethernet Data
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1

# ifconfig usb0 inet 192.168.0.200 netmask 255.255.255.0
# exit
$ ssh root@192.168.0.202
The authenticity of host '192.168.0.202 (192.168.0.202)' can't be established.
RSA key fingerprint is de:21:87:93:52:1c:6b:c7:69:29:6c:af:66:50:02:02.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.0.202' (RSA) to the list of known hosts.
root@192.168.0.202's password:
root@fic-gta01:~$ uname -a
Linux fic-gta01 2.6.20.7-moko8 #1 PREEMPT Wed Apr 25 11:13:52 UTC 2007 armv4tl unknown
</pre>

== Connecting to the serial port/Communicating with u-boot ==
If you add the option ''-serial telnet:localhost:1200,server'' to QEMU will create a telnet server on port 1200 that you can connect to as the serial port.<br>
This will allow you to experiment with u-boot configuration without risking to brick the real device.<br>
<br>
Please note that QEMU will wait for you to connect to the telnet server at port 1200 before starting the emulation.<br>
(use the command ''telnet localhost 1200'' to establish the connection)

== See also ==
*[[Building Gadget USB Module]] - Helpful guide
*[[Xephyr]] - OpenMoko on i386
*[[Xoo]] - OpenMoko on i386

{{Languages|OpenMoko_under_QEMU}}

[[Category:Developer software]]

[[Category:Guides]]

MokoMakefile

2007-08-21T00:32:42Z

RodWhitby: /* Known MokoMakefile errors */

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

Note that MokoMakefile does *not* replace bitbake, or svn, or monotone, or openembedded, or qmake, or anything else. It is a wrapper around all that to make it easy to set up and maintain a development environment that fully complies with the setup instructions published by OpenMoko. Note that you need about 12 GB of available disk space for MokoMakefile to succeed (see below for a tip on how to reduce this to . Please check that your RAM + swap partition space is greater than 512 MB (around 1GB?).

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

The MokoMakefile is able to build either OM-2007.1 or OM-2007.2 images. The core team chooses the default, but you can select one or the other at the top of the Makefile.

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

1 - Make sure your build host is set up according to:
http://www.openembedded.org/wiki/OEandYourDistro
2 - Create your $OMDIR directory (note that you can change ~/moko to any directory you like):
mkdir ~/moko ; cd ~/moko
3 - Grab MokoMakefile:
wget http://www.rwhitby.net/files/openmoko/Makefile

If that doesn't work, try

wget http://svn.nslu2-linux.org/svnroot/mokomakefile/trunk/Makefile

note: If you want to compile for 2007.2 instead of the old version edit
the top of the Makefile. Edit the lines at the top to look like this.
#OPENMOKO_GENERATION = 2007.1
OPENMOKO_GENERATION = 2007.2
On kubuntu and Debian Etch I also had to apt-get install help2man

4 - Set up the environment:
make setup
5 - Start building. Before starting a lengthy make process, check in Tips section about how to make Make multicore aware. You may want to modify the build/conf/local.conf file for your target (emulation/chroot) environment:
make openmoko-devel-image

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

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

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

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

2 - To 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

===Reporting Problems===

First, make sure that the problem is reproducible after running

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

then running

make clean-package-<foo>

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

then running

make all

If you can get the error to occur three times in a row after running that sequence of commands (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].

===Known MokoMakefile errors===

If you experience the following after changing from OM-2007.1 to OM-2007.2:

Patch bitbake-1.6.6-om3.patch does not apply (enforce with -f)

then type "make clobber-patches" to fix it. There was a period of 24 hours when there was a bug in the MokoMakefile which causes this problem. Once the patches have been clobbered, they will re-download and the problem will not reoccur.

===Work-arounds===

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

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

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

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

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

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

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

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

Dependencies:

*gcc 3.4 or 3.3 ('apt-get install gcc-3.4' in Ubuntu 7.04)
*lynx ('apt-get install lynx' in Ubuntu 7.04)
*netpbm ('apt-get install netpbm' in Ubuntu 7.04)
*sdl-devel ('apt-get install libsdl1.2-dev' in Ubuntu .704)
*mkdosfs ('apt-get install dosfstools' in Debian 4.0)

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

Other targets are “'''make download-images'''” (to download the latest official images), “'''make flash-qemu-official'''” (to flash those images) and “'''make flash-qemu-local'''” (which will flash your latest locally built images), which can then be followed by “''''make run-qemu'''” or “'''make run-qemu-snapshot'''” to run the emulator with the most recently flashed images. You can also use “''''make qemu-copy-package-''foo'''''” to copy the <code>.ipk</code> file for package ''foo'' to the virtual SD card, and later use “''''ipkg install /media/mmcblk0/''file'''''” from within the emulated Neo1973 to install the package.

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

===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 ../build/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 all

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

=== Hello World application ===

There is a [http://wiki.openmoko.org/wiki/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!", and "Wow this build system is nice - it just seems more polished than my gumstix toolchain buildroot system".

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

{{Languages|MokoMakefile}}

[[Category:Developer]]
[[Category:Guides]]

MokoMakefile

2007-08-21T00:32:21Z

RodWhitby: /* Work-arounds */

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

Note that MokoMakefile does *not* replace bitbake, or svn, or monotone, or openembedded, or qmake, or anything else. It is a wrapper around all that to make it easy to set up and maintain a development environment that fully complies with the setup instructions published by OpenMoko. Note that you need about 12 GB of available disk space for MokoMakefile to succeed (see below for a tip on how to reduce this to . Please check that your RAM + swap partition space is greater than 512 MB (around 1GB?).

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

The MokoMakefile is able to build either OM-2007.1 or OM-2007.2 images. The core team chooses the default, but you can select one or the other at the top of the Makefile.

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

1 - Make sure your build host is set up according to:
http://www.openembedded.org/wiki/OEandYourDistro
2 - Create your $OMDIR directory (note that you can change ~/moko to any directory you like):
mkdir ~/moko ; cd ~/moko
3 - Grab MokoMakefile:
wget http://www.rwhitby.net/files/openmoko/Makefile

If that doesn't work, try

wget http://svn.nslu2-linux.org/svnroot/mokomakefile/trunk/Makefile

note: If you want to compile for 2007.2 instead of the old version edit
the top of the Makefile. Edit the lines at the top to look like this.
#OPENMOKO_GENERATION = 2007.1
OPENMOKO_GENERATION = 2007.2
On kubuntu and Debian Etch I also had to apt-get install help2man

4 - Set up the environment:
make setup
5 - Start building. Before starting a lengthy make process, check in Tips section about how to make Make multicore aware. You may want to modify the build/conf/local.conf file for your target (emulation/chroot) environment:
make openmoko-devel-image

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

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

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

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

2 - To 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

===Reporting Problems===

First, make sure that the problem is reproducible after running

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

then running

make clean-package-<foo>

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

then running

make all

If you can get the error to occur three times in a row after running that sequence of commands (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].

===Known MokoMakefile errors===

If you experience the following after changing from OM-2007.1 to OM-2007.2:

Patch bitbake-1.6.6-om3.patch does not apply (enforce with -f)

then type "make clobber-patches" to fix it. There was a period of 24 hours when there was a bug in the MokoMakefile which causes this problem. Once the patches have been clobbered, they will re-download and the problem will not reoccur.

===Work-arounds===

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

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

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

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

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

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

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

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

Dependencies:

*gcc 3.4 or 3.3 ('apt-get install gcc-3.4' in Ubuntu 7.04)
*lynx ('apt-get install lynx' in Ubuntu 7.04)
*netpbm ('apt-get install netpbm' in Ubuntu 7.04)
*sdl-devel ('apt-get install libsdl1.2-dev' in Ubuntu .704)
*mkdosfs ('apt-get install dosfstools' in Debian 4.0)

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

Other targets are “'''make download-images'''” (to download the latest official images), “'''make flash-qemu-official'''” (to flash those images) and “'''make flash-qemu-local'''” (which will flash your latest locally built images), which can then be followed by “''''make run-qemu'''” or “'''make run-qemu-snapshot'''” to run the emulator with the most recently flashed images. You can also use “''''make qemu-copy-package-''foo'''''” to copy the <code>.ipk</code> file for package ''foo'' to the virtual SD card, and later use “''''ipkg install /media/mmcblk0/''file'''''” from within the emulated Neo1973 to install the package.

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

===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 ../build/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 all

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

=== Hello World application ===

There is a [http://wiki.openmoko.org/wiki/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!", and "Wow this build system is nice - it just seems more polished than my gumstix toolchain buildroot system".

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

{{Languages|MokoMakefile}}

[[Category:Developer]]
[[Category:Guides]]

OpenMoko2007.2

2007-08-19T08:25:53Z

RodWhitby: /* How to build using nslu2-linux MasterMakefile (Ubuntu 7.04) */

== FAQ ==
=== What is 2007.2? ===

As of 2007-07-26 the development of the next version of the OpenMoko distribution has begun.

Goals of the new version are an improved set of PIM applications, improved theming that fixes a lot of the usability problems of the 1st generation design, more formalized UI guidelines and a number of changes in the build system. The latter should introduce more recent software by staying closer in sync with upstream org.openembedded.dev.

An official announcement is expected soon (Aug 19).

(Initially this was named OM-2008 in SVN but renamed shortly after that.)

=== What are differences between 2007.1 and 2007.2? ===

=== Where to get images? ===

[[OpenMoko2007.2#Pre-built_snapshot_images|Unofficial images]]

=== Where are official images? ===

No official images yet.

=== My mrxvt (terminal) fonts are huge. ===

Edit src/feature.h to set MIN_XFT_FONT_SIZE to lower value:
#define MIN_XFT_FONT_SIZE (2)
and rebuild mrxvt & openmoko-devel-image.

End edit /etc/mrxvt/mrxvt.conf
Mrxvt.xftSize: 4
Mrxvt.xftHint: 1

== How to build ==

The MokoMakefile is now able to build OM-2007.2 images. If you use this new version of the MokoMakefile, you can ignore everything below and just continue building OM-2007.2 in the same way that you previously built images (i.e. according to http://wiki.openmoko.org/wiki/MokoMakefile). Make sure you set the generation correctly at the top of the file.

'''Please note that this is no official guide on how to build OM-2007.2. I am just making my first steps getting this to compile and think it would be a [http://en.wikipedia.org/wiki/Proprietary_software waste of time] of I keep problems I found for my own. Additionally it would be good if the new distro gets more exposure and testing so less things will break after the official announcement.'''

Follow the [http://www.openembedded.org/wiki/GettingStarted getting started] steps of OpenEmbedded. Use Bitbake 1.8.6 not a SVN version from the stable branch (otherwise you will get problems with checking out repositories) and the ''org.openembedded.dev'' branch of OE.

Put the following in your local.conf

BBFILES = "${HOME}/oe/org.openembedded.dev/packages/*/*.bb"

MACHINE = "fic-gta01"
DISTRO = "openmoko"

ENABLE_BINARY_LOCALE_GENERATION = "1"
GLIBC_GENERATE_LOCALES = "en_GB.UTF-8"

Replace "${HOME}/oe" with the path to where your "org.openembeded.dev" folder lives. For the other entries have a look at ''conf/local.conf.sample'' about their meaning.

Run ''bitbake <package name>'' (e.g. openmoko-devel-image).

Hopefully the MokoMakeFile is soon upgraded to be used for OM-2007.2. Since OpenMoko is not using the overlay any more that makefile should be simpler then. :-)

=== Build issues ===

==== Wrong certificate ====
You may get something like this while the bitbake recipes are parsed:

Error validating server certificate for 'https://libw100.svn.sf.net:443':
- The certificate hostname does not match.
Certificate information:
- Hostname: *.svn.sourceforge.net
- Valid: from Fri, 27 Oct 2006 12:05:58 GMT until Sun, 28 Oct 2007 13:05:58 GMT
- Issuer: Equifax Secure Certificate Authority, Equifax, US
- Fingerprint: f2:6c:fe:bb:82:92:30:09:72:dd:1c:b3:e7:56:69:c7:7a:df:67:3e

That is an issue in a bitbake file. One should not use the short-name for sourceforge (sf.net) when certificates are only for exact host names. Accept the certificate and everything is fine for now.

==== openmoko-libs FTBFS ====
Some applications have not been fully modified to build with the new libraries of OpenMoko and still need the old-style ''openmoko-libs'' package. ''libmokogsm'' which is needed for ''openmoko-libs'' then fails to build. As a workaround you can remove the not yet ported applications that need ''openmoko-libs'' making it unneccessary itself. To do this edit ''packages/tasks/openmoko-taks.bb'' and find the following lines:

.
.
.
openmoko-terminal \
matchbox-panel-2 \
matchbox-panel-2-applets \
matchbox-applet-inputmanager \
# openmoko-appmanager \
matchbox-keyboard \
matchbox-stroke \
openmoko-keyboard \
.
.
.

Now put a hash (''#'') before ''openmoko-terminal'' and ''openmoko-keyboard''. You can verify that ''openmoko-libs'' is not needed any more by issuing ''bitbake -g openmoko-devel-image'' (= creates a dependency graph). There should be no mentioning of ''openmoko-libs'' in the file ''task-depends.dot''. '''Please note that the graphicall terminal and the virtual keyboard will be missing now.''' You can still have terminal access by following the [[USB Networking]] guide. For keyboard input in Qemu add the ''-usbdevice keyboard'' switch.

==== gtk+ fails building w/ gtkcombobox.c ====

If you get these errors:

gtkcombobox.c: In function 'gtk_combo_box_size_request':
gtkcombobox.c:1859: warning: unused variable 'font_desc'
gtkcombobox.c:1858: warning: unused variable 'metrics'
gtkcombobox.c:1857: warning: unused variable 'context'
gtkcombobox.c:1855: warning: unused variable 'arrow_size'
gtkcombobox.c:1854: warning: unused variable 'font_size'
gtkcombobox.c: In function 'gtk_combo_box_size_allocate':
gtkcombobox.c:1962: error: 'arrow_size' undeclared (first use in this function)
gtkcombobox.c:1962: error: (Each undeclared identifier is reported only once
gtkcombobox.c:1962: error: for each function it appears in.)
gtkcombobox.c:1965: error: 'font_desc' undeclared (first use in this function)
gtkcombobox.c:1966: error: 'context' undeclared (first use in this function)
gtkcombobox.c:1967: error: 'metrics' undeclared (first use in this function)
gtkcombobox.c:1969: error: 'font_size' undeclared (first use in this function)

Go to your /build/tmp/work/fic-gta01-angstrom-linux-gnueabi/gtk+-2.10.14-r3/gtk+-2.10.14/gtk directory, and patch gtkcombobox.c with the following:

Thanks to rmoravcik in #openmoko (patch was taken from http://pastebin.ca/654717 )

--- gtkcombobox.c 2007-08-12 20:30:07.000000000 +0200
+++ gtkcombobox.c 2007-08-12 20:29:58.000000000 +0200
@@ -1948,6 +1948,12 @@
gtk_combo_box_size_allocate (GtkWidget *widget,
GtkAllocation *allocation)
{
+ gint font_size;
+ gint arrow_size;
+ PangoContext *context;
+ PangoFontMetrics *metrics;
+ PangoFontDescription *font_desc;
+
GtkComboBox *combo_box = GTK_COMBO_BOX (widget);
gint focus_width, focus_pad;
GtkAllocation child;

==== Building glibc fails with a segfault in QEMU ====

If your build aborts and you see something like this:

NOTE: package glibc-2.5: started
NOTE: package glibc-2.5-r6: task do_package: started
NOTE: preparing tree for binary locale generation
NOTE: generating locale en_US (UTF-8)
qemu: uncaught target signal 11 (Segmentation fault) - exiting

...

NOTE: Tasks Summary: Attempted 271 tasks of which 0 didn't need to be rerun and 1 failed.
ERROR: '/home/moko/oe/org.openembedded.dev/packages/glibc/glibc_2.5.bb' failed

Try editing your local.conf file. Change:

ENABLE_BINARY_LOCALE_GENERATION = "1"

to

ENABLE_BINARY_LOCALE_GENERATION = "0"

and restart the build. This may have some effect on internationalization (you will see a warning indicating that), but at least the build will continue. Thanks to rwhitby for the tip.

Alternatively, as suggested by XorA in #openmoko, if you are running a 64-bit host distribution, try forcing a different QEMU rev, also in local.conf:

PREFERRED_VERSION_qemu-native = "0.9.0+cvs20070701"
SRCDATE_qemu-native = 20070701

==== libxml2-native fails with xmlCatalogPtr errors ====

Go to your build/tmp/work/i686-linux/libxml2-native-2.6.29-r1/libxml2-2.6.29/include/libxml/ directory and patch xmlversion.h with the following:

--- xmlversion.h 2007-08-17 10:45:42.000000000 +0100
+++ xmlversion.h 2007-08-17 10:51:36.000000000 +0100
@@ -219,7 +219,7 @@
*
* Whether the Catalog support is configured in
*/
-#if 0
+#if 1
#define LIBXML_CATALOG_ENABLED
#endif

On my system the libxml2-native-2.6.29-r1 directory is in a directory named i686-linux, yours may be different. I believe this patch to be a workaround to make libxml2-native build. I am not yet sure what the consequences of enabling XML catalogue support are.

=== Flashing with MokoMakefile ===
Since MokoMakefile has not been adjusted to use the new build layout you cannot use it. As a quick hack to make flashing local built image possible again try this:

Find the following lines in the MokoMakefile:

flash-qemu-local: stamps/qemu stamps/openmoko-devel-image
( cd build/qemu && openmoko/flash.sh ../tmp/deploy/images )

And replace them with:

flash-qemu-local: stamps/qemu
( cd build/qemu && openmoko/flash.sh <MY_NEW_BUILD_DIR>/tmp/deploy/glibc/images/fic-gta01 )

Where you should replace <MY_NEW_BUILD_DIR> with the full path to your build directory (the one where ''conf/local.conf'' lives in). Running the image should work, too. :-)

With this changes kernel and uboot image are picked up correctly. However the name of the root filesystem image has changed in OM-2007.2 and the current scripts will not pick it up any more. Just edit ''$OM_DIR/build/qemu/openmoko/env'' and change the line saying:

rootfs_wildcard="openmoko-*.rootfs.jffs2"

to

rootfs_wildcard="OpenMoko-*.rootfs.jffs2"

Now it will work correctly again.

== How to build using nslu2-linux MasterMakefile (Ubuntu 7.04) ==

Note that the normal MokoMakefile can build OM-2007.2 now, so there is no need to use the procedure below. The nslu2-linux master makefile is designed for building various OE distributions, and is likely to produce something different from the standard OpenMoko images.

[disclaimer]

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

Note: on http://www.openembedded.org/wiki/OEandYourDistro are better instructions for Ubuntu to make sh be bash.

Create your $OMDIR directory (note that you can change ~/OM-2007.2 to any directory you like):
mkdir ~/OM-2007.2 ; cd ~/OM-2007.2

Grab the nslu2-linux [http://www.nslu2-linux.org/wiki/Development/MasterMakefile MasterMakefile]:
wget http://www.nslu2-linux.org/Makefile

This will make sure you'll have all the required packages:
sudo apt-get install \
autoconf automake automake1.9 \
bison \
ccache cogito \
cvs \
diffstat \
docbook \
flex \
gcc g++ gawk gcj gettext git-core \
help2man \
libc6-dev libglib2.0-dev libtool libxext-dev\
m4 make \
patch pkg-config \
python python-dev python2.4 python2.4-dev python-psyco \
sed \
sharutils \
texinfo texi2html \
unzip \
subversion \
sysutils \
texinfo \
bzip2

Ubuntu 7.04 comes with monotone 0.31. You could just go with that and do a mtn db migrate but this takes hours so the easier way would be to download a suitable mtn db from http://www.openembedded.org/snapshots/ and use this.
mkdir -p monotone
wget http://www.openembedded.org/snapshots/\
OE-this-is-for-mtn-<your mtn version>.mtn.bz2 -O monotone/nslu2-linux.mtn.bz2
bunzip2 monotone/nslu2-linux.mtn.bz2

If you're using MokoMakefile for building OM2007.1 you probably have fresh OE.mtn for version 0.31 already downloaded. So you can just make symlink to the OE.mtn in your OM2007.1 build directory.

(current directory(pwd) is /path/to/OM2007.2)
ln -s /path/to/OM2007.1/OE.mtn monotone/nslu2-linux.mtn

To save even more bandwith you can also use already donwloaded source files from OM2007.1. Just make a symlink to OM2007.1 sources directory. Something like this.

(current directory(pwd) is /path/to/OM2007.2)
ln -s /path/to/OM2007.1/sources downloads

Go build ;)
make openmoko-image

* If you an encounter an error with monotone similar to the following:

mtn: misuse: database monotone/nslu2-linux.mtn is laid out according to an old schema

Then you need to upgrade nslu2-linux.mtn Use the following command:

# mtn --db monotone/nslu2-linux.mtn db migrate

== Pre-built snapshot images ==
http://ipkg.nslu2-linux.org/feeds/openmoko/images/

http://people.openmoko.org/mickey/images/ (Confirmed working)



[[Category:OpenMoko2007.2| ]]

Talk:MokoMakefile

2007-08-19T08:21:36Z

RodWhitby: The need for texi2html is on the OEAndYourDistro page.

== Fails trying to fetch uboot ==
on ubuntu edgy (with all the required sofware installed):

<pre>
( cd build ; . ../setup-env ; \
bitbake openmoko-devel-image )
NOTE: Using cache in '/content/build/tmp/cache/fic-gta01'
NOTE: Handling BitBake files: \ (4333/4333) [100 %]
NOTE: Parsing finished. 4149 cached, 0 parsed, 184 skipped, 0 masked.

NOTE: build 200704240008: started

OE Build Configuration:
BB_VERSION = "1.6.7"
OE_REVISION = "<unknown>"
TARGET_ARCH = "arm"
TARGET_OS = "linux"
MACHINE = "fic-gta01"
DISTRO = "openmoko"
DISTRO_VERSION = ".dev-snapshot-20070423"
TARGET_FPU = "soft"

NOTE: preferred version 2.4 of glibc not available
NOTE: preferred version 2.4 of glibc-intermediate not available
NOTE: preferred version 2.4 of glibc not available
NOTE: Retrieved remote revisions: ['0', '1754', '0']
NOTE: Retrieved remote revisions: ['14da5f7675bbb427c469e3f45006e027b6e21db9', '0', '1811']
NOTE: package uboot-gta01-1.2.0+svnnow: started
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
Fetch failure: git://www.denx.de/git/u-boot.git/
NOTE: Task failed: Fetch failed: Git: export PATH=/content/build/tmp/staging/i686-linux/bin/arm-linux:/content/build/tmp/staging/i686-linux/bin:/content/build/tmp/cross/bin:/content/bitbake/bin:/home/philip/work/trac/install/0.10-stable/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games; git pull git://www.denx.de/git/u-boot.git/ failed
NOTE: package uboot-gta01-1.2.0+svnnow-r4_14da5f7675bbb427c469e3f45006e027b6e21db9_0_1811: task do_fetch: failed
ERROR: TaskFailed event exception, aborting
NOTE: package uboot-gta01-1.2.0+svnnow: failed
ERROR: Build of openmoko-devel-image failed
make: *** [openmoko-devel-image] Fout 1

</pre>

To fix this, upgrade git to 1.5.x. (1.4.x currently installed.)

== Fails trying to download a TTF fonts. Workaround Below ==

Trying to build with the latest MokoMakefile fails with the following output:

<pre>...
NOTE: fetch http://downloads.openmoko.org/sources/dejavu-ttf-2.15.tar.bz2
--10:32:52-- http://downloads.openmoko.org/sources/dejavu-ttf-2.15.tar.bz2
=> `/home/nat/moko/sources/dejavu-ttf-2.15.tar.bz2'
Resolving downloads.openmoko.org... 88.198.93.219
Connecting to downloads.openmoko.org|88.198.93.219|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
10:32:52 ERROR 404: Not Found.

NOTE: Task failed: Fetch failed: http://heanet.dl.sf.net/dejavu/dejavu-ttf-2.15.tar.bz2
NOTE: package ttf-dejavu-2.15-r0: task do_fetch: failed
ERROR: TaskFailed event exception, aborting
NOTE: package ttf-dejavu-2.15: failed
ERROR: Build of openmoko-devel-image failed
make: *** [openmoko-devel-image] Error 1
</pre>

To work around this problem, download from here http://dejavu.sourceforge.net/wiki/index.php/Download and save into the sources/ subdirectory beneath where you are running make. Then create a file named dejavu-ttf-2.15.tar.bz2.md5 alongside the tar.bz2 file that contains the MD5 checksum on that download page. Then issue the make command again and the build will pick up where it left off.

== do_compile fails with unreconized option '-Qy' ==

I use bash for my shell and this seems to be caused by something in my .bashrc For now, I have just commented out my .bashrc for my builds. It has something to do with the PATH variable. Try using

PATH=/bin:/usr/bin:/usr/local/bin make openmoko-devel-image"

to get around it.

== (NOT FIXED) Fails on a 32bit machine ==

<pre>| make[5]: Entering directory `/usr/local/oe/build/tmp/work/armv4t-linux/binutil
s-cross-2.17-r0/binutils-2.17/build.x86_64-linux.arm-linux/bfd'
| /bin/sh ./libtool --mode=compile ccache gcc -DHAVE_CONFIG_H -I. -I/usr/local/
oe/build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17/bfd -I. -I.
-I/usr/local/oe/build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17
/bfd -I/usr/local/oe/build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils
-2.17/bfd/../include -I/usr/local/oe/build/tmp/work/armv4t-linux/binutils-cross
-2.17-r0/binutils-2.17/bfd/../intl -I../intl -isystem/usr/local/oe/build/tmp/st
aging/x86_64-linux/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -We
rror -isystem/usr/local/oe/build/tmp/staging/x86_64-linux/include -O2 -c -o libb
fd.lo /usr/local/oe/build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-
2.17/bfd/libbfd.c
| ccache gcc -DHAVE_CONFIG_H -I. -I/usr/local/oe/build/tmp/work/armv4t-linux/bin
utils-cross-2.17-r0/binutils-2.17/bfd -I. -I. -I/usr/local/oe/build/tmp/work/arm
v4t-linux/binutils-cross-2.17-r0/binutils-2.17/bfd -I/usr/local/oe/build/tmp/wor
k/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17/bfd/../include -I/usr/local/
oe/build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17/bfd/../intl
-I../intl -isystem/usr/local/oe/build/tmp/staging/x86_64-linux/include -W -Wall
-Wstrict-prototypes -Wmissing-prototypes -Werror -isystem/usr/local/oe/build/tmp
/staging/x86_64-linux/include -O2 -c /usr/local/oe/build/tmp/work/armv4t-linux/b
inutils-cross-2.17-r0/binutils-2.17/bfd/libbfd.c -o libbfd.o
| cc1: warnings being treated as errors
| /usr/local/oe/build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17
/bfd/libbfd.c: In function 'bfd_getb_signed_64':
| /usr/local/oe/build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17
/bfd/libbfd.c:662: warning: left shift count >= width of type
| /usr/local/oe/build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17
/bfd/libbfd.c:662: warning: left shift count >= width of type
| /usr/local/oe/build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17
/bfd/libbfd.c: In function 'bfd_getl_signed_64':
| /usr/local/oe/build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17
/bfd/libbfd.c:685: warning: left shift count >= width of type
| /usr/local/oe/build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17
/bfd/libbfd.c:685: warning: left shift count >= width of type
| /usr/local/oe/build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17
/bfd/libbfd.c: In function 'bfd_putb64':
| /usr/local/oe/build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17
/bfd/libbfd.c:717: warning: right shift count >= width of type
| /usr/local/oe/build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17
/bfd/libbfd.c:718: warning: right shift count >= width of type
| /usr/local/oe/build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17
/bfd/libbfd.c:719: warning: right shift count >= width of type
| /usr/local/oe/build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17
/bfd/libbfd.c:720: warning: right shift count >= width of type
| /usr/local/oe/build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17
/bfd/libbfd.c: In function 'bfd_putl64':
| /usr/local/oe/build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17
/bfd/libbfd.c:735: warning: right shift count >= width of type
| /usr/local/oe/build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17
/bfd/libbfd.c:736: warning: right shift count >= width of type
| /usr/local/oe/build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17
/bfd/libbfd.c:737: warning: right shift count >= width of type
| /usr/local/oe/build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17
/bfd/libbfd.c:738: warning: right shift count >= width of type
| make[5]: *** [libbfd.lo] Error 1
</pre>

Any insight here? --[[User:Adam|Adam]] 23:10, 15 May 2007 (CEST)

== 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.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 fails to build '''usb-linux.c''' with error:
<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>
''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.

== Add count ==

Can the count of downloads be put on the page?

== 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.

== locale genereation segfaults with 2007.2 on 64Bit systems==

NOTE: Running task 272 of 3542 (ID: 115, /home/josch/moko2/openembedded/packages/glibc/glibc_2.5.bb, do_package)
NOTE: package glibc-2.5: started
NOTE: package glibc-2.5-r6: task do_package: started
NOTE: preparing tree for binary locale generation
NOTE: generating locale es_NI (UTF-8)
qemu: uncaught target signal 11 (Segmentation fault) - exiting
[...]

Add ENABLE_BINARY_LOCALE_GENERATION = "0" to your /build/local.conf.

MokoMakefile

2007-08-19T08:18:54Z

RodWhitby: /* QEMU */

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

Note that MokoMakefile does *not* replace bitbake, or svn, or monotone, or openembedded, or qmake, or anything else. It is a wrapper around all that to make it easy to set up and maintain a development environment that fully complies with the setup instructions published by OpenMoko. Note that you need about 12 GB of available disk space for MokoMakefile to succeed (see below for a tip on how to reduce this to . Please check that your RAM + swap partition space is greater than 512 MB (around 1GB?).

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

The MokoMakefile is able to build either OM-2007.1 or OM-2007.2 images. The core team chooses the default, but you can select one or the other at the top of the Makefile.

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

1 - Make sure your build host is set up according to:
http://www.openembedded.org/wiki/OEandYourDistro
2 - Create your $OMDIR directory (note that you can change ~/moko to any directory you like):
mkdir ~/moko ; cd ~/moko
3 - Grab MokoMakefile:
wget http://www.rwhitby.net/files/openmoko/Makefile

If that doesn't work, try

wget http://svn.nslu2-linux.org/svnroot/mokomakefile/trunk/Makefile
4 - Set up the environment:
make setup
5 - Start building. Before starting a lengthy make process, check in Tips section about how to make Make multicore aware. You may want to modify the build/conf/local.conf file for your target (emulation/chroot) environment:
make openmoko-devel-image

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

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

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

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

2 - To 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

===Reporting Problems===

First, make sure that the problem is reproducible after running

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

then running

make clean-package-<foo>

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

then running

make all

If you can get the error to occur three times in a row after running that sequence of commands (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].

===Work-arounds===

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

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

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

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

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

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

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

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

Dependencies:

*gcc 3.4 or 3.3 ('apt-get install gcc-3.4' in Ubuntu 7.04)
*lynx ('apt-get install lynx' in Ubuntu 7.04)
*netpbm ('apt-get install netpbm' in Ubuntu 7.04)
*sdl-devel ('apt-get install libsdl1.2-dev' in Ubuntu .704)
*mkdosfs ('apt-get install dosfstools' in Debian 4.0)

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

Other targets are “'''make download-images'''” (to download the latest official images), “'''make flash-qemu-official'''” (to flash those images) and “'''make flash-qemu-local'''” (which will flash your latest locally built images), which can then be followed by “''''make run-qemu'''” or “'''make run-qemu-snapshot'''” to run the emulator with the most recently flashed images. You can also use “''''make qemu-copy-package-''foo'''''” to copy the <code>.ipk</code> file for package ''foo'' to the virtual SD card, and later use “''''ipkg install /media/mmcblk0/''file'''''” from within the emulated Neo1973 to install the package.

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

===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 ../build/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 all

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

=== Hello World application ===

There is a [http://wiki.openmoko.org/wiki/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!", and "Wow this build system is nice - it just seems more polished than my gumstix toolchain buildroot system".

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

{{Languages|MokoMakefile}}

[[Category:Developer]]
[[Category:Guides]]

MokoMakefile

2007-08-19T08:18:34Z

RodWhitby: /* QEMU */

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

Note that MokoMakefile does *not* replace bitbake, or svn, or monotone, or openembedded, or qmake, or anything else. It is a wrapper around all that to make it easy to set up and maintain a development environment that fully complies with the setup instructions published by OpenMoko. Note that you need about 12 GB of available disk space for MokoMakefile to succeed (see below for a tip on how to reduce this to . Please check that your RAM + swap partition space is greater than 512 MB (around 1GB?).

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

The MokoMakefile is able to build either OM-2007.1 or OM-2007.2 images. The core team chooses the default, but you can select one or the other at the top of the Makefile.

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

1 - Make sure your build host is set up according to:
http://www.openembedded.org/wiki/OEandYourDistro
2 - Create your $OMDIR directory (note that you can change ~/moko to any directory you like):
mkdir ~/moko ; cd ~/moko
3 - Grab MokoMakefile:
wget http://www.rwhitby.net/files/openmoko/Makefile

If that doesn't work, try

wget http://svn.nslu2-linux.org/svnroot/mokomakefile/trunk/Makefile
4 - Set up the environment:
make setup
5 - Start building. Before starting a lengthy make process, check in Tips section about how to make Make multicore aware. You may want to modify the build/conf/local.conf file for your target (emulation/chroot) environment:
make openmoko-devel-image

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

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

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

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

2 - To 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

===Reporting Problems===

First, make sure that the problem is reproducible after running

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

then running

make clean-package-<foo>

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

then running

make all

If you can get the error to occur three times in a row after running that sequence of commands (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].

===Work-arounds===

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

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

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

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

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

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

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

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

Dependencies:

*gcc 3.4 or 3.3 ('apt-get install gcc-3.4' in Ubuntu 7.04)
*lynx ('apt-get install lynx' in Ubuntu 7.04)
*netpbm ('apt-get install netpbm' in Ubuntu 7.04)
*sdl-devel ('apt-get install libsdl1.2-dev' in Ubuntu .704)
*mkdosfs ('apt-get install dosfstools' in Debian 4.0)

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

Other targets are “'''make download-images'''” (to download the latest official images), “'''make flash-qemu-official'''” (to flash those images) and “'''make flash-qemu-local'''” (which will flash your latest locally built images), which can then be followed by “''''make run-qemu'''” or “'''make run-qemu-snapshot'''” to run the emulator with the most recently flashed images. You can also use “''''make qemu-copy-package-''foo'''''” to copy the <code>.ipk</code> file for package ''foo'' to the virtual SD card, and later use “''''ipkg install /media/mmcblk0/''file'''''” from within the emulated Neo1973 to install the package.

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

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

===Developing with MokoMakefile===

{{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 ../build/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 all

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

=== Hello World application ===

There is a [http://wiki.openmoko.org/wiki/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!", and "Wow this build system is nice - it just seems more polished than my gumstix toolchain buildroot system".

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

{{Languages|MokoMakefile}}

[[Category:Developer]]
[[Category:Guides]]

MokoMakefile

2007-08-19T08:18:05Z

RodWhitby: /* Tips */

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

Note that MokoMakefile does *not* replace bitbake, or svn, or monotone, or openembedded, or qmake, or anything else. It is a wrapper around all that to make it easy to set up and maintain a development environment that fully complies with the setup instructions published by OpenMoko. Note that you need about 12 GB of available disk space for MokoMakefile to succeed (see below for a tip on how to reduce this to . Please check that your RAM + swap partition space is greater than 512 MB (around 1GB?).

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

The MokoMakefile is able to build either OM-2007.1 or OM-2007.2 images. The core team chooses the default, but you can select one or the other at the top of the Makefile.

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

1 - Make sure your build host is set up according to:
http://www.openembedded.org/wiki/OEandYourDistro
2 - Create your $OMDIR directory (note that you can change ~/moko to any directory you like):
mkdir ~/moko ; cd ~/moko
3 - Grab MokoMakefile:
wget http://www.rwhitby.net/files/openmoko/Makefile

If that doesn't work, try

wget http://svn.nslu2-linux.org/svnroot/mokomakefile/trunk/Makefile
4 - Set up the environment:
make setup
5 - Start building. Before starting a lengthy make process, check in Tips section about how to make Make multicore aware. You may want to modify the build/conf/local.conf file for your target (emulation/chroot) environment:
make openmoko-devel-image

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

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

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

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

2 - To 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

===Reporting Problems===

First, make sure that the problem is reproducible after running

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

then running

make clean-package-<foo>

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

then running

make all

If you can get the error to occur three times in a row after running that sequence of commands (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].

===Work-arounds===

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

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

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

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

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

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

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

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

Dependencies:

*gcc 3.4 or 3.3 ('apt-get install gcc-3.4' in Ubuntu 7.04)
*lynx ('apt-get install lynx' in Ubuntu 7.04)
*netpbm ('apt-get install netpbm' in Ubuntu 7.04)
*sdl-devel ('apt-get install libsdl1.2-dev in Ubuntu .704')
*mkdosfs ('apt-get install dosfstools' in Debian 4.0)

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

Other targets are “'''make download-images'''” (to download the latest official images), “'''make flash-qemu-official'''” (to flash those images) and “'''make flash-qemu-local'''” (which will flash your latest locally built images), which can then be followed by “''''make run-qemu'''” or “'''make run-qemu-snapshot'''” to run the emulator with the most recently flashed images. You can also use “''''make qemu-copy-package-''foo'''''” to copy the <code>.ipk</code> file for package ''foo'' to the virtual SD card, and later use “''''ipkg install /media/mmcblk0/''file'''''” from within the emulated Neo1973 to install the package.

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

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

===Developing with MokoMakefile===

{{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 ../build/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 all

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

=== Hello World application ===

There is a [http://wiki.openmoko.org/wiki/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!", and "Wow this build system is nice - it just seems more polished than my gumstix toolchain buildroot system".

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

{{Languages|MokoMakefile}}

[[Category:Developer]]
[[Category:Guides]]

MokoMakefile

2007-08-19T08:15:48Z

RodWhitby: /* Reporting Problems */

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

Note that MokoMakefile does *not* replace bitbake, or svn, or monotone, or openembedded, or qmake, or anything else. It is a wrapper around all that to make it easy to set up and maintain a development environment that fully complies with the setup instructions published by OpenMoko. Note that you need about 12 GB of available disk space for MokoMakefile to succeed (see below for a tip on how to reduce this to . Please check that your RAM + swap partition space is greater than 512 MB (around 1GB?).

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

The MokoMakefile is able to build either OM-2007.1 or OM-2007.2 images. The core team chooses the default, but you can select one or the other at the top of the Makefile.

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

1 - Make sure your build host is set up according to:
http://www.openembedded.org/wiki/OEandYourDistro
2 - Create your $OMDIR directory (note that you can change ~/moko to any directory you like):
mkdir ~/moko ; cd ~/moko
3 - Grab MokoMakefile:
wget http://www.rwhitby.net/files/openmoko/Makefile

If that doesn't work, try

wget http://svn.nslu2-linux.org/svnroot/mokomakefile/trunk/Makefile
4 - Set up the environment:
make setup
5 - Start building. Before starting a lengthy make process, check in Tips section about how to make Make multicore aware. You may want to modify the build/conf/local.conf file for your target (emulation/chroot) environment:
make openmoko-devel-image

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

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

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

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

2 - To 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

===Reporting Problems===

First, make sure that the problem is reproducible after running

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

then running

make clean-package-<foo>

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

then running

make all

If you can get the error to occur three times in a row after running that sequence of commands (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].

===Work-arounds===

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

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

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

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

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

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

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

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

Dependencies:

*gcc 3.4 or 3.3 ('apt-get install gcc-3.4' in Ubuntu 7.04)
*lynx ('apt-get install lynx' in Ubuntu 7.04)
*netpbm ('apt-get install netpbm' in Ubuntu 7.04)
*sdl-devel ('apt-get install libsdl1.2-dev in Ubuntu .704')
*mkdosfs ('apt-get install dosfstools' in Debian 4.0)

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

Other targets are “'''make download-images'''” (to download the latest official images), “'''make flash-qemu-official'''” (to flash those images) and “'''make flash-qemu-local'''” (which will flash your latest locally built images), which can then be followed by “''''make run-qemu'''” or “'''make run-qemu-snapshot'''” to run the emulator with the most recently flashed images. You can also use “''''make qemu-copy-package-''foo'''''” to copy the <code>.ipk</code> file for package ''foo'' to the virtual SD card, and later use “''''ipkg install /media/mmcblk0/''file'''''” from within the emulated Neo1973 to install the package.

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

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

===Developing with MokoMakefile===

{{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 ../build/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 all

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

=== Hello World application ===

There is a [http://wiki.openmoko.org/wiki/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!", and "Wow this build system is nice - it just seems more polished than my gumstix toolchain buildroot system".

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

{{Languages|MokoMakefile}}

[[Category:Developer]]
[[Category:Guides]]

MokoMakefile

2007-08-19T08:15:29Z

RodWhitby: /* Updating the environment */

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

Note that MokoMakefile does *not* replace bitbake, or svn, or monotone, or openembedded, or qmake, or anything else. It is a wrapper around all that to make it easy to set up and maintain a development environment that fully complies with the setup instructions published by OpenMoko. Note that you need about 12 GB of available disk space for MokoMakefile to succeed (see below for a tip on how to reduce this to . Please check that your RAM + swap partition space is greater than 512 MB (around 1GB?).

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

The MokoMakefile is able to build either OM-2007.1 or OM-2007.2 images. The core team chooses the default, but you can select one or the other at the top of the Makefile.

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

1 - Make sure your build host is set up according to:
http://www.openembedded.org/wiki/OEandYourDistro
2 - Create your $OMDIR directory (note that you can change ~/moko to any directory you like):
mkdir ~/moko ; cd ~/moko
3 - Grab MokoMakefile:
wget http://www.rwhitby.net/files/openmoko/Makefile

If that doesn't work, try

wget http://svn.nslu2-linux.org/svnroot/mokomakefile/trunk/Makefile
4 - Set up the environment:
make setup
5 - Start building. Before starting a lengthy make process, check in Tips section about how to make Make multicore aware. You may want to modify the build/conf/local.conf file for your target (emulation/chroot) environment:
make openmoko-devel-image

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

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

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

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

2 - To 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

===Reporting Problems===

First, make sure that the problem is reproducible after running

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

then running

make clean-package-<foo>

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

then running

make all

If you can get the error to occur three times in a row after running that sequence of commands (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].

===Work-arounds===

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

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

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

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

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

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

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

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

Dependencies:

*gcc 3.4 or 3.3 ('apt-get install gcc-3.4' in Ubuntu 7.04)
*lynx ('apt-get install lynx' in Ubuntu 7.04)
*netpbm ('apt-get install netpbm' in Ubuntu 7.04)
*sdl-devel ('apt-get install libsdl1.2-dev in Ubuntu .704')
*mkdosfs ('apt-get install dosfstools' in Debian 4.0)

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

Other targets are “'''make download-images'''” (to download the latest official images), “'''make flash-qemu-official'''” (to flash those images) and “'''make flash-qemu-local'''” (which will flash your latest locally built images), which can then be followed by “''''make run-qemu'''” or “'''make run-qemu-snapshot'''” to run the emulator with the most recently flashed images. You can also use “''''make qemu-copy-package-''foo'''''” to copy the <code>.ipk</code> file for package ''foo'' to the virtual SD card, and later use “''''ipkg install /media/mmcblk0/''file'''''” from within the emulated Neo1973 to install the package.

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

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

===Developing with MokoMakefile===

{{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 ../build/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 all

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

=== Hello World application ===

There is a [http://wiki.openmoko.org/wiki/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!", and "Wow this build system is nice - it just seems more polished than my gumstix toolchain buildroot system".

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

{{Languages|MokoMakefile}}

[[Category:Developer]]
[[Category:Guides]]

MokoMakefile

2007-08-19T08:14:08Z

RodWhitby: /* MokoMakefile */

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

Note that MokoMakefile does *not* replace bitbake, or svn, or monotone, or openembedded, or qmake, or anything else. It is a wrapper around all that to make it easy to set up and maintain a development environment that fully complies with the setup instructions published by OpenMoko. Note that you need about 12 GB of available disk space for MokoMakefile to succeed (see below for a tip on how to reduce this to . Please check that your RAM + swap partition space is greater than 512 MB (around 1GB?).

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

The MokoMakefile is able to build either OM-2007.1 or OM-2007.2 images. The core team chooses the default, but you can select one or the other at the top of the Makefile.

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

1 - Make sure your build host is set up according to:
http://www.openembedded.org/wiki/OEandYourDistro
2 - Create your $OMDIR directory (note that you can change ~/moko to any directory you like):
mkdir ~/moko ; cd ~/moko
3 - Grab MokoMakefile:
wget http://www.rwhitby.net/files/openmoko/Makefile

If that doesn't work, try

wget http://svn.nslu2-linux.org/svnroot/mokomakefile/trunk/Makefile
4 - Set up the environment:
make setup
5 - Start building. Before starting a lengthy make process, check in Tips section about how to make Make multicore aware. You may want to modify the build/conf/local.conf file for your target (emulation/chroot) environment:
make openmoko-devel-image

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

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

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

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

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

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

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

===Reporting Problems===

First, make sure that the problem is reproducible after running

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

then running

make clean-package-<foo>

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

then running

make all

If you can get the error to occur three times in a row after running that sequence of commands (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].

===Work-arounds===

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

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

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

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

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

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

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

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

Dependencies:

*gcc 3.4 or 3.3 ('apt-get install gcc-3.4' in Ubuntu 7.04)
*lynx ('apt-get install lynx' in Ubuntu 7.04)
*netpbm ('apt-get install netpbm' in Ubuntu 7.04)
*sdl-devel ('apt-get install libsdl1.2-dev in Ubuntu .704')
*mkdosfs ('apt-get install dosfstools' in Debian 4.0)

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

Other targets are “'''make download-images'''” (to download the latest official images), “'''make flash-qemu-official'''” (to flash those images) and “'''make flash-qemu-local'''” (which will flash your latest locally built images), which can then be followed by “''''make run-qemu'''” or “'''make run-qemu-snapshot'''” to run the emulator with the most recently flashed images. You can also use “''''make qemu-copy-package-''foo'''''” to copy the <code>.ipk</code> file for package ''foo'' to the virtual SD card, and later use “''''ipkg install /media/mmcblk0/''file'''''” from within the emulated Neo1973 to install the package.

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

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

===Developing with MokoMakefile===

{{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 ../build/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 all

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

=== Hello World application ===

There is a [http://wiki.openmoko.org/wiki/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!", and "Wow this build system is nice - it just seems more polished than my gumstix toolchain buildroot system".

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

{{Languages|MokoMakefile}}

[[Category:Developer]]
[[Category:Guides]]

MokoMakefile

2007-08-19T08:13:52Z

RodWhitby: /* Before you begin */

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

Note that MokoMakefile does *not* replace bitbake, or svn, or monotone, or openembedded, or qmake, or anything else. It is a wrapper around all that to make it easy to set up and maintain a development environment that fully complies with the setup instructions published by OpenMoko. Note that you need about 12 GB of available disk space for MokoMakefile to succeed (see below for a tip on how to reduce this to . Please check that your RAM + swap partition space is greater than 512 MB (around 1GB?).

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

The MokoMakefile is able to build either OM-2007.1 or OM-2007.2 images. The core team chooses the default, but you can select one or the other at the top of the Makefile.

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

1 - Make sure your build host is set up according to:
http://www.openembedded.org/wiki/OEandYourDistro
2 - Create your $OMDIR directory (note that you can change ~/moko to any directory you like):
mkdir ~/moko ; cd ~/moko
3 - Grab MokoMakefile:
wget http://www.rwhitby.net/files/openmoko/Makefile

If that doesn't work, try

wget http://svn.nslu2-linux.org/svnroot/mokomakefile/trunk/Makefile
4 - Set up the environment:
make setup
5 - Start building. Before starting a lengthy make process, check in Tips section about how to make Make multicore aware. You may want to modify the build/conf/local.conf file for your target (emulation/chroot) environment:
make openmoko-devel-image

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

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

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

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

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

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

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

===Reporting Problems===

First, make sure that the problem is reproducible after running

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

then running

make clean-package-<foo>

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

then running

make all

If you can get the error to occur three times in a row after running that sequence of commands (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].

===Work-arounds===

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

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

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

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

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

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

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

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

Dependencies:

*gcc 3.4 or 3.3 ('apt-get install gcc-3.4' in Ubuntu 7.04)
*lynx ('apt-get install lynx' in Ubuntu 7.04)
*netpbm ('apt-get install netpbm' in Ubuntu 7.04)
*sdl-devel ('apt-get install libsdl1.2-dev in Ubuntu .704')
*mkdosfs ('apt-get install dosfstools' in Debian 4.0)

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

Other targets are “'''make download-images'''” (to download the latest official images), “'''make flash-qemu-official'''” (to flash those images) and “'''make flash-qemu-local'''” (which will flash your latest locally built images), which can then be followed by “''''make run-qemu'''” or “'''make run-qemu-snapshot'''” to run the emulator with the most recently flashed images. You can also use “''''make qemu-copy-package-''foo'''''” to copy the <code>.ipk</code> file for package ''foo'' to the virtual SD card, and later use “''''ipkg install /media/mmcblk0/''file'''''” from within the emulated Neo1973 to install the package.

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

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

===Developing with MokoMakefile===

{{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 ../build/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 all

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

=== Hello World application ===

There is a [http://wiki.openmoko.org/wiki/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!", and "Wow this build system is nice - it just seems more polished than my gumstix toolchain buildroot system".

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

{{Languages|MokoMakefile}}

[[Category:Developer]]
[[Category:Guides]]

MokoMakefile

2007-08-19T08:12:07Z

RodWhitby: /* MokoMakefile */

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

Note that MokoMakefile does *not* replace bitbake, or svn, or monotone, or openembedded, or qmake, or anything else. It is a wrapper around all that to make it easy to set up and maintain a development environment that fully complies with the setup instructions published by OpenMoko. Note that you need about 12 GB of available disk space for MokoMakefile to succeed (see below for a tip on how to reduce this to . Please check that your RAM + swap partition space is greater than 512 MB (around 1GB?).

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

The MokoMakefile is able to build either OM-2007.1 or OM-2007.2 images. The core team chooses the default, but you can select one or the other at the top of the Makefile.

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

Note: on http://www.openembedded.org/wiki/OEandYourDistro are better instructions for Ubuntu to make sh be bash.

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

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

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

You need to get mtn and svn for make.
sudo apt-get install subversion monotone

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

1 - Make sure your build host is set up according to:
http://www.openembedded.org/wiki/OEandYourDistro
2 - Create your $OMDIR directory (note that you can change ~/moko to any directory you like):
mkdir ~/moko ; cd ~/moko
3 - Grab MokoMakefile:
wget http://www.rwhitby.net/files/openmoko/Makefile

If that doesn't work, try

wget http://svn.nslu2-linux.org/svnroot/mokomakefile/trunk/Makefile
4 - Set up the environment:
make setup
5 - Start building. Before starting a lengthy make process, check in Tips section about how to make Make multicore aware. You may want to modify the build/conf/local.conf file for your target (emulation/chroot) environment:
make openmoko-devel-image

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

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

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

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

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

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

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

===Reporting Problems===

First, make sure that the problem is reproducible after running

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

then running

make clean-package-<foo>

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

then running

make all

If you can get the error to occur three times in a row after running that sequence of commands (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].

===Work-arounds===

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

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

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

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

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

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

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

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

Dependencies:

*gcc 3.4 or 3.3 ('apt-get install gcc-3.4' in Ubuntu 7.04)
*lynx ('apt-get install lynx' in Ubuntu 7.04)
*netpbm ('apt-get install netpbm' in Ubuntu 7.04)
*sdl-devel ('apt-get install libsdl1.2-dev in Ubuntu .704')
*mkdosfs ('apt-get install dosfstools' in Debian 4.0)

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

Other targets are “'''make download-images'''” (to download the latest official images), “'''make flash-qemu-official'''” (to flash those images) and “'''make flash-qemu-local'''” (which will flash your latest locally built images), which can then be followed by “''''make run-qemu'''” or “'''make run-qemu-snapshot'''” to run the emulator with the most recently flashed images. You can also use “''''make qemu-copy-package-''foo'''''” to copy the <code>.ipk</code> file for package ''foo'' to the virtual SD card, and later use “''''ipkg install /media/mmcblk0/''file'''''” from within the emulated Neo1973 to install the package.

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

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

===Developing with MokoMakefile===

{{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 ../build/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 all

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

=== Hello World application ===

There is a [http://wiki.openmoko.org/wiki/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!", and "Wow this build system is nice - it just seems more polished than my gumstix toolchain buildroot system".

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

{{Languages|MokoMakefile}}

[[Category:Developer]]
[[Category:Guides]]

OpenMoko2007.2

2007-08-19T08:09:53Z

RodWhitby: /* How to build */

== FAQ ==
=== What is 2007.2? ===

As of 2007-07-26 the development of the next version of the OpenMoko distribution has begun.

Goals of the new version are an improved set of PIM applications, improved theming that fixes a lot of the usability problems of the 1st generation design, more formalized UI guidelines and a number of changes in the build system. The latter should introduce more recent software by staying closer in sync with upstream org.openembedded.dev.

An official announcement is expected soon (Aug 19).

(Initially this was named OM-2008 in SVN but renamed shortly after that.)

=== What are differences between 2007.1 and 2007.2? ===

=== Where to get images? ===

[[OpenMoko2007.2#Pre-built_snapshot_images|Unofficial images]]

=== Where are official images? ===

No official images yet.

=== My mrxvt (terminal) fonts are huge. ===

Edit src/feature.h to set MIN_XFT_FONT_SIZE to lower value:
#define MIN_XFT_FONT_SIZE (2)
and rebuild mrxvt & openmoko-devel-image.

End edit /etc/mrxvt/mrxvt.conf
Mrxvt.xftSize: 4
Mrxvt.xftHint: 1

== How to build ==

The MokoMakefile is now able to build OM-2007.2 images. If you use this new version of the MokoMakefile, you can ignore everything below and just continue building OM-2007.2 in the same way that you previously built images (i.e. according to http://wiki.openmoko.org/wiki/MokoMakefile). Make sure you set the generation correctly at the top of the file.

'''Please note that this is no official guide on how to build OM-2007.2. I am just making my first steps getting this to compile and think it would be a [http://en.wikipedia.org/wiki/Proprietary_software waste of time] of I keep problems I found for my own. Additionally it would be good if the new distro gets more exposure and testing so less things will break after the official announcement.'''

Follow the [http://www.openembedded.org/wiki/GettingStarted getting started] steps of OpenEmbedded. Use Bitbake 1.8.6 not a SVN version from the stable branch (otherwise you will get problems with checking out repositories) and the ''org.openembedded.dev'' branch of OE.

Put the following in your local.conf

BBFILES = "${HOME}/oe/org.openembedded.dev/packages/*/*.bb"

MACHINE = "fic-gta01"
DISTRO = "openmoko"

ENABLE_BINARY_LOCALE_GENERATION = "1"
GLIBC_GENERATE_LOCALES = "en_GB.UTF-8"

Replace "${HOME}/oe" with the path to where your "org.openembeded.dev" folder lives. For the other entries have a look at ''conf/local.conf.sample'' about their meaning.

Run ''bitbake <package name>'' (e.g. openmoko-devel-image).

Hopefully the MokoMakeFile is soon upgraded to be used for OM-2007.2. Since OpenMoko is not using the overlay any more that makefile should be simpler then. :-)

=== Build issues ===

==== Wrong certificate ====
You may get something like this while the bitbake recipes are parsed:

Error validating server certificate for 'https://libw100.svn.sf.net:443':
- The certificate hostname does not match.
Certificate information:
- Hostname: *.svn.sourceforge.net
- Valid: from Fri, 27 Oct 2006 12:05:58 GMT until Sun, 28 Oct 2007 13:05:58 GMT
- Issuer: Equifax Secure Certificate Authority, Equifax, US
- Fingerprint: f2:6c:fe:bb:82:92:30:09:72:dd:1c:b3:e7:56:69:c7:7a:df:67:3e

That is an issue in a bitbake file. One should not use the short-name for sourceforge (sf.net) when certificates are only for exact host names. Accept the certificate and everything is fine for now.

==== openmoko-libs FTBFS ====
Some applications have not been fully modified to build with the new libraries of OpenMoko and still need the old-style ''openmoko-libs'' package. ''libmokogsm'' which is needed for ''openmoko-libs'' then fails to build. As a workaround you can remove the not yet ported applications that need ''openmoko-libs'' making it unneccessary itself. To do this edit ''packages/tasks/openmoko-taks.bb'' and find the following lines:

.
.
.
openmoko-terminal \
matchbox-panel-2 \
matchbox-panel-2-applets \
matchbox-applet-inputmanager \
# openmoko-appmanager \
matchbox-keyboard \
matchbox-stroke \
openmoko-keyboard \
.
.
.

Now put a hash (''#'') before ''openmoko-terminal'' and ''openmoko-keyboard''. You can verify that ''openmoko-libs'' is not needed any more by issuing ''bitbake -g openmoko-devel-image'' (= creates a dependency graph). There should be no mentioning of ''openmoko-libs'' in the file ''task-depends.dot''. '''Please note that the graphicall terminal and the virtual keyboard will be missing now.''' You can still have terminal access by following the [[USB Networking]] guide. For keyboard input in Qemu add the ''-usbdevice keyboard'' switch.

==== gtk+ fails building w/ gtkcombobox.c ====

If you get these errors:

gtkcombobox.c: In function 'gtk_combo_box_size_request':
gtkcombobox.c:1859: warning: unused variable 'font_desc'
gtkcombobox.c:1858: warning: unused variable 'metrics'
gtkcombobox.c:1857: warning: unused variable 'context'
gtkcombobox.c:1855: warning: unused variable 'arrow_size'
gtkcombobox.c:1854: warning: unused variable 'font_size'
gtkcombobox.c: In function 'gtk_combo_box_size_allocate':
gtkcombobox.c:1962: error: 'arrow_size' undeclared (first use in this function)
gtkcombobox.c:1962: error: (Each undeclared identifier is reported only once
gtkcombobox.c:1962: error: for each function it appears in.)
gtkcombobox.c:1965: error: 'font_desc' undeclared (first use in this function)
gtkcombobox.c:1966: error: 'context' undeclared (first use in this function)
gtkcombobox.c:1967: error: 'metrics' undeclared (first use in this function)
gtkcombobox.c:1969: error: 'font_size' undeclared (first use in this function)

Go to your /build/tmp/work/fic-gta01-angstrom-linux-gnueabi/gtk+-2.10.14-r3/gtk+-2.10.14/gtk directory, and patch gtkcombobox.c with the following:

Thanks to rmoravcik in #openmoko (patch was taken from http://pastebin.ca/654717 )

--- gtkcombobox.c 2007-08-12 20:30:07.000000000 +0200
+++ gtkcombobox.c 2007-08-12 20:29:58.000000000 +0200
@@ -1948,6 +1948,12 @@
gtk_combo_box_size_allocate (GtkWidget *widget,
GtkAllocation *allocation)
{
+ gint font_size;
+ gint arrow_size;
+ PangoContext *context;
+ PangoFontMetrics *metrics;
+ PangoFontDescription *font_desc;
+
GtkComboBox *combo_box = GTK_COMBO_BOX (widget);
gint focus_width, focus_pad;
GtkAllocation child;

==== Building glibc fails with a segfault in QEMU ====

If your build aborts and you see something like this:

NOTE: package glibc-2.5: started
NOTE: package glibc-2.5-r6: task do_package: started
NOTE: preparing tree for binary locale generation
NOTE: generating locale en_US (UTF-8)
qemu: uncaught target signal 11 (Segmentation fault) - exiting

...

NOTE: Tasks Summary: Attempted 271 tasks of which 0 didn't need to be rerun and 1 failed.
ERROR: '/home/moko/oe/org.openembedded.dev/packages/glibc/glibc_2.5.bb' failed

Try editing your local.conf file. Change:

ENABLE_BINARY_LOCALE_GENERATION = "1"

to

ENABLE_BINARY_LOCALE_GENERATION = "0"

and restart the build. This may have some effect on internationalization (you will see a warning indicating that), but at least the build will continue. Thanks to rwhitby for the tip.

Alternatively, as suggested by XorA in #openmoko, if you are running a 64-bit host distribution, try forcing a different QEMU rev, also in local.conf:

PREFERRED_VERSION_qemu-native = "0.9.0+cvs20070701"
SRCDATE_qemu-native = 20070701

==== libxml2-native fails with xmlCatalogPtr errors ====

Go to your build/tmp/work/i686-linux/libxml2-native-2.6.29-r1/libxml2-2.6.29/include/libxml/ directory and patch xmlversion.h with the following:

--- xmlversion.h 2007-08-17 10:45:42.000000000 +0100
+++ xmlversion.h 2007-08-17 10:51:36.000000000 +0100
@@ -219,7 +219,7 @@
*
* Whether the Catalog support is configured in
*/
-#if 0
+#if 1
#define LIBXML_CATALOG_ENABLED
#endif

On my system the libxml2-native-2.6.29-r1 directory is in a directory named i686-linux, yours may be different. I believe this patch to be a workaround to make libxml2-native build. I am not yet sure what the consequences of enabling XML catalogue support are.

=== Flashing with MokoMakefile ===
Since MokoMakefile has not been adjusted to use the new build layout you cannot use it. As a quick hack to make flashing local built image possible again try this:

Find the following lines in the MokoMakefile:

flash-qemu-local: stamps/qemu stamps/openmoko-devel-image
( cd build/qemu && openmoko/flash.sh ../tmp/deploy/images )

And replace them with:

flash-qemu-local: stamps/qemu
( cd build/qemu && openmoko/flash.sh <MY_NEW_BUILD_DIR>/tmp/deploy/glibc/images/fic-gta01 )

Where you should replace <MY_NEW_BUILD_DIR> with the full path to your build directory (the one where ''conf/local.conf'' lives in). Running the image should work, too. :-)

With this changes kernel and uboot image are picked up correctly. However the name of the root filesystem image has changed in OM-2007.2 and the current scripts will not pick it up any more. Just edit ''$OM_DIR/build/qemu/openmoko/env'' and change the line saying:

rootfs_wildcard="openmoko-*.rootfs.jffs2"

to

rootfs_wildcard="OpenMoko-*.rootfs.jffs2"

Now it will work correctly again.

== How to build using nslu2-linux MasterMakefile (Ubuntu 7.04) ==
[disclaimer]

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

Note: on http://www.openembedded.org/wiki/OEandYourDistro are better instructions for Ubuntu to make sh be bash.

Create your $OMDIR directory (note that you can change ~/OM-2007.2 to any directory you like):
mkdir ~/OM-2007.2 ; cd ~/OM-2007.2

Grab the nslu2-linux [http://www.nslu2-linux.org/wiki/Development/MasterMakefile MasterMakefile]:
wget http://www.nslu2-linux.org/Makefile

This will make sure you'll have all the required packages:
sudo apt-get install \
autoconf automake automake1.9 \
bison \
ccache cogito \
cvs \
diffstat \
docbook \
flex \
gcc g++ gawk gcj gettext git-core \
help2man \
libc6-dev libglib2.0-dev libtool libxext-dev\
m4 make \
patch pkg-config \
python python-dev python2.4 python2.4-dev python-psyco \
sed \
sharutils \
texinfo texi2html \
unzip \
subversion \
sysutils \
texinfo \
bzip2

Ubuntu 7.04 comes with monotone 0.31. You could just go with that and do a mtn db migrate but this takes hours so the easier way would be to download a suitable mtn db from http://www.openembedded.org/snapshots/ and use this.
mkdir -p monotone
wget http://www.openembedded.org/snapshots/\
OE-this-is-for-mtn-<your mtn version>.mtn.bz2 -O monotone/nslu2-linux.mtn.bz2
bunzip2 monotone/nslu2-linux.mtn.bz2

If you're using MokoMakefile for building OM2007.1 you probably have fresh OE.mtn for version 0.31 already downloaded. So you can just make symlink to the OE.mtn in your OM2007.1 build directory.

(current directory(pwd) is /path/to/OM2007.2)
ln -s /path/to/OM2007.1/OE.mtn monotone/nslu2-linux.mtn

To save even more bandwith you can also use already donwloaded source files from OM2007.1. Just make a symlink to OM2007.1 sources directory. Something like this.

(current directory(pwd) is /path/to/OM2007.2)
ln -s /path/to/OM2007.1/sources downloads

Go build ;)
make openmoko-image

* If you an encounter an error with monotone similar to the following:

mtn: misuse: database monotone/nslu2-linux.mtn is laid out according to an old schema

Then you need to upgrade nslu2-linux.mtn Use the following command:

# mtn --db monotone/nslu2-linux.mtn db migrate

== Pre-built snapshot images ==
http://ipkg.nslu2-linux.org/feeds/openmoko/images/

http://people.openmoko.org/mickey/images/ (Confirmed working)



[[Category:OpenMoko2007.2| ]]