Table 2.BitBake options BitBake parameter -c fetch -c cleanall
-c deploy -k -c compile -f
-g -DDD -s, –show-versions

Description
Fetches if the downloads state is not marked as done.
Cleans the entire component build directory. All the changes in the build directory are lost. The rootfs and state of the component are also cleared. The component is also removed from the download directory.
Deploys an image or component to the rootfs.
Continues building components even if a build break occurs.
It is not recommended that the source code under the temporary directory is changed directly, but if it is, the Yocto Project might not rebuild it unless this option is used. Use this option to force a recompile after the image is deployed.
Lists a dependency tree for an image or component.
Turns on debug 3 levels deep. Each D adds another level of debug.
Shows the current and preferred versions of all recipes.

5.5 U-Boot configuration
U-Boot configurations are defined in the main machine configuration file. The configuration is specified by using the UBOOT_CONFIG settings. This requires setting UBOOT_CONFIG in local.conf. Otherwise, the U-Boot build uses SD boot by default.
These can be built separately by using the following commands (change MACHINE to the correct target). Multiple U-Boot configurations can be built with one command by putting spaces between U-Boot configurations.
The following are the U-Boot configurations for each boards. i.MX 6 and i.MX 7 boards support SD without OPTEE and with OP-TEE:
· uboot_config_imx93evk=”sd fspi” · uboot_config_imx8mpevk=”sd fspi ecc” · uboot_config_imx8mnevk=”sd fspi” · uboot_config_imx8mmevk=”sd fspi” · uboot_config_imx8mqevk=”sd” · uboot_config_imx8dxlevk=”sd fspi” · uboot_conifg_imx8dxmek=”sd fspi” · uboot_config_imx8qxpc0mek=”sd fspi” · uboot_config_imx8qxpmek=”sd fspi” · uboot_config_imx8qmmek=”sd fspi” · uboot_config_imx8ulpevk=”sd fspi”

IMXLXYOCTOUG
User guide

All information provided in this document is subject to legal disclaimers.
Rev. LF6.6.3_1.0.0 — 29 March 2024

© 2024 NXP B.V. All rights reserved.
10 / 27

NXP Semiconductors

IMXLXYOCTOUG
i.MX Yocto Project User’s Guide

· uboot_config_imx8ulp-9×9-lpddr4-evk=”sd fspi” · uboot_config_imx6qsabresd=”sd sata sd-optee” · uboot_config_imx6qsabreauto=”sd sata eimnor spinor nand sd-optee” · uboot_config_imx6dlsabresd=”sd epdc sd- optee” · uboot_config_imx6dlsabreauto=”sd eimnor spinor nand sd-optee” · uboot_config_imx6solosabresd=”sd sd-optee” · uboot_config_imx6solosabreauto=”sd eimnor spinor nand sd-optee” · uboot_config_imx6sxsabresd=”sd emmc qspi2 m4fastup sd-optee” · uboot_config_imx6sxsabreauto=”sd qspi1 nand sd-optee” · uboot_config_imx6qpsabreauto=”sd sata eimnor spinor nand sd-optee” · uboot_config_imx6qpsabresd=”sd sata sd-optee” · uboot_config_imx6sllevk=”sd epdc sd-optee” · uboot_config_imx6ulevk=”sd emmc qspi1 sd-optee” · uboot_config_imx6ul9x9evk=”sd qspi1 sd-optee” · uboot_config_imx6ull14x14evk=”sd emmc qspi1 nand sd-optee” · uboot_config_imx6ull9x9evk=”sd qspi1 sd-optee” · uboot_config_imx6ulz14x14evk=”sd emmc qspi1 nand sd-optee” · uboot_config_imx7dsabresd=”sd epdc qspi1 nand sd-optee” · uboot_config_imx7ulpevk=”sd emmc sd-optee”
To build with any U-Boot configuration, perform the following steps.
With just one U-Boot configuration:
$ echo “UBOOT_CONFIG = “eimnor”” >> conf/local.conf
With multiple U-Boot configurations:
$ echo “UBOOT_CONFIG = “sd eimnor”” >> conf/local.conf
$ MACHINE= bitbake -c deploy u-boot-imx
Note: i.MX 8 uses imx-boot that pulls in U-Boot.
5.6 Build scenarios
The following are build setup scenarios for various configurations.
Set up the manifest and populate the Yocto Project layer sources with these commands:
$ mkdir imx-yocto-bsp $ cd imx-yocto-bsp $ repo init -u https://github.com /nxp-imx/imx-manifest -b imx-linux-nanbield -m imx-6.6.3-1.0.0.xml $ repo sync
The following sections give some specific examples. Replace the machine names and the backends specified to customize the commands.

IMXLXYOCTOUG
User guide

All information provided in this document is subject to legal disclaimers.
Rev. LF6.6.3_1.0.0 — 29 March 2024

© 2024 NXP B.V. All rights reserved.
11 / 27

NXP Semiconductors

IMXLXYOCTOUG
i.MX Yocto Project User’s Guide

5.6.1 Frame Buffer image on i.MX 6QuadPlus SABRE-AI
$ DISTRO=fsl-imx-fb MACHINE=imx6qpsabreauto source imx-setup-release.sh ­b build-fb
$ bitbake imx-image-multimedia
This builds a multimedia image with a frame buffer backend.
5.6.2 XWayland image on i.MX 8QuadXPlus MEK
$ DISTRO=fsl-imx-xwayland MACHINE=imx8qxpmek source imx-setup-release.sh -b build-xwayland
$ bitbake imx-image-full
This builds an XWayland image with Qt 6 and machine learning features. To build without Qt 6 and machine learning, use imx-image-multimedia instead.
5.6.3 Wayland image on i.MX 8M Quad EVK
$ DISTRO=fsl-imx-wayland MACHINE=imx8mqevk source imx-setup-release.sh -b buildwayland $ bitbake imx-image-multimedia
This builds a Weston Wayland image with multimedia without Qt 6.
5.6.4 Restarting a build environment If a new terminal window is opened or the machine is rebooted after a build directory is set up, the setup environment script should be used to set up the environment variables and run a build again. The full imxsetup-release.sh is not needed.
$ source setup-environment

5.6.5 Chromium Browser on XWayland, and Wayland
The Yocto Project community has Chromium recipes for the Wayland version Chromium Browser for i.MX SoC with GPU hardware. NXP does not support or test the patches from the community. This section describes how to integrate Chromium into your rootfs and enable hardware accelerated rendering of WebGL. The Chromium browser requires additional layers such as meta-browser added in the imx-release-setup.sh script automatically.
In local.conf for XWayland or Wayland, add Chromium into your image. X11 is not supported.
CORE_IMAGE_EXTRA_INSTALL += “chromium-ozone-wayland”

5.6.6 Qt 6 and QtWebEngine browsers

Qt 6 has both a commercial and an open source license. When building in Yocto Project, the open source license is the default. Make sure to understand the differences between these licenses and choose appropriately. After custom Qt 6 development has started on the open source license, it cannot be used with the commercial license. Work with a legal representative to understand the differences between these licenses.
Note:

IMXLXYOCTOUG
User guide

All information provided in this document is subject to legal disclaimers.
Rev. LF6.6.3_1.0.0 — 29 March 2024

© 2024 NXP B.V. All rights reserved.
12 / 27

NXP Semiconductors

IMXLXYOCTOUG
i.MX Yocto Project User’s Guide

Building QtWebEngine is not compatible with the meta-chromium layer used by the release. If you are using the NXP build setup, remove meta-chromium from bblayers.conf:

Commented out due to incompatibility with qtwebengine #BBLAYERS +=

“${BSPDIR}/sources/meta-browser/meta-chromium”
There are four Qt 6 browsers available. QtWebEngine browsers can be found in: · /usr/share/qt6/examples/webenginewidgets/StyleSheetbrowser · /usr/share/qt6/examples/webenginewidgets/Simplebrowser · /usr/share/qt6/examples/webenginewidgets/Cookiebrowser · /usr/share/qt6/examples/webengine/quicknanobrowser All three browsers can be run by going to the directory above and running the executable found there. Touchscreen can be enabled by adding the parameters -plugin evdevtouch:/dev/input/event0 to the executable.
./quicknanobrowser -plugin evdevtouch:/dev/input/event0
QtWebengine only works on SoC with GPU graphics hardware on i.MX 6, i.MX 7, i.MX 8, and i.MX 9. To include Qtwebengine in the image, put the following in local.conf or in the image recipe.
IMAGE_INSTALL:append = ” packagegroup-qt6-webengine”

5.6.7 NXP eIQ machine learning The meta-ml layer is the integration of NXP eIQ machine learning, which was formerly released as a separate meta-imx- machinelearning layer and is now integrated into the standard BSP image (imx- image-full). Many of the features require Qt 6. In case of using other configuration than imx-image-full, put the following in local.conf:
IMAGE_INSTALL:append = ” packagegroup-imx-ml”
To install the NXP eIQ packages to the SDK, put the following in local.conf:
TOOLCHAIN_TARGET_TASK:append = ” tensorflow-lite-dev onnxruntime-dev”
Note: TOOLCHAIN_TARGET_TASK_append variable installs the packages to the SDK only, not to the image. To add the model configurations and input data for the OpenCV DNN demos, put the following in local.conf:
PACKAGECONFIG:append:pn-opencv_mx8 = ” tests tests-imx”

5.6.8 Systemd
Systemd is enabled as the default initialization manager. To disable systemd as default, go to the fsl-imxpreferred-env.inc and comment out the systemd section.

IMXLXYOCTOUG
User guide

All information provided in this document is subject to legal disclaimers.
Rev. LF6.6.3_1.0.0 — 29 March 2024

© 2024 NXP B.V. All rights reserved.
13 / 27

NXP Semiconductors

IMXLXYOCTOUG
i.MX Yocto Project User’s Guide

5.6.9 Multilib enablement
For i.MX 8, building 32-bit applications on 64-bit OS can be supported using the multilib configuration. Multilib offers the ability to build libraries with different target optimizations or architecture formats and combine these together into one system image. Multilib is enabled by adding the MULTILIB, DEFAULTTUNE, and IMAGE_INSTALL declaration to your local.conf file. Multilib is not supported with the debian package management. It requires the RPM system. Comment out the two package management lines in local.conf to go to the default RPM.
The MULTILIBS declaration is typically lib32 or lib64 and needs to be defined in MULTILIB_GLOBAL_VARIANTS variable as follows:
MULTILIBS = “multilib:lib32”
DEFAULTTUNE must be one of the AVAILTUNES values for this alternative library type as follows:
DEFAULTTUNE:virtclass-multilib-lib32 = “armv7athf-neon”
IMAGE_INSTALL will be added to the image, the 32-bit libraries required by the specific application as follows:
IMAGE_INSTALL:append = ” lib32-bash”
For the case on i.MX 8, building a 32-bit application support would require the following statements in local.conf. This configuration specifies a 64-bit machine as the main machine type and adds multilib:lib32, where those libraries are compiled with the armv7athf-neon tune, and then includes to all images the lib32 packages.
MACHINE = imx8mqevk # Define multilib target require conf/multilib.conf MULTILIBS = “multilib:lib32” DEFAULTTUNE:virtclass-multilib-lib32 = “armv7athf-neon” # Add the multilib packages to the image IMAGE_INSTALL:append = ” lib32-glibc lib32-libgcc lib32-libstdc++”
Disable the deb packaging to avoid any processing errors. Check in local.conf, and comment if there are:
PACKAGE_CLASSES = “package_deb” EXTRA_IMAGE_FEATURES += “package-management”

5.6.10 OP-TEE enablement
OP-TEE requires three components: OP-TEE OS, OP-TEE client, and OP-TEE test. In addition, the kernel and U-Boot have configurations. The OP-TEE OS resides in the bootloader while the OP-TEE client and test reside in the rootfs.
OP-TEE is enabled by default in this release. To disable OP-TEE, go to the meta-imx/meta-bsp/conf/ layer.conf file and comment out the DISTRO_FEATURES_append for OP-TEE and uncomment the removed line.
5.6.11 Building Jailhouse
Jailhouse is a static partitioning Hypervisor based on Linux OS. It is supported on i.MX 8M Plus, i.MX 8M Nano, i.MX 8M Quad EVK, and i.MX 8M Mini EVK boards.

IMXLXYOCTOUG
User guide

All information provided in this document is subject to legal disclaimers.
Rev. LF6.6.3_1.0.0 — 29 March 2024

© 2024 NXP B.V. All rights reserved.
14 / 27

NXP Semiconductors

IMXLXYOCTOUG
i.MX Yocto Project User’s Guide

To enable Jailhouse build, add the following line to local.conf:
DISTRO_FEATURES:append = ” jailhouse”
In U-Boot, run run jh_netboot or jh_mmcboot. It loads the dedicated DTB for Jailhouse usage. Taking i.MX 8M Quad as an example, after Linux OS boots up:

insmod jailhouse.ko #./jailhouse enable imx8mq.cell

For more details about Jailhouse on i.MX 8, see the i.MX Linux User’s Guide (IMXLUG).
5.6.12 Package management
The default package management with Yocto Project is rpm. The i.MX distro now enables debian as the package management. This can be easily turned off by adding the PACKAGE_CLASSES set to package_rpm in the local.conf, or creating a custom distro without the debian package feed PACKAGE_CLASSES = “package_deb” . With the addition of the debian package feed, a sources.list can be added to /etc/apt that links in Debian’s package feed. This allows users to install packages not provided in the image without having to add them to a Yocto image. Because this package feed is not generated by the i.MX Yocto build process, there is no guarantee each package will work with the right dependencies but it allows simpler tools to be provided. Software that is complex and has more dependencies on specific versions might have issues with an external package feed.
6 Image Deployment
Complete filesystem images are deployed to <build directory>/tmp/deploy/images. An image is, for the most part, specific to the machine set in the environment setup. Each image build creates a U-Boot, a kernel, and an image type based on the IMAGE_FSTYPES defined in the machine configuration file. Most machine configurations provide an SD card image (.wic) and a rootfs image (.tar). The SD card image contains a partitioned image (with U-Boot, kernel, rootfs, etc.) suitable for booting the corresponding hardware.
6.1 Flashing an SD card image
An SD card image file .wic contains a partitioned image (with U-Boot, kernel, rootfs, etc.) suitable for booting the corresponding hardware. To flash an SD card image, run the following command:
zstdcat .wic.zst | sudo dd of=/dev/sd bs=1M conv=fsync
For more information on flashing, see Section “Preparing an SD/MMC card to boot” in the i.MX Linux User’s Guide (IMXLUG). For NXP eIQ machine learning applications, an additional free disk space is required (approximately 1 GB). It is defined by adding IMAGE_ROOTFS_EXTRA_SPACE variable into the local.conf file before the Yocto building process. See the Yocto Project Mega-Manual.
7 Customization
There are three scenarios to build and customize on i.MX Linux OS: · Building i.MX Yocto Project BSP and validating on an i.MX reference board. The directions in this document
describe this method in details.

IMXLXYOCTOUG
User guide

All information provided in this document is subject to legal disclaimers.
Rev. LF6.6.3_1.0.0 — 29 March 2024

© 2024 NXP B.V. All rights reserved.
15 / 27

NXP Semiconductors

IMXLXYOCTOUG
i.MX Yocto Project User’s Guide

· Customizing kernel and creating a custom board and device tree with kernel and U-Boot. For more details on how to build an SDK and set up a host machine for building the kernel and U-Boot only outside of the Yocto Project build environment, see Chapter “How to Build U-Boot and Kernel in Standalone Environment” in the i.MX User’s Guide (IMXLUG).
· Customizing a distribution adding or removing packaging from the BSP provided for i.MX Linux releases by creating a custom Yocto Project layer. i.MX provides multiple demo examples to show a custom layer on top of an i.MX BSP release . The remaining sections in this document provides instructions for creating a custom DISTRO and board configuration.
7.1 Creating a custom distro
A custom distro can configure a custom build environment. The distro files released fsl-imx-wayland, fslimx-xwayland, and fsl-imx-fb all show configurations for specific graphical backends. Distros can also be used to configure other parameters such as kernel, U-Boot, and GStreamer. The i.MX distro files are set to create a custom build environment required for testing our i.MX Linux OS BSP releases.
It is recommended for each customer to create their own distro file and use that for setting providers, versions, and custom configurations for their build environment. A distro is created by copying an existing distro file, or including one like poky.conf and adding additional changes, or including one of the i.MX distros and using that as a starting point.
7.2 Creating a custom board configuration
Vendors who are developing reference boards may want to add their board to the FSL Community BSP. Having the new machine supported by the FSL Community BSP makes it easy to share source code with the community, and allows for feedback from the community.
The Yocto Project makes it easy to create and share a BSP for a new i.MX based board. The upstreaming process should start when a Linux OS kernel and a bootloader are working and tested for that machine. It is highly important to have a stable Linux kernel and bootloader (for example, U-Boot) to be pointed to in the machine configuration file, to be the default one used for that machine.
Another important step is to determinate a maintainer for the new machine. The maintainer is the one responsible for keeping the set of main packages working for that board. The machine maintainer should keep the kernel and bootloader updated, and the user-space packages tested for that machine.
The steps needed are listed below.
1. Customize the kernel config files as needed. The kernel configuration file is location in arch/arm/ configs and the vendor kernel recipe should customize a version loaded through the kernel recipe.
2. Customize U-Boot as needed. See the i.MX BSP Porting Guide (IMXBSPPG) for details on this. 3. Assign the maintainer of the board. This maintainer makes sure that files are updated as needed, so the
build always works. 4. Set up the Yocto Project build as described in the Yocto Project community instructions as shown below.
Use the community master branch. a. Download the needed host package, depending on your host Linux OS distribution, from Yocto Project
Quick Start. b. Download Repo with the command:
$ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
c. Create a directory to keep everything in. Any directory name can be used. This document uses imxcommunity-bsp.
$ mkdir imx-community-bsp

IMXLXYOCTOUG
User guide

All information provided in this document is subject to legal disclaimers.
Rev. LF6.6.3_1.0.0 — 29 March 2024

© 2024 NXP B.V. All rights reserved.
16 / 27

NXP Semiconductors

IMXLXYOCTOUG
i.MX Yocto Project User’s Guide

d. Execute the following command: $ cd imx-community-bsp
e. Initialize the Repo with the master branch of the Repo. $ repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b master
f. Get the recipes that will be used to build. $ repo sync
g. Set up the environment with the following command: $ source setup- environment build
5. Choose a similar machine file in fsl-community-bsp/sources/meta-freescale- 3rdparty/conf/ machine and copy it, using a name indicative of your board. Edit the new board file with the information about your board. Change the name and description at least. Add MACHINE_FEATURE.
6. Test your changes with the latest community master branch, making sure everything works well. Use at least core-image-minimal. $ bitbake core-image- minimal
7. Prepare the patches. Follow the Recipe Style Guide and git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/ tree/README in the section entitled Contributing.
8. Upstream into meta-freescale-3rdparty. To upstream, send the patches to metafreescale@yoctoproject.org.
7.3 Monitoring security vulnerabilities in your BSP
The monitoring of Common Vulnerability and Exposures (CVE) can be accomplished with NXP enabled Vigiles tools from Timesys. Vigiles is a vulnerability monitoring and management tool that provides build-time Yocto CVE analysis of target images. It does this by collecting metadata about the software used in the Yocto Project BSP and comparing it against a CVE database that integrates information on CVEs from various sources, including NIST, Ubuntu, and several others. A high-level overview of the detected vulnerabilities is returned, and a full detailed analysis with information on affecting CVEs, their severity and available fixes can be viewed online. To access the report online, register for your NXP Vigiles account by following the link: https://www.timesys.com/register-nxp-vigiles/ Additional information on the setup and execution of Vigiles can be found here: https://github.com/TimesysGit/meta-timesys https://www.nxp.com/vigiles
7.3.1 Configuration
Add meta-timesys to conf/bblayers.conf of your BSP build. Follow the format of the file and add meta-timesys:
BBLAYERS += “${BSPDIR}/sources/meta-timesys”

IMXLXYOCTOUG
User guide

All information provided in this document is subject to legal disclaimers.
Rev. LF6.6.3_1.0.0 — 29 March 2024

© 2024 NXP B.V. All rights reserved.
17 / 27

NXP Semiconductors

IMXLXYOCTOUG
i.MX Yocto Project User’s Guide

Append vigiles to INHERIT variable in conf/local.conf: INHERIT += “vigiles”

7.3.2 Execution
Once meta-timesys has been added to your build, Vigiles executes a security vulnerabilities scan every time the Linux BSP is built with Yocto. There are no additional commands needed. After each build is completed, the vulnerability scan information is stored in the directory imx-yocto-bsp/<build dir>/vigiles. You can view the details of the security scan through: · Command line (summary) · Online (details) Simply open the file named <image name>-report.txt, which includes the link to the detailed online report.
8 Frequently Asked Questions
8.1 Quick Start
This section summarizes how to set up the Yocto Project on a Linux machine and build an image. Detailed explanations of what this means are in the sections above. Installing the “repo” utility To get the BSP you need to have “repo” installed. This only needs to be done once.
$: mkdir ~/bin $: curl https://storage.googleapis.com/git-repo-downloads/repo

~/bin/repo $: chmod a+x ~/bin/repo $: PATH=${PATH}:~/bin
Downloading the BSP Yocto Project Environment. Use the correct name for the release desired in the -b option for repo init. This needs to be done once for each release and sets the distribution for the directory created in the first step. repo sync can be run to update the recipes under sources to the latest.
$: mkdir imx-yocto-bsp $: cd imx-yocto-bsp $: repo init -u https://github.com /nxp-imx/imx-manifest -b imx-linux-nanbield m imx-6.6.3-1.0.0.xml : repo sync
Note: https://github.com/nxp-imx/imx-manifest/tree/imx-linux-nanbield has a list of all manifest files supported in this release. Setup for Specific Backends i.MX 8 and i.MX 9 Framebuffer is not supported. Only use these for i.MX 6 and i.MX 7 SoC.

IMXLXYOCTOUG
User guide

All information provided in this document is subject to legal disclaimers.
Rev. LF6.6.3_1.0.0 — 29 March 2024

© 2024 NXP B.V. All rights reserved.
18 / 27

NXP Semiconductors

IMXLXYOCTOUG
i.MX Yocto Project User’s Guide

Setup for Framebuffer:
$: DISTRO=fsl-imx-fb MACHINE= source imx-setup-release.sh -b build-fb
Setup for Wayland:
$: DISTRO=fsl-imx-wayland MACHINE= source imx-setup-release.sh -b build-wayland
Setup for XWayland:
$: DISTRO=fsl-imx-xwayland MACHINE= source imx-setup-release.sh -b build-xwayland
Build for All Backends Build without Qt
$: bitbake imx-image-multimedia
Build with Qt 6 and machine learning features
$: bitbake imx-image-full

8.2 Local configuration tuning
A Yocto Project build can take considerable build resources both in time and disk usage, especially when building in multiple build directories. There are methods to optimize this, for example, use a shared sstate cache (caches the state of the build) and downloads directory (holds the downloaded packages). These can be set to be at any location in the local.conf file by adding statements such as these:
DL_DIR=”/opt/imx/yocto/imx/download” SSTATE_DIR=”/opt/imx/yocto/imx/sstate- cache”
The directories need to already exist and have appropriate permissions. The shared sstate helps when multiple build directories are set, each of which uses a shared cache to minimize the build time. A shared download directory minimizes the fetch time. Without these settings, Yocto Project defaults to the build directory for the sstate cache and downloads.
Every package downloaded in the DL_DIR directory is marked with a <package name>.done. If your network has a problem fetching a package, you can manually copy the backup version of package to the DL_DIR directory and create a