Tüm eğitimler
TEKNİK REHBER GÖMÜLÜ LİNUX YOCTO 2026

Yocto Project
BitBake & Layer Sistemi

embedded Linux dağıtımını sıfırdan inşa et — recipe, layer, image ve SDK üretimi.

00 Yocto nedir ve neden

Yocto Project, OpenEmbedded altyapısı üzerine BitBake görev yöneticisini birleştiren, distro bağımsız bir embedded Linux framework'üdür.

OpenEmbedded + BitBake kombinasyonu

Yocto Project tek bir araç değil, bir ekosistemdir. OpenEmbedded metadata'yı (recipe, class, layer) tanımlar; BitBake bu metadata'yı okuyarak görev grafını oluşturur ve paralel çalıştırır. Poky ise Yocto'nun referans dağıtımıdır — hem meta-layer'ları hem BitBake'i paketler.

OpenEmbedded metadata (recipe, class, conf) → BitBake task engine → cross-toolchain + rootfs + kernel + image

Buildroot ile karşılaştırma

ÖzellikYocto ProjectBuildroot
Öğrenme eğrisiDik — BitBake DSL, layer kavramıDüz — Makefile tabanlı, sade
İlk build süresi1–2 saat (sstate-cache yoksa)20–40 dakika
Incremental buildGüçlü sstate-cache mekanizmasıSınırlı, genelde tam build
Paket sayısı5000+ recipe2000+ paket
Çoklu board desteğiBSP layer sistemiyle mükemmeldefconfig bazlı, daha az esnek
SDK üretimiYerleşik, güçlümake sdk — temel düzeyde
Ticari destekWind River, Mentor, TimesysSınırlı
Ne zaman tercih etBüyük ekip, çok board, commercialKüçük proje, sıkı boyut kısıtı

Neden custom embedded distro gerekir

Ubuntu/Debian gibi hazır dağıtımların embedded donanıma doğrudan kurulması birçok soruna yol açar:

BoyutUbuntu minimal bile 1–2 GB — birçok embedded cihazda 128–512 MB flash bulunur
GüvenlikGereksiz servis ve paket saldırı yüzeyini artırır; custom distro sadece gerekli bileşenleri içerir
Determinizmapt upgrade beklenmedik değişikliklere yol açar; Yocto build tam reproducible olabilir
Lisans uyumuYocto her paketin lisansını otomatik takip eder, rapor üretir
Cross-compileHer şey hedef mimariye cross-compile edilir — QEMU emülasyonu gerekmez

Release isimleri ve LTS

SürümKod adıDurumYayın
4.0KirkstoneLTS (Nisan 2024'e kadar)Nisan 2022
4.1LangdaleStableEkim 2022
4.2MickledoreStableMayıs 2023
5.0ScarthgapLTSNisan 2024
5.1StyheadStableEkim 2024
NOT

Üretim projelerinde LTS (Long Term Support) sürümlerini tercih edin: Kirkstone ve Scarthgap. LTS sürümleri güvenlik yamaları için en az iki yıl desteklenir.

Host gereksinimleri

bash
# Ubuntu 22.04 üzerinde gerekli paketler
sudo apt-get 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 libsdl1.2-dev pylint xterm \
  python3-subunit mesa-common-dev zstd liblz4-tool

# Minimum sistem gereksinimleri
# OS:  Ubuntu 20.04 / 22.04 veya Debian 11+ (önerilir)
# RAM: 8 GB minimum, 16 GB önerilir
# Disk: 50 GB minimum, 100 GB önerilir (sstate-cache büyür)
# CPU: mümkün olduğunca çok çekirdek (BB_NUMBER_THREADS ile kullanılır)

Bu bölümde

  • Yocto = OpenEmbedded metadata + BitBake task engine + Poky referans dağıtımı
  • Buildroot daha sade ve hızlı; Yocto daha esnek, çok board, incremental build
  • Custom distro: boyut, güvenlik, determinizm, lisans uyumu için zorunlu
  • Üretimde LTS sürümlerini kullanın: Kirkstone (4.0), Scarthgap (5.0)

01 Poky ve ilk build

Poky, Yocto'nun referans dağıtımıdır — meta, meta-poky, meta-yocto-bsp layer'larını ve BitBake'i tek repo'da paketler.

Poky yapısı

Dizin / Dosyaİçerik
bitbake/BitBake task runner kaynak kodu
meta/OpenEmbedded-Core: temel recipe'ler, class'lar
meta-poky/Poky distro konfigürasyonu
meta-yocto-bsp/Referans BSP: BeagleBone, EdgeRouter, QEMU
oe-init-build-envBuild ortamını initialize eden script
scripts/bitbake-layers, recipetool, runqemu vb. araçlar

Poky klonlama ve ortam hazırlama

bash
# Kirkstone (LTS) branch'ini klonla
git clone https://git.yoctoproject.org/poky -b kirkstone
cd poky

# Build ortamını initialize et
# Bu komut: build/ dizini oluşturur, PATH'i ayarlar, conf/ dosyalarını kopyalar
source oe-init-build-env build/

# Konum şimdi: poky/build/
# Oluşturulan dosyalar:
#   conf/local.conf     — makine, distro, thread ayarları
#   conf/bblayers.conf  — aktif layer listesi

İlk build: core-image-minimal

bash
# İlk build — sstate-cache yoksa 1-2 saat sürer
bitbake core-image-minimal

# Build çıktıları
ls tmp/deploy/images/qemux86-64/
# bzImage                           — Linux kernel
# core-image-minimal-qemux86-64.ext4 — rootfs
# core-image-minimal-qemux86-64.wic  — tam disk image

# QEMU ile test — ayrı terminal açmaya gerek yok
runqemu qemux86-64

# Nographic (headless) QEMU
runqemu qemux86-64 nographic

# Belirli bir kernel + rootfs dosyasını belirt
runqemu qemux86-64 tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.ext4
DİKKAT

İlk build'de tmp/ dizini 20–40 GB yer kaplayabilir. DL_DIR ve SSTATE_DIRlocal.conf'ta /data/yocto/ gibi büyük bir diske yönlendirin. Varsayılanda her ikisi de build/ içinde oluşur.

Build süreci adımları

source oe-init-build-env → local.conf düzenle → bitbake core-image-minimal → tmp/deploy/images/ → runqemu

Bu bölümde

  • Poky = meta + meta-poky + meta-yocto-bsp + bitbake tek repo'da
  • source oe-init-build-env build/ her yeni terminal açışında çalıştırılmalı
  • İlk build sstate-cache yoksa 1–2 saat; ikinci build dakikalar içinde
  • runqemu qemux86-64 ile gerçek donanım olmadan test

02 BitBake temelleri

BitBake, Python ve shell tabanlı bir görev yürütücüsüdür — recipe metadata'sını okur, bağımlılık grafını oluşturur ve görevleri paralel çalıştırır.

Task graph

do_fetch → do_unpack → do_patch → do_configure → do_compile → do_install → do_package → do_packagedata → do_rootfs → do_image

Her görev bağımsız olarak cache'lenebilir. sstate-cache mekanizması bir görevin hash'i değişmemişse tekrar çalıştırmaz — bu Yocto'nun incremental build gücünün temelidir.

Temel BitBake komutları

bash
# Tek recipe build et
bitbake busybox

# Belirli task'ı çalıştır
bitbake -c fetch busybox          # sadece do_fetch
bitbake -c compile busybox        # sadece do_compile
bitbake -c clean busybox          # recipe çalışma dizinini temizle
bitbake -c cleanall busybox       # sstate + dl_dir dahil temizle

# devshell: recipe ortamında interaktif bash aç
# cross-toolchain PATH'te, tüm değişkenler ayarlı
bitbake -c devshell busybox

# Değişken değerini sorgula
bitbake -e busybox | grep ^SRC_URI
bitbake -e busybox | grep ^S=    # kaynak dizin
bitbake -e busybox | grep ^WORKDIR=

Layer yönetimi komutları

bash
# Aktif layer'ları listele
bitbake-layers show-layers

# Hangi recipe hangi layer'dan geliyor
bitbake-layers show-recipes busybox
bitbake-layers show-recipes '*image*'  # wildcard kullanım

# Tüm appends'leri listele
bitbake-layers show-appends

# Layer bağımlılıklarını kontrol et
bitbake-layers show-cross-depends

Bağımlılık grafiği oluşturma

bash
# Dot formatında bağımlılık grafiği üret
bitbake -g core-image-minimal
# Oluşan dosyalar: task-depends.dot, recipe-depends.dot, pn-buildlist

# Grafiği görselleştir (graphviz gerekir)
dot -Tsvg task-depends.dot -o deps.svg
dot -Tpng recipe-depends.dot -o recipe-deps.png

# Sadece belirli recipe'nin bağımlılıkları
bitbake -g -u taskexp core-image-minimal  # GUI task explorer
NOT

bitbake -c devshell recipe içinde derleme sorunu ayıklarken en güçlü araçtır. Shell açıldığında $CC, $LD, $CFLAGS cross-compile için ayarlıdır; oe_runmake komutu do_compile'ı taklit eder.

Bu bölümde

  • BitBake task graph: do_fetch → do_unpack → ... → do_image, her adım cache'lenir
  • bitbake -c devshell <recipe>: cross-toolchain ortamında interaktif debug
  • bitbake -e <recipe> | grep ^VAR: gerçek değişken değerini sorgula
  • bitbake -g: DOT formatında bağımlılık grafiği üret

03 Recipe (.bb) dosyası anatomisi

Recipe (.bb) dosyası bir yazılımın nasıl fetch, patch, compile ve install edileceğini tanımlayan BitBake metadata'sıdır.

Temel değişkenler

DESCRIPTIONPaketin kısa açıklaması
HOMEPAGEProjenin web adresi
LICENSESPDX lisans tanımlayıcısı: "MIT", "GPL-2.0-only", "Apache-2.0"
LIC_FILES_CHKSUMLisans dosyasının checksum'ı — değişirse build kesilir
SRC_URIKaynak kod URL'i veya yerel dosya yolu
SKaynak kodun extract edildiği dizin (${WORKDIR}/${BPN}-${PV} varsayılan)
DEPENDSBuild-time bağımlılıklar (native veya target paket)
RDEPENDS:${PN}Runtime bağımlılıklar — cihazda kurulu olması gerekenler

SRC_URI türleri

myapp_1.0.bb
# HTTP/HTTPS tarball
SRC_URI = "https://example.com/myapp-${PV}.tar.gz"
SRC_URI[sha256sum] = "a3f4b2c1d..."

# Git repository (tag ile)
SRC_URI = "git://github.com/user/myapp.git;protocol=https;branch=main"
SRCREV = "a1b2c3d4e5f6..."  # tam commit hash veya tag
S = "${WORKDIR}/git"       # git clone için S değiştirilmeli

# Yerel dosya (recipe ile aynı dizin)
SRC_URI += "file://fix-makefile.patch"
SRC_URI += "file://myapp.service"  # systemd servis dosyası

# Birden fazla kaynak
SRC_URI = "https://example.com/myapp-${PV}.tar.gz \
           file://0001-fix-compile.patch \
           file://myapp.conf"

DEPENDS vs RDEPENDS

myapp_1.0.bb — bağımlılıklar
# Build-time: cross-compile sırasında host'ta veya sysroot'ta gerekli
DEPENDS = "openssl zlib libxml2"

# Runtime: cihazda çalışırken gerekli (rootfs'e dahil edilir)
RDEPENDS:${PN} = "bash libssl3 libz1"

# DEPENDS: paket adı (recipe adı, PN)
# RDEPENDS: runtime paket adı (genelde lib + sürüm)

Basit C programı için tam recipe

hello-embedded_1.0.bb
DESCRIPTION = "Gömülü Linux için hello world uygulaması"
HOMEPAGE    = "https://github.com/example/hello-embedded"
LICENSE     = "MIT"
LIC_FILES_CHKSUM = "file://LICENSE;md5=abc123..."

SRC_URI = "https://github.com/example/hello-embedded/archive/v${PV}.tar.gz"
SRC_URI[sha256sum] = "d3f1a2b4c5e6..."

# Autotools tabanlı proje için — configure + make + make install
inherit autotools

# CMake tabanlı proje için
# inherit cmake

# Ek configure argümanları
EXTRA_OECONF = "--disable-docs --enable-debug"

# Özel install adımı (autotools yeterli olmadığında)
do_install:append() {
    install -d ${D}${sysconfdir}/hello-embedded
    install -m 0644 ${WORKDIR}/myapp.conf ${D}${sysconfdir}/hello-embedded/
}

# Dosyaları hangi alt pakete dahil et
FILES:${PN} += "${sysconfdir}/hello-embedded"

Inherit class'ları

inherit autotoolsconfigure/make/make install otomatik — do_configure, do_compile, do_install tanımlar
inherit cmakecmake/ninja build sistemi için — EXTRA_OECMAKE ile argüman geç
inherit python3nativeBuild sırasında Python 3 gerektiren paketler için
inherit systemdsystemd servis dosyası yönetimi — SYSTEMD_SERVICE tanımla
inherit pkgconfigpkg-config tabanlı bağımlılıkları otomatik çöz

Bu bölümde

  • Recipe: DESCRIPTION, LICENSE, SRC_URI, S, DEPENDS, RDEPENDS temel değişkenler
  • SRC_URI: http://, git://, file:// — her birinin farklı checksum/SRCREV gereksinimi var
  • inherit autotools veya inherit cmake ile do_compile/do_install otomatik oluşur
  • DEPENDS = build-time, RDEPENDS = runtime bağımlılık (karıştırılmamalı)

04 Layer sistemi

Layer, belirli bir amaç etrafında organize edilmiş metadata koleksiyonudur — BSP, distro veya uygulama recipe'leri içerebilir.

Layer dizin yapısı

Dosya / DizinAmaç
meta-mylayer/Layer kök dizini — meta- öneki gelenek
meta-mylayer/conf/layer.confLayer konfigürasyonu — zorunlu
meta-mylayer/recipes-*/Recipe'ler — kategori dizinleri
meta-mylayer/classes/Özel .bbclass dosyaları
meta-mylayer/files/Layer genelinde kullanılan dosyalar
meta-mylayer/READMEBağımlılıklar, LAYERVERSION, nasıl kullanılır

conf/layer.conf anatomisi

meta-mylayer/conf/layer.conf
# Layer dizinini BitBake arama yoluna ekle
BBPATH .= ":${LAYERDIR}"

# Recipe dosyalarını bul
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
             ${LAYERDIR}/recipes-*/*/*.bbappend"

# Layer koleksiyon adı (benzersiz olmalı)
BBFILE_COLLECTIONS += "mylayer"
BBFILE_PATTERN_mylayer = "^${LAYERDIR}/"

# Layer önceliği — yüksek sayı daha öncelikli
BBFILE_PRIORITY_mylayer = "6"

# Bu layer'ın versiyonu
LAYERVERSION_mylayer = "1"

# Bağımlı layer'lar (uyumluluk kontrolü)
LAYERDEPENDS_mylayer = "core"

# Desteklenen Yocto sürümleri
LAYERSERIES_COMPAT_mylayer = "kirkstone langdale"

Layer ekleme ve yönetim

bash
# Layer'ı build'e ekle (bblayers.conf günceller)
bitbake-layers add-layer ../meta-mylayer

# Aktif layer'ları ve önceliklerini göster
bitbake-layers show-layers

# Hangi recipe hangi layer'dan geliyor (çakışma tespiti)
bitbake-layers show-recipes '*' | grep openssl

# Tüm .bbappend dosyalarını göster
bitbake-layers show-appends

# bblayers.conf manuel düzenleme (add-layer yerine)
cat conf/bblayers.conf

Layer türleri

BSP layermeta-raspberrypi, meta-ti, meta-freescale — donanıma özel kernel, bootloader, device tree
Distro layermeta-poky, meta-openembedded/meta-oe — dağıtım politikası, varsayılan paketler
Software layermeta-openembedded/meta-python, meta-networking — uygulama recipe'leri
Custom layermeta-myproject — projeye özel recipe'ler ve konfigürasyon

.bbappend ile override

meta-mylayer/recipes-core/busybox/busybox_%.bbappend
# % işareti her versiyona eşleşir
# busybox_1.35.0.bb için de, busybox_1.36.0.bb için de çalışır

# Ek kaynak dosyaları ekle
FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
SRC_URI += "file://my-busybox.cfg"

# Ek install adımı ekle
do_install:append() {
    install -m 0755 ${WORKDIR}/custom-script ${D}${sbindir}/
}

# Değişkeni override et
EXTRA_OECONF:append = " --enable-feature-xyz"
DİKKAT

BBFILE_PRIORITY değeri yüksek olan layer aynı recipe'yi sağlarsa düşük öncelikli layer'ın recipe'si gizlenir. bitbake-layers show-recipes ile hangi layer'ın kazandığını kontrol edin. Genellikle BSP layer = 6, distro layer = 5, meta-oe = 6, özel proje layer = 7–9 verilir.

Bu bölümde

  • Layer = meta-<name>/ + conf/layer.conf — BBPATH, BBFILES, BBFILE_PRIORITY
  • bitbake-layers add-layer bblayers.conf'u günceller
  • .bbappend (% wildcard ile): upstream recipe'yi fork etmeden genişlet
  • BBFILE_PRIORITY çakışmayı çözer — yüksek sayı kazanır

05 local.conf ve build konfigürasyonu

local.conf, build davranışını kontrol eden ana konfigürasyon dosyasıdır — makine, distro, thread sayısı, cache dizinleri burada belirlenir.

Temel makine ve distro ayarları

conf/local.conf
# Hedef donanım — MACHINE adı BSP layer'dan gelir
MACHINE ?= "qemux86-64"
# Diğer örnekler: "raspberrypi4", "raspberrypi4-64", "beaglebone", "qemuarm64"

# Distro konfigürasyonu
DISTRO ?= "poky"
# poky-tiny: çok küçük image için, init sistemi yok

# Paralel build — CPU çekirdeği sayısına göre ayarla
BB_NUMBER_THREADS ?= "8"    # BitBake eşzamanlı recipe sayısı
PARALLEL_MAKE ?= "-j8"      # make -j değeri (PARALLEL_MAKE)

# Paket formatı: package_rpm, package_deb, package_ipk
PACKAGE_CLASSES ?= "package_rpm"

Cache dizinleri — ekip paylaşımı için kritik

conf/local.conf — cache
# İndirilen kaynak arşivleri
# Ekipte NFS veya ortak disk ile paylaşılabilir
DL_DIR ?= "/data/yocto/downloads"

# sstate-cache: her task'ın binary çıktısı
# Paylaşılırsa yeni geliştiricinin ilk build'i de hızlanır
SSTATE_DIR ?= "/data/yocto/sstate-cache"

# Uzak sstate mirror (HTTP sunucu veya NFS)
SSTATE_MIRRORS ?= "file://.* https://sstate.yoctoproject.org/all/PATH;downloadfilename=PATH \n"

# Yocto'nun resmi sstate mirror'ı — public build'ler için ücretsiz
# SSTATE_MIRRORS = "file://.* https://sstate.yoctoproject.org/kirkstone/PATH"

Image özelleştirme

conf/local.conf — image
# Image'a ek paket ekle (:append operatörü — boşlukla başla!)
IMAGE_INSTALL:append = " htop strace tcpdump openssh-sftp-server"

# Image özellikleri
EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
# debug-tweaks: root şifresiz login, SSH key olmadan login
# ssh-server-openssh: OpenSSH sunucu dahil et
# tools-debug: gdb, strace, ltrace
# dev-pkgs: development header'ları (-dev paketler)
# read-only-rootfs: rootfs'i read-only mount et

# Distro özellikleri — paket setini kısıtla
DISTRO_FEATURES:remove = "x11 wayland opengl vulkan"
DISTRO_FEATURES:append = " systemd"

# systemd'yi init sistemi yap
VIRTUAL-RUNTIME_init_manager = "systemd"
DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
NOT

IMAGE_INSTALL:append değerinin başında boşluk olmalıdır — " htop strace" şeklinde. Aksi takdirde son mevcut token'a yapışır: core-image-minimalhtop gibi hatalı bir değer oluşur.

Bu bölümde

  • MACHINE hedef donanımı, DISTRO dağıtım politikasını belirler
  • DL_DIR ve SSTATE_DIR'ı ortak diske taşıyarak ekip build süresi dramatik düşer
  • IMAGE_INSTALL:append ile image'a kolayca paket eklenir (baştaki boşluğu unutmayın)
  • EXTRA_IMAGE_FEATURES: debug-tweaks geliştirme için, üretimde kaldırın

06 Image türleri ve özelleştirme

Yocto'nun standart image'ları belirli kullanım senaryoları için hazır başlangıç noktaları sunar; custom image oluşturmak ise yalnızca birkaç satır gerektirir.

Standart image'lar

ImageİçerikYaklaşık boyut
core-image-minimalBusyBox + minimal init, login shell~8 MB
core-image-baseminimal + temel araçlar~15 MB
core-image-full-cmdlineTam komut satırı araçları, bash~35 MB
core-image-satoGNOME-tabanlı masaüstü (X11)~200 MB+
core-image-minimal-devminimal + header'lar, geliştirme araçları~50 MB

Custom image oluşturma

recipes-core/images/my-product-image.bb
DESCRIPTION = "My Product — production image"

# core-image-minimal'dan türet
require recipes-core/images/core-image-minimal.bb

# Ek paketler
IMAGE_INSTALL:append = " \
    openssh \
    openssh-sftp-server \
    python3 \
    python3-pip \
    curl \
    htop \
    my-app \
    my-app-config \
"

# Debug araçları sadece debug build'de
IMAGE_INSTALL:append:class-target = " strace gdb ldd"

# Image özellikleri
IMAGE_FEATURES += "ssh-server-openssh read-only-rootfs"

# Maksimum rootfs boyutu (MB)
IMAGE_ROOTFS_SIZE ?= "65536"  # 64 MB

Image boyutunu küçültme

conf/local.conf — boyut optimizasyonu
# Gereksiz distro özellikleri kaldır
DISTRO_FEATURES:remove = "x11 wayland opengl 3g nfc wifi bluetooth"

# Doküman ve man sayfalarını dahil etme
DISTRO_FEATURES:append = " ptest"
INHERIT += "rm_work"  # build sonrası WORKDIR temizle — disk kullanımı düşer

# Locale kısıtla
IMAGE_LINGUAS = ""     # dil desteği yok — küçülür
GLIBC_GENERATE_LOCALES = "en_US.UTF-8"

# BusyBox her şeyi tek binary'de sağlar
# bash, coreutils, util-linux paketlerini KALDIRIN
# BusyBox applet konfigürasyonu: busybox-menuconfig

wic ile disk image (.wks)

scripts/lib/wic/canned-wks/my-sdimage.wks
# SD kart layout: boot (FAT32) + rootfs (ext4)
part /boot --source bootimg-partition --ondisk mmcblk0 \
           --fstype=vfat --label boot --active --align 4 --size 64

part / --source rootfs --ondisk mmcblk0 \
        --fstype=ext4 --label root --align 4

# local.conf'ta aktif et
# IMAGE_FSTYPES += "wic"
# WKS_FILE = "my-sdimage.wks"

# Üretilen dosyayı SD karta yaz
# sudo dd if=my-product-image.wic of=/dev/sdb bs=4M status=progress

Bu bölümde

  • core-image-minimal (~8 MB) en küçük başlangıç noktası; custom image için require ile türetin
  • IMAGE_FEATURES: ssh-server, read-only-rootfs, tools-debug gibi hazır özellik setleri
  • DISTRO_FEATURES:remove ile x11/wayland kaldırarak boyut önemli ölçüde düşer
  • wic + .wks ile tam SD kart image'ı doğrudan üretilebilir

07 BSP layer ve donanım desteği

BSP (Board Support Package) layer, belirli bir donanım için kernel, bootloader ve device tree konfigürasyonunu sağlar.

Yaygın BSP layer'ları

LayerDesteklenen donanımKaynak
meta-raspberrypiRaspberry Pi 2/3/4/5/Zerogit.yoctoproject.org
meta-tiBeagleBone, AM335x, AM64xgit.ti.com
meta-freescalei.MX6/7/8, LS-seriesgithub.com/Freescale
meta-intelIntel Atom, Core, NUCgit.yoctoproject.org
meta-armARM reference boards, Corstonegit.yoctoproject.org

Raspberry Pi 4 — meta-raspberrypi ile build

bash — BSP layer kurulumu
# Poky dizinine git
cd ~/yocto/poky

# meta-raspberrypi klonla — Yocto sürümüyle eşleşmeli!
git clone https://git.yoctoproject.org/meta-raspberrypi -b kirkstone

# Build ortamı
source oe-init-build-env build-rpi/

# Layer'ı ekle
bitbake-layers add-layer ../../meta-raspberrypi

# meta-openembedded de gerekli (meta-raspberrypi bağımlılığı)
git clone https://github.com/openembedded/meta-openembedded -b kirkstone
bitbake-layers add-layer ../../meta-openembedded/meta-oe
bitbake-layers add-layer ../../meta-openembedded/meta-python
bitbake-layers add-layer ../../meta-openembedded/meta-multimedia
bitbake-layers add-layer ../../meta-openembedded/meta-networking
conf/local.conf — Raspberry Pi 4
# Raspberry Pi 4 — 64-bit kernel (AArch64)
MACHINE = "raspberrypi4-64"

# Kernel sağlayıcısı — meta-raspberrypi'nin linux-raspberrypi recipe'si
PREFERRED_PROVIDER_virtual/kernel = "linux-raspberrypi"

# Device tree dosyaları
KERNEL_DEVICETREE = "broadcom/bcm2711-rpi-4-b.dtb"

# Raspberry Pi özgü özellikler
ENABLE_UART = "1"           # UART konsol aktif
ENABLE_I2C  = "1"           # I2C etkinleştir
RPI_USE_U_BOOT = "1"       # U-Boot bootloader kullan

# GPU memory split (headless için minimum)
GPU_MEM = "16"

# Image tipini SD kart için ayarla
IMAGE_FSTYPES += "rpi-sdimg"

# Build ve SD'ye yaz
# bitbake core-image-minimal
# sudo dd if=core-image-minimal-raspberrypi4-64.rpi-sdimg of=/dev/sdX bs=4M

Machine-specific .bbappend

recipes-bsp/u-boot/u-boot_%.bbappend
# Sadece raspberrypi4-64 için geçerli
FILESEXTRAPATHS:prepend:raspberrypi4-64 := "${THISDIR}/files:"
SRC_URI:append:raspberrypi4-64 = " file://rpi4-custom.cfg"

# BeagleBone için farklı konfigürasyon
SRC_URI:append:beaglebone = " file://bbb-custom.cfg"

Bu bölümde

  • BSP layer = kernel + bootloader + device tree + machine konfigürasyonu
  • meta-raspberrypi Yocto sürümüyle birebir eşleşmeli (aynı branch: kirkstone)
  • PREFERRED_PROVIDER_virtual/kernel ile hangi kernel recipe'sinin kullanılacağını seçin
  • :append:<MACHINE> ile makineye özel .bbappend değişkenleri koşullu tanımlanır

08 SDK üretimi

SDK, uygulama geliştiricilerin tam Yocto build ortamına ihtiyaç duymadan hedef sistem için cross-compile yapmasını sağlar.

SDK neden gerekli

Geliştirici ortamıUygulama geliştiricisi Yocto'yu bilmek zorunda kalmadan cross-compile yapabilir
CI/CD entegrasyonuJenkins/GitLab CI pipeline'ına kolayca dahil edilir — Yocto build gerektirmez
IDE desteğiEclipse, VS Code, CLion ile cross-compile — toolchain otomatik algılanır
HızSDK kurulumu dakikalar içinde — tam Yocto build saatler alır

SDK üretimi

bash — SDK build
# Standart SDK üret (cross-compiler + sysroot)
bitbake core-image-minimal -c populate_sdk

# SDK installer dosyası oluşur
ls tmp/deploy/sdk/
# poky-glibc-x86_64-core-image-minimal-cortexa72-raspberrypi4-64-toolchain-4.0.sh

# eSDK: BitBake dahil, recipe bazlı geliştirme
bitbake core-image-minimal -c populate_sdk_ext

# SDK'yı kur
./tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-cortexa72-*.sh
# Varsayılan kurulum dizini: /opt/poky/4.0/

SDK'yı kullanma

bash — SDK kullanımı
# Toolchain ortamını yükle (her yeni terminalde)
source /opt/poky/4.0/environment-setup-cortexa72-poky-linux

# Ortam değişkenlerini kontrol et
echo $CC
# aarch64-poky-linux-gcc  -mcpu=cortex-a72 --sysroot=/opt/poky/4.0/sysroots/cortexa72-poky-linux

echo $CXX
# aarch64-poky-linux-g++  -mcpu=cortex-a72 --sysroot=...

echo $SYSROOT
# /opt/poky/4.0/sysroots/cortexa72-poky-linux

# C programını cross-compile et
$CC -o hello hello.c

# CMake projesi için
cmake .. -DCMAKE_TOOLCHAIN_FILE="$OECORE_NATIVE_SYSROOT/usr/share/cmake/OEToolchainConfig.cmake"
make

# Autotools projesi için
./configure ${CONFIGURE_FLAGS}   # SDK ortam değişkeni kullan
make
NOT

eSDK (populate_sdk_ext) standart SDK'ya ek olarak BitBake ve recipe'leri içerir. devtool build ve devtool deploy-target ile recipe'yi doğrudan hedef cihaza gönderebilirsiniz. Büyük ekiplerde eSDK tercih edilir.

Bu bölümde

  • bitbake <image> -c populate_sdk: standalone .sh installer üretir
  • source environment-setup-*: $CC, $CXX, $SYSROOT otomatik ayarlanır
  • CMake için OEToolchainConfig.cmake, autotools için ${CONFIGURE_FLAGS} kullanın
  • eSDK = SDK + BitBake + devtool: geliştirici doğrudan recipe ile çalışabilir

09 sstate-cache ve build optimizasyonu

sstate-cache, Yocto'nun incremental build gücünün temelidir — her görevin çıktısını hashleyerek cache'ler ve tekrar çalıştırmaz.

sstate-cache nasıl çalışır

recipe değişkenleri + bağımlılıklar + flags → SHA256 hash → sstate-cache/XX/sigdata-HASH.tar.zst

BitBake bir görevi çalıştırmadan önce hash hesaplar. Eşleşen bir sstate dosyası varsa görev atlanır, çıktı doğrudan yerleştirilir. Bu sayede binlerce görevden yalnızca değişenler yeniden çalışır.

Ekip paylaşımlı sstate-cache

conf/local.conf — paylaşımlı cache
# NFS veya ortak disk üzerinde sstate
SSTATE_DIR = "/mnt/yocto-shared/sstate-cache"
DL_DIR     = "/mnt/yocto-shared/downloads"

# HTTP mirror (read-only — otomatik fallback)
SSTATE_MIRRORS = "file://.* \
    file:///mnt/yocto-shared/sstate-cache/PATH \n \
    file://.* \
    https://sstate.yoctoproject.org/kirkstone/PATH;downloadfilename=PATH \n"

# BB_HASHSERVE: hash sunucusu — ekip build koordinasyonu
BB_HASHSERVE = "auto"  # yerel hashserve başlat
# BB_HASHSERVE = "hashserve.server:8686"  # merkezi sunucu

CI/CD için fetch-only build

bash — CI optimizasyonu
# Sadece kaynak indir (compile yok) — network aşamasını öne al
bitbake --runall=fetch core-image-minimal

# Offline build: tüm kaynaklar zaten DL_DIR'da
BB_NO_NETWORK = "1"
bitbake core-image-minimal

# Signature/hash analizi — değişimi bul
bitbake -S none core-image-minimal
# stamps/ altında signature dosyaları oluşur

# İki build arasında hash farkını bul
bitbake-diffsigs \
    tmp/stamps/cortexa72-poky-linux/busybox/*/do_compile.sigdata.* \
    /old-build/tmp/stamps/.../do_compile.sigdata.*

rm_work ile disk kullanımını azalt

conf/local.conf — disk optimizasyonu
# Her recipe build sonrası WORKDIR'ı temizle
# tmp/work/ 30-50 GB yer tutabilir — rm_work ile ~5 GB'a düşer
INHERIT += "rm_work"

# Bazı recipe'leri rm_work'ten muaf tut (debug için)
RM_WORK_EXCLUDE += "my-app busybox"

Bu bölümde

  • sstate-cache: hash eşleşirse görev atlanır — ikinci build çok hızlı
  • DL_DIR + SSTATE_DIR ortak diske taşıyın: yeni geliştirici bile hızlı build yapar
  • SSTATE_MIRRORS + Yocto resmi mirror: public paketler için ücretsiz cache
  • INHERIT += "rm_work": tmp/ dizini 30–50 GB'dan ~5 GB'a düşer

10 Debugging ve sorun giderme

Build hataları genellikle fetch, checksum, compile veya paket çakışmasından kaynaklanır — her birinin sistematik debug yaklaşımı farklıdır.

Debug bilgi seviyesi artırma

bash — debug flags
# Debug çıktısı artır (-D: her -D bir seviye artırır)
bitbake -D my-app           # level 1
bitbake -DD my-app          # level 2 — çok detaylı

# Sadece belirli recipe'yi yeniden çalıştır (force)
bitbake -f -c compile my-app

# Bağımlılık eksikliği hatası — recipetool ile kontrol
bitbake -g my-app
grep my-app pn-buildlist

Recipe çalışma dizini

bash — WORKDIR inceleme
# WORKDIR: her recipe'nin geçici çalışma alanı
# tmp/work/<arch>/<recipe>/<version>-<release>/
ls tmp/work/cortexa72-poky-linux/my-app/1.0-r0/

# Önemli alt dizinler:
# sources/      — extracted kaynak
# build/        — out-of-tree build dizini (cmake/autotools)
# image/        — do_install çıktısı (sahte rootfs)
# packages-split/ — alt paketler
# temp/         — log dosyaları, run.do_* scriptleri

# Hata logunu oku
cat tmp/work/cortexa72-poky-linux/my-app/1.0-r0/temp/log.do_compile
cat tmp/work/cortexa72-poky-linux/my-app/1.0-r0/temp/run.do_compile

Yaygın hata senaryoları

bash — hata giderme
─── do_fetch hatası: checksum mismatch ───
# Eski tarball önbellekte — temizle
bitbake -c cleanall my-app
# Ya da DL_DIR'dan eski dosyayı sil, doğru sha256sum'u recipe'ye yaz
rm downloads/my-app-1.0.tar.gz*

─── do_compile hatası: header bulunamadı ───
# devshell'de manuel kontrol
bitbake -c devshell my-app
# Shell içinde:
# oe_runmake    → do_compile'ı taklit et
# $CC -v        → toolchain yolunu kontrol et
# pkg-config --list-all | grep ssl  → bağımlılık var mı?

─── Paket çakışması ───
bitbake-layers show-recipes openssl
# Hangi layer kazanıyor, BBFILE_PRIORITY kontrol et

Gelişmiş debug araçları

bash — ileri araçlar
# İki build arasında hash farkı — neden yeniden build edildi?
bitbake-diffsigs --signature-diff \
    tmp/stamps/.../do_compile.sigdata.new \
    tmp/stamps/.../do_compile.sigdata.old

# Paket içeriği sorgulama
oe-pkgdata-util list-pkgs -p my-app   # alt paketler
oe-pkgdata-util list-pkg-files my-app   # hangi dosyalar hangi paketin
oe-pkgdata-util find-path '/usr/bin/myexe'  # dosyayı hangi paket sağlıyor

# Yeni recipe iskeleti oluştur
recipetool create https://github.com/user/mylib/archive/v1.0.tar.gz
# Otomatik: LICENSE, SRC_URI, SRC_URI[sha256sum], inherit tespiti

# devtool ile kaynak üzerinde çalış
devtool modify my-app     # recipe'yi workspace'e al
devtool build my-app      # değişiklikle build et
devtool finish my-app meta-mylayer  # layer'a geri yaz
DİKKAT

bitbake -c cleanall hem WORKDIR'ı hem sstate-cache girişini hem de DL_DIR'daki arşivi siler. Ekip ortamında paylaşılan DL_DIR'da bu komutu dikkatli kullanın — diğer geliştiricilerin önbelleğini de temizler.

Bu bölümde

  • temp/log.do_compile ve temp/run.do_compile hata detaylarını içerir
  • bitbake -c devshell: cross-compile ortamında interaktif hata ayıklama
  • oe-pkgdata-util find-path: hangi dosya hangi paket, hangi recipe sorusunu çözer
  • recipetool create <url>: yeni recipe iskelet üretir, manual yazma gerekmez

11 Gerçek dünya: custom meta-layer oluşturma

Proje recipe'lerini, board konfigürasyonunu ve .bbappend dosyalarını tek bir custom layer'da toplamak Yocto'nun en iyi pratiklerindendir.

Layer iskelet oluşturma

bash — layer oluştur
# Otomatik iskelet oluştur
bitbake-layers create-layer ../meta-myproject

# Oluşturulan yapı:
# meta-myproject/
# ├── conf/layer.conf
# ├── COPYING.MIT
# ├── README
# └── recipes-example/
#     └── example/
#         └── example_0.1.bb

# Build'e ekle
bitbake-layers add-layer ../meta-myproject

C uygulaması + systemd service recipe'si

meta-myproject/recipes-myapp/myapp/myapp_1.0.bb
DESCRIPTION = "My embedded application"
LICENSE     = "MIT"
LIC_FILES_CHKSUM = "file://LICENSE;md5=..."

SRC_URI = "git://github.com/myorg/myapp.git;protocol=https;branch=main"
SRCREV  = "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2"
S       = "${WORKDIR}/git"

SRC_URI += "file://myapp.service"

DEPENDS = "openssl"

inherit cmake systemd pkgconfig

SYSTEMD_SERVICE:${PN} = "myapp.service"
SYSTEMD_AUTO_ENABLE   = "enable"

do_install:append() {
    install -d ${D}${systemd_unitdir}/system/
    install -m 0644 ${WORKDIR}/myapp.service \
        ${D}${systemd_unitdir}/system/
    install -d ${D}${sysconfdir}/myapp
    install -m 0644 ${S}/config/default.conf \
        ${D}${sysconfdir}/myapp/myapp.conf
}

FILES:${PN} += "${systemd_unitdir}/system/myapp.service \
               ${sysconfdir}/myapp"

RDEPENDS:${PN} = "libssl3"

PACKAGECONFIG ile özellik toggle

myapp_1.0.bb — PACKAGECONFIG
# PACKAGECONFIG: opsiyonel özellikleri açıp kapamak için
# Format: "feature" = "DEPENDS, RDEPENDS, EXTRA_OECONF_enabled, EXTRA_OECONF_disabled"
PACKAGECONFIG ??= "ssl"   # varsayılan: ssl açık

PACKAGECONFIG[ssl]     = "--enable-ssl,--disable-ssl,openssl,libssl3"
PACKAGECONFIG[mqtt]    = "--enable-mqtt,--disable-mqtt,mosquitto,libmosquitto1"
PACKAGECONFIG[debug]   = "--enable-debug,--disable-debug"

# local.conf veya .bbappend'den toggle:
# PACKAGECONFIG:append:pn-myapp = " mqtt debug"
# PACKAGECONFIG:remove:pn-myapp = "ssl"

CI entegrasyonu — kas / repo tool

kas-project.yml — kas manifest
header:
  version: 14

machine: raspberrypi4-64
distro: poky
target:
  - my-product-image

repos:
  poky:
    url: https://git.yoctoproject.org/poky
    branch: kirkstone
    layers:
      meta:
      meta-poky:
      meta-yocto-bsp:

  meta-raspberrypi:
    url: https://git.yoctoproject.org/meta-raspberrypi
    branch: kirkstone
    layers:
      .:

  meta-openembedded:
    url: https://github.com/openembedded/meta-openembedded
    branch: kirkstone
    layers:
      meta-oe:
      meta-python:
      meta-networking:

  meta-myproject:
    url: https://github.com/myorg/meta-myproject
    branch: main
    layers:
      .:

local_conf_header:
  standard: |
    BB_NUMBER_THREADS = "8"
    PARALLEL_MAKE = "-j8"
    DL_DIR = "/data/yocto/downloads"
    SSTATE_DIR = "/data/yocto/sstate-cache"
bash — kas ile build
# kas kurulumu
pip3 install kas

# Tek komutla tüm layer'ları klonla ve build et
kas build kas-project.yml

# Sadece ortam hazırla (shell'e girmek için)
kas shell kas-project.yml
NOT

kas, repo URL'lerini ve branch'lerini tek YAML dosyasında yönetir. Git submodule veya repo manifest'e göre çok daha sade ve Yocto'ya özgü bir yaklaşımdır. CI/CD pipeline'larında kas build kas-project.yml tek satırla tüm build ortamını oluşturur.

Bu bölümde

  • bitbake-layers create-layer: iskelet layer oluşturur — conf/layer.conf dahil
  • systemd servis recipe'si: inherit systemd + SYSTEMD_SERVICE + do_install:append
  • PACKAGECONFIG: opsiyonel özellikleri DEPENDS ve configure flag'lerini birlikte yönetir
  • kas YAML manifesti: tüm layer repo'larını + local.conf'u tek dosyada tanımlar