Configure a primary and a secondary IFS on the System

To start up as soon as possible, we recommend that you include only the necessary files (libraries, configuration files, device drivers, binaries, etc.) in the primary IFS.

In general, the fewer components that you have in your IFS, the faster your system can boot. Hence, if there are files that aren't required in an IFS, consider putting them in a filesystem that's mounted by the primary IFS. For example, if you have files that aren't required for a splash screen application to run, but must be loaded into RAM, you should put them into the secondary IFS. For more information about creating an IFS, see the “OS Images” chapter in Building Embedded Systems and the “mkifs” entry in the Neutrino RTOS Utilities Reference.

Since the kernel, Screen, and your splash screen application (if applicable) won't run until the IPL copies the primary IFS from flash memory into RAM, the smaller you make the IFS, the faster the copy operation is, and the sooner those components can begin to run. For more information about the IPL, see About the System Startup Sequence.



Figure 1. Configure a primary and a secondary IFS on the system.

Here's a general guideline of what to put into the primary and secondary IFSs to optimize the boot time:

Primary IFS
Include the kernel, Screen service, and the splash screen application (if applicable), configuration files, and any other components that must be available (e.g. display drivers). For example, if your system requires networking or video from a camera, you'll need to include those binary files in your primary IFS. For general guidelines of what to include in the primary IFS, see Minimum files to load to run Screen later in this chapter.
Keep the size of the primary IFS small. If you have a splash screen application, optimize it to use as few libraries, resources, and device drivers as possible. Since the required libraries are specific to how optimized your splash screen application is, see the Optimize the splash screen application chapter for more optimization techniques.
Note: The binaries required for Screen are listed in the sample buildfile of the Board Support Package (BSP). To find the BSP for your board, see BSPs from our download site.
Secondary IFS
Include the files (libraries, configuration files, other applications) for the components that run after Screen and any applications you start in the primary IFS. For information about Screen-related libraries that can be candidates to load in the secondary IFS, see the Board-specific Screen libraries that can be loaded later section later in this chapter.

Minimum files to load and to run Screen

Though the time saved varies between hardware platforms and system requirements, we have provided a guideline for the minimum set of files to include in your primary IFS.
Note: It's not possible to indicate the exact names of the required files because the file names vary between hardware platforms. For example, the memory allocator file is based on a value in the graphics.conf file.
Below is the suggested minimum set of files (excluding any dependencies) to include in the primary IFS to run Screen:

File for splash screen application

If you're running a splash screen application, then in addition to the files listed above, include the following files (dependencies excluded) in the primary IFS:

Determining dependencies

You can run the objdump_variant (e.g., ntoarmv7-objdump or ntox86_64-objdump) utility on your host to determine any dependencies that the above list of files have. For more information, see objdump in the Neutrino RTOS Utilities Reference guide. For example, you can use this command to determine the list of dependencies:
objdump -x | grep NEEDED
Alternatively, you can set the environment variable LD_DEBUG=lib to show the Screen dependencies.

Statically linking libraries

For some libraries, you can choose to statically link them with your splash screen application. For example, you could statically link the PNG library required to decode your splash screen image. For more information on this technique, see Use statically linked libraries section in the Optimize the splash screen application chapter.

Determining the board-specific libraries to include

To determine the libraries that are required for each hardware board, refer to your default graphics.conf file:

Note: These libraries are not required for systems that don't have a GPU, or don't support displays.

Determining the name of the board-specific memory buffer file

To determine the name of this file, find the alloc-config property in winmgr section of the graphics.conf file and use this nomenclature:

"screen-" + <value of alloc-config> + ".so"