This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[FAQ] AM6x/AM335x/AM437x: Using a Yocto-internal toolchain for target image builds and cross-development SDK installer generation with Yocto Dunfell-based v8.x SDKs for Sitara MPUs

Part Number: AM335x, AM437x, AM62x, AM62Ax, AM64x, AM65x

Overview

This E2E FAQ shows an alternative approach of how to use an Yocto-internal toolchain for image builds as well as for the associated SDK installer generation that contains the cross-toolchain and the image-specific target sysroot (libraries, header files, etc.) for development of applications that run on Sitara AM6x, AM335x, and AM437x target systems. The steps were tested and developed using the Yocto Dunfell-based AM62x SDK v8.5, and should similarly apply to other Sitara MPUs (AM62A, AM64, AM65, AM335x, AM437x) as well as other Yocto Dunfell-based SDK v8.x variants.

Using a Yocto-internal toolchain will also enable building the SDK installer containing the cross-toolchain and target-specific sysroot using the Yocto standard way of doing a bitbake -c populate_sdk <image-name> rather than using the TI SDK v8.x-specific way of using a dedicated build target of bitbake meta-toolchain-arago-tisdk. Also creating the SDK installer through bitbake -c populate_sdk <image-name> has the added advantage of the toolchain installer getting extended automatically to comprehend additional packages that may have gotten added to the target image, whereas such (dev) packages would need to get added manually through the use of the TOOLCHAIN_TARGET_TASK variable (and also kept in sync manually with the target image) when building using the standard TI SDK v8.x bitbake meta-toolchain-arago-tisdk approach.

ExclamationDisclaimer: The official and recommended way building with Yocto in the context of Yocto Dunfell-based Sitara v8.x SDKs is using an external cross-compilation toolchain provided by ARM as per SDK documentation, which is made available to the Yocto builds through the use of the TOOLCHAIN_PATH_ARMV8 / TOOLCHAIN_PATH_ARMV7 environmental variables. This is the way the SDK references images are build and regression tested. The alternative steps of switching to using a Yocto-internal toolchain here are provided as-is due to popular demand, and may or may not meet all requirements for a production solution. If an internal toolchain-based solution is required for production purposes it is recommended to wait for the release of the upcoming Yocto Kirkstone-based SDK v9.x series arriving sometime around late 2Q2023.

ExclamationNote: Upcoming Yocto Kirkstone-based Sitara SDKs v9.x will use a Yocto-internal toolchain by default, and this E2E FAQ is no longer applicable/needed.

Steps to using the Yocto-internal Toolchain

Configure the TOOLCHAIN_TYPE variable to internal. This can either be done in conf/local.conf by simply appending this to the end of the file:

# Use internal toolchain, the common Yocto way
TOOLCHAIN_TYPE = "internal"

or by making an update in the Yocto distribution layer that is used (meta-arago/meta-arago-distro/conf/distro/arago.conf in case of the default TI SDK).

Then, several patches need to be applied to the meta-arago, meta-arm, and meta-ti layers to fix a couple of issues the toolchain change exposes. The patches are listed below and are provided in a tarball. To apply the patches, extract the tarball into the Yocto sources/ folder after SDK setup, and apply the patches one by one using git am to the respective Yocto layers based on their file location as shown below.

~/tisdk/am62xx-evm/sources
$ tar -xvf tisdk-yocto-dunfell-internal-toolchain-2-mar-2023.tar.gz
meta-arago/0001-meta-toolchain-arago-fix-internal-toolchain-installe.patch
meta-arago/0002-tisdk-default-image-Add-Qt5-to-generated-SDK-when-us.patch
meta-arm/0001-optee-os_git.bb-Update-LIBGCC_LOCATE_CFLAGS-sysroot-.patch
meta-arm/0002-optee-os-Add-missing-sysroot-compiler-flag.patch
meta-ti/0001-optee-os-Fix-SRC_URI-to-allow-inherited-patch-to-get.patch

~/tisdk/am62xx-evm/sources
$ git -C meta-arago am 0001-meta-toolchain-arago-fix-internal-toolchain-installe.patch
$ git -C meta-arago am 0002-tisdk-default-image-Add-Qt5-to-generated-SDK-when-us.patch
$ git -C meta-arm am 0001-optee-os_git.bb-Update-LIBGCC_LOCATE_CFLAGS-sysroot-.patch
$ git -C meta-arm am 0002-optee-os-Add-missing-sysroot-compiler-flag.patch
$ git -C meta-ti am 0001-optee-os-Fix-SRC_URI-to-allow-inherited-patch-to-get.patch

Building using the Yocto-internal Toolchain

With the setup steps performed as outlined above, you can now build any of the standard images such as the tisdk-default-image without needing to set the TOOLCHAIN_PATH_ARMV8 / TOOLCHAIN_PATH_ARMV7 environmental variables pointing to pre-installed binary toolchain. Instead Yocto will build all toolchains it needs to create the embedded image target by downloading various GCC compiler sources and other host tool sources and building those toolchains completely from scratch. Note that this takes extra time during the initial build, but subsequent builds should not incur such a penalty assuming Yocto's shared state cache is setup properly.

# Build the AM62x Default Target System Image (same as SDK instructions, except no
# TOOLCHAIN* environmental variable setup needed)
$ MACHINE=am62xx-evm bitbake -k tisdk-default-image

# Build the cross-development SDK installer tailored for the given target image
# After the build, the installer can be found at arago-tmp-default-glibc/deploy/sdk/
$ MACHINE=am62xx-evm bitbake tisdk-default-image -c populate_sdk

tisdk-yocto-dunfell-internal-toolchain-2-mar-2023.tar.gz