Openmoko - User contributions [en]

User:RzR

2012-07-07T17:03:33Z

RzR:

Contact: http://rzr.online.fr/contact.htm

* [[boxar]] : Download and check video at : http://rzr.online.fr/q/esd
* [[Mer]] : download bootable image : http://wiki.openmoko.org/wiki/Mer
* [[Arkanae]] : http://rzr.online.fr/q/pygame

By the way I am available for linux mobile professional services :

http://rzr.online.fr/job.htm

Tags: [[Maemo]] [[Mer]] [[Meego]] [[Android]] [[FreeRunner]]

Development with Eclipse

2009-11-16T11:07:12Z

RzR: /* On the 8 of november it seems that its not working */

{{Languages| Development with Eclipse}}
A graphical Openmoko application is a gnome-based X application. Hence it is usually easy to build, run and debug it as program for the desktop computer, uploading to the mobile phone only for the final stage of debugging. Even from the mobile phone, it is possible execute the program on the phone and still use the screen, mouse and keyboard of the desktop computer to observe its work. This article describes instructions for Debian, but they will likely work with any non broken Linux distribution.

Eclipse recently has the C/C++ development plug-in. You will need the recent Eclipse, this plug-in and you may need to upgrade the GTK development packages. The easiest way to get the simple application running is to create the managed C project and add `pkg-config --cflags --libs gtk+-2.0` both to the compiler options and to linker flags. After that, go to [http://library.gnome.org/devel/gtk-tutorial/stable/ GTK tutorial] and try, using it, to compose a simple application.

This approach not only shortens development cycle from minutes to seconds, but also allows to use the Eclipse debugger for C development, stepping through the code and watching variables.

The executable for the mobile phone can usually be produced from the same source files using the Openmoko toolchain. As all surroundings of these files for Eclipse and Openmoko project are not the same, the most straightforward approach is just to set two development environments and put the symbolic links of the source files into the Openmoko project directory.

After producing the Openmoko executable, it may be reasonable to try it via X, using the keyboard, mouse and screen of the desktop computer. All you need is to use the -X option in the ssh command when you log in into the connected mobile phone. After that, you should be able to run the application inside the phone but have its X window on a screen of the desktop machine. This way you can check the actual execution speed and have access to the mobile phone devices that are not present on PC.

Eclipse allows to add the custom builder to the project. These builders can be either Ant scripts or the executable shell scripts. These possibilities can be used to force the Openmoko toolchain to produce the phone executable without leaving the Eclipse IDE.

== Set up Freerunner build Config ==

# install [[Toolchain]]
# open 'Properties' for your C or C++ Project
# select 'C/C++ Build'->'Tool Settings'
# click on 'Configuration'->'Manage' and create new configuration eg. Freerunner (copy settings from 'Relase' configuration)
# change GCC C||C++||Assembler Compiler command to /usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/bin/gcc||g++||as
# change GCC Linker Command to /usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/bin/gcc (g++ for C++ project)
# go to 'Build Steps' and add ". /usr/local/openmoko/arm/setup-env" to 'Pre-build step'
# click Ok and select 'Freerunner' in 'Active Build Configuration' for your Project

----
Notes about Eclipse Ganymed (3.4)

There are three places where you have to change settings as above in Project Properties -> C/C++ Build -> Settings -> Tool Settings
#GCC C Compiler -> Command: /usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/bin/gcc
#GCC C Linker -> Command: /usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/bin/gcc
#GCC Assembler -> Command: /usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/bin/gcc||g++||as

--[[User:Perty|Perty]] 20:22, 18 September 2008 (UTC)
----

You can copy your binary to Freerunner by adding Post-Build command in 'Build Steps' eg.

scp ${project_name} root@neo:/home/root/dev_app/

or you can Run you application on Freerunner by adding Run configuration

----

C/C++ Application: /usr/bin/ssh
Arguments: root@neo "cd dev_app && DISPLAY=:0 ./${project_name}"

--[[User:PipBoy2000|PipBoy2000]] 22:30, 9 September 2008 (UTC)

==Set up Eclipse for development with Qt4==

=== On the 8 of November it seems that its not working ===

This method has been tried on various distributions and it didn't worked, if you get it working please tell how you've done it and remove this message ...
If you have others method to cross compile for the 2008.x in Qt4/c++ let us know !

I realized this with Xubuntu Hardy in an VirtualBox and using it to compile binaries for [[FSO]] and now [[SHR]].

So it's possible to upload it somewhere for everyone. Do somebody know where??
Havn't tried to compile ipk-packages with this method, just binaries.
What exactly didn't work? If somebody has questions just ask on the Community Mailing list, I'll try to help.

yes, it should be great if you share you virtual machine ... we have to find a place !
I'm now developing under [[debian]] (who has every development libraries ), waiting a way to compile for [[FSO]]

===Set up Environment with Libraries===

*install [[Toolchain]]

*install Eclipse with C/C++ development plug-in

*add the Anstrom Repository to the '''Host'''-toolchain and also to the '''FreeRunner'''
**add Anstrom Repository to '''Host'''-toolchain:
<pre>echo arch base 50 >> /usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/etc/opkg.conf
echo src/gz base http://www.angstrom-distribution.org/feeds/2008/ipk/glibc/armv4t/base >> /usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/etc/opkg.conf</pre>
then..
<pre>opkg-target update
opkg-target install libgcc1 libglib-2.0-0 libgmodule-2.0-0 libgobject-2.0-0 libgthread-2.0-0 libpng12-0 libqt3support4 libqtassistantclient4 libqtclucene4 libqtcore4 libqtdbus4 libqtdesigner4 libqtdesignercomponents4 libqtgui4 libqthelp4 libqtnetwork4 libqtscript4 libqtsql4 libqtsvg4 libqttest4 libqtxml4 libstdc++6 qt4-assistant qt4-common qt4-dbus qt4-demos qt4-designer qt4-fonts qt4-linguist qt4-pixeltool</pre>

opkg-target install qt4-x11-free-dev qt4-designer qt4-assistant // doesn't work there are some depency problems with x11-free packages so all the libs must be installed seperately (next line)

<pre>opkg-target install libqt3support-dev libqtassistantclient-dev libqtclucene-dev libqtcore-dev libqtdbus-dev libqtdesigner-dev libqtdesignercomponents-dev libqtgui-dev libqthelp-dev libqtnetwork-dev libqtscript-dev libqtsql-dev libqtsvg-dev libqttest-dev libqtuitools4-dev libqtxml-dev libglib-2.0-dev</pre>
:*Add Qtlibs also to the '''FreeRunner''' :
<pre>opkg update
opkg -force-depends install http://www.angstrom-distribution.org/feeds/2008/ipk/glibc/armv4t/base/libqtgui4_4.4.3-r4.1_armv4t.ipk
opkg -force-depends install http://www.angstrom-distribution.org/feeds/2008/ipk/glibc/armv4t/base/libqtcore4_4.4.3-r4.1_armv4t.ipk
opkg -force-depends install http://www.angstrom-distribution.org/feeds/2008/ipk/glibc/armv4t/base/libqtdbus4_4.4.3-r4.1_armv4t.ipk
opkg -force-depends install http://www.angstrom-distribution.org/feeds/2008/ipk/glibc/armv4t/base/libqtxml4_4.4.3-r4.1_armv4t.ipk</pre>

===Configure Eclipse Project===
Project - right click - Properties --> C/C++ Build -- Tab "Tool Settings"

====Configuration: Debug====

*GCC c++ compiler -> Directories --- add
/usr/include/qt4
/usr/include/qt4/QtGui
/usr/include/qt4/QtDBus
/usr/include/qt4/QtCore

*GCC C++ Linker -> Libraries ---add
**Libraries (-l):
QtCore
QtGui
QtDBus
**Library search path (-L):
/usr/lib
** On Gentoo: /usr/lib/qt4

====Configuration: Freerunner====

Project - right click - Properties --> C/C++ Build -- Tab "Tool Settings"

create Configuration "Freerunner":
click on 'Configuration'->'Manage' and create new configuration eg. Freerunner (copy settings from 'Relase' configuration)

*GCC C++ Compiler
**Command: /usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/bin/g++
*GCC C++ Compiler -> Directories
<pre>/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/usr/include/qt4/QtCore
/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/usr/include/qt4/QtGui
/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/usr/include/qt4/QtDBus
/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/usr/include/qt4
/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/usr/include/c++/4.1.2/arm-angstrom-linux-gnueabi
/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/usr/include/c++/4.1.2
/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/usr/include/c++/4.1.2/backward</pre>

*GCC C++ Linker
**Command: /usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/bin/g++

*GCC C++ Linker -> Libraries --- add
**Libraries (-l):
<pre>QtCore
QtGui
QtDBus</pre>
**Library search path (-L):
/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/usr/lib

* GCC Assembler
**Command: /usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/bin/as

go to Tab 'Build Steps' and add ". /usr/local/openmoko/arm/setup-env" to 'Pre-build step'

====workaround to deal with .ui files from Qt-Designer====

mayby somody has a better solution please correct!!

Create a project with properties as mentioned above.
To Compile your project create a bash-file in your Project-Folder (sed commands are necessary if you're using QtDbus libraries):

#!/bin/bash
make clean
rm Makefile.sed*
qmake-qt4 -project
qmake-qt4
sed 's/INCPATH =/INCPATH = -I\/usr\/include\/qt4\/QtDBus/g' Makefile > Makefile.sed1
sed 's/LIBS = $(SUBLIBS)/LIBS = $(SUBLIBS) -lQtDBus/g' Makefile.sed1 > Makefile.sed2
cp Makefile.sed2 Makefile
make

Run it...then compile your project with Eclipse Configuration "Freerunner"

[[Category:Application Developer]]

Developing with C++ and Qt

2009-11-16T11:04:22Z

RzR: /* News */

{{note|This article is way to unify community experience, tips and tricks in order to develop C++ applications based on the QT framework. It's actually incomplete and may be wrong in several parts, please fix and improve!}}
=Introduction=
extracted from wikipedia:

''Qt is a cross-platform application development framework, widely used for the development of GUI programs, and also used for developing non-GUI programs such as console tools and servers. Qt is most notably used in KDE, Opera, Google Earth, Skype, Qtopia, Photoshop Elements, VirtualBox and OPIE. It is produced by the Norwegian company Trolltech and developed at its Brisbane office in Australia. Nokia acquired Trolltech on January 28, 2008.''

Applications using Qt should run on 2008.x, FSO/SHR, and Qtopia from Trolltech (on this firmware alternative widget toolkits, as gtk+, actually do not work, as they need an X server). This makes Qt a good choice to start developing new applications for the Openmoko world.

=Developing with Trolltech/Qt Extended=

''The SDK for the new version 4.4.1 of Ot Extended, formerly known as Qtopia is not ready yet, tarball is available but it lacks updated documentation.''

==Use pre-built SDK==

Trolltech provides good SDK and documentation. You can download the official SDK [http://sourceforge.net/project/downloading.php?groupname=qpe&filename=qtopia-ficgta01-sdk-4.3.2.iso&use_mirror=osdn here].

It's a VMware based virtual machine you can run with the free vmplayer. This is a ready to go solution. What you get is an .iso image. Mount the iso. There's a readme in there.
You will need to execute a script <tt>install.sh</tt>, which will generate several <tt>.vmdk</tt> files. Afterwards you need to load these into your vmplayer.

The VM is Ubuntu, and comes with a Qtopia SDK (surprise, surprise). Use <tt>krandrtray</tt> to switch to correct screen resolution. I had to install a new version of VMware to get this running, but unsure if this is really necessary. For the VMware stuff, you might need to have the kernel headers. Remember that Ubuntu calls them ''linux-headers''. Also remember this is Ubuntu, for root access just <tt>sudo command</tt>.

Fonts were huge in my version. Use <tt>KMenu -> Settings -> Appearance and Themes -> Fonts</tt>. Click <tt>Adjust all fonts</tt>, check <tt>size</tt>, choose <tt>7</tt>. Same with <tt>Qt Assistant</tt>, choose for the menu <tt>Edit -> Font Settings</tt>.

==Manually build SDK==

If you prefer to dirty your hands and to have a SDK on your host linux system, you may build your Qtopia image, and SDK manually:

TBD, actually refer to the excellent article at [http://blog.wolfman.com/articles/2008/08/27/porting-xgps-to-qtopia-for-the-freerunner]

''n.b. this methods will build applications suitable only for the Qtopia firmware''

=Development with QtCreator (C++ and Qt4)=
Easy crosscompiling and packaging with [[QtCreator]] IDE

=Development with Eclipse (C++ and Qt4)=

If you like to develop tools with C++ and Qt4 only with the Toolchain, see [[Development with Eclipse]]

=Developing with FSO based images=
You have to prepare an oe build tree using the makefile at http://downloads.freesmartphone.org, read [[Mokomakefile]] article, install needed tools and type the following commands as a normal unprivileged user:

<pre>
mkdir fso
cd fso
wget http://downloads.freesmartphone.org/Makefile
make setup
cd fso-unstable
make create-topdir
</pre>

You are now ready to build Qt by typing:
<pre>
. setup-env
bitbake qt4-x11-free
</pre>
After that you'll have staging Qt arm libraries and x86 tools to build your application.
==Quick instructions for SHR unstable==
sudo mkdir -p /oe/shr
cd /oe/srh
wget http://shr.bearstech.com/Makefile
make setup
cd shr-unstable
. setup-env
bitbake qt4-x11-free
==Using a devshell==
You may use a modified environment to build your application interactively. At first you have to bitbake the dev shell:
<pre>bitbake devshell</pre>
Now create a text file 'qt-arm.env' as this:
<pre>
OE_TREE=/oe/openmoko-fso/tmp
. ${OE_TREE}/deploy/glibc/addons/arm-angstrom-linux-gnueabi-openmoko-om-gta02-devshell
export QMAKESPEC="${OE_TREE}/cross/armv4t/share/qt4/mkspecs/linux-gnueabi-oe-g++"
export OE_QMAKE_UIC="${OE_TREE}/staging/i686-linux/usr/bin/uic4"
export OE_QMAKE_MOC="${OE_TREE}/staging/i686-linux/usr/bin/moc4"
export OE_QMAKE_RCC="${OE_TREE}/staging/i686-linux/usr/bin/rcc4"
export OE_QMAKE_CC=$CC
export OE_QMAKE_CXX=$CXX
export OE_QMAKE_INCDIR_QT="${OE_TREE}/staging/armv4t-angstrom-linux-gnueabi/usr/include/qt4/"
export OE_QMAKE_LINK=$CXX
export OE_QMAKE_LIBDIR_QT="${OE_TREE}/staging/armv4t-angstrom-linux-gnueabi/usr/lib"
export PS1="\[\033[01;33m\]cross-compile-qt-shell\[\033[01;34m\] \w \$\[\033[00m\] "

</pre>
''Set OE_TREE to point to your OE tree path''

Now change your current directory to your qt .pro file path and type:
<pre>
. /path/to/qt-arm.env
qmake-qt4
make
</pre>

That's all! :)))

You may now create an alias or a simple batch like this to deploy and run your application:
<pre>
#!/bin/bash
scp arm-executable root@neo-ip:/tmp/
ssh -Y root@neo-ip "/tmp/executable
</pre>

to have X11 forwarding or
<pre>ssh -Y root@neo-ip "DISPLAY=:0 /tmp/executable"</pre>
to launch it on the device display with local stdout/stderr

''consider to enable ssh public authentication''

==Using an OE bitbake recipie==
If you want to build your application in batch mode you have to create a bitbake .bb recipie file. This is not suitable to fast build/debug cycles but is a necessary step if you want to insert your project in official feed/distributions like angstrom, fso based images, 2008.x and so on. It is a quickway to create a .opkg file too!

A simple skeleton may be:

<pre>
SECTION = "x11/libs"
PRIORITY = "optional"
HOMEPAGE = "http://yourproject.org"
LICENSE = "GPL QPL"
DEPENDS = "qt4x11"

SRC_URI = "svn://your_svn_server/some_path;module=trunk;proto=https;rev=xxx"

S = "${WORKDIR}/trunk"

inherit qt4x11

do_configure() {
${OE_QMAKE_QMAKE}
}

do_compile() {
oe_runmake
}

do_install() {
install -d ${D}${bindir}
install -m 0755 your_application_executable ${D}${bindir}
}

ALLOW_EMPTY = ""
RDEPENDS_${PN} = "qt4-x11-free"
FILES_${PN} = "${bindir}/your_application_executable"
</pre>

This assumes you have an svn server for your sources, if not, SRC_URI has to be modified. To point a directory local to the build host you may use

SRC_URI=:///absolute_path_to/source_dir
and
S=${WORKDIR}/source_dir

You have to make bitbake knows about your bb file, so edit the file fso/fso-unstable/conf/local.conf and add the following line:
BBFILES += "/path/to/dir_containing_somename.bb/*.bb"

You can now do:
bitbake somename

If it compiles fine, you'll find in the tmp/deploy/glibc/ipk/armv4t an ipk package of your application, you may copy it to the device and install usually with opkg.

You may be able to use the FSO framework using the QT dbus module.

=Developing for 2008.x=
On 2008.x qt library is already shipped in /opt/Qtopia, but there is no staging files you may use to build application against it. This is in discussion, and actually you may use some workarounds.

The first is bitbaking qt4-x11-free with the official [[Mokomakefile]], and proceed as on the FSO section, but you have to load the correct libraries with LD_LIBRARY_PATH before running your application.

The second is to use build tools in the work section of the oetree as they whould be in the staging area (TBD)

To interact with the middleware you should use Qtopia library (note not qt library), but this is undocumented/untested/unconfirmed.
=Native compilation=
Native compilation is slow but possible.
==Debian based==
This is the fastest way to have a full development environment on the device
apt-get install libqt4-dev build-essential

==Gentoo==
emerge qt
but it's very slow, actually binary package cross compilation is not possible.
==Openembedded based==
The last time I tried that I was not able to found qmake/uic/moc for the target device, howewer it should be possible trying to unpack qt sources on the device and produce them manually.

=Known issues=
* on Angstrom/FSO there is no support for sqlite driver, this is discussed on openembedded-devel mailinglist.
* on FSO aux/power button does not brings up keyPressed events, you have to use FSO dbus Event api
* on illume if you open/close a dialog the parent window does not return in active state, this would be useful if you want to filter FSO dbus event api based on it (this has to be checked on other windows manager too)
* with <=480 horizontal screen resolution QMessageBox::* has serious problems, stalling the calling application, reported to qt issue tracker
* weird painting/font-rendering on ARM platform due to definition of qreal as float, this was signaled to trolltech, waiting for feedbacks
=Tip and Tricks=
==Window Managers==
Here some tips for a good interaction with window managers.
===Matchbox===
With common matchbox configuration (e.g. Hackable:1) you'll have:
* QMainWindow->show()/showMaximized will show them maximized with visible matchbox-panel
* QMainWindow->showFullscreen() will show them fullscreen, with hided matchbox-panel
* QDialog->show()/showFullScreen will be showed normally, centered and with a drag&close titlebar
* QDialog->showMaximized() will be showed maximized and with titlebar, the last will cover matchbox-panel
* QWidget's behaviour is the same of QMainWindow

QDialog issues:
* Creating an unparented QDialog will create an "always on top" window!, if you have a top level widget showed too and switch to another application, you cannot switch to it again until the QDialog is closed.

''So, use always QMainWindow/QWidget for creating the main application form, use QDialog (always parented) for simple user interaction (yes/ok/no/close/messages etc.), and QWidget to show application subwindows and customized maximized dialogs.''

''Use setWindowModality if you want to emulate a QDialog with a Top Level QWidget''
===Illume===
* QMainWindow/QDialog/QWidget->show()/showMaximized will show them maximized with visible illume top bar
* QMainWindow/QDialog/QWidget->showFullscreen() will show them fullscreen, with hided illume top bar

How to show not fullscreen QDialog (as on matchbox?)

=News=

* 16 October 2008, openembedded repository was updated, the preferred version of Qt in "openmoko" distro (used by fso) is 4.4.1
* 16 October 2008, openembedded version bump from 4.4.1 to 4.4.3
* 17 March 2009, qt 4.5.0 emerged fine on my gentooized freerunner :) this release is faster, let's wait for a bump version in [[openembedded]] too.

[[Category:Application Developer]]
[[Category:Qt]]

GSM network registration

2009-11-16T10:29:25Z

RzR:

We'd like to know the real network registration status by our NEO devices in the world. Please provide some information about your NEO status! The question list as below:

== Instructions ==

1. What NEO device you are using? [[GTA01]] or [[GTA02]].

2. Where is your location and what is your network provider? eg. T-Mobile, San Francisco in USA.

3. When you boot the NEO, how long it takes to register the network? eg. in normal case, it should be able to register to a network in 1~2 minutes immediately.

4. What is your GSM firmware version? You can get this number by an AT command. Using [[USB_Networking|SSH]] to connect to your NEO, then type these commands:

root@fic-gta02:~# [[Gsmd|libgsmd-tool]] -m atcmd
AT+CGMR
STR=`AT+CGMR'
RSTR=`+CGMR: "HW: GTA02BV5, GSM: gsm_ac_gp_fd_pu_em_cph_ds_vc_cal35_ri_36_amd8_ts0-Moko6"'

5. What is your [[IMEI]] code? Check by using this [[Hardware:AT Commands|AT command]] like previous steps.
AT+CGSN
STR=`AT+CGSN'
RSTR=`+CGSN: 000000000000000'

6. if NEO takes over 3 minutes to register to the network or it just re-register to the network again and again. Please attach your gsm log file ('/tmp/gsm.log') to our bugzilla, we already created a bug for [http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1024 this issue].

(#4 and #5 Under FSO/frameworkd - use "mdbus -s org.freesmartphone.ophoned /org/freesmartphone/GSM/Device GetInfo" to retrieve both IMEI and version string at once - mdbus is provided by the package 'mickeydbus' if not already installed)

In qtopia/qtextended, go into Applications->System Info->Modem. Look for 'Revision'.

== Results table ==

{| border="1"
| Owner || Location ||| Network Provider || How/When purchased [[SIM card]] || Device || GSM firmware || IMEI || Status || GSM log
|-
| [[User:MichaelShiloh]] || San Francisco, CA, USA ||T-Mobile|| with phone, > 2years ||GTA01||Moko6||YES||just fine||no
|-
| [[User:MichaelShiloh]] || San Francisco, CA, USA ||AT&T|| with phone, 8/28/07 ||GTA01||Moko6||YES||takes several minutes to register, home network rejects, CME error 32, reregisters continuously||no
|-
| [[User:MichaelShiloh]] || San Francisco, CA, USA ||AT&T|| replacement for one received with phone, 3/17/08 ||GTA01||Moko6||YES||preliminary test: registers promptly to home network. Will test in various locations and report back.||no
|-
| [[User:MichaelShiloh]] || San Francisco, CA, USA ||AT&T|| prepaid, no phone, 3/13/08 ||GTA01||Moko6||YES||just fine in some locations, but in others it takes several minutes to register and reregisters continuously. however, always better than card that came with phone||no
|-
| [[User:SpeedEvil]] || Fife, Scotland, UK||T-Mobile||PAYG with phone 7/2007||GTA01||Moko1||YES||Just fine||no
|-
| [mailto:erin_yueh@openmoko.com Erin Yueh] || Taipei, Taiwan || TW mobile || || GTA02BV5 || Moko6 || NO || Normal, can register to the network immediately|| no
|-
| [mailto:marcus.bauer@gmail.com Marcus Bauer] || Nice, France || Orange || || GTA01Bv4 || Moko4 || YES || Registers immediately and stays registered for ~10 minutes before the re-registering loop starts once per minute|| [http://bugzilla.openmoko.org/cgi-bin/bugzilla/attachment.cgi?id=554&action=view log]
|-
| [mailto:ahvenas@gmail.com Henrik Pihl] || Kuressaare, Estonia || Elisa || || GTA01Bv4 || Moko4 || YES || Normal, can register to the network immediately, but starts reconnecting to the network in the first minutes.|| [http://bugzilla.openmoko.org/cgi-bin/bugzilla/attachment.cgi?id=555&action=view log]
|-
| [[User:MarcinHrwJuszkiewicz | Marcin 'Hrw' Juszkiewicz]] || Poznań, Poland || Era (Heyah) || prepaid, bought in October 2007, never charged, expired || GTA01Bv4 || phase0 phone (red PCB) with old GSM firmware || YES || Card expired, home network rejects it with CME Error 32 (emergency calls only), system displays "Registering..." for several minutes. || NO
|-
| [[User:MarcinHrwJuszkiewicz | Marcin 'Hrw' Juszkiewicz]] || Poznań, Poland || PlusGSM || prepaid, several years old, not charged || GTA01Bv4 || phase0 phone (red PCB) with old GSM firmware || YES || Registered after entering PIN. Normal work after register. || NO
|-
| [mailto:plr@udgaard.com Peter Rasmussen] || Copenhagen Denmark || DK Sonofon || Pre-paid BiBoB service since Oct. 2007 || GTA01Bv4 || Moko1 || YES || Registered immediatly after entering PIN. Works after that. No /tmp/gsm.log appears || NO
|-
| [[User:Kevin_Dean | Kevin Dean]] || Washington DC Metro Area, USA || T-Mobile || || GTA01Bv4 || Moko1 || YES || Normal, can register to the network immediately, no PIN needed|| [http://www.monochromementality.com/data/files/logs/openmoko/2008-03-17/gsm.log.edited Log (Replaced my wife's # with 9991231122)]
|-
| [[User:Dennis_Wollersheim | Dennis Wollersheim]] || Melbourne, Australia || Telstra || || GTA01Bv4 || Moko4 || Yes || Registers quickly, reregisters every 30 seconds or so|| [http://bugzilla.openmoko.org/cgi-bin/bugzilla/attachment.cgi?id=556&action=view gsm log]
|-
| [[User:thomasg | Thomas Gstädtner]] || Nuremberg, Germany || T-Mobile (Ericsson RBS2206, GSM900) || 2004 || GTA01Bv4 || Moko 1 || Yes || Registers nearby immediately, w/ PIN or w/o || NO
|-
| [[User:thakoman | thakoman]] || Kassel, Germany || vodafone d2 || 2008 || GTA02BV5 || Moko 8 || Yes || The first SIM wasn'n found at all, The second made one call and after some minutes the firmware died!? Since that same issues as with the first one || No
|-
| [[User:emdete | emdete]] || Duesseldorf, Germany || vodafone d2 || 200x || GTA01Bv4 || Moko 1 || Yes || No problems || No
|-
| [[User:emdete | emdete]] || Duesseldorf, Germany || vodafone d2 || 200x || GTA02 || Moko 6 || No || Does not register, pin entry works, net scan also. || No
|-
| [[User:emdete | emdete]] || Duesseldorf, Germany || e-plus || 200x || GTA02 (same as above) || Moko 6 || No || No problems || No
|-
| [[User:ScaredyCat | ScaredyCat]] || Ipswich, UK || Virgin || 2007 || GTA01 || Moko 1 || Yes || No problems || No
|-
| [[User:ScaredyCat | ScaredyCat]] || Lelystad, Netherlands || Virgin (Roaming on T-Mobile NL) || 2007 || GTA01 || Moko 1 || Yes || No problems || No
|-
| [[user:jluis|jluis]] || Barcelona, Spain || Orange (Amena) || 082007 || GTA01Bv4 || Moko1 || YES || No problems|| No
|-
| [[user:jluis|jluis]] || Barcelona, Spain || Vodafone || phone > 3 years || GTA01Bv4 || Moko1 || YES || No problems|| No
|-
| [[User:Joachim | Joachim Jaeger]] || Eschbach, Germany || O2 || Fonic prepaid card, 01/2008 || GTA01Bv4 || Moko 4 || YES || Registers immediately after entering PIN. Normal work after register. || NO
|-
| [[user:liuxf|liuxf]] || Beijing, China || CU-GSM || 2006 || GTA01Bv4 || Moko1 || YES || No problems|| No
|-
| [[user:ismo|ismo]] || Zurich, Switzerland || sunrise || 2007 || GTA01Bv4 || Moko1 || YES || No problems || No
|-
| [[User:emdete | emdete]] || Duesseldorf, Germany || vodafone || 200x || GTA02 || Moko 7 || Yes || No problems || No
|-
| [[User:homyx | homyx]] || Ingolstadt, Germany || o2 || 2005, 2007 || GTA01 || Moko 1 || yes || No Problems || No
|-
| [[User:BasilK | basilk]] || Moskow, Russia || MegaFon || 2008 || GTA01Bv4 || Moko 4 || YES || No Problems || No
|-
| [[User:ibb | Ib Bentzen]] || Copenhagen, Denmark || TDC Mobil (Telmore) || 4 yrs || GTA01Bv4 || Moko4 || YES || OK || No
|-
| [[User:Zrich | zrich]] || Cambridge, MA, USA || Cingular || > 3 Years || GTA02 || Moko7 || Yes || No Problems || No
|-
| [[User:Infoport | William Vidrine]] || Greensboro, NC, USA || AT&T || replaced SIM sold with service Jul-18-08; model 71234 O 4022 || GTA02 || Moko8 || Yes || doesn't try to register on boot; sometimes takes switching on/off to register; re-registers with Home network frequently || No
|-
| [[User:robolange | Robert Lange]] || Philadelphia, PA, USA || AT&T || obtained with AT&T prepaid phone in July 2008; model 71234 O 4022 || GTA02Bv5 || Moko8 || Yes || Had problems with OM2007.2 occasionally failing to power up the antenna, and with losing GSM connection necessitating a reboot every few hours. With OM2008.9, I see none of these problems and the voice/sms works fine. || N/A
|-
| KB || Denmark || TDC || From TDC business in 2007 (64K43) didn't work, got new card for free (64K23) and that worked! || GTA02Bv5 || Moko8 || ¿What? || Works with new card || File not found
|-
| clare johnstone||Perth, Australia ||Vodafone AU || Prepaid 10 days||GTA02bv5 ||Moko8||YES ||no service briefly 2 min intervals for 10 hours today||MDBUS listing
|-
| [[User:gercamjr | Gerardo Camorlinga]]||Amarillo, TX, USA ||ATT || Prepaid $15 Motorola phone, pay as you go plan ||GTA02 ||Moko8||YES ||works great, used the gui script from [http://wiki.openmoko.org/wiki/Manually_using_GPRS Manually using GPRS]||No
|-
| [[User:pini | Pini]]||Lyon, France ||SFR || > 3 years ||GTA02Bv5 ||??||YES ||Just fine||No
|-
| [[User:W23 | w23]] || Novosibirsk, Russia || MegaFon || prepaid, ~2005 || GTA02 || Moko9-beta || Yes (?) || No problems || No
|-
| [[User:RzR | RzR]] || France || simyo.fr || prepaid, ~200911 || GTA02 || Moko9-beta1 || Yes || No problems on qtmoko || No
|-

== See also ==
* [[FreeRunner unable to work with 3G SIM cards]]

[[Category:GSM]]

GSM network registration

2009-11-16T09:02:48Z

RzR: /* Instructions */

We'd like to know the real network registration status by our NEO devices in the world. Please provide some information about your NEO status! The question list as below:

== Instructions ==

1. What NEO device you are using? [[GTA01]] or [[GTA02]].

2. Where is your location and what is your network provider? eg. T-Mobile, San Francisco in USA.

3. When you boot the NEO, how long it takes to register the network? eg. in normal case, it should be able to register to a network in 1~2 minutes immediately.

4. What is your GSM firmware version? You can get this number by an AT command. Using [[USB_Networking|SSH]] to connect to your NEO, then type these commands:

root@fic-gta02:~# [[Gsmd|libgsmd-tool]] -m atcmd
AT+CGMR
STR=`AT+CGMR'
RSTR=`+CGMR: "HW: GTA02BV5, GSM: gsm_ac_gp_fd_pu_em_cph_ds_vc_cal35_ri_36_amd8_ts0-Moko6"'

5. What is your [[IMEI]] code? Check by using this [[Hardware:AT Commands|AT command]] like previous steps.
AT+CGSN
STR=`AT+CGSN'
RSTR=`+CGSN: 000000000000000'

6. if NEO takes over 3 minutes to register to the network or it just re-register to the network again and again. Please attach your gsm log file ('/tmp/gsm.log') to our bugzilla, we already created a bug for [http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1024 this issue].

(#4 and #5 Under FSO/frameworkd - use "mdbus -s org.freesmartphone.ophoned /org/freesmartphone/GSM/Device GetInfo" to retrieve both IMEI and version string at once - mdbus is provided by the package 'mickeydbus' if not already installed)

In qtopia/qtextended, go into Applications->System Info->Modem. Look for 'Revision'.

== Results table ==

{| border="1"
| Owner || Location ||| Network Provider || How/When purchased [[SIM card]] || Device || GSM firmware || IMEI || Status || GSM log
|-
| [[User:MichaelShiloh]] || San Francisco, CA, USA ||T-Mobile|| with phone, > 2years ||GTA01||Moko6||YES||just fine||no
|-
| [[User:MichaelShiloh]] || San Francisco, CA, USA ||AT&T|| with phone, 8/28/07 ||GTA01||Moko6||YES||takes several minutes to register, home network rejects, CME error 32, reregisters continuously||no
|-
| [[User:MichaelShiloh]] || San Francisco, CA, USA ||AT&T|| replacement for one received with phone, 3/17/08 ||GTA01||Moko6||YES||preliminary test: registers promptly to home network. Will test in various locations and report back.||no
|-
| [[User:MichaelShiloh]] || San Francisco, CA, USA ||AT&T|| prepaid, no phone, 3/13/08 ||GTA01||Moko6||YES||just fine in some locations, but in others it takes several minutes to register and reregisters continuously. however, always better than card that came with phone||no
|-
| [[User:SpeedEvil]] || Fife, Scotland, UK||T-Mobile||PAYG with phone 7/2007||GTA01||Moko1||YES||Just fine||no
|-
| [mailto:erin_yueh@openmoko.com Erin Yueh] || Taipei, Taiwan || TW mobile || || GTA02BV5 || Moko6 || NO || Normal, can register to the network immediately|| no
|-
| [mailto:marcus.bauer@gmail.com Marcus Bauer] || Nice, France || Orange || || GTA01Bv4 || Moko4 || YES || Registers immediately and stays registered for ~10 minutes before the re-registering loop starts once per minute|| [http://bugzilla.openmoko.org/cgi-bin/bugzilla/attachment.cgi?id=554&action=view log]
|-
| [mailto:ahvenas@gmail.com Henrik Pihl] || Kuressaare, Estonia || Elisa || || GTA01Bv4 || Moko4 || YES || Normal, can register to the network immediately, but starts reconnecting to the network in the first minutes.|| [http://bugzilla.openmoko.org/cgi-bin/bugzilla/attachment.cgi?id=555&action=view log]
|-
| [[User:MarcinHrwJuszkiewicz | Marcin 'Hrw' Juszkiewicz]] || Poznań, Poland || Era (Heyah) || prepaid, bought in October 2007, never charged, expired || GTA01Bv4 || phase0 phone (red PCB) with old GSM firmware || YES || Card expired, home network rejects it with CME Error 32 (emergency calls only), system displays "Registering..." for several minutes. || NO
|-
| [[User:MarcinHrwJuszkiewicz | Marcin 'Hrw' Juszkiewicz]] || Poznań, Poland || PlusGSM || prepaid, several years old, not charged || GTA01Bv4 || phase0 phone (red PCB) with old GSM firmware || YES || Registered after entering PIN. Normal work after register. || NO
|-
| [mailto:plr@udgaard.com Peter Rasmussen] || Copenhagen Denmark || DK Sonofon || Pre-paid BiBoB service since Oct. 2007 || GTA01Bv4 || Moko1 || YES || Registered immediatly after entering PIN. Works after that. No /tmp/gsm.log appears || NO
|-
| [[User:Kevin_Dean | Kevin Dean]] || Washington DC Metro Area, USA || T-Mobile || || GTA01Bv4 || Moko1 || YES || Normal, can register to the network immediately, no PIN needed|| [http://www.monochromementality.com/data/files/logs/openmoko/2008-03-17/gsm.log.edited Log (Replaced my wife's # with 9991231122)]
|-
| [[User:Dennis_Wollersheim | Dennis Wollersheim]] || Melbourne, Australia || Telstra || || GTA01Bv4 || Moko4 || Yes || Registers quickly, reregisters every 30 seconds or so|| [http://bugzilla.openmoko.org/cgi-bin/bugzilla/attachment.cgi?id=556&action=view gsm log]
|-
| [[User:thomasg | Thomas Gstädtner]] || Nuremberg, Germany || T-Mobile (Ericsson RBS2206, GSM900) || 2004 || GTA01Bv4 || Moko 1 || Yes || Registers nearby immediately, w/ PIN or w/o || NO
|-
| [[User:thakoman | thakoman]] || Kassel, Germany || vodafone d2 || 2008 || GTA02BV5 || Moko 8 || Yes || The first SIM wasn'n found at all, The second made one call and after some minutes the firmware died!? Since that same issues as with the first one || No
|-
| [[User:emdete | emdete]] || Duesseldorf, Germany || vodafone d2 || 200x || GTA01Bv4 || Moko 1 || Yes || No problems || No
|-
| [[User:emdete | emdete]] || Duesseldorf, Germany || vodafone d2 || 200x || GTA02 || Moko 6 || No || Does not register, pin entry works, net scan also. || No
|-
| [[User:emdete | emdete]] || Duesseldorf, Germany || e-plus || 200x || GTA02 (same as above) || Moko 6 || No || No problems || No
|-
| [[User:ScaredyCat | ScaredyCat]] || Ipswich, UK || Virgin || 2007 || GTA01 || Moko 1 || Yes || No problems || No
|-
| [[User:ScaredyCat | ScaredyCat]] || Lelystad, Netherlands || Virgin (Roaming on T-Mobile NL) || 2007 || GTA01 || Moko 1 || Yes || No problems || No
|-
| [[user:jluis|jluis]] || Barcelona, Spain || Orange (Amena) || 082007 || GTA01Bv4 || Moko1 || YES || No problems|| No
|-
| [[user:jluis|jluis]] || Barcelona, Spain || Vodafone || phone > 3 years || GTA01Bv4 || Moko1 || YES || No problems|| No
|-
| [[User:Joachim | Joachim Jaeger]] || Eschbach, Germany || O2 || Fonic prepaid card, 01/2008 || GTA01Bv4 || Moko 4 || YES || Registers immediately after entering PIN. Normal work after register. || NO
|-
| [[user:liuxf|liuxf]] || Beijing, China || CU-GSM || 2006 || GTA01Bv4 || Moko1 || YES || No problems|| No
|-
| [[user:ismo|ismo]] || Zurich, Switzerland || sunrise || 2007 || GTA01Bv4 || Moko1 || YES || No problems || No
|-
| [[User:emdete | emdete]] || Duesseldorf, Germany || vodafone || 200x || GTA02 || Moko 7 || Yes || No problems || No
|-
| [[User:homyx | homyx]] || Ingolstadt, Germany || o2 || 2005, 2007 || GTA01 || Moko 1 || yes || No Problems || No
|-
| [[User:BasilK | basilk]] || Moskow, Russia || MegaFon || 2008 || GTA01Bv4 || Moko 4 || YES || No Problems || No
|-
| [[User:ibb | Ib Bentzen]] || Copenhagen, Denmark || TDC Mobil (Telmore) || 4 yrs || GTA01Bv4 || Moko4 || YES || OK || No
|-
| [[User:Zrich | zrich]] || Cambridge, MA, USA || Cingular || > 3 Years || GTA02 || Moko7 || Yes || No Problems || No
|-
| [[User:Infoport | William Vidrine]] || Greensboro, NC, USA || AT&T || replaced SIM sold with service Jul-18-08; model 71234 O 4022 || GTA02 || Moko8 || Yes || doesn't try to register on boot; sometimes takes switching on/off to register; re-registers with Home network frequently || No
|-
| [[User:robolange | Robert Lange]] || Philadelphia, PA, USA || AT&T || obtained with AT&T prepaid phone in July 2008; model 71234 O 4022 || GTA02Bv5 || Moko8 || Yes || Had problems with OM2007.2 occasionally failing to power up the antenna, and with losing GSM connection necessitating a reboot every few hours. With OM2008.9, I see none of these problems and the voice/sms works fine. || N/A
|-
| KB || Denmark || TDC || From TDC business in 2007 (64K43) didn't work, got new card for free (64K23) and that worked! || GTA02Bv5 || Moko8 || ¿What? || Works with new card || File not found
|-
| clare johnstone||Perth, Australia ||Vodafone AU || Prepaid 10 days||GTA02bv5 ||Moko8||YES ||no service briefly 2 min intervals for 10 hours today||MDBUS listing
|-
| [[User:gercamjr | Gerardo Camorlinga]]||Amarillo, TX, USA ||ATT || Prepaid $15 Motorola phone, pay as you go plan ||GTA02 ||Moko8||YES ||works great, used the gui script from [http://wiki.openmoko.org/wiki/Manually_using_GPRS Manually using GPRS]||No
|-
| [[User:pini | Pini]]||Lyon, France ||SFR || > 3 years ||GTA02Bv5 ||??||YES ||Just fine||No
|-
| [[User:W23 | w23]] || Novosibirsk, Russia || MegaFon || prepaid, ~2005 || GTA02 || Moko9-beta || Yes (?) || No problems || No
|-

== See also ==
* [[FreeRunner unable to work with 3G SIM cards]]

[[Category:GSM]]

Neo FreeRunner Hardware Issues

2009-11-16T08:53:41Z

RzR: /* Some SIMs Don't Work */

{{Neo FreeRunner Menu}}

This is a community-written page that discusses '''hardware issues''' with the FreeRunner/[[GTA02]] device. Information here is unofficial (and possibly incorrect) unless otherwise stated. Corrections and clarifications from Openmoko employees would be greatly appreciated.

Please '''DON'T PANIC''' when reading this page. Please give Openmoko employees time to investigate these issues and to develop a solution. Some of the items may turn out to be non-issues, or may have software workarounds. The FreeRunner's software is still under heavily development and can help fix most of this problems.

Please always file a bug report on the issues and mention the bug report number in this page. Otherwise it is impossible to check if a bug has been fixed or not.

=== Active Issues ===

==== Poor Audio Quality (FIXED) ====
Please use http://docs.openmoko.org/trac/attachment/ticket/2121/gsmhandset.state.new
for *all* Neo Freerunner. (2009-04-27 jOERG)

Issue: The person on the other end of a GSM phone call may experience poor audio quality, to the point where he/she cannot carry on a normal conversation.

There are three related aspects to this issue:
* Call is too quiet (mixer settings for mic and/or earpiece are set too low)
* Caller hears a loud echo of their own voice [http://docs.openmoko.org/trac/ticket/1267 #1267]
* Buzzing noise caused by GSM radio interference [http://docs.openmoko.org/trac/ticket/883 #883] [http://docs.openmoko.org/trac/ticket/1352 #1352] See [[GSM buzz]].

Affects: all devices but only some users (depending on many factors)

The source of the GSM buzz has been [http://lists.openmoko.org/pipermail/hardware/2008-August/000415.html identified]. It's a mere hw-issue, depending on the way you hold the device, and the local situation created by network settings made by the GSM-provider (mainly 1800/1900 seems to be affected), as well as your position relative to basestation. There is no way to fix GSM buzz by mixer-setting modifications. So all suggested settings here may improve a little the volume of buzz during you're *not* speaking only, while relative ratio of buzz/voice level while speaking can't be changed by mixer settings.

Some [http://lists.openmoko.org/pipermail/hardware/2008-August/000451.html hidden Calypso commands] may help with the echo problem.

hexedit, ghex /opt/Qtopia/plugins/phonevendors/libficgta01vendor.so
search "AT%N0125" and change to "AT%N0187"

Workarounds:

# Using a bluetooth headset is a possibility.
# Using external GSM-antenna will stop buzz.

Due to the multiple factors influencing the result of a single test, it's nearly impossible to find a setup that lets you compare for a decent "before / after" result. If you ever took an old analog TV portable to a place where you had to fiddle around with the antenna to try and make the snow and shadows vanish off the picture, you might have gotten a slight idea of what it's like to reproduce the same situation for decent tests. So probably most of the suggested alsa-improvements are mere random results. Even if they worked for provider A evidently, this doesn't mean there's any improvement by using same settings for provider B.

This being said, here they are:

# Better mixer settings: One confirmed good settings are here: http://www.mail-archive.com/support@lists.openmoko.org/msg00564.html. Please change accordingly in /usr/share/openmoko/scenarios/gsmhandset.state. Should eliminate/lessen echo and buzz problems. [[Neo alsamixer]] is the main article for setting the mixer settings.

===== Better set of mixer settings =====

Regarding 2. in the previous paragraph, here are my further tweaked settings:

[mic volume & buzz problem]
* 'Mono Playback Volume' (95)
* 'Mono Sidetone Playback Volume' (2)
* 'Mic2 Capture Volume' (3)
[speaker volume & echo problem]
* 'Speaker Playback Volume' (112)
* 'Bypass Playback Volume' (5)

Lowering Mono Sidetone eliminated the buzz problem better. Please try out and report if you have good success... --[[User:TimoJyrinki|TimoJyrinki]] 08:19, 16 October 2008 (UTC)

==== Can't boot with discharged or missing battery (FIXED) ====

Issue: Neo FreeRunner requires battery power to boot, because Neo FreeRunner consumes too much current while booting to boot with only a charger. Since charging isn't enabled until the Neo FreeRunner has booted, this means that a discharged battery can not be charged. Some versions of uBoot don't continue booting and just charge bat (red LED flashes constantly) when probing bat voltage shows it's too weak to start FR. Let the device sit and charge for an hour, then reboot.

Affects: All A5, older A6. With change of Vsys buffer capacitor to 100uF this issue has been fixed for good.

Fixed(?) with [http://lists.openmoko.org/pipermail/openmoko-kernel/2008-July/003799.html Werner Almesberger patches] - [http://lists.openmoko.org/pipermail/commitlog/2008-July/005403.html more here] [http://lists.openmoko.org/pipermail/community/2008-July/023392.html additional information]

I think this patch finally fixes the problem:
[http://www.abanet.ch/~hug/moko/uboot-battery/ Philipp Hugs patches]

Workarounds:

#First test if your FR starts with no bat inserted. If it does you can forget about this whole topic.
# Make sure that the battery never discharges completely
# Use [[:Image:Nokia-charging-stand.jpg|external stand-alone charger]] (compatible with the Nokia BL-5C battery)
# Boot the FreeRunner with an [[Neo_FreeRunner_Battery#Compatible_Replacement_Batteries|alternative battery]], or with a spare GTA01 or GTA02 battery, plug USB power, then switch to the empty battery.
# Boot the FreeRunner with a 4.5VDC external power source (steady hand and great care involved), plug USB power, then insert the empty battery.
## Oscilloscope digital clip probes fit perfectly on the Freerunner's battery connectors. Make sure polarity is correct!
# Some users have reported that Neo FreeRunner '''is''' able to boot on USB power alone using the NOR u-boot, thus: press AUX, plug USB power, select boot. Reports of success would be appreciated.
## Does work with sequence described. If after pressing boot it just turns off again (happened a few times), then: press AUX, plug in USB power, cycle through the menu a few times to keep it from turning off without booting, after a minute or so press boot. [[User:Imrehg|Imrehg]] 08:34, 10 September 2008 (UTC)
## This does indeed work with sequence described. After pressing boot, the screen went blank for a few seconds, but then the beast came to life again. That saved the day! [[User:Edictor|Edictor]]
## Trifirmed. Neither USB connection nor wall charger was able to wake my phone. But in NOR u-boot it worked (connected to the computer). I think this trick hasn't failed to anyone. --[[User:Flamma|Flamma]] 12:11, 17 September 2008 (UTC)
## Unfortunately this is not working for me. My FreeRunner has been off for a few weeks and completely dead. I tried various combinations of holding aux and plugging in to both wall and computer, no luck. Tried with and without the battery in place, no luck. Aux and power button / just power / aux then power. No luck... --[[User:Safire|Safire]] 6 November 2008
## This is working ! It has prevent me from buying an external power charger. My freerunner had its battery discharged for about 2 weeks now, and I was able to boot and charge it. --[[User:JRD|JRD]] 23:37, 12 November 2008 (UTC)
## It has worked for me ! I have booted to 2008.9 Om with discharged battery (after connecting the FR to power supply and waiting a few minutes until AUX button red light stopped flashing) using the NOR boot menu. Tried the same with NAND boot menu and worked also !!! Then I could charge the battery. -- [[User:Emsyr|Emsyr]] 3:23, 20 November 2008 (UTC)
## I can boot to 2008.9 without battery and with USB connection = plug USB power (FR <-> PC) + press power button. However I cannot shutdown correctly. --[[User:Cynan|Cynan]] 13:43, 9 December 2008 (UTC)
## I can boot to 2008.9 without battery and with USB connection: press AUX button, then plug USB power, then press power button (keeping AUX pressed). NOTE that battery was fully charged. The problem wasn't battery but corrupted environment in NAND u-boot: with battery IN, no access to NOR u-boot
## Both my friend's freerunner and mine was completely discharged. This trick failed. Finally booted the freerunner with a BL-5C battery from an old nokia n-gage. With the power connected I then switched the batteries. --[[User:Unlotto|Unlotto]] 14:27, 25 January 2009 (UTC)
## Another confirmation that this works. You may use the computer-USB cable or the AC adapter. I held AUX, plugged in the USB, and the NOR boot menu started before I even hit the Power button. For some reason, I have to cycle through the menu once before I choose boot, otherwise it will power off as soon as it loads the kernel. I booted it, let it start up fully, and it continued charging. After a minute or two, as a test I shut down and tried rebooting normally. There was enough power in the battery at that point to boot normally from the AC adapter. Note, I did not encounter this problem (using the AC adapter) until after I "upgraded" from the pre-installed May 2008 u-boot to the December 2008 u-boot; perhaps that is relevant. --Robolange 05:53, 1 February 2008 (UTC)
## This did ''not'' work for me (with the 1.3.2-moko12 u-boot). However, I was able to "jumpstart" my Freerunner with a bench supply and some micro-clips, as suggested above. (Worried I would fry something, I tried at lower voltages first, but it didn't start up until I set the supply to 4.5v, with the OM USB charger also attached.) Once it was well into the Linux kernel boot sequence I removed the clips and put in the battery to charge. --[[User:Wiml|Wiml]] 05:30, 9 April 2009 (UTC)
## This worked for me. Now I'm not afraid of letting my FreeRunner discharge. [[User:Cristianpark|Cristianpark]] 20:00, 30 August 2009 (GMT -5)
See also:
:[[Neo_FreeRunner_Battery|Neo FreeRunner Battery]]

==== Battery discharges when charging completes ====

Issue: If the Neo FreeRunner has been charging, when charging completes, it seems to drain the battery and not turn on charging again. This seems to be bug of PMU-registers setup, that shows up when PMU has to handle bat autonomously (=suspend). There might be issues our current scheme relies on wake-interrupt at bat-full which doesn't succeed, or something like that.

Affects: Unknown.

Status:

This has been fixed in linux. See
http://docs.openmoko.org/trac/ticket/1158

==== Suspend/resume corrupts SD card's partition table ====

Issue: Suspend/resume corrupts the partition table of the SD card

Affects: Unknown.

Status:

[[https://docs.openmoko.org/trac/ticket/1802#comment:6 Patched kernel]] might solve the problem

Workarounds:

# [[https://docs.openmoko.org/trac/ticket/1802#comment:5 Script]] as a temporary workaround

See also:

:[[https://docs.openmoko.org/trac/ticket/1802 trac ticket]]

==== Some SIMs Don't Work ====

Issue: There are reports that some users cannot register with their GSM network when using certain [[SIM]] cards. See for example http://lists.openmoko.org/pipermail/community/2008-July/020370.html

It is possible that there is more than one issue involved here. The observed problems ''might'' (i.e. some items are only speculation at this point) be caused by:

* User error, not inserting the SIM in the correct orientation or not sliding the holder to the 'locked' position

* Software issues that result in a locked SIM (not properly prompting the user for a PIN and then passing this to the SIM)

* Mechanical issues with the SIM holder that prevent the pins from making reliable contact with the pads on the SIM. Note that only 6 of the 8 pins are used, and the remaining two are not connected.

* Electrical incompatibility (some tests show problems with 1.8V SIMs while 2.9V ones work OK)

* Firmware bugs in the TI Calypso GSM chipset. Note that one issue in this category was found and fixed on the GTA01 devices (#666 in Trac), and that specific problem should not affect the FreeRunner.

* Defective SIMs, i.e. ones that do not comply with the applicable standards and are acknowledged as being defective by the carrier (even if they happen to work in some phones).

* You may have true 3G operating at 2100 and your sim doesn't fallback to GSM. The Phone works on 850/1800/1900 or 900/1800/1900.

See also:

* http://wiki.openmoko.org/wiki/Carriers/ATT
* http://wiki.openmoko.org/wiki/Carriers/Rogers

Affects: Only a subset of users (details unknown).

Status: Fixed in GSM firmware moko10-beta2 or later. See [[GSM/Flashing]] for instructions. Please add your information to [[FreeRunner_unable_to_work_with_3G_SIM_cards]] or [[GSM network registration]]

Workarounds:

# Please document your existing SIM card and provider in the table [[FreeRunner_unable_to_work_with_3G_SIM_cards|here]].
# If the table mentioned above shows any SIM cards known to work with your provider, make note of these numbers.
# Contact your network provider and request a new SIM card. You may wish to print out the table mentioned above and bring it with you to the store.
# Add your experience with the new SIM card to the table mentioned above.

=== Known/Accepted Issues ===

This section lists items that are acknowledged as being less than ideal, but are considered to be acceptable in the shipping product. They will not be discussed in detail on this page.

* Poor performance + slow bus speed of the Glamo GPU - discussed to death on the mailing lists and IRC.
** stable-2.6.26 branch of kernel has wait states lowered, core speed increased from 50MHz to 80MHz and memory speed from 80MHz to 90MHz (the latter is also in stable branch) - these lessen the problem a bit, though it's slow still
* [http://lists.openmoko.org/pipermail/hardware/2008-April/000055.html GPS antenna switch] driven out-of-spec - does not appear to have a significant effect on device performance
* Poor low-frequency audio response with low-impedance headphones, e.g. as discussed in this thread: http://lists.openmoko.org/pipermail/openmoko-kernel/2008-March/001999.html (NOTE - this thread refers to pre-mass-production devices)
** Can be fixed to an semi-acceptable level (if not high fidelity most probably) by adjusting "Bass Volume" to full (15) and "Bass Filter" to "100Hz @ 8kHz" (bass will be boosted <= 600Hz when playing back at 48kHz) or "200Hz @ 8kHz" (<= 1200Hz @ 48kHz). The default is 130Hz @ 48kHz and does not help much with the more wider scope of low frequencies.
** Ideally someone would record output and find out which setting produces best output, ie. compensating for the loss of low frequencies without boosting too high frequencies with this "bass" boost.

Actually with 16 Ohm headphones the cutoff frequency is more than 2kHz, so even 1200Hz @ 48kHz seems to be not appropriate.
If you have 30 Ohm, it might be just correct setting.

=== Resolved Issues ===

These are issues that have been discussed in the past, but have been fixed (or turned out not to be a problem) for the mass-produced devices.

* Excessive LED current - Some early units lacked a current-limiting resistor for the LEDs. This has been fixed for the production units.
* Battery life - At this time it appears that the FreeRunner battery life will be acceptable once suspend/resume support has been implemented in software.
* slow GPS TTFF - see [[GPS Problems]]
==== Empty NOR Flash ====

Issue: NOR flash (backup copy of u-boot) is not programmed. [http://docs.openmoko.org/trac/ticket/1568 #1568]

Affects: Unknown - maybe only 1 or 2 devices? Also need to confirm that the bug report was from a mass-production unit rather than an earlier prototype.

Status: Solved. The new devices are tested better if they have the NOR flashed programmed and aren't shipped if the test fail.

Workarounds: Use the NAND copy of u-boot and be careful not to brick the device unless a debug-board is available.

==== Debug board has wrong vendor/product ID ====

Issue: A debug board is not reporting the expected USB Vendor/Product ID.

Affects: Only [http://lists.openmoko.org/pipermail/device-owners/2008-July/001775.html one report] has been seen so far.

Status: Probably a single case scenario.

Workarounds: Edit configuration files (e.g. openocd.conf) to use the IDs that the board is reporting.

== List of "Current issues" Imported from the "Community update page" ==
(to be sorted)

The information below has been collected from various sources, feel free to add questions and comments here.

===GPS Performance of the FreeRunner===
The poor GPS performance on the FreeRunner has been traced to an
interaction between the microSD card and the GPS unit. A software
and a hardware fixes are available, see [[GPS Problems]].

===GTA02 battery status===
While writing a device driver for the new battery which provides an accurate counter of the charge state of the [[GTA02]], the driver developer discovered that the device driver does not get a reading of the charge state due to a very long response time with only one I/O signal when trying to read the charge state. To be able to read the battery status properly, it has been written that it will be necessary to re-design that part of the GTA02 for hardware version GTA02A5 to use two I/O signals to reduce the response time (one for transmitting commands, one for receiving data?). This was fixed (see [http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=957#c1 Bug 957]).

=== SMedia 3362 Documentation & OpenGL ES Drivers ===
There is an open source kdrive driver being written for the GTA02 which will use hardware to accelerate the XRender extension. While the chip is capable of 3D graphics, no OpenGL ES driver/library is avaliable and Openmoko developers will not be writing one in the near future (although they have not ruled it out in the long-term).

Documentation for the SMedia 3362 has been promised ([http://lists.openmoko.org/pipermail/community/2007-September/010175.html see this post]). However, this refers to documentation Openmoko developers will be writing themselves, not the technical documentation SMedia have provided Openmoko with. The Openmoko developers had to sign an NDA with SMedia to obtain this documentation and are therefore unable to pass this information on to community developers. (See [http://lists.openmoko.org/pipermail/community/2007-November/011349.html this post] for details)

=== Draws too much current from USB ===
It may be that the Neo draws too much current from your USB host/hub, and that the USB host/hub switches off to prevent damages.

The behaviour is controlled by a complex interaction between soft- and hardware, see [[Forcing fast charge mode]] and [[USB host]]. It may be that the host negotiates more power than the Hub is willing to provide. In case of problems, try to limit the current to e.g. 400mA.

[[Category:Neo FreeRunner Hardware]]

2009-02-18T18:14:10Z

RzR: /* Pre-built binaries */

{{Languages|Openmoko under QEMU}}
[http://en.wikipedia.org/wiki/Qemu QEMU] can be used in at least 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]] (GTA01) hardware, although not all of it. Additionally, Neo FreeRunner emulation is a work-in-progress. When all of the emulator parts are more mature our code is going to be submitted and merged 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 (GTA01) 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 GTA01 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 contents in QEMU window unless "-nographic" is specified on command line.
|-
|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, or the [http://doc.trolltech.com/qtopia-4.3-snapshot/fd-ModemSimulator.html phonesim] modem simulator from the ''Qtopia'' project (use the --enable-phonesim switch to ./configure) as well as the [http://doc.trolltech.com/qtopia-4.3-snapshot/modem-emulator.html atinterface] modem emulator, also from Qtopia.
|-
|[[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.

== Neo FreeRunner emulation ==

The second line of Openmoko phones, the Neo FreeRunner (GTA02) saw various hardware changes and improvements since Neo1973 (GTA01). QEMU has fullest support for the GTA01 (the first model), but partial GTA02 emulation is also planned. This will only include the hardware components which were added in GTA02 and were not present in GTA01 (see [[Neo 1973 vs Neo FreeRunner]] for complete hardware difference list):

* The u-blox GPS chip (i.e. raw NMEA protocol).
* The Atheros AR6001 WLAN / WiFi chip (and SDIO bus).
* The two LIS accelerometers.
* 128MiB, 1.8V NAND chip instead of 64MiB.

What that means is that the emulated machine will internally not be exactly like Neo FreeRunner, but will be functionally the same. That in turn means that it needs a custom kernel because it's neither a GTA01 nor GTA02 internally. This kernel source will be provided as part of qemu. The bootloader used will be the GTA01 build of u-boot.

This approach is called paravirtualisation and is often used as an emulation solution for mobile platforms. For a userspace programmer (Application developers) the machine will be visible as a genuine GTA02. For a kernel hacker it will be a custom board.

If there's an initiative among the users, to emulate GTA02 hardware to a bigger extent than explained here, patches / improvements will be always welcome because the QEMU project seeks to emulate the real hardware and stay always as close as possible to physical hardware (in other words, full emulation is preferred over paravirtualisation in the QEMU upstream).

=== What hardware is supported ===

Below is a rough status information for each of the components.
{|
! Hardware !! Status !! Usage notes
|- style="background-color:#eeeedd;"
! colspan="3"|GTA01 hardware
|-
|Processor, on-chip and external peripherals || Work || See the GTA01 supported hardware chart above. This hardware is at the base of the Neo FreeRunner emulator. The same usage notes apply.
|- style="background-color:#eeeedd;"
! colspan="3"|GTA02 components
|-
|GPS || Works || A virtual GPS chip is connected to the second serial port of the virtual machine, exactly like on the Neo FreeRunner.
|-
|WLAN
|style="background-color:#ffffcc;"|Partial support
|The Atheros AR6001 (second firmware revision) is emulated to an extent that it gets detected by the kernel SDIO stack and registered as a network interface by the Atheros driver. It doesn't allow for actual network communication yet. The basic SDIO bus emulation is complete.
|-
|Accelerometers || Work || Two dummy accelerometers are connected to the virtual machine's I2C bus. They provide a constant 1G reading at the moment. One improvement idea to be implemented when there's some software available for testing, is to pass Qemu's SDL window movements as input to the virtual accelerometers, i.e. dragging the X window around would generate motion sensor events. These events would be two-dimensional but should be enough for Application developers to test their programs' interactions with the movements.
|}

== How to get it running ==

These instructions talk about the GTA01 emulator (default).

=== Using MokoMakefile ===

This is arguably the easiest way of building qemu-neo1973 since you won't need to deal with the compiling and flashing processes yourself. See [[Using_QEMU_with_MokoMakefile|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 takes less time than 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>
If you dont want gcc-3.x then you can apply patch from here
https://bugs.gentoo.org/show_bug.cgi?id=160627
like so
<pre>
$ patch -p2 < qemu-gcc4.patch
</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 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).
'''Note''' openmoko/env might be broken. It seems to fix it to change it to this instead.
<pre># The scripts will include this on startup to setup variables

src_dir="`pwd`"
script_dir_relative=openmoko
script_dir="$src_dir/$script_dir_relative"
uboot_symlink="$src_dir/u-boot.bin"
qemu_relative="arm-softmmu/qemu-system-arm -M gta02fake -m 130"
qemu="$src_dir/$qemu_relative"
flash_base=openmoko-flash.base
flash_image=openmoko-flash.image
make=make
which gmake && make=gmake
echo=echo
which gecho && echo=gecho
export make echo
dump_dir="$script_dir/vvfat"

qemu_monitor="$HOME/.qemu_monitor"
qemu_cmd () { $script_dir/qemu-cmd.pl "$qemu_monitor" "$*"; }

kernel_addr=0x30100000
splash_addr=0x36000000
splash_size=0x5000

# We don't want the "-latest" symlinks to match
kernel_wildcard="testing-om-gta01-*.uImage.bin"
rootfs_wildcard="openmoko-testing-om-gta01.rootfs.jffs2"
uboot_wildcard="gta01bv4-u-boot.bin"

download_dir="http://downloads.openmoko.org/daily/testing/"
dev_download_dir="$download_dir"
backup_download_dir="http://buildhost.automated.it/OM2007.2/"</pre>

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://bellard.org/qemu/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 ===

Debian ubuntu package is available at : http://www.newlc.com/en/openmoko-deb-packages-and-fosdem-debian-video

Win32 binaries shipped with firmware can be downloaded from [http://yorick.keymeulen.com/openmoko-emulator-bin-20070625.rar openmoko-emulator-win32-bin-20070625.zip]. Tested on MS Windows XP and Vista Business.
Note the file openmoko-emulator-bin-20070625.rar is offline, you can look for it in p2p network if it helps...

=== Neo FreeRunner (GTA02) ===

The instructions for running the emulator are the same for FreeRunner, but the final command line to invoke qemu changes. Instead of "-M gta01" as the machine name "-M gta02fake" has to be used.

The kernel supporting GTA02 emulator is obtained by applying the ''openmoko/linux-gta02-pseudo.patch'' patch found in qemu-neo1973 sources, to the 2.6.24 openmoko kernel (vanilla linux-2.6.24 + the openmoko patchset from http://svn.openmoko.org/branches/src/target/kernel/2.6.24.x/patches/). Since the GTA02 kernel support is still under heavy development, please refer to the openmoko/README file contained in qemu-neo1973 sources for the latest instructions on building the kernel.

If a normal Openmoko kernel is used under Neo FreeRunner emulator, it will simply run as if the machine was a GTA01 and not detect any of the new peripherals.

== Convenient Scripts ==

* openmoko/qemu-auto.sh

launches qemu and opens a unix socket for communication. All additional parameters are passed to qemu. (e.g. openmoko/qemu-auto.sh -nographic launches the virtual machine with no graphics etc.).

* openmoko/qemu-upload.sh <filename>

produces a SD card image with one partition with the given file(s) on it (you can pass a list of files) and inserts it into the phone. The Openmoko kernel should detect the event and the automounter should mount the partition. openmoko/qemu-auto.sh must be running already. If you pass no parameters, it ejects the media (the OM kernel is too dumb to detect this unfortunately). This will only work with gta01 emulation because gta02 has no SD.

* openmoko/qemu-quit.sh

powers the VM down cleanly.

* openmoko/qemu-gadget.sh

attempts to connect target's S3C USB slave to host's dummy HCD (if present and gadgetfs is mounted).

== 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://bellard.org/qemu/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.

== Simple network connection with pppd ==

One simple way to get a network connection from the emulated Neo is via an emulated serial port and [[pppd]]. Add ''-serial vc -serial pty'' to the [[QEMU command line]], and QEMU prints a device name on a line like "char device redirected to /dev/pts/12".

On the Neo side, open a terminal and run the command "pppd nodetach debug /dev/ttySAC1".

On the host computer side, open a root terminal and run the command "pppd nodetach debug 192.168.68.1:192.168.68.2 noauth /dev/pts/12", substituting the actual device name from above.

Now on the host computer side, you should be able to "ping 192.168.68.2" and "ssh root@192.168.68.2".

NB : If you see in pppd trace something like this "Received bad configure-rej: 12 06 00 00 00 00" again and again, you will ping but no application will work. It is probably the compression protocol (ccp) negotiation which fail. Add "noccp" to the two pppd commands like "pppd nodetach debug noccp /dev/ttySAC1".

== Setting up Internet connection for your qemu neo ==
Before you start, you have to have a working pppd or USB connection, ([[#Simple_network_connection_with_pppd|see the previous chapter]] and [[#Setting up USB connection|the next chapter]])

(I assume that your local ip-adress is 192.168.0.100 and your router is 192.168.0.1)

In qemu terminal (or via ssh) type:

<pre>
$ ifdown usb0
$ route add default gw 192.168.68.1
</pre>

Edit /etc/resolv.conf:
nameserver 192.168.0.1
This will be your host-computer DNS server.

On the host-computer type(as root , use sudo -i on ubuntu):

<pre>
echo 1 >> /proc/sys/net/ipv4/ip_forward
echo 1 >> /proc/sys/net/ipv4/ip_dynaddr

modprobe ip_tables
modprobe iptable_nat
modprobe ipt_MASQUERADE

iptables -t filter -F
iptables -t nat -F

iptables -t filter -P INPUT ACCEPT
iptables -t filter -P FORWARD ACCEPT
iptables -t filter -P OUTPUT ACCEPT
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT

iptables -t nat -A POSTROUTING -o eth0 -s 192.168.68.0/24 -j MASQUERADE
</pre>

(Where eth0 is your network interface connected to the router)

Thats it - now you can enjoy internet in qemu.

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

(in 2.6.25 (from ???) '''Device Drivers''' -> '''Network device 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)'''

(in 2.6.25 (from ???) '''Device Drivers''' -> '''Network device 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 build directory to make sure that the detection succeeded. If it didn't, correct your linux headers and reconfigure qemu.

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)

== Instant boot ==
Actually it not instant but a lot faster that actually booting.

The boot speed is achieved by saving the virtual machine.

Here are the steps required:
* Boot Qemu as you usually do
* Wait till the emulated Neo has finished starting up.
* Go to the ''virtual console 2'' (press ''ctrl+alt+2'')
* Save the virtual machine state using '''savevm''' ''tagName''
Next time you want to boot you can either:
# Start the emulator and go to the 2. console and ''loadvm tagName''
# Add '''-loadvm tagName'''
After a short delay the emulator is just like you left it when you saved the state.

I created a script that launches qemu using the -loadvm option, result: Instant Moko™

== See also ==
*[[Building Gadget USB Module]] - Helpful guide
*[[Xephyr]] - Openmoko on i386
*[[Xoo]] - Openmoko on i386

{{Languages|Openmoko_under_QEMU}}

[[Category:Emulation]]