OS Images

QNX SDP8.0Building Embedded SystemsConfigurationDeveloper

OS images are files 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 OS 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

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 1A 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 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:
  • the startup code: startup-*
  • the OS kernel and process manager: procnto
  • drivers and managers (e.g., io-sock, devc-ser8250, devb-eide, esh (embedded shell), ksh)
  • applications
  • data files

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          procnto     devc-ser8250-abc123
# cat data1
Note:
  • 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:
  • Memory conservation — when the system boots, the entire OS image gets loaded into RAM. The OS image doesn't get unloaded from RAM, so extra programs and data built into the image require more memory than if your system loaded and unloaded them dynamically.
  • Faster boot time — loading a large OS image into RAM takes longer than loading a small image, especially if the image must be loaded via a network or serial connection. This loading time can increase the overall time it takes to start the system.
  • Stability — a small OS image provides a more stable boot process. The fewer components you have in your OS image, the lower the probability that it will fail to boot. The components that must go in your image (startup, procnto, a flash driver or network components, and a few shared objects) rarely change, so they're less subject to errors introduced during the development and maintenance cycles.

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

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 OS Utilities Reference
Page updated: