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:

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.

These are the suggested minimum set of files (excluding any dependencies) to include in the primary IFS to run Screen:

the Screen resource manager binary (screen)
the Screen API (libscreen.so)
the memory manager used by Screen (libscrmem.so and libmemobj.so )
the Screen configuration file (graphics.conf)
the memory buffer allocator for the hardware board (screen-<name>.so where name is name specified in the alloc-config property in the graphics.conf. Typically, name includes the name of your hardware platform (e.g., imx6xbuf). For information about the file name, see the “Determine the name of the board-specific memory buffer file” section later in this chapter.

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:

the display driver library (libWFD.so)
the minimum board-specific libraries and display drivers. To understand how to determine the files to include, see the “Determine the board-specific libraries to include” section later in this chapter. If you have any custom drivers for your board, you should also include them in the primary IFS.
the splash screen application binaries and any related files and libraries that the application uses. For example, if you want to show content from a PNG image file, in addition to binaries for the splash screen application, you should include:
- the codecs files for the image file (e.g., img_codec_png.so, libimg.so)
- the image file (e.g., splash_screen_application.png file)
- any other configuration files required for your splash screen application (e.g., splash_screen_application.conf)
  Note: You could statically link the libraries required for your splash screen application to reduce the number of libraries to load into the 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:

EGL — The GPU-related files that are candidates to be loaded later (i.e., not necessary required in the primary IFS, depending on your system requirements).
WFD — The display device drivers that Screen requires.

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"