Compile and test your modified RTEMS system

This blog post is about how to add code to the classical RTEMS API and compile the whole system, e.g. to test the newly implemented code in a test application. The requirement for this approach to work is that you already built the RTEMS tools and kernel, for example by following the Quick Start guide in the RTEMS user manual. I am using the erc32 board support package.

First we need to identify the RTEMS classical API's source code location. The folder location may differ depending on the configuration of the setup. Generally, the classical API implementation is located in the kernel folder, in  /rtems/cpukit/rtems/src. There, we find the implementation of several operating system services, e.g. for creating a new task in an RTEMS application, the function rtems_task_create(..) located in taskcreate.c needs to be called. In a similar way, semcreate.c allows the application developer to create and use semaphores for their resources.  

If you want to extend the classical API with your own code, you need to save your C file in  /rtems/cpukit/rtems/src as well. For my project, I implement new code in fts.c, and save it in src. fts.c contains all function calls accessible to the RTEMS user. (low level code can be stored in /rtems/cpukit/score/src (correct?))

The header files for your C file should be stored in /rtems/cpukit/rtems/include along with all the other header files for the existing classical API code.

If the C file and the header file are in their corresponding locations, they need to be added to the makefile.am, which is located in /rtems/cpukit/rtems. Following the way the other headers are included, add your header file to the list, in my case I need to add the line include_rtems_rtems_HEADERS += include/rtems/rtems/fts.h. The list is sorted alphabetically, we should follow the convention.

If you take a look at the file, the C files are listed after the header files. To add your C file to makefile.am, just add your file to the list. In my case, I add librtems_a_SOURCES += src/fts.c with the comment ##FTS_FILES, it is easier to find and follows the conventions.

I will cover what the makefile.am does in the following paragraphs (check the figure below). For now we have all the requirements to compile our modified system. 

Since we changed the makefile.am, we need to rerun bootstrap. Bootstrap runs certain commands so that all the needed files are in a state such that we can run configure, make, and make install, to compile the system.

First, set your path with

export PATH=$HOME/development/rtems/4.12/bin:$PATH

We then run bootstrap. Navigate to /kernel/rtems, and run

./bootstrap -c && ./bootstrap -p && \
$HOME/development/rtems/rsb/source-builder/sb-bootstrap

The second part of the command is the location of your rsb source builder bootstrap. The bootstrap runs autoreconf, which makes sure tools are run in a correct manner. These tools are automake, which uses our modified makefile.im to generate a Makefile.in, and autoconf, which uses the configure.ac file to generate a configure script. The bootstrap may take a few minutes.

Next, we want to run configure. A configure script examines the system and gathers the necessary information to convert the Makefile.in to a customized Makefile for our system (and then can be run with just make). Makefiles are a bit confusing, but in a nutshell, Makefile.am is a "automake" makefile. Makefile.in is a "template" makefile, and Makefile is a file created from the former two, usually using configure.

Navigate to the folder /kernel/erc32 and run

$HOME/development/rtems/kernel/rtems/configure --prefix=$HOME/development/rtems/4.12 \
--target=sparc-rtems4.12 --enable-rtemsbsp=erc32 --enable-posix

Now, we can finally run

make

make install

If the makefile.am is not changed again, we can just run the following commands to compile our modified system

export PATH=$HOME/development/rtems/4.12/bin:$PATH

cd /erc32/

make

make install



If we modify the makefile.am, bootstrap needs to be run again, followed by configure and make. Now we compiled our modified system and we can test our code by implementing a test case.

To test the code, navigate to the location where you implemented the C file of your test case. Create a Makefile, taking the Hello World implementation as a template for example.

Set your path variable with

export PATH=$HOME/development/rtems/4.12/bin:$PATH

and the path of the RTEMS makefile for erc32

RTEMS_MAKEFILE_PATH=$HOME/development/rtems/kernel/erc32/sparc-rtems4.12/c/erc32/make

export RTEMS_MAKEFILE_PATH

Then run make

make

which compiles the application to make it executable on the erc32 simulator.

Navigate to the location of your .exe file, initialize the simulator and run your program, replacing fts.exe with the name of your program

sparc-rtems4.12-gdb fts.exe

tar sim

load

r

-----------------
That's all for this post. 

Extra bits:

How a spacecraft lands: 
 

Kommentare

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

Fault Tolerant Scheduler preliminary API

Bild
In this post I want to explain the Fault Tolerant Scheduler API and its implementation structure. In RTEMS, the classical API implementation is located in /rtems/kernel/rtems/cpukit/rtems/src. For example, semrelease.c allows the user to release a semaphore by accessing the function rtems_semaphore_release( rtems_id id ). The header file semimpl.h and sem.h provide  the directives; they are located in /rtems/kernel/rtems/cpukit/rtems/include/rtems/rtems. In sem.h the definition rtems_status_code rtems_semaphore_release( rtems_id   id ) can be found, and it is implemented in semrelease.c. The low level directives used in semrelease.c are located in rtems/kernel/rtems/cpukit/score/src/. The FTS API will be implemented following the same way as existing functions in the classical API. FTS API Description void fts_rtems_task_register(rtems_id id, TECHNIQUE) From the next activation on, the task with the given id will be protected. void fts
Mehr anzeigen

Static Pattern-based Execution (SRE) in the Fault Tolerant Scheduler

Bild
In the FTS, using static patterns is a simple technique, which uses the concept of (m,k) requirements. We execute a pattern such as {1,1,0,1} . When there is a " 1 " in the pattern, the reliable version is executed, and when there is " 0 ", the unreliable version is executed. In this pattern, three out of four correct instances are executed, which complies to the (m,k) -requirement (3,4). This means that there will always be three correct executions in every four instances. There are two types of patterns available for the user, i.e. R-patterns and E-patterns [1] . An R-pattern contains all "0"s at the beginning and all " 1 "s at the end, such as in {0,0,0,1,1,1,1} . In E-patterns, the " 1 "s and " 0 "s are distributed evenly. The pattern's sufficient correctness proofs of complying to an (m,k) requirement can be read in [2] and [3]. The FTS executes this predefined pattern. The pattern is read by the FTS from left to
Mehr anzeigen

Fault Injection and Detection in Static Pattern-based Execution (SDR)

Bild
What is Static Detection and Recovery (SDR) ? In an earlier blog post I explained how Static Reliable Execution (SRE) uses a pattern (predefined sequence of bits) to decide which version of the task to execute. To comply to an (m,k) requirement (m out of k tasks have to be correct to prevent mission failure) SRE executes an error-correction version if there is a "1" at the current bit position, and a basic version if there is a "0". The problem with the SRE approach is that an error-correction version is executed m times to comply to (m,k). In general, error-correction consumes a lot of resources, more than for error detection. One way to correct errors in a calculation is to run the calculation three (or more) times, and then compare the result to use majority voting. This is the reason why we want to execute as less error-correction versions as possible. Instead of executing an error- correction version every time there is a "1" in the pattern, w
Mehr anzeigen