Introdução aos sistemas Machine to Machine – M2M  através da construção de sistemas embarcados personalizados. 

Este post é o primeiro de uma série que mostra o uso do Yocto em diferentes dispositivos e sua integração para o desenvolvimento embarcado.

De acordo com [1], o projeto Yocto é um projeto colaborativo que prove ferramentas para a criação de um sistema Linux personalizado para sistemas embarcados, independente da arquitetura de hardware, possibilitando uso de processadores de variadas plataformas, como ARM, MIPS, PowerPC and x86 e x86-64. Os componentes do projeto Yocto podem ser usados para projetar, desenvolver, construir, debugar, simular e testar completamente uma pilha de software embarcado composta pelo Kernel do Linux, o sistema Linux, X Window System, GNOME Mobile-based application frameworks, e o  Qt frameworks.

O video demonstrativo apresenta a intenção do projeto

A iniciativa por tras do projeto começou em 2010, a partir da colaboração dos principais fabricantes de processadores e componentes eletronicos, trazendo uma ordem ao desenvolvimento de Linux embarcado. O termo yocto designa a menor unidade do SI. Como prefixo, yocto indica 10 elevado a -24.

Yocto é composto de diversas partes do processo de desenvolvimento. Essas partes são  nomeadas projetos dentro do Yocto e incluem ferramentas de criação, metadados de instruções de criação chamados receitas, bibliotecas, utilitários e interfaces gráficas com o usuário.

• Prove um Kernel Linux recente, com um conjunto de comandos de sistemas e bibliotecas adaptados para o uso em ambientes embarcados.
• Disponibiliza componentes de sistema como  X11, GTK+, Qt, Clutter, e SDL de maneira a permitir a construção de uma interface gráfica configuravel para os hardware de display.
• Cria um nucleo compativel com o projeto OpenEmbedded que pode ser extensivel e distribuido.
• Suporte um conjunto de emulação de hardware através do QEMU.

Componentes do projeto Yocto

BitBake

BitBake é um programa escrito na linguagem Python. Em um nível mais alto, o BitBake interpreta o meta-dado, decide quais tarefas são requeridas para executar. BitBake é um mecanismo de execução de tarefas que permite o shell e as tarefas em Python executar eficientemente e em paralelo, enquanto trabalha resolvendo dependências entre as diferentes tarefas que gerencia. Ele lê as receitas e as segue, buscando pacotes, construindo-os e incorporando os resultados em imagens inicializáveis. Similar ao GNU Make, Bitbake controla como o software é construido. Enquanto GNU Make utiliza “makefiles”, BitBake usa “recipes”. Além disso, apesar de ser equivalente ao GNU Make, possui as seguintes diferenças:

• BitBake executa tarefas de acordo com os metadados fornecidos para construir as tarefas. Os metadados são armazenados nos recipe  (arquivos de extensão .bb), configuration (.conf), e class (.bbclass) e prove ao BitBake com instruções sobre quais tarefas executar e quais as dependencias entre as tarefas
• BitBake inclui uma biblioteca para obter codigo fonte de diversas fontes, como websites ou sistemas de controle de versão (GIT, SVN).
• BitBake inclui uma abstração cliente/servidor que pode ser usada a partir da linha de comando ou como serviço sobre o XMLRPC.

Recipes

Os BitBake Recipes, que são arquivos com a extensão .bb, são o tipo mais básico de meta-dados. Os arquivos recipe são compostos por

• Uma informação descritiva do pacote
• A versão do recipe
• Dependencias possiveis
• Onde o codigo fonte se encontra
• Se o codigo precisa de algum patch
• Como compilar o codigo fonte
• Onde instalar o pacote na maquina alvo

Configuration Files

Arquivos de configuração, os quais possuem a extensão .conf, definem as variaveis de configuração que gerenciam o processo de construção. Esses arquivos definem varias áreas da configuração das máquinas, como as opções de compilação, configurações de usuário, da distribuição. O arquivo de configuração principal é o bitbake.conf, localizado na raiz do projeto.

Classes

Arquivos Class, que são os arquivos com extensão .bbclass, contêm as informações que são compartilhadas entre os metadados. A arvore do BitBake source tree possui um arquivo basico chamado base.bbclass. Este arquivo base.bbclass é especial pois é sempre incluido por todas as outras classes e receitas. Esta classe contem definições para as tarefas basicas como fetching, unpacking, configuring (empty by default), compiling (runs any Makefile present), installing (empty by default) e packaging (empty by default). Essas tarefas podem ser sobrescritas ou extendidas por todas as outras classes no projeto.

Layers

As Layers permitem o isolamento do diferentes tipos de personalização e customização uns dos outros. A modularidade das camadas permite gerencias as evoluções dos projetos, organizando os metadados em grupos diferenciados. Para ilustrar, considere as personalizações que podem ser feitas para uma maquina alvo em especifico. Esses tipos de personalizações  podem ficar em uma cada especifica, ao inves da Layer generica, chamada Board Specific Package (BSP) Layer. Dessa maneira, pode se ter configuraçõe para um ambiente com interface gráfica e outro com configurações independentes da mesma. Este tipo de separação é importante, pois uma layer BSP pode ter adições especificas com recipes para um ambiente GUI, sem necessariamente ter inclusões na GUI layer.

Append

Os arquivos Append, que possuem a extensão .bbappend, adicionam ou extendem as informações basicas ja existentes em um recipe.

BitBake assume que cada arquivo append tenha um recipe associado. (e.g.formfactor_0.0.bb e formfactor_0.0.bbappend).

A informação descrita no append sobrescreve a mesma no recipe correspondente. Pode se usar o caracter (%) para generalizar o versionamento de arquivos .bb. Por exemplo,

busybox_1.21.%.bbappend
busybox_1.21.1.bb
busybox_1.21.2.bb
busybox_1.21.3.bb

Conjunto de metadados

O conjunto de metadados é disposto em camadas, para que cada camada possa fornecer uma funcionalidade separada para as camadas abaixo dela. A camada de base é OpenEmbedded-Core ou oe-core, que fornece receitas, classes e funções associadas que são comuns e necessárias para todas as construções. Em seguida, é possível customizar as construções incluindo novas camadas sobre a oe-core.

A OpenEmbedded-Core é mantida conjuntamente pelos projetos Yocto e OpenEmbedded. Uma camada que separa o projeto Yocto do OpenEmbedded é a camada meta-yocto , que fornece a configuração da distribuição Poky e um conjunto principal de BSPs de referência.

O projeto OpenEmbedded propriamente dito é um projeto de software livre separado com receitas intercambiáveis (de modo geral) que tem objetivos semelhantes aos do projeto Yocto, mas um controle e um escopo diferentes.

Poky

O sistema de criação Poky é um exemplo funcional do Linux que será usado no sistema embarcado. Ao fazer o download, é obtida uma instância dessas ferramentas, utilitários, bibliotecas, cadeia de ferramentas e metadados que podem ser usados para criar o sistema padrão, como se descreve aqui. O sistema de referência e a distribuição de referência que ele cria se chamam Poky.  Ele se torna o ponto de partida para criação da própria distribuição adaptada.

A toolchain — um compilador, assembler, vinculador e outros utilitários binários necessários para criar arquivos executáveis binários para uma determinada arquitetura — é um item necessário para todos os sistemas de criação. O Poky usa a compilação cruzada (cross compiling): o uso de uma cadeia de ferramentas em uma arquitetura para desenvolver arquivos executáveis binários para outra arquitetura (por exemplo, desenvolver uma distribuição ARM em um sistema host baseado em x86). Dessa maneira se aproveita o melhor desempenho do sistema host.

Pacotes de suporte de placa

O BSP contém todos os pacotes e drivers essenciais à criação do Linux para uma placa ou arquitetura especifica. Geralmente são mantidos pelos fabricantes de hardware que produzem as placas. Os BSPs são a interface entre o sistema operacional Linux e o hardware que o executa.

Hob

Frontend gráfico para o BitBake e o processo de criação.

Conformidade da licença de software livre

A conformidade com as licenças de software livre é uma parte extremamente importante de qualquer esforço de desenvolvimento em Linux. Uma das metas do projeto Yocto é facilitar a conformidade tanto quanto possível. É muito fácil usar as ferramentas do projeto Yocto para criar manifestos e até para desenvolver repositórios de origem inteiros, bem como filtrar o processo de criação para excluir pacotes que usam licenças especificas. O projeto está trabalhando, junto com a Linux Foundation, em seu programa Open Compliance em relação à especificação Software Package Data Exchange® (SPDX™).

EGLIBC

A Embedded GLIBC (EGLIBC) é uma variante da GNU C Library (GLIBC), projetada para funcionar em sistemas embarcados.

Kit de ferramentas de desenvolvimento de aplicativos

O kit de ferramentas de desenvolvimento de aplicativos (ADT) permite que os desenvolvedores de sistemas forneçam kits de desenvolvimento de software (SDKs) para as distribuições que eles criam usando as ferramentas do projeto Yocto, oferecendo a eles uma forma de desenvolver com base nas pilhas de software fornecidas pelos desenvolvedores desses sistemas. O ADT inclui uma cadeia de ferramentas de compilação cruzada, ferramentas de depuração e criação de perfil, emulação de QEMU e scripts de suporte. O ADT também inclui um plug-in do Eclipse (IDEs).

Outras ferramentas do projeto Yocto [2]:

• Autobuilder:  permite as atividades automatizadas de garantia de qualidade (QA).
• Cross-Prelink: fornece pré-vinculação para ambientes de desenvolvimento de compilação cruzada, melhorando o desempenho.
• Pseudo: emula o acesso do root, uma parte essencial da criação de uma imagem final inicializável.
• Swabber: detecta quando uma criação de compilação cruzada foi contaminada por componentes do host.
• Build Appliance: é uma máquina virtual que executa o Hob, permitindo as pessoas que usam hosts de criação que não são de Linux vejam o processo do projeto

Sequencia de criação das imagens

1. Configurar o ambiente hospedeiro para desenvolvimento do Yocto
2. Criar uma copia local dos arquivos no sistema hospdeiro.
3. Estabelecer um repositorio de metadados no sistema
4. Criar uma BSP layer usando o script yocto-bsp 
5. Efetuar mudanças de configurações para a nova BSP layer
6. Modificar as recipes para a nova BSP layer
7. Preparar o build
8. Construir imagem

Nos próximos posts iremos ver como configurar a máquina hospedeira para a criação do ambiente de desenvolvimento.

Bibliografia

[1] https://www.yoctoproject.org

[2] http://www.ibm.com/developerworks/br/library/l-yocto-linux/

[3] http://www.embarcados.com.br/beaglebone-black-qt-embedded-yocto-parte-1/

[4] http://www.embarcados.com.br/beaglebone-black-yocto/

[5] http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html