Unlike many other operating systems that perform most initialization tasks after the OS is running, QNX Neutrino performs many key initializations using its startup program.
These initializations include timers, interrupt controllers, and cache controllers. Custom board projects can require modifications to the following board and startup code elements:
For a discussion of modifying or creating the startup code, see “Modifying the startup” in the Startup Programs chapter of Building Embedded Systems.
Your custom board’s hardware determines the memory configuration options that are available to you.
Some boards expect the startup code to load the OS at a specific address (for example, SABRE platforms).
Not all boards support compression, which prevents you from compressing the IFS to improve performance or conserve memory.
The type of removable media used to store the IPL and the IFS affects the IPL design. The most common type of media used are non-linearly-mapped devices (for example, an eMMC, SD card, or SPI NOR Flash device). The storage provided by these devices can't be mapped directly into the processor's address space. Because the processor can't address the OS image, the IPL needs to copy the entire image (including the startup code) into RAM. For more information, see “Image storage” in the Initial Program Loaders (IPLs) chapter of Building Embedded Systems.
A system that uses the QNX Graphics Framework (GF) needs to power up the GPU before it initializes the graphics functionality. Refer to the hardware specifications for your board to determine whether your GPU requires the startup code to perform this task. For example, some boards enable the GPU by default and others require you to set the voltage and enable it.
Depending on your system’s requirements, you can configure the startup code to turn on only some graphics resources (for example, the display controller only). Other graphics resources can then be turned on after startup when they are needed (for example, using a driver).
The kernel uses callouts to provide the QNX Neutrino kernel and process manager with hardware-specific code. If your hardware platform isn't supported by the callouts in the startup library, or by any of the available board-specific callouts, you write your own.
For information about the callouts and how to write a kernel callout, see Kernel Callouts in Building Embedded Systems.