LI NUX

TRAI NI NG
Migrating from QNX to
Embedded Linux
July 2012
A LINUX FOUNDATION PUBLICATION
Embedded OS development porting for
those migrating from QNX
LI NUX
TRAI NI NG
2 Migrating from QNX to Embedded Linux
Abstract
In recent years, many companies have moved to open source as it affords more fexibility 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 fduciary duty to investigate and recommend technology alternatives
for technical, legal, strategic, or fnancial 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 signifcant 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.
Migrating from QNX to Embedded Linux
LI NUX
TRAI NI NG
3 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 specifc application requirements and
severe hardware limitations.
The embedded operating system used by developers must be fexible and scalable. Devices may be simple,
single-task machines or more complex multi-use devices. An embedded device must be able to effciently 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 effcient 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 reconfgurable 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 confgured 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 fnancially
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 fx issues
effectively. Kernel and system components can be selected in the build confguration. 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 beneft 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
LI NUX
TRAI NI NG
4 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 specifc 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 nonproft trade association
for the advancement, promotion and standardization of embedded Linux. Since September 9, 2005 the ELC Platform
Specifcation has been hosted by The Linux Foundation. The Embedded Linux Consortium transferred the ELC
Platform Specifcation (ELCPS) and related intellectual property to The Linux Foundation. The ELCPS can be found
here: Embedded Linux Platform Specifcation.
Comparing Linux and QNX
Footprint
Although designed to run PC platforms, Linux is also a reliable OS for embedded systems. The typical shrink-
wrapped 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 confguration. 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 fle 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.
LI NUX
TRAI NI NG
5 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
C, C++
C, C++, C#, Java and most others
Compilers and
Runtimes
GNU GCC
C/C++/Java
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
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; Certifed Plus; Secure Kernel; Safe Kernel; RTOS
v4
Wind River Linux; MontaVista Linux; LynuxWorks Inc.; iMedia
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 fle system support Excellent fle system support
FS Support of QNX/
Linux
Limited Support of Ext2 fle system
v
Limited support of QNX6, QNX4 and QNX2 fle systems
vi vii
GUI Photon and a Qt port Several GUI Choices including embedded specifc
viii
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, fle locks, anonymous and named
pipes, system V IPC, UNIX domain sockets.
Kernel Programming
Languages
C C
LI NUX
TRAI NI NG
6 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, effcient, robust and reliable Is proven to be sophisticated, effcient, robust and reliable
Memory QNX does not support a swap fle 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 fle 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
OS Load ROM Compressed kernel and root tools Compressed kernel and root tools
Process
Management
FIFO, adaptive, round robin; Fully preemptible; External of kernel
(but shares kernel address space)
FIFO, adaptive, round robin; Not fully preemptible without
available RTOS modifcations; 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 protection
ix
but if desired, Neutrino can also run with or without an
MMU
x
and Linux cant
2. Embedded Linux has a non-preemptive scheduler
3. We lose the simple IPC
4. The fle system and swap fle requirements of Linux cause trouble and cost money
5. Embedded Linux over-commits memory
LI NUX
TRAI NI NG
7 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 architectures
xii
, 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
handlers
xv
. 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 inter-
process 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.
LI NUX
TRAI NI NG
8 Migrating from QNX to Embedded Linux
4. Filesystem and Swap
For embedded Linux, a small ramdisk is suffcient for most needs and is part of the boot process already (initrd). This
fle system can be mounted as a root fle 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 fash 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 confgure the Linux kernel.
xxi xxii
There
are patches that fx 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 fat 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 diffcult in a market becoming more complex and far less limited.
LI NUX
TRAI NI NG
9 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 confgurable
multi-target
embedded development system
with POSIX compliance
and ANSI C coding
that uses an Eclipse based IDE
TO
Embedded Linux:
A confgurable
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 industry-
standard 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-specifc 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 fnd
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.
LI NUX
TRAI NI NG
10 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 benefts 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 specifcally 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 fnally 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 fxes are included. Every new release of
Yocto also provides updated recipes and templates to track changes, features and bug fxes 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 platform-
independent, 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 workfow based on
OpenEmbedded. User Confguration, Metadata,
Hardware Confguration, and Policy Confguration
determine what Upstream Projects, Local Projects
on the developers system and what sources from
Developer Layer
Commercial (OSV) Layer
UI-Specifc Layer
Hardware-Specifc BSP Layer
Yocto Layer (meta-yocto)
OpenEmbedded Core Layer (oe-core)
Figure 1: Yocto Project Architecture (Source: www.yoctoproject.org)
LI NUX
TRAI NI NG
11 Migrating from QNX to Embedded Linux
optional Source Change Management systems to include, as well as to control the individual process steps of
the workfow. A Yocto Project release already contains confguration information and metadata that will produce a
working Linux system image, thereby requiring minimal adaption to the developers local build environment.
Figure 2: OpenEmbedded Architecture Workfow (Source: www.yoctoproject.org)
Figure 2 also shows the linear workfow process for creating a Linux image and SKD. The steps consist of: Source
Fetching, Patch Application, Confgure/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 profles
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 fle 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 fle 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 profling tools as well as debug
symbols.
poky-image-lsb - An image suitable for implementations that need to conform to Linux Standard Base (LSB).
OpenEmbedded Architecture Workfow
Upstream Source
Metadata/Input
Build System
Process Steps
Output Packages
Images/SDK
Upstream
Project
Releases
Local
Projects
SCM
(Optional)
Source Mirror(s)
User
Confguration
Metadata
Hardware
Confguration
Policy
Confguration
Source
Fetching
Patch
Application
Confgure
Compile
Output
Analysis
For
Packaging
RPM
Creation
DEB
Creation
IPK
Creation
QA
Tests
Package Feeds
Image
Creation
SDK
Creation
Images
Application
Development
SDK
LI NUX
TRAI NI NG
12 Migrating from QNX to Embedded Linux
meta-toolchain - This profle 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 profle creates an archive that contains everything of the meta-toolchain profle but
also includes headers and libraries to form a complete standalone SDK.
The above list represents the most commonly used profles. Many more specialized profles 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 specifc 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
LI NUX
TRAI NI NG
13 Migrating from QNX to Embedded Linux
Training
Often overlooked but always a signifcant 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 confguration 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 specifcally 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 offces.
LI NUX
TRAI NI NG
14 Migrating from QNX to Embedded Linux
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 fexible 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 ft 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.
LI NUX
TRAI NI NG
15 Migrating from QNX to Embedded Linux
Resources
The Cathedral and the Bazaar (Eric Steven Raymond)
Embedded Distributions (LWN.net)
The Embeddable Linux Kernel Subset (ELKS)
Embedded Linux Platform Specifcation (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 frst 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.
LI NUX
TRAI NI NG
16 Migrating from QNX to Embedded Linux
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 flesystem driver for Linux: QNX4, QNX6 & foppy 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 Notifcation http://kerneltrap.org/Linux/Out_of_Memory_Notifcation
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/
LI NUX
TRAI NI NG
17 Migrating from QNX to Embedded Linux
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
LI NUX
TRAI NI NG
The Linux Foundation promotes, protects and advances Linux by
providing unifed 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/.