Embedded Labworks

Por Sergio Prado. São Paulo, maio de 2015® Copyright Embedded Labworks 2004-2015. All rights reserved.

Yocto Project

Embedded Labworks

SOBRE ESTE DOCUMENTO

✗ Este documento é disponibilizado sob a Licença Creative Commons BY-SA 3.0.http://creativecommons.org/licenses/by-sa/3.0/legalcode

✗ Os fontes deste documento estão disponíveis em:http://e-labworks.com/treinamentos/yocto/source

Embedded Labworks

SOBRE O INSTRUTOR

✗ Sergio Prado tem mais de 17 anos de experiência em desenvolvimento de software para sistemas embarcados, em diversas arquiteturas de CPU (ARM, PPC, MIPS, x86, 68K), atuando em projetos com Linux embarcado e sistemas operacionais de tempo real.

✗ É sócio da Embedded Labworks, onde atua com consultoria, treinamento e desenvolvimento de software para sistemas embarcados:http://e-labworks.com

✗ Mantém um blog pessoal sobre Linux e sistemas embarcados em:http://sergioprado.org

Embedded Labworks

O.S. SYSTEMS

✗ Este treinamento foi desenvolvido em parceria com a O.S. Systems.

http://ossystems.com.br/

✗ Empresa nacional, fundada em 2002 e sediada em Pelotas, RS.

✗ Experiência com OpenEmbedded e Yocto Project desde 2008.

✗ Contribui ativamente para o desenvolvimento do Yocto Project e de vários outros projetos de código aberto.

Embedded Labworks

AGENDA DO TREINAMENTO

✗ DIA 1: Introdução ao Yocto Project, código-fonte, processo de build, camadas, receitas.

✗ DIA 2: Criando e customizando receitas, customizando a imagem do sistema, desenvolvendo e customizando BSPs.

✗ DIA 3: Integração com ambientes de desenvolvimento, ferramentas adicionais, projeto final.

Embedded Labworks

AMBIENTE DE LABORATÓRIO

/opt/labs/ Ambiente de laboratóriodl/ Aplicações e componentes open­source

que serão usados durante asatividades de laboratório

docs/ Documentaçãoguides/ Guias de consulta

  hardware/ Documentação do hardware  training/ Slides e atividades de laboratórioex/ Exercícios de laboratóriotools/ Ferramentas de uso geral

Embedded Labworks

DURANTE O TREINAMENTO

✗ Pergunte...

✗ Expresse seu ponto de vista...

✗ Troque experiências...

✗ Ajude...

✗ Participe!

Embedded Labworks

Yocto Project

Introdução ao Yocto Project

Embedded Labworks

LINUX EMBARCADO

Hardware

Bootloader

Linux kernel

Biblioteca C

Biblioteca Biblioteca

Aplicação Aplicação

Toolchain

Embedded Labworks

COMPONENTES DO SISTEMA

✗ Hardware: seu dispositivo!

✗ 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 aplicações do usuário.

✗ 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 binários do sistema.

Embedded Labworks

IMAGENS DO SISTEMA

Bootloader

Kernel

Rootfs

Dispositivo de armazenamento

Embedded Labworks

LINUX EMBARCADO

✗ Existem basicamente 3 soluções para desenvolver um sistema com Linux embarcado:

✗ Usar uma distribuição pronta.

✗ Gerar um sistema Linux manualmente.

✗ Usar uma ferramenta de build para gerar um sistema Linux customizado para o target.

Embedded Labworks

DISTRIBUIÇÃO PRONTA

✗ Existem soluções de distribuição Linux comercializadas por empresas como a MontaVista, a WindRiver, a O.S. Systems e a Timesys.

✗ Existem também diversas soluções abertas, incluindo Android, Emdebian, Ubuntu, Tizen, Angstrom, etc.

✗ Vantagens de uma solução pronta: ✗ Simplicidade de uso.

✗ Facilidade na instalação de novos pacotes.

✗ Framework de desenvolvimento pronto e funcional.

Embedded Labworks

DISTRIBUIÇÃO PRONTA (cont.)

✗ Desvantagens no uso de uma solução pronta:✗ Falta flexibilidade (compatibilidade com plataforma de hardware,

mecanismo de inicialização, framework de desenvolvimento, etc).

✗ Pode não estar otimizado para o target, consumindo muitos recursos da máquina (CPU, memória, disco, etc).

✗ Tempo de boot normalmente alto.

✗ Dificuldade de atender aos requisitos de licença e distribuir código-fonte GPL e similares.

✗ Requer tempo e experiência para customizar e adaptar o sistema às características do target.

Embedded Labworks

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:

http://www.linuxfromscratch.org/

Embedded Labworks

SISTEMAS DE BUILD

✗ Um sistema de build permite gerar um sistema Linux completo e customizado para o target.

✗ Ele possui um conjunto de ferramentas que automatizam o processo de geração de todos os componentes do sistema (toolchain, bootloader, kernel, rootfs).

✗ Normalmente já contém um conjunto grande de pacotes configurados para serem habilitados e utilizados pelo seu sistema.

✗ E facilita o trabalho de estender e adicionar novos pacotes se necessário.

Embedded Labworks

VANTAGENS

✗ Um sistema de build possui duas grandes vantagens:✗ Facilidade e flexibilidade na geração de um sistema Linux

customizado.

✗ O processo de build torna-se reproduzível, facilitando o trabalho de recompilação, correção de problemas e adição de novas funcionalidades.

Embedded Labworks

SISTEMAS DE BUILD OPEN SOURCE

✗ Buildroot, desenvolvido pela comunidade:

http://www.buildroot.net

✗ PTXdist, desenvolvido pela empresa Pengutronix:

http://www.pengutronix.de/software/ptxdist/index_en.html

✗ LTIB, desenvolvido principalmente pela Freescale:

http://www.ltib.org/

Embedded Labworks

SISTEMAS DE BUILD OPEN SOURCE (cont.)

✗ OpenEmbedded, mais flexível (e também mais complexo):

http://www.openembedded.org

✗ Poky (baseado no OpenEmbedded, sistema de build de referência usado pelo Yocto Project):

http://www.yoctoproject.org/

Embedded Labworks

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.

✗ Gerenciado por um membro da Linux Foundation, garantindo a independência do projeto com qualquer membro da organização.

Embedded Labworks

ALGUNS MEMBROS

Embedded Labworks

PROJETOS

✗ Alguns dos projetos que formam o Yocto Project:✗ Openembedded Core

✗ BitBake

✗ Poky

✗ AutoBuilder

✗ Hob

✗ Toaster

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

https://www.yoctoproject.org/tools-resources/projects

Embedded Labworks

O QUE O YOCTO PROJECT *NÃO* É?

✗ O Yocto Project não é apenas um sistema de build. É um projeto que engloba diversas ferramentas, incluindo um sistema de build chamado Poky.

✗ O Yocto Project não é uma distribuição. Mas ele pode criar uma distribuição para você!

Embedded Labworks

HISTÓRICO

Portage (Gentoo)

BitBake

OpenZaurus

OpenEmbedded

Poky

Yocto Project

Embedded Labworks

VÍDEO

Fonte: https://www.youtube.com/watch?v=utZpKM7i5Z4

Embedded Labworks

CICLO DE RELEASE

✗ Cada release do Yocto está sujeito a um cronograma definido pela comunidade e publicado em:

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

✗ Espera-se que um novo release do Yocto seja liberado a cada 6 meses.

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

✗ Neste treinamento utilizaremos o Yocto Project 1.8 versão 13.0.0 "Fido".

Embedded Labworks

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 da implementação de camadas.

✗ Suportado pelos fabricantes das principais arquiteturas de hardware (Intel, ARM, MIPS, PowerPC, etc), servindo de padrão para o desenvolvimento de BSPs e imagens de demonstração.

Embedded Labworks

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.

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

✗ Filtro por licenças (Ex: sistema sem GPLv3).

✗ Comunidade bastante ativa.

Embedded Labworks

ARQUITETURA BÁSICA

Fonte: https://www.yoctoproject.org

Embedded Labworks

CONCEITOS

✗ Tarefa (task): Etapa executada pelo sistema de compilação (fetch, patch, configure, compile, package, etc).

✗ Receita (recipe): conjunto de tarefas para compilar determinado software (.bb, .bbappend).

✗ Classes (classes): herança e encapsulamento da lógica para a execução de tarefas comuns entre as receitas (.bbclass).

✗ Pacote (package): resultado do processamento da receita de um componente de software, agregado em algum formato popular de empacotamento (.ipk, .deb, .rpm).

Embedded Labworks

CONCEITOS (cont.)

✗ Camada (layer): Conjunto de receitas, classes e arquivos de configuração que podem ser agregados ao sistema de compilação de forma a estendê-lo (distro, BSP, software).

✗ Máquina (machine): Plataforma de hardware alvo da distribuição a ser gerada, implementada através de uma camada de BSP.

✗ Imagem (image): imagem final do rootfs do sistema gerado para determinada máquina, implementado através de uma receita de imagem.

✗ Distribuição (distro): Regras e políticas de geração da imagem do sistema.

Embedded Labworks

POKY

✗ O Poky pode se referir a dois conceitos diferentes:✗ É o sistema de build utilizado no Yocto Project.

✗ É o nome da distribuição padrão do Yocto Project.

✗ O sistema de build Poky é composto pelos seguintes componentes:✗ Metadados: descrevem a configuração do sistema e as tarefas a

serem executadas. É composto por arquivos de configuração (.conf), receitas (.bb, .bbappend) e classes (.bbclass).

✗ BitBake: ferramenta escrita em Python responsável por processar e executar as receitas.

Embedded Labworks

Yocto Project

Código-fonte

Embedded Labworks

MÁQUINA DE DESENVOLVIMENTO

✗ É recomendado o uso de uma máquina GNU/Linux com uma das seguintes distribuições: Ubuntu, Fedora, openSUSE, CentOS ou Debian.

✗ É necessário uma máquina com boa capacidade de processamento (ex: Intel Core i7) e com bastante espaço em disco.

✗ Alguns pré-requisitos de software: gcc, make, git 1.7.8+, python 2.7.3+, tar 1.24+.

✗ Consulte o link abaixo para instruções mais completas sobre como preparar a máquina de desenvolvimento:

https://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html

Embedded Labworks

CÓDIGO-FONTE

✗ O código-fonte do Yocto Project é composto pelo repositório do Poky e por diversos outros repositórios que fornecem ferramentas e camadas adicionais para construir uma distribuição Linux customizada.

✗ O repositório do Poky é versionado com o git, e pode ser clonado conforme abaixo:

$ git clone ­b fido git://git.yoctoproject.org/poky.git

✗ O parâmetro ­b possibilita clonar um branch específico do repositório, neste exemplo o release Fido do Yocto Project.

Embedded Labworks

CÓDIGO-FONTE DO POKY

$ ls poky/bitbake        meta­skeleton             READMEdocumentation  meta­yocto                README.hardwareLICENSE        meta­yocto­bsp            scriptsmeta           oe­init­build­envmeta­selftest  oe­init­build­env­memres

Embedded Labworks

CÓDIGO-FONTE DO POKY (cont.)

bitbake Diretório da ferramenta bitbake.

documentation Código-fonte da documentação do Yocto Project.

scripts Scripts de uso geral (ex: runqemu).

oe­init­build­env Script para inicializar o ambiente de compilação.

Embedded Labworks

CÓDIGO-FONTE DO POKY (cont.)

meta             Metadados do OpenEmbedded Core, incluindo                  a configuração de máquinas (machine) para                 dispositivos emulados (qemux86, qemuarm,                  etc).

meta­yocto       Metadados da distribuição de referência do                    Yocto Project.

meta­yocto­bsp   Metadados dos BSPs de referência do Yocto                  Project (beaglebone, edgerouter, etc).

Embedded Labworks

CÓDIGO-FONTE DO POKY (cont.)

meta­selftest     Metadados adicionais usados para testar o                    comportamento do sistema de build.

meta­skeleton     Template de receitas para desenvolver BSPs                   e customizar o kernel.

Embedded Labworks

COMPILANDO UMA IMAGEM

✗ O repositório do Poky contém a base do Yocto Project, incluindo as camadas com os metadados necessários para compilar uma distribuição customizada para o emulador e para os BSPs de referência.

✗ Para compilar, o primeiro passo é executar o script oe­init­build­env para que o ambiente de compilação seja configurado:

$ source oe­init­build­env

✗ Por padrão, será criado um diretório chamado build. Opcionalmente, você pode passar o nome do diretório de build:

$ source oe­init­build­env build_dir

Embedded Labworks

O DIRETÓRIO DE BUILD

✗ Todo o processo de compilação irá acontecer dentro do diretório de build.

✗ Por padrão, o diretório de build será criado com alguns arquivos de configuração, incluindo:

✗ conf/bblayers.conf: configuração das camadas que serão utilizadas na distribuição Linux a ser gerada.

✗ conf/local.conf: variáveis de configuração locais do ambiente de compilação.

Embedded Labworks

O DIRETÓRIO DE BUILD (cont.)

$ tree build/build/

 └── conf      ├── bblayers.conf      ├── local.conf      └── templateconf.cfg

Embedded Labworks

BBLAYERS.CONF# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf# changes incompatiblyLCONF_VERSION = "6"

BBPATH = "${TOPDIR}"BBFILES ?= ""

BBLAYERS ?= " \  /home/sprado/yocto/poky/meta \  /home/sprado/yocto/poky/meta­yocto \  /home/sprado/yocto/poky/meta­yocto­bsp \  "BBLAYERS_NON_REMOVABLE ?= " \  /home/sprado/yocto/poky/meta \  /home/sprado/yocto/poky/meta­yocto \  "

Embedded Labworks

LOCAL.CONF

✗ O arquivo local.conf contém algumas das principais variáveis que serão utilizadas durantes o processo de build.

✗ A variável MACHINE permite configurar para qual dispositivo de hardware o sistema será gerado.

MACHINE ??= "qemux86"

✗ A distribuição a ser gerada pode ser configurada na variável DISTRO.

DISTRO ?= "poky"

✗ A variável PACKAGE_CLASSES possibilita configurar os formatos de empacotamento habilitados.

PACKAGE_CLASSES ?= "package_rpm"

Embedded Labworks

LOCAL.CONF (OUTRAS VARIÁVEIS)

✗ A variável CORE_IMAGE_EXTRA_INSTALL pode ser usada para definir pacotes adicionais para incluir na imagem.

✗ As variáveis BB_NUMBER_THREADS e PARALLEL_MAKE permitem controlar a quantidade de threads que o bitbake irá utilizar durante o build.

BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}"

PARALLEL_MAKE ?= "­j ${@oe.utils.cpu_count()}"

✗ O manual de referência do Yocto Project contém uma lista das principais variáveis disponíveis.

Embedded Labworks

COMPILANDO

✗ 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, que irá gerar uma imagem mínima para ser executada no target (selecionado pela variável MACHINE).

✗ Por padrão, todo o processo de build acontecerá no diretório tmp/, dentro do diretório de build.

✗ As imagens do sistema gerado estarão disponíveis em tmp/deploy/images/<machine>/.

Embedded Labworks

DIRETÓRIO DE SAÍDA

$ tree ­L 1 tmp/tmp/

 ├── abi_version ├── buildstats ├── cache ├── deploy ├── log ├── saved_tmpdir ├── sstate­control ├── stamps ├── sysroots ├── work └── work­shared

Embedded Labworks

DIRETÓRIO DE SAÍDA (cont.)

buildstats        Estatísticas do processo de build.

cache             Dados de cache utilizados pelo BitBake.

deploy            Resultado da compilação (pacotes, imagens,                       SDK, etc).

log               Log do BitBake.

sysroots          Bibliotecas e arquivos de cabeçalho compartilhados                   durante o processo de compilação.

work              Diretório de compilação das receitas.

Embedded Labworks

IMAGENS$ ls tmp/deploy/images/qemux86/bzImagebzImage­­3.14+git0+928d7b2dda_0143c6ebb4­r0­qemux86­20140502124415.binbzImage­qemux86.bincore­image­minimal­qemux86­20140502124415.rootfs.ext3core­image­minimal­qemux86­20140502124415.rootfs.manifestcore­image­minimal­qemux86­20140502124415.rootfs.tar.bz2core­image­minimal­qemux86.ext3core­image­minimal­qemux86.manifestcore­image­minimal­qemux86.tar.bz2modules­­3.14+git0+928d7b2dda_0143c6ebb4­r0­qemux86­20140502124415.tgzmodules­qemux86.tgzREADME_­_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt

Embedded Labworks

QEMU

✗ O QEMU é um emulador open source que suporta diversas arquiteturas, incluindo x86, ARM, MIPS e PowerPC.

http://qemu.org

✗ Se a opção MACHINE foi configurada para o QEMU, você consegue utilizá-lo para emular e rodar a imagem gerada:

MACHINE ??= "qemux86"

✗ A imagem pode ser emulada com o comando abaixo:

$ runqemu qemux86

Embedded Labworks

QEMU

Embedded Labworks

LABORATÓRIO

Gerando uma imagem mínima e testando no QEMU

Embedded Labworks

Linux embarcado

Wandboard Quad

Embedded Labworks

WANDBOARD QUAD

✗ i.MX6 Quad (4 núcleos ARM Cortex-A9) rodando à 1GHz.

✗ 2G de RAM DDR3.

✗ Duas interfaces de cartão SD e uma interface SATA.

✗ Saídas de áudio (comum e S/PDIF) e vídeo HDMI.

✗ Ethernet Gigabit, USB host e OTG, WiFi, Bluetooth, serial, etc. http://wandboard.org

Embedded Labworks

DISPLAY E PLACA ADAPTADORA

✗ Display LCD de 7” com resolução de 800x480 (WVGA) da Touch Revolution.

✗ Touchscreen capacitivo.

✗ Placa adaptadora para a Wandboard com suporte ao display de 7” da Touch Revolution e 4 botões.

Embedded Labworks

REFERÊNCIAS E DOCUMENTAÇÃO

✗ A documentação do hardware esta disponível no ambiente de laboratório em docs/guides:

✗ IMX6DQRM.pdf (datasheet do i.MX6)

✗ WandboardQuadUserguide.pdf (guia de usuário da placa)

✗ FusionTouchDisplayDatasheet.pdf (datasheet do display)

✗ AdapterBoardSchematic.tar.gz (esquemático da placa adaptadora)

✗ Recursos na internet:

http://wandboard.org/https://community.freescale.com/

Embedded Labworks

CONECTANDO O HARDWARE

Embedded Labworks

Yocto Project

Sistema de build

Embedded Labworks

POKY E BITBAKE

✗ Poky é o sistema de build do Yocto Project.

✗ O Poky utiliza a ferramenta BitBake, desenvolvida em Python, para a execução de tarefas.

✗ O BitBake interpreta os metadados (metadata), define quais tarefas estão prontas para serem executadas, e as executa.

Embedded Labworks

METADADOS

✗ São considerados metadados:✗ Receitas (.bb, .bbappend).

✗ Classes (.bbclass).

✗ Arquivos de configuração (.conf).

Embedded Labworks

RECEITAS

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

✗ Possuem este nome porquê contém a "receita" para processar determinado componente de software.

✗ Podem incluir as seguintes informações:✗ Descrição e versão do componente de software.

✗ Localização do código-fonte.

✗ Dependências de outros componentes de software.

✗ Procedimento de compilação.

✗ Procedimento de instalação.

Embedded Labworks

RECEITAS (cont.)

✗ Uma lista das principais variáveis que podem ser usadas para descrever uma receita está disponível na documentação do Yocto Project.

http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-varlocality-recipes

Embedded Labworks

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 do conteúdo da receita, possibilitando redefinir alguma variável por exemplo.

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

Embedded Labworks

CLASSES

✗ Classes são arquivos com a extensão .bbclass, e são usadas para abstrair funcionalidades comuns que podem ser usadas por receitas.

✗ Exemplos de classes:✗ autotools.bbclass: compilar projetos baseados em Autotools.

✗ cmake.bbclass: compilar projetos que utilizam o CMake.

✗ qt4e.bbclass: compilar aplicações para o Qt/Embedded 4.x.

✗ kernel.bbclass: compilar o kernel Linux.

✗ Para utilizar uma classe, a receita deve herdar a classe com a diretiva inherit.

Embedded Labworks

BASE.BBCLASS

✗ A classe base.bbclass é herdada implicitamente por toda receita.

✗ Esta classe possui definições para tarefas comuns, incluindo o procedimento para baixar e descompactar o código-fonte, compilar projetos baseados em makefiles, etc.

✗ Uma definição das principais classes existentes está disponível na documentação do Yocto Project.

http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-classes

Embedded Labworks

ARQUIVOS DE CONFIGURAÇÃO

✗ Arquivos de configuração possuem a extensão .conf.

✗ Estes arquivos contém a definição de diversas variáveis que definem o comportamento do sistema de build.

✗ 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 na documentação do Yocto Project:

http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-varlocality-configuration

Embedded Labworks

CAMADAS

✗ Os metadados (receitas, classes e arquivos de configuração) são organizados em camadas (layers) no sistema de build.

✗ As camadas encapsulam e isolam determinadas funcionalidades do sistema a ser gerado (suporte à determinado hardware, regras de geração do sistema, suporte à interface gráfica, etc).

✗ Cada camada é composta por um conjunto de metadados agrupados em um diretório do sistema de build.

✗ Um sistema Linux é gerado com o Yocto Project através da combinação de uma ou mais camadas.

Embedded Labworks

CAMADAS (cont.)

$ tree poky/meta

 ├── classes     │ ├── allarch.bbclass     │ ├── ... ├── conf

     │ ├── layer.conf ├── recipes­bsp ├── recipes­connectivity ├── recipes­core ├── ...

meta­selftestmeta­skeletonmeta­yoctometa­yocto­bsp

Embedded Labworks

TIPOS DE CAMADAS

✗ Existem três tipos de camadas, que podem ser combinadas para gerar a imagem de um sistema Linux:

✗ BSP (Board Support Package).

✗ Distro (distribuição).

✗ Software (camadas adicionais de software).

Embedded Labworks

BSP LAYER

✗ A camada de BSP (Board Support Package) fornece basicamente configurações da plataforma de hardware, também chamada de máquina (machine). Por exemplo:

✗ Arquitetura da CPU (arm, mips, powerpc, etc).

✗ Receitas para compilar o bootloader e o kernel.

✗ Definição da TTY para acesso à console serial.

✗ As principais variáveis usadas no contexto da camada de BSP estão disponíveis na documentação do Yocto Project.

http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-varlocality-config-machine

Embedded Labworks

META-YOCTO-BSP

$ tree meta­yocto­bsp/meta­yocto­bsp

 ├── conf     │ ├── layer.conf     │ └── machine         │ ├── beaglebone.conf         │ ├── genericx86­64.conf         │ ├── genericx86.conf         │ ├── ... ├── recipes­bsp

     │ ├── ... ├── recipes­core

     │ ├── ... ├── recipes­graphics

     │ └── ... └── recipes­kernel

      └── ...

Embedded Labworks

DISTRO LAYER

✗ A camada de distribuição define algumas regras gerais para a geração da imagem, como por exemplo:

✗ Componentes básicos de software.

✗ Biblioteca C a ser usada (eglibc, uclibc, etc).

✗ Tipo do pacote a ser gerado (ipk, deb, rpm).

✗ Versão de determinado software a ser usado.

✗ As principais variáveis que podem ser usadas no contexto de distribuição estão disponíveis na documentação do Yocto Project.

http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-varlocality-config-distro

Embedded Labworks

META-YOCTO$ tree meta­yoctometa­yocto

 ├── classes     │ └── poky­sanity.bbclass ├── conf

     │ ├── bblayers.conf.sample     │ ├── conf­notes.txt     │ ├── distro         │ │ ├── include         │ │ ├── poky­bleeding.conf         │ │ ├── poky.conf         │ │ ├── poky­lsb.conf         │ │ └── poky­tiny.conf     │ ├── layer.conf     │ └── ... ├── recipes­core

     │ └── ... └── recipes­kernel

      └── ...

Embedded Labworks

SOFTWARE LAYER

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

✗ As camadas de software normalmente agrupam um conjunto de receitas com características similares (aplicações de rede, aplicações gráficas, etc).

✗ É comum agrupar em uma camada de software receitas adicionais para gerar uma imagem para determinado produto.

✗ As principais variáveis que podem ser usadas no desenvolvimento de receitas estão disponíveis na documentação do Yocto Project.

http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-varlocality-recipes

Embedded Labworks

META-BROWSER

$ tree meta­browser/meta­browser/

 ├── classes     │ └── mozilla.bbclass ├── conf

     │ └── layer.conf ├── COPYING.MIT ├── README ├── recipes­browser

     │ └── chromium ├── recipes­devtools

     │ └── ninja ├── recipes­gnome

     │ └── gnome­settings­daemon └── recipes­mozilla

      ├── firefox      └── ...

Embedded Labworks

COMANDOS DO BITBAKE

✗ A ferramenta BitBake possui a seguinte sintaxe:

$ bitbake <target>

✗ O campo <target> é normalmente a primeira parte do nome do arquivo de receita. Por exemplo, para compilar a receita busybox_1.22.1.bb:

$ bitbake busybox

✗ Para executar apenas uma tarefa de uma receita, use a opção ­c:

$ bitbake busybox ­c clean

Embedded Labworks

COMANDOS DO BITBAKE (cont.)

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

$ bitbake busybox ­c listtasks

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

$ bitbake ­k core­image­minimal

✗ Para ignorar as dependências da receita, use o parâmetro ­b:

$ bitbake ­b busybox_1.22.1.bb

Embedded Labworks

LIMPANDO A COMPILAÇÃO

✗ Para limpar apenas a saída da compilação (não limpa o cache de compilação):

$ bitbake busybox ­c clean

✗ Para limpar a saída da compilação e o cache de compilação:

$ bitbake busybox ­c cleansstate

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

$ bitbake busybox ­c cleanall

Embedded Labworks

POR DENTRO DO BITBAKE

✗ O propósito inicial do BitBake é executar as tarefas descritas nas receitas.

✗ Mas nosso objetivo final é gerar um sistema Linux customizado para o target.

✗ Qual então o procedimento utilizado pelo BitBake para ler os metadados definidos nas camadas, transformá-los em tarefas e executá-las?

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

$ bitbake core­image­minimal

Embedded Labworks

CARREGANDO A CONFIGURAÇÃO

✗ O primeiro passo executado pelo BitBake é ler os arquivos de configuração, na seguinte ordem:

✗ Arquivo conf/bblayers.conf, que contém a definição das camadas na variável BBLAYERS.

✗ Arquivos de configuração de cada uma das camadas incluídas no BBLAYERS (<layer>/conf/layer.conf).

✗ Arquivo bitbake.conf, com definições básicas e globais que afetam todas as receitas e tarefas que serão executadas.

Embedded Labworks

BITBAKE.CONF E CLASSES

✗ 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 um conjunto de classes, incluindo a classe base.bbclass.

Embedded Labworks

INCLUDE HISTORY$ bitbake ­e## INCLUDE HISTORY:## /home/sprado/yocto/build/conf/bblayers.conf# /home/sprado/yocto/poky/meta/conf/layer.conf# /home/sprado/yocto/poky/meta­yocto/conf/layer.conf# /home/sprado/yocto/poky/meta­yocto­bsp/conf/layer.conf# conf/bitbake.conf includes:#   /home/sprado/yocto/poky/meta/conf/abi_version.conf#   conf/site.conf#   conf/auto.conf#   /home/sprado/yocto/build/conf/local.conf#   [...]#   /home/sprado/yocto/poky/meta/conf/machine/qemux86.conf#   [...]#   conf/machine­sdk/${SDKMACHINE}.conf#   /home/sprado/yocto/poky/meta­yocto/conf/distro/poky.conf#   [...]# /home/sprado/yocto/poky/meta/classes/base.bbclass includes:# [...]

Embedded Labworks

PROCESSANDO A RECEITA

✗ Durante a leitura dos arquivos de configuração, a variável BBFILES será inicializada com uma lista receitas e arquivos de append existentes nas camadas habilitadas:

BBFILES += "${LAYERDIR}/recipes­*/*/*.bb \

            ${LAYERDIR}/recipes­*/*/*.bbappend"

✗ As receitas e arquivos de append são lidos, um a um, e uma lista de tarefas é definida para cada receita.

Embedded Labworks

PROCESSANDO A RECEITA (cont.)

✗ Por fim, o BitBake processa as tarefas da receita passada na linha de comandos (no nosso exemplo, core­image­minimal.bb).

✗ O processo completo está descrito de forma detalhada na documentação do BitBake.

http://www.yoctoproject.org/docs/1.6/bitbake-user-manual/ bitbake-user-manual.html

Embedded Labworks

RECEITAS DE IMAGEM

✗ Algumas receitas, como no caso da core­image­minimal.bb, são na verdade a definição de uma imagem.

✗ Estas receitas herdam a classe core­image e usam a variável IMAGE_INSTALL para definir quais pacotes serão instalados na imagem do sistema.

✗ As receitas de imagem ficam normalmente em um diretório chamado images, dentro do diretório das receitas de uma camada.

Embedded Labworks

RECEITAS DE IMAGEM (cont.)

✗ As receitas de imagem disponíveis para compilação podem ser exibidas com o comando bitbake­layers, listando todas as receitas disponíveis nas camadas habilitadas e filtrando por image:

$ bitbake­layers show­recipes *image*

✗ As receitas de imagem disponíveis podem também ser exibidas listando os diretórios das camadas:

$ ls meta*/recipes*/images/*.bb

Embedded Labworks

RECEITAS DE IMAGEM (cont.)

$ ls meta*/recipes*/images/*.bbmeta/recipes­core/images/build­appliance­image_12.0.1.bbmeta/recipes­core/images/core­image­base.bbmeta/recipes­core/images/core­image­minimal.bbmeta/recipes­core/images/core­image­minimal­initramfs.bbmeta/recipes­core/images/core­image­minimal­mtdutils.bbmeta/recipes­extended/images/core­image­full­cmdline.bbmeta/recipes­extended/images/core­image­lsb.bbmeta/recipes­extended/images/core­image­lsb­dev.bbmeta/recipes­extended/images/core­image­lsb­sdk.bbmeta/recipes­extended/images/core­image­testmaster.bbmeta/recipes­graphics/images/core­image­clutter.bbmeta/recipes­graphics/images/core­image­directfb.bbmeta/recipes­graphics/images/core­image­weston.bbmeta/recipes­graphics/images/core­image­x11.bbmeta/recipes­qt/images/qt4e­demo­image.bb[...]

Embedded Labworks

IMAGENS COMUNS

✗ core­image­minimal: imagem mínima apenas para iniciar em um terminal de linha de comando.

✗ core­image­full­cmdline: imagem mais completa com diversas ferramentas de linha de comando.

✗ core­image­x11: imagem com suporte ao servidor gráfico X11.

✗ core­image­sato: imagem da distribuição para dispositivos móveis baseado no Gnome chamado Sato.

Embedded Labworks

YOCTO PROJECT

✗ Tudo o que vimos até aqui (Poky, BitBake, camadas) são implementados em diferentes projetos.

✗ O Yocto Project é a solução que integra todos estes projetos para facilitar a construção de um sistema Linux customizado.

✗ Todos os projetos que fazem parte do Yocto Project são versionados com o git, e podem ser visualizados no link abaixo:

http://git.yoctoproject.org/cgit/cgit.cgi

Embedded Labworks

REPOSITÓRIOS GIT

Embedded Labworks

OUTROS REPOSITÓRIOS

✗ A comunidade e fabricantes de hardware podem disponibilizar camadas adicionais para o Yocto Project.

✗ Por exemplo, o BSP da Freescale contém os seguintes repositórios de camadas, mantidos pela comunidade:

✗ meta­fsl­arm: suporte aos processadores da Freescale.

✗ meta­fsl­arm­extra: suporte às placas que utilizam os processadores da Freescale.

✗ meta­fsl­demos: exemplos de imagens e receitas.

Embedded Labworks

FERRAMENTA REPO

✗ Portanto, trabalhar com o Yocto Project significa utilizar diferentes repositórios para compor o sistema de build.

✗ Para evitar o trabalho de baixar manualmente cada um dos repositórios, é comum o uso da ferramenta repo.

✗ Através de um arquivo XML, a ferramenta repo facilita o trabalho de clonar individualmente cada um dos repositórios que irão compor o sistema de build.

Embedded Labworks

MANIFEST.XML<?xml version="1.0" encoding="UTF­8"?><manifest>

  <default sync­j="4" revision="fido"/>

  <remote fetch="https://git.yoctoproject.org/git" name="yocto"/>  <remote fetch="https://github.com/Freescale" name="freescale"/>  <remote fetch="https://github.com/openembedded" name="oe"/>

  <project remote="yocto" revision="fido" name="poky" path="sources/poky"/>  <project remote="yocto" revision="fido" name="meta­fsl­arm" path="sources/meta­fsl­arm"/>

  <project remote="oe" revision="fido" name="meta­openembedded" path="sources/meta­openembedded"/>

  <project remote="freescale" revision="fido" name="fsl­community­bsp­base" path="sources/base">    <copyfile dest="README" src="README"/>    <copyfile dest="setup­environment" src="setup­environment"/>  </project>

  <project remote="freescale" revision="fido" name="meta­fsl­arm­extra"            path="sources/meta­fsl­arm­extra"/>  <project remote="freescale" revision="fido" name="meta­fsl­demos"            path="sources/meta­fsl­demos"/>  <project remote="freescale" revision="fido" name="Documentation"            path="sources/Documentation"/>

</manifest>

Embedded Labworks

BSP FREESCALE

✗ Por exemplo, o BSP da Freescale pode ser baixado através da ferramenta repo:

$ repo init ­u https://github.com/Freescale/fsl­community­

bsp­platform ­b fido

$ repo sync

✗ A documentação e os procedimentos completos para utilizar o BSP da Freescale estão disponíveis no site do projeto.

http://freescale.github.io/

Embedded Labworks

LABORATÓRIO

Compilando e testando uma imagem no target

Embedded Labworks

Yocto Project

Camadas

Embedded Labworks

CAMADAS

✗ O sistema de build Poky suporta a organização dos metadados em camadas.

✗ As camadas permitem isolar as customizações do sistema, tornando o desenvolvimento mais modular.

✗ Um sistema Linux é gerado através da combinação de uma ou mais camadas.

Embedded Labworks

DIRETÓRIOS

✗ Cada camada é um diretório no sistema de build.

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

✗ O repositório do Poky já vem com algumas camadas:

$ ls ­d poky/meta*

poky/meta           poky/meta­skeleton  poky/meta­yocto­bsp

poky/meta­selftest  poky/meta­yocto

✗ O desenvolvedor pode agregar outras camadas se necessário.

Embedded Labworks

REPOSITÓRIO DE CAMADAS

✗ Antes de criar uma nova camada, verifique na Internet se já não existe algo pronto.

✗ Uma lista de camadas da comunidade do Yocto Project e do OpenEmbedded está disponível no link abaixo:

http://layers.openembedded.org/layerindex/layers/

Embedded Labworks

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 em conf/layer.conf.

✗ Para facilitar, você pode copiar o arquivo de configuração de uma outra camada e alterá-lo conforme a necessidade.

Embedded Labworks

LAYER.CONF

BBPATH .= ":${LAYERDIR}"

BBFILES += "${LAYERDIR}/recipes­*/*/*.bb \            ${LAYERDIR}/recipes­*/*/*.bbappend"

BBFILE_COLLECTIONS += "labworks"

BBFILE_PATTERN_labworks = "^${LAYERDIR}/"

BBFILE_PRIORITY_labworks = "6"

LAYERVERSION_labworks = "2"LAYERDEPENDS_labworks = "core"

Embedded Labworks

LAYER.CONF (conf.)

✗ Se a camada tiver arquivos de configuração ou arquivos de classes, o diretório da camada deve ser incluída na variável BBPATH.

BBPATH .= ":${LAYERDIR}"

✗ A variável BBFILES deve incluir todos os arquivos de receita e de append da camada:

BBFILES += "${LAYERDIR}/recipes­*/*/*.bb \

            ${LAYERDIR}/recipes­*/*/*.bbappend"

✗ O nome da camada deve ser adicionado à variável BBFILE_COLLECTIONS. É através desta variável que o BitBake consegue encontrar as outras variáveis BBFILE_* do arquivo de configuração:

BBFILE_COLLECTIONS += "labworks"

Embedded Labworks

LAYER.CONF (conf.)

✗ A variável BBFILE_PATTERN deve conter uma expressão regular para encontrar os arquivos de receita da camada.

BBFILE_PATTERN_labworks = "^${LAYERDIR}/"

✗ A variável BBFILE_PRIORITY define a prioridade para as receitas de uma camada, útil onde a mesma receita aparece em mais de uma camada.

BBFILE_PRIORITY_labworks = "6"

Embedded Labworks

LAYER.CONF (conf.)

✗ A variável LAYERVERSION define a versão da camada.

LAYERVERSION_labworks = "2"

✗ A variável LAYERDEPENDS define as camadas que o layer depende, gerando um erro caso as camadas de dependência não sejam encontradas.

LAYERDEPENDS_labworks = "core"

Embedded Labworks

ADICIONANDO CONTEÚDO

✗ O último passo é adicionar conteúdo à camada:✗ Se a camada possuir receitas, estas são normalmente adicionadas

em subdiretórios nomeados como recipes­*.

✗ Se for uma camada de distribuição, os arquivos de configuração são definidos em conf/distro/.

✗ Se for a definição de uma máquina (machine), adicione os arquivos de configuração em conf/machine/.

✗ É comum a existência de um arquivo README descrevendo o conteúdo da camada, incluindo uma lista de dependências, o mantenedor e o conteúdo da camada.

Embedded Labworks

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 \

  "

✗ Para listar as camadas habilitadas e suas respectivas prioridades, basta usar a ferramenta bitbake­layers.

$ bitbake­layers show­layers

Embedded Labworks

LISTANDO AS CAMADAS

$ bitbake­layers show­layerslayer           path                                    priority================================================================meta            /home/sprado/yocto/poky/meta            5meta­yocto      /home/sprado/yocto/poky/meta­yocto      5meta­yocto­bsp  /home/sprado/yocto/poky/meta­yocto­bsp  5meta­labworks   /home/sprado/yocto/poky/meta­labworks   6

Embedded Labworks

SCRIPT DE CRIAÇÃO DE CAMADA$ yocto­layer create labworksPlease enter the layer priority you'd like to use for the layer: [default: 6] Would you like to have an example recipe created? (y/n) [default: n] Would you like to have an example bbappend file created? (y/n) [default: n] 

New layer created in meta­labworks.

Don't forget to add it to your BBLAYERS (for details see meta­labworks\README).

Embedded Labworks

SCRIPT DE CRIAÇÃO DE CAMADA (cont.)

$ tree meta­labworksmeta­labworks

 ├── conf     │ └── layer.conf ├── COPYING.MIT └── README

Embedded Labworks

LABORATÓRIO

Criando camadas

Embedded Labworks

Yocto Project

Receitas

Embedded Labworks

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 o formato <pkgname>_<pkgversion>.bb. Exemplos: ✗ directfb_1.7.1.bb

✗ libdrm_2.4.52.bb

✗ libpng_1.6.16.bb

✗ Para processar uma receita, basta usar a primeira parte do seu nome:

$ bitbake directfb

Embedded Labworks

PACOTES

✗ Pacotes (packages) são o resultado do processamento da receita de um componente de software, agregado em algum formato popular de empacotamento (ipk, deb, rpm).

✗ Uma única receita pode gerar mais de um pacote de software.

$ bitbake ­e unzip | grep ^PACKAGES=

PACKAGES="unzip­dbg unzip­staticdev unzip­dev unzip­doc 

unzip­locale unzip"

Embedded Labworks

REPOSITÓRIO DE RECEITAS

✗ Antes de criar uma nova receita, verifique se já não existe algo pronto.

✗ O comando bitbake­layers permite exibir todas as receitas disponíveis nas camadas habilitadas no bblayers.conf:

$ bitbake­layers show­recipes

✗ Uma base de dados de receitas é disponibilizada pela comunidade do Yocto Project e do OpenEmbedded na Internet:

http://layers.openembedded.org/layerindex/branch/master/recipes/

Embedded Labworks

COMPONENTES 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.

✗ As variáveis permitem parametrizar e moldar o comportamento das tarefas.

Embedded Labworks

lzo_2.09.bbSUMMARY = "Lossless data compression library"HOMEPAGE = "http://www.oberhumer.com/opensource/lzo/"SECTION = "libs"

LICENSE = "GPLv2+"LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263 \         file://src/lzo_init.c;beginline=5;endline=25;md5=355023835a9b9eeb70ab895395e951ff"

SRC_URI = "http://www.oberhumer.com/opensource/lzo/download/lzo­${PV}.tar.gz \           file://0001­Use­memcpy­instead­of­reinventing­it.patch \           file://acinclude.m4 \           file://run­ptest \           "

SRC_URI[md5sum] = "c7ffc9a103afe2d1bba0b015e7aa887f"SRC_URI[sha256sum] = "f294a7ced313063c057c504257f437c8335c41bfeed23531ee4e6a2b87bc b34c"

inherit autotools ptest

Embedded Labworks

VARIÁVEIS

✗ Diversas variáveis podem ser usadas para definir o comportamento do sistema de build durante o processamento da receita. Exemplos:✗ As variáveis SUMMARY e DESCRIPTION permitem descrever a receita.

✗ A variável SRC_URI define a localização do código-fonte.

✗ As variáveis LICENSE e LIC_FILES_CHKSUM configuram informações de licença.

✗ Uma lista com algumas das principais variáveis que podem ser usadas para descrever uma receita está disponível no manual de referência do Yocto Project.

http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-varlocality-recipes

Embedded Labworks

VARIÁVEIS PN, PV e PR

✗ Algumas variáveis são inicializadas automaticamente pelo sistema de build durante o processamento de uma receita.

✗ Por exemplo, a variável PN será inicializada com o nome da receita e a variável PV com sua versão.

✗ No caso da receita libpng_1.6.8.bb, a variável PN será inicializada com libpng e a variável PV será inicializada com 1.6.8.

✗ A variável PR contém a revisão da receita, e por padrão é inicializada com "r0".

Embedded Labworks

VARIÁVEL WORKDIR

✗ A variável WORKDIR contém o diretório onde a receita será processada, e é inicializada com o seguinte conteúdo:

${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}$

{PV}­${PR}

✗ Por exemplo, o resultado do processamento da receita busybox­1.23.1.bb para o emulador estará disponível em:

tmp/work/i586­poky­linux/busybox/1.23.1­r0

Embedded Labworks

VARIÁVEL S

✗ A variável S contém o diretório do código-fonte da receita, e é inicializada com o seguinte conteúdo:

${WORKDIR}/${PN}­${PV}

✗ Por exemplo, o código-fonte correspondente à receita busybox­1.23.1.bb estará disponível em:

tmp/work/i586­poky­linux/busybox/1.23.1­r0/busybox­1.23.1

Embedded Labworks

VARIÁVEL D

✗ A variável D contém o diretório de instalação da receita, e é inicializada com o seguinte conteúdo:

${WORKDIR}/image

✗ Por exemplo, o diretório de instalação da receita busybox­1.23.1.bb será:

tmp/work/i586­poky­linux/busybox/1.23.1­r0/image

Embedded Labworks

ATRIBUIÇÕES

✗ 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, uma atribuição na mesma variável pode 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.

Embedded Labworks

ATRIBUIÇÕES (cont.)

✗ 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"

Embedded Labworks

EXPANSÃO DE VARIÁVEIS

✗ O operador "${}" possibilita expandir uma variável dentro de outra variável.

VAR1 = "value1"

VAR2 = "${VAR1}value2"

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

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

VAR1 = "value1"

VAR2 := "${VAR1}value2"

Embedded Labworks

CONCATENANDO

✗ Use o operador "+=" para concatenar no final de uma variável (append), e o operador "=+" para concatenar no começo de uma variável (prepend).

VAR  = "value1"

VAR =+ "value0"

VAR += "value2"

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

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

VAR  = "value1"

VAR =. "value0 "

VAR .= " value2"

Embedded Labworks

CONCATENANDO (cont.)

✗ A concatenação também pode ser feita adicionando "_append" e "_prepend" às variáveis.

VAR         = "value1"

VAR_prepend = "value0 "

VAR_append  = " value2"

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

✗ Mas diferentemente dos operadores ".=" e "=.", onde a atribuição é realizada no momento da análise, usando este método a atribuição acontece somente no final do processo de análise (parsing).

Embedded Labworks

REMOVENDO

✗ Para remover um valor de uma variável, basta adicionar "_remove" ao nome da variável:

VAR        = "value1 value2 value1 value3"

VAR_remove = "value1"

✗ O resultado final será:

VAR = "value2 value3"

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

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

Embedded Labworks

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.

Embedded Labworks

OVERRIDES (cont.)

✗ No exemplo abaixo, a variável VAR terá o conteúdo value2.

OVERRIDES = "arm:armv7a:mx6:mx6dl:wandboard:wandboard­solo"

VAR     = "value1"

VAR_mx6 = "value2"

VAR_ppc = "value3"

✗ É possível também concatenar de forma condicional usando "_append" ou "_prepend".

VAR_append_mx6 = " value4"

Embedded Labworks

TAREFAS

✗ Todas as receitas herdam automaticamente algumas classes durante seu processamento, incluindo a classe base.bbclass.

✗ Esta classe define algumas tarefas básicas como baixar o código-fonte, aplicar patches e compilar aplicações baseadas em Makefile.

✗ A lista de tarefas de uma receita pode ser exibida executando a tarefa listtasks:

$ bitbake <recipe> ­c listtasks

Embedded Labworks

HERDANDO CLASSES

✗ As receitas podem definir novas tarefas herdando de uma classe com a palavra-chave inherit.

✗ Por exemplo, para herdar as tarefas necessárias para compilar uma aplicação baseada em Autotools:

inherit autotools

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

http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-classes

Embedded Labworks

ALTERANDO TAREFAS EXISTENTES

✗ É possível redefinir uma tarefa existente:

do_compile() {

    # instructions to compile here

}

✗ Ou então adicionar instruções à uma tarefa existente, utilizando _append ou _prepend no nome da tarefa:

do_install_append() {

    # extra install commands

}

Embedded Labworks

ADICIONANDO TAREFAS

✗ Tarefas podem ser adicionadas com a palavra-chave addtask:

do_mkimage () {

    # create image here

}

addtask mkimage after do_compile before do_install

Embedded Labworks

ESCREVENDO TAREFAS

✗ As tarefas podem ser implementadas em shell script:

do_install() {

    install ­d ${D}${bindir}

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

}

✗ Ou em Python:

python do_showdate() {

    import time

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

}

Embedded Labworks

PROCESSAMENTO BÁSICO DE UMA RECEITA

1. Baixar o código-fonte (do_fetch).

2. Descompactar o código-fonte (do_unpack).

3. Aplicar patches (do_patch).

4. Adicionar informações de licença (do_configure).

5. Configurar (do_configure).

Embedded Labworks

PROCESSAMENTO BÁSICO DE UMA RECEITA

6. Compilar (do_compile).

7. Instalar (do_install).

8. Empacotar (do_package).

9. Executar scripts pós-instalação (do_rootfs).

Embedded Labworks

DO_FETCH

✗ A variável SRC_URI é utilizada para definir a localização do código-fonte.

SRC_URI = "http://www.libsdl.org/release/SDL2­${PV}.tar.gz"

✗ O código-fonte pode ser obtido de diversas origens, incluindo HTTP, FTP, repositórios GIT e diretórios locais.

✗ O código-fonte é baixado para o diretório apontado pela variável DL_DIR, que contém por padrão <build_dir>/downloads/.

Embedded Labworks

DO_FETCH (cont.)

✗ Mais de um arquivo pode ser definido na variável SRC_URI:

SRC_URI = "http://www.busybox.net/downloads/busybox­${PV}.tar.bz2 \

           file://get_header_tar.patch \

           file://busybox­appletlib­dependency.patch"

✗ Quando o protocolo usado é do tipo file://, os arquivos são procurados localmente, com o caminho relativo à variável FILESPATH do BitBake.

Embedded Labworks

DO_FETCH (cont.)

✗ O valor da variável FILESPATH é definida por padrão pela classe base.bbclass, e inclui:

✗ Diretório files no mesmo diretório da receita. Ex: <dir_receita>/files/<arquivo.xyz>.

✗ Diretório com o nome da receita, no mesmo diretório da receita. Ex: <dir_receita>/<nome_receita>/<arquivo.xyz>.

✗ Diretório com o nome da receita e sua versão, no mesmo diretório da receita. Ex: <dir_receita>/<nome_receita>­<versao_receita>/ <arquivo.xyz>.

✗ Para estender o caminho de busca de arquivos pode-se usar a variável FILESEXTRAPATHS.

Embedded Labworks

DO_FETCH (cont.)

✗ Se você estiver baixando um arquivo de um servidor remoto sem usar uma ferramenta de controle de versão, é necessário prover o md5 e o sha256 de cada URL nas variáveis SRC_URI[md5sum] e SRC_URI[sha256sum].

SRC_URI = "http://www.busybox.net/busybox­${PV}.tar.bz2;name=tarball \

           file://busybox­udhcpc­no_deconfig.patch"

SRC_URI[tarball.md5sum] = "337d1a15ab1cb1d4ed423168b1eb7d7e"

SRC_URI[tarball.sha256sum] = "ae0b029d0a9e4dd71a077a790840e496dd838998 

e4571b87b60fed7462b6678b"

Embedded Labworks

DO_FETCH (cont.)

✗ 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 PV.

SRCREV = "d9e0c438e10e2155513e5d26498af472c5137d65"

PV = "1.22.1+git${SRCPV}"

SRC_URI = "git://busybox.net/busybox.git"

Embedded Labworks

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}"

S = "${WORKDIR}/git"

Embedded Labworks

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://dhcp­3.0.3­dhclient­dbus.patch;striplevel=0"

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

SRC_URI = "file://arm­thumb­mutex_db5.patch;patchdir=.."

Embedded Labworks

DO_CONFIGURE

✗ A receita deve ter a variável LICENSE para especificar a licença do software:

LICENSE = "GPLv2"

✗ Uma lista com o nome das licenças comuns está disponível 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=44bc22578be94b6536c 

8bdc3a01e5db9"

Embedded Labworks

DO_CONFIGURE (cont.)

✗ A maioria das aplicações possui um mecanismo para configurar o software antes de iniciar a compilação (ex: autotools, cmake, etc).

✗ Normalmente, herda-se de uma classe a implementação desta tarefa (exemplo para o Autotools):

inherit autotools

✗ A variável EXTRA_OECONF pode ser usada para passar opções extras para o script de configuração do autotools.

Embedded Labworks

DO_COMPILE

✗ Assim como a tarefa de configuração, normalmente herda-se de uma classe a implementação da tarefa de compilação (exemplo para o 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.

Embedded Labworks

DO_INSTALL

✗ Assim como as tarefas de configuração e compilação, normalmente herda-se de uma classe a implementação desta tarefa.

✗ Se necessário, você pode definir e implementar uma tarefa do_install customizada.

✗ É possível também complementar a instalação definindo a tarefa do_install_append.

✗ A instalação é realizada no diretório apontado pela variável D, que por padrão contém ${WORKDIR}/image.

Embedded Labworks

DO_PACKAGE

✗ O objetivo desta tarefa é empacotar os diversos componentes de software da receita.

✗ Os componentes lógicos do software (binário, binário com símbolo de debug, documentação, etc) são empacotados no diretório${WORKDIR}/packages­split.

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

Embedded Labworks

DO_ROOTFS

✗ Os scripts de pós-instalação são executados durante a criação da imagem ou após a instalação de um pacote no target.

✗ Para adicionar um script de pós-instalação, basta adicionar a função pkg_postinst_<PACKAGENAME> na receita, onde <PACKAGENAME> é o nome do pacote.

pkg_postinst_${PN} () {

    #!/bin/sh ­e

    # Commands to execute on the target rootfs

}

Embedded Labworks

DEPENDÊNCIAS

✗ Um pacote pode depender de outro pacote em tempo de compilação ou em tempo de execução.

✗ Para indicar estas dependências, as seguintes variáveis podem ser usadas:

✗ DEPENDS: dependências de compilação do pacote (a tarefa do_configure do pacote depende da tarefa do_populate_sysroot da sua dependência).

✗ RDEPENDS: dependências de execução do pacote (a tarefa do_build do pacote depende da tarefa do_package_write da sua dependência).

Embedded Labworks

MODELO DE RECEITA

SUMMARY = ""HOMEPAGE = ""

LICENSE = ""LIC_FILES_CHKSUM = ""

SRC_URI = ""SRC_URI[md5sum] = ""SRC_URI[sha256sum] = ""

inherit <some_class>

Embedded Labworks

EXEMPLO TEST.C

SUMMARY = "Test application"SECTION = "tests"LICENSE = "BSD"LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;\                    md5=7363621101019373746565758497289305"

SRC_URI = "file://test.c"

S = "${WORKDIR}"

do_compile() {     ${CC} test.c ­o test}

do_install() {     install ­d ${D}${bindir}     install ­m 0755 test ${D}${bindir}}

Embedded Labworks

EXEMPLO AUTOTOOLS

SUMMARY = "GNU Helloworld application"SECTION = "examples"

LICENSE = "GPLv2+"LIC_FILES_CHKSUM = "file://COPYING;\                    md5=751419260aa954499f7abaabaa882bbe"

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

inherit autotools

Embedded Labworks

INCLUDE E REQUIRE

✗ O BitBake permite o uso das diretivas de inclusão de arquivos include e require.

include udev.inc

✗ O arquivo incluído deve estar no mesmo diretório do arquivo que está incluindo, ou então deve-se usar um caminho relativo existente na variável BBPATH.

✗ 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.

Embedded Labworks

udev_182.bb

include udev.inc

PR = "r9"

DEPENDS += "module­init­tools"

SRC_URI[md5sum] = "1b964456177fbf48023dfee7db3a708d"

SRC_URI[sha256sum] = "7857ed19fafd8f3ca8de410194e8c7336e9eb 

82A0626ea8a4ba6449b017faba4"

Embedded Labworks

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 do conteúdo da receita, possibilitando redefinir alguma variável por exemplo.

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

Embedded Labworks

ARQUIVOS DE APPEND (cont.)

✗ Um arquivo de append permite implementar customizações na sua camada, alterando o comportamento de receitas de outras camadas, sem precisar alterar o código original da receita.

✗ É comum o uso da variável FILESEXTRAPATHS no arquivo de append para indicar ao sistema de build o local de arquivos adicionais (ex: patches).

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}­${PV}:"

Embedded Labworks

alsa-lib_1.0.28.bb

$ ls poky/meta/recipes­multimedia/alsa/alsa­lib_1.0.28.bb

$ tree meta­fsl­arm/recipes­multimedia/alsa/./meta­fsl­arm/recipes­multimedia/alsa/

 ├── alsa­lib     │ └── 0001­add­conf­for­multichannel­support­in­imx.patch └── alsa­lib_%.bbappend

$ cat meta­fsl­arm/recipes­multimedia/alsa/alsa­lib_%.bbappend 

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

SRC_URI_append_mx6 = " file://0001­add­conf­for­multichannel­support­in­imx.patch"

Embedded Labworks

VERSIONAMENTO

✗ As variáveis PV, PE e PR compõem o versionamento de um pacote.✗ PV (Package Version): versão do pacote, lido normalmente do nome

da receita.✗ PE (Package Epoch): por padrão vazia, mas deve ser usada caso o

esquema de versionamento do pacote seja alterado.✗ PR (Package Revision): por padrão r0, mas deve ser alterada caso

haja alteração na receita (pode ser automatizado com um servidor chamado bitbake­prserv).

✗ A versão de cada pacote pode ser exibida com o comando abaixo:

$ bitbake ­s

Embedded Labworks

VERSIONAMENTO (cont.)

$ bitbake ­s[...]cups                                                :2.0.2­r0curl                                               :7.40.0­r0curl­native                                        :7.40.0­r0cwautomacros                                     :20110201­r0cwautomacros­native                              :20110201­r0damageproto                                        1:1.2.1­r1damageproto­native                                 1:1.2.1­r1db                                                 :6.0.30­r0db­native                                          :6.0.30­r0dbus                                               :1.8.10­r0dbus­glib                                           :0.102­r0dbus­glib­native                                    :0.102­r0[...]

Embedded Labworks

VERSIONAMENTO (cont.)

✗ Se existir mais de uma versão da mesma receita, por padrão o BitBake seleciona a última versão.

✗ Se as receitas estiverem em camadas com prioridades diferentes (BBFILE_PRIORITY), a receita na camada de maior prioridade é selecionada.

Embedded Labworks

VERSIONAMENTO (cont.)

✗ A variável PREFERRED_VERSION pode ser usada em um arquivo de configuração para determinar a receita que deve ter preferência.

PREFERRED_VERSION_gtk+ ?= "2.13.3"

✗ Uma receita pode usar a variável DEFAULT_PREFERENCE para definir sua prioridade (por padrão 0, quanto maior mais prioritária).

DEFAULT_PREFERENCE = "­1"

Embedded Labworks

PROCESSAMENTO DA RECEITA

✗ A receita é processada no diretório apontado pela variável WORKDIR.

$ ls tmp/work/i586­poky­linux/zlib/1.2.8­r0/

debugsources.list        pkgdata

deploy­rpms              pseudo

image                    remove.ldconfig.call.patch

ldflags­tests.patch      run­ptest

license­destdir          sysroot­destdir

Makefile­runtests.patch  temp

package                  zlib­1.2.8

packages­split           zlib.spec

Embedded Labworks

DIRETÓRIO DE SAÍDA DA RECEITA (cont.)

temp diretório com os logs de execução das tarefas.

<sources> diretório com os fontes descompactados do software a ser compilado (o nome depende da variável S no momento da descompactação do pacote).

image diretório de instalação dos pacotes da receita.

Embedded Labworks

DIRETÓRIO DE SAÍDA DA RECEITA (cont.)

package conteúdo do(s) pacote(s) descompactado(s).

packages­split conteúdo dos pacotes, descompactados esegmentados.

deploy­rpms pacotes gerados.

Embedded Labworks

DEPURANDO

✗ No caso de erro no processamento de uma receita, verifique os logs gerados no diretório temp/, dentro do diretório de processamento da receita.

$ ls temp/

log.do_compile

log.do_compile.29699

log.do_configure

log.do_configure.29225

[...]

run.do_compile

run.do_compile.29699

run.do_configure

run.do_configure.29225

[...]

Embedded Labworks

DEPURANDO (cont.)

✗ Na dúvida sobre o conteúdo de uma variável, utilize a opção ­e do BitBake:

$ bitbake ­e <target> | grep <VAR>

✗ Utilize a opção ­c do BitBake para executar uma tarefa específica:

$ bitbake ­c compile <target>

✗ Se necessário, limpe os caches de processamento da receita executando a tarefa cleansstate.

$ bitbake ­c cleansstate <target>

Embedded Labworks

DEVSHELL

✗ A tarefa devshell permite abrir um novo terminal para depurar o processamento de uma receita.

$ bitbake unzip ­c devshell

✗ Neste novo terminal, todas as variáveis de ambiente necessárias para a compilação estarão definidas, possibilitando utilizar diretamente comandos como o configure e o make.

✗ Esta tarefa é útil também para gerar patches durante o desenvolvimento do sistema.

Embedded Labworks

REFERÊNCIAS

✗ Para mais informações sobre o processo de criação de uma receita:

http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-recipe-writing-a-new-recipe

✗ Para mais informações sobre a sintaxe do BitBake:

http://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html

Embedded Labworks

LABORATÓRIO

Criando e customizando receitas

Embedded Labworks

Yocto Project

Customizações

Embedded Labworks

CUSTOMIZANDO UMA IMAGEM

✗ Durante o desenvolvimento de um sistema Linux com o Yocto Project, pode ser necessário customizar a imagem final gerada por diversos motivos, dentre eles:

✗ Adicionar ou remover componentes de software.

✗ Adicionar ou remover arquivos do sistema (arquivos de configuração, binários, etc).

✗ Adicionar ou remover usuários e configurar senhas.

✗ Configurar permissões de arquivos e diretórios.

✗ Modificar o tipo e formato da imagem final gerada para instalação no target.

Embedded Labworks

COMO CUSTOMIZAR?

✗ Uma imagem pode ser customizada de diversas formas:✗ Alterações locais podem ser realizadas no arquivo local.conf (ex:

adição de pacotes de software para testes).

✗ A imagem final do rootfs pode ser customizada através de uma receita de imagem (conjunto de pacotes, tamanho e tipo do rootfs, etc).

✗ Políticas globais sobre como uma imagem é gerada podem ser definidas em uma distribuição (ex: funcionalidades básicas, biblioteca do sistema, etc).

Embedded Labworks

LOCAL.CONF

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

✗ Você pode usar a variável IMAGE_INSTALL pós-fixada com o operador _append para adicionar um pacote de software:

IMAGE_INSTALL_append += " ppp"

✗ O operador _append faz com que a alteração seja aplicada depois de todas as outras operações de atribuição (:=, ?=, etc).

Embedded Labworks

ALTERANDO O LOCAL.CONF (cont.)

✗ Para aplicar a alteração apenas para uma imagem específica, é possível pós-fixar o nome da imagem na variável IMAGE_INSTALL.

IMAGE_INSTALL_append_pn­core­image­minimal = " ppp"

✗ O mesmo resultado é alcançado usando a variável CORE_IMAGE_ EXTRA_INSTALL. Neste caso, todas as imagens core­image­* serão afetadas.

CORE_IMAGE_EXTRA_INSTALL += "ppp"

Embedded Labworks

ALTERANDO O LOCAL.CONF (cont.)

✗ Alterar diretamente o local.conf para customizar uma imagem possui algumas deficiências:

✗ Permite apenas alguns tipos de customizações, como a adição de pacotes de software.

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

✗ Se você não tomar cuidado, poderá sobrepor uma configuração importante da imagem ou da distribuição.

✗ É complicado documentar ou versionar as alterações de forma que seja possível reproduzir o build em uma outra máquina.

✗ Por este motivo, é aconselhável criar uma camada e realizar as alterações em uma receita de imagem e/ou distribuição.

Embedded Labworks

RECEITAS DE IMAGENS

✗ Receitas de imagem permitem uma maior flexibilidade e controle na customização da imagem final.

✗ Normalmente, as receitas de imagem ficam em um diretório chamado images no diretório de receitas da camada.

$ ls meta/recipes­core/images/

build­appliance­image            core­image­minimal­dev.bb

build­appliance­image_12.0.1.bb  core­image­minimal­initramfs.bb

core­image­base.bb               core­image­minimal­mtdutils.bb

core­image­minimal.bb

✗ As receitas de imagem disponíveis podem ser exibidas com a ferramenta bitbake­layers.

$ bitbake­layers show­recipes "*­image*"

Embedded Labworks

core-image-minimal.bb

SUMMARY = "A small image just capable of allowing a device to boot."

IMAGE_INSTALL = "packagegroup­core­boot ${ROOTFS_PKGMANAGE_BOOTSTRAP} ${CORE_IMAGE_EXTRA_INSTALL}"

IMAGE_LINGUAS = " "

LICENSE = "MIT"

inherit core­image

IMAGE_ROOTFS_SIZE ?= "8192"

Embedded Labworks

CRIANDO RECEITAS DE IMAGENS

✗ Ao criar uma receita de imagem, procure basear sua receita em outras existentes.

✗ Você pode simplesmente copiar uma outra receita de imagem para a sua camada e customizá-la.

✗ É possível também se basear em uma receita existente com a diretiva require:

require recipes­core/images/core­image­minimal.bb

✗ E então você pode adicionar pacotes à imagem utilizando as variáveis IMAGE_INSTALL , CORE_IMAGE_EXTRA_INSTALL e IMAGE_FEATURES.

Embedded Labworks

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"

Embedded Labworks

RECEITAS X PACOTES

✗ Sabemos que uma receita poderá gerar mais de um pacote.

✗ Mas não necessariamente os pacotes gerados terão o mesmo nome da receita.

✗ As variáveis IMAGE_INSTALL e CORE_IMAGE_EXTRA_INSTALL devem ser configuradas com o nome do pacote, e não da receita!

Embedded Labworks

RECEITAS X PACOTES (cont.)$ bitbake ­e python | grep ^PACKAGES=PACKAGES="python­ptest  libpython2  python­dbg  python­2to3  python­argparse  python­audio  python­bsddb  python­codecs  python­compile python­compiler  python­compression  python­contextlib  python­core python­crypt  python­ctypes  python­curses  python­datetime  python­db python­debugger  python­dev  python­difflib  python­distutils­staticdev python­distutils  python­doctest  python­elementtree  python­email python­fcntl  python­gdbm  python­hotshot  python­html  python­idle python­image  python­importlib  python­io  python­json  python­lang python­logging  python­mailbox  python­math  python­mime  python­mmap python­multiprocessing  python­netclient  python­netserver  python­numbers  python­pickle  python­pkgutil  python­pprint  python­profile python­pydoc  python­re  python­readline  python­resource  python­robotparser  python­shell  python­smtpd  python­sqlite3  python­sqlite3­tests  python­stringold  python­subprocess  python­syslog  python­terminal  python­tests  python­textutils  python­threading  python­tkinter  python­unittest  python­unixadmin  python­xml  python­xmlrpc python­zlib python­modules python­misc python­man"

Embedded Labworks

PACOTES DE UMA IMAGEM

✗ Os pacotes instalados em uma imagem podem ser exibidos listando o arquivo de manifesto da imagem:

$ cat tmp/deploy/images/qemux86/core­image­minimal­qemux86.manifest

base­files qemux86 3.0.14

base­passwd i586 3.5.29

busybox i586 1.22.1

busybox­hwclock i586 1.22.1

busybox­syslog i586 1.22.1

busybox­udhcpc i586 1.22.1

copybin i586 1.0.0

init­ifupdown qemux86 1.0

initscripts i586 1.0

initscripts­functions i586 1.0

kernel­3.14.0­yocto­standard qemux86 3.14+git0+09424...

kernel­module­uvesafb qemux86 3.14+git0+09424...

[...]

Embedded Labworks

GRUPOS DE PACOTES

✗ Um grupo de pacotes (package groups) é basicamente um conjunto de pacotes de software com um objetivo comum.

✗ Alguns exemplos:✗ Pacotes de software básico do sistema (base files, busybox, login,

etc).

✗ Pacotes de software para habilitar o stack gráfico (x11-server, x11-common, xrandr, etc).

✗ Pacotes de software do produto desenvolvido pela empresa (aplicações, bibliotecas, etc).

Embedded Labworks

GRUPOS DE PACOTES (cont.)

✗ Normalmente, os grupos de pacotes ficam em um diretório chamado packagegroups no diretório de receitas da camada:

$ ls 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

[...]

Embedded Labworks

packagegroup-core-x11-base.bb

SUMMARY = "Basic X11 session"DESCRIPTION = "Packages required to set up a basic working X11 session"

inherit packagegroup

[...]

RDEPENDS_${PN} = "\    packagegroup­core­x11­xserver \    packagegroup­core­x11­utils \    dbus \    pointercal \    matchbox­terminal \    matchbox­wm \    mini­x­session \    liberation­fonts \    "

Embedded Labworks

USANDO GRUPOS DE PACOTES NA RECEITA

✗ Um grupo de pacotes pode ser adicionado a uma imagem normalmente através das variáveis IMAGE_INSTALL e CORE_IMAGE_EXTRA_INSTALL.

✗ Por exemplo, para adicionar o suporte básico ao X11, você poderia alterar a receita da sua imagem conforme abaixo:

IMAGE_INSTALL += "packagegroup­core­x11­base"

Embedded Labworks

IMAGE FEATURES

✗ As features de imagem permitem agrupar um conjunto de grupos de pacotes (package groups) para adicionar uma funcionalidade à imagem gerada.

✗ As features de imagem disponíveis estão definidas na classe core­image.bbclass.

FEATURE_PACKAGES_x11 = "packagegroup­core­x11"

FEATURE_PACKAGES_nfs­server = "packagegroup­core­nfs­server"

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

FEATURE_PACKAGES_qt4­pkgs = "packagegroup­core­qt­demoapps"

FEATURE_PACKAGES_hwcodecs = "${MACHINE_HWCODECS}"

[...]

Embedded Labworks

IMAGE FEATURES (cont.)

✗ Para habilitar uma feature de imagem em uma receita, basta usar a variável IMAGE_FEATURES, conforme abaixo:

IMAGE_FEATURES += "x11­base"

✗ Também é possível habilitar uma feature de imagem através da variável EXTRA_IMAGE_FEATURES.

EXTRA_IMAGE_FEATURES += "x11­base"

Embedded Labworks

IMAGE FEATURES (cont.)

✗ Durante o processo de build, o BitBake adiciona os grupos de pacotes das features de imagens habilitadas na variável IMAGE_INSTALL.

✗ Uma lista das principais features de imagens está disponível no manual de referência do Yocto Project.

http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-features-image

✗ Existem ainda as features de máquina (machine features) e as features de distribuição (distro features), que estudaremos mais adiante no treinamento.

Embedded Labworks

REMOVENDO UM PACOTE

✗ 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.

Embedded Labworks

ADICIONANDO USUÁRIOS E GRUPOS

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 () {    chown ­R user1:group1 ${D}/usr/share/user1    chown ­R user2:group2 ${D}/usr/share/user2}

FILES_${PN} = "/usr/share/user1/* /usr/share/user2/*"

Embedded Labworks

PERMISSÕES DE ARQUIVOS

✗ Por padrão, o sistema de build utiliza o arquivo fs­perms.txt disponível em 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.

✗ Esta configuração deve ser realizada em uma camada separada, por exemplo em uma distribuição.

Embedded Labworks

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.

[...]

${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

[...]

/home                   0755    root    root    false   ­       ­       ­/srv                    0755    root    root    false   ­       ­       ­${prefix}/src           0755    root    root    false   ­       ­       ­${localstatedir}/local  0755    root    root    false   ­       ­       ­

[...]

Embedded Labworks

ADICIONANDO ARQUIVOS

DESCRIPTION = "Some binary library from hell"

SRC_URI[md5sum] = "7356bb3c13516c6d2a0dcfaf9e64f9e8"SRC_URI[sha256sum] = "2ea483c3c4ce87f4a3c851077c3b8ea8e7d5539 8bfb56fa3b0765e65085617bd"

LICENSE = "CLOSED"

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

do_install(){    install ­d ${D}${libdir}    cp ­axr ${WORKDIR}/mylib.so ${D}${libdir}}

FILES_${PN} = "${libdir}/mylib.so"

Embedded Labworks

POSTINSTALL SCRIPTS

✗ Scripts de pós-instalação permitem executar um comando no rootfs após sua criaçã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).

✗ Se o script retornar sucesso, o pacote associado ao script é marcado como instalado, e o script não é mais executado.

✗ Se o script falhar, será executado novamente no primeiro boot do target.

Embedded Labworks

POSTINSTALL SCRIPTS (cont.)

pkg_postinst_PACKAGENAME () {    #!/bin/sh ­e    # Commands to execute}

Embedded Labworks

dhcp.inc

pkg_postinst_dhcp­server() {    mkdir ­p $D/${localstatedir}/lib/dhcp    touch $D/${localstatedir}/lib/dhcp/dhcpd.leases    touch $D/${localstatedir}/lib/dhcp/dhcpd6.leases}

pkg_postinst_dhcp­client() {    mkdir ­p $D/${localstatedir}/lib/dhcp}

Embedded Labworks

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.

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

run_set_root_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_root_pass ; "

Embedded Labworks

ROOTFS DE APENAS LEITURA

✗ Para criar um sistema de arquivo de apenas leitura, basta habilitar na feature de imagem a opção read­only­rootfs.

IMAGE_FEATURES += "read­only­rootfs"

✗ Com esta opção habilitada, durante o boot, o rootfs é remontado com permissão de apenas leitura.

Embedded Labworks

GERANDO IMAGENS

✗ A variável IMAGE_FSTYPES pode ser usada para alterar o tipo de imagem gerada para o rootfs.

IMAGE_FSTYPES += "ext4 squashfs"

✗ Uma lista dos tipos de imagens existentes está disponível na variável IMAGE_TYPES declarada na classe image_types. bbclass.

Embedded Labworks

GERANDO IMAGENS (cont.)

✗ Parâmetros adicionais para a geração da imagem podem ser passados através da variável EXTRA_IMAGECMD.

EXTRA_IMAGECMD_ext3 ?= "­i 4096"

✗ Imagens customizadas podem ser geradas utilizando a variável IMAGE_CMD ou implementando uma classe específica (vide image_types_fsl.bbclass na camada meta­fsl­arm).

Embedded Labworks

ALTERANDO O TAMANHO DA IMAGEM

✗ A variável IMAGE_ROOTFS_SIZE pode ser usada para definir o tamanho final do rootfs (em KBs).

IMAGE_ROOTFS_SIZE = 1048576

✗ 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

Embedded Labworks

ALTERANDO O TAMANHO DA IMAGEM (cont.)

✗ 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 documentação do mecanismo de cálculo do tamanho da imagem está disponível no manual de referência do Yocto Project.

http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-IMAGE_ROOTFS_SIZE

Embedded Labworks

OUTRAS VARIÁVEIS

✗ A variável IMAGE_BASENAME define o nome que será utilizado nos arquivos de saída da imagem, que por padrão recebem o nome da receita.

IMAGE_BASENAME = "myproduct"

✗ Para adicionar suporte à localização, pode-se usar a variável IMAGE_LINGUAS:

IMAGE_LINGUAS = "pt­br en­us"

✗ Procure por variáveis que começam com IMAGE_ no manual de referência do Yocto Project.

Embedded Labworks

CRIANDO UMA DISTRIBUIÇÃO

✗ Se você criar uma imagem com o Yocto project e não alterar a distribuição, estará usando a distribuição de referência Poky.

✗ Para ter mais controle sobre a seleção de pacotes, opções de compilação e outras configurações de baixo nível, você pode criar uma distribuição.

✗ As distribuições são definidas em uma camada através de arquivos de configuração no diretório conf/distro/.

Embedded Labworks

CRIANDO UMA DISTRIBUIÇÃO (cont.)

✗ Para criar uma distribuição, você pode usar como base os arquivos de configuração da distribuição do Poky em meta­yocto/conf/ distro/poky.conf ou do OE-Core em meta/conf/distro/ defaultsetup.conf.

✗ Para usar a distribuição, você deve configurar a variável DISTRO no local.conf com o mesmo nome do arquivo de configuração criado para a sua distribuição.

Embedded Labworks

DISTRIBUIÇÃO DE REFERÊNCIA POKY

$ tree ­L 2 meta­yocto/conf/distro/ ├── include

     │ ├── distro_alias.inc     │ ├── maintainers.inc     │ ├── package_regex.inc     │ ├── poky­floating­revisions.inc     │ ├── recipe_color.inc     │ └── upstream_tracking.inc ├── poky­bleeding.conf ├── poky.conf ├── poky­lsb.conf └── poky­tiny.conf

Embedded Labworks

VARIÁVEIS DE UMA DISTRO

✗ A variável DISTRO_NAME permite configurar o nome da distribuição.

✗ Uma distribuição pode ser versionada com a variável DISTRO_VERSION.

✗ A variável PACKAGE_CLASSES permite definir o tipo de pacote que será utilizado pela distribuição.

Embedded Labworks

VARIÁVEIS DE UMA DISTRO (cont.)

✗ Pacotes específicos da distribuição podem ser adicionados à variável DISTRO_EXTRA_RDEPENDS.

✗ A variável DISTRO_EXTRA_RRECOMMENDS permite adicionar pacotes caso eles existam.

✗ A variável PREFERRED_VERSION é normalmente utilizada para definir as versões dos pacotes que serão utilizados pela distribuição.

Embedded Labworks

VARIÁVEIS DE UMA DISTRO (cont.)

✗ A variável TCMODE permite definir o toolchain que será utilizado para construir a distribuição (contém por padrão "default", que significa construir e utilizar um toolchain interno).

✗ A variável TCLIBC permite definir qual libc será utilizada (eglibc ou uclibc).

✗ As variáveis PREMIRRORS e MIRRORS permitem definir fontes alternativas para download de código-fonte.

Embedded Labworks

DISTRO FEATURES

✗ Uma feature de distribuição permite controlar as características de software da distribuição.

✗ Inclusão automática de pacotes na distribuição.

✗ Em alguns casos, altera o comportamento de scripts de configuração.

Embedded Labworks

bind_9.9.5.bbSUMMARY = "ISC Internet Domain Name Server"HOMEPAGE = "http://www.isc.org/sw/bind/"SECTION = "console/network"

[...]

ENABLE_IPV6 = "­­enable­ipv6=${@bb.utils.contains('DISTRO_FEATURES', 'ipv6',                                                        'yes', 'no', d)}"

EXTRA_OECONF = " ${ENABLE_IPV6} ­­with­randomdev=/dev/random ­­disable­threads \                 ­­disable­devpoll ­­disable­epoll ­­with­gost=no \                 ­­with­gssapi=no ­­with­ecdsa=yes \                 ­­sysconfdir=${sysconfdir}/bind \                 ­­with­openssl=${STAGING_LIBDIR}/.. \                 ­­enable­exportlib ­­with­export­includedir=${includedir} \                       ­­with­export­libdir=${libdir} "

[...]

Embedded Labworks

DISTRO FEATURES (cont.)

✗ Exemplos de features de distribuição:✗ alsa: inclui suporte à camada de áudio do kernel.

✗ directfb: suporte à biblioteca gráfica Directfb.

✗ ipv6: suporte ao protocolo IPv6.

✗ systemd: suporte ao mecanismo de inicialização systemd.

✗ As principais features de distribuição estão disponíveis no manual de referência do Yocto Project.

http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-features-distro

Embedded Labworks

DICAS PARA CUSTOMIZAÇÃO

✗ Utilize o local.conf sempre que precisar realizar testes, mas centralize as modificações no sistema de build em uma camada separada.

✗ Em alguns casos, pode ser necessário implementar mais de uma camada:✗ Normalmente, camadas de distro e BSP são mantidas em camadas

separadas.

✗ Pode ser necessário dividir em camadas caso os projetos sejam mantidos por equipes diferentes.

✗ Divida em camadas as receitas de produtos com características diferentes.

✗ Versione as camadas implementadas em repositórios Git.

Embedded Labworks

DICAS PARA CUSTOMIZAÇÃO (cont.)

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

✗ Ao invés de duplicar arquivos de receitas, use arquivos de append para modificar o comportamento das receitas.

✗ Para atualizar a versão de uma receita, crie um novo arquivo de receita, e se possível contribua de volta à comunidade.

Embedded Labworks

DICAS PARA CUSTOMIZAÇÃO (cont.)

✗ Se necessário, crie uma distribuição com as configurações e políticas que servirão de base para seus produtos.

✗ Crie uma receita de imagem para cada produto a ser desenvolvido.

✗ Se achar interessante, crie variantes de receitas de imagem para diferentes tipos de build (debug, produção, etc).

Embedded Labworks

LABORATÓRIO

Customizando o sistema

Embedded Labworks

Yocto Project

Board Support Package

Embedded Labworks

BSP E MACHINE

✗ 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 implementar uma machine em uma camada de BSP.

✗ Por padrão, o Yocto Project já possui algumas machines implementadas (QEMU, Beaglebone, Edgerouter, etc).

Embedded Labworks

BSP E MACHINE (cont.)

✗ No início do desenvolvimento do seu produto, verifique se já existe uma implementação de machine para a sua plataforma de hardware. Caso contrário, será necessário desenvolvê-la.

✗ Uma base de dados de camadas de BSP e machines existentes é disponibilizada pela comunidade do Yocto Project e do OpenEmbedded na Internet.

http://layers.openembedded.org/layerindex/branch/master/machines/

Embedded Labworks

CAMADAS DE BSP

✗ Machines são implementadas em camadas de BSP, que possuem a mesma aparência de camadas de distribuição ou de software:

✗ Contém um arquivo de configuração da camada (layer.conf).

✗ Contém diversas receitas para a compilação do BSP (bootloader, kernel, servidor gráfico, ferramentas de profiling).

✗ Contém a implementação de classes adicionais que serão usadas pelas receitas da camada.

✗ Porém, diferentemente das camadas de distribuição e software, a camada de BSP possui também arquivos de configuração de machines, disponíveis em conf/machine/.

Embedded Labworks

META-YOCTO-BSP

$ tree ­L 3 meta­yocto­bsp/./meta­yocto­bsp/

 ├── conf     │ ├── layer.conf     │ └── machine         │ ├── beaglebone.conf         │ ├── edgerouter.conf         │ ├── genericx86­64.conf         │ ├── genericx86.conf         │ ├── include         │ └── mpc8315e­rdb.conf ├── recipes­bsp ├── recipes­core ├── recipes­graphics └── recipes­kernel

Embedded Labworks

CRIANDO UMA CAMADA DE BSP

✗ Uma camada de BSP pode ser criada manualmente ou através da ferramenta yocto­bsp:

$ yocto­bsp ­h

✗ Está disponível um guia para a criação de BSPs no site do Yocto Project.

http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html

Embedded Labworks

CRIANDO UMA MACHINE

✗ Uma das principais tarefas na implementação de um BSP para o Yocto Project está na definição do arquivo de configuração da máquina (machine).

✗ Neste arquivo, deve-se definir informações sobre o bootloader, kernel, drivers, camada gráfica, parâmetros de otimização do compilador, etc.

✗ Uma forma de implementar uma machine é se basear na implementação de uma machine existente cujas características de hardware são próximas à plataforma-alvo.

Embedded Labworks

DEFININDO A ARQUITETURA

✗ A arquitetura do hardware é definida na machine normalmente incluindo um arquivo que contém as configurações para uma determinada plataforma de hardware.

include conf/machine/include/tune­cortexa9.inc

✗ Diversos arquivos de configuração de arquitetura estão disponíveis na camada do OpenEmbedded Core em meta/conf/machine/include/.

✗ Neste arquivo diversas variáveis serão configuradas (TARGET_ARCH, DEFAULTTUNE, TUNE_ARCH, etc), de forma que o sistema de build tenha conhecimento da arquitetura de hardware, possa gerar o toolchain, compilar pacotes dependentes da plataforma de hardware, etc.

Embedded Labworks

BOOTLOADER

✗ Será necessário implementar uma receita para compilar o bootloader para a plataforma de hardware.

meta­fsl­arm/recipes­bsp/u­boot/u­boot­fslc_2015.04.bb

✗ É possível também utilizar uma receita oficial do Yocto Project, desde que suporte a plataforma de hardware.

meta/recipes­bsp/u­boot/u­boot_2015.01.bb

Embedded Labworks

KERNEL LINUX

✗ Será necessário implementar uma receita para compilar o kernel Linux para a plataforma de hardware.

meta­fsl­arm­extra/recipes­kernel/linux/linux­wandboard_3.10.53.bb

✗ É possível também utilizar uma receita oficial do Yocto Project (linux­yocto), desde que suporte a plataforma de hardware.

meta/recipes­kernel/linux/linux­yocto_3.19.bb

Embedded Labworks

PROVIDES

✗ Algumas receitas, como as receitas para compilar o bootloader e o kernel, irão prover os mesmos pacotes.

✗ Para que uma receita possa indicar que ela irá prover determinado pacote (bootloader, kernel, etc), foi criado 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"

Embedded Labworks

PREFERRED_PROVIDER

✗ Na configuração da machine, a variável PREFERRED_PROVIDER pode ser usada para escolher a receita que será usada para compilar o kernel para a plataforma de hardware:

PREFERRED_PROVIDER_virtual/kernel ?= "linux­wandboard"

✗ O mesmo vale para o bootloader:

PREFERRED_PROVIDER_virtual/bootloader ?= "u­boot­fslc"

✗ Se existir mais de uma receita com versões diferentes, é possível escolher a versão com a variável PREFERRED_VERSION:

PREFERRED_VERSION_linux­wandboard ?= "3.10.53"

Embedded Labworks

VARIÁVEIS COMUNS

✗ A compilação do U-Boot pode ser parametrizada com algumas variáveis, incluindo:✗ UBOOT_MACHINE: configuração da plataforma de hardware.

✗ UBOOT_ENTRYPOINT e UBOOT_LOADADDRESS: argumentos para a ferramenta uboot­mkimage.

✗ A compilação do kernel Linux pode ser parametrizada com algumas variáveis, incluindo:✗ KERNEL_IMAGETYPE: imagem do kernel a ser gerada (padrão é a zImage).

✗ KERNEL_DEVICETREE: arquivo do device tree que deve ser compilado.

✗ As variáveis SERIAL_CONSOLE e SERIAL_CONSOLES podem ser usadas para definir as portas TTY que serão utilizadas para iniciar a aplicação getty.

Embedded Labworks

SOC_FAMILY

✗ A variável SOC_FAMILY pode ser usada para definir informações sobre a família de SoCs compatíveis com a plataforma.

SOC_FAMILY = "mx6:mx6q:wandboard"

✗ Ao incluir o arquivo soc­family.inc, o conteúdo da variável SOC_FAMILY será adicionado à variável MACHINEOVERRIDES.

MACHINEOVERRIDES="armv7a:mx6:mx6q:wandboard:wandboard­quad"

✗ Durante o processamento de uma receita, o conteúdo da variável MACHINEOVERRIDES é adicionado à variável OVERRIDES, permitindo o mecanismo de atribuição condicional de variáveis visto anteriormente.

Embedded Labworks

MACHINE_FEATURES

✗ A variável MACHINE_FEATURES pode ser usada para definir as funcionalidades presentes em uma machine.✗ touchscreen: o hardware tem uma interface de touchscreen.

✗ wifi: o hardware tem uma interface wifi.

✗ bluetooth: o hardware tem uma interface bluetooth.

✗ As machine features são utilizadas para habilitar ou desabilitar a inclusão de determinado pacote na imagem.

✗ A principais machine features estão disponíveis no manual de referência do Yocto Project.

http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-features-machine

Embedded Labworks

packagegroup-core-directfb.bbSUMMARY = "DirectFB without X11"LICENSE = "MIT"

PACKAGE_ARCH = "${MACHINE_ARCH}"

inherit packagegroup

TOUCH = '${@bb.utils.contains(             "MACHINE_FEATURES",  "touchscreen",                                    

  "tslib tslib­calibrate tslib­tests",              "",d)}'

RDEPENDS_${PN} = " \        directfb \        directfb­examples \        pango \        pango­modules \        fontconfig \        ${TOUCH} \

Embedded Labworks

MACHINE FEATURES X DISTRO FEATURES

✗ Machine features e distro features trabalham de forma conjunta para adicionar o suporte à determinada funcionalidade no sistema gerado.

✗ Por exemplo, se a machine suporta alsa, mas a distribuição não, as bibliotecas alsa serão compiladas, mas as aplicações serão compiladas sem suporte à biblioteca alsa.

✗ Da mesma forma, se a distribuição suporta alsa, mas a machine não, as aplicações serão compiladas com suporte à alsa, mas a biblioteca alsa não será compilada.

Embedded Labworks

MAIS ALGUMAS VARIÁVEIS

✗ Algumas variáveis podem ser usadas para incluir pacotes de software na imagem gerada:✗ MACHINE_EXTRA_RDEPENDS

✗ MACHINE_EXTRA_RRECOMMENDS

✗ MACHINE_ESSENTIAL_EXTRA_RDEPENDS

✗ MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS

✗ O manual de referência do Yocto Project possui mais informações sobre as principais variáveis que podem ser usadas na definição de uma machine.

http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-varlocality-config-machine

Embedded Labworks

wandboard-quad.conf#@TYPE: Machine#@NAME: Wandboard i.MX6 Wandboard Quad#@SOC: i.MX6Q#@DESCRIPTION: Machine configuration for i.MX6 Wandboard Quad#@MAINTAINER: Alfonso Tames <alfonso@tames.com>

include include/wandboard.inc

SOC_FAMILY = "mx6:mx6q:wandboard"

UBOOT_MACHINE = "wandboard_quad_config"

KERNEL_DEVICETREE = "imx6q­wandboard.dtb"

MACHINE_FEATURES += "bluetooth wifi"

MACHINE_EXTRA_RRECOMMENDS += " \  bcm4329­nvram­config \  bcm4330­nvram­config \"

Embedded Labworks

wandboard.inc

# Common settings for wandboard boards

include conf/machine/include/imx­base.incinclude conf/machine/include/tune­cortexa9.inc

PREFERRED_PROVIDER_virtual/kernel ?= "linux­wandboard"PREFERRED_VERSION_linux­wandboard ?= "3.10.53"

SERIAL_CONSOLE = "115200 ttymxc0"

MACHINE_FEATURES += "pci touchscreen"

KERNEL_IMAGETYPE = "zImage"

Embedded Labworks

USANDO A MACHINE

✗ Para usar a machine criada, basta adicionar sua camada no bblayers.conf.

BBLAYERS = "${BSPDIR}/sources/poky/meta \

            ${BSPDIR}/sources/poky/meta­yocto \

            ${BSPDIR}/sources/meta­openembedded/meta­oe \

            ${BSPDIR}/sources/meta­fsl­arm \

            ${BSPDIR}/sources/meta­fsl­arm­extra"

✗ E configurar a variável MACHINE no local.conf com o nome utilizado no arquivo de configuração da machine.

MACHINE ??= 'wandboard­quad'

Embedded Labworks

ESTENDENDO O BSP

✗ Para estender um BSP existente, é aconselhável criar uma camada para centralizar as alterações que serão realizadas.

✗ Use arquivos de append para customizar as receitas do BSP.

✗ Use arquivos de patch para controlar as alterações nos componentes de software (bootloader, kernel, etc).

Embedded Labworks

CONFIGURANDO O KERNEL

✗ Uma necessidade comum na customização do 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

✗ Neste caso, a configuração será realizada diretamente no diretório de compilação do kernel, e poderá ser perdida em uma eventual recompilação do kernel ou da imagem.

Embedded Labworks

CONFIGURANDO O KERNEL (cont.)

✗ Portanto, é necessário um mecanismo para salvar e manter uma configuração customizada do kernel.

✗ Existem basicamente duas formas para salvar uma configuração customizada do kernel:

✗ Sobrescrever a configuração padrão fornecida pelo BSP.

✗ Criar fragmentos de configuração.

Embedded Labworks

SOBRESCREVENDO A CONFIGURAÇÃO

✗ Para sobrescrever a configuração padrão do BSP, você deve:✗ Criar na sua camada a estrutura de diretórios recipes­kernel/ 

linux/files/.

✗ Criar um arquivo de append da receita de compilação do kernel e salvar em recipes­kernel/linux/.

✗ Salvar o arquivo de configuração do kernel com o nome defconfig em recipes­kernel/linux/files/.

Embedded Labworks

SOBRESCREVENDO A CONFIGURAÇÃO (cont.)

$ tree ­L 4 recipes­kernel/recipes­kernel

 └── linux      ├── files          │ └── defconfig      └── linux­wandboard_3.10.53.bbappend

$ cat linux­myboard.bbappendFILESEXTRAPATHS_prepend := "${THISDIR}/files:"SRC_URI += "file://defconfig"

Embedded Labworks

FRAGMENTOS DE CONFIGURAÇÃO

✗ Os fragmentos de configuração permitem a adição de novas opções no arquivo de configuração do kernel.

✗ Para customizar a configuração padrão do kernel usando fragmentos de configuração, é necessário:

✗ Criar na sua camada a estrutura de diretórios recipes­kernel/ linux/files/.

✗ Criar um arquivo de append da receita de compilação do kernel e salvar em recipes­kernel/linux/.

✗ Salvar o arquivo que contém os fragmentos de configuração no diretório recipes­kernel/linux/files/ com a extensão .cfg.

Embedded Labworks

SOBRESCREVENDO A CONFIGURAÇÃO (cont.)

$ tree ­L 4 recipes­kernel/recipes­kernel

 └── linux      ├── files          │ └── ntfs.cfg      └── linux­yocto_3.19.bbappend

$ cat files/ntfs.cfgCONFIG_NTFS_FS=y

$ cat linux­myboard.bbappendFILESEXTRAPATHS_prepend := "${THISDIR}/files:"SRC_URI += "file://ntfs.cfg"

Embedded Labworks

GERANDO FRAGMENTOS DE CONFIGURAÇÃO

✗ Executar a tarefa de configuração do kernel:

$ bitbake ­c kernel_configme linux­yocto

✗ Editar a configuração:

$ bitbake ­c menuconfig linux­yocto

✗ Gerar o arquivo de fragmentos de configuração do kernel:

$ bitbake ­c diffconfig linux­yocto

✗ O arquivo de fragmentos de configuração do kernel estará disponível no diretório de processamento da receita em ${WORKDIR}/fragment.cfg.

Embedded Labworks

APLICANDO PATCHES

✗ Para aplicar patches ao kernel original do BSP é necessário:✗ Criar na sua camada a estrutura de diretórios recipes­kernel/ 

linux/files/.

✗ Criar um arquivo de append da receita de compilação do kernel e salvar em recipes­kernel/linux/.

✗ Salvar os patches no diretório recipes­kernel/linux/files/.

Embedded Labworks

APLICANDO PATCHES (cont.)

$ tree ­L 4 recipes­kernel/recipes­kernel/

 └── linux      ├── files          │ └── 0001­fixbug.patch      └── linux­wandboard_3.10.53.bbappend

$ cat linux­myboard.bbappendFILESEXTRAPATHS_prepend := "${THISDIR}/files:"SRC_URI += "file://0001­fixbug.patch"

Embedded Labworks

MÓDULOS DO KERNEL

✗ Para compilar um módulo do kernel, basta criar uma receita herdando a classe module.bbclass.

✗ Algumas variáveis precisam ser definidas, incluindo SUMMARY, LICENSE, LIC_FILES_CHKSUM e SRC_URI.

✗ Uma receita de exemplo para compilar um módulo do kernel está disponível no Poky em  meta­skeleton/recipes­kernel/hello­

mod/hello­mod_0.1.bb.

Embedded Labworks

hello-mod_0.1.bb

SUMMARY = "Example of how to build an external Linux kernel module"

LICENSE = "GPLv2"LIC_FILES_CHKSUM = "file://COPYING;md5=12f884d2ae1ff87c09e5b7c cc2c4ca7e"

inherit module

PR = "r0"PV = "0.1"

SRC_URI = "file://Makefile \           file://hello.c \           file://COPYING"

S = "${WORKDIR}"

Embedded Labworks

ALTERANDO OS FONTES DO KERNEL

✗ Para utilizar uma versão customizada do kernel você pode criar uma nova receita.

✗ Um exemplo de receita para este caso está disponível no Poky em meta­skeleton/recipes­kernel/linux/linux­yocto­custom.bb.

✗ Copie a receita para a sua camada e renomeie o arquivo no padrão <recipe_name>_<kernel_version>.bb.

✗ Altere as variáveis da receita de acordo com a configuração do seu kernel.

Embedded Labworks

linux-yocto-custom.bb

inherit kernelrequire recipes­kernel/linux/linux­yocto.inc

SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/ torvalds/linux.git;protocol=git;nocheckout=1;name=machine"

LINUX_VERSION ?= "3.4"LINUX_VERSION_EXTENSION ?= "­custom"

SRCREV_machine="76e10d158efb6d4516018846f60c2ab5501900bc"

PR = "r1"PV = "${LINUX_VERSION}+git${SRCPV}"

COMPATIBLE_MACHINE = "(^$)"

Embedded Labworks

ADVANCED METADATA

✗ Outra forma de configurar o kernel padrão do Yocto Project (linux­yocto) é através de um recurso chamado Advanced Metadata.

✗ A idéia é organizar patches e fragmentos de configuração do kernel em funcionalidades.

✗ As definições das funcionalidades ficam em arquivos de descrição com a extensão scc, e podem ser habilitadas através da variável KERNEL_FEATURES.

✗ A documentação completa deste recurso está disponível no manual de desenvolvimento do kernel para o Yocto Project.

https://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html#kernel-dev-advanced

Embedded Labworks

ADVANCED METADATA (cont.)

✗ Exemplo de um arquivo de descrição de funcionalidade (smp.scc):

define KFEATURE_DESCRIPTION "Enable SMP"

kconf hardware smp.cfg

patch smp­support.patch

✗ Habilitando a funcionalidade:

KERNEL_FEATURES += "features/smp.scc"

Embedded Labworks

LABORATÓRIO

Customizando o BSP

Embedded Labworks

Yocto Project

SDK

Embedded Labworks

TRABALHANDO 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, para auxiliar no desenvolvimento de aplicações, os sistemas de build normalmente disponibilizam para o usuário um conjunto de ferramentas de desenvolvimento, que chamamos de SDK.

Embedded Labworks

SDK

✗ Um SDK (Software Development Kit) é um conjunto de ferramentas que possibilitam o desenvolvimento de aplicações para um determinado target (plataforma de hardware, sistema operacional, ambiente de execução, etc).

✗ É composto por um conjunto de componentes, incluindo:✗ Toolchain (compilador, linker, debugger, etc).

✗ Sysroot (bibliotecas e arquivos de cabeçalho).

Embedded Labworks

TOOLCHAIN

✗ Sendo o host a plataforma de desenvolvimento e target a plataforma-alvo, existem basicamente quatro tipos de toolchain:✗ Native toolchain: roda no host e gera código para o host.

✗ Cross-native: roda no target e gera código para o target.

✗ Cross-compiling toolchain: roda o host e gera código para o target.

✗ Canadian toolchain: mesmo que cross-compiling toolchain, porém o host que gerou o toolchain é diferente do host que irá executar o toolchain.

✗ Apesar do cross-native ser uma opção para o desenvolvimento em Linux embarcado, o mais comum é o uso de um cross-compiling toolchain.

Embedded Labworks

SYSROOT

✗ O sysroot é um diretório que contém as bibliotecas e arquivos de cabeçalho necessários para gerar os binários que serão executados no target.

✗ É normalmente baseado no rootfs da imagem gerada para o target.

Embedded Labworks

POKY SDK

✗ O sistema de build Poky é capaz de gerar um SDK para o desenvolvimento de aplicações.

✗ O SDK gerado é autocontido e pode ser instalado em qualquer máquina de desenvolvimento com a mesma arquitetura de hardware do host que gerou o SDK.

✗ Os dois principais mecanismos de geração de SDK do Poky são:✗ meta­toolchain: SDK genérico sem o sysroot.

✗ populate_sdk: SDK completo com o sysroot para o desenvolvimento de aplicações.

Embedded Labworks

META-TOOLCHAIN

✗ Um SDK genérico pode ser gerado processando a receita meta­toolchain.

$ bitbake meta­toolchain

✗ Ao final do processo de compilação, um script de instalação do SDK estará disponível em tmp/deploy/sdk.

✗ Ao executar o script, o toolchain é instalado por padrão em /opt/poky/<release>.

✗ Pode ser usado para o desenvolvimento de aplicações bare-metal como o bootloader ou o kernel Linux.

Embedded Labworks

POPULATE_SDK

✗ Um SDK completo com o sysroot baseado na imagem do sistema pode ser gerado processando a tarefa populate_sdk da receita da imagem:

$ bitbake <image> ­c populate_sdk

✗ Ao final do processo de compilação, um script de instalação do SDK estará disponível em tmp/deploy/sdk.

✗ Por padrão, o toolchain é instalado em /opt/poky/<release>.

✗ Este é o melhor mecanismo para gerar e distribuir um SDK para o desenvolvimento de aplicações baseado em uma determinada imagem para o target.

Embedded Labworks

INSTALANDO O SDK

$ cd tmp/deploy/sdk/

$ ./poky­eglibc­x86_64­core­image­minimal­cortexa9hf­vfp­neon­toolchain­1.6.1.shEnter target directory for SDK (default: /opt/poky/1.6.1): You are about to install the SDK to "/opt/poky/1.6.1". Proceed[Y/n]?Extracting SDK...doneSetting it up...doneSDK has been successfully set up and is ready to be used.

$ ls /opt/poky/1.6.1/environment­setup­cortexa9hf­vfp­neon­poky­linux­gnueabi  site­config­cortexa9hf­vfp­neon­poky­linux­gnueabi  sysrootsversion­cortexa9hf­vfp­neon­poky­linux­gnueabi

Embedded Labworks

USANDO O SDK

✗ Para utilizar o SDK, basta carregar o script de configuração do ambiente:

$ source /opt/poky/1.6.1/environment­setup­cortexa9hf­vfp­neon­

poky­linux­gnueabi

✗ Diversas variáveis serão criadas no ambiente de desenvolvimento (CC, CFLAGS, CXX, LD, LDFLAGS, etc).

✗ Por exemplo, para compilar uma aplicação em C:

$ $CC teste.c ­o teste

✗ Abra o script de configuração do ambiente para verificar a lista completa de variáveis criadas.

Embedded Labworks

ECLIPSE

✗ O Eclipse é uma IDE bastante popular para o desenvolvimento de software em diversas linguagens como C, C++ e Java.

✗ O Yocto Project possui um plugin para integrar o Eclipse com o SDK gerado pelo Poky.

✗ Este plugin faz parte do Yocto Project ADT (Application Development Toolkit).

http://www.yoctoproject.org/docs/current/adt-manual/adt-manual.html

Embedded Labworks

PLUGIN ECLIPSE

✗ Este plugin de integração com o Eclipse permite:✗ Criar um projeto que utiliza a toolchain gerado pelo Yocto Project.

✗ Instalar e testar a aplicação no target.

✗ Depurar a aplicação remotamente no target.

✗ Testar a aplicação no QEMU.

✗ Executar ferramentas de tracing e profiling como OProfile, Lttng, PowerTOP, LatencyTOP e Perf.

Embedded Labworks

PREPARANDO O HOST

✗ Para que esta integração funcione, é necessário:✗ Instalar uma versão suportada do Eclipse (Luna ou Kepler).

✗ Instalar alguns plugins de desenvolvimento (LTTng, RSE, Target Management Terminal, TCF, Autotools).

✗ Instalar o plugin do Yocto Project.

✗ Configurar no Eclipse o toolchain que foi gerado pelo Poky.

✗ Configurar a comunicação com o target.

✗ Mais informações sobre esta configuração no manual de desenvolvimento do Yocto Project.

http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#adt-eclipse

Embedded Labworks

PREPARANDO O TARGET

✗ Para o target suportar o Eclipse, é necessário recompilar a imagem com a feature de imagem eclipse­debug habilitada.

IMAGE_FEATURES += "eclipse­debug"

✗ Esta feature irá incluir na imagem os pacotes gdbserver, tcf­agent e openssh­sftp­server.

✗ Com estes pacotes instalados no target, configure a rede e teste a comunicação com o host.

Embedded Labworks

LABORATÓRIO

Gerando o SDK e integrando com o Eclipse

Embedded Labworks

Yocto Project

Ferramentas

Embedded Labworks

HOB

✗ O Hob é uma interface gráfica para o BitBake, visando facilitar a configuração e geração de uma imagem Linux customizada.

https://www.yoctoproject.org/tools-resources/projects/hob

✗ A primeira versão do Hob foi disponibilizada no Yocto Project 1.1.

✗ O Hob não é mais mantido ativamente desde a versão 1.6, e deverá ser substituído em breve pelo Toaster.

✗ Para executar o Hob:

$ hob

Embedded Labworks

HOB (cont.)

Embedded Labworks

FUNCIONALIDADES DO HOB

✗ Com o Hob, é possível:✗ Adicionar ou remover camadas.

✗ Selecionar uma máquina e uma receita de imagem.

✗ Customizar a imagem (tamanho, sistema de arquivos, tipo de empacotamento, distro, etc).

✗ Customizar a receita da imagem, adicionando ou removendo pacotes.

✗ Executar e monitorar o processo de compilação.

✗ O manual do Hob está disponível em:

https://www.yoctoproject.org/documentation/hob-manual

Embedded Labworks

TOASTER

✗ O Toaster, originalmente chamado de Web Hob, é uma interface Web para o BitBake.

https://www.yoctoproject.org/tools-resources/projects/toaster

✗ Liberado a partir do release 1.6 "Daisy" do Yocto Project, permite configurar e compilar uma imagem, e analisar informações do processo de build através de uma interface web.

✗ Para iniciar o Toaster:

$ source toaster start

Embedded Labworks

TOASTER (cont.)

Embedded Labworks

FUNCIONALIDADES DO TOASTER

✗ O Toaster possui diversas funcionalidades, incluindo:✗ Configurar e compilar imagens.

✗ Ver dependências de receitas, pacotes e tarefas.

✗ Analisar as informações de compilação das receitas, incluindo dados de performance.

✗ Analisar erros de compilação.

✗ A documentação completa do Toaster está disponível no site do Yocto Project.

https://www.yoctoproject.org/docs/current/toaster-manual/toaster-manual.html

Embedded Labworks

BUILD APPLIANCE

✗ O Build Appliance é uma imagem de máquina virtual que permite experimentar e estudar o Yocto Project.

✗ Não é recomendado para um ambiente de desenvolvimento/produção.

✗ A imagem da máquina virtual está disponível na página de downloads de ferramentas do Yocto Project.

https://www.yoctoproject.org/downloads/tools

✗ O manual do Build Appliance está disponível no site do Yocto Project.

https://www.yoctoproject.org/documentation/build-appliance-manual

Embedded Labworks

AUTOBUILDER

✗ O Autobuilder permite integrar e testar as mudanças realizadas por diferentes desenvolvedores de um projeto utilizando o Yocto Project.

✗ É capaz de notificar quando uma alteração (commit) no projeto quebrar o build.

✗ Permite também alimentar o cache de compilação (shared state), agilizando a compilação nas máquinas dos desenvolvedores.

Embedded Labworks

AUTOBUILDER (cont.)

✗ O Yocto Project utiliza o Buildbot como framework para a implementação do Autobuilder.

http://buildbot.net/

✗ Mais informações no site do Yocto Project.

http://autobuilder.yoctoproject.org/

Embedded Labworks

SHARED STATE

✗ Por padrão, o sistema de build compila tudo do zero, a não ser que o BitBake perceba que partes do processo de build não precisam ser executadas novamente.

✗ Devido ao tempo de compilação, compilar sempre um sistema do zero é totalmente improdutivo.

✗ Por este motivo, o Yocto Project implementa um mecanismo de compilação incremental através de um cache de compilação chamado de shared state (sstate).

Embedded Labworks

SHARED STATE (cont.)

✗ Por padrão, o cache de compilação é armazenado dentro do diretório de build em sstate­cache/.

✗ É possível mudar esta configuração definindo a variável SSTATE_DIR no local.conf.

✗ Pode-se usar também a variável SSTATE_MIRRORS para definir locais alternativos para o sstate (diretório local, HTTP ou FTP).

Embedded Labworks

SHARED STATE (cont.)

✗ É recomendado o uso de NFS para compartilhar um diretório do sstate entre múltiplos desenvolvedores.

✗ O autobuilder pode também ajudar a minizar o tempo de compilação populando o diretório do sstate.

✗ Para limpar o cache de compilação de uma receita, basta executar a tarefa cleansstate.

$ bitbake <recipe> ­c cleansstate

Embedded Labworks

BUILD HISTORY

✗ Durante o desenvolvimento, alterações em receitas podem impactar em mudanças na imagem final do sistema, causando possíveis regressões.

✗ O 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 de uma classe (buildhistory.bbclass), e possibilita identificar, por exemplo:✗ Alterações em qualquer arquivo do sistema.

✗ Inclusões ou remoções de arquivos.

✗ Mudanças de versões de pacotes.

Embedded Labworks

HABILITANDO O BUILD HISTORY

✗ Para habilitar o build history, basta herdar a classe buildhistory no local.conf:

INHERIT += "buildhistory"

BUILDHISTORY_COMMIT = "1"

✗ A variável BUILDHISTORY_COMMIT habilita o commit do build history em um repositório git.

✗ O build history pode aumentar um pouco o tempo de compilação, principalmente para imagens, além de ocupar mais espaço em disco.

Embedded Labworks

USANDO O BUILD HISTORY

✗ O build history é armazenado por padrão dentro do diretório de build em buildhistory/.

✗ O diretório do build history pode ser redefinido através da variável BUILDHISTORY_DIR.

✗ Informações sobre os pacotes instalados são armazenados no build history em packages/.

✗ Informações sobre a imagem gerada são armazenadas no build history em images/.

Embedded Labworks

PACKAGES

$ cat buildhistory/packages/i586­poky­linux/dropbear/dropbear/ latestPV = 2014.63PR = r0RPROVIDES = ssh sshdRDEPENDS = eglibc (>= 2.19) update­alternatives­opkg zlib (>= 1.2.8)RRECOMMENDS = update­rc.dPKGSIZE = 279834FILES = /usr/bin/* /usr/sbin/* /usr/lib/dropbear/* /usr/lib/ lib*.so.* /etc /com /var /bin/* /sbin/* /lib/*.so.* /lib/ude v/rules.d /usr/lib/udev/rules.d /usr/share/dropbear /usr/lib/ dropbear/* /usr/share/pixmaps /usr/share/applications [...]

Embedded Labworks

IMAGES

$ tree buildhistory/images/buildhistory/images/

 └── qemux86      └── eglibc          └── core­image­minimal              ├── build­id              ├── depends.dot              ├── depends­nokernel.dot              ├── [...]              ├── files­in­image.txt              ├── image­files                  │ └── etc                      │ ├── group                      │ └── passwd              ├── image­info.txt              ├── installed­package­names.txt              ├── installed­package­sizes.txt              └── installed­packages.txt

Embedded Labworks

ANALISANDO COM O GIT

✗ Você pode analisar as diferenças entre os builds com o git.

$ git log ­p

✗ Ou então usar a ferramenta buildhistory­diff, que possui uma saída mais amigável:

$ buildhistory­diff . HEAD^

✗ Ou ainda configurar o sistema de build para disponibilizar o build history pela web.

http://git.yoctoproject.org/cgit/cgit.cgi/buildhistory-web/about/

Embedded Labworks

GIT LOG

$ git log ­pcommit aa181f597039206b45fd0795b19e288d6a348ed9Author: buildhistory <buildhistory@poky>Date:   Wed May 28 15:58:07 2014 ­0300

    packages: Build 201405281556 of poky 1.6 for machine qemux86 on sprado­desktop        cmd: bitbake core­image­minimal

diff ­­git a/packages/all­poky­linux/packagegroup­core­ssh­dropbear/latest b/packages/all­poky­linux/packagegroup­core­ssh­dropbear/latestnew file mode 100644index 0000000..141be4c[...]

Embedded Labworks

GIT LOG (cont.)

[...]­­­ /dev/null+++ b/packages/all­poky­linux/packagegroup­core­ssh­dropbear/latest@@ ­0,0 +1,4 @@+PV = 1.0+PR = r1+DEPENDS = +PACKAGES = packagegroup­core­ssh­dropbear packagegroup­core­ssh­dropbear­dbg packagegroup­core­ssh­dropbear­dev packagegroup­core­ssh­dropbear­ptest

Embedded Labworks

BUILDHISTORY-DIFF

$ buildhistory­diff . HEAD^     Changes to images/qemux86_64/eglibc/core­image­minimal (files­in­image.txt):        /etc/anotherpkg.conf was added        /sbin/anotherpkg was added        * (installed­package­names.txt):        *   anotherpkg was added     Changes to images/qemux86_64/eglibc/core­image­minimal (installed­package­names.txt):        anotherpkg was added     packages/qemux86_64­poky­linux/v86d: PACKAGES: added "v86d­extras"        * PR changed from "r0" to "r1"        * PV changed from "0.1.10" to "0.1.12"     packages/qemux86_64­poky­linux/v86d/v86d: PKGSIZE changed from 110579 to 144381 (+30%)        * PR changed from "r0" to "r1"        * PV changed from "0.1.10" to "0.1.12"

Embedded Labworks

TRACING E PROFILING

✗ Ferramentas de tracing possibilitam a análise do fluxo de execução de aplicações e do sistema.

✗ Ferramentas de profiling possibilitam a análise de performance das aplicações e do sistema.

✗ Com o Yocto Project é possível gerar uma imagem com diversas ferramentas de tracing e profiling, incluindo perf, ftrace, systemtap, oprofile, sysprof, LTTng e blktrace.

Embedded Labworks

TRACING E PROFILING (cont.)

✗ Existem duas formas de gerar uma imagem com suporte às ferramentas de tracing e profiling:

✗ Compilar uma receita de imagem com final "­sdk":$ bitbake core­image­sato­sdk

✗ Adicionar a feature de imagem tools­profile:

EXTRA_IMAGE_FEATURES += "tools­profile"

✗ Mais informações na documentação do Yocto Project.

http://www.yoctoproject.org/docs/1.6/profile-manual/profile-manual.html

Embedded Labworks

LICENÇAS

✗ Uma das preocupações ao desenvolver produtos que contém software livre é a aderência às licenças de software.

✗ Existem normalmente três requisitos que o desenvolvedor deve se preocupar no que se refere à licenças de software:✗ Disponibilização do código-fonte.

✗ Liberação de uma cópia do texto da licença junto com o binário.

✗ Disponibilização dos scripts de compilação e das alterações realizadas no software.

✗ O Yocto Project é capaz de ajudar nestes três requisitos para garantir aderência às licenças de software.

Embedded Labworks

LICENÇAS (cont.)

✗ Através das variáveis LICENSE e LIC_FILES_CHKSUM, o sistema de build é capaz de identificar e monitorar as licenças de todos os pacotes incluídos na imagem.

✗ Para previnir com que componentes de software de uma determinada licença sejam compilados, pode-se usar a variável INCOMPATIBLE_LICENSE. Exemplo:

INCOMPATIBLE_LICENSE = "GPLv3"

Embedded Labworks

LICENÇAS (cont.)

✗ Receitas com licenças comerciais ou especiais são indicadas através da variável LICENSE_FLAGS, e são desabilitadas por padrão.

LICENSE_FLAGS = "commercial"

✗ Para habilitar o processamento de receitas com este tipo de restrição de licença, podemos utilizar a variável LICENSE_FLAGS_WHITELIST.

LICENSE_FLAGS_WHITELIST = "commercial"

✗ O diretório tmp/deploy/licenses/<package_name> possui uma cópia da licença de cada componente de software utilizado no sistema gerado.

Embedded Labworks

LIBERANDO O CÓDIGO-FONTE

✗ Uma forma de liberar o código-fonte é herdar a classe archiver no local.conf:

INHERIT += "archiver"

ARCHIVER_MODE[src] = "original"

✗ Ao final da compilação, os fontes em formato tarball e seus respectivos patches estarão disponíveis no diretório de build em tmp/deploy/sources.

✗ Se necessário, use a variável COPYLEFT_LICENSE_EXCLUDE para excluir componentes de software de determinada licença.

Embedded Labworks

COPIANDO A LICENÇA

✗ Algumas licenças requerem que o texto da licença seja distribuído junto com o binário.

✗ Para isso, deve-se declarar as variáveis abaixo no local.conf:

COPY_LIC_MANIFEST = "1"

COPY_LIC_DIRS = "1"

Embedded Labworks

SCRIPTS DE COMPILAÇÃO

✗ Para prover os scripts de compilação, basta fornecer ao usuário uma camada com os metadados das suas alterações, e um procedimento para baixar os repositórios e compilar a imagem.

$ git clone ­b daisy git://git.yoctoproject.org/poky

$ cd 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

Embedded Labworks

LABORATÓRIO

Ferramentas de suporte

Embedded Labworks

Linux Embarcado

E agora?

Embedded Labworks

RECURSOS ONLINE

✗ Yocto Project:

https://www.yoctoproject.org/

✗ OpenEmbedded:

http://www.openembedded.org/wiki/Main_Page

✗ BitBake:

http://git.openembedded.org/bitbake/

Embedded Labworks

RECURSOS ONLINE (cont.)

✗ Yocto Project Quick Start:

https://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html

✗ Yocto Project Wiki:

https://wiki.yoctoproject.org/wiki/Main_Page

✗ Yocto Project Reference Manual:

http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html

Embedded Labworks

RECURSOS ONLINE (cont.)

✗ BitBake User Manual:

http://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html

✗ Yocto Project Development Manual:

http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html

✗ Yocto Project Application Developer's Manual:

http://www.yoctoproject.org/docs/current/adt-manual/adt-manual.html

Embedded Labworks

RECURSOS ONLINE (cont.)

✗ Yocto Project Linux Kernel Development Manual:

http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html

✗ Yocto Project BSP Developer's Guide:

http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html

✗ Como submeter um patch:

http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#how-to-submit-a-change

Embedded Labworks

LISTAS DE DISCUSSÃO

✗ Lista de discussão geral do Yocto Project:

http://lists.yoctoproject.org/listinfo/yocto

✗ Lista de discussão geral do OpenEmbedded:

http://lists.openembedded.org/mailman/listinfo/openembedded-devel

✗ Lista de discussão do OpenEmbedded Core (camada meta):

http://lists.openembedded.org/mailman/listinfo/openembedded-core

Embedded Labworks

LISTAS DE DISCUSSÃO (cont.)

✗ Lista de discussão do BitBake:

http://lists.openembedded.org/mailman/listinfo/bitbake-devel

✗ Lista de discussão do Poky:

http://lists.yoctoproject.org/listinfo/poky

✗ Lista de divulgação de novos releases do Yocto Project:

http://lists.yoctoproject.org/listinfo/yocto-announce

Embedded Labworks

LIVROS

Embedded Linux Development with Yocto ProjectOtavio Salvador/Daiane Angolini

Embedded Linux Systems with the Yocto ProjectRudolf J. Streif

Embedded Labworks

PERGUNTAS OU COMENTÁRIOS FINAIS?

Embedded Labworks

Por Sergio Prado. São Paulo, maio de 2015® Copyright Embedded Labworks 2004-2015. All rights reserved.

OBRIGADO!

E-mail sergio.prado@e-labworks.comWebsite http://e-labworks.com