The bootstrap file

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 builds an image for a board with your development host's CPU type.
• 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:

Optional modules

PATH=/proc/boot procnto-smp-instr -vv

[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:

• 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, 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:

• 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: 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.