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
| Özellik | Yocto Project | Buildroot |
|---|---|---|
| Öğrenme eğrisi | Dik — BitBake DSL, layer kavramı | Düz — Makefile tabanlı, sade |
| İlk build süresi | 1–2 saat (sstate-cache yoksa) | 20–40 dakika |
| Incremental build | Güçlü sstate-cache mekanizması | Sınırlı, genelde tam build |
| Paket sayısı | 5000+ recipe | 2000+ paket |
| Çoklu board desteği | BSP layer sistemiyle mükemmel | defconfig bazlı, daha az esnek |
| SDK üretimi | Yerleşik, güçlü | make sdk — temel düzeyde |
| Ticari destek | Wind River, Mentor, Timesys | Sınırlı |
| Ne zaman tercih et | Büyük ekip, çok board, commercial | Küçü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:
Release isimleri ve LTS
| Sürüm | Kod adı | Durum | Yayın |
|---|---|---|---|
| 4.0 | Kirkstone | LTS (Nisan 2024'e kadar) | Nisan 2022 |
| 4.1 | Langdale | Stable | Ekim 2022 |
| 4.2 | Mickledore | Stable | Mayıs 2023 |
| 5.0 | Scarthgap | LTS | Nisan 2024 |
| 5.1 | Styhead | Stable | Ekim 2024 |
Ü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
# 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-env | Build ortamını initialize eden script |
| scripts/ | bitbake-layers, recipetool, runqemu vb. araçlar |
Poky klonlama ve ortam hazırlama
# 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
# İ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
İlk build'de tmp/ dizini 20–40 GB yer kaplayabilir. DL_DIR ve SSTATE_DIR'ı local.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-64ile 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ı
# 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ı
# 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
# 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
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 debugbitbake -e <recipe> | grep ^VAR: gerçek değişken değerini sorgulabitbake -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
SRC_URI türleri
# 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
# 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
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ı
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 autotoolsveyainherit cmakeile 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 / Dizin | Amaç |
|---|---|
| meta-mylayer/ | Layer kök dizini — meta- öneki gelenek |
| meta-mylayer/conf/layer.conf | Layer 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/README | Bağımlılıklar, LAYERVERSION, nasıl kullanılır |
conf/layer.conf anatomisi
# 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
# 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
.bbappend ile override
# % 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"
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-layerbblayers.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ı
# 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
# İ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
# 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"
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 | İçerik | Yaklaşık boyut |
|---|---|---|
core-image-minimal | BusyBox + minimal init, login shell | ~8 MB |
core-image-base | minimal + temel araçlar | ~15 MB |
core-image-full-cmdline | Tam komut satırı araçları, bash | ~35 MB |
core-image-sato | GNOME-tabanlı masaüstü (X11) | ~200 MB+ |
core-image-minimal-dev | minimal + header'lar, geliştirme araçları | ~50 MB |
Custom image oluşturma
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
# 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)
# 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
requireile 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ı
| Layer | Desteklenen donanım | Kaynak |
|---|---|---|
meta-raspberrypi | Raspberry Pi 2/3/4/5/Zero | git.yoctoproject.org |
meta-ti | BeagleBone, AM335x, AM64x | git.ti.com |
meta-freescale | i.MX6/7/8, LS-series | github.com/Freescale |
meta-intel | Intel Atom, Core, NUC | git.yoctoproject.org |
meta-arm | ARM reference boards, Corstone | git.yoctoproject.org |
Raspberry Pi 4 — meta-raspberrypi ile build
# 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
# 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
# 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
SDK üretimi
# 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
# 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
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 üretirsource 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
# 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
# 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
# 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
# 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
# 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ı
─── 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ı
# İ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
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_compilevetemp/run.do_compilehata detaylarını içerirbitbake -c devshell: cross-compile ortamında interaktif hata ayıklamaoe-pkgdata-util find-path: hangi dosya hangi paket, hangi recipe sorusunu çözerrecipetool 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
# 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
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
# 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
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"
# 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
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