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 the QNX OS 8.0.
OS Components & Operations
Building Embedded Systems
The Building Embedded Systems guide is intended for developers who are developing or building BSPs for QNX OS embedded systems.
OS Image Buildfiles
You can edit OS image buildfiles to configure OS images.
Including files in the image
When it looks for files to include in the OS image it is building, mkifs resolves the filepaths specified in the buildfile 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.
Location of files on the target
After the QNX OS has started running on the target, the OS image files will be in /proc/boot or any other locations that you explicitly specified as well.

QNX Momentics IDE User's Guide
This User's Guide describes version 8.0 of the Integrated Development Environment (IDE) that's part of the QNX 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 the QNX OS 8.0.
- Quickstart Guide
- System Architecture
  The System Architecture guide accompanies the QNX OS and is intended for both application developers and end-users.
- OS Components & Operations
  - 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 OS embedded systems.
    - Overview
      QNX systems are built from the QNX OS 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 first set up the minimum environment needed to execute their compiled C code, then find the OS image and load it into memory, and then jump to the QNX startup code.
    - Startup Programs
      The first program to run in a bootable OS image is the startup program; it completes the system configuration, then launches the OS kernel.
    - Kernel Callouts
      Kernel callouts are standalone pieces of code (or code fragments) that the kernel uses to perform hardware-specific functions. These callouts don't need to be statically linked to the kernel.
    - 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 included files such as executables and shared libraries.
      - The bootstrap file
        The first section of the buildfile is the bootstrap file. This inline file specifies the processor architecture, the name of the startup program, the OS kernel, and some environment variables.
      - Scripts
        The second section of the buildfile starts with the [+script] attribute. This attribute informs mkifs that the specified file is a script file, a sequence of commands that you want the procnto 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} will be 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 the 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 filepaths specified in the buildfile 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.
        Changing where mkifs looks for files
        You can change where mkifs looks for files it includes in the OS image.
        Including many files
        To include the contents of a directory and its subdirectories, you can simply specify the directory instead of individual files.
        Adding missing shared libraries automatically
        You can use the mkifs autoso attribute to add to your IFS image any shared libraries that are required by binaries included in the image but that are missing from the buildfile.
        Location of files on the target
        After the QNX OS has started running on the target, the OS image files will be in /proc/boot or any other locations that you explicitly specified as well.
      - 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 user ID and group ID are set to 0. 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
      The startup library contains a rich set of routines ranging from high-level functions called by main() to utility functions for performing specific startup tasks.
    - Debugging QNX Embedded Systems
      The microkernel architecture of QNX OS 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
  - 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 OS High-Performance Networking Stack and its manager, io-sock.
  - PCI Server User's Guide
  - Performance Tuning User's Guide
  - SMMUMAN User's Guide
  - System Analysis Toolkit (SAT) User's Guide
  - Technotes
  - User's Guide
    The QNX OS User's Guide is intended for all users of a QNX OS system, from system administrators to end users.
- Graphics
- Programming
- System Security Guide
  The QNX System Security Guide is intended for both system integrators who are responsible for the security of a QNX OS system and developers who want to create a QNX OS resource manager free from vulnerabilities.
- Utilities & Libraries
- Migrating to QNX OS 8.0
QNX Software in the Cloud
QNX Software in the Cloud enables developers to use the QNX OS in the Amazon cloud environment.
QNX Toolkit for Visual Studio Code
This User's Guide describes the QNX^® Toolkit for Visual Studio Code. The guide introduces you to the QNX Toolkit by explaining the QNX development environment and how to build, run, and debug your QNX^® Operating System (OS) applications and systems.
QNX Hypervisor User's Guide
This User's Guide explains the QNX hypervisor architecture and provides instructions for installing and running a QNX Hypervisor system, changing system components and configuration, and using hypervisor features such as virtual devices (vdevs).
Typographical Conventions, Support, and Licensing
This section describes the typographical conventions used throughout the documentation, explains how to obtain technical support, and provides some information about licensing.

Location of files on the target

QNX SDP8.0Building Embedded SystemsConfigurationDeveloper

After the QNX OS has started running on the target, the OS image files will be in /proc/boot or any other locations that you explicitly specified as well.

By default, when it builds an image, mkifs puts the included files in the /proc/boot directory. For example, the following in a buildfile:

devc-ser8250
/etc/hosts

results in the following on the target:

/proc/boot/devc-ser8250
/proc/boot/hosts

Note that the second buildfile line (/etc/hosts) instructs mkifs to place hosts at the default location, which is /proc/boot/hosts and not /etc/hosts.

To place a file in another location, you can set an alias for the file, using two pathnames separated by an equal sign (=). For example, the following in a buildfile:

/etc/hosts = /project/target_files/etc/hosts

makes mkifs place the file at the following target path:

/etc/hosts

You can place the file at the same target location as it's stored on the host, as follows:

/release/data1/ = /release/data1

This results in the following target path:

/release/data1

Page updated: March 05, 2025