Porting RTOS Device Drivers to Embedded Linux

Linux has taken the embedded marketplace by storm. According to industry analysts, one-third to one-half of new embedded 32- and 64-bit designs employ Linux. Embedded Linux already dominates multiple application spaces, including SOHO networking and imaging/multifunction peripherals, and it now is making vast strides in storage (NAS/SAN), digital home entertainment (HDTV/PVR/DVR/STB) and handheld/wireless, especially in digital mobile phones.

New embedded Linux applications do not spring, Minerva-like, from the heads of developers; a majority of projects must accommodate thousands, even millions of lines of legacy source code. Although hundreds of embedded projects have successfully ported existing code from such platforms as Wind River’s VxWorks and pSOS, VRTX, Nucleus and other RTOSes to Linux, the exercise is still nontrivial.

To date, the majority of literature on migration from legacy RTOS applications to embedded Linux has focused on RTOS APIs, tasking and scheduling models and how they map to Linux user-space equivalents. Equally important in the I/O-intensive sphere of embedded programming is porting RTOS application hardware interface code to the more formal Linux device driver model.

This article surveys several common approaches to memory-mapped I/O frequently found in legacy embedded applications. These range from ad hoc use of interrupt service routines (ISRs) and user-thread hardware access to the semi-formal driver models found in some RTOS repertoires. It also presents heuristics and methodologies for transforming RTOS code into well-formed Linux device drivers. In particular, the article focuses on memory mapping in RTOS code vs. Linux, porting queue-based I/O schemes and redefining RTOS I/O for native Linux drivers and dæmons.

Links:  http://www.linuxjournal.com/node/7355/print

A survey of Linux device drivers

In Linux, a device driver is code that implements a userspace or kernelspace abstraction of a physical device. Examples of device drivers include code that allows user applications to stream data through a 16550 UART, code that configures an Epson S1D13xxx LCD controller chip, and code manages the AT91RM9200’s built-in Ethernet controller.

Device drivers come in several different types, depending on what abstraction they provide. Serial port drivers, for example, often implement the character device type. The framebuffer driver type is normally used to enable userspace applications to write to an LCD or CRT display. Ethernet drivers allow the Linux kernel’s TCP/IP protocol stack to send packets over an Ethernet network.

A device driver abstraction is purely that, an abstraction. The underlying hardware associated with an Ethernet device driver may not actually be an Ethernet controller, for example; there may not even be any physical hardware at all! Such is the case for the usbnet driver, which allows a USB Device to communicate with a USB Host as though the two were connected via Ethernet. (The usbnet driver packages Ethernet packets and forwards them to the USB host/device drivers for transmission)

Links:  http://www.embedded.com/columns/technicalinsights/187200956?cid=RSSfeed_embedded_news&_requestid=621630

Device Drivers in Linux

“Do you pine for the nice days of Minix-1.1, when men were men and wrote their own device drivers?” Linus Torvalds 

Pre-requisites

In order to develop Linux device drivers, it is necessary to have an understanding of the following:

C programming.
Some in-depth knowledge of C programming is needed, like pointer usage, bit manipulating functions, etc.
Microprocessor programming.

It is necessary to know how microcomputers work internally: memory addressing, interrupts, etc. All of these concepts should be familiar to an assembler programmer.

There are several different devices in Linux.

 Links: http://www.freesoftwaremagazine.com/articles/drivers_linux