Building Yocto BSP from Source

Yocto can also generate standalone SDKs (Software Development Kits) that can be installed on development machines for application development outside of the Yocto build environment. The SDK includes:

Building and using SDKs is beyond the scope of this documentation. For detailed information on generating and using Yocto SDKs, see the official Yocto Project documentation: https://docs.yoctoproject.org/sdk-manual/

Before building, you must initialize the build environment. Navigate to your Yocto build directory (the parent directory containing openembedded-core and meta-* layers):

This will create a build directory and configure your shell environment.

The Yocto BSP provides several image targets:

To build the main standalone image (default machine is lan969x):

To build for a specific machine:

You can also set the machine in build/conf/local.conf to avoid specifying it each time:

To build only the Linux kernel:

To build only U-Boot:

To clean and rebuild a specific recipe:

To force a rebuild after making changes to a recipe:

The build output is located in build/tmp/deploy/images/ followed by the machine name. This directory contains:

To add a new package to the Yocto BSP, you can either:

For creating new recipes, follow the Yocto Project documentation: https://docs.yoctoproject.org/dev-manual/new-recipe.html

To add a package to an image, edit the image recipe in meta-mchp-ncs/recipes-mchp/images/:

For machine-specific additions:

The kernel uses KCONFIG_MODE = "alldefconfig" with machine-specific defconfigs.

To modify the kernel configuration:

Alternatively, you can create a configuration fragment file and add it to the kernel recipe’s SRC_URI:

Device tree source files are built as part of the kernel. To modify device trees:

To add or remove device trees from the build, modify the KERNEL_DEVICETREE variable in the machine configuration file:

Some recipes like symreg.bb build machine-specific variants from the same source using EXTRA_OECMAKE flags:

The recipe builds machine-specific binaries and creates a symlink: symreg -> symreg_${MACHINE}.

To add a new machine to the Yocto BSP:

The dr script requires a configuration file, .docker.env, which must be present somewhere between the current directory and the root of the file system.

The .docker.env file must add user and uid in the environment to allow the container to run commands as a regular user (not root). Docker containers execute as root by default, but Yocto recommends running all commands as a regular user.

Create a .docker.env file with the following content:

You will need to install Docker to use the dr script: https://docs.docker.com/engine/install/

Using the dr script enables automatic download of the Docker image from a container repository.

Alternative syntax using quotes is recommended to avoid shell interpretation issues:

To build an image using Docker:

To build for a specific machine (e.g., LAN966x):

Example for Sparx5:

For manual commands and development work, you can start an interactive shell:

Inside the container:

Note that you are the same user inside the container as outside, and the current folder is the same inside and outside the container.

Type exit to leave the Docker container.

The default configuration maps volumes to enable access to the current directory. If you need to mount other folders in the container (such as local source repositories), add them to the MCHP_DOCKER_OPTIONS variable in .docker.env:

Now you can access the /path/to/sources folder both inside and outside the container.

After modifying a recipe, rebuild it with:

BitBake recipes consist of tasks that can be run individually:

Common tasks include: * fetch - Download sources * unpack - Extract source archives * patch - Apply patches * configure - Run configuration scripts * compile - Build the software * install - Install to staging directory * deploy - Deploy to the deploy directory

To skip task execution (like do_kernel_configcheck):

Place this after inherit statements to override inherited tasks.

Three U-Boot versions for different platforms:

For ARM64 platforms (lan966x, lan969x, sparx5), the tfa recipe downloads pre-built FIP (Firmware Image Package) from GitHub and patches U-Boot as BL33 payload.

The BSP includes various switch management tools: