A QNX Apps and Media system starts up in several stages.

The startup process involves multiple tasks, completed in sequence. These tasks can be grouped into three stages:
  1. Hardware startup — board and chip dependent; software has no control over this stage.
  2. Initial startup — the IPL, IFS, and any services and applications that must be accessed immediately. To customize this stage, you need to modify the build file and rebuild the target image.
  3. Everything else — The System Launch and Monitor (SLM) service uses its configuration files to know what to launch to prepare the environment for the HMI. You don't need to rebuild the target image to change the launch order of applications; you just need to change the SLM configuration files.
Figure 1. The startup sequence for a QNX Apps and Media system

Phase locked loop (PLL)

PLL is part of the hardware startup process. It refers to how long it takes for the first instruction to begin executing after power is applied to the processor.

Most CPUs have a PLL that divides the main crystal frequency into all the timers used by the chip. The time that the PLL takes to settle to the desired frequencies often represents the largest portion of the chip's startup time.

The PLL stage is independent of any OS and varies from CPU to CPU; in some cases, it takes as long as 32 milliseconds. Consult your CPU user manual for the exact timing.

Initial Program Loader (IPL)

QNX provides a standard, bare-bones IPL that performs the fewest steps necessary to configure the memory controller, initialize the chip selects and/or PCI controller, and configure other required CPU settings. Once these steps are complete, the IPL copies the startup program from the image filesystem (IFS) into RAM and jumps to it to continue execution.

The IFS contains the OS image, which consists of the startup program, the kernel, the build scripts, and any other drivers, applications, and binaries that the system requires. Because you can control what the IFS contains, the time for the copying stage varies, but it typically constitutes the longest part of the kernel boot process. In extreme cases where the system contains a very large image and has no filesystem other than the IFS, this stage can take a long time (10 seconds or more).

You can indirectly adjust the length of this phase by reducing the size of the IFS. To add, remove, or configure files stored in the IFS, modify the .build files used by gen-ifs. You can also compress the image to make the IFS smaller (with the additional overhead of decompression, which you can speed up by enabling the cache in the IPL).

Typically, the bootloader executes for at least 6 milliseconds before it starts to load the OS image. The actual amount of time depends on the CPU architecture, on what the board requires for minimal configuration, and on what the chosen bootloader does before it passes control to the startup program.

Some boards come with another bootloader, such as U-Boot. These bootloaders aren't as fast as the QNX IPL, because this IPL has been specifically tuned for QNX systems.

For more information on the IPL and how to modify it for your purposes, see "Writing an IPL Program" in the Building Embedded Systems guide.

Startup program (including the kernel)

The first program in a bootable OS image is a startup program whose purpose is to initialize the hardware, the system page, and callouts, then load and transfer control to the kernel (procnto or procnto-smp). If the OS image isn't in its final destination in RAM, the startup program copies it there and decompresses it, if required.

During bootup, the kernel initializes the memory management unit (MMU); creates structures to handle paging, processes and exceptions; and enables interrupts. Once this phase is complete, the kernel is fully operational and can begin to load and run user processes from the build scripts.

Build scripts

Each board has a different set of build scripts to support different configurations. The build scripts let you specify which drivers and applications to start, and in what order.

You can use the build scripts to launch services or utilities that need to be running very early or that need extra time to load (for example, PPS or disk drivers). Wherever possible, these processes should be started in the background to optimize concurrency and maintain the highest possible utilization of the CPU until the HMI is fully operational.

It's also important to limit what goes into the build script because the build script is included in the IFS, and everything that's added to it increases the IFS size and, therefore, the loading time. Furthermore, SLM is more efficient at launching services and also allows you to monitor and restart services as required.

In the QNX SDK for Apps and Media platform, the build scripts start the following:

System Launch and Monitor (SLM)

SLM is a service that starts any processes required for the HMI (e.g., io-pkt), then starts the HMI. At this point, SLM waits for further instructions. SLM is controlled by a set of configuration files (slm-config-all.xml and slm-config-platform.xml) that tell it what modules to start and whether there are dependencies within or between those modules. The dependencies of the HMI are defined in the anm-init module of the file slm-config-all.xml. For more information, see the entry for SLM in the System Services Reference.