System Startup Sequence

PLL (phase locked loop)—PLL 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.

IPL (initial program loader)—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).

That said, you can exercise a great deal of control over the length of this phase, albeit indirectly, by reducing the size of the IFS. To add, remove, or configure files stored in the IFS, you can edit the build script or use the system builder tool in the IDE. 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, since the IPL has been specifically tuned for QNX systems. We recommend that you replace your bootloader with the IPL.

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—The first program in a bootable OS image is a startup program whose purpose is to initialize the hardware, initialize the system page, initialize callouts, and 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 (for example, audio chime and backup camera) 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 parallelsim 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 the time it takes to load. Furthermore, the System Launch and Monitor (SLM) is more efficient at launching services, with the added benefit that it allows you to monitor and restart services as required.

Boot Manager—The Boot Manager drives SLM by sending it commands to start up sets of components (modules) that in general comprise the dependencies for each core application (tab) of the HMI, but could also allow you to launch other sets of functionality at a particular point in the boot sequence (for example, Bluetooth services). Each tab in the HMI is defined in the file slm-config-modules.xml as the list of dependencies it requires.

The Boot Manager publishes PPS objects to /pps/services/bootmgr/modules_ready/ to signal to the HMI that a particular tab's dependencies are ready and that tab can be launched. If the /pps/services/bootmgr/last_tab object is present (representing the tab that was active when the system was last shut down), the Boot Manager launches that tab first. Otherwise, it launches tabs in the order they are listed in slm-config-modules.xml. You can change the order in which tabs are launched as priority dictates by changing the order they are listed in slm-config-modules.xml