Configure a Primary and 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.

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 (initial program loader) 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:

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.
These are the suggested minimum set of files (excluding any dependencies) to include in the primary IFS to run Screen:
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:
Note: You can run the objdump_variant (e.g., ntoarm-objdump or ntox86-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.

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.

Determine 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.

Determine 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 algorithm:
"screen-" + <value of alloc-config> + ".so"