Slides Yocto

Fazer download em pdf ou txt
Fazer download em pdf ou txt
Você está na página 1de 335

YOCTO PROJECT

Sergio Prado

[email protected]

https://www.linkedin.com/in/sprado
SOBRE ESTE DOCUMENTO
Slides do treinamento de Yocto Project v1.1.1.

A versão mais atual dos slides está disponível no site da Embedded Labworks.

https://e-labworks.com/training/ypr/slides

Este documento é disponibilizado sob a licença Creative Commons Attribution-


ShareAlike 4.0 International (CC BY-SA 4.0). Os termos completos desta licença estão
disponíveis no link abaixo:

https://creativecommons.org/licenses/by-sa/4.0/
SOBRE O INSTRUTOR
Mais de 25 anos de experiência em desenvolvimento de software para sistemas
embarcados, atuando principalmente em projetos com Linux embarcado, Android
embarcado e sistemas operacionais de tempo real.

Sócio da Embedded Labworks, onde atua com consultoria, treinamento e


desenvolvimento de software para sistemas embarcados.

https://e-labworks.com

Ativo na comunidade de sistemas embarcados no Brasil, sendo um dos criadores do


site Embarcados e mantenedor de alguns blogs sobre assuntos da área.

https://sergioprado.blog

É colaborador de alguns projetos de software livre, incluindo o Buildroot, o Yocto


Project e o kernel Linux.
AGENDA DO TREINAMENTO
DIA 1: Introdução ao Yocto Project, primeiros passos com o Poky, visão geral do
sistema de build OpenEmbedded e da ferramenta BitBake, introdução ao conceito
de camadas e receitas.

DIA 2: Conceitos avançados de receitas, customização de imagens.

DIA 3: Desenvolvimento de camadas de BSP, geração e uso do (Extensible) SDK,


ferramentas e recursos adicionais, encerramento.
HARDWARE: COLIBRI IMX6 + ASTER + IPÊ BOARD
PRÉ-REQUISITOS
Conhecimentos básicos de ferramentas de linha de comando GNU/Linux.

Arquitetura de sistemas com Linux embarcado.

Compilação de aplicações com GCC, make, cmake, autotools, etc.

Controle de versão com Git.

Programação em C/C++.
AMBIENTE DE LABORATÓRIO
$ tree -L 2 /opt/labs/

/opt/labs/

├── dl

│   ├── appsecret.tar.bz2

│   ├── fping-5.0.tar.gz

│   ├── layers.tar.bz2

| ...

├── docs

│ ├── agenda.html

│ ├── answers.html

│ ├── install.html

│ ├── labs.html

│ ├── slides.pdf

│ └── version.txt

├── ex

│ ├── downloads

│ └── sstate-cache

└── tools

├── build.conf

├── build.sh

├── layers.conf

├── prepare.cfg

└── prepare.sh
DURANTE O TREINAMENTO
Pergunte...

Expresse seu ponto de vista...

Troque experiências...

Ajude...

Participe!
YOCTO PROJECT

INTRODUÇÃO AO YOCTO PROJECT


LINUX EMBARCADO
COMPONENTES DO SISTEMA
Hardware: plataforma alvo (target).

Bootloader: responsável pela inicialização básica do hardware, carregamento e


execução do kernel Linux.

Kernel Linux: núcleo do sistema operacional. Gerencia CPU, memória e I/O,


exportando serviços para a camada de usuário (aplicações).

Rootfs: sistema de arquivos principal.


Biblioteca C: API do sistema operacional, interface entre o kernel e as aplicações.

Bibliotecas e aplicações do usuário.

Toolchain: conjunto de ferramentas para manipular e gerar os artefatos do sistema


operacional (bootloader, kernel, rootfs).
DESENVOLVENDO COM LINUX EMBARCADO
Podemos adotar 3 abordagens diferentes ao desenvolver um sistema com Linux
embarcado:
Utilizar uma distribuição pronta.

Construir um sistema Linux manualmente.

Construir um sistema Linux utilizando uma ferramenta de build (build system).


SOLUÇÃO 1: DISTRIBUIÇÃO PRONTA
Existem soluções de distribuição Linux comercializadas por empresas como a
MontaVista e a WindRiver.

https://www.mvista.com/products

Existem também diversas opções de código-aberto, incluindo Android, Debian,


Ubuntu, Fedora IoT, etc.

Vantagens do uso de uma distribuição pronta:


Simplicidade de uso.

Facilidade para estender suas funcionalidades.

Framework de desenvolvimento pronto e funcional.


DESVANTAGENS DISTRO PRONTA
Não otimizado para a plataforma alvo, impactando o consumo de recursos (CPU,
memória, armazenamento, energia, etc).

Tempo de boot alto.

Pouca flexibilidade de customização, já que os componentes de software de uma


distribuição pronta (init system, daemons, etc) são muito acoplados e dependentes
entre si.

Possíveis impactos na segurança da solução.


DESVANTAGENS DISTRO PRONTA (CONT.)
Dificuldade de atender aos requisitos de licença no uso de código copyleft (GPL e
similares).

Algumas funcionalidades são difíceis de implementar em uma distribuição pronta


(atualização remota, boot seguro, etc).

Alterações na distribuição não são facilmente reproduzíveis.

Trabalho dobrado de manutenção em possíveis atualizações da distribuição.


SOLUÇÃO 2: PROCESSO MANUAL
Gerar um sistema Linux manualmente permite um controle total sobre as
ferramentas utilizadas para a geração do sistema, assim como a flexibilidade
necessária para gerar uma distribuição Linux customizada para o target.

Porém, gerar um sistema Linux completo manualmente é uma atividade


extremamente trabalhosa, demorada, difícil de reproduzir e suscetível a erros.

Para os mais aventureiros:

https://www.linuxfromscratch.org/
SOLUÇÃO 3: SISTEMAS DE BUILD
Um sistema de build permite gerar um sistema Linux completo e customizado para a
plataforma alvo.

Provê um conjunto de ferramentas que automatizam o processo de geração de todos


os componentes do sistema operacional (toolchain, bootloader, kernel, rootfs).

Normalmente já contém um conjunto grande de pacotes pré-configurados para


serem habilitados e utilizados pelo seu sistema.

E facilita bastante o trabalho de configurar e estender o sistema gerado, conforme a


necessidade.
VANTAGENS DE UM SISTEMA DE BUILD
Flexibilidade, possibilitando o controle total sobre todos os componentes do sistema
operacional.

Permite a geração de uma imagem otimizada para a plataforma alvo.

Controle maior sobre a utilização dos recursos de hardware (CPU, memória,


armazenamento, energia, etc).

Tempo de boot menor.


VANTAGENS DE UM SISTEMA DE BUILD (CONT.)
Facilita a implementação de funcionalidades como boot seguro e atualização
remota.

Auxilia no controle das licenças dos componentes de software incluídos na imagem.

Os builds são controlados e reproduzíveis.

Arquivos de configuração e outros metadados para a geração da distribuição podem


ser versionados, facilitando o controle e a manutenção do sistema operacional no
decorrer do tempo.
SISTEMAS DE BUILD OPEN SOURCE
Buildroot, desenvolvido pela comunidade:

https://www.buildroot.org

PTXdist, mantido pela empresa Pengutronix:

https://www.ptxdist.org

OpenWRT, buildsystem (e distribuição) com foco em dispositivos de rede:

https://openwrt.org

OpenEmbedded (utilizado pelo Yocto Project), mais flexível e também mais


complexo:

https://www.openembedded.org
O QUE É O YOCTO PROJECT?
Projeto colaborativo que provê um conjunto de ferramentas para auxiliar na criação
de distribuições Linux customizadas para dispositivos embarcados.

https://www.yoctoproject.org

Fundado em 2010 por diversas empresas da área de tecnologia, fabricantes de


hardware e fornecedores de solução de software para Linux embarcado.

Sob a governança da Linux Foundation, garantindo a independência do projeto com


qualquer membro da organização.
ALGUNS MEMBROS
PROJETOS
Estes são alguns dos projetos que formam o Yocto Project:
Openembedded-Core

BitBake

Poky

Matchbox

AutoBuilder

Toaster

Uma lista dos projetos está disponível no link abaixo:

https://www.yoctoproject.org/software-overview/project-components/
O QUE O YOCTO PROJECT NÃO É?
O Yocto Project não é uma ferramenta ou um sistema de build.
É um projeto "guarda-chuva" que engloba diversas ferramentas e projetos open-
source com o objetivo de construir distribuições Linux para dispositivos
embarcados.

Utiliza o OpenEmbedded (BitBake, Openembedded-Core) como base para a


construção da distribuição.

O Yocto Project não é uma distribuição Linux.


Mas ele pode criar uma distribuição para você!
HISTÓRICO
CICLO DE RELEASE
Os releases do Yocto Project estão sujeitos a um cronograma definido pela
comunidade e publicado em:

https://wiki.yoctoproject.org/wiki/Planning#Yocto

Espera-se que um novo release do Yocto Project seja liberado a cada 6 meses
(normalmente em abril e outubro).

https://wiki.yoctoproject.org/wiki/Releases

Patches para corrigir bug críticos e falhas de segurança são aplicados também em
uma versão anterior e em versões LTS.

Neste treinamento utilizaremos o Yocto Project 4.0.1 (Kirkstone).


CARACTERÍSTICAS E VANTAGENS
Extremamente configurável e flexível na geração de sistemas Linux.

Milhares de pacotes de software pré-configurados e disponíveis para compilação


cruzada.

Provê facilidades para manter e estender o sistema através do mecanismo de


camadas.

É suportado pelas principais arquiteturas de hardware (ARM, MIPS, x86, PPC) e


fabricantes de SoC/SoM, servindo de padrão para o desenvolvimento de BSPs.
CARACTERÍSTICAS E VANTAGENS (CONT.)
Suporte à geração de sistemas Linux multiplataforma, sendo trivial mudar a geração
de uma imagem inteira para uma plataforma diferente.

Suporte ao gerenciamento de pacotes de software (rpm, deb, ipk), possibilitando o


desenvolvimento de distribuições Linux que incluem um servidor remoto de pacotes.

Permite a geração de ferramentas de desenvolvimento como SDKs e emuladores.

Controle e filtro de licenças (ex: gerar um sistema sem GPLv3).

Comunidade bastante ativa.


ARQUITETURA BÁSICA
CONCEITOS: POKY
Poky é a distribuição de referência do Yocto Project, disponibilizado através de um
repositório Git.

https://git.yoctoproject.org/poky

Contém a base do sistema de build OpenEmbedded (BitBake e OpenEmbedded-


Core) e um conjunto adicional de metadados para gerar distribuições Linux.

É capaz de gerar distribuições Linux para o QEMU e algumas plataformas de


referência (Beaglebone, EdgeRouter, x86-64, etc).

Pode ser facilmente estendido através do conceito de camadas.


CONCEITOS: CAMADAS E METADADOS
As camadas contém metadados para a compilação dos componentes de software
que irão compor a distribuição gerada.

São 3 tipos de metadados:


Receitas (recipes): conjunto de tarefas para compilar determinado software (.bb,
.bbappend).

Classes (classes): contém a definição de tarefas comuns que podem ser


reutilizadas em receitas (.bbclass).

Arquivos de configuração: contém a definição de variáveis que definem como a


distribuição deve ser gerada (.conf).
COMPONENTES DO YOCTO PROJECT
DOCUMENTAÇÃO
O Yocto Project é um projeto muito bem documentado, e sua documentação pode
ser acessada no site do projeto.

https://docs.yoctoproject.org/

Introdução e visão geral do projeto:

https://docs.yoctoproject.org/overview-manual/index.html

Guia de início rápido:

https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html

Manual de referência:

https://docs.yoctoproject.org/ref-manual/index.html
DOCUMENTAÇÃO (CONT.)
Manual de desenvolvimento do Yocto Project:

https://docs.yoctoproject.org/dev-manual/index.html

Guia de desenvolvimento de BSP (Board Support Package):

https://docs.yoctoproject.org/bsp-guide/index.html

Manual de desenvolvimento do kernel Linux:

https://docs.yoctoproject.org/kernel-dev/index.html
DOCUMENTAÇÃO (CONT.)
Manual de desenvolvimento de aplicações (SDK):

https://docs.yoctoproject.org/sdk-manual/index.html

Documentação do BitBake:

https://docs.yoctoproject.org/bitbake.html

Sinta-se livre para consultar esta documentação durante o treinamento,


principalmente o manual de referência do Yocto Project.
YOCTO PROJECT

INTRODUÇÃO AO POKY
POKY
A comunidade do Yocto Project é responsável por manter diversos projetos, dentre
eles o Poky.

O Poky é a distribuição de referência do Yocto Project.

Utilizando apenas o Poky, é possível construir uma distribuição Linux customizada


para as plataformas de hardware suportadas oficialmente pelo projeto (QEMU,
Beaglebone, EdgeRouter, etc).

Nesta seção do treinamento, teremos uma breve introdução sobre como utilizar o
Poky para construir uma distribuição Linux customizada.
PREPARANDO A MÁQUINA DE BUILD
É recomendado o uso de uma máquina GNU/Linux com uma das seguintes
distribuições: Fedora, openSUSE, CentOS, Debian ou Ubuntu.

É necessário uma máquina com boa capacidade de processamento (ex: Intel Core i7),
com bastante memória (16Gb+) e espaço em disco (100Gb+).

Alguns pré-requisitos de software: gcc 5.0+, git 1.8.3.1+, python 3.6+, tar 1.28+, make.

Para informações mais detalhadas, consulte o site do projeto.

https://docs.yoctoproject.org/dev-manual/start.html#preparing-the-build-host
BAIXANDO O POKY
O repositório do Poky é versionado com o Git e pode ser clonado conforme abaixo:
$ git clone git://git.yoctoproject.org/poky.git

Este comando irá clonar o branch master do Poky, não recomendado por ser um
branch de desenvolvimento do projeto.

Por este motivo, é recomendado utilizar o parâmetro -b para indicar um branch


estável do projeto (release Kirkstone no exemplo abaixo).
$ git clone git://git.yoctoproject.org/poky.git -b kirkstone
CÓDIGO-FONTE DO POKY
$ ls poky/

bitbake MAINTAINERS.md meta-skeleton README.poky.md

contrib Makefile meta-yocto-bsp README.qemu.md

documentation MEMORIAM oe-init-build-env scripts

LICENSE meta README.hardware.md

LICENSE.GPL-2.0-only meta-poky README.md

LICENSE.MIT meta-selftest README.OE-Core.md


DESCRIÇÃO DOS DIRETÓRIOS
Diretório Descrição
bitbake Ferramenta BitBake
documentation Código-fonte da documentação do projeto
meta Metadados do OpenEmbedded-Core
meta-poky Metadados da distribuição Poky
meta-selftest Metadados de teste do build system
meta-skeleton Metadados de exemplo e referência
meta-yocto-bsp Metadados das plataformas de referência (Beaglebone, etc)
scripts Scripts de uso geral (runqemu, devtool, oe-pkgdata-util, etc)
PREPARANDO O DIRETÓRIO DE COMPILAÇÃO
Com o Poky clonado, o próximo passo é carregar o script de configuração do
ambiente de compilação (oe-init-build-env), disponível na raiz do código-fonte do
Poky:
$ source poky/oe-init-build-env

Este script irá configurar o ambiente de compilação no terminal atual, criando por
padrão um diretório chamado build com os arquivos de configuração necessários
para realizar a compilação.

Opcionalmente, é possível passar o nome do diretório de build ao carregar o script


de configuração:
$ source poky/oe-init-build-env build-test
O DIRETÓRIO DE BUILD
$ tree build/

build/

└── conf

├── bblayers.conf

├── local.conf

└── templateconf.cfg
O DIRETÓRIO DE BUILD (CONT.)
Por padrão, todo o processo de compilação irá acontecer dentro do diretório de
build.

O diretório de build é criado com alguns arquivos de configuração, incluindo o


bblayers.conf e o local.conf.

O bblayers.conf permite configurar as camadas que serão utilizadas na distribuição


Linux a ser gerada.

O local.conf permite definir variáveis de configuração globais que serão utilizadas


para parametrizar a compilação.
BBLAYERS.CONF
# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf

# changes incompatibly

POKY_BBLAYERS_CONF_VERSION = "2"

BBPATH = "${TOPDIR}"

BBFILES ?= ""

BBLAYERS ?= " \

/opt/labs/ex/layers/poky/meta \

/opt/labs/ex/layers/poky/meta-poky \

/opt/labs/ex/layers/poky/meta-yocto-bsp \

"
LOCAL.CONF
# Machine Selection

MACHINE ??= "qemuarm"

# Where to place downloads

DL_DIR ?= "${TOPDIR}/downloads"

# Where to place shared-state files

SSTATE_DIR ?= "${TOPDIR}/sstate-cache"

# Where to place the build output

TMPDIR = "${TOPDIR}/tmp"

# Default policy config

DISTRO ?= "poky"

# Package Management configuration

PACKAGE_CLASSES ?= "package_rpm"

...
VARIÁVEIS NO LOCAL.CONF
Variável Descrição
MACHINE Nome da plataforma alvo
DISTRO Nome da distribuição
DL_DIR Diretório de downloads
SSTATE_DIR Diretório para armazenar os caches de compilação
TMPDIR Diretório de compilação
PACKAGE_CLASSES Formato de empacotamento (rpm, deb, ipk)
CORE_IMAGE_EXTRA_INSTALL Pacotes adicionais para instalar na imagem
EXTRA_IMAGE_FEATURES Funcionalidades de imagem que deseja-se habilitar
COMPILANDO A IMAGEM
Com os arquivos bblayers.conf e local.conf configurados, é só iniciar o processo de
compilação:
$ bitbake core-image-minimal

O comando acima irá processar a receita core-image-minimal.bb, gerando uma


imagem mínima para ser executada no target (selecionado pela variável MACHINE).

Outras receitas de imagem estão disponíveis para processamento:


$ ls poky/meta/recipes-core/images/

build-appliance-image core-image-minimal-initramfs.bb

build-appliance-image_15.0.0.bb core-image-minimal-mtdutils.bb

core-image-base.bb core-image-ptest-all.bb

core-image-minimal.bb core-image-ptest-fast.bb

core-image-minimal-dev.bb core-image-tiny-initramfs.bb
DIRETÓRIO DE SAÍDA
Todo o processo de build acontecerá no diretório apontado pela variável TMPDIR
(por padrão tmp):
$ tree -L 1 tmp/

tmp/

├── abi_version

├── buildstats

├── cache

├── deploy

├── hosttools

├── log

├── pkgdata

├── saved_tmpdir

├── sstate-control

├── stamps

├── sysroots-components

├── sysroots-uninative

├── work

└── work-shared
IMAGENS GERADAS
As imagens geradas estarão disponíveis em tmp/deploy/images/<machine>/:
$ ls tmp/deploy/images/qemuarm/

core-image-minimal-qemuarm-20220627125439.qemuboot.conf

core-image-minimal-qemuarm-20220627125439.rootfs.ext4

core-image-minimal-qemuarm-20220627125439.rootfs.manifest

core-image-minimal-qemuarm-20220627125439.rootfs.tar.bz2

core-image-minimal-qemuarm-20220627125439.testdata.json

core-image-minimal-qemuarm.ext4

core-image-minimal-qemuarm.manifest

core-image-minimal-qemuarm.qemuboot.conf

core-image-minimal-qemuarm.tar.bz2

core-image-minimal-qemuarm.testdata.json

modules--5.15.44+git0+947149960e_1585df4dbb-r0-qemuarm-20220627103615.tgz

modules-qemuarm.tgz

zImage
zImage--5.15.44+git0+947149960e_1585df4dbb-r0-qemuarm-20220627103615.bin

zImage-qemuarm.bin
QEMU
O QEMU é um emulador e visualizador de hardware open source que suporta
diversas arquiteturas, incluindo x86, ARM, MIPS e PowerPC.

https://www.qemu.org/

Através do OpenEmbedded-Core, o Yocto Project provê diversas machines pré-


configuradas para o QEMU:
$ ls poky/meta/conf/machine/

include qemuarmv5.conf qemuppc64.conf qemuriscv64.conf

qemuarm64.conf qemumips64.conf qemuppc.conf qemux86-64.conf

qemuarm.conf qemumips.conf qemuriscv32.conf qemux86.conf


QEMU (CONT.)
Se alguma destas plataformas for selecionada através da variável MACHINE:
MACHINE ??= "qemuarm"

É possível utilizar o script runqemu para rodar a imagem gerada:


$ runqemu qemuarm
QEMU
LABORATÓRIO 1

PRIMEIROS PASSOS COM O POKY


YOCTO PROJECT

INTRODUÇÃO AO SISTEMA DE BUILD


POKY
Poky é a distribuição de referência do Yocto Project.

O Poky possui basicamente dois grandes componentes:


BitBake: processador/executor de tarefas.

Metadados: definição das tarefas e parâmetros para a execução de tarefas (o que


fazer, como fazer, etc).

Os metadados providos pelo Poky incluem:


OpenEmbedded-Core (meta): metadados compartilhados com a comunidade do
OpenEmbedded, e que servem de base para a criação da distribuição Linux.

Outros metadados (meta-poky, meta-yocto-bsp, etc): metadados mantidos pela


comunidade do Yocto Project.
METADADOS
Os metadados contém a definição do que deve ser feito durante a geração da
distribuição Linux.

São considerados metadados:


Receitas (.bb, .bbappend).

Classes (.bbclass).

Arquivos de configuração (.conf).


RECEITAS
Receitas (recipes) são arquivos com extensão .bb ou .bbappend.

Possuem este nome por que contém a "receita" para processar determinado
componente de software.

Uma receita inclui informações como a descrição e a versão do componente de


software, localização do código-fonte, dependências, procedimentos de compilação
e instalação, etc.

Uma lista das principais variáveis que podem ser utilizadas para descrever uma
receita está disponível no guia de referência do Yocto Project.

https://docs.yoctoproject.org/ref-manual/varlocality.html#recipes
ARQUIVOS DE APPEND
Arquivos do tipo append possuem a extensão .bbappend e possibilitam modificar o
comportamento de uma receita sem alterar sua implementação.

O conteúdo de um arquivo de append é concatenado no final da receita,


possibilitando redefinir tarefas e variáveis, e consequentemente alterando o
comportamento da receita original.

Para cada arquivo do tipo append deve-se ter uma receita correspondente.

Arquivos de append incentivam a reutilização e facilitam a manutenção de receitas


no Yocto Project.
CLASSES
Classes são arquivos com a extensão .bbclass e são utilizadas para abstrair
funcionalidades (tarefas) comuns em diferentes receitas.

Alguns exemplos de classes:


autotools.bbclass: compilar projetos baseados em Autotools.

cmake.bbclass: compilar projetos que utilizam o CMake.

kernel.bbclass: compilar o kernel Linux.

Para utilizar uma classe, a receita deve utilizar a diretiva inherit.

Veja o guia de referência do Yocto Project para uma lista das classes existentes.

https://docs.yoctoproject.org/ref-manual/classes.html
ARQUIVOS DE CONFIGURAÇÃO
Arquivos de configuração possuem a extensão .conf e contém a definição de variáveis
que parametrizam o sistema de build.

Permitem definer informações sobre a arquitetura e a plataforma de hardware,


organização e conteúdo da imagem, políticas de criação da distribuição, etc.

Apenas definições de variáveis e diretivas de include são permitidas em arquivos de


configuração.

Um conjunto das principais variáveis que podem ser definidas em arquivos de


configuração está disponível no guia de referência do Yocto Project.

https://docs.yoctoproject.org/ref-manual/varlocality.html#configuration
CAMADAS
Os metadados (receitas, classes e arquivos de configuração) são organizados em
camadas (layers) no sistema de build.

Cada camada é composta por um conjunto de metadados agrupados em um


diretório do sistema de build.

As camadas facilitam a manutenção e incentivam o reuso dos metadados.

No Yocto Project, um sistema Linux é gerado através da combinação de camadas.


AS CAMADAS NO POKY
$ tree -L 1 poky/

poky/

├── bitbake

├── contrib

├── documentation

├── LICENSE

├── LICENSE.GPL-2.0-only

├── LICENSE.MIT

├── MAINTAINERS.md

├── Makefile

├── MEMORIAM

├── meta

├── meta-poky

├── meta-selftest

├── meta-skeleton

├── meta-yocto-bsp

├── oe-init-build-env

├── README.hardware.md -> meta-yocto-bsp/README.hardware.md

├── README.md -> README.poky.md

├── README.OE-Core.md

├── README.poky.md -> meta-poky/README.poky.md

├── README.qemu.md

└── scripts
TIPOS DE CAMADAS
Podemos classificar as camadas em três tipos, que podem ser combinadas para
gerar a imagem de um sistema Linux:
Camada de BSP (Board Support Package).

Camada de distro (distribuição).

Camada de software (camadas adicionais de software).


CAMADA DE BSP
Uma camada de BSP (Board Support Package) provê metadados relacionados à
plataforma de hardware (machine):
Arquivo de configuração com a definição da arquitetura da CPU, configuração e
funcionalidades providas pelo hardware, etc.

Receitas para compilar o bootloader (ex: U-Boot) e o kernel Linux.

Receitas para compilar algum software específico para o hardware (bibliotecas


de acesso à GPU, etc).

Informações detalhadas sobre a criação e manutenção de camadas de BSP estão


disponíveis no site do projeto.

https://docs.yoctoproject.org/bsp-guide/bsp.html
META-YOCTO-BSP
$ tree meta-yocto-bsp/

meta-yocto-bsp/

├── conf

│ ├── layer.conf

│ └── machine

│ ├── beaglebone-yocto.conf

│ ├── edgerouter.conf

│ ├── genericx86-64.conf

│ ├── genericx86.conf

│ └── include

...

├── recipes-bsp

│ ├── formfactor

│ └── gma500-gfx-check

├── recipes-graphics

│ └── xorg-xserver

├── recipes-kernel

│ └── linux

└── wic

├── beaglebone-yocto.wks

├── edgerouter.wks

└── genericx86.wks.in
META-RASPBERRYPI
$ tree meta-raspberrypi/

meta-raspberrypi/

├── classes

├── conf

│ ├── layer.conf

│ └── machine

│ ...

│ ├── raspberrypi3-64.conf

│ ├── raspberrypi3.conf

│ ├── raspberrypi4-64.conf

│ ├── raspberrypi4.conf

│ ├── raspberrypi-cm3.conf

│ ├── raspberrypi-cm.conf

│ └── raspberrypi.conf

...

├── recipes-connectivity

├── recipes-core

├── recipes-devtools

├── recipes-graphics

├── recipes-kernel

├── recipes-multimedia

├── recipes-sato

└── wic
CAMADA DE DISTRO
A camada de distribuição define algumas regras para a geração da imagem do
sistema operacional, incluindo:
Toolchain para compilar a distribuição.

Biblioteca C (glibc, musl, newlib, etc).

Componentes básicos de software.

Tipo de empacotamento (ipk, deb, rpm).

Versão e "provedor" de determinado software.

As principais variáveis que podem ser utilizadas no contexto de distribuição estão


disponíveis no guia de referência do Yocto Project.

https://docs.yoctoproject.org/ref-manual/varlocality.html#distribution-distro
META-POKY
$ tree meta-poky/

meta-poky/

├── classes

│   └── poky-sanity.bbclass

├── conf

│   ├── bblayers.conf.sample

│   ├── conf-notes.txt

│   ├── distro

│   │   ├── include

│   │   ├── poky-altcfg.conf

│   │   ├── poky-bleeding.conf

│   │   ├── poky.conf

│   │   └── poky-tiny.conf

│   ├── layer.conf

│   ├── local.conf.sample

│   ├── local.conf.sample.extended

│   └── site.conf.sample

├── README.poky.md

└── recipes-core

├── busybox

│   ├── busybox

│   └── busybox_%.bbappend

...
META-LUNEOS
$ tree meta-luneos/

meta-luneos/

├── classes

├── conf

│ ├── distro

│ │ ├── include

│ │ └── luneos.conf

│ └── layer.conf

├── COPYING.MIT

├── lib

├── licenses

├── README

├── recipes-android

├── recipes-benchmark

├── recipes-connectivity

├── recipes-containers

├── recipes-core

├── recipes-devtools

├── recipes-extended

├── recipes-graphics

├── recipes-kernel

├── recipes-luneos

...
CAMADA DE SOFTWARE
As camadas de software fornecem receitas adicionais para compor a imagem que
será gerada.

Estas camadas normalmente agrupam um conjunto de receitas com características


similares:
Aplicações de rede (meta-networking).

Framework gráfico (meta-qt5).

Aplicações multimedia (meta-multimedia).

Linguagem Python (meta-python).

Aplicações específicas do produto.


OPENEMBEDDED-CORE
$ tree -L 1 meta

meta

├── classes

├── conf

├── COPYING.MIT

├── files

├── lib

├── recipes-bsp

├── recipes-connectivity

├── recipes-core

├── recipes-devtools

├── recipes-example

├── recipes-extended

├── recipes-gnome

├── recipes-graphics

├── recipes-kernel

├── recipes-multimedia

├── recipes-rt

├── recipes-sato

├── recipes-support

├── recipes.txt

└── site
META-QT5
$ tree -L 2 meta-qt5/

meta-qt5/

├── classes

│   ├── cmake_qt5.bbclass

│   ├── populate_sdk_qt5_base.bbclass

│   ├── populate_sdk_qt5.bbclass

│   ├── qmake5_base.bbclass

│   ├── qmake5.bbclass

│   └── qmake5_paths.bbclass

├── conf

│   └── layer.conf

...

└── recipes-qt

├── demo-extrafiles

├── examples

├── maliit

├── meta

├── packagegroups

├── qmllive

├── qsiv

├── qt5

├── qtchooser

...
BANCO DE DADOS DE CAMADAS
O Yocto Project mantém uma lista seleta de camadas suportadas oficialmente pelo
projeto.

https://www.yoctoproject.org/software-overview/layers/

O OpenEmbedded também mantém um banco de dados de camadas, muito mais


completo, porém menos validado.

https://layers.openembedded.org/layerindex/branch/master/layers/

Fabricantes e fornecedores de hardware podem não listar suas camadas nestes


bancos de dados.
A FERRAMENTA BITBAKE
A ferramenta BitBake possui a seguinte sintaxe:
$ bitbake [options] [recipename/target recipe:do_task ...]

Por exemplo, o comando abaixo irá processar a receita do BusyBox:


$ bitbake busybox

Quando a tarefa não é indicada no comando, o BitBake executa a tarefa build, que
depende de todas as outras tarefas "normais" necessárias para processar a receita.
$ bitbake -c build busybox
EXECUTANDO TAREFAS
Para executar apenas uma tarefa de uma receita, use a opção -c:
$ bitbake -c fetch busybox

Opcionalmente, a sintaxe abaixo também pode ser utilizada:


$ bitbake busybox:do_fetch

Para listar todas as tarefas de uma receita, execute a tarefa listtasks:


$ bitbake -c listtasks busybox
OPÇÕES INTERESSANTES DO BITBAKE
Utilize a opção -f para forçar a execução de uma tarefa:
$ bitbake -f -c compile busybox

A opção -k faz com que o bitbake continue executando as tarefas, mesmo em caso de
erro, até onde puder executar.
$ bitbake -k busybox

A opção --no-setscene faz o BitBake ignorar os caches de compilação:


$ bitbake --no-setscene -c compile busybox
LIMPANDO A COMPILAÇÃO
Para limpar apenas a saída da compilação (não limpa o cache de compilação),
execute a tarefa clean:
$ bitbake -c clean busybox

Para limpar a saída da compilação e o cache de compilação, execute a tarefa


cleansstate:
$ bitbake -c cleansstate busybox

Para limpar a saída da compilação, o cache de compilação e o download do código-


fonte, execute a tarefa cleanall:
$ bitbake -c cleanall busybox
POR DENTRO DO BITBAKE
O propósito inicial do BitBake é executar as tarefas descritas nas receitas.

Qual então o procedimento utilizado pelo BitBake para ler os metadados definidos
nas camadas, transformá-los em tarefas e executá-las, até que as imagens do sistema
operacional sejam geradas?

Em outras palavras, o que faz o BitBake no comando abaixo?


$ bitbake core-image-minimal
CARREGANDO A CONFIGURAÇÃO
O primeiro passo executado pelo BitBake é a leitura dos arquivos de configuração, na
seguinte ordem:
Arquivo bblayers.conf, que contém a definição das camadas na variável
BBLAYERS.

Arquivos de configuração (layer.conf) de cada uma das camadas incluídas no


BBLAYERS.

Arquivo bitbake.conf, que contém as definições básicas e globais que afetam


todas as receitas e tarefas que serão executadas.
BITBAKE.CONF
O arquivo bitbake.conf irá incluir ainda diversos outros arquivos de configuração,
dentre eles:
Arquivos locais do usuário (site.conf, local.conf, etc).

Arquivo de configuração da máquina (MACHINE).

Arquivo de configuração da distribuição (DISTRO).

Após carregar os arquivos de configuração, o BitBake irá carregar diversas classes,


incluindo a base.bbclass, que define um conjunto de tarefas que serão herdadas por
todas as receitas.

Todo o processo de leitura dos metadados pode ser visualizado com o parâmetro -e
do BitBake.
INCLUDE HISTORY
$ bitbake -e

# INCLUDE HISTORY:

# /opt/labs/ex/build-qemu/conf/bblayers.conf

# /opt/labs/ex/layers/poky/meta/conf/layer.conf

# /opt/labs/ex/layers/poky/meta-poky/conf/layer.conf

# /opt/labs/ex/layers/poky/meta-yocto-bsp/conf/layer.conf

# conf/bitbake.conf includes:

# /opt/labs/ex/layers/poky/meta/conf/abi_version.conf

# conf/site.conf

# conf/auto.conf

# /opt/labs/ex/build-qemu/conf/local.conf

# /opt/labs/ex/layers/poky/meta/conf/multiconfig/default.conf

# /opt/labs/ex/layers/poky/meta/conf/machine/qemuarm.conf includes:

# /opt/labs/ex/layers/poky/meta/conf/machine/include/arm/armv7a/tune-cortexa15.inc includes:

# /opt/labs/ex/layers/poky/meta/conf/machine/include/arm/arch-armv7ve.inc includes:

# /opt/labs/ex/layers/poky/meta/conf/machine/include/arm/arch-armv7a.inc includes:

# /opt/labs/ex/layers/poky/meta/conf/machine/include/arm/arch-armv6.inc includes:

# /opt/labs/ex/layers/poky/meta/conf/machine/include/arm/arch-armv5-dsp.inc includes:

# /opt/labs/ex/layers/poky/meta/conf/machine/include/arm/arch-armv5.inc includes:

# /opt/labs/ex/layers/poky/meta/conf/machine/include/arm/arch-armv4.inc includes:

...
PROCESSANDO A RECEITA
Durante a leitura dos arquivos de configuração, a variável BBFILES será populada
com as receitas e arquivos de append existentes nas camadas habilitadas.

As receitas e arquivos de append serão lidos, um a um, e uma lista de tarefas será
definida para cada receita, incluindo as dependências entre elas.

Por fim, o BitBake processa a tarefa build da receita passada (core-image-minimal.bb


no nosso exemplo), o que causa a execução de todas as suas dependências, até que a
imagem final da distribuição seja gerada.

O processo completo está descrito de forma detalhada no manual do BitBake.

https://docs.yoctoproject.org/bitbake/index.html
GRÁFICO DE DEPENDÊNCIAS
O BitBake é capaz de gerar um gráfico de dependências no formato dot com o
parâmetro -g.
$ bitbake -g core-image-minimal

$ ls *.dot

task-depends.dot

O arquivo gerado pode ser convertido em uma imagem ou aberto diretamente com
um leitor de arquivos dot:
$ dot -Tps task-depends.dot -o task-depends.ps

$ xdot task-depends.dot

O BitBake também é capaz de exibir o gráfico de dependências com uma ferramenta


gráfica (Task Dependency Explorer):
$ bitbake -g core-image-minimal -u taskexp
IMAGEM DO GRÁFICO DE DEPENDÊNCIAS
TASK DEPENDENCY EXPLORER
LABORATÓRIO 2

EXPLORANDO O SISTEMA DE BUILD


YOCTO PROJECT

CAMADAS
CAMADAS
O OpenEmbedded/Yocto Project suporta a organização dos metadados em camadas
(layers).

As camadas permitem isolar as customizações do sistema, tornando o


desenvolvimento muito mais modular e fácil de manter.

No Yocto Project, uma distribuição Linux é gerada através da combinação de


camadas.

A comunidade do OpenEmbedded mantém uma base de dados bem completa de


camadas existentes.

https://layers.openembedded.org/layerindex/branch/master/layers/
ORGANIZAÇÃO DAS CAMADAS
As camadas são organizadas em diretórios no sistema de build.

O diretório da camada pode ter qualquer nome, porém o padrão adotado é iniciar
com meta.

O Poky já vem com algumas camadas:


$ ls -d meta*

meta meta-poky meta-selftest meta-skeleton meta-yocto-bsp

Uma distribuição construída com o Yocto Project irá utilizar as camadas do Poky,
além de outras camadas providas pela comunidade e camadas específicas do
projeto.
CRIANDO UMA CAMADA
Primeiro crie um diretório para a camada:
$ mkdir meta-labworks

Dentro do diretório da camada, crie o arquivo de configuração da camada


(conf/layer.conf):
$ cd meta-labworks

$ mkdir conf

$ vim conf/layer.conf

Para facilitar o trabalho, podemos nos basear em arquivos de configuração de outras


camadas e alterá-los conforme a necessidade.
LAYER.CONF
BBPATH .= ":${LAYERDIR}"

BBFILES += " \

${LAYERDIR}/recipes-*/*/*.bb \

${LAYERDIR}/recipes-*/*/*.bbappend \

"

BBFILE_COLLECTIONS += "meta-labworks"

BBFILE_PATTERN_meta-labworks = "^${LAYERDIR}/"

BBFILE_PRIORITY_meta-labworks = "6"

LAYERVERSION_meta-labworks = "1"

LAYERDEPENDS_meta-labworks = "core"

LAYERSERIES_COMPAT_meta-labworks = "kirkstone"
EXPLICANDO O LAYER.CONF
A variável BBPATH deve ser definida para que o BitBake possa encontrar arquivos na
camada (arquivos de configuração, classes, outros arquivos incluídos com as
diretivas include e require, etc).
BBPATH .= ":${LAYERDIR}"

A variável BBFILES deve incluir os caminhos dos arquivos de receita da camada.


BBFILES += " \

${LAYERDIR}/recipes-*/*/*.bb \

${LAYERDIR}/recipes-*/*/*.bbappend \

"

O nome da camada deve ser adicionado à variável BBFILE_COLLECTIONS.


BBFILE_COLLECTIONS += "meta-labworks"
EXPLICANDO O LAYER.CONF (CONF.)
A variável BBFILE_PATTERN deve conter uma expressão regular, que será utilizada
para encontrar os arquivos de receita da camada.
BBFILE_PATTERN_meta-labworks = "^${LAYERDIR}/"

A variável BBFILE_PRIORITY define a prioridade da camada (utilizada pelo BitBake


para decidir qual receita utilizar quando a mesma receita é definida em múltiplas
camadas).
BBFILE_PRIORITY_meta-labworks = "6"
EXPLICANDO O LAYER.CONF (CONF.)
A variável LAYERVERSION define a versão da camada.
LAYERVERSION_meta-labworks = "2"

A variável LAYERDEPENDS define as dependências da camada, gerando um erro caso


as camadas de dependência não sejam encontradas.
LAYERDEPENDS_meta-labworks = "core"

A variável LAYERSERIES_COMPAT permite definir a compatibilidade da camada com


os releases do Yocto Project.
LAYERSERIES_COMPAT_meta-labworks = "kirkstone"
ADICIONANDO CONTEÚDO
Após a criação do arquivo de configuração, o próximo passo é adicionar conteúdo à
camada:
Se a camada possuir receitas, estas são normalmente adicionadas em
subdiretórios começando com recipes-.

Se for uma camada de distribuição, os arquivos de configuração são definidos


em conf/distro/.

Se for uma camada de BSP, adicione os arquivos de configuração das machines


em conf/machine/.

É comum a existência de um arquivo de licença (ex: COPYING.MIT), além de um


README descrevendo o conteúdo da camada, incluindo uma lista de dependências,
mantenedor, instruções de uso, etc.
META-LABWORKS
$ tree meta-labworks/

meta-labworks/

├── conf

│ └── layer.conf

├── COPYING.MIT

└── README
HABILITANDO A CAMADA
Para habilitar a camada, basta adicioná-la à variável BBLAYERS no arquivo
conf/bblayers.conf:
BBLAYERS ?= " \

/home/sprado/yocto/poky/meta \

/home/sprado/yocto/poky/meta-yocto \

/home/sprado/yocto/poky/meta-yocto-bsp \

/home/sprado/yocto/poky/meta-labworks \

"
BITBAKE-LAYERS
$ bitbake-layers -h

usage: bitbake-layers [-d] [-q] [-F] [--color COLOR] [-h] <subcommand> ...

...

subcommands:

<subcommand>

add-layer Add one or more layers to bblayers.conf.

remove-layer Remove one or more layers from bblayers.conf.

flatten flatten layer configuration into a separate output directory.

show-layers show current configured layers.

show-overlayed list overlayed recipes (where the same recipe exists in another layer)

show-recipes list available recipes, showing the layer they are provided by

show-appends list bbappend files and recipe files they apply to

show-cross-depends Show dependencies between recipes that cross layer boundaries.

layerindex-fetch Fetches a layer from a layer index along with its dependent layers

layerindex-show-depends

Find layer dependencies from layer index.

create-layer Create a basic layer

Use bitbake-layers <subcommand> --help to get help on a specific command


BITBAKE-LAYERS: EXIBINDO AS CAMADAS
$ bitbake-layers show-layers

layer path priority

==========================================================================

meta /opt/labs/ex/layers/poky/meta 5

meta-poky /opt/labs/ex/layers/poky/meta-poky 5

meta-yocto-bsp /opt/labs/ex/layers/poky/meta-yocto-bsp 5
BITBAKE-LAYERS: CRIANDO CAMADAS
$ bitbake-layers create-layer --priority 10 ../layers/meta-labworks

Add your new layer with 'bitbake-layers add-layer ../layers/meta-labworks'

$ tree ../layers/meta-labworks/

../layers/meta-labworks/

├── conf

│ └── layer.conf

├── COPYING.MIT

├── README

└── recipes-example

└── example

└── example_0.1.bb

$ bitbake-layers add-layer ../layers/meta-labworks

$ bitbake-layers show-layers

layer path priority

==========================================================================

meta /opt/labs/ex/layers/poky/meta 5

meta-poky /opt/labs/ex/layers/poky/meta-poky 5

meta-yocto-bsp /opt/labs/ex/layers/poky/meta-yocto-bsp 5

meta-labworks /opt/labs/ex/layers/meta-labworks 10
DYNAMIC LAYERS
Para utilizar uma camada com metadados que dependem de outra camada
(arquivos de configuração, receitas de append, etc), é necessário baixar todas as
dependências para a camada funcionar.
Por exemplo, o usuário de uma camada de BSP que contém receitas de append
de aplicações gráficas precisará baixar a camada que contém as receitas de
aplicações gráficas, mesmo que sua distribuição não utilize estas aplicações.

Neste caso, a funcionalidade de dynamic layers pode ser utilizada para habilitar o
processamento condicional de metadados.

Uma camada dinâmica pode ser habilitada através da variável BBFILES_DYNAMIC no


arquivo de configuração da camada.
EXEMPLO: DYNAMIC LAYERS
$ tree -L 2 meta-oe/dynamic-layers/meta-python/recipes-core

meta-oe/dynamic-layers/meta-python/recipes-core

└── packagegroups

└── packagegroup-meta-oe.bbappend

$ tree -L 2 meta-oe/dynamic-layers/perl-layer/recipes-core/

meta-oe/dynamic-layers/perl-layer/recipes-core/

└── packagegroups

└── packagegroup-meta-oe.bbappend

# meta-oe/conf/layer.conf

...

BBFILES_DYNAMIC += " \

meta-python:${LAYERDIR}/dynamic-layers/meta-python/recipes-*/*/*.bb \
perl-layer:${LAYERDIR}/dynamic-layers/perl-layer/recipes-*/*/*.bb \

"

...
PROGRAMA DE COMPATIBILIDADE
Ao criar uma camada para ser utilizada com o Yocto Project, é vantajoso garantir que
esta camada seja compatível com os padrões do projeto:
Garante uma qualidade mínima aceitável pela comunidade, incluindo
interoperabilidade com outras camadas.

Permite o uso do Yocto Project Compatible Logo.

O processo de "certificação" da camada envolve a execução de um script (yocto-


check-layer) e um registro no site do projeto.

Mais informações sobre este processo no site do projeto em Making Sure Your Layer
is Compatible With Yocto Project.
YOCTO-CHECK-LAYER
$ yocto-check-layer --without-software-layer-signature-check meta-labworks/

INFO: Detected layers:

INFO: meta-training: LayerType.SOFTWARE, /opt/labs/ex/layers/meta-training

INFO:

INFO: Setting up for meta-training(LayerType.SOFTWARE), /opt/labs/ex/layers/meta-training

INFO: Getting initial bitbake variables ...

INFO: Getting initial signatures ...

INFO: Adding layer meta-training

INFO: Starting to analyze: meta-training

INFO: ----------------------------------------------------------------------

INFO: skipped "BSPCheckLayer: Layer meta-training isn't BSP one."

INFO: test_layerseries_compat (common.CommonCheckLayer)

INFO: ... ok

INFO: test_parse (common.CommonCheckLayer)

INFO: ... ok

...

INFO: Ran 7 tests in 435.104s

INFO: OK

INFO: (skipped=3)

INFO:

INFO: Summary of results:

INFO:

INFO: meta-training ... PASS


LABORATÓRIO 3

CRIANDO CAMADAS
YOCTO PROJECT

INTRODUÇÃO ÀS RECEITAS
RECEITAS
Receitas (recipes) são arquivos com extensão .bb, processados pela ferramenta
BitBake para gerar os diversos componentes de software do sistema.

O nome de um arquivo de receita possui normalmente o formato


<name>_<version>.bb. Exemplos:
libdrm_2.4.110.bb

libpng_1.6.37.bb

mmc-utils_git.bb

Para processar uma receita, basta usar a primeira parte do seu nome:
$ bitbake libdrm
PACOTES
O resultado do processamento de uma receita são pacotes (packages).
O Yocto Project suporta três tipos de empacotamento: ipk, deb e rpm.

Os pacotes contém arquivos gerados durante o processamento da receita, agregados


por tipo (-dbg para arquivos de debugging, -doc para documentação, etc).

Uma única receita irá gerar múltiplos pacotes!


$ bitbake -e unzip | grep ^PACKAGES=

PACKAGES="unzip-src unzip-dbg unzip-staticdev unzip-dev unzip-doc unzip-locale unzip"


CRIANDO RECEITAS
Antes de criar uma nova receita, verifique se já não existe algo pronto na base de
dados de receitas do OpenEmbedded.

https://layers.openembedded.org/layerindex/branch/kirkstone/recipes/

O comando bitbake-layers pode ajudar a pesquisar as receitas existentes nas


camadas habilitadas no bblayers.conf:
$ bitbake-layers show-recipes | grep "busybox:" -A 1

busybox:

meta 1.35.0

Caso precise criar uma nova receita, outras receitas podem ser utilizadas como
ponto de partida.

Existem ferramentas que podem auxiliar na criação de receitas (recipetool e devtool).


Estudaremos sobre estas ferramentas mais adiante no treinamento.
ESTRUTURA DE UMA RECEITA
Uma receita é composta basicamente pela definição de tarefas e variáveis.

As tarefas contém as instruções para o processamento da receita (baixar o código-


fonte, descompactar, aplicar patches, configurar, compilar, instalar, empacotar, etc).

As variáveis permitem parametrizar e configurar o comportamento das tarefas (local


do código-fonte, patches a serem aplicados, dependências, flags de compilação,
etc).
SETSERIAL_2.17.BB
SUMMARY = "Controls the configuration of serial ports"

DESCRIPTION = "setserial is a program designed to set and/or report the configuration information ass
HOMEPAGE = "http://setserial.sourceforge.net"

AUTHOR = "Theodore Ts'o <[email protected]>"

SECTION = "console/utils"

LICENSE = "GPLv2.0"

LIC_FILES_CHKSUM = "file://version.h;beginline=1;endline=6;md5=2e7c59cb9e57e356ae81f50f4e4dfd99"

PR = "r3"

DEPENDS += "groff-native"

inherit autotools-brokensep

SRC_URI = "${SOURCEFORGE_MIRROR}/setserial/${BPN}-${PV}.tar.gz \

file://add_stdlib.patch \

file://ldflags.patch \

"

SRC_URI[md5sum] = "c4867d72c41564318e0107745eb7a0f2"

SRC_URI[sha256sum] = "7e4487d320ac31558563424189435d396ddf77953bb23111a17a3d1487b5794a"

do_install() {

install -d ${D}${bindir}
TAREFAS
Tarefa (task) é uma etapa no processamento de uma receita (baixar o código-fonte,
aplicar patches, configurar, compilar, etc).

As tarefas podem ser definidas dentro do arquivo da receita e/ou herdadas através
de uma classe.

Por padrão, todas as receitas herdam automaticamente algumas classes durante seu
processamento, incluindo a classe base.bbclass.

Estas classes definem algumas tarefas comuns em todas as receitas (do_fetch,


do_unpack, do_patch, do_configure, do_compile, etc).
TAREFAS EM UMA RECEITA VAZIA
$ cat ../layers/meta-labworks/recipes-test/empty-recipe/empty-recipe_1.0.bb

LICENSE = "CLOSED"

$ bitbake empty-recipe -c listtasks

...

do_build Default task for a recipe - depends on all other normal tasks
do_checkuri Validates the SRC_URI value

do_clean Removes all output files for a target

do_cleanall Removes all output files, shared state cache, and downloaded so
do_cleansstate Removes all output files and shared state cache for a target

do_compile Compiles the source in the compilation directory

do_configure Configures the source by enabling and disabling any build-time


do_deploy_source_date_epoch

do_deploy_source_date_epoch_setscene (setscene version)

do_devshell Starts a shell with the environment set up for development/debu


do_fetch Fetches the source code

do_install Copies files from the compilation directory to a holding area

do_listtasks Lists all defined tasks for a target

do_package Analyzes the content of the holding area and splits it into sub
do_package_qa Runs QA checks on packaged files

do_package_qa_setscene Runs QA checks on packaged files (setscene version)

do_package_setscene Analyzes the content of the holding area and splits it into sub
do_package_write_rpm Creates the actual RPM packages and places them in the Package
do package write rpm setscene Creates the actual RPM packages and places them in the Package
HERDANDO CLASSES
As tarefas de uma receita podem ser alteradas, substituídas ou extendidas através de
classes (arquivos com extensão .bbclass).

As classes definem tarefas comuns que podem ser reutilizadas por receitas.

Uma classe pode ser utilizada em uma receita através da palavra-chave inherit.
inherit autotools

Uma lista das principais classes existentes está disponível no manual de referência
do Yocto Project.

https://docs.yoctoproject.org/ref-manual/classes.html
IMPLEMENTANDO TAREFAS
Uma receita pode alterar tarefas existentes ou mesmo implementar suas próprias
tarefas.

As tarefas podem ser implementadas em Shell Script ou Python.

Antes de implementar uma tarefa, verifique se já não existe uma classe com a lógica
necessária para o processamento da receita.
SHELL SCRIPT VS PYTHON
As tarefas são normalmente implementadas em Shell Script:
do_install() {

install -d ${D}${bindir}

install -m 0755 main ${D}${bindir}

As tarefas podem também ser implementadas em Python:


python do_showdate() {

import time

print time.strftime('%d/%m/%Y', time.gmtime())

}
ALTERANDO TAREFAS
É possível redefinir uma tarefa existente:
do_compile() {

# instructions to compile here

Ou então adicionar instruções a uma tarefa existente com append ou prepend:


do_configure:prepend() {

# extra configure commands

do_install:append() {

# extra install commands

}
ADICIONANDO TAREFAS
Tarefas podem ser adicionadas a uma receita com a palavra-chave addtask:
do_mkimage() {

# create image here

addtask mkimage

Novas tarefas não são executadas automaticamente por padrão, mas podem ser
executadas manualmente com o parâmetro -c:
$ bitbake myrecipe -c mkimage

Para que uma tarefa nova seja executada automaticamente durante o


processamento de uma receita, é necessário adicioná-la na cadeia de dependências
de tarefas:
addtask mkimage after do_compile before do_install
VARIÁVEIS
Variáveis são utilizadas para parametrizar e definir o comportamento das tarefas
durante o processamento da receita. Exemplos:
A tarefa do_fetch utiliza a variável SRC_URI para identificar a localização do
código-fonte.

A tarefa do_patch utiliza a variável SRC_URI para identificar os patches que


devem ser aplicados no código-fonte.

A tarefa do_populate_lic utiliza a variável LIC_FILES_CHKSUM para validar o


checksum dos arquivos de licença.

Algumas variáveis são geradas automaticamente pelo BitBake quando uma receita é
processada.
VARIÁVEIS GERADAS AUTOMATICAMENTE
Variável Descrição
PN Package name - nome da receita/pacote
PV Package version - versão da receita
PR Package revision - revisão da receita
WORKDIR Diretório de processamento da receita
S Diretório onde o código-fonte é descompactado
B Diretório onde o código-fonte é compilado
D Diretório de instalação dos arquivos gerados na compilação
VARIÁVEIS GERADAS AUTOMATICAMENTE (CONT.)
$ cat ../layers/meta-labworks/recipes-test/empty-recipe/empty-recipe_1.0.bb

LICENSE = "CLOSED"

$ bitbake empty-recipe -e | grep ^PN=

PN="empty-recipe"

$ bitbake empty-recipe -e | grep ^PV=

PV="1.0"

$ bitbake empty-recipe -e | grep ^PR=

PR="r0"

$ bitbake empty-recipe -e | grep ^WORKDIR=

WORKDIR="/opt/labs/ex/build/tmp/work/core2-64-poky-linux/empty-recipe/1.0-r0"

$ bitbake empty-recipe -e | grep ^S=

S="/opt/labs/ex/build/tmp/work/core2-64-poky-linux/empty-recipe/1.0-r0/empty-recipe-1.0"

$ bitbake empty-recipe -e | grep ^B=

B="/opt/labs/ex/build/tmp/work/core2-64-poky-linux/empty-recipe/1.0-r0/empty-recipe-1.0"

$ bitbake empty-recipe -e | grep ^D=

D="/opt/labs/ex/build/tmp/work/core2-64-poky-linux/empty-recipe/1.0-r0/image"
PROCESSAMENTO DE UMA RECEITA
DO_FETCH
A variável SRC_URI é utilizada para definir a localização do código-fonte.
SRC_URI = "https://www.mpfr.org/mpfr-${PV}/mpfr-${PV}.tar.xz"

O código-fonte pode ser obtido de diversas origens, incluindo HTTP, FTP, repositórios
GIT e diretórios locais (veja a documentação do BitBake para uma lista completa de
protocolos suportados).

O código-fonte é baixado para o diretório apontado pela variável DL_DIR.


DO_FETCH (CONT.)
Se o código-fonte for baixado de um servidor remoto, sem usar uma ferramenta de
controle de versão, é necessário prover o hash do arquivo.
SRC_URI = "http://www.libsdl.org/release/SDL2-${PV}.tar.gz"

SRC_URI[sha256sum] = "65be9ff6004034b5b2ce9927b5a4db1814930f169c4b2dae0a1e4697075f287b"

Se o código-fonte estiver disponível no repositório de uma ferramenta de controle de


versão, é necessário definir as variáveis SRCREV e (opcionalmente) PV.
SRC_URI = "git://git.yoctoproject.org/${BPN};branch=master"

SRCREV = "7ad885912efb2131e80914e964d5e635b0d07b40"

PV = "0.3+git${SRCPV}"
DO_UNPACK
O código-fonte será descompactado no diretório definido pela variável S.

Se o código-fonte for baixado de uma ferramenta de controle de versão, é necessário


definir a variável S.
SRC_URI = "git://anongit.freedesktop.org/git/xorg/lib/${XORG_PN};protocol=https"

S = "${WORKDIR}/git"

Uma receita pode ter arquivos locais (ex: patches), providos na variável SCR_URI
através do protocolo file.
SRC_URI = "http://www.mirrorservice.org/sites/lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof_${PV}.
file://lsof-remove-host-information.patch"
DO_UNPACK (CONT.)
Estes arquivos são armazenados junto com os metadados, no diretório da receita, e o
BitBake utiliza a variável FILESPATH para encontrá-los.
$ tree poky/meta/recipes-extended/lsof/

poky/meta/recipes-extended/lsof/

├── files

│ └── lsof-remove-host-information.patch

└── lsof_4.91.bb

$ bitbake lsof -e | grep ^FILESPATH=

Durante a execução da tarefa do_unpack, estes arquivos são copiados para o


WORKDIR da receita.
DO_PATCH
São tratados como patches todos os arquivos definidos na variável SRC_URI com
extensão .patch ou .diff.

Por padrão, será utilizada a opção -p1 para aplicar os patches (este comportamento
pode ser alterado com a opção striplevel).
SRC_URI += "file://0002-llvm-allow-env-override-of-exe-path.patch;striplevel=2"

A opção patchdir permite aplicar o patch a partir de um diretório específico.


SRC_URI += "file://0001-Workaround-for-GCC-11-uninit-variable-warnings-946.patch;patchdir=src"
DO_POPULATE_LIC
A tarefa do_populate_lic é responsável por verificar licenças do software.

A variável LICENSE deve ser utilizada para especificar a licença:


LICENSE = "GPL-2.0-only"

Uma lista com o nome de licenças comuns está disponível no Poky em


meta/files/common-licenses/.

A receita deve conter também a variável LIC_FILES_CHKSUM para garantir que não
houve mudanças no arquivo da licença.
LIC_FILES_CHKSUM = "file://LICENSE;md5=44bc22578be94b6536c8bdc3a01e5db9"
DO_CONFIGURE
É comum as aplicações possuirem um mecanismo de configuração do software antes
de iniciar a compilação (autotools, cmake, etc).

Normalmente, herda-se de uma classe a implementação desta tarefa. Por exemplo,


para compilar um software baseado em autotools:
inherit autotools

No caso do autotools, a variável EXTRA_OECONF pode ser utilizada para passar


opções extras para o script de configuração.
EXTRA_OECONF = "--enable-debug"

Consulte a documentação da classe que está utilizando para mais informações.


DO_COMPILE
Da mesma forma que a tarefa de configuração, normalmente herda-se de uma classe
a implementação da tarefa de compilação.

Por exemplo, para compilar um software baseado em CMake:


inherit cmake

Se necessário, é possível definir uma tarefa de compilação customizada:


do_compile() {

${CC} test.c -o test

As variáveis EXTRA_OEMAKE e EXTRA_OECMAKE podem ser usadas para passar


comandos extras para as ferramentas make e cmake, respectivamente.
DO_INSTALL
Assim como as tarefas de configuração e compilação, normalmente herda-se de uma
classe a implementação da tarefa do_install.

Se necessário, é possível definir e implementar uma tarefa de instalação


customizada.

É possível também complementar a instalação definindo a tarefa do_install:append.


do_install:append() {

install -d ${D}/${libdir}/pkgconfig

install -m 0644 ${B}/src/libgcrypt.pc ${D}/${libdir}/pkgconfig/

A instalação é realizada no diretório apontado pela variável D, que por padrão


contém ${WORKDIR}/image.
DO_PACKAGE
O objetivo desta tarefa é empacotar os diversos componentes de software
(executáveis, bibliotecas, documentação, etc) gerados durante o processamento da
receita.
$ bitbake libpcap -e | grep ^PACKAGES=

PACKAGES="libpcap-src libpcap-dbg libpcap-staticdev libpcap-dev libpcap-doc libpcap-locale libpcap

Para isso, os componentes lógicos do software gerados durante o processamento da


receita são divididos em diretórios em ${WORKDIR}/packages-split.
$ ls -1 tmp/work/cortexa9t2hf-neon-poky-linux-gnueabi/libpcap/1.10.1-r0/packages-split/

libpcap

libpcap-dbg

libpcap-dev

libpcap-doc

libpcap-locale

libpcap-src

libpcap-staticdev
DO_PACKAGE (CONT.)
A variável FILES é utilizada para o BitBake saber em qual pacote colocar cada arquivo
gerado:
$ bitbake libpng -e | grep ^FILES\:

FILES:libpng="/usr/bin/* /usr/sbin/* /usr/libexec/* /usr/lib/lib*.so.* /etc /com /var /bin/* /sbin/* /


FILES:libpng-dev="/usr/include /lib/lib*.so /usr/lib/lib*.so /usr/lib/*.la /usr/lib/*.o"

FILES:libpng-doc="/usr/share/doc /usr/share/man /usr/share/info /usr/share/gtk-doc /usr/share/gnome/he


FILES:libpng-locale="/usr/share/locale"

FILES:libpng-src=""

FILES:libpng-staticdev="/usr/lib/*.a /lib/*.a /usr/lib/libpng/*.a"

FILES:libpng-tools="/usr/bin/png-fix-itxt /usr/bin/pngfix /usr/bin/pngcp"

Os pacotes finais para instalação no target são gerados em ${WORKDIR}/deploy-rpms.


$ ls tmp/work/cortexa9t2hf-neon-poky-linux-gnueabi/libpcap/1.10.1-r0/deploy-rpms/cortexa9t2hf_neon/

libpcap1-1.10.1-r0.cortexa9t2hf_neon.rpm libpcap-dev-1.10.1-r0.cortexa9t2hf_neon.rpm

libpcap-src-1.10.1-r0.cortexa9t2hf_neon.rpm libpcap-dbg-1.10.1-r0.cortexa9t2hf_neon.rpm

libpcap-doc-1.10.1-r0.cortexa9t2hf_neon.rpm libpcap-staticdev-1.10.1-r0.cortexa9t2hf_neon.rpm
DIRETÓRIO DE PROCESSAMENTO DAS RECEITA
$ ls -1 tmp/work/core2-64-poky-linux/libpcap/1.10.1-r0/

build

configure.sstate

debugsources.list

deploy-rpms

deploy-source-date-epoch

image

libpcap-1.10.1

libpcap.spec

license-destdir

package

packages-split

pkgdata

pkgdata-pdata-input

pkgdata-sysroot

pseudo

recipe-sysroot

recipe-sysroot-native

source-date-epoch

sysroot-destdir

temp
LOGS DE PROCESSAMENTO
$ ls tmp/work/core2-64-poky-linux/libpcap/1.10.1-r0/temp/

depsig.do_deploy_source_date_epoch run.do_unpack

depsig.do_deploy_source_date_epoch.2949190 run.do_unpack.2949177

depsig.do_package run.emit_pkgdata.3006016

depsig.do_package.3006016 run.extend_recipe_sysroot.2947221

depsig.do_packagedata run.extend_recipe_sysroot.2949182

depsig.do_packagedata.3006753 run.extend_recipe_sysroot.3001129

depsig.do_package_qa run.extend_recipe_sysroot.3001312

depsig.do_package_qa.3006796 run.extend_recipe_sysroot.3005808

depsig.do_package_write_rpm run.extend_recipe_sysroot.3006016

depsig.do_package_write_rpm.3006795 run.extend_recipe_sysroot.3006017

depsig.do_populate_lic run.extend_recipe_sysroot.3006795

depsig.do_populate_lic.2949191 run.extend_recipe_sysroot.3006796

depsig.do_populate_sysroot run.fixup_perms.3006016

depsig.do_populate_sysroot.3006017 run.package_convert_pr_autoinc.3006016

log.do_compile run.packagedata_translate_pr_autoinc.3006753

log.do_compile.3005561 run.package_depchains.3006016

log.do_configure run.package_do_filedeps.3006016

log.do_configure.3001312 run.package_do_pkgconfig.3006016

log.do_deploy_source_date_epoch run.package_do_shlibs.3006016

log.do_deploy_source_date_epoch.2949190 run.package_do_split_locales.3006016

log.do_fetch run.package_fixsymlinks.3006016

log.do_fetch.2947221 run.package_get_auto_pr.3006753

log.do install run.package name hook.3006016


MODELO DE RECEITA
DESCRIPTION = ""

HOMEPAGE = ""

SECTION = ""

LICENSE = ""

LIC_FILES_CHKSUM = ""

SRC_URI = ""

SRC_URI[sha256sum] = ""

DEPENDS = ""

inherit <some_class>
EXEMPLO 1: HELLO.C
DESCRIPTION = "Hello World application"

HOMEPAGE = "git://mygitserver.com/hello.git"

SECTION = "tests"

LICENSE = "MIT"

LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=7363621101019373746565758497289305"

SRC_URI = "git://mygitserver.com/hello.git;protocol=https;branch=main"

SRCREV = "6a4be9e9946df310d9402f995f371c7deb8c27ba"

S = "${WORKDIR}/git"

TARGET_CC_ARCH += "${LDFLAGS}"

do_compile() {

${CC} hello.c -o hello

do_install() {

install -d ${D}${bindir}

install -m 0755 hello ${D}${bindir}

}
EXEMPLO 2: AUTOTOOLS
SUMMARY = "GNU Hello World application"

HOMEPAGE = "https://hello.gnu.org"

SECTION = "tests"

LICENSE = "GPL-2.0-or-later"

LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"

SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"

SRC_URI[sha256sum] = "d21b2d1fd78c1efbe1f2c16dae1cb23f8fd231dcf891465b8debe636a9054b0c"

DEPENDS = "zlib"

inherit autotools

EXTRA_OECONF = "--enable-debug"
EXEMPLO 3: AUTOTOOLS
SUMMARY = "X11 Code Viewer"

DESCRIPTION = "Allow viewing of X11 code in a fancy way which allows easier \

and more productive X11 programming"

AUTHOR = "John Bazz <[email protected]>"

HOMEPAGE = "http://www.example.org/xcv/"

SECTION = "x11/applications"

LICENSE = "GPL-2.0"

DEPENDS = "libsm libx11 libxext libxaw"

PV = "0.9+git${SRCPV}"

# upstream does not yet publish any release so we have to fetch last working version from GIT

SRCREV = "6a5e79ae8a0f4a273a603b2df1742972510d3d8f"

SRC_URI = "git://xcv.example.org/xcv;protocol=http \

file://toolbar-resize-fix.patch"

S = "${WORKDIR}/xcv/"

inherit autotools

do_configure:prepend() {

rm ${S}/aclocal.m4

do install() {
PADRÃO DE RECEITAS
Existe um guia de estilo de receitas oficial do OpenEmbedded.

https://www.openembedded.org/wiki/Styleguide

A idéia é que as receitas sigam o mesmo padrão de codificação, facilitando a leitura e


manutenção.

O guia de estilos padroniza a formatação do código, a organização das variáveis e a


ordem de declaração das tarefas em uma receita.
LABORATÓRIO 4

DESENVOLVENDO RECEITAS
YOCTO PROJECT

CONCEITOS AVANÇADOS DE RECEITAS


BITBAKE E VARIÁVEIS
Durante o processamento de uma receita, o BitBake faz a análise (parsing) de todas
as variáveis definidas em arquivos de configuração, arquivos de classe, receitas e
arquivos de append.

Durante esta análise, atribuições na mesma variável podem acontecer em diferentes


arquivos do sistema de build.

Por este motivo, é importante conhecer a sintaxe do BitBake ao atribuir um valor a


uma variável.
ATRIBUIÇÃO
O operador = realiza a atribuição à variável no momento em que encontrar a
atribuição (hard assignment).
VAR = "value"

O operador ?= realiza a atribuição à variável no momento em que encontrar a


atribuição, caso ainda não esteja definida (soft assignment).
VAR ?= "value"

O operador ??= realiza a atribuição à variável no final do processo de análise


(parsing), caso ainda não esteja definida (weak assignment).
VAR ??= "value"
EXPANSÃO
O operador ${} possibilita expandir uma variável dentro de outra variável.

Usando o operador = a expansão só acontece no momento da utilização da variável.


VAR1 = "A"

VAR2 = "${VAR1} B"

VAR1 = "C"

Usando o operador := a expansão acontece no momento da atribuição.


VAR1 = "A"

VAR2 := "${VAR1} B"

VAR1 = "C"
CONCATENAÇÃO
O operador += pode ser usado para concatenar no final de uma variável (append), e o
operador =+ para concatenar no começo de uma variável (prepend).
VAR = "1"

VAR =+ "0"

VAR += "2"

Os operadores "+=" e "=+" adicionam um espaço na concatenação.

Use os operadores ".=" e "=." para concatenar sem adicionar espaços.


VAR = "1"

VAR =. "0 "

VAR .= " 2"


CONCATENAÇÃO (CONT.)
A concatenação também pode ser feita adicionando :append e :prepend às variáveis.
VAR = "1"

VAR:prepend = "0 "

VAR:append = " 2"

Assim como os operadores .= e =., espaços não são adicionados automaticamente.

Mas diferentemente dos operadores .= e =., usando este método a atribuição


acontece somente no final do processo de análise (parsing).
REMOÇÃO
Para remover um valor de uma variável, basta adicionar :remove ao nome da
variável:
VAR = "1 2 1 3"

VAR:remove = "1"

O resultado final será:


VAR = "2 3"

Todas as ocorrências da string são removidas.

Os espaços extras ao redor da string também são removidos.


OVERRIDES
O BitBake provê um mecanismo chamado overrides para definir variáveis de forma
condicional.

Uma variável chamada OVERRIDES contém valores separados por dois-pontos (:).

Estes valores podem ser usados para condicionar o valor de uma variável.
OVERRIDES (CONT.)
No exemplo abaixo, qual será o valor da variável VAR após o parsing das atribuições?
OVERRIDES = "linux-gnueabi:arm:armv7a:mx6:mx6dl:colibri-imx6:poky"
VAR = "1"

VAR:mx6 = "2"

VAR:ppc = "3"

É possível também concatenar de forma condicional usando append ou prepend.


VAR:append:mx6 = " 4"
SINTAXE ANTIGA DE OVERRIDES
O uso do caracter : para fazer atribuição condicional via OVERRIDES é recente,
adotado por padrão a partir do release 3.4 (honister).

Antes deste release, usava-se o caractere _.


VAR_mx6 = "1"

VAR_append_mx6 = " 2"

Mais informações sobre esta mudança estão disponíveis no Release Migration Guide
do Yocto Project.
ARQUIVOS DE APPEND
Arquivos do tipo append possuem a extensão .bbappend e possibilitam modificar o
comportamento de uma receita sem alterar sua implementação original.

Podem ser utilizados para aplicar patches, customizar flags de compilação, instalar
arquivos adicionais, etc; flexibilizando bastante a manutenção dos metadados da
distribuição.

O funcionamento é bem simples: o conteúdo de um arquivo de append é


concatenado no final do conteúdo da receita, possibilitando redefinir tarefas e
variáveis, e consequentemente alterando o comportamento da receita original.
CRIANDO ARQUIVOS DE APPEND
Imagine que você queira alterar o comportamento da receita do programa json-c
disponível na camada OpenEmbedded-Core:
$ ls poky/meta/recipes-devtools/json-c/json-c_0.15.bb

O primeiro passo é criar a mesma estrutura de diretórios na sua camada:


$ mkdir -p meta-labworks/recipes-devtools/json-c/

E dentro do diretório criado, implemente a receita de append (o caractere % indica


que o append serve para qualquer versão da receita):
$ vim meta-labworks/recipes-devtools/json-c/json-c_%.bbappend
CONTEÚDO DE UMA RECEITA DE APPEND
Em uma receita de append é possível:
Definir novas tarefas, redefinir tarefas existentes, concatenar comandos às
tarefas.

Definir novas variáveis, redefinir variáveis existentes, contatenar valores às


variáveis.

É comum o uso da variável FILESEXTRAPATHS no arquivo de append.

Esta variável permite adicionar o diretório da receita de append nos caminhos de


busca do BitBake (FILESPATH).
FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
EXEMPLO 1: ALSA-LIB_%.BBAPPEND
FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"

IMX_PATCH = " \

file://0001-add-conf-for-multichannel-support-in-imx.patch \

file://0005-add-ak4458-conf-for-multichannel-support.patch \

file://0006-add-conf-for-iMX-XCVR-sound-card.patch \

"

SRC_URI:append:imx-nxp-bsp = "${IMX_PATCH}"

PACKAGE_ARCH:imx-nxp-bsp = "${MACHINE_SOCARCH}"
EXEMPLO 2: IPROUTE2_%.BBAPPEND
do_install:append () {

install -d ${D}/usr/include/tc

cp -a ${B}/include ${D}/usr/include

cp -a ${B}/tc/*.h ${D}/usr/include/tc

}
EXEMPLO 3: MTD-UTILS_%.BBAPPEND
FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"

SRC_URI:append = " file://ubihealthd.service"

inherit systemd

SYSTEMD_PACKAGES = "${PN}"

SYSTEMD_SERVICE:${PN} = "ubihealthd.service"

SYSTEMD_AUTO_ENABLE = "disable"

do_install:append() {

install -d ${D}${systemd_unitdir}/system

install -m 0644 ${WORKDIR}/ubihealthd.service ${D}${systemd_unitdir}/system/

sed -i -e 's,@SBINDIR@,${sbindir},g' \

-e 's,@SYSCONFDIR@,${sysconfdir},g' \

${D}${systemd_unitdir}/system/*.service

}
INSPECIONANDO APPENDS
O comando bitbake-layers pode ser utilizado para listar as receitas de append
existentes:

$ bitbake-layers show-appends

alsa-lib_1.2.1.2.bb:

/opt/labs/ex/layers/meta-freescale/recipes-multimedia/alsa/alsa-lib_%.bbappend

alsa-state.bb:

/opt/labs/ex/layers/meta-freescale-3rdparty/recipes-bsp/alsa-state/alsa-state.bbappend

/opt/labs/ex/layers/meta-freescale/recipes-bsp/alsa-state/alsa-state.bbappend

/opt/labs/ex/layers/meta-toradex-nxp/recipes-bsp/alsa-state/alsa-state.bbappend

base-files_3.0.14.bb:

/opt/labs/ex/layers/meta-lmp/meta-lmp-base/recipes-core/base-files/base-files_%.bbappend

/opt/labs/ex/layers/meta-toradex-torizon/recipes-core/base-files/base-files_%.bbappend

base-passwd_3.5.29.bb:

/opt/labs/ex/layers/meta-toradex-torizon/recipes-core/base-passwd/base-passwd_3.5.29.bbappend

bind_9.11.32.bb:

/opt/labs/ex/layers/meta-virtualization/recipes-core/bind/bind_%.bbappend

busybox_1.31.1.bb:

/opt/labs/ex/layers/meta-yocto/meta-poky/recipes-core/busybox/busybox_%.bbappend

/opt/labs/ex/layers/meta-virtualization/recipes-core/busybox/busybox_%.bbappend

/opt/labs/ex/layers/meta-security/recipes-core/busybox/busybox_%.bbappend

/opt/labs/ex/layers/meta-lmp/meta-lmp-base/recipes-core/busybox/busybox_%.bbappend

...
INCLUDE E REQUIRE
O BitBake permite que receitas incluam arquivos com as diretivas include e require.
No caso da diretiva include, se o arquivo não for encontrado, o processamento
continua normalmente.

No caso da diretiva require, se o arquivo não for encontrado, acontecerá um erro


no processamento da receita.

Um caso de uso comum destas diretivas é dividir a implementação da receita em


dois arquivos para facilitar sua manutenção.
Código da receita dependente da versão (ex: libmodbus_3.0.6.bb)

Código da receita independente da versão (ex: libmodbus.inc).


INCLUDE E REQUIRE (CONT.)
$ tree meta-openembedded/meta-oe/recipes-extended/libmodbus

meta-openembedded/meta-oe/recipes-extended/libmodbus

├── libmodbus

│   └── Fix-float-endianness-issue-on-big-endian-arch.patch

├── libmodbus_3.0.6.bb

├── libmodbus_3.1.7.bb

└── libmodbus.inc

$ cat meta-openembedded/meta-oe/recipes-extended/libmodbus/libmodbus_3.0.6.bb

require libmodbus.inc

SRC_URI[md5sum] = "c80f88b6ca19cabc4ceffc195ca07771"

SRC_URI[sha256sum] = "046d63f10f755e2160dc56ef681e5f5ad3862a57c1955fd82e0ce036b69471b6"
VARIABLE FLAGS
Variable flags (varflags) é um recurso do BitBake para associar informações extras à
variáveis e tarefas.

No exemplo abaixo, a variável FOO tem duas flags, a e b, com os valores 123 e 456
respectivamente.
FOO[a] = "123"

FOO[b] = "456"

Alguns usos interessantes de varflags incluem habilitar funcionalidades de software


(variável PACKAGECONFIG) e controlar a execução de tarefas (desabilitar, etc).
do_configure[noexec] = "1"

Mais informações estão disponíveis no manual do BitBake.


PACKAGECONFIG
A variável PACKAGECONFIG é utilizada como mecanismo de habilitação de
funcionalidades em receitas (via recurso de varflags do BitBake).

A receita define as funcionalidades que podem ser habilitadas:


PACKAGECONFIG ??= ""

PACKAGECONFIG[f1] = "\

--with-f1, \

--without-f1, \

build-deps-for-f1, \

runtime-deps-for-f1, \

runtime-recommends-for-f1, \

packageconfig-conflicts-for-f1"

PACKAGECONFIG[f2] = "..."

Um arquivo de append pode ser utilizado para habilitar as funcionalidades


desejadas:
PACKAGECONFIG:append = " f1"
PACKAGECONFIG (CONT.)
Por exemplo, a receita apache2_2.4.53.bb define as seguintes opções de
configuração:
$ cat meta-webserver/recipes-httpd/apache2/apache2_2.4.53.bb | grep PACKAGECONFIG

PACKAGECONFIG ?= "${@bb.utils.filter('DISTRO_FEATURES', 'selinux', d)}"

PACKAGECONFIG[selinux] = "--enable-selinux,--disable-selinux,libselinux,libselinux"

PACKAGECONFIG[openldap] = "--enable-ldap --enable-authnz-ldap,--disable-ldap --disable-authnz-ldap


PACKAGECONFIG[zlib] = "--enable-deflate,,zlib,zlib"

Um arquivo de append pode ser criado para habilitar as funcionalidades desejadas:


# cat meta-labworks/recipes-httpd/apache2/apache2_%.bbappend

PACKAGECONFIG:append = " zlib"


VERSIONAMENTO DE PACOTES
As variáveis PV, PE e PR compõem o versionamento dos pacotes gerados pela receita.

PV (Package Version) representa a versão do pacote, lido normalmente do nome da


receita (ex: pciutils_3.7.0.bb).

PE (Package Epoch) é por padrão vazia, mas deve ser usada caso o esquema de
versionamento do pacote seja alterado.

PR (Package Revision) contém r0 por padrão, mas deve ser modificada caso haja
alteração na receita.
BITBAKE -S
$ bitbake -s

Recipe Name Latest Version Preferred Version

=========== ============== =================

...

liburi-perl-native :5.08-r0
libusb1 :1.0.24-r0
libusb1-native :1.0.24-r0
libuv :1.42.0-r0
libuv-native :1.42.0-r0
libva :2.12.0-r0
libva-initial :2.12.0-r0
libva-utils :2.12.0-r0
libvorbis :1.3.7-r0
libwebp :1.2.1-r0
libwpe :1.10.1-r0
libx11 1:1.7.2-r0
libx11-native 1:1.7.2-r0
libxau 1:1.0.9-r0
libxau-native 1:1.0.9-r0
libxcb :1.14-r0
libxcb-native :1.14-r0
libxcomposite 1:0.4.5-r0
libxcomposite-native 1:0.4.5-r0
VERSÕES E PRIORIDADES
Se existir mais de uma versão da mesma receita, por padrão o BitBake seleciona a
versão mais recente.

Se as receitas estiverem em camadas com prioridades diferentes (BBFILE_PRIORITY),


a receita na camada de maior prioridade é selecionada.

A variável PREFERRED_VERSION pode ser usada em um arquivo de configuração para


determinar a versão desejada.
PREFERRED_VERSION_gtk+ ?= "2.13.3"
VERSÕES E PRIORIDADES (CONT.)
Uma receita pode usar a variável DEFAULT_PREFERENCE para definir sua prioridade
(0 por padrão, e quanto maior, mais prioritária).
DEFAULT_PREFERENCE = "-1"

Na dúvida sobre qual versão será selecionada, verifique com bitbake -e:
$ bitbake busybox -e | grep ^PV=

PV="1.34.1"
INSPECIONANDO AS VERSÕES
O comando bitbake-layers pode ser utilizado para inspecionar as versões de receitas
existentes em múltiplas camadas:
$ bitbake-layers show-overlayed

podman:

meta-toradex-torizon 3.4.1+gitAUTOINC+a6493ae690

meta-virtualization 2.0.1+gitAUTOINC+a11c4ead10

python3-colorama:

meta-virtualization 0.3.9

meta-python 0.4.3

python3-docker:

meta-lmp-base 4.2.1

meta-virtualization 4.2.0

python3-docker-compose:

meta-lmp-base 1.26.0

meta-virtualization 1.25.4

python3-scapy:

meta-security 2.4.3

meta-python 0.25

python3-websocket-client:

meta-virtualization 0.57.0

meta-python 0.56.0

...
DEPURANDO RECEITAS
Diversas técnicas podem ser utilizadas para depurar problemas em receitas:
Análise dos logs de processamento da receita.

Análise dos logs do BitBake.

Inspeção de variáveis.

Limpeza dos caches de compilação para re-execução de tarefas específicas.

Execução manual de tarefas com o devshell.

Inspeção do conteúdo dos pacotes gerados.

A seção Debugging Tools and Techniques do manual de desenvolvimento do Yocto


Project possui informações detalhadas sobre depuração de receitas.
LOGS DE PROCESSAMENTO
No caso de erro no processamento de uma receita, verifique os logs gerados em
${WORKDIR}/temp:

$ ls -1 temp/log.*

temp/log.do_cleansstate

temp/log.do_cleansstate.2772038

temp/log.do_compile

temp/log.do_compile.2779663

temp/log.do_configure

temp/log.do_configure.2778094

...

$ ls -1 temp/run.*

temp/run.do_configure

temp/run.do_configure.2778094

temp/run.do_fetch

temp/run.do_fetch.2776775

temp/run.do_patch

temp/run.do_patch.2776970

...
LOGS DO BITBAKE
Problemas gerais do BitBake podem ser visualizados com o parâmetro -D, que pode
ser definido múltiplas vezes para aumentar o nível de debug.

$ bitbake -DDD virtual/kernel

DEBUG: Using cache in '/home/sprado/workspace/yocto/training/build/cache/bb_unihashes.dat'

DEBUG: Processing core in collection list

DEBUG: Processing yocto in collection list

DEBUG: Processing yoctobsp in collection list

DEBUG: Processing meta-labworks in collection list

DEBUG: Sanity-checking tuning 'core2-64' (default) features:

DEBUG: m64: IA32e (x86_64) ELF64 standard ABI

DEBUG: core2: Enable core2 specific processor optimizations

Loading cache...DEBUG: Cache: default: Cache dir: /home/sprado/workspace/yocto/training/build/tmp/cac


Loaded 1471 entries from dependency cache.

DEBUG: Target list: ['virtual/kernel']

DEBUG: providers for virtual/kernel are: ['linux-yocto']

DEBUG: selecting /home/sprado/workspace/yocto/training/layers/poky/meta/recipes-kernel/linux/linux-yo


NOTE: selecting linux-yocto to satisfy virtual/kernel due to PREFERRED_PROVIDERS

DEBUG: sorted providers for virtual/kernel are: ['/home/sprado/workspace/yocto/training/layers/poky/m


DEBUG: adding /home/sprado/workspace/yocto/training/layers/poky/meta/recipes-kernel/linux/linux-yocto
DEBUG: Added dependencies ['xz-native', 'bc-native', 'virtual/x86_64-poky-linux-binutils', 'virtual/x
DEBUG: Added runtime dependencies ['kernel-base', 'kernel-image-bzimage'] for /home/sprado/workspace/
NOTE: Resolving any missing task queue dependencies
INSPECIONANDO VARIÁVEIS
Às vezes é necessário inspecionar os valores de variáveis durante o processamento
dos metadados (talvez porque a atribuição que estamos fazendo não está
funcionando conforme o esperado).

Isso pode ser feito com o parâmetro -e do BitBake.


$ bitbake busybox -e | grep ^PV=

PV="1.35.0"

O mesmo resultado pode ser obtido com o comando bitbake-getvar:

$ bitbake-getvar -r busybox --value PV

1.35.0
CACHES E EXECUÇÃO DE TAREFAS
Utilize a opção -c do BitBake para executar uma tarefa específica da receita:
$ bitbake unzip -c compile

Se a tarefa já tiver sido executada, uma nova execução não terá efeito. Para forçar a
execução da tarefa, podemos remover seu cache da compilação.
$ bitbake unzip -c cleansstate && bitbake unzip

Alternativamente, podemos utilizar o parâmetro -f para forçar a execução da tarefa:


$ bitbake -f -c compile unzip && bitbake unzip
DEPURANDO COM O DEVSHELL
A tarefa do_devshell permite abrir um novo terminal para depurar o processamento
de uma receita.
$ bitbake unzip -c devshell

No terminal do devshell, todas as variáveis de ambiente necessárias para a


compilação estarão definidas, possibilitando utilizar diretamente comandos de
compilação (make, cmake, autotools, etc).
$ echo $CC

x86_64-poky-linux-gcc -m64 -march=core2 -mtune=core2 -msse3 -mfpmath=sse -fstack-protector-strong

Dentro do devshell, podemos executar diretamente as tarefas da receita:


$ ../temp/run.do_compile
INSPECIONANDO PACOTES
Às vezes, o processamento de uma receita é executado com sucesso porém o
resultado final não é o desejado.

Por exemplo, a receita é processada, mas os pacotes gerados não contém os


artefatos esperados.

Para analisar estes tipos de problemas, podemos utilizar a ferramenta oe-pkgdata-


util.
OE-PKGDATA-UTIL
$ oe-pkgdata-util

oe-pkgdata-util: error: the following arguments are required: <subcommand>

usage: oe-pkgdata-util [-h] [-d] [-p PKGDATA_DIR] <subcommand> ...

OpenEmbedded pkgdata tool - queries the pkgdata files written out during do_package

options:

-h, --help show this help message and exit

-d, --debug Enable debug output

-p PKGDATA_DIR, --pkgdata-dir PKGDATA_DIR

Path to pkgdata directory (determined automatically if not specified)

subcommands:

lookup-pkg Translate between recipe-space package names and runtime package names

list-pkgs List packages

list-pkg-files List files within a package

lookup-recipe Find recipe producing one or more packages

package-info Show version, recipe and size information for one or more packages

find-path Find package providing a target path

read-value Read any pkgdata value for one or more packages

glob Expand package name glob expression

Use oe-pkgdata-util <subcommand> --help to get help on a specific command


OE-PKGDATA-UTIL (CONT.)
$ oe-pkgdata-util list-pkgs lsof*

lsof

lsof-dbg

lsof-dev

lsof-doc

lsof-src

$ oe-pkgdata-util list-pkg-files lsof

lsof:

/usr/sbin/lsof

$ oe-pkgdata-util find-path /lib/libblkid.so.1

util-linux-libblkid: /lib/libblkid.so.1

$ oe-pkgdata-util lookup-recipe util-linux-libblkid

util-linux

$ oe-pkgdata-util package-info util-linux-libblkid

util-linux-libblkid 2.37.2-r0 util-linux 2.37.2-r0 util-linux-libblkid: 347209


QA CHECKS
Um dos possíveis motivos de erro ao processar uma receita são as checagens de
qualidade (QA checks) do sistema de build.

Ao processar uma receita, o sistema de build irá realizar várias checagens para evitar
problemas comuns, e reportá-los ao desenvolvedor.

Algumas checagens geram mensagens de aviso (warning) e o processamento


acontece com sucesso.

Já outras checagens geram mensagens de erro, falhando o processamento da


receita.
EXEMPLO: QA CHECK
$ bitbake busybox

...

ERROR: busybox-1.34.1-r0 do_package: QA Issue: busybox: Files/directories were installed but not ship
/usr/share

/usr/share/udhcpc

/usr/share/udhcpc/default.script

Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid insta
busybox: 3 installed and not shipped files. [installed-vs-shipped]

ERROR: busybox-1.34.1-r0 do_package: Fatal QA errors found, failing task.


ERROR: Logfile of failure stored in: /home/sprado/workspace/yocto/training/build/tmp/work/core2-64-po
ERROR: Task (/home/sprado/workspace/yocto/training/layers/poky/meta/recipes-core/busybox/busybox_1.34
INFO: Tasks Summary: Attempted 736 tasks of which 735 didn't need to be rerun and 1 failed.

Summary: 1 task failed:

/home/sprado/workspace/yocto/training/layers/poky/meta/recipes-core/busybox/busybox_1.34.1.bb:do_pa
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
TRATANDO ERROS DE QA
Apesar de ser possível ignorar as verificações de QA, quando encontrá-las, é
recomendado procurar entender o motivo e corrigí-lo.

Uma lista de todas as verificações de QA existentes está disponível no manual de


referência do Yocto Project:

https://docs.yoctoproject.org/ref-manual/qa-checks.html

Caso não seja possível ou prático resolver um problema de QA, a variável


INSANE_SKIP pode ser utilizada para desabilitar a checagem.
INSANE_SKIP:${PN} = "installed-vs-shipped"
LABORATÓRIO 5

CUSTOMIZANDO RECEITAS
YOCTO PROJECT

CUSTOMIZAÇÃO DE IMAGENS
CUSTOMIZANDO IMAGENS
Durante o desenvolvimento de uma distribuição Linux com o Yocto Project, será
necessário customizar a imagem final gerada, por diversos motivos:
Adicionar ou remover componentes de software (packages).

Adicionar ou remover arquivos do sistema (arquivos de configuração, shell


scripts, blobs, etc).

Adicionar ou remover usuários e configurar senhas.

Configurar permissões de arquivos e diretórios.

Modificar o tamanho, formato e tipo (ext4, f2fs, btrfs, etc) da imagem final
gerada.

Etc!
ONDE CUSTOMIZAR?
Uma imagem pode ser customizada de diferentes formas:
As alterações podem ser realizadas no arquivo local.conf.

As customizações podem ser realizadas em uma receita de imagem.

As customizações podem ser realizadas em um arquivo de configuração de


distro.
LOCAL.CONF
A forma mais fácil de customizar uma imagem é alterando o local.conf.

Porém, alterar diretamente o local.conf para customizar uma imagem possui


algumas desvantagens:
Não permite qualquer tipo de customização.

A alteração afeta todos os builds que utilizam o local.conf.

Dificulta a manutenção (reuso entre diferentes plataformas, versionamento, etc).

Por este motivo, o local.conf pode ser utilizado para modificações simples e
prototipação, mas seu uso não é recomendado para customizar imagens de
produção.
RECEITAS DE IMAGEM
Receitas de imagem permitem uma maior flexibilidade e controle na customização
da imagem final.

Receitas de imagem são receitas "especiais" que descrevem:


Pacotes que devem ser instalados na imagem.

Customizações que devem ser feitas no rootfs gerado.

Informações e parâmetros para a geração das imagens do sistema operacional


(formato, tipo, tamanho, etc).
RECEITAS DE IMAGEM (CONT.)
Normalmente, as receitas de imagem ficam em um diretório chamado images no
diretório de receitas da camada. Exemplo:
$ ls poky/meta/recipes-core/images/

build-appliance-image core-image-minimal-initramfs.bb

build-appliance-image_15.0.0.bb core-image-minimal-mtdutils.bb

core-image-base.bb core-image-ptest-all.bb

core-image-minimal.bb core-image-ptest-fast.bb

core-image-minimal-dev.bb core-image-tiny-initramfs.bb

Já existem diversas receitas de imagem de exemplo no Yocto Project:

https://docs.yoctoproject.org/ref-manual/images.html

É muito comum a criação de novas receitas de imagem quando trabalhamos com o


Yocto Project.
CORE-IMAGE-MINIMAL.BB
SUMMARY = "A small image just capable of allowing a device to boot."

IMAGE_INSTALL = "packagegroup-core-boot ${CORE_IMAGE_EXTRA_INSTALL}"

IMAGE_LINGUAS = " "

LICENSE = "MIT"

inherit core-image

IMAGE_ROOTFS_SIZE ?= "8192"

IMAGE_ROOTFS_EXTRA_SPACE:append = "${@bb.utils.contains("DISTRO_FEATURES", "systemd", " + 4096", "",


CRIANDO RECEITAS DE IMAGEM
Ao criar uma receita de imagem, podemos nos basear em receitas de imagem
existentes.
Podemos simplesmente copiar uma receita de imagem existente para nossa
camada e customizá-la.

Ou então podemos nos basear em uma receita existente utilizando a diretiva require:
require recipes-core/images/core-image-minimal.bb

E então customizar o conteúdo da imagem utilizando variáveis como IMAGE_INSTALL,


CORE_IMAGE_EXTRA_INSTALL e IMAGE_FEATURES.
CORE-IMAGE-MINIMAL-MTDUTILS.BB
require core-image-minimal.bb

DESCRIPTION = "Small image capable of booting a device with support for the \

Minimal MTD Utilities, which let the user interact with the MTD subsystem in \

the kernel to perform operations on flash devices."

IMAGE_INSTALL += "mtd-utils"
ADICIONANDO PACOTES
As variáveis IMAGE_INSTALL e CORE_IMAGE_EXTRA_INSTALL podem ser utilizadas em
uma receita de imagem para adicionar pacotes à imagem.
IMAGE_INSTALL += "mtd-utils"

Estas variáveis devem ser configuradas com o nome dos pacotes.


Lembre-se que uma receita pode gerar vários pacotes, e os pacotes gerados não
necessariamente terão o mesmo nome usado para processar a receita!
RECEITAS VS PACOTES
$ bitbake pcre

...

NOTE: Tasks Summary: Attempted 717 tasks of which 717 didn't need to be rerun and all succeeded.

$ cat conf/local.conf | grep CORE_IMAGE_EXTRA_INSTALL

CORE_IMAGE_EXTRA_INSTALL += "pcre"

$ bitbake core-image-minimal

...

ERROR: Nothing RPROVIDES 'pcre' (but /opt/labs/ex/layers/poky/meta/recipes-core/images/core-image-min


NOTE: Runtime target 'pcre' is unbuildable, removing...

Missing or unbuildable dependency chain was: ['pcre']

ERROR: Required build target 'core-image-minimal' has no buildable providers.

Missing or unbuildable dependency chain was: ['core-image-minimal', 'pcre']

$ bitbake pcre -e | grep ^PACKAGES=

PACKAGES="libpcrecpp libpcreposix pcregrep pcregrep-doc pcretest pcretest-doc libpcre-ptest

libpcre-src libpcre-dbg libpcre-staticdev libpcre-dev libpcre-doc libpcre-locale libpcre"


LISTANDO OS PACOTES DE UMA IMAGEM
Os pacotes instalados em uma imagem podem ser exibidos através do arquivo de
manifesto da imagem:
$ cat tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.manifest

base-files qemux86_64 3.0.14

base-passwd core2_64 3.5.29

busybox core2_64 1.34.1

busybox-hwclock core2_64 1.34.1

busybox-syslog core2_64 1.34.1

busybox-udhcpc core2_64 1.34.1

eudev core2_64 3.2.10

init-ifupdown qemux86_64 1.0

init-system-helpers-service core2_64 1.60

initscripts core2_64 1.0

initscripts-functions core2_64 1.0

kernel-5.14.15-yocto-standard qemux86_64 5.14.15+git0+edb4dc09c5_f04b30fc15

kernel-module-uvesafb-5.14.15-yocto-standard qemux86_64 5.14.15+git0+edb4dc09c5_f04b30fc15

ldconfig core2_64 2.34

libblkid1 core2_64 2.37.2

libc6 core2_64 2.34

libkmod2 core2_64 29

...
PACKAGE GROUPS
Package groups (grupo de pacotes) permitem agrupar pacotes de software com um
objetivo comum. Exemplos:
Pacotes de software para habilitar um stack gráfico.

Pacotes de software com ferramentas de debugging.

Pacotes de software com as aplicações desenvolvidas pela empresa.

Um package group nada mais é do que uma receita que herda a classe packagegroup
para agrupar pacotes de funcionalidade comum.
LOCALIZAÇÃO DOS PACKAGE GROUPS
Normalmente, os package groups ficam em um diretório chamado packagegroups
no diretório de receitas da camada:
$ ls poky/meta/recipes-core/packagegroups/

nativesdk-packagegroup-sdk-host.bb

packagegroup-base.bb

packagegroup-core-boot.bb

packagegroup-core-buildessential.bb

packagegroup-core-eclipse-debug.bb

packagegroup-core-nfs.bb

packagegroup-core-sdk.bb

packagegroup-core-ssh-dropbear.bb

packagegroup-core-ssh-openssh.bb

packagegroup-core-standalone-sdk-target.bb

packagegroup-core-tools-debug.bb

packagegroup-core-tools-profile.bb

packagegroup-core-tools-testapps.bb

packagegroup-cross-canadian.bb

packagegroup-go-cross-canadian.bb

packagegroup-go-sdk-target.bb

packagegroup-rust-cross-canadian.bb

packagegroup-self-hosted.bb
PACKAGEGROUP-CORE-ECLIPSE-DEBUG.BB
SUMMARY = "Remote debugging tools for Eclipse integration"

inherit packagegroup

RDEPENDS:${PN} = "\

gdbserver \

tcf-agent \

openssh-sftp-server \

"
USANDO PACKAGE GROUPS
Um package group pode ser adicionado a uma imagem normalmente através das
variáveis IMAGE_INSTALL e CORE_IMAGE_EXTRA_INSTALL.

Por exemplo, existe um package group para adicionar suporte ao Weston na imagem:
$ ls poky/meta/recipes-graphics/packagegroups/packagegroup-core-weston.bb

Para instalar este package group na imagem, basta adicioná-lo nas variáveis
IMAGE_INSTALL ou CORE_IMAGE_EXTRA_INSTALL.
IMAGE_INSTALL += "packagegroup-core-weston"
IMAGE FEATURES
As features de imagem permitem habilitar alguma "funcionalidade" na imagem
gerada através das variáveis IMAGE_FEATURES ou EXTRA_IMAGE_FEATURES.

Algumas features de imagem estão diretamente relacionadas à instalação de pacotes


adicionais
IMAGE_FEATURES = "tools-debug"

Enquanto outras vão alterar diretamente o conteúdo da imagem gerada.


IMAGE_FEATURES = "read-only-rootfs"

Documentação das image features existentes:

https://docs.yoctoproject.org/ref-manual/features.html#image-features
IMPLEMENTAÇÃO DAS IMAGE FEATURES
$ cat poky/meta/classes/core-image.bbclass | grep FEATURE_PACKAGES

FEATURE_PACKAGES_weston = "packagegroup-core-weston"

FEATURE_PACKAGES_x11 = "packagegroup-core-x11"

FEATURE_PACKAGES_x11-base = "packagegroup-core-x11-base"

FEATURE_PACKAGES_x11-sato = "packagegroup-core-x11-sato"

FEATURE_PACKAGES_tools-debug = "packagegroup-core-tools-debug"

FEATURE_PACKAGES_eclipse-debug = "packagegroup-core-eclipse-debug"

FEATURE_PACKAGES_tools-profile = "packagegroup-core-tools-profile"

FEATURE_PACKAGES_tools-testapps = "packagegroup-core-tools-testapps"

FEATURE_PACKAGES_tools-sdk = "packagegroup-core-sdk packagegroup-core-standalone-sdk-target"

FEATURE_PACKAGES_nfs-server = "packagegroup-core-nfs-server"

FEATURE_PACKAGES_nfs-client = "packagegroup-core-nfs-client"

FEATURE_PACKAGES_ssh-server-dropbear = "packagegroup-core-ssh-dropbear"

FEATURE_PACKAGES_ssh-server-openssh = "packagegroup-core-ssh-openssh"

FEATURE_PACKAGES_hwcodecs = "${MACHINE_HWCODECS}"

$ cat poky/meta/classes/rootfs-postcommands.bbclass | grep IMAGE_FEATURES


ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains_any("IMAGE_FEATURES", [ 'debug-tweaks', 'empty-ro
ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains_any("IMAGE_FEATURES", [ 'debug-tweaks', 'allow-em
ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains_any("IMAGE_FEATURES", [ 'debug-tweaks', 'allow-ro
ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains_any("IMAGE_FEATURES", [ 'debug-tweaks', 'post-ins
ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("IMAGE_FEATURES", "read-only-rootfs", "read_only_
APPEND:append = '${@bb.utils.contains("IMAGE_FEATURES", "read-only-rootfs", " ro", "", d)}'

SYSTEMD DEFAULT TARGET ?= '${@bb.utils.contains any("IMAGE FEATURES", [ "x11-base", "weston" ], "grap


REMOVENDO PACOTES
A variável PACKAGE_EXCLUDE permite excluir um pacote da imagem. Neste caso, o
processo de build pode falhar caso algum outro pacote dependa dele.

A variável BAD_RECOMMENDATIONS permite remover da imagem final um pacote que


foi instalado através da variável RRECOMMENDS.

A variável NO_RECOMMENDATIONS permite remover da imagem todos os pacotes que


foram instalados através da variável RRECOMMENDS.
ADICIONANDO USUÁRIOS E GRUPOS
As classes useradd e extrausers podem ser utilizadas para adicionar usuários e
grupos à imagem gerada.

O uso da classe useradd é recomendado quando o usuário/grupo a ser criado está


associado a um pacote instalado na imagem.

https://docs.yoctoproject.org/ref-manual/classes.html#useradd-bbclass

O uso da classe extrausers é recomendado no caso do usuário/grupo ser global à


imagem, não associado a nenhum programa/pacote específico.

https://docs.yoctoproject.org/ref-manual/classes.html#extrausers-bbclass
EXEMPLO: USERADD
inherit useradd

USERADD_PACKAGES = "${PN}"

USERADD_PARAM_${PN} = "-d /home/user1 -r -s /bin/bash user1; -d /home/user2 -r -s /bin/bash user2"

GROUPADD_PARAM_${PN} = “group1; group2"

do_install:append () {

install -d -m 755 ${D}${datadir}/user1

install -d -m 755 ${D}${datadir}/user2

chown -R user1 ${D}${datadir}/user1


chown -R user2 ${D}${datadir}/user2

chgrp -R group1 ${D}${datadir}/user1

chgrp -R group2 ${D}${datadir}/user2

FILES_${PN} = "${datadir}/user1/* ${datadir}/user2/*"


EXEMPLO: EXTRAUSERS
inherit extrausers

EXTRA_USERS_PARAMS = "\

useradd -p '' tester; \

groupadd developers; \

userdel nobody; \

groupdel -g video; \

groupmod -g 1020 developers; \

usermod -s /bin/sh tester; \

"
PERMISSÕES DE ARQUIVOS E DIRETÓRIOS
Por padrão, o sistema de build utiliza o arquivo fs-perms.txt armazenado em
poky/meta/files/ para definir as permissões de arquivos e diretórios do rootfs gerado.

É possível alterar este arquivo de configuração de permissões através da variável


FILESYSTEM_PERMS_TABLES.

Isso pode ser necessário caso queira aplicar configurações de permissão globais na
imagem (configurações associadas a uma aplicação devem ser feitas na receita
correspondente).

Esta configuração deve ser realizada em uma camada separada, possivelmente em


um arquivo de configuração de distro.
FS-PERMS.TXT
# This file contains a list of files and directories with known permissions.

# It is used by the packaging class to ensure that the permissions, owners

# and group of listed files and directories are in sync across the system.

# The format of this file

#<path> <mode> <uid> <gid> <walk> <fmode> <fuid> <fgid>

...

# Documentation should always be corrected

${mandir} 0755 root root true 0644 root root

${infodir} 0755 root root true 0644 root root

${docdir} 0755 root root true 0644 root root

${datadir}/gtk-doc 0755 root root true 0644 root root

# Fixup locales

${datadir}/locale 0755 root root true 0644 root root

...
ADICIONANDO ARQUIVOS À IMAGEM
Uma necessidade comum durante a customização de imagens é a adição de arquivos
(blobs, shell scripts, arquivos de configuração, etc).

Se os arquivos em questão estiverem relacionados a um determinado software,


podemos alterar a receita correspondente para adicioná-los à imagem.

Caso os arquivos não estejam associados a nenhum software, podemos criar uma
receita específica para adicioná-los à imagem.
EXEMPLO: ADICIONANDO ARQUIVOS
DESCRIPTION = "Some closed source library from hell"

LICENSE = "CLOSED"

SRC_URI = "http://hell.com/mylib.so;unpack=false"

SRC_URI[sha256sum] = "2ea483c3c4ce87f4a3c851077c3b8ea8e7d5539 8bfb56fa3b0765e65085617bd"

do_install() {

install -d ${D}${libdir}

install -m 0755 ${WORKDIR}/mylib.so ${D}${libdir}

FILES_${PN} = "${libdir}/mylib.so"
POST-INSTALL SCRIPTS
Pacotes podem conter scripts de pós-instalação (post-install), que permitem a
execução de comandos durante sua instalação (durante a geração do rootfs ou em
tempo de execução).

São úteis para preparar o rootfs para determinado pacote (criar diretórios e arquivos
temporários, configurar permissões, alterar arquivos de configuração, etc).

Um script de pós-instalação pode ser definido através da função pkg_postinst:


pkg_postinst:<PACKAGENAME>() {

# commands to execute

Existe também o suporte aos scripts de pre-install, pre-uninstall, e post-uninstall


através das funções pkg_preinst, pkg_prerm e pkg_postrm, respectivamente.
EXEMPLO: POST-INSTALL SCRIPTS
$ cat meta-openembedded/meta-oe/recipes-shells/zsh/zsh_5.8.bb

...

pkg_postinst:${PN} () {

touch $D${sysconfdir}/shells

grep -q "bin/zsh" $D${sysconfdir}/shells || echo /bin/zsh >> $D${sysconfdir}/shells

grep -q "bin/sh" $D${sysconfdir}/shells || echo /bin/sh >> $D${sysconfdir}/shells

$ cat poky/meta/recipes-connectivity/avahi/avahi_0.8.bb

...

pkg_postinst:avahi-daemon () {

if [ -z "$D" ]; then

killall -q -HUP dbus-daemon || true

fi

}
POST-INSTALL NO BOOT
Às vezes, é necessário adiar a execução de um script de pós-instalação até o primeiro
boot do dispositivo.

Útil quando queremos por exemplo que o script de pós-instalação seja executado
diretamente no target.

Isso pode ser feito através da função pkg_postinst_ontarget():


$ cat meta-openembedded/meta-oe/recipes-bsp/nvme-cli/nvme-cli_1.13.bb

...

pkg_postinst_ontarget:${PN}() {

${sbindir}/nvme gen-hostnqn > ${sysconfdir}/nvme/hostnqn

${bindir}/uuidgen > ${sysconfdir}/nvme/hostid

}
ROOTFS_POSTPROCESS_COMMAND
Usado bastante em classes, uma forma fácil de executar um comando após a criação
do rootfs é através da variável ROOTFS_POSTPROCESS_COMMAND.

As funções adicionadas à esta variável são executadas ao final do processo de


geração do rootfs.

Por exemplo, o código abaixo tem o objetivo de alterar a senha do usuário admin :
run_set_admin_pass () {

sed 's%^admin:[^:]*:%admin:$6$3WWbKfr1$4vblknvGr6FcDe:\

%' ${IMAGE_ROOTFS}/etc/shadow \

${IMAGE_ROOTFS}/etc/shadow.new;

mv ${IMAGE_ROOTFS}/etc/shadow.new \

${IMAGE_ROOTFS}/etc/shadow ;"

ROOTFS_POSTPROCESS_COMMAND += " run_set_admin_pass ; "


ALTERANDO O FORMATO DA IMAGEM
A variável IMAGE_FSTYPES pode ser usada para alterar o formato da imagem do
rootfs.
IMAGE_FSTYPES = "ext4"

Uma lista dos tipos de imagens existentes está disponível no guia de referência do
Yocto Project.

https://docs.yoctoproject.org/ref-manual/variables.html#term-IMAGE_TYPES

A variável IMAGE_CMD pode ser utilizada para definir formatos customizados de


imagem (veja poky/meta/classes/image_types.bbclass para mais exemplos):
IMAGE_CMD:jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} --faketime \

--output=${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.jffs2 \
${EXTRA_IMAGECMD}"
ALTERANDO O TAMANHO DA IMAGEM
A variável IMAGE_ROOTFS_SIZE pode ser utilizada para definir o tamanho final do
rootfs (em KBs).
IMAGE_ROOTFS_SIZE = "1048576"

Se a variável IMAGE_ROOTFS_SIZE não for definida, ou se seu valor não for suficiente
para suportar o sistema gerado, o rootfs será gerado através da multiplicação do
tamanho do rootfs pela variável IMAGE_OVERHEAD_FACTOR, que por padrão tem o
valor 1.3, gerando uma image 30% maior que o valor mínimo necessário.

A variável IMAGE_ROOTFS_EXTRA_SPACE pode ser usada para forçar um espaço extra


ao criar a imagem (em KBs).
IMAGE_ROOTFS_EXTRA_SPACE = "524288"
CRIANDO DISTRIBUIÇÕES
Poky é a distribuição de referência utilizada por padrão em builds com o Yocto
Project.

Para ter mais controle sobre a seleção de pacotes, opções de compilação e outras
configurações de baixo nível, podemos criar uma distribuição customizada para a
plataforma alvo.

As distribuições são definidas em arquivos de configuração de distro armazenados


em camadas no diretório conf/distro/.
EXEMPLO: DISTRIBUIÇÃO POKY
$ tree poky/meta-poky/conf/distro/

poky/meta-poky/conf/distro/

├── include

│   ├── gcsections.inc

│   ├── poky-distro-alt-test-config.inc

│   ├── poky-floating-revisions.inc

│   └── poky-world-exclude.inc

├── poky-altcfg.conf

├── poky-bleeding.conf

├── poky.conf

└── poky-tiny.conf
CRIANDO UMA DISTRIBUIÇÃO
Para criar uma distribuição, podemos usar como base os arquivos de configuração
do Poky (poky/meta-poky/conf/distro/poky.conf) ou do OpenEmbedded-Core
(poky/meta/conf/distro/defaultsetup.conf).

Em arquivos de configuração de distro, podemos utilizar diversas variáveis para


customizar a distribuição gerada (TCMODE, DISTRO_NAME, DISTRO_VERSION, TCLIBC,
DISTRO_EXTRA_RRECOMMENDS, etc).

Para utilizar a distribuição, basta configurar a variável DISTRO no local.conf com o


mesmo nome do arquivo de configuração criado para a sua distribuição.
VARIÁVEIS DE UMA DISTRO
Variável Descrição
DISTRO Nome da distribuição
DISTRO_NAME Nome longo da distribuição
DISTRO_VERSION Versão da distribuição
TCMODE Toolchain
TCLIBC Biblioteca C (glibc, musl, newlib, baremetal)
INIT_MANAGER Sistema de inicialização (sysvinit, systemd, mdev-busybox)
VARIÁVEIS DE UMA DISTRO (CONT.)
Variável Descrição
DISTRO_EXTRA_RDEPENDS Adicionar pacotes à imagem
DISTRO_EXTRA_RRECOMMENDS Adicionar pacotes à imagem (caso eles existam)
PREFERRED_VERSION Definir/forçar a versão de um pacote
PACKAGE_CLASSES Tipo de pacote que será utilizado pela
distribuição
DISTROOVERRIDES Overrides específicos da distribuição
MIRRORS/PREMIRRORS Fontes alternativas para download de código-
fonte
DISTRO FEATURES
Distro features permitem controlar as características de software da distribuição:
Habilitam a instalação de pacotes adicionais.

Alteram o comportamento de scripts de configuração.

Distro features são definidas em arquivos de configuração de distro através da


variável DISTRO_FEATURES:
DISTRO_FEATURES = "opengl ppp ipv6 usrmerge"

A lista completa de distro features está disponível no manual de referência do Yocto


Project.

https://docs.yoctoproject.org/ref-manual/features.html#distro-features
PACKAGEGROUP-CORE-FULL-CMDLINE.BB
SUMMARY = "Standard full-featured Linux system"

DESCRIPTION = "Package group bringing in packages needed for a more traditional full-featured Linux s
PR = "r6"

inherit packagegroup

...

RDEPENDS:packagegroup-core-full-cmdline-sys-services = "\

at \

cronie \

logrotate \

${@bb.utils.contains('DISTRO_FEATURES', 'nfs', 'nfs-utils rpcbind', '', d)} \

"
LIBPCAP_1.10.1.BB
SUMMARY = "Interface for user-level network packet capture"

DESCRIPTION = "Libpcap provides a portable framework for low-level network \

monitoring. Libpcap can provide network statistics collection, \

security monitoring and network debugging."

...

PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'bluez5', '', d)} \

${@bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)} \

"

PACKAGECONFIG[bluez5] = "--enable-bluetooth,--disable-bluetooth,bluez5"

PACKAGECONFIG[dbus] = "--enable-dbus,--disable-dbus,dbus"

PACKAGECONFIG[ipv6] = "--enable-ipv6,--disable-ipv6,"

PACKAGECONFIG[libnl] = "--with-libnl,--without-libnl,libnl"

...
RUNTIME PACKAGE MANAGEMENT
Com o Yocto Project, é possível construir uma imagem com suporte a gerenciamento
de pacotes em tempo de execução.

Na máquina de desenvolvimento, podemos criar um repositório de pacotes que


pode ser disponibilizado remotamente através de um servidor WEB para o target.

No target, são instaladas ferramentas de gerenciamento de pacotes:


Responsáveis por manter um banco de dados de pacotes instalados.

Possibilitam a instalação e desistalação de pacotes em tempo de execução.


HABILITANDO PACKAGE MANAGEMENT
Para preparar o target para suportar gerenciamento de pacotes, basta habilitar a
feature de imagem package-management.
IMAGE_FEATURES += "package-management"

Algumas variáveis adicionais podem ser definidas para configurar a localização do


servidor de pacotes (PACKAGE_FEED_URIS, PACKAGE_FEED_ARCHS, etc).

No host, cada vez que pacotes são alterados, é necessário regerar o índice de pacotes
com o comando abaixo:
$ bitbake package-index

Informações mais detalhadas no manual de desenvolvimento do Yocto Project.


TEMPLATE FILES
É comum armazenar em uma camada de distro os arquivos de template do diretório
de build da distribuição (local.conf, bblayers.conf, etc).
$ ls meta-labworks/conf/

bblayers.conf.sample layer.conf local.conf.sample

Através da variável de ambiente TEMPLATECONF, é possível definir a localização


destes arquivos de template durante a configuração do diretório de build:
$ export TEMPLATECONF=$PWD/layers/meta-labworks/conf

$ source layers/poky/oe-init-build-env build-test


DICAS PARA CUSTOMIZAÇÃO
Utilize o local.conf para testes e prototipação, mas centralize as modificações em
uma camada separada, utilizando receitas de imagem e arquivos de configuração de
distro.

Crie receitas de imagem para cada produto a ser desenvolvido.


É comum criar variantes de receitas de imagem para diferentes tipos de build
(debug, produção, etc).

É recomendado criar uma distribuição com as configurações e políticas que servirão


de base para seus produtos.
GERENCIANDO CAMADAS
Procure organizar os metadados em camadas para facilitar a manutenção:
Separe os metadados de BSP, distro e software em camadas diferentes.

Projetos/produtos diferentes podem exigir camadas diferentes.

Metadados mantidos por equipes diferentes podem exigir camadas diferentes.

Nunca misture o código da aplicação com os metadados.

Versione sempre as camadas em repositórios Git.


Ferramentas como repo ou kas podem ajudar no gerenciamento das múltiplas
camadas que irão compor o projeto.
LABORATÓRIO 6

CUSTOMIZANDO IMAGENS
YOCTO PROJECT

DESENVOLVIMENTO DE BSP
CAMADA DE BSP
De forma geral, um BSP (Board Support Package) contém todo o código-fonte
necessário para uma plataforma de hardware suportar determinado sistema
operacional (no nosso caso o kernel Linux).

Para incluir o suporte a uma plataforma de hardware no Yocto Project é necessário


uma camada de BSP.

Uma camada de BSP contém metadados relacionados à plataforma de hardware:


Arquivos de configuração de machine.

Receitas de bootloader, kernel, etc.

Classes específicas para a plataforma alvo.


META-YOCTO-BSP
$ tree -L 3 poky/meta-yocto-bsp/

poky/meta-yocto-bsp/

├── conf

│   ├── layer.conf

│   └── machine

│   ├── beaglebone-yocto.conf

│   ├── edgerouter.conf

│   ├── genericx86-64.conf

│   ├── genericx86.conf

│   └── include

├── lib

│   └── oeqa

│   ├── controllers

│   └── selftest

├── README.hardware.md

├── recipes-bsp

│   ├── formfactor

│   │   ├── formfactor

│   │   └── formfactor_0.0.bbappend

│   └── gma500-gfx-check

│   ├── gma500-gfx-check

│   └── gma500-gfx-check_1.0.bb

├── recipes-graphics

│ └── xorg-xserver
CRIANDO UMA CAMADA DE BSP
Antes de criar uma camada de BSP, verifique se já não existe alguma implementação
pronta para a plataforma alvo.

É muito comum os fabricantes de hardware suportarem o Yocto Project provendo


uma camada de BSP para seus produtos.

Uma referência de camadas de BSP e machines existentes está disponível na base de


dados do projeto OpenEmbedded.

https://layers.openembedded.org/layerindex/branch/kirkstone/machines/
CRIANDO UMA CAMADA DE BSP (CONT.)
Uma camada de BSP possui a mesma estrutura de outras camadas e pode ser criada
seguindo os seguintes passos:
Crie uma camada com o comando bitbake-layers create-layer.

Adicione um arquivo de configuração de machine em conf/machine.

Opcionalmente, outros metadados podem ser criados, incluindo:


Receitas de bootloader em recipes-bsp/.

Receitas de kernel em recipes-kernel/.

O guia de desenvolvimento de BSP tem bastante informação sobre como criar


camadas de BSP para o Yocto Project.

https://docs.yoctoproject.org/bsp-guide/index.html
ESQUELETO DE UMA CAMADA DE BSP
$ tree meta-labworks-bsp

meta-labworks-bsp

├── classes

├── conf

│ ├── layer.conf

│ └── machine

│ └── my-machine.conf

├── recipes-bsp

│ └── u-boot

├── recipes-core

├── recipes-graphics

└── recipes-kernel

└── linux
ARQUIVO DE CONFIGURAÇÃO DA MACHINE
Uma das principais tarefas na implementação de uma camada de BSP está na
definição do arquivo de configuração da machine.

Neste arquivo, devemos definir todas as informações necessárias sobre o hardware,


incluindo:
Arquitetura do hardware e parâmetros de otimização do compilador.

Informações para a compilação do bootloader e do kernel.

Pacotes específicos para suportar a plataforma de hardware.

Ao desenvolver o arquivo de configuração da machine, podemos nos basear em


outras implementações existentes.
DEFINIÇÃO DA ARQUITETURA DA CPU
No arquivo de configuração da machine, a arquitetura da CPU é normalmente
definida através da inclusão de um arquivo que contém as configurações para uma
determinada plataforma de hardware.
require conf/machine/include/tune-cortexa9.inc

Diversos arquivos de configuração de arquitetura estão disponíveis no


OpenEmbedded-Core em conf/machine/include/<arch>/.

Nestes arquivos, algumas variáveis são configuradas (TARGET_ARCH, DEFAULTTUNE,


TUNE_ARCH, etc) de forma que o sistema de build tenha conhecimento da
arquitetura do hardware para gerar um toolchain otimizado para o target e utilizar as
flags de compilação corretas durante o processamento das receitas.
SOC_FAMILY E MACHINEOVERRIDES
No arquivo de configuração da machine, é possível definir overrides específicos para
a plataforma alvo.

Para isso, podemos utilizar as variáveis SOC_FAMILY ou MACHINEOVERRIDES:


SOC_FAMILY =. "mx6:mx6dl:"

include conf/machine/include/soc-family.inc

MACHINEOVERRIDES =. "qemuall:"

Este recurso permite o uso de atribuição condicional de variáveis por machine em


outros metadados utilizados na geração da distribuição Linux.
SRC_URI:append:mx6 = " file://fix-imx6-bug.patch"
BOOTLOADER E KERNEL
No arquivo de configuração da machine precisamos definir também as receitas de
bootloader e kernel que serão utilizadas para gerar a distribuição Linux para a
plataforma alvo.

Esta seleção é feita através das variáveis PREFERRED_PROVIDER e


PREFERRED_VERSION.

Para entender como estas variáveis funcionam, é necessário conhecer o mecanismo


de PROVIDES e pacotes virtuais do BitBake.
PROVIDES
Algumas receitas, como as de bootloader e kernel, irão prover os mesmos artefatos
(por exemplo, podem existir nos metadados diversas receitas de kernel, mas todas
elas geram o mesmo artefato: uma imagem de kernel).

Para que uma receita possa indicar que ela irá prover determinado software
(bootloader, kernel, etc), existe o mecanismo de pacote virtual.

Por exemplo, uma receita de kernel irá utilizar a variável PROVIDES para indicar que
irá prover o pacote virtual do kernel Linux:
PROVIDES += "virtual/kernel"

Assim como uma receita de bootloader irá utilizar o mesmo mecanismo:


PROVIDES += "virtual/bootloader"
SELECIONANDO AS RECEITAS
No arquivo de configuração da machine, as variáveis PREFERRED_PROVIDER e
(opcionalmente) PREFERRED_VERSION podem ser utilizadas para escolher a receita
do kernel:
PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"

PREFERRED_VERSION_linux-yocto ??= "5.15%"

O mesmo é feito para o bootloader:


PREFERRED_PROVIDER_virtual/bootloader = "u-boot-toradex"

PREFERRED_VERSION_u-boot-toradex = "2020.04%"
VARIÁVEIS DO U-BOOT
Variável Descrição
UBOOT_MACHINE Nome do arquivo de configuração da placa no U-Boot
UBOOT_SUFFIX Extensão da imagem do U-Boot (ex: .bin)
SPL_BINARY Nome do arquivo do SPL (ex: MLO)
UBOOT_ENTRYPOINT Ponto de entrada da imagem do U-Boot
UBOOT_LOADADDRESS Endereço de carga do U-Boot
UBOOT_LOCALVERSION Concatena uma string na versão do U-Boot
VARIÁVEIS DO KERNEL
Variável Descrição
KERNEL_IMAGETYPE Nome da imagem do kernel (ex: zImage)
KERNEL_DEVICETREE Nome dos arquivos de device tree (.dtb)
KERNEL_EXTRA_ARGS Argumentos adicionais para passar para o make
KERNEL_MODULE_AUTOLOAD Módulos para carregar automaticamente no boot
SERIAL_CONSOLES Porta serial (TTY) para iniciar a aplicação getty
ADICIONANDO PACOTES
Variável Descrição
MACHINE_ESSENTIAL_EXTRA_RDEPENDS Pacotes obrigatórios para instalar
específicos da machine (afeta
imagens que incluem o
packagegroup-core-boot, incluindo
a core-image-minimal)
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS Pacotes recomendados para
instalar específicos da machine
(afeta imagens que incluem o
packagegroup-core-boot, incluindo
a core-image-minimal)
MACHINE_FEATURES
A variável MACHINE_FEATURES permite especificar as funcionalidades suportadas por
uma plataforma de hardware. Exemplos:
touchscreen: o hardware tem uma interface de touchscreen.

wifi: o hardware tem uma interface wifi.

bluetooth: o hardware tem uma interface bluetooth.

Habilitar uma machine feature tem como consequência 1) a inclusão de pacotes


adicionais na imagem ou 2) a alteração na forma como algum software é compilado.

As machine features estão documentadas no manual de referência do Yocto Project.

https://docs.yoctoproject.org/ref-manual/features.html#ref-features-machine
EXEMPLO: PACKAGEGROUP-BASIC.BB
SUMMARY = "Basic task to get a device online"

PR = "r13"

...

RRECOMMENDS:${PN} = "\

${MACHINE_EXTRA_RRECOMMENDS} \

${@bb.utils.contains("MACHINE_FEATURES", "usbhost", "usbutils", "", d)} \

${@bb.utils.contains("MACHINE_FEATURES", "alsa", "alsa-utils-alsamixer", "", d)} \

${@bb.utils.contains("MACHINE_FEATURES", "usbgadget", "kernel-module-g-ether kernel-module-g-seri


\

${@bb.utils.contains("DISTRO_FEATURES", "bluetooth", "bluez5", "", d)} \

${@bb.utils.contains("DISTRO_FEATURES", "wifi", "iw wpa-supplicant", "", d)} \

tzdata \

cpufrequtils \

htop \

"

...
EXEMPLO: MATCHBOX-PANEL-2_2.11.BB
SUMMARY = "Simple GTK+ based panel for handheld devices"

DESCRIPTION = "A flexible always present 'window bar' for holding application \

launchers and small 'applet' style applications"

HOMEPAGE = "http://matchbox-project.org"

BUGTRACKER = "http://bugzilla.yoctoproject.org/"

...

DEPENDS = "gtk+3 startup-notification dbus dbus-glib dbus-glib-native"

DEPENDS += " ${@bb.utils.contains("MACHINE_FEATURES", "acpi", "libacpi", "",d)}"

DEPENDS += " ${@bb.utils.contains("MACHINE_FEATURES", "apm", "apmd", "",d)}"

...

EXTRA_OECONF = "--enable-startup-notification --enable-dbus"

EXTRA_OECONF += " ${@bb.utils.contains("MACHINE_FEATURES", "acpi", "--with-battery=acpi", "",d)}"

EXTRA_OECONF += " ${@bb.utils.contains("MACHINE_FEATURES", "apm", "--with-battery=apm", "",d)}"

...
MACHINE FEATURES VS DISTRO FEATURES
Machine features e distro features trabalham de forma conjunta para adicionar o
suporte à determinada funcionalidade na distribuição gerada.

Algumas funcionalidades só serão habilitadas se estiverem em ambas variáveis


(DISTRO_FEATURES e MACHINE_FEATURES).

Durante o processamento dos metadados, o BitBake combina os valores comuns de


DISTRO_FEATURES e MACHINE_FEATURES em uma variável chamada
COMBINED_FEATURES.
COMBINED_FEATURES
$ bitbake core-image-minimal -e | grep ^DISTRO_FEATURES=

DISTRO_FEATURES="acl alsa argp bluetooth debuginfod ext2 ipv4 ipv6 largefile pcmcia usbgadget

usbhost wifi xattr nfs zeroconf pci 3g nfc x11 vfat seccomp largefile opengl ptest multiarch

wayland vulkan pulseaudio sysvinit gobject-introspection-data ldconfig"

$ bitbake core-image-minimal -e | grep ^MACHINE_FEATURES=

MACHINE_FEATURES="alsa bluetooth usbgadget screen vfat x86 pci rtc qemu-usermode"

$ bitbake core-image-minimal -e | grep ^COMBINED_FEATURES=

COMBINED_FEATURES="usbgadget bluetooth alsa pci vfat"


EXEMPLO: IRDA-UTILS_0.9.18.BB
SUMMARY = "Common files for IrDA"

DESCRIPTION = "Provides common files needed to use IrDA. \

IrDA allows communication over Infrared with other devices \

such as phones and laptops."

HOMEPAGE = "http://irda.sourceforge.net/"

BUGTRACKER = "http://sourceforge.net/p/irda/bugs/"

...

RRECOMMENDS:${PN} = "\

kernel-module-pxaficp-ir \

kernel-module-irda \

kernel-module-ircomm \

kernel-module-ircomm-tty \

kernel-module-irlan \

${@bb.utils.contains('DISTRO_FEATURES', 'ppp', 'kernel-module-irnet', '',d)} \

kernel-module-irport \

kernel-module-irtty \

kernel-module-irtty-sir \

kernel-module-sir-dev \

${@bb.utils.contains('COMBINED_FEATURES', 'usbhost', 'kernel-module-ir-usb', '',d)} "

...
MACHINE: BEAGLEBONE-YOCTO.CONF
#@TYPE: Machine

#@NAME: Beaglebone-yocto machine

#@DESCRIPTION: Reference machine configuration for http://beagleboard.org/bone and http://beagleboard

PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"

XSERVER ?= "xserver-xorg \

xf86-video-modesetting \

"

MACHINE_EXTRA_RRECOMMENDS = "kernel-modules kernel-devicetree"

EXTRA_IMAGEDEPENDS += "virtual/bootloader"

DEFAULTTUNE ?= "cortexa8hf-neon"

include conf/machine/include/arm/armv7a/tune-cortexa8.inc

IMAGE_FSTYPES += "tar.bz2 jffs2 wic wic.bmap"

EXTRA_IMAGECMD:jffs2 = "-lnp "

WKS_FILE ?= "beaglebone-yocto.wks"

MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "kernel-image kernel-devicetree"

do_image_wic[depends] += "mtools-native:do_populate_sysroot dosfstools-native:do_populate_sysroot vi

SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyO0 115200;ttyAMA0"

SERIAL CONSOLES CHECK = "${SERIAL CONSOLES}"


MACHINE: COLIBRI-IMX6.CONF
MACHINEOVERRIDES =. "mx6dl:"

include conf/machine/include/imx-base.inc

include conf/machine/include/arm/armv7a/tune-cortexa9.inc

PREFERRED_PROVIDER_virtual/kernel:use-nxp-bsp ??= "linux-toradex"

KBUILD_DEFCONFIG:use-nxp-bsp ?= "colibri_imx6_defconfig"

KERNEL_DEVICETREE += "imx6dl-colibri-eval-v3.dtb imx6dl-colibri-cam-eval-v3.dtb \

imx6dl-colibri-aster.dtb imx6dl-colibri-iris.dtb \

imx6dl-colibri-iris-v2.dtb"

KERNEL_DEVICETREE:use-mainline-bsp = "imx6dl-colibri-eval-v3.dtb"

KERNEL_IMAGETYPE = "zImage"

# The kernel lives in a seperate FAT partition, don't deploy it in /boot/


RRECOMMENDS:${KERNEL_PACKAGE_NAME}-base = ""

IMX_DEFAULT_BOOTLOADER = "u-boot-toradex"

PREFERRED_PROVIDER_u-boot-default-script = "u-boot-script-toradex"

UBOOT_SUFFIX = "img"

SPL_BINARY = "SPL"

UBOOT_CONFIG ??= "spl"

UBOOT_CONFIG[spl] = "colibri_imx6_defconfig,,u-boot.img"
UBOOT_MAKE_TARGET = ""

UBOOT ENTRYPOINT:use-mainline-bsp = "0x10008000"


HABILITANDO A MACHINE
Para habilitar a machine criada, basta adicionar sua camada no bblayers.conf.
BBLAYERS ?= "\

/opt/labs/ex/layers/poky/meta \

/opt/labs/ex/layers/poky/meta-poky \

/opt/labs/ex/layers/poky/meta-yocto-bsp \

/opt/labs/ex/layers/meta-labworks \

/opt/labs/ex/layers/meta-labworks-bsp \

"

E configurar a variável MACHINE no local.conf com o nome utilizado no arquivo de


configuração da machine.
MACHINE ??= "colibri-imx6"
CRIANDO RECEITAS DE BSP
Uma camada de BSP irá precisar de algumas receitas, principalmente as receitas
para compilar o bootloader e o kernel Linux.

O processo de criação de receitas para a camada de BSP é o mesmo que já


estudamos no treinamento. A diferença é que existem algumas classes específicas
que podemos utilizar em receitas de BSP.
Para compilar o U-Boot, é necessário incluir o arquivo recipes-bsp/u-boot/u-
boot.inc na receita (não existe uma classe específica para compilar o U-Boot).

Para compilar o kernel, podemos utilizar a classe kernel. Opcionalmente, a classe


kernel-yocto também pode ser herdada para se beneficiar de alguns recursos
avançados do Yocto Project como o kernel cache.

Para compilar um módulo do kernel, basta herdar a classe module.


EXEMPLO: U-BOOT-TORADEX_2020.07.BB
SUMMARY = "U-Boot bootloader with support for Toradex Computer on Modules"

HOMEPAGE = "http://www.denx.de/wiki/U-Boot/WebHome"

SECTION = "bootloaders"

LICENSE = "GPL-2.0-or-later"

LIC_FILES_CHKSUM = "file://Licenses/README;md5=30503fd321432fc713238f582193b78e"

require recipes-bsp/u-boot/u-boot.inc

DEPENDS += "bc-native dtc-native bison-native"

PV = "2020.07+git${SRCPV}"

SRC_URI = " \

git://git.toradex.com/u-boot-toradex.git;branch=${SRCBRANCH} \

file://fw_env.config \

"

SRCBRANCH = "toradex_2020.07"

SRCREV = "ab862daf5d5a2eebf305c5c125f0463b0ff34161"

UBOOT_INITIAL_ENV = "u-boot-initial-env"

PROVIDES += "u-boot"

B = "${WORKDIR}/build"

S = "${WORKDIR}/git"
EXEMPLO: LINUX-YOCTO-CUSTOM.BB
inherit kernel

require recipes-kernel/linux/linux-yocto.inc

# Override SRC_URI in a copy of this recipe to point at a different source

# tree if you do not want to build from Linus' tree.

SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git;protocol=git;nocheckout=1

LINUX_VERSION ?= "4.2"

LINUX_VERSION_EXTENSION:append = "-custom"

# Modify SRCREV to a different commit hash in a copy of this recipe to

# build a different release of the Linux kernel.

# tag: v4.2 64291f7db5bd8150a74ad2036f1037e6a0428df2

SRCREV_machine="64291f7db5bd8150a74ad2036f1037e6a0428df2"

PV = "${LINUX_VERSION}+git${SRCPV}"

# Override COMPATIBLE_MACHINE to include your machine in a copy of this recipe

# file. Leaving it empty here ensures an early explicit build failure.

COMPATIBLE_MACHINE = "(^$)"
EXEMPLO: HELLO-MOD_0.1.BB
SUMMARY = "Example of how to build an external Linux kernel module"

DESCRIPTION = "${SUMMARY}"

LICENSE = "GPL-2.0-only"

LIC_FILES_CHKSUM = "file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e"

inherit module

SRC_URI = "file://Makefile \

file://hello.c \

file://COPYING \

"

S = "${WORKDIR}"

# The inherit of module.bbclass will automatically name module packages with

# "kernel-module-" prefix as required by the oe-core build environment.

RPROVIDES:${PN} += "kernel-module-hello"
ESTENDENDO UM BSP
Muitos fabricantes fornecem BSPs baseados no Yocto Project prontos para serem
utilizados com suas plataformas de hardware.

Neste caso, ao invés de criar uma camada de BSP do zero, podemos simplesmente
estender o BSP do fabricante.

Para isso, é aconselhável criar uma camada para centralizar as customizações.


Utilize arquivos de append para customizar as receitas de BSP do fabricante.

Utilize arquivos de patch para controlar as alterações em software (bootloader,


kernel, etc).
CONFIGURANDO O KERNEL
Uma necessidade comum de customização de BSP é a alteração da configuração do
kernel.

A configuração do kernel pode ser aberta diretamente pelo BitBake através da tarefa
do_menuconfig.
$ bitbake virtual/kernel -c menuconfig

A configuração será realizada diretamente no diretório de compilação do kernel, que


poderá ser recompilado para testar as alterações realizadas.

Porém, a configuração não será persistente, e poderá ser perdida em uma eventual
limpeza da compilação do kernel.
CONFIGURANDO O KERNEL (CONT.)
Para um maior controle, customizações na configuração do kernel podem ser salvas
junto com os metadados, em uma camada de BSP.

Existem basicamente dois mecanismos de customização da configuração do kernel:


Sobrescrever a configuração padrão fornecida pelo BSP.

Criar fragmentos de configuração.


SOBRESCREVENDO A CONFIGURAÇÃO
Para sobrescrever a configuração do kernel, podemos criar um arquivo de
configuração customizado chamado defconfig.

Este arquivo de configuração customizado pode ser criado manualmente ou através


do BitBake:
$ bitbake virtual/kernel -c menuconfig

$ bitbake virtual/kernel -c savedefconfig

Uma receita de append do kernel pode ser criada para adicionar este arquivo na
variável SRC_URI.
SOBRESCREVENDO A CONFIGURAÇÃO (CONT.)
$ tree recipes-kernel/

recipes-kernel

└── linux

├── files

│ └── defconfig

└── linux-toradex_%.bbappend

$ cat recipes-kernel/linux/linux-toradex_%.bbappend

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"

SRC_URI += "file://defconfig"
FRAGMENTOS DE CONFIGURAÇÃO
Fragmentos de configuração permitem definir partes da configuração do kernel em
arquivos com extensão .cfg.

Arquivos com fragmentos de configuração podem ser criados manualmente ou


através do BitBake:
$ bitbake virtual/kernel -c kernel_configme

$ bitbake virtual/kernel -c menuconfig

$ bitbake virtual/kernel -c diffconfig

Uma receita de append do kernel pode ser criada para adicionar os fragmentos de
configuração na variável SRC_URI.
FRAGMENTOS DE CONFIGURAÇÃO (CONT.)
$ tree recipes-kernel/

recipes-kernel

└── linux

├── files

│ └── ntfs.cfg

└── linux-yocto_%.bbappend

$ cat recipes-kernel/linux/files/ntfs.cfg

CONFIG_NTFS_FS=y

$ cat recipes-kernel/linux/linux-yocto_%.bbappend

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"

SRC_URI += "file://ntfs.cfg"
APLICANDO PATCHES NO KERNEL
Manter alguns patches na camada de BSP para aplicar no kernel pode ser necessário
quando optamos por não ter nosso próprio repositório de kernel.

Para aplicar patches no kernel podemos seguir o mesmo processo que já estudamos
no treinamento.

Importante: se a quantidade de patches na sua camada de BSP começar a crescer


muito, é hora de pensar em ter seu próprio repositório de kernel!
APLICANDO PATCHES NO KERNEL (CONT.)
$ tree recipes-kernel/

recipes-kernel/

└── linux

├── files

│ └── 0001-fixbug.patch

└── linux-toradex_%.bbappend

$ cat recipes-kernel/linux/linux-toradex_%.bbappend

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"

SRC_URI += "file://0001-fixbug.patch"
ADVANCED METADATA
Outra forma de configurar o kernel é através de um recurso chamado Advanced
Metadata.

A idéia é organizar patches e fragmentos de configuração do kernel em


funcionalidades, que podem ser habilitadas conforme a necessidade.

As definições das funcionalidades ficam em arquivos de descrição com a extensão


.scc, e podem ser habilitadas através das variáveis SRC_URI ou KERNEL_FEATURES.

A documentação completa deste recurso está disponível no manual de


desenvolvimento de kernel do Yocto Project.

https://docs.yoctoproject.org/kernel-dev/advanced.html
EXEMPLO: ADVANCED METADATA
$ tree meta-labworks/recipes-kernel/linux/

meta-labworks/recipes-kernel/linux/

├── files

│ ├── 0001-fix-tpm2-bug.patch

│ ├── tpm2.cfg

│ └── tpm2.scc

└── linux-yocto_%.bbappend

$ cat meta-labworks/recipes-kernel/linux/files/tpm2.scc

define KFEATURE_DESCRIPTION "Enable TPM 2.0"

kconf hardware tpm2.cfg

patch 0001-fix-tpm2-bug.patch

$ cat meta-labworks/recipes-kernel/linux/files/tpm2.cfg

CONFIG_HW_RANDOM_TPM=y

CONFIG_TCG_TPM=y

CONFIG_TCG_TIS_CORE=y

CONFIG_TCG_TIS=y

$ cat meta-labworks/recipes-kernel/linux/linux-yocto_%.bbappend

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"

SRC_URI:append = " file://tpm2.scc"


LABORATÓRIO 7

DESENVOLVENDO E CUSTOMIZANDO BSPS


YOCTO PROJECT

SOFTWARE DEVELOPMENT KIT (SDK)


DESENVOLVENDO COM BUILD SYSTEMS
Apesar de ser possível, utilizar o sistema de build para o desenvolvimento de uma
aplicação não é o processo mais adequado.

O foco de um sistema de build é a integração dos componentes do sistema e a


geração de imagens para o target.

Por este motivo, e para auxiliar no desenvolvimento de aplicações, os sistemas de


build normalmente disponibilizam para os desenvolvedores um conjunto de
ferramentas de desenvolvimento, que chamamos genericamente de SDK.
SDK
Um SDK (Software Development Kit) provê uma infraestrutura de código-fonte,
ferramentas e utilitários que possibilitam o desenvolvimento de aplicações para uma
determinada plataforma alvo.

É composto por um conjunto de componentes, incluindo:


Toolchain (compilador, linker, debugger, etc).

Sysroot (bibliotecas, arquivos de cabeçalho, símbolos de debugging, etc).

Scripts de configuração e ferramentas adicionais.


TOOLCHAIN
Sendo build a máquina que gera o toolchain, host a máquina que executa o toolchain
e target a máquina que executa o binário gerado, existem basicamente quatro tipos
de toolchain:
Native toolchain: build A, host A, target A.

Cross-native toolchain: build A, host B, target B.

Cross-compiling toolchain: build A, host A, target B.

Canadian toolchain: build A, host B, target C.

Apesar do cross-native ser uma opção para o desenvolvimento em Linux embarcado,


o mais comum é o uso de um cross-compiling toolchain.
SYSROOT
O sysroot contém diversos artefatos de software necessários para compilar e linkar
os binários que serão executados no target:
Arquivos de cabeçalho (.h, .hpp, etc).

Bibliotecas estáticas e dinâmicas (.so, .a).

Binários com símbolos de debugging (úteis para resolução de símbolos e


depuração de problemas).

O conteúdo do sysroot é normalmente baseado no rootfs de uma imagem gerada


para o target.
SCRIPTS E OUTRAS FERRAMENTAS
Um SDK pode conter scripts de configuração e outras ferramentas adicionais.

O script de configuração ajuda a configurar o ambiente de desenvolvimento:


Configurar o PATH com as ferramentas do SDK.

Configurar outras variáveis de ambiente úteis para a compilação (CC, CFLAGS, etc)

Outras ferramentas podem estar disponíveis no SDK.


O eSDK (Extensible SDK) do Yocto Project fornece uma ferramenta bem
interessante chamada devtool.
GERANDO SDKS
O Yocto Project é capaz de gerar SDKs de algumas formas diferentes:
meta-toolchain: SDK genérico com um sysroot básico.

populate_sdk: SDK completo com o sysroot baseado em uma receita de imagem.

populate_sdk_ext: SDK completo com o sysroot baseado em uma receita de


imagem, além de ferramentas adicionais para manipular a imagem e os
metadados da distribuição.

A geração do SDK (independente do tipo) irá resultar em um script de instalação


autocontido que poderá ser executado em máquinas de desenvolvimento de mesma
arquitetura da máquina que gerou o toolchain.
RECEITA META-TOOLCHAIN
Um SDK genérico com um sysroot básico pode ser gerado através do processamento
da receita meta-toolchain.
$ bitbake meta-toolchain

Ao final do processo de geração do SDK, um script de instalação estará disponível em


tmp/deploy/sdk.
$ ls -1 tmp/deploy/sdk/

poky-glibc-x86_64-meta-toolchain-cortexa9t2hf-neon-colibri-imx6-training-toolchain-4.0.1.host.mani
poky-glibc-x86_64-meta-toolchain-cortexa9t2hf-neon-colibri-imx6-training-toolchain-4.0.1.sh

poky-glibc-x86_64-meta-toolchain-cortexa9t2hf-neon-colibri-imx6-training-toolchain-4.0.1.target.ma
poky-glibc-x86_64-meta-toolchain-cortexa9t2hf-neon-colibri-imx6-training-toolchain-4.0.1.testdata.

Este SDK pode ser utilizado para o desenvolvimento de aplicações bare-metal


(bootloader, kernel, etc) ou compilação de aplicações simples.
META-TOOLCHAIN: INSTALANDO
$ tmp/deploy/sdk/poky-glibc-x86_64-meta-toolchain-cortexa9t2hf-neon-colibri-imx6-training-toolchain-4
Poky (Yocto Project Reference Distro) SDK installer version 4.0.1

=================================================================

Enter target directory for SDK (default: /opt/poky/4.0.1):

You are about to install the SDK to "/opt/poky/4.0.1". Proceed [Y/n]? y

[sudo] password for sprado:

Extracting SDK..............................................done

Setting it up...done

SDK has been successfully set up and is ready to be used.

Each time you wish to use the SDK in a new shell session, you need to source the environment setup sc
$ . /opt/poky/4.0.1/environment-setup-cortexa9t2hf-neon-poky-linux-gnueabi

$ ls -l /opt/poky/4.0.1/

total 36

-rw-r--r-- 1 root root 4084 jul 13 11:21 environment-setup-cortexa9t2hf-neon-poky-linux-gnueabi

-rw-r--r-- 1 root root 22387 jul 13 11:21 site-config-cortexa9t2hf-neon-poky-linux-gnueabi

drwxr-xr-x 4 root root 4096 jul 13 11:20 sysroots

-rw-r--r-- 1 root root 90 jul 13 11:21 version-cortexa9t2hf-neon-poky-linux-gnueabi


META-TOOLCHAIN: UTILIZANDO
$ source /opt/poky/4.0.1/environment-setup-cortexa9t2hf-neon-poky-linux-gnueabi

$ echo $CC

arm-poky-linux-gnueabi-gcc -mthumb -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 -fstack-protector-stro

$ $CC --version

arm-poky-linux-gnueabi-gcc (GCC) 11.3.0

Copyright (C) 2021 Free Software Foundation, Inc.

This is free software; see the source for copying conditions. There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ cat main.c

int main(void){return 0;}

$ $CC main.c -o main

$ file main

main: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /li
TAREFA POPULATE_SDK
Um SDK completo com o sysroot baseado em uma receita de imagem pode ser
gerado processando a tarefa populate_sdk:
$ bitbake core-image-minimal -c populate_sdk

Ao final do processo de geração do SDK, um script de instalação estará disponível em


tmp/deploy/sdk.
$ ls tmp/deploy/sdk/

poky-glibc-x86_64-core-image-minimal-cortexa9t2hf-neon-colibri-imx6-training-toolchain-4.0.1.host.
poky-glibc-x86_64-core-image-minimal-cortexa9t2hf-neon-colibri-imx6-training-toolchain-4.0.1.sh

poky-glibc-x86_64-core-image-minimal-cortexa9t2hf-neon-colibri-imx6-training-toolchain-4.0.1.targe
poky-glibc-x86_64-core-image-minimal-cortexa9t2hf-neon-colibri-imx6-training-toolchain-4.0.1.testd

Este SDK pode ser utilizado para o desenvolvimento de código bare-metal e


aplicações Linux, possibilitando linkar com qualquer biblioteca instalada na imagem
do sistema.
POPULATE_SDK: INSTALANDO
$ tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-cortexa9t2hf-neon-colibri-imx6-training-toolcha
Poky (Yocto Project Reference Distro) SDK installer version 4.0.1

=================================================================

Enter target directory for SDK (default: /opt/poky/4.0.1): y

You are about to install the SDK to "/opt/labs/ex/build/y". Proceed [Y/n]? y

Extracting SDK................................................................................done

Setting it up...done

SDK has been successfully set up and is ready to be used.

Each time you wish to use the SDK in a new shell session, you need to source the environment setup sc
$ . /opt/labs/ex/build/y/environment-setup-cortexa9t2hf-neon-poky-linux-gnueabi

$ ls -l /opt/poky/4.0.1/

total 36

-rw-r--r-- 1 root root 4084 jul 13 11:21 environment-setup-cortexa9t2hf-neon-poky-linux-gnueabi

-rw-r--r-- 1 root root 22387 jul 13 11:21 site-config-cortexa9t2hf-neon-poky-linux-gnueabi

drwxr-xr-x 4 root root 4096 jul 13 11:20 sysroots

-rw-r--r-- 1 root root 90 jul 13 11:21 version-cortexa9t2hf-neon-poky-linux-gnueabi


POPULATE_SDK: UTILIZANDO
$ source /opt/poky/4.0.1/environment-setup-cortexa9t2hf-neon-poky-linux-gnueabi

$ echo $CC

arm-poky-linux-gnueabi-gcc -mthumb -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 -fstack-protector-stro

$ $CC --version

arm-poky-linux-gnueabi-gcc (GCC) 11.3.0

Copyright (C) 2021 Free Software Foundation, Inc.

This is free software; see the source for copying conditions. There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ cat main.c

int main(void){return 0;}

$ $CC main.c -o main

$ file main

main: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /li
POPULATE_SDK: AUTOTOOLS
$ ls

configure.ac hello.c Makefile.am

$ cat hello.c

#include <stdio.h>

int main(void) { printf("Hello World!\n"); }

$ cat configure.ac

AC_INIT(hello,0.1)

AM_INIT_AUTOMAKE([foreign])

AC_PROG_CC

AC_CONFIG_FILES(Makefile)

AC_OUTPUT

$ cat Makefile.am

bin_PROGRAMS = hello

hello_SOURCES = hello.c
POPULATE_SDK: AUTOTOOLS (CONT.)
$ source /opt/poky/4.0.1/environment-setup-cortexa9t2hf-neon-poky-linux-gnueabi

$ autoreconf

$ ls

aclocal.m4 autom4te.cache compile configure configure.ac depcomp

hello.c install-sh Makefile.am Makefile.in missing

$ ./configure ${CONFIGURE_FLAGS}

$ echo $CONFIGURE_FLAGS

--target=arm-poky-linux-gnueabi --host=arm-poky-linux-gnueabi --build=x86_64-linux

--with-libtool-sysroot=/opt/poky/4.0.1/sysroots/cortexa9t2hf-neon-poky-linux-gnueabi

$ make

$ make install DESTDIR=install/

$ tree install/

install/

└── usr

└── local

└── bin

└── hello
TAREFA POPULATE_SDK_EXT
Um SDK completo com o sysroot baseado em uma receita de imagem e ferramentas
adicionais pode ser gerado processando a tarefa populate_sdk_ext:
$ bitbake core-image-minimal -c populate_sdk_ext

Ao final do processo de geração do SDK, um script de instalação estará disponível em


tmp/deploy/sdk.
$ ls -1 tmp/deploy/sdk/

poky-glibc-x86_64-core-image-training-cortexa9t2hf-neon-colibri-imx6-training-toolchain-ext-4.0.1.host
poky-glibc-x86_64-core-image-training-cortexa9t2hf-neon-colibri-imx6-training-toolchain-ext-4.0.1.sh

poky-glibc-x86_64-core-image-training-cortexa9t2hf-neon-colibri-imx6-training-toolchain-ext-4.0.1.targe
poky-glibc-x86_64-core-image-training-cortexa9t2hf-neon-colibri-imx6-training-toolchain-ext-4.0.1.testd

Este SDK é chamado de Extensible SDK (eSDK) e estende as funcionalidades do SDK


normal, permitindo customizar a manipular a imagem do sistema operacional através da
ferramenta devtool.
POPULATE_SDK_EXT: INSTALANDO
$ tmp/deploy/sdk/poky-glibc-x86_64-core-image-training-cortexa9t2hf-neon-colibri-imx6-training-toolch
Poky (Yocto Project Reference Distro) Extensible SDK installer version 4.0.1

============================================================================

Enter target directory for SDK (default: ~/poky_sdk):

You are about to install the SDK to "/home/sprado/poky_sdk". Proceed [Y/n]?

Extracting SDK.......................................................done
Setting it up...

Extracting buildtools...

Preparing build system...done

SDK has been successfully set up and is ready to be used.

Each time you wish to use the SDK in a new shell session, you need to source the environment setup sc
$ . /home/sprado/poky_sdk/environment-setup-cortexa9t2hf-neon-poky-linux-gnueabi

$ ls /home/sprado/poky_sdk/

bitbake-cookerdaemon.log preparing_build_system.log

buildtools site-config-cortexa9t2hf-neon-poky-linux-gnue
cache sstate-cache

conf sysroots

downloads tmp

environment-setup-cortexa9t2hf-neon-poky-linux-gnueabi version-cortexa9t2hf-neon-poky-linux-gnueabi

layers workspace
POPULATE_SDK_EXT: UTILIZANDO
$ source ~/poky_sdk/environment-setup-cortexa9t2hf-neon-poky-linux-gnueabi

SDK environment now set up; additionally you may now run devtool to perform development tasks.

Run devtool --help for further details.

$ echo $CC

arm-poky-linux-gnueabi-gcc -mthumb -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 -fstack-protector-stro

$ $CC --version

arm-poky-linux-gnueabi-gcc (GCC) 11.3.0

Copyright (C) 2021 Free Software Foundation, Inc.

This is free software; see the source for copying conditions. There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ cat main.c

int main(void){return 0;}

$ $CC main.c -o main

$ file main

main: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib
DEVTOOL
A grande diferença do SDK gerado com a tarefa populate_sdk para o SDK gerado com
a tarefa populate_sdk_ext é a presença da ferramenta devtool.

Esta ferramenta provê um conjunto de funcionalidades para ajudar a desenvolver e


integrar um software em uma imagem gerada com o OpenEmbedded/Yocto Project.

Possui um design parecido com o Git, com sub-comandos para cada uma das
funcionalidades suportadas.

A ferramenta devtool não está somente limitada ao SDK, e pode ser utilizada no
ambiente de build do Yocto Project.
COMANDOS INTERESSANTES
devtool add: cria uma receita a partir do código-fonte de uma aplicação.

devtool edit-recipe: abre o código da receita para edição.

devtool build: processa uma receita.

devtool deploy-target: instala os pacotes gerados por uma receita no target (via SSH).

devtool finish: integra os metadados gerados (receitas, appends, etc) em uma


camada.

devtool upgrade: atualiza a versão de uma receita/aplicação.

devtool modify: altera uma receita/aplicação existente.


DEVTOOL ADD
$ devtool add --version 4.4 fping http://www.fping.org/dist/fping-4.4.tar.gz

INFO: Fetching http://www.fping.org/dist/fping-4.4.tar.gz...

...

INFO: Recipe /home/sprado/poky_sdk/workspace/recipes/fping/fping_4.4.bb has been automatically create

$ tree -L 3 workspace/

workspace/

├── appends

│ └── fping_4.4.bbappend

├── conf

│ └── layer.conf

├── README

├── recipes

│ └── fping

│ └── fping_4.4.bb

└── sources

└── fping

├── aclocal.m4

├── CHANGELOG.md

├── ci

├── compile

├── ...

└── src
RECEITA GERADA: FPING_4.4.BB
# Recipe created by recipetool

# This is the basis of a recipe and may need further editing in order to be fully functional.

# (Feel free to remove these comments when editing.)

# WARNING: the following LICENSE and LIC_FILES_CHKSUM values are best guesses - it is

# your responsibility to verify that the values are complete and correct.
#

# The following license files were not able to be identified and are

# represented as "Unknown" below, you will need to check them yourself:

# COPYING

LICENSE = "Unknown"

LIC_FILES_CHKSUM = "file://COPYING;md5=c6170fbadddfcd74f011515291d96901"

SRC_URI = "http://www.fping.org/dist/fping-${PV}.tar.gz"
SRC_URI[md5sum] = "10e50c164ddff6941eff5fef41c21e3d"

SRC_URI[sha1sum] = "8be8be5b8dc5c0dd3505db79b8fe1438fe4ef590"

SRC_URI[sha256sum] = "9f854b65a52dc7b1749d6743e35d0a6268179d1a724267339fc9a066b2b72d11"

SRC_URI[sha384sum] = "1647b4cf07d751961fbe37bde12292dbc3820e396fe37271d088168a605588a7b4def9f14ac6978
SRC_URI[sha512sum] = "8c9ff78edee10ce8e02a0d6189d4a2d91cc60954740c15730f8f1a17d037ee9f565828fa0dcd47a

# NOTE: if this software is not capable of being built in a separate build directory

# from the source, you should replace autotools with autotools-brokensep in the

# inherit line

inherit autotools
DEVTOOL EDIT-RECIPE
$ devtool edit-recipe fping

diff --git a/fping_4.4.bb b/fping_4.4.bb

index 175c8cd0187e..8f8542dad2c9 100644

--- a/fping_4.4.bb

+++ b/fping_4.4.bb

@@ -8,15 +8,14 @@

# The following license files were not able to be identified and are

# represented as "Unknown" below, you will need to check them yourself:

# COPYING

-LICENSE = "Unknown"

+SUMMARY = "fping sends ICMP ECHO_REQUEST packets to network hosts"

+HOMEPAGE = "http://www.fping.org/"

+LICENSE = "BSD"

LIC_FILES_CHKSUM = "file://COPYING;md5=c6170fbadddfcd74f011515291d96901"

SRC_URI = "http://www.fping.org/dist/fping-${PV}.tar.gz"

-SRC_URI[md5sum] = "10e50c164ddff6941eff5fef41c21e3d"

-SRC_URI[sha1sum] = "8be8be5b8dc5c0dd3505db79b8fe1438fe4ef590"

SRC_URI[sha256sum] = "9f854b65a52dc7b1749d6743e35d0a6268179d1a724267339fc9a066b2b72d11"

-SRC_URI[sha384sum] = "1647b4cf07d751961fbe37bde12292dbc3820e396fe37271d088168a605588a7b4def9f14ac697
-SRC_URI[sha512sum] = "8c9ff78edee10ce8e02a0d6189d4a2d91cc60954740c15730f8f1a17d037ee9f565828fa0dcd47

# NOTE: if this software is not capable of being built in a separate build directory

# from the source, you should replace autotools with autotools-brokensep in the
DEVTOOL BUILD/DEPLOY-TARGET
$ devtool build fping

...

NOTE: fping: compiling from external source tree /home/sprado/poky_sdk/workspace/sources/fping

NOTE: Tasks Summary: Attempted 621 tasks of which 595 didn't need to be rerun and all succeeded.

$ devtool deploy-target fping [email protected]

...

INFO: Successfully deployed /home/sprado/poky_sdk/tmp/work/core2-64-poky-linux/fping/4.4-r0/image

# fping --version

fping: Version 4.4

fping: comments to [email protected]


DEVTOOL FINISH
$ devtool finish --force --remove-work fping meta-labworks

...

INFO: No patches or files need updating

INFO: Moving recipe file to /home/sprado/poky_sdk/layers/meta-labworks/recipes-fping/fping

INFO: -r argument used on fping, removing source tree. You will lose any unsaved work

$ tree layers/meta-labworks/recipes-fping/

layers/meta-labworks/recipes-fping/

└── fping

└── fping_4.4.bb
DEVTOOL UPGRADE
$ devtool upgrade --version 5.0 fping

...

INFO: Rebasing devtool onto d6ab87c90bc0b5b542db1c302edf2f15cc6df490

INFO: Upgraded source extracted to /home/sprado/poky_sdk/workspace/sources/fping

INFO: New recipe is /home/sprado/poky_sdk/workspace/recipes/fping/fping_5.0.bb

$ devtool build fping

$ devtool deploy-target fping [email protected]

# fping --version

fping: Version 5.0

$ devtool finish --force --remove-work fping meta-labworks

...

INFO: Removing file /home/sprado/poky_sdk/layers/meta-labworks/recipes-fping/fping/fping_4.4.bb

INFO: Moving recipe file to /home/sprado/poky_sdk/layers/meta-labworks/recipes-fping/fping

$ ls layers/meta-labworks/recipes-fping/fping/

fping_5.0.bb
DEVTOOL MODIFY
$ devtool modify fping

INFO: Source tree extracted to /home/sprado/poky_sdk/workspace/sources/fping

INFO: Recipe fping now set up to build from /home/sprado/poky_sdk/workspace/sources/fping

$ cd workspace/sources/fping

$ vim src/fping.c && git commit -s -m "change version message"

$ devtool build fping

$ devtool deploy-target fping [email protected]

# fping --version

fping: Version 5.0 (test)

$ devtool finish --force --remove-work fping meta-labworks

INFO: Adding new patch 0001-change-version-message.patch

INFO: Updating recipe fping_5.0.bb

$ tree layers/meta-labworks/recipes-fping/

layers/meta-labworks/recipes-fping/

└── fping

├── fping

│ └── 0001-change-version-message.patch

└── fping_5.0.bb
DEVTOOL --HELP
$ devtool --help

usage: devtool [--basepath BASEPATH] [--bbpath BBPATH] [-d] [-q] [--color COLOR] [-h] <subcommand> .

OpenEmbedded development tool

options:

--basepath BASEPATH Base directory of SDK / build directory

--bbpath BBPATH Explicitly specify the BBPATH, rather than getting it from the metadata

-d, --debug Enable debug output

-q, --quiet Print only errors

--color COLOR Colorize output (where COLOR is auto, always, never)

-h, --help show this help message and exit

subcommands:

Beginning work on a recipe:

add Add a new recipe

modify Modify the source for an existing recipe

upgrade Upgrade an existing recipe

Getting information:

status Show workspace status

search Search available recipes

latest-version Report the latest version of an existing recipe


check-upgrade-status Report upgradability for multiple (or all) recipes

Working on a recipe in the workspace:


SDK VS ESDK
Funcionalidade SDK (populate_sdk) eSDK (populate_sdk_ext)
Toolchain Sim Sim
Debugger Sim Sim
Tamanho 100+ MBytes 1+ GBytes
devtool Não Sim
Compilar imagens Não Sim
Atualizável Não Sim
sysroot gerenciável Não Sim
Construção Pacotes Shared State
LABORATÓRIO 8

GERANDO E UTILIZANDO SDKS


YOCTO PROJECT

FERRAMENTAS E RECURSOS ADICIONAIS


INTRODUÇÃO
Existem diversos projetos e recursos providos pelo Yocto Project que podem
beneficiar os usuários durante o desenvolvimento e manutenção da distribuição.

https://www.yoctoproject.org/software-item/

Dentre a lista de projetos e recursos adicionais, podemos destacar:


Gerenciamento de licenças.

Caches de compilação (shared state cache).

Históricos de build.

Toaster.

Ferramentas de compilação (build appliance, CROPS, autobuilder).


GERENCIAMENTO DE LICENÇAS
Uma das preocupações ao desenvolver produtos que contém software livre é a
aderência às licenças de software livre.

O OpenEmbedded/Yocto Project resolve este problema rastreando a licença de cada


componente de software através das variáveis LICENSE e LIC_FILES_CHKSUM.

A variável LICENSE aceita os seguintes valores:


Nome dos arquivos em poky/meta/files/common-licenses/ (cada arquivo neste
diretório descreve uma licença nos formatos SPDX ou OSI).

Flags da variável SPDXLICENSEMAP definidas em poky/meta/conf/licenses.conf.

Uma mensagem de aviso será exibida se a licença declarada na variável LICENSE não
for encontrada.
DIRETÓRIO COMMON-LICENSES/
$ ls poky/meta/files/common-licenses/

0BSD DRL-1.0 NLOD-2.0

AAL DSDP NLPL

Abstyles DSSSL Nokia

Adobe dvipdfm NOSL

Adobe-2006 ECL-1.0 Noweb

Adobe-Glyph ECL-2.0 NPL-1.0

ADSL eCos-2.0 NPL-1.1

AFL-1.1 EDL-1.0 NPOSL-3.0

AFL-1.2 EFL-1.0 NRL

AFL-2.0 EFL-2.0 NTP

AFL-2.1 eGenix NTP-0

AFL-3.0 Entessa OASIS

Afmparse EPICS OCCT-PL

AGPL-1.0-only EPL-1.0 OCLC-2.0

AGPL-1.0-or-later EPL-2.0 ODbL-1.0

AGPL-3.0-only ErlPL-1.1 ODC-By-1.0

AGPL-3.0-or-later etalab-2.0 OFL-1.0

Aladdin EUDatagrid OFL-1.0-no-RFN

AMDPLPA EUPL-1.0 OFL-1.0-RFN

AML EUPL-1.1 OFL-1.1

...
ARQUIVO LICENSES.CONF
$ cat meta/conf/licenses.conf

# Standards are great! Everyone has their own. In an effort to standardize licensing

# names, common-licenses will use the SPDX standard license names. In order to not

# break the non-standardized license names that we find in LICENSE, we'll set

# up a bunch of VarFlags to accommodate non-SPDX license names.

# We should really discuss standardizing this field, but that's a longer term goal.

# For now, we can do this and it should grab the most common LICENSE naming variations.

# We should NEVER have a GPL/LGPL without a version!!!!

# Any mapping to MPL/LGPL/GPL should be fixed

# AGPL variations

SPDXLICENSEMAP[AGPL-3] = "AGPL-3.0-only"

SPDXLICENSEMAP[AGPL-3+] = "AGPL-3.0-or-later"

SPDXLICENSEMAP[AGPLv3] = "AGPL-3.0-only"

SPDXLICENSEMAP[AGPLv3+] = "AGPL-3.0-or-later"

SPDXLICENSEMAP[AGPLv3.0] = "AGPL-3.0-only"

SPDXLICENSEMAP[AGPLv3.0+] = "AGPL-3.0-or-later"

SPDXLICENSEMAP[AGPL-3.0] = "AGPL-3.0-only"

SPDXLICENSEMAP[AGPL-3.0+] = "AGPL-3.0-or-later"

# BSD variations

SPDXLICENSEMAP[BSD-0-Clause] = "0BSD"
DESABILITANDO UMA LICENÇA
Durante o desenvolvimento de um produto, pode ser necessário evitar o uso de
software de determinada licença.

Por exemplo, a licença GPLv3 possui uma cláusula para impedir o que é
normalmente chamado de Tivoization (restrições no hardware que previnem o
usuário de atualizar o software no dispositivo).
Esta restrição pode ser impeditiva para alguns produtos comerciais.

Para estes casos, a variável INCOMPATIBLE_LICENSE pode ser utilizada para previnir
com que receitas de determinada licença sejam processadas.
INCOMPATIBLE_LICENSE = "GPL-3.0* LGPL-3.0* AGPL-3.0*"
SOFTWARES PROPRIETÁRIOS E COMERCIAIS
Receitas podem utilizar o valor CLOSED para definir que um software é proprietário.
LICENSE = "CLOSED"

Licenças de software comerciais ou especiais podem ser indicadas na receita através


da variável LICENSE_FLAGS.
LICENSE_FLAGS = "commercial"

Para habilitar o processamento de receitas comerciais, é necessário definir a variável


LICENSE_FLAGS_ACCEPTED em um arquivo de configuração.
LICENSE_FLAGS_ACCEPTED = "commercial"
ADERÊNCIA ÀS LICENÇAS DE SOFTWARE
Uma das preocupações em um projeto que contém software livre é a conformidade
com licenças de software.

Apesar de cada licença ter seus próprios requisitos de conformidade, são


normalmente três os pontos que o desenvolvedor deve se preocupar:
Disponibilização do código-fonte original e das alterações realizadas.

Liberação de uma cópia do texto da licença.

Disponibilização dos scripts de compilação.

O Yocto Project é capaz de ajudar nestes três requisitos para garantir aderência às
licenças de software.
DISTRIBUINDO O CÓDIGO-FONTE
A classe archiver e a variável ARCHIVER_MODE podem ser utilizadas para gerar um
diretório com o código-fonte dos componentes de software utilizados na
distribuição:
INHERIT += "archiver"

ARCHIVER_MODE[src] = "original"

Ao final da geração da imagem, os fontes em formato tarball e seus respectivos


patches estarão disponíveis em tmp/deploy/sources.

Se necessário, a variável COPYLEFT_LICENSE_EXCLUDE pode ser utilizada para excluir


o código-fonte dos componentes de software de determinada licença.
DISTRIBUINDO O CÓDIGO-FONTE (CONT.)
$ ls tmp/deploy/sources/x86_64-poky-linux/busybox-1.34.1-r0/

0001-du-l-works-fix-to-use-145-instead-of-144.patch login-utilities.cfg

0001-mktemp-add-tmpdir-option.patch longopts.cfg

0001-sysctl-ignore-EIO-of-stable_secret-below-proc-sys-ne.patch makefile-libbb-race.patch

0001-testsuite-check-uudecode-before-using-it.patch mdev

0001-testsuite-use-www.example.org-for-wget-test-cases.patch mdev.conf

0001-Use-CC-when-linking-instead-of-LD-and-use-CFLAGS-and.patch mdev-mount.sh

busybox-1.34.1.tar.bz2 mount-via-label.cfg

busybox-cron pgrep.cfg

busybox-cross-menuconfig.patch rcK

busybox-httpd rcS

busybox-klogd.service.in recognize_connmand.patch

busybox-syslog.default resize.cfg

busybox-syslog.service.in rev.cfg

busybox-udhcpc-no_deconfig.patch run-ptest

busybox-udhcpd series

default.script sha1sum.cfg

defconfig sha256sum.cfg

fail_on_no_media.patch simple.script

find-touchscreen.sh syslog

getopts.cfg syslog.cfg

hwclock.sh syslog.conf

inetd syslog-startup.conf

inetd.conf unicode.cfg
DISTRIBUINDO O TEXTO DA LICENÇA
Por padrão, as licenças de todos os componentes de software processados pelo
BitBake são mantidos no diretório de build em tmp/deploy/licenses.

Porém, algumas licenças requerem que o texto da licença seja distribuído na imagem
junto com os artefatos gerados (biblioteca, executável, etc).

Para isso, podemos declarar as variáveis abaixo em um arquivo de configuração:


COPY_LIC_MANIFEST = "1"

COPY_LIC_DIRS = "1"

LICENSE_CREATE_PACKAGE = "1"

As licenças serão adicionadas à imagem no diretório /usr/share/common-licenses.


DISTRIBUINDO O TEXTO DA LICENÇA (CONT.)
# cat /usr/share/common-licenses/license.manifest

PACKAGE NAME: base-files

PACKAGE VERSION: 3.0.14

RECIPE NAME: base-files

LICENSE: GPLv2

PACKAGE NAME: base-passwd

PACKAGE VERSION: 3.5.29

RECIPE NAME: base-passwd

LICENSE: GPLv2

PACKAGE NAME: busybox

PACKAGE VERSION: 1.34.1

RECIPE NAME: busybox

LICENSE: GPLv2 & bzip2-1.0.4

...

# ls /usr/share/common-licenses/busybox/

LICENSE.0 LICENSE.1 generic_GPLv2 generic_bzip2-1.0.4 recipeinfo


DISTRIBUINDO OS SCRIPTS DE COMPILAÇÃO
Para prover os scripts de compilação, basta fornecer ao usuário os comandos
necessários para baixar as versões corretas das camadas e configurar o diretório de
compilação:

$ git clone -b kirkstone git://git.yoctoproject.org/poky

$ git clone -b release_branch git://git.mycompany.com/meta-my-bsp-layer

$ git clone -b release_branch git://git.mycompany.com/meta-my-software-layer

$ find . -name ".git" -type d -exec rm -rf {} \;

$ source poky/oe-init-build-env build


SHARED STATE CACHE
O BitBake possui um mecanismo de cache de processamento de receitas chamado
Shared State Cache (sstate).

https://docs.yoctoproject.org/singleindex.html#shared-state-cache

Esta funcionalidade garante ao Yocto Project um mecanismo bem eficiente de


compilação incremental.

Os caches de compilação são armazenados por padrão no diretório de build em


sstate-cache/.
Este valor pode ser alterado através da variável SSTATE_DIR.

É recomendado o uso de NFS para compartilhar o diretório do sstate entre múltiplos


desenvolvedores.
HISTÓRICO DE BUILD
Durante o desenvolvimento de uma distribuição Linux com o OpenEmbedded/Yocto
Project, alterações em receitas podem impactar a imagem gerada, causando
possíveis regressões.

O histórico de build (Build History) é uma ferramenta que possibilita analisar e


rastrear mudanças na saída da compilação, identificando possíveis alterações não
desejadas.

É implementado através da classe buildhistory e possibilita identificar:


Inclusão ou remoção de arquivos e pacotes.

Alteração em arquivos e tamanho da imagem.

Mudança de versões de pacotes.


HABILITANDO O HISTÓRICO DE BUILD
O histórico de build pode ser habilitado herdando a classe buildhistory em um
arquivo de configuração.
INHERIT += "buildhistory"

BUILDHISTORY_COMMIT = "1"

A variável BUILDHISTORY_COMMIT habilita a geração de um commit a cada alteração


feita na imagem.

Tenha em mente que o build history pode aumentar um pouco o tempo de


compilação das imagens, além de aumentar o uso de disco.
ARMAZENAMENTO DO HISTÓRICO DE BUILD
O histórico de build é armazenado por padrão em buildhistory/.
Informações sobre a imagem gerada são armazenadas buildhistory/images/.

Informações sobre os pacotes instalados são armazenados em


buildhistory/packages/.

O diretório do histórico de build pode ser alterado através da variável


BUILDHISTORY_DIR.
BUILDHISTORY_DIR ?= "${TOPDIR}/buildhistory"
DIRETÓRIO BUILDHISTORY/
$ tree buildhistory/

buildhistory/

├── images

│ └── qemux86_64

│ └── glibc

│ └── core-image-minimal

│ ├── build-id.txt

│ ├── depends.dot

│ ├── depends-nokernel.dot

│ ├── depends-nokernel-nolibc.dot

│ ├── depends-nokernel-nolibc-noupdate.dot

│ ├── depends-nokernel-nolibc-noupdate-nomodules.dot

│ ├── files-in-image.txt

│ ├── image-files

│ │ └── etc

│ │ ├── group

│ │ └── passwd

│ ├── image-info.txt

│ ├── installed-package-info.txt

│ ├── installed-package-names.txt

│ ├── installed-package-sizes.txt

│ └── installed-packages.txt

├── metadata-revs

└── packages
ANALISANDO O HISTÓRICO DE BUILD
O histórico de build pode ser analisado diretamente com o Git.
$ git log

$ git show HEAD

Alternativamente, podemos utilizar a ferramenta buildhistory-diff, que possui uma


saída mais simples e amigável:
$ buildhistory-diff -a HEAD^

O histórico de build pode também ser disponibilizado através de uma interface Web:

https://git.yoctoproject.org/buildhistory-web/about/
ANALISANDO O HISTÓRICO COM GIT
$ git log --oneline

9e0bb5bf49e5 (HEAD -> master) Build 20211222192916 of poky 3.4 for machine qemux86-64 on sprado-offic
ca3d6aa3424a (tag: build-minus-1) Build 20211222185937 of poky 3.4 for machine qemux86-64 on sprado-o
9117fee4f44a (tag: build-minus-2) Build 20211222185640 of poky 3.4 for machine qemux86-64 on sprado-o

$ git show HEAD

...

diff --git a/images/qemux86_64/glibc/core-image-minimal/files-in-image.txt b/images/qemux86_64/glibc/


index fa46c3592795..ac4ca6548976 100644

--- a/images/qemux86_64/glibc/core-image-minimal/files-in-image.txt

+++ b/images/qemux86_64/glibc/core-image-minimal/files-in-image.txt

@@ -826,6 +826,7 @@ lrwxrwxrwx root root 19 ./usr/sbin/chroot -> /bin/busybox.no

lrwxrwxrwx root root 19 ./usr/sbin/delgroup -> /bin/busybox.nosuid

lrwxrwxrwx root root 19 ./usr/sbin/deluser -> /bin/busybox.nosuid

lrwxrwxrwx root root 19 ./usr/sbin/fbset -> /bin/busybox.nosuid

+-rwxr-xr-x root root 48112 ./usr/sbin/fping

-rwxr-xr-x root root 92800 ./usr/sbin/groupadd

-rwxr-xr-x root root 88512 ./usr/sbin/groupdel

-rwxr-xr-x root root 59400 ./usr/sbin/groupmems

diff --git a/images/qemux86_64/glibc/core-image-minimal/image-info.txt b/images/qemux86_64/glibc/core


index bea8e7d265cd..8c3d9004d80e 100644

--- a/images/qemux86_64/glibc/core-image-minimal/image-info.txt

+++ b/images/qemux86_64/glibc/core-image-minimal/image-info.txt

@@ -4,10 +4,10 @@ USER CLASSES = buildstats


BUILDHISTORY-DIFF
$ buildhistory-diff -a HEAD^

Changes to images/qemux86_64/glibc/core-image-minimal (files-in-image.txt):

/usr/sbin/fping was added

images/qemux86_64/glibc/core-image-minimal: IMAGE_INSTALL: added "fping"

images/qemux86_64/glibc/core-image-minimal: IMAGESIZE changed from 38844 to 38892 (+0%)

Changes to images/qemux86_64/glibc/core-image-minimal (installed-package-names.txt):

fping was added


RECIPETOOL
A ferramenta recipetool automatiza o gerenciamento de receitas do Yocto Project.

Possui funcionalidades parecidas com a ferramenta devtool, porém com um foco


maior em criar e alterar receitas.

Alguns recursos interessantes providos pela ferramenta:


Criar uma nova receita.

Criar uma receita de append.

Editar receitas existentes.

Setar variáveis em receitas.


RECIPETOOL (CONT.)
$ recipetool -h

usage: recipetool [-d] [-q] [--color COLOR] [-h] <subcommand> ...

OpenEmbedded recipe tool

options:

-d, --debug Enable debug output

-q, --quiet Print only errors

--color COLOR Colorize output (where COLOR is auto, always, never)

-h, --help show this help message and exit

subcommands:

create Create a new recipe

appendfile Create/update a bbappend to replace a target file

appendsrcfiles Create/update a bbappend to add or replace source files


appendsrcfile Create/update a bbappend to add or replace a source file

edit Edit the recipe and appends for the specified target. This obeys $VISUAL if set, o
setvar Set a variable within a recipe

newappend Create a bbappend for the specified target in the specified layer

Use recipetool <subcommand> --help to get help on a specific command


TOASTER
O Toaster é uma interface Web para o OpenEmbedded/Yocto Project.

https://docs.yoctoproject.org/toaster-manual/intro.html

Através de uma interface simples e amigável, provê duas funcionalidades principais:


Configurar e compilar imagens.

Coletar e exibir informações sobre o processo de build.

Desenvolvido em Python (Django), é composto por um frontend web, um backend


que se comunica com o servidor do BitBake e um banco de dados SQLite para
armazenar as informações de build.
TOASTER: ARQUITETURA
EXECUTANDO O TOASTER
O Toaster pode ser executado em uma instância local na máquina do desenvolvedor
ou em um servidor remoto compartilhado com múltiplos desenvolvedores.

Instruções para preparar a máquina para o Toaster estão disponíveis na


documentação da ferramenta.

https://docs.yoctoproject.org/toaster-manual/start.html

O Toaster pode ser iniciado com o comando abaixo.


$ source toaster start

Após iniciar o Toaster, sua interface web estará disponível em http://127.0.0.1:8000.


TOASTER: PÁGINA INICIAL
TOASTER: CONFIGURANDO UM BUILD
TOASTER: INSPECIONANDO UM BUILD
BUILD APPLIANCE
O Build Appliance é uma imagem de máquina virtual que permite experimentar e
utilizar o Yocto Project em máquinas rodando sistemas operacionais diferentes de
distribuições Linux (Windows, MacOS, etc).

https://www.yoctoproject.org/software-item/build-appliance/

Não é recomendado para um ambiente de desenvolvimento/produção (use apenas


para testar e experimentar as ferramentas do Yocto Project).

Disponível para download na página de ferramentas do Yocto Project.

https://www.yoctoproject.org/software-overview/downloads/
CROPS
CROPS (CROss PlatformS) é um projeto que provê um container Docker com um
ambiente de desenvolvimento integrado do Yocto Project, possibilitando manter um
ambiente de compilação em qualquer sistema operacional compatível com o Docker
(Windows, Linux, MacOS, etc).

https://github.com/crops/poky-container

Exemplo de comando para iniciar o CROPS:


$ docker run --rm -it -v /home/myuser/mystuff:/workdir crops/poky --workdir=/workdir

Instruções sobre como configurar e utilizar o CROPS estão disponíveis no manual de


desenvolvimento do Yocto Project.
AUTOBUILDER
O Autobuilder é uma ferramenta de automação de build mantida pelo Yocto Project.

https://autobuilder.yoctoproject.org/

É uma ferramenta de integração contínua (CI), permitindo integrar e testar


mudanças realizadas por diferentes desenvolvedores de um projeto utilizando o
Yocto Project.
Permite identificar quebras de build quando novos commits são introduzidos no
repositório.

Auxilia nos testes de integração com repositórios externos.

Ajuda a alimentar o cache de compilação (shared state).

Internamente, o Autobuilder utiliza um outro projeto chamado Buildbot.


LABORATÓRIO 9

EXPLORANDO FERRAMENTAS E RECURSOS ADICIONAIS


YOCTO PROJECT

CONSIDERAÇÕES FINAIS
LINKS
Site oficial do Yocto Project:

https://www.yoctoproject.org/

Site oficial do OpenEmbedded:

http://www.openembedded.org/wiki/Main_Page

Documentação do projeto:

https://docs.yoctoproject.org/
LIVROS
Embedded Linux Development with Yocto Project - Otavio Salvador/Daiane Angolini

Embedded Linux Development using Yocto Projects - Otavio Salvador/Daiane


Angolini

Embedded Linux Projects Using Yocto Project Cookbook - Alex González

Embedded Linux Systems with the Yocto Project - Rudolf Streif


YOCTO PROJECT

OBRIGADO!

Você também pode gostar