Skip to content

Modify the BSP

More about BSP-Customization

You can find more specific information and examples in the platform-specific BSP documentation.

Modifications and Collaboration

If you make any modifications to the BSP yourself and you want to use these changes in your final product, think about where to save your changes. If you work on a BSP together with KED engineers, you can use the KED GitLab server for your custom build and meta-layer repositories.

Local or temporary modifications

On the first initialization a local.conf file is created in the conf directory of your build. This file is usually not tracked by git and is meant to be used only for local or temporary changes. Please check local.conf and read the comments in the file to find out about some default options.

The default local.conf file includes the sourcecode-version.conf and user.conf file if available. sourcecode-version.conf is meant to contain the sourcecode version number for all sourcecode compiled (can be used as software release number). It should be kept in sync with repo.conf.

Furthermore the user.conf file is meant to hold user specific settings that may be different between different developers. One such example is the URL variable for the package server (PACKAGE_FEED_URIS).

Keep Modifications in the Right Place

If you have changes in your local.conf that should not stay local, but need to be set as default for everyone who uses the build, then find a way to move these changes to the correct file. Some popular places in the meta layers are:

  1. The image recipe in recipes-core for image-specific settings
  2. The distro config in conf/distro for distro-specific settings
  3. The machine config in conf/machine for machine-specific settings
  4. Recipe of some package for package-specific settings

Contribute to KED layers

If you need to work around a problem in the KED layers by adding code to your own layer, think about whether you can fix the root of the problem in the KED layer and create a "Merge Request" with the changes for the KED repository (e.g. meta-ktn).

Create your own layers

If you want to make modifications to the BSP, we suggest to create your own layers to keep your modifications reproducible and to separate them from other layers. For customer boards Kontron uses a build-<CUSTOMER> repository and a meta-<CUSTOMER> layer to keep the modifications for special customer boards.

The build-<CUSTOMER> repository describes which layers in which version are required to build the product. It works just like the KED build repositories, which you can use as a blueprint for your own build repository.

The meta-<CUSTOMER> layer holds all adaptions for the custom hardware and software. This can be additional recipes or adaptions to some recipes, separate images, configurations and so on.

Also see the Yocto documentation for creating layers.

Using devtool to work on source code

To work on the source code of any package it is most convenient to use the devtool utility. As an example we will show how to modify the kernel code.

Devtool

For more information about the substantial devtool, please visit the Yocto Manual.

Example with linux-stm32mp

To start working on the linux-stm32mp code:

devtool modify linux-stm32mp

A separate workspace layer will be created and the kernel source tree will be extracted there. Do your code changes and run a build with: 

bitbake linux-stm32mp

Test your changes and create patches if necessary. To reset to the previous state and build without the changes in the workspace run: 

devtool reset linux-stm32mp