Installation of RTAI on Custom-made Kernel

3.1 IntroductionBefore any of the real-time experiments could be compiled and run on a computer, there

are a number of things that have to be done. A Linux operating system had to be installed

on a computer configured to be able to support a real-time interface. A Hardware

Abstraction Layer needed to be patched on to the computer to link up the real-time

scheduler to the hardware and have control of the computer. The Real-Time Application

Interface itself needed to be installed as well to run the real-time experiments.

This chapter explains in detail all the steps in how to install a Linux Ubuntu distribution

on to an operating system and also how to install the latest available Real-Time

Application Interface to run on it. There are many steps that are different to installing

Ubuntu than other distributions of Linux and also more changes when it comes to

installing the RTAI.

For more advice information installing Ubuntu, visit [5] and for more information on

installing RTAI on other kernels, visit the RTAI home website at [2].

3.2 The building of a Linux kernel and installing RTAITo build a custom Linux kernel on a computer, the user needs to be working from a

Linux kernel already. There are two ways to be able to this. One way is to work off a

computer with Linux already installed and create a new kernel from there. The other is to

boot up from a Live CD, such as the one in appendix [C], install this on the computer and

then work from this to continue to install the custom kernel.

All commands in Linux are entered into the terminal to tell the kernel what to do next.

To compile a kernel, the user needs to be the ‘Superuser’ of the computer, this is the

equivalent of being an administrator in Microsoft Windows. To do this, before any

command that needs permission, the user needs to enter:

sudo

This ensures that the user has the right to perform any command on the computer from

creating a new directory to removing an entire kernel. In Ubuntu, this is asked before the

majority of commands that the user types. This can get very tiresome and inconvenient,

so to switch to the being the root user for the entire session, enter:

sudo su

A password may have to be entered at this point to verify that the user actually has

permission to be the administrator of the computer.

The next two lines update packages needed for kernel installation and installs them. It

also installs a few commands used during the process of the installation that might not

have been installed previously on the kernel in use before:

apt-get update

apt-get install kernel-package libncurses5-dev fakeroot wget bzip2

First of all, enter the directory that we will be working from and that will soon contain the

directories for the kernel and RTAI:

cd /usr/src

The next thing to do is to download the kernel from the Linux kernel repository online,

this is done with the command:

wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.17.tar.gz

This command downloads the tarball (compressed version) of the Linux 2.6.17 kernel

from the kernel.org website and saves it into the ‘/usr/src’ directory. The next step is to

untar the tarball, (like unzipping a file):

tar xvzf linux-2.6.17.tar.gz

This unpacks the folder and leaves you with the kernel which is to be configured and

built on the computer. During the build of the kernel, some of the build commands will

try to link to the directory ‘/usr/src/linux’, so a symbolic link needs to be created. This is

creating a directory that points to another directory. So the link created here, will point to

the kernel that was just untarred in the same directory:

ln –s /usr/src/linux-2.6.16 linux

The next step to take is to download the version of RTAI that will be installed on the

kernel. This version has to be able to support the version of the kernel that will be

installed. The version that we will be using is ‘rtai-3.4’, which was developed in

November 2006 and the Linux kernel was released previous to this and is fully operable

with this version of RTAI. Download from website with this command:

wget https://www.rtai.org/rtai/rtai-3.4.tar.bz2

This will download the RTAI into the same /usr/src directory that the kernel version is

downloaded into provided the user hasn’t changed from this directory since entering it.

The .bz2 extension, means that this is a tarball also, but is further compressed than the .gz

tarballs and a similar command is used to untar this:

tar -xvf rtai-3.4.tar.bz2

This has now untarred the folder, which contains the RTAI that will be installed and that

the computer will be running tasks from. It also the HAL (Hardware Abstraction Layer)

patch that will be patched onto the kernel so that the control of interrupts will go through

the RTAI before reaching the kernel, this lets the kernel can implement a real-time

interface.

Another symbolic link needs to be created for the RTAI as well, for when it is being

installed:

ln –s /usr/src/rtai-3.4 rtai

Before starting the building of the kernel, the HAL patch needs to be patched onto it, this

saves patching it on later and rebuilding the kernel again, so enter the kernel directory:

cd /usr/src/linux

and then patch onto the kernel source:

patch –p1 < /usr/src/realtime/base/arch/i386/patches/hal-linux-2.6.17.patch

This patches the HAL patch onto the kernel in the current working directory, which is the

kernel that is going to be built. The kernel is almost ready to build, it just has to be

configured first, and a few changes have to be made to make sure that it is compatible to

run the RTAI:

make menuconfig

This option brings up a menu of the configuration of the kernel in a graphical interface.

Figure 3.1 – Screenshot of the configuration stage of the kernel build

“make xconfig”, could have been entered either, this brings up a more basic GUI, or

“make config”, which just gives every line of the configuration to be entered on the

command line and is very long-winded. “make oldconfig” would have configured the

kernel we are about to build with the same configuration that the kernel running at the

moment is using.

Ok so now the configuration has to be changed:

In the code maturity level options, set the "prompt for development and/or incomplete

code/drivers" option to 'yes'.

In the "loadable module support" section, make sure that the "Enable loadable module

support" is set to 'yes', and set the "Module Versioning support" is to 'no'.

In the "processor type and features" section, set the "Preemptible kernel" and the "Use

register arguments" options to 'no', and make sure to set the "interrupt pipeline" option,

(aka IPIPE) to 'yes'.

Finally, enter “File systems”, inside there is another folder called “Pseudo filesystems”,

in here, make sure that “/proc file system support” is set to yes. Remember to save the

kernel configuration on exit.

A line has to be added to the Makefile of the kernel before it is configured. Newer

versions of Ubuntu have changed the flags that the compiler uses and there is a flag that

is missing that needs to be added or else the build process will not complete and giving

out an error, so still in the /usr/src/linux directory, enter:

vim Makefile

About around line 340 there will be a line naming the ‘CFLAGS’, Type the letter ‘i’ to

start editing the file, now enter ‘-fno-stack-protector’ as another flag here. Press escape to

stop editing the file and the enter ‘:wq’ to write and quit the Makefile.

There are two commands that build the kernel, they both take a long time to execute, it

could even be a few hours depending on the processor within the computer:

make-kpkg clean

fakeroot make-kpkg --initrd --append-to-version=-custom kernel_image kernel_headers

These commands are scripts that automate and replaces the sequence “make dep, make

clean, make bzImage, make modules”, used on other distributions of Linux.

This basically, creates any dependencies that the kernel might need, deletes any previous

configurations of the kernel and creates the new configuration file. Any modules that are

to be used with this kernel are created and installed.

Then they will create ‘initrd’, this is the initial ramdisk image (a filesystem from which

the kernel can execute programs and load kernel modules as part of the boot process) and

change the name of the kernel to ‘custom’ in this case. Whatever comes after the minus

sign in place of the word custom, as long as it does not contain a whitespace, will become

the new name of the kernel. The command also creates the kernel image (builds the

actual kernel) and the kernel headers (C language header files needed to build most

standard programs and rebuild the kernel).

After the long wait, there will be two ‘.deb’ packages leftover in the /usr/src directory

where the kernel was being installed. These are the actual kernel image and header files

that need to be installed.

So now enter that directory and install them both:

cd /usr/src

dpkg –i linux-image-2.6.16-custom_2.6.16-custom-10.00.Custom_i386.deb

dpkg –i linux-headers-2.6.16-custom_2.6.16-custom-10.00.Custom_i386.deb

Now that is the kernel fully installed on the computer with the Hardware Abstraction

Layer patch applied and is ready to be booted from and have the RTAI installed on it.

The new kernel can be observed by looking at the boot up menu in the directory

“/boot/grub/menu.lst”, using the text editor vi, the boot up options are at the end of the

document:

vi /boot/grub/menu.lst

to escape from this document without altering it, enter:

:q

Now reboot the computer and run from the newly created kernel to check and see is it

fully operating, don’t forget when “GRUB loading, please wait. Press escape to enter the

menu…”, is displayed, to press escape to view the menu of bootable kernels to choose

from:

reboot

Now presuming you pressed escaped fast enough to enter the menu and see the previous

working kernel and the kernel you just created beneath it, if not then reboot the computer

again and repeat the process. When the option is displayed, choose the kernel that was

have created – 2.6.17-custom and press enter.

The kernel that is now running is the kernel that was just built and installed with the last

set of commands. To install the RTAI next, it has to be configured first, so open the

terminal again to work from the command line again and enter:

cd /usr/src/rtai

Now inside the RTAI directory, configure it first before doing anything else:

make menuconfig

In the machine menu change the number of processors to one or however many

processors there may be on the computer being worked on. Choose no to RTAI-lab as

this is only an additional part of the RTAI package which is a tool chain for real-time

software and control system development and this will not be needed. (If this is decided

to be installed, the MESA library and the EFLTK package to support the GUI that RTAI-

lab uses will both first have to be installed).

Save the new configuration when leaving it, and then create the RTAI folders and files

with:

make

The last step is to install the RTAI onto the computer, this is simply done with:

make install

When this has completed, RTAI has been installed on the computer and it needs to be

rebooted to make sure it works ok. Reboot the computer again and choose the kernel that

you created and installed RTAI on to make sure it works.

There is a test-suite that comes with the RTAI package to test how well or even if the

RTAI works on the computer. There are 3 programs that perform latency, pre-empt and

switches test on both the kernel and the user. The results for the kernel test should be

slightly faster than the tests on the user. These are found in /usr/realtime/testsuite

But before these tests can be run, one more change has to be made. The RTAI-loader in

the real-time directory uses ‘sh’ also known as shell to perform it’s commands. On most

Linux distributions, ‘bash’ is linked to ‘sh’ and this is what executes any commands, but

in Ubuntu, ‘dash’ is linked instead and this gives errors when trying to test how the RTAI

performs on the machine. To resolve this error, the RTAI loader has to be altered. So edit

the file with:

vim /usr/realtime/bin/rtai-load

and using ‘i’ to insert and escape followed by ‘:wq’ again to edit a file, change the first

line from “#!/bin/sh” to “#!/bin/bash”.

To perform any of the real-time tests, go into any of the 6 directories using any of the

following commands:

cd /usr/realtime/testsuite/user/latency

cd /usr/realtime/testsuite/user/preempt

cd /usr/realtime/testsuite/user/switches

cd /usr/realtime/testsuite/kern/latency

cd /usr/realtime/testsuite/kern/preempt

cd /usr/realtime/testsuite/kern/switches

and once in the directory, run the test programs with

./run

To stop the program from running, press ‘control c’.

The results of how the user or the kernel performs will be displayed following the run

command on the screen. If these tests do not work, it is because the computer has been

restarted again and there is modules and devices that the testsuite needs to run these

programs, the hardware abstraction layer needs to be loaded into the kernel as a module

for real-time tests to run, as does a real-time scheduler. Also there are devices that the

testsuite uses that are volatile and these need to be created again. This is done in a few

simple commands:

insmod /usr/realtime/modules/rtai-hal.ko

insmod /usr/realtime/modules/rtai_lxrt.ko

cd /usr/src/linux

make devices

Now go back and enter the directories where the tests are and enter ‘./run’ to run each of

them and see how well the RTAI performs.

3.3 Testing the RTAI functionality

3.3.1 The Latency Test

The first test is the latency test. This test verifies the architectural latency and jitter up to

the scheduling of a task. When the test is run in one-shot mode, the test measures the

difference in time, between the expected switch time and the time when a task is actually

called by the scheduler. When run in periodic mode, the difference in time is used to

measure the scheduling latency/jitter. Jitter is how much of a deviation the test measures.

No over-runs and a low latency average are desired, if there are over-runs, this means that

the current system is not capable of running real-time tasks. The system will then have to

be tweaked and calibrated to be more suitable for real-time capabilities.

3.3.2 The Switches Test

This test provides information about the maximum amount of time that the RTAI needs

to disable interrupts. This test checks for the task switching timings. The test puts the

scheduler under a lot of pressure by running about 10 different tasks at the same time and

uses a repeated sequence of suspend/resume on the tasks, as well as a sequence of

semaphore take/give commands. This test gives a good idea about the architectural

switching time, if the results are high then the system may probably have to be tweaked a

little more

3.3.3 The Pre-empt Test

The preempt test is to check do the schedulers work ok when placed under a lot of

pressure. The latency calibration task is combined with two tasks that are given to the

scheduler. One is a slow task and one is a fast task, and they will have different levels of

preemption. The jitters of the latency test are displayed next to highest priority, and also

of the slowest task at lowest priority. Reasonable jitters in the outputted results are a clear

indication of preemption.

All the tests need to be run for both the user and the kernel to fully understand the overall

latency of the system. In user mode the results are expected to be slightly slower than the

results for the tests performed on the kernel but still decent overall.