PRODUCT HOW-TO: A New Approach to Embedded Linux Development

The commercial embedded Linux market was created ten years ago when Jim Ready founded MontaVista Software. At the time, skeptics said Linux would never work for embedded development, it lacked key features required for embedded systems, and the performance wasn't comparable to existing real time operating systems (RTOS).

Well, ten years later Linux has not only proven itself up to the task, but an entire industry has been created around embedded Linux. Multiple vendors have entered the commercial Linux business, and the semiconductor vendors have shifted their strategies and become innovators and contributors to the open source Linux community. All of their new products are showcased running reference Linux implementations.

Linux is now the preferred operating system for development of new embedded systems, outpacing all other operating system choices. But the approach to delivering embedded Linux hasn't evolved much since the beginning. Let's take a look at the challenges embedded developers face, and how MontaVista Linux 6 (Figure 1 below) takes a new approach to embedded Linux development.

Figure 1. MontaVista Linux 6

What's wrong with the old way?
In the early days, commercial Linux vendors simply took the existing RTOS model and applied it to Linux. RTOS vendors generated "board support packages" (BSPs) that adapt a predefined product, with a fixed set of features, as little as possible to execute on new hardware platforms.

This model was sensible in the era of proprietary software platforms because the vendor was the only true innovator in the software supply chain. Most commercial Linux vendors continue with this model today.

They offer one, or a few, binary Linux distributions with a defined set of features that support a range of hardware platforms. They may tailor these distributions to specific market segments but the distribution model doesn't change.

This model creates a set of challenges for the developer. Let's take a look at each of these.

Most developers begin prototyping, or early development, using the reference implementation from the semiconductor vendor. While these reference implementations are typically well integrated with the hardware, and allow the developer to fully exploit the power and functionality of the hardware, they lack many non-hardware specific features. This means the developer is forced to customize the distribution to add required features to deliver a complete commercial product.

Another key differentiator is the difference in quality. The hardware vendors provide Linux for one reason, to rapidly enable development on their hardware. They don't do the testing, bug fixing, or integration required of a commercial product. Nor do they provide technical support for developers who are customizing their Linux distributions.

Commercial Linux distributions provide the desired quality and support. But, since the commercial Linux distribution is generic in nature, containing a predetermined set of features, it's highly unlikely it will exploit the full functionality of the processor or system on a chip (SOC).

This means the developer has to compromise on functionality, or customize the distribution to add the required functionality himself. Customizing commercial Linux distributions is often a difficult task since they are binary distributions, not source driven.

The bottom line: The developer winds up having to compromise, either on functionality or quality. If they do move from the semiconductor Linux distribution to a commercial distribution, often some of the same work is repeated over again.