Yocto:ImageBuild:Stlinux

Der User seife hat diverse Recipies für das Yocto Buildsystem erstellt, die es ermöglichen ein Neutrino-MP für verschiedene Settopboxen zu erstellen. Momentan kann man USB Images und entsprechende Softwarepakete für die Receiver der 1. Generation (armv6 basierend) von Coolstream, für die SH4 basierten Boxen mit dem Prozessortypen STI7111 und STI7162, für die Tripledragon und den Raspberry (nicht Version 2) erstellen.

Vorbereitungen

Für Debian basierte System (momentan getestet mit Wheezy und Jessie in 32/64bit) sind folgende Pakete vor dem Setup von Yocto nötig.

$ sudo apt-get update
$ sudo apt-get install libsdl1.2-dev chrpath git build-essential automake texinfo

Des Weiteren benötigt man ein extra Verzeichnis im $HOME in dem man alle nötigen Verzeichnisse samt zusätzlicher Unterverzeichnisse anlegen kann. Im folgenden wird $HOME/yocto verwendet, das kann natürlich jeder seinen Gepflogenheiten anpassen. Achtung, ein späteres Verschieben ist nicht einfach möglich da innerhalb der erzeugten Toolchain mit absoluten Pfaden gearbeitet wird!

$ mkdir ~/yocto && cd ~/yocto

Innerhalb dieses Verzeichnisses sollte man direkt auch einen gemeinsamen Downloadordner für die möglichen verschiedenen Systeme anlegen, dies erspart später mehrfaches herunterladen der diversen Source Pakete. Wer ein entsprechende Verzeichnis für derartige Downloads schon besitzt kann natürlich dieses auch per Symlink einbinden (oder in der späteren Konfiguration den entsprechenden Pfad angeben).

$ mkdir download

Die STLinux Boxen benötigen eine Firmware für den Audio- und Videodekoder! Diese sind nicht Bestandteil von Yocto oder der Recipes von seife! Diese Firmware kann aus der Originalfirmware kopiert werden oder man bemüht die Internet Suchmaschine seiner Wahl! Damit das Buildsystem komplette funktionsfähige Images erstellen kann benötigt man die audio.elf und die video.elf. Diese werden im Buildsystem über die Variable BINARY_STSLAVE_FW_PATH referenziert. Diese zeigt standardmäßig auf /data/stslave_fw/${MACHINE} was allerdings außerhalb des Homeverzeichnisses liegen würde. Wir können das Umschiffen indem wir die Firmware innerhalb des eben erstellten Downloadordners ablegen und später in der Konfiguration dies dem Buildsystem mitgeben. Da das Recipe auch noch die Zielplattform auswertet und dies an die Variable BINARY_STSLAVE_FW_PATH mit anhängt müssen wir nun innerhalb vom Ordner download/ noch einen Ordner spark/ erstellen und dort die Firmware ablegen.

$ mkdir download/spark
$ cp /Pfad/zu/audio.elf download/spark
$ cp /Pfad/zu/video.elf download/spark

Erstsetup Yocto für STLinux (Spark) Boxen

Da die benötigten Buildtools, die durch Yocto zur Verfügung gestellt werden, per Git Tree verwaltet werden, können wir diese einfach per Git klonen. Beim Yocto Projekt heißt dieser Git Tree "poky" und es gibt noch zahlreiche andere Git Tree's beim Yocto Projekt. Um die möglichen verschiedenen Systeme lokal später auseinander halten zu können werden wir aber den Git Tree in ein anders benanntes Verzeichnis pullen, es empfiehlt sich den Treenamen von Upstream plus die benutze Plattform in die Benamung einfließen zu lassen. Für die ST basierten Boxen benutzt diese Anleitung den Namen 'yocto-poky-stl'.

$ git clone http://git.yoctoproject.org/git/poky yocto-poky-stl

Nach dem Pullen wechselt man in den Git Tree und wechselt dort auf den Branch 'krogoth ', dies ist der aktuell als stabil geltende Branch von Yocto Poky.

$ cd yocto-poky-stl
$ git checkout -b krogoth origin/krogoth

Auschecken der Neutrino-MP relevanten Git Tree's

Direkt nach dem Wechseln des Yocto Branches können nun zwei weitere benötigte Git Verzeichnisse geklont werden die der Benutzer seife erstellt hat und pflegt. Dies geht recht einfach und gewohnt per git Kommando.

$ git clone https://github.com/seife/meta-stlinux.git
$ git clone https://github.com/seife/meta-neutrino-mp.git

Erstellen und Anpassen der Konfiguration

Dieser Schritt ist sehr wichtig da sonst keine Pakete und Images erstellt werden können, wir müssen quasi Yocto bekannt geben was es wie bauen soll. Ohne den folgenden Schritt hat unser System keine gültige Grundkonfiguration! Zum Erstellen einer allgemein gültigen Konfiguration führt folgende Zeile aus.

$ . ./oe-init-build-env build-stl

Dies sourced die Datei 'oe-init-build-env' und übergibt dieser als Argument 'build-stl', was, wie der Name schon vermuten lässt, unser Build Verzeichnis sein soll. Ihr solltet dabei folgenden Output sehen.

You had no conf/local.conf file. This configuration file has therefore been
created for you with some default values. You may wish to edit it to use a 
different MACHINE (target hardware) or enable parallel build options to take 
advantage of multiple cores for example. See the file for more information as 
common configuration options are commented.

The Yocto Project has extensive documentation about OE including a reference manual
which can be found at:
    http://yoctoproject.org/documentation

For more information about OpenEmbedded see their website:
    http://www.openembedded.org/

You had no conf/bblayers.conf file. The configuration file has been created for
you with some default values. To add additional metadata layers into your
configuration please add entries to this file.

The Yocto Project has extensive documentation about OE including a reference manual
which can be found at:
    http://yoctoproject.org/documentation

For more information about OpenEmbedded see their website:
    http://www.openembedded.org/



### Shell environment set up for builds. ###

You can now run 'bitbake <target>'

Common targets are:
    core-image-minimal
    core-image-sato
    meta-toolchain
    adt-installer
    meta-ide-support

You can also run generated qemu images with a command like 'runqemu qemux86'
user@host:~/yocto/yocto-poky-stl/build-stl

Das Skript erstellt benötigte Variablen und erweitert auch die PATH Variable für die späteren Kommandos. Wenn Ihr obige Ausgabe nicht seht und ebenfalls auch nicht im Verzeichnis ~/yocto/yocto-poky-stl/build-stl steht habt Ihr etwas falsch gemacht!

Es müssen nun noch zwei weitere Anpassungen durchgeführt werden damit Pakete und Images erstellt werden können. Nachdem nun eine Grundkonfiguration vorhanden ist, muss diese um diverse Notwendigkeiten erweitert werden, wie zum Beispiel die Zielplattform oder weitere andere optionale Parameter. Dazu muss die Datei conf/local.conf (mit Sicht innerhalb des lokalen Verzeichnisses) angepasst werden. Folgende Zeilen erstellen die nötigen Information für das Yocto System. Achtung, bitte beachtet das die Variable DL_DIR mit dem richtigen Pfad ergänzt wird wenn nicht die Verzeichnisstruktur aus den obigen Punkten verwendet wird!

$ cat << EOF >> conf/local.conf

### DON'T CHANGE ANYTHING HERE UNLESS YOU KNOW WHAT YOU DOING!!!
### Config for STLinux based boxes
MACHINE = "spark"
### Prefered package system
PACKAGE_CLASSES = "package_ipk"
### Additional image feature, we want a package management
EXTRA_IMAGE_FEATURES += "package-management"
### Needed for using cached build informations
PRSERV_HOST = "localhost:0"

### Adopt these settings to your needs!
### Setup the seperate download folder here!
DL_DIR ?= "${HOME}/yocto/download"
### Setup a local mirror if wanted
#SOURCE_MIRROR_URL ?= "file:///home/[YOUR_USERNAME]/src/Archive"
### Uncomment if you want to use the mirror
#INHERIT += "own-mirrors"

## if you want to use ccache...
#INHERIT += "ccache"

## save some space by cleaning up after every build
#INHERIT += "rm_work"

### If you have the firmware {audio,video}.elf not in /data/stslave_fw/${MACHINE} ...
### then you can adjust the variable BINARY_STSLAVE_FW_PATH to a appropriate folder.
### Don't forget, the recipe is appending a ${MACHINE} (remind: we are using 'spark'!)
### later to the folder you adjust here!!!
BINARY_STSLAVE_FW_PATH="\${DL_DIR}"
EOF

Nun müssen Yocto die zusätzlichen Recipes (meta-stlinux und meta-neutrino-mp) noch bekannt gemacht werden. Diese Konfiguration erfolgt in der Datei conf/bblayers.conf. Mit folgendem Einzeiler kann man die nötigen zusätzlichen Recipes voll automatisiert einfügen.

$ sed -i -e "/meta-yocto-bsp/{p;s/meta-yocto-bsp/meta-stlinux/p;s/meta-stlinux/meta-neutrino-mp/}" conf/bblayers.conf

Damit ist Yocto vollständig konfiguriert und Ihr solltet folgende Verzeichnisstruktur von $HOME/yocto ausgehend besitzen:

user@host/yocto $tree -d -L 2
.
├── bitbake
│...
├── build-stl
│   ├── cache
│   ├── conf         <----- Ablageort für bblayers.conf und local.conf
│   ├── sstate-cache
│   └── tmp          <----- Verzeichnis in dem Neutrino-MP komplett gebaut wird
├── documentation
│...
├── meta-neutrino-mp
│...
├── meta-selftest
│...
├── meta-skeleton
│...
├── meta-stlinux
│...
├── meta-yocto
│...
├── meta-yocto-bsp
│...
└── scripts
 ...

Imageerstellung

Nach diesen Vorbereitungen kann dem Buildsystem mitgeteilt werden das man ein Neutrino-MP Image erstellt haben will. Eigentlich sind dies mehrere da Yocto verschiedene Images für einen USB-Stick und auch für den Flashspeicher der Boxen z.B. automatisch erstellt. Diese Erstellung stösst man über folgenden Befehl im Verzeichnis ~/yocto/yocto-poky-stl/build-stl an.

$ bitbake neutrino-image

Yocto beginnt nun die Recipies zu parsen und den jeweiligen Zustand in eine lokale SQLite3 Datenbank zu schreiben. Dies kann auf klassischen rotierenden Festplatten mehrere Minuten dauern, SSDs sind hier deutlich schneller. Folgender Output sollte in etwa zu sehen sein. Alle fehlenden Quellpakete werden automatisch aus dem Internet geladen.

NOTE: Started PRServer with DBfile: /home/carsten/yocto/yocto-poky-stl/build-stl/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 60605, PID: 13293
WARNING: Host distribution "Debian-8.0" has not been validated with this version of the build system; you may possibly experience unexpected failures. 
Parsing recipes: 100% |################################################################################################################################
Parsing of 965 .bb files complete (0 cached, 965 parsed). 1374 targets, 56 skipped, 2 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION        = "1.24.0"
BUILD_SYS         = "x86_64-linux"
NATIVELSBSTRING   = "Debian-8.0"
TARGET_SYS        = "sh4-poky-linux"
MACHINE           = "spark"
DISTRO            = "poky"
DISTRO_VERSION    = "1.7.1"
TUNE_FEATURES     = "sh4"
meta              
meta-yocto        
meta-yocto-bsp    = "dizzy:c59e3bd26d863723af7ba5e16570b091ef7cdc13"
meta-stlinux      = "master:08ee2062362eaf939aeed4516f89151265b08698"
meta-neutrino-mp  = "master:1d169c10fbc202ecc98321bd38c036676cb45ed6"

NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
WARNING: Failed to fetch URL http://zlib.net/pigz/pigz-2.3.1.tar.gz, attempting MIRRORS if available
WARNING: Failed to fetch URL http://downloads.sourceforge.net/expat/expat-2.1.0.tar.gz, attempting MIRRORS if available
WARNING: Failed to fetch URL ftp://ftp.debian.org/debian/pool/main/b/base-passwd/base-passwd_3.5.29.tar.gz, attempting MIRRORS if available
Currently 4 running tasks (603 of 2767):
0: perl-native-5.20.0-r0 do_compile (pid 27591)
1: glibc-2.20-r0 do_populate_sysroot (pid 13276)
2: glibc-2.20-r0 do_package (pid 14367)
3: glib-2.0-native-1_2.40.0-r0 do_configure (pid 14743)

Die "WARNING" Ausgaben sind in gewisser Weise normal und bedeuten kein Problem. Wenn ein Fehler auftritt wird dieser mit "ERROR" markiert und es erscheint eine sehr ausführliche Meldung wo der Build schief gelaufen ist mit zusätzlichen Angaben wo man die Logs zu diesem Vorgang findet.

Der Build dauert je nach Downloadgeschwindigkeit und Typ des Rechners teilweise mehrere Stunden wobei der längste Part das Kompilieren und Paketieren ist, auf einem i5 4x2,4GHz dauert es ca. 2h.

Images und Pakete

Alles was Yocto gebaut hat liegt nach dem erfolgreichen Durchlaufen eines bitbake Befehls im Unterverzeichnis tmp/deploy.

$ tree -d -L 2 tmp/deploy/
tmp/deploy/
├── images
│   └── spark
├── ipk
│   ├── all
│   ├── sh4
│   └── spark
└── licenses
    ├── ...

Die diversen Images

Die erstellten Images liegen wie der Name des Verzeichnisses schon vermuten lässt in tmp/deploy/images/spark. Um die erstellten Images zu richtig verwenden zu können muss man verstehen wie die Images aufgebaut sind und welcher Typ verwendet worden ist.

Die Yocto Recipies erstellen Images für den Flashspeicher in den Boxen als auch für einen USB-Stick der sich mit einem modifizierten U-Boot benutzen lässt. Die Images sind voll funktionsfähig da Yocto die benötigte Firmawaredateien audio.elf und video.elf für die beiden DSPs mit in die Images integriert hat.

Die Sparkboxen können intern im Flash mit dem UBI Filesystem oder auch JFFS2 benutzt werden. Die jeweilige Benutzung ist fast eine Frage des persönlichen Geschmacks.

HINWEIS:

Bitte mit Infos ergänzen.

Durch die Eigenheit dass das verwendete U-Boot keinen anderen Support als FAT16 für ein Filesystem eingebaut hat muss ein USB-Stick eine separate (1.) Partition für den Kernel besitzen damit dieser vom U-Boot aus geladen und gestartet werden kann. Die zweite Partition kann mit ext3 oder ext4 formatiert sein. Um dies muss man sich aber nicht kümmern da Yocto ein komplettes ISO Image erstellt hat welches man auf den USB-Stick schreiben kann. Jedoch sind auch Archive mit den benötigten Dateien für die einzelnen Partitionen des USB-Sticks erstellt worden.

Folgende Dateien sind nun im Ordner tmp/deploy/images/spark zu finden.

Übersicht Dateien in tmp/deploy/images/spark

Dateiname	Typ	Verwendung
modules--2.6.32.61-stm24-0217-r5.2-spark-[BUILD_DATE].tgz	Archiv	gepacktes Verzeichnis /lib/modules/* welches die Kernelmodule zum benutzten Kernel enthält
modules-spark.tgz	Symlink	Link auf modules--2.6.32.61-stm24-0217-r5.2-spark-[BUILD_DATE].tgz
neutrino-image-spark-[BUILD_DATE].rootfs.ext3	Image	2.Partion vom USB-Stick
neutrino-image-spark-[BUILD_DATE].rootfs.jffs2.sum	Image	Image für Flashspeicher
neutrino-image-spark-[BUILD_DATE].rootfs.manifest	Manifest Datei	Installierte Pakete in den Images
neutrino-image-spark-[BUILD_DATE].rootfs.spark71xx-usbimg	Image	Komplett Image für einen USB-Stick
neutrino-image-spark-[BUILD_DATE].rootfs.tar.gz	Archiv	gepacktes Archiv mit den Dateien für die 2.Partition auf dem USB-Stick
neutrino-image-spark-[BUILD_DATE].rootfs.ubi	Image
neutrino-image-spark-[BUILD_DATE].rootfs.ubifs	Image
neutrino-image-spark.ext3	Symlink	Link auf neutrino-image-spark-[BUILD_DATE].rootfs.ext3
neutrino-image-spark.jffs2.sum	Symlink	Link auf neutrino-image-spark-[BUILD_DATE].rootfs.jffs2.sum
neutrino-image-spark.manifest	Symlink	Link auf neutrino-image-spark-[BUILD_DATE].rootfs.manifest
neutrino-image-spark.spark71xx-usbimg	Symlink	Link auf neutrino-image-spark-[BUILD_DATE].rootfs.spark71xx-usbimg
neutrino-image-spark.tar.gz	Symlink	Link auf neutrino-image-spark-[BUILD_DATE].rootfs.tar.gz
neutrino-image-spark.ubi	Symlink	Link auf neutrino-image-spark-[BUILD_DATE].rootfs.ubi
neutrino-image-spark.ubifs	Symlink	Link auf neutrino-image-spark-[BUILD_DATE].rootfs.ubifs
uImage	Symlink	Link auf uImage--2.6.32.61-stm24-0217-r5.2-spark-[BUILD_DATE].bin
uImage--2.6.32.61-stm24-0217-r5.2-spark-[BUILD_DATE].bin	Datei	SH4 Kernelimage ST7111 für 1. Partition auf dem USB-STick
uImage--2.6.32.61-stm24-0217-r5.2-spark-[BUILD_DATE].bin-7162	Datei	SH4 Kernelimage ST7162 für 1. Partition auf dem USB-STick
uImage-7162	Symlink	Link auf uImage--2.6.32.61-stm24-0217-r5.2-spark-[BUILD_DATE].bin-7162
uImage-spark.bin	Symlink	Link auf uImage--2.6.32.61-stm24-0217-r5.2-spark-[BUILD_DATE].bin

Schreiben auf einen USB-Stick

Um einen USB-Stick zu erstellen gibt es mehrere Möglichkeiten. Der bequemste und wohl auch schnellste Weg dürfte das Schreiben des Komplettimages auf einen USB-Stick sein. Dabei muss der USB-Stick mindestens 1GB groß sein (das Komplettimage ist größer als 512MB so das man die nächste größere Kapazitätsstufe benutzen muss). Mit dem Befehl dd und sudo Berechtigungen kann man das Komplettimage auf den USB-Stick schreiben. Zuvor muss in Erfahrung gebracht werden unter welchen Devicenamen der USB-Stick ansprechbar ist, dies ist z.B. mit dem Befehl dmesg möglich. Dann kann man wie folgend das Image auf den USB-Stick schreiben, vorausgesetzt man befindet sich immer noch im Verzeichnis ~/yocto/yocto-poky-stl/build-stl. Passt die Angabe von sd[x] entsprechend Euren Gegebenheiten an!

$ sudo dd if=tmp/deploy/images/spark/neutrino-image-spark.spark71xx-usbimg of=/dev/sd[x] bs=1MB

Beachtet bitte das der Schreibvorgang sehr wahrscheinlich durch das Betriebssystem gecached wird. Am besten vor dem Abstecken des USB-Sticks per sync Befehl sicher stellen das alle Daten geschrieben sind.

Der USB-Stick kann wie erwähnt sofort verwendet werden, sofern die U-Boot Einstellungen auf der Spark STB schon entsprechend angepasst worden sind, wie das geht findet man auf der Seite Spark:U-Boot. Der erste Boot in der STB dauert etwas länger und es wird eventuell auch automatisch rebootet sofern man eine ST7162 basierte Box benutzt da diverse Symlinks intern beim ersten Booten erstellt werden müssen.