OS Installer

Installing an OS to a non-removable storage (e.g. eMMC) of an embedded board is often a complicated task, requiring significant user intervention during the installation process. The OS Installer offers our customers the following benefits:

  1. reduce user intervention as much as possible
  2. works with all board vendors
  3. make the flash process as fast as possible
  4. allow the user to tweak the flash process using a simple, well-documented, configuration file

As can be seen in the following diagram, the only requirement to run the OS Installer on an embedded board is to have a bootloader that can load a kernel and a ramdisk from a removable storage. The ramdisk includes the OS Installer application and automatically starts it.

The OS Installer application parses the configuration file and then performs all corresponding tasks (flash images, resize partitions, etc).


The OS Installer application parses a simple configuration file and then performs all corresponding tasks (flash images, resize partitions, etc):

  1. simple JSON configuration file to enable/disable features and tweak installation parameters without changing the code
  2. on-screen logging and installation progress
  3. installation log saved to file
  4. quick erase of flash storages like eMMC
  5. speed optimized image(s) flashing
  6. extraction of archive(s) to specific partitions after flashing
  7. ability to show a full-screen message after flashing
os installer diagram kynetics

Frequently Asked Questions

The OS Installer is delivered to the customer as an image that should be flashed to removable storage. The image will be prepared by Kynetics to provide the best integration with the customer's board.

This depends on the available ports / connections on the customer's board. Some boards may have only a microSD slot as removable storage, and some units enclosures may expose only USB port(s). The choice is based on which removable storage is most convenient for the customer, and is supported by the board bootloader.

Dedicated instruction will be provided, depending on the host computer OS (Windows, Mac, Linux). The most common and easy to use tools are etcher and bmaptool.

Once the removable storage is flashed with the OS Installer image an empty dedicated “FFLASH” partition will be ready on it. The user needs to copy all the required artifacts (the configuration file, the image, etc) in the main folder of this partition. If compatibility with Windows is required, “FFLASH” is pre-formatted as FAT32.

This depends on the bootloader that comes with the board. If the bootloader already gives boot priority to the removable storage of choice, no change is needed. Otherwise, changing the boot priority setting is straightforward.

If the image to be flashed is accompanied by a “block map” file (.bmap), then the write tool used by the OS Installer skips all the empty blocks. E.g. if a 1GB OS image needs to be written to a 10GB disk, only 10% of the bytes of the disk will be written.

Kynetics provides a reference configuration file that already targets the customer's requirements for the installation. The flash process can be customized just by editing a JSON configuration file. Documentation is available here. Additionally, a JSON schema file is provided to validate the modified JSON configuration files beforehand. E.g.: the Python jsonschema tool can be used to validate a JSON configuration file as follows:

$ jsonschema -i installation.json installation_schema.json

Yes, any number of images can be written to any number of block storage devices (eMMC, SATA disks, SD cards, USB drives). Wiping only the contents of a storage device is supported as well. Raw NAND storages are not supported.

The OS Installer has the following features, that can be tweaked by the respective configuration entries:

  1. logging: the installation log can be saved to a file in the removable storage. This is useful to analyze eventual errors of the installation process.
  2. backup: existing files on any storage device of the board can be backed up before flashing and restored to any partition of choice after flashing. This is useful if some data (e.g. configuration files) needs to be copied from a previous installation.
  3. erase: storage devices can be erased. This is useful to quickly wipe all the contents of a storage device.
  4. flash: images can be written to storage devices. This is the fundamental feature of the OS Installer, and the only requirement in the configuration.
  5. check-partitions: the presence after flashing of specific partitions can be verified. This is useful to make sure the partition table is consistent with what is expected after the images are flashed.
  6. gpt-fix-backup: the backup GPT partition table can be fixed by copying the primary GPT partition table to the end of the storage device. This is useful as the backup GPT partition is placed at the wrong offset when images are smaller than the storage devices they are flashed to, and needs to be copied to the correct offset.
  7. grow-partitions: partitions, and the included filesystems, can be grown to fit all the available following free disk space. This is useful for example in the case where images have a small last partition that needs to be resized to fill all the available free disk space in the target storage device.
  8. finish: the behavior at the end of the installation process can be configured. This is useful to show messages or automatically reboot the board when the installation is complete.

The actions are performed by the OS Installer in the same order as the respective features in the list herein.

OS Installer as a production tool

The OS Installer is a great tool for programming devices (Android and Linux) in your production line.
In particular, a single Linux based host can easily program hundreds of devices through the USB mass storage gadget enabled in the target bootloader. It is a very efficient way to program multiple targets with minimum hardware requirements.

Are you looking for more information?
Please complete this form.

  • Hidden
  • This field is for validation purposes and should be left unchanged.