Skip to main content

Frequently Asked Questions

I want to add package XYZ - how do I do this?​

Add the package to IMAGE_INSTALL_append as described in the Additional Packages section. You can run bitbake -s to get a list of all available recipes.

Which packages are included in my build?​

Use the command below to get a list of packages that are included. In this example we are also running the output through sort to get a sorted list of packages.

oe-pkgdata-util list-pkgs | sort > included_packages.txt

Which recipe generated a specific package?​

If you want to know which recipe generated a specific package you can use the command below. Replace <package> with the package you want to look for. It is quite common that the recipe name is the same as the package name.

oe-pkgdata-util lookup-recipe <package>

Which recipe generated a specific file on the file system?​

If you have found a file on the file system that you would like to modify you can run the command below to find which recipe create / installed that file. In this example we look for the recipe that created /etc/asound.conf.

oe-pkgdata-util find-path /etc/asound.conf
alsa-state: /etc/asound.conf

Here we can see that the recipe is called alsa-state. You can now search in the sources directory for this recipe.

find . -name *alsa-state*.bb
./poky/meta/recipes-bsp/alsa-state/alsa-state.bb

If you would like to modify this file you could then create a bbappend file an put that in your own layer as described in the Add content or change behavior section.

How do I add my own files to the file system?​

If you want to install your own files to the file system you could either add your own recipe that installs the files (see section 9.2 for a description of how to add a recipe) or you can use the Embedded Artists recipe called ea-files.

Below you can see an example where we use ea-files to add two files to the file system. The first part (EA_FILES_DIRS) lists the directories where the files need to be installed. The second part installs the file crank_8mm_mn.tar.gz to /home/root and crank_8mm_mn.sh to /etc/profile.d.

These files will be given the permissions 644 (read for all, write only for user)

EA_FILES_DIRS = "\
/home/root \
/etc/profile.d \
"

EA_FILES_644 = "\
crank_8mm_mn.tar.gz:/home/root/crank_8mm_mn.tar.gz \
crank_8mm_mn.sh:/etc/profile.d/crank_8mm_mn.sh \
"

See the ea-files.bb file for more information.

https://github.com/embeddedartists/meta-ea/blob/ea-4.14.98/recipes-ea/ea-files/ea-files.bb#L32

How do I install my own application to the file system?​

You can either follow the instructions in the How do I add my own files section if you have an already compiled application or you can follow the instructions in the Create a recipe section if you want to create your own recipe that compiles and installs the application.

Where are the repositories?​

Below you can see an overview of how repositories are organized. It all begins with the manifest located in the ea-yocto-base repository.

Repository structure

meta-ea​

The Download Yocto recipes section describes how to download the repositories included in the Yocto build. In that section you can see that a tool called repo is used together with a link to a repository called ea-yocto-base. This repository contains a manifest (default.xml) that tells repo which repositories to download, where they are located, and exactly which revision to use. Follow the link below to see how the manifest looks like for the ea-4.14.98 distribution.

https://github.com/embeddedartists/ea-yocto-base/blob/ea-4.14.98/default.xml

Below is an excerpt from the manifest file. Here you can see that the Embedded Artists repositories are located on GitGub and you can also see which revision of the layer meta-ea that will be downloaded.

...
<remote fetch="git://github.com/embeddedartists" name="EA"/>
...
<project remote="EA" name="meta-ea" path="sources/meta-ea" revision="841430dceea43fc3a82683f2a520e4c6cb9775ae">
<copyfile src="ea-setup-release.sh" dest="ea-setup-release.sh"/>
</project>
...

Linux kernel​

The Linux kernel repository is not specified in the manifest file. Instead, the layer meta-ea specifies which kernel to use. Below is a direct link to the recipe that specifies which Linux kernel to use for 4.14.98 distribution.

https://github.com/embeddedartists/meta-ea/blob/841430dceea43fc3a82683f2a520e4c6cb9775ae/recipes-kernel/linux/linux-ea_4.14.98.bb

An excerpt from the recipe shows the location of the repository (SRC_URI), the branch to use (SRCBRANCH) and also the exact revision to use ((SRCREV().

...
SRC_URI = "git://github.com/embeddedartists/linuximx.git;protocol=git;branch=${SRCBRANCH}"
...
LOCALVERSION = "-2.2.0"
SRCBRANCH = "ea_4.14.98"
SRCREV = "b095f5fb8a8de39e77f578dcd351783fdcdf1984"

U-Boot bootloader​

The U-Boot repository is not specified in the manifest file. Instead, the layer meta-ea specifies which U-Boot bootloader to use. Below is a direct link to the recipe for the U-Boot used in the 4.14.98 distribution.

https://github.com/embeddedartists/meta-ea/blob/841430dceea43fc3a82683f2a520e4c6cb9775ae/recipes-bsp/u-boot/u-boot-ea_2018.03.bb

The location and revision of the U-Boot are specified in a separate file called u-boot-ea-common_2018.03.inc.

https://github.com/embeddedartists/meta-ea/blob/841430dceea43fc3a82683f2a520e4c6cb9775ae/recipes-bsp/u-boot/u-boot-ea-common_2018.03.inc

An excerpt from u-boot-ea-common_2018.03.inc shows the location of the repository (SRC_URI), the branch to use (SRCBRANCH) and also the exact revision to use (SRCREV).

...
SRCBRANCH = "ea_v2018.03"
SRC_URI = "git://github.com/embeddedartists/uboot-imx.git;branch=${SRCBRANCH} \
"
SRCREV = "f70b292988ec7bcee7f4b412e62cdd9cd05e6dba"
...

How do I use my own Linux kernel?​

It is quite likely that you need to modify the Linux kernel that we provide. This could for example be to add a new device driver or change the default kernel configuration. What is the recommended way to include these changes in a Yocto build? The answer depends on which step of the development you are at.

In the early stages you would typically clone our repository, apply your changes and then test these by using either devtool as described in the Use devtool to build Linux / U-Boot section or compile it outside of Yocto as described in the Build Linux kernel from source section.

The recommendation is however that you in the end should use your own repository. The easiest way is to fork our repository on GitHub and then apply your changes to this new repository. You can still use the instructions in sections Build Linux kernel from source and Use devtool to build Linux / U-Boot to build your version of the Linux kernel. How to handle this in your final product see our recommendations in the Should I use my own repo manifest and Yocto layer section.

How do I use my own U-Boot?​

The recommendations are the same for the U-Boot as for the Linux kernel so see the How do I use my own Linux kernel section.

Should I use my own repo manifest and Yocto layer?​

Our recommendation is that you take control over the software you include in your product. This also includes the Linux distribution you provide. To take this control you should setup your own repo manifest (you could base it on ea-yocto-base) and also your own Yocto layer (you could base it on meta-ea). In the Yocto layer you should then use your repositories of Linux kernel and U-Boot bootloader.

How can I reduce the build time?​

See the State and download cache in Yocto section for a description of how you can use state and / or download caches to reduce the build time.

Where is the package manager?​

Many users have been using Debian / Ubuntu based distributions where they are used to installing new software using APT (apt-get) and want to know if there is something similar on Embedded Artists Yocto images. The short answer is; No there isn’t any package manager.

The main reason is that although it is quite convenient to use a package manager during the development cycle it is not that common to use it in a final product. Adding, removing or modifying software on a final product must be handled in a controlled way making sure not to break any functionality. Instead, many products have over-the-air (OTA) / remote update functions that allows it to be updated in a controlled way by the manufacturer.

It is possible to enable package manager(s) in Yocto, but this is out-of-scope for this document. See the link below for some more information.

https://docs.yoctoproject.org/dev-manual/common-tasks.html#using-runtime-package-management

Which version of Yocto am I using?​

Run the command below in the directory containing the Yocto sources

grep -E "DISTRO_VERSION|DISTRO_CODENAME" sources/poky/meta-poky/conf/distro/poky.conf