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
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.
local.conf file includes the
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
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
- The image recipe in
recipes-corefor image-specific settings
- The distro config in
conf/distrofor distro-specific settings
- The machine config in
conf/machinefor machine-specific settings
- 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.
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.
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.
For more information about the substantial
devtool, please visit the Yocto Manual.
Example with linux-stm32mp
To start working on the
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:
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