A cheat sheet for bitbake:
STM32 MPU Wiki:
For Yocto a Linux Host Machine is needed.
The supported distributions for Thud are listed at the official Yocto documentation.
If you’re running such a machine, you should be fine, else we recommend to use VirtualBox to run a virtual machine. Use an Ubuntu 16.04 or 18.04 instance. Get a virtual machine image from osboxes.org.
See their guide to run the virtual machine image.
An important consideration is the hard disk space required for the virtual appliance. At least 120 GiB is provided, 500 GiB would be better.
The Yocto framework requires dependencies that need to be available on the host system to run builds.
To meet minimal version requirements you should have the following installed:
Git 126.96.36.199 or greater
tar 1.27 or greater
Python 3.4.0 or greater
If your system does not meet these requirements see this.
To get the right packages for your build host, have a look at the official Yocto project documentation.
Essential Yocto Project host packages are:
sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib
build-essential chrpath socat cpio python python3 python3-pip python3-pexpect
xz-utils debianutils iputils-ping
Setting up Git¶
If not already done, setup git with the commands below:
git config --global user.name "Your Name"
git config --global user.email "Your Email"
git config --list
Setting up the Repo Utility¶
Repo is a tool built on top of Git that makes it easier to manage projects that contain multiple repositories, which do not need to be on the same server. Repo complements very well the layered nature of the Yocto Project, making it easier for users to add their own layers to the BSP.
To install the “repo” utility, perform these steps:
Create a bin folder in the home directory:
mkdir ~/bin (this step may not be needed if the bin folder already exists)
curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo
Add the following line to the
~/.bashrcfile to ensure that the
~/binfolder is in your PATH variable:
The Repo tool checks out different layers for you, which are defined in our XML-manifest. Their source code can be found in
layers directory, which contains the recipes and machine configurations used to build the image.
QSMP DevelopmentKit, TXMP Series
karo-stm-bsp is just an example and can be chosen free.
repo init -u https://github.com/karo-electronics/karo-stm-bsp -b <branchname>
You can update the codebase to any time if you want to, which can be performed via the following command:
Syncing the repo might take some time.
The sources are now set up.
We edited ST’s script,
envsetup.sh, to fit the setup for our machines. To use the script, the machine name
needs to be specified as well as the desired distro. The script sets up a directory and the configuration
files for the specified machine and distro. It also adds our layer to the
To get a better understanding of the layers we applied our changes to, you could have a look at STM’s documentation: https://wiki.st.com/stm32mpu/index.php/OpenSTLinux_distribution
There are different configurations you can choose from.
OpenSTLinux featuring eglfs - no X11, no Wayland
OpenSTLinux featuring Weston/Wayland
OpenSTLinux featuring X11
— DEFAULT OPENEMBEDDED SETTING: DISTRO is not defined —
A list of supported MACHINE configurations:
Machine configuration for the QSMP-1570-QSBASE1 Evaluation Kit
Machine configuration for TXMP-1570 module on MB7
Machine configuration for TXMP-1530 module on MB7
Use the command below to setup your build directory (specify the distro you want to use, the machine, and the build directory):
DISTRO=<distro> MACHINE=<machine> source layers/meta-karo-stm/envsetup.sh <build-dir>
After accepting the EULA, your current directory should have changed to the
<build-dir> you chose before.
DISTRO=openstlinux-weston MACHINE=qsmp-1570-qsbase1 source layers/meta-karo-stm/envsetup.sh build-qsmp-1570-qsbase1
When building your image, four U-Boot versions will be built.
U-Boot with default environment to write inside the eMMC and boot your module.
U-Boot with an empty environment.
U-Boot with enabled fastboot protocol. (e.g. used when flashing your device)
U-Boot with secure-boot enabled.
ARM® Trusted Firmware¶
Every image also builds the Trusted Firmware you will need to program and boot your board.
Details on how the ARM® Trusted Firmware works you will find on: https://wiki.st.com/stm32mpu/index.php/TF-A_overview
You can build the Trusted Firmware with or without (default) debug output.
To set this, go to your
conf/local.conf inside your build-directory and set the variable:
TF_DEBUG = "1"
Building an Image¶
Before starting a build, you should consider enabling the SSTATE CACHE to speedup the build process.
Here are the different images you can build :
OpenSTLinux weston image with basic Wayland support (if enabled in distro)
OpenSTLinux core image
ST example of image based on QT framework
ST example of image based on X11
ST example of image based on XFCE framework
ST example of image based on GTK framework
Build the image with the following command inside your
For your headless boards you are fine with the
st-image-core. When you are using a display you can build the
st-image-weston. There you can also test the working GPU on the XXmp-1570 variants.
After a build is complete, the created images and files are in the
Inside this directory is a folder named
/flashlayouts, containing .tsv files with partition layouts to flash your board.
To flash your board with these files, proceed with STM32CubeProgrammer.