Industry Organizations Launch To Provide Linux Support

Download this article in .PDF format
This file type includes high resolution graphics and schematics.

Cooperation is the hallmark of open source projects, and Linux is one of the prime examples. It runs on most platforms capable of supporting it, and it is the basis for popular platforms such as Android.

Linus Torvalds manages the Linux kernel. The latest kernel can be found at www.kernel.org, but it is only the core of any version of Linux that is in use. It may be closer to a version of Linux used in embedded applications, but even a minimal system will have some additions to make it useful.

Some projects target Linux specifically. The Linux Documentation Project delivers manual pages, how-to documents, and FAQs for core functions. The Linux Driver Project creates and maintains open source kernel drivers. There are also organizations for user interfaces such as Gnome and KDE and programming frameworks like Qt (see “Digia’s Lars Knoll Discusses The Qt GUI Framework” at electronicdesign.com). Of course, numerous Linux distributions like Debian, Ubuntu, Fedora, and CentOS combine all of these types of components into a platform that can be installed and used immediately. They normally target PC or server platforms.

Related Articles

These Linux distributions often come in a minimal configuration, but they are typically more than what is required for an embedded application. They also tend to have a rather quick update sequence and lack the support necessary for embedded developers. In the long past, at least by computer standards, developers had to roll their own version of Linux. These days, embedded Linux developers normally turn to tool vendors to deliver and support their version of embedded Linux. This used to result in platforms that were very specific to the vendor, but things are changing.

The Linux Foundation supports collaborative projects built around Linux such as OpenMAMA (Open Middleware Agnostic Messaging API) and virtualization as part of the Xen Project. The Yocto Project, which has garnered an amazing amount of support, provides tools to create custom Linux-based systems (see “Interview: Mike Woster Discusses The Yocto Project” at electronicdesign.com). The Yocto Project kernel targets popular hardware platforms such as x86, ARM, MIPS, and Power (PC).

The GENIVI Alliance also utilizes the output of these tools (see “Interview: Joel Hoffmann Discusses Infotainment And The GENIVI Alliance” at electronicdesign.com). It targets automotive in-vehicle infotainment (IVI) environments. GENIVI Alliance platforms have a more limited development audience, but they may provide software platforms that can be used to deliver applications from a wide range of developers.

The Yocto Project

Linux has grown into a number of diverse distributions such as Debian, Red Hat/Fedora, and Ubuntu. They target popular standard platforms like 32- and 64-bit x86 PCs, but they’re just the tip of the iceberg. Distributions that target resource-constrained environments such as Arch Linux support a mix of package management systems, but they all build on the same Linux kernel.

The Yocto Project attempts to bring these elements together into a single environment for building Linux distributions. It primarily targets embedded developers who are interested in incorporating their own collection of features, applications, and drivers. A developer may target a specific hardware platform, but the processes used by the Yocto Project tools allow the target to be part of the system specification. In theory, it makes porting to a different platform significantly easier. Further customization or support may still be necessary, but it can often be isolated to a device driver or application.

The Yocto Project’s Poky reference system is based around the OpenEmbedded architecture (Fig. 1). The project provides open source, high-quality templates, tools, and methods to allow anyone to create a Linux-based system for any supported hardware architecture. At the core is the BitBake build system and BitBake recipes/build files. BitBake can pull source code from Git, a distributed version control and source code management (SCM) system. Linus Torvalds initially developed Git for Linux kernel management.

Figure 1. The Yocto Project uses the OpenEmbedded architecture to take BitBake recipes to generate custom Linux configurations.

Other components include:

Autobuilder: a quality assurance (QA) automation environment built on BuildBot
Build Appliance: a virtual machine image used to try out the Yocto Project
EGLIBC: the embedded version of the GNU C Library
Matchbox: an X Windows-based graphical reference user interface (UI) for embedded devices
HOB: a graphical user interface for BitBake
Application Development Toolkit (ADT): a development environment for user space applications to run on operating-system (OS) stacks built by Poky
Eclipse IDE plugin: provides ADT integration
Swabber and Pseudo: tools for cross-development that are integrated with Poky

Most of the Yocto Project tools are text and command line oriented. Developers can configure the system by editing text files or by using the HOB GUI (Fig. 2). HOB provides basic configuration support, but it is sufficient for many developers who simply need to select and configure a basic set of features. The Eclipse IDE plugin provides support for developers targeting Yocto-based platforms for the graphical, open source, Eclipse development environment that is the basis for many third-party tool vendors such as Mentor Graphics’ Sourcery CodeBench and Wind River’s Workbench.

Download this article in .PDF format
This file type includes high resolution graphics and schematics.

Figure 2. HOB is a graphical front end for configuring BitBake recipes.

A typical scenario for a developer starts with the Yocto Project tools including a virtual build appliance that is a VMware virtual machine running Linux and equipped with all the necessary software to build a new Linux distribution. The developer simply needs to start with a recipe and select a target for the build process. Developers can subsequently customize a distribution by using HOB or editing the recipe files and rebuilding.

Related Articles

The virtual appliances do not contain the source code, only the tools to obtain it (git) and build it (bitbake). Git will download the source code locally and then compile, link, and build the Linux image. The image then can be downloaded to the target or a simulated target.

An application for this custom distribution can be created using most any Linux development toolset, such as the Eclipse IDE, that can be equipped with the ADT plugin. This provides cross-platform toolchain support as well as QEMU (Quick EMUlator) support for simulating target hardware for test and debug purposes. It also includes many useful user space tools that run on the target.

The major embedded Linux vendors have embraced the Yocto Project. They all had their own tools in the past, and migration to the Yocto Project toolset isn’t simply a matter of replacing a toolchain for cross-platform development. Likewise, many vendors had build systems that may have included more sophisticated features that they might want to incorporate into their offerings. Still, many are already delivering development environments that are based on the current Yocto Project output.

The advantages of a common framework from a developer’s point of view are obvious. System designs and development tools can be shared. Software can be included simply by having the recipe and access to the source code repository on the Internet.

The advantage for vendors is less clear until one considers that they can now add their value on top of a more sophisticated system. The base software will be accessible and shared by their competition if they take the Yocto approach, but this approach simplifies building and supporting that base, leaving more resources for adding value in other areas.

GENIVI Alliance

IVI is a big market and a significant selling point for new vehicles. Audio and radio solutions have grown into interactive navigation systems with Bluetooth and cellular connectivity. They still tend to be unique to an OEM and often to a particular car model or brand.

This was less of an issue before smart phones and third-party involvement in development of applications for OEMs and Tier 1 suppliers. At this point, any third-party applications on an IVI platform will be limited to a selection provided by the OEM. These applications were likely to be developed or customized specifically for the delivery platform.

The GENIVI Alliance is designed to provide a common base for IVI platforms. Joel Hoffmann, automotive strategist for Intel's Automotive Solutions Division and GENIVI Alliance spokesman, says that “the objective is to provide the industry a more competitive environment for faster innovation and lower cost of software development” (see “Interview: Joel Hoffmann Discusses Infotainment And The GENIVI Alliance” at electronicdesign.com).

OEMs and Tier 1 vendors were already using or considering Linux, although other OSs and frameworks have been used in this space. Ford Motor Company’s Sync is based on Microsoft’s Windows technology (see “Ford’s Electronics Advances Aim To Reach Drivers On A More Personal Level” at electronicdesign.com).

Applications that interface with the driver and vehicle occupants are just part of the equation. Machine-to-machine (M2M) applications are also being linked to IVI systems and the infrastructure they utilize (see “M2M Client-Side Challenges Emerge In Mobile Embedded System Updates” at electronicdesign.com). A common application development environment would be useful regardless of whether additional applications are for M2M chores or for providing occupants with more information.

The GENIVI Alliance stack builds on Linux distributions from the Yocto Project (Fig. 3). It also specifies standard frameworks on top of the Linux images while adding IVI-specific application programming interfaces (APIs).

3. The GENIVI Alliance stack builds on Linux using standard frameworks while adding IVI-specific APIs.

The GENIVI system infrastructure provides automotive APIs for information about the car such as tire pressure. It also manages Internet access and local wired and wireless networking support. GPS and navigation support are moving from optional to standard fare, so it is not surprising that this is part of the mix as well.

The application and human-machine interface (HMI) frameworks are designed to abstract the hardware that will be available. It can range from touchscreen interfaces to voice recognition systems. CE device connectivity and personal info management should make linkage details between smart phones and tablets transparent to the developer. Multimedia audio and graphics support might seem simple, but it also needs to address hardware that will be found in a car such as the radio. Graphics support needs to be coordinated with the HMI support as well.

The baseline GENIVI system comprises more than 140 components and APIs. That is a significant chunk of software and a major amount of middleware that now has a standard interface. It would make the job of building an application for different vendors utilizing GENIVI much easier.

Security is part of the mix and one reason that GENIVI’s framework may find limited third-party use compared to platforms like Android. GENIVI targets the IVI subsystem, but it is still close to the car’s command and control infrastructure. The OEM may not want to allow the car’s owner to arbitrarily select and install an application like one can on a smart phone. On the other hand, a common framework for applications will greatly simplify Tier 1 and Tier 2 suppliers’ development chores. It also means that security-approved applications can be utilized on more hardware.

Linux supports virtual machines, but this technology has yet to find major deployment in the IVI automotive space. This approach could potentially isolate GENIVI-based applications.

One major difference between the Yocto Project and the GENIVI Alliance is compliance and testing. The GENIVI Alliance addresses both. Testing gives developers confidence that the platforms provide the facilities needed to run their application. Likewise, OEMs can provide a platform with known functionality. The OEMs and Tier 1 vendors manage compliance and testing.

Tool and OS vendors are delivering GENIVI-compliant platforms and tools. These products target the OEMs and Tier 1 developers plus the limited but growing group of application developers targeting GENIVI. I would not expect Android and iPhone application developers to be flocking to GENIVI yet.

The Yocto Project has widespread support and applicability. GENIVI is more focused, but both highlight how open source is changing how embedded applications are built and supported. They also show how cooperation is raising the level of the starting point for developers and vendors.