Centro Multimídia "Kodi" e Projeto Yocto


Introdução ao Projeto Yocto


O Yocto Project é um projeto colaborativo de código aberto para simplificar o desenvolvimento de distribuições para sistemas embarcados. O Yocto contém um grande número de modelos, metadados e ferramentas de construção. No Yocto Project, você pode conectar um grande número de camadas BSP (pacote de suporte de plataforma) para todos os tipos de plataformas de hardware.

O principal objetivo do artigo é uma tentativa de mostrar a montagem de um pacote de distribuição típico no Projeto Yocto usando o exemplo do conhecido centro multimídia Kodi, versão 17.6, para o computador de placa única Raspberry Pi 3B.

Se em algum lugar no fundo da sua alma você sente que é colecionador, mas ainda não decidiu o que gostaria de colecionar, então este artigo é para você. Se você já usa o Projeto Yocto em seu trabalho diário, pode rolar este artigo. Vá direto para o último capítulo e prepare-se.

O artigo é puramente prático e demonstra a possibilidade de usar as realizações do Projeto Yocto e do OpenEmbedded para construir o centro multimídia "Kodi". As camadas Yocto são gerenciadas usando o utilitário Repo do Google. Um artigo no documento desta série.

Então: vamos lá.

Conteúdo:


Instale o Projeto Yocto no Ubuntu
Mecanismo de construção de distribuição no Projeto Yocto
Usando o OpenEmbedded com o projeto Yocto
Pacote de suporte de plataforma (BSP)
Gerenciar camadas Yocto com Repo
Instalar repositório
Manifesto de Construção de Distribuição
Conteúdo do manifesto
Descrição do manifesto
Estrutura do manifesto Bs
Inicializando Variáveis ​​Poky
Inicialização de repositório
Repo Sync
Criando uma configuração de projeto Yocto
Arquivo de configuração build / conf / local.conf
Arquivo de configuração build / conf / bblayers.conf
Camada para montagem de um centro multimídia
Estrutura de camada
Configuração de camada
Composição de receitas-berserk
Composição de receitas-core
Composição de receitas-kernel
Receitas de composição -mediacentre
Composição de receitas-multimídia
Suplemento de receita de compilação Kodi
Adicionando um novo item ao menu de configurações do Kodi
Configurações máximas de buffer para vídeo
Assistindo TV por IPTV
Assistindo ao Youtube com o plug-in Kodi
Extensão de configuração de rede do shell do console
Receita de Construção de Distribuição
Um breve guia para criar uma imagem de distribuição
Postscript

Instale o Projeto Yocto no Ubuntu


Para construir a distribuição usando o Projeto Yocto no Ubuntu, você precisa instalar os seguintes pacotes:

sudo apt-get install -y --no-install-suggests --no-install-recommends \ gawk wget git-core diffstat unzip texinfo gcc-multilib \ build-essential chrpath socat cpio python python3 python3-pip python3-pexpect \ xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev \ xterm 

Os pacotes são instalados usando o comando apt-get install e o comando sudo, da escalação de privilégios. No sistema Ubuntu, essa é uma prática generalizada quando o comando sudo é usado para executar ações administrativas (ao criar o usuário principal do sistema, ele é automaticamente registrado no grupo “sudo”).

Você pode ver instruções de instalação mais detalhadas aqui:

Mecanismo de construção de distribuição no Projeto Yocto


No Projeto Yocto, cada unidade de programa é descrita usando uma receita de montagem. A linguagem de descrição da receita se assemelha a "bash", com a capacidade de inserir partes de código na linguagem python. Você pode obter informações básicas de sintaxe no manual do Yocto Project . Um conjunto de receitas de montagem, dependendo da finalidade, pode ser combinado em camadas de montagem separadas.

As camadas são divididas em dependentes de hardware - camadas BSP, camadas da interface do usuário (interface do usuário), camadas Yocto específicas e camadas que implementam determinadas funcionalidades:
por exemplo, camadas do OpenEmbedded => multimídia, python, perl, ruby, rede, systemd, servidor da web etc.

Usando o OpenEmbedded com o projeto Yocto


E, no entanto, se você usar o Projeto Yocto, com certeza precisará de camadas com funcionalidade adicional, ou seja, Um grande conjunto de receitas para todas as ocasiões. E existe esse conjunto - estas são receitas do OpenEmbedded. O OpenEmbedded é uma infraestrutura para a construção de pacotes para Linux embarcado.

O OpenEmbedded é totalmente compatível com o Projeto Yocto, pois esse projeto foi tomado como base para o Projeto Yocto. Talvez seja por isso que o Yocto Project tenha estabilidade um pouco melhor, melhor documentação e suporte um pouco melhor (mas basicamente ainda é o mesmo OpenEmbedded).

Pacote de suporte de plataforma (BSP)


O Pacote de suporte da placa é uma camada especializada separada para uma placa específica que define os recursos de hardware da plataforma, ou seja, implementa itens específicos que distinguem uma placa da outra: recursos do processador, interrupções, endereçamento, recursos do carregador de inicialização, recursos do adaptador de vídeo (GPU) etc.

Este artigo usa a camada BSP - meta-raspberrypi
O repositório de camadas está localizado em: git.yoctoproject.org/git/meta-raspberrypi

Gerenciar camadas Yocto com Repo


O Yocto Project pode usar um grande número de camadas de diferentes fornecedores - desenvolvedores de equipamentos, e tudo isso precisa ser gerenciado de alguma forma. Imagine que você tem uma dúzia de placas diferentes e cada placa vem com um repositório BSP git separado, e isso não conta a infraestrutura do projeto Yocto, além de uma possível funcionalidade adicional do OpenEmbedded.

Em tal situação, você não precisará usar um script de instalação simples separado. À vontade, precisa procurar ferramentas que possam fazer isso bem. Ainda mais que bom. Uma das melhores ferramentas desse tipo é o utilitário Google - Repo.

O Repo é a principal ferramenta para gerenciar repositórios GIT ao criar o sistema operacional Android com sua grande base de códigos. O Repo permite gerenciar uma dúzia, se não uma centena de repositórios git separados em um projeto, cujas versões você pode especificar com cuidado em um arquivo xml do Manifesto

e para a sincronização correta de todas as versões de todos os repositórios, basta executar um comando

sincronização de repositório

Instalar repositório


Usando o seguinte conjunto de comandos, você pode instalar o Repo no diretório inicial ~ / bin
(o comando curl pode ser instalado separadamente: sudo apt-get install curl)

 PATH=${PATH}:~/bin mkdir ~/bin curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo chmod a+x ~/bin/repo 


e no futuro você só precisa usar o comando no console: repo

mais ou menos
se o diretório HOME / bin não for adicionado automaticamente ao caminho de inicialização padrão
veja o arquivo HOME / .profile

$
$ PATH = $ {PATH}: ~ / bin
$ repo
$

Manifesto de Construção de Distribuição


A distribuição coletada na estrutura do artigo, preciso chamar de algo. Que seja o nome Torvin . Com o nome de código Torvin, ele conterá uma distribuição Linux minimalista com a montagem de um único programa. Isso se refere a um programa de usuário de aplicativo - Kodi e nada mais (tudo o resto é no nível do sistema). Para um centro multimídia, na minha opinião, isso é suficiente.

Conteúdo do manifesto


O arquivo torvin-0.2.5.xml é usado para gerenciar as camadas de distribuição .

  <?xml version="1.0" encoding="UTF-8"?> <manifest> <default sync-j="4" revision="rocko"/> <remote fetch="https://git.yoctoproject.org/git" name="yocto"/> <remote fetch="https://github.com/openembedded" name="oe"/> <remote fetch="https://github.com/berserktv" name="bs"/> <project remote="bs" revision="master" name="bs-manifest" path="sources/bs-manifest"> <linkfile dest="setup-environment" src="setup-environment"/> <linkfile dest="shell.sh" src="raspberry/shell.sh"/> <linkfile dest="sources/base" src="raspberry/rocko"/> </project> <project remote="yocto" revision="rocko" name="poky" path="sources/poky"/> <project remote="oe" revision="rocko" name="meta-openembedded" \ path="sources/meta-openembedded"/> <project remote="yocto" revision="rocko" name="meta-raspberrypi" \ path="sources/meta-raspberrypi"/> <project remote="bs" revision="rocko" name="berserk" path="sources/berserk"/> </manifest> 

Descrição do manifesto


No início do manifesto, as tags remotas denotam dois repositórios GIT principais e um auxiliar:

https: ⁄⁄git.yoctoproject.org / git - repositório Yocto nomeado como yocto
https: ⁄⁄github.com / openembedded - repositório OpenEmbedded nomeado como oe
https: ⁄⁄github.com / berserktv - repositório GIT auxiliar nomeado como bs

Na próxima parte do manifesto, usando nomes abreviados, trabalhamos com projetos localizados nesses repositórios, a tag do projeto contém os seguintes atributos:

remote - o nome do repositório nomeado remoto
revisão - o nome da ramificação ou versão do hash
nome - nome do projeto no repositório especificado
path - o caminho do projeto local em seu sistema de arquivos

    <project remote="bs" revision="master" name="bs-manifest" path="sources/bs-manifest"> </project>  xml      : git clone https://github.com/berserktv/bs-manifest -b master sources/bs-manifest 

No corpo da tag do projeto , indiquei comandos para criar links simbólicos para a infraestrutura de scripts auxiliares de inicialização inicial e início regular do sistema de construção Poky de que preciso

    linkfile <project remote="bs" revision="master" name="bs-manifest" path="sources/bs-manifest"> <linkfile dest="setup-environment" src="setup-environment"> <linkfile dest="shell.sh" src="raspberry/shell.sh"> <linkfile dest="sources/base" src="raspberry/rocko"> </project>        : ln -s src dest .. #      ln -s sources/bs-manifest/setup-environment setup-environment ln -s sources/bs-manifest/raspberry/shell.sh shell.sh #    ,  #      cd sources ln -s bs-manifest/raspberry/rocko base 

Estrutura do manifesto Bs


 COP── COPYING.MIT
 ├── framboesa
 │ ├── rocko
 │ │ ├── conf
 B │ │ ─── bblayers.conf
 Local │ │── local.conf
 Tor │ └── torvin-0.2.5.xml
 Shell └── shell.sh
 ├── README.md
 Setup── ambiente de instalação


O projeto bs-manifest é usado para gerenciamento flexível de configuração, levando em consideração os assemblies de diferentes versões da distribuição. Eu tenho esta versão - 0.2.5

Inicializando Variáveis ​​Poky


O ambiente de configuração do script de inicialização foi retirado do projeto Freescale Community (no ambiente yocto, essa é uma solução comum). O script é responsável pela inicialização das variáveis ​​do sistema de construção Poky, o script cria uma estrutura de diretórios na qual está muito bem dividido:

  • build - diretório de build
  • source - código fonte de receitas de montagem
  • download - diretório para baixar o código do programa (bancos de dados git, arquivos tar.gz)

O conteúdo do script setup-environment pode ser visto aqui:

Conteúdo do script Shell.sh
  #!/bin/bash MACHINE='raspberrypi3' source ./setup-environment build echo "you may try 'bitbake core-image-minimal'" bash 


Esse script raiz serve para inicializar as variáveis ​​de configuração do ambiente de construção e geralmente é chamado no início de uma sessão.

Inicialização de repositório


Para inicializar o repo, você deve executar o comando:

 mkdir torvin cd torvin repo init -u https:⁄⁄github.com/berserktv/bs-manifest -m raspberry/rocko/torvin-0.2.5.xml 

where -u https: ⁄⁄github.com / berserktv / bs-manifest informa ao GIT o caminho para o projeto manifest

nota: você também pode especificar -b tree_name
(se você não especificar a opção -b, a ramificação principal será assumida (por padrão))

em que o caminho -m raspberry / rocko / torvin-0.2.5.xml para o arquivo de configuração indica o seguinte:

  1. O nome da plataforma de hardware para a qual a montagem está sendo executada - raspberry
  2. O nome da principal ramificação do trabalho Yocto / OpenEmbedded é rocko
  3. O nome de código da versão é torvin (todas as versões da série 0.2.x)
  4. O número da versão digital que está sendo montada é 0.2.5

Repo Sync


para iniciar ou sincronizar subsequentemente, basta executar o comando:

 repo sync 

que selecionará todas as versões mais recentes dos projetos GIT especificadas no arquivo de manifesto (as ramificações geralmente são indicadas), se você tiver um nome de hash ou tag no atributo de revisão, a versão desse repositório git não será alterada. O nome da tag pode ser especificado assim: revision = "refs / tags / v0.2.5"

Criando uma configuração de projeto Yocto


Após a execução do comando repo sync, você pode começar a criar a configuração principal do Projeto Yocto:

 ./shell.sh 

após a conclusão do script, o diretório build / conf será criado:
com dois arquivos principais:

  • local.conf - variáveis ​​de controle de montagem:
    nome da plataforma, tipo de distribuição e pacotes de compilação, etc.
  • bblayers.conf - configuração das camadas conectadas do projeto Yocto

Por padrão, o script setup-environment procura fontes / base / conf
configuração inicial e se os arquivos local.conf e bblayers.conf
existir, eles são copiados para criar / conf
(consulte a variável TEMPLATES no ambiente de configuração)

isto é arquivos são obtidos de fontes / bs-manifest / raspberry / rocko / conf
veja a criação de um link simbólico para basear

Arquivo de configuração build / conf / local.conf


Mostrar / Ocultar
  MACHINE ??= 'raspberrypi3' DISTRO ?= 'poky' PACKAGE_CLASSES ?= "package_deb" EXTRA_IMAGE_FEATURES ?= "debug-tweaks" USER_CLASSES ?= "buildstats image-mklibs image-prelink" PATCHRESOLVE = "noop" BB_DISKMON_DIRS = "\ STOPTASKS,${TMPDIR},1G,100K \ STOPTASKS,${DL_DIR},1G,100K \ STOPTASKS,${SSTATE_DIR},1G,100K \ STOPTASKS,/tmp,100M,100K \ ABORT,${TMPDIR},100M,1K \ ABORT,${DL_DIR},100M,1K \ ABORT,${SSTATE_DIR},100M,1K \ ABORT,/tmp,10M,1K" PACKAGECONFIG_append_pn-qemu-native = " sdl" PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl" CONF_VERSION = "1" DL_DIR ?= "${BSPDIR}/downloads/" # size memory GPU for Raspberry Pi GPU_MEM = "128" GPU_MEM_256 = "112" GPU_MEM_512 = "160" GPU_MEM_1024 = "320" # for libs: "mpeg2dec libmad ffmpeg x264" LICENSE_FLAGS_WHITELIST += "commercial" 


Arquivo de configuração build / conf / bblayers.conf


Mostrar / Ocultar
  # POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf # changes incompatibly LCONF_VERSION = "6" POKY_BBLAYERS_CONF_VERSION = "2" BBPATH = "${TOPDIR}" BSPDIR := \ "${@os.path.abspath(os.path.dirname(d.getVar('FILE', True)) + '/../..')}" BBFILES ?= "" BBLAYERS ?= " \ ${BSPDIR}/sources/poky/meta \ ${BSPDIR}/sources/poky/meta-poky \ ${BSPDIR}/sources/poky/meta-yocto-bsp \ ${BSPDIR}/sources/meta-openembedded/meta-oe \ ${BSPDIR}/sources/meta-openembedded/meta-python \ ${BSPDIR}/sources/meta-openembedded/meta-networking \ ${BSPDIR}/sources/meta-openembedded/meta-multimedia \ ${BSPDIR}/sources/meta-openembedded/meta-filesystems \ ${BSPDIR}/sources/meta-raspberrypi \ ${BSPDIR}/sources/berserk/meta-berserk \ " 



as principais variáveis ​​do arquivo local.conf - às quais você precisa prestar atenção:

  • MÁQUINA - o nome da plataforma sob a qual a montagem é realizada
  • DISTRO - nome da categoria de distribuição
  • PACKAGE_CLASSES - formato do pacote para instalação do software
  • LICENSE_FLAGS_WHITELIST - uso de licenças adicionais

configurações específicas para a família de placas Raspberry Pi

  • GPU_MEM = "128" - a quantidade de memória de vídeo para o adaptador de vídeo GPU (alocado da RAM)
  • GPU_MEM_256 = "112" - o mesmo apenas para placas com um tamanho total de RAM = 256MB
  • GPU_MEM_512 = "160" - o mesmo apenas para placas com um tamanho total de RAM = 512MB
  • GPU_MEM_1024 = "320" - o mesmo é apenas para placas com um tamanho total de RAM = 1024MB

nota:
por exemplo, se você deixar apenas a variável GPU_MEM = "128",
depois, para todas as placas RPI, RPI2, RPI3
independentemente da quantidade de RAM real
no quadro será sempre alocado para a GPU - 128Mb
(e o tamanho total da RAM diminui nesse valor)

se todas as variáveis ​​forem especificadas, as diretivas GPU_MEM_256, GPU_MEM_512, GPU_MEM_1024 terão mais prioridade.

Para a montagem do Multimedia Center, além das camadas regulares do Yocto, consulte o arquivo bblayers.conf

 ${BSPDIR}/sources/poky/meta \ ${BSPDIR}/sources/poky/meta-poky \ ${BSPDIR}/sources/poky/meta-yocto-bsp \ 

Conectei quatro camadas com funcionalidade adicional do OpenEmbedded.

Kodi Multimedia Center - é um programa complexo que usa um grande número de bibliotecas externas e você precisa criar cada biblioteca usando uma receita de compilação; portanto, se possível, usarei todas as receitas do OpenEmbedded na categoria Multimídia

Então, eu tenho uma camada de multimídia conectada e as camadas das quais depende

 ${BSPDIR}/sources/meta-openembedded/meta-oe \ ${BSPDIR}/sources/meta-openembedded/meta-python \ ${BSPDIR}/sources/meta-openembedded/meta-networking \ ${BSPDIR}/sources/meta-openembedded/meta-multimedia \ 

então outra camada OpenEmbedded é conectada para trabalhar com sistemas de arquivos

 ${BSPDIR}/sources/meta-openembedded/meta-filesystems \ 

conectou ainda mais a camada principal do BSP para a plataforma Raspberry Pi

 ${BSPDIR}/sources/meta-raspberrypi \ 

Bem, no final, está conectada uma camada adicional, responsável pela montagem da imagem de distribuição com a funcionalidade do "Multimedia Center"

 ${BSPDIR}/sources/berserk/meta-berserk \ 

Camada para montagem de um centro multimídia


Na minha opinião, o Projeto Yocto é uma combinação industrial para criar distribuições incorporadas. Mas se você já trabalhou com o sistema de construção Buildroot, o Yocto pode parecer complicado para você. Ele usa uma enorme quantidade de espaço livre no disco rígido. Para operação normal, o Yocto requer cerca de 80 a 100 GB de espaço livre, e isso geralmente leva em consideração o conjunto apenas para uma plataforma.

O Yocto lida com seu objetivo principal - suportar o maior número possível de plataformas de hardware, e isso requer o mecanismo mais flexível para alternar os conjuntos. E esse mecanismo precisa de tempo e lugar. Construir uma distribuição no Yocto não é um processo rápido.

Então, toda a funcionalidade para montar o "Multimedia Center" que eu tenho com uma camada separada:

 https://github/berserktv/berserk 

(Título retirado do meu livro favorito, The Hammer and the Cross, de Harry Harrison.)
(Torvin também é um personagem deste livro.)

Para criar a funcionalidade necessária, usarei os chamados complementos para receitas, localizados em arquivos com a extensão .bbappend
no arquivo .bbappend, você pode adicionar suas próprias chamadas de comando para o método de receita de construção regular, por exemplo, ao método do_configure, do_compile, do_install, etc.

Estrutura de camada


 COP── COPYING.MIT
 Meta── meta-berserk
 │ ├── conf
 Layer │ ─── layer.conf
 │ ├── receitas-berserk
 │ │ ├── bs-net
 │ │ ├── primeira execução
 Imagens de │ │ ├──
 │ │ └── tv
 │ ├── receitas-core
 Init │ ├── init-ifupdown
 │ │ └── psplash
 Recipes ├── receitas-kernel
 Lin │ └── linux
 │ ├── receitas-mediacentre
 │ │ ├── kodi
 K │ └── kodi-plugins
 │ └── receitas-multimídia
 │ └── ffmpeg
 ├── README.md
 └── changelog.txt


Composição da camada:

  • configuração de camada conf
  • recipes-berserk - distribuição de receitas de distribuição, tv, rede e receitas de primeiro lançamento
  • recipes-core - receitas básicas, em particular uma modificação na receita inicial
  • recipes-kernel - Receitas de compilação do kernel Linux
  • recipes-mediacentre - receitas para construir o Kodi e seus plugins
  • recipes-multimedia - receitas multimídia, montagem ffmpeg

configuração da camada


inclui o arquivo layer.conf
  # We have a conf and classes directory, add to BBPATH BBPATH .= ":${LAYERDIR}" # We have a packages directory, add to BBFILES BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \ ${LAYERDIR}/recipes-*/*/*.bbappend" BBFILE_COLLECTIONS += "bs" BBFILE_PATTERN_bs := "^${LAYERDIR}/" BBFILE_PRIORITY_bs = "5" DISTRO_FEATURES_append += " wifi x11" PREFERRED_VERSION_ffmpeg = "3.1.11" SYSVINIT_ENABLED_GETTYS = "1" PREFERRED_VERSION_linux-raspberrypi ?= "4.9%" 


O arquivo contém uma indicação da versão da biblioteca ffmpeg, o número da versão do kernel do linux, bem como o número de consoles virtuais (tty), e inclui os recursos do kit de distribuição - wifi x11
DISTRO_FEATURES_append + = "wifi x11"

PREFERRED_VERSION_ffmpeg = "3.1.11"
SYSVINIT_ENABLED_GETTYS = "1"

PREFERRED_VERSION_linux-raspberrypi? = "4.9%"

composição de receitas-berserk


 B── bs-net
 │ └── bs-net_0.1.3.bb
 ├── primeira execução
 │ ├── arquivos
 │ │ └── first-run.sh
 │ └── first-run.bb
 ├── imagens
 │ └── berserk-image.bb
 └── tv
     ├── arquivos
     │ └── berserk.m3u8
     ├── tv-config.bb
     └── tv-dir.inc


onde:

  • bs-net_0.1.3.bb - receita para criar extensões de shell para interfaces WLAN / Ethernet
  • first-run.bb - receita para a primeira execução, particionamento de disco adicional
  • first-run.sh - script de shell da primeira execução (executada no nível S)
  • berserk-image.bb - receita para construir a imagem de distribuição
  • tv-config.bb - receita para configurar canais de TV usando IPTV
  • berserk.m3u8 - configuração de canais públicos de televisão (formato m3u8)

composição do núcleo de receitas


 Init── init-ifupdown
 │ ├── arquivos
 Interfaces │ └── interfaces
 Init └── init-ifupdown_1.0.bbappend
 Ps── psplash
     ├── arquivos
     │ └── psplash-berserk-img.h
     Ps── psplash_git.bbappend


onde:

  • interfaces - arquivo com a configuração de rede atual
  • init-ifupdown_1.0.bbappend - extensão para receita de configuração de rede
  • psplash-berserk-img.h - imagem do protetor de tela de inicialização
    arquivo de cabeçalho obtido usando o utilitário gdk-pixbuf-csource
  • psplash_git.bbappend - extensão da receita para iniciar o protetor de tela de inicialização

A configuração de rede no dispositivo de destino está no arquivo:

 /etc/network/interfaces 

Após adicionar a extensão da receita init-ifupdown, substituo o arquivo de configuração regular pelo meu e altero a ordem (prioridade) do script executado para os níveis de execução

 INITSCRIPT_PARAMS = "start 98 2 3 4 5 . stop 10 0 6 1 ." 

No momento, quase todas as distribuições modernas do Linux incluem uma tela de inicialização. Normalmente, o protetor de tela de inicialização mostra o estado atual do carregamento indicador do tempo decorrido desde o início do sistema. A esse respeito, o Yocto não é exceção e você pode alterar a imagem do protetor de tela de inicialização padrão para uma imagem arbitrária.

Para fazer isso, você deve:

  1. FILESEXTRAPATHS_prepend - adicione diretório para recursos
  2. SRC_URI - adicione um arquivo de cabeçalho com uma imagem arbitrária
  3. SPLASH_IMAGES - alterar variável de controle de pacote

e ainda mais na receita da imagem “berserk-image.bb”, é necessário adicionar a imagem inicial do splash, pois as características da imagem

 IMAGE_FEATURES += "splash" #          SPLASH = "psplash-berserk" 

composição de receitas-kernel


 Lin── linux
     ├── arquivos
     D ├── db.txt.patch
     │ └── rbpi.cfg
     Lin── linux-raspberrypi_4.9.bbappend


onde:

  • db.txt.patch - patch com a base do domínio de regulamentação (usado para WiFi)
  • rbpi.cfg - Fragmento de configuração do kernel do Linux
  • linux-raspberrypi_4.9.bbappend - extensão da receita de compilação do kernel 4.9 para Raspberry Pi

Os dispositivos Wi-Fi operam em determinadas frequências e, para eles, existe um domínio regulatório - este é o parâmetro que indica o país em que esse dispositivo deve funcionar.

O kernel do Linux possui um banco de dados complementar no qual as frequências permitidas e a potência permitida para elas são registradas para cada país.

No caso mais simples, esse banco de dados pode ser incluído diretamente no kernel estaticamente, especificando um parâmetro:
CONFIG_CFG80211_INTERNAL_REGDB = y
que foi exatamente o que fiz ao conectar um patch a este banco de dados db.txt.patch

E outra coisa: no Yocto, existem fragmentos de configurações do kernel. Geralmente, um fragmento de configuração, um arquivo com a extensão cfg, contém apenas os parâmetros do kernel que você claramente precisa para determinados fins. E essa parte da configuração é adicionada aos parâmetros padrão que já estão presentes na receita ao criar o kernel.

Além da receita bbappend, você também pode alterar os parâmetros que são passados ​​para o kernel durante a inicialização:

isto é substituir variável
CMDLINE, consulte o arquivo linux-raspberrypi_4.9.bbappend

conteúdo de rbpi.cfg
  # use statically compiled regulatory rules database CONFIG_CFG80211_INTERNAL_REGDB=y #  Wifi  Asus USB-N53 chipset Ralink RT3572 CONFIG_RT2800USB=m #  wifi    Atheros D-Link DWA-126 802.11n (AR9271), # NetGear WNDA3200, NetGear WNA1100, TP-Link TL-WN722N (AR9271), # TL-WN322G v3, TL-WN422G  .. . cateee.net CONFIG_ATH9K_HW=m CONFIG_ATH9K_HTC=m #  Wifi    wpa_supplicant CONFIG_WIRELESS=y CONFIG_WEXT_CORE=y CONFIG_WEXT_PROC=y CONFIG_CRYPTO_AES=y #    IPSec,    Wifi  #   wpa_supplicant   CONFIG_CRYPTO_CCM=m CONFIG_CRYPTO_CTR=m CONFIG_CRYPTO_ARC4=m ######################### #   CONFIG_HAVE_PERF_EVENTS=y CONFIG_PERF_EVENTS=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LATENCYTOP=y # This option adds support for ASIX AX88xxx # based USB 2.0 10/100 Ethernet adapters. CONFIG_USB_NET_AX8817X=m 


linux-raspberrypi_4.9.bbappend
  #      rpbi.cfg FILESEXTRAPATHS_prepend := "${THISDIR}/files:" SRC_URI += "file://db.txt.patch;patch=1 \ file://rbpi.cfg \ " #  BSP  meta-raspberrypi     # https://github.com/agherzan/meta-raspberrypi/issues/14 #    #   do_kernel_configme   #     arch/    do_kernel_configme_append() { cat ${WORKDIR}/rbpi.cfg >> ${WORKDIR}/defconfig } # CMDLINE for raspberrypi # default CMDLINE = "dwc_otg.lpm_enable=0 console=serial0,115200 # root=/dev/mmcblk0p2 rootfstype=ext4 rootwait" CMDLINE = "quiet dwc_otg.lpm_enable=0 console=serial0,115200 \ root=/dev/mmcblk0p2 rootfstype=ext4 rootwait" 


recipes-mediacentre


 ├── kodi │  ├── kodi │  ├── kodi_17.bbappend │  ├── kodi-dir.inc │  ├── kodi-runner.bb │  ├── kodi-settings.bb │  └── kodi-version.inc └── kodi-plugins ├── files ├── kodi-language-ru_3.0.10.bb ├── kodi-pvr-iptvsimple.bb ├── plugin-video-youtube_5.5.1.bb ├── screensaver-kodi-universe_0.1.2.bb ├── script-berserk-network_0.2.5.bb └── script-module-requests_2.12.4.bb 

onde:

  1. kodi/
    • kodi — icon,run,settings
    • kodi_17.bbappend — Kodi
    • kodi-dir.inc — Kodi
    • kodi-runner.bb — Kodi
    • kodi-settings.bb — Kodi
    • kodi-version.inc — Kodi

  2. kodi-plugins/

    • files — tar.gz
    • kodi-language-ru_3.0.10.bb — ( Kodi)
    • kodi-pvr-iptvsimple.bb — Kodi pvr-iptvsimple
    • plugin-video-youtube_5.5.1.bb — Kodi «Youtube»
    • screensaver-kodi-universe_0.1.2.bb — screensaver-kodi-universe
    • script-berserk-network_0.2.5.bb —
    • script-module-requests_2.12.4.bb — Youtube


recipes-multimedia


└── ffmpeg
    ├── ffmpeg
    │  ├── 0001-ffmpeg-Call-get_format-to-fix-an-issue-with-MMAL-ren.patch
    │  ├── h264_parser.patch
    │  └── pfcd_hevc_optimisations.patch
    └── ffmpeg_3.1.11.bb


onde:

  • 0001-ffmpeg-Call-get_format-to-fix-an-issue-with-MMAL-ren.patch — ffmpeg
  • h264_parser.patch — h264
  • pfcd_hevc_optimisations.patch — Raspberry Pi
  • ffmpeg_3.1.11.bb — ffmpeg (, )

FFmpeg - biblioteca OpenSource para codificação / decodificação de um grande número de formatos de vídeo e áudio. O FFmpeg suporta quase 400 codecs (ffmpeg -codecs)
e mais de 300 formatos (ffmpeg -formats).

Adição de receita de compilação Kodi


A camada OpenEmbedded contém uma receita regular para a criação do Kodi, mas é bastante geral, e eu gostaria de obter uma versão um pouco mais estável e testada para a plataforma Raspberry Pi.

Os desenvolvedores de software têm um patch de porta reversa. O software é atualizado constantemente e cada nova versão inclui novos recursos e a correção de erros conhecidos. O patch de portabilidade reversa permite transferir algumas das alterações na nova versão do programa para uma mais antiga, tornando-o mais estável. Mas este é um trabalho muito árduo e meticuloso, sempre realizado por um grande número de desenvolvedores.

No mundo da comunidade OpenSource, existem vários projetos conhecidos usando o Kodi, o melhor dos quais (na minha opinião) é o LibreElec (OpenElec). O LibreElec possui uma boa compilação para a plataforma Raspberry Pi. Aqui estão eles e é melhor usar o patch de porta reversa para o Kodi. Assim, você pode se livrar de um grande número de problemas sem sequer aprender sobre isso.

O centro multimídia Kodi está focado em reproduzir o contexto "Mídia" e, na minha opinião, o componente mais crítico é a combinação de Kodi e FFmpeg, ou seja, Na interação de determinadas versões desses programas, outras bibliotecas podem ser deixadas nas camadas Yocto e OpenEmbedded.

Para montagem, peguei a versão estável do Kodi 17.6 e a versão FFmpeg 3.1.11

Nota:
   ,       ,      systemD.         (   (  )).  ,     LibreElec       : #!/bin/bash HASH_VER="934507d922fb011ce46c76566206f2f1f603360b" git clone https://github.com/LibreELEC/LibreELEC.tv.git libreelec cd libreelec git checkout ${HASH_VER}   Kodi,   : projects/RPi2/patches/kodi (. : kodi-001-backport.patch)    FFmpeg,   : packages/multimedia/ffmpeg/patches 


O arquivo de descrição da versão incluído será tão kodi-version.inc

 FILESEXTRAPATHS_prepend := "${THISDIR}/kodi:" #  Krypton SRCREV = "a9a7a20071bfd759e72e7053cee92e6f5cfb5e48" PV = "17.6+gitr${SRCPV}" 

O ramo Yocto e OpenEmbedded que estou considerando - rocko , contém o Kodi versão 17.3 e, para atualizar para a versão 17.6, basta adicionar uma pequena adição à receita - kodi_17.bbappend

 require kodi-version.inc #     (   17.3) SRC_URI_remove = "file://0013-FTPParse.cpp-use-std-string.patch" #  ,   systemd   SRC_URI_remove = "file://0004-handle-SIGTERM.patch" #      RPI   libreelec SRC_URI_append += "file://kodi-krypton-rpb-backports.patch" #  error adding symbols: DSO missing from command line SRC_URI_append += "file://vchostif.patch" MENU_ICON = "addons/skin.estuary/media/icons/settings" #       ( ) SRC_URI_append += "file://bs-menu.patch file://icon/bs-network.png" do_configure_prepend() { install -m 0644 ${WORKDIR}/icon/bs-network.png ${S}/${MENU_ICON} } #    kodi plugins RRECOMMENDS_${PN}_append = "\ python-xml python-misc python-db \ python-crypt python-threading python-math python-email \ python-io python-netserver python-urllib3 python-datetime" #     Raspberry Pi #  OPENGL    --enable-gles #  kodi     docs/README.linux => libxmu libxinerama # libxtst xdpyinfo #      DISTRO_FEATURES   "x11" #   kodi  RPI1  RPI2,3    --disable-x11 BS_RPI = " --disable-gl --enable-openmax --enable-player=omxplayer \ --with-platform=raspberry-pi --disable-x11" BS_RPI3 = " --disable-gl --enable-openmax --enable-player=omxplayer \ --with-platform=raspberry-pi2 --disable-x11" EXTRA_OECONF_append = "${@bb.utils.contains('MACHINE', 'raspberrypi', \ '${BS_RPI}', '', d)}" EXTRA_OECONF_append = "${@bb.utils.contains('MACHINE', 'raspberrypi2', \ '${BS_RPI3}', '', d)}" EXTRA_OECONF_append = "${@bb.utils.contains('MACHINE', 'raspberrypi3', \ '${BS_RPI3}', '', d)}" #       Kodi   #  ,  USB  microSDHC  ( ) EXTRA_OECONF_append = " --enable-optical-drive" 

A opção de compilação "--enable-optical-drive" permite conectar o mecanismo de notificação conveniente que o Kodi usa ao conectar um disco óptico. Nesse caso, o módulo MediaManager (a) (xbmc / storage / MediaManager.cpp) monitora a conexão / desconexão de novas partições de disco e exibe uma mensagem pop-up sobre isso.

Exemplo de conexão / desconexão de unidades do udev:

 ACTION=="add" SUBSYSTEM=="block" ENV{ID_FS_TYPE}=="vfat" \ KERNEL=="sd[az][0-9]" \ RUN+="/bin/mkdir -p /media/%k", \ RUN+="/bin/mount -o iocharset=utf8,noatime /dev/%k /media/%k" ACTION=="add" SUBSYSTEM=="block" ENV{ID_FS_TYPE}=="ntfs" \ KERNEL=="sd[az][0-9]" \ RUN+="/bin/mkdir -p /media/%k", \ RUN+="/usr/bin/ntfs-3g -o \ iocharset=utf8,noatime,windows_names /dev/%k /media/%k" ACTION=="add" SUBSYSTEM=="block" ENV{ID_FS_TYPE}=="ext2|ext3|ext4" \ KERNEL=="sd[az][0-9]" \ RUN+="/bin/mkdir -p /media/%k", \ RUN+="/bin/mount -o noatime /dev/%k /media/%k" ACTION=="remove" SUBSYSTEM=="block" KERNEL=="sd[az][0-9]" \ RUN+="/bin/umount /media/%k", RUN+="/bin/rmdir /media/%k" 

 :  rmdir     ,       ( Linux    -  )       . 

Adicionando um novo item ao menu de configurações do Kodi


No Kodi 17.6, os arquivos de configuração xml são responsáveis ​​pela exibição dos itens de menu. Para adicionar mais um item no menu "Configurações", basta ajustar o arquivo:
kodi / addons / skin.estuary / xml / Settings.xml em

que skin.estuary é o tema de design do menu padrão, a

descrição do item fica assim:

<item>
    <label> $ LOCALIZE [13279] </label>
    <onclick> RunAddon (script.berserk.network, butnetwork) </onclick>
    <icon> ícones / configurações / bs-network.png </icon>
</item>


onde:

label - nome do item de menu
onclick - manipulação do evento de pressionar o botão menu
(iniciando o plug-in, com o primeiro argumento passando a string “butnetwork”)
ícone - ícone do item de menu (caminho para a imagem png)

A funcionalidade acima, além de conectar vários plug-ins Kodi adicionais, está integrada ao usando o arquivo bs-menu.patch

Mostrar / Ocultar
  diff -Naur a/addons/skin.estuary/xml/Settings.xml b/addons/skin.estuary/xml/Settings.xml --- a/addons/skin.estuary/xml/Settings.xml 2018-02-01 18:17:45.000000000 +0300 +++ b/addons/skin.estuary/xml/Settings.xml 2018-03-08 12:06:50.000000000 +0300 @@ -134,6 +134,11 @@ <icon>icons/settings/interface.png</icon> </item> <item> + <label>$LOCALIZE[13279]</label> + <onclick>RunAddon(script.berserk.network,butnetwork)</onclick> + <icon>icons/settings/bs-network.png</icon> + </item> + <item> <label>$LOCALIZE[20077]</label> <onclick>ActivateWindow(SkinSettings)</onclick> <icon>icons/settings/skin.png</icon> diff -Naur a/system/addon-manifest.xml b/system/addon-manifest.xml --- a/system/addon-manifest.xml 2018-03-07 15:58:24.000000000 +0300 +++ b/system/addon-manifest.xml 2018-05-14 14:06:58.000000000 +0300 @@ -27,6 +27,7 @@ <addon>resource.uisounds.kodi</addon> <addon>screensaver.xbmc.builtin.black</addon> <addon>screensaver.xbmc.builtin.dim</addon> + <addon>screensaver.kodi.universe</addon> <addon>script.module.pil</addon> <addon>service.xbmc.versioncheck</addon> <addon>skin.estuary</addon> @@ -43,4 +44,8 @@ <addon>xbmc.python</addon> <addon>xbmc.webinterface</addon> <addon optional="true">peripheral.joystick</addon> + <addon>script.berserk.network</addon> + <addon>resource.language.ru_ru</addon> + <addon>script.module.requests</addon> + <addon>plugin.video.youtube</addon> </addons> 


Configurações máximas de buffer para vídeo


No Kodi Multimedia Center, para maximizar o desempenho, você pode especificar as configurações máximas de buffer:

 <advancedsettings> <cache> <buffermode>1</buffermode> <memorysize>139460608</memorysize> <readfactor>20</readfactor> </cache> </advancedsettings> 

buffermode = 1
- solicitações de buffer para todos os sistemas de arquivos (incluindo local)

readfactor
- ajusta a velocidade do download com base na taxa de bits média do vídeo. Portanto, por exemplo, se você reproduzir um vídeo com uma taxa média de transferência de dados de 5 Mbit / se definir a taxa de leitura do buffer para 2,0, isso limitará a velocidade de download (e, portanto, a taxa de preenchimento do cache) para cerca de 10 Mbit / s, assim:

readfactor = 20
remove a restrição na velocidade de download

MemorySize = 139 460 608
- buffer de tamanho é de 133 MB, utilizando a RAM 133 * 3 i cerca de 400 MB de RAM

Assistindo TV por IPTV


O Kodi Media Center é uma ferramenta muito poderosa para visualizar conteúdo digital.

A principal função para a qual coletei o "Media Center" é a função de assistir televisão digital usando IPTV (Internet Protocol Television), ou seja, televisão através do protocolo da internet. Com esta função, você pode assistir televisão digital do seu provedor de Internet.

Essa é a opção mais moderna e ideal, tanto em termos de qualidade de imagem quanto em recursos adicionais, ou seja, serviços prestados. Por exemplo, os canais de televisão podem ser fornecidos no arquivo, no qual a gravação de vídeo desejada fica disponível por algum tempo após a transmissão.

Para dar suporte ao IPTV no Kodi, existem várias opções de plug-ins, das quais eu decidi no plug-inpvr.iptvsimple

Para criar o plugin, use a receita:

    K── kodi-plugins
        └── kodi-pvr-iptvsimple.bb


O plug-in é conectado / configurado por meio de:
Menu principal do Kodi => “Complementos” => “Meus complementos” => “Clientes PVR” => “PVR IPTV Simple Client”

Para verificar o funcionamento da televisão IPTV como parte do Kodi, tomei vários canais públicos de notícias e os adicionou à lista no formato m3u8, além de ativar o lançamento automático do plug-in “pvr.iptvsimple” no início do media center.

Assistindo ao Youtube com o plug-in Kodi


Os programadores que desenvolveram o Kodi forneceram flexibilidade para expandir suas funções. Isso é feito para que qualquer entusiasta, se desejado, possa adicionar a Kodi o que ele realmente precisa. E esses plugins para Kodi são trevas. Bem, você entendeu.Existem tantos que merece uma descrição em um artigo separado.

Os plugins são instalados de maneira simples, basta conectar o Kodi à Internet e pressionar alguns botões no menu. Você pode ler sobre isso em qualquer um dos fóruns dedicados ao Kodi. Mas a montagem, existe a montagem, e incluirei outro plug-in na distribuição como exemplo.

O plugin mais interessante e mais abrangente (ohm) para o Kodi, na minha opinião, é o plugin de visualização do YouTube. O Kodi é um centro de multimídia, e o YouTube é o maior repositório desse conteúdo, portanto o plug-in do YouTube para o Kodi é quase obrigatório.

O plug-in é escrito em python, e este é um mecanismo de plug-in comum, você não precisa compilar nada, basta copiar o plug-in finalizado para o diretório raiz com os plug-ins e especificar o nome do plug-in no arquivo de manifesto xml:
"System / addon-manifest.xml"

O plug-in é retirado do repositório oficial e seu código-fonte está incluído no arquivo:
recipes-mediacentre / kodi-plugins / files / plugin.video.youtube.tar.gz Para obter a

localização da receita de criação do plug-in, veja acima capítulo "composição receitas-mediacentre"

Extensão de configuração de rede do shell do console


Como o kit de distribuição montado na estrutura deste artigo é uma demonstração, os requisitos para a configuração de “Interfaces de Rede” são mínimos. Eu não queria arrastar nenhum gerenciador de rede pesado para isso, o que era muito incompreensível para mim e muito volumoso, e, portanto, escrevi dois scripts de shell que complementam a configuração do mecanismo de configuração regular:

 ############################################################## #     /etc/network/interfaces: ############################################################## auto eth0 iface eth0 inet manual up /etc/network/eth-manual $IFACE up down /etc/network/eth-manual $IFACE down auto wlan0 iface wlan0 inet manual up /etc/network/wlan $IFACE up down /etc/network/wlan $IFACE down 

Para configurar convenientemente as interfaces de rede Ethernet / WLAN por meio da GUI, eu uso outro pequeno plug-in Kodi “script.berserk.network”. Este é quase o único plugin Kodi que eu descobri, mas para isso eu tive que escrevê-lo. É extremamente compacto e minimalista e está escrito na linguagem python.

Ambos os componentes são coletados usando receitas:

  • receitas-berserk / bs-net / bs-net_0.1.3.bb
  • recipes-mediacentre / kodi-plugins / script-berserk-network_0.2.5.bb

Neste ponto, gostaria de me debruçar sobre os detalhes. Portanto, toda a flexibilidade de usar o Yocto está em diferentes conjuntos de receitas, ou seja, conectou um conjunto de receitas - o gerenciador de rede mais simples foi adicionado ao kit de distribuição, conectou outro conjunto - adicionou seu gerenciador de rede favorito usando, por exemplo, systemD, etc.

Para conectar-se automaticamente a um ponto de acesso WiFi quando o sistema é iniciado, eu uso a regra do udev: /etc/udev/rules.d/80-wifi-start.rules

 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", KERNEL=="wlan*", \ RUN+="/etc/network/wlan-runner $env{INTERFACE} up" SUBSYSTEM=="net", ACTION=="remove", DRIVERS=="?*", KERNEL=="wlan*", \ RUN+="/etc/network/wlan-runner $env{INTERFACE} down" 

O script wlan-runner simplesmente executa os comandos:
/ etc / network / wlan $ IFACE up
ou
/ etc / network / wlan $ IFACE desativado

Receita de Construção de Distribuição


O Projeto Yocto possui um mecanismo de reutilização. Existem classes das quais você pode herdar (diretiva "herdar") e há receitas básicas que você pode conectar (diretiva "incluir").

Mostrarei herança usando o exemplo da classe:
poky / meta / clasess / core-image.bbclass

A classe é responsável por descrever os grupos de pacotes que você pode incluir em uma receita específica. Para fazer isso, basta indicar a construção no início da receita:
herdar imagem principal

Mesmo no texto desta classe, você pode ver os recursos da imagem, cada recurso é responsável por um grupo de funções incluídas na imagem e cada grupo finalmente descreve um conjunto de programas ou bibliotecas instalados.

Os recursos da imagem são indicados da seguinte forma:

 IMAGE_FEATURES += "ssh-server-dropbear splash" 

Também há DISTRO_FEATURES - recursos de distribuição que podem ser especificados no arquivo de configuração da camada. Essas são funções de nível de distribuição e, se, por exemplo, você alterar algum recurso (por exemplo, x11), o assembly subsequente começará a remontar todos os pacotes que dependem dessa opção (isso pode levar bastante tempo).

A receita básica básica que eu uso:
poky / meta / recipes-core / images / core-image-minimal.bb

receita de construção de imagem
  # Project: "Berserk" - build Kodi for the Raspberry Pi platform # license - The MIT License (MIT) DESCRIPTION = "Berserk - the image for the Raspberry PI" LICENSE = "MIT" MD5_SUM = "md5=0835ade698e0bcf8506ecda2f7b4f302" LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;${MD5_SUM}" IMAGE_FEATURES += "ssh-server-dropbear splash" #    rootfs    (250000kB=~250Mb) IMAGE_ROOTFS_EXTRA_SPACE_append += "+ 250000" # Base this image on core-image-minimal include recipes-core/images/core-image-minimal.bb # Set default password for 'root' user inherit extrausers ROOTUSERNAME = "root" ROOTPASSWORD = "berserk" EXTRA_USERS_PARAMS = "usermod -P ${ROOTPASSWORD} ${ROOTUSERNAME};" #  ,      SPLASH = "psplash-berserk" BS_DEBUG_TOOLS = "ldd strace ltrace" BS_GLIBC = "glibc-thread-db \ glibc-gconv-utf-16 \ glibc-gconv-utf-32 \ glibc-binary-localedata-en-us \ glibc-binary-localedata-ru-ru \ glibc-charmap-utf-8 \ " BS_BASE = "kernel-modules \ lsb \ pciutils \ parted \ tzdata \ dosfstools \ ntp \ ntpdate \ e2fsprogs-resize2fs \ ntfs-3g \ ntfsprogs \ " BS_WLAN = "kernel-module-rt2800usb \ kernel-module-rt2800lib \ kernel-module-rt2x00lib \ kernel-module-rt2x00usb \ kernel-module-cfg80211 \ kernel-module-nls-utf8 \ kernel-module-ath9k-common \ kernel-module-ath9k-hw \ kernel-module-ath9k-htc \ kernel-module-ctr \ kernel-module-ccm \ kernel-module-arc4 \ " BS_WIFI_SUPPORT = " \ iw \ dhcp-client \ wireless-tools \ wpa-supplicant \ linux-firmware \ " BS_SOFT = "mc \ kodi \ kodi-runner \ kodi-settings \ kodi-language-ru \ kodi-pvr-iptvsimple \ bs-net \ tv-config \ first-run \ script-berserk-network \ screensaver-kodi-universe \ plugin-video-youtube \ script-module-requests \ " # Include modules in rootfs IMAGE_INSTALL += " \ ${BS_BASE} \ ${BS_WLAN} \ ${BS_WIFI_SUPPORT} \ ${BS_GLIBC} \ ${BS_SOFT} \ ${BS_DEBUG_TOOLS} \ " 



Gostaria de esclarecer que, por exemplo , o pacote kernel-modules instalará
todos os módulos do kernel especificados no arquivo defconfig na imagem de distribuição.

Mas se você personaliza fortemente alguma coisa, é claro que talvez nem precise de todos os módulos do kernel; nesse caso, é conveniente adicionar cada módulo pelo nome, conforme indicado na variável BS_WLAN , é como uma folha de dicas, especifique apenas o que você precisa e após verificar o pacote "Kernel-modules" remove, verifica, etc.

Um breve guia para criar uma imagem de distribuição


1) Instale as dependências do Yocto Project no Ubuntu:
  sudo apt-get install -y --no-install-suggests --no-install-recommends \ gawk wget git-core diffstat unzip texinfo gcc-multilib build-essential \ chrpath socat cpio python python3 python3-pip python3-pexpect \ xz-utils debianutils iputils-ping python3-git python3-jinja2 \ libegl1-mesa libsdl1.2-dev xterm 


2) Baixe e instale o Repo:
  mkdir ~/bin curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo chmod a+x ~/bin/repo 


3) Faça o download do projeto no github:
  PATH=${PATH}:~/bin mkdir torvin cd torvin repo init -u https://github.com/berserktv/bs-manifest \ -m raspberry/rocko/torvin-0.2.5.xml repo sync 


4) Construa o projeto:
  ./shell.sh bitbake berserk-image 


5) Escreva a imagem de distribuição no cartão de memória:

torvin/build/tmp/deploy/images/raspberrypi3


:
berserk-image-raspberrypi3.rpi-sdimg

c
c UTC

dd

:
«microSDHC»
.

$ sudo bash
$ cd torvin/build/tmp/deploy/images/raspberrypi3
$ dd if=berserk-image-raspberrypi3.rpi-sdimg of=/dev/sdX bs=1M
$ sync

/dev/sdX:
X a,b,c ..


:
Windows,
Win32 Disk Imager :
:


Nota:
              N      ,      ""          ,    git  (..         "")   :  - Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz  - 8    -  USB-3.0 1T   - 4  05    - 1     - 274.8 M   torvin/build    (cache ,   ,   ,  ,   ,    ..) -   42    torvin/downloads -  9.1  (git    tar.gz )  rootfs   - 550     /lib/firmware - 212  /lib/modules - 53  :        firmware (   )       ,   200  


Postscript


Os recursos do OpenSource nos últimos anos estão apenas aumentando.

Mas essas oportunidades não são pequenas, por exemplo, você nem precisa ir longe. É improvável que a mesma "Microsoft" esperasse que a tecnologia OpenSource a jogasse no mercado de sistemas operacionais móveis. Quero dizer o sistema operacional do Google - "Android", que durante a noite jogou o "Pioneer" dos sistemas móveis à margem. E não está claro se a Microsoft poderá retornar a ele novamente.

Claro, "Google", uma grande corporação com finanças quase ilimitadas e excelentes desenvolvedores, mas ainda assim, como se costuma dizer "sem o Core e não aqui e ali".

Os melhores projetos de código aberto ao longo do tempo se tornam uma obra de arte (por exemplo, Kodi, Openelec / libre etc.)

E hoje, qualquer pessoa pode aderir às melhores práticas no OpenSource, por assim dizer, sem sair do Github (a). Este artigo é sobre isso.

Tenha muitas assembléias boas e diferentes para você e lembre-se "o mundo da Internet das coisas está chegando".

Source: https://habr.com/ru/post/pt467443/


All Articles