Porting RTOS Device Drivers to Embedded Linux

Transform your wild-and-woolly legacy RTOS code into well-formed Linux device drivers.
Porting Approaches

Porting RTOS code to embedded Linux does not differ conceptually from enterprise application migration. After the logistics of porting have been addressed (make/build scripts and methods, compiler compatibility, location of include files and so on), code-level porting challenges turn on the issues of application architecture and API usage.

For the purposes of the discussion at hand, let us assume that the application part (everything except I/O-specific code) migrates from the RTOS-based system into a single Linux process. RTOS tasks map to Linux threads and intertask IPCs map to Linux inter-process and inter-thread equivalents.

Figure 2. Mapping RTOS Tasks to Linux Process-Based Threads

Although the basic shape of the port is easy to understand, the devil is in the details. And the most salient details are the RTOS APIs in use and how to accommodate them with Linux constructs.

If your project is not time-constrained, and if your goal is to produce portable code for future project iterations, then you want to spend some time analyzing the current structure of your RTOS application and how/if it fits into the Linux paradigm. For RTOS application code, you want to consider the viability of one-to-one mapping of RTOS tasks onto Linux process-based threads and whether to repartition the RTOS application into multiple Linux processes. Depending on that decision, you should review the RTOS IPCs in use to determine proper intra-process vs. inter-process scope.

On the driver level, you definitely want to convert any informal in-line RTOS code to proper drivers. If your legacy application already is well partitioned, either using RTOS I/O APIs or at least segregated into a distinct layer, your task becomes much easier. If ad hoc I/O code is sprinkled liberally throughout your legacy code base, you've got your work cut out for you.

Developers in a hurry to move off a legacy RTOS or those trying to glue together a prototype are more likely to attempt to map or convert as many RTOS APIs to Linux equivalents in situ. Entities in common, such as comparable APIs, IPCs and system data types, port nearly transparently. Others can be addressed with #define redefinition and macros. Those remaining need to be recoded, ideally as part of an abstraction layer.

You can get a head start on API-based porting by using emulation libraries that accompany many embedded Linux distributions (including MontaVista's libraries for Wind River VxWorks and pSOS) or by using third-party API-mapping packages from companies such as MapuSoft.

Figure 3. Multipronged Approach to Porting RTOS Code and APIs to Linux

Most projects take a hybrid approach, mapping all comparable or easily translatable APIs, re-architecting where it doesn't slow things down and playing Whack-a-Mole with the remaining code until it builds and runs.

Available APIs in Kernel and User Space

For both intensive re-architecting and for quicker-and-dirtier API approaches, you still have to (re)partition your RTOS application and I/O code to fit the Linux kernel and user-space paradigm. Table 1 illustrates how Linux is much stricter about privileged operations than a legacy RTOS and helps guide you in the (re)partitioning process.

Table 1. Privileged Operations in Linux and Legacy RTOSes

RTOS ApplicationQueues, Signals, Mailboxes Informal Shared MemorySemaphores, MutexesFull RTOS Tasking RepertoireFull Application, Libraries and System (Link-Time)
RTOS DriverQueues, Signals, Mailboxes Informal Shared MemorySemaphores, MutexesFull RTOS Tasking RepertoireFull Application, Libraries and System (Link-Time)
Linux ApplicationQueues, Signals, Pipes Intra-Process Shared Memory Shared System MemorySemaphores, MutexesProcess and Threads APIs Local Process, Static and Shared Libraries
Linux Driver (Static)Shared System Memory Read/Write Process MemoryKernel Semaphores SpinlocksKernel Threads, TaskletsFull Kernel
Linux Module (Dynamic)Shared System Memory Read/Write Process MemoryKernel Semaphores SpinlocksKernel Threads, TaskletsModule-Local and Exported Kernel Symbols

Two important distinctions are called out in Table 1:

  • RTOSes are egalitarian, letting application and I/O code touch any address and perform almost any activity, whereas Linux is much more hierarchical and restrictive.

  • Legacy RTOS code can see every symbol or entry point in the system, at least at link time, whereas Linux user code is isolated from and built separately from kernel code and its accompanying namespace.

The consequences of the Linux hierarchy of privileged access is normally only kernel code (drivers) actually accesses physical memory. User code that also does so must run as root.

In general, user-space code is isolated from the Linux kernel and can see only explicitly exported symbols as they appear in /proc/ksyms. Moreover, visible system calls to the kernel are not invoked directly but by calls to user library code. This segregation is intentional, enhancing stability and security in Linux.

When you write a driver, the opposite is true. Statically linked drivers are privy to the entire kernel namespace, not only exports, but have zero visibility into user-space process-based symbols and entry points. And, when you encapsulate driver code in run-time loadable modules, your program can leverage only those interfaces explicitly exported in the kernel by the *EXPORT_SYMBOL* macro.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

As the author and a few

Moshe's picture

As the author and a few commenters rightfully noted you can go the easy path by mapping all VxWorks tasks to Linux user mode processes/threads. The downside is that the performance hit can be huge (see above comment about mmap overhead).

Fortunately, it looks like now there is a solution - www.femtolinux.com allows to run user processes in kernel mode, removing the user/kernel barrier. FemtoLinux processes are pretty much identical to VxWorks tasks.

Been on both sides of this

Baumann's picture

15 years as a VxWorks developer, now doing the linux side of the game. 99% of the time, the "real driver" approach is the preferred one - you get protection, etc. (I've ported almost all of my old VxWorks drivers to Linux that way) but there is the odd case - and I'm dealing with one now, where mmap() may buy you the realtime response you need - where even the interrupts are too slow.
(porting from linux to VxWorks is the easy direction - you're going from protected to unprotected,life is easy, aside from a few calls that aren't allowed.)
My catch at the moment though - on the architecture that I'm working with, is that the mmap call is expensive - more than you might think. Each access, by the time it has rolled up and unrolled the various page tables, is appearing to take 700ns - dropping memory bandwidth to less than 14MB/Sec. And that bytes. Pun intended.
Like everything, you've got to evaluate what you're doing, and why

migration kit for linux to vxworks - availablility !!

karthik bala guru's picture

Hi all,
VxWorks-to-Linux migration kits are offered by a number of companies, including MapuSoft, LynuxWorks, MontaVista, and TimeSys.

But, y is there no such thing like,
Linux-to-VxWorks Migration Kits ????

What is the difficulty in providing such a migration kit ?
where is the problem actually ?

if there is a linux-to-vxworks migration kit available in any website or shop, do kindly let me know.

thanks and regards,
karthik bala guru

migrating a protocol from linux to vxworks - availablility !!

karthik bala guru's picture

actually, i am porting a protocol stack developed in arm-linux into vxworks.

do let me know if there is any migration kit for this.

karthik bala guru

How to implement mmap() in vxWorks?

Anonymous's picture

Does anybody know how to use linux mmap() like function in vxWorks?
Please info me!


Vijaykc's picture

Why would you want mmap()in Vxworks? The entire memory space is yours..... :)
I am not quite sure why you need one the first place.