the idea is to use yocto as a base for a frontend operating system.

General Information

Application Development

Layer Development

Core Development

downloads and sstate-cache are available at http://yocto-cache.acc.gsi.de

rough guide to create build environment. Don't do this on an acc7 clusternode.

# create base directory
mkdir ~/yocto
cd ~/yocto

all steps assume you start in the base directory


checkout a poky version we want to use as base for our development

# clone our yocto mirror
git clone git@git.acc.gsi.de:embedded/yocto-poky.git poky
cd poky
# checkout our base version
git checkout zeus

why zeus (3.0)? This is the last version working on el7. For evaluation purposes this is new enough. Once acc moves over to el8 we can migrate to a newer poky.

base config

. ~/yocto/poky/oe-init-build-env ~/yocto/build

We are running a central yocto build server. The buildserver exposes it's downloads and buildcache via http. If the settings match, the files can be downloaded from the buildserver and not every developer needs to compile them.

Edit ~/yocto/build/conf/local.conf settings
# our machine is 64bit
MACHINE = "genericx86-64"
# the buildhost is also 64bit
SDKMACHINE = "x86_64"
# we want to use our local download cache
SOURCE_MIRROR_URL = "http://yocto-cache.acc.gsi.de/downloads"
INHERIT += "own-mirrors"
# we want to use our local build cache
SSTATE_MIRRORS = "file://.* http://yocto-cache.acc.gsi.de/sstate-cache/PATH;downloadfilename=PATH"
# our distro is ffos defined in meta-ffos
DISTRO ?= "ffos"


For each layer a seperate git repository should be used. To keep our checkout of poky and our build folder clean we create a new layers directory.

mkdir ~/yocto/layers


Add the meta-ffos layer to get a default config for fair images.

cd ~/yocto/layers
git clone git@git.acc.gsi.de:embedded/meta-ffos.git

  ${TOPDIR}/../layers/meta-ffos \

or run bitbake-layers add-layer ~/yocto/layers/meta-ffos inside ~/yocto/build

The layer proides the image ffos-image-default. This is image is suiteable for a pxe network boot. It uses systemd as an init system, initializes network interfaces using dhcp. It includes rpm, yum for packagemanagement, python and perl for scripting. Runs a net-snmpd daemon for monitoring. The unpacked image during runtime is aprox 175MB

naming conventions


  • each layer starts with meta - yocto convention
  • meta-ffos fair frontend operating system. Base recipes and configuration for fair images
  • meta-bsp-* is a baseboard support package. Containing specific drivers, kernel modules, flattened device trees, etc for a type of hardware
    • meta-bsp-scu standard control unit - propably empty
    • meta-bsp-microioc serial cards, tcp connection to motor controller, maybe utilities for the stepper motor, not the fesa classes
    • meta-bsp-microtca microtca crates
  • meta-cern cern buildsystem
  • meta-cmw all cmw recipes
  • meta-fesa fesa core and dependant libraries.
    • or should we merge cern, cmw, fesa into one layer?
  • meta-whiterabbit whiterabbit kernel modules, tools, etc=
  • meta-lobi custom unsorted recipies for lobi

leaving out groupnames from the layers, as groupnames might change.


boot image du -sh /

  • first image (busybox, openssh): 128MB
  • adding package management (dnf, also adds python): 186MB
  • replacing grub with systemd-bootd: 170MB
  • adding net-snmpd: 175MB


  • use central bitbake server? Toaster?
Topic revision: r10 - 05 Oct 2020, ChristophHandel
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback