The bootstrap file

The first section of the buildfile is the bootstrap file. This inline file specifies the processor architecture, the name of the startup program, the OS kernel, and some environment variables.

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

[image=0x10800000]
[virtual=armle-v7,raw] .boot = {
    startup-abc123
    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, you build it for a specific board architecture. You can use the PROCESSOR environment variable or the buildfile virtual attribute to indicate this architecture to mkifs, which uses this information to know the path to the components it needs to build your OS image:

For example, if you set PROCESSOR to foo-arch11 and the virtual attribute to aarch64le, mkifs sets PROCESSOR to aarch64le, and builds an OS image for an ARM 64-bit, little-endian board.

The table below summarizes what setting mkifs uses to determine the board architecture for an image it will build:

PROCESSOR virtual Source of value mkifs uses
Not set Not set Development host CPU type
Set Not set PROCESSOR
Not set Set virtual (updates PROCESSOR)
Set Set virtual (updates PROCESSOR)

Optional modules

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

For 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 handle 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 decompress it. For more information, see the Boot Optimization Guide.

The initialization code and the next program

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

The name for the inline boot file can be anything you choose, but QNX usually uses either .boot or .bootstrap. In this example, the .boot inline file consists of the following:

startup-abc123
PATH=/proc/boot procnto-smp-instr -vv
Initialization code (startup-*)
The first line of the .boot inline file specifies the file with the initialization code for the board (startup-*). This startup code is board-specific, so it is usually supplied with the 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 (on disk-based x86 systems). It initializes the hardware, system page, and kernel callouts, then loads the next program in the IFS and transfers 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 inline 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.

Passing in options at startup

Some bootloaders allow you to pass, into the system image, options presented as command-line input. Most versions of startup that either use the Multiboot protocol or accept a Flattened Device Tree (FDT) in their environment will take advantage of a bootloader that uses these vehicles to pass command-line instructions to the system image. When you pass in options, you don't need to rebuild your IFS if you change the options. The startup reads the options in as though they were entered through the command line, and processes them after the options in the IFS so they can override these other options.

To pass in options:

For example, if your buildfile's inline bootstrap file lists startup-*, kdumper and procnto as follows:

[virtual=aarch64le,elf] .bootstrap = {
    startup-armv8_fm -vvv
    kdumper 
    [module=qvm] PATH=/proc/boot KWHO=host procnto -vvvv

you could specify options for these executables with a line in the FDT thus:

-P 1 -- -B -I -- -n --

which specifies options for:

For more information about these options, see the relevant utilities in the QNX Neutrino Utilities Reference.

If an executable requires no options, you still need to add the separator; for example, if you change the above example to pass no options to kdumper, you would change the relevant line to:

-P 1 -- -- -n --

Notice that there is an option termination marker for each executable, even if there are no options specifed for that executable.

Note:

The location where you can place the options to be read in is architecture-, board- and bootloader-specific, so check you board and bootloader documentation for more information.

Not all boards support this feature. For example, on some x86 boards (e.g., startup-intel-ABL), the Multiboot boot loader is implemented in a manner that precludes passing in command-line options.