Porting Embedded Systems to uClinux

António José da Silva Instituto Superior Técnico Av. Rovisco Pais 1049-001 Lisboa, Portugal [email protected]

ABSTRACT Concerning response times, computer systems can be di- The emergence of embedded computing in our daily lives vided in soft and hard real time[26]. In soft real time sys- has made the design and development of embedded applica- tems, missing a deadline only degrades performance, unlike tions into one of the crucial factors for embedded systems. in hard real time systems. In hard real time systems, miss- Given the diversity of currently available applications, not ing a time constraint before giving an answer may be worse only for embedded, but also for general purpose systems, it than having no answer at all. An example of a soft real time will be important to easily reuse part, if not all, of these ap- system is a common DVD player. While good performance plications in future and current products. The widespread is desirable, missing time constraints in this type of system interest and enthusiasm generated by ’s successful use only results in some frame loss, or some quirks in the user in a number of embedded systems has made it into a strong interface, but the system can continue to operate. This is candidate for defining a common development basis for em- not the case for hard real time systems. Missing a deadline bedded applications. In this paper, a detailed porting guide in a pace maker or in a nuclear plant’s cooling system, for to uClinux using the XTran-3[20] board, an embedded sys- example, can lead to catastrophic scenarios! tem designed by Tecmic, is presented. The ported system performance was evaluated by several benchmark tools. The Like the first general purpose systems, the first embedded preliminary results looked promising, but there is still room systems had no . Since the first operating for improvement. Hence, some ideas on how to port the systems were implemented, their use in general purpose sys- entire system are suggested. tems became mandatory, given their general purpose nature. On the other hand, because of the reduced feature set avail- able in embedded systems, software that directly controlled General Terms the hardware available with very minimal or no multitasking Porting, uClinux, Embedded capabilities continued to be used and developed in-house by embedded system vendors. Today, with a vast number of Keywords technologies available, many complex functionalities are ex- pected even from the most basic embedded system. A good Linux, Operating System, Kernel, XTran-3, Hardware, Driver, example are home network routers which began as relatively Real Time Clock, Flash, JFFS 2, I2C simple ethernet packet multiplexers and are now expected to have wifi and printer connectivity, packet routing, switch- 1. INTRODUCTION ing and forwarding capabilities and even firewall rules that An embedded system is a computer system that is designed can operate in all the OSI network layers. Several of these to do a well defined set of tasks. Since the first embed- functionalities require similar software infrastructures that ded system, built in the early 1960s for the Apollo guid- were first available only to general purpose systems. ance system[29], other embedded systems were developed targeting different areas. Driven not only by hardware and The cost of implementing advanced functionalities in em- software advances, but also by a deeper understanding of bedded systems using only proprietary in-house developed human needs and marketing possibilities, general purpose software is unfeasible for many companies, which tend to and embedded systems became more complex, implement- migrate to embedded operating systems, commercial or free. ing a growing set of functionalities. Today, there is a multi- A real example of one of these companies is Tecmic, a por- tude of embedded systems available, from portable audio or tuguese embedded solution provider. One of Tecmic’s prod- video players to mobile phones with wifi capabilities, pow- ucts is the XTran-3 board, an embedded system designed erful gaming consoles, home network routers and the list by Tecmic, which is the hardware used in this study. The continues, but still, there are some factors that consistently XTran-3 board is a vital part of Tecmic’s larger “XTran” distinguish embedded from general purpose systems: system, conceived to remote fleet monitoring. In the XTran system, each board (from here on called XTran-3[20]) is in- • Well defined response times (the system must answer stalled and connected to each vehicle. Its function is to to specific tasks without missing deadlines) collect data about a vehicle’s mechanical status, global po- • Low hardware requirements (little RAM/ROM, task sition and driver details and send it to a central computer specific processor) probably located in the fleet’s headquarters. Currently, the • Specific hardware dedicated to a well defined set of XTran-3 board does all its tasks using a custom proprietary tasks real time operating system developed by Tecmic. • Power Management constraints • Low cost In this paper, several commercial and free open source solu- memory support is compared, including page swapping tions are reviewed and compared with each other in terms methods and/or memory pool management. Also, the of its porting to the XTran-3 board. Also, a detailed port- API richness for inter-proccess communication primi- ing guide to uClinux using the XTran-3 board is presented, tives also contributed as an important evaluation fac- including all the relevant steps, from the development envi- tor. ronment set up, to the kernel configuration, device driver im- Interrupt Handling This parameter refers to the existence plementation and application writing. Several benchmarks of different priority levels for interrupts, interrupt nest- were also performed to compare the performance of the ing and amount of resources available when an inter- ported system with the Tecmic firmware and with other pop- rupt occurs. ular embedded solutions. Network Support Describes the amount of supported net- work protocols and device drivers. This parameter 2. RELATED WORK was introduced due to the growing importance of net- work support for embedded systems[29] and also for Although uClinux was already chosen as the operating sys- the XTran-3 board. tem to port for the XTran-3 board, other candidate operat- Development Tools Due to the different nature of each ing systems were also reviewed and analyzed. operating system, several manufacturers provided their own development and deployment tools. Others rely Besides in-house proprietary embedded operating systems, on a specific amount of open source tools. The variety several commercial solutions began to appear around the and richness of the development resources is compared mid-eighties, providing several different approaches to an among each solution. extensible, multi-task and real time operating system for a Applications The amount of existing applications for each wider non-specific range of embedded systems. Two notable operating system, open or closed source, is evaluated. examples of this type of solutions are QNX and VxWorks, which are still available today. Microsoft, one of the leaders in the operating system market, also implemented its own Conki embedded operating system solution, Windows CE, aiming to provide a high degree of compatibility with its popular general purpose operating system and applications[17]. eCos With the advent of mobile phones in today’s society, several mobile phone providers, namely Nokia, Ericsson, Motorola Inferno and Psion, joined efforts to implement a special purpose operating system for those devices: the Operat- ing System[16], which will also be described and compared. uClinux Besides Linux, which made its first appearance in an em- bedded system in 1998[19], other open source operating sys- RTLinux tems were ported to run on some embedded architectures, namely, Inferno Os, a descendent from “Plan 9 from Bell Labs” (which is itself a re-engeneering of the Unix architec- Linux ture) and , a very minimal operating system written initially for the Commodore 64 home console. eCos is an open source embedded operating system commonly used to Symbian bootstrap into other operating systems, including Linux. Its mature state and modularized architecture made it into a WinCE full featured Operating System and a promising candidate for running on the XTran-3 board. VxWorks 2.1 Qualitative Approach to the Technical Eval- uation QNX In order to qualitatively evaluate each candidate operating system to run on the target board, the following parameter 0 1 2 3 4 5 list was considered sufficient for a basic overview of each Applicaons Development Tools projects’ positive and negative aspects[26]: Network Spport Interrupt Handling Install and Configuration Although each evaluated so- Memory Management Task Management lution has its own configuration and installation pro- cess, there is a common denominator specific to the Install and configuraon nature of embedded systems. This common denom- inator consists of the configuration, creation and de- Figure 1: Solution Comparison Scores ployment process of the system image file(s) from the host to the target system. Each solution was configured and installed in a test en- Task Management This parameter refers to the availabil- vironment consisting of a typical PC (Pentium IV 3GHz ity of scheduling policies and methodologies implemented with 4GB of ram) running Debian Linux and VMWare soft- in the evaluated operating systems. The existence of ware for virtual machine emulation. Also, several operat- real time scheduling, processes and/or threading re- ing system documentation considered relevant for this anal- sources, and granularity of I/O control ysis was consulted[12][31][5][17][14][16][1][28][10][27][25][13]. mechanisms was also described and compared. Figure 1 shows the qualitative analysis results for each cho- Memory Management The existence of MMU and paged sen operating system. The given score, ranging from 1 to 5, is described as follows: and xScale CPUs. The VxWorks kernel features “protection 1. Immature project with reported unfixed critical errors domains” that provide containers for logical resources which 2. Immature project, used mainly for proof of concepts define the execution environment, namely, the address space and constrained test environments and accessed libraries. By defining containers for each ap- 3. Mature project with known limitations and reduced plication, the kernel can then intercept illegal accesses from functionalities. Small number of use cases in real life the program being run, emulating by software the use of production environments an MMU, thus making possible the use of memory protec- 4. Mature project with known limitations and a large tion even in mmu-less architectures. Like QNX, VxWorks is number of functionalities. Large number of use cases multi-threaded and has 256 priority levels for scheduling. It exist in real life production environments uses preemption and also a prioritized round robin schedul- ing[27]. Interrupts are handled in a special context outside 5. No known critical errors, tested in real production en- any tasks context and have some restrictions for the kernel vironments. Very large number of functionalities API primitives that can be used inside of it. VxWorks has extensive protocol stack support[27] and network support, 2.2 QNX including drivers and basic applications used in a networked QNX is an Unix like real-time operating system. The QNX environment (ssh clients and servers, http servers, etc)[27]. Neutrino kernel has a client-server architecture consisting of a [25] and optional cooperating processes. The VxWorks comes with the Tornado IDE which comprises an microkernel implements only the core services like threads, extensive suite of tools and utilities that can be used dur- processes, signals, message passing, synchronization, schedul- ing the development and debugging phase. However, these ing and timer services. The microkernel itself is never sched- tools are integrated mainly using TCL scripts, which need uled. Its code is executed only as the result of a kernel call, to be parsed whenever an action is taken, making the pro- the occurrence of a hardware interrupt or a processor excep- cess of interacting with the gui a tedious task, even in the tion. Additional functionality is implemented in cooperative test machine. Unlike QNX, VxWorks uses a host different processes, which act as server processes and respond to the from target approach. The host and target are two different request of client processes (e.g. an application process). Ex- machines linked together by serial, LAN or other bus, for amples of such server processes are the file system manager, communication. A special software called “debug agents” process manager, device manager, network manager, etc. can run in the target system and provide the host with de- The architecture of QNX allows every application , driver, bugging information. VxWorks has a Java virtual machine file system and protocol stack to run outside the kernel, in implementation, is Posix compliant, and has a small number the safety of memory-protected user space. The interrupt of applications available. redirector in the microkernel handles interrupts in their ini- tial stage. It also supports interrupt sharing and nested 2.4 WinCE interrupts. The QNX kernel provides all protection mecha- Windows CE is Microsoft’s operating system for embedded nisms as foreseen by the different Posix standards (mutexes, systems and service oriented computers. It is supported on semaphores, conditional variables, read/write locks etc). In MIPS, Hitachi SuperH, ARM and Intel x86 architectures. the test machine, all critical hardware used was detected Windows CE is built from a set of discrete modules, each by the QNX installation process. Installation flavors range divided into components that provide specific functionali- from a minimal floppy distribution or a full suite of appli- ties. The prime modules are the kernel, the object store, the cations bundled in a bootable cd. All tasks and processes graphics subsystem and communications components. In are managed using FIFO or sporadic scheduling and have addition to these primary modules, other modules are avail- a priority number assigned. Memory management can be able and provide support for multimedia, COM (Compo- with or without MMU without loosing real time behaviour. nent Object Model), Windows CE shell and device manager. QNX also supports IPv4 and IPv6 and has a built in web Like QNX and VxWorks, Windows CE uses processes and browser which can be included in the deployed image file. threads and has 256 levels of scheduling priority. The sched- uler only uses round-robin with adjustable time-slices. The To build custom QNX images, the System Builder applica- kernel has MMU support, but when this feature is enabled, tion was used. This application is a graphical environment real time performance is disabled[17]. For interrupt sup- that runs under QNX windowing system and calculates all port, all service routines run in a special context that uses package dependences upon the building process. It also has its own virtual addresses statically mapped by the OEM. a dietitian feature that can shrink all libraries to contain API accessible from within the interrupt service routines is only the functions used by the current set of applications. very limited, much more than in VxWorks, and an option Kernel and application development can be done using the is given to the OEMs to create a shared memory region by Momentics[24] suite which is an IDE based in Eclipse. Al- statically mapping a memory region into the interrupt ser- though there is a reduced number of applications available vice routine address space. Windows CE also has extensive for QNX, there is a Java virtual machine implementation, network support and provides a HTTP server with ASP sup- full Posix compliance and several libraries available for de- port, a minimalistic version of the Internet Explorer browser velopment in different programming languages. and multiple networking protocol support[17].

2.3 VxWorks Windows CE development and deployment tools are for VxWorks 5 is a proprietary, real-time operating system de- Windows operating system only, but their level of integra- veloped by Wind River. VxWorks has been ported to a tion is excellent. The main development tool to use is Mi- number of platforms and now runs on practically any mod- crosoft Visual Studio, for which many vendors provide plu- ern CPU that is used in the embedded market. This in- gins and extensions for their embedded systems. The num- cludes the x86 family, MIPS, PowerPC, Freescale ColdFire, ber and variety of applications available for windows CE is SH-4 and the closely related family of ARM, StrongARM very high and includes many applications written for the Windows operating system that run without modification single processor machines[9]. The Linux scheduler has vari- in Windows CE. Application developers are not only third ous implementations, each one having unique properties and party companies but also enthusiasts that need specific func- advantages under certain situations. This kind of flexibility, tions for their embedded system. Also, a minimal version of customization and resource richness available to the devel- the .Net framework, the .Net compact framework, enables opers made the a popular choice adopted in the use of the .Net programming language and tools in Win- embedded, desktop and server systems. Since version 2.6, dows CE. the current major version, a considerable amount of new features and development methodologies made the develop- 2.5 Symbian ment process much more agile and reactive to changes. Symbian OS is a closed source proprietary operating sys- tem built exclusively for mobile phones. It is a preemp- Linux supports up to 64GB of RAM in 32 bit architectures tion enabled multitask operating system that uses processes, (although the hardware limitation of these type of architec- threads and hardware memory protection. As the result of tures is still present: each process can only “see” 2GB) and a joint venture between several mobile companies, several more than 1024 GB in 64bit architectures. The page size innovative and unusual concepts were implemented in Sym- is configurable in compilation time. For interrupts, Linux bian, whose code base was retrieved from Psion’s “Epoc” op- supports SoftIRQs, tasklets, bottom halves, task queues and erating system[16], namely, resource descriptors, a cleanup timers[28]. One of the reasons for Linux’s growing popular- stack operation and Active Objects. These Active Objects ity is its wide use in networking applications. Linux has allow linking applications to events and can also be used as support for a superset of all supported network protocols a tool to achieve cooperative scheduling[6]. Their use is des- and drivers seen in the other operating systems that were tined to applications that spend most of its execution time in analyzed in this paper. Linux implementation of network idle state, waking up upon certain events which may trigger, protocols and drivers are considered secure by many devel- for example, the activation of several hardware resources. opers and administrators[8], who point at faulty user space This approach allows the kernel to know that those are spe- daemons and applications (not at the kernel) when a Linux cial types of system resources thus needing special schedul- system gets compromised[2]. Linux is regarded as a refer- ing policies. The kernel then chooses to divert processor ence in software development, mostly due to the impressive cycles to some other more resource hungry tasks that may amount of tools available: all the GNU tools, cross platform be concurrently executing, or even turn off the processor emulators, compilers and even proprietary tools for devel- temporarily if no other tasks are executing. Controlling the opment for proprietary closed platforms[31]. There is also scheduler indirectly using special types of kernel resources is an already big (and continuously growing) number of open a unique characteristic unseen in all other solutions reviewed source applications available, dispelling the myth that one in this paper. Symbian OS is entirely written in C++ and cannot find an open source solution for a specific propri- the development kit (which is available to Symbian part- etary application[19]. This growth is also due to several ners only) has support for Python, Visual Basic and Java investments in open source technologies by some major IT ME. The development kit also has a full featured windowing companies and hardware manufactures that keep pushing system, with its own font server, that allows all graphical Linux into the mainstream desktop, server and embedded applications to be integrated using a common framework. market. Symbian OS is also a direct competitor against Windows CE in the PDA and smartphone market and, like its com- 2.7 RTLinux petitor, it was designed having in mind a limited number of Linux has its roots in the desktop systems, but evolved as architectures, namely ARM and x86. a general purpose operating system. The need for real time behaviour was felt after the first successful attempts for de- Symbian is very criticized because of it’s code base unmea- ployment in embedded systems occurred, in 1999[31]. From sured growth since its appearance, with all the different all the extensions that were implemented to add hard real vendors implementing their custom extensions instead of time support to the Linux kernel, the most popular is the contributing to a more centralized architecture. This re- dual kernel approach. In this approach, the “normal” non sulted in an astonishing amount of system and user classes, real time kernel is treated as the lowest priority task of a real libraries and functions available, all following their different time micro kernel, which handles all real time tasks. The approaches to solve common problems[7]. Poor documenta- new real time kernel, RTLinux, can be compiled as a mod- tion is also a weak point of the Symbian operating system, a ule and inserted or removed in execution time, adding or fact which, added to the huge size of the system API, makes taking away real time capabilities from the running kernel. many developers think of the development for the Symbian Although the dual kernel approach is invisible to applica- OS as a complex and frustrating task. tions, the tasks that run in the real time kernel always run in supervisor mode and do not take advantage of the tested 2.6 Linux and mature memory protection offered by an unmodified Linux is a free and open source operating system kernel. Linux kernel. Also, each process that runs in the new real There are many distributions based on the Linux kernel. time kernel is no longer a Linux process and must use the For the installation on the test machine, Debian Linux was non-standard, Posix based, RTLinux API[11]. The new real chosen. Despite not being a hard real time kernel, Linux’s time processes are never swapped out and run in the kernel preemptive scheduler has O(1) complexity which makes it address space, eliminating TLB misses (for those processes). suitable for some real time applications[5]. Linux’s sched- Interrupts in the new kernel have an added flag that indi- uler supports task queues, preemption under user and kernel cates the need for real time scheduling. Other interrupts are mode and four scheduling classes: Normal (dynamic priori- redirected for the non real time Linux task. As for drivers ties), FIFO, round-robin and Batch. The Linux kernel also and supported protocols, the Linux implementation contin- supports symmetric multi processor architectures without ues to be non-real time. Only the drivers and protocols loosing any of the capabilities and system calls it has on developed for RTLinux have real time behaviour, hence, the support is much poorer than the one found in the Linux to take place immediately[15]. vanilla kernel. 2.9 Inferno Installing and configuring RTLinux is not a straight forward Inferno operating system is a direct descendent from “Plan 9 process because it involves downloading, manually configu- from Bell Labs”, which aimed to be “what Unix should have ration and compilation of the RTLinux module for later in- been” since its birth in 1969[13]. Both operating systems are sertion. This is comparable to the configuration of the Linux based in common Unix premises which were implemented in vanilla kernel. Development tools and applications are the a more coherent way and can now be applied to all use cases, same as the ones available for Linux. with no exceptions. Some of these premises are: • All resources are files and share a global, unique and 2.8 uClinux unambiguous namespace uClinux was initially a port from Linux 2.0.33 to MMU- • All local and remote resources are represented in the less architectures. Linux kernel was designed having Intel’s filesystem using an unique and unambiguous names- 80386 virtual paged memory in mind, which made its use pace under processors without an MMU impossible[18]. When • All local and remote resources communicate using the no MMU is present, the operating system sees the entire same protocol (called Styx on Inferno OS) memory as a continuous block of readable/writable address InfernoOS can run on its own, as a native operating sys- space. uClinux implements a memory management sys- tem but also as an application on other platforms, namely, tem with several policies for incremental memory alloca- Linux, Windows, FreeBSD, Mac OS X and others. Appli- tion, avoiding potential fragmentation problems that can cations are written in a type safe language, called Limbo, arise. Part of the new memory management system includes which uses a byte code intermediate representation. All a “page” implementation in order to maximize compatibil- these applications can then be executed using just in time ity with the existing page oriented vanilla kernel and driver compilation in a virtual machine. Despite being a hybrid code. Linux applications must be ported for running un- kernel, the Inferno kernel always runs in supervisor mode der uClinux[19]. For C applications, this can be done us- providing memory protection only to the virtual machine ing the uClibC and its libraries, which play a vital role level, isolating each separate instance from each other. in the uClinux distribution. Upon the Linux kernel tran- sition to the 2.6 branch, much of the code under uClinux For this operating system and development kits, resources was merged in the vanilla tree, however, both are separate are very low, having only 1MB of ram as its lower limit. The projects and it is the uClinux team who needs to synchro- development kit consists of the Acme IDE which provides nize the uClinux patches for new Linux releases. Currently, several compilers (including one for the C language), unix a uClinux distribution contains a 2.2, 2.4 and 2.6 uC-kernel commands, a graphical debugger and all Limbo libraries for branches, pre-configurations for many hardware vendors and network access, GUI usage and security protocols (encoding boards, uClibC and a large number of popular applications and encryption). Being an open source operating system, which are already ported to uClinux. Like RTLinux and the all application and kernel source code is provided. Linux vanilla, configuring a uClinux bootable image is a dif- ficult process. The uClinux configuration system is buggy Inferno OS is not very popular in the embedded market, but and gives strange incompatibility and dependency results for it is tested and runs in various Intel StrongARM develop- certain option combinations. The kernel capabilities remain ment boards. The author considers the virtual machine ap- basically the same for interrupt and task management, only proach and the uniform architecture mentioned above (sin- with some minor details inherent to the target processor gle namespace, all resources as files, single message format) used. The major difference resides in the memory manage- to be a good candidate to future embedded applications. ment policy which is implemented using a pool with different Applications could be compiled once and run on any em- block allocation policies. bedded (or non embedded) operating system, similar to the Java ME concept, but with tight integration with the oper- Developing for uClinux can be done using the GNU tools and ating system. other toolchains provided by hardware manufacturers. De- spite the large number of already ported applications (http, ftp and ssh servers and clients, music players, text editors, 2.10 eCos shell and shell utilities, among others) the basis for port- eCos stands for embedded, configurable operating system. It ing existing applications from Linux to uClinux can be ex- is a real time open source operating system designed for em- plained having only two replacements in mind: malloc must bedded systems or systems that only need one process with be replaced by one of the substitutes present in the uClibC multiple threads to fulfill all their tasks. eCos is targetted for (malloc2 or malloc simple) and fork must be replaced by a systems with very limited resources (less than 1MB of RAM) vfork + exec call. For complex applications, these rules are that are simply too small to run Linux or uClinux. eCos is sufficient to render a port impossible to implement without also used as an advanced full featured boot loader, capable of a major application redesign. For example, replacing mal- retrieving other Operating Systems’ images using ethernet, loc with one of the two options mentioned can cause a lot usb or serial connections[10]. Although it is considered a of fragmentation, depending of the memory consumption minimal operating system, eCos is extensively configurable. pattern displayed by the application. As for the fork and Its kernel has real time behaviour, support for multi-level vfork+exec approach, a special care should be taken with and nested interrupts, several scheduling policies, processes, some shared and initialized variables whose value will not threads, interprocess communication primitives and offers be propagated to the child process. This is due to the lack Posix compatibility[14]. eCos hardware support list is very of implementation for the “copy-on-write” process, present extensive and includes several ARM, Hitachi, H8, Motorola in the vanilla distribution, which makes marking a memory 68000, MIPS and PowerPC processors, along with USB and region for later copy impossible, forcing the copy operation TCP/IP stack implementations. Development is done us- ing common open source GNU tools, being very similar to tion. However, when porting the application for the XTran- developing on a Linux platform. 3 board, the choices are reduced for uClinux and eCos for hardware support reasons. In fact, uClinux and eCos are 2.11 Contiki the only operating systems that provide out of the box sup- port for the M5282 processor present in the XTran-3 board. Contiki is an open source operating system designed for For the open source solutions, a port would be necessary. very small embedded devices, with little memory resources Since uClinux scored much better than eCos in the evalu- and processing capabilities. Examples of these memory con- ation done in this paper, and also due to the instability of strained systems are some 8 bit computers from 1980 (namely the current M5282 code of the eCos port[21], uClinux is, the the Commodore 64) and some microcontrollers. It has indeed, the better solution for the XTran-3 board. One al- a multitask monolitic kernel, a simple GUI library sufficient ternative solution would be to ask for support to one of the for developing graphic windowed aplications and an imple- providers for the commercial solutions analyzed. However, mentation for the TCP/IP protocol. To run Contiki with the use of a commercial solution is discouraged not only all these features only 30KB of ram are needed. Contiki’s for cost reasons, but also because the benefits of choosing a kernel is event driven such as the task model citeDunkels- Linux based alternative are not negligible in the context of GronvallVoight. Preemption support is configured and en- Tecmic’s embedded system: vendor independence, less time abled individually in each process that needs this type of to market, large hardware support and the fact that it is scheduling policy. Its graphical environment can be made an extensively used open source product with many open available using a VNC virtual display client. source applications available and a large developer and user base. When running, Contiki is divided in two parts: a core and eventually some loaded programs. The core part consists of the kernel, a set of base services and shared libraries. Shared 3. PORTING UCLINUX TO THE XTRAN-3 libraries and other common functionalities are implemented BOARD as services, which can be updated or replaced individually, The first step in porting uClinux to any embedded system resulting in a very flexible structure. One notable character- is to enumerate all the components of the hardware to port. istic of this operating system is its memory footprint which The most important components are the ones considered to can be less then 100 bytes. be vital for the system to boot, even if it will not be fully functional at first (not all drivers loaded or implemented) or 2.12 Overall Comparison of Selected Solutions even functional at all (no console shell, for example). These vital components are the processor, the RAM memory and Conki the serial port, or other means necessary for console output. eCos The XTran-3[20] board, for example, is based in a Motorola Inferno Coldfire processor (5282), four flash memory modules hold- ing 2 MB each, two ram memory modules of 4MB each, one uClinux real time clock chip and an I2C EEPROM that controlls two RTLinux I2C chips. Figure 3 shows how this hardware is connected Linux in the XTran-3 board. Symbian WinCE Motorola ColdFire 5282 VxWorks Processor QNX BUS 0 1 2 3 4 5 Flash 1 I2C EEprom RAM RTC Ds2404 Serial Port STM29W160 ATC24C128 Figure 2: Overall Solution Scores Flash 2 STM29W160 I2C Slave 1 I2C Slave 2 The choice of the operating system to use in an embedded PCF8574 PCF8574 system has a vital impact in the overall porting effort. One Flash 3 Leds Leds conclusion can be drawn from the analysis done in the pre- STM29W160 vious sections: there is a real need for an open and generic software architecture that can be extended to most, if not Flash 4 all, embedded systems. Besides WinCE and Symbian Os, STM29W160 which were designed having specific hardware arquitectures in mind (x86 and ARM), all other reviewed solutions share a common goal: to support as many architectures as pos- Figure 3: XTran-3 hardware involved in this port sible. Regarding this objective, Inferno operating system represents a major step forward, despite its lack of popular- Besides knowing the hardware to port, one must also have ity, because it has a truly universal namespace for system all the necessary software and hardware tools in order to resources and all its applications are deployed using an inter- successfuly configure, deploy and boot an uClinux image mediate, machine independent bytecode format. Inferno OS file (containing the kernel and programs that will run) in also has a unique and global format for kernel messages, im- the target system. This will be explained in the following plemented with the goal of simplifying kernel development sections. and internal implementation[13]. Of all commercial oper- ating systems analyzed, the one that showed better overall 3.1 uClinux configuration and build system score was VxWorks (see figure 2). For the free operating All the XTran-3 hardware information must be entered into systems analysed, Linux is clearly the best possible solu- the uClinux configuration system. After configured, the project can be built, resulting in an image file containing of the kernel’s first task is to rewrite every interrupt vector the kernel and user programs (see figure 4). The uClinux addresses to be able to handle all system interrupts and this configuration system is divided in three steps: vendor selec- included the watchdog kicking routine. In the absence of tion, kernel configuration and user program configuration. watchdog kicks, a software reset was immediately triggered The developer starts the configuration process issuing the by the watchdog and caused the processor to return to the command “make config” for the text version or “make xcon- boot loader execution. To solve this problem, the watchdog fig” for the tcl/tk version under a X Windows environment. initialization code was changed in Tecmic’s boot loader in The vendor “Tecmic” was created, along with the “XTran- order to disable it, causing the Linux kernel to boot, say its 3” product in order to accomodate all the settings in one motd and present the long awaited console to the user. Get- place. This creation process is manual and includes editing ting the kernel to successfully boot in the Xtran-3 board was a couple of makefiles, configuration files and create a direc- a very difficult task and took half of the porting effort total tory structure. Upon the start of the configuration process, time. The difficulty resides in the absence of console output existing vendor files and folders are processed and appear as (until proper initialization of the console) and the configura- options in the product/vendor selection screens. tion of kernel options (scheduler, addresses for code location and ram disk size) in order to get a minimal, but functional The 2.6 kernel version was chosen (2.6.19), along with the system. designated processor, ram size, interrupt vector location and size, supported filesystems, console driver and the kernel ini- tialization parameters. The image file has a structure similar 3.3 Real Time Clock driver to the one in figure 4 and must be copied to the target board The first device ported to uClinux was the real time clock ram. The copy operation was done in different ways during chip present in the XTran-3 board. This device is a Dallas development. Due to the absence of an ethernet chip in the ds2404 which is currently not supported by the Linux ker- XTran-3 board (although the slot was there, the prototype nel. The closest match to what is already implemented for used in this work did not have it mounted), the serial port that vendor in the Linux kernel, and probably would actu- was used initially to transfer the image file. A modification ally work, is the Dallas 1 wire bus driver. However, since to the Tecmic firmware was implemented in order to trans- the current Tecmic design is connected to the processor us- fer the image files using the serial port and then jump to ing the 3-wire pins, the current implementation does not fit the first address of kernel executable code. This proved to the porting purposes. Since this device serves a specific pur- be a very slow process, not only because of the record for- pose which is very frequent in embedded and non-embedded mat used (Motorola S3 records) which increased the total systems, there is a specific class for real time clocks in the amount of bytes to transfer, but also apparently to a hard- Linux kernel. For proper development of this type of de- ware limitation in the XTran-3 board, which resulted in data vices, one must implement a specific API for accessing the corruption for transfer speeds greater then 19200 bps under device and the kernel does the rest from there on. hardware and software flow control. After the initial proof of concept builds were working, Tecmic made a BDM port The DS2404 device exposes its functionality using several available to this project, which was immediately put to good memory pages. In these pages, among other information, use, resulting in transfer speed gains from 45 to 3 minutes. the current Unix time is stored. For reading and writing a determined amount of bytes from one of the available pages, one must use the scratch pad, which acts as intermediate System Image (Kernel and buffer for each byte to read or write (total capacity of the Partition 1 Vectors romfs) scratch buffer is 256 bits). There are 16 pages of 256 non- volatile bits each. The current alarm and time values can be found in the address 0x0200h[4]. The device only supports three different operations which, when called using different Figure 4: XTran-3 Image memory layout in XTran-3 arguments, provide full control of the device. These opera- ram tions are: • Copy the contents of an address range from a page to 3.2 Bootloading to uClinux the scratch buffer Although very complex and self contained, the kernel code is • Copy the contents of the scratch buffer to a page unable to boot by itself, requiring several resources to be al- ready initialized by a special component that runs before the • Read the scratch buffer kernel: the boot loader. For the XTran-3 board, the Tecmic Reading the current time, for example, involves initializing test application was used as the boot loader. Upon transfer the device with the address being read, then ask for a copy of the image to the board RAM memory, the boot loader operation from the contents of the previously given address was initialized by manually pressing the board reset button. to the scratch buffer and then read the scratch buffer[4]. Booting to uClinux is a new option implemented during de- Data is sent bit by bit using the GPIO interface of the Mo- velopment of the porting operation that simply changes the torola Codfire 5282 processor. processor’s program counter register to the initial address of the kernel executable code. In the XTran-3 architecture, Thanks to the RTC class, it was possible to initialize this de- this is enough for the Linux initialization output to start vice as the default device for time retrieval, which means the appearing in the output console. Besides proper console ini- kernel, upon initialization, will initialize its internal clock tialization in the uClinux kernel which, when enabled by (that does not need any device and uses the processor’s pre- appending the correct boot parameters, allowed to see what scaler for counting time) with the current time read from was happening during the boot phase, one of the initial prob- the ds2404 device. Also, using the proc API, a character lems faced and solved was a compulsive hardware reset trig- node was created in the /proc filesystem to show the device gered by the board’s watchdog. This happened because one status: # cat /proc/driver/rtc there was only one device. With physmap, only one of the rtc_time : 20:28:05 four modules worked correctly, hence, a new module was rtc_date : 2005-02-18 implemented to map each device individually. Each module alrm_time : 17:10:47 handles partitions and partition sizes in a similar way the alrm_date : 1973-10-08 physmap module does, so each chip can be partitioned using alrm_wakeup : no userspace utilities or at boot time using the kernel command alrm_pending : no line. If one would want to partition one of the ST flash chips 24hr : yes in three partitions, p0, p1 and p2, the first with 1024 KB, id : 0 the second with 512 KB and the third with 512 KB, the # following line should be added to the kernel boot command:

Upon loading, the new ds2404 module generates a character xt3map-flash1.0:1024k(p0),512k(p1),512k(p2) device node called /dev/rtc0 which can be accessed by any application that was designed to use the Linux kernel rtc With the mapping modules loaded, each device is accessi- API. Examples of these programs are hwclock and date, used ble for reading and writing using two filesystem nodes, a to test this module’s funcionalities. character device, for passing specific flash commands, and a block device for transferring binary data. However, this 3.4 Flash Mapping driver kind of access alone is not desirable because it is not pos- The XTran-3 board has four NOR flash modules of 2 MB sible to create files using the filesystem utilities. Currently, each, directly available through its addressing space. Sup- there are two different layers to link the mapping layer to port for flash memory devices has a special implementation the normal filesystem layer. The first one is with the FTL in the Linux kernel[30], as demonstrated in figure 5. module (flash translation layer). This module creates an ad- ditional block node for each pair of device nodes created by the mapping layer. With the new block node, one can use User Level mkdosfs mkjffs mkjffs2 the normal filesystem utilities (mkdosfs, mkext2fs, touch, cp, mkdir, etc) to create and work with the newly created filesystem. The FTL implementation in Linux is very sim- Char Access Block Access ple, but does what it is supposed to: it maps and handles Logic Level flash blocks as if they were normal byte blocks. However, FTL NFTL JFFS 1 / 2 this approach is a naive one because it does not optimize the use and weariness of each block. Flash memory has a limited number of writes before each block gets worn out, so a cru- System cial factor for extending the lifetime of this type of memory Disk On Chip Kernel RAM Memory is to distribute the write operations across as many different blocks as possible, without loosing filesystem integrity. It is Mapping Driver Physmap Octagon possible, using FTL, to mount a FAT filesystem in a flash Hardware Level chip, but the blocks will wear out quickly because FAT, by design, uses a specific region of the physical device to store the file allocation table1. In the uClinux version used in Device Driver Jedec CFI this work (20070130), the FTL module compiled, but does a kernel panic upon loading. All known good configurations for this module use the previous major kernel version (2.4) and even with some debugging and questions posed to the Figure 5: XTran-3 Memory Technology Devices im- uClinux mailing list, no fix for this problem was found. plementation in Linux However, there are other better options for implementing Starting from the lowest layer, closer to the hardware, there this layer. One of those options is the use of a filesystem that are two command sets implemented in the Linux kernel for was designed to work with flash devices[30]. For this work, communicating with the flash memory hardware: CFI and JFFS2 was chosen. JFFS2 stands for Journalling Flash File Jedec. CFI is desirable because it is supposed to be an System and is a log-structured file system for use with NOR evolution of the older Jedec and defines a common method or NAND flash memory devices. Besides the wear leveling for reading each chip’s topology and other manufacturing capabilities, two of the most notable characteristics of the data. All four flash chips are siblings from the same model: JFFS2 filesystem are the use of compression (using zlib, ru- M29W160DB from ST. After several attempts at using CFI bin or rtime algorithms) and a garbage collection algorithm to correctly auto detect each chip, the only way to make to reduce overall fragmentation[30]. The JFFS2 filesystem the kernel recognize this device was to patch the broken is available as an option in the Linux kernel, and was suc- jedec probe.c file in the kernel code. The final working con- cessfully used in the XTran-3 board, providing seamless file figuration for successful detection and communication with access to the four flash chips and enabling the use of direc- the four chips consisted in using Jedec code for the detec- tories, files, soft and hard links and access to the device as tion and a CFI command set from AMD for communicating if it was a normal block device. This is a great improvement with the device. The next layer is the mapping layer, and over the previous Tecmic software implementation, which it allows the kernel to address the device using a specific used the chip blocks directly to read and write chunks of range of memory addresses. This was achieved by configu- rating the physmap module, however, given the interleaved 1This type of mapping is what the typical USB pen drives distribution of each chip’s address range in the system mem- do by hardware. The quality and durability of each device, ory and the current implementation of the physmap mod- among other factors, is dependent of the hardware imple- ule, physmap was “tricked” into handling everything as if mentation of their internal FTL algorithms. bytes. to the information in the file. The file is a simple text file and contains a sequence of numbers and LED states whose 3.5 LED driver spatial disposition in the text file is the same as in the LED panel. An example file would be: The XTran-3 board has a set of 13 general purpose LEDs. One of them is directly connected to the processor, the 10 other 12 are divided in two groups, one with 8 and the 000000 other with 4 LEDs. Each group is connected to an I2C 000000 controller, model PCF8574SO16, but these controllers are 40 not manipulated directly by the processor. Instead, Tecmic 111111 simplified the task of having to implement a driver in its 111111 custom software and added a master I2C controller EEP- 20 ROM. The master controller is directly connected to the processor and the other two controllers are connected to the The first number is the number of times the sequence will master (see figure 3). To control each LED, one must write repeat. The next two rows provide a spatial representation an address/value pair in the EEPROM address and, upon of all the 12 LED states, 1 means on and 0 means off. The entering the execution command, the data is sent across the number next to the two rows indicates the previous state I2C bus, causing the LED to update its state. The code duration in milliseconds. In this case, the LEDs will remain to write to the EEPROM was heavily inspired in Tecmic’s completely off for 40 milliseconds. Next in the file one can implementation, and it was integrated in the Linux kernel have as many states and durations as desired. In the given using a standard character device[12]. The data is entered example, all LEDs are turned off and then lit for 40 and in the form LED number=state flag. For instance, 3=1 10 milliseconds respectively. This sequence is repeated 10 means: “lit LED 3”. Changing several states at once is pos- times as specified by the first number in the beginning of sible using the : character to separate several commands: the file. “4=0:5=1” means turn off LED 4, lit up LED 5. The device driver copies the data from userspace and sends commands to the EEPROM. Like in the ds2404 driver, several appli- 3.8 Updating the configuration scripts cations can read or write to the file at once because all the Besides all the C code files containing the implementation critical regions are protected by a spinlock. An example us- for each driver, several updates to existing configuration files age of the implemented driver can be done using only the (Kconfig files) had to be done so that the new drivers could following shell command: appear in the configuration screens and be selectable when the M5282 architecture was chosen. Also, several Makefiles # echo "3=1:4=1:5=1:10=0" > /dev/xtranleds had to be changed to enable inclusion of the new kernel object files into the image file. The critical region, protected by the spinlock, consists in changing the state of a single LED because once the write Userspace programs have a similar method for inclusion in protocol begins, it cannot be interrupted, otherwise, the de- the configuration screens. There is one Makefile for each vice would eventually enter an incoherent state and become program and, by defining actions for well known targets, the unusable. compilation script can invoke those pre defined targets and generate the executables for inclusion in the romfs image. 3.6 ds2404help application Although date and hwclock are sufficient to control the rtc 4. EVALUATION clock, there is an additional operation that was not sup- In order to accurately access the system’s performance, a ported by any of the two programs. This operation sets the rigorous program-based evaluation had to be carried out. current alarm date and time in the RTC clock. In the typ- Such procedure helped perceiving how the ported system ical PC, it is only used by the motherboard chipset driver compares to other embedded systems based in uClinux (with for triggering wake on alarm events. For setting the clock similar hardware) and to the proprietary in-house solution and alarm time and date, an application was written: the from Tecmic. ds2404help. Despite its name, it works with any rtc driver because it uses the ioctl interface, whose entry points are 4.1 Experimental Setup implemented by the rtc driver, to ask for specific rtc data. After all implementations described in the previous section, The implemented syntax allows one to set the alarm and/or the ported system was put to test. The test environment the time with one simple command: consisted in an uClinux image containing all the programs used during development, plus the test tools. All the tools # ds2404help -a 02/07/1981:21:48:00 -d 02/07/1981: used or implemented have the capability of showing the test 21:48:00 results in the output console immediately before the end of its execution, allowing the data to be extracted for further 3.7 ledshow application analysis. All the kernel modules developed were loaded in The Xtran LED driver implemented in this port allows di- the kernel, but no processes were running in the system rect manipulation of each LED state, but changing several besides each test executable file. LEDs at the same time can be bothersome and requires the programmer to know which LED number is assigned 4.2 lmbench Tool to which position in the XTran-3 board panel. To simplify The lmbench tool is a widely used test tool for Linux sys- the process of bulk state writes to all LEDs, the ledshow tems[23], providing an extensive amount of programs to test application was written. It receives a filename passed as ar- certain aspects of the operating system. By using the lm- gument and processes it, changing the LED state according bench tool, one has a common base for comparison with results obtained in other architectures and execution en- counterEnd = getTimeOfDay(); vironments. The lmbench site provides many benchmark print("Time spent: %d", counterEnd - counterStart); results on popular desktop and server environments. end

Lmbench version 3 was used in the tests, but since the vanilla Note that it is expected that the ported system will have version of this tool only compiles under libc, a ported version far worse results than Tecmic’s firmware. This is because for uClibC was checked out from the Blackfin Linux project Tecmic’s firmware is a realtime system and this code will repository and incorporated as an additional program for run in exclusive mode (there is no task scheduling and/or the customized uClinux distribution produced in this work. context switching). In Linux, the program will be run from Three benchmarks were chosen to run for their significance: user space and use the uClibC functions to access the con- lat proc, lat syscall and lat ctx, however, lat ctx is the most sole, which will in turn do a predefined system call that will important test because it is widely used for measuring the trigger the console driver to place the results in a buffer. uClinux performance on several embedded systems. lat syscall Measures the amount of time necessary to write 4.4 Evaluation Results a byte in the special node /dev/null. Although it is Figure 6 shows that the uClinux 2.6.19 scheduler does not a very simple test, the result value presents the lower get affected by a large number of processes in the system. limit of the amount of time necessary to interact with The context switching time remains steady, which can be the kernel from user space. The results can be useful explained by the absence of the MMU and the improvements for comparing the ported system with other versions implemented in the kernel scheduler since version 2.6.19. of uClinux. Note that for each buffer size, which varies from 0, 1 or 16 lat proc Measures the amount of time necessary to create KB, there is an observed time interval, corresponding to the and start a new process. This test was executed in two amount of time necessary to calculate the array values’ sum. different modes: the vfork + exit and vfork + execve. This factor is the “ovr” value showed by the lat ctx output. Vfork + exit measures the amount of time necessary to create a child process similar to the parent process. Vfork + execve measures the amount of time necessary to create a child process similar to the parent process 2.6.19‐uc1 XTran‐3 and start the execution of the child process.

s) 300.00 lat ctx Measures the amount of time necessary for the ker- µ 200.00 0 KB, 209.96 us nel to make a context switch between a variable num- 100.00 Time ( ber of processes. During the execution of these tests, 0.00 1 KB, 258.70 us several processes are created with two pipes, each con- 2 4 6 8 10 12 14 16 16 KB, 910,17 us necting the previous one to the next, making a ring. Number of Processes Each process reads data from the entry pipe, performs a variable amount os calculations (sum the values in the array) and sends the result to the next pipe. These Figure 6: lmbench lat ctx results in the XTran-3 tests are compared with the test results obtained by board (kernel version 2.6.19-uc1) Samsung using one of its boards, the S3C24A0. This Samsung board contains an ARM processor, model 926ej running at 200MHz. The kernel version used by In figure 7, the comparison results for a specific lat ctx test Samsung is older than the one used in this work, hence, are shown. The test was performed setting the array size due to improvements constantly being implemented in to 16KB and making variations to the number of processes. the Linux and uClinux kernel, some variations are to The ported system is 2.3 times faster at context switching be expected. then the 2.6.11 version of uClinux running in a faster proces- sor. This is also explained by the differences in the scheduler and the architecture used. Note the context switching time 4.3 Custom Console Test Tool in uClinux is always faster than Linux even under similar Lmbench runs in every Linux environment, but does not hardware, however, there is a large “ovr” factor difference run in Tecmic’s solution deployed in that, despite not being shown in the results, is directly ob- the XTran-3. To compare the old system and the ported servable in the system, making the test actually run slower system, a simple test program was written. It measures in the ported system versus the Samsung board. This is due the time necessary to transfer a specified amount of char- to the fact that the ARM processor has a higher clock fre- acters from the console to the kernel and back to the con- quency (200 MHz vs 66.6 MHz) and is generally much faster sole. Tecmic’s firmware was once again changed to perform doing ALU calculations[22] than the Motorola Coldfire 5282. this task and present the obtained results using the console. As for the ported system, an userspace program was im- Figure 8 shows the console test results. Surprisingly, the plemented, using the uClibC API, using simple printf and ported system is faster than Tecmic implementation, at least scanf functions[3]. The pseudocode for this test is the same for serial port transfers. Since the code being tested here for both implementations: consists of the serial driver implementations of Tecmic and uClinux, the test shows that the Linux kernel implementa- begin tion of the MCF serial driver has better performance than waitForFirstCharacter(); Tecmic’s code. counterStart = getTimeOfDay(); do{ char = receiveChar(); 5. CONCLUSIONS AND FUTURE WORK print(char); In this paper, a successful port of uClinux to a propri- } while (char != CHAR_END); etary embedded system is presented. Also, a qualitative including benchmarks with a common Linux benchmarking Size = 16KB tool: lmbench3. By planning and defining these porting 350.00 tasks for each project, a “porting road map to Linux” can 300.00 be obtained and its accomplishment is considered vital to

250.00 achieve a functional and mature Linux port for an embed- ded system. s)

µ 200.00 2.6.19‐uc1 150.00 2.6.11.6‐uc1 Time ( The proposed solution implemented the drivers for the RTC 100.00 2.6.11.6 clock, the mapping driver for the four flash chips and the 2.4.20‐mvista 50.00 LED driver. Two applications were also developed to exper- iment with the new drivers, but both can work with other 0.00 hardware because the generic kernel API was used. With 2 4 6 8 10 12 14 16 the uClinux port, the system now provides all Linux bene- Number of Processes fits: user space programming using the libc, task scheduler, processes, synchronization functionalities, proper filesystem Figure 7: lmbench lat ctx result comparison support and a multitude of advancements which were impos- sible in the original system, or required a substantial amount of investment to be implemented. Despite the successful Serial Port Transfer port in functional terms, several measurements of the system performance were taken using a widely used tool for bench- 50.000 marking: lmbench3. The preliminary results were promis- 40.000 ing. The new system performs better at context switching 30.000 than an ARM based solution using an older 2.6 kernel, even

20.000 uClinux with the differences in clock speed which clearly gave the Time (ms) ARM an advantage. Other reason for this performance im- 10.000 Firmware Tecmic provement is the advancements that get implemented in the 0.000 Linux kernel in each release. As for the performance com- 300 900 3600 parison from the old versus the ported system, the ported Number of bytes to transfer system showed gains when performing a data transfer using the serial port. Although this benchmark was developed us- ing a similar algorithm for both systems, since the uClinux Figure 8: Serial console test results implementation run in user space and used libc, a stronger negative performance impact was expected. This did not happen in the benchmarks run, probably due to the more analysis to several free and commercial embedded operat- elaborate implementation of the Coldfire serial port driver ing systems is done. From all solutions reviewed, uClinux implementation in uClinux, compared to Tecmic’s custom proved to be the best choice for the XTran-3 hardware, a implementation. In conclusion, uClinux was ported suc- custom embedded system designed by Tecmic and used in cessfully to run in the XTran-3 board without affecting the this work. Choosing the right Linux solution and kernel system performance, in fact, it actually improved it under depends mainly on system requirements and hardware lim- certain situations (serial port data transfer). itations: real time solutions require RTLinux, no-MMU ar- chitectures require uClinux and Linux can be used on all As to future work, the author concludes that porting the re- others. One can conclude that in order to gain a realistic maining board hardware and applications would give Tecmic perception of each solution’s strong and weak points, an ex- a colossal advancement over the previous system. Thanks to perimental approach is necessary. This practical approach the use of libc, future application compatibility is assured. can go from the simple installation of each solution on a There is now a multitude of applications already included development machine, to real deployment attempts on the in uClinux, ready to provide advanced network and even target embedded system. multimedia capabilities. Also, much more benefits could be obtained from a Linux port if the target processor had Developing for uClinux requires the right tools for building an MMU. The existing ported applications would work out each architecture’s specific code and the environment setup of the box, and, depending on the processor choice, minor is not tightly integrated or even user friendly, contrary to or no modifications to the new drivers would be necessary. what happens with all the commercial solutions analysed. The author suggests the migration to a processor with a uClinux build system is clearly one of the distribution’s weak MMU from Motorola. A good example is the Motorola points since several fixes to the configuration scripts and ker- 5745 because it also operates in no-MMU mode, maximiz- nel files had to be implemented in order for the system image ing compatibility with the current uClinux port. The new to be built correctly. Deploying and running the uClinux im- port would also require a heavy amount of business logic re- age required additional effort because porting uClinux to the gression tests in order to assure full compatibility with the XTran-3 board also implied a port of the XTran-3 firmware entire XTran architecture. to run uClinux. This apparently “backwards” task had to be carried out because the uClinux kernel is not capable of booting by itself and needs a bootloader to initialize part of 6. REFERENCES the hardware. In this work, Tecmic’s firmware was modified [1] Thiemo Voigt Adam Dunkels, Bjrn Grnvall. Contiki - to serve uClinux’s boot loader needs. After proper setup and a lightweight and flexible operating system for tiny deployment of the uClinux distribution, the device drivers networked sensors. NOV 2007. and application implementations took place. After the de- [2] Jorge Kurtz Brian Hatch, James Lee. Hacking Linux velopment was concluded, several tests were also performed, Exposed. McGraw-Hill, second edition, 2008. [3] Dennis M. Ritchie Brian W. Kerningham. The C [30] David Woodhouse. Jffs : The journalling flash file Programming Language. Prentice Hall, second edition, system. 1999. 1988. [31] Karim Yaghmour. Building Embedded Linux Systems. [4] Maxim Integrated Circuits. Ds 2404 econoram time O’Reilly, first edition, 2003. chip. DEZ 2000. [5] Marco Cesati Daniel P. Bovet. Understanding the Linux Kernel. O’Reilly, first edition, 2000. [6] Aapo Haapanen. Active objects in symbian os. APR 2008. [7] Hrissan. Symbian os design faults. JAN 2005. [8] Keith W. Ross James F. Kurose. Computer Networking, a Top-Down Approach Featuring the Internet. Prentice Hall, third edition, 2005. [9] Alessandro Rubini Jonathan Corbet and Greg Kroah-Hartman. Linux Device Drivers. O’Reilly, third edition, 2005. [10] Jonathan Larmour. How can be shrunk to fit. MAY 2005. [11] C. Douglass Locke. Posix and linux application compatibility design rules. NOV 2005. [12] . Linux Kernel Development. Sams Publishing, first edition, 2005. [13] Howard Trickey Martin Atkins, Rob Pike. The Inferno Programming Book: An Introduction to Programming for the Inferno Distributed System. Vita Nuova, first edition, 2005. [14] Antony J. Massa. Embedded Software Development with eCos. Prentice Hall, first edition, 2004. [15] Paul E. McKenney. Read-copy-update: Using execution history to solve concurrency problems. 2003. [16] Ben Morris. The Symbian OS architecture sourcebook. Wiley, first edition, 2006. [17] John Murray. Inside Microsoft Windows CE. Microsoft Press, first edition, 1998. [18] Kimmo Nikkanen. uclinux as an embedded solution. Technical report, Turku Polytechnic, JAN 2003. [19] Sriram Neelakandan P. Raghavan, Amol Lad. Embedded Linux System Design and Development. Auerbach Publications, first edition, 2006. [20] Tecmic SA. Xtran-3 technical documentation. MAY 2006. [21] David Shorthouse. eCos Supported Hardware. eCosCentric, http://ecos.sourceware.org/hardware.html, 2008. Accessed 2 July, 2008. [22] ARM Embedded Solutions. Arm product backgrounder. 2005. [23] Carl Staelin. lmbench3: measuring scalability. NOV 2002. [24] QNX Software Systems. Welcome to momentics. 2004. [25] QNX Software Systems. QNX Neutrino System Architecture. QNX Software Systems International Corporation, sixth edition, 2006. [26] Andrew S. Tanenbaum. Modern Operating Systems. Prentice Hall, second edition, 1993. [27] Christof Wehner. Tornado and VxWorks What’s not in the Manual. Books On Demand, first edition, 2003. [28] Matthew Wilcox. I’ll do it later: Softirqs, tasklets, bottom halves, task queues, work queues and timers. JAN 2003. [29] Wayne Wolf. Principles of Embedded Computing System Design. Morgan Kaufmann Publications, first edition, 2001.