Neo 1973 OpenOCD

From Openmoko

(Difference between revisions)
Jump to: navigation, search
(Changed neo1973 to the category page.)
(→‎openocd.cfg: added config for the current OpenOCD version)
 
(31 intermediate revisions by 18 users not shown)
Line 1: Line 1:
−
The [[:Category:Neo1973 Hardware | Neo1973]] uses an Assisted Global Positioning Ssystem, AGPS, technology. [[Hardware:AGPS | The Hardware:AGPS page]] provides information on GPS in general and the [[OpenMoko]] chip in particular.
+
== About OpenOCD ==
  
 +
[http://openocd.berlios.de/ OpenOCD] is a 100% free software On-chip-debugger for commonly-found ARM JTAG probes such as [[wiggler]], chamaeleon, jtag-key and others, like the [[Debug Board]].
  
−
== Q: Has anybody here ever used AGPS? I'd like to hear your experiences. ==
+
It provides a human-readable telnet interface for manually halting/resuming the target device, reading/writing registers and memory, etc.
  
−
Everybody who has used a modern GPS has used AGPS. It is usually called warm-start or hot-start. AGPS is purely a marketing term. To calculate the position a GPS chip needs:
+
In addition, it provides a RDI (remote debugger interface) on a TCP port. This interface can be used by gdb (the GNU Debugger).
−
    * almanac = coarse position of satellites
+
−
    * ephemeris = precise position of satellites
+
  
−
The almanac is broadcast in a loop of 12.5 minutes and valid for at least six weeks. The ephemeris is broadcast in a loop of 30 seconds and valid for ~2 hours.
+
The GTA01 development team used OpenOCD with a [[wiggler]] compatible probe as their ICE solution in the very beginning, until they had designed their own [[Debug Board]].
  
−
Time is mostly irrelevant, as modern chips synchronize within a second with the satellites.
+
== Getting OpenOCD ==
  
−
The receiver chipsets store this data in flash and load it from there onto the chip in order to _assist_ the hot or warm start.
+
=== MokoMakefile ===
  
−
AGPS now means to load the almanac and the ephemeris from elsewhere, i.e. via a network. For example for free from the american government: http://www.navcen.uscg.gov/gps/precise/default.htm
+
The [[MokoMakefile]] "make openmoko-devel-tools" target will build statically-linked openocd and [[dfu-util]] binaries. The "bitbake openocd-native" command may also be used.
  
−
AGPS is a nice convenience yet the success and proper functioning of TomTom and Navigon PDAs shows that you don't need that at all.
+
=== Debian Package ===
  
−
It's worth noting that the GPS on the neo is sensitive enough to pick up GPS signals in buildings.
+
We now have a Debian binary package of OpenOCD, available from http://people.openmoko.org/laforge/dpkg. Installing this package is the preferred method to install OpenOCD on your development machine like
−
If the spot you charge your neo happens to have a GPS signal, downloading the almanac from the satellites while it charges is essentially free, and takes no Internet access at all. Do this daily, and you get most of the benefit of aGPS.
+
  
−
== Q: The chip in the [[:Category:Neo1973 Hardware | Neo1973]] is a Global Locate AGPS. Anybody know what type? Hammerhead maybe? ==
+
dpkg --install openocd_82-1_i386.deb
−
A: It is the hammerhead.
+
  
−
== Q: I understand the concept of assisted GPS. But does the phone have its own antenna/receiver so that it can work without 'assistance'? ==
+
[http://packages.debian.org/openocd Debian/Unstable] also contains an OpenOCD build.
  
−
A: See above, the important part is the GPS and not the assistance. Antenna is thus compulsory.
+
=== Gentoo Ebuild ===
 +
There is an experimental ebuild for openocd in the [http://bugs.gentoo.org/show_bug.cgi?id=200689 gentoo bugzilla] - seems to be already in Gentoo now (May 2008) however you may need to edit the e-build because it has no keywords enabled by default: edit /usr/portage/dev-embedded/openocd/openocd-9999.ebuild and replace ''KEYWORDS=""'' with ''KEYWORDS="amd64 x86"''.  Remember to regenerate the digest afterwards:
 +
ebuild /usr/portage/dev-embedded/openocd/openocd-9999.ebuild digest
 +
# Build openocd
 +
emerge libftdi
 +
USE="ftdi ft2232" emerge openocd
  
−
== Q: Has anybody info on the whereabouts of assistance servers, especially in Belgium and Europe? ==
+
=== Source Code ===
  
−
A: They can be anywhere on the net. Alternatively a service from the cellphone operators. However, there may be occasions where you want a server 'near' where you are. See the later question on DGPS
+
OpenOCD Revision 82 and later have been proven to work with our [[QT2410]] and [[Neo1973]] target board and wiggler as well as Amontect JTAGkey and JTAGkey tiny.  You can e.g. check rev. 130 out of the OpenOCD subversion via
  
−
== Q: Using the assistance servers will probably mean that I will have to pay for that service. Any idea of the costs? ==
+
svn co -r 130 http://svn.berlios.de/svnroot/repos/openocd/trunk
  
−
A: They use the low cost of their chip as selling point. Their website implies that this is a service that comes with the chip. I'd call it not very clever if they are going to charge you - it would change their image from lowcost to money grabber and the reverse engineering of their binary protocol would happen even faster.
+
=== Windows Binaries ===
  
−
Last but not least: Global Locate boasts itself to get a first fix in 8 sec without AGPS. The importance of AGPS depends whether the part of their website you are reading is targeted at cell phone operators, or not.
+
An OpenOCD installer based on libftdi can be found at the page from [http://www.freddiechopin.info/ Freddie Chopin]
  
−
== Q: Is there any "A-GPS standard" whatsoever? ==
+
== Configuration ==
  
−
A: no. It's a broad term for many variants of GPS
+
[[User:HaraldWelte]] has provided a [http://people.gta01.hmw-consulting.de/laforge/misc/openocd.cfg openocd.cfg configuration file] for use of OpenOCD with wiggler and the QT2410 target board.  
−
== Q: I have heard elsewhere (Wikipedia) that in A-GPS the computation effort is shared between the device and the A-GPS Server. According to a previous post, the device just downloads the ephemeris table so there isn't any  actual "computation sharing", but rather a download of a pre-computed table download. Correct? ==
+
  
−
A: Yes, in this case. In others the server may do more work. For the neo, all the position information is computed in the neo.
+
== Using OpenOCD ==
  
−
== Q: A-GPS involves additional data traffic and thus (potential) additional costs. Does it use a normal GSM/GPRS IP-based data transfer? does it use some out-of-band GSM/GPRS control messages? or does it get data from broadcasts in the local cell (e.g. GSM cell-broadcast)? ==
+
We cannot provide a full manual for OpenOCD, but please check
 +
[[U-Boot#Using_JTAG_to_boot_from_RAM]] and [[NAND bad blocks#JTAG_.2F_OpenOCD_.2F_u-boot_RAM_based]], as well as the [[Neo1973 OpenOCD#Using OpenOCD telnet interface]] section below.
  
−
A: GPRS.  so its up to you whether you want that extra traffic (and
+
== Known Bugs and Troubleshooting ==
−
cost, unless you're flat) or not.
+
−
== Q: if the answer to above is GPRS: is it possible to estimate in advance how much additional traffic (in Kbytes/day of full operation)? ==
+
  
−
A: The absolute worst case is 50 bits/s * 12.5 minutes, around 5Kbytes. For the full almanac.
+
=== CP15 register read/write of ARM920T core not working ===
−
However, this is certainly not needed per day.
+
−
The errors in orbit prediction, when you have a full almanac are quite small over the short term (a week).
+
−
5K once (or the GPS on for 12.5 minutes) then .5K/day should be quite adequate.
+
  
−
== Q: Are there any known estimations on the overall (A)GPS performance on the Neo (esp. fix time) ==
+
This has been reported upstream. Bugfix pending.
  
−
A: The hammerhead brief information page specifies 1s fix time for a position with 5m error.
+
=== Did you turn it on ? ===
  
−
== Q: Coming to the [[:Category:Neo1973 Hardware | Neo1973]]. In order to save costs, can the "Assisted" function in A-GPS be disabled through software API? ==
+
An easily made but devastating mistake is to forget to actually activate the CPU. Just connecting power is not enough !
 +
Press and hold the power button until the boot loader does its count-down, or, in case there is no runnable boot loader,
 +
the CPU keeps itself busy.
  
−
A: yes, it can be disabled through preferences.
+
=== number of discovered devices in JTAG chain doesn't match configuration ===
  
−
== Q: Is it possible to tell whether A-GPS is actually in use or not? ==
+
You get something like:
 +
Error:  jtag.c:1224 jtag_examine_chain(): number of discovered devices in JTAG chain (51) doesn't match configuration (1)
  
−
A: yes. either you have enabled it in preferences or nor ;)
+
This seems like a libftdi initialization bug. Sometimes the FT2232 doesn't get completely reset into a sane state at startup of OpenOCD.  Please unplug the USB cable from the [[Amontec JTAGkey]] / [[Debug Board]] and re-plug.  It should immediately work the next time.  Bugfix would be appreciated a lot!
  
−
== Q: Is it possible to tell/know which is the A-GPS server currently in use? ==
+
=== JTAG communication failure ===
  
−
A: yes.
+
Another common error is this one:
 +
JTAG communication failure, check connection, JTAG interface, target power etc.
  
−
== Q: Can choosing to use GPS (even with A-GPS disabled) enable others to track me?  Is there a mode where this is not the case? ==
+
Also this one is fixed by unplugging and re-plugging USB.
  
−
A: The reciever does not emit significant amounts of RF - unless you are literally within centimeters of the device, it's not possible to pick it up. The other alternative would be that the supplied plugin to gpsd is trojaned, and can be asked somehow to report on your position.
+
== OpenOCD and [[Debug Board]] ==
−
The position is entirely computed in the plugin to gpsd, the GPS hardware cannot know it, it's too dumb.
+
  
−
== Q: What is DGPS, can DGPS and A-GPS work together? ==
+
=== libftdi-0.8 ===
  
−
A: [http://www.oc.nps.navy.mil/oc2902w/gps/dgpsnote.html An overview of DGPS] Differential GPS is basically a way of removing systematic per-satellite errors from various causes (satellite clock drift, atmospheric effects) for 'nearby' recievers, given one reciever that knows where it is.
+
If you want to use OpenOCD with our Debug Board v2, and want to use the serial port simultaneously with OpenOCD, you '''need libftdi-0.8 or later'''.  Chances are high that your distribution still ships an earlier version of libftdi, so you might want to download it from http://www.intra2net.com/de/produkte/opensource/ftdi/ and build yourself.
  
−
The per-satellite range errors to a satellite are around 2-3 metres typically. These per-satellite errors are similar for users close to each other.
+
=== openocd.cfg ===
−
These corrections are broadcast by radio in much of the USA (which the neo cannot pick up).
+
This is an OpenOCD config that was tested with OpenOCD version 0.6.1 and debug board v3 (using new ftdi driver, doesn't require libftdi):
  
−
If you can download error information from a nearby source, then you can obtain positions that are much more accurate than without this information. Perhaps well under 1m radius of error, instead of 2 or 3. In some applications this may be of use.
+
<pre>
 +
source [find interface/ftdi/neodb.cfg]
 +
source [find target/samsung_s3c2440.cfg]
  
−
It may be that the apgsd cannot do this, and it will require reverse engineering.
+
adapter_khz 1000
  
−
In any case, this would be another few hundred bytes a minute while this is active. (the  error information rapidly ages).
+
reset_config trst_and_srst
  
−
Any stationary reciever - even a neo on charge, with a good signal, can produce useful error information. If it had a cheap internet connection at the same time, it could be constantly updating a global error model, for use by other neo owners.
+
init
 +
reset run
 +
sleep 5000
 +
halt
 +
</pre>
  
 +
Here follow configs for some ancient OpenOCD versions:
  
 +
This is an openocd.cfg that is known to work with [[Debug Board]] (v2/v3), [[Neo1973 Hardware#GTA01Bv3]] and OpenOCD 130:
 +
<pre>
 +
telnet_port 4444
 +
gdb_port 3333
 +
interface ft2232
 +
jtag_speed 0
 +
ft2232_vid_pid 0x1457 0x5118
 +
ft2232_layout "jtagkey"
 +
reset_config trst_and_srst
 +
jtag_device 4 0x1 0xf 0xe
 +
daemon_startup attach
 +
target arm920t little reset_run 0 arm920t
 +
working_area 0 0x200000 0x4000 backup
 +
run_and_halt_time 0 5000
 +
</pre>
  
−
It may be that the apgsd cannot do this, and it will require reverse engineering.
+
For later versions of OpenOCD you may need to specify the device description. For the v2 Debug board add this line to your openocd.cfg:
−
=== Q: I thought DGPS couldn't be done like this. ===
+
<pre>
−
See for example http://gpsinformation.net/main/poordgps.htm
+
ft2232_device_desc "Debug Board for Neo1973 A"
−
A: This is quite different from simply looking at the relative offset of reference GPS device, and a known point, and then comparing.
+
</pre>
−
The difference is that the neo can help to derive (in combination with other stationary devices) a real-time model of the different sources of error. See the last comment on the article you refer to - the neo chip produces psuedorange output, it can be corrected in this same manner.
+
  
−
== Q: Is an open-source GPS daemon able to be distributed by FIC? ==
+
If you are using the libftdi version on Linux, and if you see this iProduct string in your lsusb output "Debug Board for Neo1973", please add this line instead.
−
[http://www.fas.org/spp/starwars/offdocs/itar/p121.htm A web copy of the ITAR - International Traffic in Arms Regulation legislation, currently in force in the US]
+
<pre>
 +
ft2232_device_desc "Debug Board for Neo1973"
 +
</pre>
  
−
While stupid, this defines
+
For some versions of the v3 Debug board the vid_pid need to be 0x0403 0x6010.  However, commenting out (with #) the ft2232_ lines altogether makes openocd autodetect the Debug board correctly.
  
−
----
+
For OpenOCD 0.2.0, the config file format has changed. You can start from this ("works for me"):
−
... GPS receiving equipment with any of the following characteristics:
+
−
...
+
−
  (2) Designed for producing navigation results above 60,000 feet altitude
+
−
      and at 1,000 knots velocity or greater;
+
−
----
+
  
−
as being a munition.
+
<pre>
−
This is right after the section prohibiting rockets that can be used to deorbit satellites on a specific target, and just before nuclear weapons design and test equipment.
+
interface ft2232
 +
ft2232_device_desc "Debug Board for Neo1973 A"
 +
ft2232_layout "jtagkey"
 +
ft2232_vid_pid 0x1457 0x5118
  
−
And just because it's stupid doesn't mean they won't kick the doors in - or prevent it from sale and levy huge fines, after the gleefull lawyers at apple point it out. (you need DOD licenses to import/export)
+
source [find target/samsung_s3c2440.cfg]
  
−
The plugin for the gpsd daemon presumably implements this limit.
+
reset_config trst_and_srst
  
−
Much established hardware has pretty much confirmed that it's OK to do it this way - as long as it's closed source, you can point at the evil hackers, and say that you never did it.
+
#jtag_khz 0
  
−
An open source plugin for gpsd distributed with the neo might raise other issues, namely that at some point in the code, there is a self-documented if(velocity>1000kt) test, which can be trivially commented out.
+
gdb_port 3333
−
(the hardware must be able to do this, the velocity of a satellite towards and away from the user greatly exceeds 1000 knots.)
+
tcl_port 6666
 +
telnet_port 4444
  
−
If I was FIC, I would at the very least want a good legal opinion on if an open source gpsd plugin (perhaps a user contributed one after decoding the binary stream that the hammerhead puts out) can be safely distributed, before doing so.
+
init
 +
reset run
 +
sleep 5000
 +
halt
 +
</pre>
  
−
--[[User:Morricone|Morricone]] 11:15, 16 February 2007 (CET) You forget, that FIC is not located in the USA, so US laws do not apply.
+
=== Using OpenOCD telnet interface ===
  
−
Very true, however, this would mean that it could not be imported into the US.
+
The telnet interface can be accessed using
−
Also that anyone from FIC involved in this could not travel to the US without fear of arrest.
+
telnet localhost 4444
−
The penalties are really quite high.
+
−
--[[User:Speedevil|Speedevil]] 14:10, 16 February 2007 (CET)
+
  
−
Isn't this resriction implemented in the chipset? wouldn't the chipset itself be illegal in the US without these restrictions?
+
it provides a plethora of functions for debugging. You might be interested in
−
--[[User:Kiney|Kiney]] 22:20, 14 March 2007 (CET)
+
<pre>
 +
reset
 +
reset halt
 +
resume
 +
poll
 +
reg
 +
load_binary
 +
mdw
 +
mww
 +
</pre>
  
−
The chipset is too dumb. It does not know the position or the velocity. This is only computed in the host CPU. --[[User:Speedevil|Speedevil]] 06:17, 25 March 2007 (CEST)
+
=== Using OpenOCD and gdb for remote debugging ===
  
−
[[Category:Neo1973 Hardware]]
+
First, you will need a suitable cross-gdb (a gdb that runs on your host architecture, e.g. i386, but works with code for arm).  In OpenEmbedded, you can build such a cross-gdb by using
 +
bitbake  gdb-cross
 +
 
 +
If you want to debug the kernel, you can then start this gdb with
 +
$ arm-linux-gdb vmlinux
 +
 
 +
which will give you something like
 +
<pre>
 +
GNU gdb 6.6
 +
Copyright (C) 2006 Free Software Foundation, Inc.
 +
GDB is free software, covered by the GNU General Public License, and you are
 +
welcome to change it and/or distribute copies of it under certain conditions.
 +
Type "show copying" to see the conditions.
 +
There is absolutely no warranty for GDB.  Type "show warranty" for details.
 +
This GDB was configured as "--host=i686-linux --target=arm-linux"...
 +
(gdb)
 +
</pre>
 +
 
 +
We now need to connect to the OpenOCD daemon, which is done using the '''target remote''' command.  In this particular example, we did already halt the target by issuing '''halt''' on the '''telnet''' command line
 +
 
 +
<pre>
 +
(gdb) target remote localhost:3333
 +
Remote debugging using localhost:3333
 +
warning: shared library handler failed to enable breakpoint
 +
0xc0129b8c in memmove () at include/asm/current.h:9
 +
9      {
 +
(gdb)
 +
</pre>
 +
 
 +
For breakpoints to work, you have to enable software breakpoints in OpenOCD, by issuing
 +
> arm7_9 sw_bkpts enable
 +
 
 +
on the '''telnet''' command line, and use '''hbreak''' to set breakpoints in gdb.
 +
{{Languages}}
 +
 
 +
[[Category:Developer resources]]

Latest revision as of 18:43, 10 February 2013

Contents

[edit] About OpenOCD

OpenOCD is a 100% free software On-chip-debugger for commonly-found ARM JTAG probes such as wiggler, chamaeleon, jtag-key and others, like the Debug Board.

It provides a human-readable telnet interface for manually halting/resuming the target device, reading/writing registers and memory, etc.

In addition, it provides a RDI (remote debugger interface) on a TCP port. This interface can be used by gdb (the GNU Debugger).

The GTA01 development team used OpenOCD with a wiggler compatible probe as their ICE solution in the very beginning, until they had designed their own Debug Board.

[edit] Getting OpenOCD

[edit] MokoMakefile

The MokoMakefile "make openmoko-devel-tools" target will build statically-linked openocd and dfu-util binaries. The "bitbake openocd-native" command may also be used.

[edit] Debian Package

We now have a Debian binary package of OpenOCD, available from http://people.openmoko.org/laforge/dpkg. Installing this package is the preferred method to install OpenOCD on your development machine like 

dpkg --install openocd_82-1_i386.deb

Debian/Unstable also contains an OpenOCD build.

[edit] Gentoo Ebuild

There is an experimental ebuild for openocd in the gentoo bugzilla - seems to be already in Gentoo now (May 2008) however you may need to edit the e-build because it has no keywords enabled by default: edit /usr/portage/dev-embedded/openocd/openocd-9999.ebuild and replace KEYWORDS="" with KEYWORDS="amd64 x86". Remember to regenerate the digest afterwards: 

ebuild /usr/portage/dev-embedded/openocd/openocd-9999.ebuild digest
# Build openocd
emerge libftdi
USE="ftdi ft2232" emerge openocd

[edit] Source Code

OpenOCD Revision 82 and later have been proven to work with our QT2410 and Neo1973 target board and wiggler as well as Amontect JTAGkey and JTAGkey tiny. You can e.g. check rev. 130 out of the OpenOCD subversion via 

svn co -r 130 http://svn.berlios.de/svnroot/repos/openocd/trunk

[edit] Windows Binaries

An OpenOCD installer based on libftdi can be found at the page from Freddie Chopin

[edit] Configuration

User:HaraldWelte has provided a openocd.cfg configuration file for use of OpenOCD with wiggler and the QT2410 target board.

[edit] Using OpenOCD

We cannot provide a full manual for OpenOCD, but please check U-Boot#Using_JTAG_to_boot_from_RAM and NAND bad blocks#JTAG_.2F_OpenOCD_.2F_u-boot_RAM_based, as well as the Neo1973 OpenOCD#Using OpenOCD telnet interface section below.

[edit] Known Bugs and Troubleshooting

[edit] CP15 register read/write of ARM920T core not working

This has been reported upstream. Bugfix pending.

[edit] Did you turn it on ?

An easily made but devastating mistake is to forget to actually activate the CPU. Just connecting power is not enough ! Press and hold the power button until the boot loader does its count-down, or, in case there is no runnable boot loader, the CPU keeps itself busy.

[edit] number of discovered devices in JTAG chain doesn't match configuration

You get something like: 

Error:   jtag.c:1224 jtag_examine_chain(): number of discovered devices in JTAG chain (51) doesn't match configuration (1)

This seems like a libftdi initialization bug. Sometimes the FT2232 doesn't get completely reset into a sane state at startup of OpenOCD. Please unplug the USB cable from the Amontec JTAGkey / Debug Board and re-plug. It should immediately work the next time. Bugfix would be appreciated a lot!

[edit] JTAG communication failure

Another common error is this one: 

JTAG communication failure, check connection, JTAG interface, target power etc.

Also this one is fixed by unplugging and re-plugging USB.

[edit] OpenOCD and Debug Board

[edit] libftdi-0.8

If you want to use OpenOCD with our Debug Board v2, and want to use the serial port simultaneously with OpenOCD, you need libftdi-0.8 or later. Chances are high that your distribution still ships an earlier version of libftdi, so you might want to download it from http://www.intra2net.com/de/produkte/opensource/ftdi/ and build yourself.

[edit] openocd.cfg

This is an OpenOCD config that was tested with OpenOCD version 0.6.1 and debug board v3 (using new ftdi driver, doesn't require libftdi): 

source [find interface/ftdi/neodb.cfg]
source [find target/samsung_s3c2440.cfg]

adapter_khz 1000

reset_config trst_and_srst

init
reset run
sleep 5000
halt

Here follow configs for some ancient OpenOCD versions:

This is an openocd.cfg that is known to work with Debug Board (v2/v3), Neo1973 Hardware#GTA01Bv3 and OpenOCD 130: 

telnet_port 4444
gdb_port 3333
interface ft2232
jtag_speed 0
ft2232_vid_pid 0x1457 0x5118
ft2232_layout "jtagkey"
reset_config trst_and_srst
jtag_device 4 0x1 0xf 0xe
daemon_startup attach
target arm920t little reset_run 0 arm920t
working_area 0 0x200000 0x4000 backup
run_and_halt_time 0 5000

For later versions of OpenOCD you may need to specify the device description. For the v2 Debug board add this line to your openocd.cfg: 

ft2232_device_desc "Debug Board for Neo1973 A"

If you are using the libftdi version on Linux, and if you see this iProduct string in your lsusb output "Debug Board for Neo1973", please add this line instead. 

ft2232_device_desc "Debug Board for Neo1973"

For some versions of the v3 Debug board the vid_pid need to be 0x0403 0x6010. However, commenting out (with #) the ft2232_ lines altogether makes openocd autodetect the Debug board correctly.

For OpenOCD 0.2.0, the config file format has changed. You can start from this ("works for me"): 

interface ft2232
ft2232_device_desc "Debug Board for Neo1973 A"
ft2232_layout "jtagkey"
ft2232_vid_pid 0x1457 0x5118

source [find target/samsung_s3c2440.cfg]

reset_config trst_and_srst

#jtag_khz 0

gdb_port 3333
tcl_port 6666
telnet_port 4444

init
reset run
sleep 5000
halt

[edit] Using OpenOCD telnet interface

The telnet interface can be accessed using 

telnet localhost 4444

it provides a plethora of functions for debugging. You might be interested in 

reset
reset halt
resume
poll
reg
load_binary
mdw
mww

[edit] Using OpenOCD and gdb for remote debugging

First, you will need a suitable cross-gdb (a gdb that runs on your host architecture, e.g. i386, but works with code for arm). In OpenEmbedded, you can build such a cross-gdb by using 

bitbake  gdb-cross

If you want to debug the kernel, you can then start this gdb with 

$ arm-linux-gdb vmlinux

which will give you something like 

GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-linux --target=arm-linux"...
(gdb)

We now need to connect to the OpenOCD daemon, which is done using the target remote command. In this particular example, we did already halt the target by issuing halt on the telnet command line 

(gdb) target remote localhost:3333
Remote debugging using localhost:3333
warning: shared library handler failed to enable breakpoint
0xc0129b8c in memmove () at include/asm/current.h:9
9       {
(gdb)

For breakpoints to work, you have to enable software breakpoints in OpenOCD, by issuing 

> arm7_9 sw_bkpts enable

on the telnet command line, and use hbreak to set breakpoints in gdb.

Geographylogo.png Languages:

English •  العربية •  Български •  Česky •  Dansk •  Deutsch •  Esperanto •  Eesti •  Español •  فارسی •  Suomi •  Français •  עברית •  Magyar •  Italiano •  한국어 •  Nederlands •  ‪Norsk (bokmål)‬ •  Polski •  Português •  Română •  Русский •  Svenska •  Slovenčina •  Українська •  ‪中文(中国大陆)‬ •  ‪中文(台灣)‬ •  Euskara •  Català

Retrieved from "http://openmoko.org/index.php?title=Neo_1973_OpenOCD&oldid=108705"
Personal tools

The Neo1973 uses an Assisted Global Positioning Ssystem, AGPS, technology. The Hardware:AGPS page provides information on GPS in general and the OpenMoko chip in particular.


Q: Has anybody here ever used AGPS? I'd like to hear your experiences.

Everybody who has used a modern GPS has used AGPS. It is usually called warm-start or hot-start. AGPS is purely a marketing term. To calculate the position a GPS chip needs: 

    * almanac = coarse position of satellites
    * ephemeris = precise position of satellites

The almanac is broadcast in a loop of 12.5 minutes and valid for at least six weeks. The ephemeris is broadcast in a loop of 30 seconds and valid for ~2 hours.

Time is mostly irrelevant, as modern chips synchronize within a second with the satellites.

The receiver chipsets store this data in flash and load it from there onto the chip in order to _assist_ the hot or warm start.

AGPS now means to load the almanac and the ephemeris from elsewhere, i.e. via a network. For example for free from the american government: http://www.navcen.uscg.gov/gps/precise/default.htm

AGPS is a nice convenience yet the success and proper functioning of TomTom and Navigon PDAs shows that you don't need that at all.

It's worth noting that the GPS on the neo is sensitive enough to pick up GPS signals in buildings. If the spot you charge your neo happens to have a GPS signal, downloading the almanac from the satellites while it charges is essentially free, and takes no Internet access at all. Do this daily, and you get most of the benefit of aGPS.

Q: The chip in the Neo1973 is a Global Locate AGPS. Anybody know what type? Hammerhead maybe?

A: It is the hammerhead.

Q: I understand the concept of assisted GPS. But does the phone have its own antenna/receiver so that it can work without 'assistance'?

A: See above, the important part is the GPS and not the assistance. Antenna is thus compulsory.

Q: Has anybody info on the whereabouts of assistance servers, especially in Belgium and Europe?

A: They can be anywhere on the net. Alternatively a service from the cellphone operators. However, there may be occasions where you want a server 'near' where you are. See the later question on DGPS

Q: Using the assistance servers will probably mean that I will have to pay for that service. Any idea of the costs?

A: They use the low cost of their chip as selling point. Their website implies that this is a service that comes with the chip. I'd call it not very clever if they are going to charge you - it would change their image from lowcost to money grabber and the reverse engineering of their binary protocol would happen even faster.

Last but not least: Global Locate boasts itself to get a first fix in 8 sec without AGPS. The importance of AGPS depends whether the part of their website you are reading is targeted at cell phone operators, or not.

Q: Is there any "A-GPS standard" whatsoever?

A: no. It's a broad term for many variants of GPS

Q: I have heard elsewhere (Wikipedia) that in A-GPS the computation effort is shared between the device and the A-GPS Server. According to a previous post, the device just downloads the ephemeris table so there isn't any actual "computation sharing", but rather a download of a pre-computed table download. Correct?

A: Yes, in this case. In others the server may do more work. For the neo, all the position information is computed in the neo.

Q: A-GPS involves additional data traffic and thus (potential) additional costs. Does it use a normal GSM/GPRS IP-based data transfer? does it use some out-of-band GSM/GPRS control messages? or does it get data from broadcasts in the local cell (e.g. GSM cell-broadcast)?

A: GPRS. so its up to you whether you want that extra traffic (and cost, unless you're flat) or not.

Q: if the answer to above is GPRS: is it possible to estimate in advance how much additional traffic (in Kbytes/day of full operation)?

A: The absolute worst case is 50 bits/s * 12.5 minutes, around 5Kbytes. For the full almanac. However, this is certainly not needed per day. The errors in orbit prediction, when you have a full almanac are quite small over the short term (a week). 5K once (or the GPS on for 12.5 minutes) then .5K/day should be quite adequate.

Q: Are there any known estimations on the overall (A)GPS performance on the Neo (esp. fix time)

A: The hammerhead brief information page specifies 1s fix time for a position with 5m error.

Q: Coming to the Neo1973. In order to save costs, can the "Assisted" function in A-GPS be disabled through software API?

A: yes, it can be disabled through preferences.

Q: Is it possible to tell whether A-GPS is actually in use or not?

A: yes. either you have enabled it in preferences or nor ;)

Q: Is it possible to tell/know which is the A-GPS server currently in use?

A: yes.

Q: Can choosing to use GPS (even with A-GPS disabled) enable others to track me? Is there a mode where this is not the case?

A: The reciever does not emit significant amounts of RF - unless you are literally within centimeters of the device, it's not possible to pick it up. The other alternative would be that the supplied plugin to gpsd is trojaned, and can be asked somehow to report on your position. The position is entirely computed in the plugin to gpsd, the GPS hardware cannot know it, it's too dumb.

Q: What is DGPS, can DGPS and A-GPS work together?

A: An overview of DGPS Differential GPS is basically a way of removing systematic per-satellite errors from various causes (satellite clock drift, atmospheric effects) for 'nearby' recievers, given one reciever that knows where it is.

The per-satellite range errors to a satellite are around 2-3 metres typically. These per-satellite errors are similar for users close to each other. These corrections are broadcast by radio in much of the USA (which the neo cannot pick up).

If you can download error information from a nearby source, then you can obtain positions that are much more accurate than without this information. Perhaps well under 1m radius of error, instead of 2 or 3. In some applications this may be of use.

It may be that the apgsd cannot do this, and it will require reverse engineering.

In any case, this would be another few hundred bytes a minute while this is active. (the error information rapidly ages).

Any stationary reciever - even a neo on charge, with a good signal, can produce useful error information. If it had a cheap internet connection at the same time, it could be constantly updating a global error model, for use by other neo owners.


It may be that the apgsd cannot do this, and it will require reverse engineering.

Q: I thought DGPS couldn't be done like this.

See for example http://gpsinformation.net/main/poordgps.htm A: This is quite different from simply looking at the relative offset of reference GPS device, and a known point, and then comparing. The difference is that the neo can help to derive (in combination with other stationary devices) a real-time model of the different sources of error. See the last comment on the article you refer to - the neo chip produces psuedorange output, it can be corrected in this same manner.

Q: Is an open-source GPS daemon able to be distributed by FIC?

A web copy of the ITAR - International Traffic in Arms Regulation legislation, currently in force in the US

While stupid, this defines

... GPS receiving equipment with any of the following characteristics: ... 

  (2) Designed for producing navigation results above 60,000 feet altitude
      and at 1,000 knots velocity or greater;

as being a munition. This is right after the section prohibiting rockets that can be used to deorbit satellites on a specific target, and just before nuclear weapons design and test equipment.

And just because it's stupid doesn't mean they won't kick the doors in - or prevent it from sale and levy huge fines, after the gleefull lawyers at apple point it out. (you need DOD licenses to import/export)

The plugin for the gpsd daemon presumably implements this limit.

Much established hardware has pretty much confirmed that it's OK to do it this way - as long as it's closed source, you can point at the evil hackers, and say that you never did it.

An open source plugin for gpsd distributed with the neo might raise other issues, namely that at some point in the code, there is a self-documented if(velocity>1000kt) test, which can be trivially commented out. (the hardware must be able to do this, the velocity of a satellite towards and away from the user greatly exceeds 1000 knots.)

If I was FIC, I would at the very least want a good legal opinion on if an open source gpsd plugin (perhaps a user contributed one after decoding the binary stream that the hammerhead puts out) can be safely distributed, before doing so.

--Morricone 11:15, 16 February 2007 (CET) You forget, that FIC is not located in the USA, so US laws do not apply.

Very true, however, this would mean that it could not be imported into the US. Also that anyone from FIC involved in this could not travel to the US without fear of arrest. The penalties are really quite high. --Speedevil 14:10, 16 February 2007 (CET)

Isn't this resriction implemented in the chipset? wouldn't the chipset itself be illegal in the US without these restrictions? --Kiney 22:20, 14 March 2007 (CET)

The chipset is too dumb. It does not know the position or the velocity. This is only computed in the host CPU. --Speedevil 06:17, 25 March 2007 (CEST)