Components of an image, in order of booting

Neutrino supports a wide variety of CPUs and hardware configurations. Some boards require more effort than others to embed the OS. For example, x86-based machines usually have a BIOS, which greatly simplifies your job, while other platforms require that you create a complete IPL. Embedded systems can range from a tiny memory-constrained handheld computer that boots from flash, to an industrial robot that boots through a network, to a multicore system with lots of memory that boots from a hard disk.

Whatever your particular platform or configuration, the QNX System Builder helps simplify the process of building images and transferring them from your host to your target.

Note: For a complete description of OS and flash images, see the Building Embedded Systems guide.

The goal of the boot process is to get the system into a state that lets your program run. Initially, the system might not recognize disks, memory, or other hardware, so each section of code needs to perform whatever setup is needed in order to run the subsequent section:

The IPL initializes the hardware, makes the OS image accessible, and then jumps into it.
The startup code performs further initializations, and then loads and transfers control to the microkernel/process manager (procnto), the core runtime component of the QNX Neutrino OS.
The procnto module then runs the boot script, which performs any final setup required and runs your programs.

Introduction: QNX System Builder; boot order

Typical boot order.

At reset, a typical processor has only a minimal configuration that lets code be executed from a known linearly addressable device (e.g. flash, ROM). When your system first powers on, it automatically runs the IPL code at a specific address called the reset vector.

IPL

When the IPL loads, the system memory usually isn't fully accessible. It's up to the IPL to configure the memory controller, but the method depends on the hardware — some boards need more initialization than others.

When the memory is accessible, the IPL scans the flash memory for the image filesystem, which contains the startup code (described in the next section). The IPL loads the startup header and startup code into RAM, and then jumps to the startup code.

The IPL is usually board-specific (it contains some assembly code) and is as small as possible.

Startup

The startup code initializes the hardware by setting up interrupt controllers, cache controllers, and base timers. The code detects system resources such as the processor(s), and puts information about these resources into a centrally accessible area called the system page. The code can also copy and decompress the image filesystem components, if necessary. Finally, the startup code passes control, in virtual memory mode, to the proncto module.

The startup code is board-specific and is generally much larger than the IPL. Although a larger proncto module could do the setup, we separate the startup code so that proncto can be board-independent. Once the startup code sets up the hardware, the system can reuse a part of the memory used by startup because the code won't be needed again.

Note: If you're creating your own startup variant, its name must start with startup or the QNX System Builder perspective won't recognize it.

The proncto module

The proncto module is the core runtime component of the QNX Neutrino OS. It consists of the microkernel, the process manager, and some initialization code that sets up the microkernel and creates the process-manager threads. The proncto module is a required component of all bootable images.

The process manager handles (among other things) processes, memory, and the image filesystem. The process manager lets other processes see the image filesystem's contents. Once the proncto module is running, the operating system is essentially up and running. One of the process manager's threads runs the boot script.

Several variants of proncto are available (e.g. procnto-400 for PowerPC 400 series, procnto-smp for x86 multicore machines, etc.).

Note: If you're creating your own proncto variant, its name must start with procnto- or the QNX System Builder perspective won't recognize it.

For more information, see the System Architecture Guide, as well as proncto in the Utilities Reference

Boot script

If you want your system to load any drivers or to run your program automatically after powering up, you should run those utilities and programs from the boot script. For example, you might have the boot script:

run a devf driver to access a flash filesystem image, and then run your program from that flash filesystem

create adaptive partitions, run programs in them, and set their parameters:

# Create an adaptive partition using the thread scheduler 
# named "Wickedeo" with a budget 
# of 20%: sched_aps Wickedeo 20 
# Start qconn in the Debugging partition: 

[sched_aps=Debugging]/usr/sbin/qconn 

# Use the recommended security level for the partitions: 

ap modify -s recommended

For more information about these commands, see Adaptive Partitioning User's Guide.

When you build your image, the boot script is converted from text to a tokenized form and saved as /proc/boot/.script. The process manager runs this tokenized script.