Guide to Writing Applications for the Developer Board

Examples in this document assumes that you have installed the developer board software in a directory called axis in your home directory. If this is not the case, just keep it in mind and use your installation directory instead of ~/axis in the examples.

Hello World!

Let us write a simple application that writes "Hello World!" to standard output and run it on the developer board. First we need a directory for our new application. Create a directory in the apps directory. The tool we will use to build a new image for the developer board (mkprod) will assume that applications resides in subdirectories in the apps directory. Avoid naming an application "test" since test is a shell builtin in most shells and might also be an existing executable in your environment. Let us call our application "hello". We then create a directory apps/hello for it:

cd ~/axis/apps
mkdir hello

Write the source code and save it to a file called ~/axis/apps/hello/hello.c:

#include <stdio.h>

int main(int argc, char *argv[]) {
	printf("Hello World!\n");
	return 0;
}

Compile it for your host:

cd ~/axis/apps/hello
gcc hello.c

This will create an executable for your operating system named a.out in your working directory. Try it:

./a.out

The output should be:

Hello World!

Now that we know that the application works for your operating system, let us make an executable for the developer board. This will require a bit more work than just running gcc, therefore the easiest approach is to use make. Write a makefile called Makefile and save it in the ~/axis/apps/hello directory (note: make requires tabs instead of spaces in some places):

include $(APPS)/Rules.elinux

INSTDIR   = $(prefix)/bin
INSTMODE  = 0755

PROGS     = hello

SRCS      = hello.c

OBJS      = hello.o

CFLAGS    += -Wall

all:	$(PROGS)

ifdef ELINUX
# These 3 lines are for compiling with uC-libc
# (and the uccrt0.o rule below for $(PROGS))

CFLAGS   += -nostdinc -I$(prefix)/include/uC-libc
LDFLAGS   += -nostdlib -L$(prefix)/lib
LDLIBS    = -lucc -lic -lgcc

pre-all-recurse pre-install-recurse:
	@if [ ! -e $(prefix)/lib/libucc.a ]; then \
		echo "You need to install the uC-libc library to compile this program!";\
		exit 1; \
	fi

$(PROGS): $(prefix)/lib/uccrt0.o $(OBJS)
	$(CC) $(LDFLAGS) $^ $(LDLIBS) -o $@
else
$(PROGS): $(OBJS)
	$(CC) $(LDFLAGS) $^ $(LDLIBS) -o $@
endif

install:	$(PROGS)
	$(INSTALL) -d $(INSTDIR)
	$(INSTALL) -m $(INSTMODE) $(PROGS) $(INSTDIR)

clean:
	rm -rf $(PROGS) *.o core

depend:
	makedepend -Y -- $(CFLAGS) -- $(SRCS) 2>/dev/null

This may seem like a awful lot for a makefile, but this is just to make things easier later on when we will be using the mkprod tool. Depending on whether the environment variable ELINUX is set or not the executable will be built for the developer board or your host operating system respectively. Set the ELINUX variable to 1 and export it:

ELINUX=1
export ELINUX

To build for the developer board you first need to set some additional environment variables. The easiest way to do this is to run the init_env script that should exist in the directory where you installed the developer board:

cd ~/axis
source init_env

You also need to install uC-libc on your computer:

cd ~/axis/libs/uC-libc
make install

Now tou can build the executable using make:

cd ~/axis/apps/hello
make

The output should look something like this:

gcc-cris -melinux -O2 -D__linux__ -DELINUX -Wall -nostdinc -I/home/john/axis/ero
ot/include/uC-libc   -c -o hello.o hello.c
gcc-cris -melinux -s -symbolic -nostdlib -L/home/john/axis/eroot/lib /home/john/
axis/eroot/lib/uccrt0.o hello.o -lucc -lic -lgcc -o hello

If nothing happens when you run make you may need to remove any existing .o-file and executable. In that case type:

make clean
make

If no problem occurs an executable named hello will be created.

Getting the Executable into the Developer Board

There are at least two ways of getting the executable into the developer board:

Using mkprod to build a new ROM file system for the developer board containing the executable.
Using ftp to transfer the executable to the flash file system (/mnt/flash) of the developer board.

Using mkprod

The easiest way would be using mkprod. Then you have two alternatives: Either you just copy the executable into the directory ~/axis/products/tech/devboard/eroot, which will be used as the root directory of the ROM file system image, or you edit the file ~/axis/products/tech/devboard/prodspec to tell mkprod that your application should be included in the ROM file system.

If you choose to just copy the executable, put it in the eroot/bin directory:

cp ~/axis/apps/hello/hello ~/axis/products/tech/devboard/eroot/bin

Then you need to build the new ROM file system image without rebuilding the applications:

cd ~/axis/products/tech/devboard
mkprod -i

If you would run "mkprod" without '-i', all applications in the prodspec file would be built. That would be the intended way of using mkprod. Let us see how that works. Instead of copying the executable you then edit the file ~/axis/products/tech/devboard/prodspec and add the name of your application (hello) to the section [apps]:

[apps]
init
net-tools
.
.
.
ping
mactool
# New application added by me
hello

Then run mkprod (without -i this time):

cd ~/axis/products/tech/devboard
mkprod

When mkprod is done new images have been created. To test the new ROM filesystem first put your devboard in boot mode by pressing the boot button, pressing and releasing the reset button and then releasing the boot button (i.e. the boot button must be kept down while resetting the developer board). Then run the script ktest (this requires that the developer board is on the same network segment as your computer, otherwise use FTP):

cd ~/axis/products/tech/devboard
./ktest

When ktest is executed the image file ~/axis/products/tech/devboard/kimage containing the kernel and the ROM file system (created by mkprod) will be sent to the developer board by the perl script boot_elinux and the board will boot using it. Everything now sent to the developer board is stored in the RAM of the board and therefore lost upon reboot. To make the changes permanent use "boot_elinux -f" instead of "./ktest". If you do not use /dev/eth0 on your computer for the network interface on the same segment as your developerboard you must specify which network interface to use with boot_elinux. For example:

boot_elinux -d eth1 -f

Note that the flash file system of the board is then rewritten including configuration files in the /etc directory, which will result in the network settings of the board being replaced with those in ~/axis/packages/system-base/network.conf. You can edit this file and run mkprod again from the devboard directory to make the flash file system image contain your network settings. When the board is up and running you can telnet to it and execute your application by typing "hello" in the shell of the developer board.

Using FTP

When using FTP for transfering files to the developer board, you must put them in the flash file system since you cannot write to the ROM file system. The flash file system is mounted at /mnt/flash on the board. Since transferring a file using FTP will not make the file executable you must set the execute bits manually using the chmod command from the FTP client. Make sure you transfer the file in binary mode (as opposed to ASCII mode). The default root password is 'pass'.

Example:

$ ftp 123.45.67.89
Connected to 123.45.67.89.
220 Axis Developer board - Development version Aug 14 2000 ready.
Name (123.45.67.89:john): root
331 User name okay, need password.
Password: pass
230 User logged in, proceed.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd /mnt/flash
250 Command successful.
ftp> bin
200 Command okay.
ftp> put hello
local: hello remote: hello
200 Command okay.
150 Opening data connection.
226 Transfer complete.
1298 bytes sent in 0.000105 secs (1.2e+04 Kbytes/sec)
ftp> chmod 755 hello
200 Command okay.
ftp> quit
221 Goodbye.