The bootstrap file

The first section of the buildfile contains 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-honeycomb_lx2 -W)
    PATH=/proc/boot procnto-smp-instr -vv   
}

If we parse this section, we find the following:

The image attribute specifies the offset in memory where the bootable image starts.
The virtual attribute specifies a virtual addressing model for the image to be built. (QNX doesn't currently support a physical addressing model.)
armle-v7 specifies that the target system CPU is a little-endian ARMv7 processor (see Specifying the board architecture below).
raw specifies the IFS layout. The other common layout for ARM processors is bin for binary.
.boot introduces an inline file (inside the brace brackets).

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:

If you don’t set PROCESSOR before you run mkifs and you don't set the virtual attribute in your buildfile, mkifs sets PROCESSOR to x86_64, and builds an image for an x86_64 board.
If you set PROCESSOR before you run mkifs, but you don't set the virtual attribute in your buildfile, mkifs uses the value you specified for PROCESSOR, and builds an image for that board architecture.
Even if you set PROCESSOR, if you set the virtual attribute in your buildfile, mkifs uses the value specified by the virtual attribute: it updates PROCESSOR, and builds an image for that board architecture.

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	x86_64 (default)
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-smp-instr 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 bootstrap 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-honeycomb_lx2 -W
PATH=/proc/boot procnto-smp-instr -vv

Initialization code: The first line of the inline file launches the program that initializes the board (e.g., startup-honeycomb_lx2 -W). This startup program 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.; The startup program's 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 QNX Neutrino kernel and process manager.
Next program: The second line of the .boot inline file defines the PATH environment variable that will then be used by the program to which the startup program will transfer control. In this case, it's procnto-smp-instr, the QNX Neutrino kernel and process manager for multicore processing, with instrumentation.; The PATH setting also instructs procnto-smp-instr to set the _CS_PATH configuration string (see Environment variables). This line also sets the verbosity to level two (-vv).

Note:

In this release, the only variant of the kernel and process manager has the full name procnto-smp-instr, so you must use this name in the buildfile. For convenience, though, we sometimes refer to the kernel using the short form of procnto when explaining certain concepts. For more information about launching the kernel, including the options you can specify, see the Utilities Reference procnto entry.

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:

Group them for each exectuable as though you were entering them through the command line.
Place the groups in the same order as the executables are listed in the inline file.
End each group with a two-hyphen termination marker: --

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

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

You could then specify options for these executables with a line in the FDT like this:

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

which specifies options for:

startup-armv8_fm: the -P sets the maximum number of CPUs to 1 (one).
kdumper: the -B and -I options instruct kdumper to write the dump in the 64-bit ELF format in all cases, and to dump all the IFS contents.
procnto-smp-instr: the -n option instructs the kernel to use nonlazy stack allocation.

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.

Page updated: March 12, 2026