Factory Directory Map

While in-depth knowledge of the inner workings of Desktop Factory is not needed by the majority of users, many will find a brief introduction to Desktop Factory's directory structure beneficial in understanding the patching, building, and cleaning operations done by factory.

Top-Level Factory Directory

The flexible nature of Desktop Factory allows for it to be installed in a location determined by the user. To help define the directory structure, and eliminate variance in installation directories, we refer to the installed Desktop Factory as "top-level Factory directory" or simply "Factory directory. It is commonly named factory or factory-yyyymmdd (Factory release date) depending on how the Desktop Factory is obtained.

*NOTE:* Once installed, it is not recommended to change the location of the Desktop Factory buildsystem during the course of development. In instances where this is necessary, a new Factory should be installed and the existing workorder copied to the new location.

When obtaining Desktop Factory as a tar archive from the Timesys Git repository, the top-level Factory directory will be factory-[release date] where [release date] is in the form of yyyymmdd. The location of Desktop Factory is controlled by the user, based upon where the tar archive is extracted.

For example, Desktop Factory for the release on March 17th of 2015 would look be named factory-20150317

Similarly, when Desktop Factory is obtained via the Factory-Installer script found in the output of a Web Factory build, the installed Desktop Factory's top-level Factory directory will also be named factory-[release date] as explained with the tar archive option. In this case, however, the [release date] is determined by the release date of the Web Factory used to produce the Factory-Installer script. The location of the Desktop Factory created is requested as input from the user during the installation process (default location is /home/[username]/timesys/[board]/factory-[release date]).

The default top-level Factory directory for a Desktop Factory installation cloned from Timesys' Factory Git repository is simply named "factory" - the same as the Desktop Factory Git repository. Another name for this top-level Factory directory can be specified by the user at the time of cloning.

Note: The Top-Level Factory Directory can be referenced within the Factory workorder as $(BASE_DIR)

Factory Contents

There is a slight variance in what is in the top-level Factory directory initially and depending on what stages of the BSP/SDK build have been completed (if any).

Initial Factory Contents

When starting with a new, pristine Desktop Factory, the contents of the top-level Factory directory contains the following directories:

  • toolchain/ directory contains the KConfig definition files (Config.in) for each toolchain component as well as the host utilities that are built with the toolchain. It also contains each component's corresponding make rules file (*.mk).
  • bin/ directory contains scripts that are useful in extending the Factory buildsystem.
  • doc/ while most documentation is available online, this directory contains info about licensing, Factory version, and Factory changelog
  • include/ directory contains common make rules (common.mk, target.mk, and host.mk) along with the KConfig library.
  • target/ directory contains sub-directory structure which houses the makefiles and default Kconfig definition files for various components available for selection (target boards, kernel, toolchain, packages, etc) that can be built and included within the BSP/SDK.
    • target/kernel/ contains the kernel KConfig definition file and make rule file.
    • target/bootloader/ contains subdirectories for each supported bootloader.
    • target/software/ contains the package category subdirectories and their containing package directories.
    • target/configs contains default configuration files for the kernel and applications.
    • target/early-userspace contains the build instructions for early userspace support.
    • target/installer contains the installer build instructions.
  • .git/ contains the various Git tree components (only found within a Factory installation utilizing Git).

Additionally, the following files can be found here as well:

  • Makefile — This top level makefile includes all other make rule files within the Factory builder tree. It also includes the .config file (the generated work order) that is used by the make rules in generating output.
  • Config.in — This top level Config.in includes all other Kconfig Config.in definition files. It also sets global and default options.
  • .gitignore provides files/directories not to be tracked by Git.

Configured and Built Factory Contents

Once Desktop Factory has been configured and a BSP/SDK build has been completed, the contents of the top-level Factory directory are further expanded to include various configuration files, source files, as well as compiled binary images and the main output of Desktop Factory, the components of the BSP/SDK.


Factory overview (completed BSP/SDK build)

The added items within the top-level Factory directory include:

  • .config — Factory configuration file (workorder).
  • .config.old — Single-iteration backup of the Factory configuration file (workorder), generated after modifications are made through the menuconfig interface.
  • src/dl/ — Directory structure where source files are stored after fetching.
  • src/local/ — User-created directory structure for storing local patches or any other customized files for use with Factory.
  • build_[arch]-timesys-linux-[libc]/ — Directory structure containing patched sources for selected packages, where the build occurs and output is generated.
  • .inc.mk — Makefile indicating additional makefiles to include (for selected software packages) necessary to complete the build.

The more interesting of these additions are the workorder (.config file), and the build_[arch]-timesys-linux-[libc]/ directory.

The workorder is the configuration file generated through the Kconfig interface. This is where the board, kernel, and software package selection is stored and determines what is built during the BSP/SDK generation.

The build_[arch]-timesys-linux-[libc]/ directory is where the majority of the build is completed. The following is included in the the build_[arch]-timesys-linux-[libc] directory.

  • toolchain/ (Toolchain working directory) — This is the working directory for the cross-toolchain — as pieces of the cross-toolchain are built, they are installed in this directory for use.
  • linux-[version]/ (Linux kernel working directory) — This is the kernel working directory — the kernel source tarball is extracted, patched, configured, and cross-compiled in this directory.
  • rfs/ (rfs working (or staging) directory) This is the target system rfs working directory - as software packages are built, they are installed in this directory (more info on the target RFS here).
  • images/ (Images directory) — The BSP components are collected in this directory at the end of the BSP/SDK build.
  • packages/ (Packages directory) — The cross-compiled binary packages of selected software are created in this directory.
  • [package]-[version]/ (Individual package build directories) — Package source files extracted, patched, configured, and cross-compiled.
    • Each package built by factory (including the kernel and cross-toolchain components) is processed in its own directory within this build_[arch]-timesys-linux-[libc]/ directory.

In addition to the directories listed above, the build_[arch]-timesys-linux-[libc]/ directory also includes a few files generated during the BSP/SDK build.

  • [board]-development-environement.shSDK installer
  • toolchain-initial-[arch]-timesys-linux-[libc].tgz — Bare cross-toolchain
  • toolchain-final-[arch]-timesys-linux-[libc].tgz — Bare cross-toolchain plus any package libraries selected by the user