Summary
RTEMS comes with a set of small applications designed to test various features of a Board Support Package, which implements basic hardware "hook" functions needed by RTEMS. The DAT group implements two generic BSPs, one Virtex 4 FPGAs and one for Virtex 5 FPGAs. These BSPs in their turn have "application hooks" which allow for adjustment to application specific hardware variations, e.g., number of ethernet ports. For more information on the structure of BSPs look here .
Virtex4 BSP
RTEMS 4.10.2
Application Pass? Comments
----------- ----- ------------------------------------
hello Y
base_mp n/a Requires a true multiprocessor system
with shared memory.
base_sp Y Output mangled by our console driver.
capture n/a Requires an interactive console.
cdtest Y The sample output is obsolete. The
application now tells whether
construction is local or global. No
iostream test is performed but there
is now an exception test.
fileio n/a Requires an interactive console.
iostream Y Like hello but uses C++ iostreams instead
of printf().
loopback Y Test of network stack in software loopback
mode.
minimum n/a We'd need a custom idle task for this.
nsecs N It seems we have no working nanosecond
clock.
paranoia Y Rating of arithmetic: Excellent.
pppd n/a Requires a working serial port.
ticker Y PIT interrupts evidently do occur since
task TA1 gets woken up at 5-second
intervals. The starting of the other two
tasks was commented out, not by me.
unlimited Y Tests the feature allowing one to allocate
as many RTEMS objects as working-space
memory allows.
Out of nine applicable tests the system passes eight; only nsecs fails.
Our BSP's console driver is not MT-safe so output from multiple tasks
gets garbled. We could try making all the tasks non- preemptable or,
for these tests, we could use a binary semaphore.