Updated: October 28, 2024 |
Before you can use your embedded system, you need to configure it for the drivers, filesystems, and applications it needs to run.
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:
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. If you are using a QNX product such as QNX CAR or QNX Platform for ADAS, see Working with Target Images for more information about how to use filesets, profiles, and product-specific configuration files.
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.
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 Neutrino supports many drivers and filesystems, which are described in the Utilities Reference:
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:
In other words:
When configuring your image to support a rotating or solid-state disk, you must first determine what hardware controls the disk interface. The QNX Neutrino RTOS 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:
The CAM .so files are documented under cam-* in the Utilities Reference. Currently, QNX Neutrino 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.
Filesystem | Module |
---|---|
MS-DOS | fs-dos.so |
Macintosh HFS and HFS Plus | fs-mac.so |
Windows NT | fs-nt.so |
Power-Safe | fs-qnx6.so |
ISO-9660 CD-ROM, Universal Disk Format (UDF) | fs-udf.so |
Network services are started from the io-pkt* command, which is responsible for loading the required .so files (see io-pkt-v4-hc, io-pkt-v6-hc in the Utilities Reference).
Two levels of .so files are started, based on the command-line options given to io-pkt*:
To dynamically load a network driver, simply use the mount command. For example:
mount -T io-pkt devnp-e1000.so
For more information, see the Core Networking Stack User's Guide, as well as the devnp-* and io-pkt* entries in the Utilities Reference.
To run a flash filesystem, you must select the appropriate flash driver for your target system. For details on the supported flash drivers, see the various devf-* entries in the Utilities Reference. Note that:
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.
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 Neutrino support two types of network filesystems:
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 you generate with mkefs (see Building a flash filesystem image in the OS Images chapter). If you require a particular driver to be running before you start an application, you would typically use the waitfor command in the script part of your buildfile (see Scripts in the OS Image Buildfiles chapter).
Here's an example. Before it starts, an application called peelmaster needs to wait for a driver (driver-spud) to be ready. The following sequence is typical:
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.
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.