Treinamento Yocto Project

1.453 visualizações

Publicada em

Slides do treinamento de Yocto Project da Labworks.

Publicada em: Tecnologia
0 comentários
3 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
1.453
No SlideShare
0
A partir de incorporações
0
Número de incorporações
13
Ações
Compartilhamentos
0
Downloads
55
Comentários
0
Gostaram
3
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Treinamento Yocto Project

  1. 1. Embedded Labworks Por Sergio Prado. São Paulo, maio de 2015 ® Copyright Embedded Labworks 2004-2015. All rights reserved. Yocto Project
  2. 2. 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
  3. 3. 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
  4. 4. 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.
  5. 5. Embedded Labworks AGENDA DO TREINAMENTO ✗ DIA 1: Introdução ao Yocto Project, código-fonte, processo de build, camadas, receitas. ✗ DIA 2: Criando e customizando receitas, customizando a imagem do sistema, desenvolvendo e customizando BSPs. ✗ DIA 3: Integração com ambientes de desenvolvimento, ferramentas adicionais, projeto final.
  6. 6. 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
  7. 7. Embedded Labworks DURANTE O TREINAMENTO ✗ Pergunte... ✗ Expresse seu ponto de vista... ✗ Troque experiências... ✗ Ajude... ✗ Participe!
  8. 8. Embedded Labworks Yocto Project Introdução ao Yocto Project
  9. 9. Embedded Labworks LINUX EMBARCADO Hardware Bootloader Linux kernel Biblioteca C Biblioteca Biblioteca Aplicação Aplicação Toolchain
  10. 10. 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.
  11. 11. Embedded Labworks IMAGENS DO SISTEMA Bootloader Kernel Rootfs Dispositivo de armazenamento
  12. 12. 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.
  13. 13. Embedded Labworks DISTRIBUIÇÃO PRONTA ✗ Existem soluções de distribuição Linux comercializadas por empresas como a MontaVista, a WindRiver, a O.S. Systems e a Timesys. ✗ Existem também diversas soluções abertas, incluindo Android, Emdebian, Ubuntu, Tizen, Angstrom, etc. ✗ Vantagens de uma solução pronta: ✗ Simplicidade de uso. ✗ Facilidade na instalação de novos pacotes. ✗ Framework de desenvolvimento pronto e funcional.
  14. 14. 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.
  15. 15. Embedded Labworks PROCESSO MANUAL ✗ Gerar um sistema Linux manualmente permite um controle total sobre as ferramentas utilizadas para a geração do sistema, assim como a flexibilidade necessária para gerar uma distribuição Linux customizada para o target. ✗ Porém, gerar um sistema Linux completo manualmente é uma atividade extremamente trabalhosa, demorada, difícil de reproduzir e suscetível a erros. ✗ Para os mais aventureiros: http://www.linuxfromscratch.org/
  16. 16. Embedded Labworks SISTEMAS DE BUILD ✗ Um sistema de build permite gerar um sistema Linux completo e customizado para o target. ✗ Ele possui um conjunto de ferramentas que automatizam o processo de geração de todos os componentes do sistema (toolchain, bootloader, kernel, rootfs). ✗ Normalmente já contém um conjunto grande de pacotes configurados para serem habilitados e utilizados pelo seu sistema. ✗ E facilita o trabalho de estender e adicionar novos pacotes se necessário.
  17. 17. 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.
  18. 18. 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/
  19. 19. 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/
  20. 20. 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.
  21. 21. Embedded Labworks ALGUNS MEMBROS
  22. 22. Embedded Labworks PROJETOS ✗ Alguns dos projetos que formam o Yocto Project: ✗ Openembedded Core ✗ BitBake ✗ Poky ✗ AutoBuilder ✗ Hob ✗ Toaster ✗ Uma lista dos projetos está disponível no link abaixo: https://www.yoctoproject.org/tools-resources/projects
  23. 23. 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ê!
  24. 24. Embedded Labworks HISTÓRICO Portage (Gentoo) BitBake OpenZaurus OpenEmbedded Poky Yocto Project
  25. 25. Embedded Labworks VÍDEO Fonte: https://www.youtube.com/watch?v=utZpKM7i5Z4
  26. 26. Embedded Labworks CICLO DE RELEASE ✗ Cada release do Yocto está sujeito a um cronograma definido pela comunidade e publicado em: https://wiki.yoctoproject.org/wiki/Planning#Yocto ✗ Espera-se que um novo release do Yocto seja liberado a cada 6 meses. ✗ Patches para corrigir bug críticos e falhas de segurança são aplicados também em uma versão anterior. ✗ Neste treinamento utilizaremos o Yocto Project 1.8 versão 13.0.0 "Fido".
  27. 27. Embedded Labworks CARACTERÍSTICAS E VANTAGENS ✗ Extremamente configurável e flexível na geração de sistemas Linux. ✗ Milhares de pacotes de software pré-configurados e disponíveis para compilação cruzada. ✗ Provê facilidades para manter e estender o sistema através da implementação de camadas. ✗ Suportado pelos fabricantes das principais arquiteturas de hardware (Intel, ARM, MIPS, PowerPC, etc), servindo de padrão para o desenvolvimento de BSPs e imagens de demonstração.
  28. 28. Embedded Labworks CARACTERÍSTICAS E VANTAGENS (cont.) ✗ Suporte à geração de sistemas Linux multiplataforma, sendo trivial mudar a geração de uma imagem inteira para uma plataforma diferente. ✗ Suporte ao gerenciamento de pacotes de software (rpm, deb, ipk), possibilitando o desenvolvimento de distribuições Linux. ✗ Permite geração de ferramentas de desenvolvimento como SDKs e emuladores. ✗ Filtro por licenças (Ex: sistema sem GPLv3). ✗ Comunidade bastante ativa.
  29. 29. Embedded Labworks ARQUITETURA BÁSICA Fonte: https://www.yoctoproject.org
  30. 30. Embedded Labworks CONCEITOS ✗ Tarefa (task): Etapa executada pelo sistema de compilação (fetch, patch, configure, compile, package, etc). ✗ Receita (recipe): conjunto de tarefas para compilar determinado software (.bb, .bbappend). ✗ Classes (classes): herança e encapsulamento da lógica para a execução de tarefas comuns entre as receitas (.bbclass). ✗ Pacote (package): resultado do processamento da receita de um componente de software, agregado em algum formato popular de empacotamento (.ipk, .deb, .rpm).
  31. 31. 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.
  32. 32. Embedded Labworks POKY ✗ O Poky pode se referir a dois conceitos diferentes: ✗ É o sistema de build utilizado no Yocto Project. ✗ É o nome da distribuição padrão do Yocto Project. ✗ O sistema de build Poky é composto pelos seguintes componentes: ✗ Metadados: descrevem a configuração do sistema e as tarefas a serem executadas. É composto por arquivos de configuração (.conf), receitas (.bb, .bbappend) e classes (.bbclass). ✗ BitBake: ferramenta escrita em Python responsável por processar e executar as receitas.
  33. 33. Embedded Labworks Yocto Project Código-fonte
  34. 34. Embedded Labworks MÁQUINA DE DESENVOLVIMENTO ✗ É recomendado o uso de uma máquina GNU/Linux com uma das seguintes distribuições: Ubuntu, Fedora, openSUSE, CentOS ou Debian. ✗ É necessário uma máquina com boa capacidade de processamento (ex: Intel Core i7) e com bastante espaço em disco. ✗ Alguns pré-requisitos de software: gcc, make, git 1.7.8+, python 2.7.3+, tar 1.24+. ✗ Consulte o link abaixo para instruções mais completas sobre como preparar a máquina de desenvolvimento: https://www.yoctoproject.org/docs/current/yocto-project-qs/yocto- project-qs.html
  35. 35. Embedded Labworks CÓDIGO-FONTE ✗ O código-fonte do Yocto Project é composto pelo repositório do Poky e por diversos outros repositórios que fornecem ferramentas e camadas adicionais para construir uma distribuição Linux customizada. ✗ O repositório do Poky é versionado com o git, e pode ser clonado conforme abaixo: $ git clone ­b fido git://git.yoctoproject.org/poky.git ✗ O parâmetro ­b possibilita clonar um branch específico do repositório, neste exemplo o release Fido do Yocto Project.
  36. 36. 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
  37. 37. 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.
  38. 38. 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).
  39. 39. 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.
  40. 40. Embedded Labworks COMPILANDO UMA IMAGEM ✗ O repositório do Poky contém a base do Yocto Project, incluindo as camadas com os metadados necessários para compilar uma distribuição customizada para o emulador e para os BSPs de referência. ✗ Para compilar, o primeiro passo é executar o script oe­init­build­ env para que o ambiente de compilação seja configurado: $ source oe­init­build­env ✗ Por padrão, será criado um diretório chamado build. Opcionalmente, você pode passar o nome do diretório de build: $ source oe­init­build­env build_dir
  41. 41. 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.
  42. 42. Embedded Labworks O DIRETÓRIO DE BUILD (cont.) $ tree build/ build/  └── conf       ├── bblayers.conf       ├── local.conf       └── templateconf.cfg
  43. 43. 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/yocto/poky/meta    /home/sprado/yocto/poky/meta­yocto    /home/sprado/yocto/poky/meta­yocto­bsp    " BBLAYERS_NON_REMOVABLE ?= "    /home/sprado/yocto/poky/meta    /home/sprado/yocto/poky/meta­yocto    "
  44. 44. 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"
  45. 45. Embedded Labworks LOCAL.CONF (OUTRAS VARIÁVEIS) ✗ A variável CORE_IMAGE_EXTRA_INSTALL pode ser usada para definir pacotes adicionais para incluir na imagem. ✗ As variáveis BB_NUMBER_THREADS e PARALLEL_MAKE permitem controlar a quantidade de threads que o bitbake irá utilizar durante o build. BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}" PARALLEL_MAKE ?= "­j ${@oe.utils.cpu_count()}" ✗ O manual de referência do Yocto Project contém uma lista das principais variáveis disponíveis.
  46. 46. Embedded Labworks COMPILANDO ✗ Com os arquivos bblayers.conf e local.conf configurados, é só iniciar o processo de compilação: $ bitbake core­image­minimal ✗ O comando acima irá processar a receita core­image­minimal.bb, que irá gerar uma imagem mínima para ser executada no target (selecionado pela variável MACHINE). ✗ Por padrão, todo o processo de build acontecerá no diretório tmp/, dentro do diretório de build. ✗ As imagens do sistema gerado estarão disponíveis em tmp/deploy/images/<machine>/.
  47. 47. 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
  48. 48. 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.
  49. 49. 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
  50. 50. 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
  51. 51. Embedded Labworks QEMU
  52. 52. Embedded Labworks LABORATÓRIO Gerando uma imagem mínima e testando no QEMU
  53. 53. Embedded Labworks Linux embarcado Wandboard Quad
  54. 54. Embedded Labworks WANDBOARD QUAD ✗ i.MX6 Quad (4 núcleos ARM Cortex-A9) rodando à 1GHz. ✗ 2G de RAM DDR3. ✗ Duas interfaces de cartão SD e uma interface SATA. ✗ Saídas de áudio (comum e S/PDIF) e vídeo HDMI. ✗ Ethernet Gigabit, USB host e OTG, WiFi, Bluetooth, serial, etc. http://wandboard.org
  55. 55. Embedded Labworks DISPLAY E PLACA ADAPTADORA ✗ Display LCD de 7” com resolução de 800x480 (WVGA) da Touch Revolution. ✗ Touchscreen capacitivo. ✗ Placa adaptadora para a Wandboard com suporte ao display de 7” da Touch Revolution e 4 botões.
  56. 56. Embedded Labworks REFERÊNCIAS E DOCUMENTAÇÃO ✗ A documentação do hardware esta disponível no ambiente de laboratório em docs/guides: ✗ IMX6DQRM.pdf (datasheet do i.MX6) ✗ WandboardQuadUserguide.pdf (guia de usuário da placa) ✗ FusionTouchDisplayDatasheet.pdf (datasheet do display) ✗ AdapterBoardSchematic.tar.gz (esquemático da placa adaptadora) ✗ Recursos na internet: http://wandboard.org/ https://community.freescale.com/
  57. 57. Embedded Labworks CONECTANDO O HARDWARE
  58. 58. Embedded Labworks Yocto Project Sistema de build
  59. 59. Embedded Labworks POKY E BITBAKE ✗ Poky é o sistema de build do Yocto Project. ✗ O Poky utiliza a ferramenta BitBake, desenvolvida em Python, para a execução de tarefas. ✗ O BitBake interpreta os metadados (metadata), define quais tarefas estão prontas para serem executadas, e as executa.
  60. 60. Embedded Labworks METADADOS ✗ São considerados metadados: ✗ Receitas (.bb, .bbappend). ✗ Classes (.bbclass). ✗ Arquivos de configuração (.conf).
  61. 61. Embedded Labworks RECEITAS ✗ Receitas (recipes) são arquivos com extensão .bb ou .bbappend. ✗ Possuem este nome porquê contém a "receita" para processar determinado componente de software. ✗ Podem incluir as seguintes informações: ✗ Descrição e versão do componente de software. ✗ Localização do código-fonte. ✗ Dependências de outros componentes de software. ✗ Procedimento de compilação. ✗ Procedimento de instalação.
  62. 62. 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
  63. 63. 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.
  64. 64. Embedded Labworks CLASSES ✗ Classes são arquivos com a extensão .bbclass, e são usadas para abstrair funcionalidades comuns que podem ser usadas por receitas. ✗ Exemplos de classes: ✗ autotools.bbclass: compilar projetos baseados em Autotools. ✗ cmake.bbclass: compilar projetos que utilizam o CMake. ✗ qt4e.bbclass: compilar aplicações para o Qt/Embedded 4.x. ✗ kernel.bbclass: compilar o kernel Linux. ✗ Para utilizar uma classe, a receita deve herdar a classe com a diretiva inherit.
  65. 65. Embedded Labworks BASE.BBCLASS ✗ A classe base.bbclass é herdada implicitamente por toda receita. ✗ Esta classe possui definições para tarefas comuns, incluindo o procedimento para baixar e descompactar o código-fonte, compilar projetos baseados em makefiles, etc. ✗ Uma definição das principais classes existentes está disponível na documentação do Yocto Project. http://www.yoctoproject.org/docs/current/ref-manual/ref- manual.html#ref-classes
  66. 66. 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
  67. 67. Embedded Labworks CAMADAS ✗ Os metadados (receitas, classes e arquivos de configuração) são organizados em camadas (layers) no sistema de build. ✗ As camadas encapsulam e isolam determinadas funcionalidades do sistema a ser gerado (suporte à determinado hardware, regras de geração do sistema, suporte à interface gráfica, etc). ✗ Cada camada é composta por um conjunto de metadados agrupados em um diretório do sistema de build. ✗ Um sistema Linux é gerado com o Yocto Project através da combinação de uma ou mais camadas.
  68. 68. Embedded Labworks CAMADAS (cont.) $ tree poky/ meta  ├── classes      │ ├── allarch.bbclass      │ ├── ...  ├── conf      │ ├── layer.conf  ├── recipes­bsp  ├── recipes­connectivity  ├── recipes­core  ├── ... meta­selftest meta­skeleton meta­yocto meta­yocto­bsp
  69. 69. 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).
  70. 70. Embedded Labworks BSP LAYER ✗ A camada de BSP (Board Support Package) fornece basicamente configurações da plataforma de hardware, também chamada de máquina (machine). Por exemplo: ✗ Arquitetura da CPU (arm, mips, powerpc, etc). ✗ Receitas para compilar o bootloader e o kernel. ✗ Definição da TTY para acesso à console serial. ✗ As principais variáveis usadas no contexto da camada de BSP estão disponíveis na documentação do Yocto Project. http://www.yoctoproject.org/docs/current/ref-manual/ref- manual.html#ref-varlocality-config-machine
  71. 71. Embedded Labworks META-YOCTO-BSP $ tree meta­yocto­bsp/ meta­yocto­bsp  ├── conf      │ ├── layer.conf      │ └── machine          │ ├── beaglebone.conf          │ ├── genericx86­64.conf          │ ├── genericx86.conf          │ ├── ...  ├── recipes­bsp      │ ├── ...  ├── recipes­core      │ ├── ...  ├── recipes­graphics      │ └── ...  └── recipes­kernel       └── ...
  72. 72. 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
  73. 73. Embedded Labworks META-YOCTO $ tree 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      │ └── ...  ├── recipes­core      │ └── ...  └── recipes­kernel       └── ...
  74. 74. 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
  75. 75. Embedded Labworks META-BROWSER $ tree meta­browser/ meta­browser/  ├── classes      │ └── mozilla.bbclass  ├── conf      │ └── layer.conf  ├── COPYING.MIT  ├── README  ├── recipes­browser      │ └── chromium  ├── recipes­devtools      │ └── ninja  ├── recipes­gnome      │ └── gnome­settings­daemon  └── recipes­mozilla       ├── firefox       └── ...
  76. 76. Embedded Labworks COMANDOS DO BITBAKE ✗ A ferramenta BitBake possui a seguinte sintaxe: $ bitbake <target> ✗ O campo <target> é normalmente a primeira parte do nome do arquivo de receita. Por exemplo, para compilar a receita busybox_1.22.1.bb: $ bitbake busybox ✗ Para executar apenas uma tarefa de uma receita, use a opção ­c: $ bitbake busybox ­c clean
  77. 77. Embedded Labworks COMANDOS DO BITBAKE (cont.) ✗ Para listar as tarefas de uma receita, execute a tarefa listtasks: $ bitbake busybox ­c listtasks ✗ A opção ­k faz com que o bitbake continue executando as tarefas, mesmo em caso de erro, até onde puder executar. $ bitbake ­k core­image­minimal ✗ Para ignorar as dependências da receita, use o parâmetro ­b: $ bitbake ­b busybox_1.22.1.bb
  78. 78. Embedded Labworks LIMPANDO A COMPILAÇÃO ✗ Para limpar apenas a saída da compilação (não limpa o cache de compilação): $ bitbake busybox ­c clean ✗ Para limpar a saída da compilação e o cache de compilação: $ bitbake busybox ­c cleansstate ✗ Para limpar a saída da compilação, o cache de compilação e o download do código-fonte: $ bitbake busybox ­c cleanall
  79. 79. Embedded Labworks POR DENTRO DO BITBAKE ✗ O propósito inicial do BitBake é executar as tarefas descritas nas receitas. ✗ Mas nosso objetivo final é gerar um sistema Linux customizado para o target. ✗ Qual então o procedimento utilizado pelo BitBake para ler os metadados definidos nas camadas, transformá-los em tarefas e executá-las? ✗ Em outras palavras, o que faz o BitBake no comando abaixo? $ bitbake core­image­minimal
  80. 80. 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.
  81. 81. 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.
  82. 82. Embedded Labworks INCLUDE HISTORY $ bitbake ­e # # INCLUDE HISTORY: # # /home/sprado/yocto/build/conf/bblayers.conf # /home/sprado/yocto/poky/meta/conf/layer.conf # /home/sprado/yocto/poky/meta­yocto/conf/layer.conf # /home/sprado/yocto/poky/meta­yocto­bsp/conf/layer.conf # conf/bitbake.conf includes: #   /home/sprado/yocto/poky/meta/conf/abi_version.conf #   conf/site.conf #   conf/auto.conf #   /home/sprado/yocto/build/conf/local.conf #   [...] #   /home/sprado/yocto/poky/meta/conf/machine/qemux86.conf #   [...] #   conf/machine­sdk/${SDKMACHINE}.conf #   /home/sprado/yocto/poky/meta­yocto/conf/distro/poky.conf #   [...] # /home/sprado/yocto/poky/meta/classes/base.bbclass includes: # [...]
  83. 83. Embedded Labworks PROCESSANDO A RECEITA ✗ Durante a leitura dos arquivos de configuração, a variável BBFILES será inicializada com uma lista receitas e arquivos de append existentes nas camadas habilitadas: BBFILES += "${LAYERDIR}/recipes­*/*/*.bb              ${LAYERDIR}/recipes­*/*/*.bbappend" ✗ As receitas e arquivos de append são lidos, um a um, e uma lista de tarefas é definida para cada receita.
  84. 84. Embedded Labworks PROCESSANDO A RECEITA (cont.) ✗ Por fim, o BitBake processa as tarefas da receita passada na linha de comandos (no nosso exemplo, core­image­minimal.bb). ✗ O processo completo está descrito de forma detalhada na documentação do BitBake. http://www.yoctoproject.org/docs/1.6/bitbake-user-manual/ bitbake-user-manual.html
  85. 85. Embedded Labworks RECEITAS DE IMAGEM ✗ Algumas receitas, como no caso da core­image­minimal.bb, são na verdade a definição de uma imagem. ✗ Estas receitas herdam a classe core­image e usam a variável IMAGE_INSTALL para definir quais pacotes serão instalados na imagem do sistema. ✗ As receitas de imagem ficam normalmente em um diretório chamado images, dentro do diretório das receitas de uma camada.
  86. 86. 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
  87. 87. Embedded Labworks RECEITAS DE IMAGEM (cont.) $ ls meta*/recipes*/images/*.bb meta/recipes­core/images/build­appliance­image_12.0.1.bb meta/recipes­core/images/core­image­base.bb meta/recipes­core/images/core­image­minimal.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 [...]
  88. 88. Embedded Labworks IMAGENS COMUNS ✗ core­image­minimal: imagem mínima apenas para iniciar em um terminal de linha de comando. ✗ core­image­full­cmdline: imagem mais completa com diversas ferramentas de linha de comando. ✗ core­image­x11: imagem com suporte ao servidor gráfico X11. ✗ core­image­sato: imagem da distribuição para dispositivos móveis baseado no Gnome chamado Sato.
  89. 89. 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
  90. 90. Embedded Labworks REPOSITÓRIOS GIT
  91. 91. 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.
  92. 92. Embedded Labworks FERRAMENTA REPO ✗ Portanto, trabalhar com o Yocto Project significa utilizar diferentes repositórios para compor o sistema de build. ✗ Para evitar o trabalho de baixar manualmente cada um dos repositórios, é comum o uso da ferramenta repo. ✗ Através de um arquivo XML, a ferramenta repo facilita o trabalho de clonar individualmente cada um dos repositórios que irão compor o sistema de build.
  93. 93. Embedded Labworks MANIFEST.XML <?xml version="1.0" encoding="UTF­8"?> <manifest>   <default sync­j="4" revision="fido"/>   <remote fetch="https://git.yoctoproject.org/git" name="yocto"/>   <remote fetch="https://github.com/Freescale" name="freescale"/>   <remote fetch="https://github.com/openembedded" name="oe"/>   <project remote="yocto" revision="fido" name="poky" path="sources/poky"/>   <project remote="yocto" revision="fido" name="meta­fsl­arm" path="sources/meta­fsl­arm"/>   <project remote="oe" revision="fido" name="meta­openembedded" path="sources/meta­openembedded"/>   <project remote="freescale" revision="fido" name="fsl­community­bsp­base" path="sources/base">     <copyfile dest="README" src="README"/>     <copyfile dest="setup­environment" src="setup­environment"/>   </project>   <project remote="freescale" revision="fido" name="meta­fsl­arm­extra"             path="sources/meta­fsl­arm­extra"/>   <project remote="freescale" revision="fido" name="meta­fsl­demos"             path="sources/meta­fsl­demos"/>   <project remote="freescale" revision="fido" name="Documentation"             path="sources/Documentation"/> </manifest>
  94. 94. Embedded Labworks BSP FREESCALE ✗ Por exemplo, o BSP da Freescale pode ser baixado através da ferramenta repo: $  repo  init  ­u  https://github.com/Freescale/fsl­community­ bsp­platform ­b fido $ repo sync ✗ A documentação e os procedimentos completos para utilizar o BSP da Freescale estão disponíveis no site do projeto. http://freescale.github.io/
  95. 95. Embedded Labworks LABORATÓRIO Compilando e testando uma imagem no target
  96. 96. Embedded Labworks Yocto Project Camadas
  97. 97. 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.
  98. 98. Embedded Labworks DIRETÓRIOS ✗ Cada camada é um diretório no sistema de build. ✗ O diretório da camada pode ter qualquer nome, porém o padrão adotado é iniciar com “meta­”. ✗ O repositório do Poky já vem com algumas camadas: $ ls ­d poky/meta* poky/meta           poky/meta­skeleton  poky/meta­yocto­bsp poky/meta­selftest  poky/meta­yocto ✗ O desenvolvedor pode agregar outras camadas se necessário.
  99. 99. 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/
  100. 100. 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.
  101. 101. 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"
  102. 102. 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"
  103. 103. 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"
  104. 104. 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"
  105. 105. 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.
  106. 106. 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
  107. 107. 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
  108. 108. 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).
  109. 109. Embedded Labworks SCRIPT DE CRIAÇÃO DE CAMADA (cont.) $ tree meta­labworks meta­labworks  ├── conf      │ └── layer.conf  ├── COPYING.MIT  └── README
  110. 110. Embedded Labworks LABORATÓRIO Criando camadas
  111. 111. Embedded Labworks Yocto Project Receitas
  112. 112. Embedded Labworks RECEITAS ✗ Receitas (recipes) são arquivos com extensão .bb, processados pela ferramenta BitBake para gerar os diversos componentes de software do sistema. ✗ O nome de um arquivo de receita possui o formato <pkgname>_<pkgversion>.bb. Exemplos: ✗ directfb_1.7.1.bb ✗ libdrm_2.4.52.bb ✗ libpng_1.6.16.bb ✗ Para processar uma receita, basta usar a primeira parte do seu nome: $ bitbake directfb
  113. 113. Embedded Labworks PACOTES ✗ Pacotes (packages) são o resultado do processamento da receita de um componente de software, agregado em algum formato popular de empacotamento (ipk, deb, rpm). ✗ Uma única receita pode gerar mais de um pacote de software. $ bitbake ­e unzip | grep ^PACKAGES= PACKAGES="unzip­dbg unzip­staticdev unzip­dev unzip­doc  unzip­locale unzip"
  114. 114. Embedded Labworks REPOSITÓRIO DE RECEITAS ✗ Antes de criar uma nova receita, verifique se já não existe algo pronto. ✗ O comando bitbake­layers permite exibir todas as receitas disponíveis nas camadas habilitadas no bblayers.conf: $ bitbake­layers show­recipes ✗ Uma base de dados de receitas é disponibilizada pela comunidade do Yocto Project e do OpenEmbedded na Internet: http://layers.openembedded.org/layerindex/branch/master/recipes/
  115. 115. Embedded Labworks COMPONENTES DE UMA RECEITA ✗ Uma receita é composta basicamente pela definição de tarefas e variáveis: ✗ As tarefas contém as instruções para o processamento da receita. ✗ As variáveis permitem parametrizar e moldar o comportamento das tarefas.
  116. 116. Embedded Labworks lzo_2.09.bb SUMMARY = "Lossless data compression library" HOMEPAGE = "http://www.oberhumer.com/opensource/lzo/" SECTION = "libs" LICENSE = "GPLv2+" LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263           file://src/lzo_init.c;beginline=5;endline=25;md5=355023835a9b9eeb70ab895395e951ff" SRC_URI = "http://www.oberhumer.com/opensource/lzo/download/lzo­${PV}.tar.gz             file://0001­Use­memcpy­instead­of­reinventing­it.patch             file://acinclude.m4             file://run­ptest             " SRC_URI[md5sum] = "c7ffc9a103afe2d1bba0b015e7aa887f" SRC_URI[sha256sum] = "f294a7ced313063c057c504257f437c8335c41bfeed23531ee4e6a2b87bc  b34c" inherit autotools ptest
  117. 117. Embedded Labworks VARIÁVEIS ✗ Diversas variáveis podem ser usadas para definir o comportamento do sistema de build durante o processamento da receita. Exemplos: ✗ As variáveis SUMMARY e DESCRIPTION permitem descrever a receita. ✗ A variável SRC_URI define a localização do código-fonte. ✗ As variáveis LICENSE e LIC_FILES_CHKSUM configuram informações de licença. ✗ Uma lista com algumas das principais variáveis que podem ser usadas para descrever uma receita está disponível no manual de referência do Yocto Project. http://www.yoctoproject.org/docs/current/ref-manual/ref- manual.html#ref-varlocality-recipes
  118. 118. Embedded Labworks VARIÁVEIS PN, PV e PR ✗ Algumas variáveis são inicializadas automaticamente pelo sistema de build durante o processamento de uma receita. ✗ Por exemplo, a variável PN será inicializada com o nome da receita e a variável PV com sua versão. ✗ No caso da receita libpng_1.6.8.bb, a variável PN será inicializada com libpng e a variável PV será inicializada com 1.6.8. ✗ A variável PR contém a revisão da receita, e por padrão é inicializada com "r0".
  119. 119. Embedded Labworks VARIÁVEL WORKDIR ✗ A variável WORKDIR contém o diretório onde a receita será processada, e é inicializada com o seguinte conteúdo: ${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}$ {PV}­${PR} ✗ Por exemplo, o resultado do processamento da receita busybox­ 1.23.1.bb para o emulador estará disponível em: tmp/work/i586­poky­linux/busybox/1.23.1­r0
  120. 120. Embedded Labworks VARIÁVEL S ✗ A variável S contém o diretório do código-fonte da receita, e é inicializada com o seguinte conteúdo: ${WORKDIR}/${PN}­${PV} ✗ Por exemplo, o código-fonte correspondente à receita busybox­ 1.23.1.bb estará disponível em: tmp/work/i586­poky­linux/busybox/1.23.1­r0/busybox­1.23.1
  121. 121. Embedded Labworks VARIÁVEL D ✗ A variável D contém o diretório de instalação da receita, e é inicializada com o seguinte conteúdo: ${WORKDIR}/image ✗ Por exemplo, o diretório de instalação da receita busybox­ 1.23.1.bb será: tmp/work/i586­poky­linux/busybox/1.23.1­r0/image
  122. 122. Embedded Labworks ATRIBUIÇÕES ✗ Durante o processamento de uma receita, o BitBake faz a análise (parsing) de todas as variáveis definidas em arquivos de configuração, arquivos de classe, receitas e arquivos de append. ✗ Durante esta análise, uma atribuição na mesma variável pode acontecer em diferentes arquivos do sistema de build. ✗ Por este motivo, é importante conhecer a sintaxe do BitBake ao atribuir um valor a uma variável.
  123. 123. 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"
  124. 124. 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"
  125. 125. Embedded Labworks CONCATENANDO ✗ Use o operador "+=" para concatenar no final de uma variável (append), e o operador "=+" para concatenar no começo de uma variável (prepend). VAR  = "value1" VAR =+ "value0" VAR += "value2" ✗ Os operadores "+=" e "=+" adicionam um espaço na concatenação. ✗ Use os operadores ".=" e "=." para concatenar sem adicionar espaços. VAR  = "value1" VAR =. "value0 " VAR .= " value2"
  126. 126. Embedded Labworks CONCATENANDO (cont.) ✗ A concatenação também pode ser feita adicionando "_append" e "_prepend" às variáveis. VAR         = "value1" VAR_prepend = "value0 " VAR_append  = " value2" ✗ Assim como os operadores ".=" e "=.", espaços não são adicionados automaticamente. ✗ Mas diferentemente dos operadores ".=" e "=.", onde a atribuição é realizada no momento da análise, usando este método a atribuição acontece somente no final do processo de análise (parsing).
  127. 127. Embedded Labworks REMOVENDO ✗ Para remover um valor de uma variável, basta adicionar "_remove" ao nome da variável: VAR        = "value1 value2 value1 value3" VAR_remove = "value1" ✗ O resultado final será: VAR = "value2 value3" ✗ Todas as ocorrências da string são removidas. ✗ Os espaços ao redor da string também são removidos.
  128. 128. Embedded Labworks OVERRIDES ✗ O BitBake provê um mecanismo chamado overrides para definir variáveis de forma condicional. ✗ Uma variável chamada OVERRIDES contém valores separados por dois-pontos (:). ✗ Estes valores podem ser usados para condicionar o valor de uma variável.
  129. 129. Embedded Labworks OVERRIDES (cont.) ✗ No exemplo abaixo, a variável VAR terá o conteúdo value2. OVERRIDES = "arm:armv7a:mx6:mx6dl:wandboard:wandboard­solo" VAR     = "value1" VAR_mx6 = "value2" VAR_ppc = "value3" ✗ É possível também concatenar de forma condicional usando "_append" ou "_prepend". VAR_append_mx6 = " value4"
  130. 130. Embedded Labworks TAREFAS ✗ Todas as receitas herdam automaticamente algumas classes durante seu processamento, incluindo a classe base.bbclass. ✗ Esta classe define algumas tarefas básicas como baixar o código- fonte, aplicar patches e compilar aplicações baseadas em Makefile. ✗ A lista de tarefas de uma receita pode ser exibida executando a tarefa listtasks: $ bitbake <recipe> ­c listtasks
  131. 131. Embedded Labworks HERDANDO CLASSES ✗ As receitas podem definir novas tarefas herdando de uma classe com a palavra-chave inherit. ✗ Por exemplo, para herdar as tarefas necessárias para compilar uma aplicação baseada em Autotools: inherit autotools ✗ Uma lista das principais classes existentes está disponível no manual de referência do Yocto Project. http://www.yoctoproject.org/docs/current/ref-manual/ref- manual.html#ref-classes
  132. 132. Embedded Labworks ALTERANDO TAREFAS EXISTENTES ✗ É possível redefinir uma tarefa existente: do_compile() {     # instructions to compile here } ✗ Ou então adicionar instruções à uma tarefa existente, utilizando _append ou _prepend no nome da tarefa: do_install_append() {     # extra install commands }
  133. 133. Embedded Labworks ADICIONANDO TAREFAS ✗ Tarefas podem ser adicionadas com a palavra-chave addtask: do_mkimage () {     # create image here } addtask mkimage after do_compile before do_install
  134. 134. Embedded Labworks ESCREVENDO TAREFAS ✗ As tarefas podem ser implementadas em shell script: do_install() {     install ­d ${D}${bindir}     install ­m 0755 main ${D}${bindir} } ✗ Ou em Python: python do_showdate() {     import time     print time.strftime('%d/%m/%Y', time.gmtime()) }
  135. 135. Embedded Labworks PROCESSAMENTO BÁSICO DE UMA RECEITA 1. Baixar o código-fonte (do_fetch). 2. Descompactar o código-fonte (do_unpack). 3. Aplicar patches (do_patch). 4. Adicionar informações de licença (do_configure). 5. Configurar (do_configure).
  136. 136. Embedded Labworks PROCESSAMENTO BÁSICO DE UMA RECEITA 6. Compilar (do_compile). 7. Instalar (do_install). 8. Empacotar (do_package). 9. Executar scripts pós-instalação (do_rootfs).
  137. 137. Embedded Labworks DO_FETCH ✗ A variável SRC_URI é utilizada para definir a localização do código-fonte. SRC_URI = "http://www.libsdl.org/release/SDL2­${PV}.tar.gz" ✗ O código-fonte pode ser obtido de diversas origens, incluindo HTTP, FTP, repositórios GIT e diretórios locais. ✗ O código-fonte é baixado para o diretório apontado pela variável DL_DIR, que contém por padrão <build_dir>/downloads/.
  138. 138. Embedded Labworks DO_FETCH (cont.) ✗ Mais de um arquivo pode ser definido na variável SRC_URI: SRC_URI = "http://www.busybox.net/downloads/busybox­${PV}.tar.bz2             file://get_header_tar.patch             file://busybox­appletlib­dependency.patch" ✗ Quando o protocolo usado é do tipo file://, os arquivos são procurados localmente, com o caminho relativo à variável FILESPATH do BitBake.
  139. 139. Embedded Labworks DO_FETCH (cont.) ✗ O valor da variável FILESPATH é definida por padrão pela classe base.bbclass, e inclui: ✗ Diretório files no mesmo diretório da receita. Ex: <dir_receita>/files/<arquivo.xyz>. ✗ Diretório com o nome da receita, no mesmo diretório da receita. Ex: <dir_receita>/<nome_receita>/<arquivo.xyz>. ✗ Diretório com o nome da receita e sua versão, no mesmo diretório da receita. Ex: <dir_receita>/<nome_receita>­<versao_receita>/  <arquivo.xyz>. ✗ Para estender o caminho de busca de arquivos pode-se usar a variável FILESEXTRAPATHS.
  140. 140. Embedded Labworks DO_FETCH (cont.) ✗ Se você estiver baixando um arquivo de um servidor remoto sem usar uma ferramenta de controle de versão, é necessário prover o md5 e o sha256 de cada URL nas variáveis SRC_URI[md5sum] e SRC_URI[sha256sum]. SRC_URI = "http://www.busybox.net/busybox­${PV}.tar.bz2;name=tarball             file://busybox­udhcpc­no_deconfig.patch" SRC_URI[tarball.md5sum] = "337d1a15ab1cb1d4ed423168b1eb7d7e" SRC_URI[tarball.sha256sum] = "ae0b029d0a9e4dd71a077a790840e496dd838998  e4571b87b60fed7462b6678b"
  141. 141. Embedded Labworks DO_FETCH (cont.) ✗ Se o código-fonte estiver disponível no repositório de uma ferramenta de controle de versão, é necessário definir as variáveis SRCREV e PV. SRCREV = "d9e0c438e10e2155513e5d26498af472c5137d65" PV = "1.22.1+git${SRCPV}" SRC_URI = "git://busybox.net/busybox.git"
  142. 142. Embedded Labworks DO_UNPACK ✗ O código-fonte será descompactado no diretório definido pela variável S. ✗ Se o código-fonte for baixado de uma ferramenta de controle de versão, é necessário definir a variável S. SRC_URI = "git://anongit.freedesktop.org/git/xorg/lib/${XORG_PN}" S = "${WORKDIR}/git"
  143. 143. Embedded Labworks DO_PATCH ✗ São tratados como patches todos os arquivos definidos na variável SRC_URI com extensão .patch ou .diff. ✗ Por padrão, será utilizada a opção "­p1" para aplicar os patches. ✗ Este comportamento pode ser alterado com a opção striplevel. SRC_URI = "file://dhcp­3.0.3­dhclient­dbus.patch;striplevel=0" ✗ A opção patchdir permite aplicar o patch a partir de um diretório específico. SRC_URI = "file://arm­thumb­mutex_db5.patch;patchdir=.."
  144. 144. Embedded Labworks DO_CONFIGURE ✗ A receita deve ter a variável LICENSE para especificar a licença do software: LICENSE = "GPLv2" ✗ Uma lista com o nome das licenças comuns está disponível em meta/files/common­licenses/. ✗ A receita deve conter também a variável LIC_FILES_CHKSUM para garantir que não houve mudanças no arquivo da licença. LIC_FILES_CHKSUM = "file://LICENSE;md5=44bc22578be94b6536c  8bdc3a01e5db9"
  145. 145. Embedded Labworks DO_CONFIGURE (cont.) ✗ A maioria das aplicações possui um mecanismo para configurar o software antes de iniciar a compilação (ex: autotools, cmake, etc). ✗ Normalmente, herda-se de uma classe a implementação desta tarefa (exemplo para o Autotools): inherit autotools ✗ A variável EXTRA_OECONF pode ser usada para passar opções extras para o script de configuração do autotools.
  146. 146. Embedded Labworks DO_COMPILE ✗ Assim como a tarefa de configuração, normalmente herda-se de uma classe a implementação da tarefa de compilação (exemplo para o cmake): inherit cmake ✗ Se necessário, é possível definir uma tarefa de compilação customizada: do_compile() {      ${CC} test.c ­o test } ✗ As variáveis EXTRA_OEMAKE e EXTRA_OECMAKE podem ser usadas para passar comandos extras para as ferramentas make e cmake, respectivamente.
  147. 147. Embedded Labworks DO_INSTALL ✗ Assim como as tarefas de configuração e compilação, normalmente herda-se de uma classe a implementação desta tarefa. ✗ Se necessário, você pode definir e implementar uma tarefa do_install customizada. ✗ É possível também complementar a instalação definindo a tarefa do_install_append. ✗ A instalação é realizada no diretório apontado pela variável D, que por padrão contém ${WORKDIR}/image.
  148. 148. Embedded Labworks DO_PACKAGE ✗ O objetivo desta tarefa é empacotar os diversos componentes de software da receita. ✗ Os componentes lógicos do software (binário, binário com símbolo de debug, documentação, etc) são empacotados no diretório ${WORKDIR}/packages­split. ✗ Os pacotes finais para instalação no target são gerados em ${WORKDIR}/deploy­rpms.
  149. 149. Embedded Labworks DO_ROOTFS ✗ Os scripts de pós-instalação são executados durante a criação da imagem ou após a instalação de um pacote no target. ✗ Para adicionar um script de pós-instalação, basta adicionar a função pkg_postinst_<PACKAGENAME> na receita, onde <PACKAGENAME> é o nome do pacote. pkg_postinst_${PN} () {     #!/bin/sh ­e     # Commands to execute on the target rootfs }
  150. 150. Embedded Labworks DEPENDÊNCIAS ✗ Um pacote pode depender de outro pacote em tempo de compilação ou em tempo de execução. ✗ Para indicar estas dependências, as seguintes variáveis podem ser usadas: ✗ DEPENDS: dependências de compilação do pacote (a tarefa do_configure do pacote depende da tarefa do_populate_sysroot da sua dependência). ✗ RDEPENDS: dependências de execução do pacote (a tarefa do_build do pacote depende da tarefa do_package_write da sua dependência).
  151. 151. Embedded Labworks MODELO DE RECEITA SUMMARY = "" HOMEPAGE = "" LICENSE = "" LIC_FILES_CHKSUM = "" SRC_URI = "" SRC_URI[md5sum] = "" SRC_URI[sha256sum] = "" inherit <some_class>
  152. 152. 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} }
  153. 153. 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
  154. 154. Embedded Labworks INCLUDE E REQUIRE ✗ O BitBake permite o uso das diretivas de inclusão de arquivos include e require. include udev.inc ✗ O arquivo incluído deve estar no mesmo diretório do arquivo que está incluindo, ou então deve-se usar um caminho relativo existente na variável BBPATH. ✗ No caso da diretiva include, se o arquivo não for encontrado, o processamento continua normalmente. ✗ No caso da diretiva require, se o arquivo não for encontrado, acontecerá um erro no processamento da receita.
  155. 155. Embedded Labworks udev_182.bb include udev.inc PR = "r9" DEPENDS += "module­init­tools" SRC_URI[md5sum] = "1b964456177fbf48023dfee7db3a708d" SRC_URI[sha256sum] = "7857ed19fafd8f3ca8de410194e8c7336e9eb  82A0626ea8a4ba6449b017faba4"
  156. 156. 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.
  157. 157. Embedded Labworks ARQUIVOS DE APPEND (cont.) ✗ Um arquivo de append permite implementar customizações na sua camada, alterando o comportamento de receitas de outras camadas, sem precisar alterar o código original da receita. ✗ É comum o uso da variável FILESEXTRAPATHS no arquivo de append para indicar ao sistema de build o local de arquivos adicionais (ex: patches). FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}­${PV}:"
  158. 158. Embedded Labworks alsa-lib_1.0.28.bb $ ls poky/meta/recipes­multimedia/alsa/ alsa­lib_1.0.28.bb $ tree meta­fsl­arm/recipes­multimedia/alsa/ ./meta­fsl­arm/recipes­multimedia/alsa/  ├── alsa­lib      │ └── 0001­add­conf­for­multichannel­support­in­imx.patch  └── alsa­lib_%.bbappend $ cat meta­fsl­arm/recipes­multimedia/alsa/alsa­lib_%.bbappend  FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" SRC_URI_append_mx6 = " file://0001­add­conf­for­multichannel­ support­in­imx.patch"
  159. 159. Embedded Labworks VERSIONAMENTO ✗ As variáveis PV, PE e PR compõem o versionamento de um pacote. ✗ PV (Package Version): versão do pacote, lido normalmente do nome da receita. ✗ PE (Package Epoch): por padrão vazia, mas deve ser usada caso o esquema de versionamento do pacote seja alterado. ✗ PR (Package Revision): por padrão r0, mas deve ser alterada caso haja alteração na receita (pode ser automatizado com um servidor chamado bitbake­prserv). ✗ A versão de cada pacote pode ser exibida com o comando abaixo: $ bitbake ­s
  160. 160. Embedded Labworks VERSIONAMENTO (cont.) $ bitbake ­s [...] cups                                                :2.0.2­r0 curl                                               :7.40.0­r0 curl­native                                        :7.40.0­r0 cwautomacros                                     :20110201­r0 cwautomacros­native                              :20110201­r0 damageproto                                        1:1.2.1­r1 damageproto­native                                 1:1.2.1­r1 db                                                 :6.0.30­r0 db­native                                          :6.0.30­r0 dbus                                               :1.8.10­r0 dbus­glib                                           :0.102­r0 dbus­glib­native                                    :0.102­r0 [...]
  161. 161. Embedded Labworks VERSIONAMENTO (cont.) ✗ Se existir mais de uma versão da mesma receita, por padrão o BitBake seleciona a última versão. ✗ Se as receitas estiverem em camadas com prioridades diferentes (BBFILE_PRIORITY), a receita na camada de maior prioridade é selecionada.
  162. 162. Embedded Labworks VERSIONAMENTO (cont.) ✗ A variável PREFERRED_VERSION pode ser usada em um arquivo de configuração para determinar a receita que deve ter preferência. PREFERRED_VERSION_gtk+ ?= "2.13.3" ✗ Uma receita pode usar a variável DEFAULT_PREFERENCE para definir sua prioridade (por padrão 0, quanto maior mais prioritária). DEFAULT_PREFERENCE = "­1"
  163. 163. Embedded Labworks PROCESSAMENTO DA RECEITA ✗ A receita é processada no diretório apontado pela variável WORKDIR. $ ls tmp/work/i586­poky­linux/zlib/1.2.8­r0/ debugsources.list        pkgdata deploy­rpms              pseudo image                    remove.ldconfig.call.patch ldflags­tests.patch      run­ptest license­destdir          sysroot­destdir Makefile­runtests.patch  temp package                  zlib­1.2.8 packages­split           zlib.spec
  164. 164. 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.
  165. 165. 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.
  166. 166. Embedded Labworks DEPURANDO ✗ No caso de erro no processamento de uma receita, verifique os logs gerados no diretório temp/, dentro do diretório de processamento da receita. $ ls temp/ log.do_compile log.do_compile.29699 log.do_configure log.do_configure.29225 [...] run.do_compile run.do_compile.29699 run.do_configure run.do_configure.29225 [...]
  167. 167. Embedded Labworks DEPURANDO (cont.) ✗ Na dúvida sobre o conteúdo de uma variável, utilize a opção ­e do BitBake: $ bitbake ­e <target> | grep <VAR> ✗ Utilize a opção ­c do BitBake para executar uma tarefa específica: $ bitbake ­c compile <target> ✗ Se necessário, limpe os caches de processamento da receita executando a tarefa cleansstate. $ bitbake ­c cleansstate <target>
  168. 168. Embedded Labworks DEVSHELL ✗ A tarefa devshell permite abrir um novo terminal para depurar o processamento de uma receita. $ bitbake unzip ­c devshell ✗ Neste novo terminal, todas as variáveis de ambiente necessárias para a compilação estarão definidas, possibilitando utilizar diretamente comandos como o configure e o make. ✗ Esta tarefa é útil também para gerar patches durante o desenvolvimento do sistema.
  169. 169. Embedded Labworks REFERÊNCIAS ✗ Para mais informações sobre o processo de criação de uma receita: http://www.yoctoproject.org/docs/current/dev-manual/dev- manual.html#new-recipe-writing-a-new-recipe ✗ Para mais informações sobre a sintaxe do BitBake: http://www.yoctoproject.org/docs/current/bitbake-user- manual/bitbake-user-manual.html
  170. 170. Embedded Labworks LABORATÓRIO Criando e customizando receitas
  171. 171. Embedded Labworks Yocto Project Customizações
  172. 172. Embedded Labworks CUSTOMIZANDO UMA IMAGEM ✗ Durante o desenvolvimento de um sistema Linux com o Yocto Project, pode ser necessário customizar a imagem final gerada por diversos motivos, dentre eles: ✗ Adicionar ou remover componentes de software. ✗ Adicionar ou remover arquivos do sistema (arquivos de configuração, binários, etc). ✗ Adicionar ou remover usuários e configurar senhas. ✗ Configurar permissões de arquivos e diretórios. ✗ Modificar o tipo e formato da imagem final gerada para instalação no target.
  173. 173. Embedded Labworks COMO CUSTOMIZAR? ✗ Uma imagem pode ser customizada de diversas formas: ✗ Alterações locais podem ser realizadas no arquivo local.conf (ex: adição de pacotes de software para testes). ✗ A imagem final do rootfs pode ser customizada através de uma receita de imagem (conjunto de pacotes, tamanho e tipo do rootfs, etc). ✗ Políticas globais sobre como uma imagem é gerada podem ser definidas em uma distribuição (ex: funcionalidades básicas, biblioteca do sistema, etc).
  174. 174. 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).
  175. 175. 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"
  176. 176. Embedded Labworks ALTERANDO O LOCAL.CONF (cont.) ✗ Alterar diretamente o local.conf para customizar uma imagem possui algumas deficiências: ✗ Permite apenas alguns tipos de customizações, como a adição de pacotes de software. ✗ A alteração afeta todos os builds que utilizam o local.conf. ✗ Se você não tomar cuidado, poderá sobrepor uma configuração importante da imagem ou da distribuição. ✗ É complicado documentar ou versionar as alterações de forma que seja possível reproduzir o build em uma outra máquina. ✗ Por este motivo, é aconselhável criar uma camada e realizar as alterações em uma receita de imagem e/ou distribuição.
  177. 177. Embedded Labworks RECEITAS DE IMAGENS ✗ Receitas de imagem permitem uma maior flexibilidade e controle na customização da imagem final. ✗ Normalmente, as receitas de imagem ficam em um diretório chamado images no diretório de receitas da camada. $ ls meta/recipes­core/images/ build­appliance­image            core­image­minimal­dev.bb build­appliance­image_12.0.1.bb  core­image­minimal­initramfs.bb core­image­base.bb               core­image­minimal­mtdutils.bb core­image­minimal.bb ✗ As receitas de imagem disponíveis podem ser exibidas com a ferramenta bitbake­ layers. $ bitbake­layers show­recipes "*­image*"
  178. 178. 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"
  179. 179. Embedded Labworks CRIANDO RECEITAS DE IMAGENS ✗ Ao criar uma receita de imagem, procure basear sua receita em outras existentes. ✗ Você pode simplesmente copiar uma outra receita de imagem para a sua camada e customizá-la. ✗ É possível também se basear em uma receita existente com a diretiva require: require recipes­core/images/core­image­minimal.bb ✗ E então você pode adicionar pacotes à imagem utilizando as variáveis IMAGE_INSTALL , CORE_IMAGE_EXTRA_INSTALL e IMAGE_FEATURES.
  180. 180. 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"
  181. 181. Embedded Labworks RECEITAS X PACOTES ✗ Sabemos que uma receita poderá gerar mais de um pacote. ✗ Mas não necessariamente os pacotes gerados terão o mesmo nome da receita. ✗ As variáveis IMAGE_INSTALL e CORE_IMAGE_EXTRA_INSTALL devem ser configuradas com o nome do pacote, e não da receita!
  182. 182. Embedded Labworks RECEITAS X PACOTES (cont.) $ bitbake ­e python | grep ^PACKAGES= PACKAGES="python­ptest  libpython2  python­dbg  python­2to3  python­ argparse  python­audio  python­bsddb  python­codecs  python­compile  python­compiler  python­compression  python­contextlib  python­core  python­crypt  python­ctypes  python­curses  python­datetime  python­db  python­debugger  python­dev  python­difflib  python­distutils­staticdev  python­distutils  python­doctest  python­elementtree  python­email  python­fcntl  python­gdbm  python­hotshot  python­html  python­idle  python­image  python­importlib  python­io  python­json  python­lang  python­logging  python­mailbox  python­math  python­mime  python­mmap  python­multiprocessing  python­netclient  python­netserver  python­ numbers  python­pickle  python­pkgutil  python­pprint  python­profile  python­pydoc  python­re  python­readline  python­resource  python­ robotparser  python­shell  python­smtpd  python­sqlite3  python­sqlite3­ tests  python­stringold  python­subprocess  python­syslog  python­ terminal  python­tests  python­textutils  python­threading  python­ tkinter  python­unittest  python­unixadmin  python­xml  python­xmlrpc  python­zlib python­modules python­misc python­man"
  183. 183. Embedded Labworks PACOTES DE UMA IMAGEM ✗ Os pacotes instalados em uma imagem podem ser exibidos listando o arquivo de manifesto da imagem: $ cat tmp/deploy/images/qemux86/core­image­minimal­qemux86.manifest base­files qemux86 3.0.14 base­passwd i586 3.5.29 busybox i586 1.22.1 busybox­hwclock i586 1.22.1 busybox­syslog i586 1.22.1 busybox­udhcpc i586 1.22.1 copybin i586 1.0.0 init­ifupdown qemux86 1.0 initscripts i586 1.0 initscripts­functions i586 1.0 kernel­3.14.0­yocto­standard qemux86 3.14+git0+09424... kernel­module­uvesafb qemux86 3.14+git0+09424... [...]
  184. 184. Embedded Labworks GRUPOS DE PACOTES ✗ Um grupo de pacotes (package groups) é basicamente um conjunto de pacotes de software com um objetivo comum. ✗ Alguns exemplos: ✗ Pacotes de software básico do sistema (base files, busybox, login, etc). ✗ Pacotes de software para habilitar o stack gráfico (x11-server, x11- common, xrandr, etc). ✗ Pacotes de software do produto desenvolvido pela empresa (aplicações, bibliotecas, etc).
  185. 185. Embedded Labworks GRUPOS DE PACOTES (cont.) ✗ Normalmente, os grupos de pacotes ficam em um diretório chamado packagegroups no diretório de receitas da camada: $ ls meta/recipes­core/packagegroups nativesdk­packagegroup­sdk­host.bb packagegroup­base.bb packagegroup­core­boot.bb packagegroup­core­buildessential.bb packagegroup­core­eclipse­debug.bb packagegroup­core­nfs.bb packagegroup­core­sdk.bb packagegroup­core­ssh­dropbear.bb packagegroup­core­ssh­openssh.bb packagegroup­core­standalone­sdk­target.bb [...]
  186. 186. Embedded Labworks packagegroup-core-x11-base.bb SUMMARY = "Basic X11 session" DESCRIPTION = "Packages required to set up a basic working  X11 session" inherit packagegroup [...] RDEPENDS_${PN} = "     packagegroup­core­x11­xserver      packagegroup­core­x11­utils      dbus      pointercal      matchbox­terminal      matchbox­wm      mini­x­session      liberation­fonts      "
  187. 187. Embedded Labworks USANDO GRUPOS DE PACOTES NA RECEITA ✗ Um grupo de pacotes pode ser adicionado a uma imagem normalmente através das variáveis IMAGE_INSTALL e CORE_IMAGE_EXTRA_INSTALL. ✗ Por exemplo, para adicionar o suporte básico ao X11, você poderia alterar a receita da sua imagem conforme abaixo: IMAGE_INSTALL += "packagegroup­core­x11­base"
  188. 188. Embedded Labworks IMAGE FEATURES ✗ As features de imagem permitem agrupar um conjunto de grupos de pacotes (package groups) para adicionar uma funcionalidade à imagem gerada. ✗ As features de imagem disponíveis estão definidas na classe core­ image.bbclass. FEATURE_PACKAGES_x11 = "packagegroup­core­x11" FEATURE_PACKAGES_nfs­server = "packagegroup­core­nfs­server" FEATURE_PACKAGES_ssh­server­openssh = "packagegroup­core­ssh­openssh" FEATURE_PACKAGES_qt4­pkgs = "packagegroup­core­qt­demoapps" FEATURE_PACKAGES_hwcodecs = "${MACHINE_HWCODECS}" [...]
  189. 189. Embedded Labworks IMAGE FEATURES (cont.) ✗ Para habilitar uma feature de imagem em uma receita, basta usar a variável IMAGE_FEATURES, conforme abaixo: IMAGE_FEATURES += "x11­base" ✗ Também é possível habilitar uma feature de imagem através da variável EXTRA_IMAGE_FEATURES. EXTRA_IMAGE_FEATURES += "x11­base"
  190. 190. Embedded Labworks IMAGE FEATURES (cont.) ✗ Durante o processo de build, o BitBake adiciona os grupos de pacotes das features de imagens habilitadas na variável IMAGE_INSTALL. ✗ Uma lista das principais features de imagens está disponível no manual de referência do Yocto Project. http://www.yoctoproject.org/docs/current/ref-manual/ref- manual.html#ref-features-image ✗ Existem ainda as features de máquina (machine features) e as features de distribuição (distro features), que estudaremos mais adiante no treinamento.
  191. 191. Embedded Labworks REMOVENDO UM PACOTE ✗ A variável PACKAGE_EXCLUDE permite excluir um pacote da imagem. Neste caso, o processo de build pode falhar caso algum outro pacote dependa dele. ✗ A variável BAD_RECOMMENDATIONS permite remover da imagem final um pacote que foi instalado através da variável RRECOMMENDS. ✗ A variável NO_RECOMMENDATIONS permite remover da imagem todos os pacotes que foram instalados através da variável RRECOMMENDS.
  192. 192. 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/*"
  193. 193. Embedded Labworks PERMISSÕES DE ARQUIVOS ✗ Por padrão, o sistema de build utiliza o arquivo fs­perms.txt disponível em meta/files/ para definir as permissões de arquivos e diretórios do rootfs gerado. ✗ É possível alterar este arquivo de configuração de permissões através da variável FILESYSTEM_PERMS_TABLES. ✗ Esta configuração deve ser realizada em uma camada separada, por exemplo em uma distribuição.
  194. 194. Embedded Labworks fs-perms.txt # This file contains a list of files and directories with known permissions. # It is used by the packaging class to ensure that the permissions, owners  # and group of listed files and directories are in sync across the system. [...] ${mandir}               0755    root    root    true    0644    root    root ${infodir}              0755    root    root    true    0644    root    root ${docdir}               0755    root    root    true    0644    root    root ${datadir}/gtk­doc      0755    root    root    true    0644    root    root [...] /home                   0755    root    root    false   ­       ­       ­ /srv                    0755    root    root    false   ­       ­       ­ ${prefix}/src           0755    root    root    false   ­       ­       ­ ${localstatedir}/local  0755    root    root    false   ­       ­       ­ [...]
  195. 195. 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"
  196. 196. 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.
  197. 197. Embedded Labworks POSTINSTALL SCRIPTS (cont.) pkg_postinst_PACKAGENAME () {     #!/bin/sh ­e     # Commands to execute }
  198. 198. 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 }
  199. 199. 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 ; "
  200. 200. 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.
  201. 201. Embedded Labworks GERANDO IMAGENS ✗ A variável IMAGE_FSTYPES pode ser usada para alterar o tipo de imagem gerada para o rootfs. IMAGE_FSTYPES += "ext4 squashfs" ✗ Uma lista dos tipos de imagens existentes está disponível na variável IMAGE_TYPES declarada na classe image_types.  bbclass.
  202. 202. Embedded Labworks GERANDO IMAGENS (cont.) ✗ Parâmetros adicionais para a geração da imagem podem ser passados através da variável EXTRA_IMAGECMD. EXTRA_IMAGECMD_ext3 ?= "­i 4096" ✗ Imagens customizadas podem ser geradas utilizando a variável IMAGE_CMD ou implementando uma classe específica (vide image_types_fsl.bbclass na camada meta­fsl­arm).
  203. 203. 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
  204. 204. Embedded Labworks ALTERANDO O TAMANHO DA IMAGEM (cont.) ✗ Se a variável IMAGE_ROOTFS_SIZE não for definida, ou se seu valor não for suficiente para suportar o sistema gerado, o rootfs será gerado através da multiplicação do tamanho do rootfs pela variável IMAGE_OVERHEAD_FACTOR, que por padrão tem o valor 1.3, gerando uma image 30% maior que o valor mínimo necessário. ✗ A documentação do mecanismo de cálculo do tamanho da imagem está disponível no manual de referência do Yocto Project. http://www.yoctoproject.org/docs/current/ref-manual/ref- manual.html#var-IMAGE_ROOTFS_SIZE
  205. 205. Embedded Labworks OUTRAS VARIÁVEIS ✗ A variável IMAGE_BASENAME define o nome que será utilizado nos arquivos de saída da imagem, que por padrão recebem o nome da receita. IMAGE_BASENAME = "myproduct" ✗ Para adicionar suporte à localização, pode-se usar a variável IMAGE_LINGUAS: IMAGE_LINGUAS = "pt­br en­us" ✗ Procure por variáveis que começam com IMAGE_ no manual de referência do Yocto Project.
  206. 206. 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/.
  207. 207. 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.
  208. 208. 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
  209. 209. Embedded Labworks VARIÁVEIS DE UMA DISTRO ✗ A variável DISTRO_NAME permite configurar o nome da distribuição. ✗ Uma distribuição pode ser versionada com a variável DISTRO_VERSION. ✗ A variável PACKAGE_CLASSES permite definir o tipo de pacote que será utilizado pela distribuição.
  210. 210. Embedded Labworks VARIÁVEIS DE UMA DISTRO (cont.) ✗ Pacotes específicos da distribuição podem ser adicionados à variável DISTRO_EXTRA_RDEPENDS. ✗ A variável DISTRO_EXTRA_RRECOMMENDS permite adicionar pacotes caso eles existam. ✗ A variável PREFERRED_VERSION é normalmente utilizada para definir as versões dos pacotes que serão utilizados pela distribuição.
  211. 211. Embedded Labworks VARIÁVEIS DE UMA DISTRO (cont.) ✗ A variável TCMODE permite definir o toolchain que será utilizado para construir a distribuição (contém por padrão "default", que significa construir e utilizar um toolchain interno). ✗ A variável TCLIBC permite definir qual libc será utilizada (eglibc ou uclibc). ✗ As variáveis PREMIRRORS e MIRRORS permitem definir fontes alternativas para download de código-fonte.
  212. 212. Embedded Labworks DISTRO FEATURES ✗ Uma feature de distribuição permite controlar as características de software da distribuição. ✗ Inclusão automática de pacotes na distribuição. ✗ Em alguns casos, altera o comportamento de scripts de configuração.
  213. 213. Embedded Labworks bind_9.9.5.bb SUMMARY = "ISC Internet Domain Name Server" HOMEPAGE = "http://www.isc.org/sw/bind/" SECTION = "console/network" [...] ENABLE_IPV6 = "­­enable­ipv6=${@bb.utils.contains('DISTRO_FEATURES', 'ipv6',                                                         'yes', 'no', d)}" EXTRA_OECONF = " ${ENABLE_IPV6} ­­with­randomdev=/dev/random ­­disable­threads                   ­­disable­devpoll ­­disable­epoll ­­with­gost=no                   ­­with­gssapi=no ­­with­ecdsa=yes                   ­­sysconfdir=${sysconfdir}/bind                   ­­with­openssl=${STAGING_LIBDIR}/..                   ­­enable­exportlib ­­with­export­includedir=${includedir}                         ­­with­export­libdir=${libdir} " [...]
  214. 214. Embedded Labworks DISTRO FEATURES (cont.) ✗ Exemplos de features de distribuição: ✗ alsa: inclui suporte à camada de áudio do kernel. ✗ directfb: suporte à biblioteca gráfica Directfb. ✗ ipv6: suporte ao protocolo IPv6. ✗ systemd: suporte ao mecanismo de inicialização systemd. ✗ As principais features de distribuição estão disponíveis no manual de referência do Yocto Project. http://www.yoctoproject.org/docs/current/ref-manual/ref- manual.html#ref-features-distro
  215. 215. Embedded Labworks DICAS PARA CUSTOMIZAÇÃO ✗ Utilize o local.conf sempre que precisar realizar testes, mas centralize as modificações no sistema de build em uma camada separada. ✗ Em alguns casos, pode ser necessário implementar mais de uma camada: ✗ Normalmente, camadas de distro e BSP são mantidas em camadas separadas. ✗ Pode ser necessário dividir em camadas caso os projetos sejam mantidos por equipes diferentes. ✗ Divida em camadas as receitas de produtos com características diferentes. ✗ Versione as camadas implementadas em repositórios Git.
  216. 216. Embedded Labworks DICAS PARA CUSTOMIZAÇÃO (cont.) ✗ Não misture o código da aplicação com os metadados. ✗ Ao invés de duplicar arquivos de receitas, use arquivos de append para modificar o comportamento das receitas. ✗ Para atualizar a versão de uma receita, crie um novo arquivo de receita, e se possível contribua de volta à comunidade.
  217. 217. Embedded Labworks DICAS PARA CUSTOMIZAÇÃO (cont.) ✗ Se necessário, crie uma distribuição com as configurações e políticas que servirão de base para seus produtos. ✗ Crie uma receita de imagem para cada produto a ser desenvolvido. ✗ Se achar interessante, crie variantes de receitas de imagem para diferentes tipos de build (debug, produção, etc).
  218. 218. Embedded Labworks LABORATÓRIO Customizando o sistema
  219. 219. Embedded Labworks Yocto Project Board Support Package
  220. 220. Embedded Labworks BSP E MACHINE ✗ Um BSP (Board Support Package) contém todo o código-fonte necessário para uma plataforma de hardware suportar determinado sistema operacional, no nosso caso o kernel Linux. ✗ Para incluir o suporte a uma plataforma de hardware no Yocto Project é necessário implementar uma machine em uma camada de BSP. ✗ Por padrão, o Yocto Project já possui algumas machines implementadas (QEMU, Beaglebone, Edgerouter, etc).
  221. 221. Embedded Labworks BSP E MACHINE (cont.) ✗ No início do desenvolvimento do seu produto, verifique se já existe uma implementação de machine para a sua plataforma de hardware. Caso contrário, será necessário desenvolvê-la. ✗ Uma base de dados de camadas de BSP e machines existentes é disponibilizada pela comunidade do Yocto Project e do OpenEmbedded na Internet. http://layers.openembedded.org/layerindex/branch/master/machines/
  222. 222. Embedded Labworks CAMADAS DE BSP ✗ Machines são implementadas em camadas de BSP, que possuem a mesma aparência de camadas de distribuição ou de software: ✗ Contém um arquivo de configuração da camada (layer.conf). ✗ Contém diversas receitas para a compilação do BSP (bootloader, kernel, servidor gráfico, ferramentas de profiling). ✗ Contém a implementação de classes adicionais que serão usadas pelas receitas da camada. ✗ Porém, diferentemente das camadas de distribuição e software, a camada de BSP possui também arquivos de configuração de machines, disponíveis em conf/machine/.
  223. 223. 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
  224. 224. Embedded Labworks CRIANDO UMA CAMADA DE BSP ✗ Uma camada de BSP pode ser criada manualmente ou através da ferramenta yocto­bsp: $ yocto­bsp ­h ✗ Está disponível um guia para a criação de BSPs no site do Yocto Project. http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html
  225. 225. Embedded Labworks CRIANDO UMA MACHINE ✗ Uma das principais tarefas na implementação de um BSP para o Yocto Project está na definição do arquivo de configuração da máquina (machine). ✗ Neste arquivo, deve-se definir informações sobre o bootloader, kernel, drivers, camada gráfica, parâmetros de otimização do compilador, etc. ✗ Uma forma de implementar uma machine é se basear na implementação de uma machine existente cujas características de hardware são próximas à plataforma-alvo.

×