Введение в Yocto Project

Yocto Project — это совместный Open Source проект для упрощения разработки дистрибутивов для встраиваемых систем. Yocto содержит большое количество шаблонов, метаданных и инструментальных средств сборки. В Yocto Project вы можете подключить большое количество BSP (пакет поддержки платформы) слоев для всевозможных аппаратных платформ.

Основное назначение статьи — это попытка показать сборку типового дистрибутива в Yocto Project на примере хорошо известного мультимедиа центра Kodi, версии 17.6 для одноплатного компьютера «Raspberry Pi» 3B.

Если где-то глубоко в душе вы чувствуете, что вы сборщик, но еще не решили, что бы вам такое пособирать, то эта статья для вас. Если же вы уже используете Yocto Project в своей повседневной работе, то можете эту статью пролистать. Сразу переходите к последней главе и соберитесь.

Статья является сугубо практической и демонстрирует возможности использования наработок Yocto Project и OpenEmbedded для сборки мультимедиа центра «Kodi». Управление слоями Yocto осуществляется с помощью утилиты Repo от Google. Статья из серии «Документируй это».

Итак: поехали.

Содержание:

    Установка Yocto Project в Ubuntu
    Механизм сборки дистрибутива в Yocto Project
    Использование OpenEmbedded совместно c Yocto Project
    Пакет поддержки платформы (BSP)
    Управление слоями Yocto c помощью Repo
          Установка Repo
          Манифест для сборки дистрибутива
          Содержимое Манифеста
          Описание Манифеста
          Структура bs-manifest
          Инициализация переменных Poky
          Инициализация Repo
          Синхронизация Repo
    Создание конфигурации Yocto Project
          Конфигурационный файл build/conf/local.conf
          Конфигурационный файл build/conf/bblayers.conf
    Слой для сборки мультимедиа центра
          Структура слоя
          Конфигурация слоя
          Состав recipes-berserk
          Состав recipes-core
          Состав recipes-kernel
          Состав recipes-mediacentre
          Состав recipes-multimedia
          Дополнение рецепта для сборки Kodi
          Добавление нового пункта в меню настроек Kodi
          Максимальные настройки буферизации для видео
    Просмотр телевидения по протоколу IPTV
    Просмотр Youtube с помощью Kodi плагина
    Консольное shell расширение конфигурации сети
    Рецепт сборки дистрибутива
    Краткая инструкция по созданию образа дистрибутива
    Постскриптум

Установка Yocto Project в Ubuntu

Для сборки дистрибутива с помощью Yocto Project в 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

Пакеты устанавливаются с помощью команды apt-get install и команды повышения привилегий — sudo. В системе Ubuntu это широко распространенная практика, когда для выполнения административных действий используется команда sudo (при создании основного пользователя системы, он автоматически прописывается в группу «sudo»).

Более подробную инструкцию по установке вы можете посмотреть здесь:

Механизм сборки дистрибутива в Yocto Project

В Yocto Project каждая программная единица описывается с помощью рецепта сборки. Язык описания рецепта напоминает «bash» c возможностью вставок частей кода на языке «python». Основную информацию по синтаксису вы можете почерпнуть из руководства Yocto Project . Набор рецептов сборки в зависимости от назначения можно объединять в отдельные слои сборки.

Слои разделяются на аппаратно зависимые — BSP слои, UI слои (пользовательского интерфейса), специфические Yocto слои, а также слои реализующие определенную функциональность:
например слои из OpenEmbedded => multimedia, python, perl, ruby, networking, systemd, webserver и т.д.

Использование OpenEmbedded совместно c Yocto Project

И еще, если вы будете использовать Yocto Project, то наверняка вам понадобятся слои с дополнительной функциональностью т.е. большой набор рецептов на все случаи жизни. И такой набор есть — это рецепты из OpenEmbedded. OpenEmbedded — инфраструктура для сборки пакетов для встраиваемого Linux.

OpenEmbedded полностью совместим с Yocto Project, так как этот проект был взят за основу для Yocto Project. Возможно поэтому Yocto Project отличается немного лучшей стабильностью, лучшей документацией и немного лучшей поддержкой (но в основе своей это все тот же OpenEmbedded).

Пакет поддержки платформы (BSP)

Пакет поддержки платформы (Board Support Package) — это отдельный, специализированный слой(и) для конкретной платы, который определяет аппаратные особенности платформы т.е. реализует те специфические вещи, которые отличают одну плату от другой: особенности процессора, прерывания, адресация, особенности загрузчика, особенности видео адаптера (GPU) и т.д.

В этой статье используется BSP слой — meta-raspberrypi
Репозиторий слоя располагается по адресу: git.yoctoproject.org/git/meta-raspberrypi

Управление слоями Yocto c помощью Repo

Yocto Project может использовать большое количество слоев от разных поставщиков — разработчиков оборудования, и всем этим необходимо как то управлять. Представьте себе, что у вас есть десяток различных плат, и к каждой плате поставляется отдельный BSP гит репозиторий, и это не считая инфраструктуры самого Yocto проекта, плюс возможная дополнительная функциональность из OpenEmbedded.

В такой ситуации отдельным простым скриптом установки уже не отделаешься. Волей, неволей приходиться искать инструменты, которые умеют это делать хорошо. Даже более чем хорошо. Одним из лучших инструментов такого рода является утилита Google — Repo.

Repo — это основной инструмент для управления GIT репозиториями при сборке операционной системы «Андроид» с его большой кодовой базой. Repo позволяет в одном проекте управлять десятком, если не сотней отдельных гит репозиториев, версии которых вы можете аккуратно указать в одном xml файле Манифеста

и для правильной синхронизации всех версий всех репозиториев вам достаточно выполнить одну команду

repo sync

Установка Repo

C помощью следующего набора команд вы можете установить Repo в ваш домашний каталог ~/bin
(команду curl можно установить отдельно: 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

и в дальнейшем вам достаточно использовать в консоли команду: repo

или так,
если каталог HOME/bin не добавился с стандартный путь запуска автоматически
см. файл HOME/.profile

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

Манифест для сборки дистрибутива

Дистрибутив, собираемый в рамках статьи, мне нужно как то назвать. Пусть это будет имя Torvin . Под кодовым названием Torvin будет содержаться минималистический Linux дистрибутив со сборкой одной единственной программы. Имеется ввиду одна прикладная пользовательская программа — Kodi, и ничего лишнего (все остальное системный уровень). Для мультимедиа центра, на мой взгляд этого вполне достаточно.

Содержимое Манифеста

Для управления слоями дистрибутива используется файл torvin-0.2.5.xml

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

Описание Манифеста

В начале манифеста тегами remote обозначены два основных GIT репозитория и один вспомогательный:

https:??git.yoctoproject.org/git — Yocto репозиторий, именованный как yocto
https:??github.com/openembedded — OpenEmbedded репозиторий, именованный как oe
https:??github.com/berserktv — вспомогательный GIT репозиторий, именованный как bs

В следующей части манифеста с помощью сокращенных именований осуществляется работа с проектами расположенными в этих репозиториях, тег project содержит следующие атрибуты:

    remote — имя удаленного именованного репозитория
    revision — название ветки или hash версии
    name — имя проекта в указанном репозитории
    path — локальный путь проекта в вашей файловой системе

Пример работы тега
<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

В теле тега project я указал команды создания символических ссылок на нужную мне инфраструктуру вспомогательных скриптов начальной инициализации и штатного запуска системы сборки Poky

Пример указания тегов 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

+-- COPYING.MIT
+-- raspberry
¦   +-- rocko
¦   ¦   +-- conf
¦   ¦   ¦   +-- bblayers.conf
¦   ¦   ¦   L-- local.conf
¦   ¦   L-- torvin-0.2.5.xml
¦   L-- shell.sh
+-- README.md
L-- setup-environment

Проект bs-manifest используется для гибкого управления конфигурациями, с учетом сборок разных версий дистрибутива. У меня это версия — 0.2.5

Инициализация переменных Poky

Скрипт начальной инициализации setup-environment был взят из проекта Freescale Community (в среде yocto это часто встречающееся решение). Скрипт отвечает за стартовую инициализацию переменных системы сборки Poky, скрипт создает структуру каталогов, в которой очень хорошо разделяется:

• build — каталог сборки
• source — исходный код рецептов сборки
• download — каталог загрузки кода программ (git базы, tar.gz архивы)

Содержимое скрипта setup-environment можно посмотреть здесь:


этот корневой скрипт служит для начальной конфигурации переменных среды сборки и обычно вызывается в начале сеанса работы.

Инициализация Repo

Для инициализации repo необходимо выполнить команду:

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

где -u https:??github.com/berserktv/bs-manifest указывает GIT путь к проекту манифеста

примечание: можно еще указать -b имя_ветки
(если ключ -b не указывать, то подразумевается ветка master (по умолчанию))

где путь -m raspberry/rocko/torvin-0.2.5.xml к конфигурационному файлу указывает следующее:

1. Имя аппаратной платформы для которой осуществляется сборка — raspberry
2. Имя основной рабочей ветки Yocto/OpenEmbedded — rocko
3. Кодовое имя версии — torvin (все версии серии 0.2.x)
4. Цифровой номер версии которая собирается — 0.2.5

Синхронизация Repo

для начальной загрузки или последующей синхронизации достаточно выполнить команду:

repo sync

которая заберет все последние версии GIT проектов указанных в файле манифеста (обычно указываются ветки), если же у вас указан hash коммита или имя тега в атрибуте revision, то версия для данного git репозитория не измениться. Имя тега можно указать так: revision=«refs/tags/v0.2.5»

Создание конфигурации Yocto Project

После того, как будет выполнена команда repo sync, можно приступать к созданию основной конфигурации Yocto Project:

./shell.sh

после завершения работы скрипта, будет создан каталог build/conf:
c двумя основными файлами:

• local.conf — управляющие переменные сборки:
  название платформы, тип дистрибутива и пакетов сборки и т.д.
• bblayers.conf — конфигурация подключенных слоев Yocto Project

по умолчанию скрипт setup-environment ищет по пути sources/base/conf
начальную конфигурацию, и если файлы local.conf и bblayers.conf
существуют, то они копируются в build/conf
(см. переменную TEMPLATES в setup-environment)

т.е. файлы берутся из sources/bs-manifest/raspberry/rocko/conf
см. создание символической ссылки на base

Конфигурационный файл build/conf/local.conf

Конфигурационный файл build/conf/bblayers.conf

основные переменные файла local.conf — на которые нужно обратить внимание:

• MACHINE — название платформы под которую осуществляется сборка
• DISTRO — название категории дистрибутива
• PACKAGE_CLASSES — формат пакетов для установки ПО
• LICENSE_FLAGS_WHITELIST — использование дополнительных лицензий

специфические настройки для семейства плат Raspberry Pi

• GPU_MEM = «128» — количество видео памяти для видео адаптера GPU (выделяется из ОЗУ)
• GPU_MEM_256 = «112» — то же самое только для плат с общим размером ОЗУ = 256Мб
• GPU_MEM_512 = «160» — то же самое только для плат с общим размером ОЗУ = 512Мб
• GPU_MEM_1024 = «320» — то же самое только для плат с общим размером ОЗУ = 1024Мб

примечание:
например если оставить только переменную GPU_MEM = «128»,
то для всех плат RPI, RPI2, RPI3
не зависимо от количества реальной оперативной памяти
на плате будет всегда выделено для GPU — 128Мб
(и общий размер ОЗУ уменьшиться на это значение)

в случае указания всех переменных, директивы GPU_MEM_256, GPU_MEM_512, GPU_MEM_1024 являются более приоритетными.

Для сборки Мультимедиа центра, помимо штатных слоев Yocto см. файл bblayers.conf

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

я подключил четыре слоя с дополнительной функциональностью из OpenEmbedded.

Мультимедиа Центр Kodi — является сложной программой, которая использует большое количество внешних библиотек и каждую библиотеку нужно собрать с помощью рецепта сборки, поэтому по возможности я буду использовать все рецепты из OpenEmbedded в категории Multimedia

Итак, у меня подключен слой Multimedia и слои от которых он зависит

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

затем подключен еще один слой OpenEmbedded, для работы с файловыми системами

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

далее подключен основной BSP слой для платформы Raspberry Pi

${BSPDIR}/sources/meta-raspberrypi 

ну и в самом конце подключен дополнительный слой, отвечающий за сборку образа дистрибутива с функциональностью «Мультимедиа центра»

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

Слой для сборки мультимедиа центра

На мой взгляд Yocto Project является промышленным комбайном для создания встраиваемых дистрибутивов. Но если вы когда нибудь работали с системой сборки Buildroot, то Yocto может вам показаться достаточно громоздким. Он использует огромное количество свободного места на жестком диске. Для нормальной работы Yocto требуется порядка 80 — 100 Гб свободного пространства и это обычно с учетом сборки только под одну платформу.

Yocto прекрасно справляется со своим основным назначением — поддержкой как можно большего количества различных аппаратных платформ и для этого требуется максимально гибкий механизм по переключению сборок. И этому механизму требуется место и время. Сборка дистрибутива в Yocto процесс не быстрый.

Итак, вся функциональность, для сборки «Мультимедиа центра» у меня находиться с отдельном слое:

https://github/berserktv/berserk

(Название взято из моей любимой книги «Молот и крест», писателя Гарри Гаррисона.)
(Torvin также является персонажем данной книги.)

Для внесения нужной мне функциональности я по возможности буду использовать так называемые дополнения для рецептов, которые располагаются в файлах с расширением .bbappend
в файле .bbappend вы можете добавить собственные вызовы команд для штатного метода рецепта сборки, например в метод do_configure, do_compile, do_install  и т.д.

Структура слоя

+-- COPYING.MIT
+-- meta-berserk
¦   +-- conf
¦   ¦   L-- layer.conf
¦   +-- recipes-berserk
¦   ¦   +-- bs-net
¦   ¦   +-- first-run
¦   ¦   +-- images
¦   ¦   L-- tv
¦   +-- recipes-core
¦   ¦   +-- init-ifupdown
¦   ¦   L-- psplash
¦   +-- recipes-kernel
¦   ¦   L-- linux
¦   +-- recipes-mediacentre
¦   ¦   +-- kodi
¦   ¦   L-- kodi-plugins
¦   L-- recipes-multimedia
¦       L-- ffmpeg
+-- README.md
L-- changelog.txt

Состав слоя:

• conf — конфигурация слоя
• recipes-berserk — рецепт сборки дистрибутива, рецепты настройки тв, сети и первого запуска
• recipes-core — базовые рецепты, в частности модификация рецепта стартовой заставки
• recipes-kernel — рецепты сборки Linux ядра
• recipes-mediacentre — рецепты сборки Kodi и его плагинов
• recipes-multimedia — мультимедиа рецепты, сборка ffmpeg

конфигурация слоя

Файл содержит указание версии библиотеки ffmpeg, номер версии linux ядра, а также количество виртуальных консолей (tty), и включает особенности дистрибутива — wifi x11

DISTRO_FEATURES_append += " wifi x11"

PREFERRED_VERSION_ffmpeg = «3.1.11»
SYSVINIT_ENABLED_GETTYS = «1»

PREFERRED_VERSION_linux-raspberrypi ?= «4.9%»

состав recipes-berserk

+-- bs-net
¦   L-- bs-net_0.1.3.bb
+-- first-run
¦   +-- files
¦   ¦   L-- first-run.sh
¦   L-- first-run.bb
+-- images
¦   L-- berserk-image.bb
L-- tv
    +-- files
    ¦   L-- berserk.m3u8
    +-- tv-config.bb
    L-- tv-dir.inc

где:

• bs-net_0.1.3.bb — рецепт сборки shell расширения для WLAN/Ethernet интерфейсов
• first-run.bb — рецепт первого запуска, дополнительное разбиение дисков
• first-run.sh — shell скрипт первого запуска (запускается на уровне исполнения S)
• berserk-image.bb — рецепт сборки образа дистрибутива
• tv-config.bb — рецепт настройки конфигурации ТВ каналов по протоколу IPTV
• berserk.m3u8 — конфигурация общедоступных телевизионных каналов (формат m3u8)

состав recipes-core

+-- init-ifupdown
¦   +-- files
¦   ¦   L-- interfaces
¦   L-- init-ifupdown_1.0.bbappend
L-- psplash
    +-- files
    ¦   L-- psplash-berserk-img.h
    L-- psplash_git.bbappend

где:

• interfaces — файл с текущей настройкой сети
• init-ifupdown_1.0.bbappend — расширение для рецепта конфигурации сети
• psplash-berserk-img.h — изображение стартовой заставки
  заголовочный файл получен с помощью утилиты gdk-pixbuf-csource
• psplash_git.bbappend — расширение рецепта сборки стартовой заставки

Конфигурация сети на целевом устройстве находиться в файле:

/etc/network/interfaces

Добавив расширение рецепта init-ifupdown, я заменяю штатный конфигурационный файл на собственный, и меняю порядок (приоритет) запуска скрипта для уровней исполнения

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

В настоящий момент, почти все современные Linux дистрибутивы включают в свой состав стартовую заставку. Обычно стартовая заставка показывает текущее состояние загрузки т.е. индикатор времени прошедшего с момента запуска системы. В этом плане Yocto не исключение и вы можете поменять изображение штатной стартовой заставки на произвольную картинку.

Для этого необходимо:

1. FILESEXTRAPATHS_prepend — добавить каталог для ресурсов
2. SRC_URI — добавить заголовочный файл с произвольной картинкой
3. SPLASH_IMAGES — изменить управляющую переменную пакета

и далее в рецепте образа «berserk-image.bb» необходимо добавить в качестве особенностей образа — стартовую заставку splash

IMAGE_FEATURES += "splash"

# и переменную с указанием конкретного названия пакета стартовой заставки
SPLASH = "psplash-berserk"

состав recipes-kernel

L-- linux
    +-- files
    ¦   +-- db.txt.patch
    ¦   L-- rbpi.cfg
    L-- linux-raspberrypi_4.9.bbappend

где:

• db.txt.patch — патч с базой Regulatory Domain (используется для WiFi)
• rbpi.cfg — фрагмент конфигурации Linux ядра
• linux-raspberrypi_4.9.bbappend — расширение рецепта сборки ядра 4.9 для Raspberry Pi

Wi-Fi устройства работают на определенных частотах и для них существует такое понятие как управляющий домен (regulatory domain) – именно в этом параметре указана страна, в которой, как предполагается, работает данное устройство.

В ядре Linux имеется сопутствующая база данных, в которой для каждой страны прописаны разрешенные частоты и разрешенная для них мощность.

В самом простом случае эту базу можно включить непосредственно в ядро статически, указав параметр:
CONFIG_CFG80211_INTERNAL_REGDB=y
что собственно я и сделал, подключив патч c этой базой db.txt.patch

И еще: в Yocto существует такое понятие как фрагменты конфигураций ядра. Обычно фрагмент конфигурации, файл с расширением cfg, содержит только те параметры ядра, которые вам явно необходимы для определенных целей. И этот фрагмент конфигурации добавляется к параметрам по умолчанию, которые уже присутствуют в рецепте при сборке ядра.

В дополнении рецепта bbappend, также можно изменить параметры, которые передаются ядру во время запуска:

т.е. переопределить переменную
CMDLINE см. файл linux-raspberrypi_4.9.bbappend

состав recipes-mediacentre

+-- kodi
¦   +-- kodi
¦   +-- kodi_17.bbappend
¦   +-- kodi-dir.inc
¦   +-- kodi-runner.bb
¦   +-- kodi-settings.bb
¦   L-- kodi-version.inc
L-- 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
    L-- script-module-requests_2.12.4.bb

где:

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

L-- ffmpeg
    +-- ffmpeg
    ¦   +-- 0001-ffmpeg-Call-get_format-to-fix-an-issue-with-MMAL-ren.patch
    ¦   +-- h264_parser.patch
    ¦   L-- pfcd_hevc_optimisations.patch
    L-- ffmpeg_3.1.11.bb

где:

• 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 библиотека для кодирования / декодирования огромного количества видео и аудио форматов. FFmpeg поддерживает почти 400 кодеков (ffmpeg -codecs)
и более 300 форматов (ffmpeg -formats).

Дополнение рецепта для сборки «Kodi»

В слое OpenEmbedded находиться штатный рецепт для сборки Kodi, но он достаточно общий, а мне хотелось бы получить немного более стабильную и проверенную версию для платформы Raspberry Pi.

У разработчиков программного обеспечения есть такое понятие как патч обратного портирования. Программное обеспечение постоянно обновляется, и каждая новая версия включает как новые функции так и исправление известных ошибок. Патч обратного портирования позволяет часть изменений новой версии программы перенести на более старую, тем самым сделав ее более стабильной. Но это очень тяжелая и кропотливая работа, которая всегда выполняется большим количеством разработчиков.

В мире OpenSource сообщества есть несколько хорошо известных проектов, использующих Kodi, лучшим из которых (на мой взляд) является LibreElec (OpenElec). У LibreElec есть хорошая сборка для платформы Raspberry Pi. Вот у них то и лучше всего взять патч обратного портирования для Kodi. Тем самым, можно избавиться от огромного количества проблем, даже не узнав об этом.

Мультимедиа центр Kodi заточен на проигрывание «Медиа» контекста, и на мой взгляд самым критичным компонентом является связка Kodi и FFmpeg, т.е. взаимодействие определенных версий этих программ, остальные библиотеки можно оставить из слоев Yocto и OpenEmbedded.

Для сборки я взял стабильную версия Kodi 17.6 и версию FFmpeg 3.1.11


Включаемый файл с описанием версии будет такой kodi-version.inc

FILESEXTRAPATHS_prepend := "${THISDIR}/kodi:"

# ветка Krypton
SRCREV = "a9a7a20071bfd759e72e7053cee92e6f5cfb5e48"
PV = "17.6+gitr${SRCPV}"

Ветка Yocto и OpenEmbedded, которую я рассматриваю — rocko, содержит версию Kodi 17.3, и для того чтобы перейти к версии 17.6, достаточно добавить небольшое дополнение для рецепта — 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"

Опция сборки "--enable-optical-drive" позволяет подключить удобный механизм оповещения, который используется в Kodi при подключении оптического диска. В этом случае модуль MediaManager(а) (xbmc/storage/MediaManager.cpp) отслеживает подключение/отключение новых дисковых разделов, и выводит на экран всплывающее сообщение об этом.

пример udev правила подключения/отключения дисков:

ACTION=="add" SUBSYSTEM=="block"  ENV{ID_FS_TYPE}=="vfat"               KERNEL=="sd[a-z][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[a-z][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[a-z][0-9]"               RUN+="/bin/mkdir -p /media/%k",               RUN+="/bin/mount -o noatime /dev/%k /media/%k"


ACTION=="remove" SUBSYSTEM=="block" KERNEL=="sd[a-z][0-9]"                  RUN+="/bin/umount /media/%k", RUN+="/bin/rmdir /media/%k"

Примечание: 
команда rmdir умеет удалять только пустые каталоги,
а вот не пустые уже нет (пример Linux подхода одна программа - одна функция)
и в данном контексте ее применение безопасно.

Добавление нового пункта в меню настроек Kodi

В Kodi 17.6, за отображение пунктов меню отвечают конфигурационные xml файлы. Для добавления еще одного под пункта в меню «Settings», достаточно подкорректировать файл:
kodi/addons/skin.estuary/xml/Settings.xml

где skin.estuary — тема оформления меню по умолчанию

описание пункта выглядит так:

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

где:

label — название пункта меню
onclick — обработка событие нажатия на кнопку меню
(запуск плагина, с передачей первым аргументом строки «butnetwork»)
icon — иконка пункта меню (путь к png изображению)

Указанная выше функциональность, а также подключение нескольких дополнительных Kodi плагинов интегрирована с помощью файла bs-menu.patch

Максимальные настройки буферизации для видео

В мультимедиа центре Kodi для увеличения производительности можно указать максимальные настройки буферизации:

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

buffermode=1
— буферизировать запросы для всех файловых систем (включая локальную)

readfactor
— регулирует скорость загрузки на основе среднего битрейта видео. Так, например, если вы воспроизводите видео со средней скоростью передачи данных 5 Мбит/с и устанавливаете коэффициент чтения буфера на 2.0, это ограничит скорость загрузки (и, следовательно, скорость заполнения кеша) примерно до 10 Мбит/с, таким образом:

readfactor=20
снимает ограничение на скорость загрузки

memorysize =139460608
— размер буфера составляет 133 МБайт, при этом используется 133*3 оперативной памяти т.е. около 400 Мбайт оперативной памяти

Просмотр телевидения по протоколу IPTV

Медиацентр Kodi является очень мощным инструментом для просмотра цифрового контента.

Основной функцией, для которой я собирал «Медиацентр» является функция просмотра цифрового телевидения по протоколу IPTV (Internet Protocol Television) т.е. телевидение по протоколу интернета. С помощью данной функции вы можете просматривать цифровое телевидение от вашего интернет провайдера.

Это самый современный и оптимальный вариант как с точки зрения качества изображения, так и с точки зрения дополнительных возможностей т.е. предоставляемых услуг. Например телевизионные каналы могут предоставляться в архиве, в котором нужная видео запись доступна еще какое-то время, после трансляции.

Для поддержки IPTV в Kodi существует несколько вариантов плагинов, из которых я остановился на плагине pvr.iptvsimple

Для сборки плагина используется рецепт:

    L-- kodi-plugins
        L-- kodi-pvr-iptvsimple.bb

Плагин подключается/настраивается через:
Основное меню Kodi => «Дополнения» => «Мои дополнения» => «Клиенты PVR» => «PVR IPTV Simple Client»

Для проверки работы IPTV телевидения в составе Kodi, я взял несколько общедоступных новостных информационных каналов и добавил их в список в формате m3u8, а также включил автоматический запуск плагина «pvr.iptvsimple» при старте медиацентра.

Просмотр Youtube с помощью Kodi плагина

Программисты, которые разработали «Kodi», предусмотрели возможность гибкого расширения его функций. Это сделано для того что бы любой энтузиаст при желании мог добавить в Kodi то, что ему ну очень нужно. И плагинов этих для Kodi тьма тьмущая. Ну вы поняли. Их настолько много, что это заслуживает описания в отдельной статье.

Плагины устанавливаются очень просто, достаточно подключить Kodi к интернету и нажать пару кнопок в меню. Об этом вы можете почитать на любом из форумов посвященным Kodi. Но сборка, есть сборка, и еще один плагин я включу в дистрибутив в качестве примера.

Самым интересным и распространенным plugin(ом) для Kodi по моему убеждению является плагин просмотра Youtube. Kodi же мультимедиа центр, а Youtube самое огромное хранилище этого самого мультимедиа контента, так что плагин Youtube для Kodi почти обязателен.

Плагин написан на языке python, и это штатный механизм плагинов, вам не нужно ничего компилировать, достаточно просто скопировать готовый плагин в корневой каталог с плагинами, и указать имя плагина в xml файле манифеста:
«system/addon-manifest.xml»

Плагин взят из официального репозитория, и его исходный код включен в архив:
recipes-mediacentre/kodi-plugins/files/plugin.video.youtube.tar.gz

Расположение рецепта сборки плагина см. выше в главе «состав recipes-mediacentre»

Консольное shell расширение конфигурации сети

Так как дистрибутив собираемый в рамках данной статьи является демонстрационным, то и требования к настройки «Сетевых интерфейсов» к нему минимальны. Мне не хотелось тащить для этого, какой либо тяжелый сетевой менеджер, сильно мне не понятный и сильно громоздкий, и поэтому я написал два shell скрипта, дополняющих настройку штатного механизма конфигурации:

##############################################################
# пример возможного использования в /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

Для удобной настройки Ethernet/WLAN сетевых интерфейсов через GUI, у меня используется еще один небольшой Kodi плагин «script.berserk.network». Это почти единственный Kodi plugin, в котором я разобрался, но для этого мне пришлось его написать. Он предельно компактный и минималистичный и написан на языке «python».

Оба этих компонента, собираются с помощью рецептов:

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

На этом моменте я хотел бы остановиться по подробней. Итак вся гибкость использования Yocto, заключается в разных наборах рецептов т.е. подключили один набор рецептов — в дистрибутив добавился простейший сетевой менеджер, подключили другой набор — добавили ваш любимый сетевой менеджер использующий например systemD и т.д.

Для автоматического подключения к WiFi точке доступа при старте системы, у меня используется 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"

Скрипт wlan-runner просто выполняет команды:
/etc/network/wlan $IFACE up
или
/etc/network/wlan $IFACE down

Рецепт сборки дистрибутива

В Yocto Project предусмотрен механизм повторного использования. Есть классы, от которых вы можете наследоваться (директива «inherit»), и есть базовые рецепты, которые вы можете подключить (директива «include»).

Покажу наследование на примере класса:
poky/meta/clasess/core-image.bbclass

Класс отвечает за описание групп пакетов, которые вы можете включить в тот или иной рецепт. Для этого достаточно указать в начале рецепта конструкцию:
inherit core-image

Еще в тексте этого класса вы можете посмотреть особенности образа, каждая особенность отвечает за группу функций включаемых в образ, а каждая группа в конечном итоге описывает набор устанавливаемых программ или библиотек.

Особенности образа указываются так:

IMAGE_FEATURES += "ssh-server-dropbear splash"

Еще есть DISTRO_FEATURES — особенности дистрибутива, которые можно указать в конфигурационном файле слоя. Это функции уровня дистрибутива, и если вы например поменяете какую то особенность (например x11), то последующая сборка начнет пересобирать все пакеты, которые зависят от этой опции (это может занимать достаточно длительное время).

Основной базовый рецепт, который я использую:
poky/meta/recipes-core/images/core-image-minimal.bb



Хотел бы уточнить, что например пакет «kernel-modules», установит
все модули ядра указанные в файле defconfig в образ дистрибутива.

Но если вы что то сильно кастомизируете, то конечно все модули ядра вам могут и не понадобиться, в таком случае удобно добавлять каждый модуль по имени, как указано в переменной BS_WLAN, это как шпаргалка, указываем только то, что нужно и после проверки работы пакет «kernel-modules» убираем, проверяем и т.д.

Краткая инструкция по созданию образа дистрибутива

Постскриптум

Возможности OpenSource за последние годы только увеличиваются.

А возможности эти не малые, за примерами даже не надо далеко ходить. Вряд ли та же «Microsoft» ожидала, что OpenSource технологии выбросят ее с рынка мобильных операционных систем. Я имею ввиду ОС от Google — «Android», которая в одночасье выбросила «Пионера» мобильных систем на обочину. И не понятно, сможет ли Microsoft, снова на него вернуться.

Конечно «Google», огромная корпорация с почти не ограниченными финансами и великолепными разработчиками, но все-же, как говориться «без Ядра и не туда и не сюда».

Лучшие OpenSource проекты со временем становятся произведением искусства (например Kodi, Openelec/libre и т.д.)

И сегодня любой желающий может приобщиться к лучшим практикам в OpenSource, так сказать не вылезая из Github(a). Эта статья об этом.

Побольше вам сборок хороших и разных, и помните «мир интернета вещей наступает».