Geekly articles weekly

Centro Multimedia "Kodi" y Proyecto Yocto


Introducción al proyecto Yocto


Yocto Project es un proyecto colaborativo de código abierto para simplificar el desarrollo de distribuciones para sistemas embebidos. Yocto contiene una gran cantidad de plantillas, metadatos y herramientas de compilación. En Yocto Project, puede conectar una gran cantidad de capas BSP (paquete de soporte de plataforma) para todo tipo de plataformas de hardware.

El objetivo principal del artículo es un intento de mostrar el ensamblaje de un paquete de distribución típico en el Proyecto Yocto utilizando el conocido centro multimedia Kodi, versión 17.6 para una computadora Raspberry Pi 3B de placa única como ejemplo.

Si en algún lugar en el fondo de tu alma sientes que eres un coleccionista, pero aún no has decidido qué te gustaría coleccionar, entonces este artículo es para ti. Si ya usa el Proyecto Yocto en su trabajo diario, puede desplazarse por este artículo. Ve directamente al último capítulo y prepárate.

El artículo es puramente práctico y demuestra la posibilidad de utilizar los logros del Proyecto Yocto y OpenEmbedded para construir el centro multimedia "Kodi". Las capas de Yocto se administran utilizando la utilidad Repo de Google. Un artículo en el documento de esta serie.

Entonces: vamos.

Contenido:


Instalar Yocto Project en Ubuntu
Distribución del motor de construcción en el Proyecto Yocto
Usando OpenEmbedded con el Proyecto Yocto
Paquete de soporte de plataforma (BSP)
Gestionar capas de Yocto con Repo
Instalar repositorio
Distribución Construir manifiesto
Contenido manifiesto
Descripción manifiesta
Estructura de manifiesto b
Inicializando Variables Poky
Inicialización de repos
Sincronización de repositorios
Crear una configuración de proyecto Yocto
Archivo de configuración build / conf / local.conf
Archivo de configuración build / conf / bblayers.conf
Capa para ensamblar un centro multimedia
Estructura de la capa
Configuración de la capa
Composición de recetas-berserk
Composición de recetas-núcleo
Composición de recetas-kernel
Composición recetas-mediacentro
Composición de recetas multimedia.
Kodi Build Recipe Supplement
Agregar un nuevo elemento al menú de configuración de Kodi
Configuración máxima de almacenamiento en búfer para video
Mirar televisión por IPTV
Mirar Youtube con el complemento Kodi
Extensión de configuración de red de consola
Receta de construcción de distribución
Una breve guía para crear una imagen de distribución
Postdata

Instalar Yocto Project en Ubuntu


Para construir la distribución usando el Proyecto Yocto en Ubuntu, necesita instalar los siguientes paquetes:

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

Los paquetes se instalan utilizando el comando apt-get install y el comando sudo de escalada de privilegios. En el sistema Ubuntu, esta es una práctica generalizada cuando el comando sudo se usa para realizar acciones administrativas (cuando se crea el usuario principal del sistema, se registra automáticamente en el grupo "sudo").

Puede ver instrucciones de instalación más detalladas aquí:

Distribución del motor de construcción en el Proyecto Yocto


En el Proyecto Yocto, cada unidad de programa se describe utilizando una receta de ensamblaje. El lenguaje de descripción de la receta se asemeja a "bash" con la capacidad de insertar fragmentos de código en el lenguaje python. Puede obtener información básica de sintaxis en el manual del proyecto Yocto . Un conjunto de recetas de ensamblaje, dependiendo del propósito, se puede combinar en capas de ensamblaje separadas.

Las capas se dividen en dependientes del hardware: capas BSP, capas de interfaz de usuario (interfaz de usuario), capas específicas de Yocto, así como capas que implementan cierta funcionalidad:
por ejemplo, capas de OpenEmbedded => multimedia, python, perl, ruby, redes, systemd, servidor web, etc.

Usando OpenEmbedded con el Proyecto Yocto


Y, sin embargo, si usa el Proyecto Yocto, entonces seguramente necesitará capas con funcionalidad adicional, es decir Un gran conjunto de recetas para todas las ocasiones. Y existe tal conjunto: estas son recetas de OpenEmbedded. OpenEmbedded es una infraestructura para construir paquetes para Linux embebido.

OpenEmbedded es totalmente compatible con el Proyecto Yocto, ya que este proyecto fue tomado como base para el Proyecto Yocto. Quizás es por eso que el Proyecto Yocto tiene una estabilidad ligeramente mejor, mejor documentación y un soporte un poco mejor (pero básicamente sigue siendo el mismo OpenEmbedded).

Paquete de soporte de plataforma (BSP)


El paquete de soporte de la placa es una capa (s) especializada y separada para una placa específica que define las características de hardware de la plataforma, es decir implementa esas cosas específicas que distinguen una placa de otra: características del procesador, interrupciones, direccionamiento, características del cargador de arranque, características del adaptador de video (GPU), etc.

Este artículo usa la capa BSP - meta-raspberrypi
El repositorio de capas se encuentra en: git.yoctoproject.org/git/meta-raspberrypi

Gestionar capas de Yocto con Repo


Yocto Project puede usar una gran cantidad de capas de diferentes proveedores, desarrolladores de equipos, y todo esto debe gestionarse de alguna manera. Imagine que tiene una docena de placas diferentes, y cada placa viene con un repositorio git BSP separado, y esto no cuenta la infraestructura del proyecto Yocto en sí, más la posible funcionalidad adicional de OpenEmbedded.

En tal situación, no comenzará con un script de instalación simple por separado. Willy-nilly, tiene que buscar herramientas que puedan hacerlo bien. Incluso más que bien. Una de las mejores herramientas de este tipo es la utilidad de Google: Repo.

Repo es la herramienta principal para administrar repositorios GIT al construir el sistema operativo Android con su gran código base. Repo le permite administrar una docena, si no un centenar de repositorios git separados en un proyecto, cuyas versiones puede especificar cuidadosamente en un archivo xml del Manifiesto

y para la correcta sincronización de todas las versiones de todos los repositorios solo necesita ejecutar un comando

sincronización de repositorio

Instalar repositorio


Usando el siguiente conjunto de comandos, puede instalar Repo en su directorio de inicio ~ / bin
(el comando curl se puede instalar por separado: 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


y en el futuro solo necesitas usar el comando en la consola: repo

mas o menos
si el directorio INICIO / bin no se agrega con la ruta de inicio estándar automáticamente
ver archivo INICIO / .profile

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

Distribución Construir manifiesto


La distribución recopilada en el marco del artículo, necesito llamarlo algo. Que se llame Torvin . Denominado Torvin, contendrá una distribución minimalista de Linux con el ensamblaje de un solo programa. Esto se refiere a un programa de usuario de aplicación: Kodi, y nada más (todo lo demás es un nivel de sistema). Para un centro multimedia, en mi opinión, esto es suficiente.

Contenido manifiesto


El archivo torvin-0.2.5.xml se usa para administrar capas de distribución .

  <?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>

Descripción manifiesta


Al comienzo del manifiesto, las etiquetas remotas denotan dos repositorios GIT principales y uno auxiliar:

https: ⁄⁄git.yoctoproject.org / git - repositorio de Yocto llamado yocto
https: ⁄⁄github.com / openembedded - Repositorio OpenEmbedded nombrado como oe
https: ⁄⁄github.com / berserktv - repositorio GIT auxiliar llamado bs

En la siguiente parte del manifiesto, usando nombres abreviados, trabajamos con proyectos ubicados en estos repositorios, la etiqueta del proyecto contiene los siguientes atributos:

remoto : el nombre del repositorio con nombre remoto
revisión : el nombre de la rama o la versión hash
nombre : nombre del proyecto en el repositorio especificado
ruta : la ruta del proyecto local en su sistema de archivos

    <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

En el cuerpo de la etiqueta del proyecto , indiqué comandos para crear enlaces simbólicos a la infraestructura de scripts auxiliares de inicialización inicial y arranque regular del sistema de compilación Poky que necesito

    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

Estructura de manifiesto b


 ├── COPIA.MIT
 ├── frambuesa
 │ ├── rocko
 │ │ ├── conf
 │ │ │ ├── bblayers.conf
 │ │ │ └── local.conf
 │ │ └── torvin-0.2.5.xml
 │ └── shell.sh
 ├── README.md
 └── entorno de configuración


El proyecto bs-manifest se utiliza para una gestión de configuración flexible, teniendo en cuenta los ensamblajes de diferentes versiones de la distribución. Tengo esta versión - 0.2.5

Inicializando Variables Poky


El entorno de configuración del script de inicialización se tomó del proyecto Freescale Community (en el entorno yocto, esta es una solución común). El script es responsable de la inicialización de las variables del sistema de compilación Poky, el script crea una estructura de directorio en la que está muy bien dividido:

  • build - directorio de construcción
  • fuente - código fuente de recetas de ensamblaje
  • download - directorio para descargar el código del programa (bases de datos git, archivos tar.gz)

El contenido del script de entorno de configuración se puede ver aquí:

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


Este script raíz sirve para inicializar las variables de configuración del entorno de compilación y generalmente se llama al comienzo de una sesión.

Inicialización de repos


Para inicializar el repositorio, debe ejecutar el comando:

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

donde -u https: ⁄⁄github.com / berserktv / bs-manifest le dice a GIT la ruta al proyecto de manifiesto

nota: también puede especificar -b tree_name
(si no especifica el modificador -b, se asume la rama maestra (por defecto))

donde la ruta -m raspberry / rocko / torvin-0.2.5.xml al archivo de configuración indica lo siguiente:

  1. El nombre de la plataforma de hardware para la que se realiza el ensamblaje: frambuesa
  2. El nombre de la rama de trabajo principal de Yocto / OpenEmbedded es rocko
  3. El nombre en clave de la versión es torvin (todas las versiones de la serie 0.2.x)
  4. El número de versión digital que se está ensamblando es 0.2.5

Sincronización de repositorios


para iniciar o posterior sincronización, simplemente ejecute el comando

 repo sync

que recogerá todas las últimas versiones de proyectos GIT especificados en el archivo de manifiesto (las ramas generalmente se indican), si tiene un hash commit o nombre de etiqueta en el atributo de revisión, entonces la versión para este repositorio git no cambiará. El nombre de la etiqueta se puede especificar así: revision = "refs / tags / v0.2.5"

Crear una configuración de proyecto Yocto


Después de ejecutar el comando repo sync, puede comenzar a crear la configuración principal del Proyecto Yocto:

 ./shell.sh

después de que se complete el script, se creará el directorio build / conf :
con dos archivos principales:

  • local.conf - variables de control de ensamblaje:
    nombre de la plataforma, tipo de distribución y paquetes de compilación, etc.
  • bblayers.conf - configuración de las capas conectadas del Proyecto Yocto

de forma predeterminada, el script de entorno de configuración busca fuentes / base / conf
configuración inicial y si los archivos local.conf y bblayers.conf
existen, se copian para construir / conf
(vea la variable PLANTILLAS en el entorno de configuración)

es decir los archivos se toman de sources / bs-manifest / raspberry / rocko / conf
ver crear un enlace simbólico a la base

Archivo de configuración 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"


Archivo de configuración 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 \ "



Las principales variables del archivo local.conf, a las que debe prestar atención:

  • MÁQUINA - el nombre de la plataforma bajo la cual se lleva a cabo el ensamblaje
  • DISTRO - nombre de categoría de distribución
  • PACKAGE_CLASSES: formato de paquete para instalar software
  • LICENSE_FLAGS_WHITELIST - uso de licencias adicionales

configuraciones específicas para la familia de placas Raspberry Pi

  • GPU_MEM = "128" - la cantidad de memoria de video para el adaptador de video GPU (asignado desde RAM)
  • GPU_MEM_256 = "112" - lo mismo solo para placas con un tamaño total de RAM = 256MB
  • GPU_MEM_512 = "160" - lo mismo solo para placas con un tamaño total de RAM = 512MB
  • GPU_MEM_1024 = "320" - lo mismo es solo para placas con un tamaño total de RAM = 1024MB

nota:
por ejemplo, si deja solo la variable GPU_MEM = "128",
entonces para todas las placas RPI, RPI2, RPI3
independientemente de la cantidad de RAM real
en el tablero siempre se asignarán para la GPU - 128Mb
(y el tamaño total de RAM disminuye en este valor)

si se especifican todas las variables, las directivas GPU_MEM_256, GPU_MEM_512, GPU_MEM_1024 son más prioritarias.

Para el ensamblaje del Centro Multimedia, además de las capas regulares de Yocto, vea el archivo bblayers.conf

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

Conecté cuatro capas con funcionalidad adicional de OpenEmbedded.

Kodi Multimedia Center: es un programa complejo que utiliza una gran cantidad de bibliotecas externas y necesita construir cada biblioteca utilizando una receta de compilación, por lo que, si es posible, usaré todas las recetas de OpenEmbedded en la categoría Multimedia

Entonces, tengo una capa Multimedia conectada y las capas de las que 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 \

entonces otra capa OpenEmbedded está conectada para trabajar con sistemas de archivos

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

conectó aún más la capa BSP principal para la plataforma Raspberry Pi

 ${BSPDIR}/sources/meta-raspberrypi \

Bueno, al final, se conecta una capa adicional, responsable de ensamblar la imagen de distribución con la funcionalidad del "Centro Multimedia"

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

Capa para ensamblar un centro multimedia


En mi opinión, el Proyecto Yocto es una cosechadora industrial para crear distribuciones integradas. Pero si alguna vez ha trabajado con el sistema de construcción Buildroot, entonces Yocto puede parecerle engorroso. Utiliza una gran cantidad de espacio libre en el disco duro. Para el funcionamiento normal, Yocto requiere alrededor de 80 - 100 GB de espacio libre, y esto generalmente tiene en cuenta el ensamblaje solo para una plataforma.

Yocto hace frente a su propósito principal: soportar tantas plataformas de hardware diferentes como sea posible, y esto requiere el mecanismo más flexible para cambiar los ensambles. Y este mecanismo necesita tiempo y lugar. Crear una distribución en Yocto no es un proceso rápido.

Entonces, toda la funcionalidad para ensamblar el "Centro Multimedia" que tengo con una capa separada:

 https://github/berserktv/berserk

(Título tomado de mi libro favorito, El martillo y la cruz, de Harry Harrison).
(Torvin también es un personaje en este libro).

Para hacer la funcionalidad que necesito, usaré los llamados complementos para recetas, que se encuentran en archivos con la extensión .bbappend
en el archivo .bbappend, puede agregar sus propias llamadas de comando para el método de receta de compilación normal, por ejemplo, al método do_configure, do_compile, do_install, etc.

Estructura de la capa


 ├── COPIA.MIT
 ├── metaberserk
 │ ├── conf
 │ │ └── layer.conf
 │ ├── recetas-enloquecidas
 │ │ ├── bs-net
 │ │ ├── primera carrera
 │ │ ├── imágenes
 │ │ └── tv
 │ ├── recetas-núcleo
 │ │ ├── init-ifupdown
 │ │ └── psplash
 │ ├── recetas-kernel
 │ │ └── linux
 │ ├── recetas-mediacentre
 │ │ ├── kodi
 │ │ └── complementos kodi
 │ └── recetas-multimedia
 │ └── ffmpeg
 ├── README.md
 └── changelog.txt


Composición de la capa:

  • conf - configuración de capa
  • recetas-berserk - recetas de compilación de distribución, tv, red y recetas de primer lanzamiento
  • recetas-núcleo - recetas básicas, en particular una modificación a la receta de inicio
  • recipes-kernel - recetas de compilación del kernel de Linux
  • recipes-mediacentre - recetas para construir Kodi y sus complementos
  • recetas-multimedia - recetas multimedia, montaje ffmpeg

configuración de capa


incluye archivo 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%"


El archivo contiene una indicación de la versión de la biblioteca ffmpeg, el número de versión del kernel de Linux, así como el número de consolas virtuales (tty), e incluye las características del kit de distribución - wifi x11
DISTRO_FEATURES_append + = "wifi x11"

PREFERRED_VERSION_ffmpeg = "3.1.11"
SYSVINIT_ENABLED_GETTYS = "1"

PREFERRED_VERSION_linux-raspberrypi? = "4.9%"

composición de recetas-berserk


 ├── bs-net
 │ └── bs-net_0.1.3.bb
 ├── primera carrera
 │ ├── archivos
 │ │ └── first-run.sh
 │ └── first-run.bb
 ├── imágenes
 │ └── berserk-image.bb
 └── tv
     ├── archivos
     │ └── berserk.m3u8
     ├── tv-config.bb
     └── tv-dir.inc


donde:

  • bs-net_0.1.3.bb: receta para construir extensiones de shell para interfaces WLAN / Ethernet
  • first-run.bb: receta para la primera ejecución, partición de disco adicional
  • first-run.sh: script de shell de la primera ejecución (ejecución en el nivel de ejecución S)
  • berserk-image.bb - receta para construir la imagen de distribución
  • tv-config.bb - receta para configurar canales de TV usando IPTV
  • berserk.m3u8 - configuración de canales de televisión pública (formato m3u8)

composición de recetas


 ├── init-ifupdown
 │ ├── archivos
 └── │ └── interfaces
 │ └── init-ifupdown_1.0.bbappend
 └── psplash
     ├── archivos
     │ └── psplash-berserk-img.h
     └── psplash_git.bbappend


donde:

  • interfaces: archivo con la configuración de red actual
  • init-ifupdown_1.0.bbappend - extensión para la receta de configuración de red
  • psplash-berserk-img.h: imagen del protector de pantalla de inicio
    archivo de encabezado obtenido con la utilidad gdk-pixbuf-csource
  • psplash_git.bbappend: extensión de la receta para iniciar el protector de pantalla de inicio

La configuración de red en el dispositivo de destino está en el archivo:

 /etc/network/interfaces

Después de agregar la extensión de la receta init-ifupdown, reemplazo el archivo de configuración normal por el mío y cambio el orden (prioridad) de la ejecución del script para los niveles de ejecución

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

Por el momento, casi todas las distribuciones modernas de Linux incluyen una pantalla de inicio. Normalmente, el protector de pantalla de inicio muestra el estado actual de la descarga, es decir Indicador del tiempo transcurrido desde que se inició el sistema. En este sentido, Yocto no es una excepción y puede cambiar la imagen del protector de pantalla de inicio estándar a una imagen arbitraria.

Para hacer esto, debes:

  1. FILESEXTRAPATHS_prepend - agrega directorio para recursos
  2. SRC_URI: agrega un archivo de encabezado con una imagen arbitraria
  3. SPLASH_IMAGES - cambia la variable de control del paquete

y además en la receta de la imagen "berserk-image.bb" es necesario agregar la imagen de inicio de bienvenida como las características de la imagen

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

composición de recetas-kernel


 └── linux
     ├── archivos
     │ ├── db.txt.patch
     │ └── rbpi.cfg
     └── linux-raspberrypi_4.9.bbappend


donde:

  • db.txt.patch: parche con la base de dominio regulatorio (utilizada para WiFi)
  • rbpi.cfg: fragmento de configuración del kernel de Linux
  • linux-raspberrypi_4.9.bbappend - extensión de la receta de compilación del kernel 4.9 para Raspberry Pi

Los dispositivos Wi-Fi funcionan a ciertas frecuencias y para ellos existe un dominio regulador: este es el parámetro que indica el país en el que se supone que este dispositivo debe funcionar.

El kernel de Linux tiene una base de datos complementaria en la que se registran las frecuencias permitidas y la potencia permitida para cada país.

En el caso más simple, esta base de datos se puede incluir directamente en el núcleo de forma estática especificando un parámetro:
CONFIG_CFG80211_INTERNAL_REGDB = y
que es exactamente lo que hice al conectar un parche con esta base de datos db.txt.patch

Y una cosa más: en Yocto existen fragmentos de configuraciones de kernel. Por lo general, un fragmento de configuración, un archivo con la extensión cfg, contiene solo los parámetros del núcleo que claramente necesita para ciertos fines. Y esta pieza de configuración se agrega a los parámetros predeterminados que ya están presentes en la receta al construir el núcleo.

Además de la receta bbappend, también puede cambiar los parámetros que se pasan al núcleo durante el inicio:

es decir anular variable
CMDLINE ver archivo linux-raspberrypi_4.9.bbappend

contenido 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

donde:

  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


donde:

  • 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 codificar / decodificar una gran cantidad de formatos de video y audio. FFmpeg admite casi 400 códecs (ffmpeg -codecs)
y más de 300 formatos (ffmpeg -formats).

Kodi Build Recipe Addition


La capa OpenEmbedded contiene una receta regular para construir Kodi, pero es bastante general, y me gustaría obtener una versión un poco más estable y probada para la plataforma Raspberry Pi.

Los desarrolladores de software tienen un parche de puerto inverso. El software se actualiza constantemente y cada nueva versión incluye nuevas funciones y la corrección de errores conocidos. El parche de transferencia inversa le permite transferir algunos de los cambios en la nueva versión del programa a una anterior, lo que lo hace más estable. Pero este es un trabajo muy duro y meticuloso, que siempre se lleva a cabo por un gran número de desarrolladores.

En el mundo de la comunidad OpenSource, hay varios proyectos conocidos que usan Kodi, el mejor de los cuales (en mi opinión) es LibreElec (OpenElec). LibreElec tiene una buena compilación para la plataforma Raspberry Pi. Aquí lo tienen y es mejor tomar el parche de puerto inverso para Kodi. Por lo tanto, puede deshacerse de una gran cantidad de problemas sin siquiera saberlo.

El centro multimedia Kodi se centra en reproducir el contexto de "Medios", y en mi opinión, el componente más crítico es la combinación de Kodi y FFmpeg, es decir. interacción de ciertas versiones de estos programas, se pueden dejar otras bibliotecas de las capas Yocto y OpenEmbedded.

Para el ensamblaje, tomé la versión estable de Kodi 17.6 y la versión 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


El archivo de descripción de versión incluido será tal kodi-version.inc

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

La rama Yocto y OpenEmbedded que estoy considerando - rocko , contiene Kodi versión 17.3, y para actualizar a la versión 17.6, simplemente agregue una pequeña adición a la receta - 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"

La opción de compilación "--enable-optical-drive" le permite conectar el conveniente mecanismo de notificación que Kodi usa al conectar un disco óptico. En este caso, el módulo MediaManager (a) (xbmc / storage / MediaManager.cpp) supervisa la conexión / desconexión de nuevas particiones de disco y muestra un mensaje emergente al respecto.

udev ejemplo de conectar / desconectar unidades:

 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    -  )       .

Agregar un nuevo elemento al menú de configuración de Kodi


En Kodi 17.6, los archivos de configuración xml son responsables de mostrar los elementos del menú. Para agregar un elemento más en el menú "Configuración", simplemente ajuste el archivo:
kodi / addons / skin.estuary / xml / Settings.xml

donde skin.estuary es el tema de diseño de menú predeterminado, la

descripción del elemento se ve así:

<item>
    <label> $ LOCALIZE [13279] </label>
    <onclick> RunAddon (script.berserk.network, butnetwork) </onclick>
    <icon> icons / settings / bs-network.png </icon>
</item>


donde:

etiqueta - nombre del elemento del menú
onclick - manejo del evento de presionar el botón de menú
(iniciar el complemento, con el primer argumento pasando la cadena "butnetwork")
icono - icono del elemento del menú (ruta a la imagen png)

La funcionalidad anterior, así como la conexión de varios complementos adicionales de Kodi, se integra con utilizando el archivo 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>


Configuración máxima de almacenamiento en búfer para video


En el Centro multimedia Kodi, para maximizar el rendimiento, puede especificar la configuración máxima de almacenamiento en búfer:

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

buffermode = 1
: solicitudes de almacenamiento intermedio para todos los sistemas de archivos (incluido el

factor de lectura local)
: ajusta la velocidad de descarga en función de la tasa de bits de video promedio. Entonces, por ejemplo, si reproduce un video con una velocidad de transferencia de datos promedio de 5 Mbit / sy establece la relación de lectura del búfer en 2.0, esto limitará la velocidad de descarga (y, por lo tanto, la velocidad de llenado de caché) a aproximadamente 10 Mbit / s, por lo tanto:

readfactor = 20
elimina la restricción en la velocidad de descarga

memorysize = 139460608
: el tamaño del búfer es 133 MB, mientras se usa 133 * 3 RAM, es decir alrededor de 400 MB de RAM

Mirar televisión por IPTV


Kodi Media Center es una herramienta muy poderosa para ver contenido digital.

La función principal para la que recopilé "Media Center" es la función de mirar televisión digital usando IPTV (Internet Protocol Television), es decir televisión a través del protocolo de internet. Con esta función, puede ver televisión digital desde su proveedor de Internet.

Esta es la opción más moderna y óptima tanto en términos de calidad de imagen como en términos de características adicionales, es decir Servicios prestados. Por ejemplo, se pueden proporcionar canales de televisión en el archivo, en el que la grabación de video deseada está disponible por algún tiempo después de la transmisión.

Para admitir IPTV en Kodi, hay varias opciones de complemento, de las cuales me decidí por el complementopvr.iptvsimple

Para compilar el complemento, use la receta:

    └── complementos kodi
        └── kodi-pvr-iptvsimple.bb


El complemento se conecta / configura a través de:
Menú principal de Kodi => “Complementos” => “Mis complementos” => “Clientes PVR” => “PVR IPTV Simple Client”

Para verificar el funcionamiento de la televisión IPTV como parte de Kodi, tomé varios canales de noticias públicas y los agregó a la lista en formato m3u8, y también activó el inicio automático del complemento "pvr.iptvsimple" al inicio del centro de medios.

Mirar Youtube con el complemento Kodi


Los programadores que desarrollaron Kodi proporcionaron la flexibilidad para expandir sus funciones. Esto se hace para que cualquier entusiasta, si lo desea, pueda agregar a Kodi lo que realmente necesita. Y estos complementos para Kodi son oscuridad. Bueno, entiendes el punto.Hay tantos de ellos que merece una descripción en un artículo separado.

Los complementos se instalan de manera muy simple, solo conecte Kodi a Internet y presione un par de botones en el menú. Puedes leer sobre esto en cualquiera de los foros dedicados a Kodi. Pero el ensamblaje, está el ensamblaje, e incluiré un complemento más en el kit de distribución como ejemplo.

El complemento más interesante y extendido (ohm) para Kodi en mi opinión es el complemento de vista de Youtube. Kodi es un centro multimedia y Youtube es el repositorio más grande de este contenido muy multimedia, por lo que el complemento de Youtube para Kodi es casi obligatorio.

El complemento está escrito en python, y este es un mecanismo de complemento normal, no necesita compilar nada, solo copie el complemento terminado en el directorio raíz con los complementos y especifique el nombre del complemento en el archivo de manifiesto xml:
"System / addon-manifest.xml"

El complemento se toma del repositorio oficial y su código fuente se incluye en el archivo:
recipes-mediacentre / kodi-plugins / files / plugin.video.youtube.tar.gz Consulte la

ubicación de la receta de ensamblaje del complemento en capítulo "composición recetas-mediacenter"

Extensión de configuración de red de consola


Dado que el kit de distribución ensamblado en el marco de este artículo es una demostración, los requisitos para configurar "Interfaces de red" son mínimos. No quería arrastrar a ningún administrador de red pesado para esto, lo cual era muy incomprensible para mí y muy engorroso, y por lo tanto escribí dos scripts de shell que complementan la configuración del mecanismo de configuración 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 las interfaces de red Ethernet / WLAN a través de la GUI, utilizo otro pequeño complemento de Kodi "script.berserk.network". Este es casi el único complemento de Kodi que descubrí, pero para esto tuve que escribirlo. Es extremadamente compacto y minimalista y está escrito en lenguaje python.

Ambos componentes se recopilan mediante recetas:

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

En este punto, me gustaría detenerme en los detalles. Entonces, toda la flexibilidad de usar Yocto reside en diferentes conjuntos de recetas, es decir conectó un conjunto de recetas: el administrador de red más simple se agregó al kit de distribución, conectó otro conjunto, agregó su administrador de red favorito usando, por ejemplo, systemD, etc.

Para conectarse automáticamente a un punto de acceso WiFi cuando se inicia el sistema, utilizo la regla 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"

El script wlan-runner simplemente ejecuta los comandos:
/ etc / network / wlan $ IFACE up
o
/ etc / network / wlan $ IFACE abajo

Receta de construcción de distribución


El Proyecto Yocto tiene un mecanismo de reutilización. Hay clases de las que puede heredar (directiva "heredar"), y hay recetas básicas que puede conectar (directiva "incluir"). Mostraré la

herencia usando el ejemplo de clase:
poky / meta / clasess / core-image.bbclass

La clase es responsable de describir los grupos de paquetes que puede incluir en una receta en particular. Para hacer esto, es suficiente indicar la construcción al comienzo de la receta:
heredar core-image

Incluso en el texto de esta clase puede ver las características de la imagen, cada característica es responsable de un grupo de funciones incluidas en la imagen, y cada grupo finalmente describe un conjunto de programas o bibliotecas instalados.

Las características de la imagen se indican de la siguiente manera:

 IMAGE_FEATURES += "ssh-server-dropbear splash"

También hay DISTRO_FEATURES: características de distribución que se pueden especificar en el archivo de configuración de capa. Estas son funciones de nivel de distribución, y si, por ejemplo, cambia alguna característica (por ejemplo, x11), el ensamblaje posterior comenzará a reensamblar todos los paquetes que dependen de esta opción (esto puede llevar bastante tiempo).

La receta básica básica que uso es:
poky / meta / recipes-core / images / core-image-minimal.bb

receta de construcción de imagen
  # 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} \ "



Me gustaría aclarar que, por ejemplo , el paquete kernel-modules instalará
todos los módulos kernel especificados en el archivo defconfig en la imagen de distribución.

Pero si personaliza fuertemente algo, entonces, por supuesto, es posible que ni siquiera necesite todos los módulos del kernel, en cuyo caso es conveniente agregar cada módulo por nombre, como se indica en la variable BS_WLAN , es como una hoja de trucos, especifique solo lo que necesita y después de verificar el paquete "Kernel-modules" eliminar, verificar, etc.

Una breve guía para crear una imagen de distribución


1) Instale las dependencias del Proyecto Yocto en 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) Descargue e instale Repo:
  mkdir ~/bin curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo chmod a+x ~/bin/repo


3) Descargue el proyecto desde 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) Construye el proyecto:
  ./shell.sh bitbake berserk-image


5) Escriba la imagen de distribución en la tarjeta de memoria:

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


Postdata


Las capacidades de OpenSource en los últimos años solo están aumentando.

Pero estas oportunidades no son pequeñas, por ejemplo, ni siquiera tiene que ir muy lejos. Es poco probable que el mismo "Microsoft" esperara que la tecnología OpenSource la arrojara del mercado de sistemas operativos móviles. Me refiero al sistema operativo de Google: "Android", que durante la noche arrojó al "Pionero" de los sistemas móviles al margen. Y no está claro si Microsoft podrá volver a él nuevamente.

Por supuesto, "Google", una gran corporación con finanzas casi ilimitadas y excelentes desarrolladores, pero aún así, como dicen "sin Core y no aquí y allá".

Los mejores proyectos OpenSource con el tiempo se convierten en una obra de arte (por ejemplo, Kodi, Openelec / libre, etc.)

Y hoy, cualquiera puede unirse a las mejores prácticas en OpenSource, por así decirlo, sin salir de Github (a). Este artículo es sobre eso.

Tenga muchas asambleas buenas y diferentes para usted, y recuerde "el mundo de Internet de las cosas se acerca".

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

More articles:


All Articles