Last edited 3 years ago

How to create an SDK for OpenSTLinux distribution

When an OpenSTLinux distribution has been modified, it is pertinent to build a new software development package that integrates the modifications, and to redistribute this SDK to developers (see SDK development cycle model).

1. Prerequisites[edit source]

The Distribution Package relative to your STM32 microprocessor Series is installed: Category:Distribution Package.

On the installation:

  • some pieces of software might have been modified or integrated
  • the build environment script has been executed
  • the selected image has been rebuilt

2. SDK generation[edit source]

The OpenEmbedded build system uses BitBake to generate the software development package (SDK) installation script.

For more information about the SDK, see the SDK for OpenSTLinux distribution article.

Standard SDK generation
Source: Yocto Project[1]

The do_populate_sdk task helps to create the standard SDK and handles two parts: a target part and a host part. The target part is built for the target hardware and includes libraries and headers. The host part is the part of the SDK that runs on the host machine.

  • Check that the build environment script has been executed, and that the current directory is the build directory of the OpenSTLinux distribution (for example, openstlinux-21-11-17/build-openstlinuxweston-stm32mp1')
  • Generate the SDK installation files (including the installation script) for a standard SDK with the following command :
 bitbake -c populate_sdk <image>
Where:
<image> Image name; example:
  • st-image-weston
Example:
bitbake -c populate_sdk st-image-weston
  • The SDK installation files (<image>-<distro>-<machine>-<host machine>-toolchain-<Yocto release>-snapshot.*) are written to the deploy/sdk directory inside the build directory build-<distro>-<machine> as shown in the figure above
Where:
<host machine> Host machine on which the SDK is generated
  • x86_64 (64-bit host machine; this is the only supported value)
<Yocto release> Release number of the Yocto Project; example:
  • 3.1.11 (aka dunfell)
Example
 ls tmp-glibc/deploy/sdk/
st-image-weston-openstlinux-weston-stm32mp1-x86_64-toolchain-3.1.11-openstlinux-5.10-dunfell-mp1-21-11-17.host.manifest
st-image-weston-openstlinux-weston-stm32mp1-x86_64-toolchain-3.1.11-openstlinux-5.10-dunfell-mp1-21-11-17.license
st-image-weston-openstlinux-weston-stm32mp1-x86_64-toolchain-3.1.11-openstlinux-5.10-dunfell-mp1-21-11-17.html
st-image-weston-openstlinux-weston-stm32mp1-x86_64-toolchain-3.1.11-openstlinux-5.10-dunfell-mp1-21-11-17.sh
st-image-weston-openstlinux-weston-stm32mp1-x86_64-toolchain-3.1.11-openstlinux-5.10-dunfell-mp1-21-11-17.target.manifest
st-image-weston-openstlinux-weston-stm32mp1-x86_64-toolchain-3.1.11-openstlinux-5.10-dunfell-mp1-21-11-17.testdata.json

The main final output is the cross-development toolchain installation script (.sh file), which includes the environment setup script.
Note that several OpenEmbedded variables exist that help configure these files. The following list shows the variables associated with a standard SDK:

    DEPLOY_DIR: points to the deploy directory.
    SDKMACHINE: specifies the architecture of the machine on which the cross-development tools are run to create packages for the target hardware.
    SDKIMAGE_FEATURES: lists the features to include in the "target" part of the SDK.
    TOOLCHAIN_HOST_TASK: lists packages that make up the host part of the SDK (that is, the part that runs on the SDKMACHINE). This variable allows packages other than the default ones to be added.
    TOOLCHAIN_TARGET_TASK: lists packages that make up the target part of the SDK (that is, the part built for the target hardware).
    SDKPATH: Defines the default SDK installation path offered by the installation script.

3. Reference list[edit source]