Dbox2 Entwicklungsumgebung

Aus TuxBoxWIKI
(Weitergeleitet von Images und Yadd's erstellen)
Wechseln zu: Navigation, Suche

Die Erstellung von Images und Yadds erfolgt durch einen neuen bzw. überarbeiteten "make" Prozesses, bisher auch als "Newmake" bekannt. Der inzwischen auch als Oldmake bezeichnete Bulidvorgang wurde komplett abgelöst. Dieser existiert allerdings weiterhin als eigenständiger Zweig (Branch) im Tuxbox-CVS und kann auch weiter verwendet und gepflegt werden. Die entsprechenden Artikel, die Oldmake betreffen, kann man unter Development (Oldmake) finden.

Neben einer strukturierteren Basis, hat man jetzt den Vorteil, dass es auch ohne ohne großes Verständnis für den Buildprozess gelingen kann, Flashimages und YADDs unter Linux zu erstellen. Es gibt inzwischen auch eine auf Konsole basierende Frontendlösung, mit der sich Flashimages oder YADDs benutzerdefiniert erstellen lassen, das sogenannte yBuild.

Dieser Artikel basiert zum größtem Teil auf die deutsche Version von Barfs Newmake-Dokumentation, die er uns freundlicherweise zur Verfügung gestellt hat. Eine detaillierte Beschreibung (auch der make targets) unter anderem auch in englischer Sprache befindet sich auf Barf's Homepage.

Dieser Artikel behandelt die Image- u. YADD-Herstellung sowie einfache Beipiele für Benutzeranpassungen ("Customization").

Inhaltsverzeichnis

Zur Geschichte

Vor einigen Jahren war die Imageherstellung für die Tuxbox so etwas wie "Schwarze Kunst". Die Makefile-Unterstützung war, insbesondere für andere Images als cramfs-Images, ziemlich lückenhaft. Die CVS Werkzeuge waren schlecht oder unvollständig. Noch schlimmer, einige Teile wurden absichtlich geheim gehalten. Vorallem das Werkzeug, jetzt als mkflfs bekannt, welches inzwischen aber im CVS-Verzeichnis .../hostapps/mkflfs zu finden ist, wurde zurückgehalten.


Laut eines Forumsbeitrags aus dieser Zeit, waren die meisten Entwickler nicht in der Lage, eigene Images herzustellen. Die "Gilde der Imagehersteller" wurde geboren. Aus dieser Zeit dürften die "AlexW-Images" ein Begriff sein. Hauptsächlich bestanden diese aus reinen CVS-Sources mit einigen mehr-oder-weniger geheim gehaltenen "Fixes", (vermutlich) notwendig für das Herstellen eines funktionierenden Images aus dem CVS-Quellcode.


Im August 2003, wurde es für das GNU DBox2 Software-Projekt in zunehmendem Maße peinlich, mkflfs geheim zu halten und der Quellcode für mkflfs wurde ins CVS eingecheckt. Auch die Funktionalität der Makefiles wurde stufenweise verbessert. Noch war viel zu wünschen übrig: Funktionalität, Pflegbarkeit, gesundes Software-Design... Ein Image aus reinen CVS-Dateien zu bauen, war nicht wirklich möglich.


2004 wurde das YADI ("Yet Another DBox Image") Projekt geboren.
Sein Ziel war es, das "Imagebauen" zu automatisieren und zu vereinfachen. Zu diesem Zweck wurden eine Anzahl von Scripten und Patches gesammelt und/oder geschrieben. Zusätzlich wurden flashfertige Images zur Verfügung gestellt. YADI war ein grosser Erfolg. Das Ziel wurde erreicht. Images wurden zur Verfügung gestellt, die (fast) vollständig auf freier Software basierten, sowohl inhaltlich als auch bezüglich der benötigten Werkzeuge, in einer Weise, die für den Benutzer durchaus nachvollziehbar war.


Mit dem YADI-Skript war das automatische Imagebuilden zwar möglich, jedoch statt grundlegende Schwächen im CDK-Imagebau-Prozeß zu beseitigen, stellte man Skripte zum Imagebauen zur Verfügung. Es wurde kein übliches Buildsystem zur Verfügung gestellt, wie dies beispielsweise von Make, oder ein neuerer Nachfolger wie Ant,Cmake oder Maven könnten.


Newmake, bis Ende 2008 verfügbar als alternativer Branch und seit 2009 als HEAD im CVS, versucht diese Schwächen zu beseitigen. Ein spezieller Dank an jeden, der Bugreports und Feedback geliefert hat. Insbesonderes gilt dies für dietmarw, der Newmake benutzt, um die dietmarW-Images zu erzeugen.


Ziel

Das Ziel des vorliegenden Artikels ist es, dem Leser grundlegendes Know-How zu vermitteln. Es ist nicht das Ziel, eine idiotensichere Schritt-für-Schritt Anweisung bereitzustellen, wie das bei sogenannten HOWTO's der Fall wäre. Kenntnisse im Umgang mit Shellskripten wird für viele Teile, insbesondere für das Customization-Kapitel, aber nicht für Image/YADD-Herstellung in seiner einfachsten Art und Weise vorausgesetzt.


Der vorliegende Artikel versucht nicht die innere Funktion der Makefiles und des Makeprozesses zu beschreiben. Hierfür wird der Leser auf diverse Quellen, und zu relevanten Threads im CDK-Forum des Tuxbox-Forums hingewiesen. Alle Optionen für configure werden auch nicht beschrieben, nur die Allgemeinsten und Wichtigsten.


Wie schwierig ist es?

Die Antwort könnte lauten: Es ist so schwerig wie man diesen Artikel zu lesen versteht. Für den Leser, der ohne Probleme den Inhalt dieses Artikels versteht, sollte es kein Probleme sein. Leser, für die das Meiste nur Kauderwelsch ist, sollten vielleicht besser bei fertigen Images bleiben.


Images und YADD's bauen

Targets

Es gibt neben zahlreichen untergeordneten Zielen (Targets), zwei hauptrangige Targets, um Images oder Yadd's zu bauen. Diese wären logischerweise entweder

oder

Ein YADD besteht aus einigen Dateien, die die DBox anstatt aus dem Flash über den TFTP-Service lädt, sowie ein Filesystem, das über einen NFS-Server der dBox zur Verfügung gestellt wird. Diese Daten befinden sich in der Regel in

  • .../tftpboot
  • .../cdkroot oder .../yaddroot

Diese Betriebsart hat insbesondere während der Softwareentwicklung oder beim Erlernen des Systems viele Vorteile.

Der Name "YADD" bedeutet übrigens "Yet Another DBox Distribution" ("noch eine dBox Verteilung").


Erste Schritte und Überlegungen

Eine Empfehlung für den angehenden "Image/YADD-Lehrling" wäre:
Baue zuerst ein YADD mit Deiner Lieblings-GUI, und lerne damit umzugehen.
Nächster Schritt wäre dann, ein jffs2-Image mit der Lieblings-GUI zu erstellen.


Meistens möchte man die folgenden Schritte kombinieren und/oder automatisieren.


In diesem Artikel bezeichnet "GUI" entweder


Das "Filesystem" im Kontext eines kompletten Images bezeichnet das Dateisystem, in dem das root-Verzeichnis liegt.

Dies wären:

oder

Hinweis: Cramfs-Images, (komprimiertes, Read-only filesystem für embedded Systeme) werden vom Buildprozess mit CVS-Stand ab 26.07.2009 nicht mehr untertützt.


Ein "Squashfs Komplett-Image" besteht aus einem Root-Dateisystem mit dem squashfs Dateisystem und einem kleineren jffs2-Filesystem, das nach /var, dem schreibbaren Bereich eines Images, gemounted wird.
Ein "jffs2 Komplett-Image" enthält dagegen kein separates /var-Dateisystem, weil jffs2 bereits beschreibbar ist. Welches Dateisystem man verwendet, hängt im Wesentlichem davon ab, was und wieviel man in das Image packen möchte.


Zusätzlich enthalten die Komplett-Images eine weitere Partition, die den u-boot-Bootloader enthalten. Diese Partition ist zwischen dBoxen mit einen und zwei Flashchips unterschiedlich. Dieses wird durch "1x" und "2x" angezeigt. Ein komplettes Image würde demnach so benannt werden: 

[GUI]-[Filesystem].img[1, 2]x

z.B. als fertiges Image: 

neutrino-jffs2.img2x


Buildsystem Voraussetzungen

Neben einem modernen Unix/Linux System ist ordentlich freier Speicherplatz zu empfehlen. Mit Speicherplatz sollte man deshalb nicht geizen, da beispielsweise bei Verwendung von ccache einiges an Daten zwischengelagert wird und je öfter man kompiliert, es dann doch eng werden könnte.


Das Tuxbox Projekt hat keine favorisierte Buildumgebung. Fragen wie "geht es mit Redhat x.y?" lassen sich nicht genau beantworten. Gewisse Anforderungen werden dagegen für Versionen der Werkzeuge, wie autoconf, automake, make usw. formuliert. Die meisten davon sind in den gängigsten Distributionen bereits enthalten bzw. können nachinstalliert werden. Die momentan erforderlichen Toolversionen sind in folgendender Tabelle zusammengefasst:

Tool Version
cvs
autoconf 2.57a
automake 1.8
libtool 1.4.2
gettext 0.12.1
make 3.80
makeinfo Texinfo
tar
bunzip2 bzip2
gunzip gzip
patch
infocmp ncurses
gcc = 2.95 or >= 3.0
g++ = 2.95 or >= 3.0
flex
bison
pkg-config
wget


Der Buildprozess überprüft zu Beginn automatisch einige dieser Anforderungen. Wenn eines dieser Werkzeuge fehlt, oder wenn die Version zu alt zu sein scheint, ist es in der Regel einfacher, die erforderliche Version nachträglich zu installieren, entweder als kompiliertes Paket, z.B. im rpm-Format vom jeweiligem Distributor, oder sich direkt die Quellen zu besorgen, zu kompilieren und zu installieren, als zu versuchen oder herauszufinden, ob die oben genannten Anforderungen wirklich notwendig sind.


Hinweis:

In anderen Anleitungen zum Buildvorgang wird gefordert, dass Werkzeuge wie fakeroot, mksquashfs, mkcramfs, mkjffs2fs (oder mkfs.jffs2), vielleicht auch mklibs oder ccache, auf Ihrem System installiert sein müssen. In dieser Umgebung ist dies nicht erforderlich, da einige entweder überhaupt nicht benötigt werden bzw. die Installation im Makeprozess selbst vorgenommen wird!


Das Bauen auf einem Unix-non-Linux System sollte vermutlich auch möglich sein, so weit die erforderlichen GNU Werkzeuge vorhanden sind. Mit einem anderen make als GNU wird es fast sicher nicht funktionieren, da die GNU-Spezifikationen uneingeschränkt verwendet werden.


Es wird davon abgeraten, eine Umbegebung z.B. mit Cygwin aufzubauen, da es mit Sicherheit nicht funktionieren wird. In dieser Richtung wurde zwar Einiges für den Makeprozess eingebaut, jedoch wurde der Cygwin-Support inzwischen entfernt, da der bisherige Entwicklungsstand nicht den Anforderungen entsprach, um aktuell auch damit arbeiten zu können. Dafür gibt es inzwischen wesentlich bessere Alternativen. Empfehlenswert ist aber eine Buildumgebung mittels VMWare aufzubauen. Hierfür gibt es auch eine "konfektionierte" Lösung von yiogol, der hierfür ein passendes VMWare-Image erstellt hat, dass im Prinzip alle notwendigen Zutaten enthält. Eine weitere Alternative wäre die Verwendung von VirtualBox, eine OpenSource-Alternative zu VMWare. Für die Herstellung eines solchen Images gibt es auch Forenbeiträge (siehe Weblinks).


Auschecken

Der Tuxbox Quellcode wird bei Sourceforge bereitgestellt. Dort befinden sich die Hauptentwicklungszweige des Projektes in Form von 5 Git-Repositries


Stop hand.png HINWEIS:

Die Struktur der momentan verfügbaren Repositories, entspricht in etwa der Modulstruktur, wie man sie vor Umstellung von CVS auf Git kannte, wobei es noch zu diversen Anpassungen kommen dürfte. Welche Art diese Anpassungen sind, ist noch nicht vollständig geklärt. Weitere Hintergründe dazu im Tuxbox-Forum.


Klonen der Repositories

  • Erzeuge ein Verzeichnis tuxbox-cvs und wechsle in dieses Verzeichnis:
mkdir tuxbox-cvs
cd tuxbox-cvs


Klonen

Die Methoden zum Klonen unterscheiden sich je nach Nutzer. Normalerweise wird nur lesender Zugriff auf die Quellen benötigt, wohin gegen Entwickler Schreibrechte für Änderungen zum Upstream benötigen. Eine Erstellung eines Patches ist aber unabhängig davon jederzeit möglich! Der Zugriff für Developer unterschiedet daher in der Art des Zugriffs. Bei Sourceforge wird dies über einen SSH ermöglicht.

Benutzer Developer 
REPLIST="apps boot cdk driver hostapps sandbox"
for f in  $REPLIST ; do
	git clone git://git.code.sf.net/p/tuxbox-cvs/$f $f
done

Dies geht auch über http: 

REPLIST="apps boot cdk driver hostapps sandbox"
for f in  $REPLIST ; do
	git clone http://git.code.sf.net/p/tuxbox-cvs/$f $f
done
 
REPLIST="apps boot cdk driver hostapps sandbox"
for f in  $REPLIST ; do
	git clone ssh://[user_name]@git.code.sf.net/p/tuxbox-cvs/$f $f
done

Nach dem Klonen befinden sich 5 Repos in ../tuxbox-cvs


Auf einen Branch wechseln

Standardmäßig wird automatisch nach dem Klonen auf den Master-Branch gewechselt. Möchte man aber z.B. schon beim Klonen einen anderen Branch haben, welcher bisher nur im Remote Repository vorhanden ist, wird dieser direkt so geklont (hier am Beispiel des devel-Branches): 

#clone the devel-branch
git clone -b devel git://git.code.sf.net/p/tuxbox-cvs/cdk cdk

Oder so natürlich auch nachträglich, wenn der master bereits geklont wurde: 

$ git checkout -b devel origin/devel
Branch devel set up to track remote branch devel from origin.
Switched to a new branch 'devel'


Einen bestimmten tag klonen

Um z.B. nur einen absgeschlossenen Enwicklungsstand zu klonen, kann man auch direkt ein Tag klonen (hier als Beispiel 'last_oldmake_head'): 

#clone tag 'last_oldmake_head' 
$ git clone -b last_oldmake_head  http://git.code.sf.net/p/tuxbox-cvs/cdk cdk
Cloning into 'cdk'...
remote: Counting objects: 14069, done.
remote: Compressing objects: 100% (3890/3890), done.
remote: Total 14069 (delta 10137), reused 13919 (delta 9989)
Receiving objects: 100% (14069/14069), 5.12 MiB | 1.19 MiB/s, done.
Resolving deltas: 100% (10137/10137), done.
Note: checking out '652adb038c89d4fd21dc62a89867bdae57ae3612'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name


Klonen mit Vorbereitung zum Bearbeiten der Sourcen

Wer (intensiv) Änderungen am Quellcode vornehmen möchte, legt üblicherweise einen lokalen Zweig (Branch) an, auf dem man arbeitet. Auch dies kann man vorab schon beim Klonen erledigen und einen lokalen Zweig namens [USERNAME]_local anlegen und darauf wechseln. Der Master-Branch ist zur Bearbeitung prinzipiell Tabu, siehe auch: Development:Git Workflow. 

REPLIST="apps boot cdk driver hostapps sandbox"
for f in  $REPLIST ; do
	git clone git://git.code.sf.net/p/tuxbox-cvs/$f $f 
	cd $f
	git checkout -b `logname`_local
	cd ..
done

Nur um es sinnbildlich zu verdeutlichen, entspricht nun dieser lokale Zweig im Kontext zur früheren Arbeitsweise mit CVS als nicht verteiltes VCS, dem frisch ausgecheckteten Stand vom CVS-Server, mit dem man arbeitet. Der Master-Branch schlußfolglich wäre Quasi der CVS-Server, auf dem man für gewöhnlich keinen Schreibzugriff hat.


Abgleichen des lokalen Standes mit dem Remote Repositories

Für alle Repos können diese Scripte zum Updaten verwendet werden.


Einfaches Abgleichen ohne vorhandene lokale Änderungen

Je nachdem, ob man schon einen lokalen Branch mit eigenen Änderungen angelegt hat oder nicht, muss man auch unterschiedlich vorgehen. Die folgenden Beipiele sollen mögliche Wege aufzeigen. Lokal kann das natürlich anders aussehen, aber prinzipiell sollten diese Beispiele die Vorgehensweise verdeutlichen.

ohne lokalen Branch

# this will update all repos in your clone directory
# change to the directory that contains all repositories and execute this script
# ensure that you have changed to branch 'master' !
REPLIST="apps boot cdk driver hostapps"
DIR=`pwd`
GITPULL="git pull --rebase origin master"

#pull all
for f in  $REPLIST ; do
	cd $DIR/$f
	$GITPULL
	cd ..
done

mit lokalen Branch

REPLIST="apps boot cdk driver hostapps"
DIR=`pwd`
GITPULL="git pull --rebase origin master"

#pull all
for f in  $REPLIST ; do
	cd $DIR/$f
	git checkout master
	$GITPULL
	git checkout [dein_branch]
	git rebase master
	cd ..
done

Konflikte beim Abgleichen

Git kann lokale Änderungen in der Regel recht gut mit dem Remote-Stand mergen, jedoch kann es trotzdem zu Konflikten kommen. Diese müssen dann natürlich von Hand aufgelöst werden.

Git kann dafür verschiedene Mergtools verwenden, die man ebenfalls voreinstellen kann. Zu den unterstützten Mergetools zählen unter anderem:

  • kdiff3
  • tkdiff
  • meld
  • xxdiff
  • emerge
  • vimdiff
  • gvimdiff
  • ecmerge
  • opendiff

Empfehlenswert wäre z.B. Kdiff3. Vorausgesetzt das Mergetool ist installiert, kann man dies so einstellen: 

$ git config --global merge.tool kdiff3

Abgleichen bei vorhandenen noch nicht eingetragenen lokalen Änderungen

Wenn Änderungen vorhanden sind, die noch nicht comittet wurden, wird sich GIT mit Sicherheit beschweren und verlangen, dass man diese erst comitten soll. Abgeschlossene Änderungen sollte man natürlich comitten, aber wenn es notwendig ist, hilft es auch die Änderungen kurz "zu parken". Hier besteht die Möglichkeit mit git stash, seine Änderungen vorübergehend "wegzulegen" und mit git stash pop wieder einzupflegen. Diese "Parkmethode" ist jedoch nicht für größere Änderungen geeignet.

ohne lokalen Branch

REPLIST="apps boot cdk driver hostapps"
DIR=`pwd`
GITPULL="git pull --rebase origin master"
 
#pull all
for f in  $REPLIST ; do
	cd $DIR/$f
	git stash
	$GITPULL
	git stash pop
	cd ..
done

auf lokalen Branch

REPLIST="apps boot cdk driver hostapps"
DIR=`pwd`
GITPULL="git pull --rebase origin master"
 
#pull all
for f in  $REPLIST ; do
	cd $DIR/$f
	git stash
	git checkout master
	$GITPULL
	git checkout [lokaler_branch]
	git stash pop
	cd ..
done


Stop hand.png HINWEIS:

Obwohl es eigentlich keiner Erklärung bedarf, soll aber hier trotzdem darauf hingewiesen werden, dass es nach einem Update in der Regel notwendig ist, ein neues configure durchzuführen!

Nachdem die Daten ausgecheckt wurden, könnte kann man jetzt einige Patches auf die Quellen anwenden. Wenn man zum ersten Mal kompiliert, ist es aber ratsam, vorerst keine Veränderungen vorzunehmen. Wenn Probleme auftreten, ist es viel einfacher (technisch sowohl als auch für jeden selbst) jemand zu helfen, der die "unveränderten CVS Quellen" verwendet.


Konfiguration

Nach dem Auschecken bzw. Updaten müssen nun einge Zwischenschritte erledigt werden, damit der Buildprozess auch erkennt, was und vorallem wie er es machen soll.


Man wechselt nun in das CDK-Unterverzeichnis 

cd cdk

und gibt diesen Befehl ein (ohne Argumente). 

./autogen.sh

Dieser erzeugt unter anderem ein Shellskript namens configure.


Wird autogen.sh ausgeführt, wird dabei eine Anzahl von Optionen übergeben, um das System für das Builden eines Images, YADD oder aller anderen gewünschten Ziele entsprechend den Benutzerwünschen vorzubereiten.


Optionen

Für uns sind vorerst nur wenige Optionen interessant. Die Standardvorgaben reichen vorerst völlig aus. Für eine komplette Liste von Optionen, benutze den Befehl 

./configure --help

Hier einige Ausgaben:

  • Program names:
 --program-prefix=PREFIX            prepend PREFIX to installed program names
 --program-suffix=SUFFIX            append SUFFIX to installed program names
 --program-transform-name=PROGRAM   run sed PROGRAM on installed program names
  • System types:
 --build=BUILD     configure for building on BUILD [guessed]
 --host=HOST       cross-compile to build programs to run on HOST [BUILD]
 --target=TARGET   configure for building compilers for TARGET [HOST]

Optional Features: 

 --enable-uclibc     enable rules for creating uclibc linked targets
 --enable-kernel26     set up the CDK to use the 2.6 kernel (experimental)
 --enable-maintainer-mode     enable make rules and dependencies not useful

(and sometimes confusing) to the casual installer 

 --disable-flashrules     disable rules for creating flash targets - build cdk
                         instead
 --enable-german-keymaps include loadkey and German keymaps in yadds and
                         images
 --enable-ide            include ide/mmc and ext2/ext3 drivers in yadds and
                         images
 --disable-ext3          exclude ext2/ext3 drivers in yadds and images
 --enable-xfs            include xfs drivers in yadds and images
 --enable-mmc            include mmc drivers in yadds and images - you need
                         to activate a filesystem
 --disable-drive-gui      disables neutrino gui-setup for ide hdd mmc
                         administration - uses utillinux fdisk instead of
                         busybox
 --enable-nfsserver      enable the dBox NFS server
 --enable-automount      enable automount daemon
 --disable-gui-mount     disable GUI mount functionality
 --enable-sambaserver    enable the dBox samba server
 --enable-upnp           include upnp support - depends on audioplayer
 --enable-flac           include Neutrino flac audio support - depends on
                         audioplayer
 --disable-audioplayer   include Neutrino audioplayer/internetradio
 --disable-pictureviewer include Neutrino pictureviewer
 --disable-movieplayer   include Neutrino movieplayer
 --disable-radiotext     include Neutrino Radiotext support
 --disable-fx2plugins    disable fx2-plugins (games) for gui's
 --enable-aformat        enable aformat - dbox2-only
 --enable-cdkVcInfo      include cdkVcInfo in yadds and images
 --enable-clock          enable clock
 --enable-dboxshot       enable dboxshot
 --enable-dropbear       enable dropbear
 --enable-dvbsnoop       enable dvbsnoop
 --disable-dvbsub        disable dvbsub
 --enable-esd            enable esound
 --enable-fbshot         enable fbshot
 --enable-gdbserver      enable gdbserver
 --enable-getrc          enable getrc
 --enable-hddtemp        include hddtemp in yadds and images - depends on IDE
                         support
 --enable-input          enable the tool named input
 --enable-ipkg           include ipkg in yadds and images
 --enable-lcshot         enable lcshot - dbox2-only
 --enable-lirc           include lirc in yadds and images - dbox2-only
 --enable-msgbox         enable msgbox
 --enable-openvpn        include OpenVPN in yadds and images and build tun
                         kernel module
 --disable-rtc           disable rtc hardware support - dbox2-only
 --enable-satfind        enable satfind
 --enable-shellexec      enable shellexec
 --enable-sqlite         enable sqlite
 --enable-strace         enable strace
 --enable-sysinfo        enable sysinfo
 --enable-tuxcal         enable tuxcal
 --disable-tuxcom        disable tuxcom
 --disable-tuxmail       disable tuxmail
 --disable-tuxtxt        disable tuxtxt completely
 --disable-internal-tuxtxt
                         disable internal Tuxtxt cache, use only external
                         Tuxtxt plugin instead
 -enable-tuxwetter      enable tuxwetter
 --enable-ccache         enable ccache supported compiling
 --enable-freesatepg     enable UK FreeSat EPG
 --enable-movieplayer2   enable experimental neutrino movieplayer2
 --enable-dreambox-serial-console
                         enable serial console on dream


Optional Packages: 

 --with-toolchain=PATH,	do not build a toolchain but use the one at PATH
 --with-boxtype          valid values: dbox2,tripledragon,dreambox,ipbox,generic
 --with-boxmodel         valid for dreambox: dm500, dm500plus, dm600pvr, dm56x0, dm7000, dm7020, dm7025)
                         valid for ipbox: ip200, ip250, ip350, ip400
 --with-targetruleset=NAME	OBSOLETE, use --[enable|disable]-flashrules instead
 --with-assume-kernelsources-old	Do not recompile due to new kernel sources
 --with-filesystems      comma seperated list of filesystems to be used,
                         first disk filesystem will be used as default for /hdd entry in /etc/fstab
                         allowed values: nfs (always enabled in yadd), cifs, smbfs,
                                         lufs (ftpfs), xfs (not kernel2.4/uClibc),
                                         ext2, ext3, extfs (ext2/3), vfat, reiserfs
 --with-rootpartitionsize=SIZE	size of the root partition
 --with-flashfstype=FS_TYPE	type of flash root filesystem partition for the yadd kernel (squashfs+lzma/squashfs)
 --with-defaultlocale=LOCALE	default locale
 --with-targetprefix=DIR prefix for target files [PREFIX/cdkroot]
 --with-hostprefix=DIR   prefix for host files [PREFIX/cdk]
 --with-bootprefix=DIR   prefix for boot files [PREFIX/tftpboot]
 --with-flashprefix=DIR  prefix for flash files [PREFIX/cdkflash] (only used for flash building)
 --with-serversupport=DIR  prefix for server file templates [PREFIX/serversupport]
 --with-ucodesdir=DIR  optional directory containing ucodes (dbox2 only) [NONE]
 --with-logosdir=DIR  optional directory containing logos [[CVS/]logos]
 --with-customizationsdir=DIR  optional directory containing customization scripts CVS
 --with-updatehttpprefix=URL  optional URL containing the URL of a directory with update images
                              "disable" completely disables internet update code [NONE]
 --with-busybox-conf=M4_FILE personalized optional m4 busybox configuration file [config/busybox.config.m4]
 --with-kernel-conf=FILE optional personalized linux kernel config file [config/dbox2_kernel-KERNEL_VERSION.config.m4]
 [[#--with-checkImage=[none,rename,warn]|--with-checkImage=[none,rename,warn]]]	How/if to invoke checkImage [none]
 --with-cvsdir=DIR       where to find the cvs
 --with-appsdir=DIR      apps dir from cvs [[CVS/]apps/]
 --with-bootdir=DIR      boot dir from cvs [[CVS/]boot/]
 --with-driverdir=DIR    driver dir from cvs [[CVS/]driver]
 --with-hostappsdir=DIR  hostapps dir from cvs [[CVS/]hostapps]
 --with-gnuserver=ADDRESS   the gnu server for gnu-stuff (without ftp://)
 --with-defaultserver=ADDRESS   the server that is taken if no server is given/works (without http://)
 --with-maxcachesize=SIZE maximal ccachesize for ccache
 --with-maxcachefiles=COUNT maximal count of cachefiles for ccache
 --with-webif=NAME dreambox webif [standard,expert]
 --with-epg=NAME dreambox epg [standard,private]
 --with-mhw-epg          enable capture of mhw epg (default off)
 --with-flashtool=NAME dreambox flashtool [standard,expert]
 --with-ext-flashtool=NAME dreambox ext-flashtool [yes,no]
 --with-enigma-debug=NAME dreambox enigma-debug [yes,no]

Eine typische Anwendung (Konfiguration), der mit z.B. den Pfadnamen oben kompatibel wäre, könnte so eingestellt werden: 

./configure --with-cvsdir="/tuxbox-cvs" --prefix="/dbox2" --enable-maintainer-mode


  • --with-cvsdir

sagt wo die Quellen zu finden sind, (darin sollte auch ein Unterverzeichnis .../cdk besitzen). In der Regel ist dies das Verzeichnis in das die Quelldaten gerade ausgecheckt wurden, während

  • --prefix

bedeutet, dass eine Anzahl von wichtigen Verzeichnissen als Unterverzeichnisse des besagten Verzeichnisses erstellt werden sollen. Ihre Position kann durch andere Konfigurationsoptionen weiter beeinflußt werden.

  • --enable-maintainer-mode

ist, auch für Nichtmaintainers praktisch, da er den hergestellten Makefiles ermöglicht, sich automatisch neu zu erzeugen, sobald die Notwendigkeit entsteht, zum Beispiel nach einem Software-Update.


Es gibt sicher noch andere nützliche Optionen. Einige werden weiter unten aufgelistet.


Fehlerausgaben

Überprüfe bitte die Ausgaben von autogen auf Fehler ("Error") und Warnungen.


Hierbei können diese Warnungen ignoriert werden: 

/usr/local/share/aclocal/pkg.m4:5: warning: underquoted definition of PKG_CHECK_MODULES from autogen.sh

ebenso folgende Warnungen von configure: 

...
configure: WARNING: using tuxbox mklibs
checking for mkjffs2... no
checking for mkfs.jffs2... no
configure: WARNING: using tuxbox mkfs.jffs2
checking for mksquashfs... no
configure: WARNING: using tuxbox squashfs
...

Dies sind nur Hinweise darauf, dass hier projekteigene Versionen einiger Tools verwendet werden.

Beachte! Wenn man diesen Artikel mit älteren Beschreibungen (Oldmake) vergleicht, bemerkt man, dass die Option --with-targetruleset=[standard,flash] nicht mehr vorhanden ist. Bisher war es notwendig, bei der Konfiguration sich entweder auf Builds von YADDs oder Images einzuschränken. Bei Newmake ist dieses nicht mehr notwendig.


Stop hand.png

Versuche niemals, als root zu bauen!


Kompilieren

Die high-level make Targets, die für das Builden von Komplett-Images relevant sind, lauten: 

  • flash-[neutrino, enigma, all]
  • flash-[squashfs, jffs2, all]
  • [1x, 2x, alle]

Für YADD-Builds, sind diese: 

  • yadd-[neutrino, enigma, all]

Beispiele: 

make flash-neutrino-jffs2-all

erzeugt flashbare jffs2-only Images mit Neutrino, für 1x-Boxen und für 2x-Boxen (Dateinamen neutrino-jffs2.img1x und neutrino-jffs2.img2x).

der Befehl: 

make yadd-enigma

erzeugt ein YADD, das Enigma enthält. 


make flash-enigma+neutrino-squashfs-all

diese Kombination erzeugt ein Squashfs Flash-Image, welche Enigma und Neutrino gleichzeitig enthält. 


flash-neutrino-squashfs_nolzma-all

diese Kombination erzeugt ein Neutrino-Squashfs Flash-Image, ohne LZMA-Kompression.

Hinweis: Die configure-Optionen --enable-lzma bzw. --disable-lzma haben keine Gültigkeit mehr, stattdessen wird dies im Targetnamen angegeben

Zeitaufwand

Das Kompilieren kann bei so einem Projekt und je nach Konfiguration und Rechnerleistung schon einige Zeit in Anspruch nehmen. Auf einem Athlon XP 1800 dauert ein Befehl wie make yadd-neutrino mit leeren Verzeichnissen etwa 1 und 1,5 Stunden.


Verwendung von ccache

Um den Vorgang insbesondere bei wiederholten Kompilieren und besonders auf langsameren Rechnern zu beschleunigen, steht die Option

zur Verfügung, welche man mit in die Konfiguration einbinden kann. Erfahrungsgemäß wird so durchschnittlich ca. 1-2 Drittel der Zeit eingespart.


Durch die Option --enable-ccache wird erreicht, sollte das Tool bereits in deiner Distribution installiert sein, dass ccache automatisch erkannt wird und in das Tuxbox-CDK eingebunden wird. Ist es nicht installiert, wird dies auch von configure angezeigt: 

----------------------------------------
...
ccache is not yet installed, but installation starts on first build of cdk environment or you can run make ccache
----------------------------------------
...

Falls Ccache nicht auf dem Host-System installiert ist, wird es beim ersten Bauvorgang automatisch eingebunden bzw. passend zum CDK installiert. Nachtraglich kann das Tool auch mit dem Target 

make ccache

in das CDK eingebaut werden. Ein Configure des CDK sollte dem möglichst vorausgegangen sein.

Hinweis
Die Wirkung von Ccache macht sich logischrweise erst bemerkbar, nachdem der Buildvorgang mindestens einmal durchgelaufen ist!


Die Option --enable-ccache ist normalerweise völlig ausreichend. Es stehen aber noch weitere untergeordnete Sub-Optionen zur Verfügung, die in Ausnahmefällen verwendet werden können:

  • --with-maxcachesize=SIZE maximal

Hier gibt man an, wieviel Speicher ccache verwenden darf in GB z.B: für 2GB 

--with-maxcachesize=2


  • --with-maxcachefiles=COUNT

Hier kann man angeben, wieviele Dateien ccache cachen darf. 

--with-maxcachefiles=20000

Hier würden es logischeweise 20000 sein.


Die Wirksamkeit von ccache lässt sich mit dem Befehl 

ccache -s

prüfen. Als Ergebnis werden einige Statistiken über das Cache-Verhalten von ccache ausgegeben: 

cache directory                     /home/<USER>/.ccache
cache hit                              4
cache miss                           191
called for link                       17
multiple source files                  4
compile failed                        17
preprocessor error                     2
not a C/C++ file                       5
autoconf compile/link                178
no input file                         15
files in cache                       382
cache size                           7.1 Mbytes
max cache size                     976.6 Mbytes


Tipp
Um die benötigte Zeit genau zu ermitteln, kann man den Befehl time einbauen. 

time make yadd-neutrino

Am Ende des Bauvorganges werden damit die entsprechenden Zeitinformationen ausgegeben.


Verwendung von Make-Optionen

Aktuell besteht auch die Möglichkeit den Bauvorgang mit der Makeoption -j zu beschleunigen. Hierbei können von Make gleichzeitig mehrere Jobs erledigt werden, sofern diese keine Abhängigkeiten untereinander haben. Die Wirkungen sind durchaus auch von der verwendeten Hardware abhängig. Ein Rechner mit Mehrkern-Prozessor hat hier sicher die besseren Karten. Die Übergabe dieser Option erfolgt in dieser Form: 

make J=[n] [target]

n ist die Anzahl der Jobs, Target das jeweilige Ziel.


Beispiele

Hier einige Beispiele mit denen man Images, Yadds oder einzelne Targets bauen kann. Diese Beispiele sollten so wie sie hier vorgegeben sind ohne Veränderung auf jedem Linux-System mit den bisher beschriebenen Voraussetzungen laufen. Da die Systeme trotzdem Unterschiede aufweisen können, kann man das aber nicht garantieren.

neutrino-jffs2-Image

#! /bin/bash 
# beispiel.sh
# Diese Script baut neutrino-jffs2 Images, jeweils 1x und 2x
#----------------------------------------------
USERDIR=/home/$(whoami) 
#----------------------------------------------
LOGODIR=$USERDIR/Logos 
CP=$USERDIR/tuxbox_build 
DB=$USERDIR/dbox2 
ARCHIVEDIR=$USERDIR/Archive 
mkdir $CP

cd "$CP"
REPLIST="apps boot cdk driver hostapps sandbox"
for f in  $REPLIST ; do
	git clone git://git.code.sf.net/p/tuxbox-cvs/$f $f
done

cd CP=$USERDIR/cdk
/bin/ln -sf $ARCHIVEDIR/ Archive
./autogen.sh 
./configure --prefix="$DB" --with-cvsdir="$CP" --enable-flashrules --enable-ccache --with-checkImage=rename --with-logosdir="$LOGODIR" 
make flash-neutrino-jffs2-all


Neutrigma-squashfs-Image

 #! /bin/bash 
 # beispiel.sh
 # Diese Script baut ein kombiniertes Enigma, Neutrino (Neutrigma)-Squashfs-Image, jeweils 1x und 2x
 #----------------------------------------------
USERDIR=/home/$(whoami) 
#----------------------------------------------
LOGODIR=$USERDIR/Logos 
CP=$USERDIR/tuxbox_build 
DB=$USERDIR/dbox2 
ARCHIVEDIR=$USERDIR/Archive 
mkdir $CP

cd "$CP"
REPLIST="apps boot cdk driver hostapps sandbox"
for f in  $REPLIST ; do
	git clone git://git.code.sf.net/p/tuxbox-cvs/$f $f
done

cd CP=$USERDIR/cdk
/bin/ln -sf $ARCHIVEDIR/ Archive
./autogen.sh 
./configure --prefix="$DB" --with-cvsdir="$CP" --enable-flashrules --enable-ccache --with-checkImage=rename --with-logosdir="$LOGODIR" 
make flash-enigma+neutrino-squashfs-all


Neutrino YADD

 #! /bin/bash 
 # beispiel.sh
 # Diese Script baut ein Neutrino Yadd
 #----------------------------------------------
USERDIR=/home/$(whoami) 
#----------------------------------------------
LOGODIR=$USERDIR/Logos 
CP=$USERDIR/tuxbox_build 
DB=$USERDIR/dbox2 
ARCHIVEDIR=$USERDIR/Archive 
mkdir $CP

cd "$CP"
REPLIST="apps boot cdk driver hostapps sandbox"
for f in  $REPLIST ; do
	git clone git://git.code.sf.net/p/tuxbox-cvs/$f $f
done

cd CP=$USERDIR/cdk
/bin/ln -sf $ARCHIVEDIR/ Archive
./autogen.sh 
./configure --prefix="$DB" --with-cvsdir="$CP" --with-logosdir="$LOGODIR" --enable-[[Ccache|ccache]] 
make yadd-neutrino


Kernel 2.6.x

Beispiel-Script für den Bau eines Images mit 2.6er Kernel

#Verzeichnisse festlegen#
BUILDDIR=$HOME/tuxbox_K26
CDKDIR=$BUILDDIR/cdk
DISTDIR=$HOME/dbox2_K26

#klonen
mkdir $BUILDDIR
cd $BUILDDIR
REPLIST="apps boot cdk driver hostapps sandbox"
for f in  $REPLIST ; do
	git clone git://git.code.sf.net/p/tuxbox-cvs/$f $f
done

#wechsel in das driver-Verzeichnis und driver_2_6_branch auschecken
cd $BUILDDIR/driver
git checkout -b driver_2_6_branch origin/driver_2_6_branch
cd $CDKDIR
 
#konfigurieren#
./autogen.sh
./configure --enable-kernel26 \
             --enable-maintainer-mode \
             --prefix=$DISTDIR \
             --enable-flashrules \
             --enable-cdkVcInfo \
             --disable-ext3 \
             --with-checkImage=rename \
             --with-cvsdir=$BUILDDIR \
             --enable-ccache
 
#target für Neutrino-Image aufrufen#
time make flash-neutrino-squashfs-all

IDE Interface Unterstützung für Kernel 2.6.x

Hierfür sind einige Anpassungen in der Busybox- und der Kernelconfig und evtl. an Treiber nötig. auch die Startdateien (rcS und/oder start_neutrino) müssen ggf. angepaßt werden. Da es noch keine einheitlich Vorgehensweise gibt und sich das Ganze derzeit in der Entwicklung befindet sei auf diese Forumsthreads verwiesen.

Weitere Forum-Links zum Thema


Was kommt dann...?

Booten von YADD

Wenn ein YADD frisch erzeugt wurde, kann damit auch die Box booten. Näheres dazu auch im Artikel CDK booten.
Newmake hält auch ein Make-Target für den serversupport bereit. 

make serversupport

Dieses erzeugt einige Konfigurationsdateien für den Server der das YADD-Build nahtlos an das Server-Setup anknüpft.


Flashen des Images

Wenn ein Image gebaut wurde, ist der logische nächste Schritt das Einspielen des Images in den Flash der Box. Hierfür ist entweder, das interaktive Flashen innerhalb der GUI mit den Expertenfunktionen zu benutzen, oder der dboxflasher zu verwenden. Der dboxflasher wird durch das Make-Target 

make serversupport

erzeugt.
Siehe auch Installation.


Inkrementelle Builds

Im allgemeinen ist man nicht an einem einmaligen Build der Software interessiert. Verbesserungen an den Quellen werden in das CVS täglich eingecheckt. Oft möchte man die Software durch eigene Programmierung verbessern oder Patches anwenden. Es ist dabei wünschenswert, dass genau nur die Teile neu erzeugt wird, die neu erzeugt werden sollen, nicht mehr und nicht weniger. Newmake geht einen direkten Weg in diese Richtung.
Um ein Target neu zu bauen, benutze den Befehl 

make [target]

und make wird es, falls notwendig, neu erzeugen.


Es kann auch passieren, dass make zusätzlich einen vollständig anderen Bestandteil neu erzeugt! Dies ist dann der Fall, wenn das jeweilige Target von anderen Teilen abhängt, die sich geändert haben.
In einige Situationen kann es auch wünschenswert sein, ein erneutes Bauen einer Komponente zu erzwingen. Einige Komponenten werden in einem Distributionsfile zum Verzeichnis cdk/Archive heruntergeladen, und wenn das Build stattfindet, ausgepackt, evtl. Patches angewendet, konfiguriert, kompiliert, installiert und die Quellen dann wieder gelöscht.
Alles findet automatisch statt. Die Installation eines bestimmten Pakets wird durch das Anlegen einer Markerdatei im Verzeichnis cdk/.deps vermerkt.
Falls gewünscht, kann solch eine Markiererdatei entfernt werden, um das Neuerzeugen der entsprechenden Komponetne zu erzwingen. Es gibt hierfür auch entsprechende Targets, die "Cleaning Targets".


Cleaning targets

Es gibt mehrere unterschiedliche Aufräum-Targets:

make distclean

Das drastischste Reinigungs-Target, (fast) alles löschend, was nicht vom CVS ausgecheckt wurde. Dieses ist eher selten notwendig.

make mostlyclean

Ein intelligenteres Target ist mostlyclean. Es säubert die Verzeichnisse, die Tuxboxquellen enthalten, lässt aber die Kompilationsumgebung und alle Auspacken-kompilieren-installieren-löschen-Komponente unberührt.

Auch das cdkroot Verzeichnis, (d.h. die Yadd-Installation), sowie die TFTP-Files (Kernel und u-boot) werden nicht angefasst.

make depsclean

Löscht alle Markerdateien im /cdk/.deps Verzeichnis und zwingt so zum Neukompliieren aller Auspacken-kompilieren-installieren-löschen-Komponenten.

Dies ist selten sinnvoll: Diese hängen von ihren Quellen und vielleicht von einem Patchfile ab, und der Makefile kennt diese Abhängigkeiten.

make clean

Kombiniert mostlyclean, depsclean, und flash-clean. Versucht auch soviel wie möglich im cdkroot-Verzeichnis zu löschen, das nicht während des Bootstrapdurchlaufes installiert war. So wird versucht, die Umgebung in einem Zustand zu bringen, wo die Buildumgebung gerade kompiliert worden ist, z.B. mit make bootstrap.

make flash-semiclean

Dieses Target löscht die meisten Verzeichnisse in $(flashprefix), mit Ausnahme der Boot-Partitionen und der Kernelbauverzeichnisse.
Dieses ist oft sinnvoll, da diese Bestandteile verhältnismässig sich selten ändern.

make flash-mostlyclean

Zusätzlich zum flash-semiclean löscht dieses Target auch Bootfiles und die Kernbauverzeichnisse. Vollimages werden unberührt gelassen.

make flash-clean

Dieses Target löscht Alles in $(flashprefix).

Sonstige

Einige Quellverzeichnisse können mit einem Befehl wie 

make -C /tuxbox-cvs/apps/tuxbox/neutrino clean

gesäubert werden.

Customization

Ein "Schreckgespenst" für viele "" ist anscheinend die so genannte Customization. Dies kann man immer wieder aus diversen Meinungen und Forumsbeiträgen diverser "Oldmaker" herauslesen. Ein Grund dafür dürfte wohl die scheinbare "gefühlte" Unmenge an Scripten sein, die damit in Verbindung gebracht wird. Grundsätzlich ist es aber so, dass man zuerst einmal ein Image und/oder Yadd bauen sollte, ganz ohne Zusätze, um zumindest erst einmal zu sehen, was dabei herauskommt. Dies sind, also nichts weiter als beispielsweise völlig normale Images. Die flasht man sich auf die Box und kann man zweckentsprechend verwenden. Mehr erstmal nicht. Dies dürfte auch völlig ausreichend sein, aber wir sind ja Bastler und wollen ja mehr...und daraus ergibt sich der Bedarf an der Nutzung dieser Customization.


Will man z.B. ein Image für den Hausgebrauch bauen, mit dem man nach dem flashen sofort fernsehen will, kann man sich z.B. alle benötigten Firmawaredateien (Ucodes), Senderlisten usw. an Ort und Stelle im Image platzieren lassen, ohne dass es Änderungen an irgendeinem Makefile bedarf. Das gleiche gilt auch, wenn man bespielsweise ein IDE-Interface betreiben möchte. Da das Tuxbox-Projekt hierfür enstprechende Möglichkeiten bereit hält, gibt es dafür auch entsprechende fertige Konfigurations-Optionen, die die entsprechende Funktionalität herstellen.

Konfigurationsoptionen

Hier sollen zunächst einige verschiedene Möglichkeiten für die Konfigurations-Optionen vorgestellt werden. Eine Komplettübersicht aller Optionen lässt sich mit 

./configure --help

abrufen

--with-ucodesdir=[DIR]

Hiermit kann ein Verzeichniss angegeben werden, welches die Ucodes (Firmwaredateien enthält, die im Image enthalten sein sollen. Hinweis:

Ein Image, dass ucodes enthält, darf 
nicht verbreitet werden!

--with-logosdir=[DIR]

Legt ein Verzeichniss fest, das boot-logos (logo-lcd und logo-fb) enthält, die im Image enthalten sein sollen.

--with-defaultlocale=[LOCALE]

sorgt dafür, dass die gewünschte Sprache schon beim bauen eingestellt wird.

--with-rootpartitionsize=[SIZE]

Legt die Rootpartitionsgröße für squashfs Images fest.


Die Größe der var-Partition wird automatisch berechnet, wobei man den restlichen Flashspeicher nutzt, der nicht durch die anderen Partitionen benutzt wird. Die Standardgröße ist 0x660000. Diese Zahl sollte eine Multiple der Erasesize, momentan 0x20000 sein. Dies wird allerdings ignoriert falls es wie bei der jffs2-Imageerstellung unsinnig wäre.

--with-updatehttpprefix=[URL]

Nützlich für das Verteilen von Onlineupdates oder auch nur um im eigenen Heimnetzwerk mit Hilfe eines Servers seine Boxen up-to-date zu halten, ist die Angabe einer Updateadresse (Update-URL).


Die Adresse wird in dieser Form angegeben: 

--with-updatehttpprefix=http://www.deine-updateseite.de


Diese Adresse erscheint beispielsweise in der Versionsdatei (.version), in den Image-Informationen von Neutrino und sorgt dafür, dass Online-Updates über das Netzwerk abgerufen werden können (siehe: Neutrino:Service:Software-Aktualisierung). Serverseitig muss natürlich auch eine entsprechende Informationsquelle für die entsprechenden Updates vorhandene sein. Dies übernehmen die sogenannten *.list-Files, dessen Adresse in die Datei 

/etc/update.urls (siehe Experten-Funktionen)

eingetragen werden muss. Je nachdem was für ein Update abgerufen werden soll, werden dafür verschiedene *.list-Files benötigt.

  • img.list für Komplettimages
  • squashfs.list für Root-squashfs Updates

Diese *.list-Files enthalten alle Informationen die für das Online-Update benötigt werden. Das Format sollte so aussehen: 

[URL zum Update-file] [md5-Prüfsumme] [Image-Versions-String] [Name für das Image]

Beispiel: 

http://www.deine-homepage.de/downloads/Image-v2.0_neutrino_squashfs_1200200808281200_1x.img 06c30a36329d990194f249d3a3648aec 1200200808281200 Image-v2.0_1x


Die Einträge in die *.list-Files und update.urls lassen sich mit Hilfe von Customization-Scripten erzeugen und anschließend ins Image einfügen (siehe auch: .version_anpassen). Die *.list-Files können mit diversen Werkzeugen (z.B. ncftpput) auf einen Server geladen werden. Zu beachten wäre noch, das beim Update selbst zur Neutrino-Laufzeit eine Prüfung des Release-Zyklus erfolgt. Bei Neutrino ist derzeit 2.0 aktuell und sollte eingehalten werden. Ändern kann man dies in update.cpp, zu finden im Neutrino CVS-Quellcode unter 

./apps/tuxbox/neutrino/src/gui/update.cpp

--with-targetprefix=DIR

  • standard: PREFIX/cdkroot

Gibt an, wohin alle Targets gebaut werden sollen. Ein Target mit Namen make busybox baut also standardmäßig busybox genau dorthin.

  • PREFIX/cdkroot/bin

--with-flashprefix=DIR

  • standard: PREFIX/cdkflash.

Gibt an, wohin alle Flash-Targets gebaut werden sollen. Also ein Target mit Namen make flash-busybox baut also standardmäßig busybox genau dorthin:

  • PREFIX/cdkflash/root/bin

Da beispielsweise das Flash-Target make flash-neutrino-squashfs gewisse Abhängigkeiten hat, die auch busybox betreffen, wird busybox auch hier hin gbaut.

  • PREFIX/cdkflash/root-neutrino-squashfs/bin

--with-hostprefix=DIR

  • standard: *PREFIX/cdk

Gibt an wohin die Binaries für das Tuxbox-CDK optional gebaut werden

--with-bootprefix=DIR

  • standard: *PREFIX/tftpboot

Gibt optional an wohin die Bootfiles (Kernel, U-boot) für das CDK bzw. Yadd gebaut werden

--with-serversupport=DIR

  • standard: *PREFIX/serversupport

Hier werden die Vorlagen der Konfigurationsdateien optional abgelegt, die für die Einrichtung eines bootfähigen CDK erstellt werden.

--with-customizationsdir=DIR

  • standard: *cvsdir/cdk

Hier werden optional die Customization-Scripte abgelegt, um vom Makeprozess dort abgerufen werden zu können.

--with-checkImage=[none,rename,warn]

Gibt an, wie die Prüfung von Imaages erfolgen soll

  • none=nichts
  • rename=umbenennen (Image erhält die Endung -bad)
  • warn=selbstredend

--with-cvsdir=DIR

Gibt an, wo sich optional das CVS-Verzeichnis befindet

--with-appsdir=DIR

  • standard: ./cvsdir/apps

Gibt an, wo sich optional das apps-Quellcodeverzeichnis befindet. Nützlich um auch andere Repositories als die aus dem Tuxbox-CVS einzubinden. Eine Möglichkeit wäre es z.B. ein geklontes git-Repository einzubinden, die derzeit von einigen Tuxboxentwicklern parallel betreut werden. siehe: http://gitorious.org/projects/tuxbox-apps

--with-bootdir=DIR

  • standard: ./cvsdir/boot

Gibt an wo sich optional das boot-Quellcodeverzeichnis befindet

--with-driverdir=DIR

  • standard: ./cvsdir/driver

Gibt an wo sich optional das driver-Quellcodeverzeichnis befindet

--with-hostappsdir=DIR

  • standard: ./cvsdir/hostapps

Gibt an wo sich optional das hostapps-Quellcodeverzeichnis befindet

--with-gnuserver=ADDRESS

Optionale Serveradresse für GNU-Sourcen (ohne ftp://)

--with-defaultserver=ADDRESS

Serveradresse die genommen wird falls ein Server nicht verfügbar ist (ohne http://)

--with-archivedir=DIR

Gibt optional das Verzeichnis an in dem sich die CDK-Archive befinden

--with-busybox-conf=M4-File

  • standard: ./cvsdir/cdk/Patches/busybox.config.m4

Hier kann optional eine eigene M4-Macro-Konfigurationsdatei angegeben werden

--with-yadd-kernel-conf=FILE --with-flash-kernel-conf=FILE

  • standard: ./cvsdir/cdk/Patches

Hier kann optional eine Konfigurationsdatei jeweils für Flash oder Yadd angegeben werden

--with-filesystems=comma seperated list of filesystems

Detailierte Hintergründe zu dieser Option siehe hier.

Hier können durch Komma getrennte Filesysteme angegeben werden. (siehe --enable-xfs, --disable-ext3). 

--with-filesystems=extfs,xfs,nfs,cifs,vfat,smbfs,lufs

extfs stellt ein Alias für ext2 und ext3 dar, kann aber auch einzeln verwendet werden. Der erste Eintrag wird als Standard verwendet und in der /etc/fstab verwendet. Ist für Neutrino auch Drive-GUI aktiviert, ist der Eintrag für fstab allerdings ohne Bedeutung. Werden IDE-relevante Filesysteme angegeben, wird auch gleichzeitig der IDE-Support aktiviert (siehe auch --enable-ide)

--with-filesystem-tools= comma seperated list of filesystem tools to be used

Hier können durch Komma getrennte Dateisystemtools angegeben werden. Zugelassene Werte:

  • e2fsprogs, reiserfsprogs, dosfstools, xfsprogs, fdisk (standalone)

Als Standard sind die passenden Tools aktiviert, die zu den aktivierten Dateisystemen gehören:

  • ext2/ext3: e2fsprogs
  • xfs: xfsprogs
  • reiserfs: reiserfsprogs
  • vfat: dosfstools

Diese Option ist dazu gedacht, nicht benötigte Tools nicht zu kompilieren.


Beispiele: Wer in einem ext2/vfat-Image nur e2fsprogs haben möchte, nutzt also 

--with-filesystem-tools=e2fsprogs

Wer keine Dateisystemtools im Image haben möchte, nutzt also 

--with-filesystem-tools=""
Stop hand.png HINWEIS: Dateisystemtools deaktivierter Dateisysteme sind nicht aktivierbar.

Der Parameter "fdisk" deaktiviert das fdisk-applet von busybox und installiert stattdessen fdisk aus dem utillinux-Paket. Diese Option ist standardmäßig aktiviert, sofern --disable-drive-gui nicht genutzt wird.

--disable-drive-gui

Deaktiviert den Einbau der GUI-unterstützten Laufwerksverwaltung in Neutrino (IDE-Menü), wird ansonsten standardmäßig mitgebaut!

--enable-ide

Ermöglicht das Bauen von Images/Yadds mit support für IDE-Interfaces. Es werden hierfür die passenden Treiber und Kernel-Module gebaut.

--enable-mmc

Ermöglicht das Bauen von Images/Yadds mit support für MMCs. Es werden hierfür die passenden Treiber und Kernel-Module gebaut.

--disable-ext3

Deaktiviert Treiber für ext2/ext3 Dateisysteme (siehe --with-filesystems=) Diese Option ist weiterhin gültig, kann aber weggelassen werden, wenn --with-filesystems aktiviert ist und wird nicht berücksichtigt, wenn --with-filesystems angegeben ist.

--enable-xfs

Aktiviert Treiber für XFS und baut xfsprogs (siehe --with-filesystems="xfs") Diese Option ist weiterhin gültig, kann aber weggelassen werden, wenn --with-filesystems aktiviert ist und wird nicht berücksichtigt, wenn --with-filesystems angegeben ist.

--enable-nfsserver

Ermöglicht das Bauen eines NFS-Servers

--enable-sambaserver

Ermöglicht das Bauen eines Samba-Servers

Stop hand.png HINWEIS: -enable-nfsserver und --enable-sambaserver sind zumindest mit der dbox2 nur dann sinnvoll, wenn auch entsprechende Laufwerke für Freigaben zur Verfügung stehen. Konkret wäre das beim Einsatz von weiteren Laufwerken der Fall. Für andere Receiver dürfte das ähnlich sein.

--enable-uclibc

Aktviert Makerules für uClibc verlinkte Targets (derzeit noch experimentell) Erfahrungswerte erwünscht!

--enable-maintainer-mode

Ermöglicht den hergestellten Makefiles, sich automatisch neu zu erzeugen, sobald die Notwendigkeit entsteht, zum Beispiel nach einem Software-Update.

--enable-kernel26

Es wird statt des üblichen 2.4.xer Kernel ein 2.6.xer Kernel gebaut (derzeit noch experimentell) Erfahrungswerte erwünscht! Hinweis: Hierfür ist es notwendig die entsprechenden Treiber im Kernel2.6er CVS-Branch auszuchecken! Siehe auch: Images_und_Yadd's_mit_Kernel_2.6

--enable-flashrules

Targets für das bauen von Flash-Images werden aktiviert.

--enable-lirc

Erzeugt Images/Yadds mit Lirc-Support

--enable-cdkVcInfo

Das Tool cdkVcInfo wird automatisch mitgebaut. Diese Tool ist wie einige Andere auch ein Zusatz.

--enable-german-keymaps

Tastatursupport

--enable-sqlite

Aktiviert SQL-Lite Support

--enable-upnp

Es wird Unterstützung fur upnp eingebaut, ermöglicht die Box als upnp-Client zu benutzen

--enable-flac

Support für flac-Files im Audioplayer

--enable-ccache

Aktiviert Compiler-Unterstützung durch ccache

--enable-movieplayer2

Aktiviert den MP2 für Neutrino (derzeit noch experimentell) Erfahrungswerte erwünscht!

Variablen

Pfade

Es sind noch weitere Benutzeranpassungen möglich. Dafür ist es aber notwendig, etwas Wissen über die innere Funktionsweise der Makefiles zu haben.


In der Folge bezeichnet 

$(flashprefix)

den Wert der Makefile Variablen flashprefix (mit Konfiguration wie oben /dbox2/cdkflash) 

$(targetprefix)

bezeichnet den Wert der Makefile Variablen targetprefix (mit Konfiguration wie oben /dbox2/cdkroot), und 

$(buildprefix)

bezeichnet den Wert der Makefile Variablen buildprefix (mit der Konfiguration oben /tuxbox-cvs/cdk).


Um z.B. ein neutrino-squashfs.img2x zu erzeugen, werden die folgenden Verzeichnisse erstellt:

  • $(flashprefix)/root (enthält Filesystem- und GUI-unabhängige Bestandteile)
  • $(flashprefix)/root-squashfs (enthält den Kernel, für Root-Filesystem auf squashfs konfiguriert, zusammen mit seinen Treibern) und
  • $(flashprefix)/root-neutrino (enthält die Neutrinoinstallation).


Aus diesen drei Verzeichnissen, werden das Rootfilesystemverzeichniss

var-filesystemverzeichnis


Hiermit ist es möglich, einen Befehl wie 

make $(flashprefix)/root-neutrino-jffs2

bzw. wenn man sich im Verzeichnis ./tuxbox-cvs/cdk befindet, den Befehl 

make root-neutrino-jffs2

einzugeben, wobei man bei erster VAriante natürlich $(flashprefix) selbst durch den realen Pfad ersetzen muss, da $(flashprefix) nur eine make-Variable ist, welche in unserem Beispiel den Pfad zu ./dbox2/cdkflash darstellt.
Man kann so manuell gewünschten Änderungen an $(flashprefix)/root-neutrino-jffs2 vornehmen, und dann, mit dem Befehl 

make flash-neutrino-jffs2-2x

den Imagebau abschließen, um ein Image zu erstellen, das diese manuellen Änderungen enthält.


Dieses kann zwar für den einmaligen Imagebau sinnvoll sein, jedoch in vielen Fällen dürfte eine automatisierte und systematischere Methode erforderlich sein.


Customization-Scripte

Sofern diese Scripte vorhanden und ausführbar sind, werden innerhalb der wichtigsten Targets diese sogenannten Customization-Scripte automatisch aufgerufen bzw. ausgeführt. Zum aktivieren der Scripte müssen diese lediglich in ein dafür vorgesehenes Verzeichnis abgelegt werden und ausführbar sein. Dieses Verzeichnis ist standardmäßig der */cdk-Ordner. Bei Bedarf kann mit der Option 

--with-customizationsdir=[DIR]

ein alternatives Verzeichnis für Customization-Scripte festgelegt werden.


Auf diese Scripte werden zwei Argumente zur Laufzeit übergeben:


Für Imagetargets sind dies

  • $(flashprefix)

und

  • $(buildprefix)

für Yaddtargets sind diese

  • $(targetprefix)

und

  • $(buildprefix)


Die Bezeichnung "Script" ist etwas irreführend, da sie eigentlich wie normale Programme mit zwei Argumenten ausgeführt werden. Anstelle eines Shell-Scripts könnte dies z.B. ein kompiliertes C Programme, oder ein Perl-Script sein.
Der Name eines Customization Scriptes besteht in der Regel aus dem Namen eines Targetverzeichnisses bzw. einem Target und dem angefügtem *-local.sh.


Für Flash-Targets

Der Name der Customization Scripte für Images besteht aus den wie oben benannten Verzeichnissen (in diesem Fall Targets) in flashprefix,

  • root


dem Namen der jeweilige Benutzeroberfläche, als "GUI" in Klammern bezeichnet, also


"FS" zeigt an welches Filesystem gemeint ist.


so wäre die Bezeichnung der jeweiligen Scripte wie folgt aufgebaut:

  • root-local.sh
  • root-[GUI]-local.sh
  • root-[GUI]-[FS]-local.sh
  • root-[FS]-local.sh
  • var-[GUI]-local.sh


Beispiele: 

root-local.sh
root-neutrino-local.sh
root-neutrino-squashfs-local.sh
root-squashfs-local.sh
var-neutrino-local.sh


Für Yadd-Targets

Für Yadds ist das Prinzip ähnlich, nur dass es hier quasi nur einen Ordner gibt. Dafür stellvertretend steht dann


Das "GUI" in Klammern bezeichnet auch hier die jeweilig betroffene Benutzeroberflche, also


so wäre die Bezeichnung der jeweiligen Scripte so aufgebaut.

Beispiel: 

yadd-neutrino-local.sh


für andere Targets

Die bisher benannten Customization Scripte für Flash- u. Yadd-Targets sind die Gebräuchlichsten. Diese werden allerdings gewissermaßen nur an die der bestehenden Targets angehängt, anders als es bei den anderen, von denen es in Newmake noch jede Menge mehr gibt, bei denen diese als Ersatz der eigentlichen Targets dienen.
Im Prinzip ginge dies auf so gut wie alle Targets anzuwenden. Möchte man z.B. ein Contrib-Tool "customizen", etwa hdparm, kann man ein Script erstellen:

  • hdparm-local.sh

Führt man dann das Target: 

make hdparm

aus, wird beim Bauen das ausgeführt was im Customization-Script angelgt wurde. Die Aktionen im Original-Makefile werden übersprungen.


Beispiel: version-local.sh

Diese Funktion ist recht interessant und dürfte recht oft Anwendung finden (siehe auch Anpassung .version-File):
Während des make-Durchlaufs werden einige Targets ausgeführt, welche die /.version-Files bei YADD

  • version

bzw.

im Image erstellt.
Sofern eines dieser Scripte;

  • version-local.sh
  • flash-version-local.sh

vorhanden und ausführbar ist, wird es als Ersatz statt des originalen Targets ausgeführt, welches mit 

make version

bzw. 

make flash-version

angestoßen wird.


Beispiele für Customization

Das Customizationscripting soll hier durch einige Beispiele noch mehr veranschaulicht werden.


Warnung Auch falls die Beispiele in einigen Fällen benutzbar sind, werden die Scripte als Beispiele, nicht als Lösungen zu den realen Problemen gezeigt. Aus diesem Grund sind die Beispiele hier als Codefragmente, nicht als downloadbare Dateien, veröffentlicht. Bitte nicht verwenden, es sei denn es ist ungefährlich und Ihr versteht, wie sie funktionieren. Es ist grundlegende Script-Erfahrung erfordelich.


Lirc Komponenten einbauen

In einem jffs2-Image wird dies gewünscht: 

  1. Eigene /etc/hosts benutzen,
  2. Eigene neutrino.conf, bouquets.xml, services.xml benutzen
  3. einschließlich lirc-Komponenten, zusammen mit eigenen lirc Konfigurations-Dateien.

1. und 3. sind Erweiterungen, die nach $(flashprefix)/root kommen sollten, während 2. Neutrino-regeln sind, welche nach sollten $(flashprefix)/root-neutrino-jffs2 gehöhren.
Um 1. und 3. zu erreichen, wird das Script root-local.sh erstellt, z.B.: 

#!/bin/sh
# root-local.sh
flashprefix=$1
buildprefix=$2
newroot=$flashprefix/root
myfiles=/home/somewhere/dbox/myfiles
cp -f  $myfiles/etc/hosts $newroot/etc
make flashlirc
cp -fr $myfiles/var/tuxbox/config/lirc $newroot/var/tuxbox/config

Das Script für 2. heist root-neutrino-local.sh, was dem verherigen sehr ähnlich ist: 

#!/bin/sh
# root-neutrino-local.sh
flashprefix=$1
buildprefix=$2
newroot=$flashprefix/root-neutrino
myfiles=/home/somewhere/dbox/myfiles
cp $myfiles/var/tuxbox/config/neutrino.conf	 $newroot/var/tuxbox/config
cp $myfiles/var/tuxbox/config/zapit/bouquets.xml $newroot/var/tuxbox/config/zapit
cp $myfiles/var/tuxbox/config/zapit/services.xml $newroot/var/tuxbox/config/zapit


procps-Varianten von ps und top einbauen

Im Image werden die procps-Varianten von ps und top anstelle der Busybox-Version gewünscht.

In root-local.sh 

 make procps

hinzufügen.

In root-neutrino-local.sh 

 for i in top ps; do
   cp -va $flashprefix/../cdkroot/bin/$i $flashprefix/root-neutrino/bin/
   rm -v $flashprefix/root/bin/$i
 done


Games und Languages nuker

Dieses Script löscht alle Spiele (definiert als plugins mit type=1 in ihrer Konfigurationsdatei), sowie unerwünschte Sprachfiles (Neutrino angenommen). Das File sollte von root-neutrino-$filesystem-local.sh aufgerufen werden. 

#!/bin/sh
# Nukes all game plugins, as well as all locale files not listed in LANGUAGES
newroot=$1/root-neutrino-jffs2
LANGUAGES="deutsch english"
for f in $newroot/lib/tuxbox/plugins/*.cfg; do
   grep 'type=1' $f>/dev/null && rm -f $newroot/lib/tuxbox/plugins/`basename $f .cfg`.*
done
for f in $newroot/share/tuxbox/neutrino/locale/*; do
   (echo $LANGUAGES | grep -v `basename $f .locale` >/dev/null) && rm -f $f
done


/.version anpassen

Diese .version-Datei enthält unter anderem einige Daten zum verwendetem Image, die teilweise etwas kryptisch dort untergebracht sind. Verwendet werden diese Angabe z.B. In den Neutrino-Imageinformationen oder der Softwareaktualisierung und beim Bootvorgang, angezeigt durch das Infotool cdkVcInfo.


Folgende Daten können dort hinterlegt werden:


Diese Daten werden standardmäßig beim Buildvorgang angelegt:

  • kryptischer Versionsstring (enthält Imagetyp, Releasezyclus, Datum und Zeit der Erstellung)
  • Ersteller
  • Imagetyp (Release, Snapshot, Intern)
  • Imagename
  • Homepagename

Optional können noch diese Daten hinzugefügt werden, die nur in den Neutrino-Imageinformationen zusätzlich angezeigt werden, sofern diese vorhanden sind:

  • Sub-Version
  • CVS-Datum
  • 1.Kommentarzeile
  • 2.Kommentarzeile

Eine eigene /.version-File herzustellen (angezeigt von Neutrino durch dBox -> Services -> Image-Version und cdkVcInfo beim Booten) ist daher sicher ein allgemeiner Wunsch.


die .version liegt im Rootbereich des Images bzw.Yadd. Sie ist wie folgt aus 16 Spalten aufgebaut: 

RVVVYYYYMMDDHHmm

Dabei haben die einzelnen Spalten diese Bedeutung

  • R = Imagetyp: dabei bedeutet 0 = Release, 1 = Snapshot, 2 = Intern
  • V = Basis, 200 würde 2.00 bedeuten (CVS-Standard)
  • YYYY = Jahr, z.B. 2009
  • MM = Monat, z.B. 12
  • DD = Tag, z.B. 29
  • HH = Stunde, z.B. 13
  • mm = Minuten, z.B. 19

Beispiel: Für ein Release mit den genannten Beispieldaten würde der String so aussehen: 

0200200912291319


Eine eigene /.version-File herzustellen (angezeigt von Neutrino durch dBox -> Services -> Image-Version und cdkVcInfo beim Booten) ist daher sicher ein allgemeiner Wunsch. 


#/bin/sh
USER=$(whoami)
if [ $0 = $CDIR/flash-version-local.sh ] ; then
   outfile=$FLASHDIR/root/.version
   type="Image"
else
   outfile=$TARGETDIR/.version
   type="Yadd"
fi;
echo Creating $outfile ...
echo "version=`./mkversion -snapshot -version 200`"      > $outfile
echo "creator=$USER"                                     >> $outfile
echo "imagename=$USER-$type"                             >> $outfile 
echo "homepage=http://www.your-website.de"                   >> $outfile


mkversion

Das benannte Script mkversion erzeugt die etwas kryptische Versionszeichenkette: 

#!/bin/sh
releasetype=3
versionnumber=000
year=`date +%Y`
month=`date +%m`
day=`date +%d`
hour=`date +%H`
minute=`date +%M`
while expr $# > 0 ; do
case "$1" in
    -release) 
    releasetype=0
  ;;	
    -snapshot) 
    releasetype=1
  ;;	
    -internal) 
    releasetype=2
  ;;
   -version)
    versionnumber=$2
  shift
  ;;	
esac
shift
done
echo $releasetype$versionnumber$year$month$day$hour$minute


Archivierung der Images

Es ist eigentlich die Aufgabe des Buildprozesses, flashbare Images zu erzeugen, und nicht sie zu archivieren. Jedoch kann die Customization leicht dazu "missbraucht" werden, um irgendeine Art der Archivierung zu ermöglichen, wie das folgende Beispiel zeigt: 

#!/bin/sh
flashprefix=$1
imagefile=`basename $0|sed -e s/-local.sh//`
imagefilebase=`echo $imagefile|sed -e s/\.img.x//`
extension=`echo $imagefile|sed -e s/[-a-z0-9]*\.//`
newfilename="barf-"$imagefilebase-`date --iso-8601`.$extension
echo Copying $flashprefix/$imagefile to $flashprefix/$newfilename...
cp $flashprefix/$imagefile $flashprefix/$newfilename

Das Script sollte einen oder mehr der Namen 

[neutrino, enigma]-[squashfs, jffs2].[img1x, img2x]

haben. Es benennt die Files entsprechend dem Tagesdatum um.


Einige "best practices"

In diesem Abschnitt befinden sich einige Richtlinien, die zwar nicht zwingend "notwendig" sind, um korrekte Ergebnisse zu erzeilen, jedoch werden sie langfristig helfen, bessere, zuverlässigere und pflegbare Software zu erstellen. Dies betrifft Customizations, sowie zukünftige Änderungen am Makefile und deren Bestandteile selbst.
Wenn man diese Richtlinien nicht mag, kann man sie ignorieren, zumindest wenn man Customization Scripte für den eigenen Bedarf schreibt.


Idempotens

Es ist fast immer eine gute Idee zu versuchen, ein Installationsscript idempotent zu schreiben. Dies bedeutet, dass das mehrmalige Ausführen den gleichen Effekt hat wie das einmalige Ausführen. Benutze "make install".
In der Vergangenheit hat das Tuxbox Makefile die Komponenten zuerst in $(targetprefix) installiert, und dann die Imageverzeichnisse durch Kopieren der einzelnen Files aus der $(targetprefix) Hierarchie erstellt. Dieses ist keine sehr gute Softwaretechnik.
Zuerst gehört das Know-How bzgl. Installation des Paketes in das Makefile des Pakets, und soll nicht in einem einzigem großen Makefile sitzen, das einfach einzelne Files rüberkopiert. Wenn dieses Paket sich ändert, z.B. man ein Konfigurations-File hinzufügt oder löscht, wird es auch notwendig, das globale Makefile zu ändern.

Es ist häufig der Fall, dass das Makefile, das zu einem Paket gehört, include-Files, (statische) Bibliotheken, Info-Files etc. installiert, die nicht auf einem enbedded System mit beschränktem Speicher erwünscht sind. Die korrekte Lösung zu diesem (wirklichen!) Problem wäre, das Makefile des betreffenden Pakets zu ändern, entweder, um ein flashinstall-Target zu schreiben, oder das Makefile mit einem Parameter wie installsize=[full,flash] zu versehen.
Wenn dies nicht durchführbar ist, ist es durchaus sinnvoller, daß nach make -C ... install das Löschen unerwünschter Files besser ist, als das kopieren einzelner Files.
Zu erwähnen ist auch, daß in dem Schritt, der die Verzeichnisse $(flashprefix)/root-gui-filesystem erzeugt, das include-verzeichnis, sowie alle statischen Bibliotheken gelöscht werden und dynamische Bibliotheken von unbenutzten Symbolen gestrippt werden.


Antworten auf einige Fragen

Falls das Build nicht gelingt

Es gibt kein Standardverfahren was zu tun wäre, wenn das Build misslingt. Es wird versucht, hier einige Richtlinien zu geben und diese zu lesen bevor man im Forum postet.

Zuerst, überprüft man den Output der ersten zwei Schritte, autogen.sh und configure auf Fehler und Warnungen. Jede Warnung oder Fehler, außer den fünf Warnungen, die oben genannt wurden, zeigen ein Problem an, dass ein Build wahrscheinlich unmöglich macht.

Wenn ein Build abbricht, kann es die Umgebung in einem inkonsistenten Zustand versetzen. Dies gilt insbesondere für die Verzeichnisse in $(flashprefix). Wenn der Bau solch eines Make-Targets abbricht, besteht das Verzeichnis, ist entsprechend seiner Änderungszeit aktuell, und ein folgender make Befehl behandelt ihn wie fertig und okay.

Selbstverständlich wird ein fehlerhaftes Build das Ergebniss sein. Wenn ein Build eines Unterverzeichnisses von $(flashprefix) in die Brüche geht, dann lösche man es, bevor ein anderer Make Befehl ausgeführt wird.

Bei "es funktionierte gestern"-Problemen, ist vermutlich die Umgebung in solch einem Zustand. Ein mehr-oder-weniger drastischer Reinigungsbefehl (siehe oben) ist hierbei oft schneller als eine Problemsuche.

Wenn man Hilfe benötigt, siehe unten!.


Nach dem Flashen: "Kein System" auf dem LCD/Was ist diese "bad magic byte" Zeugs?

Diese Frage kommt hoffentlich nicht... Die kurze Antwort ist: Man weiß es nicht. Wir wissen es nicht. Aber, wenn Ihr diesen Artikel so weit gelesen habt, erwartet bitte keine "kurze Antworten", sondern "gute Antworten". O.K. Das Thema ist ausführlich hier besprochen worden.
Kurz gesagt, das Image "ist" in Ordnung, es ist nur dass irgendwelche Firmware in der dBox es zurückweisen wird, weil es einige "schlechte magische Bytes" auf bestimmten Adressen finden wird.

Das Programm checkImage aus dem CVS, zu finden im Verzeichnis ./hostapps/checkImage ermittelt diese "schlechten Bytes", aber ändert nichts daran, um diese zu beheben. Die Erfahrung zeigt, daß Images, die checkImage für gut findet, wirklich laufen. squashfs Images, worüber sich checkImage beschwert, laufen im allgemeinen nicht, in einigen Ausnahmefällen laufen sie aber doch.

Auch bei jffs2-Images ist es manchmal der Fall, dass sich checkImage beschwert, die Images laufen, aber eben nicht immer. Mit diesen empirischen Beobachtungen ist man nun sich selbst überlassen.

Der Buildprozess weiß, wie dieses Programm aufgerufen werden kann, um die erzeugenden Images automatisch zu überprüfen. Die Konfigurationsoption 

--with-checkImage=[none,rename,warn]

wird hierfür verwendet. Falls warn gewählt ist, wird für jedes Image, das den Test nicht besteht, eine leere Datei erzeugt, am Namen wird "_bad" angehängt. Wenn rename gewählt wird, wird das fragliche Imagefile nur umbenannt indem "_bad" angehängt wird.

Es muss noch erwähnt werden, daß die "schlechten magischen Bytes" in einem (oder mehreren!) der Partitionsteile sitzen, und werden nicht durch den abschließenden Schritt erzeugt, welche die endgültigen *.img1x und/oder *.img2x Files zusammenstellen. Es ist auch möglich, checkImage auf die einzelnen Partitionsfiles anzuwenden *.jffs2 oder *.squashfs, *.flfs1x, *.flfs2x. Schließlich besitzt checkImage eine Debugoption, die nützlich sein kann.


Ich habe ein Fehler gefunden!

Bugs, Unklarheiten, Verbesserungsvorschläge, etc. der Software sollten vorzugsweise im Cross Development Kit - Forum des Tuxbox-Boards gepostet werden.


Ich benötige Hilfe!

Supportanfragen können im Cross Development Kit - Forum des Tuxbox-Boards gepostet werden. Postings in deutsch oder englisch sind willkommen. Bitte nicht vergessen, die benutzten Konfigurationsoptionen zu erwähnen.


Weblinks



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.


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