| Porting RTLinux to the MIPS 'Atlas' reference board |
by Sachin Bharadwaj and M.R.Venkatesh (Sept. 11, 2002)
Introduction
The aim of this research project was to port RTLinux to the MIPS Atlas board with MIPS 4Kc core. We further intended to measure the response time of the real-time interrupts and the scheduler, and develop a suitable real-time environment for system-on-chip (SOC) based embedded applications such as media gateway controllers, Voice-over-IP (VoIP) solutions, multimedia solutions, routers etc.
Approach and Design
The first step towards achieving our goal was to study the architecture of the MIPS Atlas boards, and get to know the microprocessor design and details. Then came the task of porting RTLinux onto the MIPS hardware. This required a complete and thorough understanding of both the RTLinux (software) and MIPS (hardware) architectures.
RTLinux uses a dual kernel architecture in which a small real-time micro kernel takes over the complete control of the MIPS hardware and runs Linux as the lowest priority task.
The following steps were needed in order to fulfill the goals of the project . . .
- Bring up a boot loader on the MIPS Atlas board
- Bring up the Linux 2.4.4 kernel on the MIPS Atlas board
- Port the RTLinux 3.1 micro kernel (on top of Linux 2.4.4) to MIPS Atlas board
- Write a serial test driver for the TL16C550 chip, in order to measure the interrupt and schedule response time of RTLinux on the MIPS Atlas board
Implementation
RTLinux is GPL software, and comes with following six modules . . . - rtl.o -- provides rtl_printfs for debugging, and provides APIs to configure real-time interrupts.
- rtl_time.o -- provides rtl_timer.
- rtl_schedule.o -- provides real-time scheduling capability.
- rtl_posix.o -- provides posix standard APIs.
- rtl_fifo.o -- provides FIFOs to enable communication with the Linux tasks.
- mbuff.o -- memory buffer for shared memory.
In order to port these six modules to the MIPS Atlas board, some changes had to be made to the available RTLinux source code. Here is a brief summary of the major changes this entailed . . .
- The module rtl.o was re-coded so that rtl_printf's were available for debugging. The Interrupt handling portion of the Linux was taken over by RTLinux. The right to disable or mask interrupts was taken away from Linux by RTLinux -- instead Linux got an interrupt handling routine which queues the interrupts. Responsibility of dispatching a task for execution was given to RTLinux depending on the priority. Interrupt dispatcher code was re-coded for RTLinux. The Linux calls like CLI, STI, save_and_cli(), were replaced with soft_cli(), soft_sti() and rtl_soft_save_and_cli(). rtl_hard_sti and rtl_hard_cli were used to perform the functions of disabling and restoring the interrupts.
- Modules rtl_schedule.o and rtl_time.o were ported, which required rtl_timer to be re-coded so as to have a real-time reference for scheduling a task. rtl_schedule had to be recoded so that it could schedule a task with real-time priority. We also had to resolve some issues relative to ispatching Linux tasks when RTLinux was up and running.
- As a result of porting RTLinux to MIPS, we could schedule more than one real-time task and could make certain interrupts real-time. When an interrupt occurs, RTLinux decides whether to execute it or keep it pending for normal Linux to handle. RTLinux disables interrupts only for the least possible period.
POSIX standard API's were available using rtl_posix.o module.
Response Time Measurement
Resources used were as follows . . . - Necessary Hardware -- SAB80C535 board (8051 compatible), 1488 and 1489 chips (to convert TTL voltage levels to RS232 voltage levels and back), +9V , -9V and +5V supply(we used 7809 and 7805 for +9V and +5V, -9V came from a second supply). The target system (MIPS ATLAS board with 4KC core) running RTLinux, had one RS232 serial port and a special driver was written for this. This driver had a Line Status interrupt service routine. Whenever the CTS signal on the port turn high, the driver should toggle the RTS in response.
- Optional Hardware -- Breakout Box, CRO.
- Necessary Software -- C Compiler for 8051 with ROM monitor debug feature (support for the SAB80C535 board). The serail port driver of the MIPS board running RTLinux has to be modified to respond to interrupts.
The following diagram illustrates the setup used for response time measurement . . .
Setup Diagram
RTLinux running on MIPS was tested using a serial port driver (the debug port of the Atlas board). Basically, a change in CTS used to generate an interrupt. Every low-to-high transition of CTS would make the RTS pin high (via an interrupt service routine), and a task is scheduled which subsequently sets the RTS pin low. The CTS signal to the COM port is made high through an output pin of the 80535. In response to this interrupt, the MIPS board (running RTLinux) will make RTS high. The time difference between these two events (CTS made high to RTS becoming high) represents the interrupt reponse time of the target system.
The steps followed to measure the interrupt response time are - The CTS signal to the COM port is made high through an output pin of the 80535.
- The 80535 immediately starts polling the RTS pin, where it expects the response, as often as possible. The 80535 runs a time counter by incrementing a register.
- When the response is received on RTS pin (becomes high), the response time for that particular iteration is compared with a stored value (which is initially zero). If the present iteration response time is greater than the stored value, the present iteration response time is is stored.
- This loop is run as many times as wanted while some load (i.e. FTP, NFS activities, flood ping, etc.) is placed on the target MIPS board running the RTLinux system.
- When all the iterations are finished, the stored value will represent the worst case response time of the target RTLinux system.
The steps followed to measure the task response time are . . . - A task is created which can make RTS pin low on the availability of a semaphore.
- The CTS signal to the COM port is made high through an output pin of the 80535.
- As RTS pin is made high in the ISR, and the semaphore is being released.
- The scheduled thread picks up the released semaphore, and makes the RTS pin low.
- The time difference between RTS-high and RTS-low is recorded as the task response time.
Observations
The following table summarizes the observations for the Interrupt and Task response time for MIPS 4KC platform . . .
Table of Results
Conclusion
The response time was measured for both interrupt and scheduler, and both response times were predictable and consistent. The figures in the above table indicate that the target system running the RTLinux system is capable of handling hard real-time applications. It has predictable and acceptable worst case timings for all the critical response times.
About the authors: Sachin Bharadwaj and M.R.Venkatesh are members of the Embedded System Group of Multitech Software Systems India. Bharadwaj serves as Project Leader, with responsibility for project management, technical leadership, and marketing support. Venkatesh, a software engineer, is responsible for implementation and testing of various embedded operating system projects based on ARM, MIPS, Motorola, and Intel processors. Aginotech Technologies Inc is the 100% US subsidiary of Multitech Software Systems India.
(Click here for further information)
|
|
|
7 Advantages of D2D Backup
For decades, tape has been the backup medium of choice. But, now, disk-to-disk (D2D) backup is gaining in favor. Learn why you should make the move in this whitepaper.
4 Legal Reasons to Control Internet Access
The Internet is obviously a valuable resource for many organizations. However, many are exposed to legal liability concerns because they fail to control Internet access. Learn if you're safe in this white paper.
Rapidly Resolve J2EE Application Problems
Whether you are in the process of building J2EE applications or have J2EE applications already running in production, you must ensure that they deliver the expected ROI. Learn how in this white paper.
Load Testing 2.0 for Web 2.0
There are many unknowns in stress testing Web 2.0 applications. Find out how to test the performance of Web 2.0 in this white paper.
Build Better Games Online
For the game infrastructure providers, life is complex. Making money from games has become more complicated. Why? Find out in this white paper.
Building a Virtual Infrastructure from Servers to Storage
This white paper discusses the virtual storage solutions that reduce cost, increase storage utilization, and address the challenges of backing up and restoring Server environments.
Gaining Faster Wireless Connections with WiMAX
Welcome to what is quickly becoming the hyperconnected world where anything that would benefit from being connected to the network will be connected. Learn more in this white paper.
Is Your Desktop a Security Threat?
The new wave of sophisticated crimeware not only targets specific companies, but also targets desktops and laptops as backdoor entryways into those business’ operations and resources. Learn how to stay safe in this white paper.
Increasing SAN Reliability by 100 Percent
Storage area networks (SAN) are a strong part of storage plans. Learn how to increase your reliability and uptime by 100 percent in this case study.
|
|
|
|
|
news feed