Embedded PCI and Linux
Peripheral Component Interconnect (PCI) technology is prevalent on the desktop and embedded computing environments. PCI has a significant share of the desktop market, and the sizeable volumes associated with this market enable PCI technology to be implemented cost effectively.
Unfortunately, the low-cost nature of PCI has not been realized in the embedded environment. This is mainly due to two factors: the desktop PC form factor being unsuitable for embedded applications and the low-volume requirements of most industrial applications not yielding to economics of scale.
The desktop PC form factor is not well suited for many embedded applications, generally due to space constraints or the fact that the form factor itself inherently is unreliable in demanding industrial settings. Alternative form factors are available, such as CompactPCI and PC/104+. However, these technologies suffer from the inhibiting fact that their applications primarily are industrial in nature, resulting in the volumes for these applications being significantly less than those in the desktop environment. Consequently, components of these technologies are costly due to the market niche that they occupy.
The proposed dimmPCI standard (see www.dimmpci.com) attempts to alleviate these two problems. The dimmPCI standard is a superset of the 32-bit, 33MHz desktop PCI standard in a dual in-line memory module (DIMM) form factor. This form factor uses a high-volume, commercially available DIMM interconnect component. The use of a high-volume interconnect reduces system cost considerably, as can be seen when a comparison is done between the desktop market and other PCI technologies.
The acceptable sizes defined by the DIMM standard improve reliability by reducing the mass of the circuit card considerably. Reliability is enhanced further by the presence of card locks at both ends of the DIMM connector. Easily manufactured and inexpensive braces also may be added to the middle of the circuit cards for additional support.
By using PCI, a myriad of options are available to the embedded systems developer. The developer now may select from a range of high-volume PCI components used in desktop applications. This brings low-cost, high-performance, system-level solutions within reach of the embedded marketplace.
Use of standard PCI technology enables a significant reduction in development effort. Using existing proven technology reduces time-to-market of both the hardware and software components.
Finally, an operating system was required that met the following requirements: widely used, easily supported, ease of development, low-development costs, low per-unit licensing fees, support for wide range of hardware platforms and devices, code maintenance, qualified developers and maximized exploitation of the technology platform. After analysis of various options, µClinux was chosen.
Linux has existed in the desktop domain for a considerable length of time, and thus it has accumulated a significant knowledge base related to PCI development.
Our selection of hardware and software occurred using an iterative process. That is, the initial hardware and operating system requirements (low cost, performance, networking) identified a broad solution set. The new solution set was combined with the initial requirements and information we collected during the first iteration to generate new initial conditions (network stack, OS/RTOS, SRAM/DRAM, PCI). Again, the equation was solved and a solution identified. This process went through three iterations, each time identifying a better solution. At the end of the process, we settled on the hardware and operating system components described herein.
Our iterative process indicated Linux as a possible choice for our operating system quite early in the process. Based on previous work, use of closed-source OSes for embedded projects has created problems with code debug and trace during development. Another important consideration is off-the-shelf support for different filesystems, network stacks and peripheral devices. Finally, support for a wide range of hardware platforms is important for future development projects that require application migration to higher levels of performance. An analysis of available options quickly identified Linux as the OS of choice.
Our first hardware platform (described below) is based on the Motorola Dragonball VZ microcontroller. The Motorola Dragonball family devices use a large-endian memory format and alignment that is different from x86-based devices. The Dragonball also lacks a memory management unit (MMU) unlike microprocessors used in desktop computers. Typically, lower-cost processors lack an MMU, and many embedded applications are driven by cost. The software for these applications does not require the benefits that an MMU would provide.
It is known that a full Linux kernel requires the presence of an MMU in the hardware system. Due to the absence of the MMU in the Dragonball processor, the process of porting a Linux kernel to this microprocessor architecture is a significant undertaking.
µClinux is a Linux 2.0 kernel that has been ported to a Motorola 68k family device that does not have an MMU. Some kernel services need to be adapted to work in an environment without an MMU. For example, services normally provided by the function fork() may be accomplished with vfork(), given that care is used. Note that µClinux originally was ported to the Dragonball EZ processor. Our implementation uses the Dragonball VZ and so requires some additional kernel modifications.
|Bitcoin on Amazon! Sort of...||Sep 28, 2016|
|Free Today: September Issue of Linux Journal (Retail value: $5.99)||Sep 27, 2016|
|nginx||Sep 27, 2016|
|Epiq Solutions' Sidekiq M.2||Sep 26, 2016|
|Nativ Disc||Sep 23, 2016|
|Android Browser Security--What You Haven't Been Told||Sep 22, 2016|
- Free Today: September Issue of Linux Journal (Retail value: $5.99)
- Bitcoin on Amazon! Sort of...
- Android Browser Security--What You Haven't Been Told
- Epiq Solutions' Sidekiq M.2
- Nativ Disc
- The Many Paths to a Solution
- Identity: Our Last Stand
- Tech Tip: Really Simple HTTP Server with Python
- Securing the Programmer