How to Install and Configure Yocto-Embedded Linux Training In Hyderabad

PREV_LEC NEXT_LEC
Install and Configure Yocto
Clone Poky, understand the build directory, and configure your first QEMU build — free embedded systems course
3 Files
in conf/
1 Command
to set up the shell
~40 GB
Typical build disk usage
free linux kernel development course free linux device drivers course free embedded systems course free linux development course install Yocto Project
Now that you know what BitBake, oe-core and Poky each do, it’s time to actually install Yocto Project and configure a build. This lecture walks through cloning Poky, understanding the generated build directory, and setting up a QEMU ARM target — all using the current long-term-support release, so the exact commands below work today, unlike a lot of older tutorials still floating around online.

What You Will Learn

Cloning Poky on the correct LTS branch What oe-init-build-env actually does local.conf, bblayers.conf and templateconf.cfg explained Configuring the MACHINE for a QEMU ARM build Running your first bitbake build and booting it

Prerequisites

A 64-bit Linux host (Ubuntu 22.04 or newer is well tested), roughly 50-100 GB of free disk space, git, and the Yocto host build-essential package set. If you followed our earlier Buildroot lectures in this free embedded systems course, your host machine is very likely already ready to go.

Step 1: Install Host Packages

Every Yocto release documents an exact list of required host packages in its reference manual, and it does change slightly between releases, so always check the manual for the branch you are building. On a Debian/Ubuntu host, a typical starting set looks like this:

$ sudo apt update
$ sudo apt install -y gawk wget git diffstat unzip texinfo gcc build-essential 
    chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils 
    iputils-ping python3-git python3-jinja2 libegl1-mesa liberror-perl 
    python3-subunit zstd liblz4-tool file locales
$ sudo locale-gen en_US.UTF-8

Step 2: Clone Poky on the Current LTS Branch

Rather than cloning the default branch, always clone the codename of the release you want. At the time of writing, the current LTS release is 6.0 “Wrynose”, with 5.0 “Scarthgap” still under support as the previous LTS. Pick whichever your product’s support window calls for:

$ git clone -b wrynose git://git.yoctoproject.org/poky.git
$ cd poky

You will find everything — oe-core, BitBake, and the reference Poky configuration — inside this single poky directory.

Step 3: Set Up the Build Environment

Every new terminal session needs the environment script sourced before any bitbake command will work:

$ source oe-init-build-env

This creates and switches into a working directory named build, and drops you into it as your current directory. You can also name the directory explicitly, which is useful for keeping several targets side by side:

$ source oe-init-build-env build-ep-qemuarm64
What oe-init-build-env Sets Up
build-ep-qemuarm64/
  conf/local.conf    – machine, distro, download/cache paths
  conf/bblayers.conf – list of active meta-layers
  conf/templateconf.cfg – where the default conf templates came from
  tmp/                – generated after the first build, safe to delete

Step 4: Configure the Target Machine

Open conf/local.conf in your build directory and set the MACHINE variable to a QEMU target. For a 64-bit ARM target:

$ sed -i 's/^MACHINE ??= "qemux86-64"/MACHINE ??= "qemuarm64"/' conf/local.conf
$ grep '^MACHINE' conf/local.conf
MACHINE ??= "qemuarm64"

It’s also worth pointing the shared caches outside your build directory the first time, so every future build directory you create reuses already-built artifacts instead of rebuilding from scratch:

DL_DIR ?= "/home/ravi/yocto-shared/downloads"
SSTATE_DIR ?= "/home/ravi/yocto-shared/sstate-cache"

Step 5: Build and Boot an Image

With the machine configured, build a minimal image. Expect the very first build to take anywhere from thirty minutes to a few hours depending on your hardware and network, since it compiles the entire toolchain and root filesystem from source:

$ bitbake core-image-minimal

Typical tail of a successful build looks like this:

NOTE: Tasks Summary: Attempted 3842 tasks of which 0 didn't need to be rerun
      and all succeeded.
Summary: There was 1 WARNING message.

Boot the resulting image straight in QEMU:

$ runqemu qemuarm64 nographic
Poky (Yocto Project Reference Distro) 6.0 ep-qemuarm64 ttyAMA0
ep-qemuarm64 login: root

Common Mistakes

Cloning the default branch instead of a named release

Cloning without -b <codename> gives you an unstable development branch, not a supported release — always pin the branch explicitly.

Opening a new terminal and forgetting to re-source

bitbake: command not found almost always means oe-init-build-env was not sourced in that particular shell session.

Running out of disk space mid-build

A full build of even a minimal image easily needs 40-50 GB; check available space before starting a long build rather than after it fails hours in.

Best Practices

Pin the exact Poky branch and layer revisions per project Point DL_DIR and SSTATE_DIR outside the build directory Keep one build directory per MACHINE/DISTRO combination Never hand-edit files under tmp/ — treat it as disposable

Summary and Key Takeaways

Installing Yocto Project is really just cloning Poky on the correct release branch and sourcing oe-init-build-env to generate a build directory. The three configuration files inside conf/ — local.conf, bblayers.conf and templateconf.cfg — control almost everything about what gets built and how. Once MACHINE is set, a single bitbake command turns those recipes into a bootable image you can run instantly under QEMU, no real hardware required.

Frequently Asked Questions

Do I need to source oe-init-build-env every time?

Yes, in every new terminal session before running any bitbake command; it sets required environment variables and switches you into the build directory.

How much disk space does a Yocto build actually need?

Plan for 40-100 GB depending on the image and how many layers you add; the shared download and sstate caches also grow over time across multiple projects.

Can I build for real hardware instead of QEMU?

Yes — set MACHINE to the value defined by your board’s BSP meta-layer instead of a qemu target, after adding that layer to bblayers.conf.

Why does the first build take so long?

The first build compiles an entire cross-toolchain and root filesystem from source; later builds reuse the sstate cache and are dramatically faster.

What’s the difference between local.conf and bblayers.conf?

local.conf configures the machine, distro and build behavior; bblayers.conf lists which meta-layers are active for this particular build directory.

Is it safe to delete the tmp directory?

Yes, tmp/ is fully regenerated by BitBake on the next build; nothing you hand-authored should ever live there.

Continue This Free Linux Kernel Development Course

Next up: adding your own meta-layer and writing a custom recipe.


PREV_LEC NEXT_LEC 

2 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *