Embedded PCI and Linux

A major prerequisite for selection of an OS is a wide range of support for hardware platforms and peripheral components. In order to establish dimmPCI as an open standard, it is necessary to have full software support for as many devices as possible. Thus, migrating an application to the dimmPCI architecture mainly would involve a hardware form-factor change, with only minimal changes to the hardware design and application software. Device-driver design is one of the most substantial costs during software development. A large support base for peripheral devices and components, such as network interfaces, RAM, ROM, serial communications and displays, is essential for cost savings during the development phase. Again, Linux surfaces as the option that is most suitable, especially since the supported knowledge base includes source code.

Performance was considered during our OS selection process. Linux is a multitasking operating system and provides a rich application development environment. Many practical embedded applications can be developed within this operating system environment, and our immediate application needs were satisfied. We have found that with properly written drivers, one can respond to hard real-time interrupts without having to preempt the kernel. For most of our applications, this is sufficient--especially given that the gcc tools compile C code into efficient code, and embedded assembly code can be written if response times are critical.

We have, from time to time in the past, required a more deterministic response. This type of response is a primary characteristic of a real-time operating system (RTOS). We conducted some research into real-time extensions for Linux and were pleased to find that such technology exists. Projects such as RTLinux and RTAI provide the necessary framework for providing real-time response within Linux. They operate on the principle that an RT kernel runs at the core with the Linux kernel scheduled as a low-priority task.

Filesystems for embedded applications require a level of robustness that exceeds that of normal desktop systems. In addition, they must support diskless storage and embedded devices. Achieving these requirements generally involves a sacrifice in efficiency and performance.

The Journaling Flash Filesystem (JFFS) was chosen since it is specifically designed to minimize the risk of data loss from a system crash or noncontrolled shutdown for industry-standard Flash memories. It is included in the standard Linux 2.4 kernel and is available as an open-source patch for the Linux 2.0 kernel. Our implementation using the Linux 2.0 kernel required significant work to obtain reliable operation with our hardware configuration.

JFFS is simply a log-structured list of nodes on the Flash media. Each node contains information about the associated file and possible file data. If data is present, the node will contain a field that indicates the location in the file where data should appear. This allows newer data to overwrite older data. The node also contains information about the amount and location of data to delete from the file. This information is used for truncating files or overwriting selected data within a file. In addition, each node contains information that is used to indicate the relative age of the node. In order to recreate a file, the entire media must be scanned, the individual nodes must be sorted in order of increasing version number and the data must be processed according to the instructions in each node. This is required only once when the filesystem is mounted.

JFFS writes to the Flash media in a cyclic manner. New nodes simply are appended until the end of the media is reached. Before reaching the end of the media, the first block of media must be freed for use. This is accomplished by copying all valid nodes (nodes that have not been made obsolete by later nodes) and then erasing the block. This inherent cyclic nature ensures wear-leveling of the Flash media.

As evident, JFFS is not an efficient means of storing and retrieving data. The number of bytes required to store a file can be more significant than the actual file size. However, in terms of robustness and crash recovery, JFFS rates highly. If the system crashes or experiences an unexpected loss of power, only the last node written might be affected. Thus, the file still can be recreated excluding the changes described by the last corrupted node.

The dimmPCI hardware was selected to address the needs of the embedded marketplace by focusing on scalability, physical size, flexibility, development costs and product cost. Figure 1 illustrates the first-generation hardware platform consisting of a passive developers' backplane and the netdimm CPU module. The developers' backplane is intended to be used by other embedded system developers for quick application development. The backplane includes a standard desktop PCI slot to facilitate software development earlier in the cycle using standard PCI peripheral cards.

Figure 1. First-Generation dimmPCI CPU Module and Backplane