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.
Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
| Trying to Tame the Tablet | May 08, 2013 |
- Using Salt Stack and Vagrant for Drupal Development
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Home, My Backup Data Center
- New Products
- New Products
- RSS Feeds



5 hours 48 min ago
11 hours 27 min ago
17 hours 26 min ago
17 hours 49 min ago
17 hours 59 min ago
18 hours 3 min ago
18 hours 33 min ago
21 hours 24 min ago
22 hours 31 sec ago
22 hours 1 min ago