Migrating From QNX to Embedded Linux

LINUXTRAINING

Migrating from QNX to Embedded Linux

July 2012

A LINUX FOUNDATION PUBLICATION

Embedded OS development porting for those migrating from QNX

LINUXTRAINING

2 Migrating from QNX to Embedded Linux

AbstractIn 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.

IntroductionWhy 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.

Migrating from QNX to Embedded Linux

LINUXTRAINING


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 IssuesPorting 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 reconfigurable 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 ResourcesTwo 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 LinuxWhy 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, FlexibilityThe 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

LINUXTRAINING


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 VendorThe 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 FoundationEmbedded 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 QNXFootprintAlthough 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 WeightLinux 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.

LINUXTRAINING


QNX Linux Comparison Reference TableAttribute QNX Linux

APIStandard and widely supported APIsUses ANSI Standards

Standard and widely supported APIsUses ANSI Standards

Design Designed for embedded use, scalableLinux 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 GCCC/C++/Java

GNU GCC; IBM C/C++, Fortran; Open64 Open Research Compiler; g95 Production Fortran 95clang 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; Certified 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 file system support Excellent file system supportFS Support of QNX/Linux

Limited Support of Ext2 file systemv 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

C C

LINUXTRAINING


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 reliableMemory 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 ProcessingAviage HMI SuiteAviage 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

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 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 LinuxA 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 Linux1. QNX uses the CPUs MMU for memory protectionix but if desired, Neutrino can also run with or without an

MMUx and Linux cant2. Embedded Linux has a non-preemptive scheduler3. We lose the simple IPC4. The file system and swap file requirements of Linux cause trouble and cost money5. Embedded Linux over-commits memory

LINUXTRAINING


6. The OOM Killer Task Issue is insurmountable7. The QNX microkernel never, ever crashes - Linux does8. Retraining will be too hard9. Porting the application code will be painful10. Licensing is too hard11. Too many distributions to sort through with no single universal plug-and-play embedded Linux distribution12. 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 Facts1. Linux - No MMU RequiredEmbedded 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 IncludedThe 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. IPCFor 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.

LINUXTRAINING


4. Filesystem and SwapFor 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 TaskThese 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 microkernelThere 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: [email protected] (Linus Torvalds)Newsgroups: comp.os.qnx,comp.sys.amiga.misc,comp.os.linux.miscSubject: Re: Amiga, QNX, Linux and RevolutionDate: 3 Sep 1999 19:03:10 GMT

In article , John Birch 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.

LINUXTRAINING


8. TrainingNew 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:

FROMQNX:

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

TOEmbedded 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 LinuxPorting 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-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.

LINUXTRAINING


10. LicensingMany 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 SupportIts 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 ProjectThe 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 StructureAt 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 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)

LINUXTRAINING


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.

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).

OpenEmbedded Architecture WorkflowUpstream SourceMetadata/InputBuild System

Process StepsOutput PackagesImages/SDK

UpstreamProject

Releases

LocalProjects

SCM(Optional)

Source Mirror(s)

UserConfiguration

Metadata

HardwareConfiguration

PolicyConfiguration

SourceFetching

PatchApplication

ConfigureCompile

OutputAnalysis

ForPackaging

RPM Creation

DEBCreation

IPK Creation

QA Tests

Package Feeds

ImageCreation

SDKCreation

ImagesApplication

DevelopmentSDK

LINUXTRAINING


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 & ToolsYocto 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

PlatformsYocto supports popular hardware including:

ARM MIPS PowerPC x86 architectures

Yocto Project CollaboratorsThe 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 FoundationAMDARMCiscoDellFujitsuHewlett-PackardHitachi

IBMIntelMentor GraphicsMotorolaNECOpenEmbeddedOracleQualcomm

SonySuSeTexas InstrumentsTexas InstrumentsTimesysWind RiverYocto Adobeand many more

LINUXTRAINING


TrainingOften 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 CoursesLF488 Implementation and Management of Open Source Compliance LF320 Linux Kernel Internals and DebuggingLF426 Linux Performance Tuning LF315 Inside Android: An Intro to Android InternalsLF425 Linux Performance Tuning Crash Course LF312 Developing Applications For LinuxLF411 Embedded Linux Development LF295 Android BootcampLF410 Embedded Linux Development: A Crash Course LF281 Executive Review of Open Source ComplianceLF405 Building Embedded Linux with the Yocto Project LF273 Tizen Training For Non-DevelopersLF404 Building Embedded Linux with the Yocto Project: Crash Course LF272 Open Source Compliance Programs - What You Must KnowLF384 Overview of Open Source Compliance End-to-End Process LF271 Practical Guide to Open Source DevelopmentLF363 Portable Application Development for Tizen Devices LF262 Developing with GITLF331 Developing Linux Device Drivers LF211 Introduction to Linux for DevelopersLF329 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.

LINUXTRAINING


ConclusionBoth 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.

LINUXTRAINING


ResourcesThe 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 AuthorTW 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.

LINUXTRAINING


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/

LINUXTRAINING


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

LINUXTRAINING

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 athttp://www.linuxfoundation.org/.

Documents

Migrating From QNX to Embedded Linux