Neutrino-MP Entwicklungsumgebung

Aus TuxBoxWIKI
(Weitergeleitet von CS Development)
Wechseln zu: Navigation, Suche

Dieser Artikel soll Einsteigern, Versierten und Interessierten zeigen, wie man sich mit den momentan verfügbaren Buildsystem-Quellen eine minimale Buildumgebung aufbauen kann, mit der es möglich ist, fertige Distributionen basierend auf Neutrino-HD für verschiedene Platformen zu erstellen.

Das Buildsystem selbst enthält keine Quellen für Neutrino-HD, sondern ist nur als Modul zu verstehen und dient als Werkzeug zum Bauen von Neutrino-HD-Binaries oder Images bzw. Distributionen, die auf USB-Sticks oder in Form von OPKG-Paketen verfügbar gemacht werden können. Dieses System ist dafür ausgelegt, USB- u. Flash-Images für verschiedene Platformen herzustellen. Ausserdem verwendet es ein angepasstes OPKG-Installationssystem, wodurch lästiges Flashen unnötig ist und für Distributoren sehr praktische Möglichkeiten für die Verteilung von Up- bzw. Upgrades bietet.

Die Erstellung von Flash-Images ist ebenfalls möglich und benötigt lediglich einige Erweiterungen, um die Images für den jeweiligen Bedarf anpassen zu können. Siehe Flashimage bauen.

Voraussetzungen

Zunächst sollte sichergestellt sein, dass genügend Festplattenspeicher (> 20 GB), vernünftige Rechnerleistung und ein möglichst schneller Internetzugang zur Verfügung steht. Aktuelle Mehrkernrechner sollten damit allemal zurechtkommen. Weiterhin benötigt man eine aktuelle Linux-Distribution wie z.B. OpenSUSE 11.3, 11.4, die man auch auf virtuellen Systemen wie z.B. VMWare oder VirtualBox verwenden kann. Nur zur Orientierung, für die Kompilierung einer Crosstool Umgebung auf einem WindowsXP-Rechner mit VMware-basiertem OpenSUSE 11.3 System und AMD Phenom 9750 Quadcore-Rechner mit 2.4 GHz ca. 4GB RAM benötigt man ca. 1h. Diverse Grundkenntnisse im Umgang mit der Kommandozeile (Shell), Subversion und Git sollte man mitbringen.

Unterstützte Plattformen

Es kann auch für native PC-Systeme gebaut werden. Mit einigen Modifikationen sollten noch weitere Plattformen möglich sein. Patche sind hierfür willkommen und können an die entsprechende Mailingliste oder Foren geschickt werden.

Benötigte Tools

Es werden diverse Programme und Tools benötigt, die installiert sein müssen, um fehlerfrei bauen zu können. Falls nötig, muss man diese nachinstallieren: Hier als Beispielinstallation für OpenSUSE 11.2 i386, andere Distribution haben möglicherweise ähnliche Paketnamen. Einige andere Pakete werden während der Installation wegen diverser Abhängigkeiten nachgeladen. Das Nachladen erfolgt vom Buildsystem meist mit wget, jedoch kann es auch vorkommen, dass für einige Tools oder Libs die nachgeladen werden, Tools wie Mercurial (hg) benötigt werden. Diese lassen sich ebenfalls in der Regel nachinstallieren (z.B. mit Yast). Ebenso kann es auch sein, dass die hier angegebenen Tools unter Umständen nicht für alle Plattformen notwendig sind. 

zypper install --no-recommends \
 	git make subversion patch \
 	gcc bison flex texinfo gettext\
 	automake libtool ccache \
 	ncurses-devel pkg-config cmake zlib-devel zlib-devel-static lzo-devel genromfs

Weiterhin wird noch benötigt:

  • mkimage


Stop hand.png TIPP:

OpenSuse.org bietet für mehrere Distributionen (z.B. auch Debian) praktische Paketsuchfunktionen an, womit man recht schnell und einfach diverse Pakete nachinstallieren kann. Die Benutzung der Paketverwaltung des benutzten Systems ist aber auf jeden Fall zu bevorzugen!

Beispiele:

  • mtd-utils (wird zur Herstellung von Flashimages benötigt) Für OpenSuse kann man dies z.B. direkt hier vornehmen.
  • unp siehe hier
Stop hand.png HINWEIS:

Wer ein Debian Wheezy 64Bit als Linuxsystem einsetzt und für die SH4 Plattformen bauen will muss noch fehlende Libraries (zu finden im Paket ia32-libs) installieren. Debian Wheezy unterstützt nun komplett Multiarch Installationen. Das heißt man kann andere Libraries für andere Architekturen zusätzlich installieren. Der Crosscompiler für SH4 hat Bindings zu 32Bit Libraries, die natürlich auf einer 64Bit Umgebung fehlen. Dank der Multiarchunterstützung kann man diese aber sehr einfach nachinstallieren. Zunächst muss man i386 als zusätzliche Architektur hinzufügen und kann danach das Paket ia32-libs installieren. 

sudo dpkg --add-architecture i386 && sudo apt-get update

Für Debian Squeeze oder Wheezy basierte Systeme, diese Pakete verwenden: 

apt-get install --yes \
 	git git-gui make subversion patch ia32-libs \
 	gcc bison flex texinfo gettext autopoint gawk \
 	automake libtool zlib1g-dev libglib2.0-dev gperf \
 	ncurses-dev pkg-config cmake ccache lzma rpm2cpio genromfs


Stop hand.png HINWEIS:

Unter Ubuntu als auch unter Debian ab Squeeze (Debian 6.x) muss die Systemshell noch angepasst werden. Viele Buildtools sind (noch) nicht auf die Dash abgestimmt, deswegen sollte /bin/sh auf /bin/bash zeigen. Siehe auch: Bash vs. Dash. Zum Anpassen benutzt man dpkg-reconfigure (siehe Debian Wiki) was in weiterer Zukunft eventuell nicht mehr nötig sein wird. 

dpkg-reconfigure dash

Auschecken der Buildsystem Quellen

Die benötigten Quellen für das Buildsystem liegen auf Gitorious, einem Open Source Project Hoster, vergleichbar mit GitHub oder auch SourceForge und werden von Seife verwaltet. Es nennt sich einfach "buildsystem-cs". Zudem gibt es dort noch weitere "Ableger", sog. Clones, welche einige zweckgebundene Eigenheiten aufweisen, auf die im Artikel bei Bedarf hingewiesen wird. Die Original Buildsystem-Quellen von Coolstream sind nicht öffentlich.

Config: 

PLATFORM=tripledragon

Andere Geräte, so auch Coolstream oder Spark erfordern den passenden Eintrag in der config: 

PLATFORM=coolstream

PLATFORM=spark


Stop hand.png HINWEIS:

Weitere Informationen zu unterstützten Plattformen im Forum oder direkt in der Dokumentation des Buildsystems

Klonen

Um Quelldaten mit Git von einem Server auf seinen Lokalen Rechner, wie man es von CVS oder Subversion kennt, zu bekommen, spricht man vom Klonen. Allerdings entspricht dieser Vorgang nicht wirklich dem Auschecken wie man es von CVS oder SVN kennt.

Git ist ein verteiltes System und somit nicht vom entfernten Repo abhängig, wie bei CVS oder SVN. Man checkt erst lokal einen Branch aus. Standardmäßig ist dies nach dem Klonen der "master"-Branch, den man wie ein Remoterepo behandelt. Alles weitere wie z.B. Branching und Comitten wird nur lokal in eigenen Branches gemacht, jedoch nicht auf den "master". Lokale Commits auf den Master sind zwar möglich, sollte man aber vermeiden. Dies ist in der Regel den Maintainern des Remote-Repos vorbehalten. Dieser dient lediglich dem regelmäßigen Abgleichen mit dem Remote-Repo (pull) und rebased oder vereinigt nur immer seine lokalen Branches mit dem Master! Siehe auch Git Workflow

Man legt zunächst einen Ordner an wo man das Buildsystem ablegt. 

you@machine:~mkdir $HOME/coolstream

in diesen wechseln: 

you@machine:~cd $HOME/coolstream

klonen: 

you@machine:~/coolstream> git clone git://gitorious.org/neutrino-hd/buildsystem-cs.git buildsystem-cs

Die Ausgabe sollte nun etwa so aussehen: 

Cloning into buildsystem-cs...
remote: Counting objects: 2891, done.
remote: Compressing objects: 100% (2583/2583), done.
remote: Total 2891 (delta 1813), reused 414 (delta 208)
Receiving objects: 100% (2891/2891), 5.60 MiB | 1.41 MiB/s, done.
Resolving deltas: 100% (1813/1813), done.

Buildsystem vorbereiten

Verzeichnisse anlegen

Beim Klonen wurde automatisch ein Unterordner erzeugt in den man nun wechselt: 

you@machine:~/coolstream> cd buildsystem-cs

Nun einen Ordner anlegen, wo diverse Archive abgelegt werden können, die während des Buildvorganges heruntergeladen werden: 

you@machine:~ mkdir download

alternativ kann man auch einen bereits vorhandenen Archiv-Ordner verwenden den man hier verlinkt 

you@machine:~/coolstream/buildsystem-cs> ln -sf $HOME/<dein vorhandenes Archiv> download

Konfiguration

Im Ordner .../buildsystem-cs eine Datei namens config anlegen und anhand dieses Beispiels anpassen (im Ordner .../buildsystem-cs/doc befindet sich auch eine Beispieldatei namens config.example, welche als Vorlage dienen kann)

Stop hand.png HINWEIS: Die folgenden Beispiele sind lediglich Vorschläge und müssen möglicherweise je nach lokalen Gegebenheiten noch angepasst werden!
# The type of box to build for.
# either "tripledragon" or "coolstream"
# default (if empty) is "coolstream"
PLATFORM=coolstream
 
# if you want to use your precompiled toolchain, define those variables:
# this will skip the building of our own compiler/glibc combination!
#
# ONLY CHANGE THOSE VARIABLES IF YOU KNOW WHAT YOU ARE DOING!
#
# do not set this if you want to build a toolchain with these makefiles.
#CROSS_DIR=/opt/cross
#TARGET=arm-linux-gnueabi

# if /usr/share/libtool/config/config.guess does not supply a valid
# build type, specify it here. THIS IS A WORKAROUND. Use with caution.
# BUILD=x86_64-unknown-linux-gnu

#
#
# set the flavour of neutrino you want to build
# "neutrino-hd":              use git://gitorious.org/neutrino-hd/neutrino-hd-experimental.git
# "neutrino-hd-tripledragon": use git://gitorious.org/neutrino-hd/neutrino-hd-tripledragon.git
# empty: choose one of the above depending on PLATFORM
FLAVOUR=neutrino-hd

#
# configure the directory where "make dist-pkgs"
# PKG_DEST_DIR = /srv/www/dist/$(PLATFORM)

#
# the name used to replace "@MAINT@" in the opkg control files
# defaults to your name from the passwd GECOS field
#
MAINTAINER = "<dein Name>"

Die Quellen des Buildsystems, die benötigen Archivordner und Konfiguration sollten nun stehen. Jetzt fehlen noch die Vorbereitungen, um richtig loszulegen. Die kann das Buildsystem nun mittels Targets jetzt selbst erledigen.

Welche Make-Targets gibt es?

Einen kleinen Überblick über verfügbare Make-Targets gibt dieses Kommando: 

you@machine:~/coolstream/buildsystem-cs> make print-targets

Welche Umgebungsvariablen gibt es?

Anzeige diverser Umgebungsvariablen: 

you@machine:~/coolstream/buildsystem-cs> make printenv

Makefile.local

Neben den fest verbauten Targets, welche im Buildsystem bereits vorhanden sind, kann man auch eigene Targets anlegen. Hierfür wird eine lokales Makefile namens Makefile.local im Stammverzeichnis benötigt, welches man mit eigenen Targets befüllen kann.

TIP: Es kann sinnvoll sein, auf diese Datei einen Symlink mit der Dateiendung .mk anzulegen. z.B: Makefile.local.mk. Editoren können unter Umständen dann auch diesen Typ erkennen und passendes Syntax-Highlighting für Makefiles anzeigen, was durchaus hilfreich sein kann.

Start

Prinzipell sind diese 3 Kommandos der Reihe nach zuerst auszuführen: 

 make preqs
 make crosstool
 make bootstrap

Sehr zu empfehlen, der Einsatz von ccache: 

 make ccache

Die kann bei mehrmaligen Baudurchgängen, die Bauzeit erheblich verkürzen!


Stop hand.png HINWEIS zu make crosstool (Toolchain bauen):

Beim Bauen der Crosstoolumgebung könnte es evtl. Probleme mit LD_LIBRARY_PATH geben 

...Don't set LD_LIBRARY_PATH. It screws up the build.

Dieses Kommando behebt das Problem und kann vorsorglich ausgeführt werden. 

you@machine:~/coolstream/buildsystem-cs> unset LD_LIBRARY_PATH

Das dauert jetzt natürlich eine Weile, aber muss auch nur einmal gemacht werden. Alternativ kann man auch ein bereits vorhandenes Crosstool verwenden. Hierfür muss in der config der Ordner angegeben werden wo sich das Crosstool befindet Dazu diesen Eintrag anpassen: 

CROSS_DIR=$HOME/[dein Verzeichnis zum Croostoool]

Neutrino-HD bauen

you@machine:~/coolstream/buildsystem-cs> make bootstrap
you@machine:~/coolstream/buildsystem-cs> make neutrino

Das dauert natürlich auch wieder etwas, aber am Schluß sollte alles Relevante gebaut worden sein und unter

$HOME/coolstream/buildsystem-cs/root/

zu finden sein. Achtung! Dies an sich reicht noch nicht aus um ein komplettes Filesystem zusammen bauen zu können!

Neutrino-HD Quellen updaten und neu bauen

Wenn man die Buildumgebung neu erstellt wird automatisch die aktuelle Version von Neutrino-HD aus dem Git Repo geholt. Will man aber nach ein paar Tagen z.B. Neutrino-HD neu bauen, muss man natürlich die Neutrino-HD Quellen updaten, da die Entwicklung von Neutrino-HD schließlich voran schreitet. 

you@machine:~/coolstream/buildsystem-cs> make update-neutrino

Damit werden nur die aktuellsten Sourcen für Neutrino-HD aus dem jeweiligen Git Repo geholt.

Coolstream Library updaten


Stop hand.png HINWEIS:

Da sich von Zeit zu Zeit auch die Coolstream-Library libcoolstream-mt.so ändert, sollte man vor dem erneuten Bau von Neutrino-HD diese zuerst auf den neuesten Stand bringen damit beim Bauen später keine Probleme auftreten können. Eine veraltete Version von libcoolstream-mt.so kann trotz erfolgreicher Kompilierung zu gravierenden Laufzeitfehlern (Abstürze etc.) führen und die erzeugten Binaries im schlimmsten Fall unbrauchbar machen!

Hierfür diese Targets ausführen: 

you@machine:~/coolstream/buildsystem-cs> make update-svn

Und dann diese Libraries ins Buildsystem einpflegen lassen. 

you@machine:~/coolstream/buildsystem-cs> make update-svn-target

Nun das selbe für eventuell benötigte Header von Coolstream durchführen, den Makeaufruf kennt man schon vom erstmaligen Bauen von Neutrino-HD. Anschließend kann der Bau angestoßen werden. 

you@machine:~/coolstream/buildsystem-cs> make bootstrap
you@machine:~/coolstream/buildsystem-cs> make neutrino


Stop hand.png HINWEIS:

Man kann diese Makeaufrufe auch alle kombinieren (aber dann in genau dieser Reihenfolge!). Man könnte unten aufgeführte beide Aufrufe auch zu einem zusammen fassen, dies macht dann aber eine Problemsuche unter Umständen schwieriger! 

you@machine:~/coolstream/buildsystem-cs> make update-neutrino update-svn update-svn-target
you@machine:~/coolstream/buildsystem-cs> make bootstrap neutrino

Extras kompilieren

Beispiel: wie man sich den Midnight Commander baut 

make mc
make pkg-index
make dist-pkgs

OPKG-Pakete

Voraussetzungen

Damit man dieses System benutzen kann, benötigt man ein fertig! eingerichtetes Neutrino Buildsystem von Seife sowie einen USB-Stick mit mindestens 512MB freiem Speicher und angepasste Bootargumente im UBoot der entsprechenden Box, damit diese vom USB-Stick überhaupt booten kann.

Unterstützte Hardware Plattformen sind aktuell die Boxen von Coolstream und die SPARK RELOADED von Golden Media.

USB Stick erstellen

Für das Präparieren eines USB-Sticks kann man das fertige Script unter scripts/mkusbimage.sh benutzten.

OPKG Pakete erzeugen

Ein Grossteil aller Targets im Buildsystem mit denen die Libraries, Tools und Binaries erstellt werden, bauen auch automatisch die entsprechenden OPKG Pakete mit. Wenn man eigene Pakete erstellt oder wenn man ein fehlendes aber benötigtes Paket bauen will, muss man sich um das erstellen der OPKG Pakete selbst kümmern bzw. das jeweilige Target anpassen. Hilfe ist in diesem Fall willkommen und man kann seine Änderungen dem Maintainer gerne zukommen lassen. Siehe dazu auch Git Patch erstellen und versenden.

Beispiele für die Erzeugung minimaler Systeme mit lauffähigem Neutrino


Stop hand.png HINWEIS:

Das Buildsystem muss die Targets

  • preqs
  • crosstool und
  • bootstrap

erfolgreich durchlaufen haben! Siehe auch doc/README.first!

Minimales Root Filesystem erzeugen

Dazu dient der Aufruf des Targets minimal-systems-pkg. Dabei wird ein einfaches Basis Filesystem erstellt was auf einen USB Stick kopiert werden kann. 

$ make minimal-system-pkgs
... # lauter Build Ausgaben
tar -czf /home/user/gitprojects/buildsystem-cs/build_tmp/min-root-coolstream.tar.gz \
                --owner=0 --group=0 -C /home/user/gitprojects/buildsystem-cs/build_tmp/install .

=====================================================================
A minimal system has been installed in build_tmp/install.
A tarball of this installation was created as
build_tmp/min-root-coolstream.tar.gz
Unpack this onto an empty root fs, which will enable you to install
further packages via 'opkg-cl' after configuring in /etc/opkg/.
List of installed packages:
        aaa_base        1-6
        busybox         1.18.4-2
        glibc-debug     2.8-1
        libncurses      5.6-1
        opkg            0.1.8-1
        procps          3.2.8-1

Have a lot of fun...

Die Ausgabe erfolgt nach build_tmp/install, dort befindet sich nun das einfache Filesystem.

Filesystem mit Neutrino erstellen

Alternativ gibt es ein Target mit dem die obigen System Pakete gebaut werden und zusätzlich auch noch Neutrino. Hierfür ist es sinnvoll natürlich vor einem Build die Neutrinosourcen neu abzugleichen, sofern nicht schon zuvor geschehen. 

$ make update-neutrino update-svn update-svn-target cs-drivers-pkg cs-libs-pkg
$ make system-pkgs
...
Configuring libz.
Configuring libvorbisidec.
Configuring libcurl.
Configuring libOpenThreads.
Configuring libpng.
Configuring ffmpeg.
Configuring cs-drivers.
Configuring cs-libs.
Configuring libfreetype.
Configuring libid3tag.
Configuring libjpeg-turbo.
Configuring libmad.
Configuring libungif.
Configuring neutrino-hd.

Systemtools erzeugen

Will man ein Filesystem erstellen in dem die meisten Systemtools vorhanden sind bzw. zusätzlich als OPKG Paket gebaut werden dann benutzt man wiederum ein separates Target system-tools-all dafür. Dieses ist zusätzlich zum Target system-pkgs auszuführen. 

$ make system-tools-all
$ make system-pkgs

OPKG Package von Neutrino neu erzeugen

Wollt Ihr nur ein neues OPKG Paket für Neutrino erstellen, ohne alle System-Pakete neu zu bauen, dann geht das natürlich auch. Nach dem Build nicht vergessen den Paketindex auch neu zu erstellen! 

$ make update-neutrino update-svn update-svn-target
$ make neutrino neutrino-pkg pkg-index


Stop hand.png Tip:

Man kann sich ein eigenes Makefile namens Makefile.local parallel zum original Makefile anlegen, welches sich im Stammverzeichnis des Buidlsystems befindet und darin ein eigenes Target festlegen. Damit lassen sich gewisse Vorgänge vereinfachen. Um z.B. die vorher genannten Aufrufe zu bündeln, wird folgender Eintrag in Makefile.local angelegt: 

neutrino-hd: update-neutrino update-svn update-svn-target neutrino neutrino-pkg pkg-index

Jetzt reicht der Aufruf: 

make neutrino-hd


Stop hand.png HINWEIS:

Wenn Ihr längere Zeit das Buildsystem nicht aktualisiert habt dann ist möglicher Weise vor diesen Makeaufrufen noch ein 

$ make bootstrap

nötig! Es schadet aber auch nie dies vorher aufzurufen.

USB-Stick vorbereiten

Der einfache Weg

Nachdem das Filesystem erfolgreich zusammen gestellt worden ist kann man ein Script nutzen welches im Buildsystem von seife enthalten ist um alle nötigen Daten auf einen USB-Stick schreiben zu können.

Stop hand.png Achtung!

Das Script erstellt nur ein Image welches dann mit zusätzlichen Tools auf einen USB-Stick geschrieben werden muss!

Um also ein USB Image zu erstellen ruft Ihr das Script scripts/mkusbimage.sh auf. 

$ ./scripts/mkusbimage.sh

Der Punkt am Anfang ist wichtig und richtig! 

1+0 Datensätze ein
1+0 Datensätze aus
ein Byte kopiert, 2,158e-05 s, 46,3 kB/s
WARNING: You are not superuser.  Watch out for permissions.
WARNING: You are not superuser.  Watch out for permissions.
WARNING: You are not superuser.  Watch out for permissions.
add map loop0-usbstick-1 (252:0): 0 29296 linear /dev/loop0 1
add map loop0-usbstick-2 (252:1): 0 947265 linear /dev/loop0 29297
mkdosfs 3.0.9 (31 Jan 2010)
unable to get drive geometry, using default 255/63
mke2fs 1.41.12 (17-May-2010)
Dateisystem-Label=root-fs
OS-Typ: Linux
Blockgröße=1024 (log=0)
Fragmentgröße=1024 (log=0)
Stride=0 Blöcke, Stripebreite=0 Blöcke
118784 Inodes, 473632 Blöcke
23681 Blöcke (5.00%) reserviert für den Superuser
Erster Datenblock=1
Maximale Dateisystem-Blöcke=67633152
58 Blockgruppen
8192 Blöcke pro Gruppe, 8192 Fragmente pro Gruppe
2048 Inodes pro Gruppe
Superblock-Sicherungskopien gespeichert in den Blöcken: 
        8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409

Schreibe Inode-Tabellen: erledigt                        
Erstelle Journal (8192 Blöcke): erledigt
Schreibe Superblöcke und Dateisystem-Accountinginformationen: erledigt

Das Dateisystem wird automatisch nach jeweils 20 Einhäng-Vorgängen bzw.
alle 180 Tage überprüft, je nachdem, was zuerst eintritt. Dies kann durch
tune2fs -c oder -i geändert werden.
del devmap : loop0-usbstick-2
del devmap : loop0-usbstick-1
loop deleted : /dev/loop0

the usb boot image is now in build_tmp/usb.img

-rw-r--r-- 1 user user 500000000  1. Jun 21:19 build_tmp/usb.img

Das fertige Image findet Ihr unter build_tmp/usb.img wie aus der letzten Zeile der Ausgaben zu erkennen ist.

Der händische Weg

Um den Inhalt von build_tmp/install auf den USB-Stick kopieren zu können, muss dieser vorbereitet sein. Der Stick muss zwei Partitionen besitzen. Die erste Partition muss mit FAT16 formatiert sein und dient der Aufnahme der Kernelimages. Die zweite Partition muss mit ext3 formatiert sein. Den Inhalt des oben genannten Ordners kopiert man auf die zweite Partition (ext3) vom USB-Stick.

Diese Vorgehensweise ist immer dann etwas praktischer, wenn man selektiv neue Dateien auf den Stick kopieren will und schon einmal diesen Schritt durchlaufen hat. Einen passenden Stick erhält man durch den folgenden Schritt.

USB-Images auf einen Stick kopieren

Hier unterscheiden sich die Wege naturgemäß, je nach dem ob man dies mit einem Windows System oder einem Linux machen will. Wichtig ist das der Stick mindestens die gleiche Größe wie das Image besitzt. Im Standardfall ohne weitere Anpassungen erzeugt das Script von oben ein Image von 500MB. Somit sollte der Stick mindestens 512MB groß sein. Größere Sticks gehen natürlich auch, nur macht dies dann wegen der unvorteilhaften Nutzung des Flashspeichers nur bedingt Sinn.

Unter Linux:

Hier gibt es mehrere Möglichkeiten. Zum einen mit dem klassischen dd Befehl. Um zu wissen auf welches Device das Image geschrieben werden muss prüft unter welchen Device der USB-Stick im System eingebunden worden ist. Am einfachsten geht dies mittel dmesg | grep sd. Im folgenden wurde ein 512MB Stick eingesteckt und erkannt. Prüft gfs. noch ob der Stick nicht durch einen Autmount eingehangen wurden ist! 

$ dmesg | grep sd
...
[ 1430.532086] usb 1-2: new high speed USB device number 8 using ehci_hcd
[ 1430.669241] scsi6 : usb-storage 1-2:1.0
[ 1431.696127] scsi 6:0:0:0: Direct-Access     SanDisk  Cruzer Mini      0.2  PQ: 0 ANSI: 2
[ 1431.699909] sd 6:0:0:0: Attached scsi generic sg3 type 0
[ 1431.699994] sd 6:0:0:0: [sdc] 1000944 512-byte logical blocks: (512 MB/488 MiB)
[ 1431.702007] sd 6:0:0:0: [sdc] Write Protect is off
[ 1431.702022] sd 6:0:0:0: [sdc] Mode Sense: 03 00 00 00
[ 1431.702032] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[ 1431.707669] sdc: sdc1
[ 1431.710470] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[ 1431.710479] sd 6:0:0:0: [sdc] Attached SCSI removable disk

Der Stick wurde unter /dev/sdc eingebunden. Dieses Device benötigen wir nun als Angabe des Zieles. 

$ dd  if=build_tmp/usb.img of=/dev/sdc bs=1M

Vorteil dieser Methode ist das Ihr dies mit Userrechten ausführen könnt. Ein zweite Möglichkeit ist die Benutzung eines Pythonscriptes. Dies setzt natürlich die Installation von Python voraus!

Ladet Euch das Script tools_moblin-image-writer von http://git.moblin.org in einen Ordner Eurer Wahl. Danach das Script ausführbar machen: 

chmod +x image-writer

Dieses Script benötigt allerdings Superuser Berechtigungen und Python zur Ausführung. Es fragt bei mehreren erkannten USB Devices nach auf welches geschrieben werden soll. 

$ sudo ~/Downloads/image-writer /home/user/path/to/buildsystem/build_tmp/usb.img
Multiple USB drives discovered:
1) /dev/sdb
2) /dev/sdc
 Select the USB drive to use (1-2): 1
Warning:  The USB drive (/dev/sdb) will be completely erased!
 Do you want to continue anyway? (y/n) y
Source:      /home/carsten/gitprojects/buildsystem-cs/build_tmp/usb.img
Size:        476 MB
Destination: /dev/sdb
Writing image (Est. 1min 35sec)... 100%
122070+1 Datensätze ein
122070+1 Datensätze aus
500000000 Bytes (500 MB) kopiert, 167,698 s, 3,0 MB/s

The image was successfully written to the USB drive
You may now boot your mobile device with this USB drive

Unter Windows:

Zum Beschreiben eines USB-Sticks unter Windows empfiehlt sich der Win32DiskImager.

Mit diesem Tool kann das oben erstellte Image mit einem aktuellen Windowsbetriebssystem auf einen Stick geschrieben werden. Ladet Euch dazu das Archiv win32diskimager-RELEASE-0.2-r23-win32.zip auf Euren Windows-PC und entpackt das Tool in einen separaten Ordner.

Nun steckt den USB Stick ein und startet in dem Ordner wohin der Inhalt des Archives entpackt wurde einfach die Win32DiskImager.exe. Dazu werden Administratorrechte benötigt.

In dem Tool einfach das Image und den Buchstaben wo der USB-Stick eingebunden worden ist auswählen und schließlich mit dem Write-Button den Schreibvorgang starten.

Win32diskimager-usbimage-write.png

OPKG Client-Server Einrichtung

Die oben genannten Schritte bauen alle OPKG Pakete die möglich sind. Nicht alle Tools und AddOns werden auch im Filesystem abgelegt sondern müssen dann per OPKG nachinstalliert werden. Um diese OPKG Pakete selbst nachinstallieren zu können benötigt Ihr einen Webserver im Netz und eine entsprechende Konfiguration auf der STB.

OPKG Client auf der STB einrichten

Die Konfigurationsdatei für das OPKG Tools muss in /etc/opkg/ erstellt werden. Als Vorlage gibt es die Datei opkg.conf.example. Diese copiert Ihr einfach in opkg.conf. 

cp /etc/opkg/opkg.conf.example /etc/opkg/opkg.conf

Nun diese Datei entsprechend Euren Gegebenheiten anpassen. Der Aufbau sollte selbsterklärend sein.

OPKG Webserver konfigurieren

Eine spezielle Konfiguration des Webservers für OPKG ist nicht nötig, es reicht ein Verzeichnis innerhalb des Webcontents anzulegen, in dem die Pakete abgelegt werden können. Diese Pakete befinden sich im Rootverzeichnis des Buildsystemverzeichnisses unter /pkgs/opkg. Beachtet die nötigen Berechtigungen, damit der http Server die Dateien auch lesen kann!

Flashimage bauen

Hierfür sind nur wenige Vorbereitungen notwendig. Der größte Aufwand liegt evtl. darin, eigene Daten mit in ein Image zu packen, wobei dies nur von persönlichen Ansprüchen her ins Gewicht fällt.

Das zuständige Target für die Flashimage-Erzeugung hat die Möglichkeit, automatisch lokale Dateien einzupflegen. Hierfür muss im Stammverzeichnis des Buildsytems nur ein Vereichnis namens ./local/flash angelegt sein, welches die Dateien enthält. Die Struktur ist ähnlich zu verstehen, wie das bereits in ./skel-root/[PLATFORM] der Fall ist.

Obligatorisch kann man auch die Daten ebenfalls nach ./root einpflegen lassen und kann einen entsprechenden Symlink auf ../flash setzen. Die lokalen Daten werden dann nicht nur ins Flashimage eingepflegt, sondern auch nach ./root. Ein einfaches benutzerdefinierte Target (local-files) erledigt diese Schritte in Handumdrehen. Einfach im Stammverzeichnis des Buildsystems eine Datei namens Makefile.local erstellen und mit diesem Inhalt ausfüllen. Das benutzerdefinierte Target neutrino-dist, sollte genügen um fertige Images zu erzeugen. In diesem Beispiel für Neo/Neo-Twin: 

LOCALROOT       = $(BASE_DIR)/local
local-files:
	if [ ! -d $(LOCALROOT)/root ]; then \
		mkdir -p $(LOCALROOT)/root && \
		ln -sf $(LOCALROOT)/root $(BASE_DIR)/local/flash; \
	fi; \
	rsync -avP --exclude=*.*~ $(LOCALROOT)/root $(BASE_DIR)

trim-glib: 
	rm -f $(BASE_DIR)/pkgs/opkg/glibc-2.*.opk

neutrino-dist: preqs crosstool bootstrap cs-drivers-pkg cs-libs-pkg minimal-system-pkgs wget neutrino-pkg trim-glib install-pkgs dist-pkgs

Dann: 

make neutrino-dist

Die Flash-Images liegen dann unter: 

./build_tmp

bzw. Images, die mit einem Rettungs/Update-USB-Stick geflasht werden können, unter: 

./build_tmp/coolstream


Weblinks

Quellcodes

Abgerufen von „https://wiki.tuxbox-neutrino.org/w/index.php?title=Neutrino-MP_Entwicklungsumgebung&oldid=17619“