Como Sobreviver Embedded Linux – Parte 1 O Linux Embarcado Processo de Desenvolvimento
O Linux Embarcado Processo de Desenvolvimento
O kernel do Linux pode ser executado em diferentes arquiteturas de computador, a maioria dos quais são bastante populares no mundo incorporado. Todos os pacotes básicos que permitem ao sistema operacional executar as tarefas básicas são adequados para compilação cruzada, portanto, o Linux pode ser tão difundido quanto microcontroladores e sistemas no Chip (SoCs).
uma distribuição Linux é um sistema operacional feito a partir de uma coleção de software, que é baseado no Kernel do Linux e – muitas vezes – um sistema de gerenciamento de pacotes. A distribuição pode vir como binários e pacotes pré-compilados juntos
pelos mantenedores de distribuição, ou como fontes emparelhadas com instruções sobre como (cross-) compilá-los.
no domínio incorporado, uma vez que a plataforma de hardware é geralmente sob medida, o designer de SO geralmente prefere gerar a distribuição do zero, a partir de fontes. Isso dá ao designer controle absoluto do que acaba no produto
. Além disso, o engenheiro do pacote de Suporte Da Placa (Bsp) modifica o código de baixo nível para fazer com que a funcionalidade principal do sistema operacional funcione no produto de hardware específico.
reunir todos os componentes de software necessários para gerar a distribuição Linux para um determinado produto incorporado costumava ser um pesadelo, mas, felizmente, esse não é mais o caso.
muitos compartilharam com a comunidade de código aberto as fontes de sistemas de construção capazes de buscar todos os componentes de Software fora da Internet, compilá-los e vinculá-los, até a geração de imagens de instalação de sistemas operacionais de pleno direito. Algumas empresas estão desenvolvendo e mantendo seu próprio sistema de compilação, outras compilam apenas alguns dos componentes principais e, em seguida, usam binários pré-construídos para finalizar o sistema operacional.
em 2010, um grupo de trabalho da Linux Foundation começou a abordar ferramentas e processos para permitir a criação de distribuições Linux para software incorporado (também conhecido como Linux incorporado). Esse grupo de trabalho, conhecido como projeto Yocto, alinhou-se com o Open Embedded, uma estrutura com objetivos semelhantes.
o projeto Yocto é um projeto de código aberto cujo foco é melhorar o processo de desenvolvimento de software para distribuições Linux embarcadas. O projeto Yocto fornece ferramentas interoperáveis, metadados e processos que permitem o desenvolvimento rápido e repetível de sistemas embarcados baseados em Linux.
o projeto Yocto está atualmente alimentando as distribuições Linux mais populares para o sistema embarcado, a um ponto em que às vezes os Termos “Embedded Linux” e “Yocto Project” são facilmente confundidos como sinônimos. Yocto não é uma distribuição Linux incorporada, cria uma personalizada para você.
Yocto meta-camadas de layout
A versão moderna do Yocto da arquitetura é baseada em meta-camadas, que são os diretórios que contém arquivos de configuração e regras sobre como compilar e montar distribuições Linux para sistemas embarcados.
Normalmente, mas não sempre, uma meta-camada de mora no seu próprio repositório git, e fornece:
- seus próprios pacotes (definido por receitas .bb arquivos),
- modificações em pacotes fornecidos por outras meta-camadas (.arquivos bbappend),
- máquinas (.arquivos conf),
- arquivos de configuração (.arquivos conf),
- código comum (.arquivos bbclass),
- licenças,
- e outros bits e peças menores.
uma única meta-camada normalmente aborda uma finalidade específica. Portanto, para alcançar um sistema totalmente funcional, mais meta-camadas precisam ser combinadas.
versões escolhendo e combinando
ao montar diferentes componentes de software, é preciso estar atento à versão de cada componente, pois a versão errada pode não funcionar bem junto com os outros componentes ou até mesmo quebrar o sistema.
o projeto Yocto fornece versões de componentes conhecidos por funcionarem bem juntos, mas esse é apenas o ponto de partida para o seu produto.
o kernel do Linux é um grande pedaço de código que precisa expor as interfaces certas ao espaço do Usuário e deve conter os drivers certos para que o sistema funcione corretamente. Portanto, o papel do Fornecedor de silício tornou-se cada vez mais importante nos dias de hoje, pois eles geralmente têm seus próprios repositórios de desenvolvimento para o kernel Linux e o bootloader, portanto, eles são as melhores pessoas para montar um sistema base de trabalho baseado em sua tecnologia.
repo do Google
originalmente desenvolvido para lidar com a multiplicidade de repositórios Git em um projeto Android, repo tornou-se bastante popular entre os desenvolvedores Yocto também.
Repo é uma ferramenta construída em cima do Git; ele usa um” arquivo de manifesto ” para clonar e puxar um conjunto de repositórios Git ao mesmo tempo.
um manifesto repo é um .documento xml contendo referências a repositórios git (junto com suas versões), repo pode usar o manifesto para preencher um diretório com todas as fontes provenientes dos vários repositórios Git necessários para construir um projeto.
além disso, o mesmo Manifesto pode ser usado pelo repo para manter a verificação (sincronização) das fontes do projeto quando o upstream faz alterações.
alguns fornecedores de silício fornecem manifestos para seus ramos de desenvolvimento e lançamento nos dias de hoje, para que os designers possam verificar facilmente o ponto de partida para seus próprios produtos.
desenvolvimento de produto baseado em Yocto
o engenheiro BSP geralmente parte do manifesto de repositório do Fornecedor de silício para verificar a versão do software para o projeto de referência (ou seja, um projeto fornecido pelo próprio fornecedor de silício ou por um de seus parceiros, contendo o mesmo ou similar SoC ao baseado no novo produto). O engenheiro faz alterações no bootloader e no kernel do Linux para garantir que o hardware selecionado pelo engenheiro eletrônico tenha suporte adequado a software de baixo nível (por exemplo, drivers de dispositivo, árvore de dispositivos, configuração do kernel, etc.).
o objetivo do produto é executar um ou mais aplicativos, portanto, o engenheiro BSP/OS garante que todas as dependências do(s) Aplicativo (s) estejam sendo construídas para o sistema. Os engenheiros que desenvolvem o aplicativo precisam de um kit de desenvolvimento de Software (SDK) para compilar e vincular o aplicativo, portanto, o engenheiro BSP/OS
fornecerá a eles esse kit e, graças ao Yocto, isso se tornou bastante simples.
Boas Práticas do Linux incorporado
os manifestos de repo usados para desenvolvimento geralmente contêm referência a ramificações de desenvolvimento, o que significa que o repo buscará o commit mais recente para essas ramificações.
se você usar o mesmo manifesto para buscar o projeto em uma data posterior, você pode buscar uma versão diferente do Código! Isso é perfeitamente adequado para o desenvolvimento porque você deseja manter a versão mais recente do seu projeto, mas uma de suas versões de desenvolvimento acabará se tornando uma versão e, portanto, você precisa “tirar uma foto” dessa versão precisa das fontes usadas para gerar a versão de software que vai no projeto. Não fazer isso pode expô-lo a problemas legais, pois você não poderá regenerar a mesma compilação a partir de fontes, portanto, você não poderá fazer uma alteração em cima de uma versão específica, forçando o cliente a testar novamente todo o sistema, pois será forçado a corrigir o bug ou adicionar o novo recurso em cima da versão mais recente do software.
além disso, se você não tirar esses instantâneos, não há como executar um bisect nas fontes do projeto para descobrir qual commit quebrou a funcionalidade de que você precisa desesperadamente. Ao projetar seu processo de desenvolvimento, encontre uma maneira de gerar automaticamente repo manifests com commits precisos neles, para que você possa salvá-los ao lado de releases para verificar as mesmas fontes novamente em uma data posterior e fazer o que for pago para fazer.
Copiar fontes em casa
também Manter em mente que 99,9% das fontes no interior do seu produto vem da comunidade de código aberto, o que significa que você não tem nenhuma garantia de que o mesmo fontes estarão disponíveis para download novamente. Como designer, você precisa se proteger contra mudanças e erros cometidos upstream. Mantenha uma cópia de todas as fontes relevantes em casa e encontre uma maneira de conectá-las de volta ao seu sistema de compilação. Além disso, você pode querer espelhar alguns dos repositórios que você mais usa, pois às vezes os servidores git upstream podem de repente ficar indisponíveis. Se você não tiver uma cópia interna, ficará preso até que os servidores voltem online.
na ByteSnap, temos uma maneira totalmente automatizada de lançar projetos baseados em Yocto, de modo que possamos recuperar as fontes que entram em uma versão e também recriar a mesma versão em uma data posterior. Mantemos cópias de pacotes de código aberto de forma automática, para que não tenhamos tempo de inatividade causado por servidores defeituosos em todo o mundo. Além disso, apoiamos tudo todos os dias para que possamos garantir que nenhum trabalho será perdido, mesmo em caso de desastre no local.
Fabrizio Castro
Fab é engenheiro sênior de software. Ele obteve seu bacharelado e mestrado no Politecnico di Milano, em Milão, Itália. Ele tem 20 anos de experiência em desenvolvimento de software completo (serviços, bases de dados, aplicativos, software científico, firmware, RTOS, drivers de dispositivos, kernel Linux, etc.), passou a trabalhar na academia e na indústria. Fab é co-autor de artigos científicos e livros, e trabalhou em patentes. Além de pesquisa e desenvolvimento, ele é especializado em desenvolvimento Linux incorporado – fornecendo designs de última geração que alimentam produtos científicos, industriais, comerciais e militares de sucesso. Fab também foi professor e ensinou alunos de graduação em algumas das universidades mais prestigiadas da Europa. Para mais informações sobre Bytesnap Design visite http://www.bytesnap.co.uk.