Embedded RTLinux: A New Stand-Alone RTLinux Approach Miguel Masmano1 , Apolinar Gonz´ alez2 , Ismael Ripoll1 , and Alfons Crespo1 1 Universidad Politecnica de Valencia, Spain 2 Universidad de Colima (Mexico)
[email protected] [email protected] {iripoll, alfons}@disca.upv.es Abstract RTLinux is a hard Real-Time OS (RTOS) which uses an original approach to develop complex hard real-time applications in a fairly easy way: Executing a hard RTOS (RTLinux itself) jointly with Linux in the same box. This approach enables splitting up a hard real-time application according to its criticality, the part with deadline requirements is run on the RTOS while the part with no “special” time requirements is executed on Linux. However, this approach presents two drawbacks. Firstly, Linux has a big footprint, especially in the 2.6 series, which is unsuitable for system with low resources. On the other hand, it is possible for a Linux application to directly disable interrupts, disrupting the real-time properties of RTLinux. Several years ago, people from our department developed Stand-Alone RTLinux (SA-RTL), a RTLinuxcompatible standalone kernel which was able to execute RTLinux applications in a bare machine. However, this approach was not completely optimum since was built cutting and pasting code from RTLinux, being rather difficult to maintain. Besides, it did not provide binary compatibility with RTLinux applications. In this paper we present Embedded RTLinux (ERTL), our second approach of what a Stand-Alone RTLinux system should be. This second kernel, unlike SA-RTL, just replaces Linux with a minimal set of drivers, allowing to execute the original RTLinux jointly with a RTLinux application on a bare machine.
1
Introduction
executes a RTOS (RTLinux itself) and a general purpose OS (usually Linux) in the same box. The RTOS is who actually manages the whole physical hardware while the OS is executed over a virtual hardware layer. The general purpose OS is run on the background as the least priority thread of the RTOS.
1
The aim of a general purpose operating system (OS) is to provide a good average response time, not to guarantee maximum bounds of execution time. This makes general purpose OSes inadequate to achieve hard real-time performance, with guaranteed deadlines. On the other hand, besides running correctly an application, the goal of a real-time operating system (RTOS) is to fulfil the timing requirements of the application. The most RTOSes often provide a spartan programming interface with just the fairly necessary primitives (thread, I/O, and synchronisation procedures), avoiding other interesting features (network, graphic interface, etc) in benefit of the time determinism. Thus, turning the implementation of a complex application into a very tedious task. RTLinux is a hard RTOS which works around this drawback by using an innovative approach. It 1 This
RTLinux enables and eases splitting up a quite complex, hard real-time application on two or more logical parts according to their timing requirements. Executing, subsequently, each of these parts in the most suitable kernel. For example, an application to control a motor can be easily divided in the control routines of the motor, with hard real-time constraints, which will be executed on RTLinux. And the user interface, without any timing requirement, which will be run on Linux with all the advantages that it represents. However, although this approach presents multiple benefits, it also shows some drawbacks. Firstly, the large footprint of the Linux kernel (up to several Mbytes) can suppose a problem for system with low
work has been supported by the Spanish Governement Projects: TIC2005-08665 and DPI2005-09327
1
resources. Secondly and more important, any Linux application with root permissions can disable interrupts, disrupting the normal operation of RTLinux. Several years ago, to work around these problems, some people of our research group proposed a stand-alone version of RTLinux. This new version of RTLinux, called SA-RTL, would replace the original RTLinux when its use were not suitable. However, SA-RTL shows two important disadvantages. On the one hand, since it was built cutting and pasting code from a specific version of RTLinux, it is hard to keep it up-to-date. On the other, SA-RTL does not implement binary compatibility with RTLinux applications but source-level compatibility, forcing to recompile the whole RTLinux application. In this paper, we present a new stand-alone version of RTLinux called Embedded-RTLinux (ERTL for short), unlike SA-RTL, ERTL does not implement a new version of the RTLinux kernel but it replaces the whole Linux kernel with a thin software layer which enables executing directly RTLinux and a RTLinux application on a bare machine. This paper has been organised as follow, next section shows a brief overview of RTLinux. Section 3 describes a previous work carried out by our grup the Stand-Alone RTLinux. Section 4 details the eRTL design criteria. Section 5 performs an evaluation of eRTL. Finally, some conclusions are drawn.
2
pose OS and a newly developed executive (RTLinux itself) running underneath Linux.
FIGURE 1: RTLinux’s architecture The RTLinux internal architecture, figure 6, can be split up into two separate parts: a hardware abstraction layer (the RTLinux’s HAL), and the executive operating system. The RTLinux’s HAL2 is in charge of the hardware devices that conflict with Linux (basically, the interrupt controller and the hardware timers). This layer provides access to these hardware devices to both the RTLinux executive and Linux in a prioritised way. Hardware virtualisation is achieved by directly modifying the Linux kernel sources applying a patch file. These changes do not replace the hardware drivers but prepare the kernel, adding hooks (see section 2.1), to dynamically replace the drivers. The RTLinux executive implements a partial Minimal Real-Time POSIX.13 interface. The executive is highly customisable. It has been implemented in a modular way that allows to dynamically load into the system the parts of the API that are used by the application.
Overview of RTLinux
Linux is a general purpose OS with multiprocessor support, management of large amounts of memory, efficient handling of a large number of running processes, etc. In fact, nowadays, Linux is a fullfeatured, efficient (good throughput) OS, but with little or no real-time performance. Currently, there are two different approaches to provide Linux with real-time performance:
2.1
1. Modifying Linux to make it a kernel with realtime characteristics. The modification would consist in adding more predictability, more responsibility, and a real-time API.
Taking over the Linux Kernel: The RTLinux’s hooks
As mentioned above, some Linux’s drivers (basically, interrupts and timers) are modified to directly deal with the RTLinux’s HAL instead of with the hardware. These modifications are carried out inserting hooks (in the RTLinux terminology, a hook is a pointer to a function initially initalised to null) in the Linux’s source code. The execution of a hook is only performed when the hook points out to a valid function (actually, the hook will be called always that its value is not null).
2. Adding a new operating system (or executive) that takes over some hardware subsystems (those that compromise the real-time performance) and who gives Linux a virtualised view of the controlled devices. RTLinux was the first project following the second proposed approach: Linux as the general pur-
2 The mechanism of intercept hardware access off a general purpose OS to implement a real-time layer is covered by U.S. Patent No. 5,995,745, titled: “ADDING REAL-TIME SUPPORT TO GENERAL PURPOSE OPERATING SYSTEMS”. The owner of the patent permits the use of the patented method if the software is released under the General Public License (GPL). For more details read “The RTLinux Open Patent License, version 2.0” [8].
2
The next example, extracted from the file entry.S of an already-patched Linux kernel, shows an example of how a hook in RTLinux works: movl rtl emulate iret, %eax; testl %eax, %eax; je 1f; call ∗%eax; 1:
A C translation of this assembly code could be: if (rtl emulate iret ) (∗rtl emulate iret )();
This hook, rtl emulate iret, emulates an interrupt return when the processor winds up the execution of the interrupt handlers, as can be seen, rtl emulate iret will be only executed when its value is not null. These hooks are strategically inserted into the Linux kernel code, enabling RTLinux to take the control of the machine once it is initialised. The most important hooks inserted in the Linux kernel are:
FIGURE 2: SA-RTL’s architecture SA-RTL, figure 2, is a small kernel, which implements the minimal quantity of drivers to: boot the machine, manage interrupts and traps, and write on the screen. Besides, to provide a better RTLinux compatibility, some code (basically, the scheduler) of RTLinux has been directly used in SA-RTL. However, this approach has two manifest drawbacks:
• rtl emulate iret: emulates the behaviour of the iret instruction, that is, enabling interrupts if they were on before the interrupt was triggered.
• SA-RTL is only compatible with RTLinux applications at source level but not at binary level. In other words, to run a RTLinux application, its source code must be available and has to be recompiled.
• rtl syscall intercept: intercepts the execution of Linux’s System Calls.
• SA-RTL was built cutting and pasting code from a specific version of RTLinux-GPL3 . Thus, complicating the support and upkeep of the kernel when a new version of RTLinux-GPL is released.
• rtl exception intercept: intercepts the execution of traps (memory fail, segmentation fault, division by zero, ...). • rtl do exit handler: intercepts the finalisation of a Linux’s process.
ERTL also implements some features that did not exist in the original RTLinux, among others, inter-threading memory protection, that is, the ability of executing each thread in an isolate memory space. These features, although interesting and funny, are not either POSIX standard or RTLinux standard. An application spending these capabilities will not be compatible with other RTOSes.
Besides these hooks, RTLinux also replaces cli (disable interrupts) and sti (enable interrupts) with fake ones which will emulate their operation, preserving, thus, RTLinux real-time capabilities.
3
Previously SA-RTL
existing
work:
4
Several years ago, some people of our department implemented an initial stand-alone version of RTLinux: SA-RTL [7]. The aim of this project, developed in the OCERA [1] framework, was to implement a small-footsized kernel which were RTLinuxcomplaint, allowing the execution of RTLinux applications on a bare machine. 3 RTLinux-GPL
ERTL overview
Embedded RTLinux (ERTL for short) is our second, improved approach of what a stand-alone RTLinux should be. Unlike SA-RTL, ERTL (figure 3) does not implement a new version of RTLinux but replaces the whole Linux kernel with a thin software layer. ERTL
is the GPLed version of RTLinux, currently maintained by the RTLinux community.
3
• i8259 driver: This driver is a set of functions packed in the irq desc structure which allows to deal with the programmable interrupt controller (i8259). RTLinux uses them to control hardware interrupts.
provides, on the one hand, the minimum functionality to: boot the machine, manage interrupts and traps, and read from the keyboard and write to the screen. And, on the other, the RTLinux’s hooks, allowing, thus, the execution of an unmodified version of RTLinux on its top. The main advantage of ERTL is that it is compatible with RTLinux (in fact, it executes the actual RTLinux once it has already been compiled for Linux) and the RTLinux applications at binary level, what means that any application that alreadyworked for RTLinux will work on ERTL. Currently, ERTL is only available for the i386 architecture. However, due to its simplicity, it should be rather portable to other architectures where RTLinux is already working.
4.1
• Dynamic memory manager: ERTL emulates the behaviour of the vmalloc and vfree via the TLSF [5, 6] dynamic memory allocator. • Idle task: This task emulates the whole Linux kernel, that means that this task will be executed with the lowest priority task of the system. Its only functionality is to execute RTLinux’s soft interrupts as the Linux kernel would do. For instance, printing on the screen every time a RTLinux’s application uses the rtl printf routine.
ERTL architecture
• Screen driver: A simple screen driver which permits ERTL and RTLinux writing on the screen.
ERTL, figure 3, provides, on the one hand, the minimum functionality to: • Boot the machine: ERTL takes advantage of the Multiboot Specification [3]. Hence, the code involved in this process is quite simple and just has to: 1. Create a valid Global Descriptor Table (GDT) with just two segments, a code and a data segment. 2. Create a valid stack. 3. Set up the ERTL’s memory manager with the free memory reported by Multiboot. 4. Jump to the first C routine. 5. Call RTLinux’s init module functions whose address were gathered during the ERTL kernel building process (see section 4.3).
FIGURE 3: ERTL’s architecture
• Manage interrupts/traps: when an interrupt or a trap is triggered, ERTL emulates the Linux kernel’s behaviour, that is:
4.2
Emulating Linux
In order to allow the execution of RTLinux, the following hooks have been inserted inside the ERTL’s code:
1. Store the interrupt number. 2. Save all registers calling the Linux’s SAVE ALL macro.
• rtl emulate iret: This hook is executed just before calling the iret, emulating, thus, the behaviour of this instruction.
3. Call a routine called do IRQ. This function deals with the i8259 driver to re-enable this device and allow future interrupts. 4. Restore all registers calling the Linux’s RESTORE ALL macro. 5. Call the RTLinux hook’s rtl emulate iret as described in the section 2.1. 6. Execute iret, restoring, thus, the execution of the current application.
• rtl exception intercept: This hook is called just after a trap has been “issued”, enabling RTLinux to manage it before Linux’s trap handlers do. The following symbols are also exported to RTLinux:
4
5
• irq desc: This structure packs all functions related with the i8259 driver. RTLinux does not implement the i8259 driver, therefore, needs to use the driver provided by Linux.
ERTL has been evaluated to measure the stability and the overhead introduced by the kernel. The test platform is an embedded system based on Pentium II at 300 MHz. The system has 64Mb of memory.
• do IRQ: During its initialisation, RTLinux replaces the function do IRQ with its own interrupt handler. Since ERTL is completely RTLinux-aware, it is unnecessary to patch the cli and sti instructions, since they are not executed in an indiscriminate way.
4.3
Evaluation of ERTL
5.1
Stability evaluation
In order to evaluate the stability the kernel, we have evaluated the its latency. This evaluation has consisted in a periodic task which program a delay and waits for it. As soon as the task is executed, the task reads the clock value and calculates the difference between the programmed delay and the real clock, then the task period is increased in order to evaluate the kernel latency from 100 nanoseconds to 1 seconds.
Building an ERTL kernel
ERTL provides the script build ertl to ease the generation of an ERTL kernel. The figure 4 reflects the process of building a ERTL kernel when build ertl is invoked with the suitable parameters. The process can be summarised as follow:
task body task estad is
1. Firstly, each RTLinux module file (rtl.o, rtl sched.o, rtl time.o, ...) and the RTLinux application are processed to rename the init module routine to init file name. For example, the init module function of a RTLinux module called hello.o will be renamed to init hello. Besides, the address of these routines are written down in an external file.
Period: Time span:=nanoseconds(100); Period Cte: integer :=1; Period Final:constant time span; next, clk: Time; error : Time; Periodo Int: Integer; begin while Period < Period Final loop next:=clock; for I in 1..100 loop clk := clock; error := error + (clk−next)); next := next + Period; delay until next; end loop; Put Time(error)); Period := Increment Period(Period); end loop; end task estad;
2. The RTLinux module’s files and the RTLinux application are linked together creating a single object file. 3. The object file resulted in step 2 is linked with the ERTL library, generating, thus, a working ERTL kernel.
Next figure shows the latency measured in the experiment.
FIGURE 4: Building process of an ERTL kernel. As mentioned above, ERTL implements the multiboot specification, therefore, to boot an ERTL kernel, it is necessary to use a multiboot-compliant boot loader, such as GRUB [2] and Etherboot [4]. 5
jointly with a RTLinux application on a bare machine. ERTL provides the minimum functionality to: boot the machine, manage interrupts and traps, and read from the keyboard and write to the screen. And the RTLinux’s hooks, allowing, thus, the execution of an unmodified version of RTLinux on its top. The main advantage of ERTL is that it is compatible with RTLinux (in fact, it executes the actual RTLinux once it has already been compiled for Linux) and the RTLinux applications at binary level, what means that any application that alreadyworked for RTLinux will work on ERTL. ERTL supports the same languages that RTLinux: C, C++ and Ada. The stability and overhead measures showed that these measures are a bit lower than RTLinux and SA-RTL.
FIGURE 5: Stability measure As can be seen in the plot, the periods of 10 microseconds have constant latency (25 microseconds). Nonetheless, lower periods show higher latencies because of the time taken to program the system timer.
5.2
Overhead measures
The overhead tries to measure the cost of the scheduling algorithm. In order to avoid interferences, a small application has been built to send through a digital output signals to an oscilloscope. Overhead values has been measured from the oscilloscope. Next figure shows the measures carried out.
References [1] OCERA: Open Components for Embedded RealTime Applications, 2002. IST 35102 European Research Project. (http://www.ocera.org). [2] Yoshinori K. Okuji, GRand Unified Bootloader, available at http://www.gnu.org/software/grub/
FIGURE 6: 3 tasks overhead measure The measure obtained has been: Overhead = (t1 − t2 − t3 − t4)/4 = (100µs − 300µs − 300µs − 300µs)/4 = 25s Another way to measure the overhead has been performed using the Hartstone benchmark[9]. This test tries to test the ability of a system to handle hard real-time applications under well-defined workloads and timing constraints. The workload is composed by 5 harmonic tasks which are initialised to a lower period. Starting with the baseline task set, all the frequencies are scaled by 1.1, then 1.2, then 1.3, and so on for each new test until a deadline is missed. The per-period workloads of all tasks do not change. The scaling preserves the harmonic frequencies. A test finishes when a task misses its deadline. At this point we measure the CPU utilisation. In the previous version of the SARTL we obtained a 99,2 % of the CPU while the value obtained by ERTL is 99,6 %. The test has been written in Ada.
6
[3] Yoshinori K. Okuji, Bryan Ford, Erich Stefan Boleyn, and Kunihiro Ishiguro. The Multiboot Specification, available at http://www.gnu.org/software/grub/ [4] EtherBoot Project, available at http://www.etherboot.org/ [5] Miguel Masmano, Ismael Ripoll, Alfons Crespo, and Jorge Real, TLSF: a New Dynamic Memory Allocator for Real-Time Systems, Proc. of the 16th Euromicro Conference on Real-Time Systems. [6] Miguel Masmano, Ismael Ripoll, and Alfons Crespo, Dynamic storage allocation for real-time embedded systems, Proc. of Real-Time System Simposium WIP. [7] Vicente Esteve, Ismael Ripoll, Alfons Crespo, Stand-Alone RTLinux-GPL, Fifth RealTime Linux Workshop.
Conclusions
[8] FSMLABS, The RTLinux Open Patent License, version 2.0, available at http://fsmlabs.com/products/rtlinuxpro/rtlinux patent.html
In this paper we presented Embedded RTLinux (ERTL), a new approach of what a Stand-Alone RTLinux system should be. This second kernel, unlike SA-RTL, just replaces Linux with a minimal set of drivers, allowing to execute the original RTLinux
[9] Nelson Weiderman. Hartstone: Synthetic Benchmark Requirements for Hard Real-Time Application, 1990 Technical report CMU/SEI-89-TR-23. 6
