Tutorial: installation

From RFID Wiki

This describes the complete installation procedure, including how to obtain and/or build prerequisites for the Guardian Software.


The RFID Guardian software distribution can build a number of different configurations:

  • programs to run on the embedded system; the obvious example is the Guardian Main program;
  • program on a PC that controls an RFID Reader; we include the software for the Philips Pegoda reader;
  • simulator, that uses sockets in stead of RFID communication; this allows to run a Guardian Main and a Reader (etc) and have them communicate in a very controlled setup;
  • Java program to interact with the Guardian over BlueTooth, to run on a cell phone.


These different configurations have different requirements for software:

  • for a Windows PC, the Linux emulator Cygwin is required;
  • for the embedded system, a checkout of the RTOS eCos is required, and a cross-compiler toolkit; we provide a port of eCos for our Guardian hardware;
  • for the Reader connected to a PC, the DLLs and device drivers for this piece of hardware are necessary;
  • for the simulator, nothing special is required;
  • for the Java modules, Java J2ME and Ant are required.


All software assumes that you have GNU make on your system. Chances are that that's the case already. If you run Linux or Cygwin, the default make is GNU make. On many other systems, GNU make is installed as gmake. Then you should replace calls to 'make' below with calls to 'gmake'. If GNU make is not installed, you will need to download it from the GNU make pages, and install it yourself.

Contents

[edit] Pre-install

This section descibes how to install any prerequisites to building the RFID Guardian software.

[edit] Cygwin Setup

NOTE: Skip this if you don't build on a Windows system.

Get Cygwin from www.cygwin.com.

  • Make sure you have selected file type [Unix/binary], not file type [DOS/text]. All text-based tools under Cygwin get confused by the [DOS/text] file type conversions, because line endings are converted from LF to CR/LF transparently.

Module prerequisites:

  • Make sure you have 'development environment' selected, so you have gcc, make, ar, ld, ...
  • You need svn, the SubVersion client.
  • If you want to build the ACL module or the GP module, make sure you have selected 'flex' and friends in the compiler tools section, and 'perl' in the interpreters section.
  • If you need OpenSSL (e.g. for the GP module), make sure you have selected the Cygwin openssl developer modules.


[edit] Caveats for Cygwin users

  • Cygwin users must not use TortoiseSVN or any other native Windows tool to do their SubVersion checkouts. These cause the line endings to be CR/LF in stead of the desired LF. Use the SubVersion command line client svn.
  • Cygwin users may need the --non-interactive flag for all svn commands.
  • The Cygwin command line client svn may display a bug at initial checkout. Some SubVersion working files are reported to have the wrong permissions, and checkout halts. This is a race condition in the cooperation with Windows. The fix is straightforward. Move into the top-level directory of the distribution and do
$ svn update

If this helps, good. Else, say the error occurs in '.../mrg-subdir/.svn/.../some-file'. Then throw away the directory mrg-subdir, i.e. the directory immediately above .svn in the path to the error:

$ rm -rf .../mrg-subdir

and do

$ svn update

from the root directory of the checkout. This procedure may have to be iterated a few times

  • Whitespace in file names: GNU make notoriously has problems with whitespace in file names. The only solution may be to ensure that none of the paths in the checkout directories have any white space. This might typically surface if your user name has a space: /home/Joe\ User/ . The fix is to create a directory without whitespace: /home/joe-user/, and checkout there. Under CygWin, there is no restraint at all to create such a directory.

[edit] Environment setup for java

NOTE: Skip this if you don't want to build the Java modules.

If you don't have java, javac, jar etc, get them from Sun: java.sun.com. If you build on Cygwin, get a native Windows Java. Let the environment variable JAVA_HOME point to your Java installation. For Cygwin, that would be something like

$ export JAVA_HOME="/cygdrive/c/Program Files/Java/jdk1.5.0_10"

(or whatever version).

You also need Sun's Java Wireless Toolkit, WTK. It provides j2me libraries and a cell phone emulator, on Windows as well as on Linux. Download it from java.sun.com/products/sjwtoolkit.

If you don't have ant, get it from http://ant.apache.org. Let the environment variable ANT_HOME point to the ant installation.

[edit] eCos setup

NOTE: Skip this if you don't want to do a build for the Guardian embedded system.

Our eCos distribution contains code developed by Ka-Ro for the Triton-270 computer-on-a-PCB which we use in our embedded system. Ka-Ro's code is covered by the GPL, so it is free as in speech but not free as in beer. Only if you buy a Triton-270, you are entitled to KaRo's eCos additions. This constraint is reflected by our eCos repository because it contains KaRo's changes. For this reason our eCos code is protected by a username/password.

However, it ought to be possible to build the Guardian software for any eCos port that supports the devices that the Guardian needs. Our custom devices are accessed only through GPIO pins, so there are no separate device drivers within eCos.

[edit] Tool chain

Select a directory where you want your eCos checkout, like ~/projects/ecos. We will call it ~ECOS in this tutorial, as an abbreviation.

You need to get a cross-compiler tool chain to build the Guardian software. Prebuilt tool chains are available from eCos: see http://ecos.sourceware.org/getstart.html.

In summary:

$ wget --passive-ftp ftp://ecos.sourceware.org/pub/ecos/ecos-install.tcl
$ sh ecos-install.tcl

Select some mirror site.

Select some directory for installation: choose ~ECOS

Select prebuilt GNU tools [1] arm-elf , then [q]

Now, this downloads not only a gcc tool chain, but also an antique eCos distro which we're not going to use. Therefore delete everything in ~ECOS except ~ECOS/gnutools.

If you wish you may move gnutools, the tool chain, to a place where other users on your system may also use it, like /usr/local/gnutools. We will abbreviate the toolchain location as ~GNUTOOLS in this tutorial.

[edit] eCos source checkout, eCos build

$ svn checkout https://svn.rfidguardian.org/ecos/trunk ~ECOS

Build configuration is done in ~ECOS/ecos-build. The build itself is done in a subdirectory of ~ECOS/ecos-build, which depends on the type of configuration.

$ cd ~ECOS/ecos-build
$ bash ./configure [options]

Options (selection, do -help to get an overview):

-triton-270
-stamp

Select build type. Option -triton270 creates a configuration in ~ECOS/ecos-build/triton-270, option -stamp creates a configuration in ~ECOS/ecos-build/bfin53x-stamp.

--toolset=~GNUTOOLS

Specify the location of the GNU compiler toolset. Default is ~ECOS/gnutools.

The eCos installer uses the utility 'tail'. Modern versions of Linux 'tail' have changed their command line interface. To reproduce tail's behaviour as understood by eCos, do:

$ export _POSIX2_VERSION=199209

}

You might consider putting this in your .bashrc. (Or do setenv _POSIX2_VERSION 199209 and put it in your .cshrc or .tcshrc).

Then build eCos.

$ cd triton-270 (or bfin53x-stamp)
$ make

Have a cup of coffee while eCos builds.

[edit] Philips Pegoda software

NOTE: skip this if you won't use a Philips Pegoda Reader

For builds where you will use a Philips Pegoda RFID reader, you need the software that comes with that reader. Like with our eCos code, we provide this software for registered users.

$ cd ~/projects
$ mkdir 3rdparty-proprietary
$ cd 3rdparty-proprietary
$ svn checkout https://svn.rfidguardian.org/3rdparty-proprietary/trunk ~3RDPARTY_PROPRIETARY

[edit] The Guardian software

The software that runs on top of the OS or the RTOS: Guardian Main, Reader, simulator, etc.

[edit] Get a checkout of the source tree

If you have a checkout with write access to the software, you must be extremely careful in committing anything to the repository. Please follow these guidelines:

  • don't change anything in files (code, documentation, everything) that was written by somebody else, unless you have reached agreement with the author on your changes;
  • don't ever commit anything that is generated; think .o, .obj, .a, .dll, .dvi, .ps, .pdf, .class, .jar, and so on; commit the sources from which the thing is generated, together with a Makefile or a build.xml or a shell script;
  • don't change anything to reflect your 'better taste', like indentation and layout, local names etc;

Now on to building the RFID Guardian software.

$ cd ~/projects
$ mkdir mrg
$ cd mrg
$ svn checkout https://svn.rfidguardian.org/mrg/trunk ~ECOS

We will call this directory ~MRG in all the RFID Guardian documentation, as an abbreviation.

[edit] MRG Configuration

$ cd ~MRG
$ bash ./configure [options]

The configure options will reflect the type of build you want to do.

Options you may want to know about here:

target platform
--ecc=<eCos .ecc> build for eCos; select the eCos build description file. CPU type etc is inferred. By default, chooses the triton-270 .ecc file. Beware: don't use home directory expansion. Bash fails on it.
-sim build a simulator
-host build a standalone environment to control the Pegoda reader
optional modules
-acl --no-acl (don't) build ACL support
--ssl=[path] indicate where openssl lives. For simulator and host builds, specify --ssl=/usr. For eCos builds, specify --ssl=~MRG/openssl/install. Beware: don't use home directory expansion. Bash fails on it.
-java --no-java (don't) build Java stubs for the GP messages
-ui --no-ui (don't) build a command-line User Interface

Note: to build the Guardian Main program, you need -acl and -ui; for cryptographic operations (authentication, key transfer) you also need --ssl=[OpenSSL path]

[edit] OpenSSL

If your build will use OpenSSL, you need an appropriate OpenSSL package. This is the case if your build will use GP (Guardian Protocol), for example. For simulator and host builds, any pre-installed OpenSSL is fine (it might be named something like openssl-devel or libssl-dev). For eCos, proceed as follows.

$ cd ~MRG/openssl/ecos

Get an openssl-0.9.7g tarball from http://www.openssl.org. Extract it *here*, so the distribution lives as openssl-0.9.7g/ under ~MRG/openssl/ecos/.

$ patch -p0 < Configure.patch
$ bash ./BUILD.eCos

This will configure and build your eCos openssl. Have a cup of coffee. It will also attempt to make and run the OpenSSL test suite. This will obviously fail. Ignore any error messages that result from this.

[edit] Build MRG

$ cd ~MRG
$ make

This builds the RFID Guardian library. On my 2007 system (dual-core Athlon 3800+), a build takes between 1 and 2 minutes.

This library must be linked with a main program. Examples are given in Tutorial:_guardian_programs.

[edit] Build the Java jar for the Cell Phone User Interface

An ant build.xml is provided in ~MRG/java. It is invoked from the top-level make if Java support has been configured in. This build.xml creates a .jar and a .jad in ~MRG/build/. These can be uploaded to a cell phone, or fed to a cell phone emulator.