Neutrino-MP Entwicklungsumgebung

Aus TuxBoxWIKI
Version vom 1. Juli 2011, 22:27 Uhr von Tijuca (Diskussion | Beiträge) (→‎Wittinobis Buildsystem: Anpassen Syntaxhighlighting)
Wechseln zu: Navigation, Suche


Review-KandidatDieser Artikel befindet sich derzeit im Reviewprozess. Hilf mit, ihn zu verbessern! Falls du bei weiteren Artikeln helfen willst, findest du hier eine Auswahl offener Artikel.

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, Neutrino-HD relevante Teile zu erstellen.

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. 3GB RAM benötigt man ca. 1h. Diverse Grundkenntnisse im Umgang mit der Kommandozeile (Shell), Subversion und Git sollte man mitbringen.

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. 

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

Nötigenfalls müssen mtd-utils ebenfalls nachinstalliert werden. Unter OpenSuse kann man dies z.B. direkt hier vornehmen.

Für Debian basierte Systeme, diese Pakete verwenden: 

apt-get install --yes \
 	git git-gui make subversion patch \
 	gcc bison flex texinfo autopoint \
 	automake libtool zlib1g-dev libglib2.0-dev \
 	ncurses-dev pkg-config cmake ccache


Stop hand.png HINWEIS:

Unter Ubuntu als auch unter Debian ab Squeeze (Debian 6.x) muss die Systemshell noch angepasst werden. Viele Buildtools sind nicht auf die Dash abgestimmt, deswegen sollte /bin/sh auf /bin/bash zeigen. Siehe auch: Bash vs. Dash. Mit root Berechtigungen folgenden Symlink erstellen. 

ln -sf /bin/bash /bin/sh
In weiterer Zukunft ist dies eventuell nicht mehr nötig.

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. Das Buildsystem selbst enthält keine Quellen für Neutrino-HD, sondern kann man als Modul 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.

Auswahl des Buildsystems

Hier wird auf 3 Buildsyteme eingegangen:

  • buildsystem-cs
  • tijucas-buildsystem-cs

Diese beiden, sind fast identisch, jedoch sind in tijucas-buildsystem einige Erweiterungen enthalten, auf die wie schon angedeutet wurde, bei Bedarf hingewiesen wird, wobei im Zuge der Entwicklung nicht auszuschließen ist, dass davon auch in Seifes Buildsystem einiges übernommen wird. Grundsätzlich ist es aber so, dass tijucas-buildsystem genau so verwendbar ist wie Seifes. Es ist aber zu beachten, das es durchaus vorkommen kann, das in diesem Buildsystem auf Grund des experimentellen Charakters auch mal zu Buildfehlern oder zu nicht einwandfrei funktionierenden Binaries kommen kann!

Beide Systeme sind dafür ausgelegt, USB- u. Flash-Images zu erstellen, wobei die Erstellung von Flash-Images derzeit noch weitestgehend unerprobt ist, aber es geht und benötigt lediglich einige Erweiterungen, um die Images für den jeweiligen Bedarf anpassen zu können.

  • wittinobis-buildsystem-cs

Dieses Buildsystem ist hauptsächlich darauf ausgelegt Flash-Images zu erstellen.

Es basiert auf einen früheren Stand von Seifes-Buildsystem und weicht daher in einigen Details deutlich von den anderen Beiden ab und ist auch in der Wartung nicht immer konform mit den oben genannten und scheint auch etwas störanfälliger in Bezug auf Konsistenz und Verarbeitung von Abhängigkeiten zu sein. Es empfiehlt sich daher, sich genau an die im Buildsystem befindlichen Readme-Lists zu halten und Fehler dem Maintainer zu melden.

Klonen

Beim Auschecken via. Git spricht man vom Clonen, dabei werden von einem entfernten Repository (kurz. Repo = remote) die benötigten Daten auf das lokale System übertragen. Das ist also vergleichbar mit dem Checkout wie bei CVS oder SVN. Man ist jedoch nicht vom entfernten Repo abhängig, wie man es von CVS oder SVN her kennt. Alles weitere wird lokal gemacht!

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

you@machine:~mkdir $HOME/coolstream


und wechselt in diesen: 

you@machine:~cd $HOME/coolstream


Nun das Kommando für's Klonen eingeben:

seifes-buildsystem-cs

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


tijucas-buildsystem-cs

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


wittinobis-buildsystem-cs

you@machine:~/coolstream> git clone git://gitorious.org/~wittinobi/neutrino-hd/wittinobis-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.

Verzeichnisse anlegen

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

Stop hand.png HINWEIS: Die folgenden Beispiele sind lediglich Vorschläge und müssen möglicherweise je nach lokalen Gegebenheiten noch angepasst werden!

Seife/Tijucas Buildsystem

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

Wittinobis Buildsystem

Hierfür ist diese Konfiguration zu empfehlen. 

# if you want to use your precompiled toolchain, define those variables:
# this will skip the building of our own compiler/glibc combination!
#CROSS_DIR=/opt/newcross/arm-cx2450x-linux-gnueabi
TARGET=arm-cx2450x-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

# if you want to build your own toolchain, with "make crosstool",
# comment out the above settings of CROSS_DIR *and* TARGET and uncomment this.
# DO NOT SET CROSS_DIR IN THIS CASE
#TARGET=arm-cx2450x-linux-gnueabi

Buildsystem vorbereiten

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 help

bei wittinobi's System: 

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

Quellen holen

Nun dieses Kommando ausführen: 

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

bei wittinobi's System: 

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

Jetzt werden alle weiteren Quellen geholt.

Optionale Quellen einbinden

Dies kann nützlich sein, wenn man mehr als nur die originalen Neutrino-HD-Quellen nutzen will und neuere Entwicklungen verfolgen möchte.

Falls gewünscht, die tuxbox-port Quellen holen (aktuell nur in tijucas-buildsystem-cs!). Das betreffende Repository wird in die bereits bestehenden Sourcen eingebunden und auf den Branch umgeschaltet 

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

ansonsten kann man auch mit 

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

wieder zurückschalten.

Wie man mit Git innerhalb der Neutrino-HD-Quellen, weitere Funktionen nutzen kann, wird später beschrieben.

Toolchain bauen


Stop hand.png HINWEIS:

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
you@machine:~/coolstream/buildsystem-cs> make crosstool

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.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.so kann trotz erfolgreicher Kompilierung zu gravierenden Laufzeitfehlern (Abstürze etc.) führen und die erzeugeten Binaries im schlimmsten Fall unbrauchbar machen!

Hierfür diese Targets ausführen: 

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

Und dann diese Librarys 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. Anschliesend 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!

Weblinks

Quellcodes

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