Multimedia Center "Kodi" und Yocto Project

Einführung in das Yocto-Projekt

Yocto Project ist ein kollaboratives Open Source-Projekt zur Vereinfachung der Entwicklung von Distributionen für eingebettete Systeme. Yocto enthält eine große Anzahl von Vorlagen, Metadaten und Build-Tools. In Yocto Project können Sie eine große Anzahl von BSP-Schichten (Platform Support Package) für alle Arten von Hardwareplattformen verbinden.

Der Hauptzweck des Artikels ist der Versuch, die Zusammenstellung eines typischen Distributionspakets im Yocto-Projekt am Beispiel des bekannten Multimedia-Centers Kodi, Version 17.6, für einen Raspberry Pi 3B-Computer mit einer Karte zu zeigen.

Wenn Sie sich irgendwo tief in Ihrer Seele als Sammler fühlen, sich aber noch nicht entschieden haben, was Sie sammeln möchten, dann ist dieser Artikel für Sie. Wenn Sie das Yocto-Projekt bereits in Ihrer täglichen Arbeit verwenden, können Sie durch diesen Artikel scrollen. Gehen Sie direkt zum letzten Kapitel und machen Sie sich bereit.

Der Artikel ist rein praktisch und zeigt die Möglichkeit, die Erfolge des Yocto-Projekts und von OpenEmbedded für den Aufbau des Multimedia-Centers "Kodi" zu nutzen. Yocto-Ebenen werden mit dem Repo-Dienstprogramm von Google verwaltet. Ein Artikel im Dokument dieser Reihe.

Also: lass uns gehen.

Inhalt:

Installieren Sie Yocto Project unter Ubuntu
Distributions-Build- Engine in Yocto Project
Verwenden von OpenEmbedded mit dem Yocto-Projekt
Platform Support Package (BSP)
Verwalten Sie Yocto-Ebenen mit Repo
Installieren Sie Repo
Verteilungserstellungsmanifest
Manifestierter Inhalt
Manifest Beschreibung
Bs-Manifest- Struktur
Poky-Variablen initialisieren
Repo- Initialisierung
Repo Sync
Erstellen einer Yocto-Projektkonfiguration
Konfigurationsdatei build / conf / local.conf
Konfigurationsdatei build / conf / bblayers.conf
Ebene zum Zusammenbau eines Multimedia-Centers
Schichtstruktur
Ebenenkonfiguration
Zusammensetzung der Rezepte-Berserker
Zusammensetzung des Rezeptkerns
Zusammensetzung des Rezeptkerns
Kompositionsrezepte -Medienzentrum
Zusammensetzung der Rezepte-Multimedia
Kodi Build Rezept Ergänzung
Hinzufügen eines neuen Elements zum Kodi-Einstellungsmenü
Maximale Puffereinstellungen für Video
Fernsehen über IPTV
Youtube mit dem Kodi Plugin ansehen
Konsolen- Shell-Netzwerkkonfigurationserweiterung
Verteilungserstellungsrezept
Eine kurze Anleitung zum Erstellen eines Verteilungsimages
Nachtrag

Installieren Sie Yocto Project unter Ubuntu

Um die Distribution mit dem Yocto Project unter Ubuntu zu erstellen, müssen Sie die folgenden Pakete installieren:

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 

Pakete werden mit dem Befehl apt-get install und dem Befehl skalo zur Eskalation von Berechtigungen installiert . Im Ubuntu-System ist dies eine weit verbreitete Praxis, wenn der Befehl sudo zum Ausführen von Verwaltungsaktionen verwendet wird (beim Erstellen des Hauptbenutzers des Systems wird er automatisch in der sudo-Gruppe registriert).

Detaillierte Installationsanweisungen finden Sie hier:

Distributions-Build-Engine in Yocto Project

Im Yocto-Projekt wird jede Programmeinheit anhand eines Montagerezeptes beschrieben. Die Rezeptbeschreibungssprache ähnelt "bash" mit der Möglichkeit, Codeteile in die Python-Sprache einzufügen. Grundlegende Syntaxinformationen finden Sie im Yocto Project-Handbuch . Je nach Verwendungszweck kann eine Reihe von Baugruppenrezepten zu separaten Montageschichten kombiniert werden.

Die Ebenen sind in hardwareabhängige Ebenen unterteilt: BSP-Ebenen, UI-Ebenen (Benutzeroberfläche), bestimmte Yocto-Ebenen sowie Ebenen, die bestimmte Funktionen implementieren:
B. Ebenen von OpenEmbedded => Multimedia, Python, Perl, Ruby, Networking, Systemd, Webserver usw.

Verwenden von OpenEmbedded mit dem Yocto-Projekt

Wenn Sie jedoch das Yocto-Projekt verwenden, benötigen Sie mit Sicherheit Ebenen mit zusätzlichen Funktionen, d. H. Eine große Auswahl an Rezepten für alle Gelegenheiten. Und es gibt so ein Set - das sind Rezepte von OpenEmbedded. OpenEmbedded ist eine Infrastruktur zum Erstellen von Paketen für Embedded Linux.

OpenEmbedded ist vollständig kompatibel mit dem Yocto-Projekt, da dieses Projekt als Grundlage für das Yocto-Projekt verwendet wurde. Vielleicht hat das Yocto-Projekt deshalb etwas bessere Stabilität, bessere Dokumentation und etwas besseren Support (aber im Grunde ist es immer noch dasselbe OpenEmbedded).

Platform Support Package (BSP)

Das Board Support Package ist eine separate, spezialisierte Schicht (en) für eine bestimmte Karte, die die Hardwarefunktionen der Plattform definiert, d. H. implementiert die spezifischen Dinge, die eine Karte von einer anderen unterscheiden: Prozessorfunktionen, Interrupts, Adressierung, Bootloaderfunktionen, Videoadapterfunktionen (GPU) usw.

Dieser Artikel verwendet die BSP-Schicht - meta-raspberrypi
Das Layer-Repository befindet sich unter: git.yoctoproject.org/git/meta-raspberrypi

Verwalten Sie Yocto-Ebenen mit Repo

Yocto Project kann eine große Anzahl von Ebenen von verschiedenen Lieferanten - Geräteentwicklern - verwenden, und all dies muss irgendwie verwaltet werden. Stellen Sie sich vor, Sie haben ein Dutzend verschiedene Boards und jedes Board verfügt über ein separates BSP-Git-Repository. Dies berücksichtigt nicht die Infrastruktur des Yocto-Projekts selbst sowie mögliche zusätzliche Funktionen von OpenEmbedded.

In einer solchen Situation kommen Sie nicht mit einem separaten einfachen Installationsskript davon. Willy-nilly, muss nach Werkzeugen suchen, die es gut können. Noch mehr als gut. Eines der besten Tools dieser Art ist das Google-Dienstprogramm Repo.

Repo ist das Hauptwerkzeug zum Verwalten von GIT-Repositorys beim Erstellen des Android-Betriebssystems mit seiner großen Codebasis. Mit Repo können Sie ein Dutzend, wenn nicht hundert separate Git-Repositorys in einem Projekt verwalten, deren Versionen Sie sorgfältig in einer XML-Datei des Manifests angeben können

und für die korrekte Synchronisation aller Versionen aller Repositorys müssen Sie nur einen Befehl ausführen

Repo-Synchronisierung

Installieren Sie Repo

Mit den folgenden Befehlen können Sie Repo in Ihrem ~ / bin -Ausgangsverzeichnis installieren
(Der Befehl curl kann separat installiert werden: 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 

und in Zukunft müssen Sie nur noch den Befehl in der Konsole verwenden: repo

oder so
Wenn das Verzeichnis HOME / bin nicht automatisch mit dem Standardstartpfad hinzugefügt wird
siehe Datei HOME / .profile

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

Verteilungserstellungsmanifest

Die im Rahmen des Artikels gesammelte Distribution muss ich so nennen. Lass es der Name Torvin sein . Mit dem Codenamen Torvin wird es eine minimalistische Linux-Distribution mit einem einzigen Programm enthalten. Dies bezieht sich auf ein Anwendungsbenutzerprogramm - Kodi und nichts weiter (alles andere ist eine Systemebene). Für ein Multimedia-Center ist dies meiner Meinung nach völlig ausreichend.

Manifestierter Inhalt

Die Datei torvin-0.2.5.xml wird zum Verwalten von Verteilungsebenen verwendet .

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

Manifest Beschreibung

Zu Beginn des Manifests bezeichnen Remote- Tags zwei Haupt-GIT-Repositorys und ein Hilfs-Repository:

https: ⁄⁄git.yoctoproject.org / git - Yocto-Repository mit dem Namen yocto
https: ⁄⁄github.com / openembedded - OpenEmbedded-Repository mit dem Namen oe
https: ⁄⁄github.com / berserktv - Hilfs-GIT-Repository mit dem Namen bs

Im nächsten Teil des Manifests arbeiten wir mit abgekürzter Benennung mit Projekten, die sich in diesen Repositorys befinden. Das Projekt- Tag enthält die folgenden Attribute:

remote - Der Name des Remote-Repositorys
Revision - Der Name des Zweigs oder der Hash-Version
name - Name des Projekts im angegebenen Repository
Pfad - Der lokale Projektpfad in Ihrem Dateisystem

    <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 

Im Hauptteil des Projekt- Tags habe ich Befehle zum Erstellen symbolischer Links zur Infrastruktur von Hilfsskripten für die Erstinitialisierung und den regelmäßigen Start des von mir benötigten Poky- Build-Systems angegeben

    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 

Bs-Manifest-Struktur

 ├── COPYING.MIT
 ├── Himbeere
 │ ├ rocko
 │ │ ├── conf
 Bl │ │ ├ bblayers.conf
 │ │ │ └ local.conf
 Vin │ └ torvin-0.2.5.xml
 │ └ shell.sh
 ├── README.md
 └── Setup-Umgebung

Das bs-manifest- Projekt wird für ein flexibles Konfigurationsmanagement verwendet, wobei die Assemblys verschiedener Versionen der Distribution berücksichtigt werden. Ich habe diese Version - 0.2.5

Poky-Variablen initialisieren

Die Setup-Umgebung für das Initialisierungsskript wurde aus dem Freescale Community-Projekt übernommen (in der Yocto-Umgebung ist dies eine gängige Lösung). Das Skript ist für die Initialisierung der Variablen des Poky-Build-Systems verantwortlich. Das Skript erstellt eine Verzeichnisstruktur, in die es sehr gut unterteilt ist:

• build - Build- Verzeichnis
• Quellcode für Assembly-Assembly-Rezepte
• download - Verzeichnis zum Herunterladen von Programmcode (Git-Datenbanken, tar.gz-Archive)

Der Inhalt des Setup-Umgebungsskripts kann hier angezeigt werden:


Dieses Root-Skript dient zum Initialisieren der Konfigurationsvariablen der Build-Umgebung und wird normalerweise zu Beginn einer Sitzung aufgerufen.

Repo-Initialisierung

Um Repo zu initialisieren, müssen Sie den folgenden Befehl ausführen:

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

Dabei teilt -u https: ⁄⁄github.com / berserktv / bs-manifest GIT den Pfad zum Manifestprojekt mit

Hinweis: Sie können auch -b Baumname angeben
(Wenn Sie den Schalter -b nicht angeben, wird der Hauptzweig angenommen (standardmäßig))

Dabei gibt der Pfad -m Himbeere / Rocko / Torvin-0.2.5.xml zur Konfigurationsdatei Folgendes an:

1. Der Name der Hardwareplattform, für die die Montage ausgeführt wird - Himbeere
2. Der Name des Hauptarbeitszweigs von Yocto / OpenEmbedded lautet rocko
3. Der Codename der Version lautet torvin (alle Versionen der 0.2.x-Serie)
4. Die digitale Versionsnummer, die zusammengebaut wird, ist 0.2.5

Repo Sync

Führen Sie zum Booten oder anschließende Synchronisieren einfach den folgenden Befehl aus:

 repo sync 

Wenn Sie im Revisionsattribut einen Hash-Commit- oder Tag-Namen haben, ändert sich die Version für dieses Git-Repository nicht. Dabei werden alle neuesten Versionen von GIT-Projekten abgerufen, die in der Manifestdatei angegeben sind (Zweige werden normalerweise angegeben). Der Tag-Name kann wie folgt angegeben werden: revision = "refs / tags / v0.2.5"

Erstellen einer Yocto-Projektkonfiguration

Nachdem der Befehl repo sync ausgeführt wurde, können Sie mit der Erstellung der Hauptkonfiguration des Yocto-Projekts beginnen:

 ./shell.sh 

Nach Abschluss des Skripts wird das Verzeichnis build / conf erstellt:
mit zwei Hauptdateien:

• local.conf - Assembly- Steuervariablen :
  Plattformname, Art der Verteilung und Build-Pakete usw.
• bblayers.conf - Konfiguration der verbundenen Ebenen des Yocto-Projekts

Standardmäßig sucht das Setup-Umgebungsskript nach source / base / conf
Erstkonfiguration und wenn local.conf und bblayers.conf Dateien
existieren, werden sie nach build / conf kopiert
(Siehe die Variable TEMPLATES in der Setup-Umgebung.)

d.h. Dateien stammen aus den Quellen / bs-manifest / raspberry / rocko / conf
Siehe Erstellen eines Symlinks zur Basis

Konfigurationsdatei build / conf / local.conf

Konfigurationsdatei build / conf / bblayers.conf

Die Hauptvariablen der Datei local.conf, auf die Sie achten müssen:

• MASCHINE - der Name der Plattform, unter der die Montage durchgeführt wird
• DISTRO - Name der Verteilungskategorie
• PACKAGE_CLASSES - Paketformat für die Installation von Software
• LICENSE_FLAGS_WHITELIST - Verwendung zusätzlicher Lizenzen

Spezifische Einstellungen für die Raspberry Pi-Board-Familie

• GPU_MEM = "128" - Die Größe des Videospeichers für den GPU-Videoadapter (aus dem RAM zugewiesen)
• GPU_MEM_256 = "112" - das gleiche gilt nur für Karten mit einer Gesamt-RAM-Größe von 256 MB
• GPU_MEM_512 = "160" - das gleiche gilt nur für Karten mit einer Gesamtspeichergröße von 512 MB
• GPU_MEM_1024 = "320" - Gleiches gilt nur für Karten mit einer Gesamt-RAM-Größe von 1024 MB

Hinweis:
Wenn Sie beispielsweise nur die Variable GPU_MEM = "128" belassen,
dann für alle RPI-, RPI2-, RPI3-Karten
unabhängig von der Menge des realen RAM
auf der Karte wird immer für die GPU zugewiesen - 128Mb
(und die gesamte RAM-Größe nimmt um diesen Wert ab)

Wenn alle Variablen angegeben sind, haben die Anweisungen GPU_MEM_256, GPU_MEM_512, GPU_MEM_1024 höhere Priorität.

Informationen zum Zusammenstellen des Multimedia-Centers finden Sie zusätzlich zu den regulären Yocto-Ebenen in der Datei bblayers.conf

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

Ich habe vier Ebenen mit zusätzlichen Funktionen von OpenEmbedded verbunden.

Kodi Multimedia Center - ist ein komplexes Programm, das eine große Anzahl externer Bibliotheken verwendet. Sie müssen jede Bibliothek mit einem Build-Rezept erstellen. Wenn möglich, verwende ich daher alle Rezepte von OpenEmbedded in der Kategorie Multimedia

Ich habe also eine Multimedia-Ebene angeschlossen und die Ebenen, von denen es abhängt

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

Dann wird eine weitere OpenEmbedded-Ebene verbunden, um mit Dateisystemen zu arbeiten

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

Außerdem wurde die BSP-Hauptschicht für die Raspberry Pi-Plattform verbunden

 ${BSPDIR}/sources/meta-raspberrypi \ 

Nun, ganz am Ende ist eine zusätzliche Ebene verbunden, die für die Zusammenstellung des Verteilungsbildes mit der Funktionalität des "Multimedia Centers" verantwortlich ist.

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

Ebene zum Zusammenbau eines Multimedia-Centers

Meiner Meinung nach ist das Yocto-Projekt ein industrieller Mähdrescher zur Erstellung eingebetteter Distributionen. Wenn Sie jedoch jemals mit dem Buildroot-Build-System gearbeitet haben, erscheint Ihnen Yocto möglicherweise umständlich. Es verwendet eine große Menge an freiem Festplattenspeicher. Für den normalen Betrieb benötigt Yocto etwa 80 bis 100 GB freien Speicherplatz. Dabei wird normalerweise die Baugruppe nur für eine Plattform berücksichtigt.

Yocto erfüllt seinen Hauptzweck - die Unterstützung möglichst vieler verschiedener Hardwareplattformen. Dies erfordert den flexibelsten Mechanismus zum Wechseln von Baugruppen. Und dieser Mechanismus braucht Zeit und Ort. Das Erstellen einer Distribution in Yocto ist kein schneller Prozess.

Alle Funktionen zum Zusammenstellen des "Multimedia Centers" habe ich mit einer separaten Ebene:

 https://github/berserktv/berserk 

(Titel aus meinem Lieblingsbuch, Der Hammer und das Kreuz, von Harry Harrison.)
(Torvin ist auch eine Figur in diesem Buch.)

Um die Funktionalität zu erhalten, die ich benötige, verwende ich die sogenannten Add-Ons für Rezepte, die sich in Dateien mit der Erweiterung .bbappend befinden
In der .bbappend-Datei können Sie Ihre eigenen Befehlsaufrufe für die reguläre Build-Rezept-Methode hinzufügen, z. B. für die Methode do_configure, do_compile, do_install usw.

Schichtstruktur

 ├── COPYING.MIT
 ├── Meta-Berserker
 │ ├ conf
 │ │ └── layer.conf
 │ ├ Rezepte-Berserker
 │ │ ├ bs-net
 │ │ ├ erste Runde
 │ │ ├ Bilder
 │ │ └── tv
 │ ├ Rezepte-Kern
 │ │ ├ init-ifupdown
 │ │ └ psplash
 │ ├ Rezepte-Kernel
 │ │ └ Linux
 │ ├ Rezepte-Medienzentrum
 │ │ ├ kodi
 │ │ └ Kodi-Plugins
 │ └ Rezepte-Multimedia
 │ └ ffmpeg
 ├── README.md
 └── changelog.txt

Schichtzusammensetzung:

• Konfiguration der Konf - Schicht
• Rezepts -Berserker - Rezepte für die Erstellung von Distributionen, Fernsehern, Netzwerken und Erststarts
• Rezept -Kern - Grundrezepte, insbesondere eine Änderung des Startrezepts
• Rezepte-Kernel - Linux-Kernel-Build-Rezepte
• Rezepte-Medienzentrum - Rezepte zum Erstellen von Kodi und seinen Plugins
• rezepte-multimedia - multimedia rezepte, ffmpeg montage

Schichtkonfiguration

Die Datei enthält einen Hinweis auf die Version der ffmpeg-Bibliothek, die Versionsnummer des Linux-Kernels sowie die Anzahl der virtuellen Konsolen (tty) und enthält die Funktionen des Distributionskits - wifi x11

DISTRO_FEATURES_append + = "wifi x11"

PREFERRED_VERSION_ffmpeg = "3.1.11"
SYSVINIT_ENABLED_GETTYS = "1"

PREFERRED_VERSION_linux-raspberrypi? = "4,9%"

Zusammensetzung der Rezepte-Berserker

 ├── bs-net
 │ └── bs-net_0.1.3.bb
 ├── Erster Lauf
 │ ├ Dateien
 │ │ └── first-run.sh
 │ └ first-run.bb
 ├── Bilder
 │ └ berserk-image.bb
 └── Fernsehen
     ├── Dateien
     │ └ berserk.m3u8
     ├── tv-config.bb
     └── tv-dir.inc

wo:

• bs-net_0.1.3.bb - Rezept zum Erstellen von Shell-Erweiterungen für WLAN / Ethernet-Schnittstellen
• first-run.bb - Rezept für den ersten Lauf, zusätzliche Festplattenpartitionierung
• first-run.sh - Shell-Skript des ersten Laufs (auf Laufstufe S ausführen)
• berserk-image.bb - Rezept zum Erstellen des Distributionsimages
• tv-config.bb - Rezept zum Konfigurieren von TV-Kanälen mit IPTV
• berserk.m3u8 - Konfiguration öffentlicher Fernsehkanäle (m3u8-Format)

Rezept-Kernkomposition

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

wo:

• Schnittstellen - Datei mit der aktuellen Netzwerkeinstellung
• init-ifupdown_1.0.bbappend - Erweiterung für das Netzwerkkonfigurationsrezept
• psplash-berserk-img.h - Bild des Startbildschirmschoners
  Header-Datei, die mit dem Dienstprogramm gdk-pixbuf-csource abgerufen wurde
• psplash_git.bbappend - Erweiterung des Rezepts zum Starten des Startbildschirmschoners

Die Netzwerkkonfiguration auf dem Zielgerät befindet sich in der Datei:

 /etc/network/interfaces 

Nachdem ich die Erweiterung des Rezepts init-ifupdown hinzugefügt habe, ersetze ich die reguläre Konfigurationsdatei durch meine eigene und ändere die Reihenfolge (Priorität) des Skriptlaufs für die Ausführungsebenen

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

Derzeit enthalten fast alle modernen Linux-Distributionen einen Startbildschirm. In der Regel zeigt der Start-Bildschirmschoner den aktuellen Ladezustand an Anzeige der seit dem Systemstart verstrichenen Zeit. In dieser Hinsicht ist Yocto keine Ausnahme und Sie können das Bild des Standard-Start-Bildschirmschoners in ein beliebiges Bild ändern.

Dazu müssen Sie:

1. FILESEXTRAPATHS_prepend - Verzeichnis für Ressourcen hinzufügen
2. SRC_URI - Fügt eine Header-Datei mit einem beliebigen Bild hinzu
3. SPLASH_IMAGES - Paketsteuervariable ändern

und weiter im Bildrezept "berserk-image.bb" ist es notwendig, das Splash-Startbild als die Merkmale des Bildes hinzuzufügen

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

Zusammensetzung der Rezepte-Kernel

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

wo:

• db.txt.patch - Patch mit der Regulatory Domain-Basis (für WiFi verwendet)
• rbpi.cfg - Konfigurationsfragment des Linux-Kernels
• linux-raspberrypi_4.9.bbappend - Erweiterung des 4.9-Kernel-Build-Rezepts für Raspberry Pi

Wi-Fi-Geräte arbeiten mit bestimmten Frequenzen und für sie gibt es so etwas wie eine Regulierungsdomäne - dies ist der Parameter, der das Land angibt, in dem dieses Gerät arbeiten soll.

Der Linux-Kernel verfügt über eine Begleitdatenbank, in der die zulässigen Frequenzen und die für sie zulässige Leistung für jedes Land registriert sind.

Im einfachsten Fall kann diese Datenbank durch Angabe eines Parameters statisch direkt in den Kernel aufgenommen werden:
CONFIG_CFG80211_INTERNAL_REGDB = y
Genau das habe ich getan, indem ich einen Patch mit dieser Datenbank db.txt.patch verbunden habe

Und noch etwas: In Yocto gibt es Fragmente von Kernelkonfigurationen. Normalerweise enthält ein Konfigurationsfragment, eine Datei mit der Erweiterung cfg, nur die Kernelparameter, die Sie für bestimmte Zwecke eindeutig benötigen. Diese Konfiguration wird zu den Standardparametern hinzugefügt, die bereits beim Erstellen des Kernels im Rezept vorhanden sind.

Zusätzlich zum Rezept bbappend können Sie auch die Parameter ändern, die beim Start an den Kernel übergeben werden:

d.h. Variable überschreiben
CMDLINE siehe Datei linux-raspberrypi_4.9.bbappend

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 

wo:

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

wo:

• 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 - OpenSource-Bibliothek zum Codieren / Decodieren einer Vielzahl von Video- und Audioformaten. FFmpeg unterstützt fast 400 Codecs (ffmpeg-Codecs)
und über 300 Formate (ffmpeg-Formate).

Kodi Build Rezeptzusatz

Die OpenEmbedded-Ebene enthält ein reguläres Rezept zum Erstellen von Kodi, ist jedoch recht allgemein gehalten, und ich möchte eine etwas stabilere und getestete Version für die Raspberry Pi-Plattform erhalten.

Softwareentwickler haben so etwas wie einen Reverse-Port-Patch. Die Software wird ständig aktualisiert und jede neue Version enthält sowohl neue Funktionen als auch die Korrektur bekannter Fehler. Mit dem Patch für die umgekehrte Portierung können Sie einige der Änderungen in der neuen Version des Programms auf eine ältere Version übertragen, wodurch es stabiler wird. Dies ist jedoch eine sehr harte und sorgfältige Arbeit, die immer von einer großen Anzahl von Entwicklern ausgeführt wird.

In der Welt der OpenSource-Community gibt es mehrere bekannte Projekte mit Kodi, von denen das beste (meiner Meinung nach) LibreElec (OpenElec) ist. LibreElec hat einen guten Build für die Raspberry Pi-Plattform. Hier haben sie es und es ist am besten, den Reverse-Port-Patch für Kodi zu nehmen. So können Sie eine Vielzahl von Problemen loswerden, ohne etwas darüber zu lernen.

Das Kodi Multimedia Center konzentriert sich auf die Wiedergabe des "Medien" -Kontexts, und meiner Meinung nach ist die Kombination von Kodi und FFmpeg, d. H. Durch die Interaktion bestimmter Versionen dieser Programme können andere Bibliotheken aus den Ebenen Yocto und OpenEmbedded belassen werden.

Für die Montage habe ich die stabile Version von Kodi 17.6 und die Version FFmpeg 3.1.11 verwendet


Die mitgelieferte Versionsbeschreibungsdatei lautet kodi-version.inc

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

Der von mir in Betracht gezogene Zweig Yocto und OpenEmbedded - rocko - enthält Kodi Version 17.3. Um ein Upgrade auf Version 17.6 durchzuführen, fügen Sie dem Rezept einfach eine kleine Ergänzung hinzu - 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" 

Mit der Build-Option "--enable-optisches Laufwerk" können Sie den praktischen Benachrichtigungsmechanismus verbinden, den Kodi beim Anschließen einer optischen Festplatte verwendet. In diesem Fall überwacht das MediaManager-Modul (a) (xbmc / storage / MediaManager.cpp) das Verbinden / Trennen neuer Festplattenpartitionen und zeigt eine Popup-Meldung dazu an.

Beispiel für das Anschließen / Trennen von Laufwerken:

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

Hinzufügen eines neuen Elements zum Kodi-Einstellungsmenü

In Kodi 17.6 sind XML-Konfigurationsdateien für die Anzeige von Menüelementen verantwortlich. Um ein weiteres Element im Menü "Einstellungen" hinzuzufügen, passen Sie einfach die Datei an:
kodi / addons / skin.estuary / xml / Settings.xml

wobei skin.estuary das Standarddesign für das Menüdesign ist. Die Elementbeschreibung

sieht folgendermaßen aus:

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

wo:

label - Name des
Menüelements onclick - Behandlung des Ereignisses des Drückens der Menüschaltfläche
(Starten des Plugins, wobei das erste Argument die Zeichenfolge "butnetwork" übergibt)
Symbol - Symbol des Menüelements (Pfad zum PNG-Bild)

Die oben genannte Funktionalität sowie das Verbinden mehrerer zusätzlicher Kodi-Plugins sind in integriert Verwenden der Datei bs-menu.patch

Maximale Puffereinstellungen für Video

Um die Leistung zu maximieren, können Sie im Kodi Multimedia Center die maximalen Puffereinstellungen festlegen:

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

buffermode = 1
- Pufferanforderungen für alle Dateisysteme (einschließlich lokaler)

Lesefaktoren
- Passt die Download-Geschwindigkeit basierend auf der durchschnittlichen Video-Bitrate an. Wenn Sie beispielsweise ein Video mit einer durchschnittlichen Datenübertragungsrate von 5 Mbit / s

abspielen und das Pufferleseverhältnis auf 2,0 einstellen, wird die Download-Geschwindigkeit (und damit die Cache-Füllrate) auf etwa 10 Mbit / s begrenzt, also: readfactor = 20
hebt die Einschränkung der Download-Geschwindigkeit auf.

Memorysize = 139460608
- die Puffergröße beträgt 133 MB, während 133 * 3 RAM verwendet wird, d.h. ca. 400 MB RAM

Fernsehen über IPTV

Kodi Media Center ist ein sehr leistungsfähiges Tool zum Anzeigen digitaler Inhalte.

Die Hauptfunktion, für die ich "Media Center" gesammelt habe, ist die Funktion des digitalen Fernsehens mit IPTV (Internet Protocol Television), d. H. Fernsehen über das Internetprotokoll. Mit dieser Funktion können Sie von Ihrem Internetanbieter aus digitales Fernsehen schauen.

Dies ist die modernste und optimalste Option sowohl hinsichtlich der Bildqualität als auch hinsichtlich zusätzlicher Merkmale, d.h. erbrachte Dienstleistungen. Beispielsweise können Fernsehkanäle im Archiv bereitgestellt werden, in denen die gewünschte Videoaufzeichnung einige Zeit nach der Ausstrahlung verfügbar ist.

Um IPTV in Kodi zu unterstützen, gibt es mehrere Plugin-Optionen, von denen ich mich für das Plugin entschieden habepvr.iptvsimple

Verwenden Sie das Rezept, um das Plugin zu erstellen:

    └── Kodi-Plugins
        └── kodi-pvr-iptvsimple.bb

Das Plug-In ist verbunden über:
Kodi-Hauptmenü => "Add-Ons" => "Meine Add-Ons" => "PVR-Clients" => "PVR IPTV Simple Client"

Um den Betrieb des IPTV-Fernsehens als Teil von Kodi zu überprüfen, habe ich mehrere öffentliche Nachrichtensender verwendet und fügte sie der Liste im m3u8-Format hinzu und aktivierte auch den automatischen Start des Plugins „pvr.iptvsimple“ zu Beginn des Media Centers.

Youtube mit dem Kodi Plugin ansehen

Die Programmierer, die Kodi entwickelten, boten die Flexibilität, seine Funktionen zu erweitern. Dies geschieht, damit jeder Enthusiast auf Wunsch Kodi hinzufügen kann, was er wirklich braucht. Und diese Plugins für Kodi sind Dunkelheit. Nun, du verstehst, worum es geht.Es gibt so viele von ihnen, dass es eine Beschreibung in einem separaten Artikel verdient.

Plugins werden sehr einfach installiert. Verbinden Sie Kodi einfach mit dem Internet und drücken Sie einige Tasten im Menü. Sie können darüber in allen Foren lesen, die Kodi gewidmet sind. Aber die Assembly, da ist die Assembly, und ich werde ein weiteres Plugin als Beispiel in das Distributionskit aufnehmen.

Das meiner Meinung nach interessanteste und am weitesten verbreitete Plugin (Ohm) für Kodi ist das Youtube View Plugin. Kodi ist ein Multimedia-Center, und Youtube ist das größte Repository für diese Multimedia-Inhalte. Daher ist das Youtube-Plug-In für Kodi fast obligatorisch.

Das Plugin ist in Python geschrieben. Dies ist ein regulärer Plug-In-Mechanismus. Sie müssen nichts kompilieren. Kopieren Sie einfach das fertige Plug-In mit den Plug-Ins in das Stammverzeichnis und geben Sie den Namen des Plug-Ins in der XML-Manifestdatei an:
"System / addon-manifest.xml"

Das Plugin stammt aus dem offiziellen Repository und sein Quellcode ist im Archiv enthalten:
Rezepte-Medienzentrum / Kodi-Plugins / Dateien / Plugin.video.youtube.tar.gz Die

Position des Plugin-Build-Rezepts finden Sie oben Kapitel "Rezept-Medienzentrum Komposition"

Konsolen-Shell-Netzwerkkonfigurationserweiterung

Da es sich bei dem im Rahmen dieses Artikels zusammengestellten Distributionskit um eine Demo handelt, sind die Anforderungen für die Einrichtung von „Netzwerkschnittstellen“ minimal. Ich wollte dafür keinen schweren Netzwerkmanager ziehen, was für mich sehr unverständlich und sehr umständlich war, und deshalb habe ich zwei Shell-Skripte geschrieben, die die Konfiguration des regulären Konfigurationsmechanismus ergänzen:

 ############################################################## #     /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 

Um Ethernet / WLAN-Netzwerkschnittstellen bequem über die GUI zu konfigurieren, verwende ich ein weiteres kleines Kodi-Plugin „script.berserk.network“. Dies ist fast das einzige Kodi-Plugin, das ich herausgefunden habe, aber dafür musste ich es schreiben. Es ist extrem kompakt und minimalistisch und in der Python-Sprache geschrieben.

Beide Komponenten werden nach Rezepten gesammelt:

• Rezepte-Berserker / bs-net / bs-net_0.1.3.bb
• Rezepte-Medienzentrum / Kodi-Plugins / script-berserk-network_0.2.5.bb

An dieser Stelle möchte ich auf die Details eingehen. Die ganze Flexibilität bei der Verwendung von Yocto liegt also in verschiedenen Rezepten, d.h. Verbunden Sie einen Satz von Rezepten - der einfachste Netzwerkmanager wurde zum Verteilungskit hinzugefügt, ein anderer Satz verbunden - fügte Ihren bevorzugten Netzwerkmanager hinzu, indem Sie beispielsweise systemD usw.

Um beim Systemstart automatisch eine Verbindung zu einem WiFi-Zugangspunkt herzustellen, verwende ich die udev-Regel: /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" 

Das WLAN-Runner-Skript führt einfach die folgenden Befehle aus:
/ etc / network / wlan $ IFACE up
oder
/ etc / network / wlan $ IFACE down

Verteilungserstellungsrezept

Das Yocto-Projekt verfügt über einen Wiederverwendungsmechanismus. Es gibt Klassen, von denen Sie erben können (Direktive "erben"), und es gibt grundlegende Rezepte, die Sie verbinden können (Direktive "include").

Ich werde die Vererbung anhand des Klassenbeispiels zeigen:
poky / meta / clasess / core-image.bbclass

Die Klasse ist dafür verantwortlich, die Gruppen von Paketen zu beschreiben, die Sie in ein bestimmtes Rezept aufnehmen können. Zu diesem Zweck reicht es aus, die Konstruktion am Anfang des Rezepts anzugeben:
Kernbild erben

Selbst im Text dieser Klasse können Sie die Merkmale des Bildes sehen. Jedes Merkmal ist für eine Gruppe von Funktionen verantwortlich, die im Bild enthalten sind, und jede Gruppe beschreibt letztendlich eine Reihe installierter Programme oder Bibliotheken.

Merkmale des Bildes werden wie folgt angezeigt:

 IMAGE_FEATURES += "ssh-server-dropbear splash" 

Es gibt auch DISTRO_FEATURES - Verteilungsfunktionen, die in der Layer-Konfigurationsdatei angegeben werden können. Dies sind Funktionen auf Verteilungsebene. Wenn Sie beispielsweise eine Funktion ändern (z. B. x11), werden in der nachfolgenden Assembly alle Pakete wieder zusammengesetzt, die von dieser Option abhängen (dies kann ziemlich lange dauern).

Das grundlegende Grundrezept, das ich verwende, ist:
poky / meta / prescription-core / images / core-image-minimal.bb



Ich möchte klarstellen, dass das Kernel-Modul- Paket beispielsweise
alle in der defconfig-Datei angegebenen Kernel-Module in das Distributions-Image installiert .

Wenn Sie jedoch etwas stark anpassen, benötigen Sie möglicherweise nicht einmal alle Kernelmodule. In diesem Fall ist es praktisch, jedes Modul nach Namen hinzuzufügen, wie in der Variablen BS_WLAN angegeben . Es ist wie ein Spickzettel. Geben Sie nur das an, was Sie benötigen, und überprüfen Sie nach Überprüfung des Pakets "Kernel-Module" entfernen, prüfen usw.

Eine kurze Anleitung zum Erstellen eines Verteilungsimages

Nachtrag

Die Fähigkeiten von OpenSource in den letzten Jahren nehmen nur noch zu.

Aber diese Möglichkeiten sind nicht gering, zum Beispiel müssen Sie nicht einmal weit gehen. Es ist unwahrscheinlich, dass dasselbe "Microsoft" erwartet, dass die OpenSource-Technologie es vom Markt für mobile Betriebssysteme verdrängt. Ich meine das Betriebssystem von Google - "Android", das über Nacht den "Pionier" mobiler Systeme an den Rand gedrängt hat. Und es ist nicht klar, ob Microsoft wieder darauf zurückgreifen kann.

Natürlich "Google", ein riesiges Unternehmen mit nahezu unbegrenzten Finanzen und exzellenten Entwicklern, aber dennoch, wie sie sagen "ohne den Kern und nicht hier und da".

Die besten OpenSource-Projekte werden im Laufe der Zeit zu einem Kunstwerk (z. B. Kodi, Openelec / libre usw.)

Und heute kann jeder sozusagen an den Best Practices in OpenSource teilnehmen, ohne aus Github (a) herauszukriechen. Dieser Artikel handelt davon.

Haben Sie viele gute und unterschiedliche Baugruppen für sich und denken Sie daran, dass "die Welt des Internets der Dinge kommt".