Yocto Project E Como Usá-Lo Em Seu Próximo Projeto

padtec.com Introdução ao Yocto Project e como usá-lo em seu próximo projeto

João Freitas [email protected]

padtec.com [email protected] http://www.github.com/joaohf

padtec.com Linux Embarcado

Aplicação Aplicação • Fim específico • Conjunto reduzido • Autonomia Biblioteca Biblioteca Biblioteca

Toolchain Biblioteca C

Linux Kernel

Hardware

Bootloader

• Tamanho reduzido Linux Kernel • Particionamento

rootfs1

rootfs2

data

Opções para construção:

• Distribuição pronta • Gerar uma distribuição manualmente • Usar um sistema de build

● Usar uma distribuição pronta

– Red Hat – Ubuntu – Suse – Archlinux – Slackware – Debian – Android, Emdebian, Tizen

● Gerar uma distribuição manualmente

– Controle Total – Flexibilidade – Trabalhoso – Reprodutibilidade

● Linux From Scratch: vale a experiência!

– http://www.linuxfromscratch.org/

● Ferramenta de Build

– Automatização do processo de geração – Conjunto de pacotes validados – Frameworks para extensão e desenvolvimento

● Buildroot, PTXdist, LTIB, BaseRock, OpenEmbedded, Poky

Unidade SI de medição, igual a 10^24

http://www.yoctoproject.org

● Projeto Open Source

● Build System para Linux OS

● Coleção de projetos, métodos e ferramentas

– Fácil customização – Um lugar para a Indústria publicar BSPs

● Fundado em 2010

● Gerenciado por membros da Linux Foundation

● Cadência de releases: 6 meses

● “The Yocto Project is not an Embedded Linux Distribution – It creates a custom one for You!”

● “The Yocto Project is not Single Open Source Project – It is an Ecosystem”

● “The Yocto Project combines the convenience of a ready-to-run Linux Distribuition with the flexibility of a custom Linux operation system stack”

● “... to bring some order to the chaos of embedded Linux development”

● Comunidade de usuários

● Organizações

– Desenvolvedores individuais – Embeded Hardware – Semicondutores – OS Vendors

● Linux Foundation

● Adivisory Board

– LSI, Freescale, Wind River, OpenEmbedded – TI, Intel, LTSI, Juniper Networks, AMD – Mentor Graphics, LG, Dell, Broadcom, – Renesas, OS Systems, MontaVista, Huawei, – Enea

● Participantes

● Membros

● Colaboradores

● Distros Comerciais

– Wind River Linux Carrier Grade Profile 5 – Wind River Linux 6 – Enea Linux 4.0 – MontaVista Linux Carrier Grade Edition 7 – Mentor Embedded Linux

● Distros

– Angstron (http://www.angstrom-distribution.org) – Shr (http://shr-project.org)

● BSP (Board Support Package)

– Intel – Freescale – Texas Instruments – Renesas – AMD

Para começar... ● PC padrão

● 50Gb de disco

● Um distro recente (debian, ubuntu, fedora, opensuse, centos)

● Pacotes de desenvolvimento (gcc,make,git)

● Uma release do Yocto Project

● http://www.yoctoproject.org/docs/1.7/yocto-project-qs/yocto-project-qs.ht ml

● Se quiser brincar profissionalmente:

– Processador Xeon, 16Gb RAM, 1Tb Disco, controlador RAID com cache alto

● Em casa: i5 terceira geração com 16Gb RAM e 1Tb HD 7200 SATA

● Um bom processador e disco com controladora rápida vai fazer a diferença.

● Build System:

– Poky reference system

● Bitbake: build engine

● OpenEmbedded Core: receitas e classes bases – http://www.openembedded.org ● Core BSPs e layers

● Ferramentas de desenvolvimento

– Application Development Toolkit – Hob – Toaster

● Eclise IDE Plugin: integração entre ADT e Eclipse

● AutoBuilder: build tests e QA

● cross-prelink, pseudo, swabber

● Tarefa (task): etapas executadas pelo build engine

● Receita (recipe): conjunto de tarefas necessárias para compilar determinado software (.bb, .bbappend)

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

● Configuração (conf): arquivos com definições globais (.conf)

● Pacote (package): resultado do processamento da receita de um componente de software

● Camada (layer): conjunto de receitas, classes, arquivos de configuração que podem ser agregados ao sistema de build para estendê-lo ou modificar comportamentos

● Composição de layers

● Layers são blocos de construção

● Layer é o modo de extender o build system

– Adicionar, remover, modificar

● Classes, receitas, configurações – São adicionadas no sistema

● Agrupe as layers por funcionalidade, exemplo:

– Toolchains – BSP/Machine – Áreas funcionais (database, networking, languages) – Especificidades do projeto

● Pilhas de software de terceiros

● Componente usados em outros projetos

● Configurações

● Máquina (machine): plataforma de hardware alvo da distribuição. Implementado através de uma layer BSP

● Imagem (image): imagem final do rootfs do sistema gerado

● Distribuição (distro): regras e políticas de geração da imagem do sistema

● Bitbake: linha de comando

$ bitbake

$ bitbake -c

$ bitbake -k

$ bitbake -s

● HOB

● Toaster

● Distribuição Pronta, vantagens

Framework de Simplicidade de uso desenvolvimento Pronto e funcional

Facilidade na Base de usuários instalação (pacotes)

Suporte comercial

● Distribuição Pronta, desvantagens

Tempo de boot Falta de pode ser alto flexibilidade

Requisitos de licença Pode não estar otimizada

Experiência Requer tempo Para adaptação e customização

● Versão dos componentes de sw

● Subsistemas

– Systemv, systemd

● Features adicionais: alsa, wayland, x11, usb, pci

● Toolchain

– Interna ou externa

● Versão de Linux Kernel

● Não há restrição de licenças

● Há preocupação do YP em gerar distros legais

– Opções para não permitir determinada licença – Manifesto de licenças – Exportação de código fonte, scripts, patches

● https://www.yoctoproject.org/blogs/davest/2012/binaries-considered-dang erous

● Plataformas:

– 2 EVKs (ppc e x86-64) – plataforma alvo do produto – máquina virtual para integração

● Solução YP:

– Distro e Linux Kernel comum – A mesma SDK – MACHINE=

● BSP antigo (2002)

– Fabricante não oferecia suporte ($$$)

● Necessidade de evolução kernel e userland

● Plataforma não otimizada

● Solução YP:

– Redução do footprint – Toolchain otimizado – Bugfixes gerais e críticos solucionados – Controle de todos os componentes do produto

● Geração de SDKs

– Podem ser instaladas em qualquer workstation linux

● Mesma versão de GCC

● Target para diferentes plataformas

● Imagem: ext2, ext3, cpio, directdisk, jffs2, ubi, cramfw, brtfs, live

● Linux kernel image (bz2, uImage)

● Pacotes (rpm, ipk, deb, tar)

● Manifesto das licenças de softwares usadas

● Histórico de build (buildhistory)

● Código fonte de todos os softwares usados

● Scripts de build e patches aplicados

● Arquiteturas: ARM, PPC, MIPS, x86 e x86-64

● Machines: qemuarm, qemumips64, qemumips, qemuppc, qemux86, qemux86-64

● Vendor BSPs:

– TI, FSF, Intel, AMD, LSI

● Qualquer sw pode ser buildado e adicionado na imagem final

● Alguns sw são mais complicados de empacotar

– Requerem buildtools exóticos ou scripts que não seguem padrões

● Como regra geral: qualquer artefato que o bitbake consiga empacotar, pode ser usado

● Qualquer Linux Kernel pode ser usado

● Defina uma imagem base para a distro

● Use a SDK gerada pelo YP

– Máquinas de desenvolvimento – Servidores de build

● Mesmo não tendo definido a arquitetura alvo escolha uma MACHINE virtual mais próxima do seu alvo

– Assim você já pode iniciar as primeiras validações antes do hw final chegar

$ git git://git.yoctoproject.org/poky -b dizzy

$ source oe-init-build-env

$ bitbake core-image-minimal

$ runqemu qemux86

● Requisitos muito bem definidos

– Aderência a padrões: LSB, CGL – Footprint

● sdcard, HD, flash, netboot, nfs – Qual versão de Linux Kernel atende ?

● LTSI, mainline, old kernel, vendor kernel – Vendor de hw possui BSP ?

● Comece gerando imagens usando as distros de referência:

– poky, poky-lsb, poky-tiny

● Depois defina uma imagem base

– core-image-minimal

● Crie uma ou várias layer(s) para as suas modificações

– sempre modifique a layer

● Analise os resultados

– buildhistory – bitbake -g -u depexp

● Adicione aos poucos novos pacotes e layers

● As atualizações podem ser feitas usando

– Gerenciador de pacotes – Imagem

● YP não oferece uma solução para atualização da distro. Ele suporta os mecanismos para que isso seja implementado

● A intenção é que todos os softwares sejam construídos e empacotados pelo YP

● Cada aplicação ou o conjunto de aplicações precisam ter uma receita

– Descrição de onde baixar – Compilar – Instalar

● Cada receita ganha uma versão: my-app_0.1.2.bb

SUMMARY = „Test app“ ● A receita precisa ficar dentro de SECTION = „tests“ uma layer

LICENSE = „CLOSED“ ● Uma layer pode alterar uma LIC_FILES_CHKSUM = „“ receita de outra layer:

SRC_URI = „git.my.com“ bitbake-layers

S = „${WORKDIR}“

do_compile() {

${CC} test.c o test

}

do_install() {

install -d ${D}${bindir}

install -m 0755 test ${D}/${bindir}

}

● Defina uma versão estável do YP para usar

● Sincronize o upstream com um repositório interno

● Monitore atualizações na branch estável

● Crie repositórios internos para as várias layers que serão criadas

– Escolha uma política de versionamento – Faça builds contínuas para garantir a integridade durante o desenvolvimento

● Patches de componentes

– Podem ser mantidos, num diretório, junto com os meta-dados

● Versões do YP são feitas a cada 6 meses

– As últimas duas releases são mantidas

● Cada versão deve ser encarada como uma linha de desenvolvimento diferente

● Se sair uma nova versão de um branch estável, então atualize

– Correções de segurança e bug críticos

● São feitos backports das correções

● Se for uma nova release do YP e o seu produto ainda não saiu para campo, então migre de versão

– Supondo que todo o seu trabalho esteja nas layers a migração não terá dores de cabeça

● Se houver quebras, os motivos são

– YP ficou mais criterioso, não tolerando erros triviais nas receitas – Pacotes que não existem mais no OE-Core

● .bbappends feitos usando a versão da receita

● Receitas removidas

● Tenha builds contínuas no master branch

– Assim você pode consertar o seu projeto ao longo do ciclo de desenvolvimento

● Você ganha:

– Melhorias no desempenho da build – Atualizações da base de pacotes e toolchain – Novas features – Melhorias e correções feitos ao longo de 6 meses

● Pense um pouco:

– O seu produto suporta atualização em campo? – Como você cuida da atualização de software? – Quais são os seus componentes críticos?

● Tenha em mente que cada release do YP é testada e validada com um conjunto de versões

● Você pode manter a versão de alguns componentes enquanto atualiza a base do sistema.

● Vai depender da sua análise entre os componentes

● Exemplo prático:

– Yocto 1.7 com gcc 4.8 e libc 2.20

● Projeto Open Source com excelente documentação:

– Bitbake User Manual – Application Development Guide – Board Support Package Development Guide – Development Manual – Linux Kernel Development Manual – Profilling and Tracing Manual – Quick Start – Reference Manual

● Lista de discussão

– https://www.yoctoproject.org/tools-resources/community/mailing-lists

● IRC #yocto #poky

– https://www.yoctoproject.org/tools-resources/community/irc

● Apresentações

– https://www.yoctoproject.org/tools-resources/presentations

● Vídeos

– https://www.yoctoproject.org/tools-resources/videos

● Leia a documentação

● Pergunte na Lista de discussão

● Entre no IRC

● Leia o código fonte

● Leia os commits (git log)

● Não existe um treinamento oficial

● Linux Foundation

– LF405 Building Embedded Linux with the Yocto Project – LF404 Building Embedded Linux with the Yocto Project: Crash Course

● Free Electrons

– Yocto Project and OpenEmbedded development training

● Embedded Labworks

– Yocto Project

● Embedded Linux Development with Yocto Project, by Otavio Salvador e Daiane Angolini

– Escrito por Brasileiros.

● The Architecture Of Open Source Applications, Volume II

– Capítulo 22: Yocto, by Elizabeth Flanagan

● Open Software Stack for the Intel® AtomTM Processor, by Sean D. Liming e John R. Malin

padtec.com