== Development Environment ==

SB3 is used for CM2 firware code development. In addition to all the necessary software, SB3 console has USB based JTAG programmer attached.
[[Image(SB3.jpg)]]
 
=== Prerequisites ===

Prerequisites include SUN JDK but only if you want to use Eclipse for development.

{{{
  apt-get install bzip2 gcc gnumake automake1.9 mpfr sun-java6-jdk tk-dev tcl-dev libncurses-dev
}}}

=== Firmware Programming ===

CM2 build configuration is done by overriding variables from the first few hundred lines of the Makefile on the {{{make}}} command line.

==== JTAG Programmer Hardware ====

We are using Olimex [http://www.olimex.com/dev/arm-usb-ocd.html ARM-USB-OCD] USB based JTAG debugger that is attached to the JTAG port on the CM2 board (JXX).

[[Image(JTAG.jpg)]]
 
==== JTAG Programmer Software ====

Software used for debugging and internal flash programming is [http://openfacts.berlios.de/index-en.phtml?title=Open_On-Chip_Debugger OpenOCD] (standard Debian package - {{{ apt-get isntall openocd }}} ).

The file openocd.cfg, included in the source repository, has an appropriate configuration for programming the CM2 hardware, although you can experiment with different scripts to automate erasing the flash, verifying the image, and so forth.

The daemon is started with:

{{{
  openocd -f openocd.cfg
}}}

It is listening for gdb connections on default port 3333. Note that openocd has a startup script and should be running at all times.  Often there's a {{{native}}} screen session with an obvious name like {{{openocd}}} that displays the openocd log.

You can develop on your private system and run {{{arm-elf-gdb}}} against openocd remotely.  sb3 does not expose an ssh port, but you can tunnel through {{{gw.orbit-lab.org}}} with a command like the following.

{{{
  $ ssh gw.orbit-lab.org -L 3333:sb3.orbit-lab.org:3333
}}}

=== Cross-compiler ===

Software development environment is based on the latest version of gcc, binutils, and newlib.  There are two tricks to compiling these tools: one is to use separate build directories, the other is to bootstrap a C compiler against the newlib headers, compile newlib with that compiler, then compile another C compiler with newlib installed.  Interwork and Multilib support are necessary.

{{{
  $ # unpack tarballs in $SRC_TOP
  $ mkdir $SRC_TOP/binutils-build
  $ cd $SRC_TOP/binutils-build
  $ ../binutils-$BINUTILS_VERSION/configure --target=arm-elf --enable-interwork --enable-multilib
  $ make && sudo make install
  $ mkdir $SRC_TOP/gcc-build 
  $ cd $SRC_TOP/gcc-build 
  $ ../gcc-$GCC_VERSION/configure --target=arm-elf --enable-interwork --enable-multilib --enable-languages=c --with-newlib --with-headers=../newlib-$NEWLIB_VERSION/newlib/libc/include
  $ make all-gcc && sudo make install-gcc
  $ mkdir $SRC_TOP/newlib-build
  $ cd $SRC_TOP/newlib-build
  $ ../newlib-$NEWLIB_VERSION/configure  --target=arm-elf --enable-interwork --enable-multilib
  $ make all && sudo make install
  $ cd $SRC_TOP/gcc-build
  $ make all && sudo make install
  $ mkdir $SRC_TOP/gdb-build
  $ cd $SRC_TOP/gdb-build
  $ ../gdb-$GDB_VERSION/configure --target=arm-elf
  $ make all && sudo make install
}}}

This build procedure is what makes people balk at building vanilla arm-elf debian packages.  Not that it's a lot of commands, but that there's a chicken and egg problem with newlib.

=== Debugger ===

Use [source:CM2/trunk/gdbinit-rom gdb initialization file] to properly interact with the JTAG debugger:

{{{
  $ arm-elf-gdb --annotate=3 -x gdbinit-rom main.elf
}}}

This will load and run the CM2 with a breakpoint set at {{{main()}}}.