Follow the yocto documentation to setup poky. I'm using kirkstone branch. Some details might vary depending on the branch. Always refer to the branch documentation.
MACHINE and DISTRO
==================
when you create a build, conf/local.conf specifies distro and the machine
dld@dld:~/yocto$ source poky/oe-init-build-env build-qemu
in this build, we have
MACHINE ??= "qemux86-64"
DISTRO ?= "poky"
distro comes from meta-poky/conf/distro/poky.conf
dld@dld:~/yocto/poky$ ls meta-poky/conf/distro/ -F
include/ poky-altcfg.conf poky-bleeding.conf poky.conf poky-tiny.conf
machine comes from meta/conf/machine/qemux86-64.conf
dld@dld:~/yocto/poky$ ls meta/conf/machine -F
include/ qemuarm64.conf qemuarm.conf qemuarmv5.conf qemumips64.conf qemumips.conf qemuppc64.conf qemuppc.conf qemuriscv32.conf qemuriscv64.conf qemux86-64.conf qemux86.conf
What is a BSP layer
===================
- MACHINE comes from a BSP layer
- at a minimum, a BSP layer should have a machine configuration (see documentation/bsp-guide/bsp.rst for details)
- meta has machine configs in its conf/, so it's a BSP layer
- meta-poky isn't a BSP layer, it only has distro (check on your side or see its listed contents in the previous post)
- our build directory's conf/bblayers.conf has the following
# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
POKY_BBLAYERS_CONF_VERSION = "2"
BBPATH = "${TOPDIR}"
BBFILES ?= ""
BBLAYERS ?= " \
/home/dld/yocto/poky/meta \
/home/dld/yocto/poky/meta-poky \
/home/dld/yocto/poky/meta-yocto-bsp \
"
Why is the meta-yocto-bsp there?
- it's a BSP layer
- if you check the conf/local.conf, you'll see that we can use the following for the MACHINE
# There are also the following hardware board target machines included for
# demonstration purposes:
#
#MACHINE ?= "beaglebone-yocto"
#MACHINE ?= "genericx86"
#MACHINE ?= "genericx86-64"
#MACHINE ?= "edgerouter"
#
- these machines come from meta-yocto-bsp
dld@dld:~/yocto/poky$ tree meta-yocto-bsp/conf/
meta-yocto-bsp/conf/
├── layer.conf
└── machine
├── beaglebone-yocto.conf
├── edgerouter.conf
├── genericx86-64.conf
├── genericx86.conf
└── include
└── genericx86-common.inc
- so, if you build for one of these machines, you need the meta-yocto-bsp BSP layer
- when you are building for qemux86-64, you don't really need it
- so try removing that layer, and the build should work just fine
dld@dld:~/yocto/build-qemu$ bitbake-layers remove-layer /home/dld/yocto/poky/meta-yocto-bsp
dld@dld:~/yocto/build-qemu$ bitbake-layers show-layers
NOTE: Starting bitbake server...
layer path priority
==========================================================================
meta /home/dld/yocto/poky/meta 5
meta-poky /home/dld/yocto/poky/meta-poky 5
dld@dld:~/yocto/build-qemu$ bitbake core-image-minimal
bootloader and kernel specification
===================================
Where u-boot comes from
-----------------------
meta/recipes-bsp/u-boot
- this is the only u-boot specification in poky which is in meta BSP layer
- in meta/recipes-bsp/u-boot/u-boot.inc
PROVIDES = "virtual/bootloader"
- for example, if we build for beaglebone, we have in meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"
- see how PROVIDES and PREFERRED_PROVIDER work in documentation/ref-manual/variables.rst
Where linux kernel comes from
-----------------------------
- from the machine configuration file in the BSP layer, the machine we are building for
- for example, if we build for qemux86-64, which is the default, machine config will specify it (may get from an *.inc)
PREFERRED_PROVIDER_virtual/kernel ??= "linux-yocto"
- version comes from meta-poky/conf/distro/poky.conf for qemux86-64
PREFERRED_VERSION_linux-yocto ?= "5.15%"
- for beaglebone, we'll get them from the machine configuration beaglebone-yocto.conf
PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
PREFERRED_VERSION_linux-yocto ?= "5.15%"
- Q: where's the PROVIDES that specifies virtual/kernel?
- A: it's in the kernel.bbclass, and the kernel recipes inherit kernel.bbclass
- experiment commenting out the version and see what happens by querying the variables using bitbake -e (BitBake’s -e option is used to display variable values after parsing)
- lets check the linux version that'll be used
- for beaglebone
dld@dld:~/yocto/build-bb$ bitbake -e core-image-minimal | grep PREFERRED_VERSION_linux-yocto
# $PREFERRED_VERSION_linux-yocto
PREFERRED_VERSION_linux-yocto="5.15%"
# $PREFERRED_VERSION_linux-yocto-rt
PREFERRED_VERSION_linux-yocto-rt="5.15%"
- if you check the full bitbake -e (redirect to a file and search), you'll see from where it's set
for qemux86-64
#
# $PREFERRED_VERSION_linux-yocto
# set? /home/dld/yocto/poky/meta-poky/conf/distro/poky.conf:23
# "5.15%"
PREFERRED_VERSION_linux-yocto="5.15%"
#
for beaglebone
#
# $PREFERRED_VERSION_linux-yocto [2 operations]
# set? /home/dld/yocto/poky/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf:27
# "5.15%"
# set? /home/dld/yocto/poky/meta-poky/conf/distro/poky.conf:23
# "5.15%"
# pre-expansion value:
# "5.15%"
PREFERRED_VERSION_linux-yocto="5.15%"
#
- so, qemux86-64 will use
meta/recipes-kernel/linux/linux-yocto_5.15.bb
- beaglebone will use
meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.15.bbappend
- beaglebone is having the following in linux-yocto_5.15.bbappend
KBRANCH:beaglebone-yocto = "v5.15/standard/beaglebone"
KMACHINE:beaglebone-yocto ?= "beaglebone"
SRCREV_machine:beaglebone-yocto ?= "9aabbaa89fcb21af7028e814c1f5b61171314d5a"
COMPATIBLE_MACHINE:beaglebone-yocto = "beaglebone-yocto"
LINUX_VERSION:beaglebone-yocto = "5.15.54"