This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
Abstract- The Embox OS is an open source cross-platform (RTOS) real-time operating system, designed and developed for resource constrained environment such as hardware simulators. The main feature of embox OS include the development of hardware and analysing hardware prototype, as well as it works on end-user devices as a full-featured operating system. With this important feature it offers the environment for development of embedded applications. The architecture of Embox OS kernel is exokernel, which enables the programmers to interact with the hardware directly thus enable the simulators to achieve high performance by avoiding most of the abstractions in kernel. The embox kernel is modular also, modules are loaded in memory when needed.
Keywords:Embedded,OS,RTOS,OperatingSystem,Realtime,HardwareTesting,C,Assembly, Education,SPARC, Microblaze, ARM,x86, Lego, NXT
An operating system (OS) is use for managing hardware resources of a system and hosting applications or programs that runs the system. But these tasks are specially designed to run processes with very precise timing and reliability in real time operating systems (RTOS). The Embox OS is an open source cross-platform real-time operating system. Its main features include its exokernel modular kernel, the kernel is configurable for a specific hardware or task. It is used as a testing frame-work for hardware simulators. It is also use as a development tool for developing applications for embed system as well as it's a complete operating system with network capabilities. It allow to configure its kernel for a specific device to avoid other abstraction of kernel in debugging mode. In short Embox is development heaven for system programmers, hardware developers, researchers, and kernel developers. It's a complete package contain sufficient tools to implement something new. Plus different modules can be loaded into kernel if required. This paper covers details on
Embox OS evolution, its features, Embox Architecture, Embox Kernel Architecture, file system, network, supported platforms and its future work.
This project is started by employees of Hardware Engineering Department of Lanit-Tercom Inc as a part of commercial project in 2009. Soon its code was made open source to share with others. Now development team consists of Students of Saint Petersburg State University as well as founder of the project themselves .
Embox is cross-plate form OS, currently it can be ported on five processors: x86, ARM, SPARC, MIPS and Microblaza . Due to the interconnected modules, each of which can be configured to the required parameters it's relatively easy and simple to port Embox to the new architecture. All you need to know is a well-defined Hardware Abstraction level interface.
Modular and configurable kernel
Embox is designed into a set of fine-grained modules, each has some implemented interface. Its kernel is micro and all modules works with the kernel, the kernel is also called exokernel through which programs directly interact with hardware. Thus it can be tuned for a specific usage .
Embox contain an embedded unit testing framework which is used for debugging, developing and self-checking hardware and software modules.
Designing a new hardware
Embox is highly configurable system which run in dedicated environment for hardware simulators. Thus it can be used in early hardware development stages. Hardware requirement can be estimated during design phase and in debugging phase one can prepare set of test need for testing and coverage. There are several simulators and you can debug your code without hardware platform. The main simulator used by embox is QEMU .
Similarly a build used in embox allows to get a source distribution only for a required modules. It makes the process cheaper by reducing the amount of code needed for certification. In addition this build allows to get files lists and modules graph.
Embox has base level and module architecture, its architecture is used in fig. 1 .http://embox.googlecode.com/svn/wiki/images/EmboxArchitecture/arch.png
Fig. . Embox Architecture
It is the interface implantation that need for porting Embox to a new architecture. HAL supports virtual memory primitives, Memory Management Unit (MMU), Instruction Traps, I/O Access Limitation, Timing Control, atomic operation clock etc.
Like the whole system, Embox kernel is also of modular design. The type of Embox kernel architecture is exokernel. Which includes the following parts :
Hardware and software interrupts handling
Timers and clock source management
Hardware and software interrupts handling
Timesharing the processor between the partitions(threads, tasks or event handlers)
Drivers provide a combine program interface to the hardware devices and program pseudo-devices. It's similar to HAL but it work on external devices while HAL supports internal devices like CPU .
Services layer or library is the module which provide services to different system parts and users application through a well-defined interface (API), unlike drivers it does not access hardware, and services include file system, Network, testing services, protection like encryption integrity monitoring and other services like graphics .
Embox kernel architecture
Embox uses modular kernel like the whole system. Fig. 2 shows different modules and its communication with other modules and layers.
Superseding is the simplest multi-tasking form, the system loads several task but the CPU time is allocated to one active task. Task switching or multi-tasking occurs either when the active task ends or when it enters a loop from external event. The planning method is same as in MS-DOS, application task can capture the processor any time.
In cooperative multitasking the current task itself give its CPU scheduler, and selects the next task. It is also used in Linux kernel or POSIX threads as well as windows to create threads i.e. SCHED_PR or SCHED_FIFO, windows gets task which sent the message and it does not handle it when it returns to the scheduler. This method is not safe because the application thread can consume all the CPU time. But this is easy to implement so it's the responsibility of the developer to manage it effectively.
In pre-emptive multi-tasking the scheduler allocates time to each task. When expiration of quantum scheduler suspends the problem, it find the following problem which both conducts the next quantum. This process is called planning. It is produced by different algorithms, these algorithms are called scheduling policy. There are two type of planning. Static and
Fig. Embox Kernel Architecture
Dynamic. Most of the systems build on principle of dynamic scheduling. System during run time decides which task to give processor time. Depending on these settings scheduler decides which task to give CPU time. While in static scheduling task is given time in percentage time or on interest granted priority for example in real time system which require mathematical task verification execution time .
Threads can be interrupted by scheduler, the flow is replaced by another thread. The basic flow field is the context i.e the state of processor during the execution of the flow. When resuming, the CPU returns the state it was interrupted, the process of saving current state and starting new processor state is called context switching. The implementation details always has additional information like ID, status and execute the fuction. To create a new thread thread_create call is called, as well as the attributes are set in the flow i.e joinable, running etc. Memory to the new thread is allocated dynamically. To free up the memory the thread_detach() or thread_join() is called, or you can specify when you create the stream flag THREAD_FLAG_DETACHED. thread_join () also allows the current thread to wait and see the results of the completion of the thread. After calling these functions will be told that the memory can be removed. With each transaction scheduler thread state changes. It either goes to sleep or suspend it, or both. Leave the thread scheduler can only be completed. At the completion of the flow status will
change to suspended and then immediately goes to exit .
In RTOS embox scheduling is done by a share scheduler module which implements the planning strategy shown in fig. 3.
Fig. scheduler API
Its main function is the division of the CPU time quanta and their distribution between context switching and threads. Planning strategies have simple algorithms for start-up and shutdown flow selection of the next. Thus the general structure of multi-threading work like system communicates with the scheduler through the API (sched api) which is independent of strategy implementation, and rge scheduler uses the API's provided strategy (sched_strategy api) .
The Critical API is a mechanism for tracing current execution.
To understand it clearly let's consider an interrupt example.
An interrupt can occur if its priority is higher than current Interrupt Priority Level or more precisely when two conditions are met the interrupts are not disabled by call ipl_save(), and when there is no interrupt with higher priority.
Only a limited set of resources can be accessed by interrupt handler. For example, it can wake up threads waiting for some event, but it can't create a new thread.
To see the possible execution contexts is configured in fig. 4 C:\Users\Slim Shady\Desktop\table 4.jpg
Memory allocation is done through algorithms which is managed chunks of memory allocated to objects during execution. For instance the dynamic objects with unknown size, set of objects of same nature and size, virtual memory mode table. Memory can be allocated to both instruction as well as process. In this case it's useful to use virtual memory mode. This results in isolation of process address. To work with others virtual memory allocation is done through paging.
This approach is useful when you want to allocate a great number of objects with fixed size. The high border of the number of holding objects is limited by fixed value before compiling. Objects will be stored in the array with size equal to high border. Then free elements of array link into list of free objects. So, allocation of object - returning a link to free space, de-allocation of object - returning of the link in the list of free object. Object manager belong to O(1) complexity class, where n is an array size.
It is an algorithm with the main goal to minimize time for operations by allocating and initialization some parts of dynamic memory for objects with the same size.
Algorithm don't know that how many objects will be allocated by user? It try to allocate memory for some part of object and initialize this part (called slab). Each slab will initialize as object manager. Slabs may be free, partially full or full.
Allocation of object is done by searching cache that contains objects having appropriated size (it's requires number of operations equal to number of different sizes). Then we get first of partial full slabs and allocate object for O(1) operation. If slab is full, we delete it from list of partial full slabs and add to list of full slabs. It's O(1) operations.
De-allocation of object - obviously it's O(1) So, the main costs consist of time for initializing of each slab. It is O(n), where n is number of objects stored on slab. Obviously optimizations based on statistic to define optimal init size of each slab.
Each descriptor contains flag specified to free it or busy and number(int) equal to its own size. Its method allows to allocate objects of any size.
Allocation is done through list and search for "appropriate" block.
- First free
- The Best - In this case we search block with minimum difference between it size and size of our object.
- The worst - As in previous case, but difference must be maximum. All algorithms belong to O(n) complexity class.
De-allocation Object is deleted by pointer. But when new block get free than it is combined with its nearly free blocks. It's O(1) operations.
This algorithm represent pool of memory as binary tree. Element of tree is block of memory. Size of parent of each node is equal to double size of child. E.g. root has 2^n size. Its two children have 2^(n-1) size and etc.
Allocation is done through tree from leaf to root and search free block with appropriate size. Then mark it block as busy and go to its child to mark it, then go to its children and so on.
De-allocation is done by searching appropriate block by pointer to it. Then mark it as free. Then go to leafs and by the way mark other nodes if need. Let's look at buddy of block (this is its brother). If it is free, then combine them and mark their parent as free. Recursively make such merge for parent and so on .
It is an abstraction of file interface like (open(), close(), read(), write(), ioctrl()) as well as data formats in storage devices and its distribution.
In Embox OS file system is consists of different and handle files and folders in file system through symbolic names. Files can be created and deleted if permissions is allowed.
rootfs: Rootfs is a node with ramfs driver. Another systems just mount another filesystem over rootfs and ignore it.
ramfs: Resizable simple ram filesystem (virtual filesystem)
devfs: Device filesystem.
Embox File System Features
Embox can use initramfs (cpio, tar formats)
Embox can load ELF files.
Embox can use an interface for a device driver that appears in a file system (devfs) .
Similar principles can be implemented and integrated into Systems such as quadrupeds characteristic places without hard drives, moreover, in some systems, the code is executed directly from the flash memory (such as Lego Mindstorm). In any case, the system begins to perform start-up code from what is permanent storage, this code is sometimes called the boot loader first level, for example, it can read the partition table and transfer control to the desired second-level boot loader, which in turn transfers control is the primary OS.
Disks are divided into sections with independent file system on each partition. The general structure of the disc is shown below.
Embedded systems start code is often on the same media where program. That is, the structure of the storage device is as follows;
STORAGE_INFO may present a structure of the above.
Master Boot Record
Section 0 is called the master boot record (MBR, Master Boot Record) and is used to boot the computer. The beginning of this record - set assembly instructions that the startup (boot the first level). At the end of the master boot record contains the partition table, which stores the start and end addresses of each remaining section (so it stores information about the division of the remaining space on the partitions). One of the sections in the table is marked as active. The task of the loader first level - find the active partition and passes control to its starting address.
In a MBR partition table allocated 64 bytes. Each section has a record of 16 bytes. Thus, in the table can have only 4 entries. In reality, this means that any disk can be divided into no more than four sections. In modern systems, this limit costs by introducing the concept of the extended partition, but this is not important. More information about the structure of the MBR and the partition table will be later.
Structure of partition
The start of every section - boot block. He is always present. Boot block contains some executable code (boot second level), which loads the operating system, as contained in this section. Even if the section does not contain the OS, the boot block is still there for consistency.
The rest of the structure of the disk can vary from system to system, the circuit shown in the picture are not more than a kind of recommendation is that usually it contains. Superblock contains key parameters file system is read into memory when the computer the first time a file system. Typical information contained in it - a "magic number" that identifies the system files, the number of blocks in the file system, and more.
Further information is available on the file system blocks (for example, as a bitmap or a list of pointers). Next usually have more information about the file system, depending on the type of file system. For example, information about the files that the root directory. Next is the actual files and directories that contain useful information.
The network subsystem implements the socket interface (Berkeley sockets API) in the system, and part of the standard protocol stack. This gives the programmer a convenient interface to the network with the other modules and devices. Implements the following protocols :
ARP ( RFC 826 )
IP ( RFC 791 )
UDP ( RFC 768 )
ICMP ( RFC 792 ).
Embox can be executed on several processor architectures. There are a simulator for each of them. And you can debug you code without hardware platform. The main simulator is QEMU. Details for simulation on different processor architecture below :
Simulation on x86 platform simulators
Simulation on a SPARC v8 Leon3 processor
Simulation on an ARM
Embox supports several types of processor architecture this page contains examples of real hardware platforms (boards) which Embox is supported.
Embox supports Leon3 processor. Is is open source processor which compatible with SPARC v8 architecture. We run Embox on the Virtex-5 LXT FPGA ML505 Evaluation Platform.
Embox supports Microblaze processor. This processor is supported by Xilinx. We run Embox on the HW-SPAR3AN-SK-UNI-G Starter Kit.
This development board contains at91sam7 controller and simple peripheral. It is very cheap and easy to development start. Embox supports Lego Mindstorms NXT.
This development board contains Cortex-M3 and integrated debugger.
Embox supports PC platform the same, and it can be executed on QEMU .
Embox is collaborating with "theoretical cybernetics" department in the research of robotics system. Embox powerful features made it a robotics OS, as a result Robots programming platform is created. It consists of the RTOS "Embox" and Graphical IDE "QReal", both are the projects of Software Engineering department.
Embox Operating System is configurable OS, its powerful feature include modular kernel, which is also an exokernel. Which means that this OS can interact with the hardware directly avoiding most of the abstraction of kernel. Different simulators can be used to develop new hardware. The performance of simulators on this OS is fairly better than others because of its exokernel type of kernel. It allows agile configuration for a specific task. So appropriate strategies on different kernel services like memory allocation, IPC and scheduling etc can be applied. In future Embox can play an important role in next generation of RTOS.