LINUX

TRAINING

Migrating from QNX to

Embedded Linux
Embedded OS development porting for
those migrating from QNX
July 2012

A LINUX FOUNDATION PUBLICATION

Migrating from QNX to Embedded Linux

Abstract

In recent years, many companies have moved to open source as it affords more flexibility and cost control. Many
users of QNX are currently looking at Embedded Linux as an alternative embedded OS, but are unsure of how to
migrate. The Linux Foundation offers resources, training and an open source build tool, the Yocto Project, to help
companies make this transition.
IT executives, managers, and engineers have a fiduciary duty to investigate and recommend technology alternatives
for technical, legal, strategic, or financial reasons. This article discusses what these persons interested in porting
QNX-based embedded systems to an Embedded Linux platform should consider.

Introduction
Why Move to Linux?

There may be a strategic advantage in moving the development platform of an embedded product from QNX to
Embedded Linux. Ownership of QNX has gone from the original company founded in 1980 to Harmon International
in 2004 and to Research In Motion (RIM) in 2010. Both Harmon and RIM wanted to build in-vehicle infotainment
systems based on QNX, and RIM developed the PlayBook tablet based on QNX and currently has plans to develop
QNX-based smartphones. This apparent move away from development platform support seems to be a trend:
In September 2007, QNX Software Systems had made some of its source code available as part of an effort to
attract open source developers. When RIM announced the acquisition of QNX, this source code access was
restricted.
QNX dropped the Solaris OS as a development host.
RIM has recently experienced market setbacks and, a loss of prestige due to events such as the Halliburton
switch to iPhone, and currently is undergoing some corporate turmoil.
RIM is primarily a smartphone company that developed a proprietary OS, not an operating system marketer or
development platform vendor.
These events raise the following questions:
Will RIMs problems jeopardize continued industry support for QNX?
Will RIM abandon and sell or orphan QNX, leaving the future of QNX in doubt?
Will RIM stop licensing new versions of QNX or renewing older agreements in order to monopolize QNX
technology to its own advantage?
Will RIM be able and willing to provide the services QNX developers require?
Embedded Linux can be a viable and advantageous replacement for QNX for embedded devices. Embedded Linux
lets the designer leverage a large pool of developers, a rich legacy of source code, and industry standard POSIX
APIs. Linux in embedded devices has enjoyed strong growth over recent years, from Android tablets to Sony
Televisions and many other products.
As the complexity of embedded systems grows, higher level tools and operating systems are migrating into the
machinery. For example, cellphones, tablets, and other consumer devices often need significant software that is
purchased or provided by those other than the devices builder. Googles Linux-based Android is an example. An
open and popular programming environment is required so that the third-party software provider can sell to a large
market. QNX was developed to address niche market issues and provide for these needs and has only now moved
into general, mass produced consumer electronics support. Linux has evolved to become a proven and established
platform for embedded development.

LINUX

TRAINING
Migrating from QNX to Embedded Linux

Speculation as to the future of QNX, market pressures, budget constraints, customer demands and myriad other
forces has many QNX based developers looking into Linux solutions for future projects and ports of legacy systems.

Porting Issues

Porting an embedded development project from one platform to another is a formidable task due to the highly
intimate interaction of hardware and operating system software involved with embedded platforms. The operating
system needs of an embedded system are greatly impacted by both very specific application requirements and
severe hardware limitations.
The embedded operating system used by developers must be flexible and scalable. Devices may be simple,
single-task machines or more complex multi-use devices. An embedded device must be able to efficiently handle
applications with relatively few processes or even just a single task for one device, while also being able to provide
the scheduling, process management, and system protection needed in more complex devices.
Embedded devices also create unique hardware handling issues. The lack of hard disks for caching, minimal memory
footprints, primitive or no MMU support, and low power consumption requirements necessitate efficient use and
management of system resources by the OS.
Developers can and have used two or more different platforms in these situations, but this is not ideal for obvious
reasons.
Factors to consider include real-time operations and the future advent of recongurable hardware platforms (e.g.
those using Embedded Java) that would make embedded devices reusable and versatile. There are also questions of
development support, build and test tools, available resources (infrastructure and people), and licensing. Embedded
Linux has addressed all of these issues.

Costs and Resources

Two primary factors contributing to a developers choice of embedded operating systems for projects being built new
are cost and the availability of source code.i Wanting to increase development potential and decrease costs while
supporting existing projects make matters more complex. Not only does the source code need to be changed for
the new platform, but a new operating system must be purchased and configured or designed and built to run in the
target device.
Improvements in embedded Linux designs, tools, and infrastructure make moving to Linux an easier and financially
more palatable business decision. Choosing Embedded Linux as a platform is a logical move for many developers.
Embedded Linux supplies the same, and more, of the resources of QNX.

Choosing Embedded Linux

Why many have chosen Embedded Linux as the next step in a long term development cycle is based on solid
business and technical reasons: Linux offers the ability to address market opportunities and provides the technical
resources to do so. Even more important is the industry support for established standards of the Embedded Linux
codebase the Community.

Linux Code - Quality, Reliability, Adaptation, Usability, Flexibility

The quality and reliability of the Linux codebase is due to an open source development model that invites many
parties (generally referred to as the Community) to contribute, identify problems, debate solutions, and fix issues
effectively. Kernel and system components can be selected in the build configuration. The community of companies
and individuals maintaining the various components of the software ensures problems are pointed out and corrected
quickly and features are added as required. Support for hardware and communications protocols is broad, and there
is a large driver support base. Another benefit of Linux is that it works well with other systems. Linux can function
easily alongside Windows and UNIX by supporting any protocol that either uses.ii

LINUX

TRAINING
Migrating from QNX to Embedded Linux

There is also a large variety of tools to choose from. Of course, all of this choice can be overwhelming, so commercial
embedded packaged distributions targeted to specific needs are available for purchase.

Independence from a Single Vendor

The open source licensing model under which Linux is distributed provides developers the same rights as the vendor.
If a change is desired, it does not involve a complete migration of all code.

Embedded Linux Standards ELC and The Linux Foundation

Embedded Linux is a very established, supported, serious development platform. There are over 200 distributions
of Linux and many embedded and RTOS versions. Without the existence of a standard for Embedded Linux that
enable the use of a cost-effective, focused environment, Embedded Linux would be useless. To make Embedded
Linux versions compatible, the Embedded Linux Consortium (ELC) was formed. ELC is a nonprofit trade association
for the advancement, promotion and standardization of embedded Linux. Since September 9, 2005 the ELC Platform
Specification has been hosted by The Linux Foundation. The Embedded Linux Consortium transferred the ELC
Platform Specification (ELCPS) and related intellectual property to The Linux Foundation. The ELCPS can be found
here: Embedded Linux Platform Specification.

Comparing Linux and QNX

Footprint

Although designed to run PC platforms, Linux is also a reliable OS for embedded systems. The typical shrinkwrapped Linux system has a full featured Linux kernel that requires about 1 MB of memory. The Linux pure kernel
(virtual memory and all core operating system functions) actually consumes only about 100KB. With the networking
stack and basic utilities, a complete Linux system runs at about 500KB of memory. The total memory required is
dictated by the applications to be run, but a Linux system can be adapted to work with as little as 256 KB ROM and
512 KB RAM. That makes Linux a lightweight operating system for the embedded market.iii

Kernel Weight

Linux is often referred to as a monolithic kernel OS. This is true of its standard desktop configuration. An Embedded
Linux core, like QNX, has a simple kernel architecture, although its not a microkernel like QNX since the drivers
do run in kernel mode. However, the Linux kernel is modular and allows loading of device drivers during runtime.
Networking and file systems are layered on top of the microkernel in a modular fashion. Drivers and other features
can either be compiled into the kernel to create a larger core or added to the kernel at run-time as loadable modules
are needed. This provides a highly modular building-block approach to constructing a customized embedded system,
which typically uses a combination of custom drivers and application programs to provide the added functionality.
Designers of embedded systems have long used both QNX and Embedded Linux successfully. Because of its
robustness, relative compactness, versatility, low cost, and open source licensing model, Embedded Linux has
become the most used platform. Embedded Linux also lets the designer leverage a large pool of developers, a rich
legacy of source code, and industry standard POSIX APIs.

LINUX

TRAINING
Migrating from QNX to Embedded Linux

QNX Linux Comparison Reference Table

Attribute

QNX

Linux

API

Standard and widely supported APIs

Uses ANSI Standards

Standard and widely supported APIs

Uses ANSI Standards

Design

Designed for embedded use, scalable

Linux is inherently modular and easily scaled up or down to

include only necessary drivers for embedded hardware and
applications

Application
Programming
Languages
Compilers and
Runtimes

C, C++

C, C++, C#, Java and most others

GNU GCC; IBM C/C++, Fortran; Open64 Open Research
Compiler; g95 Production Fortran 95
clang C Frontend for LLVM; LLVM C/C++; Free Pascal Pascal
and Object Pascal; Glasgow Haskell Compiler; FreeBASIC 32-bit
BASIC compiler

GNU GCC
C/C++/Java
Cost

Cost of Development
Seat

US$9,695 per seat

Free open source (Ranges with commercial version or can be

free but also has services cost)

Cost of Runtime
license

US$150 per unit as of February 2012 (less if 10,000+)iv

No runtime royalties

Cost of Support

US$1,842 per year per seat

Open source development environment has no maintenance

cost. However, commercially supported environments are
available ranging from $33 to more than $15,000 per seat per
year.

Development
Environments
Available

Neutrino RTOS; Certified Plus; Secure Kernel; Safe Kernel; RTOS Wind River Linux; MontaVista Linux; LynuxWorks Inc.; iMedia
v4
Linux; TimSys Linux; And many other commercial, low cost, or
free alternatives

Drivers

Having dynamically loaded device drivers is automatic

Having dynamically loaded device drivers is automatic

File Systems

Excellent file system support

Excellent file system support

FS Support of QNX/
Linux

Limited Support of Ext2 file system

Limited support of QNX6, QNX4 and QNX2 file systemsvi vii

GUI

Photon and a Qt port

Several GUI Choices including embedded specificviii

Hardware Support

Supports large number of peripherals

Supports large number of peripherals

Hardware Support
and Device Drivers

Very complete

Very complete

Hardware Supported

Binaries for ARM, MIPS, PowerPC, SH-4, StrongARM, XScale,

and x86 architectures

Binaries and source for ARM, AVR32, ETRAX CRIS, FR-V, H8300,
IP7000, m68k, MIPS, mn10300, PowerPC, SuperH SH-4, xScale,
x86, and Xtensa processors

Host System

Windows, Linux, QNX 6, Sun

Usually Linux

IDE

Eclipse

Eclipse, NetBeans, Anjuta, Aptana Studio, Bloodshed Dev,

Code::Blocks, Geany, Qt Creator, IntelliJ IDEA

Interprocess
Communication

message-passing primitives providing Synchronous Message

Passing and other mechanisms

Synchronous Message Passing and other mechanisms based

on UNIX: signals, wait queues, file locks, anonymous and named
pipes, system V IPC, UNIX domain sockets.

Kernel Programming
Languages

LINUX

TRAINING
Migrating from QNX to Embedded Linux

Attribute

QNX

Linux

Libraries

ANSI C; POSIX; Dinkum C++; Dinkum embedded C++

ANSI C; POSIX; Many others

Maturity

Is proven to be sophisticated, efficient, robust and reliable

Is proven to be sophisticated, efficient, robust and reliable

Memory

QNX does not support a swap file in the same way

Can expand RAM using disk virtual memory; Zero size swap
space disables disk virtual memory

Memory
Management

virtual memory with hardware abstraction and protection

virtual memory with hardware abstraction and protection

Middleware

Aviage (QNX) Acoustic Processing

Aviage HMI Suite
Aviage Multimedia Suite

Gnome, KDE, IBM, Alliance Automotive, Oracle, Athena PKI,

JBoss Enterprise, Red Hat, and many more

Network Ability

Superior network capability

Superior network capability

Network Support

Full

Full

NFS Availability

Network File System included

Network File System included

Open Source
Resource

Not as much as Linux and not open source

Has enormous amount of open-source software, documents

and developers

Operating Systems
Architecture

Real time POSIX-based microkernel containing CPU scheduling,

interprocess communication, interrupt redirection, low-level
network communication. (Timers and other components are in
run user space).

POSIX-based layered module kernel containing process

scheduler, memory manager, the virtual file system, network
interface, and interprocess communication. Other components
like hardware drivers can be compiled into the kernel.

OS Load RAM

Temporary, process directories

Temporary, process directories

Compressed kernel and root tools

OS Load ROM

Compressed kernel and root tools

Process
Management

FIFO, adaptive, round robin; Fully preemptible; External of kernel FIFO, adaptive, round robin; Not fully preemptible without
(but shares kernel address space)
available RTOS modifications; Internal of kernel

Real Time Support

Built into the design

Requires extensions

RTOS

Can provide real time preemptive process scheduling

Can provide real time preemptive process scheduling (with the

PREEMPT_RT patch)

Scalability

Highly capable; SMP support

Highly capable; SMP support

Standards

POSIX-based and compliant

POSIX-based and compliant

Technical Support

Only from QNX or QNX vendors

Technical support from Open-Source Community of all around

world

Web Support

Supports both HTML5 and Flash

Supports both HTML5 and Flash

Common Misconceptions about Embedded Linux

A big problem of moving to a different operating system is resistance to a new platform. Rumors and misconceptions
about Embedded Linux that make it seem a non-viable embedded solution are based on knowledge of the generic
desktop Linux distributions, not embedded Linux. Some typical (and incorrect) arguments against Embedded Linux
include:
Some Common Falsehoods about Embedded Linux
1. QNX uses the CPUs MMU for memory protectionix but if desired, Neutrino can also run with or without an
MMUx and Linux cant
2. Embedded Linux has a non-preemptive scheduler
3. We lose the simple IPC
4. The file system and swap file requirements of Linux cause trouble and cost money
5. Embedded Linux over-commits memory

LINUX

TRAINING
Migrating from QNX to Embedded Linux

6. The OOM Killer Task Issue is insurmountable

7. The QNX microkernel never, ever crashes - Linux does
8. Retraining will be too hard
9. Porting the application code will be painful
10. Licensing is too hard
11. Too many distributions to sort through with no single universal plug-and-play embedded Linux distribution
12. Hardware for embedded devices is too diverse to be supported by Linux communities.
13. We need to have committed support, Linux is disorganized

Embedded Linux Facts

1. Linux - No MMU Required

Embedded Linux can in fact be used for hardware without a Memory Management Unit, e.g. System on a Chip
or SoC. (However, this setup is becoming less common as most SoCs now have MMUs.). Engineers can build
Embedded Linux based operating systems for embedded microcontroller systems and thin clients.xi Embedded Linux
supports both MMU and no-MMU architecturesxii, though the latter have some limitations,xiii such as no memory
protection and the risk of having the address space extremely fragmented xiv.
2. Preemptive Scheduler Included
The Linux 2.6 kernel added preemptive scheduling with the ability to interrupt a most tasks executing the kernel code
and a real-time Linux patch (PREEMPT_RT) can be added to support full preemption of critical sections and interrupt
handlersxv. Linux also includes RTOS enhancements in the common kernel. Linux 2.6 Kernel Real-Time Technology
Enhancements include:xvi
Preemptible Interrupt Handlers in Thread Context
IRQ-Disable Virtualization for Drivers
IRQ threads disabled without masking hardware
Integrated Kernel Mutex with Priority Inheritance (PI)
Protection of Kernel Critical Sections by Preemptible PI Mutex
PI Mutex Substituted for Non-Preemptible Kernel (SMP) Locks
Big Kernel Lock (BKL) converted to PI Mutex
Spin-Locks converted to PI Mutex
Read-Write Locks converted to PI Mutex
RCU Preemption Enhancements
High Resolution Timers
User-Space Mutex
3. IPC
For real-time systems, IPC (Interprocess Communication) overhead is a major concern. QNX supports several interprocess communication mechanisms, but its core is its native synchronous message passing which is simple and
versatile. Linux also has synchronous message passing available, even a QNX-API compatible one.
Synchronous Interprocess Messaging Project for LINUX (SIMPL)xvii provides a synchronous message passing module
for the Linux kernel. Derived from this project is the SRRIPC Linux Kernel Module,xviii which adds a QNX-compatible
API layer in a loadable kernel module designed to be QNX-API compatible to facilitate porting of code.

LINUX

TRAINING
Migrating from QNX to Embedded Linux

4. Filesystem and Swap

For embedded Linux, a small ramdisk is sufficient for most needs and is part of the boot process already (initrd). This
file system can be mounted as a root file system, the kernels local storage, and the application is executed from it the desired run-time environment for most embedded systems.xix Most new SOC-based systems have flash drives,
and setting a zero size swap space disables Linux disk based virtual memory, thus eliminating any need for a swap
partition.
5/6. Linux over-commits memory and the OOM Killer Task
These are related and valid points. Linux does have a problem estimating available memory and does over-commit
memory; if memory is not available, malloc() does not return null. Instead, the out of memory (OOM) killer task selects
and kills a process to free memory.xx In Linuxs defense, frustrations over the lack of control of memory allocation are
to some degree due to program design errors and lack of knowledge on how to configure the Linux kernel. xxi xxii There
are patches that fix Linux memory issues as needed.xxiii xxiv xxv
7. The uncrashable (almost) QNX microkernel
There is still the argument of QNX being the superior platform. However, markets are expecting more from devices.
Embedded customers want more of the convenience and niceties general computing devices provide. Its true that
the QNX kernel is almost completely uncrashable; however, as Linus Torvalds stated:
From: torvalds@transmeta.com (Linus Torvalds)
Newsgroups: comp.os.qnx,comp.sys.amiga.misc,comp.os.linux.misc
Subject: Re: Amiga, QNX, Linux and Revolution
Date: 3 Sep 1999 19:03:10 GMT
In article <37cf9cb5.2992973@news.demon.co.uk>, John Birch <nospam> wrote:
>
>QNX does a number of things right that Linux does flat wrong (true
>_uncrashable_ (almost) micro kernel, real time performance etc)
Ehhh..
Sure, the QNX microkernel is pretty uncrashable. But have you ever asked yourself why? Maybe because it doesnt do all
that much.
Put it in a general-purpose system, do some real work with it, open it up to people who arent polite, and see what happens.

Not many people care that the microkernel hasnt crashed when everything else has.
>Im sure youre right, the problem for QNX is that few people know how
>good it is because it is so expensive (aimed at a different market).

Its good for that market. But think about that _really_ means for a moment. Dont make the mistake of extrapolating
goodness in a very specialized market into goodness a more real-life and much less constrained market.

Linus xxvi

An embedded system has to be built so that none of the components crash, not just the kernel, and this is getting
more difficult in a market becoming more complex and far less limited.

LINUX

TRAINING
Migrating from QNX to Embedded Linux

8. Training
New systems require training and often the recruiting of new people or consultants. There are certainly some new
things about Embedded Linux that will need to be learned, but writing code should not be an issue. The Linux
Foundation has created a comprehensive training program to help companies make this move. Open enrollment as
well as customized training can be selected. The Linux Foundation has already trained people from many companies
making this transition. For more information, go to https://training.linuxfoundation.org/.
Moving from QNX to Linux is switching:
FROM
QNX:

A configurable
multi-target
embedded development system
with POSIX compliance
and ANSI C coding
that uses an Eclipse based IDE

TO
Embedded Linux:
A configurable
multi-target
embedded development system
with POSIX compliance
and ANSI C coding
that often uses Eclipse as the IDE
QNX and Linux are the same structure using the same standards. The learning curve for developers is minimal.
9. Porting QNX Applications to Embedded Linux
Porting QNX applications to Linux can be surprisingly straightforward since Linux is based on the same industrystandard POSIX API and uses the same ANSI C code. Because both were designed to support POSIX and ANSI
standards, many applications can run with few or even no major code changes. Aside side from header and
environment changes like OS-specific code, the developer simply has to recompile and relink the QNX source code.
QNX makes the same claim in porting Linux code to QNX.xxvii QNX made a considerable effort to ensure that Linux
developers could keep their programming model. This means the reverse is also true: QNX programmers will find
moving to Linux not only provides a very similar model, but also includes the key advantages of the Linux open
source model.
Note that QNX and Linux binaries are not compatible and custom QNX libraries will require rewrites. However, due
to the large code library in the Linux community, adapting an existing library that has similar functions will likely be
possible.
The standard Linux kernel does not have the real-time operating system (RTOS) capabilities (often referred to as
deterministic behavior) that QNX provides to embedded systems. But Linux 2.6 added preemptive scheduling with
the ability to interrupt most tasks executing the kernel code, and (as was previously noted) a real-time Linux patch
(PREEMPT_RT) can be added to support full preemption of critical sections and interrupt handlers. Also, several well
established Linux-based RTOS-dedicated products are available.

LINUX

TRAINING
Migrating from QNX to Embedded Linux

10. Licensing
Many open source projects adopt a license allowing proprietary software to use source code without any copyleft
(must be free to use) or all derived source code must be published clauses. Proprietary software retains its proprietary
nature.xxviii
11/12/13. Choice, Diversity, and Committed Support
Its ironic that the abundance of choice and diversity, the result of a free market economy and open source sharing,
is given as a reason not to use Linux. There are so many embedded distributions, but some do not support a large
amount of embedded hardware or provide direct code support and training. Missing deadlines due to lack of support
on code issues or kernel problems can outweigh any benefits of royalty-free code.
What developers need is a solution that provides a cohesive, standard development platform for building Linux
kernels for the target hardware that allows both diversity and choice, but also provides committed support.
The Yocto Project provides this solution.

The Yocto Project

The Yocto Project is a Linux Foundation workgroup and open source collaboration project whose goal it is to produce
tools and processes enabling the creation of Linux distributions for embedded software that are independent of the
underlying architecture of the embedded software itself. The Yocto Project is not an embedded Linux distribution
but a kit of tools and recipes to create a custom Linux distribution from source. Yocto relieves the embedded
developer from having to specifically identify and download the source of each of the packages that make up a Linux
distribution, then setting up a system with the correct set of tools to build these packages and finally assembling
them into an embedded Linux image.
The Yocto Project builds upon and extends a series of upstream open-source projects that form its toolkit. With each
Yocto release, updated versions of these projects with new features and bug fixes are included. Every new release of
Yocto also provides updated recipes and templates to track changes, features and bug fixes of the source packages
that make up a Linux distribution such as the Linux kernel.

Is The Yocto Project a Distribution?

Yocto is not a Linux distribution. Yocto allows the developer to create a Linux distribution by providing the tools
and infrastructure supporting embedded Linux development efforts. The key goal of the Yocto Project is to present
the developer with a kernel that has a clear and continuous history that is visible to the user. Parallels can be found
between the architecture and mechanisms of the Yocto Project and the Linux kernel build contributions
in the upstream kernel.org.

Yocto Project Structure

At the center of the Yocto Project is Poky, a platformindependent, cross-compiling layer that utilizes the
OpenEmbedded core. Poky provides the mechanism
to download, patch, build and combine thousands of
distributed open-source projects to form a complete
and coherent but fully customizable Linux software
stack.
Figure 2 depicts the Yocto workflow based on
OpenEmbedded. User Configuration, Metadata,
Hardware Configuration, and Policy Configuration
determine what Upstream Projects, Local Projects
on the developers system and what sources from

Developer Layer
Commercial (OSV) Layer
UI-Specific Layer
Hardware-Specific BSP Layer
Yocto Layer (meta-yocto)
OpenEmbedded Core Layer (oe-core)
Figure 1: Yocto Project Architecture (Source: www.yoctoproject.org)

LINUX

TRAINING
Migrating from QNX to Embedded Linux

10

optional Source Change Management systems to include, as well as to control the individual process steps of
the workflow. A Yocto Project release already contains configuration information and metadata that will produce a
working Linux system image, thereby requiring minimal adaption to the developers local build environment.

Upstream
Project
Releases

Local
Projects

SCM
(Optional)

OpenEmbedded Architecture Workflow

Process Steps
Upstream Source
Output Packages
Metadata/Input
Images/SDK
Build System

Source Mirror(s)

User
Configuration

Source
Fetching

Metadata
Hardware
Configuration
Policy
Configuration

Patch
Application

RPM
Creation
Output
Analysis
For
Packaging

Configure
Compile

DEB
Creation

Package Feeds
QA
Tests
Image
Creation

SDK
Creation

Images

Application
Development
SDK

IPK
Creation

Figure 2: OpenEmbedded Architecture Workflow (Source: www.yoctoproject.org)

Figure 2 also shows the linear workflow process for creating a Linux image and SKD. The steps consist of: Source
Fetching, Patch Application, Configure/Compile, Output Analysis for Packaging, Package Creation and QA Tests.
These steps are in fact repeated for each source package before all sources or Package Feeds have been created
and can be combined into an image. Yocto supports multi-processor and multi-core build systems by automatically
calculating dependencies and executing process steps in parallel, managing changes and only rebuilding Package
Feeds whose input, source, metadata, dependencies, or other parameters have changed. This greatly accelerates the
entire build process.
To further simplify the process for novice as well as experienced users, Yocto provides a series of different profiles
that automatically create images for common applications:
poky-image-minimal - A small image just capable of allowing a device to boot.
poky-image-base - A console-only image that fully supports the target device hardware.
poky-image-core - An X11 image with simple applications such as terminal, editor, and file manager.
poky-image-sato - An X11 image with example GUI implementation using Matchbox Window Manager, Sato
theme and Pimlico applications. The image also contains terminal, editor, and file manager.
poky-image-sato-dev - An X11 image similar to poky-image-sato but also includes a native toolchain and
libraries needed to build applications on the device itself. Includes testing and profiling tools as well as debug
symbols.
poky-image-lsb - An image suitable for implementations that need to conform to Linux Standard Base (LSB).

LINUX

TRAINING
Migrating from QNX to Embedded Linux

11

 meta-toolchain - This profile creates an archive that contains a standalone toolchain to be used externally to

Yocto. The archive also contains QEMU and the scripts necessary to run Yocto QEMU images.
meta-toolchain-sdk - This profile creates an archive that contains everything of the meta-toolchain profile but
also includes headers and libraries to form a complete standalone SDK.
The above list represents the most commonly used profiles. Many more specialized profiles are available and the list
continues to grow.

Yocto Project Components & Tools

Yocto Project features include:

Application Development Toolkit installer and Application Development Guide
Board support packages for the Atheros RouterStationPro, Freescales MPC8315E, Intels Atom, and Texas
Instruments OMAP, and others
GCC toolchain
Linaro kernel and toolchain for ARM processors
Open source Linux 2.6.37 commands, libraries and middleware
Poky and an improved OpenEmbedded bitbake
Process for gathering, compiling and building from upstream source code
System toolchain bootstrapping and machine specific sysroot
X Windows System

Platforms

Yocto supports popular hardware including:

ARM
MIPS
PowerPC
x86 architectures

Yocto Project Collaborators

The Yocto Project is actively supported by embedded and Embedded Linux industry leaders in embedded design,
development, tools, and products which include:
Hosted by The Linux Foundation
AMD
ARM
Cisco
Dell
Fujitsu
Hewlett-Packard
Hitachi

IBM
Intel
Mentor Graphics
Motorola
NEC
OpenEmbedded
Oracle
Qualcomm

Sony
SuSe
Texas Instruments
Texas Instruments
Timesys
Wind River
Yocto Adobe
and many more

LINUX

TRAINING
Migrating from QNX to Embedded Linux

12

Training

Often overlooked but always a significant factor in any development project is training. Without the knowledge to
utilize the resources provided, a software project is likely to fail.
According to a 2005 survey of embedded developers by EE Times:
A sizeable portion (18%) gave other as their reason for not evaluating Linuxthat the learning curve was too steep;
their schedule wouldnt allow them to learn an entirely new operating system and take on its configuration and
management tasks.xxix
Though training itself was not the major concern, the scheduling issues and delays cause training training to have a
huge impact on projects. It was not specifically training itself as the major concern but the scheduling and the impact
delays caused by it will have on the project. The Linux Foundation offers timely and effective training that provides
what staff accustomed to QNX need to know for porting to Embedded Linux. The Linux Foundation training offers
Corporate Linux Training that includes custom and on-site options.

Linux Foundation Courses

LF488 Implementation and Management of Open Source Compliance

LF320 Linux Kernel Internals and Debugging

LF426 Linux Performance Tuning

LF315 Inside Android: An Intro to Android Internals

LF425 Linux Performance Tuning Crash Course

LF312 Developing Applications For Linux

LF411 Embedded Linux Development

LF295 Android Bootcamp

LF410 Embedded Linux Development: A Crash Course

LF281 Executive Review of Open Source Compliance

LF405 Building Embedded Linux with the Yocto Project

LF273 Tizen Training For Non-Developers

LF404 Building Embedded Linux with the Yocto Project: Crash Course

LF272 Open Source Compliance Programs - What You Must Know

LF384 Overview of Open Source Compliance End-to-End Process

LF271 Practical Guide to Open Source Development

LF363 Portable Application Development for Tizen Devices

LF262 Developing with GIT

LF331 Developing Linux Device Drivers

LF211 Introduction to Linux for Developers

LF329 Introduction to Android

LF205 How to Participate with the Linux Community

Linux Foundation Course Locations

Barcelona

San Francisco

Jersey City

San Jose

New York

Santa Clara

Los Angeles

Sao Paulo

Prague

Vancouver

Redwood Shores

Yokohama

San Diego

And instructors can also visit companys offices.

LINUX

TRAINING
Migrating from QNX to Embedded Linux

13

Conclusion

Both QNX and Linux are proven and capable embedded systems platforms. Both have:
POSIX API
ANSI Standards
Support a variety of standard hardware
QNX Shortcomings:
Designed for real-time and less flexible when non-real-time applications are designed
Smaller user base
Does not offer developers some features that are available with Embedded Linux
Limited middleware selection
Smaller code base
Vendor lock-in
Embedded Linux provides vendor independence. Embedded Linux solutions come from several vendors and range
greatly in offerings and price, making it easier to fit to various needs and budgets.
An embedded system often requires generic capabilities, which, in order to avoid re-inventing the wheel, are
built from open source code with off-the-shelf programs and drivers supporting common peripherals and other
applications. Linux offers a greater developer base, software base and true open source code, as well as a larger
platform base than QNX. The Linux Foundation and its supporters have made Embedded Linux an, if not the,
embedded development standard.
With sophisticated tools like The Yocto Project, The Linux Foundation provides the tools and infrastructure, including
training and other support materials, that make the transition from QNX to Embedded Linux a smooth and timely
effort.

LINUX

TRAINING
Migrating from QNX to Embedded Linux

14

Resources
The Cathedral and the Bazaar (Eric Steven Raymond)
Embedded Distributions (LWN.net)
The Embeddable Linux Kernel Subset (ELKS)
Embedded Linux Platform Specification (The Linux Foundation)
Free Electrons Embedded Linux Experts (Free Electrons)
Free Electrons Linux Cross Reference (Free Electrons)
git (Git.Kernel.org)
Linaro (Linaro.org)
Linux For Devices (LinuxDevices.com)
Linux Kernel Newbies (KernelNewbies.org
Linux Tools: Freecode & SourceForge
Linux Training (The Linux Foundation)
OpenEmbedded (OpenEmbedded.org)
Poky (PokyLinux.org)
The Linux Foundation (The Linux Foundation)
The Linux Kernel Archives (Kernel.org)
Various Licenses and Comments About Them (GNU.org)
Yocto Project (YoctoProject.org)
Yocto Project Development Manual (Scott Rifenbark, Intel Corporation)
Yocto Project Wiki (Wiki.YoctoProject.org)

About the Author

TW Burger wrote his first embedded OS in 1986 on a custom Zilog Z80 based board using assembler. The 4 by
20 character black and white LCD display unit cost nearly $200. Since then he has provided support for, analyzed,
programmed applications, and done systems programming on QNX, Linux, AIX, UNIX, Ultrix, VAX 11/780, IBM S/370
MVS, z/OS, CPM, DOS, Windows 3 through 8, and various MS Servers, Win CE, and provided training on, and written
about various computer science subjects for companies like IBM and Intel. He lives in Vancouver, BC Canada.

LINUX

TRAINING
Migrating from QNX to Embedded Linux

15

i.
Yocto Project Big in Embedded Linux By Rudolf Streif, director of embedded solutions, The Linux
Foundation http://eecatalog.com/embeddedlinux/2011/08/23/yocto-project-big-in-embedded-linux/
ii.

Building Embedded Linux Systems By Karim Yaghmour, OReilly & Associates, Inc., 2003

iii.
September 2010 the Xubuntu developers claimed that the minimum RAM Xubuntu could be run on was 128
MB. http://en.wikipedia.org/wiki/Xubuntu
iv.

Source: QNX Sales Team

v.

QNX Working with Filesystems http://www.qnx.com/developers/docs/6.3.2/neutrino/user_guide/fsystems.html

vi.

Filesystems HOWTO Martin Hinner Version 0.8, Jan 2007 http://tldp.org/HOWTO/Filesystems-HOWTO-9.html

vii.
The QNX filesystem driver for Linux: QNX4, QNX6 & floppy read/write support. 03 may 2009, Dmitry Yakovlev.
http://qnxfs.narod.ru/
viii.
Choosing a GUI Library for Your Embedded Device Jan 01, 2007 By Martin Hansen From Linux Journal Issue
#153 January 2007 http://www.linuxjournal.com/article/9403
ix.
Comparison of Memory Management in QNX Neutrino and VxWorks http://www.ida.liu.se/~TDDB72/rtproj/
reports2006/41-joeja305ulfma629-QNX_Neutrino_VxWorks_Memory.pdf
x.

The Neutrino Microkernel http://www.swd.de/documents/manuals/neutrino/kernel_en.html

xi.
Supporting Linux Without an MMU Class #407 D. Jeff Dionne http://www.eetimes.com/electrical-engineers/
education-training/tech-papers/4124800/Supporting-Linux-Without-an-MMU
xii.
OpenEmbedded follow-up questions: Does OpenEmbedded support any devices that dont have an MMU?,
Scott Garman sgarman at zenlinux.com http://lists.pdxlinux.org/pipermail/plug/2010-February/067776.html
xiii.
Embedded Linux Introduction Thomas Petazzoni Free Electrons http://free-electrons.com/pub/
conferences/2011/montpellier/presentation.pdf
xiv.
Porting to architecture with no MMU (ipod/gba ARM), OSDev.Org, http://forum.osdev.org/viewtopic.
php?f=1&t=12242&start=15
xv.
HOWTO: Realtime-Preempt Kernel, Enable real-time capabilities of the mainline kernel https://www.osadl.org/
Realtime-Preempt-Kernel.kernel-rt.0.html
xvi. Brief History of Real-Time Linux - Linux World 2006, Sven-Thorsten Dietrich, Montavista Software, Inc. page
13 http://moss.csc.ncsu.edu/~mueller/seminar/spring06/dietrich.ppt
xvii.

SIMPL http://www.icanprogram.com/simpl/ and http://sourceforge.net/projects/simpl/

xviii.

SRRIPC http://www.opcdatahub.com/Docs/booksr.html

xix. Toolchain for ARM no-MMU OABI with FLAT binaries system, Khem Raj http://sourceware.org/ml/
crossgcc/2012-02/msg00054.html
xx.

OOM Killer http://linux-mm.org/OOM_Killer

xxi.

Out of Memory Notification http://kerneltrap.org/Linux/Out_of_Memory_Notification

xxii.

OOM Killer for embedded Linux systems http://www.mnis.fr/en/support/doc/oomkiller/

xxiii.

Taming the OOM killer http://lwn.net/Articles/317814/

xxiv.

Avoiding the OOM killer with mem_notify http://lwn.net/Articles/267013/

xxv.

Respite from the OOM killer http://lwn.net/Articles/104179/

LINUX

TRAINING
Migrating from QNX to Embedded Linux

16

xxvi. QNX does a number of things http://yarchive.net/comp/microkernels.html

xxvii. Migrating Linux Device Drivers to a Microkernel POSIX RTOS: A Case Study, David Donohoe Senior
SoftwareDeveloper QNX Software Systems http://photon.qnx.com/download/download/8086/qnx_porting_drivers_
from_linux_to_rtos.pdf
xxviii. GPL Compatible Licenses http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses
xxix. Embedded systems survey: Operating systems up for grabs

LINUX

TRAINING
Migrating from QNX to Embedded Linux

17

The Linux Foundation promotes, protects and advances Linux by

providing unified resources and services needed for open source to
successfully compete with closed platforms.
To learn more about Linux Training from The Linux Foundation please visit
us at http://training.linuxfoundation.org/. For more information on The
Linux Foundation and our other initiatives please visit us at
http://www.linuxfoundation.org/.

LINUX

TRAINING