OS Images

An OS image is a file that contains the OS, your executables, and any data files that might be related to your programs.

This chapter explains how to:

Note: For detailed information about QNX buildfile syntax and how to use a buildfile to configure an OS image see the OS Image Buildfiles chapter.

Image types

An image can be non-bootable, or bootable. In the embedded QNX Neutrino world, an “image” can mean any of the following:

Image type Description Created by
OS image A bootable or non-bootable structure that contains files mkifs
Flash filesystem image A structure that can be used in a read-only, read/write, or read/write/reclaim flash filesystem mkefs
Embedded transaction filesystem image A binary image file containing the ETFS as a sequence of transactions mketfs

What is a bootable image?

A bootable image is an image that contains the startup code and procnto and that the Initial Program Loader (IPL), Boot ROM, or BIOS (x86) can transfer control to. For more information, see The boot process and Initial Program Loaders (IPLs).

Figure 1. A bootable image

A non-bootable image is usually provided for systems where a separate, configuration-dependent setup may be required. Think of it as a second “filesystem” that has some additional files in it (we'll discuss this in more depth later). Since it's non-bootable, this image will typically not contain the OS, startup file, etc.

QNX OS images

A QNX Neutrino OS image includes the OS (procnto), startup code, the libraires required to start up and for the OS to run (libc.so), and any drivers or other code and files needed to access the basic hardware.

Usually, a small embedded system will have only one (bootable) OS image. In a QNX system this includes components such as:

Drivers for other devices, and user applications along with the libraries and data files they need, are usually placed in another filesystem, if available.

An OS image is read-only; if you want to use the flash for read/write storage, you need to import to create a flash filesystem image (.efs file). For more information, see Building a flash filesystem image.

For most embedded systems, it is preferable to keep the OS image as small as possible, putting application programs and even drivers that are not needed during the initial startup in another filesystem, such as a NAND or NOR flash filesystem.

The OS image as a filesystem (IFS)

After a boot, the contents of a QNX OS image are presented as a filesystem at: /proc/boot. In fact, a good way to think about an OS image is to consider it as a small filesystem. In fact in QNX-speak the OS image is often called simply the IFS, for Image FileSystem. This IFS has a small directory structure and some files. The directory tells the OS kernel and process manager, procnto, the names and positions of the files in the OS image. When a QNX embedded system is running, even though the OS image is at /proc/boot, it can be accessed just like any other read-only filesystem. For example:

# cd /proc/boot
# ls
.script     ping        cat       data1        pidin       
ksh         ls          ftp       procnto      devc-ser8250-abc123
# cat data1
  • The ls and cat utilities are loaded from /proc/boot.
  • data1 is a data file included in the OS image. Including the data in the image is a convenient way of associating data files with your programs, but increasing the size of the image can increase boot times.

The example above actually shows two aspects of OS image functioning as a filesystem:

  1. When we issued the ls command, the OS loaded ls from the image filesystem (pathname /proc/boot/ls).

  2. Then, when we issued the cat command, the OS loaded cat from the image filesystem as well, and opened the file data1.

The OS image can be configured to contain files you need in your embedded system. For more information, see Building an OS image below.

About image size

A small OS image has the following benefits:

If your embedded system has a hard drive or flash memory (e.g., MMC/SD), you can access the data on it by including the appropriate filesystem driver (e.g., devb-eide, devb-mccsd-board_name) in your OS image filesystem and calling the driver from your boot script.

If your system has an on-board flash device, you can use this device to store your OS image and boot the system directly from flash, if your board allows this. (Check the board hardware documentation.)

Note: The smallest possible OS image is not always the best choice. See the Boot Optimization Guide for a discussion about how to configure your system to meet its boot-time requirements.

More information

For more information see:

Topic See
Building the OS image for a specific board BSP User's Guide for the board
Buildfile syntax OS Image Buildfiles
Customizing product-specific images The Working with Target Images guide for the product
Optimizing your system's boot sequence The Boot Optimization Guide.
Using the various utilities described in this chapter the QNX Neutrino Utilities Reference