Chapter 3 Design and Implementation of RTLinux in Embedded Real Time Linux System
From the previous chapter, we already know that Linux is a general operating system that applies it to the embedded real-time environment. Especially when running the kernel thread, Linux closes interrupts, other issues include time-time scheduling, time uncertainty of virtual file systems, lack high-precision timers. So the existing Linux is transformed, that is, the Linux is real-time, this chapter will introduce the structure of RTLinux and how RTLinux is real-time.
3.1 RTLINUX structure
RTLinux uses a simple solution of well-known virtual machine technology to solve these mutually peer-to-peer resolution above. A simulation program is added to replace the underlying interrupt program of Linux. A small real-time kernel and Linux kernel sharing control processor. If an interrupt from a real-time kernel from a hardware will be processed directly, an interrupt belongs to the Linux kernel is processed by an interrupt emulation program. If the Linux kernel interrupt request is not allowed, the Interrupt Analog Program will mark the interrupt in the interrupt queue. When the interrupt request of the Linux kernel is allowed, the interrupt in the interrupt queue will be executed. Therefore, the operation of the real-time kernel can obtain the immediate corresponding to the machine, and the Linux kernel cannot delay the implementation of the real-time task. Communication between the real-time task and the process running in the Linux kernel is performed by FIFOS with shared memory. Using the scheduler schedule for real-time kernels to schedule real-time tasks, the scheduler's algorithms and policies can be defined by their own; and the system has also implemented RMS and EDF algorithms.
This retains the rich features provided by the Linux operating system, and changes it as a basic kernel to control the CPU. In fact, the system can be seen as a dual-core operating system. Real-time kernel has a higher priority task. In other words, the basic kernel can see the idle task of real-time systems: just run when there is no real-time processing requirements. The detailed structure diagram of RTLinux thus implemented is shown in Figure 3.1.
Figure 3.1 RTLINUX details
3.2 Interrupt Simulation
It is necessary to increase hard real-time capabilities on standard Linux. One of the issues that are first encountered is that Linux is in order to achieve synchronous use. Mixing on a level of off and interrupts (I486 processor CLI and STI machine instructions) causing unseasive interrupt dispatch delays. The Linux kernel is a large number of kernels. There is no protected line between the various parts of the system service. It is very difficult to rewrite the Linux kernel. It is very difficult to cause limitations to the interruption. When the update version is released, it may become incorrect. Even if we can handle these, it is still too long.
In real-time Linux, it is a technique similar to the literature [6] by adding a simulation software between the Linux kernel and the interrupt control hardware, but is used for different purposes. All CLIs, STI, and IRETs in the Linux source code are replaced with the corresponding macros: S_CLI, S_STI and S_IRET. All hardware interrupt instructions are interrupted simulator capture.
/ * THESE ARE Macros * /
S_CLI: MOVL $ 0, SFIF
S_IRET: PUSH% DS
Pushl% EAX
Pushl% EDX
MOVL $ KERNEL_DS,% EDX
MOV% DX,% DS
CLI
MOVL SFREQ,% EDX
Andl sfmask,% EDX
BSRL% EDX,% EAX
JZ Not_Found
MOVL $ 0, SFIF
STI
JMP SFIDT (,% Eax, 4)
NOT_FOUNT:
MOVL $ 1, SFIF
STI
POPL% EDXPOPL% EAX
POP% DS
Iret
S_STI: Pushfl
Pushl $ kernel_cs
Pushl $ DONE_STI
S_IRET
DONE_STI:
Program 3.1 "Soft" CLI, STI and IRet
When interrupt occurs, a variable of the simulator is reset. As long as interrupt occurs, the simulator will check this variable. If this value is set (Linux interrupt is allowed), Linux interrupt handler will call immediately. If the Linux interrupt is not allowed, the interrupt handler will not be called. A variable value will be set and saves all the information that hangs. Once the Linux interrupts the process, all suspended interrupts will be processed. This interrupt is called soft interrupt.
Since Linux does not directly control the interrupt controller, Linux interrupt does not affect the processing of real-time interrupt.
S_CLI, S_STI and S_IRET macro, program 3.1. This code uses the GNU assembly specification. The S_CLI macro is simple to reset the variable value, save the Linux interrupt status. The S_STi macro sets the stack that is being processed. The S_IRET macro disruption is returned. The work of the S_IRET macro is like the hardware IRET instructions to allow soft interrupts.
S_IRET macro is the most interesting one in three macros. It first saves some registers and initializes the data segment register to the kernel. Then access global variables. Scan all pending interrupts set the mask bit. If the suspended interrupt is not found, set an interrupt status variable, and a hardware interrupt return command is executed. If an interrupt is found, jump to the Linux interrupt handler. After the interrupt handler returns, jump to the next unprocessed interrupt interrupt handler until no interrupt will hang.
Scanning and Go to Interrupt Handle is an atomic operation, otherwise, there is an interrupt occurrence scan in this process that will not be able to find any hang-up interrupts, and the newly interrupt handler will delay until the next S_STI or S_IRET is executed to be processed.
The use of chain jumps instead of the subroutine call to call the Linux interrupt handler because the latter cannot fully simulate direct interrupt processing. The Linux interrupt handler check stack is discovered whether the user or the kernel code is interrupted, based on this decision processing. Therefore, it is important to protect the interrupt status.
