IPLs initialize the hardware, set up a stack for the C-language environment, load the OS image into
memory, and finish up by jumping to the QNX startup code.
An IPL is minimalist; it uses as little code as possible to get the startup code to
run. An IPL first sets up the minimal environment needed to execute its compiled
C code, which then looks up the OS image and loads it into memory. Thus, an IPL
performs the following tasks, in sequence:
- Complete hardware initializations, if needed.
- Set up a stack for the C-language environment.
- Find and validate the OS image.
- Load the OS image into memory.
- Jump to the startup code.
An IPL can be stored on either a linearly mapped device, such as a NOR Flash memory
device, or a non-linearly mapped device, such as an eMMC, SD card, or SPI NOR Flash
device. Like the board architecture, the type of memory device on which the IPL and
the OS image are stored determines the design of the IPL (see the next section and
Image storage later in this chapter).
Factors affecting IPL design
The design and content of an IPL are affected by numerous factors, including:
- Board
- IPLs are target architecture-specific. IPLs for x86 processors and ARM
processors are very different (see From reset to startup).
- In addition to being architecture-specific, an IPL is specific to the board
(and even the board variant) that it runs on. It must be customized so that
it knows how to configure the memory controller, set the clocks, and perform
other hardware initializations.
- Supported removeable media
- The type of removable media that the board retrieves the boot image from determines the
boot strategies and techniques that the IPL can use.
- Although linear media are supported, non-linear media (for example, USB key
or onboard eMMC, NOR flash, or NAN flash) have become the most common
options.
- Size of the storage media
- Whether the IFS image is compressed or uncompressed depends
on the size and performance of the storage media.