Setting Up the Yocto Environment

This page collects the one-time setup needed before any EDF Yocto build: checking the host tools, configuring git, fetching the source layers with repo, sourcing the build environment, and pointing at local download and shared-state caches.

Prepare the Build Host Tools

A Yocto Project build requires minimum versions of some host tools, and several of the Linux distributions AMD supports ship default packages older than those minimums. A build on such a host fails until those tools are replaced. The supported-host table in Supported Linux Host Distributions records which hosts this applies to.

The remedy is the Yocto Project buildtools tarball, a prebuilt set of host tools that a build uses in place of the distribution’s own. Fetch the source layers first (see Using Repo to Fetch and Manage Source Layers), then install the tarball with sources/poky/scripts/install-buildtools and source the environment script the installer leaves behind. The Yocto Project documents the current minimum versions, the tarball variants, and the installation steps in Required Git, tar, Python, make and gcc Versions (Yocto Project Reference Manual, Scarthgap).

The following points matter for an EDF build:

A host whose compiler is too old needs the extended tarball. The standard one refreshes the general host tools but leaves the compiler alone, so it does nothing for a host whose only shortfall is its compiler. install-buildtools installs the extended tarball by default; pass --with-extended-buildtools to be explicit.
Source the environment script in every shell that runs a build, and source it before the EDF build environment rather than after. The EDF script wraps the Yocto Project’s own, which checks the host python3 version and refuses to initialize when it is too old. On a host that needs the tarball for its Python, the other order never gets far enough to matter.
BitBake checks the tool versions itself, the first time it runs in a build directory and again whenever the host distribution changes, and names whichever tool falls short. There is no need to audit a new machine by hand beforehand: start a build and read what it reports.

Note

A host can pass those checks and still be too old to compile an individual native tool from source, which BitBake reports as a failure in that recipe rather than as a host problem. A build that reuses a populated sstate cache does not expose it, because the native tools come from the cache and the host compiler never runs on them. The failure appears on the first build that has to compile them, and an offline build pointed at a downloads mirror with no sstate mirror is the common case. Prepare the host tools whenever the supported-host table calls for them, even when an earlier sstate-backed build on that host succeeded.

A build container is the alternative to preparing the host: the AMD-provided image ships a toolchain that already meets these requirements. See Build EDF Yocto With the EDF Build Container.

Configure Git

$ git config --global user.name "Your Name"
$ git config --global user.email "you@example.com"

Using Repo to Fetch and Manage Source Layers

EDF uses the repo tool to manage multiple Git repositories that are needed by the Yocto build. After installation, make sure the tool is in the system path and that Git is configured.

You can then use repo to initialize and sync with the AMD yocto-manifests for EDF, which define all required layers for a specific release. This downloads all source repositories needed for the build.

Example:

Download the Repo script:

$ curl https://storage.googleapis.com/git-repo-downloads/repo > repo

Make it executable:

$ chmod a+x repo

Move it onto the system path:

$ mv repo ~/bin/

Initialize the repo for the EDF release:

$ repo init -u https://github.com/Xilinx/yocto-manifests.git \
            -b refs/tags/amd-edf-rel-v26.06.1 \
            -m default-edf.xml

The -m argument selects which manifest from the yocto-manifests repository to use. default-edf.xml is the manifest for external users of the EDF flow and is the recommended starting point. For the full list of available manifests and which one to use for a given audience, see the yocto-manifests README.

Note

repo requires that the build host shell be bash (not tcsh or dash). If repo init fails with manifest '...' not available, double-check that the manifest filename above matches a file that exists in the selected revision in yocto-manifests.

Sync to get all sources:

$ repo sync

Optional:

$ repo start <branch_name> --all

Source the Build Environment

Use the scripts provided by AMD to configure the Yocto build environment. This is a wrapper around Yocto’s oe-init-build-env and sets up paths, environment variables, and the build directory. Refer to the AMD Yocto wiki for version details, features, and known issues.

Source the environment to build using bitbake:

$ source <AMD EDF-init-build>-env

Configure Your Environment

Set up local downloads and sstate directories to save compile time. See Optimizing Build Time Locally - Central Download and Shared State Locations for details.

A build machine with a working connection to the Internet needs no mirror configuration: the local.conf template already points at the AMD source and shared state mirrors. See Source Downloads and Shared State Cache for what the defaults do and how to work offline.