Porting Embedded Systems to uClinux · Porting, uClinux, Embedded Keywords Linux, Operating System, Kernel, XTran-3, Hardware, Driver, Real Time Clock, Flash, JFFS 2, I2C 1. INTRODUCTION

Porting Embedded Systems to uClinux

António José da SilvaInstituto Superior Técnico

Av. Rovisco Pais1049-001 Lisboa, [email protected]

ABSTRACTThe emergence of embedded computing in our daily liveshas made the design and development of embedded applica-tions into one of the crucial factors for embedded systems.Given the diversity of currently available applications, notonly for embedded, but also for general purpose systems, itwill be important to easily reuse part, if not all, of these ap-plications in future and current products. The widespreadinterest and enthusiasm generated by Linux’s successful usein a number of embedded systems has made it into a strongcandidate for defining a common development basis for em-bedded applications. In this paper, a detailed porting guideto uClinux using the XTran-3[20] board, an embedded sys-tem designed by Tecmic, is presented. The ported systemperformance was evaluated by several benchmark tools. Thepreliminary results looked promising, but there is still roomfor improvement. Hence, some ideas on how to port theentire system are suggested.

General TermsPorting, uClinux, Embedded

KeywordsLinux, Operating System, Kernel, XTran-3, Hardware, Driver,Real Time Clock, Flash, JFFS 2, I2C

1. INTRODUCTIONAn embedded system is a computer system that is designedto do a well defined set of tasks. Since the first embed-ded system, built in the early 1960s for the Apollo guid-ance system[29], other embedded systems were developedtargeting different areas. Driven not only by hardware andsoftware advances, but also by a deeper understanding ofhuman needs and marketing possibilities, general purposeand embedded systems became more complex, implement-ing a growing set of functionalities. Today, there is a multi-tude of embedded systems available, from portable audio orvideo players to mobile phones with wifi capabilities, pow-erful gaming consoles, home network routers and the listcontinues, but still, there are some factors that consistentlydistinguish embedded from general purpose systems:

• Well defined response times (the system must answerto specific tasks without missing deadlines)

• Low hardware requirements (little RAM/ROM, taskspecific processor)

• Specific hardware dedicated to a well defined set oftasks

• Power Management constraints

• Low cost

Concerning response times, computer systems can be di-vided in soft and hard real time[26]. In soft real time sys-tems, missing a deadline only degrades performance, unlikein hard real time systems. In hard real time systems, miss-ing a time constraint before giving an answer may be worsethan having no answer at all. An example of a soft real timesystem is a common DVD player. While good performanceis desirable, missing time constraints in this type of systemonly results in some frame loss, or some quirks in the userinterface, but the system can continue to operate. This isnot the case for hard real time systems. Missing a deadlinein a pace maker or in a nuclear plant’s cooling system, forexample, can lead to catastrophic scenarios!

Like the first general purpose systems, the first embeddedsystems had no operating system. Since the first operatingsystems were implemented, their use in general purpose sys-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 controlledthe hardware available with very minimal or no multitaskingcapabilities continued to be used and developed in-house byembedded system vendors. Today, with a vast number oftechnologies available, many complex functionalities are ex-pected even from the most basic embedded system. A goodexample are home network routers which began as relativelysimple ethernet packet multiplexers and are now expectedto have wifi and printer connectivity, packet routing, switch-ing and forwarding capabilities and even firewall rules thatcan operate in all the OSI network layers. Several of thesefunctionalities require similar software infrastructures thatwere first available only to general purpose systems.

The cost of implementing advanced functionalities in em-bedded systems using only proprietary in-house developedsoftware is unfeasible for many companies, which tend tomigrate to embedded operating systems, commercial or free.A real example of one of these companies is Tecmic, a por-tuguese embedded solution provider. One of Tecmic’s prod-ucts is the XTran-3 board, an embedded system designedby Tecmic, which is the hardware used in this study. TheXTran-3 board is a vital part of Tecmic’s larger “XTran”system, conceived to remote fleet monitoring. In the XTransystem, each board (from here on called XTran-3[20]) is in-stalled and connected to each vehicle. Its function is tocollect data about a vehicle’s mechanical status, global po-sition and driver details and send it to a central computerprobably located in the fleet’s headquarters. Currently, theXTran-3 board does all its tasks using a custom proprietaryreal time operating system developed by Tecmic.

In this paper, several commercial and free open source solu-tions are reviewed and compared with each other in termsof its porting to the XTran-3 board. Also, a detailed port-ing guide to uClinux using the XTran-3 board is presented,including all the relevant steps, from the development envi-ronment set up, to the kernel configuration, device driver im-plementation and application writing. Several benchmarkswere also performed to compare the performance of theported system with the Tecmic firmware and with other pop-ular embedded solutions.

2. RELATED WORKAlthough uClinux was already chosen as the operating sys-tem to port for the XTran-3 board, other candidate operat-ing systems were also reviewed and analyzed.

Besides in-house proprietary embedded operating systems,several commercial solutions began to appear around themid-eighties, providing several different approaches to anextensible, multi-task and real time operating system for awider non-specific range of embedded systems. Two notableexamples of this type of solutions are QNX and VxWorks,which are still available today. Microsoft, one of the leadersin the operating system market, also implemented its ownembedded operating system solution, Windows CE, aimingto provide a high degree of compatibility with its populargeneral purpose operating system APIs and applications[17].With the advent of mobile phones in today’s society, severalmobile phone providers, namely Nokia, Ericsson, Motorolaand Psion, joined efforts to implement a special purposeoperating system for those devices: the Symbian Operat-ing System[16], which will also be described and compared.Besides Linux, which made its first appearance in an em-bedded system in 1998[19], other open source operating sys-tems were ported to run on some embedded architectures,namely, Inferno Os, a descendent from “Plan 9 from BellLabs” (which is itself a re-engeneering of the Unix architec-ture) and Contiki, a very minimal operating system writteninitially for the Commodore 64 home console. eCos is anopen source embedded operating system commonly used tobootstrap into other operating systems, including Linux. Itsmature state and modularized architecture made it into afull featured Operating System and a promising candidatefor running on the XTran-3 board.

2.1 Qualitative Approach to the Technical Eval-uation

In order to qualitatively evaluate each candidate operatingsystem to run on the target board, the following parameterlist was considered sufficient for a basic overview of eachprojects’ positive and negative aspects[26]:

Install and Configuration Although each evaluated so-lution has its own configuration and installation pro-cess, there is a common denominator specific to thenature of embedded systems. This common denom-inator consists of the configuration, creation and de-ployment process of the system image file(s) from thehost to the target system.

Task Management This parameter refers to the availabil-ity of scheduling policies and methodologies implementedin the evaluated operating systems. The existence ofreal time scheduling, processes and/or threading re-sources, preemption and granularity of I/O controlmechanisms was also described and compared.

Memory Management The existence of MMU and paged

memory support is compared, including page swappingmethods and/or memory pool management. Also, theAPI richness for inter-proccess communication primi-tives also contributed as an important evaluation fac-tor.

Interrupt Handling This parameter refers to the existenceof different priority levels for interrupts, interrupt nest-ing and amount of resources available when an inter-rupt occurs.

Network Support Describes the amount of supported net-work protocols and device drivers. This parameterwas introduced due to the growing importance of net-work support for embedded systems[29] and also forthe XTran-3 board.

Development Tools Due to the different nature of eachoperating system, several manufacturers provided theirown development and deployment tools. Others relyon a specific amount of open source tools. The varietyand richness of the development resources is comparedamong each solution.

Applications The amount of existing applications for eachoperating system, open or closed source, is evaluated.

0 1 2 3 4 5

QNX

VxWorks

WinCE

Symbian

Linux

RTLinux

uClinux

Inferno

eCos

ConCki

ApplicaCons DevelopmentTools

NetworkSpport InterruptHandling

MemoryManagement TaskManagement

InstallandconfiguraCon

Figure 1: Solution Comparison Scores

Each solution was configured and installed in a test en-vironment consisting of a typical PC (Pentium IV 3GHzwith 4GB of ram) running Debian Linux and VMWare soft-ware for virtual machine emulation. Also, several operat-ing system documentation considered relevant for this anal-ysis was consulted[12][31][5][17][14][16][1][28][10][27][25][13].Figure 1 shows the qualitative analysis results for each cho-sen operating system. The given score, ranging from 1 to 5,

is described as follows:

1. Immature project with reported unfixed critical errors2. Immature project, used mainly for proof of concepts

and constrained test environments3. Mature project with known limitations and reduced

functionalities. Small number of use cases in real lifeproduction environments

4. Mature project with known limitations and a largenumber of functionalities. Large number of use casesexist in real life production environments

5. No known critical errors, tested in real production en-vironments. Very large number of functionalities

2.2 QNXQNX is an Unix like real-time operating system. The QNXNeutrino kernel has a client-server architecture consisting ofa microkernel[25] and optional cooperating processes. Themicrokernel implements only the core services like threads,processes, signals, message passing, synchronization, schedul-ing and timer services. The microkernel itself is never sched-uled. Its code is executed only as the result of a kernel call,the occurrence of a hardware interrupt or a processor excep-tion. Additional functionality is implemented in cooperativeprocesses, which act as server processes and respond to therequest of client processes (e.g. an application process). Ex-amples of such server processes are the file system manager,process manager, device manager, network manager, etc.The architecture of QNX allows every application , driver,file system and protocol stack to run outside the kernel, inthe safety of memory-protected user space. The interruptredirector in the microkernel handles interrupts in their ini-tial stage. It also supports interrupt sharing and nestedinterrupts. The QNX kernel provides all protection mecha-nisms as foreseen by the different Posix standards (mutexes,semaphores, conditional variables, read/write locks etc). Inthe test machine, all critical hardware used was detectedby the QNX installation process. Installation flavors rangefrom a minimal floppy distribution or a full suite of appli-cations bundled in a bootable cd. All tasks and processesare managed using FIFO or sporadic scheduling and havea priority number assigned. Memory management can bewith or without MMU without loosing real time behaviour.QNX also supports IPv4 and IPv6 and has a built in webbrowser which can be included in the deployed image file.

To build custom QNX images, the System Builder applica-tion was used. This application is a graphical environmentthat runs under QNX windowing system and calculates allpackage dependences upon the building process. It also hasa dietitian feature that can shrink all libraries to containonly the functions used by the current set of applications.Kernel and application development can be done using theMomentics[24] suite which is an IDE based in Eclipse. Al-though there is a reduced number of applications availablefor QNX, there is a Java virtual machine implementation,full Posix compliance and several libraries available for de-velopment in different programming languages.

2.3 VxWorksVxWorks 5 is a proprietary, real-time operating system de-veloped by Wind River. VxWorks has been ported to anumber of platforms and now runs on practically any mod-ern CPU that is used in the embedded market. This in-cludes the x86 family, MIPS, PowerPC, Freescale ColdFire,SH-4 and the closely related family of ARM, StrongARM

and xScale CPUs. The VxWorks kernel features “protectiondomains” that provide containers for logical resources whichdefine the execution environment, namely, the address spaceand accessed libraries. By defining containers for each ap-plication, the kernel can then intercept illegal accesses fromthe program being run, emulating by software the use ofan MMU, thus making possible the use of memory protec-tion even in mmu-less architectures. Like QNX, VxWorks ismulti-threaded and has 256 priority levels for scheduling. Ituses preemption and also a prioritized round robin schedul-ing[27]. Interrupts are handled in a special context outsideany tasks context and have some restrictions for the kernelAPI primitives that can be used inside of it. VxWorks hasextensive protocol stack support[27] and network support,including drivers and basic applications used in a networkedenvironment (ssh clients and servers, http servers, etc)[27].

VxWorks comes with the Tornado IDE which comprises anextensive suite of tools and utilities that can be used dur-ing the development and debugging phase. However, thesetools are integrated mainly using TCL scripts, which needto be parsed whenever an action is taken, making the pro-cess of interacting with the gui a tedious task, even in thetest machine. Unlike QNX, VxWorks uses a host differentfrom target approach. The host and target are two differentmachines linked together by serial, LAN or other bus, forcommunication. A special software called “debug agents”can run in the target system and provide the host with de-bugging information. VxWorks has a Java virtual machineimplementation, is Posix compliant, and has a small numberof applications available.

2.4 WinCEWindows CE is Microsoft’s operating system for embeddedsystems and service oriented computers. It is supported onMIPS, Hitachi SuperH, ARM and Intel x86 architectures.Windows CE is built from a set of discrete modules, eachdivided into components that provide specific functionali-ties. The prime modules are the kernel, the object store, thegraphics subsystem and communications components. Inaddition to these primary modules, other modules are avail-able and provide support for multimedia, COM (Compo-nent Object Model), Windows CE shell and device manager.Like QNX and VxWorks, Windows CE uses processes andthreads and has 256 levels of scheduling priority. The sched-uler only uses round-robin with adjustable time-slices. Thekernel has MMU support, but when this feature is enabled,real time performance is disabled[17]. For interrupt sup-port, all service routines run in a special context that usesits own virtual addresses statically mapped by the OEM.API accessible from within the interrupt service routines isvery limited, much more than in VxWorks, and an optionis given to the OEMs to create a shared memory region bystatically mapping a memory region into the interrupt ser-vice routine address space. Windows CE also has extensivenetwork support and provides a HTTP server with ASP sup-port, a minimalistic version of the Internet Explorer browserand multiple networking protocol support[17].

Windows CE development and deployment tools are forWindows operating system only, but their level of integra-tion is excellent. The main development tool to use is Mi-crosoft Visual Studio, for which many vendors provide plu-gins and extensions for their embedded systems. The num-ber and variety of applications available for windows CE isvery high and includes many applications written for the

Windows operating system that run without modificationin Windows CE. Application developers are not only thirdparty companies but also enthusiasts that need specific func-tions for their embedded system. Also, a minimal version ofthe .Net framework, the .Net compact framework, enablesthe use of the .Net programming language and tools in Win-dows CE.

2.5 SymbianSymbian OS is a closed source proprietary operating sys-tem built exclusively for mobile phones. It is a preemp-tion enabled multitask operating system that uses processes,threads and hardware memory protection. As the result ofa joint venture between several mobile companies, severalinnovative and unusual concepts were implemented in Sym-bian, whose code base was retrieved from Psion’s “Epoc” op-erating system[16], namely, resource descriptors, a cleanupstack operation and Active Objects. These Active Objectsallow linking applications to events and can also be used asa tool to achieve cooperative scheduling[6]. Their use is des-tined to applications that spend most of its execution time inidle state, waking up upon certain events which may trigger,for example, the activation of several hardware resources.This approach allows the kernel to know that those are spe-cial types of system resources thus needing special schedul-ing policies. The kernel then chooses to divert processorcycles to some other more resource hungry tasks that maybe concurrently executing, or even turn off the processortemporarily if no other tasks are executing. Controlling thescheduler indirectly using special types of kernel resources isa unique characteristic unseen in all other solutions reviewedin this paper. Symbian OS is entirely written in C++ andthe development kit (which is available to Symbian part-ners only) has support for Python, Visual Basic and JavaME. The development kit also has a full featured windowingsystem, with its own font server, that allows all graphicalapplications to be integrated using a common framework.Symbian OS is also a direct competitor against WindowsCE in the PDA and smartphone market and, like its com-petitor, it was designed having in mind a limited number ofarchitectures, namely ARM and x86.

Symbian is very criticized because of it’s code base unmea-sured growth since its appearance, with all the differentvendors implementing their custom extensions instead ofcontributing to a more centralized architecture. This re-sulted in an astonishing amount of system and user classes,libraries and functions available, all following their differentapproaches to solve common problems[7]. Poor documenta-tion is also a weak point of the Symbian operating system, afact which, added to the huge size of the system API, makesmany developers think of the development for the SymbianOS as a complex and frustrating task.

2.6 LinuxLinux is a free and open source operating system kernel.There are many distributions based on the Linux kernel.For the installation on the test machine, Debian Linux waschosen. Despite not being a hard real time kernel, Linux’spreemptive scheduler has O(1) complexity which makes itsuitable for some real time applications[5]. Linux’s sched-uler supports task queues, preemption under user and kernelmode and four scheduling classes: Normal (dynamic priori-ties), FIFO, round-robin and Batch. The Linux kernel alsosupports symmetric multi processor architectures withoutloosing any of the capabilities and system calls it has on

single processor machines[9]. The Linux scheduler has vari-ous implementations, each one having unique properties andadvantages under certain situations. This kind of flexibility,customization and resource richness available to the devel-opers made the Linux kernel a popular choice adopted inembedded, desktop and server systems. Since version 2.6,the current major version, a considerable amount of newfeatures and development methodologies made the develop-ment process much more agile and reactive to changes.

Linux supports up to 64GB of RAM in 32 bit architectures(although the hardware limitation of these type of architec-tures is still present: each process can only “see” 2GB) andmore than 1024 GB in 64bit architectures. The page sizeis configurable in compilation time. For interrupts, Linuxsupports SoftIRQs, tasklets, bottom halves, task queues andtimers[28]. One of the reasons for Linux’s growing popular-ity is its wide use in networking applications. Linux hassupport for a superset of all supported network protocolsand drivers seen in the other operating systems that wereanalyzed in this paper. Linux implementation of networkprotocols and drivers are considered secure by many devel-opers and administrators[8], who point at faulty user spacedaemons and applications (not at the kernel) when a Linuxsystem gets compromised[2]. Linux is regarded as a refer-ence in software development, mostly due to the impressiveamount of tools available: all the GNU tools, cross platformemulators, compilers and even proprietary tools for devel-opment for proprietary closed platforms[31]. There is alsoan already big (and continuously growing) number of opensource applications available, dispelling the myth that onecannot find an open source solution for a specific propri-etary application[19]. This growth is also due to severalinvestments in open source technologies by some major ITcompanies and hardware manufactures that keep pushingLinux into the mainstream desktop, server and embeddedmarket.

2.7 RTLinuxLinux has its roots in the desktop systems, but evolved asa general purpose operating system. The need for real timebehaviour was felt after the first successful attempts for de-ployment in embedded systems occurred, in 1999[31]. Fromall the extensions that were implemented to add hard realtime support to the Linux kernel, the most popular is thedual kernel approach. In this approach, the “normal” nonreal time kernel is treated as the lowest priority task of a realtime micro kernel, which handles all real time tasks. Thenew real time kernel, RTLinux, can be compiled as a mod-ule and inserted or removed in execution time, adding ortaking away real time capabilities from the running kernel.Although the dual kernel approach is invisible to applica-tions, the tasks that run in the real time kernel always runin supervisor mode and do not take advantage of the testedand mature memory protection offered by an unmodifiedLinux kernel. Also, each process that runs in the new realtime kernel is no longer a Linux process and must use thenon-standard, Posix based, RTLinux API[11]. The new realtime processes are never swapped out and run in the kerneladdress space, eliminating TLB misses (for those processes).Interrupts in the new kernel have an added flag that indi-cates the need for real time scheduling. Other interrupts areredirected for the non real time Linux task. As for driversand supported protocols, the Linux implementation contin-ues to be non-real time. Only the drivers and protocolsdeveloped for RTLinux have real time behaviour, hence, the

support is much poorer than the one found in the Linuxvanilla kernel.

Installing and configuring RTLinux is not a straight forwardprocess because it involves downloading, manually configu-ration and compilation of the RTLinux module for later in-sertion. This is comparable to the configuration of the Linuxvanilla kernel. Development tools and applications are thesame as the ones available for Linux.

2.8 uClinuxuClinux was initially a port from Linux 2.0.33 to MMU-less architectures. Linux kernel was designed having Intel’s80386 virtual paged memory in mind, which made its useunder processors without an MMU impossible[18]. Whenno MMU is present, the operating system sees the entirememory as a continuous block of readable/writable addressspace. uClinux implements a memory management sys-tem with several policies for incremental memory alloca-tion, avoiding potential fragmentation problems that canarise. Part of the new memory management system includesa “page” implementation in order to maximize compatibil-ity with the existing page oriented vanilla kernel and drivercode. Linux applications must be ported for running un-der uClinux[19]. For C applications, this can be done us-ing the uClibC and its libraries, which play a vital rolein the uClinux distribution. Upon the Linux kernel tran-sition to the 2.6 branch, much of the code under uClinuxwas merged in the vanilla tree, however, both are separateprojects and it is the uClinux team who needs to synchro-nize the uClinux patches for new Linux releases. Currently,a uClinux distribution contains a 2.2, 2.4 and 2.6 uC-kernelbranches, pre-configurations for many hardware vendors andboards, uClibC and a large number of popular applicationswhich are already ported to uClinux. Like RTLinux and theLinux vanilla, configuring a uClinux bootable image is a dif-ficult process. The uClinux configuration system is buggyand gives strange incompatibility and dependency results forcertain option combinations. The kernel capabilities remainbasically the same for interrupt and task management, onlywith some minor details inherent to the target processorused. The major difference resides in the memory manage-ment policy which is implemented using a pool with differentblock allocation policies.

Developing for uClinux can be done using the GNU tools andother 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,shell and shell utilities, among others) the basis for port-ing existing applications from Linux to uClinux can be ex-plained having only two replacements in mind: malloc mustbe replaced by one of the substitutes present in the uClibC(malloc2 or malloc simple) and fork must be replaced by avfork + exec call. For complex applications, these rules aresufficient to render a port impossible to implement withouta major application redesign. For example, replacing mal-loc with one of the two options mentioned can cause a lotof fragmentation, depending of the memory consumptionpattern displayed by the application. As for the fork andvfork+exec approach, a special care should be taken withsome shared and initialized variables whose value will notbe propagated to the child process. This is due to the lackof implementation for the “copy-on-write” process, presentin the vanilla distribution, which makes marking a memoryregion for later copy impossible, forcing the copy operation

to take place immediately[15].

2.9 InfernoInferno operating system is a direct descendent from “Plan 9from Bell Labs”, which aimed to be “what Unix should havebeen” since its birth in 1969[13]. Both operating systems arebased in common Unix premises which were implemented ina more coherent way and can now be applied to all use cases,with no exceptions. Some of these premises are:

• All resources are files and share a global, unique andunambiguous namespace

• All local and remote resources are represented in thefilesystem using an unique and unambiguous names-pace

• All local and remote resources communicate using thesame protocol (called Styx on Inferno OS)

InfernoOS can run on its own, as a native operating sys-tem but also as an application on other platforms, namely,Linux, Windows, FreeBSD, Mac OS X and others. Appli-cations are written in a type safe language, called Limbo,which uses a byte code intermediate representation. Allthese applications can then be executed using just in timecompilation in a virtual machine. Despite being a hybridkernel, the Inferno kernel always runs in supervisor modeproviding memory protection only to the virtual machinelevel, isolating each separate instance from each other.

For this operating system and development kits, resourcesare very low, having only 1MB of ram as its lower limit. Thedevelopment kit consists of the Acme IDE which providesseveral compilers (including one for the C language), unixcommands, a graphical debugger and all Limbo libraries fornetwork access, GUI usage and security protocols (encodingand encryption). Being an open source operating system,all application and kernel source code is provided.

Inferno OS is not very popular in the embedded market, butit is tested and runs in various Intel StrongARM develop-ment boards. The author considers the virtual machine ap-proach and the uniform architecture mentioned above (sin-gle namespace, all resources as files, single message format)to be a good candidate to future embedded applications.Applications could be compiled once and run on any em-bedded (or non embedded) operating system, similar to theJava ME concept, but with tight integration with the oper-ating system.

2.10 eCoseCos stands for embedded, configurable operating system. Itis a real time open source operating system designed for em-bedded systems or systems that only need one process withmultiple threads to fulfill all their tasks. eCos is targetted forsystems with very limited resources (less than 1MB of RAM)that are simply too small to run Linux or uClinux. eCos isalso used as an advanced full featured boot loader, capable ofretrieving other Operating Systems’ images using ethernet,usb or serial connections[10]. Although it is considered aminimal operating system, eCos is extensively configurable.Its kernel has real time behaviour, support for multi-leveland nested interrupts, several scheduling policies, processes,threads, interprocess communication primitives and offersPosix compatibility[14]. eCos hardware support list is veryextensive and includes several ARM, Hitachi, H8, Motorola68000, MIPS and PowerPC processors, along with USB andTCP/IP stack implementations. Development is done us-

ing common open source GNU tools, being very similar todeveloping on a Linux platform.

2.11 ContikiContiki is an open source operating system designed forvery small embedded devices, with little memory resourcesand processing capabilities. Examples of these memory con-strained systems are some 8 bit computers from 1980 (namelythe the Commodore 64) and some microcontrollers. It hasa multitask monolitic kernel, a simple GUI library sufficientfor developing graphic windowed aplications and an imple-mentation for the TCP/IP protocol. To run Contiki withall these features only 30KB of ram are needed. Contiki’skernel is event driven such as the task model citeDunkels-GronvallVoight. Preemption support is configured and en-abled individually in each process that needs this type ofscheduling policy. Its graphical environment can be madeavailable using a VNC virtual display client.

When running, Contiki is divided in two parts: a core andeventually some loaded programs. The core part consists ofthe kernel, a set of base services and shared libraries. Sharedlibraries and other common functionalities are implementedas services, which can be updated or replaced individually,resulting in a very flexible structure. One notable character-istic of this operating system is its memory footprint whichcan be less then 100 bytes.

2.12 Overall Comparison of Selected Solutions

0 1 2 3 4 5

QNX

VxWorks

WinCE

Symbian

Linux

RTLinux

uClinux

Inferno

eCos

ConCki

Figure 2: Overall Solution Scores

The choice of the operating system to use in an embeddedsystem has a vital impact in the overall porting effort. Oneconclusion can be drawn from the analysis done in the pre-vious sections: there is a real need for an open and genericsoftware architecture that can be extended to most, if notall, embedded systems. Besides WinCE and Symbian Os,which were designed having specific hardware arquitecturesin mind (x86 and ARM), all other reviewed solutions sharea common goal: to support as many architectures as pos-sible. Regarding this objective, Inferno operating systemrepresents a major step forward, despite its lack of popular-ity, because it has a truly universal namespace for systemresources and all its applications are deployed using an inter-mediate, machine independent bytecode format. Inferno OSalso has a unique and global format for kernel messages, im-plemented with the goal of simplifying kernel developmentand internal implementation[13]. Of all commercial oper-ating systems analyzed, the one that showed better overallscore was VxWorks (see figure 2). For the free operatingsystems analysed, Linux is clearly the best possible solu-

tion. However, when porting the application for the XTran-3 board, the choices are reduced for uClinux and eCos forhardware support reasons. In fact, uClinux and eCos arethe only operating systems that provide out of the box sup-port for the M5282 processor present in the XTran-3 board.For the open source solutions, a port would be necessary.Since uClinux scored much better than eCos in the evalu-ation done in this paper, and also due to the instability ofthe current M5282 code of the eCos port[21], uClinux is,indeed, the better solution for the XTran-3 board. One al-ternative solution would be to ask for support to one of theproviders for the commercial solutions analyzed. However,the use of a commercial solution is discouraged not onlyfor cost reasons, but also because the benefits of choosing aLinux based alternative are not negligible in the context ofTecmic’s embedded system: vendor independence, less timeto market, large hardware support and the fact that it isan extensively used open source product with many opensource applications available and a large developer and userbase.

3. PORTING UCLINUX TO THE XTRAN-3BOARD

The first step in porting uClinux to any embedded systemis to enumerate all the components of the hardware to port.The most important components are the ones considered tobe vital for the system to boot, even if it will not be fullyfunctional at first (not all drivers loaded or implemented) oreven functional at all (no console shell, for example). Thesevital components are the processor, the RAM memory andthe serial port, or other means necessary for console output.The XTran-3[20] board, for example, is based in a MotorolaColdfire processor (5282), four flash memory modules hold-ing 2 MB each, two ram memory modules of 4MB each, onereal time clock chip and an I2C EEPROM that controlls twoI2C chips. Figure 3 shows how this hardware is connectedin the XTran-3 board.

Motorola ColdFire 5282 Processor

BUS

Flash 1STM29W160

Flash 2STM29W160

Flash 3STM29W160

Flash 4STM29W160

RAM RTC Ds2404 I2C EEpromATC24C128 Serial Port

I2C Slave 1PCF8574

I2C Slave 2PCF8574

Leds Leds

Figure 3: XTran-3 hardware involved in this port

Besides knowing the hardware to port, one must also haveall the necessary software and hardware tools in order tosuccessfuly configure, deploy and boot an uClinux imagefile (containing the kernel and programs that will run) inthe target system. This will be explained in the followingsections.

3.1 uClinux configuration and build systemAll the XTran-3 hardware information must be entered intothe uClinux configuration system. After configured, the

project can be built, resulting in an image file containingthe kernel and user programs (see figure 4). The uClinuxconfiguration system is divided in three steps: vendor selec-tion, kernel configuration and user program configuration.The developer starts the configuration process issuing thecommand “make config” for the text version or “make xcon-fig” for the tcl/tk version under a X Windows environment.The vendor “Tecmic” was created, along with the “XTran-3” product in order to accomodate all the settings in oneplace. This creation process is manual and includes editinga couple of makefiles, configuration files and create a direc-tory structure. Upon the start of the configuration process,existing vendor files and folders are processed and appear asoptions in the product/vendor selection screens.

The 2.6 kernel version was chosen (2.6.19), along with thedesignated processor, ram size, interrupt vector location andsize, supported filesystems, console driver and the kernel ini-tialization parameters. The image file has a structure similarto the one in figure 4 and must be copied to the target boardram. The copy operation was done in different ways duringdevelopment. Due to the absence of an ethernet chip in theXTran-3 board (although the slot was there, the prototypeused in this work did not have it mounted), the serial portwas used initially to transfer the image file. A modificationto the Tecmic firmware was implemented in order to trans-fer the image files using the serial port and then jump tothe first address of kernel executable code. This proved tobe a very slow process, not only because of the record for-mat used (Motorola S3 records) which increased the totalamount of bytes to transfer, but also apparently to a hard-ware limitation in the XTran-3 board, which resulted in datacorruption for transfer speeds greater then 19200 bps underhardware and software flow control. After the initial proofof concept builds were working, Tecmic made a BDM portavailable to this project, which was immediately put to gooduse, resulting in transfer speed gains from 45 to 3 minutes.

System Vectors

Image (Kernel and romfs) Partition 1

Figure 4: XTran-3 Image memory layout in XTran-3ram

3.2 Bootloading to uClinuxAlthough very complex and self contained, the kernel code isunable to boot by itself, requiring several resources to be al-ready initialized by a special component that runs before thekernel: the boot loader. For the XTran-3 board, the Tecmictest application was used as the boot loader. Upon transferof the image to the board RAM memory, the boot loaderwas initialized by manually pressing the board reset button.Booting to uClinux is a new option implemented during de-velopment of the porting operation that simply changes theprocessor’s program counter register to the initial addressof the kernel executable code. In the XTran-3 architecture,this is enough for the Linux initialization output to startappearing in the output console. Besides proper console ini-tialization in the uClinux kernel which, when enabled byappending the correct boot parameters, allowed to see whatwas happening during the boot phase, one of the initial prob-lems faced and solved was a compulsive hardware reset trig-gered by the board’s watchdog. This happened because one

of the kernel’s first task is to rewrite every interrupt vectoraddresses to be able to handle all system interrupts and thisincluded the watchdog kicking routine. In the absence ofwatchdog kicks, a software reset was immediately triggeredby the watchdog and caused the processor to return to theboot loader execution. To solve this problem, the watchdoginitialization code was changed in Tecmic’s boot loader inorder to disable it, causing the Linux kernel to boot, say itsmotd and present the long awaited console to the user. Get-ting the kernel to successfully boot in the Xtran-3 board wasa very difficult task and took half of the porting effort totaltime. The difficulty resides in the absence of console output(until proper initialization of the console) and the configura-tion of kernel options (scheduler, addresses for code locationand ram disk size) in order to get a minimal, but functionalsystem.

3.3 Real Time Clock driverThe first device ported to uClinux was the real time clockchip present in the XTran-3 board. This device is a Dallasds2404 which is currently not supported by the Linux ker-nel. The closest match to what is already implemented forthat vendor in the Linux kernel, and probably would actu-ally work, is the Dallas 1 wire bus driver. However, sincethe current Tecmic design is connected to the processor us-ing the 3-wire pins, the current implementation does not fitthe porting purposes. Since this device serves a specific pur-pose which is very frequent in embedded and non-embeddedsystems, there is a specific class for real time clocks in theLinux kernel. For proper development of this type of de-vices, one must implement a specific API for accessing thedevice and the kernel does the rest from there on.

The DS2404 device exposes its functionality using severalmemory pages. In these pages, among other information,the current Unix time is stored. For reading and writing adetermined amount of bytes from one of the available pages,one must use the scratch pad, which acts as intermediatebuffer for each byte to read or write (total capacity of thescratch buffer is 256 bits). There are 16 pages of 256 non-volatile bits each. The current alarm and time values can befound in the address 0x0200h[4]. The device only supportsthree different operations which, when called using differentarguments, provide full control of the device. These opera-tions are:

• Copy the contents of an address range from a page tothe scratch buffer

• Copy the contents of the scratch buffer to a page

• Read the scratch buffer

Reading the current time, for example, involves initializingthe device with the address being read, then ask for a copyoperation from the contents of the previously given addressto the scratch buffer and then read the scratch buffer[4].Data is sent bit by bit using the GPIO interface of the Mo-torola Codfire 5282 processor.

Thanks to the RTC class, it was possible to initialize this de-vice as the default device for time retrieval, which means thekernel, upon initialization, will initialize its internal clock(that does not need any device and uses the processor’s pre-scaler for counting time) with the current time read fromthe ds2404 device. Also, using the proc API, a characternode was created in the /proc filesystem to show the devicestatus:

# cat /proc/driver/rtc

rtc_time : 20:28:05

rtc_date : 2005-02-18

alrm_time : 17:10:47

alrm_date : 1973-10-08

alrm_wakeup : no

alrm_pending : no

24hr : yes

id : 0

#

Upon loading, the new ds2404 module generates a characterdevice node called /dev/rtc0 which can be accessed by anyapplication that was designed to use the Linux kernel rtcAPI. Examples of these programs are hwclock and date, usedto test this module’s funcionalities.

3.4 Flash Mapping driverThe XTran-3 board has four NOR flash modules of 2 MBeach, directly available through its addressing space. Sup-port for flash memory devices has a special implementationin the Linux kernel[30], as demonstrated in figure 5.

User Level

Logic Level

Hardware Level

mkdosfs mkjffs mkjffs2

Char Access Block Access

FTL NFTL JFFS 1 / 2

Disk On Chip System Memory Kernel RAM

Device Driver Jedec CFI

Mapping Driver Physmap Octagon

Figure 5: XTran-3 Memory Technology Devices im-plementation in Linux

Starting from the lowest layer, closer to the hardware, thereare two command sets implemented in the Linux kernel forcommunicating with the flash memory hardware: CFI andJedec. CFI is desirable because it is supposed to be anevolution of the older Jedec and defines a common methodfor reading each chip’s topology and other manufacturingdata. All four flash chips are siblings from the same model:M29W160DB from ST. After several attempts at using CFIto correctly auto detect each chip, the only way to makethe kernel recognize this device was to patch the brokenjedec probe.c file in the kernel code. The final working con-figuration for successful detection and communication withthe four chips consisted in using Jedec code for the detec-tion and a CFI command set from AMD for communicatingwith the device. The next layer is the mapping layer, andit allows the kernel to address the device using a specificrange of memory addresses. This was achieved by configu-rating the physmap module, however, given the interleaveddistribution of each chip’s address range in the system mem-ory and the current implementation of the physmap mod-ule, physmap was “tricked” into handling everything as if

there was only one device. With physmap, only one of thefour modules worked correctly, hence, a new module wasimplemented to map each device individually. Each modulehandles partitions and partition sizes in a similar way thephysmap module does, so each chip can be partitioned usinguserspace utilities or at boot time using the kernel commandline. If one would want to partition one of the ST flash chipsin three partitions, p0, p1 and p2, the first with 1024 KB,the second with 512 KB and the third with 512 KB, thefollowing line should be added to the kernel boot command:

xt3map-flash1.0:1024k(p0),512k(p1),512k(p2)

With the mapping modules loaded, each device is accessi-ble for reading and writing using two filesystem nodes, acharacter device, for passing specific flash commands, anda block device for transferring binary data. However, thiskind of access alone is not desirable because it is not pos-sible to create files using the filesystem utilities. Currently,there are two different layers to link the mapping layer tothe normal filesystem layer. The first one is with the FTLmodule (flash translation layer). This module creates an ad-ditional block node for each pair of device nodes created bythe mapping layer. With the new block node, one can usethe normal filesystem utilities (mkdosfs, mkext2fs, touch,cp, mkdir, etc) to create and work with the newly createdfilesystem. The FTL implementation in Linux is very sim-ple, but does what it is supposed to: it maps and handlesflash blocks as if they were normal byte blocks. However,this approach is a naive one because it does not optimize theuse and weariness of each block. Flash memory has a limitednumber of writes before each block gets worn out, so a cru-cial factor for extending the lifetime of this type of memoryis to distribute the write operations across as many differentblocks as possible, without loosing filesystem integrity. It ispossible, using FTL, to mount a FAT filesystem in a flashchip, but the blocks will wear out quickly because FAT, bydesign, uses a specific region of the physical device to storethe file allocation table1. In the uClinux version used inthis work (20070130), the FTL module compiled, but doesa kernel panic upon loading. All known good configurationsfor this module use the previous major kernel version (2.4)and even with some debugging and questions posed to theuClinux mailing list, no fix for this problem was found.

However, there are other better options for implementingthis layer. One of those options is the use of a filesystem thatwas designed to work with flash devices[30]. For this work,JFFS2 was chosen. JFFS2 stands for Journalling Flash FileSystem and is a log-structured file system for use with NORor NAND flash memory devices. Besides the wear levelingcapabilities, two of the most notable characteristics of theJFFS2 filesystem are the use of compression (using zlib, ru-bin or rtime algorithms) and a garbage collection algorithmto reduce overall fragmentation[30]. The JFFS2 filesystemis available as an option in the Linux kernel, and was suc-cessfully used in the XTran-3 board, providing seamless fileaccess to the four flash chips and enabling the use of direc-tories, files, soft and hard links and access to the device asif it was a normal block device. This is a great improvementover the previous Tecmic software implementation, whichused the chip blocks directly to read and write chunks of

1This type of mapping is what the typical USB pen drivesdo by hardware. The quality and durability of each device,among other factors, is dependent of the hardware imple-mentation of their internal FTL algorithms.

bytes.

3.5 LED driverThe XTran-3 board has a set of 13 general purpose LEDs.One of them is directly connected to the processor, theother 12 are divided in two groups, one with 8 and theother with 4 LEDs. Each group is connected to an I2Ccontroller, model PCF8574SO16, but these controllers arenot manipulated directly by the processor. Instead, Tecmicsimplified the task of having to implement a driver in itscustom software and added a master I2C controller EEP-ROM. The master controller is directly connected to theprocessor and the other two controllers are connected to themaster (see figure 3). To control each LED, one must writean address/value pair in the EEPROM address and, uponentering the execution command, the data is sent across theI2C bus, causing the LED to update its state. The codeto write to the EEPROM was heavily inspired in Tecmic’simplementation, and it was integrated in the Linux kernelusing a standard character device[12]. The data is enteredin the form LED number=state flag. For instance, 3=1means: “lit LED 3”. Changing several states at once is pos-sible using the : character to separate several commands:“4=0:5=1” means turn off LED 4, lit up LED 5. The devicedriver copies the data from userspace and sends commandsto the EEPROM. Like in the ds2404 driver, several appli-cations can read or write to the file at once because all thecritical regions are protected by a spinlock. An example us-age of the implemented driver can be done using only thefollowing shell command:

# echo "3=1:4=1:5=1:10=0" > /dev/xtranleds

The critical region, protected by the spinlock, consists inchanging the state of a single LED because once the writeprotocol begins, it cannot be interrupted, otherwise, the de-vice would eventually enter an incoherent state and becomeunusable.

3.6 ds2404help applicationAlthough date and hwclock are sufficient to control the rtcclock, there is an additional operation that was not sup-ported by any of the two programs. This operation sets thecurrent alarm date and time in the RTC clock. In the typ-ical PC, it is only used by the motherboard chipset driverfor triggering wake on alarm events. For setting the clockand alarm time and date, an application was written: theds2404help. Despite its name, it works with any rtc driverbecause it uses the ioctl interface, whose entry points areimplemented by the rtc driver, to ask for specific rtc data.The implemented syntax allows one to set the alarm and/orthe time with one simple command:

# ds2404help -a 02/07/1981:21:48:00 -d 02/07/1981:

21:48:00

3.7 ledshow applicationThe Xtran LED driver implemented in this port allows di-rect manipulation of each LED state, but changing severalLEDs at the same time can be bothersome and requiresthe programmer to know which LED number is assignedto which position in the XTran-3 board panel. To simplifythe process of bulk state writes to all LEDs, the ledshowapplication was written. It receives a filename passed as ar-gument and processes it, changing the LED state according

to the information in the file. The file is a simple text fileand contains a sequence of numbers and LED states whosespatial disposition in the text file is the same as in the LEDpanel. An example file would be:

10

000000

000000

40

111111

111111

20

The first number is the number of times the sequence willrepeat. The next two rows provide a spatial representationof all the 12 LED states, 1 means on and 0 means off. Thenumber next to the two rows indicates the previous stateduration in milliseconds. In this case, the LEDs will remaincompletely off for 40 milliseconds. Next in the file one canhave as many states and durations as desired. In the givenexample, all LEDs are turned off and then lit for 40 and10 milliseconds respectively. This sequence is repeated 10times as specified by the first number in the beginning ofthe file.

3.8 Updating the configuration scriptsBesides all the C code files containing the implementationfor each driver, several updates to existing configuration files(Kconfig files) had to be done so that the new drivers couldappear in the configuration screens and be selectable whenthe M5282 architecture was chosen. Also, several Makefileshad to be changed to enable inclusion of the new kernelobject files into the image file.

Userspace programs have a similar method for inclusion inthe configuration screens. There is one Makefile for eachprogram and, by defining actions for well known targets, thecompilation script can invoke those pre defined targets andgenerate the executables for inclusion in the romfs image.

4. EVALUATIONIn order to accurately access the system’s performance, arigorous program-based evaluation had to be carried out.Such procedure helped perceiving how the ported systemcompares to other embedded systems based in uClinux (withsimilar hardware) and to the proprietary in-house solutionfrom Tecmic.

4.1 Experimental SetupAfter all implementations described in the previous section,the ported system was put to test. The test environmentconsisted in an uClinux image containing all the programsused during development, plus the test tools. All the toolsused or implemented have the capability of showing the testresults in the output console immediately before the end ofits execution, allowing the data to be extracted for furtheranalysis. All the kernel modules developed were loaded inthe kernel, but no processes were running in the systembesides each test executable file.

4.2 lmbench ToolThe lmbench tool is a widely used test tool for Linux sys-tems[23], providing an extensive amount of programs to testcertain aspects of the operating system. By using the lm-bench tool, one has a common base for comparison with

results obtained in other architectures and execution en-vironments. The lmbench site provides many benchmarkresults on popular desktop and server environments.

Lmbench version 3 was used in the tests, but since the vanillaversion of this tool only compiles under libc, a ported versionfor uClibC was checked out from the Blackfin Linux projectrepository and incorporated as an additional program forthe customized uClinux distribution produced in this work.Three benchmarks were chosen to run for their significance:lat proc, lat syscall and lat ctx, however, lat ctx is the mostimportant test because it is widely used for measuring theuClinux performance on several embedded systems.

lat syscall Measures the amount of time necessary to writea byte in the special node /dev/null. Although it isa very simple test, the result value presents the lowerlimit of the amount of time necessary to interact withthe kernel from user space. The results can be usefulfor comparing the ported system with other versionsof uClinux.

lat proc Measures the amount of time necessary to createand start a new process. This test was executed in twodifferent modes: the vfork + exit and vfork + execve.Vfork + exit measures the amount of time necessaryto create a child process similar to the parent process.Vfork + execve measures the amount of time necessaryto create a child process similar to the parent processand start the execution of the child process.

lat ctx Measures the amount of time necessary for the ker-nel to make a context switch between a variable num-ber of processes. During the execution of these tests,several processes are created with two pipes, each con-necting the previous one to the next, making a ring.Each process reads data from the entry pipe, performsa variable amount os calculations (sum the values inthe array) and sends the result to the next pipe. Thesetests are compared with the test results obtained bySamsung using one of its boards, the S3C24A0. ThisSamsung board contains an ARM processor, model926ej running at 200MHz. The kernel version used bySamsung is older than the one used in this work, hence,due to improvements constantly being implemented inthe Linux and uClinux kernel, some variations are tobe expected.

4.3 Custom Console Test ToolLmbench runs in every Linux environment, but does notrun in Tecmic’s proprietary software solution deployed inthe XTran-3. To compare the old system and the portedsystem, a simple test program was written. It measuresthe time necessary to transfer a specified amount of char-acters from the console to the kernel and back to the con-sole. Tecmic’s firmware was once again changed to performthis task and present the obtained results using the console.As for the ported system, an userspace program was im-plemented, using the uClibC API, using simple printf andscanf functions[3]. The pseudocode for this test is the samefor both implementations:

begin

waitForFirstCharacter();

counterStart = getTimeOfDay();

do{

char = receiveChar();

print(char);

} while (char != CHAR_END);

counterEnd = getTimeOfDay();

print("Time spent: %d", counterEnd - counterStart);

end

Note that it is expected that the ported system will havefar worse results than Tecmic’s firmware. This is becauseTecmic’s firmware is a realtime system and this code willrun in exclusive mode (there is no task scheduling and/orcontext switching). In Linux, the program will be run fromuser space and use the uClibC functions to access the con-sole, which will in turn do a predefined system call that willtrigger the console driver to place the results in a buffer.

4.4 Evaluation ResultsFigure 6 shows that the uClinux 2.6.19 scheduler does notget affected by a large number of processes in the system.The context switching time remains steady, which can beexplained by the absence of the MMU and the improvementsimplemented in the kernel scheduler since version 2.6.19.Note that for each buffer size, which varies from 0, 1 or 16KB, there is an observed time interval, corresponding to theamount of time necessary to calculate the array values’ sum.This factor is the “ovr” value showed by the lat ctx output.

0.00100.00200.00300.00

2 4 6 8 10 12 14 16

Time(µs)

NumberofProcesses

2.6.19‐uc1XTran‐3

0KB,209.96us

1KB,258.70us

16KB,910,17us

Figure 6: lmbench lat ctx results in the XTran-3board (kernel version 2.6.19-uc1)

In figure 7, the comparison results for a specific lat ctx testare shown. The test was performed setting the array sizeto 16KB and making variations to the number of processes.The ported system is 2.3 times faster at context switchingthen the 2.6.11 version of uClinux running in a faster proces-sor. This is also explained by the differences in the schedulerand the architecture used. Note the context switching timein uClinux is always faster than Linux even under similarhardware, however, there is a large “ovr” factor differencethat, despite not being shown in the results, is directly ob-servable in the system, making the test actually run slowerin the ported system versus the Samsung board. This is dueto the fact that the ARM processor has a higher clock fre-quency (200 MHz vs 66.6 MHz) and is generally much fasterdoing ALU calculations[22] than the Motorola Coldfire 5282.

Figure 8 shows the console test results. Surprisingly, theported system is faster than Tecmic implementation, at leastfor serial port transfers. Since the code being tested hereconsists of the serial driver implementations of Tecmic anduClinux, the test shows that the Linux kernel implementa-tion of the MCF serial driver has better performance thanTecmic’s code.

5. CONCLUSIONS AND FUTURE WORKIn this paper, a successful port of uClinux to a propri-etary embedded system is presented. Also, a qualitative

0.00

50.00

100.00

150.00

200.00

250.00

300.00

350.00

2 4 6 8 10 12 14 16

Time(µs)

NumberofProcesses

Size=16KB

2.6.19‐uc1

2.6.11.6‐uc1

2.6.11.6

2.4.20‐mvista

Figure 7: lmbench lat ctx result comparison

0.000

10.000

20.000

30.000

40.000

50.000

300 900 3600

Time(m

s)

Numberofbytestotransfer

SerialPortTransfer

uClinux

FirmwareTecmic

Figure 8: Serial console test results

analysis to several free and commercial embedded operat-ing systems is done. From all solutions reviewed, uClinuxproved to be the best choice for the XTran-3 hardware, acustom embedded system designed by Tecmic and used inthis work. Choosing the right Linux solution and kerneldepends mainly on system requirements and hardware lim-itations: real time solutions require RTLinux, no-MMU ar-chitectures require uClinux and Linux can be used on allothers. One can conclude that in order to gain a realisticperception of each solution’s strong and weak points, an ex-perimental approach is necessary. This practical approachcan go from the simple installation of each solution on adevelopment machine, to real deployment attempts on thetarget embedded system.

Developing for uClinux requires the right tools for buildingeach architecture’s specific code and the environment setupis not tightly integrated or even user friendly, contrary towhat happens with all the commercial solutions analysed.uClinux build system is clearly one of the distribution’s weakpoints since several fixes to the configuration scripts and ker-nel files had to be implemented in order for the system imageto be built correctly. Deploying and running the uClinux im-age required additional effort because porting uClinux to theXTran-3 board also implied a port of the XTran-3 firmwareto run uClinux. This apparently “backwards” task had tobe carried out because the uClinux kernel is not capable ofbooting by itself and needs a bootloader to initialize part ofthe hardware. In this work, Tecmic’s firmware was modifiedto serve uClinux’s boot loader needs. After proper setup anddeployment of the uClinux distribution, the device driversand application implementations took place. After the de-velopment was concluded, several tests were also performed,

including benchmarks with a common Linux benchmarkingtool: lmbench3. By planning and defining these portingtasks for each project, a “porting road map to Linux” canbe obtained and its accomplishment is considered vital toachieve a functional and mature Linux port for an embed-ded system.

The proposed solution implemented the drivers for the RTCclock, the mapping driver for the four flash chips and theLED driver. Two applications were also developed to exper-iment with the new drivers, but both can work with otherhardware because the generic kernel API was used. Withthe uClinux port, the system now provides all Linux bene-fits: user space programming using the libc, task scheduler,processes, synchronization functionalities, proper filesystemsupport and a multitude of advancements which were impos-sible in the original system, or required a substantial amountof investment to be implemented. Despite the successfulport in functional terms, several measurements of the systemperformance were taken using a widely used tool for bench-marking: lmbench3. The preliminary results were promis-ing. The new system performs better at context switchingthan an ARM based solution using an older 2.6 kernel, evenwith the differences in clock speed which clearly gave theARM an advantage. Other reason for this performance im-provement is the advancements that get implemented in theLinux kernel in each release. As for the performance com-parison from the old versus the ported system, the portedsystem showed gains when performing a data transfer usingthe serial port. Although this benchmark was developed us-ing a similar algorithm for both systems, since the uClinuximplementation run in user space and used libc, a strongernegative performance impact was expected. This did nothappen in the benchmarks run, probably due to the moreelaborate implementation of the Coldfire serial port driverimplementation in uClinux, compared to Tecmic’s customimplementation. In conclusion, uClinux was ported suc-cessfully to run in the XTran-3 board without affecting thesystem performance, in fact, it actually improved it undercertain situations (serial port data transfer).

As to future work, the author concludes that porting the re-maining board hardware and applications would give Tecmica colossal advancement over the previous system. Thanks tothe use of libc, future application compatibility is assured.There is now a multitude of applications already includedin uClinux, ready to provide advanced network and evenmultimedia capabilities. Also, much more benefits couldbe obtained from a Linux port if the target processor hadan MMU. The existing ported applications would work outof the box, and, depending on the processor choice, minoror no modifications to the new drivers would be necessary.The author suggests the migration to a processor with aMMU from Motorola. A good example is the Motorola5745 because it also operates in no-MMU mode, maximiz-ing compatibility with the current uClinux port. The newport would also require a heavy amount of business logic re-gression tests in order to assure full compatibility with theentire XTran architecture.

6. REFERENCES[1] Thiemo Voigt Adam Dunkels, Bjrn Grnvall. Contiki -

a lightweight and flexible operating system for tinynetworked sensors. NOV 2007.

[2] Jorge Kurtz Brian Hatch, James Lee. Hacking LinuxExposed. McGraw-Hill, second edition, 2008.

[3] Dennis M. Ritchie Brian W. Kerningham. The CProgramming Language. Prentice Hall, second edition,1988.

[4] Maxim Integrated Circuits. Ds 2404 econoram timechip. DEZ 2000.

[5] Marco Cesati Daniel P. Bovet. Understanding theLinux Kernel. O’Reilly, first edition, 2000.

[6] Aapo Haapanen. Active objects in symbian os. APR2008.

[7] Hrissan. Symbian os design faults. JAN 2005.

[8] Keith W. Ross James F. Kurose. ComputerNetworking, a Top-Down Approach Featuring theInternet. Prentice Hall, third edition, 2005.

[9] Alessandro Rubini Jonathan Corbet and GregKroah-Hartman. Linux Device Drivers. O’Reilly, thirdedition, 2005.

[10] Jonathan Larmour. How ecos can be shrunk to fit.MAY 2005.

[11] C. Douglass Locke. Posix and linux applicationcompatibility design rules. NOV 2005.

[12] Robert Love. Linux Kernel Development. SamsPublishing, first edition, 2005.

[13] Howard Trickey Martin Atkins, Rob Pike. The InfernoProgramming Book: An Introduction to Programmingfor the Inferno Distributed System. Vita Nuova, firstedition, 2005.

[14] Antony J. Massa. Embedded Software Developmentwith eCos. Prentice Hall, first edition, 2004.

[15] Paul E. McKenney. Read-copy-update: Usingexecution 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. MAY2006.

[21] David Shorthouse. eCos Supported Hardware.eCosCentric,http://ecos.sourceware.org/hardware.html, 2008.Accessed 2 July, 2008.

[22] ARM Embedded Solutions. Arm productbackgrounder. 2005.

[23] Carl Staelin. lmbench3: measuring scalability. NOV2002.

[24] QNX Software Systems. Welcome to qnx momentics.2004.

[25] QNX Software Systems. QNX Neutrino SystemArchitecture. QNX Software Systems InternationalCorporation, sixth edition, 2006.

[26] Andrew S. Tanenbaum. Modern Operating Systems.Prentice Hall, second edition, 1993.

[27] Christof Wehner. Tornado and VxWorks What’s notin 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 ComputingSystem Design. Morgan Kaufmann Publications, firstedition, 2001.

[30] David Woodhouse. Jffs : The journalling flash filesystem. 1999.

[31] Karim Yaghmour. Building Embedded Linux Systems.O’Reilly, first edition, 2003.