- redone command line parsing: gengetopt is now used to generate a parser from the configuration file cmdline.ggo
- cmdline.c and cmdline.h are automatically generated by gengetopt. They are included in the repository for people with no gengetopt
- genBenchmark.py has been modified to use the new command line interface
- removing early error injection prototype from sort demo
Forgot to commit the source files, which used the removed eif framework.
- extending download tools to be able to download elf files to slave processor
- making reset function public while devloping worker cpus for reconos
- shall help with finding the correct reset implementation
- comitting software projects for main processor (linux/*) and slave processor (hw/sdk_workspace/*)
- added fsl_write_block() and fsl_read_block() functions which speed up data transfers over FSL witzh a factor of over 30.
- workercpu.c now tests almost all reconos system calls. exception: pthread condition variable. does anybody use them?
- additionally some benchmarks are added which measure FSL and memory performance:
    - theoretical FSL performance:
        - Write one word per cycle
        - Read  one word per two cylces
        - for 100 Mhz Clock:
        - Write Speed: 400 MB/s
        - Read Speed: 200 MB/s
    - measured FSL performance:
        - Write Speed : 59.379530 KB/s
        - Read Speed : 62.015504 KB/s
        - Echo Speed : 30.534351 KB/s
    - measured FSL Block OP performabce:
        - Write Speed : 1882.352941 KB/s
        - Read Speed : 1882.352941 KB/s
        - Echo Speed : 941.176471 KB/s
    - measured Memory Performance:(no Data Cache)
        - Write Speed : 4138.418793 KB/s
        - Read Speed : 9965.936740 KB/s
        - Copy Speed : 9711.914641 KB/s
Now with bootloader support
- increased perfomance of larger fsl reads/writes:
	- write: from 1.88 MB/s to 3.2 MB/s
	- read: from 1.88 MB/s to 2.66 MB/s
- Reading is still slow because of the interrupt handling

- single word read/writes are slow to: under 60 KB/s how to improve this?
- improved performance of reconos library by using fsl_read/write_block where appropiate.
- added copyright notes
Extended workercpu test program with reconos os call benchmarks.
Here are the results, comparing the original fsl_driver and reconos lib
with optimized versions.

			mbox put mbox get rqueue send	rqueue receive	semaphore	mutex	fsl single write fsl single read fsl block write fsl block read	memory write	memory read
original		1106.19	 1103.32  51.01		53.78		994.04		681.83	57.2		 60.22		 1885.78	 2025.46   	4146.8		9996.34
fsl_optimized		1145.1	 1093.49  50.87		51.77		980.67		680.07	56.5		 58.24		 3038.19	 2734.38   	4140.51		9978.08
fsl+reconos optimized	1100.54	 1140.53  617.12	593.5		982.87		682.8	56.55		 57.75		 3038.19	 2734.38   	4143.65		9996.34

This has been measured with Linux on a MicroBlaze as Master CPU and a Microblaze with bare-metal software as hardware thread (hwt). The MBOX and RQUEUE sizes are set to 1. RQUEUE message length is 1024 bytes.
FSL single writes and reads single words in a loop. FSL block write and read operate on 32KB of data. As a comparison, memory write and read show how fast the Microblaze Master Processor can read from /write
to main memory.
The units are as follows: mbox and rqueue numbers are calls per second on the master cpu. Semaphore and Mutex numbers are lock/unlock pairs per second. This is need for proper synchronization with slave.
The remaining numbers are kilobytes per second.

Normalized to the original version, improvements may be seen more easily:

			mbox put mbox get rqueue send	rqueue receive	semaphore	mutex	fsl single write fsl single read fsl block write fsl block read	memory write	memory read
original		1	 1	  1		1		1		1	1		 1		 1		 1	   	1		1
fsl_optimized		1.035	 0.991	  0.997		0.962		0.986		0.997	0.987		 0.967		 1.611		 1.350	   	0.998		0.998
fsl+reconos optimized	0.994	 1.033	  12.098	11.035		0.988		1.001	0.988		 0.958		 1.611		 1.350	   	0.999		1

In summary: Block transfers over fsl improved by 35% for reading and 61% for writing.
This resulted in a factor 11 to 12 boost for the reconos queue. All other calls have
nearly the same performance as before. Please note that i have only made one benchmark
run per version, so there might be some uncertainity.
- extended mhsaddhwts.py so that it is able to add a microblaze workercpu as a hardware thread.
- just add a line "microblaze_<version>" to the list of hardware threads in the setup_linux.sh
- adding fsl2fifo module which is needed to connect a microblaze cpu to the reconos memory subsystem  via microblazes fsl
- restructured workercpu software: libreconos is now a library, which is included by the bootloader and other programs running on the worker cpu
- added a first version of worker cpu implementation of sort demo
- setup script modified to implement 7 worker cpus. At the moment this is somehow the maximum number of worker cpus.
(With the main processor there are 8 microblaze in the system.) With more than 7 worker cpus, the mdm debug module
is not able to access any cpu and therefore downloading code or the linux kernel is not working.
Merge branch 'workercpu' into shadowing

Conflicts:
	linux/reconos/libreconos-us/reconos.c
Workercpu software will be held in the respective hardware thread directory.
That means that for microblaze worker cpus, their software programs are treated as part of the hardware thread and therefore
will be stored in the microblaze_v8_40_a directory.
Merge branch 'workercpu' into shadowing