Understanding the Latest Open-Source Implementations of Real ...

Technical ViewUnderstanding the Latest Open-Source Implementations of Real-Time Linuxfor Embedded Processors By: Michael Roeder, Field Applications Engineer, Future ElectronicsBy origin GNU/Linux is an Operating System(OS) for desktop computers and servers. Inapplications usually run on those systems,the timing determinism of operations is not acritical feature. However, GNU/Linux also appealsstrongly to embedded system designers, sovarious efforts to modify or extend Linuxin order to provide time determinism andreal-time capabilities have been made by theLinux community.This article provides an insight into three of theopen-source GNU/Linux real-time extensionscurrently available to embedded designers.Of course, when real-time is examined, it isimportant to be clear about what is meant by‘real-time’. In a hard real-time environment, asystem will always meet its deadlines. This meansthat the system has to guarantee:• Strict event determinism• Bounded latencies; in other words, it mustoffer a guaranteed worst-case latencyHard real-time operation is usually required insafety- or system-critical applications, in forexample the automotive, avionics, medical andautomation sectors. A soft real-time environmentis usually optimized for a ‘best effort’. In mostcases, real-time criteria will be met, but there isno guarantee. Common applications include audioand video encoding and broadcast, and VoIP.A soft real-time environment is usually optimizedfor a ‘best effort’. In most cases, real-time criteriawill be met, but there is no guarantee. Commonapplications include audio and video encoding andbroadcast, and VoIP.A concept linked to that of real time is preemption:the ability of a system to interrupt tasks at many‘preemption points’ (Figure 1). The longer thenon-interruptible program units are, the longer isthe waiting time (‘latency’) of a higher priority taskbefore it can be started or resumed. GNU/Linux is‘user-space preemptible’: it allows user tasks tobe interrupted at any point. The job of real-timeextensions is to make system calls preemptibleas well.In its current form, GNU/Linux can at best satisfysoft real-time conditions, and is not a hard RTOSby design. At the same time, plenty of commercialTask 2scheduledTask 1Task 2starts executionlatencyLowpriorityTask 2 total response timeTask 2scheduledTask 1Task 2starts executionTask 2Task 2HighpriorityTask 1(cont’ed)Task 2 total response timeFigure 1: The operation of non-preemptive (top) andpreemptive (bottom) operating systemstimePreemptionPointstimeRTOSs are available for those with real-time requirements.So why would an engineer bother tomodify GNU/Linux to meet RTOS requirements?The reasons are usually similar to the reasonsthat Linux has been a success in desktop andenterprise computing:• Open architecture, open-source licences andno software patents• Wide choice of application software, availablein source code• Total code transparency• Support for wide range of processors andother hardware• Support for the latest technology in domainssuch as wireless communications, internetprotocol and security• Community support and community projects• Lower total cost of ownership compared to acommercial RTOSCommercial businesses are among those whohave modified GNU/Linux for use in real-timeapplications. But for many embedded developers,the appeal of Linux is that it is open-source, andthey will therefore want any real-time modificationof GNU/Linux to also be open source. Today,there are three mainstream open-source choicesfor implementing real-time applications withGNU/Linux:• Linux with the RT_PREEMPT patch(Linux/PREEMPT_RT)• RTAI• XenomaiThe PREEMPT_RT project is a set of patches forstandard Linux kernels, aimed at improving thenative real-time capabilities of GNU/Linux. Theproject’s goal is to get all its patches approved foraddition to the mainline kernel; for many, this hasalready been achieved.RTAI uses a dual-kernel system: a smalldeterministic real-time kernel with scheduler,and the regular Linux kernel. The Linux kernel ismodified to access an interrupt abstraction layer,the RTHAL, instead of the hardware directly. Thisallows the real-time kernel to block the Linuxkernel while executing real-time functions.Xenomai was launched in 2001 with the aim ofnot only providing real-time capabilities to GNU/Linux, but also of making it easier to port softwarewritten for other RTOSs to GNU/Linux. Toachieve this, it provides real-time APIs (for POSIX*1003.1b, VxWorks, pSOS+, VRTX, uITRON, RTAI)*,known as ‘skins’ that can be used to easily portapplications written for those operating systemsto GNU/Linux.Of the three products, Xenomai has technicalfeatures which – in this author’s opinion – make itthe most interesting free hard real-time approachfor GNU/Linux.Originally, Xenomai was solely based on adual-kernel concept using the ADEOS (AdaptiveDomain Environment for Operating Systems)I-Pipe as an interrupt abstraction layer. In thiscase, Xenomai provides the real-time kernel andthe Linux kernel is just a special low-priority‘task’ which can be interrupted at any time, quitesimilar to the RTAI approach.However, the forthcoming Xenomai 3.0 canoperate as a POSIX user thread on any regularLinux kernel (usually with PREEMPT_RT enabled).261.800.FUTURE.1 • www.FutureElectronics.com

Technical ViewIt therefore allows all applications implementedon Xenomai skins to run directly on a monolithickernel. In other words, Xenomai 3.0 acts as anabstraction layer over the regular Linux kernel,providing this kernel’s real-time capabilities to itsapplications through the various skins. Xenomai3.0 only requires the standard POSIX API, sothat no patching or porting to particular kernelversions is needed.This gives the developer of applications for Xenomaia useful choice: to run the applications under asmall, lightweight and industry-proven real-timekernel, or under a preemptible Linux monolithickernel. It is important to understand, however,that the second choice means that all real-timecapabilities have to come from – and are only asgood as – the underlying Linux kernel itself.Dual Kernel Versus Native PreemptionEach method has its own benefits. The co-kernelapproach has the advantage that the real-timeapplication is totally independent of the Linuxkernel and only depends on the real-time kernel,scheduler and abstraction layers. There is a clearseparation between the real-time and non-realtimedomain. This simplifies maintenance, timingand safety certification.Porting to new CPU architectures is also easy,because only the abstraction layers have to beadapted. An interrupt abstraction layer patch,however, is always specific to a certain kernelversion, and patches are only available forselected versions of the of the mainline kernel.Under the single-kernel approach with the Linux/PREEMPT_RT patch, a POSIX real-time APIallows real-time applications to be developed inthe GNU/Linux user-space, and to benefit fromall development, debugging and profiling toolsavailable there.At some point in the future, the RT_PREEMPTpatch will be completely merged into the mainlinekernel, and then it will be simple to compile areal-time kernel for any supported system. Then,however, every modification to the operatingsystem, such as kernel patches or new drivers,might influence the system in a perhapsundesired way. Therefore the system will haveto be re-qualified and possibly re-certified aftersuch modifications.Another drawback is that the Linux/PREEMPT_RTentails higher worst-case latencies than adual-kernel system.In the author’s opinion, using the POSIX real-timeAPI is the best answer to the problem of decidingbetween the two approaches. Depending on thespecific requirements of the end product, POSIXreal-time applications can either run on Xenomai’sdedicated real-time kernel or on a single Linux/PREEMPT_RT kernel.Performance Evaluation in the Real WorldSo just how ‘real’ is the real-time performanceof Linux? Below is a method to get a quick firstimpression of the latency of any given system.The tool cyclictest is used to schedule a task withthe highest priority every 10ms. The tool knowswhen this task is expected to run and calculatesthe latency or deviation from this expected time.Table 1 shows the results of a test run on aFreescale i.MX53 ARM Cortex-A8 processoroperating at 1GHz. It ran Linux kernel 2.6.38 fromthe DENX Linux tree. Two different test systemswere set up.S_CPRE: standard kernel withCONFIG_PREEMPT (“Preemptible Kernel(Low-Latency Desktop)) enabled./cyclictest –m -n -p99 -t1 -i10000 -1360000S_XENO: Kernel + Xenomai 2.6.0-rc4 + I-Pipe1.18-03./cyclictest -n -p99 -t1 -i10000 -1360000SystemLatency/µsS_XENOS_CPRE1st runS_CPRE2nd runMinimum 2 27 13Average 43 88 81Maximum 58 415 1829Table 1: Cyclic test of single- and dual-kernel Linux systemsThe average latency shows the typical values thatcan be expected from this system. For developersof hard real-time applications, however, only themaximum latency is of interest. The table clearlyshows the superior performance of a dual-kernelsystem.ConclusionWhen the entire PREEMPT_RT patch has goneinto mainline Linux, it will be the method of choicefor ordinary real-time applications. Xenomai 3.0will then allow easy porting of existingapplications to a single, real-time Linux kernel.A dual-kernel approach will continue to be mostappropriate for hard real-time requirements.For developers of new applications, the use of thePOSIX API is highly recommended whether theyare implementing a single- or dual-kernel system.In the near future, the trend to use multi-coreprocessors will allow for new solutions to theproblems discussed in this article. For example,it is already possible in mainline GNU/Linux toassign interrupts to a CPU core and to keep nonreal-timetasks away from this core. Interestingly,therefore, a multi-core system nullifies theperformance advantage of the dual-kernelapproach. An asymmetric CPU such asFreescale’s Vybrid processor family (using acombination of ARM Cortex-A5 and Cortex-M4cores) offers the option of running multipleoperating systems, each optimised for differentfunctions, to even further improve hard or softreal-time performance.* POSIX is a series of IEEE standards that helpensure compatibility across operating systems bydefining a series of application program interfaces(APIs), functions and command-line shells foruse by the OS. Many embedded OSs are POSIXcompliant,including VxWorks, Linux, MQXand QNX.1.800.FUTURE.1 • www.FutureElectronics.com27