Building Target RFS

Table of Contents

Here we'll discuss working with your target RFS and Timesys tools. The focus of this document is to familiarize you with how you build your target's RFS with the Desktop Factory buildsystem.

Target RFS Introduction

The target RFS is the root filesystem for use on the running target system. The directory structure is similar to that of desktop Linux distributions. The target RFS for an embedded systems is commonly stripped of many unnecessary items to reduce the overall filesystem size due to limited storage, and to provide only specific functionality. This can include the removal of installed package man and info pages and the stripping of binaries and libraries of debug symbols among other filesystem size reduction options.

During the BSP/SDK build process, Desktop Factory builds up the target RFS within the RFS working directory (build_[arch]-timesys-linux-[libc]/rfs/). As each selected software package gets built, it is installed to this RFS working directory. It is in this way that the target RFS is built up consisting of only the packages and components selected in the workorder.

Initial RFS Build

Since the Desktop Factory is set to build the target RFS during the BSP/SDK build process by default, generating the target RFS is as easy as configuring Factory and selecting which packages to include in the RFS via one of the provided Factory configuration tools. Once configured, building the BSP/SDK with the following from the top-level Factory directory will automatically generate the target RFS:

make

With this, Desktop Factory starts the BSP/SDK build process. After each selected package is cross-compiled, it is installed to the RFS working directory (build_[arch]-timesys-linux-[libc]/rfs/) thereby progressively building up the target RFS. Once the all of the selected software packages are built and installed, the RFS working directory is then further processed according to RFS Build options selected in the workorder (size reduction options, such as stripping operations, removal of man and info pages, etc) and any user-specified customizations are run (RFS Customization Script and/or RFS Overlay). After any selected RFS size reductions and user customizations are completed, the RFS images used in the BSP and SDK Installer are generated. By default the RFS image format is set to tar archive, though many other options are also available.

Target RFS Build Process

As mentioned, Factory is designed to build the target RFS automatically during the BSP/SDK build. While an in-depth knowledge of how the RFS is generated is not necessary for most users, some may find a brief summary of how this occurs and fits in with the overall Factory buildsystem useful. This can be broken down into three sections as illustrated below.


Factory target RFS build process

Building Target RFS

Based on the configured workorder (minimally selecting a target board and init system, i.e. busybox or combination of sysvinit + bash), the BSP/SDK build starts by building the host tools that are necessary to complete the remaining cross-compilation of target system components. This typically includes ccache, gcc cross compiler suite (c library, binutils, etc.), as well as other host tools being run from the x86 host machine.

Once the host tools are completed, Factory moves onto cross-compiling selected target software packages. It is during this portion of the BSP/SDK build that the RFS is built up in the target RFS working directory build_[arch]-timesys-linux-[libc]/rfs. After a package is cross-compiled, it is then installed to the target RFS working directory and a couple of hidden RFS-related .stamp* files are created in the package's build directory to indicate which RFS install steps have occurred for each package. It is with these .stamp* files that Factory is able to determine when a newly selected package needs to be installed to the target RFS working directory.

Modifying Target RFS

Once all the selected packages have been cross-compiled and installed to the target RFS working directory, Factory moves on to further process the target RFS. This is when user customizations are applied — first, the RFS Customization script, followed by the RFS overlay. After these user customizations are applied to the RFS working directory, the RFS Pruning options are applied (removal of man and info pages, stripping of binaries and libraries, and any other RFS Pruning option selected in workorder), along with the removal of initscripts (if selected) and the installation of custom initscript and/or workorder to the target RFS (again, if selected).

Packaging Target RFS

It is at this time that the RFS images selected in the workorder are generated from the target RFS working directory and placed in the BSP location (build_[arch]-timesys-linux-[libc]/images/rfs/).

Factory Built RFS Options

As mentioned earlier, the default setting in Desktop Factory is to build the target RFS. Other RFS-related defaults are automatically set along with this RFS build option. These can be reviewed in greater detail within the menuconfig interface by navigating to Target Configuration > Build RFS and selecting Help for any of the options listed within. The default RFS build options are set as follows:

  • Strip all libraries and binaries in the RFS
  • Remove Man Pages
  • Remove Info Pages
  • Remove development header file directories
  • Remove all static library files
  • Remove i18n
  • Remove locale
  • Remove zoneinfo
  • Remove gconv
  • Remove /usr/doc and /usr/share/doc directories
  • Remove pkg-config entries
  • Remove aclocal macro files
  • Build a tar archive RFS image

Additional RFS options include the ability to:

Note: Debug symbols are removed from the target RFS when Strip all libraries and binaries in the RFS is selected in the workorder. For debug purposes, these symbols can be built separately from the RFS images and re-introduced to the running target system via Factory-built binary packages with debug symbols for selected software. This can be enabled in the workorder through the menuconfig interface by selecting Target Configuration > Build Packages of selected Software and Target Configuration > Build Packages of selected Software > Build Debug Symbol packages.

Remove Initscripts

This option allows for the removal of initscripts originating from selected software packages. Selecting this option will still maintain basic system initialization.

Option Location: menuconfig > Target Configuration > Build RFS > Remove Initscripts

Add Custom Initscript

This option is intended to replace the any existing /etc/init.d/rc.local script in the target RFS with one specified in the workorder.

Option Location: menuconfig > Target Configuration > Build RFS > Custom Init script

Install Factory Workorder to RFS

This option simply adds the Factory workorder to the target RFS (under /etc/workorder). This is useful when trying to determine which system a particular RFS was built for or what packages are included in an particular RFS.

Option Location: menuconfig > Target Configuration > Build RFS > Install Workorder to RFS

Do Not Install C Library to RFS

This option can be selected to forgo the installation of the C library to the target's RFS. This is useful if applications are statically linked and do not require a runtime C library. Selecting this option also prevents libgcc and libsdtc++ from being installed to the target RFS.

Option Location: menuconfig > Target Configuration > Build RFS > Do not install the C library in the RFS

RFS Image Formats

In addition to the default tarball RFS image output by the Factory BSP/SDK build process, each of the following can be selected in place of, or in addition to the default tar archive RFS image:

  • cpio
  • cramfs
  • squashfs
  • jffs2
  • ext2
  • ubifs
  • yaffs2

These selections add the RFS image type to be automatically generated during the RFS image creation portion of the BSP/SDK build process. If additional RFS image formats are selected after the initial build completes, the new RFS images can be created with the following:

make rfs-images

Options Location: menuconfig > Target Configuration > Build RFS > under *** RFS Output Formats *** .

Adding a Package to the RFS

Once the RFS has be built with Factory, to add a package, simply select the package in the workorder via menuconfig and build the BSP/SDK.

There is no need for Factory to rebuild existing software packages, or the RFS working directory.

In order to add a package, select it in the Factory workorder, install it to the RFS working directory and regenerate RFS images.

  1. Select new package via menuconfig
    • menuconfig > navigate to package, select package
  2. Exit menuconfig and save workorder
  3. Build and install new package to RFS working directory
    • run make [package]-rfs-install from the top-level Factory directory
  4. Generate new RFS images and rebuild SDK Installer
    • run make installers from the top-level Factory directory

Note: Running make from the top-level Factory directory will accomplish both steps 3 and 4 automatically for you.

Removing a Package from the RFS

Once the RFS has been built with Factory, removing a package from the via menuconfig does not automatically remove the package from the RFS working directory or RFS images. In order to accomplish this, the RFS working directory needs to be removed and recreated. Since the toolchain and individual packages do not need to be rebuilt, packages still selected in the workorder will only need to be re-installed to the RFS working directory and the RFS images regenerated. This helps reduce rebuild time for the system when removing packages from the build.

This can be done via the following command run from the top-level Factory directory:

Note: This is a destructive operation, removing the build_[arch]-timesys-linux-[libc]/rfs/ and build_[arch]-timesys-linux-[libc]/images/rfs/ directories. Any manual modifications in these locations will be lost.

  1. De-select unwanted package via menuconfig
    • Run make menuconfig from top-level Factory directory, then navigate to package, de-select package
  2. Exit menuconfig and save workorder
  3. Remove the RFS working directory and any RFS images in build_[arch]-timesys-linux-[libc]/images/rfs/
    • Run make rfs-distclean from the top-level Factory directory
  4. Re-install selected packages to the RFS working directory and rebuild RFS images
    • Run make rfs-images from the top-level Factory directory
  5. Rebuild the SDK installer, incorporating the new RFS images
    • Run make installers from the top-level Factory directory

or steps 3-5 shortened to

make rfs-distclean && make

The resulting RFS images in the build_[arch]-timesys-linux-[libc]/images/rfs/ directory (and included in the SDK installer) will reflect the latest software package selections.