1. RTEMS Real-time Executive for Multiprocessor System Network Security Lab. Dept. of Computer Engineering Korea Aerospace University Tae Hwan Kim (thkim@kau.ac.kr)

2. 2/34 Index What is RTEMS Highlights of RTEMS history RTEMS features RTEMS Architecture Rate Monotonic Scheduling Evaluated against other RTOS Structure of RTEMS System initialisation RTEMS Application

3. 3/34 What is RTEMS RTEMS is a real-time executive which provides a high performance environment for embedded military applications including many features.

4. 4/34 StandFor RTEMS RTEMS is an acronym for the Real-Time Executive for Multiprocessor Systems. Real-time executive Missile System Real-time executive Military System Real-time executive for Multiprocessor System

5. 5/34 RTEMS RTEMS is a full featured Real-Time Operating System. Commercial grade real-time OS designed for deeply embedded systems. All source code for OS, support components, tests, documentation, development environment, and project website is provided. Designed to support applications with the most stringent real-time requirements. High performance, deterministic behavior. Standards compliant environment. Highly portable across CPU architectures. Many Board Support Packages available. Prebuilt development toolsets for GNU/Linux and MS- Windows.

6. 6/34 Highlights of RTEMS history 1988 – OAR initiates development under contact to U.S. Army Missile Command (now U.S. AMCOM) 1992 – Superconducting Super Collider (SSC) is first non-Army organization to receive RTEMS. Evaluated easily and favorably against pSOS+. 1992 – Project begins using GNU tools 1994 – ESA sponsors OAR development of SPARC port 1994 – Publicly available via anonymous ftp from U.S. Army 1995 – Oldest date in RTEMS CVS 11 May 1995 1996 – rtems.com domain registered 1997 – GNAT/RTEMS passes Ada95 ACVC 1998 – Eric Norum ports FreeBSD TCP/IP stack 1998 – OAR officially takes over development, maintenance and distribution from U.S. Army

7. 7/34 Highlights of RTEMS history 1999 – First GNU/Linux RPMs 1999 – Motorola powerpc_shared BSP submitted 2001 – Steering Committee formed 2001 – Public problem tracking database available 2001 – Ported to NASA space hardened MIPS 2001 – Eric Norum publishes EPICS Porting Retrospective 2002 – Till Straumann publishes latency benchmark 2004 – Wiki started 2006 – Circles Venus and Mars 2007 – Launched to the asteroid belt on Dawn probe 2008 – Launched with Herschel/Plank missions

8. 8/34 RTEMS Features Standards Compliant Basic Kernel Features Networking File system Support Debugging

9. 9/34 Standard Compliant POSIX 1003.1b API including threads RTEID/ORKID based Classic API TCP/IP including BSD Sockets uITRON 3.0 API GNU Toolset Supports Multiple Language Standards ISO/ANSI C ISO/ANSI C++ including Standard Template Library Ada with GNAT/RTEMS

10. 10/34 Basic Kernel Features Multitasking capabilities Homogeneous and heterogeneous multiprocessor systems Event-driven, priority-based pre-emptive scheduling Optional rate-monotonic scheduling Intertask communication and synchronization Priority inheritance Responsive interrupt management Dynamic memory allocation High level of user configurability

11. 11/34 Networking High performance port of FreeBSD TCP/IP stack UDP, TCP ICMP, DHCP, RARP, BOOTP, PPPD Client Services Domain Name Service (DNS) client Trivial FTP (TFTP) client Network Filesystem System (NFS) client Servers FTP server (FTPD) Web Server (HTTPD) Telnet Server (Telnetd) Sun Remote Procedure Call (RPC) Sun eXternal Data Representation (XDR) CORBA

12. 12/34 File systems In-memory file system (IMFS) mini-IMFS (reduced services and footprint) MS-DOS FAT32, FAT16, and FAT12 TFTP client file system FTP client file system FAT file system (IDE and CompactFlash) NFS client RTEMS has a driver structure for block devices that allow them to accessed via the standard file system semantics as defined by the POSIX standard. The drivers are layered over the file system support which handles the specifics of a specific type of disk format.

13. 13/34 Debugging GNU debugger (gdb) DDD GUI interface to GDB Thread aware Debug over Ethernet Debug over serial port

14. 14/34 Processors Supported by RTEMS Architecture (version)4.64.74.8CVS Altera NIOS II No Yes ADI Blackfin No Yes ARM with many CPU models Yes Atmel AVR NoPartial AMD A29K YesNo HP PA-RISC YesNo Intel/AMD x86 (i386 and above) Yes Intel i960 YesNo MIPS including multiple ISA levels Yes

15. 15/34 Processors Supported by RTEMS Architecture (version)4.64.74.8CVS Freescale MC68xxx Yes Freescale MC683xx Yes Freescale Coldfire Yes OpenCores OR32 YesNo PowerPC including 4xx, 5xx, 6xx, 7xx, 8xx, 52xx, and 74xx Yes Reneas H8/300 Yes Reneas SuperH including SH1, SH2, SH3, and SH4 Yes SPARC including ERC32 and LEON Yes TI C3x/C4x YesNo Yes

16. 16/34 RTEMS Architecture

17. 17/34 RTEMS Rate Monotonic Scheduling RTEMS offers rate monotonic scheduling for periodic and hard real-time tasks. The rate monotonic scheduling algorithm is a hard real-time scheduling methodology. Using this scheduling algorithm a set of independent tasks are always guaranteed to meet their deadline. The algorithm assigns each task a priority based on its period. RMS analyses the schedulability of tasks using task periods and execution times in conjunction with specific algorithms.

18. 18/34 RTEMS Rate Monotonic Scheduling Processor Utilisation Rule can initially be used to examine the schedulability of the task set. If it fails one can still use the First Deadline Rule to further examine the schedulability of a task set. If either rules are satisfied, the task set is said to be schedulable by the Rate Monotonic Scheduler.

19. 19/34 Comparison of RTEMS with others RTEMS in most cases is superior to the other two systems in terms of availability of features and support of services.

20. 20/34 RTEMS Structure cpukit Executive RTEMS core. ada Facilitates Ada API. itron Facilitates ITRON API. libblock Provides generic device and block controller functionalities, these are device and hardware independent IO functionalities. libcsupport Provides the required support for the newlib package. It also includes implementations of POSIX services as well as non-threading ANSI C library. libfs Filesystem support, currently DOS FS and IM (In Memory) FS. libmisc Miscellaneous libraries, including modules for RTEMS performance monitoring, high level OS functionalities and interface support for MicroWindows input devices. libnetworking Supports FreeBSD TCP/IP network stacks. librpc Facilitates the Sun RPC module (FreeBSD RPC/XDR). posix Facilitates POSIX API (threading portion). rtems Facilitates RTEMS API (resource managers).

21. 21/34 RTEMS Structure lib Contains processor and board dependent libraries libbsp Contains processor and board dependent packages and routines, including shared routines among boards 11, initialisation routines and board specfic device drivers (processor and board dependent). libcpu Specfic processor functionalities and modules are present within this directory (processor dependent). llibchip Chip related library supporting hardware chip-sets available across range of boards (such as ethernet card, serial ports, IDE and rtc). libnetworking RTEMS networking application layer (rtems servers, rtems telnetd, rtems webserver and pppd). librtems++ RTEMS C++ API.

22. 22/34 RTEMS Build The RTEMS end result is a binary image file. The RTEMS image file is placed on the target board or loaded into memory at the system start by a loader. The RTEMS image file will take control of the system from the moment of initialisation of system, customly initiating the processor, board and related attached devices. The RTEMS image file may be built on most platforms and is independent of the target environment.

23. 23/34 RTEMS Build RTEMS Build Diagram

24. 24/34 RTEMS Tools RTEMS tools are composed of GNU tools and corresponding RTEMS patches. Tools must be compiled and built in the following order. binutils configure --target=i386-rtems --prefix=/opt/rtems gcc configure --target=i386-rtems --with-gnu-as --with-gnu-ld --with-newlib --verbose --enable-threads --prefix=/opt/rtems gdb configure --target=i386-rtems --prefix=/opt/rtems

25. 25/34 RTEMS Makefiles

26. 26/34 RTEMS Image File The RTEMS image file is the final resultant system, which is both target hardware and user application dependent. The user compiles and builds one’s application using the RTEMS kernel library. The user need to provide a suitable Makefile to perform this process. The required parts and segments of the RTEMS kernel library will be built into the resultant binary file.(image file)

27. 27/34 RTEMS Initialisation The initialisation routine of a system is the first piece of code which is executed on the system processor after a reboot or restart. The initialisation routine starts by execution of a processor specific assembly language code, located within the libbsp directory. The invocation of the shared boot_card() method signifies the end of assembly language code and the initiation of execution through C language. Following the bsp start() function, the rtems_initialize_ executive_early and the c_rtems_main directives are invoked sequentially. Finally the bsp cleanup() directive ends the system. the user application is executed within the c_rtems_main function and once finished the system shuts down by calling the bsp_cleanup() function.

28. 28/34 bsp_start() In the i386 processor package this directive is weakly aliased to bsp_start_default, This allows the user to override the default bsp_ start() function with one’s own function. It inserts the processor and board specific information into the earlier created configuration tables. It initialises the RTEMS interrupt manager. It initialises the RTEMS exception manager.

29. 29/34 rtems_initialize_executive_early This routine is called when the target environment is ready for initiation of the RTEMS system environment. This is considered as the start of the RTEMS itself. Initiating a series of managers and handlers starting with the Debugging manager to enable debugging at all stages. Initialising the RTEMS API and other supported APIs. Creating the “idle thread" which is considered as the starting point of thread initialisations as well. Before this point no thread should be created since _Thread_Executing and _Thread_Heir are not set yet. Initialising all device drivers. It should be noted that the _API_ extensions_Run_predriver and the _API_extensions_Run_ postdriver functions are provisions for the user to perform desired tasks before or after the device driver initialisations.

30. 30/34 c_rtems_main This routine after setting the rtems_progname (program's name) variable, simply calls the rtems_initialize_executive_late directive. The rtems_initialize_executive_late directive initiates multitasking within the system, starts the main application and simply goes away. Execution is resumed within this thread once the application calls rtems_shutdown_executive. rtems_shutdown_executive routine stops multitasking and resumes execution of the c_rtems_main directive.

31. 31/34 bsp_cleanup() The bsp_cleanup() directive is executed as part of the shut down sequence. This directive simply calls the rtemsReboot routine, which performs board specific reboot operation. Within the i386 environment, the rtemsReboot routine performs reboot using the keyboard controller.

32. 32/34 RTEMS Application Space and Aviation Herschel and Plank Mission(RTEMS, ERC32) Venus Express: VMC Dawn: Framing Camera(RTEMS, LEON) Robotics Fire Marchall Bill Military Avenger Forward Air Defense System Flight Data Recorder FDR Music and Sound Soundart Chameloen Smart Controller Medical Frye electronics Fonix7000 hearing aid test system AMV Technics TECHNIC I, syringe pump for high-precision

33. 33/34 RTEMS Application Spotlight: Dawn On September 27, 2007, NASA’s Dawn spacecraft was successfully launched from Cape Canaveral, Florida to begin its 3 billion kilometer (1.7 billion mile) journey to the asteroid belt. Dawn is designed to investigate two of the largest protoplanets in the main asteroid belt – Vesta and Ceres. Dawn is scheduled to reach Vesta in 2011 and Ceres in 2015.

34. 34/34 RTEMS Application Spotlight: Dawn Two identical Framing Cameras[External] (FC) are the scientific imaging system of the Dawn spacecraft, providing cold redundancy also for optical navigation. Each camera is controlled and its data is processed by a Data Processing Unit (DPU), which was completely developed and verified at IDA. An enhanced version of the VMC "System-on- Chip (SoC)" approach is used by implementation of all functionalities together with a SPARC-V8 compatible LEON2 processor core within reprogrammable Xilinx FPGAs. The real-time operating system RTEMS is used as basis for a complete instrument control and on-board data processing system, implemented in a sophisticated on-board command language (OCL).

35. Thank you