System configuration

Exactly how you should configure your system depends on the type of system you're building. Below are some very general guidelines to help you understand how to use an mkifs buildfile to configure your system, including which executables should be used in what circumstances, and which shared libraries are required for these executables.

The general procedure to set up a system is as follows:

1. Establish an output device (see Output device).
2. Run drivers and filesystems (see Drivers and filesystems).
3. Run applications (see Applications).

For changes you make to your mkifs buildfile to affect your system configuration, you must rebuild your system. For instructions on how to build a new system image after you have modified the buildfile, see the chapter Working with QNX BSPs in this guide.

See the Sample Buildfiles appendix in this guide for some sample buildfiles.

Output device

One of the first things you should do in a buildfile is start a driver to which you can redirect standard input, output, and error. Starting a driver early in the startup sequence provides all subsequent drivers and applications a known location for outputting startup, diagnostics, and error messages. In most cases, the output device you should start will be a serial port driver (e.g., devc-ser8250).

If your system doesn't have a serial driver, you may choose to omit this step, or use some other type of device, for which you will need to write a specialized driver. If you don't specify a driver, by default, output goes to the debug output driver provided by the startup code.

Drivers and filesystems

Your embedded system must run drivers and filesystems that will make the hardware accessible to external devices.

You can include these drivers and filesystems in the image you build before you transfer it to the target. QNX OS supports many drivers and filesystems, which are described in the Utilities Reference:

• disk drivers (devb-*)
• flash filesystems (devf-*)
• network drivers (devs-*)
• input drivers (devi-*)
• USB drivers (devu-*)
• filesystems (fs-*)

Placing drivers in the startup sequence

For most systems it is best to keep the OS image small. This means not putting all of the executables and shared libraries into the OS image. Instead, do the following:

1. In some other medium, such as a flash filesystem, a network filesystem, or rotating disk, place the executables and libaries you won't need immediately.
2. In the OS image, place the executables that need to be started immediately (e.g., the watchdog and a serial driver), and the drivers the system will need to access the executables from the other media (e.g., start drivers).

In other words:

• Disk, flash, and network drivers all rely on a process that loads one or more .so files. (These files are selected through either the command line or automatic configuration detection.)
• Since these drivers all use shared object (.so) files (both their own driver-specific files, and standard ones such as the C library), these .so files must be present before the drivers start.
• Therefore, the .so files needed to start these drivers must be on a medium other than the one for which the driver is being started. (For instance, don't put the executables and libraries the system will need to access a rotating disk on the rotating disk.)
• In short, put the .so files in the OS image.

Disk drivers

When configuring your image to support a rotating or solid-state disk, you must first determine what hardware controls the disk interface. The QNX OS supports a number of interfaces, including the EIDE controller. For details on the supported interface controllers, see the various devb-* entries in the Utilities Reference.

The only instruction you need to put in your buildfile is to start the driver for the appropriate hardware. For example, for the AHCI SATA interfaces driver on an x86 board:

• Detect all SATA controllers and list all connected devices:

  devb-ahci &

• Detect all SATA controllers and use DMA-typed memory:

  devb-ahci mem name=/ram/dma &

The driver will then dynamically load the required modules, in this order:

1. libcam.so — Common Access Method library
2. cam-*.so — Common Access Method module(s)
3. io-blk.so — block I/O module
4. fs-*.so — filesystem personality module(s)

The CAM .so files are documented under cam-* in the Utilities Reference. Currently, QNX OS supports CD-ROMs (cam-cdrom.so), hard disks (cam-disk.so), and optical disks (cam-optical.so).

The io-blk.so module is responsible for dealing with a disk on a block-by-block basis. It includes caching support.

Network drivers

Network services are started from the io-sock command, which is responsible for loading the required .so files.

The -d option for io-sock specifies the hardware driver or drivers you need for the network card on your system. You can also dynamically load a network driver, using the mount command.

For more information, see the High-Performance Networking Stack User's Guide, and the devs-* and io-sock entries in the Utilities Reference.

Flash filesystems

To run a flash filesystem, you must select the appropriate flash driver for your target system. For details on the supported flash driver, see devf-ram in the Utilities Reference. Note that:

NOR flash

The NOR flash filesystem drivers don't rely on any flash-specific .so files, so the only module required is the standard C library (libc.so).

Since these drivers are written for specific target boards, you can usually start them without command-line options; they'll find the flash filesystem for the board for which they're written.

NAND flash

The devb-nand NAND flash driver isn't shipped with the QNX OS. It is included in BSPs for boards that support NAND flash filesystems.

For instructions on building the filesystem image, see Building a flash filesystem image in the OS Images chapter. For instructions on starting flash filesystem drivers, see your BSP User's Guide.

Network filesystems

Before it tries to load a network filesystem, your system must load the network drivers it will need (see Network drivers above). Be sure to set the load sequence appropriately in your startup configuration.

QNX OS supports NFS filesystems which allows file access over a network to a UNIX or other system running an NFS server (see fs-nfs3) in the Utilities Reference).

Applications

Nothing special is required to run applications. Usually, you place them in the script file after all the drivers have started, or later in a flash filesystem image that you generate with mkefs (see Building a flash filesystem image in the OS Images chapter). If you require a certain driver to be running before you start an application, you typically use the waitfor command in the script part of your buildfile (see Scripts in the OS Image Buildfiles chapter).

driver-spud &
waitfor /dev/spud
peelmaster

This sequence causes the driver (driver-spud) to be run in the background (specified by the ampersand character). The expectation is that when the driver is ready, it will register the pathname /dev/spud. The waitfor command tries to access (with stat()) the pathname /dev/spud periodically, blocking execution of the script until either the pathname appears or a pre-determined timeout has been reached.

When the pathname appears in the pathname space, we assume that the driver is ready to accept requests. At this point, the waitfor unblocks, and the next program in the list (in our case, peelmaster) executes.

Without the waitfor command, the peelmaster program would run immediately after the driver was started, which could cause peelmaster to miss the /dev/spud pathname and fail.

Boot optimization

For information about how to optimize boot times, or how to get specific components up quickly so they can provide services (e.g., rearview camera in a vehicle), see the Boot Optimization Guide.