How to create your own machine

Template:ArticleMainWriter Template:ArticleApprovedVersion

1 Introduction[edit]

For your own needs, you can add in the Yocto project a new machine reflecting your own board and your own features.
This article is reserved to Yocto experts or at least people who have already practiced with the Yocto environmment.

This section describes how to add and configure a machine that is similar to those that the OpenSTLinux Distribution Package already supports.
This customer machine is associated to STM32CubeMX tool which provides DeviceTree files per component (tf-a, u-boot and kernel).

We suppose here that all the material described below is done inside an existing STM32MP BSP layer 'addons'.
For reminder this addons layer is deployed here in our delivery : <path of OpenSTLinux distribution delivery>/layers/meta-st/meta-st-stm32mp-addons/

2 Generate devicetree[edit]

The principle is that the user generates devicetree files from the STM32CubeMX tool.
With the STM32CubeMX tool, the user browses inside the OpenSTLinux distribution file system until “mx” folder located into STM32MP BSP layer addons : <path of OpenSTLinux distribution delivery>/layers/meta-st/meta-st-stm32mp-addons/mx/

  • 3 sub-folders are created and populated with generated devicetree files :
    • <ProjectName>/kernel
    • <ProjectName>/u-boot
    • <ProjectName>/tf-a

Where <ProjectName> is the “STM32CubeMX user project name”

Each directory of <ProjectName> contains devicetree files associated to the component directory, here: kernel, u-boot and tf-a (Trusted Firmware-A).
Please refer to this page for more details on this tool and its usage :

3 Create a custom machine[edit]

Create a machine based on the one provided by ST and align some environment variables with the content of mx/<ProjectName> sub-folders

3.1 Create the new machine[edit]

  $> cd <path of OpenSTLinux distribution delivery>/layers/meta-st/meta-st-stm32mp-addons/conf/machine
  $> cp stm32mp1-mx.conf stm32mp1-<ProjectName>.conf
  $> cd include
  $> cp stm32mp1-<ProjectName>
  $> cp stm32mp1-<ProjectName>

3.2 Edit the new machine file: stm32mp1-<ProjectName>.conf[edit]

Replace these 2 lines :

include conf/machine/include/
include conf/machine/include/

By these ones :

include conf/machine/include/stm32mp1-<ProjectName>
include conf/machine/include/stm32mp1-<ProjectName>

3.3 Edit the new machine config file: stm32mp1-<ProjectName>[edit]

In this config file you can select :

* boot scheme (by default trusted is set)
* boot device  (by default sdcard is set)
* board (by default eval is set)
* name of CubeMX Board DeviceTree files (by default stm32mp157c-defaultmxconfig-mx is commented)
* path of CubeMX Board DeviceTree files (by default STM32MP157C-EV1/Templates/DefaultMXConfig/DeviceTree/DefaultMXConfig is commented)

To select one of each parameter you have just to comment and uncomment lines, and modify CUBEMX_DTB accordingly to the name of CubeMX Board DeviceTree files

3.4 Create symbolic link for EULA with new machine created[edit]

To support GPU and third party content, you need to accept the EULA. So a symbolic link must be created with the EULA existing file and the new machine :

  $> cd <path of OpenSTLinux distribution delivery>/layers/meta-st/meta-st-stm32mp-addons/conf/eula
  $> ln -s ST_EULA_SLA stm32mp1-<ProjectName>

4 Miscellaneous[edit]

4.1 MACHINEOVERRIDES regular expression[edit]

In each customer machine we retrieve this line:

MACHINEOVERRIDES .= ":stm32mpcommonmx"

A regular expression that resolves to one or more target machines with which a recipe is compatible.

The impact in the build environment is that recipes can now do things conditionally only on the builds for all mx specific machines: stm32mpcommonmx
It is very useful in some existing recipes to keep the compatibility for all stm32mp1-<ProjectName>.conf machines.
For instance use it like this (as it is done in the recipe <path of OpenSTLinux distribution delivery>/layers/meta-st/meta-st-stm32mp-addons/recipes-bsp/alsa/alsa-state-stm32mp1.bbappend):


The append will be applied for all machines (all stm32mp1-<ProjectName>.conf) which include MACHINEOVERRIDES .= ":stm32mpcommonmx"

So it avoids to create an append file by customer machine.

4.2 STM32CubeMX class[edit]

A dedicated class is provided here :

<STM32MP BSP layer addons>/classes/cubemx-stm32mp.bbclass

The main goal of this class is to manage any change done by the customer in sub folders mx/<ProjectName>/...

So if a devicetree file is updated for one or more of components, this change will be taken into account automatically during the next compilation done in the Distribution Package.

5 Compile your image with the yocto build process[edit]

 $> cd <path of yocto delivery>
 (directory which contains meta-st, openembedded-core, meta-openembedded)
$> MACHINE=stm32mp1-<ProjectName> DISTRO=openstlinux-weston source layers/meta-st/script/ Accept the term of EULA (if you agree with)
$> bitbake st-image-weston The generated images are available on build-openstlinuxweston-stm32mp1-<ProjectName>/tmp-glibc/deploy/images/stm32mp1-<ProjectName>