Before 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  and for more information on installing RTAI on other kernels, visit the RTAI home website at .
To 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:
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:
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 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:
The next thing to do is to download the kernel from the Linux kernel repository online, this is done with the command:
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:
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:
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:
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:
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:
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:
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:
to escape from this document without altering it, enter:
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:
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:
Now inside the RTAI directory, configure it first before doing anything else:
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:
The last step is to install the RTAI onto the computer, this is simply done with:
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:
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:
and once in the directory, run the test programs with
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:
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.