With the QNX Neutrino RTOS and its microkernel architecture, you can modify the script section
in the buildfile to start services or applications earlier to take advantage of any idle time on the CPU.
This flexibility lets you start certain components in your system earlier.
The script section is used to generate the boot script for a system.
Figure 1. Optimize the script section in the buildfile.
You can start applications before starting some device drivers–if it's sensible for your system and
the hardware platform permits you to start device drivers as required. For example, if your system requires
network connectivity, you would need to start a network driver, but because the splash screen application
doesn't require network connectivity, you could, in fact launch your splash screen application before you
start the network driver. This way, the system can show the content on the display more quickly because
it won't need to wait for the network driver to start.
CAUTION:
This technique requires that you have a good understanding of the configuration of your buildfile. If
any file is missing in the configuration, your system may fail to boot.
Note:
Some hardware platforms require that all devices drivers be started at one time. For those platforms,
you might not be able to use this technique to start applications before some of the device drivers.
Typically, the default boot script that comes with your BSP
(see the
BSPs and Drivers project on Foundry27)
have
Screen configured to start as one of the last services. We recommend that
you start the following services in this order as soon as you can:
-
The Screen service (screen)
Note:
Don't use the an "&" (ampersand) to start
screen in the background because the
Screen service automatically puts itself into background when it
starts. If you specify the "&", a
waitfor may be executed, which may increase
the time it takes to show content on the display. For more information, see
Consider the placement of waitfor statements.
- Your Screen application(s) (e.g. the splash screen application)
Other boot script considerations
In some situations, you might want to start some services, such as slogger2 early so that
you can debug your system. This practice is useful in the early stages of the development process, but later
you might choose to disable slogger2 after your system is ready for production. You might
find it useful to keep services, such as slogger2, enabled because it can help customer
support troubleshoot issues in production.
For applications that use hardware rendering (OpenGL ES, OpenVG, blitting, etc.), you can choose
to start the hardware-rendering application at the same time as the splash screen application. Running the
applications in parallel won’t increase the time it takes to show content on the display, despite the fact
that the hardware rendering application may cause device drivers to start, unless there’s CPU or disk
contention.
However, if during the startup sequence or the transition from one application to another application, a
framebuffer gets created, there’s potential for the following to occur on the splash screen application:
-
if the content has been shown, animation (such as a video feed) you might experience momentary
pausing or stutter
- if the content hasn't been shown, the time to show the content may increase