DH electronics GmbH
Zu Deutsch wechseln
scroll Scroll Down down

Linux as operating system

In addition to hardware development, software development is also one of our core competencies

We have been involved in the development of individual embedded systems for more than 30 years. Over time, we have specialized in Linux as an embedded operating system and today support a Linux system based on Yocto and Debian with our BSP. We are convinced of the open source movement and make our code available to the Linux kernel community

Mainline-kernel vs. vendor-kernel

Several factors come into play when deciding between the mainline kernel and the vendor kernel:

  • Security and CRA (Cyber Resilience Act)
  • Up-to-dateness and version flexibility
  • Quality control and workarounds
  • Binary blobs and dependencies

  • Problems are solved in a generic way in the mainline kernel

    To summarize, choosing a kernel from one vendor comes with disadvantages in terms of security, timeliness, flexibility, quality control, binary blocks and CI/CD compatibility. However, all these disadvantages can be overcome by using the mainline kernel.

Yocto layer structure

Yocto basically uses various layers that together make up the build system and can be used to build a Linux image. These layers contain recipes from which the individual software packages are built and configurations in which the properties of the resulting system are configured.

All Yocto layers are also Git repositories, where each Yocto version that the layer supports is a separate branch.
The layers each have a different purpose.

The following layers are usually used in a build for a DHSOM module:

Yocto base layer (poky, https://git.yoctoproject.org/poky/)
The “poky” layer contains the core of the build system (bitbake) and recipes for the most important packages and libraries that are often required for the base system.
The layer is managed by the open source community under the umbrella of the Yocto Foundation.

OpenEmbedded layer (meta-openembedded, https://git.openembedded.org/meta-openembedded/)
“meta-openembedded” contains a large number of recipes for popular packages and libraries.
The layer is managed by the open source community.

Mainline layer (meta-mainline-common, https://source.denx.de/denx/meta-mainline-common)
The layer contains regularly updated recipes for the various LTS versions of the Linux kernel, U-Boot and Mesa (general graphics driver). These are the mainline versions without any patches.
The layer is managed by DENX.

DH BSP layer (meta-dhsom-imx-bsp (for i.MX6, i.MX8), https://github.com/dh-electronics/meta-dhsom-imx-bsp, meta-dhsom-stm32-bsp (für STM32MP), https://github.com/dh-electronics/meta-dhsom-stm32-bsp)
This layer contains the adjustments so that images for DHSOM modules can be built. These include patches for kernel and U-Boot (from the mainline layer) and the build configurations for the various modules.
These layers are managed by DH.

DH Extras layer (meta-dhsom-extras, https://github.com/dh-electronics/meta-dhsom-extras)
This layer primarily contains a modular demo image (dh-image-demo). This demo image can be used to test various aspects of the DHSOM modules.
In addition, useful adaptations are available for a few packages.
This layer is managed by DH

Various layers for different frameworks or software packages (optional)
If required, there are special layers for various frameworks or software packages that can be integrated into the build. Examples of this are

  • Qt (meta-qt5, meta-qt6)
  • Flutter (meta-flutter)
  • Webkit webbrowser (meta-webkit)

The customer layer is specific to the respective customer or the respective customer project. The layer usually contains the following:

  • Customized kernel and bootloader
  • Recipes for customized packages
  • Recipe adaptations for packages from other layers
  • Customized configuration of the image

The layer is not public, but hosted in the non-public DH GitLab or at the customer's site.

When working on a customer project, only the customer layer is changed.

In order to “fix” a build so that it can be repeated in the future with the same result, the build must be carried out with the same statuses (= commits) of the respective Yocto layers with which the original build was carried out. The KAS tool can help with this.

If you want to get the latest security updates for a project, it is sufficient to roll the current versions of the various higher-level layers. The updated recipes are then used. If you extend a recipe from another layer in the customer layer, it may be that something has to be adapted here as a result of the update.

More information on our maintenance contract

Mainline support (upstream support)

Every new DH System On Module (SOM) is upstreamed to Mainline Linux and U-Boot. There cannot be a mainline version of a System On Module directly, as only a finished product can be upstreamed. Therefore, the System On Modules are always upstreamed on the basis of the respective evaluation board.
 

Here is an overview of our SOMs and the evaluation boards:

+

The Yocto-based BSP also uses the mainline version and not a vendor version from the SoC manufacturer. This makes it much easier to maintain the BSP and keep it up to date.

Maintenance of the BSP is based on the combination with the evaluation board and is free of charge.

For customer-specific projects, the reference design is always used as the basis for creating a customized BSP for the respective product. The Yocto structure is also designed in such a way that the basic BSP can continue to be used unchanged. This has the advantage for the project that an updated basic BSP can be adopted more easily.

KAS Tool

KAS (https://github.com/siemens/kas)  is a Python tool that supports the workflow of building Linux images with Yocto/OpenEmbedded by offering a wide range of possible configurations.

KAS not only simplifies the configuration of Yocto systems, but also allows them to be easily extended with additional software support. This keeps our software systems up-to-date and therefore secure.

KAS covers the following areas:

  • Downloading the various layers required for the build
  • Initializing the build environment and configuration for the build (e.g. target hardware)
  • Starting the build

KAS works with configuration files in which the various layers and configuration options to be used are defined. Selection options can also be defined.

These selection options can be selected via a console-based GUI (as with the configuration of the Linux kernel).

In the DH repository for building Yocto images with KAS (https://github.com/dh-electronics/kas-dhsom) for example, this GUI can be used to select the DHSOM module for which the image is to be built (e.g. i.MX6, i.MX8MP or STM32MP15) and to control which components are to be integrated into the demo image (e.g. Qt, various web browsers, Flutter). This is the great advantage of KAS. Once the KAS configuration files for a project have been created, it is relatively easy to build a Yocto image with KAS, even for someone with no knowledge of the Yocto/OpenEmbedded build process.

Projects with different hardware variants, each of which requires its own builds, can also be mapped very well with KAS, as a selection option can be included in the KAS configuration files. For example, if you release a build image on your device, the KAS configuration can be extended by an option that fixes the Yocto/OpenEmbedded layers to the respective status of the released image. This enables reproducible builds.

+