The bootstrap file

The first section of a buildfile is the bootstrap file. The bootstrap file specifies whether the address system being built is physicial or virtual, the processor architecture, some environment variables, etc.

The first section of the buildfile example presented above in Buildfile structure and contents is:

	[virtual=armle-v7,raw] .boot = {
    PATH=/proc/boot procnto-smp-instr -vv   

If we parse this section, we find the following:

Specifying the board architecture

When you build your OS image, mkifs places the target system CPU information (e.g., armle-v7) into the $PROCESSOR environment variable, and uses this as the path to get the components for your OS image.


If you don't specify the processor (and hence don't set $PROCESSOR), mkifs assumes the architecture of the system one which it is building the image and looks for the image components in the path for that assumed architecture. For example, if your host system is an x86 system and you build an image without specifying that the target system is an ARM little-endian system, mkifs will look in ${QNX_TARGET)/x86/ for components and built and image for an x86 system. Of course, this image will not run on your target.

Optional modules

The QNX OS includes optional modules. You can use the buildfile [module= ...] modifier to bind in to procnto when you build the image. For example, to bind in the adaptive partitioning scheduler, change the procnto line to from: PATH=/proc/boot procnto-smp-instr -vv to:

[module=aps] PATH=/proc/boot procnto-smp-instr -vv

For more information about the adaptive partitioning scheduler, see the Adaptive Partitioning User's Guide.

Compressing the OS image

You can use the [+compress] attribute to compress the entire image, except the startup code and the startup header, which are needed to decompress the image.

To compress the OS image, simply add the attribute after the IFS layout specification. For example:

[virtual=armle-v7,raw +compress] .boot = {

The startup program will look after the decompression. Compressing the image can be useful when optimizing the boot. It reduces the time needed to copy the image, but adds the time needed to decompresion. For more information, see the Boot Optimization Guide.

The initialization code, and the next program

The in-line file in the bootstrap section of the buildfile specifies the file with the initialization code, and the path for next program to run after initialization (usually the OS).

The name for the in-line boot file is arbitrary. It can be anything you choose, but QNX usually uses either .boot or .bootstrap. In this example, the .boot in-line file consists of the following:

PATH=/proc/boot procnto-smp-instr -vv
Initialization code (startup-*)
The first line of the .boot in-line file (startup-*) specifies the file with the initialization code for the board. This startup code is board-specific, so it is usually supplied with the board BSP, and the hyphen in the file's name is usually followed by the name of the board on which it runs.
This code is the first code to run after the Inital Program Loader (IPL), U-Boot, or the bootloader (disk-based x86 systems). It initializes the hardware, system page, and kernel callouts, then loads loads the next program in the IFS and transfer control to that program. This next program is usually some version of the OS kernel and process manager procnto.
Next program (PATH=/proc/boot procnto-smp-instr -vv)
The second line of the .boot in-line file specifies the path to the program to which the startup program will transfer control — in this case procnto-smp-instr, the QNX OS kernel and process manager for multi-core processing, with instrumentation.
This line also instructs procnto-smp-instr to set the _CS_PATH configuration string. (see Environment variables), and sets the verbosity level.

See the Utilities Reference for more information about procnto, in particular its variants for single-core or multi-core processing, its instrumented and uninstrumented variants, and the options you can specify at startup.