• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Treinamento Yocto Project
 

Treinamento Yocto Project

on

  • 476 views

Slides do treinamento de Yocto Project da Labworks.

Slides do treinamento de Yocto Project da Labworks.

Statistics

Views

Total Views
476
Views on SlideShare
476
Embed Views
0

Actions

Likes
1
Downloads
9
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Treinamento Yocto Project Treinamento Yocto Project Presentation Transcript

    • Embedded Labworks Por Sergio Prado. São Paulo, Maio de 2014 ® Copyright Embedded Labworks 2004-2014. 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, receitas, camadas. ✗ DIA 2: Customizando o sistema, desenvolvendo e customizando BSPs, integração com ambientes de desenvolvimento, ferramentas disponíveis, depuração de problemas de build.
    • Embedded Labworks AMBIENTE DE LABORATÓRIO /opt/labs/ Ambiente de laboratório dl/ Aplicações e componentes open­source que serão usados durante as atividades de laboratório docs/ Documentação guides/ Guias de consulta   hardware/ Documentação do hardware   training/ Slides e atividades de laboratório ex/ Exercícios de laboratório tools/ 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 Timesys e a WindRiver. ✗ 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 à 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 extender 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 MEMBROS
    • 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 à 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.6 versão 11.0.0 "Daisy".
    • Embedded Labworks PRINCIPAIS CARACTERÍSTICAS ✗ 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 extender 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.
    • Embedded Labworks PRINCIPAIS CARACTERÍSTICAS (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 (rmp, deb, ipk). ✗ Filtro por licenças (Ex: sistema sem GPLv3). ✗ Permite geração de ferramentas de desenvolvimento como SDKs e emuladores. ✗ 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). ✗ Recipe (receita): 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 à 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 Linux com uma das seguintes distribuições: Ubuntu, Fedora, openSUSE, CentOS ou Debian. ✗ É necessário uma máquina com boa capacidade de processamento (ex: Core i7) e com bastante espaço em disco. ✗ Pré-requisitos de software: git 1.7.5+, 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 http://git.yoctoproject.org/git/poky ✗ Após clonar o repositório, você pode fazer o checkout do último release do Yocto Project: $ git checkout ­b daisy origin/daisy
    • Embedded Labworks CÓDIGO-FONTE DO POKY $ ls poky/ bitbake        meta­skeleton             README documentation  meta­yocto                README.hardware LICENSE        meta­yocto­bsp            scripts meta           oe­init­build­env meta­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 my_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 incompatibly LCONF_VERSION = "6" BBPATH = "${TOPDIR}" BBFILES ?= "" BBLAYERS ?= "    /home/sprado/workspace/build/yocto/yocto/poky/meta    /home/sprado/workspace/build/yocto/yocto/poky/meta­yocto    /home/sprado/workspace/build/yocto/yocto/poky/meta­yocto­bsp    " BBLAYERS_NON_REMOVABLE ?= "    /home/sprado/workspace/build/yocto/yocto/poky/meta    /home/sprado/workspace/build/yocto/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) ✗ As variáveis EXTRA_IMAGE_FEATURES e IMAGE_INSTALL_append podem ser usadas 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()}" ✗ A documentação do Yocto Project contém uma lista das principais variáveis disponíveis: http://www.yoctoproject.org/docs/current/ref-manual/ref- manual.html#ref-variables-glos
    • 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 de imagem 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/ bzImage bzImage­­3.14+git0+928d7b2dda_0143c6ebb4­r0­qemux86­20140502124415.bin bzImage­qemux86.bin core­image­minimal­qemux86­20140502124415.rootfs.ext3 core­image­minimal­qemux86­20140502124415.rootfs.manifest core­image­minimal­qemux86­20140502124415.rootfs.tar.bz2 core­image­minimal­qemux86.ext3 core­image­minimal­qemux86.manifest core­image­minimal­qemux86.tar.bz2 modules­­3.14+git0+928d7b2dda_0143c6ebb4­r0­qemux86­20140502124415.tgz modules­qemux86.tgz README_­_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 Yocto Project Sistema de build
    • Embedded Labworks POKY E BITBAKE ✗ Poky é o sistema de build utilizado no Yocto Project. ✗ O Poky utiliza a ferramenta BitBake, desenvolvida em Python, para a execução de tarefas. ✗ O BitBake interpreta 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. ✗ 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. ✗ Dependências de outros componentes de software. ✗ Localização do código-fonte. ✗ 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 com o 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 aplicações, 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 através da combinação de uma ou mais camadas.
    • Embedded Labworks CAMADAS (cont.) meta  ──├ classes      │ ──├ allarch.bbclass      │ ──├ ...  ──├ conf      │ ──├ layer.conf  ──├ recipes­bsp  ──├ recipes­connectivity  ──├ recipes­core  ──├ ... meta­selftest meta­skeleton meta­yocto meta­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). ✗ Definição da TTY para acesso à console serial. ✗ Informações do bootloader e do kernel. ✗ 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 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 meta­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      │ ──├ local.conf.sample      │ ──├ local.conf.sample.extended      │ ──└ site.conf.sample  ──├ 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 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       ──├ firefox­addon       ──├ firefox­l10n       ──└ mozilla­devscripts
    • Embedded Labworks POR DENTRO DO BITBAKE ✗ O propósito inicial do BitBake é executar as tarefas descritas nas receitas. ✗ Mas o que queremos no 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/workspace/build/yocto/yocto/build/conf/bblayers.conf # /home/sprado/workspace/build/yocto/yocto/poky/meta/conf/layer.conf # /home/sprado/workspace/build/yocto/yocto/poky/meta­yocto/conf/layer.conf # /home/sprado/workspace/build/yocto/yocto/poky/meta­yocto­bsp/conf/layer.conf # conf/bitbake.conf includes: #   /home/sprado/workspace/build/yocto/yocto/poky/meta/conf/abi_version.conf #   conf/site.conf #   conf/auto.conf #   /home/sprado/workspace/build/yocto/yocto/build/conf/local.conf #   [...] #   /home/sprado/workspace/build/yocto/yocto/poky/meta/conf/machine/qemux86.conf #   [...] #   conf/machine­sdk/${SDKMACHINE}.conf #   /home/sprado/workspace/build/yocto/yocto/poky/meta­yocto/conf/distro/poky.conf #   [...] # /home/sprado/workspace/build/yocto/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á configurada com uma lista de diretórios que contém receitas e arquivos de append: 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 a receita passada na linha de comando (no nosso exemplo, core­image­minimal.bb). ✗ O processo completo está descrito na documentação do Yocto Project em: 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 usam normalmente 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/*.bb meta/recipes­core/images/build­appliance­image_8.0.bb meta/recipes­core/images/core­image­base.bb meta/recipes­core/images/core­image­minimal.bb meta/recipes­core/images/core­image­minimal­dev.bb meta/recipes­core/images/core­image­minimal­initramfs.bb meta/recipes­core/images/core­image­minimal­mtdutils.bb meta/recipes­extended/images/core­image­full­cmdline.bb meta/recipes­extended/images/core­image­lsb.bb meta/recipes­extended/images/core­image­lsb­dev.bb meta/recipes­extended/images/core­image­lsb­sdk.bb meta/recipes­extended/images/core­image­testmaster.bb meta/recipes­graphics/images/core­image­clutter.bb meta/recipes­graphics/images/core­image­directfb.bb meta/recipes­graphics/images/core­image­weston.bb meta/recipes­graphics/images/core­image­x11.bb meta/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 Sato.
    • Embedded Labworks COMANDOS BITBAKE ✗ A ferramenta BitBake tem a seguinte sintaxe: $ bitbake <target> ✗ O campo <target> é a primeira parte do nome do arquivo de receita. Por exemplo, para compilar a receita busybox_1.22.1.bb: $ bitbake busybox ✗ A opção ­k faz com que o bitbake continue executando as tarefas, mesmo em caso de erro, até onde puder executar. $ bitbake ­k core­image­minimal
    • Embedded Labworks COMANDOS BITBAKE (cont.) ✗ Para executar apenas uma tarefa de uma receita, use a opção ­c: $ bitbake busybox ­c clean ✗ Para ignorar as dependências da receita, use o parâmetro ­b: $ bitbake ­b busybox_1.22.1.bb ✗ Para exibir o help do BitBake: $ bitbake ­h
    • 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 ✗ 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="daisy"/>   <remote fetch="git://git.yoctoproject.org" name="yocto"/>   <remote fetch="git://github.com/Freescale" name="freescale"/>   <remote fetch="git://git.openembedded.org" name="oe"/>   <project remote="yocto" revision="daisy" name="poky" path="sources/poky"/>   <project remote="yocto" revision="daisy" name="meta­fsl­arm"                                            path="sources/meta­fsl­arm"/>   <project remote="oe" revision="daisy" name="meta­openembedded"                                         path="sources/meta­openembedded"/>   <project remote="freescale" revision="daisy" 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="daisy" name="meta­fsl­arm­extra"                                                path="sources/meta­fsl­arm­extra"/>   <project remote="freescale" revision="daisy" name="meta­fsl­demos"                                                path="sources/meta­fsl­demos"/> </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 daisy $ repo sync ✗ A documentação e os procedimentos completos para utilizar o BSP da Freescale estão disponíveis em: 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­”. ✗ Por padrão, 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­layers layer           path                                    priority ================================================================ meta            /home/sprado/yocto/poky/meta            5 meta­yocto      /home/sprado/yocto/poky/meta­yocto      5 meta­yocto­bsp  /home/sprado/yocto/poky/meta­yocto­bsp  5 meta­labworks   /home/sprado/yocto/poky/meta­labworks   6
    • Embedded Labworks ALGUMAS DICAS ✗ Use arquivos de append para redefinir uma receita ao invés de copiar e modificar receitas de outras camadas. ✗ Evite duplicar arquivos de include de receitas (.inc). Use arquivos de append para redefinir a receita ou então inclua o arquivo usando o caminho relativo à camada original: require recipes­foo/bar/somefile.inc ✗ Armazene suas camadas em um repositório GIT.
    • Embedded Labworks SCRIPT DE CRIAÇÃO DE CAMADA $ yocto­layer create labworks Please 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­ labworksREADME).
    • Embedded Labworks SCRIPT DE CRIAÇÃO DE CAMADA (cont.) $ tree meta­labworks meta­labworks  ──├ conf      │ ──└ layer.conf  ──├ COPYING.MIT  ──└ README
    • Embedded Labworks LABORATÓRIO Criando e customizando 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 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 RECEITAS (cont.) ✗ Uma receita é composta basicamente pela definição de variáveis e tarefas. ✗ As variáveis definirão o comportamento do processamento da receita. ✗ As tarefas contém as instruções para o processamento da receita.
    • Embedded Labworks powertop_2.5.bb SUMMARY = "Power usage tool" DESCRIPTION = "Linux tool to diagnose issues with power consumption and  power management." HOMEPAGE = "http://01.org/powertop/" BUGTRACKER = "http://bugzilla.lesswatts.org/" DEPENDS = "ncurses libnl pciutils" LICENSE = "GPLv2" LIC_FILES_CHKSUM = "file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e" SRC_URI = "http://01.org/powertop/sites/default/files/downloads/powertop­$ {PV}.tar.gz" SRC_URI[md5sum] = "806bbcbd44fcea1f807c9582fc1f7d3e" SRC_URI[sha256sum] = "8b2c08a555d79e1c428863470c41cb023971d74ba4801d80a05  e35adeec23c0b" inherit autotools gettext
    • Embedded Labworks VARIÁVEIS ✗ Diversas variáveis podem ser usadas para definir o comportamento do sistema de build durante o processamento da receita, por exemplo: ✗ 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. ✗ A variável DEPENDS define a dependência de outros pacotes.
    • Embedded Labworks VARIÁVEIS (cont.) ✗ Uma lista com algumas 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 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 à 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 VARIÁVEIS ✗ 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 VARIÁVEIS (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 VARIÁVEIS PN, PV e PR ✗ Algumas variáveis são inicializadas automaticamente pelo BitBake durante o processamento de uma receita. ✗ Por convenção, o nome de uma receita tem o formato <basename>_<version>.bb, onde <basename> é o nome da receita e <version> é sua versão. Ex: libpng_1.6.8.bb. ✗ Durante o processamento da receita, a variável PN será inicializada com o nome da receita e a variável PV com sua versão. ✗ 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.22.1.bb para o emulador estará disponível em: tmp/work/i586­poky­linux/busybox/1.22.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.22.1.bb estará disponível em: tmp/work/i586­poky­linux/busybox/1.22.1­r0/busybox­1.22.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.22.1.bb será: tmp/work/i586­poky­linux/busybox/1.22.1­r0/image/
    • Embedded Labworks VARIÁVEL PACKAGES ✗ A variável PACKAGES contém a lista de pacotes que serão criados durante o processamento da receita. ✗ Por padrão, ela é inicializada com o seguinte conteúdo: ${PN}­dbg  ${PN}­staticdev  ${PN}­dev  ${PN}­doc  ${PN}­locale  ${PACKAGE_BEFORE_PN} ${PN} ✗ Mas pode ser alterada por uma receita (exemplo para a receita do Busybox): busybox­ptest  busybox­httpd  busybox­udhcpd  busybox­udhcpc  busybox­syslog  busybox­mdev  busybox­hwclock  busybox­dbg  busybox­staticdev  busybox­dev  busybox­doc  busybox­locale  busybox
    • Embedded Labworks ANALISANDO VARIÁVEIS ✗ Na dúvida sobre o valor de uma variável durante o processamento de uma receita, use o parâmetro "­e" do BitBake. ✗ Exemplo: $ bitbake busybox ­e | grep "^D=" D="/home/sprado/workspace/build/yocto/yocto/build/tmp/work/ i586­poky­linux/busybox/1.22.1­r0/image"
    • Embedded Labworks DEFININDO TAREFAS ✗ As tarefas da receita são normalmente herdadas de uma classe através da palavra-chave inherit. inherit autotools ✗ É possível também implementar ou redefinir uma tarefa manualmente: do_compile() {     # instructions to compile here }
    • Embedded Labworks DEFININDO TAREFAS (cont.) ✗ Para concatenar instruções à uma tarefa já definida, adicione "_append" ao nome da tarefa: do_install_append() {     # extra install commands } ✗ A lista de tarefas de uma receita pode ser exibida executando a tarefa listtasks: $ bitbake <recipe> ­c listtasks
    • Embedded Labworks PROCESSAMENTO DA RECEITA 1. Baixar o código-fonte. 2. Descompactar o código-fonte. 3. Aplicar patches. 4. Adicionar informações de licença. 5. Configurar.
    • Embedded Labworks PROCESSAMENTO DA RECEITA (cont.) 6. Compilar. 7. Instalar. 8. Habilitar serviços do sistema. 9. Empacotar. 10.Executar scripts pós-instalação.
    • Embedded Labworks BAIXANDO O CÓDIGO-FONTE ✗ A variável SRC_URI é utilizada para definir a localização do código-fonte. SRC_URI = "http://matt.ucc.asn.au/dropbear/releases/  dropbear­${PV}.tar.bz2" ✗ O código-fonte pode ser baixado de diversas origens, incluindo diretórios locais, pacotes na Internet via HTTP (ex: tar.bz2) ou usando ferramentas de controle de versão (ex: git).
    • Embedded Labworks BAIXANDO VÁRIOS ARQUIVOS ✗ 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 BAIXANDO VÁRIOS ARQUIVOS (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 BAIXANDO DE REPOSITÓRIOS ✗ 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 CHECKSUMS ✗ 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/downloads/busybox­${PV}.tar.bz2             file://get_header_tar.patch             file://busybox­appletlib­dependency.patch             file://busybox­udhcpc­no_deconfig.patch" SRC_URI[tarball.md5sum] = "337d1a15ab1cb1d4ed423168b1eb7d7e" SRC_URI[tarball.sha256sum] = "ae0b029d0a9e4dd71a077a790840e496dd83  8998e4571b87b60fed7462b6678b"
    • Embedded Labworks DESCOMPACTANDO ✗ 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 APLICANDO PATCHES ✗ 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 CHECANDO LICENÇAS ✗ 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 mais 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 CONFIGURANDO ✗ 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 COMPILANDO ✗ 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 INSTALANDO ✗ 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 HABILITANDO SERVIÇOS ✗ O Poky suporta dois tipos de mecanismos de inicialização: sysvinit e systemd. ✗ Se o software é um serviço (daemon) que precisa ser iniciado automaticamente no boot, é possível utilizar este recurso para instalar os scripts de inicialização da aplicação. ✗ Para utilizar o sysvinit, basta herdar a classe update­rc.d e definir as variáveis INITSCRIPT_PACKAGES, INITSCRIPT_NAME e INITSCRIPT_PARAMS. ✗ Para utilizar o systemd, é necessário herdar a classe systemd.
    • Embedded Labworks EMPACOTANDO ✗ 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 SCRIPTS DE PÓS-INSTALAÇÃO ✗ 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 OUTRAS VARIÁVEIS SUMMARY Nome descritivo da receita. SECTION Classificação descritiva da receita. HOMEPAGE URL do site do projeto. BUGTRACKER URL do site de bug tracking do projeto.
    • Embedded Labworks OUTRAS VARIÁVEIS (cont.) DEPENDS       Dependência de outros pacotes para compilar determinado pacote. RDEPENDS       Dependência de outros pacotes para executar determinado pacote. RRECOMMENDS Lista de pacotes que extendem a funcionalidade de determinado pacote (a instalação é opcional). RCONFLICTS Lista de pacotes que conflitam com determinado pacote. RREPLACES Lista de pacotes substituídos por determinado pacote.
    • Embedded Labworks MODELO DE RECEITA SUMMARY = "" HOMEPAGE = "" LICENSE = "" LIC_FILES_CHKSUM = "" SRC_URI = "" SRC_URI[md5sum] = "" SRC_URI[sha256sum] = "" S = "${WORKDIR}/${PN}­${PV}" 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 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}/files:"
    • Embedded Labworks alsa-state.bb $ ls ./meta/recipes­bsp/alsa­state/alsa­state.bb ./meta/recipes­bsp/alsa­state/alsa­state.bb $ tree ./meta­yocto­bsp/recipes­bsp/alsa­state/ ./meta­yocto­bsp/recipes­bsp/alsa­state/  ──├ alsa­state      │ ──└ beagleboard          │ ──└ asound.state  ──└ alsa­state.bbappend $ cat ./meta­yocto­bsp/recipes­bsp/alsa­state/alsa­ state.bbappend FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
    • Embedded Labworks DIRETÓRIO DE SAÍDA DA RECEITA $ ls tmp/work/i586­poky­linux/zlib/1.2.8­r0/ archiver­work            remove.ldconfig.call.patch debugsources.list        run­ptest deploy­rpms              sstate­install­package deploy­sources           sstate­install­packagedata image                    sstate­install­package_write_rpm license­destdir          sstate­install­populate_lic Makefile­runtests.patch  sstate­install­populate_sysroot package                  sysroot­destdir packages­split           temp pkgdata                  zlib­1.2.8 pseudo                   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 e segmentados. deploy­rpms pacotes gerados.
    • Embedded Labworks REFERÊNCIAS ✗ Para mais informações sobre o processo de criação de uma receita: http://www.yoctoproject.org/docs/1.6/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/1.6/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 pacotes de software. ✗ Adicionar ou remover outros arquivos (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 CUSTOMIZANDO UMA IMAGEM (cont.) ✗ Uma imagem pode ser customizada de diversas formas: ✗ Políticas globais sobre como uma imagem é gerada podem ser definidas em uma distribuição (ex: funcionalidades básicas, biblioteca do sistema, etc). ✗ O conjunto de pacotes que será incluído na imagem final pode ser definido em uma receita de imagem (ex: pacotes de software, arquivos de configuração, tamanho e geração da imagem do rootfs, etc). ✗ Alterações locais podem ser realizadas no arquivo local.conf (ex: adição de pacotes de software).
    • Embedded Labworks PACOTES DE SOFTWARE ✗ Pacotes (packages) são o resultado do processamento da receita de um componente de software. ✗ Uma única receita pode gerar mais de um pacote de software. ✗ Uma das tarefas mais comuns durante a customização do sistema é a adição de um novo pacote de software.
    • Embedded Labworks PESQUISANDO PACOTES EXISTENTES ✗ Os pacotes já instalados na imagem gerada podem ser exibidos filtrando a árvore de dependências da imagem: $ bitbake ­g <image> && cat pn­depends.dot | grep ­v ­e '­ native'  |  grep  ­v  digraph  |  grep  ­v  ­e  '­image'  |  awk  '{print $1}' | sort | uniq ✗ Outra forma é listar o arquivo de manifesto da imagem, disponível no diretório de saída da imagem, que contém uma lista de pacotes instalados no formato abaixo: <packagename> <packagearch> <version>
    • Embedded Labworks ARQUIVO DE MANIFESTO DA IMAGEM $ cat tmp/deploy/images/qemux86/core­image­minimal­ labworks­qemux86­20140520211247.rootfs.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+928d7b2dda_0143c6ebb4 kernel­module­uvesafb qemux86  3.14+git0+928d7b2dda_0143c6ebb4 [...]
    • Embedded Labworks PESQUISANDO PACOTES EXISTENTES (cont.) ✗ Existem algumas formas de verificar se as camadas habilitadas no BBLAYERS possuem uma receita para o pacote que você está procurando: $ bitbake­layers show­recipes | grep <package_name> $ bitbake ­s | grep <package_name> ✗ Com o nome da receita você pode verificar os pacotes correspondentes: $ bitbake ­e unzip | grep ^PACKAGES= PACKAGES="unzip­dbg unzip­staticdev unzip­dev unzip­doc unz  ip­locale unzip"
    • 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. ✗ É necessário documentar e 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_8.0.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 customizar a receita usando por exemplo as variáveis IMAGE_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 GRUPOS DE RECEITAS ✗ Um grupo de receitas (package groups) é basicamente um conjunto de receitas com um objetivo comum. ✗ Alguns exemplos: ✗ Receitas com os pacotes de software básico do sistema (base files, busybox, login, etc). ✗ Receitas com os pacotes de software para habilitar o stack gráfico (x11-server, x11-common, xrandr, etc). ✗ Receitas com os pacotes de software do produto desenvolvido pela empresa (aplicações, bibliotecas, etc).
    • Embedded Labworks GRUPOS DE RECEITAS (cont.) ✗ Normalmente, os grupos de receitas 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" [...] 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 ✗ Como um grupo de pacotes também é representado por uma receita, ela pode ser adicionada à uma imagem normalmente através da variável IMAGE_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 receitas (package groups) para adicionar uma funcionalidade à imagem gerada. ✗ A maioria da 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" ✗ É possível também habilitar uma feature de imagem no local.conf, 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 link abaixo: http://www.yoctoproject.org/docs/1.6/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). Estudaremos estas features mais adiante no treinamento.
    • Embedded Labworks REMOVENDO UM PACOTE ✗ 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. ✗ A variável PACKAGE_EXCLUDE permite excluir qualquer pacote da imagem. Neste caso, o processo de build pode falhar caso algum outro pacote dependa dele.
    • 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 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 carry out }
    • 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 ALTERANDO O TIPO DE IMAGEM GERADA ✗ 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. ✗ Imagens customizadas podem ser geradas implementando uma classe específica e herdando a classe image_types.bbclass (vide a classe 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 link abaixo: 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 utilizado nos arquivos de saída, que por padrão recebem o nome da receita (${PN}). IMAGE_BASENAME = "myproduct" ✗ Para adicionar suporte à localização, pode-se usar a variável IMAGE_LINGUAS: IMAGE_LINGUAS = "pt­br en­us"
    • 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 DEFININDO UMA DISTRIBUIÇÃO ✗ A variável DISTRO_NAME permite configurar o nome da distribuição. ✗ Uma distribuição pode ser versionada com a variável DISTRO_VERSION. ✗ Pacotes específicos da distro podem ser adicionados à variável DISTRO_EXTRA_RDEPENDS.
    • Embedded Labworks DEFININDO UMA DISTRIBUIÇÃO (cont.) ✗ A variável DISTRO_EXTRA_RRECOMMENDS permite adicionar pacotes caso eles existam. ✗ A variável TCLIBC permite definir qual libc será usada (eglibc ou uclibc).
    • Embedded Labworks DISTRO FEATURES ✗ Uma feature de distribuição permite controlar as características de software da distribuição. ✗ Permite controlar a inclusão automática de pacotes na distribuição. ✗ Em alguns casos altera o comportamento de scripts de configuração de alguns pacote, por exemplo quando a feature x11 é habilitada. DISTRO_FEATURES += "x11"
    • 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 link abaixo: http://www.yoctoproject.org/docs/current/ref-manual/ref- manual.htm#ref-features-distro
    • Embedded Labworks DICAS PARA CUSTOMIZAÇÃO ✗ Use o local.conf sempre que precisar realizar testes, mas tente centralizar as modificações necessárias em uma camada separada. ✗ Crie uma ou mais receitas de imagens para customizar as imagens dos seus produtos. ✗ Ao invés de duplicar arquivos de receitas, use arquivos de append (.bbappend) para modificar o comportamento das receitas. ✗ Se necessário, crie uma distribuição para o seu produto (dependendo do nível de customização necessário).
    • Embedded Labworks LABORATÓRIO Customizando o sistema
    • Embedded Labworks Yocto Project Board Support Package
    • Embedded Labworks O QUE É UM BSP? ✗ Um BSP (Board Support Package) contém documentação e código- fonte para adicionar o suporte à determinada plataforma de hardware. ✗ Para adicionar o suporte à uma plataforma de hardware no Yocto Project, é necessário adicionar uma camada de BSP. ✗ Por padrão, o Yocto Project já possui algumas camadas de BSP implementadas (beaglebone, edgerouter, etc). ✗ Ao desenvolver o seu produto, verifique se já existe um BSP do Yocto Project para a sua plataforma. Caso contrário, será necessário desenvolvê-la.
    • Embedded Labworks CAMADA DE BSP ✗ Uma camada de BSP tem a mesma aparência de uma camada de distro 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 máquinas (machines).
    • 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 ✗ Um guia para a criação de BSPs no Yocto Project está disponível no link abaixo: http://www.yoctoproject.org/docs/1.6/bsp-guide/bsp-guide.html
    • Embedded Labworks ADICIONANDO UMA MACHINE ✗ O segredo da implementação da camada de BSP 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, parâmetros de otimização do compilador, etc. ✗ Dentre as variáveis mais comuns, temos: ✗ TARGET_ARCH: arquitetura da máquina. ✗ PREFERRED_PROVIDER_virtual/kernel: permite definir a receita do kernel que será utilizada para esta máquina. ✗ Use a definição das máquinas existentes para identificar as variáveis que podem ser usadas na definição de uma máquina.
    • Embedded Labworks wandboard-quad.conf include conf/machine/include/imx­base.inc include conf/machine/include/tune­cortexa9.inc SOC_FAMILY = "mx6:mx6q:wandboard" PREFERRED_PROVIDER_virtual/kernel ?= "linux­wandboard" UBOOT_MACHINE = "wandboard_quad_config" KERNEL_DEVICETREE = "imx6q­wandboard.dtb" SERIAL_CONSOLE = "115200 ttymxc0" MACHINE_FEATURES += " pci wifi bluetooth" MACHINE_EXTRA_RRECOMMENDS += " broadcom­nvram­config"
    • Embedded Labworks imx-base.inc include conf/machine/include/fsl­default­settings.inc include conf/machine/include/fsl­default­versions.inc include conf/machine/include/fsl­default­providers.inc include conf/machine/include/soc­family.inc # Set specific make target and binary suffix UBOOT_MAKE_TARGET = "u­boot.imx" UBOOT_SUFFIX ?= "imx" UBOOT_ENTRYPOINT_mx3 = "0x80008000" [...] XSERVER_DRIVER = "xf86­video­fbdev" [...] # Float­Point setting DEFAULTTUNE_mx6 ?= "cortexa9hf­neon"
    • Embedded Labworks MACHINE FEATURES ✗ As features de máquinas podem ser definidas com a variável MACHINE_FEATURES. ✗ Elas permitem habilitar determinadas opções de hardware, como por exemplo: ✗ touchscreen: o hardware tem uma interface de touchscreen. ✗ wifi: o hardware tem uma interface wifi. ✗ bluetooth: o hardware tem uma interface bluetooth. ✗ A principais features de máquinas estão disponíveis no link abaixo: http://www.yoctoproject.org/docs/1.6/ref-manual/ref- manual.html#ref-features-machine
    • Embedded Labworks USANDO O BSP ✗ Para usar o BSP, 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 máquina. 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 no 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 linux­yocto ­c menuconfig ✗ Neste caso, a configuração será realizada diretamente no diretório de compilação do kernel em tmp/work/, 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­myboard.bbappend $ cat linux­myboard.bbappend FILESEXTRAPATHS_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 BSP. ✗ Para customizar a configuração padrão do BSP 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­myboard.bbappend $ cat files/ntfs.cfg CONFIG_NTFS_FS=y $ cat linux­myboard.bbappend FILESEXTRAPATHS_prepend := "${THISDIR}/files:" SRC_URI += "file://ntfs.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.) recipes­kernel/  ──└ linux       ──├ files           │ ──└ 0001­fixbug.patch       ──└ linux­myboard.bbappend $ cat linux­myboard.bbappend FILESEXTRAPATHS_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 <project_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 kernel require 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 OUTRAS OPÇÕES DE CONFIGURAÇÃO ✗ A variável APPEND permite alterar a linha de comandos do kernel. APPEND += "printk.time=y initcall_debug debug" ✗ O arquivo de device tree (DTB) pode ser definido na variável KERNEL_DEVICETREE. KERNEL_DEVICETREE = "imx6q­wandboard.dtb" ✗ A variável SERIAL_CONSOLE permite definir a console serial do target. SERIAL_CONSOLE = "115200 ttyS0"
    • Embedded Labworks LABORATÓRIO Customizando o BSP
    • Embedded Labworks Yocto Project Integração
    • Embedded Labworks TRABALHANDO COM BUILD SYSTEMS ✗ Apesar de ser possível utilizar uma ferramenta de build de sistema durante o desenvolvimento de uma aplicação, seu uso é mais adequado durante a integração do sistema. ✗ Isso significa que você deve usar um build system para integrar os componentes do sistema e gerar imagens para o target. ✗ Neste sentido, para auxiliar no desenvolvimento de aplicações, o build system normalmente disponibiliza para o usuário um conjunto de ferramentas de desenvolvimento, que chamamos de toolchain.
    • Embedded Labworks TIPOS DE 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 desenvolvimento em Linux embarcado, o mais comum é o uso de ferramentas de compilação cruzada.
    • Embedded Labworks TOOLCHAIN NO YOCTO PROJECT ✗ O Yocto Project possui três mecanismos para a instalação e utilização do toolchain de compilação cruzada no desenvolvimento de uma aplicação: ✗ Usar o toolchain diretamente do diretório de build. ✗ Instalar o toolchain manualmente no host. ✗ Instalar o ADT (Application Development Toolkit).
    • Embedded Labworks TOOLCHAIN NO DIRETÓRIO DE BUILD ✗ Para gerar o toolchain diretamente no diretório de build do sistema, devemos: ✗ Executar o script de configuração do ambiente. ✗ Configurar corretamente a variável MACHINE no local.conf. ✗ Processar a receita meta­ide­support. $ bitbake meta­ide­support ✗ Ao final da compilação, um script de configuração do ambiente para utilizar o toolchain estará disponível no diretório tmp/.
    • Embedded Labworks TOOLCHAIN NO DIRETÓRIO DE BUILD (cont.) ✗ Para usar o toolchain, basta carregar o script de configuração do ambiente: $ source tmp/environment­setup­cortexa9hf­vfp­neon­poky­ linux­gnueabi ✗ E então o toolchain estará disponível para uso: $ arm­poky­linux­gnueabi­gcc ­v Using built­in specs. [...] gcc version 4.8.1 (GCC) 
    • Embedded Labworks EXTRAINDO O ROOTFS ✗ Em alguns casos, pode ser necessário ter acesso ao rootfs do target para o desenvolvimento de aplicações. Exemplos: ✗ Montar o rootfs por NFS. ✗ Usar o rootfs como sysroot para compilar aplicações que dependam de bibliotecas que não estejam instaladas no sysroot do toolchain. ✗ Para extrair o rootfs para um diretório do sistema: ✗ Carregue o script de configuração do ambiente do toolchain. ✗ Execute o script runqemu­extract­sdk, passando como parâmetro a imagem e o diretório do rootfs.
    • Embedded Labworks EXTRAINDO O ROOTFS (cont.) $ cd tmp/ $ mkdir ­p rootfs $ source environment­setup­cortexa9hf­vfp­neon­poky­linux­ gnueabi $ runqemu­extract­sdk deploy/images/wandboard­quad/core­image­ minimal­wandboard­quad.tar.bz2 rootfs
    • Embedded Labworks INSTALANDO O TOOLCHAIN ✗ Para instalar um toolchain manualmente, você pode baixar o script de instalação do toolchain no site do Yocto Project. http://downloads.yoctoproject.org/releases/yocto/yocto-1.6/toolchain/ ✗ E depois executar o script, conforme abaixo: $ ./poky­eglibc­x86_64­core­image­sato­i586­toolchain­ 1.6.sh
    • Embedded Labworks INSTALANDO O TOOLCHAIN (cont.) ✗ Durante a execução do script, será necessário configurar o diretório de instalação do toolchain (/opt/poky/<release> por padrão). ✗ Estão disponíveis para download os scripts para instalar toolchains compatíveis com as imagens do tipo core­image­*.
    • Embedded Labworks INSTALANDO O TOOLCHAIN (cont.) ✗ Existem duas formas de gerar um script de instalação do toolchain: ✗ Processando a receita meta­toolchain (neste caso, o sysroot precisa ser instalado separadamente). $ bitbake meta­toolchain ✗ Executando a tarefa populate_sdk da imagem (método recomendado, já que neste caso a instalação do sysroot no toolchain é automática). $ bitbake <image> ­c populate_sdk ✗ Use a variável SDKMACHINE caso o host que irá executar o toolchain é diferente do host que está gerando o toolchain (o padrão é i686).
    • Embedded Labworks INSTALANDO O TOOLCHAIN (cont.) ✗ Ao final do processo de compilação, o script de instalação do toolchain estará disponível em tmp/deploy/sdk. $ ls tmp/deploy/sdk poky­eglibc­x86_64­meta­toolchain­cortexa9hf­vfp­neon­ toolchain­1.5.1.sh ✗ Então é só executar o script: $ cd tmp/deploy/sdk $ ./poky­eglibc­x86_64­meta­toolchain­cortexa9hf­vfp­neon­ toolchain­1.5.1.sh
    • Embedded Labworks INSTALANDO O TOOLCHAIN (cont.) ✗ Durante a execução do script, será necessário configurar o diretório de instalação do toolchain (/opt/poky/<release> por padrão). ✗ Ao final do processo, o toolchain estará disponível no diretório selecionado para a instalação: $ ls /opt/poky/1.6/ environment­setup­cortexa9hf­vfp­neon­poky­linux­gnueabi   site­config­cortexa9hf­vfp­neon­poky­linux­gnueabi   sysroots   version­cortexa9hf­vfp­neon­poky­linux­gnueabi
    • Embedded Labworks INSTALANDO O TOOLCHAIN (cont.) ✗ Então é só carregar o script de configuração do ambiente para utilizar o toolchain: $ source /opt/poky/1.6/environment­setup­cortexa9hf­vfp­ neon­poky­linux­gnueabi $ arm­poky­linux­gnueabi­gcc ­v Using built­in specs. [...] gcc version 4.8.1 (GCC) 
    • Embedded Labworks INSTALANDO O ADT ✗ A instalação do ADT (Application Development Toolkit) é recomendada porque automatiza o processo de geração e instalação do toochain e do rootfs para o desenvolvimento de aplicações. ✗ O script de instalação do ADT pode ser baixado na Internet: http://downloads.yoctoproject.org/releases/yocto/yocto-1.6/adt- installer
    • Embedded Labworks INSTALANDO O ADT (cont.) ✗ Ou então compilado através do processamento da receita adt­ installer: $ bitbake adt­installer ✗ Ao final do processo de compilação, o tarball de instalação do ADT estará disponível em tmp/deploy/sdk/adt_installer.tar.  bz2.
    • Embedded Labworks INSTALANDO O ADT (cont.) ✗ O tarball contém um arquivo de configuração (adt_installer.conf) e o script de instalação (adt_installer) do ADT. ✗ Antes de executar o script de instalação, altere o adt_installer.conf conforme a necessidade. Você pode por exemplo configurar o diretório de descompactação do rootfs na variável YOCTOADT_TARGET_SYSROOT_  LOC_<arch>. ✗ Mais informações sobre as variáveis existentes no adt_installer.conf estão disponíveis na documentação do Yocto Project. http://www.yoctoproject.org/docs/1.6/adt-manual/adt-manual.html #installing-the-adt
    • Embedded Labworks INSTALANDO O ADT (cont.) ✗ Depois de configurar o adt_installer.conf é só executar o script: $ ./adt_installer ✗ Durante a execução do script, será necessário configurar o diretório de instalação do toolchain (/opt/poky/<release> por padrão). ✗ Ao final do processo, o toolchain estará disponível no diretório selecionado para a instalação: $ ls /opt/poky/1.6/ environment­setup­cortexa9hf­vfp­neon­poky­linux­gnueabi   site­config­cortexa9hf­vfp­neon­poky­linux­gnueabi   sysroots   version­cortexa9hf­vfp­neon­poky­linux­gnueabi
    • Embedded Labworks INSTALANDO O ADT (cont.) ✗ Então é só carregar o script de configuração do ambiente para utilizar o toolchain: $ source /opt/poky/1.6/environment­setup­cortexa9hf­vfp­ neon­poky­linux­gnueabi $ arm­poky­linux­gnueabi­gcc ­v Using built­in specs. [...] gcc version 4.8.1 (GCC)
    • Embedded Labworks COMPILANDO APLICAÇÕES ✗ Com o toolchain instalado, basta usá-lo para compilar uma aplicação para o target. ✗ Para compilar um projeto com o autotools, basta configurar o software com o comando abaixo: $ configure ­­host=arm­poky­linux­gnueabi –with­libtool­ sysroot=<sysroot­dir> ✗ Para compilar uma aplicação baseada em makefile, basta configurar no ambiente do terminal ou no Makefile as opções abaixo: CC=arm­poky­linux­gnueabi­gcc LD=arm­poky­linux­gnueabi­ld CFLAGS="${CFLAGS} ­­sysroot=<sysroot­dir>" CXXFLAGS="${CXXFLAGS} ­­sysroot=<sysroot­dir>"
    • Embedded Labworks INTEGRANDO COM O ECLIPSE ✗ Para desenvolver com o Eclipse, é necessário: ✗ Instalar uma versão suportada do Eclipse (Kepler ou Juno). ✗ 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.
    • 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 DESENVOLVIMENTO COM O ECLIPSE ✗ O desenvolvimento 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 montando o rootfs via NFS. ✗ Executar ferramentas de tracing e profiling como OProfile, Lttng, PowerTOP, LatencyTOP e Perf.
    • Embedded Labworks LABORATÓRIO Integrando com uma IDE
    • Embedded Labworks Yocto Project Ferramentas e depuração
    • 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. ✗ A partir do release 1.4 "Dylan", o Hob passou a compartilhar os mesmos arquivos de configuração do BitBake (local.conf e bblayers.conf). ✗ 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 ferramenta de análise de build. https://www.yoctoproject.org/documentation/toaster-manual ✗ Liberado a partir do release 1.6 "Daisy" do Yocto Project, permite navegar, procurar e analisar informações do processo de build de uma imagem através de uma interface web. ✗ Para iniciar o Toaster: $ source toaster start
    • Embedded Labworks TOASTER (cont.)
    • Embedded Labworks FUNCIONALIDADES DO TOASTER ✗ Com o Toaster, é possível exibir: ✗ Informações gerais do processo de build, incluindo warnings e erros. ✗ Receitas processadas e pacotes incluídos na imagem. ✗ Estrutura de diretórios da imagem. ✗ Dependências de tarefas, receitas e pacotes. ✗ Performance do processo de build (tempo de build, uso de CPU e disco por tarefa). ✗ Existe um plano para integrar as funcionalidades do Hob no Toaster.
    • 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 do Yocto Project. https://www.yoctoproject.org/downloads/ ✗ 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 do sistema, 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/  latest PV = 2014.63 PR = r0 RPROVIDES = ssh sshd RDEPENDS = eglibc (>= 2.19) update­alternatives­opkg zlib (>=  1.2.8) RRECOMMENDS = update­rc.d PKGSIZE = 279834 FILES = /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 ­p commit aa181f597039206b45fd0795b19e288d6a348ed9 Author: 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/latest new file mode 100644 index 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 de código-aberto é a aderência às licenças dos softwares utilizados. ✗ 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 (testado apenas com a licença GPLv3). INCOMPATIBLE_LICENSE = "GPLv3"
    • Embedded Labworks LICENÇAS (cont.) ✗ Licenças comerciais são compiladas apenas se incluídas na variável LICENSE_FLAGS_WHITELIST. Exemplo: LICENSE_FLAGS = "commercial" ✗ O diretório tmp/deploy/licenses/<package_name>, dentro do diretório de build, 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 DEPURANDO PROBLEMAS DE BUILD ✗ Liste as tarefas de uma receita executando a tarefa listtasks. $ bitbake busybox ­c listtasks ✗ Use a opção "­c" do BitBake para compilar determinada tarefa. $ bitbake busybox ­c compile ✗ Para forçar a execução de uma tarefa, use a opção "­f". $ bitbake busybox ­c compile ­f
    • Embedded Labworks DEPURANDO PROBLEMAS DE BUILD (cont.) ✗ Estude o log de execução da tarefa no diretório tmp/, dentro do diretório da receita: $ ls tmp/work/i586­poky­linux/busybox/1.22.1­r0/temp/ log.do_ar_original log.do_ar_original.26561 log.do_compile log.do_compile.18021 log.do_compile_ptest_base log.do_compile_ptest_base.18582 log.do_configure log.do_configure.11494 log.do_configure_ptest_base log.do_configure_ptest_base.17801 [...]
    • Embedded Labworks DEPURANDO PROBLEMAS DE BUILD (cont.) ✗ Use a opção "­b" para processar diretamente uma receita (esta opção não verifica as dependências). $ bitbake ­b meta/recipes­core/busybox/busybox_1.22.1.bb ✗ Se o problema for de dependência, gere o gráfico de dependências com a opção "­g". $ bitbake ­g busybox ✗ As dependências podem ser visualizadas com a opção "­u  depexp". $ bitbake ­g ­u depexp busybox
    • Embedded Labworks DEPURANDO PROBLEMAS DE BUILD (cont.) ✗ Use a opção "­e" para exibir o resultado do parsing das receitas e variáveis de configuração. $ bitbake busybox ­e ✗ O modo verbose do BitBake pode ser habilitado com a opção "­v", possibilitando visualizar por exemplo as mensagens de compilação. $ bitbake busybox ­v ✗ Mensagens de debug do sistema de build podem ser habilitadas com as opções "­D", "­DD" ou "­DDD". $ bitbake busybox ­v ­DDD
    • Embedded Labworks DEPURANDO PROBLEMAS DE BUILD (cont.) ✗ Verifique no release notes do Yocto Project se o problema pode estar relacionado ao release do projeto ou à alguma incompatibilidade com as ferramentas do host. https://www.yoctoproject.org/download/yocto-project-16 ✗ Use a lista de discussão correspondente à camada que contém a receita com problema. ✗ Se o erro for em uma camada do Yocto Project, reporte o erro para a comunidade: http://www.yoctoproject.org/docs/1.6/dev-manual/dev- manual.html#using-the-error-reporting-tool
    • Embedded Labworks LABORATÓRIO Analisando problemas de build
    • Embedded Labworks Linux Embarcado E agora?
    • Embedded Labworks RECURSOS ONLINE ✗ Site do Yocto Project: https://www.yoctoproject.org/ ✗ Site do OpenEmbedded: http://www.openembedded.org/wiki/Main_Page ✗ Site do BitBake: http://developer.berlios.de/projects/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/1.6/bitbake-user-manual/ bitbake-user-manual.html ✗ Yocto Project Development Manual: http://www.yoctoproject.org/docs/1.6/dev-manual/dev- manual.html ✗ Yocto Project Application Developer's Manual: http://www.yoctoproject.org/docs/1.6/adt-manual/adt- manual.html
    • Embedded Labworks RECURSOS ONLINE (cont.) ✗ Yocto Project Linux Kernel Development Manual: http://www.yoctoproject.org/docs/1.6/kernel-dev/kernel-dev.html ✗ Yocto Project BSP Developer's Guide: http://www.yoctoproject.org/docs/1.6/bsp-guide/bsp-guide.html ✗ Como submeter um patch: http://www.yoctoproject.org/docs/1.6/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 Project Otavio Salvador/Daiane Angolini Embedded Linux Systems with the Yocto Project Rudolf J. Streif
    • Embedded Labworks PERGUNTAS OU COMENTÁRIOS FINAIS?
    • Embedded Labworks CONSULTORIA COM A O.S. SYSTEMS ✗ Empresa nacional, fundada em 2002 e sediada em Pelotas, RS. http://ossystems.com.br/ ✗ 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. ✗ Contato: Otávio Salvador <otavio@ossystems.com.br>
    • Embedded Labworks Por Sergio Prado. São Paulo, Novembro de 2012 ® Copyright Embedded Labworks 2004-2013. All rights reserved. OBRIGADO! E-mail sergio.prado@e-labworks.com Website http://e-labworks.com