Skip to content

Kontron Electronics GmbH Boards and Modules

See Website for Hardware Specifications and User/Design Guides

This section contains documentation, examples and references for integration between hardware and software. This is mainly intended for software development. For hardware specifications, datasheets and user/design guides, please visit our website.

Customer Specific Configurations

Kontron Electronics provides customer specific configurations for their products. Please contact our sales department at sales@kontron-electronics.de for further information.

Customer OTP Fuse Configuration Values

To specify the desired OTP fuse configuration for your customized product, see the currently available OTP fuse configurations:

Customer Flash Programming File Formats

For customer flash programming, the following file formats are required:

  • Bootloader in NOR flash or eMMC boot partition
    Binary bootloader without offset (e.g. flash.bin, as created by KED Yocto BSP)
  • NAND image (e.g. UBI image with Linux filesystems) One UBI image for the whole NAND flash device. Be careful: The UBI image contents has to fit to the hardware configuration of the NAND device!
  • eMMC image (e.g. partitioned image with Linux filesystems)
    A *.wic.gz image with the corresponding *.wic.bmap file, created by bmaptool as generated for all platforms by KED Yocto BSP

Creating a *.wic.bmap file outside a Yocto build pipeline

For the bmaptool to be useful, it's essential, that the originally used *.wic image file, from which the *.wic.bmap file is created, contains so called 'holes'.

These 'holes' represent not yet written data areas in a file on a disk. Based on this information, bmaptool creates a *.wic.bmap file alongside the original *.wic image file with the information about the position and sizes of all 'holes' in the original *.wic file.
With this information, bmaptool can later skip writing the 'hole' areas to the flash and can speed up writing the image to the flash significantly this way. The acceleration is dependent on the amount and sizes of the contained 'holes' in the original *.wic file.

It is important to know that the original *.wic file looses its holes, when it is compressed or copied as usual! Running bmaptool on a *.wic file without 'holes' becomes useless.

Therefore we recommend strongly, to use Yocto and its build pipeline to create the *.wic.bmap files, else it is easy to render them useless!

We recommend to provide the files to Kontron Electronics GmbH

  • in a compressed ZIP archive,
  • containing a 'README' file and
  • a MD5 checksum file to assure completeness and integrity of the package in whole

The README file should contain the following information for identification

  • Customer
  • Customers product identification
  • Kontron item number for the product to be equipped with
  • Customer version information of the contained software/collection
  • Customer contact person and contact details in case of queries

For example something like this:

CUSTOMER: Demo Company
PRODUCT: Kontron i.MX8MM SOM with Demo Companys firmware
KONTRON ITEM NO: 40123 456
VERSION: 1.0.0 (31.12.2025)
CONTACT: development@demo-company.com

Some more additional information here ...

This is an example how the production artifacts can be packed:

dev@democo:~/$ cd production-artifacts/

dev@democo:~/production-artifacts$ ls -1
emmc.wic.bmap
emmc.wic.gz
flash.bin
README

dev@democo:~/production-artifacts$ FILE=contents.md5sum; find -type f | sort | sed /${FILE}/d | xargs md5sum > ${FILE} && md5sum -c ${FILE} && zip -r ../production-artifacts.zip *

./emmc.wic.bmap: OK
./emmc.wic.gz: OK
./flash.bin: OK
./README: OK
  adding: contents.md5sum (deflated 43%)
  adding: emmc.wic.bmap (stored 0%)
  adding: emmc.wic.gz (stored 0%)
  adding: flash.bin (stored 0%)
  adding: README (deflated 17%)