Home
QNX Software Development Platform
QNX SDP is a cross-compiling and debugging environment, including an IDE and command-line tools, for building binary images and programs for target boards running QNX Neutrino 7.1.
OS Components & Operations
Building Embedded Systems
The Building Embedded Systems guide is intended for developers who are developing or building BSPs for QNX Neutrino RTOS embedded systems.
OS Image Buildfiles
You can edit OS image buildfiles to configure OS images.
Board-specific information
When you modify an existing buildfile to support a new target board, you must update the board-specific information.

QNX Momentics IDE User's Guide
This User's Guide describes version 7.1 of the Integrated Development Environment (IDE) that's part of the QNX Momentics tool suite.
QNX Software Development Platform
QNX SDP is a cross-compiling and debugging environment, including an IDE and command-line tools, for building binary images and programs for target boards running QNX Neutrino 7.1.
- Quickstart Guide
- OS Components & Operations
  - Adaptive Partitioning User's Guide
  - Boot Optimization Guide
    The Boot Optimization Guide describes techniques you can use to reduce the time from your board's initial power on until you have a fully functional QNX system running on the board.
  - Building Embedded Systems
    The Building Embedded Systems guide is intended for developers who are developing or building BSPs for QNX Neutrino RTOS embedded systems.
    - Overview
      QNX systems are built from the QNX Neutrino RTOS standard release components, the architecture- and board-specific files provided in QNX BSPs, and customer and third-party components.
    - Working with QNX BSPs
      Before you attempt to write a new BSP or modify an existing one, it is helpful to know how to use a BSP.
    - Initial Program Loaders (IPLs)
      IPLs initialize the hardware, set up a stack for the C-language environment, load the OS image into memory, and finish up by jumping to the QNX startup code.
    - Startup Programs
      The first program to run in a bootable OS image is the startup code; it completes the system configuration, then launches the OS kernel.
    - Kernel Callouts
    - System Page
      The system page contains essential information about the system, including the system page's size, information about the hardware platform (including IRQs and the CPU), the cache size, and the location of kernel callouts in memory.
    - OS Images
      OS images are files that contains the OS, your executables, and any data files that might be related to your programs.
    - OS Image Buildfiles
      You can edit OS image buildfiles to configure OS images.
      - Buildfile syntax
        The buildfile text may include blank lines and comments. All sections are optional, but not all combinations are permitted.
      - Buildfile structure and contents
        The buildfile for a bootable image includes three major sections: a bootstrap loader (which includes an operating system), a script, and executables and shared libraries.
      - The bootstrap file
        The first section of the buildfile contains the bootstrap file. This inline file specifies the processor architecture, the name of the startup program, the OS kernel, and some environment variables.
      - The script file
        The second section of the buildfile starts with the [+script] attribute. This attribute informs mkifs that the specified file is a script file, which is a sequence of commands that you want the kernel and process manager to execute when it has completed its own startup.
      - Environment variables
        Host-side environment variables can be accessed in a buildfile. All occurrences of ${NAME} are replaced by the value of the environment variable with the given name. You can set additional variables in the buildfile to define the environment of any processes started on the target at boot time.
      - The rest of the buildfile
        The rest of the buildfile contains attributes, filenames, and image contents. These determine where mkifs looks for the files it includes in the image, as well as system attributes such as file ownership and permissions.
      - Board-specific information
        When you modify an existing buildfile to support a new target board, you must update the board-specific information.
      - Including files in the image
        When it looks for files to include in the OS image it is building, mkifs resolves the file paths specified in the build file by searching host paths in a preferred order. This order is based on whether these specified paths are absolute or relative, the search attribute setting, and the MKIFS_PATH environment variable setting.
      - File ownership and permissions
        When mkifs includes files, directories, and symbolic links in an OS image, by default these items inherit the development host's permissions, and the user ID and group ID are set to those of the host file (or to 0 on Windows). You can override these settings through buildfile attributes.
      - System configuration
        Before you can use your embedded system, you need to configure it for the drivers, filesystems, and applications it needs to run.
    - IPL Library
      The IPL library contains a set of routines for building a custom IPL.
    - Startup Library
    - Debugging QNX Embedded Systems
      The microkernel architecture of QNX Neutrino means that debugging QNX embedded systems can be different from debugging other embedded systems.
    - Sample Buildfiles
      This appendix contains sample buildfiles that you can modify to support your hardware platform and your implementation requirements.
    - Glossary
  - Core Networking Stack User's Guide
    This guide introduces you to the QNX Neutrino Core Networking stack and its manager, io-pkt.
  - Customizing a BSP
    While QNX provides Board Support Packages (BSPs) for many common platforms and their individual variants, in some cases, you need a BSP for a board that QNX does not provide. If this is the case, you can modify a QNX BSP or develop your own.
  - Device Publishers Developer's Guide
  - High Availability Framework Developer's Guide
  - High-Performance Networking Stack (io-sock) User's Guide
    This guide contains instructions for implementing and using the QNX Neutrino High-Performance Networking Stack and its manager, io-sock.
  - Instant Device Activation
  - Migrating to QNX SDP 7.1
  - PCI Server User's Guide
  - Persistent Publish/Subscribe Developer's Guide
  - Platform-independent Publish/Subscribe Developer's Guide
    This guide is intended for application developers who want to use the Platform-independent Publish Subscribe (PiPS) framework to exchange information with other applications. First, the overall PiPS design and data-exchange model are explained. Then, tutorials on using PiPS are given. These tutorials cover key tasks such as selecting a publish-subscribe provider to use and writing plugins that read and write custom data types.
  - QDB Developer's Guide
  - QNX Helpers Developer's Guide
    These libraries provide QNX helpers, including helpers that assist with logging, string conversion, and number and type sizes.
  - SMMUMAN User's Guide
  - System Analysis Toolkit (SAT) User's Guide
  - System Architecture
    The System Architecture guide accompanies the QNX Neutrino RTOS and is intended for both application developers and end-users.
  - Technotes
  - User's Guide
    The QNX Neutrino User's Guide is intended for all users of a QNX Neutrino RTOS system, from system administrators to end users.
- Audio & Graphics API
- Multimedia
- Networking Middleware
- Programming
- Sensor Framework
- System Security Guide
  The QNX System Security Guide is intended for both system integrators who are responsible for the security of a QNX Neutrino RTOS system and developers who want to create a QNX Neutrino resource manager free from vulnerabilities.
- Utilities & Libraries
QNX Hypervisor
The QNX Hypervisor allows you to run multiple OSs on a target system so you can separate critical and non-critical functions, support a wide variety of applications, and reduce hardware costs.
QNX Software in the Cloud
QNX Software in the Cloud enables developers to use the QNX software in Amazon Web Services (AWS) and Microsoft Azure (Azure).
QNX Advanced Virtualization Frameworks User's Guide
This User's Guide is aimed at all systems integrators and developers who want to design and build embedded systems using the QNX Advanced Virtualization Frameworks.
Typographical Conventions, Support, and Licensing
This section describes the typographical conventions used throughout the documentation and explains how to obtain technical support.

Board-specific information

When you modify an existing buildfile to support a new target board, you must update the board-specific information.

Most of the processor- and platform-specific code for QNX Neutrino systems is in the kernel and startup program, so only minimal changes are needed to adapt a buildfile written for one board to work with another board. For your new target board, you need to specify its:

processor
startup program
serial device

Specifying the processor

The buildfile's virtual attribute specifies the processor, the bootstrap loader, whether the image is compressed or not, and the operating system (see Buildfile syntax in this chapter). To specify a different processor, simply update this attribute's value. For example, for an ARM little-endian, version 7 CPU, you could change the virtual attribute to:

[virtual=armle-v7,binary]

Specifying the startup program

QNX BSPs include a startup program for the board for which the BSP has been written. If you are using a board for which no QNX BSP currently exists, you can start with a BSP for a similar board and modify the startup program (as well as other BSP components, as needed). Be sure to include the correct startup program name in your buildfile. For example:

[virtual=armle-v7,binary] .bootstrap = {
    startup-abc123
    PATH=/proc/boot procnto-smp-instr -vv
    ...
}

For more details, see the chapter Startup Programs, and startup-* options in the QNX Neutrino Utilities Reference.

Specifying the serial device

If there is a QNX BSP for your board, then the BSP probably includes most (if not all) drivers you will need. If you don't have a QNX BSP for your board, you may need to modify existing QNX drivers so they will work with your board. For more information, see the devc-* entries in the QNX Neutrino Utilities Reference.

Page updated: March 12, 2026