QNX Neutrino RTOS The QNX® Neutrino® RTOS is a …docenti.unicam.it/tmp/3724.pdf · smartphones...

11/4/2014 QNX Neutrino RTOS

http://www.qnx.com/products/neutrino-rtos/neutrino-rtos.html 1/19

QNX Neutrino RTOS

The QNX® Neutrino® RTOS is a full-featured and robust OS that scales down to meet the constrained resource

requirements of realtime embedded systems. Its true microkernel design and its modular architecture enable

customers to create highly optimized and reliable systems with low total cost of ownership. It offers the

embedded industry’s only field-proven, clean strategy for migrating from single-core to multi-core

processing.

QNX Neutrino RTOS architecture

Because every driver, protocol stack, filesystem, and application runs in the safety of memory-

protected user space, virtually any component can be automatically restarted if it fails.

Tr u e micr oker n e l O S

The QNX Neutrino RTOS (realtime operating system) is so reliable because it is a true microkernel operating

system.

Under QNX Neutrino, every driver, protocol stack, filesystem and application runs in the safety of memory-

protected user space, outside the kernel. Virtually any component can fail — and be automatically restarted —

without affecting other components or the kernel. No other commercial RTOS offers this degree of protection

and isolation.

Advan ces in s ecu r i ty

The QNX Neutrino RTOS has innovative security mechanisms designed to help you easily build impenetrable

devices. Encrypted filesystems, memory guard pages, and limited root permissions are core features of the

operating system that can be used to create secure and reliable devices.

Gr aph ics an d HMI tech n ologies

The QNX graphics technologies use hardware layering (pipelines) for combining multiple content sources

together into a single image. Display images from video, OpenGL ES, HTML5, and Qt 5 on a single display.

Combine those graphics technologies with Neutrino’s support for multi-touch UIs and video capture, to build

embedded devices that meet the user interface expectations that have been set by mobile devices, such as

smartphones and automotive infotainment systems.

Mu lt icor e migr at ion

The QNX Neutrino RTOS has a field-proven strategy for migrating from single-processor to multi-processor

embedded environments. Its unique bound multi-processing (BMP) technology takes the risk out of migration

by enabling developers to decide exactly where every process and thread will run.

The QNX® Neutrino® RTOS offers great economic and technical advantages thanks to its ability to extract

extremely fast, predictable response times from inexpensive embedded hardware.

High r e l iabi l i ty with low r is k

Since 1980, manufacturers have relied on QNX RTOS technology to power their mission-critical applications —

everything from medical instruments and Internet routers to telematics devices, 911 call centers, process

control applications, and air traffic control systems.

Small or large, simple or distributed, these systems share an unmatched reputation for operating 24 hours a

day, 365 days a year. Time-tested and field-proven, the QNX Neutrino RTOS sets the industry standard for

reliability, fault tolerance, and scalability.

Advan ced s ecu r i ty mech an is ms

QNX brings advanced security mechanisms that are built directly into the OS and kernel. With QNX you can

build a system that offers the best possible security measures, thanks to:

Granular contro l o f system privi lege leve ls – restrict processes’ capabilities to only the elevated

privilege level that is necessary for the specific commands, without providing the process with access to

http://www.qnx.com/images/products/rtos/rtos_800.png

http://www.qnx.com/images/products/rtos/rtos_800.png



the entire system by elevating it to root privilege

Encrypted f i lesystems – the filesystem can be encrypted by dividing it into encryption domains, which

can be locked, or unlocked for access

Read-only f i lesystems – protect data using a read-only filesystem that compresses the files in blocks,

yet still supports random access

Reduced security attack surface – all processes, including drivers, filesystems, etc. execute in user-

mode, greatly reducing the ability of compromised processes

Heap, Stack, and Memory Pro tection – heap, stack, and allocated memory blocks are protected by

“guard pages” that the microkernel uses to detect and trap stack overflows

ASLR – The heap is protected by address space layout randomization (ASLR), which randomizes the

stack start address and code locations in executable and libraries, and heap cookies

R edu ced power con s u mpt ion

QNX brings advanced thermal and power management capabilities that are built directly into the OS and

kernel, to reduce the power consumed by mobile and powered devices, through:

Tickless mode – skip unnecessary clock ticks when system is in an idle state

Tolerant timers – timers can have a tolerance for non-realtime timer requirements (e.g. UI response timers)

Lazy interrupts – interrupts can have acceptable latencies for non-realtime devices (e.g. keyboard interrupt

events)

Dynamic Voltage and Frequency Scaling – DVFS for ARM Cortex SoCs

Su ppor t for lates t mobi le gr aph ics tech n iqu es

The QNX Neutrino RTOS provides a level of graphical and mobile techniques not offered by any other

commercial RTOS.

QNX delivers a compositing windowing system which integrates multiple graphics and user interface (UI)

technologies into a single scene. This scene is then rendered into one image that is associated with a display.

This allows the designer to use the most appropriate graphics technology that corresponds with the image,

be it video, Open GL ES, HTML5, or Qt 5.

Multi touch input control – QNX supports multi-touch graphical displays that are popular in mobile devices

Video capture – frames can be captured from a video source and displayed using the compositing

windowing system

OpenWF Display (WFD) API – driver architecture based on the WFD APIs

Multiple source graphics – graphics subsystem can render images from multiple sources onto a single

display

Con n ect to oth er dev ices u s in g th e lates t tech n iqu es

QNX Neutrino RTOS provides support for the latest in wired and wireless networking, and connectivity

options, making the job of the designer simpler and faster due to:

USB 3.0 – support for USB 3.0 is included for the latest OMAP and x86 hardware

USB device – support device class drivers for CDC ACM (serial), USB Mass Storage and CDC_NCM

(Network)

USB On-The-Go (OTG) Support – USB OTG systems can drop the hosting role and act as normal USB

devices when attached to another host

Low BO M cos t

The QNX Neutrino RTOS is the perfect OS for reducing the per-unit costs of embedded hardware. It can offer

the best possible performance, even on inexpensive hardware, thanks to:

True realtime OS design – predictable response times and extremely fast interrupt latencies and context

switches

Microkernel architecture – robust, self-healing systems

Adaptive partitioning – optimal use of all available CPU capacity for high performance with a small

memory footprint

Self - h eal in g s ys tems

The QNX Neutrino RTOS provides a level of fault containment and recovery offered by no other commercial

RTOS.

Its microkernel architecture has every driver, protocol stack, filesystem and application run outside the kernel,

in the safety of memory-protected user space. Virtually any component can fail and be automatically restarted

without affecting other components or the kernel.

Scale f r om s mal l to lar ge

The same RTOS, tools, APIs, and source code are used for developing and implementing systems to meet all

manner of requirements for single-processor and multi-processor systems, large and small.

Gu ar an teed s ys tem r es ou r ces

QNX adaptive partitioning technololgy can guarantee system resources for all applications as needed. Under

normal operating conditions it allows applications to use all available CPU cycles, but during overload



conditions, it enforces hard resource guarantees to ensure that all applications receive their budgeted share

of resources.

Ex ten s ive boar d s u ppor t

The QNX Neutrino RTOS supports a broad range of x86, PowerPC, ARM, MIPS and SH-4 platforms.

The resource manager framework, which, unlike conventional drivers, runs in memory-protected user space,

simplifies driver development for custom hardware.

Ef f ic ien t pr odu ct deve lopmen t

The QNX Neutrino RTOS enables rapid and efficient product development in a number of ways:

The microkernel architecture facilitates bug identification and resolution, and enables safe and rapid

component upgrades without costly downtimes or system outages

Just one OS and one set of binaries can target single-processor devices, SMP systems, or processor

clusters

Open-source UNIX, Linux, and other code can be ported with a simple recompile because QNX Neutrino is

engineered to the POSIX standard (1003.1-2001 POSIX.1)

Standard POSIX APIs not only let developers easily reuse application code but also provide a familiar

development environment

Development teams can reuse code and reduce their verification efforts thanks to field-tested binaries —

drivers, applications, custom OS services – which can be implemented across entire product lines

Out-of-the-box support for a wide range of networking protocols and flash filesystems, and a built-in high

availability solution reduce overall development work

The QNX® Neutrino® RTOS is a full-featured and robust OS with a number of unique technological features

that set it apart from all other competitive products.

R ealt ime

The QNX Neutrino RTOS provides deterministic response times at the application level and in all

subsystems. Thread priority inheritance eliminates priority inversion problems.


Thanks to the microkernel architecture of the QNX Neutrino RTOS, virtually any component — even a low-

level driver — can fail without damaging the kernel or other components. What's more, failed components

can be restarted quickly and intelligently.

Adapt ive par t i t ion in g

With the QNX Neutrino RTOS, spare CPU capacity is used when available. If resources are constrained,

processes get their budgeted share. If, however, a system has spare cycles, processes can exceed their

budget limits.

High avai labi l i ty

If a device driver, protocol stack, or application experiences a problem, it does not take other components

down with it. The QNX Neutrino RTOS high availability manager can terminate and restore the faulting

component in isolation — often in just a few milliseconds without a reboot.

Networ kin g

Supported networking technologies include IPv4, IPv6, IPSec, FTP, HTTP, SSH and Telnet. Unique

transparent distributed processing enables an application to access resources on any node in a network

for seamless peer-to-peer resource sharing.

P r otected & en cr ypted f i les ys tems

QNX filesystems execute outside the microkernel in memory-protected user space. Developers can start,

stop, or upgrade filesystems on the fly without having to reboot. Multiple filesystems can run concurrently

on the same target and even work in concert to extend one another's capabilities. Filesystems can be

marked as read-only, compressing the files in blocks while still supporting random access. Filesystems may

also be encrypted and subdivided into encryption domains, rendering the files inaccessible until the

domain is “unlocked”, thus providing further barriers to intrusion and significantly improved security and

hardening of the filesystem.

P or tabi l i ty

Extensive support for POSIX standards facilitates application portability and rapid migration from Linux,

UNIX, and other open source programs.

Runtime support and BSPs for popular chipsets, including ARM, MIPS, PowerPC and x86, lets designers

select the best hardware platform for their embedded system, and then quickly get their systems up and

running.

P ower man agemen t

The QNX Neutrino RTOS offers several power management strategies to help developers meet the

stringent power and heat requirements of many embedded systems. These include:

Tickless mode – optimize clock ticks when system is in idle state

Tole rant t imers – for non-realtime timer requirements (e.g. UI response timers)



Laz y inte rrupts – for non-realtime interrupts (e.g. keyboard interrupt event)

Dynamic Vo ltage and Frequency Scaling (DVFS) – DVFS for ARM Cortex SoCs

Secu r i ty

To address the ever-increasing security threats facing embedded systems, whether they are large

distributed systems or small, isolated industrial controllers, QNX has advanced security mechanisms built

directly into the QNX Neutrino RTOS that protect the device from malicious attacks. These can be used to

ensure that all processes, including drivers and filesystems, execute in user-mode, greatly reducing the

ability of compromised processes. Further, it is possible to divide the filesystem into encrypted domains,

as well as to randomize the address space layout for further protection against malicious intent.

The security attack surface of the system can be further reduced by utilizing a unique ability to control

settings that govern and protect which operations a process can perform, with granularity down to the

system-call level. As a result, embedded developers no longer have to give processes root permissions

and access to the entire system in order to gain access to necessary system resources.

Gr aph ics

With the QNX Neutrino RTOS, developers can build graphically rich, compelling user interfaces (UIs) using

built-in, high-performance OpenGL-ES based transitions, support multi-touch displays, and render images

from Qt, HTML5, video, and other technologies through a single compositing windowing system. This

system integrates multiple graphics and UI technologies into a single scene.

In tegr ated tool ch ain

The QNX® Momentics® Tool Suite offers all the development and debugging features commonly found in

other Eclipse-based IDEs, plus unique QNX capabilities, such as multicore profiling and an instrumented

kernel.

Eclipse provides well-defined interfaces to ensure that tools work together seamlessly. Developers also

benefit from an open, extensible platform for tool integration supported by a large and rapidly growing

community of tool vendors and developers. They can plug in third-party tools, or build their own plug-ins

using the industry-standard Eclipse framework.

QNX has advanced security mechanisms that are built directly into the QNX Neutrino RTOS that protect the

device from malicious attacks. These can be used to encrypt the filesystem and reduce the attack surface

of the system by restricting the privilege levels for elevated processes and by randomizing the address

space layout.

Acces s con tr o l l is ts

Some filesystems, such as the Power-Safe (fs-qnx6.so) filesystem, extend file permissions with Access

Control Lists (ACLs), which are based on the withdrawn IEEE POSIX 1003.1e and 1003.2c draft standards.

ACLs extend the traditional permissions as set with chmod, providing finer control over who has access to

files and directories within the system.

With the traditional file permissions as set with chmod, there are few choices for providing special access

to a file:

Adding that person to the owning group

Creating a supplemental group that includes that person and the owner of the file

Loosening the permissions for "others"

Keeping track of the users in each group can become complicated, and allowing "others" additional

permissions can make the system less secure. Access Control Lists extend file permissions, giving you finer

control over who has access to files.

ACLs allow the administrators to specifically add, then view, users that can be permitted specific levels of

access beyond simply "users", "groups", and "others". The permissions for these classifications can also

contain specific user names at the corresponding access level.

Gr an u lar con tr o l o f s ys tem pr iv i lege leve ls

No longer is it necessary to elevate the privilege of a process to root when that process needs to access

system resources. The QNX Neutrino RTOS supports process-manager settings that govern permitted

operations for a particular process.

A privileged process can obtain these abilities before dropping root privileges, which lets it retain some

functionality that historically would have been restricted to root. Furthermore, these process-manager

settings can be locked, meaning that even root users can't carry out certain actions that they might

historically have been able to. This change significantly reduces the attack surface of the system, even

when dealing with a root process.

R edu ced at tack s u r face

The attack surface of the system is further reduced by the inherent characteristic that all processes

including drivers and filesystems, execute in user-mode, greatly reducing the ability of compromised

processes. Combined with the granular control of system privilege levels, any compromised process will

be significantly restricted in its ability to affect harm or gain elevated access.

Heap an d s tack pr otect ion , an d ASLR

The heap is protected by address space layout randomization (ASLR), which randomizes the stack start

address and code locations in executable and libraries, and heap cookies. Stack guard pages protect

against stack overflows. At the end of each virtual stack is a guard page that the microkernel uses to detect



stack overflows. If a program writes to an address within the guard page, the microkernel detects the error

and sends the process a SIGSEGV signal.

In addition, malloc has been modified to place guard regions at both ends of allocated memory blocks in

order to trap rogue code and prevent malicious intent.

En cr ypted f i les ys tems

All or part of the contents of a QNX6FS power-safe filesystem can be encrypted by dividing it into

encryption domains.

A domain can contain any number of files or directories. After a domain has been assigned to a directory,

all files created within that directory are encrypted and inherit that same domain. By default, assigning a

domain key to a directory with existing files or directories doesn't introduce encryption to those files.

During operation, files that are assigned to a domain are encrypted, and the files' contents are available

only when the associated domain is unlocked. When a domain is unlocked, all the files and directories

under that domain are unlocked as well, and are therefore accessible (as per basic file permissions). When

a domain is locked, any access to files belonging to that domain is denied.

The encrypted filesystem uses:

AES-256 in CBC mode

AES-256 in XTS mode

Encryption keys can be private and randomly generated on a per-file or per-domain level, or they can be

optionally public, and managed external to the filesystem. There is a master system key which is private

and randomly generated only once, and is used to encrypt all the domain master keys.

With its pre-emptible microkernel and priority-based preemptive scheduler, the QNX Neutrino RTOS

delivers response times that are both fast and highly predictable. High-priority threads can meet their

deadlines on time, every time, even under heavy system load.

A comprehensive, integrated set of technologies supports the realtime reliability and performance of the

QNX Neutrino RTOS, including:

Fast interrupt latencies and context switches that help squeeze the fastest possible response time from

embedded hardware

Priority inheritance to eliminate priority inversion

Simplified modeling of realtime activities through synchronous message passing

Nested interrupts and a fixed upper bound on interrupt latency to ensure that high-priority interrupts are

handled first, within a predictable timeframe

The QNX Neutrino RTOS is a true microkernel operating system and, as such, the microkernel includes only

the most fundamental services, such as signals, timers, and schedulers. All other components —

filesystems, drivers, protocol stacks, and applications — run in the safety of memory-protected user space.

Fault resilience is built right in.

All OS components communicate via a single, well-defined messaging layer. This messaging layer forms a

virtual "software bus" that permits the addition — plug in — and removal of software components at any

time. Messages flow transparently across processor boundaries, providing seamless access to any

resource, anywhere on the network.

QNX Neutrino RTOS microkernel

The QNX Neutrino RTOS microkernel isolates processes in memory-protected user space.

http://www.qnx.com/images/products/rtos/QNX_microkernel_wheel_03_10_D3_800.jpg




The principles behind the QNX microkernel architecture have been proven through more than three

decades of implementations in the most exacting environments:

Virtually any component, even a low-level driver, can fail without damaging the kernel or other

components

If a component fails, the OS can cleanly terminate it and reclaim any resources it was using — no need to

reboot

Failed components can be restarted quickly and intelligently, using the operating system's high

availability manager

Simpl i f ied des ign

Inherently modular, the QNX Neutrino RTOS microkernel architecture simplifies the design of modular and

easy-to-maintain systems. Distributed messaging:

Provides a consistent form of inter-process communication (IPC)

Enables scalable, distributed, fault-resilient systems that can transparently share resources across

almost any chassis, fabric, or interconnect

Automatically synchronizes the execution of cooperating components

Eliminates the need to track complicated queuing behavior

Partitions complex applications into cleanly separated building blocks, which can be individually

developed and tested

Allows system services to be accessed via simple, industry-standard POSIX function calls — there is no

need to manage a complex messaging layer

QNX adaptive partitioning is a simple, reliable solution for processor-intensive systems where task

starvation is not an option. It ensures that critical processes are never starved of resources and always meet

realtime deadlines.

Adaptive partitioning eliminates the over-engineering required by fixed-partitioning designs, which waste

unused cycles and force designers to use more-expensive CPUs. It thus both improves product time to

market and does away with the complex task-starvation problems that typically arise during a project’s

integration phase.

QNX Neutrino RTOS adaptive partitioning

QNX adaptive partitioning offers applications unused CPU capacity while guaranteeing required CPU

cycles to critical processes.

A u n iqu e appr oach

QNX adaptive partitioning is a unique partitioning approach. It provides minimum CPU time guarantees to

partitions (sets of processes or threads), while allowing partitions to exceed their time budgets when spare

processing cycles are available.

The system designer can reserve a percentage of processing resources for a specific partition. Under

normal operating conditions, partitions can use whatever CPU cycles are available. However, during an

overload when more computation is required than the system can sustain over time, the QNX adaptive

partitioning scheduler enforces limits on the CPU cycles that each partition is permitted to consume,

guaranteeing that the minimum required CPU resources are always available for specified processes.

Sys tem e f f ic ien cy

By its very nature, QNX adaptive partitioning is more efficient than fixed partitioning.

Fixed partitioning designs, such as ARINC 653, are inherently inefficient. Spare CPU capacity in a

partition cannot be temporarily borrowed by other partitions, so CPU budgets must be set in advance to

anticipate peak demand.

With QNX adaptive partitioning, spare CPU capacity is used when it is available. Processes can exceed

their budget limits if the overall system has available cycles. When CPU resources are constrained,

budgets are enforced and every part of the system gets its fair share.

http://www.qnx.com/images/products/rtos/QNX_microkernel_wheel_03_10_D3_800.jpg

http://www.qnx.com/images/products/rtos/adaptive_partitioning_D4_800.gif

http://www.qnx.com/images/products/rtos/adaptive_partitioning_D4_800.gif



Impr oved s ys tem s ecu r i ty

QNX adaptive partitioning fundamentally improves system security:

Developers and integrators can isolate downloadable content to secure partitions, thwarting denial-of-

service (DoS) attacks

Malicious or unvalidated software that monopolizes system resources can’t starve critical functions of

CPU time


QNX adaptive partitioning helps create fault tolerant and self-healing systems:

Guaranteed CPU cycles for error detection and system-recovery operations ensures rapid system

recovery

Operators and administrators with access to the user interface — a console or a remote — can always

determine the system state, regardless of processor load

Gu ar an teed r eal t ime deadl in es

QNX adaptive partitioning technology provides flexible scheduling while maintaining real time

determinism:

Available CPU cycles are dynamically assigned from partitions that aren’t busy to partitions that can

benefit from extra processing time

Available CPU cycles always go to the highest priority, ready-to-run thread in the system

Developers can designate critical threads as guaranteed to run regardless of partition budget and

system load

Gu ar an teed even t r es pon s es

QNX adaptive partitioning helps system designers guarantee responses to events without complex

manipulation of process and thread priorities:

A minimum CPU budget allocated to a device’s user interface can guarantee that it rapidly and

invariably responds to user actions, such as a button push or voice command

CPU cycle guarantees for media players can ensure that they always get the cycles they need to deliver

smooth, continuous playback — eliminating skipping or pauses in media playback


QNX adaptive partitioning reduces the time and effort needed to integrate and debug embedded

systems:

Developers can set aside CPU budgets for individual parts of the system to ensure fair sharing of

system resources, avoiding the need to normalize priority schemes across the system, which is time

consuming and error prone

Developers and integrators can monitor and reset budgets as determined by their projects’ unique

requirements — all without writing or even recompiling code

Simpl i f ied in tegr at ion

No extra work is required to integrate QNX adaptive partitioning technology into a system.

Adaptive partitioning can be added to a system with minimal effort — no recoding (or even recompiling)

of applications is required

Partition parameters are configured, not programmed: no code changes are necessary to implement

CPU guarantees for specified processes

The QNX Neutrino RTOS implements two simple principles to ensure high availability:

Fault iso lat ion — segregate failures in well-defined software components to minimize their impact on

overall system availability.

Recovery — detect faults and automate recovery without system reboots to minimize mean time to

repair (MTTR)

These principles are embodied in the QNX Neutrino RTOS microkernel architecture, which ensures that a

component failure is constrained to that component, and the High Availability Framework, which provides

the infrastructure for fault detection and recovery.

In addition, the QNX Neutrino RTOS supports high availability through:

Redundant se rvices — transparent distributed processing (network distributed architecture) enables

rapid building of redundant services

Guaranteed CPU resources — adaptive partitioning guarantees minimal CPU time and memory to

critical software components, ensuring that they have the resources they need under all conditions

F au lt is o lat ion — th e micr oker n e l

The QNX RTOS microkernel architecture isolates faults, ensuring that a component failure is constrained to

that component:



Full MMU-based memory protection for all components ensures that a failure in one component cannot

corrupt other components or the OS kernel

Device drivers and system services, such as networking and filesystems, can be restarted automatically

without affecting other software components

POSIX process model enforces clear resource ownership and automatic cleanup by QNX Neutrino when

processes terminate abnormally

R ecover y — th e High Avai labi l i ty F r amewor k

The QNX High Availability Framework provides a reliable software infrastructure on which to build highly

effective high availability systems. As well as supporting hardware-oriented high availability solutions, it

provides developers with tools to isolate and even repair software faults before they domino through a

system.

With the High Availability framework, developers can quickly construct custom failure recovery scenarios

and design systems to recover quickly and transparently.


The High Availability Framework enables developers to build and implement self-healing systems:

Automatic restart of failed processes — without a system rebooting

Automatic recovery of inter-process communications following process failures

Customized failure recovery actions, where applications identify failure conditions and perform

specified activities to mitigate consequences and speed recovery

High Avai labi l i ty Man ager

The High Availability Manager (HAM) is a "smart watchdog" — a highly resilient manager process that

monitors a system and performs multi-stage recovery whenever system services or processes fail or no

longer respond.

As a self-monitoring manager, the HAM is resilient to internal failures. If, for whatever reason, the HAM itself

is stopped abnormally, it can immediately and completely reconstruct its own state by handing over to a

mirror process.

The High Availability Framework includes a HAM API library, which offers a simple, thread-safe mechanism

for communicating with the HAM, and a client recovery library, which provides a drop-in enhancement

solution for many standard libc I/O operations.

QNX Neutrino RTOS networking support includes an ever-expanding list of protocols, including:

IPv4/IPv6 (based on NetBSD 4.0)

SNMP v1/v2/v3

L2 VLAN, QoS, STP

802.11a/b/g, WPA, WPA2, WEP

Security protocol suite support includes:

IPSec, IKE, SSL, SSH, NAT, IP filtering

Open cryptography API

hardware acceleration support for packet handling

TCP / IP Stack R F C Su ppor t

QNX Software Systems is continuously expanding its networking support. If you cannot find the protocols

you need, please contact us for the very latest information.

IPv6 stack (npm-tcpip-v6.so) [+] More

2367 PF_KEY Key Management API, Version 2

1826 IP Authentication Header

2402 IP Authentication Header

2403 The Use of HMAC-MD5-96 within ESP and AH

2404 The Use of HMAC-SHA-1-96 within ESP and AH

2405 The ESP DES-CBC Cipher Algorithm With Explicit IV

2406 IP Encapsulating Security Payload (ESP)

1828 IP Authentication using Keyed MD5.

1829 The ESP DES-CBC Transform

1852 IP Authentication using Keyed SHA

2841 IP Authentication using Keyed SHA1 with Interleaved Padding (IP-MAC)

2292 Advanced Sockets API for IPv6

2553 Basic Socket Interface Extensions for IPv6

2463 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification

2460 Internet Protocol, Version 6 (IPv6) Specification

2461 Neighbor Discovery for IP Version 6 (IPv6)

2462 IPv6 Stateless Address Autoconfiguration

2451 The ESP CBC-Mode Cipher Algorithms

1981 Path MTU Discovery for IP version 6

2373 IP Version 6 Addressing Architecture

2144 The CAST-128 Encryption Algorithm

2401 Security Architecture for the Internet Protocol

2960 Stream Control Transmission Protocol (SCTP)

3257 Stream Control Transmission Protocol Applicability Statement



3309 Stream Control Transmission Protocol (SCTP) Checksum Change

3286 An Introduction to SCTP

2526 Reserved IPv6 Subnet Anycast Addresses

2374 An IPv6 Aggregatable Global Unicast Address Format

2375 IPv6 Multicast Address Assignments

2473 Generic Packet Tunneling in IPv6 Specification

2464 Transmission of IPv6 Packets over Ethernet Networks

2893 (Portions of) Transition Mechanisms for IPv6 Hosts and Routers

1701 Generic Routing Encapsulation (GRE)

1702 Generic Routing Encapsulation over IPv4 networks

2710 Multicast Listener Discovery (MLD) for IPv6

2711 IPv6 Router Alert Option

3493 Basic Socket Interface Extensions for IPv6

3602 The AES-CBC Cipher Algorithm and Its Use with IPsec

2410 The NULL Encryption Algorithm and Its Use with IPsec

2408 Internet Security Association and Key Management Protocol (ISAKMP)

2407 Internet IP Security Domain of Interpretation for ISAKMP

2631 Diffie-Hellman Key Agreement Method

1933 Transition Mechanisms for IPv6 Hosts and Routers

NIST, "Digital Signature Standard", FIPS 186, National Institute of Standards and Technology, U.S.

Department of Commerce.

Rivest, R., Shamir, A., and Adleman, L., "A Method for Obtaining Digital Signatures and Public-Key

Cryptosystems", Communications of the ACM, v. 21, n. 2, February 1978.

IPv4 full stack (npm-tcpip-v4.so) [+] More

791 INTERNET PROTOCOL - DARPA INTERNET PROGRAM - PROTOCOL SPECIFICATION

792 INTERNET CONTROL MESSAGE PROTOCOL - DARPA INTERNET PROGRAM - PROTOCOL

SPECIFICATION

793 Transmission Control Protocol (TCP)

768 User Datagram Protocol

1122 Requirements for Internet Hosts -- Communication Layers

2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms

1112 Host Extensions for IP Multicasting

1323 TCP Extensions for High Performance

826 An Ethernet Address Resolution Protocol

2236 Internet Group Management Protocol, Version 2

894 A Standard for the Transmission of IP Datagrams over Ethernet Networks

IPv4 tiny stack (npm-ttcpip.so) [+] More

791 INTERNET PROTOCOL - DARPA INTERNET PROGRAM - PROTOCOL SPECIFICATION

793 Transmission Control Protocol (TCP)

768 User Datagram Protocol

826 An Ethernet Address Resolution Protocol

894 A Standard for the Transmission of IP Datagrams over Ethernet Networks

1812 (Portions of) Requirements for IP Version 4 Routers

Application RFC Support

1123 Requirements for Internet Hosts -- Application and Support

1700 Assigned Numbers

951 BOOTSTRAP PROTOCOL (BOOTP)

2409 The Internet Key Exchange (IKE)

1542 Clarifications and Extensions for the Bootstrap Protocol

1048 BOOTP Vendor Information Extensions

1084 BOOTP Vendor Information Extensions

854 TELNET PROTOCOL SPECIFICATION

1408 Telnet Environment Option

1572 Telnet Environment Option

959 FILE TRANSFER PROTOCOL (FTP)

2389 Feature negotiation mechanism for the File Transfer Protocol

2428 FTP

QNX’s Transparent Distributed Processing (TDP) technology enables seamless peer-to-peer resource

sharing on a network. It is ideal for:

"In the box" networking equipment, where it can be used over backplanes and interconnection

technologies

Industrial control systems applications, such as distributed monitoring, management, and control

O ptimal u s e of s h ar ed r es ou r ces

TDP extends the QNX message passing architecture across virtually any network interconnection

technology. It provides a framework for the dynamic interconnection of hardware and software resources

(message queues, filesystems, services, databases) located on remote nodes, using standard messages.

Resources have true location independence: software on any node can access any published resource.

Transparent distributed processing



QNX transparent distributed processing allows an application to access resources on any node in the

network, across virtually any network interconnection technology.

Locat ion in depen den ce

Complete location independence is supported by a central directory of global naming and location

services:

Registration by multiple cards for the same service

Automatic supervision and notification of available resources

Flexible deployment and partitioning of applications at runtime

Bu i l t - in r edu n dan cy an d load balan c in g

Redundancy and load balancing are a fundamental quality of systems implementing TDP:

There are inherent supports for multiple links between CPUs, so if one link fails, data is automatically re-

routed over the remaining links, without loss of service

Network traffic can be load-balanced over all available links, resulting in significantly higher throughput

Applications can specify a preferred node for data, but if a failure occurs on that node, the data is

transparently load balanced over the remaining functioning nodes

Su ppor t for var iou s t r an s por ts

Messaging for TDP operates above the transport layer. It works equally well across LANs, backplanes,

proprietary switch fabrics, vehicle buses such as CAN and MOST, and even the Internet.


TDP saves time and costs associated with custom development and incremental hardware. TDP replaces

the traditional custom — and cumbersome — messaging infrastructures required to enable inter-process

communications. No special coding is needed to make applications and servers instantly network

distributed:

No additional network code is required

Processes running on a single CPU will continue to communicate with each other even if they are

subsequently distributed among multiple CPUs, allowing developers to extend resources to networked

nodes and simplify the development of multi-node systems

Developers can create robust and fault-tolerant systems that offer on-demand access to resources on

multiple CPUs, and if a CPU is not available, a similar resource can be transparently accessed on another

CPU — delivering built-in redundancy and load balancing

When debugging, developers can query and collect remote data via a single connection to multiple

cards, ensuring that data can be accessed even in the event of a broken connection

QNX filesystems are robust, portable and efficient.

Execute outside the microkernel, in memory-protected user space, and start, stop, or upgrade

filesystems on the fly, without having to reboot

Accessible through simple POSIX / C API calls: open(), read(), write(), close()

Run concurrently on the same target, and even work in concert to extend one another's capabilities

Q NX path n ame s pace

QNX filesystems all work inside the QNX pathname space. This pathname space allows QNX systems to

seamlessly access filesystems on any computer in a network. QNX systems do not even require a hard

http://www.qnx.com/images/products/rtos/distributed_processing_800.gif

http://www.qnx.com/images/products/rtos/distributed_processing_800.gif



drive or a flash drive to boot. They can be designed to boot from RAM, from another machine in a network,

or from a flash drive offering read-only access.

F i le s ys tems at a g lan ce

Embedded Disk Network Other

Flash

Devices

NOR Flash

NAND Flash

RAM

Temporary

storage

POSIX – QNX Filesystem

Ext2 - Linux

FAT 12, 16, 32 –

Windows/DOS

NTFS (read only) - Windows

ISO9660, Joliet – CD-ROM

Devices

HFS+ (read only) - Apple

Mac OSX

UDF - CDs and DVDs

NFS

Unix connectivity

CIFS

Microsoft

connectivity

Compression

Add compression / decompression to any

file system

Encryption

Encryption can be applied to a QNX6FS

file system

Embedded f i les ys tems — NO R an d NAND f las h

QNX flash filesystem technology delivers reliability at the filesystem level:

Read/write persistent storage resists data corruption from an unexpected reset or a power loss.

Wear-level capability increases the life span of flash parts.

Embedded Transaction Filesystem (ETFS) structure

ETFS is a power-safe filesystem composed entirely of transactions.

P er for man ce

QNX NOR and NAND filesystem performance features include:

Background reclaim, which concurrently performs background garbage collection to reclaim unused

space, mitigating potential I/O delays to find and erase blocks and sectors

RAM filesystem for caching and temporary files

Compression support to optimize use of flash

P O SIX, ISO C f i le s eman t ics , an d tools

QNX NOR and NAND filesystem supports:

Standard file stream operations

Dynamic creation and manipulation of files and directories

Symbolic names, long file names, and permissions

Raw flash can be read and written directly for reprogramming boot loaders via standard POSIX

command line tools such as cp and dd

NO R f las h dev ices

NOR flash devices are supported with the QNX Flash Filesystem version 3 (FFSv3).

F au lt r ecover y

Updates to metadata are handled in carefully executed sequences. This behavior allows for high filesystem

integrity even after power-loss.

After a reset or power-on, the filesystem is scanned, and data integrity is restored wherever possible.

Bad s ector h an dl in g

http://www.qnx.com/images/products/rtos/etfs_D6_800.gif

http://www.qnx.com/images/products/rtos/etfs_D6_800.gif



Sectors with errors are recorded and transparently avoided.

NAND f las h dev ices

NAND flash devices are supported with Embedded Transaction Filesystem (ETFS) technology.

R es is t power fai lu r e cor r u pt ion s

Atomic transactions ensure integrity of file and directory operations, and resist corruptions caused power

failures.

Block in tegr i ty

The QNX filesystem ensures the quality for all blocks on NAND flash devices:

Factory-marked bad blocks are reserved and unused

Blocks are marked for refresh before hitting the normal read degradation limit, avoiding possible ECC

errors and the need to recover data

Au tomat ic f i le de- f r agmen tat ion

The QNX filesystem employs several strategies to prevent data fragmentation:

Write buffering reduces fragmentation by consolidating small write transactions before they are written

to NAND

Background de-fragmentation runs automatically, but is automatically pre-empted by user activity

Bu lk copy s u ppor t

Filesystem data is not block-specific. NAND devices can be bulk copied using a separate flash program.

The QNX Neutrino RTOS offers several fastboot strategies to help developers meet the stringent fast boot

requirements of many embedded systems. These include:

BIOS-less boot — customize the boot sequence to bypass the BIOS

Microkerne l — easily start applications before starting drivers

Instant Device Activation (IDA) — a minidriver starts applications needed to meet early readiness,

then hands control over to a standard boot process

BIO S- les s boot

With the QNX Neutrino RTOS, developers can easily replace standard BIOS with customised early

initialisation of periphereals. Customized early initialisation can eliminate time-consuming tasks (such as

initializing keyboards or USB devices) that may be superflous in embedded systems.

Most x86 systems place device drivers — which are responsible for device initialization — in the BIOS. In

the QNX Neutrino RTOS these drivers are outside the BIOS. This architecture allows developers to easily

select which drivers and, therefore, which devices are initialized and when, removing unneeded

initializations and deferring others until after the boot. In brief, work is removed or deferred to achieve the

fastest possible boot times.

When developing BIOS-less boots, developers can hard-code custom interrupt assignments so that they

are known at compile time. They can design their systems to boot from a partial boot image boot on a

linearly mapped device, such as a flash or EEPROM. This partial image can be optimized for fast boot times,

but include a driver to access storage, such as a hard drive, NAND flash device or USB device with a full

boot image.

Micr oker n e l

The QNX Neutrino RTOS’s unique microkernel architecture makes it easy to optimize component and

application availability following a boot to change the startup sequence to take advantage of any idle time.

The system architect has complete control of what starts when. For example, developers could configure a

system to play a jingle almost instantly after power-up by loading the audio driver and a small, throw-away

playback utility before most other drivers.

In s tan t Dev ice Act ivat ion

QNX Instant Device Activation enables embedded systems to meet critical early readiness requirements,

such as receiving and responding to CAN bus messages, after a cold power up and boot.

Instant Device Activation (IDA) boot process



Instant Device Activation brings a minidriver up before the kernel initialization to meet early boot

requirements, then hands control over to the OS.

Cr i t ical fu n ct ion al i ty

IDA uses small, highly efficient device drivers that start executing before the OS kernel is initialized. This

minimal driver layer can:

Respond to external events, meet critical response times, access hardware, and store data for the full

driver

Either continue to run or exit seamlessly once control has been assumed by the full driver process, all

without blackout times or data loss

R edu ced h ar dwar e cos ts

IDA technology can be used to reduce hardware costs, because it:

Manages data from buses, such as MOST and CAN, without the addition of costly hardware, such as

external power modules

Boots from a cold or low-power state without auxiliary communications processors to meet timing and

response requirements

Appl icat ion cu s tomiz at ion

Designed to facilitate application customizations, IDA technology includes the full source code and

documentation for easy configuration. Designers and integrators can:

Adapt standard polling intervals to meet device timing requirements

Define the amount of data stored in the IDA buffer

Determine the optimal driver transition model, by specifying when the full driver process takes over

Persistent/Publish-Subscribe (PPS) is a small, efficient, and flexible service introduced by QNX Software

Systems specifically for use in embedded systems. PPS allows developers to build loosely connected

systems based on asynchronous publications and notifications. Software components can easily

communicate with each other, even when they are created using differing programming languages or

environments. Features include:

Support for one-to-one, one-to-many, and many-to-one relationships between publishers and

subscribers

Interface based on object names, which allows plug-ins and substitutable components

Compatibility with any programming language, including C, C++, Java, Flash, Python, Perl, bash, or ksh

Object attributes that can be persisted across a system reset without requiring additional logic

Support for on-demand publishing (pull instead of push)

The QNX Neutrino RTOS offers several power management strategies to help developers meet the

stringent power and heat requirements of many embedded systems. These include:

Tickles s mode

Power savings can be achieved by having timers set to help the system sleep for longer intervals. The

kernel can reduce power consumption by running in tickless mode, although this is a bit of a misnomer. The

system still has clock ticks, and everything runs as normal unless the system is idle. Only when the system

goes completely idle does the kernel "turn off" clock ticks. In reality what it does is slow down the clock so

that the next tick interrupt occurs just after the next active timer is set to fire.

Tickless mode must be enabled via the system startup code, and is only active when the entire system is

idle.

Toler an t t imer s

In order to help the kernel save power, timers that don't require real-time precision can be assigned a

tolerance value. The classic example of this is a UI response timer set in seconds. The kernel then uses the

expiry time plus the tolerance to optimize processing of timers and interrupts.

When setting up a timer, you can specify how much tolerance the kernel is allowed when scheduling your

thread after the timer fires. Setting timer tolerance allows the system to sleep longer and then do more

work when it does wake up as multiple timers can be fired when the kernel awakens.

http://www.qnx.com/images/products/rtos/IDA_3_10_800.gif

http://www.qnx.com/images/products/rtos/IDA_3_10_800.gif



Laz y in te r r u pts

In order to help the kernel save power, you can make an interrupt "lazy" by specifying an acceptable

latency for it. Before putting the CPU to sleep, the kernel checks all the interrupt latency values and sees if

it can guarantee that another interrupt (e.g., for a timer tick) will occur before the latency period has

expired. If it can prove that another interrupt will occur first, the kernel masks the lazy interrupt before

going to sleep. When any interrupt is received by the CPU, all the lazily masked interrupts are unmasked.

In order to save power, interrupts that don't require realtime responses can be assigned a latency value.

The classic example of this is a keyboard interrupt event. The kernel will mask this interrupt if it can

guarantee that another interrupt will occur within the latency window. When any interrupt is received, the

kernel then also processes interrupts that may have occurred for lazily masked interrupts.

Dyn amic Voltage F r equ en cy Scal in g

Dynamic Voltage Frequency Scaling (DVFS) allows ARM Cortex SoCs to run at various power levels based

on CPU load and/or temperature. This system-level power management could be beneficial in saving

power during low CPU loads and in ensuring that the chip’s thermal limits are never reached.

The DVFS driver manages Dynamic Voltage Frequency Scaling for a system on a chip (Soc) This driver

provides some level of power and thermal management from a system level. The driver is responsible for

the following tasks:

Monitoring the CPU load (MPU load)

Monitoring the SoC temperature (if possible)

Scaling the voltage and the frequency of MPU, based on the reported CPU load and/or SoC

temperature

Providing an API for applications to send commands or read various information

The QNX Neutrino RTOS provides a level of graphical and mobile techniques offered by no other

commercial RTOS.

QNX delivers a compositing windowing system which integrates multiple graphics and user interface (UI)

technologies into a single scene. This scene is then rendered into one image that is associated with a

display. This allows the designer to use the most appropriate graphics technology that corresponds with

the image, be it video, Open GL ES, HTML5, or Qt 5.

Scr een : mu lt ip le gr aph ical in pu ts

QNX Neutrino has been updated with a new graphics compositing windowing system called Screen, which

integrates multiple graphics and user interface (UI) technologies into a single scene. This scene is then

rendered into one image that is associated with a display. This allows the designer to use the most

appropriate graphics technology that corresponds with the image.

Screen: A composited windowing system

Screen enables developers to create separate windows for the output of each rendering technology

(HTML5, Qt, Video, or OpenGL ES) so that each window can be transformed - scaling, translation, rotation,

alpha blending - to build the final scene for display.

Unlike traditional windowing systems that arbitrate access to a single buffer associated with a display, this

compositing windowing system provides the means for applications to render off-screen.

Rendering to off-screen buffers allows the manipulation of window contents without having to involve the

applications that are doing the rendering. Windows can be moved around, zoomed in, zoomed out,

rotated, or have transparency effects applied to them, all without requiring the application to redraw or

even be aware that such effects are taking place.

Screen is responsible for:

Running all drivers (input, display, OpenGL ES)

Allocating memory needed by application windows

http://www.qnx.com/images/products/rtos/screen_overview_800.jpg

http://www.qnx.com/images/products/rtos/screen_overview_800.jpg



Displaying content when rendering completes

Screen integrates multiple graphics and user interface (UI) technologies into a single scene. This scene is

rendered into one image that is associated with a display.

Screen: A composited windowing system

Screen integrates multiple graphics and user interface (UI) technologies into a single scene.

The main responsibility of Screen is to combine all visible window buffers into one final image that is

displayed. This responsibility is handled by the Composition Manager and is achieved using several classes

of hardware. The Composition Manager can be configured to use available compositing hardware in a way

that best meets the needs of a particular system.

Screen has a plug-in architecture that includes hardware-specific compositing modules and a module for

OpenGL for Embedded Systems (OpenGL ES).

Screen uses GPU-accelerated operations to optimally build the final scene. You may resort to using

software rendering if your hardware cannot satisfy the requests. The graphics drivers and display

controllers that run within Screen are based on the OpenWF Display (WFD) API.

Mu lt i tou ch in pu t con tr o l

QNX supports multi-touch graphical displays that are in wide use. The Input Events Library has been

extended to support multi-touch screens. The Gestures Library provides gesture recognizers to detect

gestures through touch events that occur when you place one or more fingers on a touch screen.

What are gestures?

A gesture is an interaction between users and your application through a touch screen. A composite (also

called transform or continuous) gesture is one that may send multiple notifications to the application as you

continue to touch or move your fingers on the screen. Discrete gestures send only a single notification to

the application. The supported gestures are:

Composite

Swipe

Pinch

Rotate

Two-finger

Pan

Discre te

Tap

Double tap

Triple tap

Long press

Press and tap

Two-finger tap

If it is necessary to detect a gesture that isn't supported by the Gestures Library, new gesture recognizers

can be added. Touch events are events generated by the touch controller. In the Gestures Library, touch

events contain various types of information about the touch event, such as the type of touch event (touch,

move, or release), the timestamp of the event, the coordinates of the touch, and so on.

Video captu r e

The video capture framework gives applications the ability to capture frames from a video input source and

display them using the Screen compositing windowing system.

Win dow gr ou pin gs

A window group is used to organize windows who share properties and a context. Properties can be

http://www.qnx.com/images/products/rtos/screen_mgr_800.jpg

http://www.qnx.com/images/products/rtos/screen_mgr_800.jpg



QNX® Software Systems offers the only full multi-core solution for embedded RTOS systems on the market.

Multiprocessor capable since 1997, and deployed on multi-core processors in virtually every embedded

environment, the QNX® Neutrino® RTOS offers:

Symmetric (SMP), asymmetric (AMP), and bound (BMP) multiprocessing models

Inherent scalability — symmetric and bound multiprocessing scale seamlessly beyond two processors

Support for a wide range of popular multiprocessor boards

queried and set based on the group type. These properties when set, are then applied across each

window in the group. Properties that windows can share when in the same group include:

Idle time

Keyboard focus

Multi-touch focus

All windows in the same group also share the same context.

Mor e e f f ic ien t an d s tr eaml in ed AP Is

QNX Neutrino has a graphics driver architecture that is based on the OpenWF Display (WFD) API, which is

tuned for embedded and mobile devices, typically under resource constraints.

High - per for man ce gr aph ics ar ch i tec tu r e

QNX Neutrino makes full use of the built-in high-performance OpenGL ES based transitions and

accelerated blitting APIs within the Screen subsystem.

In addition to its unparalleled reliability and self-healing capabilities, the QNX Neutrino RTOS microkernel

architecture offers significant advantages over monolithic kernels.

Mon ol i th ic ker n e ls

Monolithic kernels, such as Microsoft Windows or Linux, require either big kernel locks (BKL) or fine-grain

locking. This is more problematic than QNX's microkernel implementation because:

BKLs can cause long delays for threads requiring kernel access when the kernel is running on a different

core, greatly degrading coherency

Fine grained locking introduces a large amount of complexity into code, creating fragile, difficult to

understand system level interactions, without solving the entire problem — timeliness of access is still

restricted to the degree of locking implemented in the current subsystem

Micr oker n e ls

With the QNX microkernel, kernel operations are relatively few and of short duration. This minimal locking

approach improves the performance of the rest of the system because neither BKL or fine grained locking

approaches are necessary.

Long time-scale operations (including process managers) run in process space, and because of that, they

do not halt the scheduling of other threads in the system: applications, drivers, or protocol stacks. Keeping

extended duration operations in process threads (and outside the kernel) grants the microkernel the

freedom to schedule regular process threads across multiple CPUs.

Ef f ic ien t deve lopmen t

The QNX Neutrino RTOS enables rapid time-to-market for multi-core applications:

Reuse existing applications

Advanced visualization tools for multi-core systems

Multi-core debugging and optimization tools

SMP and BMP provide full visibility of all application processes and system resources

Bound multiprocessing (BMP) is a QNX innovation for multi-core systems. It extends the SMP practice of

"processor affinity" to enable developers and system integrators to bind processes and threads to a

specified processor without code changes. BMP is attractive to developers for a number of reasons:

Facilitated migration to multi-core systems — ensures, for example, that a legacy application without

proper synchronization mechanisms runs as if it were on a single processor

Alternative to asynchronous multiprocessing (AMP) — where one or more cores are dedicated to the

data plane, and one or more cores are dedicated to the control plane

Prevention of threads unnecessarily migrating between cores, or from overwriting each other’s caches

Bound multiprocessing use case



P O SIX cer t i f ied

The QNX® Neutrino® RTOS supports hundreds of POSIX commands, utilities, and programming interfaces that

maximize code portability and reusability. This rich, standards-based environment includes familiar shells and

command-line interfaces, and allows developers to quickly migrate Linux, UNIX, and other open source

programs to QNX.

The QNX Neutrino RTOS is certified for conformance to the POSIX PSE52 Realtime Controller 1003.13-2003

System product standard. Government agencies as well as commercial customers can choose the QNX

Neutrino RTOS with the assurance that it provides both the code portability and the realtime determinism

needed for an array of military, networking, medical, and automotive systems.

En gin eer ed for P O SIX

The QNX Neutrino RTOS was engineered from the ground up for POSIX standards. This approach eliminates

the complex POSIX adaptation layer needed by other RTOSs, resulting in faster performance and lower

memory costs for embedded applications.

See also: Certifications

QNX Neutr ino RTOS 6.6

QNX® Neutrino® RTOS 6.6 – released in February 2014 offers a wealth of new graphics, UI, multimedia,

security, and power management capabilities. The QNX OS 6.6 also supports the new QNX SDK for Apps and

Media, which allows developers to create rich user interfaces with web technologies (HTML5, JavaScript, CSS)

and to develop and deploy packaged HTML5 apps.

Scr een gr aph ics s u bs ys tem

A new graphics subsystem that can render images from multiple sources onto a single display

Support for multi-touch displays and gestures

QNX Software System's unique BMP technology enables developers to bind processes and threads to

a specified processor without code changes.

O ptimiz at ion tech n iqu es

The QNX Neutrino RTOS uses multiple techniques to optimize performance on BMP systems. These

techniques include soft affinity and runmasks.

Sof t af f in i ty

Whenever possible, the QNX Neutrino RTOS ensures that a thread is scheduled to run on the same CPU

that it was last running on in order to improve cache performance.

R u n mas ks

Each thread has a runmask; that is, a bitmask that indicates which processors the thread is permitted — or

forbidden — to run on. By default, a thread inherits the runmask of its parent thread to ensure that all

threads in a process are bound to the same processor. Runmasks for each thread can be changed

dynamically at any time, if a thread or its children need to change processor. This gives the system designer

the ability to fine-tune system performance by tying threads to specific CPU cores or reserving cores for

dedicated functions.

The QNX® Momentics® Tool Suite is a complete multi-core aware tool chain with multiprocessing

debuggers, compilers, and embedding tools. Developers can easily reuse applications developed for

single-core systems and quickly get them to market on multi-core systems:

Application profiler – isolates processing bottlenecks and finds candidates for multi-threading and

parallel operations

System profiler – shows the processing load on each core, monitors inter-core communication, and

detects resource contention to ensure optional performance on multi-core processors

Source level debugging – performs equally well on one or multiple cores

Blocking analysis – helps with shared resources

See also: QNX Momentics Tool Suite

http://www.qnx.com/products/certifications.html

http://www.qnx.com/products/apps-media/

http://www.qnx.com/images/products/rtos/SMP_BMP_Mode_Cores_800.gif

http://www.qnx.com/images/products/rtos/SMP_BMP_Mode_Cores_800.gif

http://www.qnx.com/products/neutrino-rtos/qnx-momentics.html



Support for video capture and display

New driver architecture based on the OpenWF Display (WFD) API

Cor e oper at in g s ys tem

Security enhancements:

Granular control of privilege elevation, without needing to assign root level privilege to the process

Kernel memory management enhancements for security

Address space layout randomization

Guard pages in heap and stack

Support for USB 3.0, OTG, and USB Device

Updates to OpenSSH, OpenSSL, and DHCPv6

Power and thermal management features designed to reduce CPU power consumption and heat

dissipation

Updates to the filesystems

Read-only compressed filesystem (ROCF)

QNXFS6 with encryption

Updated GNU tool ch ain

Latest Eclipse-based IDE

Eclipse 4.2, with support for Git

CDT 8.2

gcc 4.7.3

gdb 7.5

binutils 2.23

C++11 support

See also: QNX Neutrino RTOS 6.6 Release Notes

QNX Neutr ino RTOS 6.5 Service Pack 1

QNX® Neutrino® RTOS 6.5 Service Pack 1 was released in June 2012. This service pack included new

enhancements to the Neutrino RTOS software.


Kernel memory management enhancements

io-pkt enhancements

New USB communication class support

Updated suppport for latest x86 platforms

See also: QNX Neutrino RTOS 6.5 Service Pack 1 Release Notes

QNX Neutr ino RTOS 6.5

QNX® Neutrino® RTOS 6.5 was released in July 2010. This release included new enhancements to the core

software and kernel.


Symmetric Multiprocessing support for ARM Cortex-A9 and Freescale Power e500MC cores

Persistent Publish/Subscribe service

Improved performance and higher file throughput

New support for Intel APICs and MSIs for x86 hardware

Expanded support for x86 boards from Advantech, Intel, and Kontron

See also: QNX Neutrino RTOS 6.5 Release Notes

QNX Neutr ino RTOS 6.4. 1

QNX® Neutrino® RTOS 6.4.1 was released in May 2009. This release included new features, as well as

important bug fixes.


Support for ARM Cortex A8 (ARMv7 architecture)

Support for Freescale e500 Core Signal Processing Extensions (SPE)

Defragmentation of physical memory

Restored support for MIPSBE and MIPSLE targets

Networ kin g

BIND9 support

SSH support

http://www.qnx.com/developers/articles/rel_5849_7.html





F i les ys tems

Read-only support for Microsoft NTFS and Apple HFS+

Gr aph ics

Composition window manager — a new tool that enables the easy creation of transparency holes in video

and flash content

See also: QNX Neutrino RTOS 6.4.1 Release Notes


QNX Neutrino RTOS The QNX® Neutrino® RTOS is a …docenti.unicam.it/tmp/3724.pdf · smartphones...

Documents

Transcript of QNX Neutrino RTOS The QNX® Neutrino® RTOS is a …docenti.unicam.it/tmp/3724.pdf · smartphones...