OS Images

Image types

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

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:

• the startup code: startup-*
• the OS kernel and process manager: procnto
• drivers and managers (e.g., io-pkt, 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          ftp       procnto      devc-ser8250-abc123
# cat data1

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.)

More information