Frequently asked questions

For an overview check this blog post: Unleashing the Power of the Yocto Project®: A Comprehensive Guide to Building Custom Linux Distributions.
For a deep dive you can book our course: The Yocto Project® — A thorough Overview.

For companies that want to train their teams on Yocto and thus ensure long-term support themselves, Robert Berger offers comprehensive training and consulting. With over 30 years of experience in embedded Linux and Yocto, teams can be equipped to sustainably operate and further develop Yocto projects.
For individual and professional advice on Yocto in industry, I recommend first contacting Robert Berger (Reliable Embedded Systems), as training and consulting are closely integrated here, and they have many years of experience.
Feel free to check out our clients and what customers are saying.

See answer above and you’ll also get a certificate after attending our courses.

We offer private and public training events on-site and online.

Nowadays most Embedded Linux vendors offer OpenEmbedded/Yocto Project compatible layers. Feel free to ask.

The Yocto Project performs most of their tests and builds with QEMU. As long as you don’t need specific hardware to test your stuff, this should be fine.
Check this blog post: The poky repository master branch is gone & qemux86-64 – whinlatter

Check this blog post: How to become part of our Yocto Project® community

I would recommend building a “stable” version of your project but in parallel also a “master” version.
In the mega manual, you can see this. It describes general migration considerations and what changed from one version to the previous.

Quilt is used internally by Bitbake and metadata to apply patches. We will not use it directly, but a workflow with this tool is described here: https://docs.yoctoproject.org/dev/dev-manual/quilt.html. I prefer to use git and stgit depending on what I am doing. Quilt could be useful to create and apply patches on top of directories which are not under version control.

According to the BitBake manual, the PERSISTENT_DIR variable specifies the directory BitBake uses to store data that should be preserved between builds. In particular, the data stored is the data that uses BitBake’s persistent data API and the data used by the PR Server and PR Service.

In short: no.
This directory should not be shared between builds. The default location of the Hash Equivalence database is this directory when BB_HASHSERVE is set to auto. If you need to share the Hash Equivalence database between builds, don’t share this directory, but instead refer to the Yocto Project Development Tasks Manual how to set up Hash Equivalence server.

The Yocto Mega Manual explains this here.
In short: IMAGE_FEATURES += "read-only-rootfs"

Any attempt by the target device to write to the root file system at runtime fails. Consequently, you must make sure that you configure processes and applications that attempt these types of write only access directories with write access (e.g., /tmp or /var/run). An overlay file system might also be a good idea, e.g., for /etc.

1) different distros — release vs. bleeding edge (nightly integration build, e.g., poky vs. poky-bleeding)
The reference Yocto implementation distinguishes between the poky distro and the poky-bleeding distro. poky.conf is the stable release, where only of fixed commid ids are used (SRCREV). poky-bleeding.conf on the other hand, includes a file called poky-floating-revisions.inc. It pulls in various repositories in “floating” versions with this variable: POKY_AUTOREV_RECIPES via AUTOREV.

2) different recipes — stable vs. development ( DEFAULT_PREFERENCE = "1" )
With a good old Yocto version (morty) we have two recipes for busybox. Namely busybox_1.24.1.bb and busybox_git.bb. busybox_git contains PV = "1.25.0+git${SRCPV}" which means, that it’s a bigger version than 1.24.1. But busybox_git also contains DEFAULT_PREFERENCE = "-1". See DEFAULT_PREFERENCE. This means: BitBake does not choose busybox_git, but busybox_1.42.1.bb instead. That’s the mechanism which can be used when you work on a bleeding edge version and don’t want other users by default to automatically use the development version of your recipe. Only with PREFERRED_VERSION_busybox = "1.25.0%" in a config file, the development version is being picked up by BitBake instead of the stable version.

3) different recipes — stable vs. latest (devupstream.bbclass)
The Mega Manual says: The devupstream class uses BBCLASSEXTEND to add a variant of the recipe that fetches from an alternative URI (e.g., Git) instead of a tarball. A fully worked out example is simple-hello-world-git-devupstream_git.bb.

Yes.

1) You need to enable buildhistory in a conf file.

INHERIT += “buildhistory”
BUILDHISTORY_COMMIT = “1”

2) in the build directory, execute buildhistory-collect-srcrevs

tree -L 1
.
├── bitbake-cookerdaemon.log
├── bitbake.lock
├── buildhistory
├── cache
├── conf
├── init-build-env
├── README
└── tmp

$ buildhistory-collect-srcrevs

this shows:

#phyboard_pollux_imx8mp_3-phytec-linux
SRCREV_machine:pn-linux-yocto-dev = “b8892e24935e21dc9257f1beabceb88aaa6f7ce8”
SRCREV_meta:pn-linux-yocto-dev = “1f7e5229027dcd871f872478f5cbc8047626cac3”
SRCREV:pn-u-boot-master = “2bc0715b558fa1ac5c88b11e250740b16a905837”

Note: buildhistory-collect-srcrevs -a shows all SRCREV and not just those with AUTOREV.

That’s not possible out of the box, since due to AUTOREV: Bitbake will need to get out to the upstream repository and pull the latest commit of the branch you defined and BB_NO_NETWORK = “1” will disallow it. But you can try something like this:

1) Buildhistory + buildhistory-collect-srcrevs
See above how to extract all the SRCREV / AUTOREV. Write them into an .inc file, which, e.g., you include in your distro configuration.

2) BB_SRCREV_POLICY
Set BB_SRCREV_POLICY = "cache" in your configuration. This will use the last cached revision. (The disadvantage of this method is that it is a little more difficult to preserve or share with others the fixed revisions.)

Note that in either case if you later want to build the latest version again, you will of course need to undo the configuration changes.

The only thing I could imagine is, that the update-alternatives class is involved. This means both binaries are installed, but only one is used via a symlink. That’s a standard Linux mechanism and you can read more about it in the man page update-alternatives(1).

1) Use buildhistory to find out what’s in the image
cd <whatever>/buildhistory/images/multi_v7_ml/glibc
grep -r ‘/bin/ls ‘ .
./core-image-sato-sdk/files-in-image.txt:lrwxrwxrwx root root 17 ./bin/ls -> /bin/ls.coreutils
./core-image-minimal/files-in-image.txt:lrwxrwxrwx root root 19 ./bin/ls -> /bin/busybox.nosuid

grep -r ‘/bin/df ‘ .
./core-image-sato-sdk/files-in-image.txt:lrwxrwxrwx root root 21 ./bin/df -> /usr/bin/df.coreutils
./core-image-minimal/files-in-image.txt:lrwxrwxrwx root root 19 ./bin/df -> /bin/busybox.nosuid

2) update-alternatives
inherit update-alternatives
ALTERNATIVE_PRIORITY = “100”
ALTERNATIVE:${PN} = “…df”
ALTERNATIVE:${PN}-doc = “…df.1”
…
ALTERNATIVE_LINK_NAME[df] = “${base_bindir}/df”
ALTERNATIVE_TARGET[df] = “${bindir}/df.${BPN}”
ALTERNATIVE_LINK_NAME[df.1] = “${mandir}/man1/df.1”
…

A fully worked example is here.

You could write a class for that. Maybe something like this or you could extend the insane class.

You make a new kernel recipe.

1) Kernel vs. gcc
With differnet poky versions you typically also get different gcc versions. Patches might be necessary to get an old kernel compile with a new gcc and vice versa.

2) Code which comes with kernel sources
Perf is a tool which comes with kernel sources and you might also want to update it’s recipe accordingly as well as other recipes which break due to kernel source dependencies.

3) Supported kernel versions
bitbake -e | grep ^OLDEST_KERNEL=
OLDEST_KERNEL=”5.15″

The kernel-devicetree class, which is inherited by the kernel class, supports device tree generation of device tree source files which are part of the kernel tree. It is used to build “stable” device trees together with the kernel.
If you only want to build the device tree without building the kernel in order to get a new device tree you should use the devicetree class. The devicetree class allows to build a recipe that compiles device tree source files that are not in the kernel tree.

Start here.

Memory overcommit is the decision to allocate more memory than physically available, and swap is the technology that makes this decision possible without immediate system failure, albeit at a performance cost. See Overcommit Accounting.

One might use memory overcommit without swap primarily to prioritize system responsiveness under heavy memory pressure and to prevent performance degradation caused by slow disk I/O when swapping occurs. This configuration changes the behavior when the system runs out of physical RAM: instead of slowing down due to swapping, the system will immediately invoke the Out-Of-Memory (OOM) killer to terminate a process. Also, to avoid “Thrashing” and Performance Penalties. For predictable Behavior in Memory Exhaustion Scenarios (OOM killer instead of slow, grinding system). As an optimization for specific workloads like sparse arrays. For better application stability by disabling swap and setting specific memory limits, which causes immediate memory allocation failure (ENOMEM) and handle the error gracefully (e.g., stopping the current transaction) rather than being abruptly killed by the OOM killer.

Assuming U-Boot boots, you can do this on the U-Boot prompt:

32 it ARM:

=> bdinfo
boot_params = 0x10000100
DRAM bank = 0x00000000
-> start = 0x10000000
-> size = 0x40000000
flashstart = 0x00000000
flashsize = 0x00000000
flashoffset = 0x00000000
baudrate = 115200 bps
relocaddr = 0x4ff5c000
reloc off = 0x3875c000
Build = 32-bit
current eth = ethernet@2188000
ethaddr = 50:2d:f4:09:cf:54
IP addr = 192.168.42.126
fdt_blob = 0x4f750980
lmb_dump_all:
memory.count = 0x1
memory[0] [0x10000000-0x4fffffff], 0x40000000 bytes, flags: none
reserved.count = 0x2
reserved[0] [0x4e74d000-0x4e74ffff], 0x3000 bytes, flags: no-notify, no-overwrite
reserved[1] [0x4e750960-0x4fffffff], 0x18af6a0 bytes, flags: no-overwrite
devicetree = separate
arch_number = 0x00000000
TLB addr = 0x4fff0000
irq_sp = 0x4f750970
sp start = 0x4f750960
Early malloc usage: 650 / 2000

64 Bit ARM:

u-boot=> bdinfo
boot_params = 0x0000000000000000
DRAM bank = 0x0000000000000000
-> start = 0x0000000040000000
-> size = 0x000000003e000000
DRAM bank = 0x0000000000000001
-> start = 0x0000000080000000
-> size = 0x0000000040000000
flashstart = 0x0000000000000000
flashsize = 0x0000000000000000
flashoffset = 0x0000000000000000
baudrate = 115200 bps
relocaddr = 0x000000007decf000
reloc off = 0x000000003dccf000
Build = 64-bit
current eth = ethernet@30be0000
ethaddr = 50:2d:f4:3a:4e:18
IP addr =
fdt_blob = 0x000000007bebbc20
lmb_dump_all:
memory.count = 0x2
memory[0] [0x40000000-0x7dffffff], 0x3e000000 bytes, flags: none
memory[1] [0x80000000-0xbfffffff], 0x40000000 bytes, flags: none
reserved.count = 0x3
reserved[0] [0x7aeb2000-0x7aebafff], 0x9000 bytes, flags: no-notify, no-overwrite
reserved[1] [0x7aebbc10-0x7dffffff], 0x31443f0 bytes, flags: no-overwrite
reserved[2] [0x80000000-0xbfffffff], 0x40000000 bytes, flags: no-overwrite
devicetree = separate
arch_number = 0x0000000000000000
TLB addr = 0x000000007dfe0000
irq_sp = 0x000000007bebbc10
sp start = 0x000000007bebbc10
Early malloc usage: d8d0 / 10000

In the above, search for relocaddr and reloc off. You need to adjust your symbols in gdb accordingly.