TuxBoxWIKI - Benutzerbeiträge [de]

Vorlage:Neutrino-HD-Info

2015-01-10T13:11:10Z

Dixidix: Leichte Textanpassungen, Verkürzungen

[[Bild:NeutrinoHD.png|400px]]

'''Neutrino-HD''' ist eine freie unter [[GPL]]-Lizenz stehende [[GUI|Benutzeroberfläche]] für SetTop-Boxen. Neutrino-HD ist ein [[Fork]] des ursprünglich vom [[DBox2 Software Projekt|Tuxbox]]-Projekt für die [[dBox2]] entwickeltem [[Neutrino]] und wurde auf Geräte mit [[HDTV]]-Unterstützung portiert und wird speziell dafür weiterentwickelt.

Diese [[GUI]] wird namentlich und werksseitig auf Receivern von [[CST]] eingesetzt und zusammen mit Community-Enwicklern weiter entwickelt. Von der [[Tuxbox]]-Community wurde die [[GUI]] auf verschiedene andere Boxtypen portiert und wird dort unter dem Namen [[Neutrino-MP]] bzw. namentlich daraus abgeleiteten Community-[[Fork]]s geführt und ist unter anderem auf SH4-basierten [[Spark]]-Boxen des Herstellers [http://www.fulansoft.com Fulan], die [[TripleDragon]], auf einigen [http://www.azbox.eu AZbox]-Receiver Serien und ist ansatzweise auf [[PC]] und auf der [http://de.wikipedia.org/wiki/Raspberry_Pi Raspberry Pi-Plattform] lauffähig.
Erwähnt sei noch ein weiteres Derivat namens [[NeutrinoHD2]]. Benutzern von [[NeutrinoHD2]] dürfte die alternativen Optik auffallen wobei diese Variante auf einen deutlich älteren Softwarestand basiert und nur teilweise oder garnicht auf den aktuellen Stand gebracht bzw. alternativ angepasst. Einige Funktionen dürften deshalb in diesem Artikel nur begrenzt oder nicht zutreffen.

<div style="margin: 0; margin-top:10px; margin-right:10px; border: 1px solid #999999; padding: 8px 10px 11px 10px; background-color:white; align:right; ">
* [http://www.dbox2-tuning.net/ulc/index.php?action=downloadfile&filename=NeutrinoHD_Quickstart_1.0.pdf&directory=Doku&‎ Quickstart Anleitung zum Download als PDF]
</div>

Neutrino:Einstellungen:IDE-MMC-HDD-Setup

2012-06-25T15:52:09Z

Dixidix: Hinweis zum Modemport

[[Category:Register]]
[[Category:Neutrino]]
{{Neutrino_sidebar}}

Nach jahrelangen "Übergangslösungen" gibt es nun für die [[Neutrino]]-GUI eine einheitliche Möglichkeit, eingebundene Laufwerke, wie z.B [[HDD|Festplatten]] oder eine [[SD-Karte|MMC-Karte]] komfortabel einzurichten und zu warten. Ziel war es, eine möglichst umfassende aber kompakte und für den Benutzer schnell und unkomplizierte Möglichkeit anzubieten.
Unterstützt werden bis zu 2 [[HDD|Festplatten]] und 1 [[SD-Karte|MMC]] auf denen jeweils bis zu 4 Partitionen eingerichtet werden können. Das Anlegen einer [[Swap-Partition]] und die Freigabe für [[NFS]] und [[Samba]] (Windows-Freigaben) sind ebenfalls möglich.
Diese Laufwerksverwaltung, im Folgendem als Menü bezeichnet, nutzt die Funktionalität des Linux-Tools "[[fdisk]]".

__TOC__

=Voraussetzungen=
Vorraussetzung dafür ist natürlich die entsprechende Ausstattung des jeweiligen [[Receiver]]s mit einem passendem [[Hardware:dbox2:IDE-Interface|IDE-Interface]]. Bei der [[hardware:dbox2|dBox2]] wäre dies durch ein nachrüstbares [[Hardware:dbox2:IDE-Interface|IDE-Interface]] zum Anschluß von IDE/SATA-Festplatten oder ein integriertes MMC-Interface als separates Bauteil oder kombiniert mit einem [[Hardware:dbox2:IDE-Interface|IDE-Interface]] der Fall. Images mit Kernel 2.6.x und somit andere Receivertypen, werden derzeit noch nicht unterstützt.
Ob Dein Image ein Laufwerk-Setup besitzt und auch für [[NFS]] und/oder [[Samba]] gerüstet ist, hängt davon ab, wie du es gebaut hast. Näheres zu den dafür notwendigen Build-Optionen findest du unter [[Tuxbox Entwicklungsumgebung|Entwicklung]]. Die [[Images|Tuxbox-Distributionen]] haben dieses Menü standardmäßig eingebaut. Ein Blick in die [[Neutrino:Service:Image Informationen|Imageinformationen]] gibt ebenfalls Aufschluß:
[[Bild:Ide imageinfo.jpg|thumb|none|150px|Menü-Version Anzeige]]

=Anmerkung=
{{request}}

=System=
Es wäre größtenteils auch möglich auch ohne dieses Menü, seine Laufwerke z.B. über Telnet einzurichten. Man muss nur die entsprechenden Einstellungen und Änderungen an den Startscripten und Systemdateien manuell vornehmen. Deshalb der Vollständigkeit halber einige Erläuterungen über das, was das Menü eigentlich macht.

 
<div style="padding:0.5em; margin-bottom:1em; border: 2px solid #a00;">[[Bild:Stop hand.png]] '''HINWEIS:'''
''Damit die Laufwerke auch beim Booten so wie sie eingerichtet wurden zur Verfügung stehen, ist die Einrichtung immer mit '''Übernehmen''' ''abzuschließen, denn nur so werden die benötigten Einstellungen dem System (Startscripte, fstab, etc...) mitgeteilt! In der Regel wird der Benutzer beim Schließen des Menüs darauf hingewiesen, falls Änderungen vorgenommen wurden.''</div>

==Startscripte==
Es gibt einige Startscripte, die das Menü anlegt.
 
<div style="padding:0.5em; margin-bottom:1em; border: 2px solid #a00;">[[Bild:Stop hand.png]] '''HINWEIS:'''
''Es ist nicht ratsam die Startscripte manuell zu verändern bzw. zu löschen, sofern das nicht ein ausdrücklicher Wunsch ist. Diese Scripte sind teilweise verlinkt und es kann vorkommen, dass diese dann nicht mehr richtig funktionieren oder wegen falscher Rechte nicht mehr das machen was sie sollen. Zum Löschen sollte man den Menüpunkt '''[[#Zur.C3.BCcksetzen|Zurücksetzen]]''' verwenden''</div>

===/etc/init.d/06hdd===
Hier werden die Ladebefehle für fs-Module und [[hdparm]] eingetragen. Das Menü sorgt auch dafür, dass nur die Einträge für Treiber-Module eingetragen werden, die auch benötigt werden.
Beispiel:
#!/bin/sh
echo "/etc/init.d/06hdd generated from neutrino ide/mmc/hdd drive-setup
13.12.2009 - 22:28:04
BETA! 0.4 do not edit!"
case $1 in
start)
insmod reiserfs
insmod fat
insmod vfat
insmod jbd
insmod ext3
insmod ext2
insmod xfs
insmod ide-core
insmod dboxide
insmod ide-detect
insmod ide-disk
insmod mmc2
hdparm -S6 -W0 -c1 /dev/ide/host0/bus0/target0/lun0/disc
hdparm -S6 -W0 -c1 /dev/ide/host0/bus0/target1/lun0/disc
;;
stop)
;;
esac
exit 0

===/etc/init.d/07mounts===
hier werden die Mountbefehle abgelegt.
Beispiel:
#!/bin/sh
echo "/etc/init.d/07mounts generated from neutrino ide/mmc/hdd drive-setup
13.12.2009 - 22:28:04
BETA! 0.4 do not edit!"
case $1 in
start)
mount -a
swapon -a
;;
stop)
umount /hdd1
umount /hdd
umount /hdd2
umount /mmc
swapoff -a
;;
esac
exit 0

===/etc/init.d/31sambaserver===
Hier werden die Start und Stop-Befehle für den [[Samba]]server abgelegt. Dieses Script wird nur erzeugt wenn auch [[Samba]] im [[Images|Image]] verfügbar ist.
#!/bin/sh
# /var/etc/init.d/31sambaserver generated from neutrino ide/mmc/hdd drive-setup
# BETA! 1.50 29.03.2010 - 21:01:44

case $1 in
start)
if [ -e /var/etc/.sambaserver -a -e /etc/smb.conf ]; then
/bin/nmbd -D
/bin/smbd -D -a -s /etc/smb.conf
fi
;;
stop)
killall smbd
killall nmbd
;;
esac
exit 0

====/etc/smb.conf====
weiterhin wird die für [[Samba]] benötigte Konfigurationsdatei erzeugt:
; /etc/smb.conf generated by neutrino ide/mmc/hdd drive-setup, do not edit!
; BETA! 1.50 29.03.2010 - 21:01:44
[global]
interfaces = 192.168.1.22/24
workgroup = MSHEIMNETZ
server string = Samba@Dbox
netbios name = dbox
security = share
load printers = no
guest ok = yes
guest account = root
encrypt passwords = yes
os level = 0
log level = 0
browseable = yes
preserve case = yes
short preserve case = yes
character set = iso8859-1
[Share_1_2]
comment = P2@FUJITSU MPB3032ATU E
path = /mnt/hdd1
read only = no
public = yes

===Verlinkte Startscripte===
Wie man sieht, stehen hier zwei Blöcke in den jeweiligen Scripten, die abwechselnd einmal mit dem Parameter '''start)''' und '''stop)''' ausgeführt werden. Diese Scripte sind wie alle anderen Startscripte verlinkt und werden beim Booten mit dem Start-Parameter innerhalb der '''/etc/init.d/rcS''' und beim Herunterfahren mit dem Stop-Parameter von '''/etc/init.d/rcK''' (entspricht dem [[halt]]-Script) aufgerufen. Die verlinkten Scripte haben dann jeweils noch ein Präfix:
*'''S''' = '''S'''tart
*'''K''' = Stop ('''K'''ill)

 
<div style="padding:0.5em; margin-bottom:1em; border: 2px solid #a00;">[[Bild:Stop hand.png]] '''HINWEIS:'''
''Im mount-Script ist es notwendig, dass im Stop-Block die Einträge zum Aushängen der jeweiligen Laufwerke eingetragen sind. Der Stop-Block im hdd-Script kann im Prinzip leer bleiben bzw. sollte keine unload-Befehle für ide-Module enthalten, damit die Laufwerke auch vom System beim Herunterfahren zurückgesetzt werden können.''</div>

Hier die Benennung der Links
*/etc/init.d/'''S'''06hdd
*/etc/init.d/'''K'''06hdd
*/etc/init.d/'''S'''07mounts
*/etc/init.d/'''K'''07mounts
*/etc/init.d/'''S'''31sambaserver
*/etc/init.d/'''K'''31sambaserver

Das Schreiben der Scripte und die anschließende Verlinkung wird vom Menü automatisch durchgeführt.
 
<div style="padding:0.5em; margin-bottom:1em; border: 2px solid #a00;">[[Bild:Stop hand.png]] '''HINWEIS:''' Davon abhängig ob sich '''/etc''' in einer beschreibbaren Partition ([[jFFS2|jffs2]], [[YADD Mini-Howto|Yadd]]) oder im Readonly-Bereich ([[squashFS|squashfs]]) befindet, werden die Scripte bei [[squashFS|squashfs]]-[[Images]] in
*/var/etc/init.d/
oder bei [[YADD Mini-Howto|Yadd]] oder [[jFFS2|jffs2]]-[[Images]] in
*/etc/init.d/
abgelegt.
Wo das Menü die Dateien hinschreiben muss, wird automatisch erkannt. Das [[Initsystem]] ist ausserdem so ausgelegt, dass es immer die richtige Version der Init-Scripte verwendet. </div>

==fstab==
Das Menü ist für die Verwendung von [[fstab]] (Linux-Standard) ausgelegt. Diese wird ebenfalls vom Menü verwaltet. Man braucht sich also auch hier um nichts zu kümmern. Es besteht aber die Möglichkeit, aus welchen Gründen auch immer, auf die Verwendung der [[fstab]] zu verzichten und kann statt der im mount-Script eingetragenen üblichen automatischen Einträge wie:
mount -a
swapon -a
auch normale Mounteinträge in das Startscript eintragen lassen. Im Untermenü '''[[#Erweiterte_Einstellungen|Erweitert]]''' steht die Option zur Verfügung, ob du [[fstab]] verwenden willst oder nicht.
[[Bild:Ide_service_setup_fstab.jpg|thumb|none|300px|Fstab-Optionen]]
Ausserdem kann man hier auch festlegen, ob die [[fstab]]-Parameter für [[Dateisystem]]e automatisch oder die vom Benutzer festgelegten [[Dateisystem]]e verwendet werden sollen. Standardvorgabe ist

'''Dateisystem automatisch zuweisen = aus'''

 
<div style="padding:0.5em; margin-bottom:1em; border: 2px solid #a00;">[[Bild:Stop hand.png]] '''HINWEIS:''' ''Unter Umständen ist es bei Verwendung von ext2/3 ratsam, auf die Autofunktion zu verzichten, da [[ext3]] als [[ext2]] erkannt werden kann.''
''Werden normale Einträge verwendet, wird immer das vom Benutzer festgelegte [[Dateisystem]] verwendet.

''Auch für [[fstab]] gilt der Grundsatz, dass abhängig von der Beschreibbarkeit des '''/etc'''-Ordners, '''[[fstab]]''' nach '''/var/etc/fstab''' oder '''/etc/fstab''' geschrieben wird. Auch das regelt das Menü automatisch.''
''Ebenso muss [[BusyBox|Busybox]]-Mount so angepasst sein, damit bei Bedarf auf die richtige [[fstab]] zugegriffen werden kann! Ab [[BusyBox|Busybox]]-Version 1.14.4 ist dies bei der Tuxbox-Variante der Fall.''</div>

==drivesetup.conf==
Hier werden einige Konfigurationsdaten "zwischengelagert", damit keine benötigten Informationen verloren gehen. Die Bezeichnung ".conf" als solche ist eigentlich nicht ganz korrekt, weil das Menü einige Daten dort eigenständig verwaltet, um zum einem dem Benutzer möglichst zutreffende Daten anzuzeigen und zum Anderen selbst auf aktuelle dem System angepasste Einstellungen zugreifen zu können. Dies ist beispielsweise der Fall, wenn man eine Partition löscht, aber im Menü selbst nichts geändert hat und Einträge wie z.B. für Filesystem und Mountpoint nicht mehr passen würden. In diesem Fall setzt das Menü die entsprechenden Einstellungen zurück. Wird hingegen nur eine Partition deaktiviert, also nicht eingehangen, bleiben diese Einstellungen auf Abruf bereit. Beispielsweise werden auch für die Einrichtung von bereits formatierten Laufwerken die vom System abgerufenen Informationen automatisch übernommen.
 
<div style="padding:0.5em; margin-bottom:1em; border: 2px solid #a00;">[[Bild:Stop hand.png]] '''HINWEIS:''' ''{{note_drivesetup.conf}}''</div>

==/etc/exports==
Auch diese Datei wird vom Menü angelegt, sofern NFS-Freigaben eingerichtet wurden und das Image für den Betrieb eines NFS-Servers ausgelegt ist. Siehe [[Neutrino:Service:IDE-MMC-HDD-Setup#NFS-Freigabe_einrichten|NFS-Freigabe einrichten]]
 
<div style="padding:0.5em; margin-bottom:1em; border: 2px solid #a00;">[[Bild:Stop hand.png]] '''HINWEIS:''' ''Auch für [[exports]] gilt hier, dass abhängig von der Beschreibbarkeit des '''/etc'''-Ordners, '''[[exports]]''' nach '''/var/etc/exports''' oder '''/etc/exports''' geschrieben wird. Auch das regelt das Menü automatisch.
''Im Normalfall ist /etc/[[exports]] ein Symlink auf /var/etc/[[exports]].''</div>

==Module==
Das Menü nutzt standardmäßig die [[Dateisystem]]-Treibermodule unter
/lib/modules/[KERNEL]/kernel/fs/...
die Ide-Module unter
/lib/modules/[KERNEL]/kernel/drivers/ide/...
die [[SD-Karte|MMC]]-Module und dboxide.o unter
/lib/modules/[KERNEL]/misc
Alternativ kann man auch die Module in einen benutzerdefinierten Ordner legen, um evtl. weitere Module hinzuzufügen oder zu ersetzen (siehe [[#Benutzerdefinierter_Ordner|Benutzerdefinierter Modul-Ordner]]).
<div style="padding:0.5em; margin-bottom:1em; border: 2px solid #a00;">[[Bild:Stop hand.png]] '''HINWEIS:''' ''Die in den genannten Standardverzeichnissen vorhandenen Module werden ignoriert sofern gleichnamige benutzerdefinierten Module verwendet werden. Auch bei der Übernahme von Einstellungen werden dann auch immer die alternativen Module in die Startscripte übernommen.''

''Bei nachinstallierten Dateisystem-Modulen ist darauf zu achten, dass auch die dazu gehörenden Tools nachinstalliert werden (siehe [[Neutrino:Service:IDE-MMC-HDD-Setup#Tools|Tools]])!''</div>

===Verwendbare Filesysteme===
Es können derzeit diese Dateisysteme unter Verwendung der dafür notwendigen Module genutzt werden:
*'''ext2'''
*'''ext3''' (benötigt jbd.o)
*'''reiserfs'''
*'''vfat''' (benötigt fat.o)
*'''xfs'''
Konform dazu werden die passenden [[#Tools|Tools]] benötigt!

Die Nutzung von ntfs/hpfs ist derzeit nicht möglich!

===Unterstützte MMC/SD-Treibermodule (Kernel 2.4.x)===
{{mmc module}}

==Tools==
Tools wie z.B. [[fdisk]], [[mkfs.ext3]] oder die passenden Checking- oder auch Repair-Tools liegen in der Regel unter
/sbin
Alternative Tools sollten funktionieren, wenn man sie unter '''/var/bin''' ablegt. Dies sollte normalerweise möglich sein, kann aber von Image zu Image anders sein, es kommt daher darauf an, wie die notwendigen Umgebungsvariablen für die Pfade in deinem Image angelegt wurden.
Unterstützt werden diese Dateisysteme und FS-Tools:
{{supported_fs}}

==Verwendung von CF-Karten==
Die Verwendung von [[CF-Karten]] sollte möglich sein, jedoch sind Einstellungen bzw. Parameter, wie sie mittels Hdparm für Festplatten vorgesehen sind, natürlich nicht nutzbar.
Siehe [[#Spindown|Spindown]], [[#WriteCache|WriteCache]]

=Menüaufbau=
Das Menü ist in ein [[#Hauptmenü|Hauptmenü]] und mehrere Untermenüs ([[#Laufwerksmenü|Laufwerk]]- u. [[#Partitionsmenü|Partitionsmenüs]]) unterteilt und gibt somit quasi die Struktur der Laufwerke im System wieder.

==Hauptmenü==
[[Bild:Ide_service_setup_main_set-ide.jpg|thumb|none|300px|Hauptmenü inaktives IDE-Interface und ohne geladene SD/MMC-Module]][[Bild:Ide_service_setup_main_set-ide.png|thumb|none|300px|Hauptmenü wenn alle Module geladen wurden]]

===Übernehmen===
Alle Einstellungen werden gespeichert, Initscripte werden geschrieben und verlinkt sowie [[fstab]] und sofern unterstützt auch die Konfigurationsdateien für NFS- u. Sambaserver. Diese Funktion ist immer dann notwendig, wenn geänderte Einstellungen auf das System übertragen werden sollen. Falls Änderungen vorgenommen wurden, wird man beim Verlassen des Menüs gefragt, ob man das auch möchte.

Es spielt auch keine Rolle ob man die IDE- und MMC/SD-Treiber einzeln oder auf einen Rutsch aktiviert.
Durch das Übernehmen werden die eingeschalteten Treiber geladen, egal ob dafür Geräte installiert sind oder nicht. Falls kein Gerät, also Festplatten oder MMC/SD-Karten, durch die Treiber aktiviert werden konnten, werden logischerweise auch keine Geräte im Menü angezeigt, die man verwenden könnte. Sollte man aber eine Platte oder Karte eingebaut haben und dennoch keines angezeigt werden, kann dies verschiedene Ursachen haben. In erster Linie sollte man darauf achten, dass Festplatten korrekt verbunden und gejumpert sind, also entweder Master oder Slave. [[Cabel Select|CS]] dürfte nicht ohne weiteres funktionieren. Ob das Interface richtig eingebaut wurde, ist natürlich auch wichtig. Sollte dennoch nichts gehen, kann man den Fehler melden (http://forum.tuxbox.org/bugs). In dem Fall bitte auch ein [[Bootlog]] machen.
 
<div style="padding:0.5em; margin-bottom:1em; border: 2px solid #a00;">[[Bild:Stop hand.png]] '''HINWEIS:'''
''Nicht alle Änderungen sind relevant und müssen übernommen werden, weil einige vom System automatisch übernommen werden oder nur für gewisse Aufgaben wie z.B. Formatieren oder Prüfen notwendig sind. Dies trifft beispielsweise auf die verwendeten Dateisysteme oder Partitionsgrössen zu. Einstellungen dieser Art werden daher nur formal in der Konfigurationsdatei gespeichert. Beim Übernehmen werden auch keine Änderungen am Dateisystem oder Partitionsgrößen vorgenommen. Diese Aufgaben werden direkt in den dafür vorgesehenen Untermenüs vorgenommen.''</div>

===IDE-Interface===
Hier wird das [[Hardware:dbox2:IDE-Interface|IDE-Interface]] mit entsprechender Option eingestellt.
* aus
* aktiv mit Standard-IRQ
* aktiv mit IRQ6

===Sektion: MMC/SD===
====Verwendeter MMC/SD-Treiber====
Ermöglicht die Auswahl des gewünschten MMC-Moduls. Sollte im Image keine MMC-Modul vorhanden sein, entfällt dieser Menüpunkt

====Lade-Parameter====
Sofern ein Modul bestimmte Parameter unterstützt, kann man hier ein Untermenü öffnen und mit Hilfe einer Eingabemaske zusätzliche Ladeparameter angeben.

===Erweitert===
Unter diesem Menüpunkt lassen sich einige Sonderfunktionen aktivieren oder deaktivieren.
[[Bild:Ide service setup advanced.png|thumb|none|300px|Untermenü: Erweitert]]

====fstab====
siehe [[#fstab|fstab]]

====insmod====
Hier besteht die Möglichkeit, dem Ladekommando eine oder mehrere Optionen mitzugeben, die auch in die Initscripte eingetragen werden. Hierfür öffnet man über den Menüpunkt '''Optionen''' einen Eingabedialog, in dem man die gewünschten Optionen eintragen kann.
 
<div style="padding:0.5em; margin-bottom:1em; border: 2px solid #a00;">[[Bild:Stop hand.png]] '''HINWEIS:''' ''Auch wenn das Menü diese Möglichkeit bereitstellt, sollte man von dieser Funktion möglichst keinen Gebrauch machen, da die Funktionsweise der Ladekommandos eigentlich optimal auf das System abgestimmt ist! Die eingetragenen Optionen wirken sich ausserdem pauschal auf alle zu ladenenden Module aus und kann unter Umständen das Bootverhalten zum Teil erheblich negativ (lange Bootzeiten etc...) beeinflussen. Wenn du diese Funktion benutzt, solltest du also schon wissen was du machst!''</div>

====Treiber-Module====
=====Benutzerdefinierter Ordner=====
Hier kann man ein benutzerdefinierts Verzeichnis für IDE-, MMC- oder Fs-Treiber-Modul angeben. Diese Option bewirkt, dass ein Treiber-Modul, welches sich in diesem Ordner befindet, bevorzugt verwendet wird also auch dann wenn bereits ein gleichnamiges Modul in einem dafür bereits vorhandenen Modulordner vorliegen sollte (siehe [[#Module|Module]]). Standardvorgabe ist
/var/lib/modules
 
<div style="padding:0.5em; margin-bottom:1em; border: 2px solid #a00;">[[Bild:Stop hand.png]] '''HINWEIS:''' ''Auch diese Option sollte nur bedingt genutzt werden.
''{{note_drivesetup.conf}}''''</div>

====Formatierungsoptionen====
Mit diesen Einstellungen (ab V1.79) ist es möglich den Tools, die für die Erzeugung der [[Dateisystem]]e verwendet werden, bestimmte Parameter zu übergeben. Die vorgegebenen Werte sollten eigentlich optimal passen, jedoch kann man hier diverse Anpassungen vornehmen. Im Menü stehen auch hier nur die von deinem [[Images|Image]] unterstützten [[Dateisystem]]e. Die Eingabe der Optionen erfolgt über eine Eingabemaske.
Welche Parameter verwendet werden können, kann man aus den entsprechenden Manpages erfahren.
*ext2/3 http://linux.die.net/man/8/mke2fs
*xfs http://linux.die.net/man/8/mkfs.xfs
*vfat/msdos http://linux.die.net/man/8/mkfs.vfat
*reiserfs http://linux.die.net/man/8/mkfs.reiserfs
*swap http://linux.die.net/man/8/mkswap
 
<div style="padding:0.5em; margin-bottom:1em; border: 2px solid #a00;">[[Bild:Stop hand.png]] '''HINWEIS:'''
''Auch hier wieder der Hinweis, dass es sich hier um Experteneinstellungen handelt, bei denen es bei falscher Anwendung zu Fehlfunktionen kommen kann! Unter Umständen werden auch nicht alle Optionen vom Tuxbox-System unterstützt.''</div>

====Zurücksetzen====
Mit dieser Funktion werden sämtliche Treiber entladen, Initscripte sowie /etc/exports gelöscht und die Einstellungen in drivesetup.conf auf die Standardwerte zurückgesetzt.
Nachdem dieser Menüpunkt aufgerufen wurde, muss erst mit OK bestätigt werden, erst dann erfolgt die Rücksetzung und das Menü wird neu geladen.

===Sektion: Laufwerke auswählen===
Je nachdem, wieviel und welche Laufwerke (Festplatten, SD/MMC) erkannt wurden, kann man diese hier auswählen und im entsprechendem Untermenü (Laufwerksmenü) die jeweiligen Einstellungen und Aufgaben vornhemen.

====Laufwerksmenü====
[[Bild:Ide service setup discmenue.png|thumb|none|300px|Laufwerksmenü]]
Im Menükopf ist zu erkennen, welches Laufwerk gerade bearbeitet wird.
* hda (Master)
* hdb (Slave)
* mmc

=====Sektion: HDD-Parameter=====
Diese Sektion ist nicht bei SD/MMC-Laufwerken verfügbar.

=====Ausschalten nach (Sekunden)=====
Ändert die Spindownzeit einer Festplatte, sofern dies von dieser unterstützt wird. Siehe [[#Spindown|Spindown]]

=====Schreib-Cache=====
Ändert den Parameter Writecache für Festplatten, sofern dies von dieser unterstützt wird. Siehe [[#WriteCache|Writcache]]

=====Swap-Partition anlegen=====
Öffnet ein Untermenü, um eine Swap-Partition anzulegen. Siehe [[#Swap_anlegen|Swap-Partition anlegen]]

=====Sektion: Partionen bearbeiten=====
Alle verfügbaren Partitionen werden hier sofern diese bereits angelegt sind zur Auswahl angezeigt. Durch Anwahl einer Partition, gelangt man in das Partitionsmenü, in dem man verschiedene Einstellungen setzen und Aufgaben für die betreffende Partition ausführen kann.

=====Partitionsmenü=====
siehe [[#Partitionen_einrichten|Partitionen einrichten]] und [[#Aufgaben|Aufgaben]]

=Fabrikneue Festplatte und/oder MMC Laufwerk einrichten=
Am Beispiel der Einrichtung einer Festplatte soll hier der Ablauf der Einrichtung erklärt werden. Die Einrichtung einer MMC-Karte erfolgt auf die gleiche Weise.

Nach dem das Menü aufgerufen wurde, sieht man zunächst nur Grundfunktionen, da ja bisher noch kein Treiber geladen wurde:
Um das [[Hardware:dbox2:IDE-Interface|IDE-Interface]] zu aktivieren, wird die Option '''aktiv mit Standard-IRQ''' ausgewählt. Um auch (einzeln) eine MMC-Karte einzurichten, muss der gewünschte mmc-Treiber gewählt werden:
[[Bild:Ide_service_setup_main_set-ide.jpg|thumb|none|300px|Hauptmenü: alles deaktiviert]]

 
<div style="padding:0.5em; margin-bottom:1em; border: 2px solid #a00;">[[Bild:Stop hand.png]] '''HINWEIS:'''
''Sollte der Modemport weiterhin benötigt werden, besteht die Möglichkeit das [[IDE-Interface]] alternativ über den IRQ6 zu nutzen. Diese Option ist technisch zwar gegeben, jedoch nicht ohne erforderliche Modifikationen an der Hardware nutzbar und sollte in der Regel unverändert bleiben! [[Hardware:dbox2:IDE-Interface#MultiCam_.2F_MC_das_unbekannte_Wesen.3F|Siehe Modemport]]''</div>

Wenn die Auswahl getroffen wurde, den Eintrag '''"Übernehmen"''' drücken. Es werden nun alle erforderlichen Module geladen.
[[Bild:Ide service setup load.jpg|thumb|none|300px|Hauptmenü: laden...]]
Stehen alle Daten zur Verfügung, werden nun alle gefundenen Laufwerke aufgelistet:
[[Bild:Ide service setup main loaded-hdd.jpg|thumb|none|300px|Hauptmenü: Auflistung]]

Jetzt kann man sich ein Laufwerk auswählen und entsprechende Einstellungen für Spindown und/oder Writecache vornehmen und weitere Vorgänge starten.
[[Bild:Ide service setup main loaded-hdd-selected.jpg|thumb|none|300px|1.Untermenü: nächste Schritte]]

==MMC/SD==
Bei vorhandenem SD/MMC Support im jeweiligem [[Images|Image]] ist es möglich Speicherkarten bis maximal '''1GB''' zu verwenden. Höhere Kapazitäten werden derzeit nicht unterstützt. Ob Dein [[Images|Image]] SD/MMC-Karten unterstützt, erkennt man daran, dass der zugehörige Menüeintrag für die Modul- bzw. Treiberauswahl vorhanden ist. Eine Nachinstallation ist ebenfalls möglich. Siehe [[#Module|Module]]!

===Aktivierung===
Die Aktivierung hierfür erfolgt über die Treiberauswahl und durch anschließendes '''Übernehmen'''.
[[Bild:Ide service setup main loaded-mmc-activating.jpg|thumb|none|300px|Hauptmenü: MMC aktivieren]]

===Lade-Parameter===
Ausserdem besteht für [[SD-Karte|MMC]] die Option, dem Treiber zusätzliche Ladeparameter mitzugeben. Diese können unter dem Menüpunkt '''Lade-Parameter''' eingetragen werden. Die Eingabe erfolgt über eine entsprechende Eingabemaske, sobald der jeweilige Treiber im Untermenü ausgewählt wurde. Eine Eingabe ist dabei nur möglich, wenn das Treiber-Modul auch installiert ist. Welche Parameter in Frage kommen, kann man ggfs. in den Sourcen der Module einsehen.
 
<div style="padding:0.5em; margin-bottom:1em; border: 2px solid #a00;">[[Bild:Stop hand.png]] '''HINWEIS:''' ''Es handelt sich auch hier um eine Expertenfunktion. Fehlerhafte Eingaben, können Ladefehler verursachen oder die Übernahme der Einstellungen schon im voraus verhindern und die Lade-Parameter haben nichts mit den Kommando-Optionen für [[#insmod|insmod]] oder [[#insmod|modprobe]] zu tun. Diese Parameter betreffen nur die Treiber selbst!''</div>
[[Bild:Ide service setup main mmc_load_param.jpg|thumb|none|300px|MMC Untermenü: Ladeparameter]]

==Spindown==
 
<div style="padding:0.5em; margin-bottom:1em; border: 2px solid #a00;">[[Bild:Stop hand.png]] '''HINWEIS:'''
''Dieser Menüpunkt entfällt bei MMC.''</div>

Diese Einstellung legt fest nach welcher Zeit eine Festplatte abgeschaltet wird.
Dafür wird der Menüeintrag "Ausschalten nach" gewählt...
[[Bild:Ide service setup main loaded-hdd-selected-spindown.jpg|thumb|none|300px|1.Untermenü: Spindown]]...und kann dann die Angaben in Sekunden eingeben. [[Bild:Ide service setup main loaded-hdd-selected-spindown-setup.jpg|thumb|none|300px|Spindown Eingabe]]

==WriteCache==
 
<div style="padding:0.5em; margin-bottom:1em; border: 2px solid #a00;">[[Bild:Stop hand.png]] '''HINWEIS:'''
''Dieser Menüpunkt entfällt bei MMC.''</div>

Diese Einstellung legt fest ob eine Festplatte mit WriteCache arbeitet oder nicht.
Dafür wird der Menüeintrag "Schreib-Cache" gewählt...
[[Bild:Ide service setup main loaded-hdd-selected-wcache.jpg|thumb|none|300px|1.Untermenü: Writecache]]

 
<div style="padding:0.5em; margin-bottom:1em; border: 2px solid #a00;">[[Bild:Stop hand.png]] '''HINWEIS:'''
''Vor allem ältere Platten unterstützen diese Funktion nicht, evtl. kann diese Einstellung sogar Fehlfunktionen hervorrufen, im Zweifelsfall einen Blick ins [[Bootlog]] werfen oder diese Option nicht einschalten!''</div>

==Partition anlegen==
Hierfür den Menüpunkt "Partition hinzufügen" anwählen:
[[Bild:Ide service setup main loaded-hdd-selected-add-part.jpg|thumb|none|300px|1.Untermenü]]
Du gelangst nun in das nächste Untermenü, wo alle relevanten Einstellungen für die gewünschte Partition vorgenommen werden können.
Man erhält zunächst auch einen Überblick über den noch verfügbaren freien partitionierbaren Speicherplatz. Die Auswahl der Partitionsnummer wird vom Menü automatisch vorgenommen und wird im Menükopf angezeigt. Dabei wird immer die niedrigste freie Partition zugeordnet, man braucht sich also darum nicht zu kümmern. Es können bis zu 4 Partitionen erstellt werden, sofern genug Platz frei ist.
 
<div style="padding:0.5em; margin-bottom:1em; border: 2px solid #a00;">[[Bild:Stop hand.png]] '''HINWEIS:'''
''Bei den angelegten Partitionen handelt es sich dabei um primäre Partitionen. Erweiterte Partitionen bzw. Partitionstabellen anderen Typs können nicht erstellt werden, dies wäre auch für die Zwecke, für die eine [[Receiver|Set-Top-Box]] üblicherweise dient unnötig und in der Regel dürfte eine Partition sogar immer ausreichend sein.''</div>
[[Bild:Ide service setup main loaded-hdd-selected-add-part-setup.jpg|thumb|none|300px|Partition hinzufügen]]

Du gibst nun deine gewünschten Vorgaben ein:

===Partition aktivieren===
'''Ja''', bewirkt lediglich, dass diese Partition auch eingehangen wird. Bei '''Nein''' wird die Partition angelegt jedoch nicht eingehangen. Im Prinzip ist hier die Vorgabe '''Ja''' üblich.

===Dateisystem festlegen===
Hier kannst du das gewünschte Dateisystem angeben, mit dem die Partition formatiert werden soll. Die Auswahl ist nicht statisch, sondern ermöglicht die Auswahl aller vorhandenen FS-Kernelmodule die im Image vorhanden sind, was bedeutet, dass auch nachinstallierte Module verfügbar sind.
[[Bild:Ide service setup main loaded-hdd-selected-add-part-setup-fs.jpg|thumb|none|300px|Dateisystem]]

===Mountpoint festlegen===
Der Menüeintrag hierfür lautet "Einhängen nach". Wähle bitte hier den gewünschten Mountpoint aus.
[[Bild:Ide service setup main loaded-hdd-selected-add-part-setup-mp.jpg|thumb|none|300px|Mountpoint ]]
Hierfür wird der Auswahldialog über den Browser genutzt.
[[Bild:Ide service setup main loaded-hdd-selected-add-part-setup-mp-select.jpg|thumb|none|300px|Mountpoint Dialog]]

===Partitionsgröße festlegen===
Hier wird die gewünschte Größe der Partition festgelegt. Wenn man den gesamten bzw. restlichen verfügbaren Platz verwenden will, lässt man diese Angaben einfach weg,...
[[Bild:Ide service setup main loaded-hdd-selected-add-part-setup-size.jpg|thumb|none|300px|Partitionsgröße]]
...ansonsten kann man einen entsprechenden Wert eingeben.
[[Bild:Ide service setup main loaded-hdd-selected-add-part-setup-size-input.jpg|thumb|none|300px|Partitionsgröße eingeben]]

===Partition erstellen und formatieren===
Sind alle Angaben komplett, muss nur noch der letzte Menüpunkt ausgeführt werden.
[[Bild:Ide service setup main loaded-hdd-selected-add-part-setup-make-part.jpg|thumb|none|300px|erstellen und formatieren]]
Letzte Warnung:
[[Bild:Ide service setup main loaded-hdd-selected-add-part-setup-make-part-warning.jpg|thumb|none|300px|Warnung]]
Warten und dann sollte das irgendwann fertig sein.
[[Bild:Ide service setup main loaded-hdd-selected-add-part-setup-make-part-creating-ready.jpg|thumb|none|300px|fertig]]
Wenn alles ohne Fehlermeldungen durchgelaufen ist, gelangst du zurück ins Hauptmenü.
[[Bild:Ide service setup main loaded-hdd-selected-add-part-setup-make-part-creating-ready-select.jpg|thumb|none|300px|fertig]]

Willst du noch weitere Partitionen anlegen, kannst du das an dieser Stelle so lange genug Speicher da ist, ohne weiteres tun.

===Kontrolle und Übernehmen===
Um die frisch angelegte Partition jetzt dem System zur Verfügung zu stellen, muss zum Abschluß alles noch übernommen werden. Solltest du das Menü verlassen oder ein Timeout das Menü schließen wollen, wirst du automatisch darauf hingewiesen, die vorgenommenen Einstellungen und geändertet Partitionsdaten zu übernehmen.
Zur Kontrolle, kannst du vorher noch einen Blick in die aktuelle Partitionierung werfen.
Hier werden die im System vorhandenen Partitionen der gewählten Platte mit Informationen über Mountpoint, das verwendete Dateisystem, Mountoptionen, noch freien Speicherplatz in Megabyte und einer geschätzten freien Stundenzahl angezeigt.
Man kann auch jetzt noch die Partition auswählen, um noch Details einzusehen oder auch diese Partition für [[#NFS-Freigabe_einrichten|NFS]] oder [[#Samba-Freigabe_einrichten|Sambaserver freigeben]], zu prüfen, ein- oder aushängen oder sogar löschen.
[[Bild:Ide service setup main loaded-hdd-selected-add-part-setup-make-part-creating-ready-selected.jpg|thumb|none|300px|Partitionsliste]]
Zum Übernehmen der aktuellen Partitionen und Mounteinstellungen, gehe zurück ins Hauptmenü und wähle dann '''Übernehmen'''
[[Bild:Ide service setup applied.jpg|thumb|none|300px|Die erzeugte(n) Partition(en) steht/stehen dem System nun zur Verfügung]]
Das Ergebnis wird kurz angezeigt und die Partition steht ab sofort auch beim nächsten Bootvorgang zur Verfügung.

==Swap anlegen==
Hierfür steht der Menüpunkt '''Swap-Partition anlegen''' zur Verfügung
[[Bild:Ide service setup main loaded-hdd-selected-add-swap.jpg|thumb|none|300px|Partitionsliste]]
Hiermit werden alle nötigen Schritte und Vorgänge durchgeführt, die zum Einrichten einer Swap-Partition notwendig sind.
Es spielt auch keine Rolle, ob bereits eine normale Partition existiert. Solange genug Platz vorhanden ist, wird auch hierfür die nächste verfügbare Partitionsnummer verwendet und die weitere Vorgehensweise ist mit dem Erstellen normaler Partitionen identisch.
 
<div style="padding:0.5em; margin-bottom:1em; border: 2px solid #a00;">[[Bild:Stop hand.png]] '''HINWEIS:'''
''Es kann nur eine einzige Swap-Partition angelegt werden und die Größe ist auf 128MB vorgegeben. Optional kann auch 64MB gewählt werden und sollte weniger Speicherplatz verfügbar sein, kann der verfügbare Platz verwendet werden''</div>
[[Bild:Ide service setup main loaded-hdd-selected-add-swap applied.jpg|thumb|none|300px|Partitionsliste]]

=Vorbereitetes Laufwerk einrichten=
Recht komfortabel lassen sich auch bereits fertig partitionierte und formatierte Laufwerke einrichten. Im Optimalfall ist es auch nicht notwendig das Dateisystem zu kennen.

Es wird im Folgenden davon ausgegangen, dass noch keine Laufwerke installiert waren, also gerade so, als ob noch ein jungfräuliches [[Images|Image]] vorliegt und auch die [[#drivesetup.conf|drive_setup.conf]] noch nicht existiert.
Für den Fall, dass du schon eingerichtete Laufwerke drin hattest, solltest du sicherstellen, dass das [[Hardware:dbox2:IDE-Interface|IDE-Interface]] und [[SD-Karte|MMC]] deaktiviert ist. Zu empfehlen ist eine eine [[#Zur.C3.BCcksetzen|Rücksetzung]]. In diesem Fall kann man auch die [[#drivesetup.conf|drive_setup.conf]] bei Bedarf vorher sichern. Bleibt die alte [[#drivesetup.conf|drive_setup.conf]] bestehen, ist das auch kein Problem, da sich einige Einstellungen teilweise selbst erneuern, aber eben nicht alle und einige Meldungen, die für den Benutzer wichtig wären, könnten ausbleiben.

<div style="padding:0.5em; margin-bottom:1em; border: 2px solid #a00;">[[Bild:Stop hand.png]] '''HINWEIS:'''
''Es werden nur für das jeweilige Image verfügbare Dateisysteme unterstützt. Welche das sind, wird bei der Auswahl des Filesystems angezeigt. Andere gehen nicht! Um weitere Dateisysteme nutzen zu können, kann man die benötigten Module nachinstallieren (siehe [[Neutrino:Service:IDE-MMC-HDD-Setup#Module|Module]])''

''Erkannt werden nur Primäre Partitionen auf der Basis von Partitionstabellen die typisch für die allgemeine Verwendung unter Linux sind. Erweiterte Partitionen bzw. Partitionstabellen anderen Typs können nicht verwendet werden.''</div>

==Laufwerke aktivieren==
Man baut nun z.B. eine Festplatte ein und bootet die Box. Man öffnet nun das Menü und es werden nur die wichtigsten Einträge angezeigt, weil bisher noch kein Treiber oder Filesystem geladen sein sollte:
[[Bild:Ide_service_setup_main_off.jpg|thumb|none|300px|Hauptmenü: alles deaktiviert]]
Um das IDE-Interface oder mmc zu aktivieren wird die gewünschte Option ausgewählt:
[[Bild:Ide_service_setup_main_set-ide.jpg|thumb|none|300px|Hauptmenü: Interface einschalten]]

Drücke dann '''Übernehmen'''.
Es werden nun alle notwendigen Treiber und Einstellungen geladen. Werden während dieses Vorganges schon Partitionen gefunden, die ein unterstütztes Dateisystem enthalten, werden diese automatisch übernommen und in Standardordner eingehangen, welche man im Anschluß natürlich nach seinen eigenen Bedürfnissen ändern kann.

Es können auch einige Meldungen ausgegeben werden, die anzeigen, auf welchem Laufwerk und für welche Partition vom Benutzer noch kein Dateisystem oder Mountpoints angegeben wurden.
'''Das ist noch kein Problem!''' Diese Meldungen sollen dem Benutzer nur zeigen, was noch fehlt. Es sind also nur gut gemeinte Hinweise darauf, dass man für dieses und jenes Laufwerk noch keine brauchbaren Angaben vorliegen und diese während der folgenden Schritte nachholen muss.
<div style="padding:0.5em; margin-bottom:1em; border: 2px solid #a00;">[[Bild:Stop hand.png]] '''HINWEIS:'''
''Für den Fall, dass mehrere Partitionen gefunden werden, werden automatisch Ordner erzeugt, in welche diese Partitionen eingehangen werden. In der Regel können aber nur Ordner in beschreibbaren jffs-Bereichen angelegt werden. Zur Sicherheit werden diese Ordner allerdings ohne Schreibrechte angelegt, so dass das Risiko einer Beschädigung minimiert ist! Die darin eingehangenen Partitionen sind aber beschreibbar.''</div>

==Laufwerk wählen==
''Die folgenden Schritte sind nur notwendig, wenn noch nicht alle Laufwerke automatisch erkannt und einghangen wurden oder man nachträglich noch Änderungen nach eigenen Wünschen wie z.B. an den Mountpunkten oder diverse Parameter vornehmen möchte.''

Im Hauptmenü werden nun die erkannten Laufwerke angezeigt.
[[Bild:Ide service setup main loaded-hdd-selected-present-hdd.jpg|thumb|none|300px|Hauptmenü: Erkannte Laufwerke]]

Wähle dann ein Laufwerk aus, um ins Laufwerksmenü zu gelangen. Hier werden nun die auf dem Laufwerk vorhandenen Partitionen angezeigt. Wähle dir dann eine aus, um wiederum diese Partition zu bearbeiten.
[[Bild:Ide service setup main loaded-hdd-selected-present-hdd-parts.jpg|thumb|none|300px|Hauptmenü: Erkannte Partitionen]]

==Partitionen einrichten==
Im Partitionsmenü gibst du dann bei Bedarf einen anderen Mountpoint an.
[[Bild:Ide service setup main loaded-hdd-selected-present-hdd-parts-edit.jpg|thumb|none|300px|Bearbeite Partition]]
Jetzt noch die Partition einhängen:
[[Bild:Ide service setup main loaded-hdd-selected-add-part-setup-make-part-creating-ready-selected-singlemount.jpg|thumb|none|300px|Bearbeite Partition]]
Solltest du versuchen, ein anderes Dateisystem angeben zu wollen, als das was auf der Partition zur Verfügung steht, wird dies in der Regel beim Übernehmen
der Einstellungen automatisch korrigiert bzw. mit einer Fehlermeldung quittiert. Ebenso kann dies bei einem ungültigen Mountverzeichnis der Fall sein. Das muss dann korrigiert werden.

Solange die Partition aktiviert, also eingehangen ist, sind die Einträge für Dateisystem, Einhängepunkt deaktiviert. Um dort Änderungen vornehmen zu können, muss die Partition erst ausgehangen werden.
 
<div style="padding:0.5em; margin-bottom:1em; border: 2px solid #a00;">[[Bild:Stop hand.png]] '''HINWEIS:'''
''Um ein anderes Dateisystem zu verwenden, muss dieses natürlich vorhanden sein oder zuerst erzeugt werden. Verwende hierfür den Menüpunkt '''[[#Formatieren|Formatieren]] '''. Danach sollte auch das Einhängen wie gewohnt funktionieren. Bei ext2/3 formatierten Laufwerken kann es unter Umständen möglich sein, beide Versionen verwenden zu können, was allerdings nicht zwingend der Fall sein muss, da beim Formatieren gewisse Optionen gesetzt worden sein könnten, die nur die Verwendung einer Version zulassen.
'''''Beim Formatieren werden bekanntermaßen, alle Daten der Partition, unbrauchbar!'''''''</div>

Wenn du fertig bist, gehe zurück ins Hauptmenü, um mit '''Übernehmen''' den Vorgang abzuschließen. Das Laufwerk steht dann zur Verfügung und wird auch beim nächsten Booten entsprechend aktiviert bzw. eingehangen.

=Aufgaben=
Das Menü stellt einige Möglichkeiten zur Bearbeitung und Wartung von einzelnen Partitionen zur Verfügung.
 
<div style="padding:0.5em; margin-bottom:1em; border: 2px solid #a00;">[[Bild:Stop hand.png]] '''HINWEIS:'''
''Beim Prüfen, Löschen und Formatieren von Partitionen wird systembedingt immer die betreffende Partition vorher automatisch ausgehangen. Für diesen Fall bitte auch beachten, dass evtl. laufende Prozesse auf der jeweiligen Partition beendet werden. Siehe auch [[#Customizing|Customizing!]]''</div>
[[Bild:Ide_service_setup_main_loaded-hdd-selected-add-part-setup-jobs.jpg|thumb|none|300px|Partitionen bearbeite: Aufgaben]]

==Formatieren==
Mit dieser Funktion kann man das unter dem Menüpunkt '''''Dateisystem''''' angegebene Dateisystem anlegen. Die Partitionsgröße wird nicht geändert. Siehe auch [[#Formatierungsoptionen|Formatierungsoptionen]]!

==Aushängen/Einhängen==
Wie die Bezeichnung schon sagt, wird damit die jeweilige Partition ein- oder ausgehangen. Die Bezeichnung des Menüeintrags ändert sich dabei je nach dem, ob die Partition bereits eingehangen ist oder nicht. Im übergeordnetem Laufwerksmenü ist das Gegenstück zu finden. Dort lauten die Menüeinträge
*'''Alle einhängen'''
*'''Alle aushängen'''
Hiermit kann man entsprechend '''alle''' Partitionen des gewählten Laufwerks in einem Arbeitsgang ein- oder aushängen.
 
<div style="padding:0.5em; margin-bottom:1em; border: 2px solid #a00;">[[Bild:Stop hand.png]] '''HINWEIS:'''
''Wenn im Partitionsmenü der Menüeintrag '''Partition aktivieren''' auf '''nein''' gestellt ist, hat dies keine Auswirkung auf das manuelle Einhängen. Diese Option greift nur beim '''Übernehmen''' der Einstellungen.''</div>

==Löschen==
Alle Daten auf der Partition gehen verloren. Der freie Speicher kann anschließend wieder genutzt werden. In der Regel ist nach der Löschung kein Neustart erforderlich. Sollte dies trotzdem erforderlich sein, wird man darauf hingewiesen.
[[Bild:Ide setup reboot.png|thumb|none|300px|Hinweis, falls Neustart erforderlich]]

==Prüfen==
Mit dieser Funktion wird das Prüfwerkzeug für das zugehörige Dateisystem gestartet. Je nach Zustand und Größe der Partition, kann dies unter Umständen auch recht lange dauern.
 
<div style="padding:0.5em; margin-bottom:1em; border: 2px solid #a00;">[[Bild:Stop hand.png]]
'''HINWEIS:''''' Es ist nicht erforderlich, zusätzlich eine Prüfung direkt nach der Erzeugung einer Partition durchzuführen, da die Prüfung immer automatisch nach ihrer Erzeugung erfolgt jedoch schadet es nicht, hin und wieder vorallem nach häufigen Bootvorgängen und den damit verbundenen Einhängevorgängen eine Prüfung durchzuführen! Genauere Auskunft, ob eine Prüfung erforderlich ist, gibt ein [[Bootlog]]''</div>

=Serverfreigaben einrichten=
Im Partitionsmenü lassen sich in Abhängikeit von der im Image unterstützten Serverfunktion NFS und/oder [[Samba]](Windows)-Freigaben festlegen.
[[Bild:Ide service setup shares.jpg|thumb|none|300px|Partitionsmenü: Serverfreigaben einrichten]]
[[Bild:Ide main disc partition share.png|thumb|none|300px|Partitionsuntermenü: Serverfreigaben einrichten]]

==NFS-Freigabe einrichten==
Sofern das [[Images|Image]] für die [[NFS]]-Serverfunktionalität ausgelegt ist, lassen sich auch ganz einfach Partitionen für [[NFS]] freigeben.

Es kann praktisch für jede einzelne Partition, eine NFS-Freigabe eingerichtet werden.
Hierfür stellt man im jeweiligen Partitionsmenü die Option "'''Für NFS-Server freigeben'''" auf '''Ja'''. Danach kann man im darunterliegenden Menüeintrag, die Client-IP eingeben.
Durch '''[[#Übernehmen|Übernehmen]]''' wird die [[#.2Fetc.2Fexports|exports]]-Datei entsprechend modifiziert und die eingestellten NFS-Freigaben stehen '''nach dem nächsten Bootvorgang''' der Receivers zur Verfügung.

Der Server läuft standardmäßig mit diesen Optionen:
*'''rw,sync,no_subtree_check'''

 
<div style="padding:0.5em; margin-bottom:1em; border: 2px solid #a00;">[[Bild:Stop hand.png]] '''HINWEIS:'''
''Sollte man eine Partition aushängen wollen, die gerade von einem Clienten oder anderen Prozessen verwendet wird, schlägt dies fehl. Die Partition muss also erst wieder "befreit" werden!'' Siehe auch: [[#Customizing|Customizing]]</div>

===NFS-Client einrichten===
Hier als Beispiel, wie der [[NFS-Client]] unter OpenSuse 11.1 über [[YaST]] eingestellt werden kann, um auf den Server zugreifen zu können.
Man öffnet die entsprechende Anwendung für [[NFS-Client]] im [[YaST]]-Kontrollzentrum und kann dann die gewünschte Freigabe, die nun vom Receiver bereitgestellt wird hinzufügen:
[[Bild:Ide setup nfs yast client settings.jpg|thumb|none|400px|NFS-Client einrichten]]
Die hier angebenenen Einstellungen sind nur Beispiele, jedoch sollte man die Optionen in etwa so vornehemen.
*'''ro,soft,udp'''
oder
*'''rw,soft,udp'''
sollte gleichermaßen funktionieren, jedoch hat man auch nur dann Schreibrechte, wenn man als Root vom Clienten auf die Daten zugreift.
Wenn keine Fehler auftauchen, sollte alles dann so übernommen werden.
[[Bild:Ide setup nfs yast client.jpg|thumb|none|400px|NFS-Client einrichten]]

==[[Samba]]-Freigabe einrichten==
Bei Bedarf kann hier ein eigener Freigabename über einen Eingabedialog vergeben werden und noch die Angaben für '''Nur lesen''' und '''Öffentlich''' geändert werden.
===Globale Sambaeinstellungen===
{{sambaserver}}

=Auslagern=
Hier soll kurz auf das Thema '''Auslagern''' von Programmdateien eingegangen werden. Das Prinzip ist in der Regel auch auf alle anderen Programme, Dateien oder Verzeichnisse übertragbar, die man aus Platzmangel nicht immer im Flash unterbringen kann.
==Beispiel: Sambaserver==
{{Samba}}

=Customizing=
{{Mount unmount scripts}}

=Weblinks=
*[http://www.dbox2-tuning.net/forum/viewtopic.php?f=7&t=49067 Diskussion zum aktuellen IDE-Menü im Tuxbox-Forum]
*[http://www.dbox2-tuning.net/forum/viewtopic.php?p=373385#p373385 Ur-Thread zum Entwurf im Tuxbox-Forum]

Tuxbox-Neutrino

2012-06-04T17:13:41Z

Dixidix: Typo fix

[[Category:Register]]
[[Category:NeutrinoHD]]
{{NeutrinoHD_sidebar}}
[[Bild:NeutrinoHD.png|400px]]

'''Neutrino-HD''' ist eine freie unter [[GPL]] stehende aus dem [[DBox2 Software Projekt|Tuxbox]]-Projekt hervorgegangene und auf das für die [[dBox2]] entwickelte [[Neutrino]] basierende [[GUI|Benutzeroberfläche]]. '''Neutrino-HD''' wurde für den Betrieb von [[Receiver]]n der neueren Generation mit [[HDTV]]-Unterstützung portiert und wird speziell dafür weiterentwickelt.
Als erster Receiverhersteller verwendet Coolstream-Tech '''Neutrino-HD''' serienmäßig auf seinen [[HDTV]]-Geräten und zwar bei den Modellen
*[[Hardware:Coolstream:HD1|HD1]]
*[[Hardware:Coolstream:NEO|NEO]]
*[[Hardware:Coolstream:NEO²_Twin|NEO²]]
*[[Hardware:Coolstream:ZEE|Zee]]
Andere Hersteller verwenden ebenfalls auf '''Neutrino-HD''' basierende Systeme auf ihren Geräten. Ein bekanntes Beispiel ist aktuell [http://www.azbox.com/ Azbox], der es unter dem Namen '''[http://www.myazbox.de/wiki//index.php/AZtrino AZtrino]''' verwendet.
Entgegen der Darstellung, das es sich um 1:1 Versionen handelt (siehe [http://www.myazbox.de/wiki//index.php/Hauptseite#Die_AZBox_Me Azbox-Wiki]), sei an dieser Stelle ausdrücklich darauf hingewiesen, dass dies aus technischen Gründen und dem unterschiedlichem Entwicklungsstand nicht den Tatsachen entsprechen kann. Demzufolge sind die hier beschriebenen Funktionsmerkmale, sofern dies nicht ausdrücklich angemerkt ist, nur teilweise oder nicht auf Geräte anderer Hersteller anwendbar.
Dies trifft ebenfalls auf '''Neutrino-HD''' basierende, aber [[lizenzwidrig]] verbreitete [[Fremdsoftware]] zu.

__TOC__

=Bedienung=

==Einschalten==

==Umschalten (zappen)==

{{Vorlage:NeutrinoHD_EPGVorschau}}

{{Vorlage:NeutrinoHD_Tonoptionen}}

{{Vorlage:NeutrinoHD_Bildoptionen}}

{{Vorlage:NeutrinoHD_Erweiterungen}}

==Kanalliste==

[[Bild:NeutrinoHD Kanalliste.png|Kanalliste|none|thumb|500px]]

=Menüs=
Beschreibungen zur Menüstruktur und den einzelnen Optionen finden Sie unter [[NeutrinoHD:Hauptmenü|NeutrinoHD Hauptmenü]].

=Aufzeichnen=
{{Vorlage:NeutrinoHD_Aufnahme}}

=Optionen=

{{body}}

Tuxbox-Neutrino

2012-01-16T08:28:34Z

Dixidix: Formulierung angepasst

[[Category:Register]]
[[Category:NeutrinoHD]]
{{NeutrinoHD_sidebar}}
[[Bild:NeutrinoHD.png|400px]]

'''Neutrino-HD''' ist eine freie unter [[GPL]] stehende aus dem [[DBox2 Software Projekt|Tuxbox]]-Projekt hervorgegangene und auf das für die [[dBox2]] entwickelte [[Neutrino]] basierende [[GUI]], die für den Betrieb von [[Receiver]]n der neueren Generation mit [[HDTV]]-Unterstützung portiert wurde und speziell dafür weiterentwickelt wird.
Als erster Receiverhersteller verwendet Coolstream-Tech '''Neutrino-HD''' serienmäßig auf seinen [[HDTV]]-Geräten und zwar bei den Modellen
*[[Hardware:Coolstream:HD1|HD1]]
*[[Hardware:Coolstream:NEO|NEO]]
*[[Hardware:Coolstream:ZEE|Zee]]
Andere Hersteller verwenden ebenfalls auf '''Neutrino-HD''' basierende Systeme auf ihren Geräten. Ein bekanntes Beispiel ist aktuell [http://www.azbox.com/ Azbox], der es unter dem Namen '''[http://www.myazbox.de/wiki//index.php/AZtrino AZtrino]''' verwendet.
Entgegen der Darstellung, das es sich um 1:1 Versionen handelt (siehe [http://www.myazbox.de/wiki//index.php/Hauptseite#Die_AZBox_Me Azbox-Wiki]), sei an dieser Stelle ausdrücklich darauf hingewiesen, dass dies aus technischen Gründen und dem unterschiedlichem Entwicklungsstand nicht den Tatsachen entsprechen kann. Demzufolge sind die hier beschriebenen Funktionsmerkmale, sofern dies nicht ausdrücklich angemerkt ist, nur teilweise oder nicht auf Geräte anderer Hersteller anwendbar.
Dies trifft ebenfalls auf '''Neutrino-HD''' basierende, aber [[GNU Public License (GPL)|lizenz]]wiedrig verbreitete Fremdsoftware zu.

__TOC__

=Bedienung=

==Einschalten==

==Umschalten (zappen)==

{{Vorlage:NeutrinoHD_EPGVorschau}}

{{Vorlage:NeutrinoHD_Tonoptionen}}

{{Vorlage:NeutrinoHD_Bildoptionen}}

{{Vorlage:NeutrinoHD_Erweiterungen}}

==Kanalliste==

[[Bild:NeutrinoHD Kanalliste.png|Kanalliste|none|thumb|500px]]

=Menüs=
Beschreibungen zur Menüstruktur und den einzelnen Optionen finden Sie unter [[NeutrinoHD:Hauptmenü|NeutrinoHD Hauptmenü]].

=Aufzeichnen=
{{Vorlage:NeutrinoHD_Aufnahme}}

=Optionen=

{{body}}

Tuxbox-Neutrino

2012-01-11T16:46:32Z

Dixidix: typo

[[Category:Register]]
[[Category:NeutrinoHD]]
{{NeutrinoHD_sidebar}}
[[Bild:NeutrinoHD.png|400px]]

'''Neutrino-HD''' ist eine freie unter [[GPL]] stehende aus dem [[DBox2 Software Projekt|Tuxbox]]-Projekt hervorgegangene und auf das für die [[dBox2]] entwickelte [[Neutrino]] basierende [[GUI]], die für den Betrieb von [[Receiver]]n der neueren Generation mit [[HDTV]]-Unterstützung portiert wurde und speziell dafür weiterentwickelt wird.
Als erster Receiverhersteller verwendet Coolstream-Tech '''Neutrino-HD''' serienmäßig auf seinen [[HDTV]]-Geräten und zwar bei den Modellen
*[[Hardware:Coolstream:HD1|HD1]]
*[[Hardware:Coolstream:NEO|NEO]]
*[[Hardware:Coolstream:ZEE|Zee]]
Andere Hersteller verwenden ebenfalls auf '''Neutrino-HD''' basierende Systeme auf ihren Geräten. Ein bekanntes Beispiel ist aktuell [http://www.azbox.com/ Azbox], der es unter dem Namen '''[http://www.myazbox.de/wiki//index.php/AZtrino AZtrino]''' verwendet.
Entgegen der Darstellung, das es sich um 1:1 Versionen handelt (siehe [http://www.myazbox.de/wiki//index.php/Hauptseite#Die_AZBox_Me Azbox-Wiki]), sei an dieser Stelle ausdrücklich darauf hingewiesen, dass dies aus technischen Gründen und dem unterschiedlichem Entwicklungsstand nicht den Tatsachen entsprechen kann. Demzufolge sind die hier beschriebenen Funktionsmerkmale, sofern dies nicht ausdrücklich angemerkt ist, nur teilweise oder nicht auf Geräte anderer Hersteller anwendbar.
Dies trifft prinzipiell auch auf [[GNU Public License (GPL)|lizenz]]wiedrig verbreitete auf '''Neutrino-HD''' basierende Fremdsoftware zu.

__TOC__

=Bedienung=

==Einschalten==

==Umschalten (zappen)==

{{Vorlage:NeutrinoHD_EPGVorschau}}

{{Vorlage:NeutrinoHD_Tonoptionen}}

{{Vorlage:NeutrinoHD_Bildoptionen}}

{{Vorlage:NeutrinoHD_Erweiterungen}}

==Kanalliste==

[[Bild:NeutrinoHD Kanalliste.png|Kanalliste|none|thumb|500px]]

=Menüs=
Beschreibungen zur Menüstruktur und den einzelnen Optionen finden Sie unter [[NeutrinoHD:Hauptmenü|NeutrinoHD Hauptmenü]].

=Aufzeichnen=
{{Vorlage:NeutrinoHD_Aufnahme}}

=Optionen=

{{body}}

Tuxbox-Neutrino

2012-01-11T16:36:48Z

Dixidix: ergänzt

[[Category:Register]]
[[Category:NeutrinoHD]]
{{NeutrinoHD_sidebar}}
[[Bild:NeutrinoHD.png|400px]]

'''Neutrino-HD''' ist eine freie unter [[GPL]] stehende aus dem [[DBox2 Software Projekt|Tuxbox]]-Projekt hervorgegangene und auf das für die [[dBox2]] entwickelte [[Neutrino]] basierende [[GUI]], die für den Betrieb von [[Receiver]]n der neueren Generation mit [[HDTV]]-Unterstützung portiert wurde und speziell dafür weiterentwickelt wird.
Als erster Receiverhersteller verwendet Coolstream-Tech '''Neutrino-HD''' serienmäßig auf seinen [[HDTV]]-Geräten und zwar bei den Modellen
*[[Hardware:Coolstream:HD1|HD1]]
*[[Hardware:Coolstream:NEO|NEO]]
*[[Hardware:Coolstream:ZEE|Zee]]
Andere Hersteller verwenden ebenfalls auf '''Neutrino-HD''' basierende Systeme auf ihren Geräten. Ein bekanntes Beispiel ist aktuell [http://www.azbox.com/ Azbox], der es unter dem Namen '''[http://www.myazbox.de/wiki//index.php/AZtrino AZtrino]''' verwendet.
Entgegen der Darstellung, das es sich um 1:1 Versionen handelt (siehe [http://www.myazbox.de/wiki//index.php/Hauptseite#Die_AZBox_Me Azbox-Wiki]), sei an dieser Stelle ausdrücklich darauf hingewiesen, dass dies aus technischen Gründen und dem unterschiedlichem Entwicklungsstand nicht den Tatsachen entsprechen kann. Demzufolge sind die hier beschriebenen Funktionsmerkmale, sofern dies nicht ausdrücklich angemerkt ist, nur teilweise oder nicht auf Geräte anderer Hersteller anwendbar.
Dies trifft prinzipiell auch für [[GNU Public License (GPL)|lizenz]]wiedrig verbreitete auf '''Neutrino-HD''' basierende Fremdsoftware zu.

__TOC__

=Bedienung=

==Einschalten==

==Umschalten (zappen)==

{{Vorlage:NeutrinoHD_EPGVorschau}}

{{Vorlage:NeutrinoHD_Tonoptionen}}

{{Vorlage:NeutrinoHD_Bildoptionen}}

{{Vorlage:NeutrinoHD_Erweiterungen}}

==Kanalliste==

[[Bild:NeutrinoHD Kanalliste.png|Kanalliste|none|thumb|500px]]

=Menüs=
Beschreibungen zur Menüstruktur und den einzelnen Optionen finden Sie unter [[NeutrinoHD:Hauptmenü|NeutrinoHD Hauptmenü]].

=Aufzeichnen=
{{Vorlage:NeutrinoHD_Aufnahme}}

=Optionen=

{{body}}

Tuxbox-Neutrino

2012-01-11T15:28:36Z

Dixidix: Hinweise zu Beschränkungen mit Fremdsoftware eingefügt

[[Category:Register]]
[[Category:NeutrinoHD]]
{{NeutrinoHD_sidebar}}
[[Bild:NeutrinoHD.png|400px]]

'''Neutrino-HD''' ist eine aus dem [[DBox2 Software Projekt|Tuxbox]]-Projekt hervorgegangene auf [[Neutrino]] basierende [[GUI]], die für den Betrieb von [[Receiver]]n der neueren Generation mit [[HDTV]]-Unterstützung portiert wurde und speziell dafür weiterentwickelt wird. Als erster Receiverhersteller verwendet Coolstream-Tech '''Neutrino-HD''' serienmäßig auf seinen [[HDTV]]-Geräten und zwar bei den Modellen
*[[Hardware:Coolstream:HD1|HD1]]
*[[Hardware:Coolstream:NEO|NEO]]
*[[Hardware:Coolstream:ZEE|Zee]]
Andere Hersteller verwenden ebenfalls auf '''Neutrino-HD''' basierende Systeme auf ihren Geräten. Ein bekanntes Beispiel ist aktuell [http://www.azbox.com/ Azbox], der es unter dem Namen '''[http://www.myazbox.de/wiki//index.php/AZtrino AZtrino]''' verwendet.
Entgegen der Darstellung, das es sich um 1:1 Versionen handelt (siehe [http://www.myazbox.de/wiki//index.php/Hauptseite#Die_AZBox_Me Azbox-Wiki]), sei an dieser Stelle ausdrücklich darauf hingewiesen, dass dies aus technischen Gründen und dem unterschiedlichem Entwicklungsstand nicht den Tatsachen entsprechen kann. Demzufolge sind die hier beschriebenen Funktionsmerkmale, sofern dies nicht ausdrücklich angemerkt ist, nur teilweise oder nicht auf Geräte anderer Hersteller anwendbar.

__TOC__

=Bedienung=

==Einschalten==

==Umschalten (zappen)==

{{Vorlage:NeutrinoHD_EPGVorschau}}

{{Vorlage:NeutrinoHD_Tonoptionen}}

{{Vorlage:NeutrinoHD_Bildoptionen}}

{{Vorlage:NeutrinoHD_Erweiterungen}}

==Kanalliste==

[[Bild:NeutrinoHD Kanalliste.png|Kanalliste|none|thumb|500px]]

=Menüs=
Beschreibungen zur Menüstruktur und den einzelnen Optionen finden Sie unter [[NeutrinoHD:Hauptmenü|NeutrinoHD Hauptmenü]].

=Aufzeichnen=
{{Vorlage:NeutrinoHD_Aufnahme}}

=Optionen=

{{body}}

Images:Yadi

2011-09-06T17:47:52Z

Dixidix: Berlios verlinkt

[[Category:Register]]
[[Category:Images]]
[[Bild:yadi.png|right|200px| ]]
__TOC__

=Allgemeines=
Yadi galt als Nachfolger der bis dahin verbreiteten AlexW-Images und versuchte nach deren Wegfall den Prozess der Imageerstellung basierend auf dem GNU [[Hardware:dbox2|DBox2]] Software Projekt, durch diverse Scripte und Patches zu vereinfachen bzw. zu automatisieren. Zusätzlich wurden fertige [[Images]] im [[SquashFS]] und [[JFFS2]] Format verteilt.

=Links=
*[http://dboxjffs2.sourceforge.net/ Yadi Homepage]
*[http://dboxjffs2.sourceforge.net/faq.php Yadi FAQ]
*[http://forum.tuxbox.org/forum/viewforum.php?f=28 Support im Tuxbox-Forum]
*[http://developer.berlios.de/projects/yadi/ BerliOs Projektseite]

{{body}}

Tuxbox-Projekt

2011-01-13T18:55:49Z

Dixidix: redirect angelegt

#REDIRECT [[DBox2 Software Projekt‎]]

Tuxbox-Neutrino

2011-01-13T18:50:06Z

Dixidix: aktualisiert

[[Category:Register]]
[[Category:NeutrinoHD]]
{{NeutrinoHD_sidebar}}
[[Bild:NeutrinoHD.png|400px]]

'''Neutrino-HD''' ist eine aus dem [[Tuxbox]]-Projekt hervorgegangene auf [[Neutrino]] basierende [[GUI]], die für den Betrieb von [[Receiver]]n der neueren Generation mit [[HDTV]]-Unterstützung portiert wurde und speziell dafür weiterentwickelt wird. Derzeit findet '''Neutrino-HD''' serienmäßig Verwendung auf [[HDTV]]-Receivern von [[Coolstream]] bei den Modellen [[HD1]], [[NEO]] und [[Zee]].

__TOC__

=Bedienung=

==Einschalten==

==Umschalten (zappen)==

{{Vorlage:NeutrinoHD_EPGVorschau}}

{{Vorlage:NeutrinoHD_Tonoptionen}}

{{Vorlage:NeutrinoHD_Bildoptionen}}

{{Vorlage:NeutrinoHD_Erweiterungen}}

==Kanalliste==

[[Bild:NeutrinoHD Kanalliste.png|Kanalliste|none|thumb|500px]]

=Menüs=
Beschreibungen zur Menüstruktur und den einzelnen Optionen finden Sie unter [[NeutrinoHD:Hauptmenü|NeutrinoHD Hauptmenü]].

=Optionen=

{{body}}

GNU-Tuxbox Projekt

2011-01-13T18:44:55Z

Dixidix: aktualisiert

[[Category:Register]]
__TOC__

=Allgemeines=
Das Projekt hatte ursprünglich das Ziel, auf der [[DBox2]] ein alternatives [[Betriebssystem]] bzw. eine entsprechende Software basierend auf [[Linux]] und offenen Standards bereitzustellen. Dazu wurden u.a. bereits vorhandene [[DVB]]-Umsetzungen wie z.B. der Firma Convergence ([[Linux]] [[DVB]] [[API]]) verwendet und auf die [[Hardware]] der [[DBox2]] portiert.
[[Bild:Dbox2_logo.jpg|175px|right]]
Die [[DBox2]] ist eine Settop-Box für den Empfang von digitalen TV- und Radio-Programmen im [[DVB]]-Format. Die [[DBox2]] ist sowohl für Kabel-, als auch Satellitenempfang erhältlich und wurde hauptsächlich von Premiere (jetzt: Sky) vertrieben, ist jedoch auch von Mediavision oder als einfacher Digital-Receiver bei verschiedenen Händlern erhältlich gewesen.

Hersteller der [[DBox2]] waren [[Nokia]], [[Philips]] und [[Sagem]].

Inzwischen wurde die Tuxbox-Software auch für andere Set-Top-Boxen portiert und es dürften noch weitere folgen. Die Entwicklung dürfte also noch einiges bereithalten. Ein besonderes Augenmerk besteht deshalb auf die Unterstützung für HDTV-fähige Geräte.

Die Entwicklung der Tuxbox-Software erfolgt als [[Open-Source]] unter der [[GNU Public License (GPL)]]. Obwohl das Projekt ursprünglich keinerlei finanzielle Interessen verfolgte und für die Entwickler nach wie vor ein Hobby darstellt, findet die Software inzwischen auch bei diversen Geräteherstellern in Form von Ablegern, sog. [[Forks]], Verwendung an dem auch einige der Tuxbox-Entwickler beteilgt sind. Bekanntes Beispiel ist [[Neutrino-HD]], welches ähnlich wie [[Enigma]] inzwischen von einigen Geräteherstellern serienmäßig in ihren Geräten Verwendung findet.

=Weblinks=
*[http://www.tuxbox.org Tuxbox Homepage]
*[http://forum.tuxbox.org Tuxbox Forum]
*[http://cvs.tuxbox.org/ Tuxbox CVS]

{{body}}

Esound

2010-11-03T19:18:27Z

Dixidix: Verweis hinzugefügt

Der '''Enlightened Sound Daemon''', kurz '''EsounD''' oder '''esd''', ist ein Sound[[server]], der normalerweise von den [[WP:Fenstermanager|Fenstermanager]]n [[WP:Enlightenment|Enlightenment]] und [[WP:GNOME|Gnome]] verwendet wird.

Zweck eines Soundservers ist es, dafür zu sorgen, dass mehrere [[Anwendungsprogramm|Anwendungen]] gleichzeitig Audiosignale ausgeben können. Dazu greifen die Anwendungen selbst nicht mehr direkt auf das Audiogerät beziehungsweise deren Treiber zu, sondern senden stattdessen den wiederzugebenden Audiostrom an den Soundserver. Dieser mischt die Ströme und spielt das Ergebnis dann über das Audiogerät ab.

EsounD verfügt auch über einfache [[WP:Sequenzer (Musik)|Sequenzer]]fähigkeiten; so können [[WP:Computersample|Samples]] geladen und später wiedergegeben werden, auf der Dbox2 ist diese Funktion aus Platzgründen nicht implementiert. Weiterhin ist EsounD [[WP:Netzwerktransparenz|netzwerktransparent]] - ein Programm muss also nicht auf demselben [[WP:Host (Informationstechnik)|Host]] wie der Soundserver laufen, um Audioströme an diesen zu senden.

Siehe auch: [[Neutrino:Esound_Soundserver|Esound-Server auf der dbox2 (ESD)]]

== Weblinks ==
* [http://www.tux.org/~ricdude/EsounD.html EsounD Website] (englisch)
* [ftp://ftp.gnome.org/pub/GNOME/sources/esound/0.2/ FTP-Server mit neuen Releases]

LGPL

2010-08-18T07:24:41Z

Dixidix: Redirekt auf GNU Lesser General Public License angelegt

#REDIRECT [[GNU Lesser General Public License]]

GNU Lesser General Public License

2010-08-18T07:23:35Z

Dixidix:

[[Category:Register]]
{{Infos}}

*[[Wikipedia:LGPL]]
* [http://www.gnu.org/licenses/lgpl.html GNU Lesser General Public License 3] (englisch)
* [http://www.gnu.de/lgpl-ger.html inoffizielle deutsche Übersetzung der LGPL]

{{body}}

Loki Software

2010-08-18T07:16:36Z

Dixidix:

[[Category:Register]]
{{Infos}}

*[[Wikipedia:Loki Software]]

{{body}}

Hardware:Dreambox:DM7020

2010-08-18T07:12:41Z

Dixidix: Registereinträge hinzugefügt

[[Category:Register]]
[[Category:Hardware]]
[[Category:Hardware:Dreambox]]

__TOC__

Die '''DM7020''' ist eine Modell-Variante der [[Dreambox]], einem Digital Satelliten-Empfangsreceiver für TV- und Radioprogramme.

== Weblinks ==

* [http://www.dream-multimedia-tv.de/ Webseite des Herstellers]

Hardware:Dreambox:DM7025

2010-08-18T07:11:55Z

Dixidix: Registereinträge hinzugefügt

[[Category:Register]]
[[Category:Hardware]]
[[Category:Hardware:Dreambox]]

__TOC__

Die '''DM7025''' ist eine Modell-Variante der [[Dreambox]], einem Digital Satelliten-Empfangsreceiver für TV- und Radioprogramme.

== Weblinks ==

* [http://www.dream-multimedia-tv.de/ Webseite des Herstellers]

Hardware:Dreambox:DM500

2010-08-18T07:11:00Z

Dixidix: Registereinträge eingefügt

[[Category:Register]]
[[Category:Hardware]]
[[Category:Hardware:Dreambox]]

__TOC__

Die '''DM500''' ist eine Modell-Variante der [[Dreambox]], einem Digital Satelliten-Empfangsreceiver für TV- und Radioprogramme.

== Weblinks ==

* [http://www.dream-multimedia-tv.de/ Webseite des Herstellers]

Development:NeutrinoHD auf der Triple Dragon (veraltet)

2010-08-16T03:14:44Z

Dixidix: Kategorien hinzugefügt

[[Category:Register]]
[[Category:Development]]
[[Category:CDK]]
[[Category:NeutrinoHD]]
[[Category:Hardware:TripleDragon]]

=Build-Umgebung=

==Auschecken==
Zuerst sollte man ein Verzeichnis erstellen, in dem der spätere Quell-Code und die fertigen Binarys abgelegt werden:
mkdir ~/neutrino-hd-td
cd ~/neutrino-hd-td

Anschließend checkt man das Build-System für die Triple Dragon aus
git clone git://gitorious.org/tripledragon-buildscripts/mainline.git
cd mainline

==Konfiguration vorbereiten==
Anschließend öffnet man die Datei config mit einem Editor und nimmt folgenden Eintrag vor:
FLAVOUR=neutrino-hd

==Build-System erstellen==
Nun gibt man folgende Befehle ein:
make preqs
make crosstool
make bootstrap

=NeutrinoHD=
==Compilieren==
Mit folgenden Kommandos baut man dann Neutrino
make neutrino-hd
make neutrino-hd-system

==System von Festplatte starten==
===Festplatte vorbereiten===
Nachdem alles durchgelaufen ist, liegt im Verzeichnis in dem man gebaut hat, unter ./root das fertige System. Um das nun auf der TripleDragon zum laufen zu bekommen, sollte man die Festplatte in 2 Partitionen aufteilen:

* Partition 1: Für Timeshift und Co.
* Partition 2: Das System

Nachdem man die Partitionen formatiert hat (z.B. mit ext3), kopiert man den Inhalt aus dem root-Verzeichnis auf die Partition 2

===Bootloader vorbereiten===
Anschließend muss man noch dem Bootloader der TripleDragon mitteilen, das man von der Festplatte booten möchte. Da man diesen nur über die serielle Schnittstelle erreichen kann, braucht man ein entsprechendes Kabel.
Nachdem man das soweit in Betrieb genommen hat, startet man eine entsprechende Terminal-Software. Die Einstellungen können i.d.R. so belassen werden, wie sie sind - nur die Baud-Rate sollte auf 115.200 gestellt werden.
Um nun in den Bootloader zu gelangen, muss man während die Box unter Strom gesetzt wird, die Pfeil-nach-Links Taste und die Enter-Taste gleichzeitig gedrückt werden.
Wenn man das richtig macht, sieht man in etwa folgendes:
_______________________________
/ (C) MNC Ltd. Set-Top-Box \
\ BIOS 3.29 (2005/11/07) /
-------------------------------
\ .--. Serialnumber: Tripledragon-EU-0-172xxxxxx-S
|o_o | PowerPC at : 252 MHz, EBIU: 63 MHz, PVR: 41810952, VDEV: 0B
|:_/ | RAM config : B0: 2x32=64 MB, B1: 2x8=16 MB, [80 MB]
// \ \ Flash memory: Size: 8 MB, Manufacturer: 04, Type: 22D7
(| | ) Tunertype : DVB-S, Sat-Tuner BS2F7VZ0184
/'\_ _/`\ Ethernet : Chip 33, Revis. 91 (SMC91C11x)
\___)=(___/ Network : not initialised yet
Ethernet MAC: BADDxxxxxxxx, TD IP: 192.168.1.123, Host IP: 192.168.1.1
F-System: 0xFF9C0000, 0x47B000 (4698112 Byte), VAR: 1769472 Byte / 27 sect
Kernel : 0xFFE40000, 0x197A00 (1669632 Byte / 26 sect), autostart

Main Bios-Menu
0 - Boot
R - Reset
S - Save config

B - Boot/Kernel Setup
E - Upgrade/Flash/Network
H - Hardware Setup
L - Loader Config
V - Video/Modulator Setup
->
Hier drückt man erst B und anschließend K. Dann sollte man folgendes vor sich haben:
_______________________________
/ (C) MNC Ltd. Set-Top-Box \
\ BIOS 3.29 (2005/11/07) /
-------------------------------
\ .--. Serialnumber: Tripledragon-EU-0-172xxxxxx-S
|o_o | PowerPC at : 252 MHz, EBIU: 63 MHz, PVR: 41810952, VDEV: 0B
|:_/ | RAM config : B0: 2x32=64 MB, B1: 2x8=16 MB, [80 MB]
// \ \ Flash memory: Size: 8 MB, Manufacturer: 04, Type: 22D7
(| | ) Tunertype : DVB-S, Sat-Tuner BS2F7VZ0184
/'\_ _/`\ Ethernet : Chip 33, Revis. 91 (SMC91C11x)
\___)=(___/ Network : not initialised yet
Ethernet MAC: BADDxxxxxxxx, TD IP: 192.168.1.123, Host IP: 192.168.1.1
F-System: 0xFF9C0000, 0x47B000 (4698112 Byte), VAR: 1769472 Byte / 27 sect
Kernel : 0xFFE40000, 0x197A00 (1669632 Byte / 26 sect), autostart

Kernel Commandline Setup
0 - Boot
R - Reset
S - Save config

1 - CMDline 1: console=ttyS1,115200 ip=off root=/dev/mtdblock2

2 - CMDline 2: console=ttyS1,115200 ip=192.168.1.123:192.168.1.1:192.168.1.1:255.255.255.0:dvt3000 root=/dev/nfs rw nfsroot=192.168.1.1:/tftpboot/dvt3000,hard,intr

3 - CMDline 3: console=ttyS1,115200 root=/dev/ide/host0/bus0/target0/lun0/part2 rw

4 - CMDline 4: console=ttyS1,115200 root=/dev/ide/host0/bus0/target0/lun0/part3 rw

a-d select comandline 1-4
Y - toggle CMDline to use: [use CMDline 3]
->
Hier drückt man dann solange Y, bis unten
Y - toggle CMDline to use: [use CMDline 2]
steht. Das bedeutet, dass der Bootloader sein System auf der Partition 2 der Platte sucht.

Jetzt sollte die Platte soweit sein, dass diese das System startet.

=Nützliche Quellen für weitere Informationen und bei Problemen=
* http://www.dbox2-tuning.net/forum/viewtopic.php?f=62&t=49203
* http://www.dbox2-tuning.net/forum/viewtopic.php?f=62&t=49199

Bootlog

2010-07-15T13:45:47Z

Dixidix:

[[Category:Register]]

Das [[Bootlog]] (= serielles Log) wird benötigt, um z.B. Ausgaben über den Startvorgang oder allgemeine Ausgaben während des Betriebes der [[DBox2]]-Software analysieren zu können.

__TOC__

=Vorraussetzungen=
Um das [[Bootlog]] zu bekommen, benötigt man Folgendes:

* in der GUI muss die Logausgabe auf seriell gestellt sein siehe z.B: [[Neutrino:Einstellungen:Treiber-_%26_Bootoptionen#EXPERT.21_Boot-Konsole|Neutrino-Einstellungen]]
[[Bild:seriell.jpg|thumb|none|300px|Beispiel: Neutrino Einstellung muss auf seriell stehen!]]
* Terminal-Programm (z.B. Hyperterminal) oder [[DBox2]]-[[Bootmanager]], [[Putty]] oder [[Minicom]] unter Linux
* angeschlossenes [[Nullmodem|Null-Modemkabel]]

alternativ, wenn kein Nullmodemkabel verwendet wird:
* mit ''[[setconsole]]'' (über [[BusyBox]] aktiviert)

'''Hinweis'''
''[[Setconsole]] ist nicht in jedem [[Image]] enthalten.''

Wenn Ihr nicht wisst, was ein [[Nullmodem|Null-Modemkabel]] oder Terminal-Programm ist, solltet Ihr besser nicht versuchen eine [[DBox2]] mit [[Linux]] zu [[flashen]]. Wer trotzdem unerschrocken und lernwillig ist, möge [http://www.google.de Google] für weitere Informationen bemühen. Für die Nutzung des [[DBox2]]-[[Bootmanager]]s lest bitte die entsprechende Anleitung, welche im Readme des Bootmanagers zu finden sein sollte!

=mit Bootmanager oder Terminalprogramm=
==Einstellungen==
* [[Nullmodem]]kabel mit [[DBox2]] und [[PC]] (Com1 od. Com2) verbinden

* Schnittstelle am [[PC]] entsprechend konfigurieren. Stellt die benutzte [[COM]]-Schnittstelle auf 9600 Baud, 8bit, no parity

* [[DBox2]] starten und gucken, ob eine Ausgabe im Terminalprogramm erfolgt. Wenn nein (oder nur unleserliche Zeichen), Schnittstelle auf 57600 Baud, 8 bit, no parity konfigurieren und [[DBox2]] wieder neu booten.

Im Terminal-Programm sollten eine lange Liste der von der [[DBox2]] durchgeführten Aktionen stehen. Dies ist das Bootlog...

==Beispiel==
(extrem gekürzt):

debug: DDF: Calibrating delay loop... debug: DDF: 67.79 BogoMIPS
debug: BMon V1.2 mID 01
debug: feID dd gtxID 0b
debug: fpID 5a dsID 01-8b[....]
debug: HWrev 09 FPrev 0.81
debug: B/Ex/Fl(MB) 32/00/08
WATCHDOG reset enabled
dbox2:root> debug:
BOOTP/TFTP bootstrap loader (v0.3)
debug:
debug: Transmitting BOOTP request via broadcast
debug: Given up BOOTP/TFTP boot
boot net failed

Flash-FS bootstrap loader (v1.5)

[...]

Initializing...
CPU: PPC823ZTnnB2 at 67 MHz: 2 kB I-Cache 1 kB D-Cache
Board: ### No HW ID - assuming TQM8xxL
DRAM: (faked) 32 MB
Ethernet: .....
FLASH: 8 MB
LCD driver (KS0713) initialized
LCD logo at: 0x84A7E (0x1E00 bytes)
FB logo at: 0x868A6 (0x31C1 bytes)
AVIA Frambuffer
Input: serial
Output: serial

[...]

events are old 60min after their end time
[sectionsd ] checking timerd
[sectionsd ] timerd available
dmxdev: set buffer size 40000 -> 60000
$Id: zapit.cpp,v 1.163 2002/04/24 18:51:18 field Exp $

/var/tuxbox/config/zapit/zapit.conf: No such file or directory
[getservices.cpp] /var/tuxbox/config/zapit/services.xml: No such file or directory
[zapit] /var/tuxbox/config/zapit/bouquets.xml: No such file or directory
[zapit] channels have been loaded succesfully
Controld $Id: controld.cpp,v 1.57 2002/03/29 15:47:18 obi Exp $

[controld] Boxtype detected: (01, 1, 1, Nokia)
set event: 00000009
SWITCH LETTER BOX
[nhttpd] [[Neutrino]] HTTP-Server starting..

httpd gestartet
dmxdev: set buffer size 40000 -> 60000
NeutrinoNG $Id: neutrino.cpp,v 1.243 2002/04/24 13:06:58 field Exp $

[neutrino] frameBuffer Instance created
[...]

=Hinweis=
Bricht das [[Bootlog]] nach

Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 576993 Bytes = 563 kB = 0 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK

ab, dann startet die [[DBox2]] nochmal und drückt die "2" (auf der [[Fernbedienung]]) an dieser Stelle:

Options:
1: Console on null
2: Console on ttyS0
3: Console on framebuffer
Select (1-3), other keys to stop autoboot: 0

=Bootlog über Netzwerk=
Es besteht die Möglichkeit, über den Befehl ''[[setconsole]]'', ein Log über [[Telnet]] über das [[Netzwerk]] aufzuzeichnen. Vorraussetzung dafür ist, dass Dbox-Taste -> Einstellungen -> Treiber- und Bootoptionen -> Expert! Bootconsole auf seriell steht. Die Ausgaben über das Netzwerk sind unter Umständen nicht so ausführlich wie ein serielles Bootlog. Man sollte daher immer ein Bootlog über die serielle Schnittstelle vorziehen. Das erleichtert in der Regel immer die Suche nach Fehlern.

=Kernel-Log ausgeben=
Mit dem Befehl "dmesg" (alternativ mit "cat /proc/kmsg") kann man sich mittels [[Telnet]] den [[Kernel]]-Log ausgeben lassen. Auch hier sollte immer ein Bootlog über die serielle Schnittstelle vorgezogen werden. Die dmesg-Ausgaben sind bei weitem nicht so üppig wie es über die serielle Schnittstelle möglich wäre.

=unter Linux=
Ein Bootlog unter Linux kann man relativ einfach mit diesem Befehl erstellen:
sudo cat -u /dev/ttyS0

{{body}}

Dbox2:Bootlogo austauschen

2010-04-20T14:15:53Z

Dixidix: Neutrino Grafics Creator hinzugefügt

[[Category:Register]]
[[Category:Neutrino]]
[[Category:Howto]]
{{Howto_sidebar}}
__TOC__

=Allgemeines=
'''Es gibt 2 Arten von Bootlogos.'''

*Das Bootlogo, welches auf dem [[Framebuffer]] (TV) dargestellt wird
*Das Bootlogo, welches auf dem [[LCD]] dargestellt wird

Diese Dateien liegen im Ordner '''/var/tuxbox/boot''' und können mit einem [[FTP]]-Client getauscht werden

*logo-fb für das Logo auf dem [[Framebuffer]] (TV)
*logo-lcd für das Logo auf dem [[LCD]] 
*lcd.ani für animierte Logos auf dem [[LCD]] 

''Hinweis: Die animierten Logos sind nicht in jedem Image lauffähig, da hierfür ein spezielles Programm benötigt wird. Standardmäßig lassen sich diese Logos bisher nur mit den NovaTux-Images nutzen.''

Alle diese Dateien haben ein bestimmtes Format und eine bestimmte Auflösung. 
Das Logo für den [[Framebuffer]] ist ein Ein-Frame MPEG1 Video in der Größe 720 x 576 Pixel 
Das Logo für das [[LCD]] ist ein [[RAW]] File mit der Größe 120 x 64 Pixel (2 Farben) 
Animierte Logos für das [[LCD]] haben ein spezielles Format die ebenfalls mit der Größe 120 x 64 Pixel (2 Farben) arbeiten 

Am einfachsten kann man die -lcd und -lb Files mit dem [[Logo_Viewer|'''TuxBox Logo Viewer''']] erstellen. 
Der [[Logo_Viewer|TuxBox Logo Viewer]] kann diese Dateien auch direkt auf der [[DBox2]] ersetzen.
Die -ani Files lassen sich nur mit einem bestimmten Programm (bmp2ani) und aus einer Folge von 1bit-Bitmaps erzeugen. Es gibt aber auch einige fertige -ani's zum herunterladen.
Die ani-Files können bisher nur über ein FTP-Programm eingespielt werden.

Um Radio-, Scan- und Shutdownbilder herzustellen, bedarf es eines gewissen Aufwands, da es sich hier um ganz spezielle raw-Formate in Verbindung mit Paletten-Dateien (*.pal) handelt. Um es auszutauschen, kann man diese Bilder in den Benutzerdefinierten Bereich des [[Images]] installieren.
Das Shutdown-Logo lässt sich unter Umständen auch mit dem [[Logo_Viewer|'''TuxBox Logo Viewer''']] herstellen, da dieses Programm eine Extrafunktion ("RAW Viewer") bereit hält, mit der es in gewissen Grenzen möglich ist, solche Bilder zu erzeugen. In diesem Fall kommt es auf einen Versuch an.

Ein gelungenes Tool gibts von Loostech. Den '''Neutrino Grafics Creator'''. Dies ist praktisch der Nachfolger des [[Logo_Viewer|TuxBox Logo Viewer's]]. Damit lassen sich fast alle Bilder herstellen.

=Links=
*siehe auch [[Neutrino:Customizing#eigene_LCD-Vorlagen|Ändern des LCD_Hintergrunds]]

*[http://lostech.bplaced.net/download.php#1016 Download: Neutrino Grafics Creator]
*[http://www.chatlogin.com/dbox2/chkdesign/htdocs/start.php Bootlogo Sammlung]
*[http://www.dbox2.info Logo Viewer Download]
*[http://www.dbox2-tuning.net/dlc/index.php?name=CmodsDownload&file=index&req=viewdownload&cid=10&orderby=dateD Weitere Bootlogo-Sammlung]

{{body}}

Μcodes

2010-03-02T07:17:38Z

Dixidix: Weiterleitung nach UCodes erstellt

#REDIRECT [[UCodes]]

Microcode

2010-03-02T06:40:16Z

Dixidix: Weiterleitung nach UCodes erstellt

#REDIRECT [[UCodes]]

Microcode

2010-03-02T06:37:48Z

Dixidix: Weiterleitung nach Ucodes erstellt

#REDIRECT [[Ucodes]]

GNU-Tuxbox Projekt

2009-11-23T08:13:35Z

Dixidix: Text aktualisiert

[[Category:Register]]
__TOC__

=Allgemeines=
Das Projekt hatte ursprünglich das Ziel, auf der [[DBox2]] ein alternatives [[Betriebssystem]] bzw. eine entsprechende Software basierend auf [[Linux]] und offenen Standards bereitzustellen. Dazu wurden u.a. bereits vorhandene [[DVB]]-Umsetzungen wie z.B. der Firma Convergence ([[Linux]] [[DVB]] [[API]]) verwendet und auf die [[Hardware]] der [[DBox2]] portiert.
[[Bild:Dbox2_logo.jpg|175px|right]]
Die [[DBox2]] ist eine Settop-Box für den Empfang von digitalen TV- und Radio-Programmen im [[DVB]]-Format. Die [[DBox2]] ist sowohl für Kabel-, als auch Satellitenempfang erhältlich.

Hersteller der [[DBox2]] waren [[Nokia]], [[Philips]] und [[Sagem]].

Inzwischen wurde die Tuxbox-Software auch für andere Set-Top-Boxen portiert und es dürften noch weitere folgen. Die Entwicklung dürfte also noch einiges bereithalten. Ein besonderes Augenmerk besteht deshalb auf die Unterstützung für HDTV-fähige Geräte.

Das Projekt verfolgt keinerlei finanzielle Interessen und stellt für die Entwickler nur ein Hobby dar. Die Entwicklung der Tuxbox-Software erfolgt als [[Open-Source]] unter der [[GNU Public License (GPL)]].

Die [[DBox2]] wurde hauptsächlich von Premiere vertrieben, ist jedoch auch von Mediavision oder als einfacher Digital-Receiver bei verschiedenen Händlern erhältlich.

=Links=
*[http://www.tuxbox.org Tuxbox Homepage]
*[http://forum.tuxbox.org Tuxbox Forum]
*[http://cvs.tuxbox.org/ Tuxbox CVS]

{{body}}

Datei:Kanalsuche kabel.png

2009-10-21T15:30:09Z

Dixidix: hat eine neue Version von „Bild:Kanalsuche kabel.png“ hochgeladen

Neutrino:Customizing

2009-08-28T15:50:19Z

Dixidix:

Hardware:dbox2

2009-06-26T06:57:11Z

Dixidix: Kategorie angelegt

[[Category:Register]]
[[Category:Hardware]]
[[Category:dbox2]]
__TOC__

=Allgemeines=
Die [[DBox2]] wurde als Nachfolger der [[DBox1]] hauptsächlich durch Premiere vertrieben.
Ursprünglich wie die [[DBox1]] wurde auch diese durch [[Nokia]] gefertigt. Premiere hat die [[DBox2]] jedoch später auch von [[Sagem]] und [[Philips]] für sich bauen lassen. Die [[DBox2]] ist als digitaler Satelliten- und Kabelreceiver ([[Hardware#DVB-S_.28Satellit.29|DVB-S]] und [[Hardware#DVB-C_.28Cable.2FKabel.29|DVB-C]]) verfügbar.

Die ständige Weiterentwicklung der Produktionstechniken und der Leistungsfähigkeit bestimmter Chips hat auch vor der [[DBox2]] nicht halt gemacht. Das hatte zur Folge, dass sich die [[DBox2]] eines Herstellers nicht direkt mit der eines anderen Herstellers vergleichen lässt.
So fertigte [[Nokia]] die [[DBox2]] hautsächlich in der Kombination [[Hardware#AViA500|AViA500]]/[[Hardware#GTX|GTX]] und später noch mit [[Hardware#AViA600|AViA600]]/[[Hardware#GTX|GTX]], während [[Philips]] und [[Sagem]] ausschließlich die Kombination [[Hardware#AViA600|AViA600]]/[[Hardware#eNX|eNX]] verbauten. [[Sagem]] stattete außerdem viele seiner Boxen mit einem [[Hardware#Flash_Chips|Flashbaustein]] aus, während [[Nokia]] und [[Philips]] immer zwei [[Hardware#Flash_Chips|Flashbausteine]] einsetzten. Ein weiterer nicht weniger relevanter Unterschied liegt z.B. im verwendeten [[Hardware#Tuner_.28Frontend.29|Tuner]] bzw. [[Hardware#Tuner_.28Frontend.29|Frontend]].

Die [[DBox2]] wird bereits seit einiger Zeit nicht mehr hergestellt, die u.a. von Premiere weiterhin angebotenen Geräte sind so genannte "refurbished" Boxen. Das sind generalüberholte Boxen mit einem Jahr Garantie.

Nähere Informationen zu den einzelnen Boxen der genannten Hersteller sind [[DBox2|hier]] zu finden.
'''Siehe auch [[Erweiterungen]]'''.

=Varianten=
Die [[DBox2]] gibt es von drei verschiedenen Herstellern: [[Nokia]], [[Philips]] und [[Sagem]]. Je nachdem welcher Hersteller die Box gefertigt hat, werden unterschiedliche [[Hardware#Flash_Chips|Flash]]bausteine verwendet. Gefertigt werden diese entweder von Intel oder AMD.

==DBox2 von Nokia==
[[Bild:Dbox2_nokia_340.png]]

Die [[DBox2]] von Nokia gibt es sowohl mit Intel als auch mit AMD [[Hardware#Flash_Chips|Flash]]bausteinen. Es wurden immer zwei verbaut. Als [[Hardware#MPEG-2_Audio.2FVideo_Decoder_Chip|MPEG-Dekoder]] ist entweder ein [[Hardware#AViA500|AViA500]] oder ein [[Hardware#AViA600|AViA600]] in der Box, als Demux ein [[Hardware#GTX|GTX]]. Es gibt zwei verschiedene [[Fernbedienung#Nokia|Fernbedienungen]] von Nokia.

==DBox2 von Philips==
[[Bild:Dbox2_philips.jpg]]

Die Philips - [[DBox2]] gibt es nur als [http://de.wikipedia.org/wiki/Satellitenreceiver Sat] Version und auch nur mit 2 Intel-Bausteinen und der Dekoder/Demux-Kombination [[Hardware#AViA600|AViA600]]/[[Hardware#eNX|eNX]].

Ein "berühmtes" Problem der Philips ist der sogenannte "Fernbedienungsbug" der sich dadurch bemerkbar macht, dass unter anderem beim schnellen Umschalten mit den Hoch-Runter-Tasten der [[Fernbedienung#Nokia|Fernbedienung]] auf einmal Zahlen erkannt werden.

==DBox2 von Sagem==
[[Bild:Dbox2_sagem.jpg]]

Für die [[DBox2]] von Sagem gibt es wie auch bei Nokiageräten sowohl Geräte mit Intel als auch mit AMD [[Hardware#Flash_Chips|Flash]]bausteinen. Die Sagem [[DBox2]] ist das einzige Modell bei dem es Boxen mit nur einem 8MB Intel [[Hardware#Flash_Chips|Flash]]baustein gibt.

== Flashidentifikation ==

Um herauszufinden, welche Flashanzahl die eigene Box hat, hilft im Normalfall entweder aufschrauben und nachsehen, oder, wenn bereits Linux auf der Box installiert ist, folgendes:

===Konsole===

* per telnet zur Box verbinden
* Ausführen von :
sed -n -e '/^mtd0/p' /proc/mtd | sed -e 's/$.*$ $.*$ $.*$ $.*$ $.*$/\3/'
*Es wird ausgegeben:

00020000 = 1 Flashbausteine
oder
00004000 = 2 Flashbausteine

===Neutrino GUI===
Bei aktuellen Images ab CVS-Stand Mai 2007 im Servicemenü:

'''Imageinformationen > Unterstützung'''

[[Bild:Imageinfo_support.jpg|none|thumb|300px]]

===Flashen mit Expertenfunktionen===
Möchte man mit den Expertenfunktionen ein Image flashen, wird ein entsprechender Hinweis daraufhin gegeben, welcher Imagetyp benötigt wird. Dies betrifft die Funktionen:
*flashimage
*flash(without bootloader)

=Fernbedienung=
Es gibt drei verschiedene Fernbedienungen für die [[DBox2]]. Alle drei haben die gleichen Funktionen und unterscheiden sich nur in der Anordnung der Tasten.

==Nokia==
<table cellpadding="0" cellspacing="0" border="0">
<tr>
<td align="center">alte Fernbedienung</td>
<td align="center">neue Fernbedienung</td>
</tr>
<tr>
<td align="center">[[Bild:FB_Nokia02.jpg]]</td>
<td align="center">[[Bild:FB_Nokia01.jpg]]</td>
</tr>
</table>
Die alte Fernbedienung wird nur von Nokia-Boxen erkannt, die neue kann auch an [[DBox2#DBox2_von_Sagem|Sagem]] und [[DBox2#DBox2_von_Philips|Philips]] benutzt werden. Umgekehrt können Nokias mit allen 3 Fernbedienungen gesteuert werden.

In aktuellen [[Image]]s kann man einstellen, daß die [[DBox2]] nur noch auf die alte bzw. neue Fernbedienung reagiert. Dazu legt man im Verzeichnis /var/etc eine Datei namens '''''.'''oldrc'' bzw. '''''.'''newrc'' an.

==Sagem und Philips==
[[Bild:FB_Sagem_Philips.jpg]]

'''''Hinweis:''''' Für die [[DBox2#DBox2_von_Philips|Philips]] Fernbedienung gibt es eine [[Umbau_Philips_Fernbedienung|Umbauanleitung]] um die Funktionstüchtigkeit zu erhöhen.

=Anschlüsse=
Die [[DBox2]] verfügt über diverse Anschlussmöglichkeiten. Hier kann z.B. ein Fernsehgerät, eine Stereoanlage, ein Videorekorder, ein Telefonanschluss oder ein [[Netzwerk]] angeschlossen werden.

==DBox2 (Sat)==
{|
|1x|| 230 V Input
|-
|1x|| Stereo RCA (Cinch) Output
|-
|2x|| [[Scart]] (1x TV, 1x VCR)
|-
|1x|| [[LIRC|VCR Steuerung]] (via Infrarot / "Sichtkontakt" zwischen [[DBox2]] und VCR muss bestehen)
|-
|1x|| [[Digital Audio]] (Optisch, IEC-958)
|-
|1x|| [[RS 232]] (Serieller Anschluss)
|-
|1x|| Telefon (RJ11)
|-
|1x|| [[Ethernet]] (RJ45 - 10MBit/Halb-Duplex)
|-
|1x|| [[LNB]] (400 mA)
|-
|1x|| Analog Receiver Anschluss (um das Signal bei ausgeschalteter [[DBox2]] an einen Analog-Receiver "durchzuschleifen")
|}

[[Bild:Dbox rueckansicht.jpg]]

==DBox2 (Kabel)==
{|
|1x|| 230 V Input
|-
|1x|| Stereo RCA (Cinch) Output
|-
|2x|| [[Scart]] (1x TV, 1x VCR)
|-
|1x|| [[LIRC|VCR Steuerung]] (via Infrarot / "Sichtkontakt" zwischen [[DBox2]] und VCR muss bestehen)
|-
|1x|| [[Digital Audio]] (Optisch, IEC-958)
|-
|1x|| [[RS 232]] (Serieller Anschluss)
|-
|1x|| Telefon (RJ11)
|-
|1x|| [[Ethernet]] (RJ45 - 10MBit/Halb-Duplex)
|-
|1x|| Antenne (Koaxialbuchse für den Kabelanschluss)
|-
|1x|| TV / VCR (Koaxialstecker um das Eingangssignal an weitere Geräte "durchzuschleifen")
|}

[[Bild:dbox-rueckansicht-kabel.jpg]]

=Innenleben=
==Hauptprozessor (CPU)==
Als [[CPU]] (Central Processing Unit) der [[DBox2]] kommt ein ursprünglich von Motorola entwickelter MPC823 zum Einsatz. Es handelt sich dabei um einen mit 66MHz. getakteten 32Bit [[Prozessor]] mit [[PowerPC]]-Kern (PowerPC wird gerne auch durch "[[PPC]]" abgekürzt) und integrierter Kommunikations-Peripherie. Das heißt, dass diverse Interfaces wie z.B. ein [[USB]]-Kanal und ein [[I2C]]-Port bereits im [[Prozessor]] integriert sind. Die Netzwerkschnittstelle der [[DBox2]] ist mit Ausnahme des Tranceiver-Chips z.B. ebenfalls innerhalb der [[CPU]] realisiert. Aufgrund des Designs der [[DBox2]] ist der [[USB]]-Kanal leider nicht verwendbar, da u.a. bestimmte Anschlussleitungen bereits für andere Dinge genutzt werden.

[[Bild:MPC823_neu.png]]

Die [[CPU]] ist bei der [[DBox2]] in einem BGA-Gehäuse (Ball Grid Array) auf dem [[Mainboard]] aufgelötet. Dabei werden die einzelnen Anschlusskontakte eines BGA-Gehäuses (kleine Lötmittelperlen) beim Auflöten mittels einer speziellen Heißluftlötstation kurz aufgeschmolzen und bilden dadurch den Kontakt zu den Anschlüssen des [[Mainboard]]s. Der Wechsel einer [[CPU]] ist daher aufwendig und kann nur durch teures Equipment und dem entsprechenden Know How durchgeführt werden.

Technische Daten können hier eingesehen werden:
*[http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC823&nodeId=018rH3bTdG8657 MPC823]

==RAM Chips==
Hauptspeicher ([[RAM]]) wird immer und grundsätzlich zur Ausführung von Programmcode benötigt. Bei der [[DBox2]] kommen insgesamt 32MB [[RAM]] zum Einsatz. Es handelt sich dabei um SDRAM, der entweder komplett auf dem [[Mainboard]] aufgelötet ist oder bei älteren [[Nokia]]-Boxen auch je zur Hälfte onboard und als Modul auf der [[Hardware#Speichererweiterung|Speichererweiterung]] sitzt.

[[Bild:150px-RAM-16MB.png|thumb|none|150px|16MB SDRAM-Chip]]

==Flash Chips==
Die Flashbausteine dienen der dauerhaften Speicherung der Betriebssoftware. Mit Ausnahme von einigen frühen und Entwickler-Boxen hat jede [[DBox2]] 8MB Flashspeicher. Der Zugriff auf den Flashspeicher erfolgt immer mit 32Bit Breite.

Der '''AMD 29DL323CB''' ist in [[Nokia]] und [[Sagem]] verbaut (paarweise, 2x16Bit Datenbus).
{| valign=bottom
|[[Bild:150px-AMD_29DL323CB.jpg|thumb|none|150px|AMD 29DL323CB]]
|}

Der '''Intel TE28F320C3B''' ist in den Boxen aller 3 Hersteller zu finden (paarweise, 2x16Bit Datenbus).
{| valign=bottom
|[[Bild:150px-Intel_TE28F320.jpg|thumb|none|150px|Intel TE28F320C3B]]
|}

Den '''Intel E28F640J3A''' gibt es ausschließlich in der [[Sagem]] 1xIntel. Da dieser Chip 8MB hat (daher "solo" verwendet wird) und wie die anderen Flashs nur einen 16Bit Datenbus, wird der Bus mit einem [[GAL]] (kleiner Chip unterhalb des Flashs) gemultiplext, also 2 16Bit Worte hintereinander ausgegeben.
{| valign=bottom
|[[Bild:150px-Inteltsop56.jpg|thumb|none|150px|Intel E28F640J3A]]
|}

Weitere Flashversionen (nur 4MB, Flashs von ST-Micro) sind nur in Entwicklerboxen aufgetaucht, in "freier Wildbahn" haben diese keine Bedeutung.

==Tuner (Frontend)==
Der Tuner eines jeden Empfängers dient zum Empfang der vom Sender ausgestrahlten Trägerfrequenz, auf der die eigentlichen Nutzdaten durch ein entsprechendes Modulationsverfahren (z.B. AM=Amplitudenmodulation oder FM=Frequenzmodulation) "aufmoduliert" wurden.

Der Tuner empfängt den Träger entweder durch Vorwahl einer Frequenz (z.B. durch den Benutzer) oder durch ein geeignetes Verfahren zur automatischen Erkennung von entsprechenden Trägerfrequenzen. Nachdem der Tuner auf eine Trägerfrequenz "getuned" hat, greift der PLL (Phase Locked Loop/Geschlossener Phasenregelkreis) des Tuners und sorgt dafür, dass der Tuner auf der Trägerfrequenz stabil getuned (abgestimmt) bleibt. Im Weiteren greifen dann noch zusätzliche Mechanismen zur Optimierung der Empfangsqualität durch Einsatz einer automatischen Signal-Verstärker/-Begrenzer-Schaltung (AGC=Automatic Gain Control).

Durch den Demodulator wird nun das Nutzsignal bzw. die Nutzdaten in verschiedenen Schritten aus dem Trägersignal gefiltert. Dabei kommen natürlich auch diverse Verfahren zur Rauschunterdrückung zum Einsatz.

Das gesamte Gebilde aus Tuner/PLL/AGC/Demodulator/ZF und weiteren Schaltungen wird in der Regel auch als "Frontend" bezeichnet. Heute wird dies üblicherweise durch hochintegrierte Schaltkreise zusammen mit dem eigentlichen Tuner als komplettes Produkt durch die Hersteller vertrieben.

===DVB-S (Satellit)===
{|style="background-color:white; font-size:small; margin:3px 3px 3px 10px"
|style="background-color:#8DB6CD; width: 100px;" |  ''' ''' 
|style="background-color:#8DB6CD; width: 250px;" |  '''Nokia''' 
|style="background-color:#8DB6CD; width: 250px;" |  '''Sagem''' 
|style="background-color:#8DB6CD; width: 250px;" |  '''Philips''' 
|-

|style="background-color:#B9D3EE" |  Demodulator 
|style="background-color:#B9D3EE" |  VLSI VES1893 oder VLSI VES1993 
|style="background-color:#B9D3EE" |  VLSI VES1993 
|style="background-color:#B9D3EE" |  [[Philips]] TDA8044 
|-

|style="background-color:#B9D3EE" |  PLL 
|style="background-color:#B9D3EE" |  Zarlink SP5668 oder [[Philips]] TSA5059 
|style="background-color:#B9D3EE" |  [[Philips]] TSA5059 
|style="background-color:#B9D3EE" |  [[Philips]] TSA5059 
|}

Bei [[DVB-S]] wird die so genannte "[[QPSK|Quadrature Phase Shift Keying]]" (QPSK) Modulation verwendet.

===DVB-C (Cable/Kabel)===
{|style="background-color:white; font-size:small; margin:3px 3px 3px 10px"
|style="background-color:#8DB6CD; width: 100px;" |  ''' ''' 
|style="background-color:#8DB6CD; width: 250px;" |  '''Nokia''' 
|style="background-color:#8DB6CD; width: 250px;" |  '''Sagem''' 
|style="background-color:#8DB6CD; width: 250px;" |  '''Philips''' 
|-
|style="background-color:#B9D3EE" |  Demodulator 
|style="background-color:#B9D3EE" |  VLSI VES1820 
|style="background-color:#B9D3EE" |  Atmel AT76C651 
|style="background-color:#B9D3EE" |  ST STV0297 
|-
|style="background-color:#B9D3EE" |  PLL 
|style="background-color:#B9D3EE" |  Zarlink SP5659 
|style="background-color:#B9D3EE" |  Infineon TUA6010XS 
|style="background-color:#B9D3EE" |  [[Philips]] TSA5512 
|}

Bei [[DVB-C]] hingegen verwendet man die "[[QAM|Quadrature Amplitude Modulation]]" (QAM) (hängt im Detail vom Kabelnetzbetreiber ab!).

===DVB-T (Terrestrisch)===
{|style="background-color:white; font-size:small; margin:3px 3px 3px 10px"
|style="background-color:#8DB6CD; width: 100px;" |  ''' ''' 
|style="background-color:#8DB6CD; width: 250px;" |  '''Nokia''' 
|style="background-color:#8DB6CD; width: 250px;" |  '''Sagem''' 
|style="background-color:#8DB6CD; width: 250px;" |  '''Philips''' 
|-
|style="background-color:#B9D3EE" |  Demodulator 
|style="background-color:#B9D3EE" |  Infineon SQC6100 
|style="background-color:#B9D3EE" |  - 
|style="background-color:#B9D3EE" |  - 
|-
|style="background-color:#B9D3EE" |  PLL 
|style="background-color:#B9D3EE" |  Zarlink SP5668 
|style="background-color:#B9D3EE" |  - 
|style="background-color:#B9D3EE" |  - 
|}

Für [[DVB-T]] wurden die Modulationsverfahren [[QPSK]], 16-[[QAM]] und 64-[[QAM]] definiert.

Bei der [[DVB-T]] Übertragung handelt es sich um ein als [[COFDM|"Coded Orthogonal Frequency Division Multiplex"]] (COFDM) bezeichnetes Mehrträgerverfahren. Dabei werden viele in geringem Frequenzabstand nebeneinander liegende Trägersignale einzeln moduliert und als Gesamtsignal übertragen.

==CAM-Chip (SEC)==
[[CAM]] steht für "'''C'''onditional '''A'''ccess '''M'''odule" und bezeichnet einen Standard zum Einsatz von Entschlüsselungsmodulen in so genannten [[CI]]s, was selbst einen Standard darstellt und für "'''C'''ommon '''I'''nterface" steht.

Ist ein Digital-Receiver mit einem [[CI]] ausgestattet, dann kann er der Theorie nach jedes dem Standard entsprechende [[CAM]] aufnehmen und somit jede verfügbare Verschlüsselungstechnologie in Verbindung mit einer entsprechenden [[Smartcard]] entschlüsseln.

Schon bei der [[DBox1]] war der Weg zu einer proprietären Lösung zu erkennen, da die dort eingesetzten [[CAM]]s keine [[CI]]-[[CAM]]s waren (auch wenn das Hardwareinterface genauso aussieht!), sondern eine eigene Lösung, die über [[I2C]] angesprochen wurde.

Bei der [[DBox2]] ist [[BR|BetaResearch]] dann noch einen Schritt weiter gegangen und hat von vornherein alternative Verschlüsselungssysteme ausgeschlossen. Das [[CAM]] ist bei der [[DBox2]] fest auf dem [[Mainboard]] aufgebracht und wird durch den SEC-Chip verkörpert. Es handelt sich bei dem Chip um eine Eigenentwicklung von BetaResearch, zu der es keine offizielle Dokumentation gibt und dessen [[Firmware]] nicht nur verschlüsselt sondern auch noch signiert ist.

[[Bild:150px-SEC.jpeg|thumb|none|150px|SEC-Chip]]

'''Hinweis:'''
{{cam_note}}

==MPEG-2 Transport Demultiplexer Chip==
Der in der [[DBox2]] eingesetzte "'''MPEG-2 Graphics Transport Demultiplexer Processor'''" -im Folgenden "Demux" genannt- wurde von der Firma C-Cube entwickelt, welche später durch das Unternehmen LSI-Logic übernommen wurde. Er wurde in verschiedenen Varianten hergestellt, die vor allem durch eine kontinuierliche Weiterentwicklung der eingesetzten Technologie begründet war.

'''Der Chip hat folgende Aufgabe:'''

Um verschiedene Signale bzw. Informationen gebündelt über einen Übertragungskanal zu übermitteln, werden die entsprechenden Einzelsignale durch einen Multiplexer zu einem komplexen Gesamtsignal geschnürt und mit geeigneten Zusatzinformationen zum korrekten Entschnüren der Einzelsignale ([[Demultiplexen]]) versehen. Die [[DVB]]-Spezifikation sieht u.a. vor, die einzelnen Signale/Daten, welche ein Sender zu seinem Programm anbieten kann, zu einem gemeinsamen Datenbündel zusammenzufügen. Diese Daten wie z.B. [[EPG]]-Informationen, Videotext aber auch die Audio-/Video-Daten selbst usw. werden zu einem Paket zusammengefügt. Der Demux trennt nun dieses Gesamtpaket wieder in seine Einzelinhalte auf und stellt dabei z.B. die AV-Signale dem "[[MPEG]]-2 Audio/Video Decoder Chip" zur Verfügung.

===GTX===
Demuxer Chip, den man nur in den Boxen des Herstellers [[Nokia]] findet. Der [[GTX]] ist der Vorgänger vom eNX Chip und hat weniger Features. Der Vorteil des [[GTX]] gegenüber dem eNX ist, dass es nicht so viele verschiedene Baureihen des Chips gab und das auf Grund dessen es leichter war für die Developer der Linux@Dbox2 Soft, die Treiber für den Chip zu schreiben.

===eNX===
Diesen Chip findet man in den Boxen der Hersteller [[Sagem]] und [[Philips]]. Der Demux demultiplext den Datenstrom und leitet ihn an den MPEG-Dekoder bzw. die [[CPU]] weiter und er ist auch noch für das [[OSD]] zuständig.

==MPEG-2 Audio/Video Decoder Chip==
Der "'''MPEG-2 Audio/Video Decoder Chip'''" der [[DBox2]] wurde ursprünglich ebenfalls durch C-Cube entwickelt. In der [[DBox2]] wurden der AViA500 und der AViA600 in noch zusätzlichen Detailvariationen eingesetzt, auf die aber nicht weiter eingegangen werden soll. Vom Hersteller wurde der Einsatz im Gespann mit dem GTX/eNX-Chip vorgesehen, was zumindest bei der [[DBox2]] auch so realisiert wurde.

'''Der Chip hat folgende Aufgabe:'''

Durch den "MPEG-2 Audio/Video Decoder Chip" wird der vom Transport-Demultiplexer erzeugte Transport [[Stream]] dekodiert. Das heißt, dass die durch den MPEG2-Standard zur Verringerung der Datenmenge (Datenreduktion) komprimierten digitalen Audio/Video-Daten wieder zu getrennten und unkomprimierten digitalen Audio- und Video-Daten dekodiert werden. Da der MPEG2-Standard eine so genannte verlustbehaftete Kompression beschreibt, in der im Wesentlichen abwechselnd ein Vollbild gefolgt von diversen Differenzbildern usw. übertragen werden, muss der A/V-Decoder nicht nur dafür sorgen, dass die Daten nach einem vorbestimmten Algorithmus entpackt werden, sondern er muss auch die verlorengegangenen Daten substituieren, denn am Ende müssen vom A/V-Dekoder wieder vollwertige, unkomprimierte digitale Audio- und Video-Daten ausgegeben werden. Die zur Verwendung kommenden Algorithmen (Ein Algorithmus ist eine eindeutige Beschreibung eines endlichen Verfahrens zur Lösung eines bestimmten Problems) zur Dekomprimierung der MPEG2-Kodierten Daten, sowie die Strategien zur Erzeugung (in der Regel aufwendige Interpolationsverfahren) möglichst realitätsnaher Daten, machen die Qualität eines MPEG2-Dekoders aus.

===AViA500===
Dieser wurde nur in alten Nokia-Boxen verbaut.

[[Bild:150px-Avia500.png|thumb|none|150px|AViA500-Chip]]

===AViA600===
Dieser wurde in allen Boxen der drei bekannten Hersteller eingebaut.

[[Bild:150px-Avia600.png|thumb|none|150px|AViA600-Chip]]

==Digital Video Encoder (SAA7126)==
Der "'''Digital Video Encoder'''" (kurz DENC) sorgt für die Umsetzung der vom "MPEG-2 Audio/Video Decoder Chip" angelieferten digitalen Video-Signale (im Standardformat der ITU-R BT.601/BT.656) in die üblichen analogen Signalarten, die in der Fernsehtechnik eingesetzt werden (z.B. RGB, CVBS und S-Video). Er besitzt dafür mehrere DACs (Digital-Analog-Converter). Einige DENCs können optional auch das "Macrovision® Copy Protection"-Signal zur Unterbindung von (analogen) Mitschnitten erzeugen. In der [[DBox2]] kommt der SAA7126 von Philips zum Einsatz.

Nähere Informationen zum SAA können hier eingesehen werden:

*[http://www.nxp.com/pip/SAA7126H_7127H_2.html SAA]

==Audio/Video-Switch (CXA)==
Der von Sony hergestellte "Audio/Video-Switch" wurde je nach Hersteller in verschiedenen Typen (z.B. [[Nokia]]=CXA2092Q oder [[Sagem]]=CXA2126Q) u.a. zur Bereitstellung der Scart-Anschlüsse der [[DBox2]] eingesetzt.

*[http://www.sony.co.jp/~semicon/english/img/sonyde01/a6801541.pdf CXA] (PDF-Dokument)

==Frontprozessor==
Der Frontprozessor (FP) ist ein speziell für die [[DBox2]] hergestellter [[Mikrocontroller]] mit maskiertem [[ROM]]. Die [[CPU]] an sich ist ein standard NEC [[Mikrocontroller]] der 78K-Serie. Da die fest eingebrannte [[Firmware]] aber bisher nicht ausgelesen werden konnte, kann man einen Ersatz nur aus einer anderen [[DBox2]] beziehen. Zu seinen Aufgaben gehören folgende Funktionen:

- Steuern der Polarisationsumschaltung (Vertikal/Horizontal) für das [[LNB]] 
- Setzen der Tuningfrequenzen für die Tuner der Nokia-Boxen (3wire-bus) 
- Erzeugen der 22kHz. Signale für [[Hardware#DiSEqC|DiSEqC]] (nur VES1893 und VES1993) (Nokia und Sagem) 
- Betrieb der Hintergrundbeleuchtung des [[LCD]] inkl. Dimmen und Auto-Dimmen 
- Betrieb der [[LED]]s (Gehäusefront) 
- Funktion der Tasten (Gehäusefront) 
- [[IR]]-Funktionen (inkl. [[Keyboard]] und [[Mouse]]) 
- Reboot und Shutdownfunktionen (Power on/off bzw. [[Deep_Standby#Deep-Standby|Deep-Standby]]) 
- Steuern des "Resetbus" (betrifft u.a. das [[CAM]]) 
- Steuern der Wakeup-Timer 
- Scart-Umschaltung (im Zusammenspiel mit dem [[Hardware#Audio.2FVideo-Switch_.28CXA.29|Audio/Video-Switch]] (CXA))

==Netzwerk-Schnittstelle==
Das Ethernet-Interface der [[DBox2]] wurde innerhalb der [[Hardware#Hauptprozessor_.28CPU.29|CPU]] realisiert. Nur der Tranceiver-Chip sitzt als diskretes Bauteil auf dem [[Mainboard]] bzw. einer Interfaceplatine der [[DBox2]].

Das Netzwerk-Interface der [[DBox2]] ist schaltungsbedingt fest auf 10MBit/HalbDuplex eingestellt. Durch einen elektrischen Eingriff und Patchen des [[Linux]]-[[Kernel]]s kann er fest auf 10MBit/VollDuplex eingestellt werden. Zuzeit ist es nicht klar, ob dieser Eingriff auf allen Versionen der [[DBox2]] problemlos funktionert.
Zumindest auf einer Sagem [[DBox2]] mit LevelOne LXT905LC Transiver konnte der Umbau erfolgreich durchgeführt werden. Es sind aber weitere Tests auf anderen Boxen nötig.

*[http://forum.tuxbox.org/forum/viewtopic.php?t=18485 Link zu einem entsprechenden Thread im Tuxbox-Forum]

*[http://tuxbox-forum.dreambox-fan.de/forum/viewtopic.php?f=19&t=47415 Link zum aktuellen Thread mit Testimages]

Artikel [[Erweiterungen#Netzwerkschnittstelle_auf_Fullduplex_umr.C3.BCsten|Fullduplex Umbau]]

==Speichererweiterung==
[[Sagem]]-Boxen kann man mit einem 32MB Modul von Kingston (KTH-LJ4100/32, entspricht HP C7845A) auf 64MB Arbeitsspeicher erweitern. Ein Kingston KTH-LJ4100/64 mit 64MB funktioniert ebenfalls, es werden allerdings nur 32MB davon erkannt, sodass insgesamt 64MB zur Verfügung stehen.

===Die Belegung des Ports der Sagem (Jolt)===
01 gnd 51 gnd
02 d15 52 d07
03 d14 53 d06
04 d13 54 d05
05 d12 55 d04
06 3v3 56 3v3
07 d11 57 d03
08 d10 58 d02
09 d09 59 d01
10 d08 60 d00

11 we1* 61 we0*
12 gnd 62 gnd
13 a29 63 a28
14 a27 64 a26
15 a25 65 a24
16 a23 66 a22
17 a21 67 a20
18 gpl_a0* 68 ba0
19 ba1 69 a18
20 a17 70 a19

21 3v3 71 3v3
22 a15 72 gpl_a2*
23 cs0* 73 gpl_a3*
24 reset_flash* 74 gpl_a4*
25 clkout_mod 75
26 gnd 76 gnd
27 gpl_a5* 77
28 oe* 78 a15
29 cs2* 79
30 cs2* 80

31 3v3 81 3v3
32 a13 82 a14
33 a11 83 a12
34 a09 84 a10
35 rsv1 85
36 gnd 86 gnd
37 we3* 87 we2*
38 d31 88 d23
39 d30 89 d22
40 d29 90 d21

41 d28 91 d20
42 3v3 92 3v3
43 d27 93 d19
44 d26 94 d18
45 d25 95 d17
46 d24 96 d16
47 gnd 97 gnd
48 98
49 99
50 3v3 100

==Interrupts==
Eine Liste der verwendeten Interrupts:

IRQ0 - ???
IRQ1 - AViA 500/600
IRQ2 - Pre-Processor
IRQ3 - Descrambler-Block
IRQ4 - MPEG-Block
IRQ5 - AViA 500/600
IRQ6 - ???
IRQ7 - Tuner

==Modem==
Die [[DBox2]] hat ein eingebautes Modem. Dieses Modem war ursprünglich dafür vorgesehen, Mehrwertdienste und Abrechnungen über den Telefonanschluss zu ermöglichen. Das Modem im eigentlichen Sinne wird von [[Neutrino]] nicht unterstützt. Das Modem arbeitet mit 3,3V-[[TTL]] Pegeln (High=3,3V). Für eigene Anwendungen (Einbau eines zweiten [[COM]] Ports) muss der Signalpegel an die [[RS232]] Spezifikation angepasst werden. Diesbezügliche Schaltungen (meist basierend auf dem [[IC]] [http://pdfserv.maxim-ic.com/en/ds/MAX220-MAX249.pdf MAX232]<-Datenblatt) findet man zuhauf im Internet.

'''Die Anschlussbelegung des Steckers (Modem abgezogen, Blick von oben auf das Board):'''

===Nokia===
1 3 5 7 9 11 13 15 17 19
* * * * * * * * * *
---> dbox Frontblende
* * * * * * * * * *
2 4 6 8 10 12 14 16 18 20

1 GND
2 RTS
3
4
5
6 DTR
7
8 VCC
9
10 GND
11 TxD
12 RxD
13 CTS
14
15 GND
16
17
18
19 GND
20

===Philips===
2 4 6 8 10 12
* * * * * *
-----> Netzteil
* * * * * *
1 3 5 7 9 11

1 VCC 5V
2 GND
3
4 GND
5
6 RESET (von FP)
7
8
9
10 TxD
11
12 RxD

===Sagem===
1 2 3 4 5 6 7 8 9 10 11 12
* * * * * * * * * * * *
-----> Netzteil

1 SMTXD2
2 SMRXD2
3 GND
4 CTS (PC4)
5 Vpp
6 !DTR (PB16)
7 GND
8 !DCD (PC15)
9 !Resetleitung (vom FP)
10 !RTS (PB17)
11 KR/RETRY/IRQ4/SPKROUT (Pin B7 vom MPC823)
12 !Sleepmode (vom FP)

derget hat sich vor einiger Zeit mit dem Thema befasst und auf seiner [http://www.noernet.de/dbox2/modem/ Website] einige Erläuterungen.

==LC-Display (LCD)==
Das [[LCD]] hängt mit seinen Adressleitungen direkt an der [[Hardware#Hauptprozessor_.28CPU.29|CPU]]. Die Hintergrundbeleuchtung wird durch den so genannten [[Hardware#Frontprozessor|Frontprozessor]] gesteuert.

[[Bild:Debug.jpg|thumb|none|Das [[LCD]] im [[Debug-Mode]] beim Starten]]

==Netzteil==
Das Netzteil der [[DBox2]] entspricht einem Standard-Schaltnetzteil, wie es heute in nahezu jedem elektronischen Gerät eingesetzt wird und dessen Leistungsaufnahme nicht durch ein konventionelles Netzteil abgedeckt werden kann. Schaltnetzteile zeichnen sich vor allem durch einen deutlich höheren Wirkungsgrad (geringe Verlustleistung) bei kleinerer Baugröße -vor allem des Trafos- aus, was sich u.a. in einer niedrigeren Wärmeentwicklung bemerkbar macht.

Bei einem Schaltnetzteil wird im Primärteil die Wechselspannung in der Regel durch einen Brückengleichrichter mit anschließender Glättung und Siebung der Primärwicklung des Transformators zugeführt. Eine Elektronik (inkl. Oszillator, Taktfrequenz liegt je nach Netzteil zwischen 30-100kHz.) sorgt nun dafür, dass der in Reihe zur Primärwicklung liegende Schalttransistor einen kurzen Stromfluss durch die Primarwicklung erzeugt. Dadurch wird eine Spannung in die Sekundärwicklung des Transformators induziert. Die Pulslänge zum Durchsteuern des Schalttransistors bestimmt dabei die Amplitude (Höhe) der am Ausgang der Sekundärwicklung erzeugten Spannung.

Durch die galvanische Trennung werden Störungen auf der Primärseite deutlich schwächer auf der Sekundärseite wiedergegeben. Im Weiteren wird die hochfrequente Sekundärspannung nun wieder gleichgerichtet und geglättet/gesiebt. Geeignete Stabilisierungsschaltungen sorgen für eine möglichst stabile Gleichspannung. Diese Spannung kann höher als die gleichgerichtete Eingangsspannung sein. Im Normalfall werden durch mehrere Sekundärwicklungen eine ganze Reihe von unterschiedlich hohen Spannungen erzeugt.

==IR-Sender/Empfänger==
Die [[DBox2]] verfügt über einen [[IR]]-Empfänger, der am [[Hardware#Frontprozessor|Frontprozessor]] angeschlossen ist. Dieser Empfänger ist für die [[Fernbedienung]] und die optional erhältliche [[Keyboard]]-/[[Mouse]]-Kombination zuständig.

Eine [[IR]]-Sendediode ist am [[Hardware#MPEG-2_Transport_Demultiplexer_Chip|Demux]] angeschlossen. Sie ist zur Aufnahmesteuerung eines Videorekorders gedacht, welche durch [[LIRC]] realisiert werden kann.

Am [[Hardware#MPEG-2_Transport_Demultiplexer_Chip|Demux]] ist auserdem eine weitere [[IR]]-Empfangsdiode angeschlossen, wodurch er theoretisch auch die Möglichkeit besitzt, ein IR-Signal zu dekodieren. Die Empfangsdiode ist dafür aber nicht geeignet, da im Gegensatz zum Frontprozessor der Demodulator fehlt. Wird allerdings ein entsprechender [[IR]]-Demodulator nachgerüstet, kann über [[LIRC]] oder einen alternativen Input-Event-Treiber auch ein Fernbedienungssignal ausgewertet werden.

==Optischer Ausgang (S/P-DIF)==
Die [[DBox2]] besitzt hinten einen optischen Ausgang für das AC3-Signal, was teilweise mitgesendet wird. Dieser wird über ein TOTX178a von Toshiba realisiert und ist direkt an dem [[Hardware#MPEG-2_Audio.2FVideo_Decoder_Chip|AViA]] angeschlossen.
Die Reichweite beträgt maximal 5 Meter und die Datenrate maximal 6 Mb/s.

==DiSEqC==
siehe: [[DiSEqC]].

===DiSEqC mit der DBox2===
22kHz. Signale, also auch [[DiSEqC]], werden bei den Boxen von [[Nokia]] und [[Sagem]] vom [[Hardware#Frontprozessor|Frontprozessor]] erzeugt. Bei [[Philips]] übernimmt das [[Hardware#Tuner_.28Frontend.29|Frontend]] diese Aufgabe.

Dbox2 Entwicklungsumgebung

2009-04-20T18:19:31Z

Dixidix: Einige Inhalte ergänzt

[[Category:Register]]
[[Category:Development]]
[[Category:CDK]]
{{Development_sidebar}}

__TOC__
{{Review}}
=Allgemeines=
Die Erstellung von [[Images]] und [[Yadd]]s erfolgt durch einen neuen bzw. überarbeiteten "[[Make|make]]" Prozesses, bisher auch als "Newmake" bekannt. Der inzwischen auch als [[Image erstellen|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 |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, [[Images|Flashimages]] und [[yadd|YADDs]] unter [[Linux|Linux]] zu erstellen.
Es gibt inzwischen auch eine auf Konsole basierende Frontendlösung, mit der sich [[Images|Flashimages]] oder [[yadd|YADDs]] benutzerdefiniert erstellen lassen, das sogenannte [[yBuild]].

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

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

==Zur Geschichte==
Vor einigen Jahren war die Imageherstellung für die [[Tuxbox|Tuxbox]] so etwas wie [[Wikipedia:Schwarze Kunst|"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|CVS]]-Verzeichnis ''.../hostapps/[[Mkflfs|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|CVS]]-Sources mit einigen mehr-oder-weniger geheim gehaltenen "Fixes", (vermutlich) notwendig für das Herstellen eines funktionierenden [[Images]] aus dem [[CVS|CVS]]-Quellcode.

Im August 2003, wurde es für das [[DBox2 Software Projekt|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|Software]]-Design... Ein [[Image]] aus reinen [[CVS|CVS]]-Dateien zu bauen, war nicht wirklich möglich.

2004 wurde das [[YADI]] ("'''Y'''et '''A'''nother '''D'''Box '''I'''mage") Projekt geboren. 
Sein Ziel war es, das "Imagebauen" zu automatisieren und zu vereinfachen. Zu diesem Zweck wurden eine Anzahl von [[Wikipedia:Skripte|Scripten]] und [[Wikipedia:Patches|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|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|Skript]] war das automatische Imagebuilden zwar möglich, jedoch statt grundlegende Schwächen im [[CDK|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|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 [[Images#DietmarW-Images|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 [[Wikipedia:Skriptsprache|Shellskripten]] wird für viele Teile, insbesondere für das [[Customization]]-Kapitel, aber nicht für [[Image]]/[[yadd|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|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|Images]] bleiben.

= [[Images|Images]] und [[Yadd|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
*[[YADD]]
oder
*[[Image]].
Ein [[YADD]] besteht aus einigen Dateien, die die DBox anstatt aus dem [[Flash]] über den [[TFTP]]-Service lädt, sowie ein [[Filesystem|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 "'''Y'''et '''A'''nother '''D'''Box '''D'''istribution" ("noch eine dBox Verteilung").''

=== Erste Schritte und Überlegungen ===
Eine Empfehlung für den angehenden "[[Image|Image]]/[[Yadd|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|Image]] mit der Lieblings-[[GUI]] zu erstellen.

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

In diesem Artikel bezeichnet "[[GUI]]" entweder
*[[Neutrino]]
*[[Enigma]]
*[[Lcars]]
*[[Radiobox]].

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

Dies wären:
*[[cramfs]] (komprimiertes, Read-only [[Filesystem|filesystem]] für embedded Systeme)
*[[squashfs]] (komprimiertes read-only-[[Dateisystem|Dateisystem]] (wird allgemnein leistungsfähiger als [[cramfs]] angesehen)
oder
*[[jffs2]] (ein "journalled" Read-Write-[[Filesystem|Filesystem]]).

Ein "'''[[Cramfs|cramfs]] Komplett-[[Image|Image]]'''" besteht aus einem Root-[[Dateisystem|Dateisystem]] mit dem [[cramfs]] [[Dateisystem|Dateisystem]] und einem kleineren [[jffs2]]-[[Filesystem|Filesystem]], das nach '''/var''', dem schreibbaren Bereich eines [[Images]], gemounted wird.
 
Dies gilt auch für "'''[[Squashfs|squashfs]] Komplett-[[Images|Images]]'''", während ein "'''[[Jffs2|jffs2]] Komplett-[[Image|Image]]'''" kein separates ''/var-[[Dateisystem|Dateisystem]]'' enthält, weil [[Jffs2|jffs2]] bereits beschreibbar (var) 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|Images]] eine weitere [[Partition|Partition]], die den [[u-boot]]-[[Bootloader]] enthalten. Diese [[Partition|Partition]] ist zwischen dBoxen mit einen und zwei [[Flash]]chips unterschiedlich. Dieses wird durch "'''1x'''" und "'''2x'''" angezeigt. Ein komplettes [[Image|Image]] würde demnach so benannt werden:

[GUI]-[Filesystem].img[1, 2]x
z.B. als fertiges [[Image|Image]]:
[[Neutrino|neutrino]]-[[Jffs2|jffs2]].img2x

== Buildsystem Voraussetzungen ==
Neben einem modernen [[Unix|Unix]]/[[Linux|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 [[DBox2 Software Projekt|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 [[WP:autoconf|autoconf]], [[WP:automake|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:

{{Vorlage:GNU_Tools}}

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!''

Builden auf einem [[Unix|Unix]]-non-[[Linux|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|GNU]]-Spezifikationen uneingeschränkt verwendet werden.

Es wird daher davon abgeraten eine Umbegebung z.B. mit [[Cygwin]] aufzubauen, da es höchstwahrscheinlich nicht funktionieren wird. In dieser Richtung wurde zwar Einiges für den Makeprozess eingebaut, jedoch dürfte der gegenwärtige Entwicklungsstand nicht den gegenwärtigen Anforderungen entsprechen, um aktuell auch damit arbeiten zu können.

Empfehlenswert ist allerdings 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.

== Auschecken ==
Die [[Tuxbox|Tuxbox]] Quellen werden durch den [[Tuxbox|Tuxbox]] [[CVS-Server]] bereitgestellt.

Regelmäßige Quellreleases sind niemals gemacht worden, und sind auch nicht für die Zukunft geplant. Als Normalbenutzer werden die Quellen anonym "ausgecheckt", was bedeutet, dass diese auf die eigene Festplatte kopiert werden, indem man zuerst auf einer (lokalen) Festplatte mit "ordentlich" freiem Platz ein leeres Verzeichnis erstellt, z.B. ''/[[Tuxbox|tuxbox]]-[[CVS|cvs]]'' und in diesen Ordner wechselt, und diesen Befehl ausführt.

cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .

Für ein Update der Quellen, diesen Befehl verwenden:

cvs -z3 -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox up -dP .

'''Hinweis:'''
''Es ist durchaus sinnvoll wegen des Traffics möglichst nur ein Update zu machen, als jedesmal komplett auszuchecken!''

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|CVS]] Quellen" verwendet.

== Konfiguration ==
Jetzt müssen einge Zwischenschritte erledigt werden, damit der Buildprozess auch erkennt, was und vorallem wie er es machen soll.

Man wechselt nun in das [[CDK|CDK]]-Unterverzeichnis
cd [[CDK|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|Images]], [[Yadd|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.
{{Newmake_Build_Optionen}}
Eine typische Anwendung (Konfiguration), der mit z.B. den Pfadnamen oben kompatibel wäre, könnte so eingestellt werden:

./configure --with-cvsdir="/[[Tuxbox|tuxbox]]-[[CVS|cvs]]" --prefix="/[[Dbox2|dbox2]]" --enable-maintainer-mode

*''--with-cvsdir''
sagt wo die Quellen zu finden sind, (darin sollte auch ein Unterverzeichnis ''.../[[CDK|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|Makefiles]] ermöglicht, sich automatisch neu zu erzeugen, sobald die Notwendigkeit entsteht, zum Beispiel nach einem [[Software|Software]]-[[Update|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|tuxbox]] [[Mklibs|mklibs]]
checking for mkcramfs... no
configure: WARNING: using [[Tuxbox|tuxbox]] [[Cramfs|cramfs]]
checking for mkjffs2... no
checking for [[Mkfs.jffs2|mkfs.jffs2]]... no
configure: WARNING: using [[Tuxbox|tuxbox]] [[Mkfs.jffs2|mkfs.jffs2]]
checking for mksquashfs... no
configure: WARNING: using [[Tuxbox|tuxbox]] [[Squashfs|squashfs]]
...

Dies sind nur Hinweise darauf, dass hier projekteigene Versionen einiger [[Tools|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.''

[[Bild:Stop hand.png]]
<div style="margin: 0; margin-top:10px; margin-right:0px; border: 3px solid #FF0000; padding: 0px 10px 1px 10px; background-color:#DEB0B0; align:right; ">
'''
Versuche niemals, als root zu bauen!'''
</div>

== Kompilieren ==
Die high-level [[Make|make]] Targets, die für das Builden von Komplett-[[Images|Images]] relevant sind, lauten:
*<pre><nowiki>flash-[neutrino, enigma, all]</nowiki></pre>
*<pre><nowiki>flash-[cramfs, squashfs, jffs2, all]</nowiki></pre>
*<pre><nowiki>[1x, 2x, alle]</nowiki></pre>
Für [[Yadd|YADD]]-Builds, sind diese:
*<pre><nowiki>yadd-[neutrino, enigma, all]</nowiki></pre>
'''Beispiele:'''

[[Make|make]] [[Flash|flash]]-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]-all

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

'''der Befehl:'''

make [[Yadd|yadd]]-[[Enigma|enigma]]

erzeugt ein [[Yadd|YADD]], das [[Enigma|Enigma]] enthält.

make flash-enigma+neutrino-squashfs-all

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

=== 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|make]] [[Yadd|yadd]]-[[Neutrino|neutrino]]''' mit leeren Verzeichnissen etwa 1 und 1,5 Stunden.

==== Verwendung von [[Ccache|ccache]] ====
Um den Vorgang insbesondere bei wiederholten Kompilieren und besonders auf langsameren Rechnern zu beschleunigen, steht die Option
* --enable-[[Ccache|ccache]]
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|ccache]]''' wird erreicht, sollte das Tool bereits in deiner Distribution installiert sein, dass [[ccache]] automatisch erkannt wird und in das [[Tuxbox|Tuxbox]]-[[CDK|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|make]] [[Ccache|ccache]]
in das [[CDK|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|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|ccache]] -s
prüfen. Als Ergebnis werden einige Statistiken ü[[BER|ber]] das Cache-Verhalten von [[Ccache|ccache]] ausgegeben:
cache directory /home/<USER>/.[[Ccache|ccache]]
cache hit 4
cache miss 191
called for [[Link|link]] 17
multiple source files 4
compile failed 17
preprocessor error 2
not a C/C++ file 5
autoconf compile/[[Link|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|make]] [[Yadd|yadd]]-[[Neutrino|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 '''J'''obs 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|Images]], Yadds oder einzelne Targets bauen kann. Diese Beispiele sollten so wie sie hier vorgegeben sind ohne Veränderung auf jedem [[Linux|Linux]]-System mit den bisher beschriebenen Voraussetzungen laufen. Da die Systeme trotzdem [[Unterschiede|Unterschiede]] aufweisen können, kann man das aber nicht garantieren.

==== [[Neutrino|neutrino]]-[[Jffs2|jffs2]]-[[Image|Image]] ====
#! /bin/bash
# beispiel.sh
# Diese Script baut [[Neutrino|neutrino]]-[[Jffs2|jffs2]] [[Images|Images]], jeweils 1x und 2x
#----------------------------------------------
USERDIR=/home/$(whoami)
#----------------------------------------------
LOGODIR=$USERDIR/Logos
CP=$USERDIR/[[Tuxbox|tuxbox]]-[[CVS|cvs]]
DB=$USERDIR/[[Dbox2|dbox2]]
ARCHIVEDIR=$USERDIR/Archive
export CVS_RSH=[[SSH|ssh]]
#-----------------------------------------------
cd "$CP"
[[CVS|cvs]] -d anoncvs@[[CVS|cvs]].[[Tuxbox|tuxbox]].org:/[[CVS|cvs]]/[[Tuxbox|tuxbox]] -z3 co -P .
cd [[CDK|cdk]]
/bin/ln -sf $ARCHIVEDIR/ Archive
./autogen.sh
./configure --prefix="$DB" --with-cvsdir="$CP" --enable-flashrules --enable-[[Ccache|ccache]] --with-[[CheckImage|checkImage]]=rename --with-logosdir="$LOGODIR"
[[Make|make]] [[Flash|flash]]-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]-all

==== Neutrigma-[[squashfs]]-[[Image|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|tuxbox]]-[[CVS|cvs]]
DB=$USERDIR/[[Dbox2|dbox2]]
ARCHIVEDIR=$USERDIR/Archive
export CVS_RSH=[[SSH|ssh]]
#-----------------------------------------------
cd "$CP"
[[CVS|cvs]] -d anoncvs@[[CVS|cvs]].[[Tuxbox|tuxbox]].org:/[[CVS|cvs]]/[[Tuxbox|tuxbox]] -z3 co -P .
cd [[CDK|cdk]]
/bin/ln -sf $ARCHIVEDIR/ Archive
./autogen.sh
./configure --prefix="$DB" --with-cvsdir="$CP" --enable-flashrules --enable-[[Ccache|ccache]] --with-[[CheckImage|checkImage]]=rename --with-logosdir="$LOGODIR"
[[Make|make]] flash-enigma+neutrino-squashfs-all

==== [[Neutrino|Neutrino]] [[Yadd|YADD]] ====
#! /bin/bash
# beispiel.sh
# Diese Script baut ein [[Neutrino|Neutrino]] [[Yadd|Yadd]]
#----------------------------------------------
USERDIR=/home/$(whoami)
#----------------------------------------------
LOGODIR=/Logos
CP=$USERDIR/[[Tuxbox|tuxbox]]-[[CVS|cvs]]
DB=$USERDIR/[[Dbox2|dbox2]]
ARCHIVEDIR=$USERDIR/Archive
export CVS_RSH=[[SSH|ssh]]
#-----------------------------------------------
cd "$CP"
[[CVS|cvs]] -d anoncvs@[[CVS|cvs]].[[Tuxbox|tuxbox]].org:/[[CVS|cvs]]/[[Tuxbox|tuxbox]] -z3 co -P .
cd [[CDK|cdk]]
/bin/ln -sf $ARCHIVEDIR/ Archive
./autogen.sh
./configure --prefix="$DB" --with-cvsdir="$CP" --with-logosdir="$LOGODIR" --enable-[[Ccache|ccache]]
[[Make|make]] [[Yadd|yadd]]-[[Neutrino|neutrino]]

= Kernel 2.6.x =

{{Bulid_kernel_26}}

= Was kommt dann...? =
== Booten von [[Yadd|YADD]] ==
Wenn ein [[Yadd|YADD]] frisch erzeugt wurde, kann damit auch die Box booten. Näheres dazu auch im Artikel [[CDK booten]]. 
Newmake hält auch ein [[Make|Make]]-Target für den serversupport bereit.
[[Make|make]] serversupport
Dieses erzeugt einige Konfigurationsdateien für den [[Server|Server]] der das [[Yadd|YADD]]-Build nahtlos an das [[Server|Server]]-Setup anknüpft.

== [[Flashen|Flashen]] des [[Images|Images]] ==
Wenn ein [[Image|Image]] gebaut wurde, ist der logische nächste Schritt das Einspielen des [[Images|Images]] in den [[Flash|Flash]] der Box. Hierfür ist entweder, das interaktive [[Flashen|Flashen]] innerhalb der [[GUI|GUI]] mit den [[Installation:Neutrino|Expertenfunktionen]] zu benutzen, oder der ''dboxflasher'' zu verwenden. Der ''dboxflasher'' wird durch das [[Make|Make]]-Target
[[Make|make]] serversupport
erzeugt. 
Siehe auch [[Installation]].

== Inkrementelle Builds ==
Im allgemeinen ist man nicht an einem einmaligen Build der [[Software|Software]] interessiert. Verbesserungen an den Quellen werden in das [[CVS|CVS]] täglich eingecheckt. Oft möchte man die [[Software|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|make]] [target]
und [[Make|make]] wird es, falls notwendig, neu erzeugen.

Es kann auch passieren, dass [[Make|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|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|Installation]] eines bestimmten Pakets wird durch das Anlegen einer Markerdatei im Verzeichnis ''[[CDK|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|make]] distclean
Das drastischste Reinigungs-Target, (fast) alles löschend, was nicht vom [[CVS|CVS]] ausgecheckt wurde.
Dieses ist eher selten notwendig.
 
[[Make|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|Yadd]]-[[Installation|Installation]]), sowie die [[Tftp|TFTP]]-Files ([[Kernel|Kernel]] und [[U-boot|u-boot]]) werden nicht angefasst.
 
[[Make|make]] depsclean
Löscht alle Markerdateien im /[[CDK|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|make]] clean
Kombiniert ''mostlyclean'', ''depsclean'', und ''[[Flash|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|make]] bootstrap''.
 
[[Make|make]] [[Flash|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|make]] [[Flash|flash]]-mostlyclean
Zusätzlich zum ''[[Flash|flash]]-semiclean'' löscht dieses Target auch Bootfiles und die Kernbauverzeichnisse. Vollimages werden unberührt gelassen.
 
[[Make|make]] [[Flash|flash]]-clean
Dieses Target löscht Alles in $(flashprefix).
 
Einige Quellverzeichnisse können mit einem Befehl wie
[[Make|make]] -C /[[Tuxbox|tuxbox]]-[[CVS|cvs]]/apps/[[Tuxbox|tuxbox]]/[[Neutrino|neutrino]] clean
gesäubert werden.

== Aktualisierung des [[CVS|CVS]]-Quellcodes ==
Um die Quellen mit neueren Checkins zu aktualisieren, verwende diesen Befehl für das toplevel [[CVS|CVS]] Verzeichnis (oder von einem anderen Verzeichnis, wenn Ihr wisst, was ihr tut;-). Mögliche Fehler werden in das logfile [[CVS|cvs]].log geschrieben.

cvs up -r HEAD > cvs.log 2>&1

'''Tipp'''
 
Um mit dem [[CVS|CVS]] arbeiten zu können nimmt man für gewöhnlich die Konsole für Eingaben. Es gibt aber auch verschiedene Frontendwerkzeuge wie z.B. [http://www.crossvc.com CrossVC] oder [http://cervisia.kde.org/ Cervisia] um nur einige zu nennen, die einen recht komfortablen Umgang mit den [[CVS|CVS]]-Daten ermöglichen. [[Bild:Crossvc.jpg|CrossVC als CVS Frontendlösung]] [[Bild:Cervisia.jpg|Cervisia als CVS Frontendlösung]] 
Auch einige [[IDE|IDE]]'s wie z.B. [[WP:Anjuta|Anjuta]] [[Bild:anjuta.jpg|Anjuta als IDE mit CVS-Anbindung]] bieten solche [[CVS|CVS]]-Schnittstellen an.

== [[Customization|Customization]] ==
Ein "Schreckgespenst" für viele "[[Oldmake]]rs" ist anscheinend die so genannte [[Customization|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|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|Ucodes (Firmaredateien]] enthält, die im [[Image|Image]] enthalten sein sollen.
'''Hinweis:''' 
Ein [[Image|Image]], dass [[Ucodes|ucodes]] enthält, darf
nicht verbreitet werden! 

====--with-logosdir=[DIR]====
Legt ein Verzeichniss fest, das boot-logos (logo-[[LCD|lcd]] und logo-fb) enthält, die im [[Image|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 [[Cramfs|cramfs]] und [[Squashfs|squashfs]] [[Images|Images]] fest.

Die Größe der var-[[Partition|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|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=<nowiki>http://www.deine-updateseite.de</nowiki>

Diese Adresse erscheint beispielsweise in der Versionsdatei ''(.version)'', in den [[Neutrino:Service:Image_Informationen|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 [[Neutrino:Service:Software-Aktualisierung#Experten-Funktionen|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
*cramfs.list für Root-cramfs Updates
*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:
<nowiki>http://www.deine-homepage.de/downloads/Image-v2.0_neutrino_squashfs_1200200808281200_1x.img 06c30a36329d990194f249d3a3648aec 1200200808281200 Image-v2.0_1x</nowiki>

Die Einträge in die ''*.list''-Files und ''update.urls'' lassen sich mit Hilfe von [[Newmake#Customization-Scripte|Customization-Scripte]]n erzeugen und anschließend ins Image einfügen (siehe auch: [[Newmake#.2F.version_anpassen|.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-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====
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

====--enable-uclibc====
Aktviert Makerules für uClibc verlinkte Targets (derzeit noch experimentell) '''Erfahrungswerte erwünscht'''!

====--enable-maintainer-mode====
Ermöglicht den hergestellten [[Makefiles|Makefiles]], sich automatisch neu zu erzeugen, sobald die Notwendigkeit entsteht, zum Beispiel nach einem [[Software|Software]]-[[Update|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%27s_mit_Kernel_2.6|Images_und_Yadd's_mit_Kernel_2.6]]

====--enable-lzma====
Images/Kernel werden mit [[Squashfs]]-[[Lzma]]-Unterstützung gebaut. Bootzeiten können dadurch länger werden, aber [[Images]] sind aufnahmefähiger.

====--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-ide====
Ermöglicht das Bauen von Images/Yadds mit support für [[IDE-Interface]]s. Es werden hierfür die passenden Treiber und Kernel-Module gebaut.

====--enable-mmc====
Ermöglicht das Bauen von Images/Yadds mit support für [[MMC]]s. Es werden hierfür die passenden Treiber und Kernel-Module gebaut.

====--enable-sqlite====
Aktiviert SQL-Lite Support

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

====--enable-dosfstools====
Es werden dos Filesystem Werkzeuge gebaut

====--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 [[Kompiler]]-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|Wissen]] ü[[BER|ber]] die innere Funktionsweise der [[Makefiles|Makefiles]] zu haben.

In der Folge bezeichnet
$(flashprefix)
den Wert der Makefile Variablen '''flashprefix''' (mit Konfiguration wie oben '''/[[Dbox2|dbox2]]/cdkflash''')
$(targetprefix)
bezeichnet den Wert der Makefile Variablen '''targetprefix''' (mit Konfiguration wie oben '''/[[Dbox2|dbox2]]/cdkroot'''), und
$(buildprefix)
bezeichnet den Wert der Makefile Variablen '''buildprefix''' (mit der Konfiguration oben '''/[[Tuxbox|tuxbox]]-[[CVS|cvs]]/[[CDK|cdk]]''').

Um z.B. ein '''[[Neutrino|neutrino]]-[[Cramfs|cramfs]].img2x''' zu erzeugen, werden die folgenden Verzeichnisse erstellt: 
*'''$(flashprefix)/root''' (enthält [[Filesystem|Filesystem]]- und [[GUI|GUI]]-unabhängige Bestandteile)
*'''$(flashprefix)/root-[[Cramfs|cramfs]]''' (enthält den [[Kernel|Kernel]], für Root-[[Filesystem|Filesystem]] auf [[Cramfs|cramfs]] konfiguriert, zusammen mit seinen Treibern) und
*'''$(flashprefix)/root-[[Neutrino|neutrino]]''' (enthält die Neutrinoinstallation).

Aus diesen drei Verzeichnissen, werden das Rootfilesystemverzeichniss
*'''$(flashprefix)/root-[[Neutrino|neutrino]]-[[Cramfs|cramfs]]''' und das
var-filesystemverzeichnis
*'''$(flashprefix)/var-[[Neutrino|neutrino]]''' gebaut.

Hiermit ist es möglich, einen Befehl wie
[[Make|make]] $(flashprefix)/root-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]
bzw. wenn man sich im Verzeichnis ''./[[Tuxbox|tuxbox]]-[[CVS|cvs]]/[[CDK|cdk]]'' befindet, den Befehl
[[Make|make]] root-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]
einzugeben, wobei man bei erster VAriante natürlich '''$(flashprefix)''' selbst durch den realen Pfad ersetzen muss, da '''$(flashprefix)''' nur eine [[Make|make]]-Variable ist, welche in unserem Beispiel den Pfad zu '''./[[Dbox2|dbox2]]/cdkflash''' darstellt. 
Man kann so manuell gewünschten Änderungen an '''$(flashprefix)/root-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]''' vornehmen, und dann, mit dem Befehl
[[Make|make]] [[Flash|flash]]-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]-2x
den Imagebau abschließen, um ein [[Image|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|Customization]]-Scripte ===
Sofern diese Scripte vorhanden und ausführbar sind, werden innerhalb der wichtigsten Targets diese sogenannten ''[[Customization|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|cdk]]'''-Ordner.
Bei Bedarf kann mit der Option
--with-customizationsdir=[DIR]
ein alternatives Verzeichnis für [[Customization|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|Shell]]-Scripts könnte dies z.B. ein kompiliertes C Programme, oder ein [[Perl|Perl]]-Script sein. 
Der Name eines [[Customization|Customization]] Scriptes besteht in der Regel aus dem Namen eines Targetverzeichnisses bzw. einem Target und dem angefügtem *'''-local.sh'''.

==== Für [[Flash|Flash]]-Targets ====
Der Name der [[Customization|Customization]] Scripte für [[Images|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
*[[Neutrino|neutrino]]
*[[Enigma|enigma]]
*[[Lcars|lcars]]
*[[Radiobox|radiobox]]

"[[FS]]" zeigt an welches [[Filesystem|Filesystem]] gemeint ist.
*[[Cramfs|cramfs]]
*[[Squashfs|squashfs]]
*[[Jffs2|jffs2]]

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|neutrino]]-local.sh
root-[[Neutrino|neutrino]]-[[Squashfs|squashfs]]-local.sh
root-[[Squashfs|squashfs]]-local.sh
var-[[Neutrino|neutrino]]-local.sh

==== Für [[Yadd|Yadd]]-Targets ====
Für Yadds ist das Prinzip ähnlich, nur dass es hier quasi nur einen Ordner gibt. Dafür stellvertretend steht dann
*[[Yadd|yadd]].

Das "[[GUI]]" in Klammern bezeichnet auch hier die jeweilig betroffene Benutzeroberflche, also
*[[Neutrino|neutrino]]
*[[Enigma|enigma]]
*[[Lcars|lcars]]
*[[Radiobox|radiobox]]

so wäre die Bezeichnung der jeweiligen Scripte so aufgebaut.
*[[Yadd|yadd]]-[GUI]-local.sh
'''Beispiel:'''
[[Yadd|yadd]]-[[Neutrino|neutrino]]-local.sh

==== für andere Targets ====
Die bisher benannten [[Customization|Customization]] Scripte für [[Flash|Flash]]- u. [[Yadd|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|make]] hdparm
aus, wird beim Bauen das ausgeführt was im [[Customization|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 [[Newmake#.2F.version_anpassen|Anpassung .version-File]]): 
Während des [[Make|make]]-Durchlaufs werden einige Targets ausgeführt, welche die '''/.version'''-Files bei [[YADD]]
*'''version'''
bzw.
*'''[[Flash|flash]]-version'''
im [[Image]] erstellt.
 
Sofern eines dieser Scripte;
*'''version-local.sh'''
*'''[[Flash|flash]]-version-local.sh'''
vorhanden und ausführbar ist, wird es als Ersatz statt des originalen Targets ausgeführt, welches mit
[[Make|make]] version
bzw.
[[Make|make]] [[Flash|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|jffs2]]-[[Image|Image]] wird dies gewünscht:

1. Eigene /etc/hosts benutzen,
2. Eigene [[Neutrino|neutrino]].conf, [[Bouquets|bouquets]].[[XML|xml]], services.[[XML|xml]] benutzen
3. einschließlich [[Lirc|lirc]]-Komponenten, zusammen mit eigenen [[Lirc|lirc]] Konfigurations-Dateien.

1. und 3. sind [[Erweiterungen|Erweiterungen]], die nach '''$(flashprefix)/root''' kommen sollten, während 2. [[Neutrino|Neutrino]]-regeln sind, welche nach sollten '''$(flashprefix)/root-[[Neutrino|neutrino]]-[[Jffs2|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|make]] flashlirc
cp -fr $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Lirc|lirc]] $newroot/var/[[Tuxbox|tuxbox]]/config

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

#!/bin/sh
# root-[[Neutrino|neutrino]]-local.sh
flashprefix=$1
buildprefix=$2
newroot=$flashprefix/root-[[Neutrino|neutrino]]
myfiles=/home/somewhere/dbox/myfiles
cp $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Neutrino|neutrino]].conf $newroot/var/[[Tuxbox|tuxbox]]/config
cp $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]/[[Bouquets|bouquets]].[[XML|xml]] $newroot/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]
cp $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]/services.[[XML|xml]] $newroot/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]

===== procps-Varianten von ps und top einbauen =====
Im Image werden die procps-Varianten von [[WP:Ps_%28Unix%29|ps]] und [[WP:Unix-Kommando#Prozessmanagement|top]] anstelle der [[WP:busybox|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|Spiele]] (definiert als [[Plugins|plugins]] mit type=1 in ihrer Konfigurationsdatei), sowie unerwünschte Sprachfiles ([[Neutrino|Neutrino]] angenommen). Das File sollte von '''root-[[Neutrino|neutrino]]-$[[Filesystem|filesystem]]-local.sh''' aufgerufen werden.

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

===== /.version anpassen =====

{{edit_version_file}}

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

*[[Flash|flash]]-version-local.sh

#/bin/sh
USER=$(whoami)
if [ $0 = $CDIR/flash-version-local.sh ] ; then
outfile=$FLASHDIR/root/.version
type="[[Image|Image]]"
else
outfile=$TARGETDIR/.version
type="[[Yadd|Yadd]]"
fi;
echo Creating $outfile ...
echo "version=`./mkversion -[[Snapshot|snapshot]] -version 200`" > $outfile
echo "creator=$USER" >> $outfile
echo "imagename=$USER-$type" >> $outfile
echo "homepage=[[HTTP|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|release]])
releasetype=0
;;
-[[Snapshot|snapshot]])
releasetype=1
;;
-internal)
releasetype=2
;;
-version)
versionnumber=$2
shift
;;
esac
shift
done
echo $releasetype$versionnumber$year$month$day$hour$minute

===== Archivierung der [[Images|Images]] =====
Es ist eigentlich die Aufgabe des Buildprozesses, flashbare [[Images|Images]] zu erzeugen, und nicht sie zu archivieren. Jedoch kann die [[Customization|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]-[cramfs, 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|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|Customization]] Scripte für den eigenen Bedarf schreibt.

== Idempotens ==
Es ist fast immer eine gute Idee zu versuchen, ein Installationsscript [[Wikipedia:Idempotent|idempotent]] zu schreiben. Dies bedeutet, dass das mehrmalige Ausführen den gleichen Effekt hat wie das einmalige Ausführen.
Benutze "[[Make|make]] install".
 
In der Vergangenheit hat das [[Tuxbox|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|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|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|gui]]-[[Filesystem|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 [[Wikipedia:Inkonsistent|inkonsistenten]] Zustand versetzen. Dies gilt insbesondere für die Verzeichnisse in '''$(flashprefix)'''. Wenn der Bau solch eines [[Make|Make]]-Targets abbricht, besteht das Verzeichnis, ist entsprechend seiner Änderungszeit aktuell, und ein folgender [[Make|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|Br]]üche geht, '''dann lösche man es''', bevor ein anderer [[Make|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|Hilfe]] benötigt, siehe unten!.

=== Nach dem [[Flashen|Flashen]]: "Kein System" auf dem [[LCD|LCD]]/Was ist diese "bad magic byte" Zeugs? ===
Diese Frage kommt hoffentlich nicht... Die kurze Antwort ist: Man weiß es nicht. Wir [[Wissen|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|Image]] "ist" in Ordnung, es ist nur dass irgendwelche [[Firmware|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|CVS]], zu finden im Verzeichnis '''./hostapps/[[CheckImage|checkImage]]''' ermittelt diese "schlechten Bytes", aber ändert nichts daran, um diese zu beheben. Die Erfahrung zeigt, daß [[Images|Images]], die [[checkImage]] für gut findet, wirklich laufen. [[Cramfs|Cramfs]]-, oder [[Squashfs|squashfs]] [[Images|Images]], worü[[BER|ber]] sich [[CheckImage|checkImage]] beschwert, laufen im allgemeinen nicht, in einigen Ausnahmefällen läufen sie aber doch.
 
Auch bei [[Jffs2|jffs2]]-[[Images|Images]] ist dies manchmal der Fall, dass sich [[checkImage]] beschwert, die [[Images|Images]] laufen, aber eben nicht immer. Mit diesen empirischen Beobachtungen ist man nun sich selbst überlassen.
 
Newmake weiß, wie dieses Programm aufgerufen werden kann, um die erzeugten [[Images|Images]] automatisch zu überprüfen. Die Konfigurationsoption
--with-[[CheckImage|checkImage]]=[none,rename,warn]
wird hierfür verwendet. Falls '''warn''' gewählt ist, wird für jedes [[Image|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 erwähnt werden, daß die "schlechten magischen Bytes" in einem (oder mehreren!) der Partitionsteile sitzt, und werden nicht durch den abschließenden Schritt erzeugt (die *.img1x und/oder *.img2x Files bauen). Es ist auch möglich, [[CheckImage|checkImage]] auf die Partitionsfiles anzuwenden *.[[Jffs2|jffs2]], *.[[Cramfs|cramfs]]
*.[[Squashfs|squashfs]]
*.flfs1x
*.flfs2x
Schließlich hat [[CheckImage|checkImage]] eine Debugoption, die nützlich sein kann.

== Ich habe ein Fehler gefunden! ==
Bugs, Unklarheiten, Verbesserungsvorschläge, etc. der [[Software|Software]] sollten vorzugsweise im [http://tuxbox-forum.dreambox-fan.de/forum/viewforum.php?f=7 Cross Development Kit - Forum] des [[Tuxbox|Tuxbox]]-Boards gepostet werden.

== Ich benötige [[Hilfe|Hilfe]]! ==
Supportanfragen können im [http://tuxbox-forum.dreambox-fan.de/forum/viewforum.php?f=7 Cross Development Kit - Forum] des [[Tuxbox|Tuxbox]]-Boards gepostet werden. Postings in deutsch oder englisch sind willkommen. Bitte nicht vergessen, die benutzten Konfigurationsoptionen zu erwähnen.

=Links=
*[http://www.gnu.org/software/make/manual/make.html GNU Make manual]
*[http://www.gnu.org/software/autoconf/manual/ Autoconf manual]
*[http://www.gnu.org/software/automake/manual/ Automake manual]
*[http://sources.redhat.com/autobook/ GNU Autoconf, Automake, and Libtool]
*[http://www.gnu.org/prep/standards/ GNU Coding standards]
*[http://cvsbook.red-bean.com/ Open Source Development with CVS, 3rd Edition]
*Barf's Homepage: [http://bengt-martensson.de/dbox2/ Barfs ][[Newmake]]-Dokumentation]

{{review}}

{{body}}

Diskussion:Neutrino:Einstellungen:Video

2009-04-01T06:18:23Z

Dixidix: RGB-Justierung -- ~~~~

== RGB-Justierung -- [[Benutzer:Dixidix|Dixidix]] 08:18, 1. Apr. 2009 (CEST) ==

Zitat:
''ACHTUNG: Wird hier ein anderer Wert als "0" eingestellt, dann wird an den Composite-Ausgängen (sowohl am TV- als auch am VCR-SCART) kein Bildsignal mehr ausgegeben, d. h. eine Aufnahme des Videosignals durch einen an VCR-SCART angeschlossenen Videorekorder funktioniert nicht mehr und der Fernseher an TV-SCART zeigt kein Bild mehr, falls er das nur das Composite-Signal (und nicht das RGB-Signal) verwendet oder falls das SCART-Kabel nicht voll belegt ist.''
Ist das wirklich so, ist mir noch nie aufgefallen?

Bootlog

2009-03-10T19:02:46Z

Dixidix: Bootlogaktivierung für GUI hinzugefügt

[[Category:Register]]
__TOC__

=Allgemeines=
Das [[Bootlog]] (= serielles Log) wird benötigt, um z.B. Ausgaben über den Startvorgang oder allgemeine Ausgaben während des Betriebes der [[DBox2]]-Software analysieren zu können.

=Vorraussetzungen=
Um das [[Bootlog]] zu bekommen, benötigt man Folgendes:

* in der GUI muss die Logausgabe entsprechend aktiviert sein siehe z.B: [[Neutrino:Einstellungen:Treiber-_%26_Bootoptionen#EXPERT.21_Boot-Konsole|Neutrino-Einstellungen]]
* Terminal-Programm (z.B. Hyperterminal) oder [[DBox2]]-[[Bootmanager]] oder [[Minicom]] unter Linux
* [[Nullmodem|Null-Modemkabel]]

alternativ, wenn kein Nullmodemkabel verwendet wird:
* mit ''[[setconsole]]'' (über [[BusyBox]] aktiviert)

'''Hinweis'''
''[[Setconsole]] ist nicht in jedem [[Image]] enthalten.''

Wenn Ihr nicht wisst, was ein [[Nullmodem|Null-Modemkabel]] oder Terminal-Programm ist, solltet Ihr besser nicht versuchen eine [[DBox2]] mit [[Linux]] zu [[flashen]]. Wer trotzdem unerschrocken und lernwillig ist, möge [http://www.google.de Google] für weitere Informationen bemühen. Für die Nutzung des [[DBox2]]-[[Bootmanager]]s lest bitte die entsprechende Anleitung, welche im Readme des Bootmanagers zu finden sein sollte!

=Einstellungen=
* [[Nullmodem]]kabel mit [[DBox2]] und [[PC]] (Com1 od. Com2) verbinden

* Schnittstelle am [[PC]] entsprechend konfigurieren. Stellt die benutzte [[COM]]-Schnittstelle auf 9600 Baud, 8bit, no parity

* [[DBox2]] starten und gucken, ob eine Ausgabe im Terminalprogramm erfolgt. Wenn nein (oder nur unleserliche Zeichen), Schnittstelle auf 57600 Baud, 8 bit, no parity konfigurieren und [[DBox2]] wieder neu booten.

Im Terminal-Programm sollten eine lange Liste der von der [[DBox2]] durchgeführten Aktionen stehen. Dies ist das Bootlog...

Beispiel (extrem gekürzt):

debug: DDF: Calibrating delay loop... debug: DDF: 67.79 BogoMIPS
debug: BMon V1.2 mID 01
debug: feID dd gtxID 0b
debug: fpID 5a dsID 01-8b[....]
debug: HWrev 09 FPrev 0.81
debug: B/Ex/Fl(MB) 32/00/08
WATCHDOG reset enabled
dbox2:root> debug:
BOOTP/TFTP bootstrap loader (v0.3)
debug:
debug: Transmitting BOOTP request via broadcast
debug: Given up BOOTP/TFTP boot
boot net failed

Flash-FS bootstrap loader (v1.5)

[...]

Initializing...
CPU: PPC823ZTnnB2 at 67 MHz: 2 kB I-Cache 1 kB D-Cache
Board: ### No HW ID - assuming TQM8xxL
DRAM: (faked) 32 MB
Ethernet: .....
FLASH: 8 MB
LCD driver (KS0713) initialized
LCD logo at: 0x84A7E (0x1E00 bytes)
FB logo at: 0x868A6 (0x31C1 bytes)
AVIA Frambuffer
Input: serial
Output: serial

[...]

events are old 60min after their end time
[sectionsd ] checking timerd
[sectionsd ] timerd available
dmxdev: set buffer size 40000 -> 60000
$Id: zapit.cpp,v 1.163 2002/04/24 18:51:18 field Exp $

/var/tuxbox/config/zapit/zapit.conf: No such file or directory
[getservices.cpp] /var/tuxbox/config/zapit/services.xml: No such file or directory
[zapit] /var/tuxbox/config/zapit/bouquets.xml: No such file or directory
[zapit] channels have been loaded succesfully
Controld $Id: controld.cpp,v 1.57 2002/03/29 15:47:18 obi Exp $

[controld] Boxtype detected: (01, 1, 1, Nokia)
set event: 00000009
SWITCH LETTER BOX
[nhttpd] [[Neutrino]] HTTP-Server starting..

httpd gestartet
dmxdev: set buffer size 40000 -> 60000
NeutrinoNG $Id: neutrino.cpp,v 1.243 2002/04/24 13:06:58 field Exp $

[neutrino] frameBuffer Instance created
[...]

=Hinweis=
Bricht das [[Bootlog]] nach

Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 576993 Bytes = 563 kB = 0 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK

ab, dann startet die [[DBox2]] nochmal und drückt die "2" (auf der [[Fernbedienung]]) an dieser Stelle:

Options:
1: Console on null
2: Console on ttyS0
3: Console on framebuffer
Select (1-3), other keys to stop autoboot: 0

=Bootlog über Netzwerk=
Es besteht die Möglichkeit, über den Befehl ''[[setconsole]]'', ein Log über [[Telnet]] über das [[Netzwerk]] aufzuzeichnen. Vorraussetzung dafür ist, dass Dbox-Taste -> Einstellungen -> Treiber- und Bootoptionen -> Expert! Bootconsole auf seriell steht. Die Ausgaben über das Netzwerk sind unter Umständen nicht so ausführlich wie ein serielles Bootlog. Man sollte daher immer ein Bootlog über die serielle Schnittstelle vorziehen. Das erleichtert in der Regel immer die Suche nach Fehlern.

=Kernel-Log ausgeben=
Mit dem Befehl "dmesg" (alternativ mit "cat /proc/kmsg") kann man sich mittels [[Telnet]] den [[Kernel]]-Log ausgeben lassen. Auch hier sollte immer ein Bootlog über die serielle Schnittstelle vorgezogen werden. Die dmesg-Ausgaben sind bei weitem nicht so üppig wie es über die serielle Schnittstelle möglich wäre.

{{body}}

Neutrino:Senderlisten

2008-11-13T07:33:45Z

Dixidix:

[[Category:Register]]
[[Category:Neutrino]]
[[Category:Howto]]
__TOC__

=Allgemeines=
{{MissingText}}

=satellites.xml=
In dieser Datei sind die verschiedenen Satelliten und die Transponder beschrieben, die bei einem Sendersuchlauf abgescannt werden.

Um die Datei aktuell zu halten am besten öfter mal auf [http://www.lyngsat.com Lyngsat.com] nachsehen: [http://www.lyngsat.com/astra19.shtml Astra], [http://www.lyngsat.com/hotbird.shtml Eutelsat].

Damit man die Datei ersetzten kann, zunächst den symbolischen Link per telnet löschen: rm var/tuxbox/config/satellites.xml.
Danach an die selbe Stelle die eigene satellites.xml aufspielen (gilt ebenso für cables.xml).

<?xml version="1.0" encoding="UTF-8"?>
<satellites>
<sat name="Astra 19.2E" flags="9" position="192">
<transponder frequency="10876000" symbol_rate="22000000" polarization="1" fec_inner="4"/>
<transponder frequency="12187500" symbol_rate="27500000" polarization="0" fec_inner="3"/>
<transponder frequency="12551000" symbol_rate="22000000" polarization="1" fec_inner="4"/>
</sat>
<sat name="Eutelsat 13.0E" flags="5" position="130">
<transponder frequency="12692000" symbol_rate="27500000" polarization="0" fec_inner="3"/>
....
<transponder frequency="12539000" symbol_rate="27500000" polarization="0" fec_inner="3"/>
<transponder frequency="12111000" symbol_rate="27500000" polarization="1" fec_inner="3"/>
</sat>
</satellites>

{|width=800 style="background-color:white; font-size:small; margin:3px 3px 3px 10px"
|style="background-color:#8DB6CD; width: 150px;"|<satellites> </satellites>
|style="background-color:#B9D3EE;" valign="top"|Zwischen diesen beiden Tags befinden sich die Daten aller Satelliten
|-
|style="background-color:#8DB6CD;" valign="top"|<sat...> </sat>
|style="background-color:#B9D3EE;" valign="top"|Alles zwischen diesen beiden Tags bezieht sich auf den selben Satelliten
|-
|style="background-color:#8DB6CD;" valign="top"|name=“Astra 19.2E“
|style="background-color:#B9D3EE;" valign="top"|Name des Satelliten
|-
|style="background-color:#8DB6CD;" valign="top"|flags=“9“
|style="background-color:#B9D3EE;" valign="top"|1 = Network Scan
Bei der Netzwerksuche werden die Werte aus den Transpondern ausgewertet. In vielen Transpondern ist eine Liste mit weiteren Transpondern enthalten, so dass beim Suchlauf automatisch weitere Transponder mit einbezogen werden, wenn die satellites.xml nicht vollständig ist. Leider sind die Daten oft fehlerhaft, so dass es wichtig ist die satellites.xml immer auf den neuesten Stand zu halten.

2 = use BAT -- BAT=Bouquet Association Table.

Informationen im Datenstrom über die Zugehörigkeit von Programmpaketen zu einem bestimmten Bouquet.

4 = use ONIT -- NIT=Network Information Table.

In der Netzwerks-Informations-Tabelle im Datenstrom eines Satelliten sind Transponder angegeben, auf der weitere Sender zu finden sind. -> Kanalnummer und Frequenz.

8 = skip NITs of known networks -- NIT=Network Information Table.

In der Netzwerks-Informations-Tabelle im Datenstrom eines Transponders sind die Daten anderer Transponder angegeben, auf denen weitere Sender zu finden sind.

--> 9=8+1 Kombination aus verschiedenen Flags durch Addition der Werte möglich.
|-
|style="background-color:#8DB6CD;" valign="top"|position="192"
|style="background-color:#B9D3EE;" valign="top"|Position des Satelliten im Orbit -> 19,2°
|-
|style="background-color:#8DB6CD;" valign="top"|<transponder ...... />
|style="background-color:#B9D3EE;" valign="top"|Alles in dieser Zeile bezieht sich auf einen bestimmten Transponder
|-
|style="background-color:#8DB6CD;" valign="top"|frequency="10876000"
|style="background-color:#B9D3EE;" valign="top"|Transponderfrequenz des Satelliten 10,876 GHz
|-
|style="background-color:#8DB6CD;" valign="top"|symbol_rate="22000000"
|style="background-color:#B9D3EE;" valign="top"|Symbolrate 22000
|-
|style="background-color:#8DB6CD;" valign="top"|polarization="1"
|style="background-color:#B9D3EE;" valign="top"|Polarisation: 0=horizontal, 1=vertikal (2=linksdrehend, 3=rechtsdrehend)
|-
|style="background-color:#8DB6CD;" valign="top"|fec_inner="4"
|style="background-color:#B9D3EE;" valign="top"|FEC=Forward Error Correction:
Mit dem Nutzsignal werden zusätzliche Daten übertragen, mit deren Hilfe bei einer Übertragunsstörung das Nutzsignal rekonstruiert werden kann. Der Wert der FEC zeigt das Verhältnis zwischen Daten für Fehlerkorrektur zu den Daten des Nutzsignals an. Ein Wert von 5/6 bedeutet: 5 Bytes werden für die Datenübertragung benutzt und 1 Byte für die Fehlerkorrektur. Das bedeutet auch, das 1/6 der Bandbreite für die Fehlerkorrektur "verschwendet" wird. Bei einem Wert von 1/2 wird die Hälfte der Bandbreite zur Fehlerkorrektur verwendet.

Mit Hilfe der Symbolrate und der FEC kann man Datenrate errechnen:
Nettodatenrate = Symbolrate (2 * FEC) (188/204)

Beispiel: Symbolrate=27500, FEC=3/4

Nettodatenrate = 27500 (2 * 3/4) (188/204) = 38014,71 Mbps

Neues Format:
*FEC 1/2 => fec_inner=1
*FEC 2/3 => fec_inner=2
*FEC 3/4 => fec_inner=3
*FEC 4/5 => fec_inner=4
*FEC 5/6 => fec_inner=5
*FEC 6/7 => fec_inner=6
*FEC 7/8 => fec_inner=7
*FEC 8/9 => fec_inner=8
*AutoFEC => fec_inner=9

Früheres Format:
*FEC 1/2 => fec_inner=1
*FEC 2/3 => fec_inner=2
*FEC 3/4 => fec_inner=3
*FEC 5/6 => fec_inner=4
*FEC 7/8 => fec_inner=5

Hinweis: Bei meiner Box funktioniert das neue Format jedoch nicht (cramfs v. 18.02.03). Bei einem Sendersuchlauf wird die FEC, bei meiner Box, im alten Format in die services.xml geschrieben. Deshalb hab ich hier jetzt beide Möglichkeiten dargestellt.
|}

=cables.xml=
{{MissingText}}

=services.xml=
Senderliste. Die Datei Services.xml wird bei der Sendersuche automatisch angelegt. Hier werden die gefundenen Sender/Services zu den Transpondern zugeordnet abgelegt. Man kann diese Liste von Hand bearbeiten und erweitern, ohne dass ein Sendersuchlauf notwendig ist.
Die services.xml liegt im Verzeichnis /var/tuxbox/config/zapit.

<?xml version="1.0" encoding="iso-8859-1"?>
<zapit>
<sat name="Astra 19.2E" diseqc="0">
<transponder id="044d" onid="0001" frequency="11836500" inversion="2" symbol_rate="27500000" fec_inner="3" polarization="0">
<channel service_id="6dca" name="Das Erste" service_type="01"/>
<channel service_id="6dcb" name="Bayerisches FS" service_type="01"/>
<channel service_id="6dcc" name="hessen fernsehen" service_type="01"/>
<channel service_id="6dcd" name="arte" service_type="01"/>
<channel service_id="6dce" name="SR Fernsehen Suedwest" service_type="01"/>
<channel service_id="6dcf" name="WDR FERNSEHEN" service_type="01"/>
<channel service_id="6dd0" name="BR-alpha" service_type="01"/>
</transponder>
</sat>
</zapit>

{| width=800 style="background-color:white; font-size:small; margin:3px 3px 3px 10px"
|style="background-color:#8DB6CD; width: 160px;"|<zapit> </zapit>
|style="background-color:#B9D3EE;" valign="top"|Zwischen diesen beiden Tags befinden sich die Daten aller Satelliten
|-
|style="background-color:#8DB6CD;" valign="top"|<sat...> </sat>
|style="background-color:#B9D3EE;" valign="top"|Alles zwischen diesen beiden Tags bezieht sich auf den selben Satelliten
|-
|style="background-color:#8DB6CD;" valign="top"|name="Astra 19.2E"
|style="background-color:#B9D3EE;" valign="top"|Name des Satelliten
|-
|style="background-color:#8DB6CD;" valign="top"|diseqc="0"
|style="background-color:#B9D3EE;" valign="top"|[[DiSEqC]] = Digital Satellite Equipment Control. Ermöglicht das Anwählen verschiedener Satellitenpositionen mit Hilfe der Umschaltung durch digitale Impulse.
Dabei steht "0" für LNB 1 (Astra) u. "1" für LNB 2 (Eutelsat).

Zusammen mit dem Wert für diseqcType in der zapit.conf werden die DiSEqC-Einstellungen bestimmt. Die DiSEqC-Einstellungen in den Neutrino-Menüs gelten nur für den Sendersuchlauf und haben bei Änderungen keine Auswirkungen auf die bereits vorhandene Senderliste.

Wenn DiSEqC nicht funktioniert, liegt es häufig daran, dass der Wert für den diseqcType in der zapit.conf nicht stimmt. Dieser muss meistens auf "2" stehen, bei Astra/Hotbird-Anlagen meistens auf "3".

DisEqC diseqcType
*kein 0?
*Mini 1?
*1.0 2
*1.1 3?
|-
|style="background-color:#8DB6CD;" valign="top"|<transponder......> </transponder>
|style="background-color:#B9D3EE;" valign="top"|Alles zwischen diesem Bereich bezieht sich auf einen bestimmten Transponder
|-
|style="background-color:#8DB6CD;" valign="top"|Transponder_id="044d"
|style="background-color:#B9D3EE;" valign="top"|ID-Nummer des Transponders (TSID o. TID). Identifiziert einen Transponder/Multiplex innerhalb eines Netzwerks. Jede Transponder-ID existiert pro zugehöriger NID/ONID nur ein mal, kann jedoch pro Satellit öfter vorkommen.
Der Wert ist hexadezimal anzugeben: 044d (hex) = 1101 (dez)
In den Listen auf [http://www.lyngsat.com/ Lyngsat] oder [http://www.satcodx.com/ SatcoDX] werden die Werte als Dezimalwerte angegeben!!!!
|-
|style="background-color:#8DB6CD;" valign="top"|onid="0001"
|style="background-color:#B9D3EE;" valign="top"|OriginalNetworkIdentifikation (ONID, NID). Identifiziert einen Netzwerkprovider. Die Kombination von ONID und TID identifiziert einen Transponder/Multiplex eindeutig. Die ONID ist nicht die Bezeichnung des Satelliten.
Wert ist hexadezimal anzugeben: onid="0001" => 0x0001 (hex) = 0001 (dez)
Bei [http://www.lyngsat.com/ Lyngsat] werden NID und TID zusammen als Dezimalwerte angegeben: 1-1101

Beispiele:
*0x0001 Astra Satellite Network 19,2°E
*0x0035 Nethold Main Mux System
*0x0085 Beta Technik
*0x013e Eutelsat Satellite System 13°E
*0xF001 Deutsche Telekom
*0xfbff Stream Spa.
|-
|style="background-color:#8DB6CD;" valign="top"|frequency="11836500"
|style="background-color:#B9D3EE;" valign="top"|Transponderfrequenz des Satelliten 10,876 GHz
|-
|style="background-color:#8DB6CD;" valign="top"|inversion="2"
|style="background-color:#B9D3EE;" valign="top"|Wert nur für Kabelboxen erforderlich. Aus Kompatiblitätsgründen auch bei den SAT-Boxen vorhanden.
|-
|style="background-color:#8DB6CD;" valign="top"|symbol_rate="27500000"
|style="background-color:#B9D3EE;" valign="top"|Symbolrate 27500
|-
|style="background-color:#8DB6CD;" valign="top"|fec_inner="3"
|style="background-color:#B9D3EE;" valign="top"|FEC: 2=2/3, 3=3/4, 4=5/6, 5=7/8
|-
|style="background-color:#8DB6CD;" valign="top"|polarization="0" (bei Sat)
|style="background-color:#B9D3EE;" valign="top"|Polarisation: 0=horizontal, 1=vertikal
|-
|style="background-color:#8DB6CD;" valign="top"|modulation="6" (bei Kabel)
|style="background-color:#B9D3EE;" valign="top"|Polarisation: 3=QAM64, 5=QAM256, 6=Auto
|-
|style="background-color:#8DB6CD;" valign="top"|<channel ...... />
|style="background-color:#B9D3EE;" valign="top"|Alles in dieser Zeile bezieht sich auf einen bestimmten Sender
|-
|style="background-color:#8DB6CD;" valign="top"|service_id="6dca"
|style="background-color:#B9D3EE;" valign="top"|Die Service ID bzw. SID (Service Identifikation) ermöglicht die eindeutige Markierung eines einzelnen Video- und Audioprogrammes innerhalb eines Transponderdatentstroms. Durch die Service ID können Set-Top-Boxen jeweils das gewünschte Programm aus einem Bouquet konkret lokalisieren. Dabei kann ein Service auch aus Teilen verschiedener Programme bestehen, die zu bestimmten Zeitpunkten unter einer Service Identifikatin angeboten werden und praktisch ein neues Programmangebot bilden (z.B bei den Fensterprogrammen des NDR und MDR, bei denen die Fensterprogramme über 1Festival bzw. 1Muxx übertragen werden).
Jede SID existiert pro Transponder nur einmal. Der Wert ist hexadezimal anzugeben:
6dca (hex) = 28106 (dez)
|-
|style="background-color:#8DB6CD;" valign="top"|name="Das Erste"
|style="background-color:#B9D3EE;" valign="top"|Sendername
|-
|style="background-color:#8DB6CD;" valign="top"|service_type="01"
|style="background-color:#B9D3EE;" valign="top"|
Art des übertragenen Services:
*00=RESERVED
*01=DIGITAL_TELEVISION_SERVICE
*02=DIGITAL_RADIO_SOUND_SERVICE
*03=TELETEXT_SERVICE
*04=NVOD_REFERENCE_SERVICE (NVOD=Near Video On Demand)
*05=NVOD_TIME_SHIFTED_SERVICE
*06=MOSAIC_SERVICE
*07=PAL_CODED_SIGNAL
*08=SECAM_CODED_SIGNAL
*09=D_D2_MAC
*0a=FM_RADIO
*0b=NTSC_CODED_SIGNAL
*0c=DATA_BROADCAST_SERVICE
*0e=COMMON_INTERFACE_RESERVED
*0f=RCS_MAP
*10=RCS_FLS
*11=DVB_MHP_SERVICE

viele, viele weitere u.a.: 0c 80 81 82 aa ab=Download b1=ZDF Digitext b2=Data b3=Premiere Sport Interactive c1=Data c3=Kiosque c5 c6=Radios

Wenn man bei einem Radiosender statt einer "02" eine "01" einträgt, kann man mit dem Werbeblocker oder mit der Taste "0" zwischen dem TV-Programm und dem Radiosender wechseln. Bei dem so veränderten Radiosender wird dann kein Bildsignal übertragen, dadurch können sich evt angeschlossene Fernseher/Displays ausschalten!
|-
|style="background-color:#8DB6CD;" valign="top"|channel_nr="0"
|style="background-color:#B9D3EE;" valign="top"|???? mittlerweile entfallen
|}

=myservices.xml=
Sender, die den Sendern aus der services.xml zugefügt werden. Vorteil, die hier enthaltenen Sender werden durch keinen Suchlauf verändert. Man muss diese Liste von Hand bearbeiten und bei Änderungen entsprechend selbst anpassen. Das Format entspricht der [[Neutrino:Senderlisten#services.xml|services.xml]].

Folgende Aktionen werden von Myservices.xml unterstützt:

==Add==
Durch diese Aktion können Kanäle, die beim Suchlauf nicht gefunden werden (z.B. Premiere Subchannels), in die Kanalliste hinzugefügt werden.

==Replace==
Durch diese Aktion können Kanäle umbenannt werden. Z.B. "Das Erste" in "ARD".

==Remove==
Durch diese Aktion können unerwünschte Kanäle aus der Kanalliste entfernt werden.

Ein Beispiel:

<?xml version="1.0" encoding="UTF-8" ?>
<zapit>
<cable name="Kabelcom Rheinhessen">
<transponder id="0001" onid="0085" frequency="386000000" inversion="2" symbol_rate="6900000" fec_inner="0" modulation="3">
<channel action="add" name="Premiere Direkt d4" service_id="00d4" service_type="01" />
</transponder>
<transponder id="0003" onid="0085" frequency="362000000" inversion="2" symbol_rate="6900000" fec_inner="0" modulation="3">
<channel action="add" name="Premiere Direkt da" service_id="00da" service_type="01" />
<channel action="add" name="Premiere Direkt db" service_id="00db" service_type="01" />
<channel action="add" name="Premiere Direkt dc" service_id="00dc" service_type="01" />
<channel action="add" name="Premiere Direkt de" service_id="00de" service_type="01" />
<channel action="add" name="Premiere Direkt f0" service_id="00f0" service_type="01" />
<channel action="add" name="Premiere Direkt f1" service_id="00f1" service_type="01" />
<channel action="add" name="Premiere Direkt f2" service_id="00f2" service_type="01" />
<channel action="add" name="Premiere Direkt f3" service_id="00f3" service_type="01" />
<channel action="add" name="Premiere Direkt f4" service_id="00f4" service_type="01" />
<channel action="add" name="Premiere Direkt f5" service_id="00f5" service_type="01" />
</transponder>
<transponder id="0004" onid="0085" frequency="378000000" inversion="2" symbol_rate="6900000" fec_inner="0" modulation="3">
<channel action="add" name="Premiere Direkt d0" service_id="00d0" service_type="01" />
<channel action="add" name="Premiere Direkt d1" service_id="00d1" service_type="01" />
<channel action="add" name="Premiere Direkt d2" service_id="00d2" service_type="01" />
</transponder>
<transponder id="0011" onid="0085" frequency="354000000" inversion="2" symbol_rate="6900000" fec_inner="0" modulation="3">
<channel action="add" name="Premiere Direkt d3" service_id="00d3" service_type="01" />
<channel action="add" name="Premiere Direkt dd" service_id="00dd" service_type="01" />
</transponder>
<transponder id="0003" onid="0085" frequency="362000000" inversion="2" symbol_rate="6900000" fec_inner="0" modulation="3">
<channel action="replace" service_id="0011" name="Premiere Sportportal" service_type="01" />
</transponder>
<transponder id="2716" onid="f001" frequency="450000000" inversion="2" symbol_rate="6900000" fec_inner="0" modulation="3">
<channel action="remove" service_id="2261" name="FRANCE 2" service_type="01"/>
<channel action="remove" service_id="2262" name="FRANCE 3" service_type="01"/>
</transponder>
<transponder id="0445" onid="0001" frequency="12265500" inversion="2" symbol_rate="27500000" fec_inner="3" polarization="0">
<channel action="replace" service_id="6ef2" name="Bayern 3" service_type="01"/>
<channel action="replace" service_id="6ef6" name="DAS MODUL" service_type="01"/>
<channel action="replace" service_id="6f18" name="N-JOY" service_type="01"/>
<channel action="replace" service_id="6f05" name="hr3" service_type="01"/>
<channel action="replace" service_id="6f3b" name="Eins Live" service_type="01"/>
<channel action="replace" service_id="6f3c" name="WDR 2" service_type="01"/>
<channel action="replace" service_id="6f41" name="Eins Live diggi" service_type="01"/>
<channel action="replace" service_id="6f07" name="YOU FM" service_type="01"/>
</transponder>
</cable>
</zapit>

Das Beispiel zeigt nicht nur

- dass man Sender, Unterkanäle als Hauptkanäle eintragen kann,

- sondern auch dass die Radiosender die 01 für TV bekommen können und dann gehen sie als TV-Sender durch, mit schwarzem Bild.

Nicht besonders schön, aber der Werbetimer und die "0" als lezter Kanal funktioniert dann auch beim Radio-Sender.

=antiservices.xml=
{{Box_Achtung||Diese Funktion sollte nicht mehr verwendet werden, da das Entfernen von unerwünschten Kanälen jetzt durch myservices.xml erledigt wird!}}

Sender, die im laufenden Betrieb in der Senderliste aus der services.xml nicht angezeigt werden. Vorteil, die hier enthaltenen Sender werden durch keinen Suchlauf verändert. Man muss diese Liste von Hand bearbeiten und bei Änderungen entsprechend selbst anpassen. Das Format entspricht der [[Neutrino:Senderlisten#services.xml|services.xml]].

=epgfilter.xml=
{{review}}

Mit Hilfe dieser Datei lassen sich diverse EPG-Daten filtern.

==Blacklist==
In diesem Beispiel wird die Möglichkeit gezeigt, eine Blacklist für Sender zu erstellen, für die keine EPG-Daten verwendet werden sollen.

Format:
<filter serviceID="445d" name="ProSieben" tsid="0453" onid="0001" blacklist="1"/>

'''Hinweis:'''
''In diesem konkreten Fall handelt es sich mehr oder weniger um einen Workaround, da es beim derzeitigen Entwicklungsstand einige Probleme beim Verarbeiten der EPG-Daten gibt. Hierbei wird der [[sectionsd]] praktisch "schlafen gelegt" solange man auf diesen Sender geschaltet hat. Dies kann dann sinnvoll sein, falls ein Sender fehlerhafte Daten liefert und [[Neutrino]] dadurch evtl. nicht mehr bedienbar ist. Siehe auch [http://tuxbox-forum.dreambox-fan.de/forum/viewtopic.php?p=361261#p361261 hier]''

=bouquets.xml=
In der Datei bouquets.xml werden die einzelnen Sender einem bestimmten Bouquet zugeordnet. Dies erfolgt automatisch bei der Kanalsuche. Man kann dann auch eigene Bouquets erstellen und aus den anderen Bouquets Sender übernehmen.
Die bouquets.xml liegt im Verzeichnis /var/tuxbox/config/zapit.

Die Zuordnung der Sender erfolgt über onid und ServiceID zu der Senderliste in der Datei services.xml. Dabei entsteht das Problem, das es möglich ist, das serviceID und onid mehrfach vorhanden sind. So ist eine eindeutige Zuordnung nicht mehr möglich. Die Wahrscheinlichkeit wird höher, je größer die Anzahl der Sender in services.xml ist, insbesondere wenn mehr als eine Satellitenposition verfügbar ist.

Ein bestimmter Service (=Sender) wird gemäß ETSI (European Telecommunications Standards Institute) eindeutig über folgende Parameter identifiziert werden:

original_network_id/transport_stream_id/service_id.

<?xml version="1.0" encoding="UTF-8"?>
<ZAPIT>
<Bouquet name="Meine Favoriten" hidden="0" locked="0">
<channel serviceID="6dca" name="Das Erste" tsid="044d" onid="0001" sat_position="192"/>
<channel serviceID="6d66" name="ZDF" tsid="0437" onid="0001" sat_position="192"/>
<channel serviceID="6e96" name="WDR MÃ¼nster" tsid="04b1" onid="0001" sat_position="192"/>
<channel serviceID="2ee3" name="RTL Television" tsid="0441" onid="0001" sat_position="192"/>
<channel serviceID="002e" name="SAT.1" tsid="0021" onid="0085" sat_position="192"/>
<channel serviceID="2f1c" name="VOX" tsid="0441" onid="0001" sat_position="192"/>
<channel serviceID="0382" name="ProSieben" tsid="0021" onid="0085" sat_position="192"/>
<channel serviceID="0383" name="KABEL1" tsid="0021" onid="0085" sat_position="192"/>
<channel serviceID="6d67" name="3sat" tsid="0437" onid="0001" sat_position="192"/>
<channel serviceID="6dcd" name="arte" tsid="044d" onid="0001" sat_position="192"/>
<channel serviceID="c49f" name="Motors TV" tsid="0964" onid="0002" sat_position="282"/>
<channel serviceID="0384" name="DSF" tsid="0021" onid="0085" sat_position="192"/>
</Bouquet>
<Bouquet name="ARD" hidden="0" locked="0">
<channel serviceID="6e3a" name="ARD-Online-Kanal" onid="0001"/>
<channel serviceID="6e29" name="EinsExtra" onid="0001"/>
.......usw.
</Bouquet>
</ZAPIT>

{| valign=top width=800 style="background-color:white; font-size:small; margin:3px 3px 3px 10px"
|style="background-color:#8DB6CD; width: 150px;" valign="top"|encoding=
|style="background-color:#B9D3EE;" valign="top"|Zeichensatz, derzeit wird UTF-8 gesetzt.
Bei älteren Images wird encoding="iso-8859-1" benutzt.
|-
|style="background-color:#8DB6CD;" valign="top"|<zapit> </zapit>
|style="background-color:#B9D3EE;" valign="top"|Zwischen diesen beiden Tags befinden sich die Daten aller Bouquets
|-
|style="background-color:#8DB6CD;" valign="top"|<Bouquet...> </Bouquet>
|style="background-color:#B9D3EE;" valign="top"|Alles zwischen diesen beiden Tags bezieht sich auf ein bestimmtes Bouquet
|-
|style="background-color:#8DB6CD;" valign="top"|name="Meine Favoriten"
|style="background-color:#B9D3EE;" valign="top"|Bezeichnung des Bouquets
|-
|style="background-color:#8DB6CD;" valign="top"|hidden="0"
|style="background-color:#B9D3EE;" valign="top"|hidden (engl. für versteckt). Bei einem Wert von 1 wird das Bouquet versteckt und nicht angezeigt.
|-
|style="background-color:#8DB6CD;" valign="top"|locked="0"
|style="background-color:#B9D3EE;" valign="top"|locked (engl. für gesichert, verriegelt). Bei einem Wert von 1 erfolgt eine Pinabfrage, wenn man auf einen Sender innerhalb dieses Bouquets umschalten möchte.
|-
|style="background-color:#8DB6CD;" valign="top"|<channel ...... />
|style="background-color:#B9D3EE;" valign="top"|Alles in dieser Zeile bezieht sich auf einen bestimmten Sender
|-
|style="background-color:#8DB6CD;" valign="top"|serviceID="6dca"
|style="background-color:#B9D3EE;" valign="top"|Service Identifikation (SID). Identifiziert einen bestimmten Sender innerhalb eines Transponders.
Der Wert ist hexadezimal anzugeben: 6dca (hex) = 28106 (dez)
In den Listen auf [http://www.lyngsat.com/ Lyngsat] oder [http://www.satcodx.com/ SatcoDX] werden die Werte als Dezimalwerte angegeben!!!!
|-
|style="background-color:#8DB6CD;" valign="top"|name="Das Erste"
|style="background-color:#B9D3EE;" valign="top"|Sendername
|-
|style="background-color:#8DB6CD;" valign="top"|tsid="044d"
|style="background-color:#B9D3EE;" valign="top"|Transport Stream ID (TSID, TID). Identifiziert einen Transponder/Multiplex innerhalb eines Netzwerks. Jede Transponder-ID existiert pro zugehöriger NID/ONID nur ein mal, kann jedoch pro Satellit öfter vorkommen.
Der Wert ist hexadezimal anzugeben: 044d (hex) = 1101 (dez)
In den Listen auf [http://www.lyngsat.com/ Lyngsat] oder [http://www.satcodx.com/ SatcoDX] werden die Werte als Dezimalwerte angegeben!!!!
|-
|style="background-color:#8DB6CD;" valign="top"|Onid="0001"
|style="background-color:#B9D3EE;" valign="top"|OriginalNetworkIdentifikation (ONID, NID). Identifiziert ein Netzwerk bzw. einen Netzwerkprovider. Ist für alle Services eines Transponders gleich. Die gleiche ONID wird jedoch für diverse Transponder vergeben, so dass ein Service nur durch die Kombination von (T)SID und (O)NID eindeutig unterschieden werden kann.
Wert ist hexadezimal anzugeben: 0001 (hex) = 0001 (dez)
Bei [http://www.lyngsat.com/ Lyngsat] werden NID und TID zusammen als Dezimalwerte angegeben: 1-1101
|-
|style="background-color:#8DB6CD;" valign="top"|sat_position="192"
|style="background-color:#B9D3EE;" valign="top"|Position des Satelliten (entfällt bei Kabel-Empfang).
|}

=Beispiel für Datenübernahme von Lyngsat=
{{MissingBild}}
[[Bild:neutrino_senderlisten_lyngsat01.jpg]]

=Service Information: (DVB-Standard)=
{| valign=top width=800 style="background-color:white; font-size:small; margin:3px 3px 3px 10px"
|style="background-color:#8DB6CD; width: 50px;" valign="top"|PAT
|style="background-color:#B9D3EE;" valign="top"|Program Association Table. Data appearing in packets having PID code of zero that the MPEG decoder uses to determine which programs exist in a transport stream. PAT points to PMT, which in turn points to the video, audio and data content of each program.
|-
|style="background-color:#8DB6CD;" valign="top"|PMT
|style="background-color:#B9D3EE;" valign="top"|Program Map Table. The tables in PAT that point to video, audio and data content of a transport stream.
*0x01 ISO/IEC 11172 Video
*0x02 ITU-T Rec. H.262 | ISO/IEC 13818-2 Video or ISO/IEC 11172-2 constrained parameter video stream
*0x03 ISO/IEC 11172 Audio
*0x04 ISO/IEC 13818-3 Audio
*0x05 ITU-T Rec. H.222.0 | ISO/IEC 13818-1 private_sections, e.g. MHP Application signalling stream
*0x06 ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data, e.g. teletext or ac3
*0x0b ISO/IEC 13818-6 type B
*0x81 User Private (MTV)
*0x90 User Private (Premiere Mail, BD_DVB
*0xc0 User Private (Canal+)
*0xc1 User Private (Canal+)
*0xc6 User Private (Canal+)
|-
|style="background-color:#8DB6CD;" valign="top"|NIT
|style="background-color:#B9D3EE;" valign="top"|Network Information Table. Information in one transport stream that describes many transport streams
|-
|style="background-color:#8DB6CD;" valign="top"|NID
|style="background-color:#B9D3EE;" valign="top"|Network Identifikation. Netzwerk-ID oder Programm-Kennummer. Wert liegt zwischen 0 und 8191 (dez) bzw. 0000 und 1fff (hex).
|-
|style="background-color:#8DB6CD;" valign="top"|BAT
|style="background-color:#B9D3EE;" valign="top"|Bouquet Association Table. The BAT is an optional table vor DVB taht provides details of bouquets, which are collections of services marketed as a single produkt
|-
|style="background-color:#8DB6CD;" valign="top"|SDT
|style="background-color:#B9D3EE;" valign="top"|Service Description Table. Each service in a DVB transport stream can have a service descriptor and these descriptors are assembled into the service description table. a service may be television, radio or teletext. The service descriptor includes the name of the service provider.
|-
|style="background-color:#8DB6CD;" valign="top"|EIT
|style="background-color:#B9D3EE;" valign="top"|Event Information Table. EIT is an optional table for DVB which contains program names, start times, durations and so on.
|-
|style="background-color:#8DB6CD;" valign="top"|TDT
|style="background-color:#B9D3EE;" valign="top"|Time And Date Table. The TDT is an option that embeds a UTC time and date stamp in the transport stream.
|-
|style="background-color:#8DB6CD;" valign="top"|AIT
|style="background-color:#B9D3EE;" valign="top"|Application Information Table. AIT has to be transmitted either within or alongside an object carousel carrying MHP content. The AIT provides information to the decoder about the data services and the state of each MHP application.
|-
|style="background-color:#8DB6CD;" valign="top"|CAT
|style="background-color:#B9D3EE;" valign="top"|Conditional Access Table. Packets having PID codes of 1 and that contain information about the scrambling system.
|-
|style="background-color:#8DB6CD;" valign="top"|PID
|style="background-color:#B9D3EE;" valign="top"|Packet IDentifiers
|}

Satelliten verfügen über mehrere Transponder, die bei analoger Übertragung jeweils mit einem TV-Programm belegt sind. Bei digitaler Übertragung wird auf jedem Transponder ein sogenannter Multiplex übertragen.

Ein Multiplex enthält mehrere Services (Fernseh- bzw. Radioprogramme, aber auch Datendienste), die wiederum aus mehreren Komponenten (Video, Audio, eventuell auch mehrere davon für mehrsprachige Übertragung) bestehen. Außerdem sieht der DVB-Standard vor, dass man auch mehrere Services (von verschiedenen Multiplexen) zu einem Bouquet zusammenfassen kann. Ein Beispiel wäre ein Sportbouquet mit allen Sportprogrammanbietern.

=Links=
*[http://www.gerdschweizer.homepage.t-online.de Homepage] / *[http://www.gerdschweizer.homepage.t-online.de/faqsat.htm FAQ] von Gerd Schweizer

*[http://tuxbox-forum.dreambox-fan.de/forum/viewtopic.php?p=361261#p361261 Workaround für EPG-Blackliste]

{{review}}

{{body}}

Neutrino:Senderlisten

2008-11-13T07:19:58Z

Dixidix: Blacklist hinzugefügt

[[Category:Register]]
[[Category:Neutrino]]
[[Category:Howto]]
__TOC__
[[

=Allgemeines=
{{MissingText}}

]]
=satellites.xml=
In dieser Datei sind die verschiedenen Satelliten und die Transponder beschrieben, die bei einem Sendersuchlauf abgescannt werden.

Um die Datei aktuell zu halten am besten öfter mal auf [http://www.lyngsat.com Lyngsat.com] nachsehen: [http://www.lyngsat.com/astra19.shtml Astra], [http://www.lyngsat.com/hotbird.shtml Eutelsat].

Damit man die Datei ersetzten kann, zunächst den symbolischen Link per telnet löschen: rm var/tuxbox/config/satellites.xml.
Danach an die selbe Stelle die eigene satellites.xml aufspielen (gilt ebenso für cables.xml).

<?xml version="1.0" encoding="UTF-8"?>
<satellites>
<sat name="Astra 19.2E" flags="9" position="192">
<transponder frequency="10876000" symbol_rate="22000000" polarization="1" fec_inner="4"/>
<transponder frequency="12187500" symbol_rate="27500000" polarization="0" fec_inner="3"/>
<transponder frequency="12551000" symbol_rate="22000000" polarization="1" fec_inner="4"/>
</sat>
<sat name="Eutelsat 13.0E" flags="5" position="130">
<transponder frequency="12692000" symbol_rate="27500000" polarization="0" fec_inner="3"/>
....
<transponder frequency="12539000" symbol_rate="27500000" polarization="0" fec_inner="3"/>
<transponder frequency="12111000" symbol_rate="27500000" polarization="1" fec_inner="3"/>
</sat>
</satellites>

{|width=800 style="background-color:white; font-size:small; margin:3px 3px 3px 10px"
|style="background-color:#8DB6CD; width: 150px;"|<satellites> </satellites>
|style="background-color:#B9D3EE;" valign="top"|Zwischen diesen beiden Tags befinden sich die Daten aller Satelliten
|-
|style="background-color:#8DB6CD;" valign="top"|<sat...> </sat>
|style="background-color:#B9D3EE;" valign="top"|Alles zwischen diesen beiden Tags bezieht sich auf den selben Satelliten
|-
|style="background-color:#8DB6CD;" valign="top"|name=“Astra 19.2E“
|style="background-color:#B9D3EE;" valign="top"|Name des Satelliten
|-
|style="background-color:#8DB6CD;" valign="top"|flags=“9“
|style="background-color:#B9D3EE;" valign="top"|1 = Network Scan
Bei der Netzwerksuche werden die Werte aus den Transpondern ausgewertet. In vielen Transpondern ist eine Liste mit weiteren Transpondern enthalten, so dass beim Suchlauf automatisch weitere Transponder mit einbezogen werden, wenn die satellites.xml nicht vollständig ist. Leider sind die Daten oft fehlerhaft, so dass es wichtig ist die satellites.xml immer auf den neuesten Stand zu halten.

2 = use BAT -- BAT=Bouquet Association Table.

Informationen im Datenstrom über die Zugehörigkeit von Programmpaketen zu einem bestimmten Bouquet.

4 = use ONIT -- NIT=Network Information Table.

In der Netzwerks-Informations-Tabelle im Datenstrom eines Satelliten sind Transponder angegeben, auf der weitere Sender zu finden sind. -> Kanalnummer und Frequenz.

8 = skip NITs of known networks -- NIT=Network Information Table.

In der Netzwerks-Informations-Tabelle im Datenstrom eines Transponders sind die Daten anderer Transponder angegeben, auf denen weitere Sender zu finden sind.

--> 9=8+1 Kombination aus verschiedenen Flags durch Addition der Werte möglich.
|-
|style="background-color:#8DB6CD;" valign="top"|position="192"
|style="background-color:#B9D3EE;" valign="top"|Position des Satelliten im Orbit -> 19,2°
|-
|style="background-color:#8DB6CD;" valign="top"|<transponder ...... />
|style="background-color:#B9D3EE;" valign="top"|Alles in dieser Zeile bezieht sich auf einen bestimmten Transponder
|-
|style="background-color:#8DB6CD;" valign="top"|frequency="10876000"
|style="background-color:#B9D3EE;" valign="top"|Transponderfrequenz des Satelliten 10,876 GHz
|-
|style="background-color:#8DB6CD;" valign="top"|symbol_rate="22000000"
|style="background-color:#B9D3EE;" valign="top"|Symbolrate 22000
|-
|style="background-color:#8DB6CD;" valign="top"|polarization="1"
|style="background-color:#B9D3EE;" valign="top"|Polarisation: 0=horizontal, 1=vertikal (2=linksdrehend, 3=rechtsdrehend)
|-
|style="background-color:#8DB6CD;" valign="top"|fec_inner="4"
|style="background-color:#B9D3EE;" valign="top"|FEC=Forward Error Correction:
Mit dem Nutzsignal werden zusätzliche Daten übertragen, mit deren Hilfe bei einer Übertragunsstörung das Nutzsignal rekonstruiert werden kann. Der Wert der FEC zeigt das Verhältnis zwischen Daten für Fehlerkorrektur zu den Daten des Nutzsignals an. Ein Wert von 5/6 bedeutet: 5 Bytes werden für die Datenübertragung benutzt und 1 Byte für die Fehlerkorrektur. Das bedeutet auch, das 1/6 der Bandbreite für die Fehlerkorrektur "verschwendet" wird. Bei einem Wert von 1/2 wird die Hälfte der Bandbreite zur Fehlerkorrektur verwendet.

Mit Hilfe der Symbolrate und der FEC kann man Datenrate errechnen:
Nettodatenrate = Symbolrate (2 * FEC) (188/204)

Beispiel: Symbolrate=27500, FEC=3/4

Nettodatenrate = 27500 (2 * 3/4) (188/204) = 38014,71 Mbps

Neues Format:
*FEC 1/2 => fec_inner=1
*FEC 2/3 => fec_inner=2
*FEC 3/4 => fec_inner=3
*FEC 4/5 => fec_inner=4
*FEC 5/6 => fec_inner=5
*FEC 6/7 => fec_inner=6
*FEC 7/8 => fec_inner=7
*FEC 8/9 => fec_inner=8
*AutoFEC => fec_inner=9

Früheres Format:
*FEC 1/2 => fec_inner=1
*FEC 2/3 => fec_inner=2
*FEC 3/4 => fec_inner=3
*FEC 5/6 => fec_inner=4
*FEC 7/8 => fec_inner=5

Hinweis: Bei meiner Box funktioniert das neue Format jedoch nicht (cramfs v. 18.02.03). Bei einem Sendersuchlauf wird die FEC, bei meiner Box, im alten Format in die services.xml geschrieben. Deshalb hab ich hier jetzt beide Möglichkeiten dargestellt.
|}

=cables.xml=
{{MissingText}}

=services.xml=
Senderliste. Die Datei Services.xml wird bei der Sendersuche automatisch angelegt. Hier werden die gefundenen Sender/Services zu den Transpondern zugeordnet abgelegt. Man kann diese Liste von Hand bearbeiten und erweitern, ohne dass ein Sendersuchlauf notwendig ist.
Die services.xml liegt im Verzeichnis /var/tuxbox/config/zapit.

<?xml version="1.0" encoding="iso-8859-1"?>
<zapit>
<sat name="Astra 19.2E" diseqc="0">
<transponder id="044d" onid="0001" frequency="11836500" inversion="2" symbol_rate="27500000" fec_inner="3" polarization="0">
<channel service_id="6dca" name="Das Erste" service_type="01"/>
<channel service_id="6dcb" name="Bayerisches FS" service_type="01"/>
<channel service_id="6dcc" name="hessen fernsehen" service_type="01"/>
<channel service_id="6dcd" name="arte" service_type="01"/>
<channel service_id="6dce" name="SR Fernsehen Suedwest" service_type="01"/>
<channel service_id="6dcf" name="WDR FERNSEHEN" service_type="01"/>
<channel service_id="6dd0" name="BR-alpha" service_type="01"/>
</transponder>
</sat>
</zapit>

{| width=800 style="background-color:white; font-size:small; margin:3px 3px 3px 10px"
|style="background-color:#8DB6CD; width: 160px;"|<zapit> </zapit>
|style="background-color:#B9D3EE;" valign="top"|Zwischen diesen beiden Tags befinden sich die Daten aller Satelliten
|-
|style="background-color:#8DB6CD;" valign="top"|<sat...> </sat>
|style="background-color:#B9D3EE;" valign="top"|Alles zwischen diesen beiden Tags bezieht sich auf den selben Satelliten
|-
|style="background-color:#8DB6CD;" valign="top"|name="Astra 19.2E"
|style="background-color:#B9D3EE;" valign="top"|Name des Satelliten
|-
|style="background-color:#8DB6CD;" valign="top"|diseqc="0"
|style="background-color:#B9D3EE;" valign="top"|[[DiSEqC]] = Digital Satellite Equipment Control. Ermöglicht das Anwählen verschiedener Satellitenpositionen mit Hilfe der Umschaltung durch digitale Impulse.
Dabei steht "0" für LNB 1 (Astra) u. "1" für LNB 2 (Eutelsat).

Zusammen mit dem Wert für diseqcType in der zapit.conf werden die DiSEqC-Einstellungen bestimmt. Die DiSEqC-Einstellungen in den Neutrino-Menüs gelten nur für den Sendersuchlauf und haben bei Änderungen keine Auswirkungen auf die bereits vorhandene Senderliste.

Wenn DiSEqC nicht funktioniert, liegt es häufig daran, dass der Wert für den diseqcType in der zapit.conf nicht stimmt. Dieser muss meistens auf "2" stehen, bei Astra/Hotbird-Anlagen meistens auf "3".

DisEqC diseqcType
*kein 0?
*Mini 1?
*1.0 2
*1.1 3?
|-
|style="background-color:#8DB6CD;" valign="top"|<transponder......> </transponder>
|style="background-color:#B9D3EE;" valign="top"|Alles zwischen diesem Bereich bezieht sich auf einen bestimmten Transponder
|-
|style="background-color:#8DB6CD;" valign="top"|Transponder_id="044d"
|style="background-color:#B9D3EE;" valign="top"|ID-Nummer des Transponders (TSID o. TID). Identifiziert einen Transponder/Multiplex innerhalb eines Netzwerks. Jede Transponder-ID existiert pro zugehöriger NID/ONID nur ein mal, kann jedoch pro Satellit öfter vorkommen.
Der Wert ist hexadezimal anzugeben: 044d (hex) = 1101 (dez)
In den Listen auf [http://www.lyngsat.com/ Lyngsat] oder [http://www.satcodx.com/ SatcoDX] werden die Werte als Dezimalwerte angegeben!!!!
|-
|style="background-color:#8DB6CD;" valign="top"|onid="0001"
|style="background-color:#B9D3EE;" valign="top"|OriginalNetworkIdentifikation (ONID, NID). Identifiziert einen Netzwerkprovider. Die Kombination von ONID und TID identifiziert einen Transponder/Multiplex eindeutig. Die ONID ist nicht die Bezeichnung des Satelliten.
Wert ist hexadezimal anzugeben: onid="0001" => 0x0001 (hex) = 0001 (dez)
Bei [http://www.lyngsat.com/ Lyngsat] werden NID und TID zusammen als Dezimalwerte angegeben: 1-1101

Beispiele:
*0x0001 Astra Satellite Network 19,2°E
*0x0035 Nethold Main Mux System
*0x0085 Beta Technik
*0x013e Eutelsat Satellite System 13°E
*0xF001 Deutsche Telekom
*0xfbff Stream Spa.
|-
|style="background-color:#8DB6CD;" valign="top"|frequency="11836500"
|style="background-color:#B9D3EE;" valign="top"|Transponderfrequenz des Satelliten 10,876 GHz
|-
|style="background-color:#8DB6CD;" valign="top"|inversion="2"
|style="background-color:#B9D3EE;" valign="top"|Wert nur für Kabelboxen erforderlich. Aus Kompatiblitätsgründen auch bei den SAT-Boxen vorhanden.
|-
|style="background-color:#8DB6CD;" valign="top"|symbol_rate="27500000"
|style="background-color:#B9D3EE;" valign="top"|Symbolrate 27500
|-
|style="background-color:#8DB6CD;" valign="top"|fec_inner="3"
|style="background-color:#B9D3EE;" valign="top"|FEC: 2=2/3, 3=3/4, 4=5/6, 5=7/8
|-
|style="background-color:#8DB6CD;" valign="top"|polarization="0" (bei Sat)
|style="background-color:#B9D3EE;" valign="top"|Polarisation: 0=horizontal, 1=vertikal
|-
|style="background-color:#8DB6CD;" valign="top"|modulation="6" (bei Kabel)
|style="background-color:#B9D3EE;" valign="top"|Polarisation: 3=QAM64, 5=QAM256, 6=Auto
|-
|style="background-color:#8DB6CD;" valign="top"|<channel ...... />
|style="background-color:#B9D3EE;" valign="top"|Alles in dieser Zeile bezieht sich auf einen bestimmten Sender
|-
|style="background-color:#8DB6CD;" valign="top"|service_id="6dca"
|style="background-color:#B9D3EE;" valign="top"|Die Service ID bzw. SID (Service Identifikation) ermöglicht die eindeutige Markierung eines einzelnen Video- und Audioprogrammes innerhalb eines Transponderdatentstroms. Durch die Service ID können Set-Top-Boxen jeweils das gewünschte Programm aus einem Bouquet konkret lokalisieren. Dabei kann ein Service auch aus Teilen verschiedener Programme bestehen, die zu bestimmten Zeitpunkten unter einer Service Identifikatin angeboten werden und praktisch ein neues Programmangebot bilden (z.B bei den Fensterprogrammen des NDR und MDR, bei denen die Fensterprogramme über 1Festival bzw. 1Muxx übertragen werden).
Jede SID existiert pro Transponder nur einmal. Der Wert ist hexadezimal anzugeben:
6dca (hex) = 28106 (dez)
|-
|style="background-color:#8DB6CD;" valign="top"|name="Das Erste"
|style="background-color:#B9D3EE;" valign="top"|Sendername
|-
|style="background-color:#8DB6CD;" valign="top"|service_type="01"
|style="background-color:#B9D3EE;" valign="top"|
Art des übertragenen Services:
*00=RESERVED
*01=DIGITAL_TELEVISION_SERVICE
*02=DIGITAL_RADIO_SOUND_SERVICE
*03=TELETEXT_SERVICE
*04=NVOD_REFERENCE_SERVICE (NVOD=Near Video On Demand)
*05=NVOD_TIME_SHIFTED_SERVICE
*06=MOSAIC_SERVICE
*07=PAL_CODED_SIGNAL
*08=SECAM_CODED_SIGNAL
*09=D_D2_MAC
*0a=FM_RADIO
*0b=NTSC_CODED_SIGNAL
*0c=DATA_BROADCAST_SERVICE
*0e=COMMON_INTERFACE_RESERVED
*0f=RCS_MAP
*10=RCS_FLS
*11=DVB_MHP_SERVICE

viele, viele weitere u.a.: 0c 80 81 82 aa ab=Download b1=ZDF Digitext b2=Data b3=Premiere Sport Interactive c1=Data c3=Kiosque c5 c6=Radios

Wenn man bei einem Radiosender statt einer "02" eine "01" einträgt, kann man mit dem Werbeblocker oder mit der Taste "0" zwischen dem TV-Programm und dem Radiosender wechseln. Bei dem so veränderten Radiosender wird dann kein Bildsignal übertragen, dadurch können sich evt angeschlossene Fernseher/Displays ausschalten!
|-
|style="background-color:#8DB6CD;" valign="top"|channel_nr="0"
|style="background-color:#B9D3EE;" valign="top"|???? mittlerweile entfallen
|}

=myservices.xml=
Sender, die den Sendern aus der services.xml zugefügt werden. Vorteil, die hier enthaltenen Sender werden durch keinen Suchlauf verändert. Man muss diese Liste von Hand bearbeiten und bei Änderungen entsprechend selbst anpassen. Das Format entspricht der [[Neutrino:Senderlisten#services.xml|services.xml]].

Folgende Aktionen werden von Myservices.xml unterstützt:

==Add==
Durch diese Aktion können Kanäle, die beim Suchlauf nicht gefunden werden (z.B. Premiere Subchannels), in die Kanalliste hinzugefügt werden.

==Replace==
Durch diese Aktion können Kanäle umbenannt werden. Z.B. "Das Erste" in "ARD".

==Remove==
Durch diese Aktion können unerwünschte Kanäle aus der Kanalliste entfernt werden.

Ein Beispiel:

<?xml version="1.0" encoding="UTF-8" ?>
<zapit>
<cable name="Kabelcom Rheinhessen">
<transponder id="0001" onid="0085" frequency="386000000" inversion="2" symbol_rate="6900000" fec_inner="0" modulation="3">
<channel action="add" name="Premiere Direkt d4" service_id="00d4" service_type="01" />
</transponder>
<transponder id="0003" onid="0085" frequency="362000000" inversion="2" symbol_rate="6900000" fec_inner="0" modulation="3">
<channel action="add" name="Premiere Direkt da" service_id="00da" service_type="01" />
<channel action="add" name="Premiere Direkt db" service_id="00db" service_type="01" />
<channel action="add" name="Premiere Direkt dc" service_id="00dc" service_type="01" />
<channel action="add" name="Premiere Direkt de" service_id="00de" service_type="01" />
<channel action="add" name="Premiere Direkt f0" service_id="00f0" service_type="01" />
<channel action="add" name="Premiere Direkt f1" service_id="00f1" service_type="01" />
<channel action="add" name="Premiere Direkt f2" service_id="00f2" service_type="01" />
<channel action="add" name="Premiere Direkt f3" service_id="00f3" service_type="01" />
<channel action="add" name="Premiere Direkt f4" service_id="00f4" service_type="01" />
<channel action="add" name="Premiere Direkt f5" service_id="00f5" service_type="01" />
</transponder>
<transponder id="0004" onid="0085" frequency="378000000" inversion="2" symbol_rate="6900000" fec_inner="0" modulation="3">
<channel action="add" name="Premiere Direkt d0" service_id="00d0" service_type="01" />
<channel action="add" name="Premiere Direkt d1" service_id="00d1" service_type="01" />
<channel action="add" name="Premiere Direkt d2" service_id="00d2" service_type="01" />
</transponder>
<transponder id="0011" onid="0085" frequency="354000000" inversion="2" symbol_rate="6900000" fec_inner="0" modulation="3">
<channel action="add" name="Premiere Direkt d3" service_id="00d3" service_type="01" />
<channel action="add" name="Premiere Direkt dd" service_id="00dd" service_type="01" />
</transponder>
<transponder id="0003" onid="0085" frequency="362000000" inversion="2" symbol_rate="6900000" fec_inner="0" modulation="3">
<channel action="replace" service_id="0011" name="Premiere Sportportal" service_type="01" />
</transponder>
<transponder id="2716" onid="f001" frequency="450000000" inversion="2" symbol_rate="6900000" fec_inner="0" modulation="3">
<channel action="remove" service_id="2261" name="FRANCE 2" service_type="01"/>
<channel action="remove" service_id="2262" name="FRANCE 3" service_type="01"/>
</transponder>
<transponder id="0445" onid="0001" frequency="12265500" inversion="2" symbol_rate="27500000" fec_inner="3" polarization="0">
<channel action="replace" service_id="6ef2" name="Bayern 3" service_type="01"/>
<channel action="replace" service_id="6ef6" name="DAS MODUL" service_type="01"/>
<channel action="replace" service_id="6f18" name="N-JOY" service_type="01"/>
<channel action="replace" service_id="6f05" name="hr3" service_type="01"/>
<channel action="replace" service_id="6f3b" name="Eins Live" service_type="01"/>
<channel action="replace" service_id="6f3c" name="WDR 2" service_type="01"/>
<channel action="replace" service_id="6f41" name="Eins Live diggi" service_type="01"/>
<channel action="replace" service_id="6f07" name="YOU FM" service_type="01"/>
</transponder>
</cable>
</zapit>

Das Beispiel zeigt nicht nur

- dass man Sender, Unterkanäle als Hauptkanäle eintragen kann,

- sondern auch dass die Radiosender die 01 für TV bekommen können und dann gehen sie als TV-Sender durch, mit schwarzem Bild.

Nicht besonders schön, aber der Werbetimer und die "0" als lezter Kanal funktioniert dann auch beim Radio-Sender.

=antiservices.xml=
{{Box_Achtung||Diese Funktion sollte nicht mehr verwendet werden, da das Entfernen von unerwünschten Kanälen jetzt durch myservices.xml erledigt wird!}}

Sender, die im laufenden Betrieb in der Senderliste aus der services.xml nicht angezeigt werden. Vorteil, die hier enthaltenen Sender werden durch keinen Suchlauf verändert. Man muss diese Liste von Hand bearbeiten und bei Änderungen entsprechend selbst anpassen. Das Format entspricht der [[Neutrino:Senderlisten#services.xml|services.xml]].

=epgfilter.xml=
{{review}}

Mit Hilfe dieser Datei lassen sich diverse EPG-Daten filtern.

==Blacklist==
In diesem Beispiel wird die Möglichkeit gezeigt, eine Blacklist für Sender zu erstellen, für die keine EPG-Daten verwendet werden sollen.

Format:
<filter serviceID="445d" name="ProSieben" tsid="0453" onid="0001" blacklist="1"/>

'''Hinweis:'''
''In diesem konkreten Fall handelt es sich mehr oder weniger um einen Workaround, da es beim derzeitigen Entwicklungsstand einige Probleme beim Verarbeiten der EPG-Daten gibt. Hierbei wird der [[sectionsd]] praktisch "schlafen gelegt" solange man auf diesen Sender geschaltet hat. Dies kann dann sinnvoll sein, falls ein Sender fehlerhafte Daten liefert und [[Neutrino]] dadurch evtl. nicht mehr bedienbar ist. Siehe auch [http://tuxbox-forum.dreambox-fan.de/forum/viewtopic.php?p=361261#p361261 hier]''

=bouquets.xml=
In der Datei bouquets.xml werden die einzelnen Sender einem bestimmten Bouquet zugeordnet. Dies erfolgt automatisch bei der Kanalsuche. Man kann dann auch eigene Bouquets erstellen und aus den anderen Bouquets Sender übernehmen.
Die bouquets.xml liegt im Verzeichnis /var/tuxbox/config/zapit.

Die Zuordnung der Sender erfolgt über onid und ServiceID zu der Senderliste in der Datei services.xml. Dabei entsteht das Problem, das es möglich ist, das serviceID und onid mehrfach vorhanden sind. So ist eine eindeutige Zuordnung nicht mehr möglich. Die Wahrscheinlichkeit wird höher, je größer die Anzahl der Sender in services.xml ist, insbesondere wenn mehr als eine Satellitenposition verfügbar ist.

Ein bestimmter Service (=Sender) wird gemäß ETSI (European Telecommunications Standards Institute) eindeutig über folgende Parameter identifiziert werden:

original_network_id/transport_stream_id/service_id.

<?xml version="1.0" encoding="UTF-8"?>
<ZAPIT>
<Bouquet name="Meine Favoriten" hidden="0" locked="0">
<channel serviceID="6dca" name="Das Erste" tsid="044d" onid="0001" sat_position="192"/>
<channel serviceID="6d66" name="ZDF" tsid="0437" onid="0001" sat_position="192"/>
<channel serviceID="6e96" name="WDR MÃ¼nster" tsid="04b1" onid="0001" sat_position="192"/>
<channel serviceID="2ee3" name="RTL Television" tsid="0441" onid="0001" sat_position="192"/>
<channel serviceID="002e" name="SAT.1" tsid="0021" onid="0085" sat_position="192"/>
<channel serviceID="2f1c" name="VOX" tsid="0441" onid="0001" sat_position="192"/>
<channel serviceID="0382" name="ProSieben" tsid="0021" onid="0085" sat_position="192"/>
<channel serviceID="0383" name="KABEL1" tsid="0021" onid="0085" sat_position="192"/>
<channel serviceID="6d67" name="3sat" tsid="0437" onid="0001" sat_position="192"/>
<channel serviceID="6dcd" name="arte" tsid="044d" onid="0001" sat_position="192"/>
<channel serviceID="c49f" name="Motors TV" tsid="0964" onid="0002" sat_position="282"/>
<channel serviceID="0384" name="DSF" tsid="0021" onid="0085" sat_position="192"/>
</Bouquet>
<Bouquet name="ARD" hidden="0" locked="0">
<channel serviceID="6e3a" name="ARD-Online-Kanal" onid="0001"/>
<channel serviceID="6e29" name="EinsExtra" onid="0001"/>
.......usw.
</Bouquet>
</ZAPIT>

{| valign=top width=800 style="background-color:white; font-size:small; margin:3px 3px 3px 10px"
|style="background-color:#8DB6CD; width: 150px;" valign="top"|encoding=
|style="background-color:#B9D3EE;" valign="top"|Zeichensatz, derzeit wird UTF-8 gesetzt.
Bei älteren Images wird encoding="iso-8859-1" benutzt.
|-
|style="background-color:#8DB6CD;" valign="top"|<zapit> </zapit>
|style="background-color:#B9D3EE;" valign="top"|Zwischen diesen beiden Tags befinden sich die Daten aller Bouquets
|-
|style="background-color:#8DB6CD;" valign="top"|<Bouquet...> </Bouquet>
|style="background-color:#B9D3EE;" valign="top"|Alles zwischen diesen beiden Tags bezieht sich auf ein bestimmtes Bouquet
|-
|style="background-color:#8DB6CD;" valign="top"|name="Meine Favoriten"
|style="background-color:#B9D3EE;" valign="top"|Bezeichnung des Bouquets
|-
|style="background-color:#8DB6CD;" valign="top"|hidden="0"
|style="background-color:#B9D3EE;" valign="top"|hidden (engl. für versteckt). Bei einem Wert von 1 wird das Bouquet versteckt und nicht angezeigt.
|-
|style="background-color:#8DB6CD;" valign="top"|locked="0"
|style="background-color:#B9D3EE;" valign="top"|locked (engl. für gesichert, verriegelt). Bei einem Wert von 1 erfolgt eine Pinabfrage, wenn man auf einen Sender innerhalb dieses Bouquets umschalten möchte.
|-
|style="background-color:#8DB6CD;" valign="top"|<channel ...... />
|style="background-color:#B9D3EE;" valign="top"|Alles in dieser Zeile bezieht sich auf einen bestimmten Sender
|-
|style="background-color:#8DB6CD;" valign="top"|serviceID="6dca"
|style="background-color:#B9D3EE;" valign="top"|Service Identifikation (SID). Identifiziert einen bestimmten Sender innerhalb eines Transponders.
Der Wert ist hexadezimal anzugeben: 6dca (hex) = 28106 (dez)
In den Listen auf [http://www.lyngsat.com/ Lyngsat] oder [http://www.satcodx.com/ SatcoDX] werden die Werte als Dezimalwerte angegeben!!!!
|-
|style="background-color:#8DB6CD;" valign="top"|name="Das Erste"
|style="background-color:#B9D3EE;" valign="top"|Sendername
|-
|style="background-color:#8DB6CD;" valign="top"|tsid="044d"
|style="background-color:#B9D3EE;" valign="top"|Transport Stream ID (TSID, TID). Identifiziert einen Transponder/Multiplex innerhalb eines Netzwerks. Jede Transponder-ID existiert pro zugehöriger NID/ONID nur ein mal, kann jedoch pro Satellit öfter vorkommen.
Der Wert ist hexadezimal anzugeben: 044d (hex) = 1101 (dez)
In den Listen auf [http://www.lyngsat.com/ Lyngsat] oder [http://www.satcodx.com/ SatcoDX] werden die Werte als Dezimalwerte angegeben!!!!
|-
|style="background-color:#8DB6CD;" valign="top"|Onid="0001"
|style="background-color:#B9D3EE;" valign="top"|OriginalNetworkIdentifikation (ONID, NID). Identifiziert ein Netzwerk bzw. einen Netzwerkprovider. Ist für alle Services eines Transponders gleich. Die gleiche ONID wird jedoch für diverse Transponder vergeben, so dass ein Service nur durch die Kombination von (T)SID und (O)NID eindeutig unterschieden werden kann.
Wert ist hexadezimal anzugeben: 0001 (hex) = 0001 (dez)
Bei [http://www.lyngsat.com/ Lyngsat] werden NID und TID zusammen als Dezimalwerte angegeben: 1-1101
|-
|style="background-color:#8DB6CD;" valign="top"|sat_position="192"
|style="background-color:#B9D3EE;" valign="top"|Position des Satelliten (entfällt bei Kabel-Empfang).
|}

=Beispiel für Datenübernahme von Lyngsat=
{{MissingBild}}
[[Bild:neutrino_senderlisten_lyngsat01.jpg]]

=Service Information: (DVB-Standard)=
{| valign=top width=800 style="background-color:white; font-size:small; margin:3px 3px 3px 10px"
|style="background-color:#8DB6CD; width: 50px;" valign="top"|PAT
|style="background-color:#B9D3EE;" valign="top"|Program Association Table. Data appearing in packets having PID code of zero that the MPEG decoder uses to determine which programs exist in a transport stream. PAT points to PMT, which in turn points to the video, audio and data content of each program.
|-
|style="background-color:#8DB6CD;" valign="top"|PMT
|style="background-color:#B9D3EE;" valign="top"|Program Map Table. The tables in PAT that point to video, audio and data content of a transport stream.
*0x01 ISO/IEC 11172 Video
*0x02 ITU-T Rec. H.262 | ISO/IEC 13818-2 Video or ISO/IEC 11172-2 constrained parameter video stream
*0x03 ISO/IEC 11172 Audio
*0x04 ISO/IEC 13818-3 Audio
*0x05 ITU-T Rec. H.222.0 | ISO/IEC 13818-1 private_sections, e.g. MHP Application signalling stream
*0x06 ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data, e.g. teletext or ac3
*0x0b ISO/IEC 13818-6 type B
*0x81 User Private (MTV)
*0x90 User Private (Premiere Mail, BD_DVB
*0xc0 User Private (Canal+)
*0xc1 User Private (Canal+)
*0xc6 User Private (Canal+)
|-
|style="background-color:#8DB6CD;" valign="top"|NIT
|style="background-color:#B9D3EE;" valign="top"|Network Information Table. Information in one transport stream that describes many transport streams
|-
|style="background-color:#8DB6CD;" valign="top"|NID
|style="background-color:#B9D3EE;" valign="top"|Network Identifikation. Netzwerk-ID oder Programm-Kennummer. Wert liegt zwischen 0 und 8191 (dez) bzw. 0000 und 1fff (hex).
|-
|style="background-color:#8DB6CD;" valign="top"|BAT
|style="background-color:#B9D3EE;" valign="top"|Bouquet Association Table. The BAT is an optional table vor DVB taht provides details of bouquets, which are collections of services marketed as a single produkt
|-
|style="background-color:#8DB6CD;" valign="top"|SDT
|style="background-color:#B9D3EE;" valign="top"|Service Description Table. Each service in a DVB transport stream can have a service descriptor and these descriptors are assembled into the service description table. a service may be television, radio or teletext. The service descriptor includes the name of the service provider.
|-
|style="background-color:#8DB6CD;" valign="top"|EIT
|style="background-color:#B9D3EE;" valign="top"|Event Information Table. EIT is an optional table for DVB which contains program names, start times, durations and so on.
|-
|style="background-color:#8DB6CD;" valign="top"|TDT
|style="background-color:#B9D3EE;" valign="top"|Time And Date Table. The TDT is an option that embeds a UTC time and date stamp in the transport stream.
|-
|style="background-color:#8DB6CD;" valign="top"|AIT
|style="background-color:#B9D3EE;" valign="top"|Application Information Table. AIT has to be transmitted either within or alongside an object carousel carrying MHP content. The AIT provides information to the decoder about the data services and the state of each MHP application.
|-
|style="background-color:#8DB6CD;" valign="top"|CAT
|style="background-color:#B9D3EE;" valign="top"|Conditional Access Table. Packets having PID codes of 1 and that contain information about the scrambling system.
|-
|style="background-color:#8DB6CD;" valign="top"|PID
|style="background-color:#B9D3EE;" valign="top"|Packet IDentifiers
|}

Satelliten verfügen über mehrere Transponder, die bei analoger Übertragung jeweils mit einem TV-Programm belegt sind. Bei digitaler Übertragung wird auf jedem Transponder ein sogenannter Multiplex übertragen.

Ein Multiplex enthält mehrere Services (Fernseh- bzw. Radioprogramme, aber auch Datendienste), die wiederum aus mehreren Komponenten (Video, Audio, eventuell auch mehrere davon für mehrsprachige Übertragung) bestehen. Außerdem sieht der DVB-Standard vor, dass man auch mehrere Services (von verschiedenen Multiplexen) zu einem Bouquet zusammenfassen kann. Ein Beispiel wäre ein Sportbouquet mit allen Sportprogrammanbietern.

=Links=
*[http://www.gerdschweizer.homepage.t-online.de Homepage] / *[http://www.gerdschweizer.homepage.t-online.de/faqsat.htm FAQ] von Gerd Schweizer

*[http://tuxbox-forum.dreambox-fan.de/forum/viewtopic.php?p=361261#p361261 Workaround für EPG-Blackliste]

{{review}}

{{body}}

EPG

2008-11-11T14:07:02Z

Dixidix:

[[Category:Register]]
{{Infos}}

*[[wikipedia:EPG]]
*[[sectionsd]]
*[[Neutrino:Senderlisten#epgfilter.xml|EPG-Filter]]
{{body}}

Senderlogos

2008-11-11T14:02:35Z

Dixidix: Weiterleitung nach Neutrino:Customizing#Senderlogos erstellt

#REDIRECT [[Neutrino:Customizing#Senderlogos|Senderlogos]]

MMC-Karte

2008-11-02T17:30:47Z

Dixidix: Weiterleitung nach SD-Karte erstellt

#REDIRECT [[SD-Karte]]

Mirco-SD-Karte

2008-11-02T17:30:37Z

Dixidix: Weiterleitung nach SD-Karte erstellt

#REDIRECT [[SD-Karte]]

Mini-SD-Karte

2008-11-02T17:30:27Z

Dixidix: redirect sd-karte

#REDIRECT [[SD-Karte]]

SD-Karte

2008-11-02T17:27:45Z

Dixidix: SD-Karte verlinkt

[[Category:Register]]
{{Infos}}

*[[Wikipedia:SD-Karte]]

{{body}}

Hardware:dbox2:Erweiterungen:IDE-Interface

2008-11-02T17:17:48Z

Dixidix: SD-Karte vorgemerkt

[[Category:Register]]
[[Category:Hardware]]
__TOC__

=Allgemeines=

'''Stand 22.7.2006'''

Dieses Projekt verfolgt zurzeit ebenfalls die Realisierung einer [[IDE]]-Schnittstelle, jedoch mittels eines [[CPLD]] (Complex Programmable Logic Device). Dies hat u.a. den Vorteil, gegenüber der Lösung mit diskretem Schaltungsaufbau, dass die Schaltung selbst "übersichtlich" ist, da nur wenige Komponenten auf dem eigentlichen [[IDE]]-Modul bzw. auf der Platine aufgebracht werden müssen.

Des Weiteren gestattet die Programmierung des [[CPLD]] einen flexibleren Funktionsumfang, da davon ausgegangen wird, dass alle Anschlüsse des Speichermodul-Steckplatz der [[DBox2]] an das [[CPLD]] angeschlossen werden. Änderungen und Erweiterungen können allein durch eine geeignete Programmierung vorgenommen werden, ein nachträglicher Eingriff in den Schaltungsaufbau ist daher nicht nötig.

Das [[CPLD]] wird wie bereits erwähnt -analog zur ersten [[IDE]]-Variante- an den Speichermodul-Steckplatz der [[DBox2]] und dem Modemstecker angeschlossen. Außerdem muss natürlich an einer geeigneten Stelle noch die Betriebsspannung für das [[IDE]]-Modul abgegriffen werden.

Aus [[CPU]] Sicht wird das [[CPLD]] wie das normale [[RAM]] angesprochen, d.h. via UPM (User Programmable Machine). Dabei werden die Daten in den Adressraum für die erweiterten 32MB Hauptspeicher eingeblendet.

Die Grund-Idee für einen Zugriff war "Write before Read". Die [[CPU]] muss dem Chip vor einem [[IDE]]-Register Lesezugriff sagen, dass der Chip das jetzt mal bitte machen soll, zum Beispiel per Schreibzugriff auf eine bestimmte Adresse.
Der zweite Zugriff liefert dann die gelesenen Daten. Performance gibt's trotzdem, weil der zweite Lesezugriff wieder den nächsten [[IDE]]-Zugriff auslösen kann (durch die Wahl der Adresse) usw.
Und ganz nebenbei können so zur [[CPU]] auch gleich 32 Bit transportiert werden, weil der Chip gleich 2 [[IDE]]-Lesezugriffe durchführt.

Die Software Xilinx ISE 7.1i zur Programmierung des [[CPLD]] ist frei erhältlich.

Da Nokia, Phillips und Sagem unterschiedliche Speichermodul-Steckplätze verwenden war die Entwicklung von drei verschiedenen Platinenlayouts notwendig. Die Layouts und die Software sind mittlerweile fertig gestellt. Die fertigbestückte Platine wird von Hallenberg.com vertrieben und kann für 50 Euro + Versand vorbestellt werden. Mit dabei sind ein Einbaurahmen für 2,5"- und 3,5"-Festplatten, ein IDE-Kabel, ein Kabel zum Modemport sowie ein Netzteil als Spannungsversorgung für die Festplatte. Die Veröffentlichung und der Beginn des Versands sind auf den 1.August 2006 festgesetzt.

An einer Anpassung des [[Kernel]]s usw. wird ebenfalls noch gearbeitet.

=FAQ=
==Rund um das Interface==
'''Wird das IDE-Interface Timeshift beherrschen?''' 
Eine Timeshift-Funktion ist bis jetzt nicht vorgesehen. Aber eventuell werden sich ja ein paar Entwickler auf dieses Themengebiet stürzen.

'''Können wir User die Firmware updaten?''' 
Im Prinzip ja.
Es gab den Vorschlag, das direkt in der Box über Pins vom Modemport zu machen.
Ob dies bei den einzelnen Layouts vorgesehen ist, ist noch nicht bekannt.

Dieses Verfahren birgt allerdings ein Risiko: Da der CPLD direkt am Prozessorbus hängt, kann eine falsche Firmware dazu führen das die Box sich aufhängt und nicht einmal mehr bootet. Die Platine kann man dann immernoch updaten, muss sie aber aus dem Connector ziehen und irgendwie mit Strom (3.3V) versorgen. Am Modem-Connector ist aber auch dafür alles vorhanden.

Alternative ist ein relativ einfaches Kabel am Parallelport eines PCs. Die 3.3V können dann aus der Box kommen, und ob die sich nach dem Update aufhängt oder nicht ist dann ja egal. Sollte sich die Box aufhängen spielt man einfach das alte Image wieder auf den Chip.

'''Wo bekomme ich ein Kabel her um den CPLD zu programmieren?''' 
Hier ist der Schaltplan um sich ein Kabel für den Parallel-Port bauen zu können.
[http://toolbox.xilinx.com/docsan/3_1i/data/common/jtg/dppb/appb.htm] [http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=3418]

'''Wird es eine Variante des IDE-Interfaces mit Speichereweiterung geben?''' 
Eher unwahrscheinlich. Der Grund ist das man sich aus Timinggründen keinen Multiplexer am RAM leisten kann.

'''Auf der Platine sind noch acht unbestückte Lötpads. Wozu dienen diese?''' 
Diese Lötpads sind für eine RealTimeClock bestimmt. Sie können mit einem DS1307Z (SMD), ein Standarduhrenquarz und ein Knopfzellenhalter (KZH-1) bestückt werden.

==Imageprobleme==

'''Wann werden die Sourcen veröffentlicht?''' 
Die Sourcen werden veröffentlicht, sobald das Interface verfügbar ist. Die Sourcen kommen ins CVS, sodass man sich sein eigenes Image mit HDD-Unterstützung bauen kann.

'''Wird es möglich sein Images mit HDD-Unterstützung und ohne HDD-Unterstützung zu bauen? Oder haben die Images dann standardmäßig HDD-Unterstützung?''' 
Default ändert sich nichts, man muss nur die IDE-Patches zusätzlich aktivieren. Man verwende hierfür die [[Vorlage:Newmake_Build_Optionen|configure-Option]]:

--enable-ide

'''Hinweis!''' 
''Im gegenwärtigen CVS-Stand wird das in einigen [[Images]] verwendete HDD-Menü nicht eingebaut. Hierfür ist ein spezieller Patch notwendig, der sicher irgendwann im CVS zu finden sein wird.''

'''Nehmen die Erweiterungen die für das IDE Interface benötigt werden viel Platz im Image weg?''' 
Das Image wächst um ungefähr 300 kB.

==Rund um die HD==
'''Kann ich die Energie für die Platte vom internen Netzteil beziehen?''' 
Die Leistungsreserven des dboxinternen Netzteils sind begrenzt. Ein Betrieb einer 2,5"-Platte ist mit Hilfe einer kleinen Schaltung (Schaltregler) an der 27 V- Spannungsversorgung für die Displaybeleuchtung und das LNB möglich. Für 3,5"-Platten muss ein externes Netzteil verwendet werden.

Hier die Schaltung: [http://foto.arcor-online.net/palb/alben/16/849616/1280_3237636664653165.jpg] [http://foto.arcor-online.net/palb/alben/89/689889/1280_3466343933633531.jpg] [http://foto.arcor-online.net/palb/alben/89/689889/1280_3065633939363232.jpg] [http://foto.arcor-online.net/palb/alben/89/689889/1280_6466393530653565.jpg]

'''Ich habe eine Kabelbox. Kann ich trotzdem obige Schaltung verwenden oder haben die Kabelboxen keine 27 V-Spannung?''' 
Alle Boxen haben diese 27 V-Spannung, auch Kabelboxen.

'''Kann ich eine SATA-Platte an das IDE-Interface anschließen? /'''
'''Wird es eine SATA-Version dieses IDE-Interfaces geben?''' 
Der Einsatz einer SATA-Platte an diesem Interface ist noch nicht getestet worden.
Laut DBoxBear sollte es aber theoretisch möglich sein eine SATA-Platte mit Hilfe eines PATA-SATA-Adapters zu betreiben. DboxBear wird laut Posting keine Schaltung für SATA entwickeln.

'''Wird die Festplatte bei Nichtbenutzung in den Standby geschickt?''' 
Die Festplatte wird nach 5 Minuten in Standby geschickt. Dieser Wert ist mit hdparm frei zu definieren.

'''Wird es HD-Tools geben?''' 
Im aktuell in Entwicklung befindlichen Yadi und JtG-Image sind bereits Tools zum Partitionieren und Formatieren der Festplatte sowie die benötigten Treiber enthalten.

'''Welches IDE-Kabel soll ich verwenden?''' 
Bitte benutze ein 80-poliges IDE-Kabel. Die zusätzlichen Masseleitungen helfen die Signale vor Störeinflüssen zu schützen.

'''Gibt es eine Kapazitätsgrenze für die Festplatte?''' 
Da Linux LBA48 unterstützt und den Treiber/Chip das nicht interessiert:
Alles was es an IDE Platten gibt. (zur Zeit 500GB?)
Und davon bis zu zwei Stück -> 1TB

'''Wieviel Platten kann ich anschließen?''' 
Zwei. Eine Master- und eine Slave-Platte

'''In welchem Modus wird die Platte laufen?''' 
PIO-Mode 4 (max. 16 MByte/s)

'''Wie hoch wird die Datenübertragungsrate sein?''' 
Die Platte erreicht zur Zeit zwischen 2 und 4 MByte/s. Das ist mehr als das
10 MBit-LAN der DBox zu leisten vermag.
Das ist mehr als genug um ZDF mit allen Audiokanälen ohne Unterbrechungen aufzuzeichnen.

'''Was ist der Unterschied zwischen Mbit/s und MByte/s?''' 
8 Bit entsprechen 1 Byte. 10 MBit/s entsprechen unter realen Bedingungen etwas weniger als 1 MByte/s.

'''Welches Format wird die Partition auf der Festplatte haben?''' 
Die Festplatte wird in ext3 formatiert. Es gibt aber Tools um ext2/3 unter Windows lesen und schreiben zu können. [http://www.fs-driver.org/]

==MultiCam / MC das unbekannte Wesen?==

'''Wofür dient das Kabel zum Modemport?''' 
Über den Modemport bezieht das IDE-Interface seinen Interrupt. Das Kabel ist für die Funktion unbedingt notwendig.

'''Funktioniert das IDE-Interface auch mit einem MultiCam?''' 
Der parallele Einsatz von einem MultiCam und vom IDE-Interface ist von den Entwicklern nicht vorgesehen.

'''Warum berücksichtigen die Entwickler keine MultiCams''' 
Vom Projekt wird das nicht unterstützt, da auch andere Crypt-Verfahren möglich sind/wären, für die die dbox2 keine Lizenz mitbringt.

'''Hinweis!'''

{{cam_note}}

=Schaltungen=
==Hallenberg.com==
Das IDE-Interface von Hallenberg kann [http://www.Hallenberg.com hier] bezogen werden.

'''Produkteigenschaften:'''
* 40poliger IDE-Anschluß für 3,5" Festplatten oder 2,5" Festplatten (Adapter 40<>44polig erforderlich)
* Erweiterung mit einer RealTimeClock (RTC) möglich (als Option bestellbar)
* Netzteil (extern) 5V-2A (Spitzenlast) extern für die Versorgung von zwei Festplatten 2,5" oder 3,5“ und Lüftern
* 5V-Anschluss über Modemport für 2,5“-Festplatten (optional mit Anschlusskabel bestellbar)
* LED-Anschluss für die Festplattenaktivität
* Lötpunkt für alternativen IRQ 6
* Unterstützt Compactflash-Karten über IDE-Adapter
* Freie und nicht belegte IO-Pins vom XC95144XL für zukünftige Applikationen.

===IDE-Interface Nokia===
====Version 1====
[[Bild:IDE Nokia.jpg|400px|Bild1: Nokia IDE-Interface von Hallenberg.com]]

====Version 2====
[[Bild:IDE Hallenberg nokia r2 a.jpg|400px|Bild1: Nokia IDE-Interface von Hallenberg.com]]
[[Bild:IDE Hallenberg nokia r2 b.jpg|400px|Bild2: Nokia IDE-Interface von Hallenberg.com]]

===IDE-Interface Sagem===
[[Bild:IDE Hallenberg Sagem.jpg|400px|Bild1: Nokia IDE-Interface von Hallenberg.com]]

===IDE-Interface Philips===
[[Bild:IDE Philips.jpg|400px|Bild1: Philips IDE-Interface von Hallenberg.com]]

==Dbox2.com (IDE-Interface)==
Das IDE-Interface von Dbox2.com kann [http://www.Dbox2.com hier] bezogen werden.

'''Produkteigenschaften:'''
* 40poliger IDE-Anschluß für 3,5" Festplatten oder 2,5" Festplatten (Adapter 40<>44polig erforderlich)
* SD-/MMC-Kartenleser / Lesen und Schreiben auf [[SD-Karte]], [[Mini-SD-Karte]], [[Mirco-SD-Karte]] oder [[MMC-Karte]]
* Vorbereitet für RTC (Realtimeclock) / Echtzeituhr für die DBox2.
* Netzteil 5V - 2A (Spitzenlast) onboard für die Versorgung von zwei 2,5" Festplatten und der RTC
* 5V-Anschluss über Modemport für 2,5“-Festplatten
* 3x zusätzlich Anschlüsse für Lüfter (5V)
* LED für HDD-Aktivität onboard / Der Anschluss einer externen LED ist auch möglich.
* Lötpunkt oder Jumper für alternativen IRQ 6
* Unterstützt Compactflash-Karten über Adapter
* Freie und nicht belegte IO-Pins vom XC95144XL für zukünftige Applikationen.

===IDE-Interface Nokia===
[[Bild:IDE_DBOX2-COM Nokia1.jpg|400px|Bild1: Nokia IDE-Interface von Dbox2.com]]
[[Bild:IDE_DBOX2-COM_Nokia2.jpg|300px|Bild2: Nokia IDE-Interface von Dbox2.com]]

===IDE-Interface Sagem===
[[Bild:IDE_DBOX2-COM_Sagem1.jpg|400px|Bild1: Sagem IDE-Interface von Dbox2.com]]

===IDE-Interface Philips===
[[Bild:IDE_DBOX2-COM_Philips1.jpg|400px|Bild1: Philips-IDE Interface von Dbox2.com]]
[[Bild:IDE_DBOX2-COM_Philips2.jpg|400px|Bild2: Philips-IDE Interface von Dbox2.com]]

==Dbox2.com (IDE-SATA-Interface)==
Das IDE-SATA-Interface von Dbox2.com kann [http://www.Dbox2.com hier] bezogen werden.

'''Produkteigenschaften:'''
* 40poliger IDE-Anschluß für 3,5" Festplatten oder 2,5" Festplatten (Adapter 40<>44polig erforderlich)
* 7poliger SATA-Anschluß für 3,5" Festplatten oder 2,5" Festplatten
* MircoSD-Kartenleser / Lesen und Schreiben auf [[Mirco-SD-Karte]]
* Vorbereitet für RTC (Realtimeclock) / Echtzeituhr für die DBox2.
* Netzteil 5V - 2A (Spitzenlast) onboard für die Versorgung von zwei 2,5" Festplatten und der RTC
* 5V-Anschluss über Modemport für 2,5“-Festplatten
* 3x zusätzlich Anschlüsse für Lüfter (5V)
* LED für HDD-Aktivität onboard / Der Anschluss einer externen LED ist auch möglich.
* Lötpunkt oder Jumper für alternativen IRQ 6
* Unterstützt Compactflash-Karten über Adapter
* Freie und nicht belegte IO-Pins vom XC95144XL für zukünftige Applikationen.

===IDE-SATA-Interface Nokia===
[[Bild:IDE_SATA_DBOX2-COM Nokia3.jpg|400px|Bild1: Nokia IDE-SATA-Interface von Dbox2.com]]
[[Bild:IDE_SATA_DBOX2-COM_Nokia4.jpg|300px|Bild2: Nokia IDE-SATA-Interface von Dbox2.com]]

===IDE-SATA-Interface Sagem===
[[Bild:IDE_SATA_DBOX2-COM_Sagem2.jpg|400px|Bild1: Sagem IDE-SATA-Interface von Dbox2.com]]

===IDE-SATA-Interface Philips===
[[Bild:IDE_SATA_DBOX2-COM_Philips3.jpg|400px|Bild1: Philips-SATA-IDE Interface von Dbox2.com]]
[[Bild:IDE_SATA_DBOX2-COM_Philips4.jpg|300px|Bild2: Philips-SATA-IDE Interface von Dbox2.com]]

=Alternative IRQ´s=

==Nokia==
Der Pin14 muss abgeloetet oder die Leiterbahn unterbrochen werden, ansonsten kann es zu Problemen kommen wenn man die serielle Schnittstelle verwendet!

[[Bild:IRQ6 Nokia1.jpg|400px|Bild1: IRQ6 Nokia]] 
[[Bild:IRQ6 Nokia2.jpg|400px|Bild2: IRQ6 Nokia]] 
[[Bild:IRQ6 Nokia3.jpg|400px|Bild3: IRQ6 Nokia]] 
[[Bild:IRQ6 Nokia4.jpg|400px|Bild4: IRQ6 Nokia]] 

==Sagem==
Der Pin15 muss abgeloetet oder die Leiterbahn unterbrochen werden, ansonsten kann es zu Problemen kommen wenn man die serielle Schnittstelle verwendet!

[[Bild:IRQ6_Sagem1.jpg|400px|Bild1: IRQ6 Sagem]] 
[[Bild:IRQ6_Sagem2.jpg|400px|Bild2: IRQ6 Sagem]] 
[[Bild:IRQ6_Sagem3.jpg|400px|Bild3: IRQ6 Sagem]] 
[[Bild:IRQ6_Sagem4.jpg|400px|Bild4: IRQ6 Sagem]] 

==Philips==
[[Bild:IRQ6_Philips1.jpg|400px|Bild1: IRQ6 Philips]] 
[[Bild:IRQ6_Philips2.jpg|400px|Bild2: IRQ6 Philips]] 

=Schaltregler=
Ein Schaltregler ermöglicht den Betrieb von 2,5" Festplatten ohne zusätliches Netzteil. Die hierzu benötigte Spannung wird vom internen Netzteil der [[dbox2]] abgegriffen und auf 5Volt gewandelt. 
[[Bild:Schaltregler Platine.jpg|400px]] 

==Nokia==
[[Bild:Spannung Schaltregler Nokia1.jpg|400px|Spannung (27Volt/GND/Schaltspannung) Nokia]] 

==Sagem==
[[Bild:Spannung Schaltregler Sagem1.jpg|400px|Spannung (27Volt/GND/Schaltspannung) Sagem(Netzteil braun)]] 
[[Bild:Spannung Schaltregler Sagem2.jpg|400px|Spannung (27Volt/GND/Schaltspannung) Sagem(Netzteil weiss)]] 

==Philips==
[[Bild:Spannung Schaltregler Philips1.jpg|400px|Spannung (22Volt/GND) Philips]] 
[[Bild:Spannung Schaltregler Philips2.jpg|400px|Einschaltspannung (3,3Volt) Philips]] 

=Downloads=
* [[Download:IDE-CPLD-Sourcen.zip|CPLD-Sourcen für das IDE-Interface]]
* [[Download:DBoxNokiaIDE.zip|Eagle-Schaltbilder des Prototypen von DBoxBaer]]

=Links=
* [http://www.dboxservice-hallenberg.de/ Hallenberg.com Vertrieb]
* [http://www.dbox2.com/ Dbox2.com Vertrieb]
* [http://tuxbox-forum.mine.nu/forum/viewtopic.php?t=39462 Detailinfos zum Projekt im Tuxbox-Forum]
* [http://www.xilinx.com/ise/logic_design_prod/webpack.htm Softwaredownload für die Entwicklungsumgebung]
www.digchip.com/datasheets/parts/datasheet/534/XC95144XL-5.php CPLD-Spezifikation

{{review}}

{{body}}

Neutrino:Customizing

2008-11-02T16:59:00Z

Dixidix: Pfad zu Senderlogos ergänzt

[[Category:Register]]
[[Category:Neutrino]]
[[Category:Howto]]
{{Howto_sidebar}}
__TOC__

=Allgemeines=
Unter [[Neutrino]] gibt es einige Möglichkeiten die Benutzeroberfläche ([[GUI]]) nach seinen eigenen Wünschen anzupassen und da [[Neutrino]] nach dem Client-Server Prinzip funktioniert, lässt sich [[Neutrino]] über einige Befehle mittels [[API]] auch ohne [[GUI]] in gewissem Umfang bedienen. Desweiteren besteht auch die Möglichkeit, einzelne Ereignisse wie z.B. Aufnahmestop, Bildformatumschaltung etc. abzufangen und diese bei Bedarf mittels [[WP:Unix-Shell|Shell-]][[WP:Bash|Script]] für bestimmte zusätzliche Funktionen zu nutzen. Es wäre auch möglich, ein eigenes Webinterface zu benutzen.

=Benutzeroberfläche anpassen=
==Alternative Sprachen (custom locale)==
Die [[locale]] ist eine Datei, welche für die Ausgabe der Sprache auf der [[GUI]] verantwortlich ist. Eigene oder geänderte locales können bei [[squashFS]] [[Images]] im /var Verzeichnis gespeichert werden:

format: UTF-8 encoded
directory: /var/tuxbox/config/locale or /share/tuxbox/neutrino/locale
filenames: *.locale

Die Sprache kann nach Neustart unter [[Neutrino:Einstellungen:Sprache|Einstellungen:Sprache]] ausgewählt werden

==Plugins hinzufügen/entfernen==
Eigene [[Plugins]] können gespeichert werden unter:

directory: /var/tuxbox/plugins or /lib/tuxbox/plugins
Disabling plugin X (X.cfg, X.so) available in /lib/tuxbox/plugins: touch /var/tuxbox/plugins/X.cfg

==eigene Icons==
Für alle Icons, also Symbole, die in den Menüs und Fenstern zu sehen sind, können ersatzweise eigene Icons verwendet werden. Es werden dafür entsprechende Dateien im Raw-Format benötigt. Auch die Größe sollte man dabei beachten, damit es zu keinen unschönen Abbildungen in den jeweiligen Fenstern kommt.
Mgck hat auch ein kleines Programm ([http://tuxbox-forum.dreambox-fan.de/forum/viewtopic.php?f=27&t=45435 RawIconEditor] )zum editieren solcher Icons geschrieben, womit man relativ einfach solche Icons bearbeiten kann.
Die entsprechenden Icons werden hier abgelegt:

var/share/tuxbox/neutrino/icons/

==eigene Radiomode-, Shutdown- und Scanbilder==
Ebenso wie Icons lassen sich auch die Hintergrundbilder austauschen. Dies erfolgt auf die gleiche Weise wie bei eigenen Icons. Der Unterschied ist nur, dass auch die dazugehörigen .pal-Dateien nicht vergessen werden dürfen. Diese Hintergrundbilder sind relativ groß und schlucken einiges vom ohnehin knappen Speicherplatz in der Box. Man sollte daher eigentlich davon absehen diese Logos zu tauschen, aber wenn man es dennoch haben möchte, sei hier der Hinweis angebracht, dass das Risiko, sein Image "platzen" zu lassen ungemein größer wird. Alternativ besteht auch die Möglichkeit Symlinks auf die Dateien zu setzen. Diese können dann auf ein Ausgelagertes Verzeichnis zeigen, welche sich z.B. auf MMC oder HDD befinden.

==Senderlogos==
ab CVS-Stand 17.07.2008

Im Infobar besteht die Möglichkeit, Senderlogos einzublenden. Es werden dafür entsprechende Dateien vom gleichen Raw-Format wie Icons benötigt und werden standardmäßig im gleichen Ordner wie die alternativen Icons abgelegt.
/var/share/tuxbox/neutrino/icons/
Der Speicherort ist entsprechend den eigenen Bedürfnissen anpassbar. Zu berücksichtigen ist auch das bei [[jffs2]]-Images kein ''/var'' Ordner vorhanden ist. Hier muss das Verzeichnis entweder entsprechend ohne das ''/var'' in den Infobareinstellungen geändert werden.
/share/tuxbox/neutrino/icons/
oder man legt gleich einen anderen Pfad an.
Empfehlenswert ist auch, eine Auslagerung auf ein [[SD-Medium]], sofern man ein entsprechendes [[IDE-Interface]] nutzen kann

Je nachdem wo man die Logos angezeigt haben möchte, ist auch die Größe der Grafikdateien variabel. Erfahrungsgemäß sind Logos mit der Größe 120x34px zu empfehlen, damit sie optisch am besten eingepasst werden können. Sollte es Probleme bei der Größe geben, wird dies auch im Bootlog entsprechend angezeigt. Die Position der Logos lässt sich im Menü
'''''Diverse Einstellungen>Infobar>Anzeige''''' einstellen.

Es besteht auch die Möglichkeit den Hintergrund der Logos gerahmt oder schattiert darzustellen. Dies kann unter Umständen bei bestimmten Themes sinnvoll sein.
*[[Bild:infobar_channellogo_gerahmt.png|300px]]
*[[Bild:infobar_channellogo_schattiert.png|300px]]

Die Darstellung der Logos lässt sich im Menü
'''''Diverse Einstellungen>Infobar>Hintergrund''''' einstellen.

*[[Bild:Diverse einstellungen infobar.jpg|300px]]

Der Dateiname für ein Logo setzt sich aus der '''ChannelID''' '''oder''' dem '''Realnamen des Kanals''' wie er in den EPG-Informationen angezeigt wird und der Dateiendung "'''.raw'''" zusammen.
Beispiel hier für 3Sat:
43700016d67.raw
oder
3sat.raw

Die ChannelID ist eine Kombination einiger Daten, die man beispielsweise aus den [[Neutrino#Technische_Information|Streaminfos]] abrufen kann.
*[[Bild:Technische_informationen.png|400px]]
Diese setzt sich zusammen aus
*tsid 0x0'''437'''
*onid 0x'''0001'''
*sid 0x'''6d67'''
Wie man sieht, ist das angezeigte Format in den Informationen etwas anders. Es werden nur die fett abgebildeten Daten benötigt.

Eine weitere Möglichkeit, die ChannelID zu gewinnen besteht darin, diese über den Webbrowser abzurufen. Dafür muss die dBox natürlich mit dem PC verbunden sein. Im Browser gibt man hierfür diese Daten ein:
<nowiki>http://<dBoxIP>/control/getonidsid</nowiki>
Als Rückgabe erscheint dann die gewünschte ID vom aktuell eingeschaltetem Sender.

Die Datei
/var/tuxbox/config/zapit/services.xml
enthält ebenfalls diese Daten.

'''Hinweis:''' ''Die ChannelID's sind je nach Empfangsmöglichkeiten (Kabel-Provider, Satellit usw.) unterschiedlich. Wenn es denn möglich sein sollte, könnte man evtl. auf vorgefertigte Logo-Packs zurückgreifen.''

Wird solch eine Raw-Datei anhand der ChannelID bzw. dem Sendernamen erkannt, wird sie automatisch zum passenden Kanal angezeigt.

Hier einige Beipiele:

*[[Bild:Infobar chlogo number.jpg|300px]] anstelle Kanalnummer 120x64px
*[[Bild:Infobar chlogo ersatz.jpg|300px]] anstelle Sendername [max]x64px
*[[Bild:Infobar chlogo beside.jpg|300px]] neben Sendername [max]x64px

'''Hinweis:''' [max] ''gibt die Breite an, die verwendet werden kann. Die Breite für das Logo kann je nach Länge des Programmnames, der je nach Einstellung bis zur Zeitanzeige reichen kann, variieren. Dies ist somit auch davon abhängig, welche Einstellungen für den OSD-Bereich gemacht wurden. Sollte ein Logo nicht passen, kann das [[Bootlog]] mehr Informationen über die maximal mögliche Größe Aufschluß geben ''

Nach dem Einspielen sind die Logos sofort verfügbar sobald sie durch den Infobar aufgerufen werden. Ein Neustart von Neutrino ist nicht erforderlich.

Sollte jemand Logos zur Verfügung stellen wollen, besteht [http://www.dbox2-tuning.net/ulc hier] die Möglichkeit, Logos zu sammeln.

==eigene LCD-Vorlagen==
Neben dem [[Bootlogo austauschen|LCD-Bootlogo]] lassen sich auch die während des Betriebs der Box vom LC-Displays abgebildeten Hintergründe nach eigenen Wünschen austauschen. Hierfür werden Bilder im png-Format mit einer Auflösung von 120x64 Pixel 1bit-Modus, horizontale und vertikale Auflösung jeweils 96 dpi benötigt.
Speicherort:

var/share/tuxbox/neutrino/lcdd/

Diese Dateien können hierbei ersetzt werden:
*lcd.png
*lcd2.png
*lcd3.png
*power.png
*setup.png

=eigene Bootlogos verwenden=

siehe [[Bootlogo austauschen]]

=Ereignisse abfangen=
Angenommen man möchte eine nächtliche Timeraufname machen und diese aber möglicht bald auf seinem Rechner wiederfinden. Hier kann es beispielsweise nützlich sein, nachdem die Aufnahme beendet wurde, sich diese von einer evtl. vorhandenen Festplatte über das Netzwerk auf seinen Rechner kopieren zu lassen. Genau hierfür bietet Neutrino die Möglichkeit, eine entsprechende Aktion auszuführen. In diesem Fall wäre es das Script '''recording.end''' dass, sofern es vorhanden und ausführbar ist, nach jedem Ende einer Aufnahme ausgeführt wird. Dieses und noch einige weitere Ereignisse lassen sich damit abfangen und nutzen...

==Aufnahme Ankündigung==
Wenn eine Aufnahme angekündigt wird, wird zunächst (wenn vorhanden) dieses Skript ausgeführt:

/var/tuxbox/config/recording.timer (Rechte auf 755)
Dieses Script kann benutzt werden um eine evtl. im Standby/ Spindown befindliche Platte im Server/ NAS zu "wecken"

==Aufnahme Start==
Wenn eine Aufnahme gestartet wird, wird zunächst (wenn vorhanden) dieses Skript ausgeführt:

/var/tuxbox/config/recording.start (Rechte auf 755)

==Aufnahme Ende==
Seit [[Yadi]] 1.9.0.2 ist im folgenden Pfad eine Beispielkonfiguration für ein Skript, was bei Aufnahmeende ausgeführt wird. Damit es ausgeführt wird, muss es in record.end umbenannt werden. Rechte müssen auf 755 stehen.

/var/tuxbox/config/recording.end''.dist''

Wenn ihr das Beispielskript /var/tuxbox/config/recording.end.dist umbenennt in recording.end werden die aufgenommenen ts-files mit dbox2genpsi gepatcht, sodass sie auch unter [[Enigma]] abspielbar sind.

und so sieht es aus:

#!/bin/sh
# $Id: recording.end,v 1.5 2004/08/07 21:11:31 essu Exp $
FOUND=`grep network_nfs_recordingdir /var/tuxbox/config/neutrino.conf` || exit
RECDIR=`expr substr $FOUND 26 154`
cd $RECDIR && FILES=`ls -c *.ts` || exit
for FILE in $FILES; do
break;
done
dbox2genpsi $RECDIR/$FILE

Natürlich können an dieser Stelle auch andere Skripte ausgeführt werden.

==Standby ON==
Wenn die Box in den Standby geschickt wird, wird dieses Skript (wenn vorhanden) ausgeführt:

/var/tuxbox/config/standby.on (Rechte auf 755)

==Standby OFF==
Wenn die Box aus dem Standby geholt wird, wird dieses Skript (wenn vorhanden) ausgeführt:

/var/tuxbox/config/standby.off (Rechte auf 755)

==Audioplayer Start==
Wenn der Audioplayer gestartet wird, wird dieses Skript (wenn vorhanden) ausgeführt:

/var/tuxbox/config/audioplayer.start (Rechte auf 755)
Beispiel:
#!/bin/sh
killall -9 sectionsd
Das beendet den [[sectionsd]] beim Starten des [[Audioplayer]]s

==Audioplayer Stop==
Wenn der Audioplayer beendet wird, wird dieses Skript (wenn vorhanden) ausgeführt:

/var/tuxbox/config/audioplayer.end (Rechte auf 755)
Beispiel:
#!/bin/sh
sectionsd
Das startet den [[sectionsd]] nach Beendung des [[Audioplayer]]s

==Bildbetrachter Start==
(ab Pictureviewer Version 1.63)
Wenn der [[Neutrino:Bildbetrachter|Bildbetrachter]] gestartet wird, wird dieses Skript (wenn vorhanden) ausgeführt:

/var/tuxbox/config/pictureviewer.start (Rechte auf 755)
Beispiel:
#!/bin/sh
killall -9 sectionsd
Das beendet den [[sectionsd]] beim Starten des [[Neutrino:Bildbetrachter|Bildbetrachter]]s

==Bildbetrachter Stop==
Wenn der [[Neutrino:Bildbetrachter|Bildbetrachter]] beendet wird, wird dieses Skript (wenn vorhanden) ausgeführt:

/var/tuxbox/config/pictureviewer.end (Rechte auf 755)

==Movieplayer Start==
Wenn der Movieplayer gestartet wird, wird dieses Skript (wenn vorhanden) ausgeführt:

/var/tuxbox/config/movieplayer.start (Rechte auf 755)
Beispiel:
#!/bin/sh
killall -9 sectionsd
Das beendet den [[sectionsd]] beim Starten des [[Movieplayer]]s

==Movieplayer Stop==
Wenn der Movieplayer beendet wird, wird dieses Skript (wenn vorhanden) ausgeführt:

/var/tuxbox/config/movieplayer.end (Rechte auf 755)
Beispiel:
#!/bin/sh
sectionsd
Das startet den [[sectionsd]] nach Beendung des [[Movieplayer]]s

==Bei Bildformatumschaltung==
Wenn das jeweilige Bildformat umgeschaltet wird, werden diese Skripte (wenn vorhanden) ausgeführt:

/var/tuxbox/config/16:9.start (Rechte auf 755)

/var/tuxbox/config/4:3.start (Rechte auf 755)

Ausserdem gibt es noch die Alternativen für [[Lirc]], welche ebenfalls genutzt werden können.

16:9.lirc

4:3.lirc

=custom Webinterface=
Das [[Webinterface]] von [[Neutrino]] liegt im Verzeichnis:
/share/tuxbox/neutrino/httpd

Bei [[squashFS]] [[Images]] ([[Yadi]]) ist dieses Verzeichnis schreibgeschützt. Das heißt, dass Änderungen dort nicht so einfach möglich sind. Es gibt jedoch einen Eintrag in der nhttpd.conf, der einen alternativen Pfad beinhaltet. Man erstellt unter /var das Verzeichnis "httpd":
/var/httpd
In diesen Pfad kann man das alternative Webinterface ablegen. Bei Aufruf im Browser
<nowiki>http://<dboxIP>/</nowiki>
erscheint die in diesem Verzeichnis abgelegte "index.html"

=nhttpd /control api doku=
Diese Dokumentation ist auch im [[CVS]] [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/apps/tuxbox/neutrino/daemons/nhttpd/api_doku.txt?view=markup hier] zu finden. Bei Aufrufen vom Browser ist im Handler "dbox" durch die IP Adresse der Dbox zu ersetzen.

==Die Kanalliste==
'''Handler:''' <nowiki>http://dbox/control/channellist</nowiki> 
'''Parameter:''' keine 
'''Rückgabe:'''
Es wird die gesamte Kanalliste von [[Neutrino]] zurückgegeben. Jede Zeile wird von einem Enter (\n) von der Nächsten getrennt. Eine Zeile enthält ein Programm.

'''Rückgabeformat:''' channel_id Programmname

Die channel_id dient als Handle für andere Operationen wie Zappen oder [[EPG]].
Die channel_id ist eine 64 bit Hexadezimalzahl.

'''Beispiel:'''

>>><nowiki>http://dbox/control/channellist</nowiki>
16dca Das Erste
16e29 EinsExtra
16e2a EinsFestival
16e2b EinsMuXx
16d66 ZDF

==EPG-Abfrage==
'''Handler:''' <nowiki>http://dbox/control/epg</nowiki> 

'''Parameter:''' keine 
'''Rückgabe:'''
Es werden alle verfügbaren EPGs aller Programme zur aktuellen Zeit zurückgegeben. Jede Zeile wird von einem Enter (\n) von der Nächsten getrennt. Eine Zeile enthält die Information über die aktuell laufende Sendung.

'''Rückgabeformat:''' channel_id EVENTID Titel der Sendung

Die EVENTID dient als Handle um genauere Informationen abzufragen.

'''Beispiel:'''

>>><nowiki>http://dbox/control/epg</nowiki>
8716804 571264467523 Wasserloch Nr. 3
8716304 571231699926 Ein Käfig voller Helden
8716311 571232198133 Cop Rock

'''Parameter:''' channel_id (64 bit, hexadezimal) 
'''Rückgabe:'''
Als Rückgabe wird die Eventliste des durch die channel_id identifizierten Senders gesendet, d.h. eine Liste, welche Filme auf diesem Sender kommen. Jede Zeile wird von einem Enter (\n) von der Nächsten getrennt.

'''Rückgabeformat:''' EVENTID Startzeit Dauer Titel der Sendung

Die EVENTID dient als Handle um genauere EPG-Informationen abzufragen.

'''Beispiel:'''

>>><nowiki>http://dbox/control/epg?8716304</nowiki>
571231699925 1021322700 1500 Shooting Stars
571231699926 1021324200 1500 Ein Kaefig voller Helden
571231699927 1021325700 1500 The Hitchhiker
571231699928 1021327200 1500 The Hitchhiker

'''Parameter:''' id=channel_id 
'''Rückgabe:'''
Als Rückgabe wird die Eventliste des durch die channel_id identifizierten Senders gesendet, das heißt eine Liste, was für Filme auf einem Sender kommen. Jeder Datensatz wird von einem EnterEnter (\n\n) vom Nächsten getrennt.

'''Rückgabeformat:'''
EVENTID Startzeit DURATION
TITLE
INFO1
INFO2

Die EVENTID dient als Handle um genauere EPG-Informationen abzufragen.

'''Beispiel:'''

>>><nowiki>http://dbox/control/epg?id=16dcb</nowiki>
6143198520 1067754600 1800
Daten der Woche
Moderation: Andrea Müller
Themen:Š* Kandidatenkür: Maas wird SpitzenkandidatŠ* ......

6143198521 1067756400 1800
Abendschau
Themen:Š* Protestmarsch "Es reicht"Š* ..........

'''Parameter:''' eventid=EVENTID 
'''Rückgabe:'''
Es wird die ausführliche Beschreibung eines Films zurückgegeben. Diese besteht aus einem Titel, einer allgemeinen Info und der Beschreibung. Titel Info und Beschreibung werden mit einem Enter (\n) voneinander getrennt. Es muss beachtet werden, dass in der Beschreibung weitere Enter vorkommen können.

'''Rückgabeformat:''' 
Titel 
Info 
Beschreibung

'''Beispiel:'''

>>><nowiki>http://dbox/control/epg?eventid=571231699926</nowiki>
Ein Käfig voller Helden
Operation 'Tiger'
blablabla

'''Parameter:''' ext 
'''Rückgabe:'''
Es werden alle verfügbaren EPGs aller Programme zur aktuellen Zeit zurückgegeben. Jede Zeile wird von einem Enter (\n) von der Nächsten getrennt.
Eine Zeile enthält die Information über die aktuell laufende Sendung.

'''Rückgabeformat:''' channel_id Startzeit Dauer EVENTID Titel der Sendung

Die EVENTID dient als Handle um genauere Informationen abzufragen.

'''Beispiel:'''

>>><nowiki>http://dbox/control/epg?ext</nowiki>
8716330 1025382300 6900 571233417784 Rocky 2

==Die DBox herunterfahren==
'''Handler:''' <nowiki>http://dbox/control/shutdown</nowiki>

'''Parameter:''' keine 
'''Rückgabe:'''
Es wird der Text "ok" bei Erfolg oder "error" im Fehlerfall zurückgegeben. Die Dbox schaltet sich bei "ok" sofort ab.

'''Rückgabeformat:''' ok / error

'''Beispiel:'''

>>><nowiki>http://dbox/control/shutdown</nowiki>
ok

==Standby Mode==
'''Handler:''' <nowiki>http://dbox/control/standby</nowiki>

'''Parameter:''' on 
'''Rückgabe:'''
Schaltet in den Standby Mode

'''Rückgabeformat:''' ok /error

'''Beispiel:'''

>>><nowiki>http://dbox/control/standby?on</nowiki>
ok

'''Parameter:''' off 
'''Rückgabe:'''
Schaltet den Standby Mode aus

'''Rückgabeformat:''' ok /error

'''Beispiel:'''

>>><nowiki>http://dbox/control/standby?off</nowiki>
ok

==Lautstärke-Steuerung==
'''Handler:''' <nowiki>http://dbox/control/volume</nowiki>

'''Parameter:''' keine 
'''Rückgabe:'''
Es wird die aktuell eingestellte Lautstärke zurückgegeben - die Werte bewegen sich zwischen 0 (leise) und 100 (laut).

'''Rückgabeformat:''' Lautstärke

'''Beispiel:'''

>>><nowiki>http://dbox/control/volume</nowiki>
80

'''Parameter:''' <Lautstärke als ganze Zahl in 5er Schritten> 
'''Rückgabe:'''
Es kann die Lautstärke eingestellt werden - die Werte müssen sich zwischen 0 (leise) und 100 (laut) bewegen. Es sollten nur Werte in 5er-Schritten gesetzt werden (5,10,...).

'''Rückgabeformat:''' ok / error

'''Beispiel:'''

>>><nowiki>http://dbox/control/volume?40</nowiki>
ok

'''Parameter:''' mute 
'''Rückgabe:'''
Die Audio-Ausgabe wird abgeschaltet. Es kommt als Bestätigung der String "mute" zurück.

'''Rückgabeformat:''' ok

'''Beispiel:'''

>>><nowiki>http://dbox/control/volume?mute</nowiki>
mute

'''Parameter:''' unmute 
'''Rückgabe:'''
Die Audio-Ausgabe wird wieder eingeschaltet. Es kommt als Bestätigung der String "unmute" zurück.

'''Rückgabeformat:''' ok

'''Beispiel:'''

>>><nowiki>http://dbox/control/volume?mute</nowiki>
unmute

'''Parameter:''' status 
'''Rückgabe:'''
Es wird der Status (ob gerade mute aktiv ist) zurückgegeben. (0 - unmuted, 1 - mute)

'''Rückgabeformat:''' 0 oder 1

'''Beispiel:'''

>>><nowiki>http://dbox/control/volume?status</nowiki>
1

==Programm umschalten / Playback==
'''Handler:''' <nowiki>http://dbox/control/zapto</nowiki>

'''Parameter:''' keine 
'''Rückgabe:'''
Es wird die channel_id (hex-value, 64 bit, kein 0x-prefix) des aktuell laufenden Senders zurückgegeben.

'''Beispiel:'''

>>><nowiki>http://dbox/control/zapto</nowiki>
16dcb

'''Parameter:''' getpids 
'''Rückgabe:'''
Es werden die VPID und die APID des laufenden Senders angezeigt. Die beiden Werte sind durch ein Enter voneinander getrennt.

'''Rückgabeformat:''' VPID, APID

'''Beispiel:'''

>>><nowiki>http://dbox/control/zapto?getpids</nowiki>
305
306

'''Parameter:''' getallpids 
'''Rückgabe:'''
Es werden die VTXT PID, VPID und alle APIDs des laufenden Senders angezeigt. Die Werte sind durch ein Enter voneinander getrennt. Hinter jeder APID wird eine kurze Beschreibung angegeben, bei [[AC3]] Streams zusätzlich (AC3).

'''Rückgabeformat:''' 
VPID 
APID <description> [(AC3)] 
[APID...] 
[VTXT PID]

'''Beispiel:'''

>>><nowiki>http://dbox/control/zapto?getallpids</nowiki>

00511
00512 deutsch
00513 englisch
00515 Dolby Digital 2.0
00032 vtxt
00101 pmt

oder

00101
00102 German
00104 vtxt
00100 pmt

'''Parameter:''' stopplayback 
'''Rückgabe:'''
Stoppt die Decodierung, um grabben zu können. Zusätzlich wird der Sectionsd gestoppt. Rückgabewert sollte ok für Erfolg sein.

'''Rückgabeformat:''' ok / error

'''Beispiel:'''

>>><nowiki>http://dbox/control/zapto?stopplayback</nowiki>
ok

'''Parameter:''' startplayback 
'''Rückgabe:'''
Startet die Decodierung nach dem Grabben wieder, [[Sectionsd]] wird auch wieder gestartet. Rückgabewert sollte ok für Erfolg sein.

'''Rückgabeformat:''' ok

'''Beispiel:'''

>>><nowiki>http://dbox/control/zapto?startplayback</nowiki>
ok

'''Parameter:''' statusplayback 
'''Rückgabe:'''
'1': Playback aktiv, '0': kein Playback aktiv

'''Rückgabeformat:''' 0/1

'''Beispiel:'''

>>><nowiki>http://dbox/control/zapto?statusplayback</nowiki>
0

'''Parameter:''' stopsectionsd 
'''Rückgabe:'''
Stoppt den [[Sectionsd]] zum Grabben. Rückgabewert sollte ok für Erfolg sein.

'''Rückgabeformat:''' ok

'''Beispiel:'''

>>><nowiki>http://dbox/control/zapto?stopsectionsd</nowiki>
ok

'''Parameter:''' startsectionsd 
'''Rückgabe:'''
Startet [[Sectionsd]] nach dem Grabben wieder. Rückgabewert sollte "ok" für Erfolg sein.

'''Rückgabeformat:''' ok

'''Beispiel:'''

>>><nowiki>http://dbox/control/zapto?startsectionsd</nowiki>
ok

'''Parameter:''' statussectionsd 
'''Rückgabe:'''
gibt den Status des [[Sectionsd]] zurück. (Scanning, bzw, kein Scanning)

'''Rückgabe-Format:''' '1': sectionsd scanning an, '0': sectionsd scanning aus

'''Beispiel:'''

>>><nowiki>http://dbox/control/zapto?statussectionsd</nowiki>
1

'''Parameter:''' channel_id (64 bit, hexidecimal value) 
'''Rückgabe:'''
Zappt auf den angegebenen Kanal. Als Rückgabe ist im Erfolgsfall "ok" zu erwarten.

'''Rückgabeformat:''' ok / error

'''Beispiel:'''

>>><nowiki>http://dbox/control/zapto?16dcb</nowiki>
ok

==Radio/TV, Record Mode==
'''Handler:''' <nowiki>http://dbox/control/setmode</nowiki>

'''Parameter:''' status 
'''Rückgabe:'''
Es wird der aktuelle record mode Status zurückgegeben

'''Rückgabeformat:''' on / off

'''Beispiel:'''

>>><nowiki>http://dbox/control/setmode?status</nowiki>
on

'''Parameter:''' radio 
'''Rückgabe:'''
Schaltet in den radio mode

'''Rückgabeformat:''' ok / error

'''Beispiel:'''

>>><nowiki>http://dbox/control/setmode?radio</nowiki>
ok

'''Parameter:''' tv 
'''Rückgabe:'''
Schaltet in den TV mode

'''Rückgabeformat:''' ok / error

'''Beispiel:'''

>>><nowiki>http://dbox/control/setmode?tv</nowiki>
ok

'''Parameter:''' record 
'''Rückgabe:'''
Schaltet in den record mode
Dies beinhaltet auch das Stoppen, bzw. das Starten des [[sectionsd]] Scanning, das Starten des Playbacks(immer) und Stoppen des Playbacks (nur bei stopplayback=true).

'''Rückgabeformat:''' ok / error

'''Beispiele:'''

>>><nowiki>http://dbox/control/setmode?record=start</nowiki>
ok

>>><nowiki>http://dbox/control/setmode?record=start&stopplayback=true</nowiki>
ok

>>><nowiki>http://dbox/control/setmode?record=stop</nowiki>
ok

==Radio/TV Mode Abfrage==
'''Handler:''' <nowiki>http://dbox/control/getmode</nowiki>

'''Parameter:''' 
'''Rückgabe:''' "tv", "radio", "unkown"

Es wird der aktuelle mode zurückgegeben tv / radio / unknown (shouldn't happen)

'''Beispiel:'''

>>><nowiki>http://dbox/control/getmode</nowiki>
tv

==Datum von der Box abfragen==
'''Handler:''' <nowiki>http://dbox/control/getdate</nowiki>

'''Parameter:''' keine 
'''Rückgabe:'''
Es wird das Datum zurückgegeben.

'''Rückgabeformat:''' dd.mm.yyyy

'''Beispiel:'''

>>><nowiki>http://dbox/control/getdate</nowiki>
25.02.2005

==Uhrzeit von der Box abfragen==
'''Handler:''' <nowiki>http://dbox/control/gettime</nowiki>

'''Parameter:''' keine 
'''Rückgabe:'''
Es wird die Uhrzeit zurückgegeben.

'''Rückgabeformat:''' hh:mm:ss

'''Beispiel:'''

>>><nowiki>http://dbox/control/gettime</nowiki>
20:34:24

'''Parameter:''' rawtime 
'''Rückgabe:'''
Es wird die Uhrzeit im [[time_t]] Format zurückgegeben.

'''Rückgabeformat:''' [[time_t]]

'''Beispiel:'''

>>><nowiki>http://dbox/control/gettime?rawtime</nowiki>
1046804654

==Allgemeine Informationen abfragen==
'''Handler:''' <nowiki>http://dbox/control/info</nowiki>

'''Parameter:''' streaminfo 
'''Rückgabe:'''
Es werden Streaminfos zurückgegeben. Die Werte sind durch Enter (\n) getrennt

'''Rückgabeformat:''' X_res Y_res [[Bitrate]] Videoformat [[Framerate]] Audioformat

'''Beispiel:'''

>>><nowiki>http://dbox/control/info?streaminfo</nowiki>
480
576
997500
4:3
25
joint stereo

'''Parameter:''' version 
'''Rückgabe:'''
Aktuelle [[cramfs]] - Version. Es wird der Inhalt der Datei /.version zurückgegeben.

'''Beispiel:'''

>>><nowiki>http://dbox/control/info?version</nowiki>
version: 1.1.27032002-21.8
md5sum: f1d7d47578bb9040a82085182934ce0e
Erstellt von alexW

'''Parameter:''' settings 
'''Rückgabe:'''
Aktuelle Settings und DBox Typ

'''Beispiel:'''

>>><nowiki>http://dbox/control/info?settings</nowiki>
Boxtype Nokia
videooutput RGB
videoformat 4:3

'''Parameter:''' httpdversion 
'''Rückgabe:''' 
Version des httpd 
1 : nhttpd (legacy api) 
2 : thttpd 
3 : nhttpd

'''Beispiel:'''

>>><nowiki>http://dbox/control/info?httpdversion</nowiki>
3

==Aktuellen Kanal abfragen==
'''Handler:''' <nowiki>http://dbox/control/getonidsid</nowiki>

'''Parameter:''' 
'''Rückgabe:'''
Es wird die TSIDONIDSID des aktuellen Kanals zurückgegeben.

''Diese Funktion sollte NICHT mehr verwendet werden und ist durch folgenden Aufruf ersetzt:'' 
<nowiki>http://dbox/control/zapto</nowiki>

'''Rückgabeformat:''' TSIDONIDSID

'''Beispiel:'''

>>><nowiki>http://dbox/control/getonidsid</nowiki>
44d00016dca

==services.xml lesen==
'''Handler:''' <nowiki>http://dbox/control/getservicesxml</nowiki>

'''Parameter:''' 
'''Rückgabe:'''
Es wird der Inhalt der Datei /var/tuxbox/config/zapit/[[services.xml]] zurückgegeben.

'''Beispiel:'''

>>><nowiki>http://dbox/control/getservicesxml</nowiki>
<xml version="1.0" encoding="iso-8859-1"?>
<ZAPIT>
<cable>
<transponder transportID="00001" networkID="0">
<cable frequency="04020" symbolRate="06900" fec="0" polarity="0"/>
...

==bouquets.xml auslesen==
'''Handler:''' <nowiki>http://dbox/control/getbouquetsxml</nowiki>

'''Parameter:''' 
'''Rückgabe:'''
Es wird der Inhalt der Datei /var/tuxbox/config/zapit/[[bouquets.xml]] zurückgegeben.

'''Beispiel:'''

>>><nowiki>http://dbox/control/getbouquetsxml</nowiki>

<?xml version="1.0" encoding="iso-8859-1"?>
<ZAPIT>
<Bouquet name="beispielbouquet" hidden="0" locked="0">
<channel serviceID="6d67" name="3sat" onid="0001"/>
...

==Bouquetlist abfragen==
'''Handler:''' <nowiki>http://dbox/control/getbouquets</nowiki>

'''Parameter:''' 
'''Rückgabe:'''
Es werden alle [[Bouquets]] zurückgeliefert

'''Beispiel:'''

>>><nowiki>http://dbox/control/getbouquets</nowiki>
1 ARD
3 Premiere World
4 VisionProgramme
5 ZDFvision

==Bouquet abfragen==
'''Handler:''' <nowiki>http://dbox/control/getbouquet</nowiki>

'''Parameter:''' [[Bouquet]] Nr. und TV|RADIO 
'''Rueckgabe:'''
Es werden alle Sender des Bouquets zurückgeliefert

'''Rückgabeformat:''' [Nummer_des_Kanals] [channel_id] [Name_des_Senders]

'''Beispiel:'''
>>><nowiki>http://dbox/control/getbouquet?bouquet=2&mode=TV</nowiki>
20 12ee3 RTL Television
21 85002e SAT.1
22 850382 ProSieben
23 12ef4 RTL2
24 12f1c VOX

==Fenster in Neutrino==
'''Handler:''' <nowiki>http://dbox/control/message</nowiki>

'''Parameter:''' popup=text oder nmsg=text 
'''Rückgabe:''' ok

'''Character encoding:''' [[UTF-8]], Leerzeichen werden mit ''%20'' dargestellt

[[Neutrino]] öffnet ein Popup (popup) oder Message (nmsg) Window, in dem der Textteil des Parameter angezeigt wird. Ein Popup Fenster schließt sich nach einiger Zeit von selbst, während ein Message Window vom Benutzer geschlossen werden muss.

'''Beispiel:'''

>>><nowiki>http://dbox/control/message?popup=Hello%20World</nowiki>
Popup Window auf dem Bildschirm "Hello World"

>>><nowiki>http://dbox/control/message?nmsg=Hello%20Welt</nowiki>
Message Window auf dem Bildschirm "Hello World"

==Timerd Interface==
'''Handler:''' <nowiki>http://dbox/control/timer</nowiki>

'''Parameter:''' 
'''Rückgabe:'''
Zeigt die Liste aller Timer

'''Rückgabeformat:''' [eventID] [eventType] [eventRepeat] [repcount] [announceTime] [alarmTime] [stopTime] [data]

''eventID'' ist der Timerplatz. 
''eventType'' ist die Art des Timers, die kann sein:

1 = SHUTDOWN
2 = NEXTPROGRAM
3 = ZAPTO
4 = STANDBY
5 = RECORD
6 = REMIND
7 = SLEEPTIMER
8 = EXEC_PLUGIN

siehe dazu auch: [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/*checkout*/tuxbox/apps/tuxbox/neutrino/daemons/timerd/doku.html?rev=1.3&content-type=text/plain [[Neutrino]] Timer Doku]

''eventRepeat'' ist die Angabe der Timerwiederholung. Die kann sein:

0 = ONCE (Einmal)
1 = DAILY (Täglich)
2 = WEEKLY (Wöchentlich)
3 = BIWEEKLY (Alle 2 Wochen)
4 = FOURWEEKLY (Alle 4 Wochen)
5 = MONTHLY (Monatlich)
6 = BYEVENTDESCRIPTION (noch nicht implementiert)

Es gibt auch noch eine Möglichkeit WEEKDAYS also auch Wochentage festzulegen, an denen die Aufnahme stattfinden soll. Dies wird über einen Bitschlüssel angegeben, der Bit 9-15 als die Wochentage ansieht. 
Das heißt:

0000000100000000 = 256 = Montag
0000001000000000 = 512 = Dinstag
0000010000000000 = 1024 = Mittwoch
0000100000000000 = 2048 = Donerstag
0001000000000000 = 4096 = Freitag
0010000000000000 = 8192 = Samstag
0100000000000000 = 16384 = Sontag

Demzufolge ist Montag+ Mittwoch+ Samstag

0000000100000000 = 256
0000010000000000 = 1024
0010000000000000 = 8192
---------------- ----
0010010100000000 = 9472

Siehe dazu auch: [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/apps/tuxbox/neutrino/lib/timerdclient/timerdtypes.h?rev=1.10&content-type=text/vnd.viewcvs-markup timerdtypes.h]

''repcount'' bestimmt die Anzahl der Timeraufrufe, nach der der Timer automatisch gelöscht wird. 0 bedeutet, dass es keine Beschränkung gibt. Bei eventRepeat=ONCE hat diese Einstellung keine Auswirkungen. 
''announceTime'' ist die Zeit, an der die Warnung vor dem Timer auf dem Bildschirm erscheint. 
''alarmTime'' ist die Zeit des Timer-Starts 
''stopTime'' ist die Stoppzeit für den Timer 
''data'' ist der Name des Senders.

'''Beispiel:'''

>>><nowiki>http://dbox/control/timer</nowiki>
1 1 1 4 1034309516 1034309576 1034284376 555089

d.h. event 1, SHUTDOWN, DAILY, nach 4 Timerausführungen wird der Timer gelöscht, announcezeit, alarm/startzeit, stoppzeit, kanal/daten
''die zeiten sind time_t (Unix Zeitstempel)''

'''Parameter:''' action,[id],<alarm|ad,amo,ay,ah,ami>,<stop|sd,smo,sy,sh,smi>,announce,type,rep,repcount,channel_id,msg,rs 
'''Rückgabe:''' ok / error

''announce'', ''type'', ''rep'' und ''repcount'' analog zu oben.

''action'' kann entweder new oder modify sein. Bei ''modify'' muss noch ein Parameter id angegeben werden, um festzulegen, welcher Timer modifiziert wird.

Man kann entweder ''alarm'' und ''stop'' mit einer [[time_t]] Zeit verwenden oder die anderen Variablen mit den Daten füttern:

a/sd = Tag
a/smo = Monat
a/sy = Jahr
a/sh = Stunde
a/smi = Minute

''channel_id'' ist die Kennung des Senders (als Hexadezimalzahl ohne '0x'-Prefix). 
''msg'' ist die Message die bei REMIND gesendet wird

Ist der Parameter "rs" auf "1" gesetzt, so wird bei Aufnahmetimern, die in [[Neutrino]] konfigurierte "Aufnahmestart/stop-Korrektur" berücksichtigt.

siehe dazu auch: [http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/apps/tuxbox/neutrino/daemons/nhttpd/webapi.cpp?rev=HEAD&content-type=text/vnd.viewcvs-markup webapi.cpp]

'''Rückgabeformat:''' ok / error

'''Beispiel:'''

>>><nowiki>http://dbox/control/timer?action=new&alarm=1034309576&stop=1034284376&announce=1034309576&type=1&rep=1&channel_id=16dcb</nowiki>
ok

==Shellscript ausführen==
'''Handler:''' <nowiki>http://dbox/cgi-bin/exec</nowiki> oder <nowiki>http://dbox/control/exec</nowiki>

'''Parameter:''' <Scriptname> (ohne .sh!) 
'''Rückgabe:'''
Führt das Shellscript aus und liefert die Ausgabe an den Client zurück. 404 Bei Nicht-Auffinden.

'''Beispiel:'''

buli.sh gibt einen RSS-Feed zurück, der vom Newsticker angezeigt wird. In newsticker.list muss dann der Aufruf folgendermaßen aussehen:

<nowiki>http://dbox/cgi-bin/exec?buli</nowiki>

HINWEIS: Shellscript muss im richtigen Verzeichnis liegen. Ansonsten 404. (siehe oben unter Custom Plugins)

==System-/Treiberfunktionen==
'''Handler:''' <nowiki>http://dbox/control/system</nowiki>

'''Parameter:''' getAViAExtIec 
'''Rückgabe:''' Status des Iec (optischer Ausgang)

0 = Iec deaktiviert 
1 = Iec aktiviert

'''Beispiel:'''

<nowiki>http://dbox/control/system?getAViAExtIec</nowiki>
1

'''Parameter:''' setAViAExtIec=on 
'''Rückgabe:''' ok

Aktiviert den Iec

'''Beispiel:'''

<nowiki>http://dbox/control/system?setAViAExtIec=on</nowiki>
ok

'''Parameter:''' setAViAExtIec=off 
'''Rückgabe:''' ok

Deaktiviert den Iec

'''Beispiel:'''

<nowiki>http://dbox/control/system?setAViAExtIec=off</nowiki>
ok

'''Parameter:''' getAViAExtPlayBack 
'''Rückgabe:''' Gibt zurück, in welchem Dekoder-Modus der Avia läuft

0 = PES 
1 = SPTS

'''Beispiel:'''

<nowiki>http://dbox/control/system?getAViAExtPlayBack</nowiki>
1

'''Parameter:''' getAViAExtPlayBack=pes 
'''Rückgabe:''' ok

Aktiviert den DualPES-Modus

'''Beispiel:'''

<nowiki>http://dbox/control/system?setAViAExtPlayBack=pes</nowiki>
ok

'''Parameter:''' getAViAExtPlayBack=spts 
'''Rückgabe:''' ok

Aktiviert den SPTS-Modus

'''Beispiel:'''

<nowiki>http://dbox/control/system?setAViAExtPlayBack=spts</nowiki>
ok

{{review}}

{{body}}

Dbox2:Development:README.3rdparty.en (Oldmake) obsolete

2008-08-11T15:28:19Z

Dixidix: Verweise hinzugefügt

[[Category:Register]]
[[Category:CDK]]
[[Category:FAQ]]
[[Category:English]]
[[Category:Development]]
{{Development_sidebar}}
__TOC__
{{Deutsch|Development:README.3rdparty.de}}

=General=
==And this is how you add new tools to the cdk==
First of all start thinking if whatever you intend to add really is a useful
addition to the project. If you still think your idea is great you can start
integrating it.

The audience of this document is neither developers wanting to add their own software
nor people who deeply integrated some 3rd party software into their projects.

It is meant for people wanting to add someone's else's code in more or less its original
form. Please be very careful to check that the code's license is suitable for the project.

Often you will need to make some small changes to the source code to make it build properly.
In that case you must NOT create a new archive but simply take the original version,
copy it, add your changes and create a diff between the two.

You do this with the command:

"diff -Naur packet.orig packet > packet.diff"

The created patch goes to "$HOME/tuxbox-cvs/cdk/Patches". Do not add any version information
to the filename.

The next step is to make some additions to the following files:
$HOME/tuxbox-cvs/cdk/Makefile.am
$HOME/tuxbox-cvs/cdk/configure.ac
$HOME/tuxbox-cvs/cdk/rules-archive
$HOME/tuxbox-cvs/cdk/rules-make
$HOME/tuxbox-cvs/cdk/rules-install

=Let's start with rules-archive=
This file describes the packets' download source(s). Since most packets are hosted on public
servers we simply download them when needed. Both the http and ftp protocol is supported.
Format is one line per packet, first the name then URL(s), all separated by semicolons.

packetname;URL1[;URL2...;URLN]

example:
paket-1.0.tar.gz;<nowiki>khttp://www.packethome.com/download</nowiki>

=Next we deal with rules-make=
This file describes the steps necessary to 'make' the packet.

Again we have one line per packet with several entries separated by semicolons.
The entries are as follows:

identifier;version;directory;archive[:patch1...:patchN];rule1[;rule2...;ruleN]

==identifier==
Must be a unique name. It will be used again in the files
rules-install, configure.ac and Makefile.am. It can be any name but
it's best to use part of the packet name to avoid namespace clashes.

==version==
Versionnumber of the packet. Even though most packets have this as part
of their archive name you might find one that doesn't so it's provided as
an additional separate entry.

==directory==
This is the name of the directory that results from unpacking the
archive. Even though most archives will contain just one directory
which will in turn contain all the necessary files and subdirectories
there might be some exceptions. In this case choose a suitable name here
and use "dirextract" as a rule (see below).

==archive==
The name of the packet archive itself. If there are additional files
necessary (diffs or additional archives) you add the names without path and
separate them by colons.

==rules==
You state rules that need to be applied to the packet and its files
extract - extracts a packet
dirextract - creates a directory and extracts the packet inside it
patch - applies a diff-file to patch the packet

Take a look at rules-make for additional rules.

example1 (just extract):
packet;1.0;packet-1.0;packet-1.0.tar.gz;extract:packet-1.0.tar.gz

example2 (extract and apply patch):
packet;1.0;packet-1.0;packet-1.0.tar.gz:packet.diff;extract:packet-1.0.tar.gz;patch:packet.diff

=rules-install=
If everything related to the installation will be taken care of by Makefile.am
you can simply add just one line here containing the identifier.

Else you might want to add an entry like this:

packet;make:install:DESTDIR=TARGET

You can state multiple commands which have to be separated by semicolons.
The commands and their parameter(s) are separated by colons.

DESTDIR=TARGET is used to inform 'make' about the path of the cdkroot.
But of course this is not valid for all packets, some might use different variable
names or you will need to add parameters like --prefix while running their
'configure'-scripts.

=configure.ac=
Choose a suitable section here (take the existing entries as a guide)
and either add TUXBOX_RULES_MAKE(...) or TUXBOX_RULES_MAKE_EXDIR(...). Replace
the three dots by the unique identifier you chose in rules-make.

TUXBOX_RULES_MAKE(packet)

Creates variables from the information you gave in rules-install and rules-make.
These variables can be used later inside Makefile.am. The following variables
will be defined:

DEPENDS_packet - archive(s) and patch(es) necessary to build the packet
PREPARE_packet - expands to commands for extracting and patching the packet
DIR_packet - name of the directory to which the archive has been unpacked to
INSTALL_packet - expands to commands for installing the packet
CLEANUP_packet - expands to commands responsible for removing the sourcecode and build files
no longer needed after building and installing the packet. Note that this
does NOT remove the downloaded archive.

TUXBOX_RULES_MAKE_EXDIR(packet)

same as above but the difference being that you use it for packets that do not get built
inside their sourcedirectory. Additionally the variable CONFIGURE_packet is defined which
expands to a command executing the configure-script of the packet.

=Makefile.am=
If you know your way around Makefile.am you should have no trouble. This file contains
commands and variables that are used to create the final Makefile when 'configure'
is run and serves as a kind of basis.

If you create rules for 'make' that belong to a packet then add a dot in front of the
name. The last command used is "touch $@". This command will create a file with the
name of the currently used rule which indicates that the rule was sucessfully executed.

Example for a rule:

.paket: .bootstrap @DEPENDS_packet@
@PREPARE_packet@
cd @DIR_packet@ && \
$(BUILDENV) \
./configure \
--build=$(build) \
--host=$(target) \
--prefix= && \
$(MAKE) all && \
@INSTALL_packet@
@CLEANUP_packet@
touch $@

$(BUILDENV) is a macro that expands to widely used environmental variables like
CC, CFLAGS etc.
Then and now you might encounter a packet that needs additional or different variables.
You can add these below $(BUILDENV) in a rule. Take a look at Makefile.am for examples.

Furthermore there are some rules in Makefile.am which group the single packet rules
to useful group-rules (for exmaple "libs"). These rules might be further grouped until
finally there is an "all"-rule.

Take a look at the group-rules and think where your newly added rule might fit best.

example:
devel = .gdb .strace .packet

At the end of Makefile.am you will find a section that deals with cleaning up the
environment in case you want to start from anew. You need to add your packet's rulename
here to remove the file that has been created by 'touch' when the packet was built and
which would prevent the packet from being rebuilt.

==see also==
siehe auch
*[[Development:Newmake.3rdparty|Create 3rdparty Tools with Newmake de]]
*[[Development:Newmake.3rdparty.en|Create 3rdparty Tools with Newmake en]]

{{body}}

Dbox2:Development:README.3rdparty.de (Oldmake) veraltet

2008-08-11T15:25:17Z

Dixidix: Verweise hinzugefügt

[[Category:Register]]
[[Category:CDK]]
[[Category:FAQ]]
[[Category:Development]]
{{Development_sidebar}}
__TOC__
{{English|Development:README.3rdparty.en}}

=Allgemeines=
==Und so baut man neue Tools in das cdk ein==
Zunächst macht man sich Gedanken darüber, ob das, was man einbauen will, Sinn
macht. Wenn man meint, die Idee wäre gut, dann kann man anfangen sie zu
integrieren.

Handelt es sich hierbei um eigene Software oder um bis zur Unkenntlichkeit
veränderte Software, so ist das hier nicht das passende Dokument.
Handelt es sich hingegen um veränderte Software anderer Leute, so nehme man den
unveränderten Quellcode und erstelle dazu ein passendes Patch. Das geht mit
dem Kommando
"diff -Naur paket.orig paket > paket.diff"
Der erstellte Patch gehört in das Verzeichnis
$HOME/tuxbox-cvs/cdk/Patches.
Es werden keine Versionsinformationen an den Dateinamen angehängt.

Was nun noch fehlt sind ein paar Eintraege in folgenden Dateien:
$HOME/tuxbox-cvs/cdk/Makefile.am
$HOME/tuxbox-cvs/cdk/configure.ac
$HOME/tuxbox-cvs/cdk/rules-archive
$HOME/tuxbox-cvs/cdk/rules-make
$HOME/tuxbox-cvs/cdk/rules-install

=Beginnen wir mit rules-archive=
Hier gehört genau eine Zeile pro Paket hinein, und zwar der Name des Archivs,
sowie eine oder mehrere http- oder ftp-Adressen, von denen das Archiv direkt
geladen werden kann. Diese werden mit Semikolon voneinander getrennt.

z.B.
paket-1.0.tar.gz;<nowiki>http://www.pakethome.de/download</nowiki>

=Als nächstes zu rules-make=
Wieder braucht man eine Zeile pro Paket und wieder werden die Einträge mit
Semikolon getrennt. Diesmal sind es allerdings ein paar mehr und zwar die
Folgenden:

- Bezeichner fuer die Software
- Versionsnummer der Software
- Verzeichnisname nach dem entpacken der Software
- Archivname und Name eventueller Patches (durch Doppelpunkt getrennt)
- Eine oder mehrere Regeln zum Bearbeiten des Archivs und vorhandender Patches

Der Bezeichner wird wieder in rules-install, configure.ac und Makefile.am zum
Einsatz kommen. Er ist prinzipiell frei wählbar, sollte aber dennoch möglichst
viel mit dem Paketnamen gemeinsam haben.

Was mit Versionsnummer gemeint ist sollte jedem klar sein.

Der darauf folgende Verzeichnisname muss dem Pfad entsprechen, der in dem zu
entpackenden Archiv gespeichert ist. Ist kein Pfad gespeichert, so muss man
einen Pfad möglichst sinnvoll wählen und später bei den Regeln anstatt
extract dirextract verwenden.

Archivname sollte auch klar sein. Falls zusätzliche Dateien existieren, die
für das Paket benutzt werden, seien es diffs oder zusätzliche Archive, so
gibt man deren Namen ohne Verzeichnis und durch Doppelpunkt getrennt an.

Zu guter letzt traegt man die Regeln ein, nach denen mit dem Archiv und seinen
Patches verfahren werden soll:
extract - extrahiert ein Paket
dirextract - extrahiert ein Paket in das angegebene Verzeichnis
patch - patcht eine diff Datei in ein extrahiertes Paket

Für weitere Regeln kann man einen Blick in die Datei rules-make werfen.

z.B. sieht das dann so aus;
paket;1.0;paket-1.0;paket-1.0.tar.gz;extract:paket-1.0.tar.gz

oder falls ein patch vorhanden ist:
paket;1.0;paket-1.0;paket-1.0.tar.gz:paket.diff;extract:paket-1.0.tar.gz;patch:paket.diff

=rules-install ist wieder kürzer=
Falls die Installation von Hand im Makefile.am geregelt wird, reicht es, hier
den Bezeichner in eine eigene Zeile zu schreiben. Ansonsten nimmt man in der
Regel folgenden Eintrag:

paket;make:install:DESTDIR=TARGET

Es können mehrere Befehle angegeben werden, diese sind per Semikolon von
einander zu trennen. Befehle und zugehörige Parameter werden durch Doppelpunkt
getrennt.
DESTDIR=TARGET wird benutzt, um make den Pfad des cdkroots mitzuteilen. Einige Pakete
benutzen davon abweichende Variablennamen oder können ausschließlich ueber --prefix
zur configure-zeit den Zielpfad mitgeteilt bekommen.

=configure.ac=
Hier sucht man sich die passende Sektion in der Datei aus (an den vorhandenen
Einträgen orientieren) und fügt dort entweder TUXBOX_RULES_MAKE(...) oder
TUXBOX_RULES_MAKE_EXDIR(...) ein. Anstatt der Punkte benutzt man den in
rules-make gewählten Bezeichner.

Beispiel:
TUXBOX_RULES_MAKE(paket)

erstellt Variablen, aus den Daten in rules-install, rules-make und
rules-install, die in Makefile.am benutzt werden koennen. Es werden die
folgenden Variablen definiert:
DEPENDS_paket - benötigte Archive und Patches
PREPARE_paket - Kommandos zum extrahieren und patchen des Paketes
DIR_paket - Name des Verzeichnisses, in das entpackt wurde
INSTALL_paket - Installationsbefehle
CLEANUP_paket - Befehle zum Entfernen von Dateien nach Bau und Installation

TUXBOX_RULES_MAKE_EXDIR(paket)

tut prinzipiell dasselbe, hat jedoch den Unterschied, dass es für Pakete
benutzt wird, bei denen das Bauen nicht im Quellverzeichnis selbst passieren
soll. Zusätzlich wird die folgende Variable definiert:
CONFIGURE_paket - Aufruf des Konfiurationsskriptes des Paketes

=Makefile.am=
Wer Makefiles kennt, der hat es leicht. Diese Datei ist sozusagen der Rohbau
des Makefiles und unterscheidet sich nur durch die Variablen, die durch den
Aufruf von configure ersetzt und in ein Makefile geschrieben werden.

Regeln, die zu einem Paket gehören, werden wie der oben gewählte Bezeichner
mit einem Punkt vorangestellt genannt.

Am Ende jeder Regel steht '''"touch $@"'''. Dieser Befehl erstellt eine Datei mit
dem Namen der aktuellen Regel. Dadurch wird gekennzeichnet, dass eine Regel
vollständig durchlaufen wurde.

Beispiel für eine Regel:

.paket: .bootstrap @DEPENDS_packet@
@PREPARE_packet@
cd @DIR_packet@ && \
$(BUILDENV) \
./configure \
--build=$(build) \
--host=$(target) \
--prefix= && \
$(MAKE) all && \
@INSTALL_packet@
@CLEANUP_packet@
touch $@

$(BUILDENV) ist ein Makro, das eine Menge an oft gebrauchten Umgebungsvariablen
enthält, wie z.b. CC, CFLAGS usw.
Ab und zu kann es vorkommen, dass ein Paket andere oder zusätzliche Variablen
braucht. Diese können unterhalb von $(BUILDENV) angegeben werden. Beispiele
dazu findet man im Makefile.am.

Weiterhin gibt es in Makefile.am Regeln, die verschiedene Regeln gruppieren
und letztendlich zu einer globalen Regel ("all") zusammengefasst werden.
Dort, wo das hinzugefügte Paket kategorisch am besten einzuordnen ist, fügt
man den Eintrag hinzu, z.B.

devel = .gdb .strace .paket

Am Ende der Datei ist die Regel zum Säubern der Umgebung zu finden. Auch
hier muss man an geeigneter Stelle den Regelnamen aufführen, so dass die
Markierung, die nach erfolgreichem Bauen angelegt wurde, entfernt werden
kann.

==Verweise==
siehe auch
*[[Development:Newmake.3rdparty|Tools mit Newmake einbauen de]]
*[[Development:Newmake.3rdparty.en|Tools mit Newmake einbauen en]]

{{body}}

Dbox2 Entwicklungsumgebung

2008-07-30T15:41:06Z

Dixidix: Auschecken präzisiert

[[Category:Register]]
[[Category:Development]]
[[Category:CDK]]
{{Development_sidebar}}

__TOC__
{{Review}}
=Allgemeines=
Newmake ist eine Überarbeitung des alten "[[Make|make]]" Prozesses, inzwischen auch als [[Image erstellen|Oldmake]] bezeichnet, und wurde durch Barf ins Leben gerufen.
Neben einer deutlich strukturierteren Basis, bietet es unter anderem auch den Vorteil, dass es auch ohne ohne großes Verständnis für den Buildprozess gelingen kann, [[Images|Flashimages]] und [[yadd|YADDs]] unter [[Linux|Linux]] zu erstellen.
Basierend auf Newmake gibt es inzwischen auch eine auf Scripts basierende Quasi-Frontendlösung, mit der sich [[Images|Flashimages]] oder [[yadd|YADDs]] benutzerdefiniert erstellen lassen, das sogenannte [[yBuild]]. 
Dieser Artikel basiert zum größtem Teil auf die deutsche Version von [http://bengt-martensson.de/dbox2/ Barfs Newmake-Dokumentation], die er uns freundlicheweise zur Verfügung gestellt hat.
Eine detaillierte Beschreibung (auch der [[Make|make]] targets) unter anderem auch in englischer Sprache befindet sich auf [http://bengt-martensson.de/dbox2/ Barf's Homepage]. 

Dieser Artikel behandelt Newmake aus Sicht des Benutzers (nicht Entwickler). Es behandelt die [[Image]]- u. [[yadd|YADD]]-Herstellung sowie einfache Beipiele für Benutzeranpassungen ("[[Customization]]"). 

==Zur Geschichte==
Vor einigen Jahren war die Imageherstellung für die [[Tuxbox|Tuxbox]] so etwas wie [[Wikipedia:Schwarze Kunst|"Schwarze Kunst"]].
Die Makefile-Unterstützung war, insbesondere für andere [[Images]] als [[cramfs]]-[[Images]], ziehmlich 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|CVS]]-Verzeichnis ''.../hostapps/[[Mkflfs|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|CVS]]-Sources mit einigen mehr-oder-weniger geheim gehaltenen "Fixes", (vermutlich) notwendig für das Herstellen eines funktionierenden [[Images]] aus dem [[CVS|CVS]]-Quellcode.
 
 
Im August 2003, wurde es für das [[DBox2 Software Projekt|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|Software]]-Design... 
Ein [[Image]] aus reinen [[CVS|CVS]]-Dateien zu bauen, war nicht wirklich möglich.
 
 
2004 wurde das [[YADI]] ("'''Y'''et '''A'''nother '''D'''Box '''I'''mage") Projekt geboren. 
Sein Ziel war es, das "Imagebauen" zu automatisieren und zu vereinfachen. Zu diesem Zweck wurden eine Anzahl von [[Wikipedia:Skripte|Scripten]] und [[Wikipedia:Patches|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|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|Skript]] war das automatische Imagebuilden zwar möglich, jedoch statt grundlegende Schwächen im [[CDK|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, verfügbar als alternativer [[Branch]] im [[CVS|CVS]], versucht diese Schwächen zu beseitigen. 
 
Ein spezieller Dank an jedem, der Bugreports und Feedback geliefert hat. Insbesonderes gilt dies für dietmarw, der Newmake benutzt, um die [[images|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 [[Wikipedia:Skriptsprache|Shellskripten]] wird für viele Teile, insbesondere für das [[Customization]]-Kapitel, aber nicht für [[Image]]/[[yadd|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|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|Images]] bleiben.

= [[Images|Images]] und [[Yadd|YADD]]'s bauen=
== Targets ==
Es gibt neben zahlreichen untergeordneten Zielen (Targets), zwei hauptrangige Targets. Diese wären entweder
*[[YADD]]
oder
*[[Image]].
Ein [[YADD]] besteht aus einigen Dateien, die die DBox anstatt aus dem [[Flash]] ü[[BER|ber]] den [[TFTP]]-Service lädt, sowie ein [[Filesystem|Filesystem]], das ü[[BER|ber]] einen [[NFS-Server]] der dBox zur Verfügung gestellt wird.
 
Diese Betriebsart hat insbesondere während der Softwareentwicklung oder beim Erlernen des Systems viele Vorteile. 
Der Name "[[YADD]]" bedeutet übrigens "'''Y'''et '''A'''nother '''D'''Box '''D'''istribution" ("noch eine dBox Verteilung").

=== Erste Schritte und Überlegungen ===
Eine Empfehlung für den angehenden "[[Image|Image]]/[[Yadd|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|Image]] mit der Lieblings-[[GUI]] zu erstellen.

Meistens möchte man die folgenden Schritte kombinieren und/oder automatisieren.
 
In diesem Artikel bezeichnet "[[GUI]]" entweder
*[[Neutrino]] oder
*[[Enigma]]
*[[Lcars]]
*[[Radiobox]].
 
Das "[[Filesystem]]" im Kontext eines kompletten [[Images]] bezeichnet das [[Dateisystem]], in dem das root-Verzeichnis liegt. Diese kann ein
*[[cramfs]] (ein komprimiertes, Read-only [[Filesystem|filesystem]] für embedded Systeme) sein,
*[[squashfs]] (ein weiterd komprimiertes read-only-[[Dateisystem|Dateisystem]], was leistungsfähiger als [[cramfs]] betrachtet wird)
oder
*[[jffs2]] (ein "journalled" Read-Write-[[Filesystem|Filesystem]]).
Ein "[[Cramfs|cramfs]] Komplett-[[Image|Image]]" besteht aus einem Root-[[Dateisystem|Dateisystem]] mit dem [[cramfs]] [[Dateisystem|Dateisystem]] und einem kleineren [[jffs2]]-[[Filesystem|Filesystem]], das nach '''/var''' gemounted wird.
 
Analog gilt dies auch für "'''[[Squashfs|squashfs]] Komplett-[[Images|Images]]'''", während ein "'''[[Jffs2|jffs2]] Komplett-[[Image|Image]]'''" kein separates ''/var-[[Dateisystem|Dateisystem]]'' enthält, weil [[Jffs2|jffs2]] an sich beschreibbar (var) ist.
 
Zusätzlich enthalten die Komplett-[[Images|Images]] eine weitere [[Partition|Partition]], die den [[u-boot]]-[[Bootloader]] enthalten. Diese [[Partition|Partition]] ist zwischen dBoxen mit einen und zwei Flashchips unterschiedlich. Dieses wird durch "'''1x'''" und "'''2x'''" angezeigt. Ein komplettes [[Image|Image]] würde demnach so benannt werden:

[neutrino, enigma]-[cramfs, squashfs, jffs2].img[1, 2]x,
z.B. als fertiges [[Image|Image]]:
[[Neutrino|neutrino]]-[[Jffs2|jffs2]].img2x.

== Buildsystem Voraussetzungen ==
Die Voraussetzungen auf dem Buildhost können in etwa so zusammengefasst werden:
 
Ein modernes [[Unix|Unix]]/[[Linux|Linux]] System mit ca. 2 GB freiem Speicherplatz. Epfehlenswert ist es aber mehr Speicherplatz einzuplanen, da beispielsweise bei Verwendung von [[ccache]] einiges an Daten zwischengelagert wird und je öfter man kompiliert, es dann doch eng werden könnte.

Das [[DBox2 Software Projekt|Tuxbox Projekt]] hat keine favorisierte Buildumgebung. Fragen wie "geht es mit Redhat x.y?" lassen sich nicht genau beantworten. Der Grund hierfür ist, dass niemand sich wirklich dafür interessiert, die Eigenschaften der bestimmten Distributionen zu erkunden. Gewisse Anforderungen werden dagegen für Versionen der Werkzeuge, wie [[WP:autoconf|autoconf]], [[WP:automake|automake]], [[make]] usw. formuliert. Die meisten davon sind in den gängigsten Distributionen bereits enthalten bzw. können nachinstalliert werden. Die momentan erfordelichen Toolversionen sind in folgendender Tabelle zusammengefasst:
 
{{Vorlage:GNU_Tools}}
 
Der Buildprozess überprüft zu Beginn automatisch einige dieser Anforderungen. Wenn eines dieser [[Tools|Tools]] 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|Anleitungen]] zum Buildvorgang wird gefordert, dass [[Tools|Tools]] 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
erfordelich, da einige entweder überhaupt nicht benötigt werden bzw. die [[Installation|Installation]] im
Makeprozess selbst vorgenommen wird!
 ''
Builden auf einem [[Unix|Unix]]-non-[[Linux|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|GNU]]-[[Erweiterungen|Erweiterungen]] uneingeschränkt verwendet werden.
 
Es wird daher davon abgeraten eine Umbegebung z.B. mit [[Cygwin]] aufzubauen, da es höchstwahrscheinlich nicht funktionieren wird. In dieser Richtung wurde zwar Einiges für den Makeprozess eingebaut, jedoch dürfte der gegenwärtige Entwicklungsstand nicht den gegenwärtigen Anforderungen entsprechen, um aktuell auch damit arbeiten zu können.
 
Empfehlenswert ist allerdings 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.

== Auschecken ==
Die [[Tuxbox|Tuxbox]] Quellen werden durch den [[Tuxbox|Tuxbox]] [[CVS-Server]] bereitgestellt. 
Regelmäßige Quellreleases sind niemals gemacht worden, und sind auch nicht für die Zukunft geplant. Für unsere Zwecke werden die Quellen anonym "ausgecheckt", was bedeutet, dass diese auf die eigene Festplatte kopiert werden, indem man zuerst auf einer (lokalen) Festplatte mit "ordentlich" freiem Platz ein leeres Verzeichnis erstellt, z.B. ''/[[Tuxbox|tuxbox]]-[[CVS|cvs]]'' und in diesen Ordner wechselt, und diesen Befehl ausführt.

[[CVS|cvs]] -d anoncvs@[[CVS|cvs]].[[Tuxbox|tuxbox]].org:/[[CVS|cvs]]/[[Tuxbox|tuxbox]] -z3 co -f -r newmake -P .

Da sich ''Newmake'' (noch) nicht im [[HEAD]] des [[CVS]] befindet, sondern als getrennter [[Branch]] bzw. Zweig im [[CVS]] vorliegt, checkt diese Anweisung nun die benötigen Newmake-Files aus. In Fällen, in denen keine Newmake Version vorhanden ist, wird die HEAD-Version ausgecheckt.
Lokal werden die HEAD-Files allerdings auch als Newmake markiert, was aber für anonyme Nutzer nicht von Belang sein dürfte. Entwickler müssen dies aber beachten, da es beispielsweise bei Commits zu unerwünschten Ergebnissen kommen könnte.

'''Hinweis:'''
''Im HEAD gibt es zwei Files:''
*[[CDK|cdk]]/root/etc/init.d/rcS
''und''
*[[CDK|cdk]]/root/etc/init.d/rcS.insmod
''Im [[Newmake]] werden diese nicht benötigt da sie mittels''
[[CDK|cdk]]/root/etc/init.d/rcS.m4
''erzeugt werden.''
''Um auf der sicheren Seite zu sein, ist es ratsam, diese beiden zu löschen, daher bietet es sich an, dies gleich im Anschluß an den Checkout mit einer entsprechenden Anweisung zu erledigen''.

rm -f [[CDK|cdk]]/root/etc/init.d/rcS.insmod
rm -f [[CDK|cdk]]/root/etc/init.d/rcS

Nachdem die Daten ausgecheckt wurden, könnte kann man jetzt einige Patches auf die Quellen anwenden. 
Wenn man aber zum ersten Mal kompiliert, ist es 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|CVS]] Quellen" verwendet.

== Konfiguration ==
Jetzt müssen einge Zwischenschritte erledigt werden, damit der Buildprozess auch erkennt, was und vorallem wie er es machen soll.
 
Man wechselt nun in das [[CDK|CDK]]-Unterverzeichnis
cd [[CDK|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|Images]], [[Yadd|YADD]] oder aller anderen gewünschten Ziele entsprechend den Benutzerwünschen vorzubereiten.

=== Optionen ===
{{Newmake_Build_Optionen}}

Für uns sind vorerst nur wenige Optionen interessant. Die Standardvorgaben reichen vorerst völlig aus. 
Eine typische Anwendung (Konfiguration), der mit z.B. den Pfadnamen oben kompatibel wäre, könnte so eingestellt werden:

./configure --with-cvsdir="/[[Tuxbox|tuxbox]]-[[CVS|cvs]]" --prefix="/[[Dbox2|dbox2]]" --enable-maintainer-mode

*''--with-cvsdir''
sagt wo die Quellen zu finden sind, (darin sollte auch ein Unterverzeichnis ''.../[[CDK|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|Makefiles]] ermöglicht, sich automatisch neu zu erzeugen, sobald die Notwendigkeit entsteht, zum Beispiel nach einem [[Software|Software]]-[[Update|Update]].

Es gibt sicher noch andere nützliche Optionen. Einige werden später noch besprochen.

=== 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|tuxbox]] [[Mklibs|mklibs]]
checking for mkcramfs... no
configure: WARNING: using [[Tuxbox|tuxbox]] [[Cramfs|cramfs]]
checking for mkjffs2... no
checking for [[Mkfs.jffs2|mkfs.jffs2]]... no
configure: WARNING: using [[Tuxbox|tuxbox]] [[Mkfs.jffs2|mkfs.jffs2]]
checking for mksquashfs... no
configure: WARNING: using [[Tuxbox|tuxbox]] [[Squashfs|squashfs]]
...

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

'''''Beachte!'''
Wenn man diesen Artikel mit ähnlichen Beschreibungen aus vergangenen Zeiten
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.
 ''
 
[[Bild:Stop hand.png]]
<div style="margin: 0; margin-top:10px; margin-right:0px; border: 3px solid #FF0000; padding: 0px 10px 1px 10px; background-color:#DEB0B0; align:right; ">
'''
Versuche niemals, als root zu bauen!'''
</div>

== Kompilieren ==
Die high-level [[Make|make]] Targets, die für das Builden von Komplett-[[Images|Images]] relevant sind, lauten:
*<pre><nowiki>flash-</nowiki>[neutrino, enigma, all]</nowiki></pre>
*<pre><nowiki>flash-</nowiki>[cramfs, squashfs, jffs2, all]</nowiki></pre>
*<pre><nowiki></nowiki>[1x, 2x, alle]</nowiki></pre>
Für [[Yadd|YADD]]-Builds, sind diese:
*<pre><nowiki>yadd-</nowiki>[neutrino, enigma, all]</nowiki></pre>
'''Beispiele:'''

[[Make|make]] [[Flash|flash]]-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]-all

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

'''der Befehl:'''

[[Make|make]] [[Yadd|yadd]]-[[Enigma|enigma]]

erzeugt ein [[Yadd|YADD]], das [[Enigma|Enigma]] enthält.

=== 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|make]] [[Yadd|yadd]]-[[Neutrino|neutrino]]''' mit leeren Verzeichnissen etwa 1 und 1,5 Stunden.

==== Verwendung von [[Ccache|ccache]] ====
Um den Vorgang insbesondere bei wiederholten Kompilieren und besonders auf langsameren Rechnern zu beschleunigen, steht die Option
* --enable-[[Ccache|ccache]]
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|ccache]]''' wird erreicht, sollte das Tool bereits in deiner Distribution installiert sein, dass [[ccache]] automatisch erkannt wird und in das [[Tuxbox|Tuxbox]]-[[CDK|CDK]] eingebunden wird. Ist es nicht installiert, wird dies auch von configure angezeigt:
...
----------------------------------------
[[Ccache|ccache]] support: no
[[Ccache|ccache]] installdir:
[[Ccache|ccache]] is not installed please run [[Make|make]] [[Ccache|ccache]] or install it and configure again
----------------------------------------
...
Dann sollte man das Tool nachinstallieren oder mit dem Target
[[Make|make]] [[Ccache|ccache]]
in das [[CDK|CDK]] einbauen und configure wiederholen.

'''Hinweis'''
 
''[[Ccache]] macht sich erst bemerkbar, nachdem der Buildvorgang mindestens einmal durchgelaufen ist!''

Die Option ''--enable-[[Ccache|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-ccachedir=DIR
Diese Option kann man verwenden, wenn man [[ccache]] beispielsweise nur als Binary abgelegt hat und den Pfad dazu bestimmen möchte.
 
'''Hinweis'''
 
''Die Option '''--with-ccachedir''' bewirkt auch das die mit '''[[Make|make]] [[Ccache|ccache]]''' installierte Version im [[CDK|CDK]] und/oder auch die evtl. im System installierte Version ignoriert wird!''

*--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|ccache]] -s
prüfen. Als Ergebnis werden einige Statistiken ü[[BER|ber]] das Cache-Verhalten von [[Ccache|ccache]] ausgegeben:
cache directory /home/<USER>/.[[Ccache|ccache]]
cache hit 4
cache miss 191
called for [[Link|link]] 17
multiple source files 4
compile failed 17
preprocessor error 2
not a C/C++ file 5
autoconf compile/[[Link|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|make]] [[Yadd|yadd]]-[[Neutrino|neutrino]]
Am Ende des Bauvorganges werden damit die entsprechenden Zeitinformationen ausgegeben.

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

==== [[Neutrino|neutrino]]-[[Jffs2|jffs2]]-[[Image|Image]] ====
#! /bin/bash
# beispiel.sh
# Diese Script baut [[Neutrino|neutrino]]-[[Jffs2|jffs2]] [[Images|Images]], jeweils 1x und 2x
#----------------------------------------------
USERDIR=/home/$(whoami)
#----------------------------------------------
LOGODIR=$USERDIR/Logos
CP=$USERDIR/[[Tuxbox|tuxbox]]-[[CVS|cvs]]
DB=$USERDIR/[[Dbox2|dbox2]]
ARCHIVEDIR=$USERDIR/Archive
export CVS_RSH=[[SSH|ssh]]
#-----------------------------------------------
cd "$CP"
[[CVS|cvs]] -d anoncvs@[[CVS|cvs]].[[Tuxbox|tuxbox]].org:/[[CVS|cvs]]/[[Tuxbox|tuxbox]] -z3 co -f -r newmake -P .
cd [[CDK|cdk]]
/bin/ln -sf $ARCHIVEDIR/ Archive
./autogen.sh
./configure --prefix="$DB" --with-cvsdir="$CP" --enable-flashrules --enable-[[Ccache|ccache]] --with-[[CheckImage|checkImage]]=rename --with-logosdir="$LOGODIR"
[[Make|make]] [[Flash|flash]]-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]-all

==== [[Neutrino|Neutrino]] [[Yadd|YADD]] ====
#! /bin/bash
# beispiel.sh
# Diese Script baut ein [[Neutrino|Neutrino]] [[Yadd|Yadd]]
#----------------------------------------------
USERDIR=/home/$(whoami)
#----------------------------------------------
LOGODIR=/Logos
CP=$USERDIR/[[Tuxbox|tuxbox]]-[[CVS|cvs]]
DB=$USERDIR/[[Dbox2|dbox2]]
ARCHIVEDIR=$USERDIR/Archive
export CVS_RSH=[[SSH|ssh]]
#-----------------------------------------------
cd "$CP"
[[CVS|cvs]] -d anoncvs@[[CVS|cvs]].[[Tuxbox|tuxbox]].org:/[[CVS|cvs]]/[[Tuxbox|tuxbox]] -z3 co -f -r newmake -P .
cd [[CDK|cdk]]
/bin/ln -sf $ARCHIVEDIR/ Archive
./autogen.sh
./configure --prefix="$DB" --with-cvsdir="$CP" --with-logosdir="$LOGODIR" --enable-[[Ccache|ccache]]
[[Make|make]] [[Yadd|yadd]]-[[Neutrino|neutrino]]

= Kernel 2.6.x =

{{Bulid_kernel_26}}

= Was kommt dann...? =
== Booten von [[Yadd|YADD]] ==
Wenn ein [[Yadd|YADD]] frisch erzeugt wurde, kann damit auch die Box booten. Näheres dazu auch im Artikel [[CDK booten]]. 
Newmake hält auch ein [[Make|Make]]-Target für den serversupport bereit.
[[Make|make]] serversupport
Dieses erzeugt einige Konfigurationsdateien für den [[Server|Server]] der das [[Yadd|YADD]]-Build nahtlos an das [[Server|Server]]-Setup anknüpft.

== [[Flashen|Flashen]] des [[Images|Images]] ==
Wenn ein [[Image|Image]] gebaut wurde, ist der logische nächste Schritt das Einspielen des [[Images|Images]] in den [[Flash|Flash]] der Box. Hierfür ist entweder, das interaktive [[Flashen|Flashen]] innerhalb der [[GUI|GUI]] mit den [[Installation:Neutrino|Expertenfunktionen]] zu benutzen, oder der ''dboxflasher'' zu verwenden. Der ''dboxflasher'' wird durch das [[Make|Make]]-Target
[[Make|make]] serversupport
erzeugt. 
Siehe auch [[Installation]].

== Inkrementelle Builds ==
Im allgemeinen ist man nicht an einem einmaligen Build der [[Software|Software]] interessiert. Verbesserungen an den Quellen werden in das [[CVS|CVS]] täglich eingecheckt. Oft möchte man die [[Software|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|make]] [target]
und [[Make|make]] wird es, falls notwendig, neu erzeugen.

Es kann auch passieren, dass [[Make|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|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|Installation]] eines bestimmten Pakets wird durch das Anlegen einer Markerdatei im Verzeichnis ''[[CDK|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|make]] distclean
Das drastischste Reinigungs-Target, (fast) alles löschend, was nicht vom [[CVS|CVS]] ausgecheckt wurde.
Dieses ist eher selten notwendig.
 
[[Make|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|Yadd]]-[[Installation|Installation]]), sowie die [[Tftp|TFTP]]-Files ([[Kernel|Kernel]] und [[U-boot|u-boot]]) werden nicht angefasst.
 
[[Make|make]] depsclean
Löscht alle Markerdateien im /[[CDK|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|make]] clean
Kombiniert ''mostlyclean'', ''depsclean'', und ''[[Flash|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|make]] bootstrap''.
 
[[Make|make]] [[Flash|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|make]] [[Flash|flash]]-mostlyclean
Zusätzlich zum ''[[Flash|flash]]-semiclean'' löscht dieses Target auch Bootfiles und die Kernbauverzeichnisse. Vollimages werden unberührt gelassen.
 
[[Make|make]] [[Flash|flash]]-clean
Dieses Target löscht Alles in $(flashprefix).
 
Einige Quellverzeichnisse können mit einem Befehl wie
[[Make|make]] -C /[[Tuxbox|tuxbox]]-[[CVS|cvs]]/apps/[[Tuxbox|tuxbox]]/[[Neutrino|neutrino]] clean
gesäubert werden.

== Aktualisierung des [[CVS|CVS]]-Quellcodes ==
Um die Quellen mit neueren Checkins zu aktualisieren, verwende diesen Befehl für das toplevel [[CVS|CVS]] Verzeichnis (oder von einem anderen Verzeichnis, wenn Ihr wisst, was ihr tut;-). Mögliche Fehler werden in das logfile [[CVS|cvs]].log geschrieben.

[[CVS|cvs]] up -f -r Newmake -dP > [[CVS|cvs]].log 2>&1

'''Tipp'''
 
Um mit dem [[CVS|CVS]] arbeiten zu können nimmt man für gewöhnlich die Konsole für Eingaben. Es gibt aber auch verschiedene Frontendwerkzeuge wie z.B. [http://www.crossvc.com CrossVC] oder [http://cervisia.kde.org/ Cervisia] um nur einige zu nennen, die einen recht komfortablen Umgang mit den [[CVS|CVS]]-Daten ermöglichen. [[Bild:Crossvc.jpg|CrossVC als CVS Frontendlösung]] [[Bild:Cervisia.jpg|Cervisia als CVS Frontendlösung]] 
Auch einige [[IDE|IDE]]'s wie z.B. [[WP:Anjuta|Anjuta]] [[Bild:anjuta.jpg|Anjuta als IDE mit CVS-Anbindung]] bieten solche [[CVS|CVS]]-Schnittstellen an.

== [[Customization|Customization]] ==
Bisher lief immer alles darauf hinaus [[Images|Images]] oder Yadds zu bauen, die aus unveränderten [[CVS|CVS]]-Quellen gebaut wurden. 
[[Images|Images]] und die Yadds können aber auch angepasst ("customized") werden, ohne die [[Makefiles|Makefiles]] zu ändern.
 
Hier gibt es verschiedene Möglichkeiten.

=== Konfigurationsoptionen ===
hier einige nützliche Optionen: 
Hiermit kann ein Verzeichniss angegeben werden, welches die [[Ucodes|Ucodes]] enthält, die im [[Image|Image]] enthalten sein sollen.
--with-ucodesdir=[DIR]
'''Hinweis:''' 
Ein [[Image|Image]], dass [[Ucodes|ucodes]] enthält, darf
nicht verbreitet werden! 
 
 
Mit der Option
--with-logosdir=[DIR]
kann ein Verzeichniss angegeben werden, das boot-logos (logo-[[LCD|lcd]] und logo-fb) enthält, die im [[Image|Image]] enthalten sein sollen.
 
 
Diese Option
--with-defaultlocale=[LOCALE]
sorgt dafür, dass die gewünschte Sprache schon beim bauen eingestellt wird.

=== Ändern der Partitionierung ===
Die Rootpartitionsgröße für [[Cramfs|cramfs]] und [[Squashfs|squashfs]] [[Images|Images]] kann mit der Configure-Option
--with-rootpartitionsize=[SIZE]
angegeben werden.
 
Die Größe der var-[[Partition|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|jffs2]]-Imageerstellung unsinnig wäre.

=== Variablen ===
==== Pfade ====
Es sind noch weitere Benutzeranpassungen möglich. Dafür ist es aber notwendig, etwas [[Wissen|Wissen]] ü[[BER|ber]] die innere Funktionsweise der [[Makefiles|Makefiles]] zu haben. 
In der Folge bezeichnet
$(flashprefix)
den Wert der Makefile Variablen '''flashprefix''' (mit Konfiguration wie oben '''/[[Dbox2|dbox2]]/cdkflash''')
$(targetprefix)
bezeichnet den Wert der Makefile Variablen '''targetprefix''' (mit Konfiguration wie oben '''/[[Dbox2|dbox2]]/cdkroot'''), und
$(buildprefix)
bezeichnet den Wert der Makefile Variablen '''buildprefix''' (mit der Konfiguration oben '''/[[Tuxbox|tuxbox]]-[[CVS|cvs]]/[[CDK|cdk]]''').
 
 
Um z.B. ein '''[[Neutrino|neutrino]]-[[Cramfs|cramfs]].img2x''' zu erzeugen, werden die folgenden Verzeichnisse erstellt: 
*'''$(flashprefix)/root''' (enthält [[Filesystem|Filesystem]]- und [[GUI|GUI]]-unabhängige Bestandteile)
*'''$(flashprefix)/root-[[Cramfs|cramfs]]''' (enthält den [[Kernel|Kernel]], für Root-[[Filesystem|Filesystem]] auf [[Cramfs|cramfs]] konfiguriert, zusammen mit seinen Treibern) und
*'''$(flashprefix)/root-[[Neutrino|neutrino]]''' (enthält die Neutrinoinstallation).
 
Aus diesen drei Verzeichnissen, werden das Rootfilesystemverzeichniss
*'''$(flashprefix)/root-[[Neutrino|neutrino]]-[[Cramfs|cramfs]]''' und das
var-filesystemverzeichnis
*'''$(flashprefix)/var-[[Neutrino|neutrino]]''' gebaut.
 
Hiermit ist es möglich, einen Befehl wie
[[Make|make]] $(flashprefix)/root-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]
bzw. wenn man sich im Verzeichnis ''./[[Tuxbox|tuxbox]]-[[CVS|cvs]]/[[CDK|cdk]]'' befindet, den Befehl
[[Make|make]] root-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]
einzugeben, wobei man bei erster VAriante natürlich '''$(flashprefix)''' selbst durch den realen Pfad ersetzen muss, da '''$(flashprefix)''' nur eine [[Make|make]]-Variable ist, welche in unserem Beispiel den Pfad zu '''./[[Dbox2|dbox2]]/cdkflash''' darstellt. 
Man kann so manuell gewünschten Änderungen an '''$(flashprefix)/root-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]''' vornehmen, und dann, mit dem Befehl
[[Make|make]] [[Flash|flash]]-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]-2x
den Imagebau abschließen, um ein [[Image|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|Customization]]-Scripte ===
Sofern diese Scripte vorhanden und ausführbar sind, werden innerhalb der wichtigsten Targets diese sogenannten ''[[Customization|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|cdk]]'''-Ordner.
Bei Bedarf kann mit der Option
--with-customizationsdir=[DIR]
ein alternatives Verzeichnis für [[Customization|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|Shell]]-Scripts könnte dies z.B. ein kompiliertes C Programme, oder ein [[Perl|Perl]]-Script sein. 
Der Name eines [[Customization|Customization]] Scriptes besteht in der Regel aus dem Namen eines Targetverzeichnisses bzw. einem Target und dem angefügtem *'''-local.sh'''. 

==== Für [[Flash|Flash]]-Targets ====
Der Name der [[Customization|Customization]] Scripte für [[Images|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
*[[Neutrino|neutrino]]
*[[Enigma|enigma]]
*[[Lcars|lcars]]
*[[Radiobox|radiobox]]
 
"[[FS]]" zeigt an welches [[Filesystem|Filesystem]] gemeint ist.
*[[Cramfs|cramfs]]
*[[Squashfs|squashfs]]
*[[Jffs2|jffs2]]
 
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|neutrino]]-local.sh
root-[[Neutrino|neutrino]]-[[Squashfs|squashfs]]-local.sh
root-[[Squashfs|squashfs]]-local.sh
var-[[Neutrino|neutrino]]-local.sh

==== Für [[Yadd|Yadd]]-Targets ====
Für Yadds ist das Prinzip ähnlich, nur dass es hier quasi nur einen Ordner gibt. Dafür stellvertretend steht dann
*[[Yadd|yadd]]. 
Das "[[GUI]]" in Klammern bezeichnet auch hier die jeweilig betroffene Benutzeroberflche, also
*[[Neutrino|neutrino]]
*[[Enigma|enigma]]
*[[Lcars|lcars]]
*[[Radiobox|radiobox]]
 
so wäre die Bezeichnung der jeweiligen Scripte so aufgebaut.
*[[Yadd|yadd]]-[GUI]-local.sh
'''Beispiel:'''
[[Yadd|yadd]]-[[Neutrino|neutrino]]-local.sh

==== für andere Targets ====
Die bisher benannten [[Customization|Customization]] Scripte für [[Flash|Flash]]- u. [[Yadd|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|make]] hdparm
aus, wird beim Bauen das ausgeführt was im [[Customization|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 [[Newmake#.2F.version_anpassen|Anpassung .version-File]]): 
Während des [[Make|make]]-Durchlaufs werden einige Targets ausgeführt, welche die '''/.version'''-Files bei [[YADD]]
*'''version'''
bzw.
*'''[[Flash|flash]]-version'''
im [[Image]] erstellt.
 
Sofern eines dieser Scripte;
*'''version-local.sh'''
*'''[[Flash|flash]]-version-local.sh'''
vorhanden und ausführbar ist, wird es als Ersatz statt des originalen Targets ausgeführt, welches mit
[[Make|make]] version
bzw.
[[Make|make]] [[Flash|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|jffs2]]-[[Image|Image]] wird dies gewünscht:

1. Eigene /etc/hosts benutzen,
2. Eigene [[Neutrino|neutrino]].conf, [[Bouquets|bouquets]].[[XML|xml]], services.[[XML|xml]] benutzen
3. einschließlich [[Lirc|lirc]]-Komponenten, zusammen mit eigenen [[Lirc|lirc]] Konfigurations-Dateien.

1. und 3. sind [[Erweiterungen|Erweiterungen]], die nach '''$(flashprefix)/root''' kommen sollten, während 2. [[Neutrino|Neutrino]]-regeln sind, welche nach sollten '''$(flashprefix)/root-[[Neutrino|neutrino]]-[[Jffs2|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|make]] flashlirc
cp -fr $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Lirc|lirc]] $newroot/var/[[Tuxbox|tuxbox]]/config

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

#!/bin/sh
# root-[[Neutrino|neutrino]]-local.sh
flashprefix=$1
buildprefix=$2
newroot=$flashprefix/root-[[Neutrino|neutrino]]
myfiles=/home/somewhere/dbox/myfiles
cp $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Neutrino|neutrino]].conf $newroot/var/[[Tuxbox|tuxbox]]/config
cp $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]/[[Bouquets|bouquets]].[[XML|xml]] $newroot/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]
cp $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]/services.[[XML|xml]] $newroot/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]

===== procps-Varianten von ps und top einbauen =====
Im Image werden die procps-Varianten von [[WP:Ps_%28Unix%29|ps]] und [[WP:Unix-Kommando#Prozessmanagement|top]] anstelle der [[WP:busybox|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|Spiele]] (definiert als [[Plugins|plugins]] mit type=1 in ihrer Konfigurationsdatei), sowie unerwünschte Sprachfiles ([[Neutrino|Neutrino]] angenommen). Das File sollte von '''root-[[Neutrino|neutrino]]-$[[Filesystem|filesystem]]-local.sh''' aufgerufen werden.

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

===== /.version anpassen =====

{{edit_version_file}}

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

*[[Flash|flash]]-version-local.sh

#/bin/sh
USER=$(whoami)
if [ $0 = $CDIR/flash-version-local.sh ] ; then
outfile=$FLASHDIR/root/.version
type="[[Image|Image]]"
else
outfile=$TARGETDIR/.version
type="[[Yadd|Yadd]]"
fi;
echo Creating $outfile ...
echo "version=`./mkversion -[[Snapshot|snapshot]] -version 200`" > $outfile
echo "creator=$USER" >> $outfile
echo "imagename=$USER-$type" >> $outfile
echo "homepage=[[HTTP|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|release]])
releasetype=0
;;
-[[Snapshot|snapshot]])
releasetype=1
;;
-internal)
releasetype=2
;;
-version)
versionnumber=$2
shift
;;
esac
shift
done
echo $releasetype$versionnumber$year$month$day$hour$minute

===== Archivierung der [[Images|Images]] =====
Es ist eigentlich die Aufgabe des Buildprozesses, flashbare [[Images|Images]] zu erzeugen, und nicht sie zu archivieren. Jedoch kann die [[Customization|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]-[cramfs, 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|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|Customization]] Scripte für den eigenen Bedarf schreibt.

== Idempotens ==
Es ist fast immer eine gute Idee zu versuchen, ein Installationsscript [[Wikipedia:Idempotent|idempotent]] zu schreiben. Dies bedeutet, dass das mehrmalige Ausführen den gleichen Effekt hat wie das einmalige Ausführen.
Benutze "[[Make|make]] install".
 
In der Vergangenheit hat das [[Tuxbox|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|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|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|gui]]-[[Filesystem|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 [[Wikipedia:Inkonsistent|inkonsistenten]] Zustand versetzen. Dies gilt insbesondere für die Verzeichnisse in '''$(flashprefix)'''. Wenn der Bau solch eines [[Make|Make]]-Targets abbricht, besteht das Verzeichnis, ist entsprechend seiner Änderungszeit aktuell, und ein folgender [[Make|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|Br]]üche geht, '''dann lösche man es''', bevor ein anderer [[Make|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|Hilfe]] benötigt, siehe unten!.

=== Nach dem [[Flashen|Flashen]]: "Kein System" auf dem [[LCD|LCD]]/Was ist diese "bad magic byte" Zeugs? ===
Diese Frage kommt hoffentlich nicht... Die kurze Antwort ist: Man weiß es nicht. Wir [[Wissen|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|Image]] "ist" in Ordnung, es ist nur dass irgendwelche [[Firmware|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|CVS]], zu finden im Verzeichnis '''./hostapps/[[CheckImage|checkImage]]''' ermittelt diese "schlechten Bytes", aber ändert nichts daran, um diese zu beheben. Die Erfahrung zeigt, daß [[Images|Images]], die [[checkImage]] für gut findet, wirklich laufen. [[Cramfs|Cramfs]]-, oder [[Squashfs|squashfs]] [[Images|Images]], worü[[BER|ber]] sich [[CheckImage|checkImage]] beschwert, laufen im allgemeinen nicht, in einigen Ausnahmefällen läufen sie aber doch.
 
Auch bei [[Jffs2|jffs2]]-[[Images|Images]] ist dies manchmal der Fall, dass sich [[checkImage]] beschwert, die [[Images|Images]] laufen, aber eben nicht immer. Mit diesen empirischen Beobachtungen ist man nun sich selbst überlassen.
 
Newmake weiß, wie dieses Programm aufgerufen werden kann, um die erzeugten [[Images|Images]] automatisch zu überprüfen. Die Konfigurationsoption
--with-[[CheckImage|checkImage]]=[none,rename,warn]
wird hierfür verwendet. Falls '''warn''' gewählt ist, wird für jedes [[Image|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 erwähnt werden, daß die "schlechten magischen Bytes" in einem (oder mehreren!) der Partitionsteile sitzt, und werden nicht durch den abschließenden Schritt erzeugt (die *.img1x und/oder *.img2x Files bauen). Es ist auch möglich, [[CheckImage|checkImage]] auf die Partitionsfiles anzuwenden *.[[Jffs2|jffs2]], *.[[Cramfs|cramfs]]
*.[[Squashfs|squashfs]]
*.flfs1x
*.flfs2x
Schließlich hat [[CheckImage|checkImage]] eine Debugoption, die nützlich sein kann.

== Ich habe ein Fehler gefunden! ==
Bugs, Unklarheiten, Verbesserungsvorschläge, etc. der [[Software|Software]] sollten vorzugsweise im [http://tuxbox-forum.dreambox-fan.de/forum/viewforum.php?f=7 Cross Development Kit - Forum] des [[Tuxbox|Tuxbox]]-Boards gepostet werden.

== Ich benötige [[Hilfe|Hilfe]]! ==
Supportanfragen können im [http://tuxbox-forum.dreambox-fan.de/forum/viewforum.php?f=7 Cross Development Kit - Forum] des [[Tuxbox|Tuxbox]]-Boards gepostet werden. Postings in deutsch oder englisch sind willkommen. Bitte nicht vergessen, die benutzten Konfigurationsoptionen zu erwähnen.

=Links=
*[http://www.gnu.org/software/make/manual/make.html GNU Make manual]
*[http://www.gnu.org/software/autoconf/manual/ Autoconf manual]
*[http://www.gnu.org/software/automake/manual/ Automake manual]
*[http://sources.redhat.com/autobook/ GNU Autoconf, Automake, and Libtool]
*[http://www.gnu.org/prep/standards/ GNU Coding standards]
*[http://cvsbook.red-bean.com/ Open Source Development with CVS, 3rd Edition]
*Barf's Homepage: [http://bengt-martensson.de/dbox2/ Barfs ][[Newmake]]-Dokumentation]

{{review}}

{{body}}

Dbox2 Entwicklungsumgebung

2008-07-01T15:21:53Z

Dixidix:

[[Category:Register]]
[[Category:Development]]
[[Category:CDK]]
{{Development_sidebar}}

__TOC__
{{Review}}
=Allgemeines=
Newmake ist eine Überarbeitung des alten "[[Make|make]]" Prozesses, inzwischen auch als [[Image erstellen|Oldmake]] bezeichnet, und wurde durch Barf ins Leben gerufen.
Neben einer deutlich strukturierteren Basis, bietet es unter anderem auch den Vorteil, dass es auch ohne ohne großes Verständnis für den Buildprozess gelingen kann, [[Images|Flashimages]] und [[yadd|YADDs]] unter [[Linux|Linux]] zu erstellen.
Basierend auf Newmake gibt es inzwischen auch eine auf Scripts basierende Quasi-Frontendlösung, mit der sich [[Images|Flashimages]] oder [[yadd|YADDs]] benutzerdefiniert erstellen lassen, das sogenannte [[yBuild]]. 
Dieser Artikel basiert zum größtem Teil auf die deutsche Version von [http://bengt-martensson.de/dbox2/ Barfs Newmake-Dokumentation], die er uns freundlicheweise zur Verfügung gestellt hat.
Eine detaillierte Beschreibung (auch der [[Make|make]] targets) unter anderem auch in englischer Sprache befindet sich auf [http://bengt-martensson.de/dbox2/ Barf's Homepage]. 

Dieser Artikel behandelt Newmake aus Sicht des Benutzers (nicht Entwickler). Es behandelt die [[Image]]- u. [[yadd|YADD]]-Herstellung sowie einfache Beipiele für Benutzeranpassungen ("[[Customization]]"). 

==Zur Geschichte==
Vor einigen Jahren war die Imageherstellung für die [[Tuxbox|Tuxbox]] so etwas wie [[Wikipedia:Schwarze Kunst|"Schwarze Kunst"]].
Die Makefile-Unterstützung war, insbesondere für andere [[Images]] als [[cramfs]]-[[Images]], ziehmlich 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|CVS]]-Verzeichnis ''.../hostapps/[[Mkflfs|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|CVS]]-Sources mit einigen mehr-oder-weniger geheim gehaltenen "Fixes", (vermutlich) notwendig für das Herstellen eines funktionierenden [[Images]] aus dem [[CVS|CVS]]-Quellcode.
 
 
Im August 2003, wurde es für das [[DBox2 Software Projekt|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|Software]]-Design... 
Ein [[Image]] aus reinen [[CVS|CVS]]-Dateien zu bauen, war nicht wirklich möglich.
 
 
2004 wurde das [[YADI]] ("'''Y'''et '''A'''nother '''D'''Box '''I'''mage") Projekt geboren. 
Sein Ziel war es, das "Imagebauen" zu automatisieren und zu vereinfachen. Zu diesem Zweck wurden eine Anzahl von [[Wikipedia:Skripte|Scripten]] und [[Wikipedia:Patches|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|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|Skript]] war das automatische Imagebuilden zwar möglich, jedoch statt grundlegende Schwächen im [[CDK|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, verfügbar als alternativer [[Branch]] im [[CVS|CVS]], versucht diese Schwächen zu beseitigen. 
 
Ein spezieller Dank an jedem, der Bugreports und Feedback geliefert hat. Insbesonderes gilt dies für dietmarw, der Newmake benutzt, um die [[images|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 [[Wikipedia:Skriptsprache|Shellskripten]] wird für viele Teile, insbesondere für das [[Customization]]-Kapitel, aber nicht für [[Image]]/[[yadd|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|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|Images]] bleiben.

= [[Images|Images]] und [[Yadd|YADD]]'s bauen=
== Targets ==
Es gibt neben zahlreichen untergeordneten Zielen (Targets), zwei hauptrangige Targets. Diese wären entweder
*[[YADD]]
oder
*[[Image]].
Ein [[YADD]] besteht aus einigen Dateien, die die DBox anstatt aus dem [[Flash]] ü[[BER|ber]] den [[TFTP]]-Service lädt, sowie ein [[Filesystem|Filesystem]], das ü[[BER|ber]] einen [[NFS-Server]] der dBox zur Verfügung gestellt wird.
 
Diese Betriebsart hat insbesondere während der Softwareentwicklung oder beim Erlernen des Systems viele Vorteile. 
Der Name "[[YADD]]" bedeutet übrigens "'''Y'''et '''A'''nother '''D'''Box '''D'''istribution" ("noch eine dBox Verteilung").

=== Erste Schritte und Überlegungen ===
Eine Empfehlung für den angehenden "[[Image|Image]]/[[Yadd|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|Image]] mit der Lieblings-[[GUI]] zu erstellen.

Meistens möchte man die folgenden Schritte kombinieren und/oder automatisieren.
 
In diesem Artikel bezeichnet "[[GUI]]" entweder
*[[Neutrino]] oder
*[[Enigma]]
*[[Lcars]]
*[[Radiobox]].
 
Das "[[Filesystem]]" im Kontext eines kompletten [[Images]] bezeichnet das [[Dateisystem]], in dem das root-Verzeichnis liegt. Diese kann ein
*[[cramfs]] (ein komprimiertes, Read-only [[Filesystem|filesystem]] für embedded Systeme) sein,
*[[squashfs]] (ein weiterd komprimiertes read-only-[[Dateisystem|Dateisystem]], was leistungsfähiger als [[cramfs]] betrachtet wird)
oder
*[[jffs2]] (ein "journalled" Read-Write-[[Filesystem|Filesystem]]).
Ein "[[Cramfs|cramfs]] Komplett-[[Image|Image]]" besteht aus einem Root-[[Dateisystem|Dateisystem]] mit dem [[cramfs]] [[Dateisystem|Dateisystem]] und einem kleineren [[jffs2]]-[[Filesystem|Filesystem]], das nach '''/var''' gemounted wird.
 
Analog gilt dies auch für "'''[[Squashfs|squashfs]] Komplett-[[Images|Images]]'''", während ein "'''[[Jffs2|jffs2]] Komplett-[[Image|Image]]'''" kein separates ''/var-[[Dateisystem|Dateisystem]]'' enthält, weil [[Jffs2|jffs2]] an sich beschreibbar (var) ist.
 
Zusätzlich enthalten die Komplett-[[Images|Images]] eine weitere [[Partition|Partition]], die den [[u-boot]]-[[Bootloader]] enthalten. Diese [[Partition|Partition]] ist zwischen dBoxen mit einen und zwei Flashchips unterschiedlich. Dieses wird durch "'''1x'''" und "'''2x'''" angezeigt. Ein komplettes [[Image|Image]] würde demnach so benannt werden:

[neutrino, enigma]-[cramfs, squashfs, jffs2].img[1, 2]x,
z.B. als fertiges [[Image|Image]]:
[[Neutrino|neutrino]]-[[Jffs2|jffs2]].img2x.

== Buildsystem Voraussetzungen ==
Die Voraussetzungen auf dem Buildhost können in etwa so zusammengefasst werden:
 
Ein modernes [[Unix|Unix]]/[[Linux|Linux]] System mit ca. 2 GB freiem Speicherplatz. Epfehlenswert ist es aber mehr Speicherplatz einzuplanen, da beispielsweise bei Verwendung von [[ccache]] einiges an Daten zwischengelagert wird und je öfter man kompiliert, es dann doch eng werden könnte.

Das [[DBox2 Software Projekt|Tuxbox Projekt]] hat keine favorisierte Buildumgebung. Fragen wie "geht es mit Redhat x.y?" lassen sich nicht genau beantworten. Der Grund hierfür ist, dass niemand sich wirklich dafür interessiert, die Eigenschaften der bestimmten Distributionen zu erkunden. Gewisse Anforderungen werden dagegen für Versionen der Werkzeuge, wie [[WP:autoconf|autoconf]], [[WP:automake|automake]], [[make]] usw. formuliert. Die meisten davon sind in den gängigsten Distributionen bereits enthalten bzw. können nachinstalliert werden. Die momentan erfordelichen Toolversionen sind in folgendender Tabelle zusammengefasst:
 
{{Vorlage:GNU_Tools}}
 
Der Buildprozess überprüft zu Beginn automatisch einige dieser Anforderungen. Wenn eines dieser [[Tools|Tools]] 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|Anleitungen]] zum Buildvorgang wird gefordert, dass [[Tools|Tools]] 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
erfordelich, da einige entweder überhaupt nicht benötigt werden bzw. die [[Installation|Installation]] im
Makeprozess selbst vorgenommen wird!
 ''
Builden auf einem [[Unix|Unix]]-non-[[Linux|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|GNU]]-[[Erweiterungen|Erweiterungen]] uneingeschränkt verwendet werden.
 
Es wird daher davon abgeraten eine Umbegebung z.B. mit [[Cygwin]] aufzubauen, da es höchstwahrscheinlich nicht funktionieren wird. In dieser Richtung wurde zwar Einiges für den Makeprozess eingebaut, jedoch dürfte der gegenwärtige Entwicklungsstand nicht den gegenwärtigen Anforderungen entsprechen, um aktuell auch damit arbeiten zu können.
 
Empfehlenswert ist allerdings 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.

== Auschecken ==
Die [[Tuxbox|Tuxbox]] Quellen werden durch den [[Tuxbox|Tuxbox]] [[CVS-Server]] bereitgestellt. 
Regelmäßige Quellreleases sind niemals gemacht worden, und sind auch nicht für die Zukünft geplant. Für unsere Zwecke werden die Quellen anonym "ausgecheckt", was bedeutet, dass diese auf die eigene Festplatte kopiert werden, indem man zuerst auf einer (lokalen) Festplatte mit "ordentlich" freiem Platz ein leeres Verzeichnis erstellt, z.B. ''/[[Tuxbox|tuxbox]]-[[CVS|cvs]]'' und in diesen Ordner wechselt, und diesen Befehl ausführt.

[[CVS|cvs]] -d anoncvs@[[CVS|cvs]].[[Tuxbox|tuxbox]].org:/[[CVS|cvs]]/[[Tuxbox|tuxbox]] -z3 co -f -r newmake -P .

Dieser Befehl checkt die Newmake Files aus. In Fällen, in denen keine Newmake Version vorhanden ist, wird die HEAD-Version ausgecheckt.
 
'''Hinweis:'''
''Im HEAD gibt es zwei Files:''
*[[CDK|cdk]]/root/etc/init.d/rcS
''und''
*[[CDK|cdk]]/root/etc/init.d/rcS.insmod
''Im [[Newmake]] werden diese nicht benötigt da sie mittels''
[[CDK|cdk]]/root/etc/init.d/rcS.m4
''erzeugt werden.''
''Um auf der sicheren Seite zu sein, ist es ratsam, diese beiden zu löschen''.
 
Nachdem die Daten ausgecheckt wurden, könnte kann man jetzt einige Patches auf die Quellen anwenden. 
Wenn man aber zum ersten Mal kompiliert, ist es ratsam, vorerst keine Patches anzuwenden. Wenn Probleme auftreten, ist es viel einfacher (technisch sowohl als auch für jeden selbst) jemand zu helfen, der die "unveränderten [[CVS|CVS]] Quellen" verwendet.

== Konfiguration ==
Jetzt müssen einge Zwischenschritte erledigt werden, damit der Buildprozess auch erkennt, was und vorallem wie er es machen soll.
 
Man wechselt nun in das [[CDK|CDK]]-Unterverzeichnis
cd [[CDK|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|Images]], [[Yadd|YADD]] oder aller anderen gewünschten Ziele entsprechend den Benutzerwünschen vorzubereiten.

=== Optionen ===
{{Newmake_Build_Optionen}}

Für uns sind vorerst nur wenige Optionen interessant. Die Standardvorgaben reichen vorerst völlig aus. 
Eine typische Anwendung (Konfiguration), der mit z.B. den Pfadnamen oben kompatibel wäre, könnte so eingestellt werden:

./configure --with-cvsdir="/[[Tuxbox|tuxbox]]-[[CVS|cvs]]" --prefix="/[[Dbox2|dbox2]]" --enable-maintainer-mode

*''--with-cvsdir''
sagt wo die Quellen zu finden sind, (darin sollte auch ein Unterverzeichnis ''.../[[CDK|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|Makefiles]] ermöglicht, sich automatisch neu zu erzeugen, sobald die Notwendigkeit entsteht, zum Beispiel nach einem [[Software|Software]]-[[Update|Update]].

Es gibt sicher noch andere nützliche Optionen. Einige werden später noch besprochen.

=== 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|tuxbox]] [[Mklibs|mklibs]]
checking for mkcramfs... no
configure: WARNING: using [[Tuxbox|tuxbox]] [[Cramfs|cramfs]]
checking for mkjffs2... no
checking for [[Mkfs.jffs2|mkfs.jffs2]]... no
configure: WARNING: using [[Tuxbox|tuxbox]] [[Mkfs.jffs2|mkfs.jffs2]]
checking for mksquashfs... no
configure: WARNING: using [[Tuxbox|tuxbox]] [[Squashfs|squashfs]]
...

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

'''''Beachte!'''
Wenn man diesen Artikel mit ähnlichen Beschreibungen aus vergangenen Zeiten
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.
 ''
 
[[Bild:Stop hand.png]]
<div style="margin: 0; margin-top:10px; margin-right:0px; border: 3px solid #FF0000; padding: 0px 10px 1px 10px; background-color:#DEB0B0; align:right; ">
'''
Versuche niemals, als root zu bauen!'''
</div>

== Kompilieren ==
Die high-level [[Make|make]] Targets, die für das Builden von Komplett-[[Images|Images]] relevant sind, lauten:
*<pre><nowiki>flash-</nowiki>[neutrino, enigma, all]</nowiki></pre>
*<pre><nowiki>flash-</nowiki>[cramfs, squashfs, jffs2, all]</nowiki></pre>
*<pre><nowiki></nowiki>[1x, 2x, alle]</nowiki></pre>
Für [[Yadd|YADD]]-Builds, sind diese:
*<pre><nowiki>yadd-</nowiki>[neutrino, enigma, all]</nowiki></pre>
'''Beispiele:'''

[[Make|make]] [[Flash|flash]]-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]-all

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

'''der Befehl:'''

[[Make|make]] [[Yadd|yadd]]-[[Enigma|enigma]]

erzeugt ein [[Yadd|YADD]], das [[Enigma|Enigma]] enthält.

=== 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|make]] [[Yadd|yadd]]-[[Neutrino|neutrino]]''' mit leeren Verzeichnissen etwa 1 und 1,5 Stunden.

==== Verwendung von [[Ccache|ccache]] ====
Um den Vorgang insbesondere bei wiederholten Kompilieren und besonders auf langsameren Rechnern zu beschleunigen, steht die Option
* --enable-[[Ccache|ccache]]
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|ccache]]''' wird erreicht, sollte das Tool bereits in deiner Distribution installiert sein, dass [[ccache]] automatisch erkannt wird und in das [[Tuxbox|Tuxbox]]-[[CDK|CDK]] eingebunden wird. Ist es nicht installiert, wird dies auch von configure angezeigt:
...
----------------------------------------
[[Ccache|ccache]] support: no
[[Ccache|ccache]] installdir:
[[Ccache|ccache]] is not installed please run [[Make|make]] [[Ccache|ccache]] or install it and configure again
----------------------------------------
...
Dann sollte man das Tool nachinstallieren oder mit dem Target
[[Make|make]] [[Ccache|ccache]]
in das [[CDK|CDK]] einbauen und configure wiederholen.

'''Hinweis'''
 
''[[Ccache]] macht sich erst bemerkbar, nachdem der Buildvorgang mindestens einmal durchgelaufen ist!''

Die Option ''--enable-[[Ccache|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-ccachedir=DIR
Diese Option kann man verwenden, wenn man [[ccache]] beispielsweise nur als Binary abgelegt hat und den Pfad dazu bestimmen möchte.
 
'''Hinweis'''
 
''Die Option '''--with-ccachedir''' bewirkt auch das die mit '''[[Make|make]] [[Ccache|ccache]]''' installierte Version im [[CDK|CDK]] und/oder auch die evtl. im System installierte Version ignoriert wird!''

*--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|ccache]] -s
prüfen. Als Ergebnis werden einige Statistiken ü[[BER|ber]] das Cache-Verhalten von [[Ccache|ccache]] ausgegeben:
cache directory /home/<USER>/.[[Ccache|ccache]]
cache hit 4
cache miss 191
called for [[Link|link]] 17
multiple source files 4
compile failed 17
preprocessor error 2
not a C/C++ file 5
autoconf compile/[[Link|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|make]] [[Yadd|yadd]]-[[Neutrino|neutrino]]
Am Ende des Bauvorganges werden damit die entsprechenden Zeitinformationen ausgegeben.

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

==== [[Neutrino|neutrino]]-[[Jffs2|jffs2]]-[[Image|Image]] ====
#! /bin/bash
# beispiel.sh
# Diese Script baut [[Neutrino|neutrino]]-[[Jffs2|jffs2]] [[Images|Images]], jeweils 1x und 2x
#----------------------------------------------
USERDIR=/home/$(whoami)
#----------------------------------------------
LOGODIR=$USERDIR/Logos
CP=$USERDIR/[[Tuxbox|tuxbox]]-[[CVS|cvs]]
DB=$USERDIR/[[Dbox2|dbox2]]
ARCHIVEDIR=$USERDIR/Archive
export CVS_RSH=[[SSH|ssh]]
#-----------------------------------------------
cd "$CP"
[[CVS|cvs]] -d anoncvs@[[CVS|cvs]].[[Tuxbox|tuxbox]].org:/[[CVS|cvs]]/[[Tuxbox|tuxbox]] -z3 co -f -r newmake -P .
cd [[CDK|cdk]]
/bin/ln -sf $ARCHIVEDIR/ Archive
./autogen.sh
./configure --prefix="$DB" --with-cvsdir="$CP" --enable-flashrules --enable-[[Ccache|ccache]] --with-[[CheckImage|checkImage]]=rename --with-logosdir="$LOGODIR"
[[Make|make]] [[Flash|flash]]-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]-all

==== [[Neutrino|Neutrino]] [[Yadd|YADD]] ====
#! /bin/bash
# beispiel.sh
# Diese Script baut ein [[Neutrino|Neutrino]] [[Yadd|Yadd]]
#----------------------------------------------
USERDIR=/home/$(whoami)
#----------------------------------------------
LOGODIR=/Logos
CP=$USERDIR/[[Tuxbox|tuxbox]]-[[CVS|cvs]]
DB=$USERDIR/[[Dbox2|dbox2]]
ARCHIVEDIR=$USERDIR/Archive
export CVS_RSH=[[SSH|ssh]]
#-----------------------------------------------
cd "$CP"
[[CVS|cvs]] -d anoncvs@[[CVS|cvs]].[[Tuxbox|tuxbox]].org:/[[CVS|cvs]]/[[Tuxbox|tuxbox]] -z3 co -f -r newmake -P .
cd [[CDK|cdk]]
/bin/ln -sf $ARCHIVEDIR/ Archive
./autogen.sh
./configure --prefix="$DB" --with-cvsdir="$CP" --with-logosdir="$LOGODIR" --enable-[[Ccache|ccache]]
[[Make|make]] [[Yadd|yadd]]-[[Neutrino|neutrino]]

= Was kommt dann...? =
== Booten von [[Yadd|YADD]] ==
Wenn ein [[Yadd|YADD]] frisch erzeugt wurde, kann damit auch die Box booten. Näheres dazu auch im Artikel [[CDK booten]]. 
Newmake hält auch ein [[Make|Make]]-Target für den serversupport bereit.
[[Make|make]] serversupport
Dieses erzeugt einige Konfigurationsdateien für den [[Server|Server]] der das [[Yadd|YADD]]-Build nahtlos an das [[Server|Server]]-Setup anknüpft.

== [[Flashen|Flashen]] des [[Images|Images]] ==
Wenn ein [[Image|Image]] gebaut wurde, ist der logische nächste Schritt das Einspielen des [[Images|Images]] in den [[Flash|Flash]] der Box. Hierfür ist entweder, das interaktive [[Flashen|Flashen]] innerhalb der [[GUI|GUI]] mit den [[Installation:Neutrino|Expertenfunktionen]] zu benutzen, oder der ''dboxflasher'' zu verwenden. Der ''dboxflasher'' wird durch das [[Make|Make]]-Target
[[Make|make]] serversupport
erzeugt. 
Siehe auch [[Installation]].

== Inkrementelle Builds ==
Im allgemeinen ist man nicht an einem einmaligen Build der [[Software|Software]] interessiert. Verbesserungen an den Quellen werden in das [[CVS|CVS]] täglich eingecheckt. Oft möchte man die [[Software|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|make]] [target]
und [[Make|make]] wird es, falls notwendig, neu erzeugen.

Es kann auch passieren, dass [[Make|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|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|Installation]] eines bestimmten Pakets wird durch das Anlegen einer Markerdatei im Verzeichnis ''[[CDK|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|make]] distclean
Das drastischste Reinigungs-Target, (fast) alles löschend, was nicht vom [[CVS|CVS]] ausgecheckt wurde.
Dieses ist eher selten notwendig.
 
[[Make|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|Yadd]]-[[Installation|Installation]]), sowie die [[Tftp|TFTP]]-Files ([[Kernel|Kernel]] und [[U-boot|u-boot]]) werden nicht angefasst.
 
[[Make|make]] depsclean
Löscht alle Markerdateien im /[[CDK|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|make]] clean
Kombiniert ''mostlyclean'', ''depsclean'', und ''[[Flash|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|make]] bootstrap''.
 
[[Make|make]] [[Flash|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|make]] [[Flash|flash]]-mostlyclean
Zusätzlich zum ''[[Flash|flash]]-semiclean'' löscht dieses Target auch Bootfiles und die Kernbauverzeichnisse. Vollimages werden unberührt gelassen.
 
[[Make|make]] [[Flash|flash]]-clean
Dieses Target löscht Alles in $(flashprefix).
 
Einige Quellverzeichnisse können mit einem Befehl wie
[[Make|make]] -C /[[Tuxbox|tuxbox]]-[[CVS|cvs]]/apps/[[Tuxbox|tuxbox]]/[[Neutrino|neutrino]] clean
gesäubert werden.

== Aktualisierung des [[CVS|CVS]]-Quellcodes ==
Um die Quellen mit neueren Checkins zu aktualisieren, verwende diesen Befehl für das toplevel [[CVS|CVS]] Verzeichnis (oder von einem anderen Verzeichnis, wenn Ihr wisst, was ihr tut;-). Mögliche Fehler werden in das logfile [[CVS|cvs]].log geschrieben.

[[CVS|cvs]] up -f -r Newmake -dP > [[CVS|cvs]].log 2>&1

'''Tipp'''
 
Um mit dem [[CVS|CVS]] arbeiten zu können nimmt man für gewöhnlich die Konsole für Eingaben. Es gibt aber auch verschiedene Frontendwerkzeuge wie z.B. [http://www.crossvc.com CrossVC] oder [http://cervisia.kde.org/ Cervisia] um nur einige zu nennen, die einen recht komfortablen Umgang mit den [[CVS|CVS]]-Daten ermöglichen. [[Bild:Crossvc.jpg|CrossVC als CVS Frontendlösung]] [[Bild:Cervisia.jpg|Cervisia als CVS Frontendlösung]] 
Auch einige [[IDE|IDE]]'s wie z.B. [[WP:Anjuta|Anjuta]] [[Bild:anjuta.jpg|Anjuta als IDE mit CVS-Anbindung]] bieten solche [[CVS|CVS]]-Schnittstellen an.

== [[Customization|Customization]] ==
Bisher lief immer alles darauf hinaus [[Images|Images]] oder Yadds zu bauen, die aus unveränderten [[CVS|CVS]]-Quellen gebaut wurden. 
[[Images|Images]] und die Yadds können aber auch angepasst ("customized") werden, ohne die [[Makefiles|Makefiles]] zu ändern.
 
Hier gibt es verschiedene Möglichkeiten.

=== Konfigurationsoptionen ===
hier einige nützliche Optionen: 
Hiermit kann ein Verzeichniss angegeben werden, welches die [[Ucodes|Ucodes]] enthält, die im [[Image|Image]] enthalten sein sollen.
--with-ucodesdir=[DIR]
'''Hinweis:''' 
Ein [[Image|Image]], dass [[Ucodes|ucodes]] enthält, darf
nicht verbreitet werden! 
 
 
Mit der Option
--with-logosdir=[DIR]
kann ein Verzeichniss angegeben werden, das boot-logos (logo-[[LCD|lcd]] und logo-fb) enthält, die im [[Image|Image]] enthalten sein sollen.
 
 
Diese Option
--with-defaultlocale=[LOCALE]
sorgt dafür, dass die gewünschte Sprache schon beim bauen eingestellt wird.

=== Ändern der Partitionierung ===
Die Rootpartitionsgröße für [[Cramfs|cramfs]] und [[Squashfs|squashfs]] [[Images|Images]] kann mit der Configure-Option
--with-rootpartitionsize=[SIZE]
angegeben werden.
 
Die Größe der var-[[Partition|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|jffs2]]-Imageerstellung unsinnig wäre.

=== Variablen ===
==== Pfade ====
Es sind noch weitere Benutzeranpassungen möglich. Dafür ist es aber notwendig, etwas [[Wissen|Wissen]] ü[[BER|ber]] die innere Funktionsweise der [[Makefiles|Makefiles]] zu haben. 
In der Folge bezeichnet
$(flashprefix)
den Wert der Makefile Variablen '''flashprefix''' (mit Konfiguration wie oben '''/[[Dbox2|dbox2]]/cdkflash''')
$(targetprefix)
bezeichnet den Wert der Makefile Variablen '''targetprefix''' (mit Konfiguration wie oben '''/[[Dbox2|dbox2]]/cdkroot'''), und
$(buildprefix)
bezeichnet den Wert der Makefile Variablen '''buildprefix''' (mit der Konfiguration oben '''/[[Tuxbox|tuxbox]]-[[CVS|cvs]]/[[CDK|cdk]]''').
 
 
Um z.B. ein '''[[Neutrino|neutrino]]-[[Cramfs|cramfs]].img2x''' zu erzeugen, werden die folgenden Verzeichnisse erstellt: 
*'''$(flashprefix)/root''' (enthält [[Filesystem|Filesystem]]- und [[GUI|GUI]]-unabhängige Bestandteile)
*'''$(flashprefix)/root-[[Cramfs|cramfs]]''' (enthält den [[Kernel|Kernel]], für Root-[[Filesystem|Filesystem]] auf [[Cramfs|cramfs]] konfiguriert, zusammen mit seinen Treibern) und
*'''$(flashprefix)/root-[[Neutrino|neutrino]]''' (enthält die Neutrinoinstallation).
 
Aus diesen drei Verzeichnissen, werden das Rootfilesystemverzeichniss
*'''$(flashprefix)/root-[[Neutrino|neutrino]]-[[Cramfs|cramfs]]''' und das
var-filesystemverzeichnis
*'''$(flashprefix)/var-[[Neutrino|neutrino]]''' gebaut.
 
Hiermit ist es möglich, einen Befehl wie
[[Make|make]] $(flashprefix)/root-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]
bzw. wenn man sich im Verzeichnis ''./[[Tuxbox|tuxbox]]-[[CVS|cvs]]/[[CDK|cdk]]'' befindet, den Befehl
[[Make|make]] root-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]
einzugeben, wobei man bei erster VAriante natürlich '''$(flashprefix)''' selbst durch den realen Pfad ersetzen muss, da '''$(flashprefix)''' nur eine [[Make|make]]-Variable ist, welche in unserem Beispiel den Pfad zu '''./[[Dbox2|dbox2]]/cdkflash''' darstellt. 
Man kann so manuell gewünschten Änderungen an '''$(flashprefix)/root-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]''' vornehmen, und dann, mit dem Befehl
[[Make|make]] [[Flash|flash]]-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]-2x
den Imagebau abschließen, um ein [[Image|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|Customization]]-Scripte ===
Sofern diese Scripte vorhanden und ausführbar sind, werden innerhalb der wichtigsten Targets diese sogenannten ''[[Customization|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|cdk]]'''-Ordner.
Bei Bedarf kann mit der Option
--with-customizationsdir=[DIR]
ein alternatives Verzeichnis für [[Customization|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|Shell]]-Scripts könnte dies z.B. ein kompiliertes C Programme, oder ein [[Perl|Perl]]-Script sein. 
Der Name eines [[Customization|Customization]] Scriptes besteht in der Regel aus dem Namen eines Targetverzeichnisses bzw. einem Target und dem angefügtem *'''-local.sh'''. 

==== Für [[Flash|Flash]]-Targets ====
Der Name der [[Customization|Customization]] Scripte für [[Images|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
*[[Neutrino|neutrino]]
*[[Enigma|enigma]]
*[[Lcars|lcars]]
*[[Radiobox|radiobox]]
 
"[[FS]]" zeigt an welches [[Filesystem|Filesystem]] gemeint ist.
*[[Cramfs|cramfs]]
*[[Squashfs|squashfs]]
*[[Jffs2|jffs2]]
 
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|neutrino]]-local.sh
root-[[Neutrino|neutrino]]-[[Squashfs|squashfs]]-local.sh
root-[[Squashfs|squashfs]]-local.sh
var-[[Neutrino|neutrino]]-local.sh

==== Für [[Yadd|Yadd]]-Targets ====
Für Yadds ist das Prinzip ähnlich, nur dass es hier quasi nur einen Ordner gibt. Dafür stellvertretend steht dann
*[[Yadd|yadd]]. 
Das "[[GUI]]" in Klammern bezeichnet auch hier die jeweilig betroffene Benutzeroberflche, also
*[[Neutrino|neutrino]]
*[[Enigma|enigma]]
*[[Lcars|lcars]]
*[[Radiobox|radiobox]]
 
so wäre die Bezeichnung der jeweiligen Scripte so aufgebaut.
*[[Yadd|yadd]]-[GUI]-local.sh
'''Beispiel:'''
[[Yadd|yadd]]-[[Neutrino|neutrino]]-local.sh

==== Andere [[Customization|Customization]] Scripte ====
Die bisher benannten [[Customization|Customization]] Scripte für [[Flash|Flash]]- u. [[Yadd|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|make]] hdparm
aus, wird beim Bauen das ausgeführt was im [[Customization|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: 
Während des [[Make|make]]-Durchlaufs werden einige Targets ausgeführt, welche die '''/.version'''-Files bei [[YADD]]
*'''version'''
bzw.
*'''[[Flash|flash]]-version'''
im [[Image]] erstellt.
 
Sofern eines dieser Scripte;
*'''version-local.sh'''
*'''[[Flash|flash]]-version-local.sh'''
vorhanden und ausführbar ist, wird es als Ersatz statt des originalen Targets ausgeführt, welches mit
[[Make|make]] version
bzw.
[[Make|make]] [[Flash|flash]]-version
angestoßen wird.

==== weitere Beispiele für Custiomization ====
Das Custiomizationscripting soll durch das folgende Beispiel noch mehr veranschaulicht werden.
Beispiel:

In einem [[Jffs2|jffs2]]-[[Image|Image]] wird dies gewünscht:

1. Eigene /etc/hosts benutzen,
2. Eigene [[Neutrino|neutrino]].conf, [[Bouquets|bouquets]].[[XML|xml]], services.[[XML|xml]] benutzen
3. einschließlich [[Lirc|lirc]]-Komponenten, zusammen mit eigenen [[Lirc|lirc]] Konfigurations-Dateien.

1. und 3. sind [[Erweiterungen|Erweiterungen]], die nach '''$(flashprefix)/root''' kommen sollten, während 2. [[Neutrino|Neutrino]]-regeln sind, welche nach sollten '''$(flashprefix)/root-[[Neutrino|neutrino]]-[[Jffs2|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|make]] flashlirc
cp -fr $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Lirc|lirc]] $newroot/var/[[Tuxbox|tuxbox]]/config

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

#!/bin/sh
# root-[[Neutrino|neutrino]]-local.sh
flashprefix=$1
buildprefix=$2
newroot=$flashprefix/root-[[Neutrino|neutrino]]
myfiles=/home/somewhere/dbox/myfiles
cp $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Neutrino|neutrino]].conf $newroot/var/[[Tuxbox|tuxbox]]/config
cp $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]/[[Bouquets|bouquets]].[[XML|xml]] $newroot/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]
cp $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]/services.[[XML|xml]] $newroot/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]

'''Bitte beachten:'''
Diese Scripte sollen als Beispiele dienen und können vermutlich nicht ohne Anpassung verwendet werden.

= 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|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|Customization]] Scripte für den eigenen Bedarf schreibt.

== Idempotens ==
Es ist fast immer eine gute Idee zu versuchen, ein Installationsscript [[Wikipedia:Idempotent|idempotent]] zu schreiben. Dies bedeutet, dass das mehrmalige Ausführen den gleichen Effekt hat wie das einmalige Ausführen.
Benutze "[[Make|make]] install".
 
In der Vergangenheit hat das [[Tuxbox|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|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|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|gui]]-[[Filesystem|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 [[Wikipedia:Inkonsistent|inkonsistenten]] Zustand versetzen. Dies gilt insbesondere für die Verzeichnisse in '''$(flashprefix)'''. Wenn der Bau solch eines [[Make|Make]]-Targets abbricht, besteht das Verzeichnis, ist entsprechend seiner Änderungszeit aktuell, und ein folgender [[Make|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|Br]]üche geht, '''dann lösche man es''', bevor ein anderer [[Make|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|Hilfe]] benötigt, siehe unten!.

=== Nach dem [[Flashen|Flashen]]: "Kein System" auf dem [[LCD|LCD]]/Was ist diese "bad magic byte" Zeugs? ===
Diese Frage kommt hoffentlich nicht... Die kurze Antwort ist: Man weiß es nicht. Wir [[Wissen|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|Image]] "ist" in Ordnung, es ist nur dass irgendwelche [[Firmware|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|CVS]], zu finden im Verzeichnis '''./hostapps/[[CheckImage|checkImage]]''' ermittelt diese "schlechten Bytes", aber ändert nichts daran, um diese zu beheben. Die Erfahrung zeigt, daß [[Images|Images]], die [[checkImage]] für gut findet, wirklich laufen. [[Cramfs|Cramfs]]-, oder [[Squashfs|squashfs]] [[Images|Images]], worü[[BER|ber]] sich [[CheckImage|checkImage]] beschwert, laufen im allgemeinen nicht, in einigen Ausnahmefällen läufen sie aber doch.
 
Auch bei [[Jffs2|jffs2]]-[[Images|Images]] ist dies manchmal der Fall, dass sich [[checkImage]] beschwert, die [[Images|Images]] laufen, aber eben nicht immer. Mit diesen empirischen Beobachtungen ist man nun sich selbst überlassen.
 
Newmake weiß, wie dieses Programm aufgerufen werden kann, um die erzeugten [[Images|Images]] automatisch zu überprüfen. Die Konfigurationsoption
--with-[[CheckImage|checkImage]]=[none,rename,warn]
wird hierfür verwendet. Falls '''warn''' gewählt ist, wird für jedes [[Image|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 erwähnt werden, daß die "schlechten magischen Bytes" in einem (oder mehreren!) der Partitionsteile sitzt, und werden nicht durch den abschließenden Schritt erzeugt (die *.img1x und/oder *.img2x Files bauen). Es ist auch möglich, [[CheckImage|checkImage]] auf die Partitionsfiles anzuwenden *.[[Jffs2|jffs2]], *.[[Cramfs|cramfs]]
*.[[Squashfs|squashfs]]
*.flfs1x
*.flfs2x
Schließlich hat [[CheckImage|checkImage]] eine Debugoption, die nützlich sein kann.

== Ich habe ein Fehler gefunden! ==
Bugs, Unklarheiten, Verbesserungsvorschläge, etc. der [[Software|Software]] sollten vorzugsweise im [http://tuxbox-forum.dreambox-fan.de/forum/viewforum.php?f=7 Cross Development Kit - Forum] des [[Tuxbox|Tuxbox]]-Boards gepostet werden.

== Ich benötige [[Hilfe|Hilfe]]! ==
Supportanfragen können im [http://tuxbox-forum.dreambox-fan.de/forum/viewforum.php?f=7 Cross Development Kit - Forum] des [[Tuxbox|Tuxbox]]-Boards gepostet werden. Postings in deutsch oder englisch sind willkommen. Bitte nicht vergessen, die benutzten Konfigurationsoptionen zu erwähnen.

=Anhang=
==Einige nützliche [[Customization|Customization]] Script Snippets==
In diesem Anhang werden einige nützliche [[Customization|Customization]] Scripte gezeigt. Zwei Scripte sind bereits oben gezeigt worden.
 

'''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.

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

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

=== /.version anpassen ===
Euere eigene ''/.version''-File herzustellen (anggezeigt von [[Neutrino|Neutrino]] durch dBox -> Services -> [[Image|Image]]-Version und cdkVcInfo beim Booten) ist sicher ein allgemeiner Wunsch.

*[[Flash|flash]]-version-local.sh

#/bin/sh
USER=$(whoami)
if [ $0 = $CDIR/flash-version-local.sh ] ; then
outfile=$FLASHDIR/root/.version
type="[[Image|Image]]"
else
outfile=$TARGETDIR/.version
type="[[Yadd|Yadd]]"
fi;
echo Creating $outfile ...
echo "version=`./mkversion -[[Snapshot|snapshot]] -version 200`" > $outfile
echo "creator=$USER" >> $outfile
echo "imagename=$USER-$type" >> $outfile
echo "homepage=[[HTTP|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|release]])
releasetype=0
;;
-[[Snapshot|snapshot]])
releasetype=1
;;
-internal)
releasetype=2
;;
-version)
versionnumber=$2
shift
;;
esac
shift
done
echo $releasetype$versionnumber$year$month$day$hour$minute

=== Archivierung der [[Images|Images]] ===
Es ist eigentlich die Aufgabe des Buildprozesses, flashbare [[Images|Images]] zu erzeugen, und nicht sie zu archivieren. Jedoch kann die [[Customization|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]-[cramfs, squashfs,jffs2].[img1x, img2x]
haben. Es benennt die Files entsprechend dem Tagesdatum um.

=Links=
*[http://www.gnu.org/software/make/manual/make.html GNU Make manual]
*[http://www.gnu.org/software/autoconf/manual/ Autoconf manual]
*[http://www.gnu.org/software/automake/manual/ Automake manual]
*[http://sources.redhat.com/autobook/ GNU Autoconf, Automake, and Libtool]
*[http://www.gnu.org/prep/standards/ GNU Coding standards]
*[http://cvsbook.red-bean.com/ Open Source Development with CVS, 3rd Edition]
*Barf's Homepage: [http://bengt-martensson.de/dbox2/ Barfs ][[Newmake]]-Dokumentation]

{{review}}

{{body}}

Dbox2 Entwicklungsumgebung

2008-07-01T15:20:23Z

Dixidix:

[[Category:Register]]
[[Category:Development]]
[[Category:CDK]]
{{Development_sidebar}}

__TOC__
{{Review}}
=Allgemeines=
Newmake ist eine Überarbeitung des alten "[[Make|make]]" Prozesses, inzwischen auch als [[Image erstellen|Oldmake]] bezeichnet, und wurde durch Barf ins Leben gerufen.
Neben einer deutlich strukturierteren Basis, bietet es unter anderem auch den Vorteil, dass es auch ohne ohne großes Verständnis für den Buildprozess gelingen kann, [[Images|Flashimages]] und [[yadd|YADDs]] unter [[Linux|Linux]] zu erstellen.
Basierend auf Newmake gibt es inzwischen auch eine auf Scripts basierende Quasi-Frontendlösung, mit der sich [[Images|Flashimages]] oder [[yadd|YADDs]] benutzerdefiniert erstellen lassen, das sogenannte [[yBuild]]. 
Dieser Artikel basiert zum größtem Teil auf die deutsche Version von [http://bengt-martensson.de/dbox2/ Barfs Newmake-Dokumentation], die er uns freundlicheweise zur Verfügung gestellt hat.
Eine detaillierte Beschreibung (auch der [[Make|make]] targets) unter anderem auch in englischer Sprache befindet sich auf [http://bengt-martensson.de/dbox2/ Barf's Homepage]. 

Dieser Artikel behandelt Newmake aus Sicht des Benutzers (nicht Entwickler). Es behandelt die [[Image]]- u. [[yadd|YADD]]-Herstellung sowie einfache Beipiele für Benutzeranpassungen ("[[Customization]]"). 

==Zur Geschichte==
Vor einigen Jahren war die Imageherstellung für die [[Tuxbox|Tuxbox]] so etwas wie [[Wikipedia:Schwarze Kunst|"Schwarze Kunst"]].
Die Makefile-Unterstützung war, insbesondere für andere [[Images]] als [[cramfs]]-[[Images]], ziehmlich 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|CVS]]-Verzeichnis ''.../hostapps/[[Mkflfs|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|CVS]]-Sources mit einigen mehr-oder-weniger geheim gehaltenen "Fixes", (vermutlich) notwendig für das Herstellen eines funktionierenden [[Images]] aus dem [[CVS|CVS]]-Quellcode.
 
 
Im August 2003, wurde es für das [[DBox2 Software Projekt|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|Software]]-Design... 
Ein [[Image]] aus reinen [[CVS|CVS]]-Dateien zu bauen, war nicht wirklich möglich.
 
 
2004 wurde das [[YADI]] ("'''Y'''et '''A'''nother '''D'''Box '''I'''mage") Projekt geboren. 
Sein Ziel war es, das "Imagebauen" zu automatisieren und zu vereinfachen. Zu diesem Zweck wurden eine Anzahl von [[Wikipedia:Skripte|Scripten]] und [[Wikipedia:Patches|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|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|Skript]] war das automatische Imagebuilden zwar möglich, jedoch statt grundlegende Schwächen im [[CDK|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, verfügbar als alternativer [[Branch]] im [[CVS|CVS]], versucht diese Schwächen zu beseitigen. 
 
Ein spezieller Dank an jedem, der Bugreports und Feedback geliefert hat. Insbesonderes gilt dies für dietmarw, der Newmake benutzt, um die [[images|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 [[Wikipedia:Skriptsprache|Shellskripten]] wird für viele Teile, insbesondere für das [[Customization]]-Kapitel, aber nicht für [[Image]]/[[yadd|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|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|Images]] bleiben.

= [[Images|Images]] und [[Yadd|YADD]]'s bauen=
== Targets ==
Es gibt neben zahlreichen untergeordneten Zielen (Targets), zwei hauptrangige Targets. Diese wären entweder
*[[YADD]]
oder
*[[Image]].
Ein [[YADD]] besteht aus einigen Dateien, die die DBox anstatt aus dem [[Flash]] ü[[BER|ber]] den [[TFTP]]-Service lädt, sowie ein [[Filesystem|Filesystem]], das ü[[BER|ber]] einen [[NFS-Server]] der dBox zur Verfügung gestellt wird.
 
Diese Betriebsart hat insbesondere während der Softwareentwicklung oder beim Erlernen des Systems viele Vorteile. 
Der Name "[[YADD]]" bedeutet übrigens "'''Y'''et '''A'''nother '''D'''Box '''D'''istribution" ("noch eine dBox Verteilung").

=== Erste Schritte und Überlegungen ===
Eine Empfehlung für den angehenden "[[Image|Image]]/[[Yadd|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|Image]] mit der Lieblings-[[GUI]] zu erstellen.

Meistens möchte man die folgenden Schritte kombinieren und/oder automatisieren.
 
In diesem Artikel bezeichnet "[[GUI]]" entweder
*[[Neutrino]] oder
*[[Enigma]]
*[[Lcars]]
*[[Radiobox]].
 
Das "[[Filesystem]]" im Kontext eines kompletten [[Images]] bezeichnet das [[Dateisystem]], in dem das root-Verzeichnis liegt. Diese kann ein
*[[cramfs]] (ein komprimiertes, Read-only [[Filesystem|filesystem]] für embedded Systeme) sein,
*[[squashfs]] (ein weiterd komprimiertes read-only-[[Dateisystem|Dateisystem]], was leistungsfähiger als [[cramfs]] betrachtet wird)
oder
*[[jffs2]] (ein "journalled" Read-Write-[[Filesystem|Filesystem]]).
Ein "[[Cramfs|cramfs]] Komplett-[[Image|Image]]" besteht aus einem Root-[[Dateisystem|Dateisystem]] mit dem [[cramfs]] [[Dateisystem|Dateisystem]] und einem kleineren [[jffs2]]-[[Filesystem|Filesystem]], das nach '''/var''' gemounted wird.
 
Analog gilt dies auch für "'''[[Squashfs|squashfs]] Komplett-[[Images|Images]]'''", während ein "'''[[Jffs2|jffs2]] Komplett-[[Image|Image]]'''" kein separates ''/var-[[Dateisystem|Dateisystem]]'' enthält, weil [[Jffs2|jffs2]] an sich beschreibbar (var) ist.
 
Zusätzlich enthalten die Komplett-[[Images|Images]] eine weitere [[Partition|Partition]], die den [[u-boot]]-[[Bootloader]] enthalten. Diese [[Partition|Partition]] ist zwischen dBoxen mit einen und zwei Flashchips unterschiedlich. Dieses wird durch "'''1x'''" und "'''2x'''" angezeigt. Ein komplettes [[Image|Image]] würde demnach so benannt werden:

[neutrino, enigma]-[cramfs, squashfs, jffs2].img[1, 2]x,
z.B. als fertiges [[Image|Image]]:
[[Neutrino|neutrino]]-[[Jffs2|jffs2]].img2x.

== Buildsystem Voraussetzungen ==
Die Voraussetzungen auf dem Buildhost können in etwa so zusammengefasst werden:
 
Ein modernes [[Unix|Unix]]/[[Linux|Linux]] System mit ca. 2 GB freiem Speicherplatz. Epfehlenswert ist es aber mehr Speicherplatz einzuplanen, da beispielsweise bei Verwendung von [[ccache]] einiges an Daten zwischengelagert wird und je öfter man kompiliert, es dann doch eng werden könnte.

Das [[DBox2 Software Projekt|Tuxbox Projekt]] hat keine favorisierte Buildumgebung. Fragen wie "geht es mit Redhat x.y?" lassen sich nicht genau beantworten. Der Grund hierfür ist, dass niemand sich wirklich dafür interessiert, die Eigenschaften der bestimmten Distributionen zu erkunden. Gewisse Anforderungen werden dagegen für Versionen der Werkzeuge, wie [[WP:autoconf|autoconf]], [[WP:automake|automake]], [[make]] usw. formuliert. Die meisten davon sind in den gängigsten Distributionen bereits enthalten bzw. können nachinstalliert werden. Die momentan erfordelichen Toolversionen sind in folgendender Tabelle zusammengefasst:
 
{{Vorlage:GNU_Tools}}
 
Der Buildprozess überprüft zu Beginn automatisch einige dieser Anforderungen. Wenn eines dieser [[Tools|Tools]] 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|Anleitungen]] zum Buildvorgang wird gefordert, dass [[Tools|Tools]] 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
erfordelich, da einige entweder überhaupt nicht benötigt werden bzw. die [[Installation|Installation]] im
Makeprozess selbst vorgenommen wird!
 ''
Builden auf einem [[Unix|Unix]]-non-[[Linux|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|GNU]]-[[Erweiterungen|Erweiterungen]] uneingeschränkt verwendet werden.
 
Es wird daher davon abgeraten eine Umbegebung z.B. mit [[Cygwin]] aufzubauen, da es höchstwahrscheinlich nicht funktionieren wird. In dieser Richtung wurde zwar Einiges für den Makeprozess eingebaut, jedoch dürfte der gegenwärtige Entwicklungsstand nicht den gegenwärtigen Anforderungen entsprechen, um aktuell auch damit arbeiten zu können.
 
Empfehlenswert ist allerdings 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.

== Auschecken ==
Die [[Tuxbox|Tuxbox]] Quellen werden durch den [[Tuxbox|Tuxbox]] [[CVS-Server]] bereitgestellt. 
Regelmäßige Quellreleases sind niemals gemacht worden, und sind auch nicht für die Zukünft geplant. Für unsere Zwecke werden die Quellen anonym "ausgecheckt", was bedeutet, dass diese auf die eigene Festplatte kopiert werden, indem man zuerst auf einer (lokalen) Festplatte mit "ordentlich" freiem Platz ein leeres Verzeichnis erstellt, z.B. ''/[[Tuxbox|tuxbox]]-[[CVS|cvs]]'' und in diesen Ordner wechselt, und diesen Befehl ausführt.

[[CVS|cvs]] -d anoncvs@[[CVS|cvs]].[[Tuxbox|tuxbox]].org:/[[CVS|cvs]]/[[Tuxbox|tuxbox]] -z3 co -f -r newmake -P .

Dieser Befehl checkt die Newmake Files aus. In Fällen, in denen keine Newmake Version vorhanden ist, wird die HEAD-Version ausgecheckt.
 
'''Hinweis:'''
''Im HEAD gibt es zwei Files:''
*[[CDK|cdk]]/root/etc/init.d/rcS
''und''
*[[CDK|cdk]]/root/etc/init.d/rcS.insmod
''Im [[Newmake]] werden diese nicht benötigt da sie mittels''
[[CDK|cdk]]/root/etc/init.d/rcS.m4
''erzeugt werden.''
''Um auf der sicheren Seite zu sein, ist es ratsam, diese beiden zu löschen''.
 
Nachdem die Daten ausgecheckt wurden, könnte kann man jetzt einige Patches auf die Quellen anwenden. 
Wenn man aber zum ersten Mal kompiliert, ist es ratsam, vorerst keine Patches anzuwenden. Wenn Probleme auftreten, ist es viel einfacher (technisch sowohl als auch für jeden selbst) jemand zu helfen, der die "unveränderten [[CVS|CVS]] Quellen" verwendet.

== Konfiguration ==
Jetzt müssen einge Zwischenschritte erledigt werden, damit der Buildprozess auch erkennt, was und vorallem wie er es machen soll.
 
Man wechselt nun in das [[CDK|CDK]]-Unterverzeichnis
cd [[CDK|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|Images]], [[Yadd|YADD]] oder aller anderen gewünschten Ziele entsprechend den Benutzerwünschen vorzubereiten.

=== Optionen ===
{{Newmake_Build_Optionen}}

Für uns sind vorerst nur wenige Optionen interessant. Die Standardvorgaben reichen vorerst völlig aus. 
Eine typische Anwendung (Konfiguration), der mit z.B. den Pfadnamen oben kompatibel wäre, könnte so eingestellt werden:

./configure --with-cvsdir="/[[Tuxbox|tuxbox]]-[[CVS|cvs]]" --prefix="/[[Dbox2|dbox2]]" --enable-maintainer-mode

*''--with-cvsdir''
sagt wo die Quellen zu finden sind, (darin sollte auch ein Unterverzeichnis ''.../[[CDK|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|Makefiles]] ermöglicht, sich automatisch neu zu erzeugen, sobald die Notwendigkeit entsteht, zum Beispiel nach einem [[Software|Software]]-[[Update|Update]].

Es gibt sicher noch andere nützliche Optionen. Einige werden später noch besprochen.

=== 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|tuxbox]] [[Mklibs|mklibs]]
checking for mkcramfs... no
configure: WARNING: using [[Tuxbox|tuxbox]] [[Cramfs|cramfs]]
checking for mkjffs2... no
checking for [[Mkfs.jffs2|mkfs.jffs2]]... no
configure: WARNING: using [[Tuxbox|tuxbox]] [[Mkfs.jffs2|mkfs.jffs2]]
checking for mksquashfs... no
configure: WARNING: using [[Tuxbox|tuxbox]] [[Squashfs|squashfs]]
...

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

'''''Beachte!'''
Wenn man diesen Artikel mit ähnlichen Beschreibungen aus vergangenen Zeiten
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.
 ''
 
[[Bild:Stop hand.png]]
<div style="margin: 0; margin-top:10px; margin-right:0px; border: 3px solid #FF0000; padding: 0px 10px 1px 10px; background-color:#DEB0B0; align:right; ">
'''
Versuche niemals, als root zu bauen!'''
</div>

== Kompilieren ==
Die high-level [[Make|make]] Targets, die für das Builden von Komplett-[[Images|Images]] relevant sind, lauten:
*<pre><nowiki>flash-</nowiki>[neutrino, enigma, all]</nowiki></pre>
*<pre><nowiki>flash-</nowiki>[cramfs, squashfs, jffs2, all]</nowiki></pre>
*<pre><nowiki></nowiki>[1x, 2x, alle]</nowiki></pre>
Für [[Yadd|YADD]]-Builds, sind diese:
*<pre><nowiki>yadd-</nowiki>[neutrino, enigma, all]</nowiki></pre>
'''Beispiele:'''

[[Make|make]] [[Flash|flash]]-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]-all

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

'''der Befehl:'''

[[Make|make]] [[Yadd|yadd]]-[[Enigma|enigma]]

erzeugt ein [[Yadd|YADD]], das [[Enigma|Enigma]] enthält.

=== 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|make]] [[Yadd|yadd]]-[[Neutrino|neutrino]]''' mit leeren Verzeichnissen etwa 1 und 1,5 Stunden.

==== Verwendung von [[Ccache|ccache]] ====
Um den Vorgang insbesondere bei wiederholten Kompilieren und besonders auf langsameren Rechnern zu beschleunigen, steht die Option
* --enable-[[Ccache|ccache]]
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|ccache]]''' wird erreicht, sollte das Tool bereits in deiner Distribution installiert sein, dass [[ccache]] automatisch erkannt wird und in das [[Tuxbox|Tuxbox]]-[[CDK|CDK]] eingebunden wird. Ist es nicht installiert, wird dies auch von configure angezeigt:
...
----------------------------------------
[[Ccache|ccache]] support: no
[[Ccache|ccache]] installdir:
[[Ccache|ccache]] is not installed please run [[Make|make]] [[Ccache|ccache]] or install it and configure again
----------------------------------------
...
Dann sollte man das Tool nachinstallieren oder mit dem Target
[[Make|make]] [[Ccache|ccache]]
in das [[CDK|CDK]] einbauen und configure wiederholen.

'''Hinweis'''
 
''[[Ccache]] macht sich erst bemerkbar, nachdem der Buildvorgang mindestens einmal durchgelaufen ist!''

Die Option ''--enable-[[Ccache|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-ccachedir=DIR
Diese Option kann man verwenden, wenn man [[ccache]] beispielsweise nur als Binary abgelegt hat und den Pfad dazu bestimmen möchte.
 
'''Hinweis'''
 
''Die Option '''--with-ccachedir''' bewirkt auch das die mit '''[[Make|make]] [[Ccache|ccache]]''' installierte Version im [[CDK|CDK]] und/oder auch die evtl. im System installierte Version ignoriert wird!''

*--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|ccache]] -s
prüfen. Als Ergebnis werden einige Statistiken ü[[BER|ber]] das Cache-Verhalten von [[Ccache|ccache]] ausgegeben:
cache directory /home/<USER>/.[[Ccache|ccache]]
cache hit 4
cache miss 191
called for [[Link|link]] 17
multiple source files 4
compile failed 17
preprocessor error 2
not a C/C++ file 5
autoconf compile/[[Link|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|make]] [[Yadd|yadd]]-[[Neutrino|neutrino]]
Am Ende des Bauvorganges werden damit die entsprechenden Zeitinformationen ausgegeben.

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

==== [[Neutrino|neutrino]]-[[Jffs2|jffs2]]-[[Image|Image]] ====
#! /bin/bash
# beispiel.sh
# Diese Script baut [[Neutrino|neutrino]]-[[Jffs2|jffs2]] [[Images|Images]], jeweils 1x und 2x
#----------------------------------------------
USERDIR=/home/$(whoami)
#----------------------------------------------
LOGODIR=$USERDIR/Logos
CP=$USERDIR/[[Tuxbox|tuxbox]]-[[CVS|cvs]]
DB=$USERDIR/[[Dbox2|dbox2]]
ARCHIVEDIR=$USERDIR/Archive
export CVS_RSH=[[SSH|ssh]]
#-----------------------------------------------
cd "$CP"
[[CVS|cvs]] -d anoncvs@[[CVS|cvs]].[[Tuxbox|tuxbox]].org:/[[CVS|cvs]]/[[Tuxbox|tuxbox]] -z3 co -f -r newmake -P .
cd [[CDK|cdk]]
/bin/ln -sf $ARCHIVEDIR/ Archive
./autogen.sh
./configure --prefix="$DB" --with-cvsdir="$CP" --enable-flashrules --enable-[[Ccache|ccache]] --with-[[CheckImage|checkImage]]=rename --with-logosdir="$LOGODIR"
[[Make|make]] [[Flash|flash]]-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]-all

==== [[Neutrino|Neutrino]] [[Yadd|YADD]] ====
#! /bin/bash
# beispiel.sh
# Diese Script baut ein [[Neutrino|Neutrino]] [[Yadd|Yadd]]
#----------------------------------------------
USERDIR=/home/$(whoami)
#----------------------------------------------
LOGODIR=/Logos
CP=$USERDIR/[[Tuxbox|tuxbox]]-[[CVS|cvs]]
DB=$USERDIR/[[Dbox2|dbox2]]
ARCHIVEDIR=$USERDIR/Archive
export CVS_RSH=[[SSH|ssh]]
#-----------------------------------------------
cd "$CP"
[[CVS|cvs]] -d anoncvs@[[CVS|cvs]].[[Tuxbox|tuxbox]].org:/[[CVS|cvs]]/[[Tuxbox|tuxbox]] -z3 co -f -r newmake -P .
cd [[CDK|cdk]]
/bin/ln -sf $ARCHIVEDIR/ Archive
./autogen.sh
./configure --prefix="$DB" --with-cvsdir="$CP" --with-logosdir="$LOGODIR" --enable-[[Ccache|ccache]]
[[Make|make]] [[Yadd|yadd]]-[[Neutrino|neutrino]]

= Was kommt dann...? =
== Booten von [[Yadd|YADD]] ==
Wenn ein [[Yadd|YADD]] frisch erzeugt wurde, kann damit auch die Box booten. Näheres dazu auch im Artikel [[CDK booten]]. 
Newmake hält auch ein [[Make|Make]]-Target für den serversupport bereit.
[[Make|make]] serversupport
Dieses erzeugt einige Konfigurationsdateien für den [[Server|Server]] der das [[Yadd|YADD]]-Build nahtlos an das [[Server|Server]]-Setup anknüpft.

== [[Flashen|Flashen]] des [[Images|Images]] ==
Wenn ein [[Image|Image]] gebaut wurde, ist der logische nächste Schritt das Einspielen des [[Images|Images]] in den [[Flash|Flash]] der Box. Hierfür ist entweder, das interaktive [[Flashen|Flashen]] innerhalb der [[GUI|GUI]] mit den [[Installation:Neutrino|Expertenfunktionen]] zu benutzen, oder den ''dboxflasher'' zu verwenden. Der dboxflasher wird durch das [[Make|Make]]-Target
[[Make|make]] serversupport
erzeugt. 
Siehe auch [[Installation]].

== Inkrementelle Builds ==
Im allgemeinen ist man nicht an einem einmaligen Build der [[Software|Software]] interessiert. Verbesserungen an den Quellen werden in das [[CVS|CVS]] täglich eingecheckt. Oft möchte man die [[Software|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|make]] [target]
und [[Make|make]] wird es, falls notwendig, neu erzeugen.

Es kann auch passieren, dass [[Make|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|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|Installation]] eines bestimmten Pakets wird durch das Anlegen einer Markerdatei im Verzeichnis ''[[CDK|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|make]] distclean
Das drastischste Reinigungs-Target, (fast) alles löschend, was nicht vom [[CVS|CVS]] ausgecheckt wurde.
Dieses ist eher selten notwendig.
 
[[Make|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|Yadd]]-[[Installation|Installation]]), sowie die [[Tftp|TFTP]]-Files ([[Kernel|Kernel]] und [[U-boot|u-boot]]) werden nicht angefasst.
 
[[Make|make]] depsclean
Löscht alle Markerdateien im /[[CDK|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|make]] clean
Kombiniert ''mostlyclean'', ''depsclean'', und ''[[Flash|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|make]] bootstrap''.
 
[[Make|make]] [[Flash|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|make]] [[Flash|flash]]-mostlyclean
Zusätzlich zum ''[[Flash|flash]]-semiclean'' löscht dieses Target auch Bootfiles und die Kernbauverzeichnisse. Vollimages werden unberührt gelassen.
 
[[Make|make]] [[Flash|flash]]-clean
Dieses Target löscht Alles in $(flashprefix).
 
Einige Quellverzeichnisse können mit einem Befehl wie
[[Make|make]] -C /[[Tuxbox|tuxbox]]-[[CVS|cvs]]/apps/[[Tuxbox|tuxbox]]/[[Neutrino|neutrino]] clean
gesäubert werden.

== Aktualisierung des [[CVS|CVS]]-Quellcodes ==
Um die Quellen mit neueren Checkins zu aktualisieren, verwende diesen Befehl für das toplevel [[CVS|CVS]] Verzeichnis (oder von einem anderen Verzeichnis, wenn Ihr wisst, was ihr tut;-). Mögliche Fehler werden in das logfile [[CVS|cvs]].log geschrieben.

[[CVS|cvs]] up -f -r Newmake -dP > [[CVS|cvs]].log 2>&1

'''Tipp'''
 
Um mit dem [[CVS|CVS]] arbeiten zu können nimmt man für gewöhnlich die Konsole für Eingaben. Es gibt aber auch verschiedene Frontendwerkzeuge wie z.B. [http://www.crossvc.com CrossVC] oder [http://cervisia.kde.org/ Cervisia] um nur einige zu nennen, die einen recht komfortablen Umgang mit den [[CVS|CVS]]-Daten ermöglichen. [[Bild:Crossvc.jpg|CrossVC als CVS Frontendlösung]] [[Bild:Cervisia.jpg|Cervisia als CVS Frontendlösung]] 
Auch einige [[IDE|IDE]]'s wie z.B. [[WP:Anjuta|Anjuta]] [[Bild:anjuta.jpg|Anjuta als IDE mit CVS-Anbindung]] bieten solche [[CVS|CVS]]-Schnittstellen an.

== [[Customization|Customization]] ==
Bisher lief immer alles darauf hinaus [[Images|Images]] oder Yadds zu bauen, die aus unveränderten [[CVS|CVS]]-Quellen gebaut wurden. 
[[Images|Images]] und die Yadds können aber auch angepasst ("customized") werden, ohne die [[Makefiles|Makefiles]] zu ändern.
 
Hier gibt es verschiedene Möglichkeiten.

=== Konfigurationsoptionen ===
hier einige nützliche Optionen: 
Hiermit kann ein Verzeichniss angegeben werden, welches die [[Ucodes|Ucodes]] enthält, die im [[Image|Image]] enthalten sein sollen.
--with-ucodesdir=[DIR]
'''Hinweis:''' 
Ein [[Image|Image]], dass [[Ucodes|ucodes]] enthält, darf
nicht verbreitet werden! 
 
 
Mit der Option
--with-logosdir=[DIR]
kann ein Verzeichniss angegeben werden, das boot-logos (logo-[[LCD|lcd]] und logo-fb) enthält, die im [[Image|Image]] enthalten sein sollen.
 
 
Diese Option
--with-defaultlocale=[LOCALE]
sorgt dafür, dass die gewünschte Sprache schon beim bauen eingestellt wird.

=== Ändern der Partitionierung ===
Die Rootpartitionsgröße für [[Cramfs|cramfs]] und [[Squashfs|squashfs]] [[Images|Images]] kann mit der Configure-Option
--with-rootpartitionsize=[SIZE]
angegeben werden.
 
Die Größe der var-[[Partition|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|jffs2]]-Imageerstellung unsinnig wäre.

=== Variablen ===
==== Pfade ====
Es sind noch weitere Benutzeranpassungen möglich. Dafür ist es aber notwendig, etwas [[Wissen|Wissen]] ü[[BER|ber]] die innere Funktionsweise der [[Makefiles|Makefiles]] zu haben. 
In der Folge bezeichnet
$(flashprefix)
den Wert der Makefile Variablen '''flashprefix''' (mit Konfiguration wie oben '''/[[Dbox2|dbox2]]/cdkflash''')
$(targetprefix)
bezeichnet den Wert der Makefile Variablen '''targetprefix''' (mit Konfiguration wie oben '''/[[Dbox2|dbox2]]/cdkroot'''), und
$(buildprefix)
bezeichnet den Wert der Makefile Variablen '''buildprefix''' (mit der Konfiguration oben '''/[[Tuxbox|tuxbox]]-[[CVS|cvs]]/[[CDK|cdk]]''').
 
 
Um z.B. ein '''[[Neutrino|neutrino]]-[[Cramfs|cramfs]].img2x''' zu erzeugen, werden die folgenden Verzeichnisse erstellt: 
*'''$(flashprefix)/root''' (enthält [[Filesystem|Filesystem]]- und [[GUI|GUI]]-unabhängige Bestandteile)
*'''$(flashprefix)/root-[[Cramfs|cramfs]]''' (enthält den [[Kernel|Kernel]], für Root-[[Filesystem|Filesystem]] auf [[Cramfs|cramfs]] konfiguriert, zusammen mit seinen Treibern) und
*'''$(flashprefix)/root-[[Neutrino|neutrino]]''' (enthält die Neutrinoinstallation).
 
Aus diesen drei Verzeichnissen, werden das Rootfilesystemverzeichniss
*'''$(flashprefix)/root-[[Neutrino|neutrino]]-[[Cramfs|cramfs]]''' und das
var-filesystemverzeichnis
*'''$(flashprefix)/var-[[Neutrino|neutrino]]''' gebaut.
 
Hiermit ist es möglich, einen Befehl wie
[[Make|make]] $(flashprefix)/root-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]
bzw. wenn man sich im Verzeichnis ''./[[Tuxbox|tuxbox]]-[[CVS|cvs]]/[[CDK|cdk]]'' befindet, den Befehl
[[Make|make]] root-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]
einzugeben, wobei man bei erster VAriante natürlich '''$(flashprefix)''' selbst durch den realen Pfad ersetzen muss, da '''$(flashprefix)''' nur eine [[Make|make]]-Variable ist, welche in unserem Beispiel den Pfad zu '''./[[Dbox2|dbox2]]/cdkflash''' darstellt. 
Man kann so manuell gewünschten Änderungen an '''$(flashprefix)/root-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]''' vornehmen, und dann, mit dem Befehl
[[Make|make]] [[Flash|flash]]-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]-2x
den Imagebau abschließen, um ein [[Image|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|Customization]]-Scripte ===
Sofern diese Scripte vorhanden und ausführbar sind, werden innerhalb der wichtigsten Targets diese sogenannten ''[[Customization|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|cdk]]'''-Ordner.
Bei Bedarf kann mit der Option
--with-customizationsdir=[DIR]
ein alternatives Verzeichnis für [[Customization|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|Shell]]-Scripts könnte dies z.B. ein kompiliertes C Programme, oder ein [[Perl|Perl]]-Script sein. 
Der Name eines [[Customization|Customization]] Scriptes besteht in der Regel aus dem Namen eines Targetverzeichnisses bzw. einem Target und dem angefügtem *'''-local.sh'''. 

==== Für [[Flash|Flash]]-Targets ====
Der Name der [[Customization|Customization]] Scripte für [[Images|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
*[[Neutrino|neutrino]]
*[[Enigma|enigma]]
*[[Lcars|lcars]]
*[[Radiobox|radiobox]]
 
"[[FS]]" zeigt an welches [[Filesystem|Filesystem]] gemeint ist.
*[[Cramfs|cramfs]]
*[[Squashfs|squashfs]]
*[[Jffs2|jffs2]]
 
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|neutrino]]-local.sh
root-[[Neutrino|neutrino]]-[[Squashfs|squashfs]]-local.sh
root-[[Squashfs|squashfs]]-local.sh
var-[[Neutrino|neutrino]]-local.sh

==== Für [[Yadd|Yadd]]-Targets ====
Für Yadds ist das Prinzip ähnlich, nur dass es hier quasi nur einen Ordner gibt. Dafür stellvertretend steht dann
*[[Yadd|yadd]]. 
Das "[[GUI]]" in Klammern bezeichnet auch hier die jeweilig betroffene Benutzeroberflche, also
*[[Neutrino|neutrino]]
*[[Enigma|enigma]]
*[[Lcars|lcars]]
*[[Radiobox|radiobox]]
 
so wäre die Bezeichnung der jeweiligen Scripte so aufgebaut.
*[[Yadd|yadd]]-[GUI]-local.sh
'''Beispiel:'''
[[Yadd|yadd]]-[[Neutrino|neutrino]]-local.sh

==== Andere [[Customization|Customization]] Scripte ====
Die bisher benannten [[Customization|Customization]] Scripte für [[Flash|Flash]]- u. [[Yadd|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|make]] hdparm
aus, wird beim Bauen das ausgeführt was im [[Customization|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: 
Während des [[Make|make]]-Durchlaufs werden einige Targets ausgeführt, welche die '''/.version'''-Files bei [[YADD]]
*'''version'''
bzw.
*'''[[Flash|flash]]-version'''
im [[Image]] erstellt.
 
Sofern eines dieser Scripte;
*'''version-local.sh'''
*'''[[Flash|flash]]-version-local.sh'''
vorhanden und ausführbar ist, wird es als Ersatz statt des originalen Targets ausgeführt, welches mit
[[Make|make]] version
bzw.
[[Make|make]] [[Flash|flash]]-version
angestoßen wird.

==== weitere Beispiele für Custiomization ====
Das Custiomizationscripting soll durch das folgende Beispiel noch mehr veranschaulicht werden.
Beispiel:

In einem [[Jffs2|jffs2]]-[[Image|Image]] wird dies gewünscht:

1. Eigene /etc/hosts benutzen,
2. Eigene [[Neutrino|neutrino]].conf, [[Bouquets|bouquets]].[[XML|xml]], services.[[XML|xml]] benutzen
3. einschließlich [[Lirc|lirc]]-Komponenten, zusammen mit eigenen [[Lirc|lirc]] Konfigurations-Dateien.

1. und 3. sind [[Erweiterungen|Erweiterungen]], die nach '''$(flashprefix)/root''' kommen sollten, während 2. [[Neutrino|Neutrino]]-regeln sind, welche nach sollten '''$(flashprefix)/root-[[Neutrino|neutrino]]-[[Jffs2|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|make]] flashlirc
cp -fr $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Lirc|lirc]] $newroot/var/[[Tuxbox|tuxbox]]/config

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

#!/bin/sh
# root-[[Neutrino|neutrino]]-local.sh
flashprefix=$1
buildprefix=$2
newroot=$flashprefix/root-[[Neutrino|neutrino]]
myfiles=/home/somewhere/dbox/myfiles
cp $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Neutrino|neutrino]].conf $newroot/var/[[Tuxbox|tuxbox]]/config
cp $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]/[[Bouquets|bouquets]].[[XML|xml]] $newroot/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]
cp $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]/services.[[XML|xml]] $newroot/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]

'''Bitte beachten:'''
Diese Scripte sollen als Beispiele dienen und können vermutlich nicht ohne Anpassung verwendet werden.

= 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|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|Customization]] Scripte für den eigenen Bedarf schreibt.

== Idempotens ==
Es ist fast immer eine gute Idee zu versuchen, ein Installationsscript [[Wikipedia:Idempotent|idempotent]] zu schreiben. Dies bedeutet, dass das mehrmalige Ausführen den gleichen Effekt hat wie das einmalige Ausführen.
Benutze "[[Make|make]] install".
 
In der Vergangenheit hat das [[Tuxbox|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|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|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|gui]]-[[Filesystem|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 [[Wikipedia:Inkonsistent|inkonsistenten]] Zustand versetzen. Dies gilt insbesondere für die Verzeichnisse in '''$(flashprefix)'''. Wenn der Bau solch eines [[Make|Make]]-Targets abbricht, besteht das Verzeichnis, ist entsprechend seiner Änderungszeit aktuell, und ein folgender [[Make|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|Br]]üche geht, '''dann lösche man es''', bevor ein anderer [[Make|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|Hilfe]] benötigt, siehe unten!.

=== Nach dem [[Flashen|Flashen]]: "Kein System" auf dem [[LCD|LCD]]/Was ist diese "bad magic byte" Zeugs? ===
Diese Frage kommt hoffentlich nicht... Die kurze Antwort ist: Man weiß es nicht. Wir [[Wissen|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|Image]] "ist" in Ordnung, es ist nur dass irgendwelche [[Firmware|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|CVS]], zu finden im Verzeichnis '''./hostapps/[[CheckImage|checkImage]]''' ermittelt diese "schlechten Bytes", aber ändert nichts daran, um diese zu beheben. Die Erfahrung zeigt, daß [[Images|Images]], die [[checkImage]] für gut findet, wirklich laufen. [[Cramfs|Cramfs]]-, oder [[Squashfs|squashfs]] [[Images|Images]], worü[[BER|ber]] sich [[CheckImage|checkImage]] beschwert, laufen im allgemeinen nicht, in einigen Ausnahmefällen läufen sie aber doch.
 
Auch bei [[Jffs2|jffs2]]-[[Images|Images]] ist dies manchmal der Fall, dass sich [[checkImage]] beschwert, die [[Images|Images]] laufen, aber eben nicht immer. Mit diesen empirischen Beobachtungen ist man nun sich selbst überlassen.
 
Newmake weiß, wie dieses Programm aufgerufen werden kann, um die erzeugten [[Images|Images]] automatisch zu überprüfen. Die Konfigurationsoption
--with-[[CheckImage|checkImage]]=[none,rename,warn]
wird hierfür verwendet. Falls '''warn''' gewählt ist, wird für jedes [[Image|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 erwähnt werden, daß die "schlechten magischen Bytes" in einem (oder mehreren!) der Partitionsteile sitzt, und werden nicht durch den abschließenden Schritt erzeugt (die *.img1x und/oder *.img2x Files bauen). Es ist auch möglich, [[CheckImage|checkImage]] auf die Partitionsfiles anzuwenden *.[[Jffs2|jffs2]], *.[[Cramfs|cramfs]]
*.[[Squashfs|squashfs]]
*.flfs1x
*.flfs2x
Schließlich hat [[CheckImage|checkImage]] eine Debugoption, die nützlich sein kann.

== Ich habe ein Fehler gefunden! ==
Bugs, Unklarheiten, Verbesserungsvorschläge, etc. der [[Software|Software]] sollten vorzugsweise im [http://tuxbox-forum.dreambox-fan.de/forum/viewforum.php?f=7 Cross Development Kit - Forum] des [[Tuxbox|Tuxbox]]-Boards gepostet werden.

== Ich benötige [[Hilfe|Hilfe]]! ==
Supportanfragen können im [http://tuxbox-forum.dreambox-fan.de/forum/viewforum.php?f=7 Cross Development Kit - Forum] des [[Tuxbox|Tuxbox]]-Boards gepostet werden. Postings in deutsch oder englisch sind willkommen. Bitte nicht vergessen, die benutzten Konfigurationsoptionen zu erwähnen.

=Anhang=
==Einige nützliche [[Customization|Customization]] Script Snippets==
In diesem Anhang werden einige nützliche [[Customization|Customization]] Scripte gezeigt. Zwei Scripte sind bereits oben gezeigt worden.
 

'''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.

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

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

=== /.version anpassen ===
Euere eigene ''/.version''-File herzustellen (anggezeigt von [[Neutrino|Neutrino]] durch dBox -> Services -> [[Image|Image]]-Version und cdkVcInfo beim Booten) ist sicher ein allgemeiner Wunsch.

*[[Flash|flash]]-version-local.sh

#/bin/sh
USER=$(whoami)
if [ $0 = $CDIR/flash-version-local.sh ] ; then
outfile=$FLASHDIR/root/.version
type="[[Image|Image]]"
else
outfile=$TARGETDIR/.version
type="[[Yadd|Yadd]]"
fi;
echo Creating $outfile ...
echo "version=`./mkversion -[[Snapshot|snapshot]] -version 200`" > $outfile
echo "creator=$USER" >> $outfile
echo "imagename=$USER-$type" >> $outfile
echo "homepage=[[HTTP|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|release]])
releasetype=0
;;
-[[Snapshot|snapshot]])
releasetype=1
;;
-internal)
releasetype=2
;;
-version)
versionnumber=$2
shift
;;
esac
shift
done
echo $releasetype$versionnumber$year$month$day$hour$minute

=== Archivierung der [[Images|Images]] ===
Es ist eigentlich die Aufgabe des Buildprozesses, flashbare [[Images|Images]] zu erzeugen, und nicht sie zu archivieren. Jedoch kann die [[Customization|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]-[cramfs, squashfs,jffs2].[img1x, img2x]
haben. Es benennt die Files entsprechend dem Tagesdatum um.

=Links=
*[http://www.gnu.org/software/make/manual/make.html GNU Make manual]
*[http://www.gnu.org/software/autoconf/manual/ Autoconf manual]
*[http://www.gnu.org/software/automake/manual/ Automake manual]
*[http://sources.redhat.com/autobook/ GNU Autoconf, Automake, and Libtool]
*[http://www.gnu.org/prep/standards/ GNU Coding standards]
*[http://cvsbook.red-bean.com/ Open Source Development with CVS, 3rd Edition]
*Barf's Homepage: [http://bengt-martensson.de/dbox2/ Barfs ][[Newmake]]-Dokumentation]

{{review}}

{{body}}

Dbox2 Entwicklungsumgebung

2008-07-01T15:18:39Z

Dixidix: Imageflashen direkt verlinkt

[[Category:Register]]
[[Category:Development]]
[[Category:CDK]]
{{Development_sidebar}}

__TOC__
{{Review}}
=Allgemeines=
Newmake ist eine Überarbeitung des alten "[[Make|make]]" Prozesses, inzwischen auch als [[Image erstellen|Oldmake]] bezeichnet, und wurde durch Barf ins Leben gerufen.
Neben einer deutlich strukturierteren Basis, bietet es unter anderem auch den Vorteil, dass es auch ohne ohne großes Verständnis für den Buildprozess gelingen kann, [[Images|Flashimages]] und [[yadd|YADDs]] unter [[Linux|Linux]] zu erstellen.
Basierend auf Newmake gibt es inzwischen auch eine auf Scripts basierende Quasi-Frontendlösung, mit der sich [[Images|Flashimages]] oder [[yadd|YADDs]] benutzerdefiniert erstellen lassen, das sogenannte [[yBuild]]. 
Dieser Artikel basiert zum größtem Teil auf die deutsche Version von [http://bengt-martensson.de/dbox2/ Barfs Newmake-Dokumentation], die er uns freundlicheweise zur Verfügung gestellt hat.
Eine detaillierte Beschreibung (auch der [[Make|make]] targets) unter anderem auch in englischer Sprache befindet sich auf [http://bengt-martensson.de/dbox2/ Barf's Homepage]. 

Dieser Artikel behandelt Newmake aus Sicht des Benutzers (nicht Entwickler). Es behandelt die [[Image]]- u. [[yadd|YADD]]-Herstellung sowie einfache Beipiele für Benutzeranpassungen ("[[Customization]]"). 

==Zur Geschichte==
Vor einigen Jahren war die Imageherstellung für die [[Tuxbox|Tuxbox]] so etwas wie [[Wikipedia:Schwarze Kunst|"Schwarze Kunst"]].
Die Makefile-Unterstützung war, insbesondere für andere [[Images]] als [[cramfs]]-[[Images]], ziehmlich 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|CVS]]-Verzeichnis ''.../hostapps/[[Mkflfs|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|CVS]]-Sources mit einigen mehr-oder-weniger geheim gehaltenen "Fixes", (vermutlich) notwendig für das Herstellen eines funktionierenden [[Images]] aus dem [[CVS|CVS]]-Quellcode.
 
 
Im August 2003, wurde es für das [[DBox2 Software Projekt|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|Software]]-Design... 
Ein [[Image]] aus reinen [[CVS|CVS]]-Dateien zu bauen, war nicht wirklich möglich.
 
 
2004 wurde das [[YADI]] ("'''Y'''et '''A'''nother '''D'''Box '''I'''mage") Projekt geboren. 
Sein Ziel war es, das "Imagebauen" zu automatisieren und zu vereinfachen. Zu diesem Zweck wurden eine Anzahl von [[Wikipedia:Skripte|Scripten]] und [[Wikipedia:Patches|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|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|Skript]] war das automatische Imagebuilden zwar möglich, jedoch statt grundlegende Schwächen im [[CDK|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, verfügbar als alternativer [[Branch]] im [[CVS|CVS]], versucht diese Schwächen zu beseitigen. 
 
Ein spezieller Dank an jedem, der Bugreports und Feedback geliefert hat. Insbesonderes gilt dies für dietmarw, der Newmake benutzt, um die [[images|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 [[Wikipedia:Skriptsprache|Shellskripten]] wird für viele Teile, insbesondere für das [[Customization]]-Kapitel, aber nicht für [[Image]]/[[yadd|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|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|Images]] bleiben.

= [[Images|Images]] und [[Yadd|YADD]]'s bauen=
== Targets ==
Es gibt neben zahlreichen untergeordneten Zielen (Targets), zwei hauptrangige Targets. Diese wären entweder
*[[YADD]]
oder
*[[Image]].
Ein [[YADD]] besteht aus einigen Dateien, die die DBox anstatt aus dem [[Flash]] ü[[BER|ber]] den [[TFTP]]-Service lädt, sowie ein [[Filesystem|Filesystem]], das ü[[BER|ber]] einen [[NFS-Server]] der dBox zur Verfügung gestellt wird.
 
Diese Betriebsart hat insbesondere während der Softwareentwicklung oder beim Erlernen des Systems viele Vorteile. 
Der Name "[[YADD]]" bedeutet übrigens "'''Y'''et '''A'''nother '''D'''Box '''D'''istribution" ("noch eine dBox Verteilung").

=== Erste Schritte und Überlegungen ===
Eine Empfehlung für den angehenden "[[Image|Image]]/[[Yadd|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|Image]] mit der Lieblings-[[GUI]] zu erstellen.

Meistens möchte man die folgenden Schritte kombinieren und/oder automatisieren.
 
In diesem Artikel bezeichnet "[[GUI]]" entweder
*[[Neutrino]] oder
*[[Enigma]]
*[[Lcars]]
*[[Radiobox]].
 
Das "[[Filesystem]]" im Kontext eines kompletten [[Images]] bezeichnet das [[Dateisystem]], in dem das root-Verzeichnis liegt. Diese kann ein
*[[cramfs]] (ein komprimiertes, Read-only [[Filesystem|filesystem]] für embedded Systeme) sein,
*[[squashfs]] (ein weiterd komprimiertes read-only-[[Dateisystem|Dateisystem]], was leistungsfähiger als [[cramfs]] betrachtet wird)
oder
*[[jffs2]] (ein "journalled" Read-Write-[[Filesystem|Filesystem]]).
Ein "[[Cramfs|cramfs]] Komplett-[[Image|Image]]" besteht aus einem Root-[[Dateisystem|Dateisystem]] mit dem [[cramfs]] [[Dateisystem|Dateisystem]] und einem kleineren [[jffs2]]-[[Filesystem|Filesystem]], das nach '''/var''' gemounted wird.
 
Analog gilt dies auch für "'''[[Squashfs|squashfs]] Komplett-[[Images|Images]]'''", während ein "'''[[Jffs2|jffs2]] Komplett-[[Image|Image]]'''" kein separates ''/var-[[Dateisystem|Dateisystem]]'' enthält, weil [[Jffs2|jffs2]] an sich beschreibbar (var) ist.
 
Zusätzlich enthalten die Komplett-[[Images|Images]] eine weitere [[Partition|Partition]], die den [[u-boot]]-[[Bootloader]] enthalten. Diese [[Partition|Partition]] ist zwischen dBoxen mit einen und zwei Flashchips unterschiedlich. Dieses wird durch "'''1x'''" und "'''2x'''" angezeigt. Ein komplettes [[Image|Image]] würde demnach so benannt werden:

[neutrino, enigma]-[cramfs, squashfs, jffs2].img[1, 2]x,
z.B. als fertiges [[Image|Image]]:
[[Neutrino|neutrino]]-[[Jffs2|jffs2]].img2x.

== Buildsystem Voraussetzungen ==
Die Voraussetzungen auf dem Buildhost können in etwa so zusammengefasst werden:
 
Ein modernes [[Unix|Unix]]/[[Linux|Linux]] System mit ca. 2 GB freiem Speicherplatz. Epfehlenswert ist es aber mehr Speicherplatz einzuplanen, da beispielsweise bei Verwendung von [[ccache]] einiges an Daten zwischengelagert wird und je öfter man kompiliert, es dann doch eng werden könnte.

Das [[DBox2 Software Projekt|Tuxbox Projekt]] hat keine favorisierte Buildumgebung. Fragen wie "geht es mit Redhat x.y?" lassen sich nicht genau beantworten. Der Grund hierfür ist, dass niemand sich wirklich dafür interessiert, die Eigenschaften der bestimmten Distributionen zu erkunden. Gewisse Anforderungen werden dagegen für Versionen der Werkzeuge, wie [[WP:autoconf|autoconf]], [[WP:automake|automake]], [[make]] usw. formuliert. Die meisten davon sind in den gängigsten Distributionen bereits enthalten bzw. können nachinstalliert werden. Die momentan erfordelichen Toolversionen sind in folgendender Tabelle zusammengefasst:
 
{{Vorlage:GNU_Tools}}
 
Der Buildprozess überprüft zu Beginn automatisch einige dieser Anforderungen. Wenn eines dieser [[Tools|Tools]] 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|Anleitungen]] zum Buildvorgang wird gefordert, dass [[Tools|Tools]] 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
erfordelich, da einige entweder überhaupt nicht benötigt werden bzw. die [[Installation|Installation]] im
Makeprozess selbst vorgenommen wird!
 ''
Builden auf einem [[Unix|Unix]]-non-[[Linux|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|GNU]]-[[Erweiterungen|Erweiterungen]] uneingeschränkt verwendet werden.
 
Es wird daher davon abgeraten eine Umbegebung z.B. mit [[Cygwin]] aufzubauen, da es höchstwahrscheinlich nicht funktionieren wird. In dieser Richtung wurde zwar Einiges für den Makeprozess eingebaut, jedoch dürfte der gegenwärtige Entwicklungsstand nicht den gegenwärtigen Anforderungen entsprechen, um aktuell auch damit arbeiten zu können.
 
Empfehlenswert ist allerdings 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.

== Auschecken ==
Die [[Tuxbox|Tuxbox]] Quellen werden durch den [[Tuxbox|Tuxbox]] [[CVS-Server]] bereitgestellt. 
Regelmäßige Quellreleases sind niemals gemacht worden, und sind auch nicht für die Zukünft geplant. Für unsere Zwecke werden die Quellen anonym "ausgecheckt", was bedeutet, dass diese auf die eigene Festplatte kopiert werden, indem man zuerst auf einer (lokalen) Festplatte mit "ordentlich" freiem Platz ein leeres Verzeichnis erstellt, z.B. ''/[[Tuxbox|tuxbox]]-[[CVS|cvs]]'' und in diesen Ordner wechselt, und diesen Befehl ausführt.

[[CVS|cvs]] -d anoncvs@[[CVS|cvs]].[[Tuxbox|tuxbox]].org:/[[CVS|cvs]]/[[Tuxbox|tuxbox]] -z3 co -f -r newmake -P .

Dieser Befehl checkt die Newmake Files aus. In Fällen, in denen keine Newmake Version vorhanden ist, wird die HEAD-Version ausgecheckt.
 
'''Hinweis:'''
''Im HEAD gibt es zwei Files:''
*[[CDK|cdk]]/root/etc/init.d/rcS
''und''
*[[CDK|cdk]]/root/etc/init.d/rcS.insmod
''Im [[Newmake]] werden diese nicht benötigt da sie mittels''
[[CDK|cdk]]/root/etc/init.d/rcS.m4
''erzeugt werden.''
''Um auf der sicheren Seite zu sein, ist es ratsam, diese beiden zu löschen''.
 
Nachdem die Daten ausgecheckt wurden, könnte kann man jetzt einige Patches auf die Quellen anwenden. 
Wenn man aber zum ersten Mal kompiliert, ist es ratsam, vorerst keine Patches anzuwenden. Wenn Probleme auftreten, ist es viel einfacher (technisch sowohl als auch für jeden selbst) jemand zu helfen, der die "unveränderten [[CVS|CVS]] Quellen" verwendet.

== Konfiguration ==
Jetzt müssen einge Zwischenschritte erledigt werden, damit der Buildprozess auch erkennt, was und vorallem wie er es machen soll.
 
Man wechselt nun in das [[CDK|CDK]]-Unterverzeichnis
cd [[CDK|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|Images]], [[Yadd|YADD]] oder aller anderen gewünschten Ziele entsprechend den Benutzerwünschen vorzubereiten.

=== Optionen ===
{{Newmake_Build_Optionen}}

Für uns sind vorerst nur wenige Optionen interessant. Die Standardvorgaben reichen vorerst völlig aus. 
Eine typische Anwendung (Konfiguration), der mit z.B. den Pfadnamen oben kompatibel wäre, könnte so eingestellt werden:

./configure --with-cvsdir="/[[Tuxbox|tuxbox]]-[[CVS|cvs]]" --prefix="/[[Dbox2|dbox2]]" --enable-maintainer-mode

*''--with-cvsdir''
sagt wo die Quellen zu finden sind, (darin sollte auch ein Unterverzeichnis ''.../[[CDK|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|Makefiles]] ermöglicht, sich automatisch neu zu erzeugen, sobald die Notwendigkeit entsteht, zum Beispiel nach einem [[Software|Software]]-[[Update|Update]].

Es gibt sicher noch andere nützliche Optionen. Einige werden später noch besprochen.

=== 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|tuxbox]] [[Mklibs|mklibs]]
checking for mkcramfs... no
configure: WARNING: using [[Tuxbox|tuxbox]] [[Cramfs|cramfs]]
checking for mkjffs2... no
checking for [[Mkfs.jffs2|mkfs.jffs2]]... no
configure: WARNING: using [[Tuxbox|tuxbox]] [[Mkfs.jffs2|mkfs.jffs2]]
checking for mksquashfs... no
configure: WARNING: using [[Tuxbox|tuxbox]] [[Squashfs|squashfs]]
...

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

'''''Beachte!'''
Wenn man diesen Artikel mit ähnlichen Beschreibungen aus vergangenen Zeiten
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.
 ''
 
[[Bild:Stop hand.png]]
<div style="margin: 0; margin-top:10px; margin-right:0px; border: 3px solid #FF0000; padding: 0px 10px 1px 10px; background-color:#DEB0B0; align:right; ">
'''
Versuche niemals, als root zu bauen!'''
</div>

== Kompilieren ==
Die high-level [[Make|make]] Targets, die für das Builden von Komplett-[[Images|Images]] relevant sind, lauten:
*<pre><nowiki>flash-</nowiki>[neutrino, enigma, all]</nowiki></pre>
*<pre><nowiki>flash-</nowiki>[cramfs, squashfs, jffs2, all]</nowiki></pre>
*<pre><nowiki></nowiki>[1x, 2x, alle]</nowiki></pre>
Für [[Yadd|YADD]]-Builds, sind diese:
*<pre><nowiki>yadd-</nowiki>[neutrino, enigma, all]</nowiki></pre>
'''Beispiele:'''

[[Make|make]] [[Flash|flash]]-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]-all

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

'''der Befehl:'''

[[Make|make]] [[Yadd|yadd]]-[[Enigma|enigma]]

erzeugt ein [[Yadd|YADD]], das [[Enigma|Enigma]] enthält.

=== 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|make]] [[Yadd|yadd]]-[[Neutrino|neutrino]]''' mit leeren Verzeichnissen etwa 1 und 1,5 Stunden.

==== Verwendung von [[Ccache|ccache]] ====
Um den Vorgang insbesondere bei wiederholten Kompilieren und besonders auf langsameren Rechnern zu beschleunigen, steht die Option
* --enable-[[Ccache|ccache]]
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|ccache]]''' wird erreicht, sollte das Tool bereits in deiner Distribution installiert sein, dass [[ccache]] automatisch erkannt wird und in das [[Tuxbox|Tuxbox]]-[[CDK|CDK]] eingebunden wird. Ist es nicht installiert, wird dies auch von configure angezeigt:
...
----------------------------------------
[[Ccache|ccache]] support: no
[[Ccache|ccache]] installdir:
[[Ccache|ccache]] is not installed please run [[Make|make]] [[Ccache|ccache]] or install it and configure again
----------------------------------------
...
Dann sollte man das Tool nachinstallieren oder mit dem Target
[[Make|make]] [[Ccache|ccache]]
in das [[CDK|CDK]] einbauen und configure wiederholen.

'''Hinweis'''
 
''[[Ccache]] macht sich erst bemerkbar, nachdem der Buildvorgang mindestens einmal durchgelaufen ist!''

Die Option ''--enable-[[Ccache|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-ccachedir=DIR
Diese Option kann man verwenden, wenn man [[ccache]] beispielsweise nur als Binary abgelegt hat und den Pfad dazu bestimmen möchte.
 
'''Hinweis'''
 
''Die Option '''--with-ccachedir''' bewirkt auch das die mit '''[[Make|make]] [[Ccache|ccache]]''' installierte Version im [[CDK|CDK]] und/oder auch die evtl. im System installierte Version ignoriert wird!''

*--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|ccache]] -s
prüfen. Als Ergebnis werden einige Statistiken ü[[BER|ber]] das Cache-Verhalten von [[Ccache|ccache]] ausgegeben:
cache directory /home/<USER>/.[[Ccache|ccache]]
cache hit 4
cache miss 191
called for [[Link|link]] 17
multiple source files 4
compile failed 17
preprocessor error 2
not a C/C++ file 5
autoconf compile/[[Link|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|make]] [[Yadd|yadd]]-[[Neutrino|neutrino]]
Am Ende des Bauvorganges werden damit die entsprechenden Zeitinformationen ausgegeben.

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

==== [[Neutrino|neutrino]]-[[Jffs2|jffs2]]-[[Image|Image]] ====
#! /bin/bash
# beispiel.sh
# Diese Script baut [[Neutrino|neutrino]]-[[Jffs2|jffs2]] [[Images|Images]], jeweils 1x und 2x
#----------------------------------------------
USERDIR=/home/$(whoami)
#----------------------------------------------
LOGODIR=$USERDIR/Logos
CP=$USERDIR/[[Tuxbox|tuxbox]]-[[CVS|cvs]]
DB=$USERDIR/[[Dbox2|dbox2]]
ARCHIVEDIR=$USERDIR/Archive
export CVS_RSH=[[SSH|ssh]]
#-----------------------------------------------
cd "$CP"
[[CVS|cvs]] -d anoncvs@[[CVS|cvs]].[[Tuxbox|tuxbox]].org:/[[CVS|cvs]]/[[Tuxbox|tuxbox]] -z3 co -f -r newmake -P .
cd [[CDK|cdk]]
/bin/ln -sf $ARCHIVEDIR/ Archive
./autogen.sh
./configure --prefix="$DB" --with-cvsdir="$CP" --enable-flashrules --enable-[[Ccache|ccache]] --with-[[CheckImage|checkImage]]=rename --with-logosdir="$LOGODIR"
[[Make|make]] [[Flash|flash]]-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]-all

==== [[Neutrino|Neutrino]] [[Yadd|YADD]] ====
#! /bin/bash
# beispiel.sh
# Diese Script baut ein [[Neutrino|Neutrino]] [[Yadd|Yadd]]
#----------------------------------------------
USERDIR=/home/$(whoami)
#----------------------------------------------
LOGODIR=/Logos
CP=$USERDIR/[[Tuxbox|tuxbox]]-[[CVS|cvs]]
DB=$USERDIR/[[Dbox2|dbox2]]
ARCHIVEDIR=$USERDIR/Archive
export CVS_RSH=[[SSH|ssh]]
#-----------------------------------------------
cd "$CP"
[[CVS|cvs]] -d anoncvs@[[CVS|cvs]].[[Tuxbox|tuxbox]].org:/[[CVS|cvs]]/[[Tuxbox|tuxbox]] -z3 co -f -r newmake -P .
cd [[CDK|cdk]]
/bin/ln -sf $ARCHIVEDIR/ Archive
./autogen.sh
./configure --prefix="$DB" --with-cvsdir="$CP" --with-logosdir="$LOGODIR" --enable-[[Ccache|ccache]]
[[Make|make]] [[Yadd|yadd]]-[[Neutrino|neutrino]]

= Was kommt dann...? =
== Booten von [[Yadd|YADD]] ==
Wenn ein [[Yadd|YADD]] frisch erzeugt wurde, kann damit auch die Box booten. Näheres dazu auch im Artikel [[CDK booten]]. 
Newmake hält auch ein [[Make|Make]]-Target für den serversupport bereit.
[[Make|make]] serversupport
Dieses erzeugt einige Konfigurationsdateien für den [[Server|Server]] der das [[Yadd|YADD]]-Build nahtlos an das [[Server|Server]]-Setup anknüpft.

== [[Flashen|Flashen]] des [[Images|Images]] ==
Wenn ein [[Image|Image]] gebaut wurde, ist der logische nächste Schritt das Einspielen des [[Images|Images]] in den [[Flash|Flash]] der Box. Hierfür ist entweder, das interaktive [[Flashen|Flashen]] innerhalb der [[GUI|GUI]] mit den [[Installation:Neutrino|Expertenfunktionen]] zu benutzen, oder der ''dboxflasher'' zu verwenden. Der dboxflasher wird durch das [[Make|Make]]-Target
[[Make|make]] serversupport
erzeugt. Andere Möglichkeiten des Flashens werden [[Installation|hier]] beschrieben.

== Inkrementelle Builds ==
Im allgemeinen ist man nicht an einem einmaligen Build der [[Software|Software]] interessiert. Verbesserungen an den Quellen werden in das [[CVS|CVS]] täglich eingecheckt. Oft möchte man die [[Software|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|make]] [target]
und [[Make|make]] wird es, falls notwendig, neu erzeugen.

Es kann auch passieren, dass [[Make|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|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|Installation]] eines bestimmten Pakets wird durch das Anlegen einer Markerdatei im Verzeichnis ''[[CDK|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|make]] distclean
Das drastischste Reinigungs-Target, (fast) alles löschend, was nicht vom [[CVS|CVS]] ausgecheckt wurde.
Dieses ist eher selten notwendig.
 
[[Make|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|Yadd]]-[[Installation|Installation]]), sowie die [[Tftp|TFTP]]-Files ([[Kernel|Kernel]] und [[U-boot|u-boot]]) werden nicht angefasst.
 
[[Make|make]] depsclean
Löscht alle Markerdateien im /[[CDK|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|make]] clean
Kombiniert ''mostlyclean'', ''depsclean'', und ''[[Flash|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|make]] bootstrap''.
 
[[Make|make]] [[Flash|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|make]] [[Flash|flash]]-mostlyclean
Zusätzlich zum ''[[Flash|flash]]-semiclean'' löscht dieses Target auch Bootfiles und die Kernbauverzeichnisse. Vollimages werden unberührt gelassen.
 
[[Make|make]] [[Flash|flash]]-clean
Dieses Target löscht Alles in $(flashprefix).
 
Einige Quellverzeichnisse können mit einem Befehl wie
[[Make|make]] -C /[[Tuxbox|tuxbox]]-[[CVS|cvs]]/apps/[[Tuxbox|tuxbox]]/[[Neutrino|neutrino]] clean
gesäubert werden.

== Aktualisierung des [[CVS|CVS]]-Quellcodes ==
Um die Quellen mit neueren Checkins zu aktualisieren, verwende diesen Befehl für das toplevel [[CVS|CVS]] Verzeichnis (oder von einem anderen Verzeichnis, wenn Ihr wisst, was ihr tut;-). Mögliche Fehler werden in das logfile [[CVS|cvs]].log geschrieben.

[[CVS|cvs]] up -f -r Newmake -dP > [[CVS|cvs]].log 2>&1

'''Tipp'''
 
Um mit dem [[CVS|CVS]] arbeiten zu können nimmt man für gewöhnlich die Konsole für Eingaben. Es gibt aber auch verschiedene Frontendwerkzeuge wie z.B. [http://www.crossvc.com CrossVC] oder [http://cervisia.kde.org/ Cervisia] um nur einige zu nennen, die einen recht komfortablen Umgang mit den [[CVS|CVS]]-Daten ermöglichen. [[Bild:Crossvc.jpg|CrossVC als CVS Frontendlösung]] [[Bild:Cervisia.jpg|Cervisia als CVS Frontendlösung]] 
Auch einige [[IDE|IDE]]'s wie z.B. [[WP:Anjuta|Anjuta]] [[Bild:anjuta.jpg|Anjuta als IDE mit CVS-Anbindung]] bieten solche [[CVS|CVS]]-Schnittstellen an.

== [[Customization|Customization]] ==
Bisher lief immer alles darauf hinaus [[Images|Images]] oder Yadds zu bauen, die aus unveränderten [[CVS|CVS]]-Quellen gebaut wurden. 
[[Images|Images]] und die Yadds können aber auch angepasst ("customized") werden, ohne die [[Makefiles|Makefiles]] zu ändern.
 
Hier gibt es verschiedene Möglichkeiten.

=== Konfigurationsoptionen ===
hier einige nützliche Optionen: 
Hiermit kann ein Verzeichniss angegeben werden, welches die [[Ucodes|Ucodes]] enthält, die im [[Image|Image]] enthalten sein sollen.
--with-ucodesdir=[DIR]
'''Hinweis:''' 
Ein [[Image|Image]], dass [[Ucodes|ucodes]] enthält, darf
nicht verbreitet werden! 
 
 
Mit der Option
--with-logosdir=[DIR]
kann ein Verzeichniss angegeben werden, das boot-logos (logo-[[LCD|lcd]] und logo-fb) enthält, die im [[Image|Image]] enthalten sein sollen.
 
 
Diese Option
--with-defaultlocale=[LOCALE]
sorgt dafür, dass die gewünschte Sprache schon beim bauen eingestellt wird.

=== Ändern der Partitionierung ===
Die Rootpartitionsgröße für [[Cramfs|cramfs]] und [[Squashfs|squashfs]] [[Images|Images]] kann mit der Configure-Option
--with-rootpartitionsize=[SIZE]
angegeben werden.
 
Die Größe der var-[[Partition|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|jffs2]]-Imageerstellung unsinnig wäre.

=== Variablen ===
==== Pfade ====
Es sind noch weitere Benutzeranpassungen möglich. Dafür ist es aber notwendig, etwas [[Wissen|Wissen]] ü[[BER|ber]] die innere Funktionsweise der [[Makefiles|Makefiles]] zu haben. 
In der Folge bezeichnet
$(flashprefix)
den Wert der Makefile Variablen '''flashprefix''' (mit Konfiguration wie oben '''/[[Dbox2|dbox2]]/cdkflash''')
$(targetprefix)
bezeichnet den Wert der Makefile Variablen '''targetprefix''' (mit Konfiguration wie oben '''/[[Dbox2|dbox2]]/cdkroot'''), und
$(buildprefix)
bezeichnet den Wert der Makefile Variablen '''buildprefix''' (mit der Konfiguration oben '''/[[Tuxbox|tuxbox]]-[[CVS|cvs]]/[[CDK|cdk]]''').
 
 
Um z.B. ein '''[[Neutrino|neutrino]]-[[Cramfs|cramfs]].img2x''' zu erzeugen, werden die folgenden Verzeichnisse erstellt: 
*'''$(flashprefix)/root''' (enthält [[Filesystem|Filesystem]]- und [[GUI|GUI]]-unabhängige Bestandteile)
*'''$(flashprefix)/root-[[Cramfs|cramfs]]''' (enthält den [[Kernel|Kernel]], für Root-[[Filesystem|Filesystem]] auf [[Cramfs|cramfs]] konfiguriert, zusammen mit seinen Treibern) und
*'''$(flashprefix)/root-[[Neutrino|neutrino]]''' (enthält die Neutrinoinstallation).
 
Aus diesen drei Verzeichnissen, werden das Rootfilesystemverzeichniss
*'''$(flashprefix)/root-[[Neutrino|neutrino]]-[[Cramfs|cramfs]]''' und das
var-filesystemverzeichnis
*'''$(flashprefix)/var-[[Neutrino|neutrino]]''' gebaut.
 
Hiermit ist es möglich, einen Befehl wie
[[Make|make]] $(flashprefix)/root-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]
bzw. wenn man sich im Verzeichnis ''./[[Tuxbox|tuxbox]]-[[CVS|cvs]]/[[CDK|cdk]]'' befindet, den Befehl
[[Make|make]] root-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]
einzugeben, wobei man bei erster VAriante natürlich '''$(flashprefix)''' selbst durch den realen Pfad ersetzen muss, da '''$(flashprefix)''' nur eine [[Make|make]]-Variable ist, welche in unserem Beispiel den Pfad zu '''./[[Dbox2|dbox2]]/cdkflash''' darstellt. 
Man kann so manuell gewünschten Änderungen an '''$(flashprefix)/root-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]''' vornehmen, und dann, mit dem Befehl
[[Make|make]] [[Flash|flash]]-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]-2x
den Imagebau abschließen, um ein [[Image|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|Customization]]-Scripte ===
Sofern diese Scripte vorhanden und ausführbar sind, werden innerhalb der wichtigsten Targets diese sogenannten ''[[Customization|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|cdk]]'''-Ordner.
Bei Bedarf kann mit der Option
--with-customizationsdir=[DIR]
ein alternatives Verzeichnis für [[Customization|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|Shell]]-Scripts könnte dies z.B. ein kompiliertes C Programme, oder ein [[Perl|Perl]]-Script sein. 
Der Name eines [[Customization|Customization]] Scriptes besteht in der Regel aus dem Namen eines Targetverzeichnisses bzw. einem Target und dem angefügtem *'''-local.sh'''. 

==== Für [[Flash|Flash]]-Targets ====
Der Name der [[Customization|Customization]] Scripte für [[Images|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
*[[Neutrino|neutrino]]
*[[Enigma|enigma]]
*[[Lcars|lcars]]
*[[Radiobox|radiobox]]
 
"[[FS]]" zeigt an welches [[Filesystem|Filesystem]] gemeint ist.
*[[Cramfs|cramfs]]
*[[Squashfs|squashfs]]
*[[Jffs2|jffs2]]
 
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|neutrino]]-local.sh
root-[[Neutrino|neutrino]]-[[Squashfs|squashfs]]-local.sh
root-[[Squashfs|squashfs]]-local.sh
var-[[Neutrino|neutrino]]-local.sh

==== Für [[Yadd|Yadd]]-Targets ====
Für Yadds ist das Prinzip ähnlich, nur dass es hier quasi nur einen Ordner gibt. Dafür stellvertretend steht dann
*[[Yadd|yadd]]. 
Das "[[GUI]]" in Klammern bezeichnet auch hier die jeweilig betroffene Benutzeroberflche, also
*[[Neutrino|neutrino]]
*[[Enigma|enigma]]
*[[Lcars|lcars]]
*[[Radiobox|radiobox]]
 
so wäre die Bezeichnung der jeweiligen Scripte so aufgebaut.
*[[Yadd|yadd]]-[GUI]-local.sh
'''Beispiel:'''
[[Yadd|yadd]]-[[Neutrino|neutrino]]-local.sh

==== Andere [[Customization|Customization]] Scripte ====
Die bisher benannten [[Customization|Customization]] Scripte für [[Flash|Flash]]- u. [[Yadd|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|make]] hdparm
aus, wird beim Bauen das ausgeführt was im [[Customization|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: 
Während des [[Make|make]]-Durchlaufs werden einige Targets ausgeführt, welche die '''/.version'''-Files bei [[YADD]]
*'''version'''
bzw.
*'''[[Flash|flash]]-version'''
im [[Image]] erstellt.
 
Sofern eines dieser Scripte;
*'''version-local.sh'''
*'''[[Flash|flash]]-version-local.sh'''
vorhanden und ausführbar ist, wird es als Ersatz statt des originalen Targets ausgeführt, welches mit
[[Make|make]] version
bzw.
[[Make|make]] [[Flash|flash]]-version
angestoßen wird.

==== weitere Beispiele für Custiomization ====
Das Custiomizationscripting soll durch das folgende Beispiel noch mehr veranschaulicht werden.
Beispiel:

In einem [[Jffs2|jffs2]]-[[Image|Image]] wird dies gewünscht:

1. Eigene /etc/hosts benutzen,
2. Eigene [[Neutrino|neutrino]].conf, [[Bouquets|bouquets]].[[XML|xml]], services.[[XML|xml]] benutzen
3. einschließlich [[Lirc|lirc]]-Komponenten, zusammen mit eigenen [[Lirc|lirc]] Konfigurations-Dateien.

1. und 3. sind [[Erweiterungen|Erweiterungen]], die nach '''$(flashprefix)/root''' kommen sollten, während 2. [[Neutrino|Neutrino]]-regeln sind, welche nach sollten '''$(flashprefix)/root-[[Neutrino|neutrino]]-[[Jffs2|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|make]] flashlirc
cp -fr $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Lirc|lirc]] $newroot/var/[[Tuxbox|tuxbox]]/config

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

#!/bin/sh
# root-[[Neutrino|neutrino]]-local.sh
flashprefix=$1
buildprefix=$2
newroot=$flashprefix/root-[[Neutrino|neutrino]]
myfiles=/home/somewhere/dbox/myfiles
cp $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Neutrino|neutrino]].conf $newroot/var/[[Tuxbox|tuxbox]]/config
cp $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]/[[Bouquets|bouquets]].[[XML|xml]] $newroot/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]
cp $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]/services.[[XML|xml]] $newroot/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]

'''Bitte beachten:'''
Diese Scripte sollen als Beispiele dienen und können vermutlich nicht ohne Anpassung verwendet werden.

= 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|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|Customization]] Scripte für den eigenen Bedarf schreibt.

== Idempotens ==
Es ist fast immer eine gute Idee zu versuchen, ein Installationsscript [[Wikipedia:Idempotent|idempotent]] zu schreiben. Dies bedeutet, dass das mehrmalige Ausführen den gleichen Effekt hat wie das einmalige Ausführen.
Benutze "[[Make|make]] install".
 
In der Vergangenheit hat das [[Tuxbox|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|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|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|gui]]-[[Filesystem|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 [[Wikipedia:Inkonsistent|inkonsistenten]] Zustand versetzen. Dies gilt insbesondere für die Verzeichnisse in '''$(flashprefix)'''. Wenn der Bau solch eines [[Make|Make]]-Targets abbricht, besteht das Verzeichnis, ist entsprechend seiner Änderungszeit aktuell, und ein folgender [[Make|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|Br]]üche geht, '''dann lösche man es''', bevor ein anderer [[Make|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|Hilfe]] benötigt, siehe unten!.

=== Nach dem [[Flashen|Flashen]]: "Kein System" auf dem [[LCD|LCD]]/Was ist diese "bad magic byte" Zeugs? ===
Diese Frage kommt hoffentlich nicht... Die kurze Antwort ist: Man weiß es nicht. Wir [[Wissen|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|Image]] "ist" in Ordnung, es ist nur dass irgendwelche [[Firmware|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|CVS]], zu finden im Verzeichnis '''./hostapps/[[CheckImage|checkImage]]''' ermittelt diese "schlechten Bytes", aber ändert nichts daran, um diese zu beheben. Die Erfahrung zeigt, daß [[Images|Images]], die [[checkImage]] für gut findet, wirklich laufen. [[Cramfs|Cramfs]]-, oder [[Squashfs|squashfs]] [[Images|Images]], worü[[BER|ber]] sich [[CheckImage|checkImage]] beschwert, laufen im allgemeinen nicht, in einigen Ausnahmefällen läufen sie aber doch.
 
Auch bei [[Jffs2|jffs2]]-[[Images|Images]] ist dies manchmal der Fall, dass sich [[checkImage]] beschwert, die [[Images|Images]] laufen, aber eben nicht immer. Mit diesen empirischen Beobachtungen ist man nun sich selbst überlassen.
 
Newmake weiß, wie dieses Programm aufgerufen werden kann, um die erzeugten [[Images|Images]] automatisch zu überprüfen. Die Konfigurationsoption
--with-[[CheckImage|checkImage]]=[none,rename,warn]
wird hierfür verwendet. Falls '''warn''' gewählt ist, wird für jedes [[Image|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 erwähnt werden, daß die "schlechten magischen Bytes" in einem (oder mehreren!) der Partitionsteile sitzt, und werden nicht durch den abschließenden Schritt erzeugt (die *.img1x und/oder *.img2x Files bauen). Es ist auch möglich, [[CheckImage|checkImage]] auf die Partitionsfiles anzuwenden *.[[Jffs2|jffs2]], *.[[Cramfs|cramfs]]
*.[[Squashfs|squashfs]]
*.flfs1x
*.flfs2x
Schließlich hat [[CheckImage|checkImage]] eine Debugoption, die nützlich sein kann.

== Ich habe ein Fehler gefunden! ==
Bugs, Unklarheiten, Verbesserungsvorschläge, etc. der [[Software|Software]] sollten vorzugsweise im [http://tuxbox-forum.dreambox-fan.de/forum/viewforum.php?f=7 Cross Development Kit - Forum] des [[Tuxbox|Tuxbox]]-Boards gepostet werden.

== Ich benötige [[Hilfe|Hilfe]]! ==
Supportanfragen können im [http://tuxbox-forum.dreambox-fan.de/forum/viewforum.php?f=7 Cross Development Kit - Forum] des [[Tuxbox|Tuxbox]]-Boards gepostet werden. Postings in deutsch oder englisch sind willkommen. Bitte nicht vergessen, die benutzten Konfigurationsoptionen zu erwähnen.

=Anhang=
==Einige nützliche [[Customization|Customization]] Script Snippets==
In diesem Anhang werden einige nützliche [[Customization|Customization]] Scripte gezeigt. Zwei Scripte sind bereits oben gezeigt worden.
 

'''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.

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

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

=== /.version anpassen ===
Euere eigene ''/.version''-File herzustellen (anggezeigt von [[Neutrino|Neutrino]] durch dBox -> Services -> [[Image|Image]]-Version und cdkVcInfo beim Booten) ist sicher ein allgemeiner Wunsch.

*[[Flash|flash]]-version-local.sh

#/bin/sh
USER=$(whoami)
if [ $0 = $CDIR/flash-version-local.sh ] ; then
outfile=$FLASHDIR/root/.version
type="[[Image|Image]]"
else
outfile=$TARGETDIR/.version
type="[[Yadd|Yadd]]"
fi;
echo Creating $outfile ...
echo "version=`./mkversion -[[Snapshot|snapshot]] -version 200`" > $outfile
echo "creator=$USER" >> $outfile
echo "imagename=$USER-$type" >> $outfile
echo "homepage=[[HTTP|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|release]])
releasetype=0
;;
-[[Snapshot|snapshot]])
releasetype=1
;;
-internal)
releasetype=2
;;
-version)
versionnumber=$2
shift
;;
esac
shift
done
echo $releasetype$versionnumber$year$month$day$hour$minute

=== Archivierung der [[Images|Images]] ===
Es ist eigentlich die Aufgabe des Buildprozesses, flashbare [[Images|Images]] zu erzeugen, und nicht sie zu archivieren. Jedoch kann die [[Customization|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]-[cramfs, squashfs,jffs2].[img1x, img2x]
haben. Es benennt die Files entsprechend dem Tagesdatum um.

=Links=
*[http://www.gnu.org/software/make/manual/make.html GNU Make manual]
*[http://www.gnu.org/software/autoconf/manual/ Autoconf manual]
*[http://www.gnu.org/software/automake/manual/ Automake manual]
*[http://sources.redhat.com/autobook/ GNU Autoconf, Automake, and Libtool]
*[http://www.gnu.org/prep/standards/ GNU Coding standards]
*[http://cvsbook.red-bean.com/ Open Source Development with CVS, 3rd Edition]
*Barf's Homepage: [http://bengt-martensson.de/dbox2/ Barfs ][[Newmake]]-Dokumentation]

{{review}}

{{body}}

Sectionsd

2008-06-30T19:26:16Z

Dixidix: Steuerkommandos eingebaut

[[Category:Register]]
[[Category:Linux]]
[[Category:DBox2 Software]]
__TOC__

=Allgemeines=
Der ''Sections-[[Daemon]]'' ist unter [[Neutrino]] für das Sammeln, Aufbereiten und zur Verfügung stellen der [[EPG]]-Daten zuständig.

Er gilt als eine der Schwachstellen von [[Neutrino]], da diverse Instabilitäten und Fehlverhalten von ihm bekannt sind.

=Benutzung über die Kommandozeile=
Neben Neutrinointernen Steuerbefehlen, die direkt im Quellcode von [[Neutrino]] verbaut sind, von denen man im Regelfall nur aus dem [[Bootlog]] einiges zu sehen bekommt, kann der ''Sectionsd'' auch über einige Kommandos von Hand gesteuert werden. Nützlich können diese Befehle z.B. zum erstellen von [[Scripts]] oder zur Fehlersuche mittels [[Bootlog]] sein. (siehe auch [[Neutrino:Customizing#Ereignisse_abfangen|Customizing]])

Hier einige Beispiele:

Aufrufen mit
/var # sectionsdcontrol
usage: sectionsdcontrol --pause stop sectionsd
sectionsdcontrol --nopause restart sectionsd
sectionsdcontrol --state get sectionsd runstate
sectionsdcontrol --wepg <epgdir> write epgfiles to dir
sectionsdcontrol --repg <epgdir> read epgfiles from dir
sectionsdcontrol --freemem unloads all events
sectionsdcontrol --restart restart sectionsd

{{MissingText}}

{{Review}}

{{body}}

Dbox2 Entwicklungsumgebung

2008-06-26T08:17:15Z

Dixidix:

[[Category:Register]]
[[Category:Development]]
[[Category:CDK]]
{{Development_sidebar}}

__TOC__
{{Review}}
=Allgemeines=
Newmake ist eine Überarbeitung des alten "[[Make|make]]" Prozesses, inzwischen auch als [[Image erstellen|Oldmake]] bezeichnet, und wurde durch Barf ins Leben gerufen.
Neben einer deutlich strukturierteren Basis, bietet [[ES|es]] unter anderem auch den Vorteil, dass [[ES|es]] auch ohne ohne groß[[ES|es]] Verständnis für den Buildprozess gelingen kann, [[Images|Flashimages]] und [[yadd|YADDs]] unter [[Linux|Linux]] zu erstellen.
Basierend auf Newmake gibt [[ES|es]] inzwischen auch eine auf Scripts basierende Quasi-Frontendlösung, mit der sich [[Images|Flashimages]] oder [[yadd|YADDs]] benutzerdefiniert erstellen lassen, das sogenannte [[yBuild]]. 
Dieser Artikel basiert zum größtem Teil auf die deutsche Version von [http://bengt-martensson.de/dbox2/ Barfs Newmake-Dokumentation], die er uns freundlicheweise zur Verfügung gestellt hat.
Eine detaillierte Beschreibung (auch der [[Make|make]] targets) unter anderem auch in englischer Sprache befindet sich auf [http://bengt-martensson.de/dbox2/ Barf's Homepage]. 

Dieser Artikel behandelt Newmake aus Sicht des Benutzers (nicht Entwickler). [[ES|Es]] behandelt die [[Image]]- u. [[yadd|YADD]]-Herstellung sowie einfache Beipiele für Benutzeranpassungen ("[[Customization]]"). 

==Zur Geschichte==
Vor einigen Jahren war die Imageherstellung für die [[Tuxbox|Tuxbox]] so etwas wie [[Wikipedia:Schwarze Kunst|"Schwarze Kunst"]].
Die Makefile-Unterstützung war, insbesondere für andere [[Images]] als [[cramfs]]-[[Images]], ziehmlich 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|CVS]]-Verzeichnis ''.../hostapps/[[Mkflfs|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|CVS]]-Sources mit einigen mehr-oder-weniger geheim gehaltenen "Fixes", (vermutlich) notwendig für das Herstellen eines funktionierenden [[Images]] aus dem [[CVS|CVS]]-Quellcode.
 
 
Im August 2003, wurde [[ES|es]] für das [[DBox2 Software Projekt|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|Software]]-Design... 
Ein [[Image]] aus reinen [[CVS|CVS]]-Dateien zu bauen, war nicht wirklich möglich.
 
 
2004 wurde das [[YADI]] ("'''Y'''et '''A'''nother '''D'''Box '''I'''mage") Projekt geboren. 
Sein Ziel war [[ES|es]], das "Imagebauen" zu automatisieren und zu vereinfachen. Zu diesem Zweck wurden eine Anzahl von [[Wikipedia:Skripte|Scripten]] und [[Wikipedia:Patches|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|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|Skript]] war das automatische Imagebuilden zwar möglich, jedoch statt grundlegende Schwächen im [[CDK|CDK]]-Imagebau-Prozeß zu beseitigen, stellte man [[Skripte]] zum Imagebauen zur Verfügung. [[ES|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, verfügbar als alternativer [[Branch]] im [[CVS|CVS]], versucht diese Schwächen zu beseitigen. 
 
Ein spezieller Dank an jedem, der Bugreports und Feedback geliefert hat. Insbesonderes gilt dies für dietmarw, der Newmake benutzt, um die [[images|dietmarW-Images]] zu erzeugen.

=Ziel=
Das Ziel des vorliegenden Artikels ist [[ES|es]], dem Leser grundlegendes Know-How zu vermitteln. [[ES|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 [[Wikipedia:Skriptsprache|Shellskripten]] wird für viele Teile, insbesondere für das [[Customization]]-Kapitel, aber nicht für [[Image]]/[[yadd|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|Tuxbox]]-Forums hingewiesen. Alle Optionen für ''configure'' werden auch nicht beschrieben, nur die Allgemeinsten und Wichtigsten.

= Wie schwierig ist [[ES|es]]? =
Die Antwort könnte lauten: ''[[ES|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|es]] kein Probleme sein. Leser, für die das Meiste nur Kauderwelsch ist, sollten vielleicht besser bei fertigen [[Images|Images]] bleiben.

= [[Images|Images]] und [[Yadd|YADD]]'s bauen=
== Targets ==
[[ES|Es]] gibt neben zahlreichen untergeordneten Zielen (Targets), zwei hauptrangige Targets. Diese wären entweder
*[[YADD]]
oder
*[[Image]].
Ein [[YADD]] besteht aus einigen Dateien, die die DBox anstatt aus dem [[Flash]] ü[[BER|ber]] den [[TFTP]]-Service lädt, sowie ein [[Filesystem|Filesystem]], das ü[[BER|ber]] einen [[NFS-Server]] der dBox zur Verfügung gestellt wird.
 
Diese Betriebsart hat insbesondere während der Softwareentwicklung oder beim Erlernen des Systems viele Vorteile. 
Der Name "[[YADD]]" bedeutet übrigens "'''Y'''et '''A'''nother '''D'''Box '''D'''istribution" ("noch eine dBox Verteilung").

=== Erste Schritte und Überlegungen ===
Eine Empfehlung für den angehenden "[[Image|Image]]/[[Yadd|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|Image]] mit der Lieblings-[[GUI]] zu erstellen.

Meistens möchte man die folgenden Schritte kombinieren und/oder automatisieren.
 
In diesem Artikel bezeichnet "[[GUI]]" entweder
*[[Neutrino]] oder
*[[Enigma]]
*[[Lcars]]
*[[Radiobox]].
 
Das "[[Filesystem]]" im Kontext eines kompletten [[Images]] bezeichnet das [[Dateisystem]], in dem das root-Verzeichnis liegt. Diese kann ein
*[[cramfs]] (ein komprimiertes, Read-only [[Filesystem|filesystem]] für embedded Systeme) sein,
*[[squashfs]] (ein weiterd komprimiertes read-only-[[Dateisystem|Dateisystem]], was leistungsfähiger als [[cramfs]] betrachtet wird)
oder
*[[jffs2]] (ein "journalled" Read-Write-[[Filesystem|Filesystem]]).
Ein "[[Cramfs|cramfs]] Komplett-[[Image|Image]]" besteht aus einem Root-[[Dateisystem|Dateisystem]] mit dem [[cramfs]] [[Dateisystem|Dateisystem]] und einem kleineren [[jffs2]]-[[Filesystem|Filesystem]], das nach '''/var''' gemounted wird.
 
Analog gilt dies auch für "'''[[Squashfs|squashfs]] Komplett-[[Images|Images]]'''", während ein "'''[[Jffs2|jffs2]] Komplett-[[Image|Image]]'''" kein separates ''/var-[[Dateisystem|Dateisystem]]'' enthält, weil [[Jffs2|jffs2]] an sich beschreibbar (var) ist.
 
Zusätzlich enthalten die Komplett-[[Images|Images]] eine weitere [[Partition|Partition]], die den [[u-boot]]-[[Bootloader]] enthalten. Diese [[Partition|Partition]] ist zwischen dBoxen mit einen und zwei Flashchips unterschiedlich. Dieses wird durch "'''1x'''" und "'''2x'''" angezeigt. Ein komplettes [[Image|Image]] würde demnach so benannt werden:

[neutrino, enigma]-[cramfs, squashfs, jffs2].img[1, 2]x,
z.B. als fertiges [[Image|Image]]:
[[Neutrino|neutrino]]-[[Jffs2|jffs2]].img2x.

== Buildsystem Voraussetzungen ==
Die Voraussetzungen auf dem Buildhost können in etwa so zusammengefasst werden:
 
Ein modernes [[Unix|Unix]]/[[Linux|Linux]] System mit ca. 2 GB freiem Speicherplatz. Epfehlenswert ist [[ES|es]] aber mehr Speicherplatz einzuplanen, da beispielsweise bei Verwendung von [[ccache]] einiges an Daten zwischengelagert wird und je öfter man kompiliert, [[ES|es]] dann doch eng werden könnte.

Das [[DBox2 Software Projekt|Tuxbox Projekt]] hat keine favorisierte Buildumgebung. Fragen wie "geht [[ES|es]] mit Redhat x.y?" lassen sich nicht genau beantworten. Der Grund hierfür ist, dass niemand sich wirklich dafür interessiert, die Eigenschaften der bestimmten Distributionen zu erkunden. Gewisse Anforderungen werden dagegen für Versionen der Werkzeuge, wie [[WP:autoconf|autoconf]], [[WP:automake|automake]], [[make]] usw. formuliert. Die meisten davon sind in den gängigsten Distributionen bereits enthalten bzw. können nachinstalliert werden. Die momentan erfordelichen Toolversionen sind in folgendender Tabelle zusammengefasst:
 
{{Vorlage:GNU_Tools}}
 
Der Buildprozess überprüft zu Beginn automatisch einige dieser Anforderungen. Wenn eines dieser [[Tools|Tools]] fehlt, oder wenn die Version zu alt zu sein scheint, ist [[ES|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|Anleitungen]] zum Buildvorgang wird gefordert, dass [[Tools|Tools]] 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
erfordelich, da einige entweder überhaupt nicht benötigt werden bzw. die [[Installation|Installation]] im
Makeprozess selbst vorgenommen wird!
 ''
Builden auf einem [[Unix|Unix]]-non-[[Linux|Linux]] System sollte vermutlich auch möglich sein, so weit die erforderlichen [[GNU]] Werkzeuge vorhanden sind. Mit einem anderen [[make]] als [[GNU]] wird [[ES|es]] fast sicher nicht funktionieren, da die [[GNU|GNU]]-[[Erweiterungen|Erweiterungen]] uneingeschränkt verwendet werden.
 
[[ES|Es]] wird daher davon abgeraten eine Umbegebung z.B. mit [[Cygwin]] aufzubauen, da [[ES|es]] höchstwahrscheinlich nicht funktionieren wird. In dieser Richtung wurde zwar Einiges für den Makeprozess eingebaut, jedoch dürfte der gegenwärtige Entwicklungsstand nicht den gegenwärtigen Anforderungen entsprechen, um aktuell auch damit arbeiten zu können.
 
Empfehlenswert ist allerdings eine Buildumgebung mittels [[VMWare]] aufzubauen. Hierfür gibt [[ES|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.

== Auschecken ==
Die [[Tuxbox|Tuxbox]] Quellen werden durch den [[Tuxbox|Tuxbox]] [[CVS-Server]] bereitgestellt. 
Regelmäßige Quellreleases sind niemals gemacht worden, und sind auch nicht für die Zukünft geplant. Für unsere Zwecke werden die Quellen anonym "ausgecheckt", was bedeutet, dass diese auf die eigene Festplatte kopiert werden, indem man zuerst auf einer (lokalen) Festplatte mit "ordentlich" freiem Platz ein leeres Verzeichnis erstellt, z.B. ''/[[Tuxbox|tuxbox]]-[[CVS|cvs]]'' und in diesen Ordner wechselt, und diesen Befehl ausführt.

[[CVS|cvs]] -d anoncvs@[[CVS|cvs]].[[Tuxbox|tuxbox]].org:/[[CVS|cvs]]/[[Tuxbox|tuxbox]] -z3 co -f -r newmake -P .

Dieser Befehl checkt die Newmake Files aus. In Fällen, in denen keine Newmake Version vorhanden ist, wird die HEAD-Version ausgecheckt.
 
'''Hinweis:'''
''Im HEAD gibt [[ES|es]] zwei Files:''
*[[CDK|cdk]]/root/etc/init.d/rcS
''und''
*[[CDK|cdk]]/root/etc/init.d/rcS.insmod
''Im [[Newmake]] werden diese nicht benötigt da sie mittels''
[[CDK|cdk]]/root/etc/init.d/rcS.m4
''erzeugt werden.''
''Um auf der sicheren Seite zu sein, ist [[ES|es]] ratsam, diese beiden zu löschen''.
 
Nachdem die Daten ausgecheckt wurden, könnte kann man jetzt einige Patches auf die Quellen anwenden. 
Wenn man aber zum ersten Mal kompiliert, ist [[ES|es]] ratsam, vorerst keine Patches anzuwenden. Wenn Probleme auftreten, ist [[ES|es]] viel einfacher (technisch sowohl als auch für jeden selbst) jemand zu helfen, der die "unveränderten [[CVS|CVS]] Quellen" verwendet.

== Konfiguration ==
Jetzt müssen einge Zwischenschritte erledigt werden, damit der Buildprozess auch erkennt, was und vorallem wie er [[ES|es]] machen soll.
 
Man wechselt nun in das [[CDK|CDK]]-Unterverzeichnis
cd [[CDK|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|Images]], [[Yadd|YADD]] oder aller anderen gewünschten Ziele entsprechend den Benutzerwünschen vorzubereiten.

=== Optionen ===
{{Newmake_Build_Optionen}}

Für uns sind vorerst nur wenige Optionen interessant. Die Standardvorgaben reichen vorerst völlig aus. 
Eine typische Anwendung (Konfiguration), der mit z.B. den Pfadnamen oben kompatibel wäre, könnte so eingestellt werden:

./configure --with-cvsdir="/[[Tuxbox|tuxbox]]-[[CVS|cvs]]" --prefix="/[[Dbox2|dbox2]]" --enable-maintainer-mode

*''--with-cvsdir''
sagt wo die Quellen zu finden sind, (darin sollte auch ein Unterverzeichnis ''.../[[CDK|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|Makefiles]] ermöglicht, sich automatisch neu zu erzeugen, sobald die Notwendigkeit entsteht, zum Beispiel nach einem [[Software|Software]]-[[Update|Update]].

[[ES|Es]] gibt sicher noch andere nützliche Optionen. Einige werden später noch besprochen.

=== 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|tuxbox]] [[Mklibs|mklibs]]
checking for mkcramfs... no
configure: WARNING: using [[Tuxbox|tuxbox]] [[Cramfs|cramfs]]
checking for mkjffs2... no
checking for [[Mkfs.jffs2|mkfs.jffs2]]... no
configure: WARNING: using [[Tuxbox|tuxbox]] [[Mkfs.jffs2|mkfs.jffs2]]
checking for mksquashfs... no
configure: WARNING: using [[Tuxbox|tuxbox]] [[Squashfs|squashfs]]
...

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

'''''Beachte!'''
Wenn man diesen Artikel mit ähnlichen Beschreibungen aus vergangenen Zeiten
vergleicht, bemerkt man, dass die Option '''--with-targetruleset=[standard,flash]''' nicht mehr
vorhanden ist. Bisher war [[ES|es]] notwendig, bei der Konfiguration sich entweder auf Builds von [[YADDs]]
oder [[Images]] einzuschränken. Bei Newmake ist dieses nicht mehr notwendig.
 ''
 
[[Bild:Stop hand.png]]
<div style="margin: 0; margin-top:10px; margin-right:0px; border: 3px solid #FF0000; padding: 0px 10px 1px 10px; background-color:#DEB0B0; align:right; ">
'''
Versuche niemals, als root zu bauen!'''
</div>

== Kompilieren ==
Die high-level [[Make|make]] Targets, die für das Builden von Komplett-[[Images|Images]] relevant sind, lauten:
*<pre><nowiki>flash-</nowiki>[neutrino, enigma, all]</nowiki></pre>
*<pre><nowiki>flash-</nowiki>[cramfs, squashfs, jffs2, all]</nowiki></pre>
*<pre><nowiki></nowiki>[1x, 2x, alle]</nowiki></pre>
Für [[Yadd|YADD]]-Builds, sind diese:
*<pre><nowiki>yadd-</nowiki>[neutrino, enigma, all]</nowiki></pre>
'''Beispiele:'''

[[Make|make]] [[Flash|flash]]-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]-all

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

'''der Befehl:'''

[[Make|make]] [[Yadd|yadd]]-[[Enigma|enigma]]

erzeugt ein [[Yadd|YADD]], das [[Enigma|Enigma]] enthält.

=== 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|make]] [[Yadd|yadd]]-[[Neutrino|neutrino]]''' mit leeren Verzeichnissen etwa 1 und 1,5 Stunden.

==== Verwendung von [[Ccache|ccache]] ====
Um den Vorgang insbesondere bei wiederholten Kompilieren und besonders auf langsameren Rechnern zu beschleunigen, steht die Option
* --enable-[[Ccache|ccache]]
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|ccache]]''' wird erreicht, sollte das Tool bereits in deiner Distribution installiert sein, dass [[ccache]] automatisch erkannt wird und in das [[Tuxbox|Tuxbox]]-[[CDK|CDK]] eingebunden wird. Ist [[ES|es]] nicht installiert, wird dies auch von configure angezeigt:
...
----------------------------------------
[[Ccache|ccache]] support: no
[[Ccache|ccache]] installdir:
[[Ccache|ccache]] is not installed please run [[Make|make]] [[Ccache|ccache]] or install it and configure again
----------------------------------------
...
Dann sollte man das Tool nachinstallieren oder mit dem Target
[[Make|make]] [[Ccache|ccache]]
in das [[CDK|CDK]] einbauen und configure wiederholen.

'''Hinweis'''
 
''[[Ccache]] macht sich erst bemerkbar, nachdem der Buildvorgang mindestens einmal durchgelaufen ist!''

Die Option ''--enable-[[Ccache|ccache]]'' ist normalerweise völlig ausreichend. [[ES|Es]] stehen aber noch weitere untergeordnete Sub-Optionen zur Verfügung, die in Ausnahmefällen verwendet werden können:
*--with-ccachedir=DIR
Diese Option kann man verwenden, wenn man [[ccache]] beispielsweise nur als Binary abgelegt hat und den Pfad dazu bestimmen möchte.
 
'''Hinweis'''
 
''Die Option '''--with-ccachedir''' bewirkt auch das die mit '''[[Make|make]] [[Ccache|ccache]]''' installierte Version im [[CDK|CDK]] und/oder auch die evtl. im System installierte Version ignoriert wird!''

*--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|es]] logischeweise 20000 sein.

Die Wirksamkeit von [[ccache]] lässt sich mit dem Befehl
[[Ccache|ccache]] -s
prüfen. Als Ergebnis werden einige Statistiken ü[[BER|ber]] das Cache-Verhalten von [[Ccache|ccache]] ausgegeben:
cache directory /home/<USER>/.[[Ccache|ccache]]
cache hit 4
cache miss 191
called for [[Link|link]] 17
multiple source files 4
compile failed 17
preprocessor error 2
not a C/C++ file 5
autoconf compile/[[Link|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|make]] [[Yadd|yadd]]-[[Neutrino|neutrino]]
Am Ende des Bauvorganges werden damit die entsprechenden Zeitinformationen ausgegeben.

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

==== [[Neutrino|neutrino]]-[[Jffs2|jffs2]]-[[Image|Image]] ====
#! /bin/bash
# beispiel.sh
# Diese Script baut [[Neutrino|neutrino]]-[[Jffs2|jffs2]] [[Images|Images]], jeweils 1x und 2x
#----------------------------------------------
USERDIR=/home/$(whoami)
#----------------------------------------------
LOGODIR=$USERDIR/Logos
CP=$USERDIR/[[Tuxbox|tuxbox]]-[[CVS|cvs]]
DB=$USERDIR/[[Dbox2|dbox2]]
ARCHIVEDIR=$USERDIR/Archive
export CVS_RSH=[[SSH|ssh]]
#-----------------------------------------------
cd "$CP"
[[CVS|cvs]] -d anoncvs@[[CVS|cvs]].[[Tuxbox|tuxbox]].org:/[[CVS|cvs]]/[[Tuxbox|tuxbox]] -z3 co -f -r newmake -P .
cd [[CDK|cdk]]
/bin/ln -sf $ARCHIVEDIR/ Archive
./autogen.sh
./configure --prefix="$DB" --with-cvsdir="$CP" --enable-flashrules --enable-[[Ccache|ccache]] --with-[[CheckImage|checkImage]]=rename --with-logosdir="$LOGODIR"
[[Make|make]] [[Flash|flash]]-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]-all

==== [[Neutrino|Neutrino]] [[Yadd|YADD]] ====
#! /bin/bash
# beispiel.sh
# Diese Script baut ein [[Neutrino|Neutrino]] [[Yadd|Yadd]]
#----------------------------------------------
USERDIR=/home/$(whoami)
#----------------------------------------------
LOGODIR=/Logos
CP=$USERDIR/[[Tuxbox|tuxbox]]-[[CVS|cvs]]
DB=$USERDIR/[[Dbox2|dbox2]]
ARCHIVEDIR=$USERDIR/Archive
export CVS_RSH=[[SSH|ssh]]
#-----------------------------------------------
cd "$CP"
[[CVS|cvs]] -d anoncvs@[[CVS|cvs]].[[Tuxbox|tuxbox]].org:/[[CVS|cvs]]/[[Tuxbox|tuxbox]] -z3 co -f -r newmake -P .
cd [[CDK|cdk]]
/bin/ln -sf $ARCHIVEDIR/ Archive
./autogen.sh
./configure --prefix="$DB" --with-cvsdir="$CP" --with-logosdir="$LOGODIR" --enable-[[Ccache|ccache]]
[[Make|make]] [[Yadd|yadd]]-[[Neutrino|neutrino]]

= Was kommt dann...? =
== Booten von [[Yadd|YADD]] ==
Wenn ein [[Yadd|YADD]] frisch erzeugt wurde, kann damit auch die Box booten. Näheres dazu auch im Artikel [[CDK booten]]. 
Newmake hält auch ein [[Make|Make]]-Target für den serversupport bereit.
[[Make|make]] serversupport
Dieses erzeugt einige Konfigurationsdateien für den [[Server|Server]] der das [[Yadd|YADD]]-Build nahtlos an das [[Server|Server]]-Setup anknüpft.

== [[Flashen|Flashen]] des [[Images|Images]] ==
Wenn ein [[Image|Image]] gebaut wurde, ist der logische nächste Schritt das Einspielen des [[Images|Images]] in den [[Flash|Flash]] der Box. Hierfür ist entweder, das interaktive [[Flashen|Flashen]] innerhalb der [[GUI|GUI]] (Expertenfunktionen) zu benutzen, oder der ''dboxflasher'' zu verwenden. Der dboxflasher wird durch das [[Make|Make]]-Target
[[Make|make]] serversupport
erzeugt. Andere Möglichkeiten des Flashens werden [[Installation|hier]] beschrieben.

== Inkrementelle Builds ==
Im allgemeinen ist man nicht an einem einmaligen Build der [[Software|Software]] interessiert. Verbesserungen an den Quellen werden in das [[CVS|CVS]] täglich eingecheckt. Oft möchte man die [[Software|Software]] durch eigene Programmierung verbessern oder Patches anwenden. [[ES|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|make]] [target]
und [[Make|make]] wird [[ES|es]], falls notwendig, neu erzeugen.

[[ES|Es]] kann auch passieren, dass [[Make|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|es]] auch wünschenswert sein, ein erneutes Bauen einer Komponente zu erzwingen. Einige Komponenten werden in einem Distributionsfile zum Verzeichnis [[CDK|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|Installation]] eines bestimmten Pakets wird durch das Anlegen einer Markerdatei im Verzeichnis ''[[CDK|cdk]]/.deps'' vermerkt.
 
Falls gewünscht, kann solch eine Markiererdatei entfernt werden, um das Neuerzeugen der entsprechenden Komponetne zu erzwingen. [[ES|Es]] gibt hierfür auch entsprechende Targets, die "''Cleaning Targets''".

== Cleaning targets ==
[[ES|Es]] gibt mehrere unterschiedliche Aufräum-Targets:
 
[[Make|make]] distclean
Das drastischste Reinigungs-Target, (fast) alles löschend, was nicht vom [[CVS|CVS]] ausgecheckt wurde.
Dieses ist eher selten notwendig.
 
[[Make|make]] mostlyclean
Ein intelligenteres Target ist ''mostlyclean''. [[ES|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|Yadd]]-[[Installation|Installation]]), sowie die [[Tftp|TFTP]]-Files ([[Kernel|Kernel]] und [[U-boot|u-boot]]) werden nicht angefasst.
 
[[Make|make]] depsclean
Löscht alle Markerdateien im /[[CDK|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|make]] clean
Kombiniert ''mostlyclean'', ''depsclean'', und ''[[Flash|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|make]] bootstrap''.
 
[[Make|make]] [[Flash|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|make]] [[Flash|flash]]-mostlyclean
Zusätzlich zum ''[[Flash|flash]]-semiclean'' löscht dieses Target auch Bootfiles und die Kernbauverzeichnisse. Vollimages werden unberührt gelassen.
 
[[Make|make]] [[Flash|flash]]-clean
Dieses Target löscht Alles in $(flashprefix).
 
Einige Quellverzeichnisse können mit einem Befehl wie
[[Make|make]] -C /[[Tuxbox|tuxbox]]-[[CVS|cvs]]/apps/[[Tuxbox|tuxbox]]/[[Neutrino|neutrino]] clean
gesäubert werden.

== Aktualisierung des [[CVS|CVS]]-Quellcodes ==
Um die Quellen mit neueren Checkins zu aktualisieren, verwende diesen Befehl für das toplevel [[CVS|CVS]] Verzeichnis (oder von einem anderen Verzeichnis, wenn Ihr wisst, was ihr tut;-). Mögliche Fehler werden in das logfile [[CVS|cvs]].log geschrieben.

[[CVS|cvs]] up -f -r Newmake -dP > [[CVS|cvs]].log 2>&1

'''Tipp'''
 
Um mit dem [[CVS|CVS]] arbeiten zu können nimmt man für gewöhnlich die Konsole für Eingaben. [[ES|Es]] gibt aber auch verschiedene Frontendwerkzeuge wie z.B. [http://www.crossvc.com CrossVC] oder [http://cervisia.kde.org/ Cervisia] um nur einige zu nennen, die einen recht komfortablen Umgang mit den [[CVS|CVS]]-Daten ermöglichen. [[Bild:Crossvc.jpg|CrossVC als CVS Frontendlösung]] [[Bild:Cervisia.jpg|Cervisia als CVS Frontendlösung]] 
Auch einige [[IDE|IDE]]'s wie z.B. [[WP:Anjuta|Anjuta]] [[Bild:anjuta.jpg|Anjuta als IDE mit CVS-Anbindung]] bieten solche [[CVS|CVS]]-Schnittstellen an.

== [[Customization|Customization]] ==
Bisher lief immer alles darauf hinaus [[Images|Images]] oder Yadds zu bauen, die aus unveränderten [[CVS|CVS]]-Quellen gebaut wurden. 
[[Images|Images]] und die Yadds können aber auch angepasst ("customized") werden, ohne die [[Makefiles|Makefiles]] zu ändern.
 
Hier gibt [[ES|es]] verschiedene Möglichkeiten.

=== Konfigurationsoptionen ===
hier einige nützliche Optionen: 
Hiermit kann ein Verzeichniss angegeben werden, welches die [[Ucodes|Ucodes]] enthält, die im [[Image|Image]] enthalten sein sollen.
--with-ucodesdir=[DIR]
'''Hinweis:''' 
Ein [[Image|Image]], dass [[Ucodes|ucodes]] enthält, darf
nicht verbreitet werden! 
 
 
Mit der Option
--with-logosdir=[DIR]
kann ein Verzeichniss angegeben werden, das boot-logos (logo-[[LCD|lcd]] und logo-fb) enthält, die im [[Image|Image]] enthalten sein sollen.
 
 
Diese Option
--with-defaultlocale=[LOCALE]
sorgt dafür, dass die gewünschte Sprache schon beim bauen eingestellt wird.

=== Ändern der Partitionierung ===
Die Rootpartitionsgröße für [[Cramfs|cramfs]] und [[Squashfs|squashfs]] [[Images|Images]] kann mit der Configure-Option
--with-rootpartitionsize=[SIZE]
angegeben werden.
 
Die Größe der var-[[Partition|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|es]] wie bei der [[Jffs2|jffs2]]-Imageerstellung unsinnig wäre.

=== Variablen ===
==== Pfade ====
[[ES|Es]] sind noch weitere Benutzeranpassungen möglich. Dafür ist [[ES|es]] aber notwendig, etwas [[Wissen|Wissen]] ü[[BER|ber]] die innere Funktionsweise der [[Makefiles|Makefiles]] zu haben. 
In der Folge bezeichnet
$(flashprefix)
den Wert der Makefile Variablen '''flashprefix''' (mit Konfiguration wie oben '''/[[Dbox2|dbox2]]/cdkflash''')
$(targetprefix)
bezeichnet den Wert der Makefile Variablen '''targetprefix''' (mit Konfiguration wie oben '''/[[Dbox2|dbox2]]/cdkroot'''), und
$(buildprefix)
bezeichnet den Wert der Makefile Variablen '''buildprefix''' (mit der Konfiguration oben '''/[[Tuxbox|tuxbox]]-[[CVS|cvs]]/[[CDK|cdk]]''').
 
 
Um z.B. ein '''[[Neutrino|neutrino]]-[[Cramfs|cramfs]].img2x''' zu erzeugen, werden die folgenden Verzeichnisse erstellt: 
*'''$(flashprefix)/root''' (enthält [[Filesystem|Filesystem]]- und [[GUI|GUI]]-unabhängige Bestandteile)
*'''$(flashprefix)/root-[[Cramfs|cramfs]]''' (enthält den [[Kernel|Kernel]], für Root-[[Filesystem|Filesystem]] auf [[Cramfs|cramfs]] konfiguriert, zusammen mit seinen Treibern) und
*'''$(flashprefix)/root-[[Neutrino|neutrino]]''' (enthält die Neutrinoinstallation).
 
Aus diesen drei Verzeichnissen, werden das Rootfilesystemverzeichniss
*'''$(flashprefix)/root-[[Neutrino|neutrino]]-[[Cramfs|cramfs]]''' und das
var-filesystemverzeichnis
*'''$(flashprefix)/var-[[Neutrino|neutrino]]''' gebaut.
 
Hiermit ist [[ES|es]] möglich, einen Befehl wie
[[Make|make]] $(flashprefix)/root-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]
bzw. wenn man sich im Verzeichnis ''./[[Tuxbox|tuxbox]]-[[CVS|cvs]]/[[CDK|cdk]]'' befindet, den Befehl
[[Make|make]] root-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]
einzugeben, wobei man bei erster VAriante natürlich '''$(flashprefix)''' selbst durch den realen Pfad ersetzen muss, da '''$(flashprefix)''' nur eine [[Make|make]]-Variable ist, welche in unserem Beispiel den Pfad zu '''./[[Dbox2|dbox2]]/cdkflash''' darstellt. 
Man kann so manuell gewünschten Änderungen an '''$(flashprefix)/root-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]''' vornehmen, und dann, mit dem Befehl
[[Make|make]] [[Flash|flash]]-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]-2x
den Imagebau abschließen, um ein [[Image|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|Customization]]-Scripte ===
Sofern diese Scripte vorhanden und ausführbar sind, werden innerhalb der wichtigsten Targets diese sogenannten ''[[Customization|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|cdk]]'''-Ordner.
Bei Bedarf kann mit der Option
--with-customizationsdir=[DIR]
ein alternatives Verzeichnis für [[Customization|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|Shell]]-Scripts könnte dies z.B. ein kompiliertes C Programme, oder ein [[Perl|Perl]]-Script sein. 
Der Name eines [[Customization|Customization]] Scriptes besteht in der Regel aus dem Namen eines Targetverzeichnisses bzw. einem Target und dem angefügtem *'''-local.sh'''. 

==== Für [[Flash|Flash]]-Targets ====
Der Name der [[Customization|Customization]] Scripte für [[Images|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
*[[Neutrino|neutrino]]
*[[Enigma|enigma]]
*[[Lcars|lcars]]
*[[Radiobox|radiobox]]
 
"[[FS]]" zeigt an welches [[Filesystem|Filesystem]] gemeint ist.
*[[Cramfs|cramfs]]
*[[Squashfs|squashfs]]
*[[Jffs2|jffs2]]
 
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|neutrino]]-local.sh
root-[[Neutrino|neutrino]]-[[Squashfs|squashfs]]-local.sh
root-[[Squashfs|squashfs]]-local.sh
var-[[Neutrino|neutrino]]-local.sh

==== Für [[Yadd|Yadd]]-Targets ====
Für Yadds ist das Prinzip ähnlich, nur dass es hier quasi nur einen Ordner gibt. Dafür stellvertretend steht dann
*[[Yadd|yadd]]. 
Das "[[GUI]]" in Klammern bezeichnet auch hier die jeweilig betroffene Benutzeroberflche, also
*[[Neutrino|neutrino]]
*[[Enigma|enigma]]
*[[Lcars|lcars]]
*[[Radiobox|radiobox]]
 
so wäre die Bezeichnung der jeweiligen Scripte so aufgebaut.
*[[Yadd|yadd]]-[GUI]-local.sh
'''Beispiel:'''
[[Yadd|yadd]]-[[Neutrino|neutrino]]-local.sh

==== Andere [[Customization|Customization]] Scripte ====
Die bisher benannten [[Customization|Customization]] Scripte für [[Flash|Flash]]- u. [[Yadd|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|make]] hdparm
aus, wird beim Bauen das ausgeführt was im [[Customization|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: 
Während des [[Make|make]]-Durchlaufs werden einige Targets ausgeführt, welche die '''/.version'''-Files bei [[YADD]]
*'''version'''
bzw.
*'''[[Flash|flash]]-version'''
im [[Image]] erstellt.
 
Sofern eines dieser Scripte;
*'''version-local.sh'''
*'''[[Flash|flash]]-version-local.sh'''
vorhanden und ausführbar ist, wird es als Ersatz statt des originalen Targets ausgeführt, welches mit
[[Make|make]] version
bzw.
[[Make|make]] [[Flash|flash]]-version
angestoßen wird.

==== weitere Beispiele für Custiomization ====
Das Custiomizationscripting soll durch das folgende Beispiel noch mehr veranschaulicht werden.
Beispiel:

In einem [[Jffs2|jffs2]]-[[Image|Image]] wird dies gewünscht:

1. Eigene /etc/hosts benutzen,
2. Eigene [[Neutrino|neutrino]].conf, [[Bouquets|bouquets]].[[XML|xml]], services.[[XML|xml]] benutzen
3. einschließlich [[Lirc|lirc]]-Komponenten, zusammen mit eigenen [[Lirc|lirc]] Konfigurations-Dateien.

1. und 3. sind [[Erweiterungen|Erweiterungen]], die nach '''$(flashprefix)/root''' kommen sollten, während 2. [[Neutrino|Neutrino]]-regeln sind, welche nach sollten '''$(flashprefix)/root-[[Neutrino|neutrino]]-[[Jffs2|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|make]] flashlirc
cp -fr $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Lirc|lirc]] $newroot/var/[[Tuxbox|tuxbox]]/config

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

#!/bin/sh
# root-[[Neutrino|neutrino]]-local.sh
flashprefix=$1
buildprefix=$2
newroot=$flashprefix/root-[[Neutrino|neutrino]]
myfiles=/home/somewhere/dbox/myfiles
cp $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Neutrino|neutrino]].conf $newroot/var/[[Tuxbox|tuxbox]]/config
cp $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]/[[Bouquets|bouquets]].[[XML|xml]] $newroot/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]
cp $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]/services.[[XML|xml]] $newroot/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]

'''Bitte beachten:'''
Diese Scripte sollen als Beispiele dienen und können vermutlich nicht ohne Anpassung verwendet werden.

= 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|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|Customization]] Scripte für den eigenen Bedarf schreibt.

== Idempotens ==
[[ES|Es]] ist fast immer eine gute Idee zu versuchen, ein Installationsscript [[Wikipedia:Idempotent|idempotent]] zu schreiben. Dies bedeutet, dass das mehrmalige Ausführen den gleichen Effekt hat wie das einmalige Ausführen.
Benutze "[[Make|make]] install".
 
In der Vergangenheit hat das [[Tuxbox|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|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|es]] auch notwendig, das globale Makefile zu ändern.
 
 
[[ES|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|es]] durchaus sinnvoller, daß nach [[Make|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|gui]]-[[Filesystem|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|Es]] gibt kein Standardverfahren was zu tun wäre, wenn das Build misslingt. [[ES|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|es]] die Umgebung in einem [[Wikipedia:Inkonsistent|inkonsistenten]] Zustand versetzen. Dies gilt insbesondere für die Verzeichnisse in '''$(flashprefix)'''. Wenn der Bau solch eines [[Make|Make]]-Targets abbricht, besteht das Verzeichnis, ist entsprechend seiner Änderungszeit aktuell, und ein folgender [[Make|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|Br]]üche geht, '''dann lösche man [[ES|es]]''', bevor ein anderer [[Make|Make]] Befehl ausgeführt wird.
 
Bei "[[ES|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|Hilfe]] benötigt, siehe unten!.

=== Nach dem [[Flashen|Flashen]]: "Kein System" auf dem [[LCD|LCD]]/Was ist diese "bad magic byte" Zeugs? ===
Diese Frage kommt hoffentlich nicht... Die kurze Antwort ist: Man weiß [[ES|es]] nicht. Wir [[Wissen|wissen]] [[ES|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|Image]] "ist" in Ordnung, [[ES|es]] ist nur dass irgendwelche [[Firmware|Firmware]] in der dBox [[ES|es]] zurückweisen wird, weil [[ES|es]] einige "schlechte magische Bytes" auf bestimmten Adressen finden wird.
 
Das Programm [[checkImage]] aus dem [[CVS|CVS]], zu finden im Verzeichnis '''./hostapps/[[CheckImage|checkImage]]''' ermittelt diese "schlechten Bytes", aber ändert nichts daran, um diese zu beheben. Die Erfahrung zeigt, daß [[Images|Images]], die [[checkImage]] für gut findet, wirklich laufen. [[Cramfs|Cramfs]]-, oder [[Squashfs|squashfs]] [[Images|Images]], worü[[BER|ber]] sich [[CheckImage|checkImage]] beschwert, laufen im allgemeinen nicht, in einigen Ausnahmefällen läufen sie aber doch.
 
Auch bei [[Jffs2|jffs2]]-[[Images|Images]] ist dies manchmal der Fall, dass sich [[checkImage]] beschwert, die [[Images|Images]] laufen, aber eben nicht immer. Mit diesen empirischen Beobachtungen ist man nun sich selbst überlassen.
 
Newmake weiß, wie dieses Programm aufgerufen werden kann, um die erzeugten [[Images|Images]] automatisch zu überprüfen. Die Konfigurationsoption
--with-[[CheckImage|checkImage]]=[none,rename,warn]
wird hierfür verwendet. Falls '''warn''' gewählt ist, wird für jedes [[Image|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|Es]] muss erwähnt werden, daß die "schlechten magischen Bytes" in einem (oder mehreren!) der Partitionsteile sitzt, und werden nicht durch den abschließenden Schritt erzeugt (die *.img1x und/oder *.img2x Files bauen). [[ES|Es]] ist auch möglich, [[CheckImage|checkImage]] auf die Partitionsfiles anzuwenden *.[[Jffs2|jffs2]], *.[[Cramfs|cramfs]]
*.[[Squashfs|squashfs]]
*.flfs1x
*.flfs2x
Schließlich hat [[CheckImage|checkImage]] eine Debugoption, die nützlich sein kann.

== Ich habe ein Fehler gefunden! ==
Bugs, Unklarheiten, Verbesserungsvorschläge, etc. der [[Software|Software]] sollten vorzugsweise im [http://tuxbox-forum.dreambox-fan.de/forum/viewforum.php?f=7 Cross Development Kit - Forum] des [[Tuxbox|Tuxbox]]-Boards gepostet werden.

== Ich benötige [[Hilfe|Hilfe]]! ==
Supportanfragen können im [http://tuxbox-forum.dreambox-fan.de/forum/viewforum.php?f=7 Cross Development Kit - Forum] des [[Tuxbox|Tuxbox]]-Boards gepostet werden. Postings in deutsch oder englisch sind willkommen. Bitte nicht vergessen, die benutzten Konfigurationsoptionen zu erwähnen.

=Anhang=
==Einige nützliche [[Customization|Customization]] Script Snippets==
In diesem Anhang werden einige nützliche [[Customization|Customization]] Scripte gezeigt. Zwei Scripte sind bereits oben gezeigt worden.
 

'''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|es]] sei denn [[ES|es]] ist ungefährlich und Ihr versteht, wie sie funktionieren. [[ES|Es]] ist grundlegende Script-Erfahrung erfordelich.

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

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

=== /.version anpassen ===
Euere eigene ''/.version''-File herzustellen (anggezeigt von [[Neutrino|Neutrino]] durch dBox -> Services -> [[Image|Image]]-Version und cdkVcInfo beim Booten) ist sicher ein allgemeiner Wunsch.

*[[Flash|flash]]-version-local.sh

#/bin/sh
USER=$(whoami)
if [ $0 = $CDIR/flash-version-local.sh ] ; then
outfile=$FLASHDIR/root/.version
type="[[Image|Image]]"
else
outfile=$TARGETDIR/.version
type="[[Yadd|Yadd]]"
fi;
echo Creating $outfile ...
echo "version=`./mkversion -[[Snapshot|snapshot]] -version 200`" > $outfile
echo "creator=$USER" >> $outfile
echo "imagename=$USER-$type" >> $outfile
echo "homepage=[[HTTP|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|release]])
releasetype=0
;;
-[[Snapshot|snapshot]])
releasetype=1
;;
-internal)
releasetype=2
;;
-version)
versionnumber=$2
shift
;;
esac
shift
done
echo $releasetype$versionnumber$year$month$day$hour$minute

=== Archivierung der [[Images|Images]] ===
[[ES|Es]] ist eigentlich die Aufgabe des Buildprozesses, flashbare [[Images|Images]] zu erzeugen, und nicht sie zu archivieren. Jedoch kann die [[Customization|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]-[cramfs, squashfs,jffs2].[img1x, img2x]
haben. [[ES|Es]] benennt die Files entsprechend dem Tagesdatum um.

=Links=
*[http://www.gnu.org/software/make/manual/make.html GNU Make manual]
*[http://www.gnu.org/software/autoconf/manual/ Autoconf manual]
*[http://www.gnu.org/software/automake/manual/ Automake manual]
*[http://sources.redhat.com/autobook/ GNU Autoconf, Automake, and Libtool]
*[http://www.gnu.org/prep/standards/ GNU Coding standards]
*[http://cvsbook.red-bean.com/ Open Source Development with CVS, 3rd Edition]
*Barf's Homepage: [http://bengt-martensson.de/dbox2/ Barfs ][[Newmake]]-Dokumentation]

{{review}}

{{body}}

Dbox2 Entwicklungsumgebung

2008-06-26T05:39:21Z

Dixidix:

[[Category:Register]]
[[Category:Development]]
[[Category:CDK]]
{{Development_sidebar}}

__TOC__
{{Review}}
=Allgemeines=
Newmake ist eine Überarbeitung des alten "[[Make|make]]" Prozesses, inzwischen auch als [[Image erstellen|Oldmake]] bezeichnet, und wurde durch Barf ins Leben gerufen.
Neben einer deutlich strukturierteren Basis, bietet [[ES|es]] unter anderem auch den Vorteil, dass [[ES|es]] auch ohne ohne groß[[ES|es]] Verständnis für den Buildprozess gelingen kann, [[Images|Flashimages]] und [[yadd|YADDs]] unter [[Linux|Linux]] zu erstellen.
Basierend auf Newmake gibt [[ES|es]] inzwischen auch eine auf Scripts basierende Quasi-Frontendlösung, mit der sich [[Images|Flashimages]] oder [[yadd|YADDs]] benutzerdefiniert erstellen lassen, das sogenannte [[yBuild]]. 
Dieser Artikel basiert zum größtem Teil auf die deutsche Version von [http://bengt-martensson.de/dbox2/ Barfs Newmake-Dokumentation], die er uns freundlicheweise zur Verfügung gestellt hat.
Eine detaillierte Beschreibung (auch der [[Make|make]] targets) unter anderem auch in englischer Sprache befindet sich auf [http://bengt-martensson.de/dbox2/ Barf's Homepage]. 

Dieser Artikel behandelt Newmake aus Sicht des Benutzers (nicht Entwickler). [[ES|Es]] behandelt die [[Image]]- u. [[yadd|YADD]]-Herstellung sowie einfache Beipiele für Benutzeranpassungen ("[[Customization]]"). 

==Zur Geschichte==
Vor einigen Jahren war die Imageherstellung für die [[Tuxbox|Tuxbox]] so etwas wie [[Wikipedia:Schwarze Kunst|"Schwarze Kunst"]].
Die Makefile-Unterstützung war, insbesondere für andere [[Images]] als [[cramfs]]-[[Images]], ziehmlich 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|CVS]]-Verzeichnis ''.../hostapps/[[Mkflfs|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|CVS]]-Sources mit einigen mehr-oder-weniger geheim gehaltenen "Fixes", (vermutlich) notwendig für das Herstellen eines funktionierenden [[Images]] aus dem [[CVS|CVS]]-Quellcode.
 
 
Im August 2003, wurde [[ES|es]] für das [[DBox2 Software Projekt|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|Software]]-Design... 
Ein [[Image]] aus reinen [[CVS|CVS]]-Dateien zu bauen, war nicht wirklich möglich.
 
 
2004 wurde das [[YADI]] ("'''Y'''et '''A'''nother '''D'''Box '''I'''mage") Projekt geboren. 
Sein Ziel war [[ES|es]], das "Imagebauen" zu automatisieren und zu vereinfachen. Zu diesem Zweck wurden eine Anzahl von [[Wikipedia:Skripte|Scripten]] und [[Wikipedia:Patches|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|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|Skript]] war das automatische Imagebuilden zwar möglich, jedoch statt grundlegende Schwächen im [[CDK|CDK]]-Imagebau-Prozeß zu beseitigen, stellte man [[Skripte]] zum Imagebauen zur Verfügung. [[ES|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, verfügbar als alternativer [[Branch]] im [[CVS|CVS]], versucht diese Schwächen zu beseitigen. 
 
Ein spezieller Dank an jedem, der Bugreports und Feedback geliefert hat. Insbesonderes gilt dies für dietmarw, der Newmake benutzt, um die [[images|dietmarW-Images]] zu erzeugen.

=Ziel=
Das Ziel des vorliegenden Artikels ist [[ES|es]], dem Leser grundlegendes Know-How zu vermitteln. [[ES|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 [[Wikipedia:Skriptsprache|Shellskripten]] wird für viele Teile, insbesondere für das [[Customization]]-Kapitel, aber nicht für [[Image]]/[[yadd|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|Tuxbox]]-Forums hingewiesen. Alle Optionen für ''configure'' werden auch nicht beschrieben, nur die Allgemeinsten und Wichtigsten.

= Wie schwierig ist [[ES|es]]? =
Die Antwort könnte lauten: ''[[ES|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|es]] kein Probleme sein. Leser, für die das Meiste nur Kauderwelsch ist, sollten vielleicht besser bei fertigen [[Images|Images]] bleiben.

= [[Images|Images]] und [[Yadd|YADD]]'s bauen=
== Targets ==
[[ES|Es]] gibt neben zahlreichen untergeordneten Zielen (Targets), zwei hauptrangige Targets. Diese wären entweder
*[[YADD]]
oder
*[[Image]].
Ein [[YADD]] besteht aus einigen Dateien, die die DBox anstatt aus dem [[Flash]] ü[[BER|ber]] den [[TFTP]]-Service lädt, sowie ein [[Filesystem|Filesystem]], das ü[[BER|ber]] einen [[NFS-Server]] der dBox zur Verfügung gestellt wird.
 
Diese Betriebsart hat insbesondere während der Softwareentwicklung oder beim Erlernen des Systems viele Vorteile. 
Der Name "[[YADD]]" bedeutet übrigens "'''Y'''et '''A'''nother '''D'''Box '''D'''istribution" ("noch eine dBox Verteilung").

=== Erste Schritte und Überlegungen ===
Eine Empfehlung für den angehenden "[[Image|Image]]/[[Yadd|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|Image]] mit der Lieblings-[[GUI]] zu erstellen.

Meistens möchte man die folgenden Schritte kombinieren und/oder automatisieren.
 
In diesem Artikel bezeichnet "[[GUI]]" entweder
*[[Neutrino]] oder
*[[Enigma]]
*[[Lcars]]
*[[Radiobox]].
 
Das "[[Filesystem]]" im Kontext eines kompletten [[Images]] bezeichnet das [[Dateisystem]], in dem das root-Verzeichnis liegt. Diese kann ein
*[[cramfs]] (ein komprimiertes, Read-only [[Filesystem|filesystem]] für embedded Systeme) sein,
*[[squashfs]] (ein weiterd komprimiertes read-only-[[Dateisystem|Dateisystem]], was leistungsfähiger als [[cramfs]] betrachtet wird)
oder
*[[jffs2]] (ein "journalled" Read-Write-[[Filesystem|Filesystem]]).
Ein "[[Cramfs|cramfs]] Komplett-[[Image|Image]]" besteht aus einem Root-[[Dateisystem|Dateisystem]] mit dem [[cramfs]] [[Dateisystem|Dateisystem]] und einem kleineren [[jffs2]]-[[Filesystem|Filesystem]], das nach '''/var''' gemounted wird.
 
Analog gilt dies auch für "'''[[Squashfs|squashfs]] Komplett-[[Images|Images]]'''", während ein "'''[[Jffs2|jffs2]] Komplett-[[Image|Image]]'''" kein separates ''/var-[[Dateisystem|Dateisystem]]'' enthält, weil [[Jffs2|jffs2]] an sich beschreibbar (var) ist.
 
Zusätzlich enthalten die Komplett-[[Images|Images]] eine weitere [[Partition|Partition]], die den [[u-boot]]-[[Bootloader]] enthalten. Diese [[Partition|Partition]] ist zwischen dBoxen mit einen und zwei Flashchips unterschiedlich. Dieses wird durch "'''1x'''" und "'''2x'''" angezeigt. Ein komplettes [[Image|Image]] würde demnach so benannt werden:

[neutrino, enigma]-[cramfs, squashfs, jffs2].img[1, 2]x,
z.B. als fertiges [[Image|Image]]:
[[Neutrino|neutrino]]-[[Jffs2|jffs2]].img2x.

== Buildsystem Voraussetzungen ==
Die Voraussetzungen auf dem Buildhost können in etwa so zusammengefasst werden:
 
Ein modernes [[Unix|Unix]]/[[Linux|Linux]] System mit ca. 2 GB freiem Speicherplatz. Epfehlenswert ist [[ES|es]] aber mehr Speicherplatz einzuplanen, da beispielsweise bei Verwendung von [[ccache]] einiges an Daten zwischengelagert wird und je öfter man kompiliert, [[ES|es]] dann doch eng werden könnte.

Das [[DBox2 Software Projekt|Tuxbox Projekt]] hat keine favorisierte Buildumgebung. Fragen wie "geht [[ES|es]] mit Redhat x.y?" lassen sich nicht genau beantworten. Der Grund hierfür ist, dass niemand sich wirklich dafür interessiert, die Eigenschaften der bestimmten Distributionen zu erkunden. Gewisse Anforderungen werden dagegen für Versionen der Werkzeuge, wie [[WP:autoconf|autoconf]], [[WP:automake|automake]], [[make]] usw. formuliert. Die meisten davon sind in den gängigsten Distributionen bereits enthalten bzw. können nachinstalliert werden. Die momentan erfordelichen Toolversionen sind in folgendender Tabelle zusammengefasst:
 
{{Vorlage:GNU_Tools}}
 
Der Buildprozess überprüft zu Beginn automatisch einige dieser Anforderungen. Wenn eines dieser [[Tools|Tools]] fehlt, oder wenn die Version zu alt zu sein scheint, ist [[ES|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|Anleitungen]] zum Buildvorgang wird gefordert, dass [[Tools|Tools]] 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
erfordelich, da einige entweder überhaupt nicht benötigt werden bzw. die [[Installation|Installation]] im
Makeprozess selbst vorgenommen wird!
 ''
Builden auf einem [[Unix|Unix]]-non-[[Linux|Linux]] System sollte vermutlich auch möglich sein, so weit die erforderlichen [[GNU]] Werkzeuge vorhanden sind. Mit einem anderen [[make]] als [[GNU]] wird [[ES|es]] fast sicher nicht funktionieren, da die [[GNU|GNU]]-[[Erweiterungen|Erweiterungen]] uneingeschränkt verwendet werden.
 
[[ES|Es]] wird daher davon abgeraten eine Umbegebung z.B. mit [[Cygwin]] aufzubauen, da [[ES|es]] höchstwahrscheinlich nicht funktionieren wird. In dieser Richtung wurde zwar Einiges für den Makeprozess eingebaut, jedoch dürfte der gegenwärtige Entwicklungsstand nicht den gegenwärtigen Anforderungen entsprechen, um aktuell auch damit arbeiten zu können.
 
Empfehlenswert ist allerdings eine Buildumgebung mittels [[VMWare]] aufzubauen. Hierfür gibt [[ES|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.

== Auschecken ==
Die [[Tuxbox|Tuxbox]] Quellen werden durch den [[Tuxbox|Tuxbox]] [[CVS-Server]] bereitgestellt. 
Regelmäßige Quellreleases sind niemals gemacht worden, und sind auch nicht für die Zukünft geplant. Für unsere Zwecke werden die Quellen anonym "ausgecheckt", was bedeutet, dass diese auf die eigene Festplatte kopiert werden, indem man zuerst auf einer (lokalen) Festplatte mit "ordentlich" freiem Platz ein leeres Verzeichnis erstellt, z.B. ''/[[Tuxbox|tuxbox]]-[[CVS|cvs]]'' und in diesen Ordner wechselt, und diesen Befehl ausführt.

[[CVS|cvs]] -d anoncvs@[[CVS|cvs]].[[Tuxbox|tuxbox]].org:/[[CVS|cvs]]/[[Tuxbox|tuxbox]] -z3 co -f -r newmake -P .

Dieser Befehl checkt die Newmake Files aus. In Fällen, in denen keine Newmake Version vorhanden ist, wird die HEAD-Version ausgecheckt.
 
'''Hinweis:'''
''Im HEAD gibt [[ES|es]] zwei Files:''
*[[CDK|cdk]]/root/etc/init.d/rcS
''und''
*[[CDK|cdk]]/root/etc/init.d/rcS.insmod
''Im [[Newmake]] werden diese nicht benötigt da sie mittels''
[[CDK|cdk]]/root/etc/init.d/rcS.m4
''erzeugt werden.''
''Um auf der sicheren Seite zu sein, ist [[ES|es]] ratsam, diese beiden zu löschen''.
 
Nachdem die Daten ausgecheckt wurden, könnte kann man jetzt einige Patches auf die Quellen anwenden. 
Wenn man aber zum ersten Mal kompiliert, ist [[ES|es]] ratsam, vorerst keine Patches anzuwenden. Wenn Probleme auftreten, ist [[ES|es]] viel einfacher (technisch sowohl als auch für jeden selbst) jemand zu helfen, der die "unveränderten [[CVS|CVS]] Quellen" verwendet.

== Konfiguration ==
Jetzt müssen einge Zwischenschritte erledigt werden, damit der Buildprozess auch erkennt, was und vorallem wie er [[ES|es]] machen soll.
 
Man wechselt nun in das [[CDK|CDK]]-Unterverzeichnis
cd [[CDK|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|Images]], [[Yadd|YADD]] oder aller anderen gewünschten Ziele entsprechend den Benutzerwünschen vorzubereiten.

=== Optionen ===
{{Newmake_Build_Optionen}}

Für uns sind vorerst nur wenige Optionen interessant. Die Standardvorgaben reichen vorerst völlig aus. 
Eine typische Anwendung (Konfiguration), der mit z.B. den Pfadnamen oben kompatibel wäre, könnte so eingestellt werden:

./configure --with-cvsdir="/[[Tuxbox|tuxbox]]-[[CVS|cvs]]" --prefix="/[[Dbox2|dbox2]]" --enable-maintainer-mode

*''--with-cvsdir''
sagt wo die Quellen zu finden sind, (darin sollte auch ein Unterverzeichnis ''.../[[CDK|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|Makefiles]] ermöglicht, sich automatisch neu zu erzeugen, sobald die Notwendigkeit entsteht, zum Beispiel nach einem [[Software|Software]]-[[Update|Update]].

[[ES|Es]] gibt sicher noch andere nützliche Optionen. Einige werden später noch besprochen.

=== 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|tuxbox]] [[Mklibs|mklibs]]
checking for mkcramfs... no
configure: WARNING: using [[Tuxbox|tuxbox]] [[Cramfs|cramfs]]
checking for mkjffs2... no
checking for [[Mkfs.jffs2|mkfs.jffs2]]... no
configure: WARNING: using [[Tuxbox|tuxbox]] [[Mkfs.jffs2|mkfs.jffs2]]
checking for mksquashfs... no
configure: WARNING: using [[Tuxbox|tuxbox]] [[Squashfs|squashfs]]
...

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

'''''Beachte!'''
Wenn man diesen Artikel mit ähnlichen Beschreibungen aus vergangenen Zeiten
vergleicht, bemerkt man, dass die Option '''--with-targetruleset=[standard,flash]''' nicht mehr
vorhanden ist. Bisher war [[ES|es]] notwendig, bei der Konfiguration sich entweder auf Builds von [[YADDs]]
oder [[Images]] einzuschränken. Bei Newmake ist dieses nicht mehr notwendig.
 ''
 
[[Bild:Stop hand.png]]
<div style="margin: 0; margin-top:10px; margin-right:0px; border: 3px solid #FF0000; padding: 0px 10px 1px 10px; background-color:#DEB0B0; align:right; ">
'''
Versuche niemals, als root zu bauen!'''
</div>

== Kompilieren ==
Die high-level [[Make|make]] Targets, die für das Builden von Komplett-[[Images|Images]] relevant sind, lauten:
*<pre><nowiki>flash-</nowiki>[neutrino, enigma, all]</nowiki></pre>
*<pre><nowiki>flash-</nowiki>[cramfs, squashfs, jffs2, all]</nowiki></pre>
*<pre><nowiki></nowiki>[1x, 2x, alle]</nowiki></pre>
Für [[Yadd|YADD]]-Builds, sind diese:
*<pre><nowiki>yadd-</nowiki>[neutrino, enigma, all]</nowiki></pre>
'''Beispiele:'''

[[Make|make]] [[Flash|flash]]-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]-all

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

'''der Befehl:'''

[[Make|make]] [[Yadd|yadd]]-[[Enigma|enigma]]

erzeugt ein [[Yadd|YADD]], das [[Enigma|Enigma]] enthält.

=== 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|make]] [[Yadd|yadd]]-[[Neutrino|neutrino]]''' mit leeren Verzeichnissen etwa 1 und 1,5 Stunden.

==== Verwendung von [[Ccache|ccache]] ====
Um den Vorgang insbesondere bei wiederholten Kompilieren und besonders auf langsameren Rechnern zu beschleunigen, steht die Option
* --enable-[[Ccache|ccache]]
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|ccache]]''' wird erreicht, sollte das Tool bereits in deiner Distribution installiert sein, dass [[ccache]] automatisch erkannt wird und in das [[Tuxbox|Tuxbox]]-[[CDK|CDK]] eingebunden wird. Ist [[ES|es]] nicht installiert, wird dies auch von configure angezeigt:
...
----------------------------------------
[[Ccache|ccache]] support: no
[[Ccache|ccache]] installdir:
[[Ccache|ccache]] is not installed please run [[Make|make]] [[Ccache|ccache]] or install it and configure again
----------------------------------------
...
Dann sollte man das Tool nachinstallieren oder mit dem Target
[[Make|make]] [[Ccache|ccache]]
in das [[CDK|CDK]] einbauen und configure wiederholen.

'''Hinweis'''
 
''[[Ccache]] macht sich erst bemerkbar, nachdem der Buildvorgang mindestens einmal durchgelaufen ist!''

Die Option ''--enable-[[Ccache|ccache]]'' ist normalerweise völlig ausreichend. [[ES|Es]] stehen aber noch weitere untergeordnete Sub-Optionen zur Verfügung, die in Ausnahmefällen verwendet werden können:
*--with-ccachedir=DIR
Diese Option kann man verwenden, wenn man [[ccache]] beispielsweise nur als Binary abgelegt hat und den Pfad dazu bestimmen möchte.
 
'''Hinweis'''
 
''Die Option '''--with-ccachedir''' bewirkt auch das die mit '''[[Make|make]] [[Ccache|ccache]]''' installierte Version im [[CDK|CDK]] und/oder auch die evtl. im System installierte Version ignoriert wird!''

*--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|es]] logischeweise 20000 sein.

Die Wirksamkeit von [[ccache]] lässt sich mit dem Befehl
[[Ccache|ccache]] -s
prüfen. Als Ergebnis werden einige Statistiken ü[[BER|ber]] das Cache-Verhalten von [[Ccache|ccache]] ausgegeben:
cache directory /home/<USER>/.[[Ccache|ccache]]
cache hit 4
cache miss 191
called for [[Link|link]] 17
multiple source files 4
compile failed 17
preprocessor error 2
not a C/C++ file 5
autoconf compile/[[Link|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|make]] [[Yadd|yadd]]-[[Neutrino|neutrino]]
Am Ende des Bauvorganges werden damit die entsprechenden Zeitinformationen ausgegeben.

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

==== [[Neutrino|neutrino]]-[[Jffs2|jffs2]]-[[Image|Image]] ====
#! /bin/bash
# beispiel.sh
# Diese Script baut [[Neutrino|neutrino]]-[[Jffs2|jffs2]] [[Images|Images]], jeweils 1x und 2x
#----------------------------------------------
USERDIR=/home/$(whoami)
#----------------------------------------------
LOGODIR=$USERDIR/Logos
CP=$USERDIR/[[Tuxbox|tuxbox]]-[[CVS|cvs]]
DB=$USERDIR/[[Dbox2|dbox2]]
ARCHIVEDIR=$USERDIR/Archive
export CVS_RSH=[[SSH|ssh]]
#-----------------------------------------------
cd "$CP"
[[CVS|cvs]] -d anoncvs@[[CVS|cvs]].[[Tuxbox|tuxbox]].org:/[[CVS|cvs]]/[[Tuxbox|tuxbox]] -z3 co -f -r newmake -P .
cd [[CDK|cdk]]
/bin/ln -sf $ARCHIVEDIR/ Archive
./autogen.sh
./configure --prefix="$DB" --with-cvsdir="$CP" --enable-flashrules --enable-[[Ccache|ccache]] --with-[[CheckImage|checkImage]]=rename --with-logosdir="$LOGODIR"
[[Make|make]] [[Flash|flash]]-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]-all

==== [[Neutrino|Neutrino]] [[Yadd|YADD]] ====
#! /bin/bash
# beispiel.sh
# Diese Script baut ein [[Neutrino|Neutrino]] [[Yadd|Yadd]]
#----------------------------------------------
USERDIR=/home/$(whoami)
#----------------------------------------------
LOGODIR=/Logos
CP=$USERDIR/[[Tuxbox|tuxbox]]-[[CVS|cvs]]
DB=$USERDIR/[[Dbox2|dbox2]]
ARCHIVEDIR=$USERDIR/Archive
export CVS_RSH=[[SSH|ssh]]
#-----------------------------------------------
cd "$CP"
[[CVS|cvs]] -d anoncvs@[[CVS|cvs]].[[Tuxbox|tuxbox]].org:/[[CVS|cvs]]/[[Tuxbox|tuxbox]] -z3 co -f -r newmake -P .
cd [[CDK|cdk]]
/bin/ln -sf $ARCHIVEDIR/ Archive
./autogen.sh
./configure --prefix="$DB" --with-cvsdir="$CP" --with-logosdir="$LOGODIR" --enable-[[Ccache|ccache]]
[[Make|make]] [[Yadd|yadd]]-[[Neutrino|neutrino]]

= Was kommt dann...? =
== Booten von [[Yadd|YADD]] ==
Wenn ein [[Yadd|YADD]] frisch erzeugt wurde, kann damit auch die Box booten. Näheres dazu auch im Artikel [[CDK booten]]. 
Newmake hält auch ein [[Make|Make]]-Target für den serversupport bereit.
[[Make|make]] serversupport
Dieses erzeugt einige Konfigurationsdateien für den [[Server|Server]] der das [[Yadd|YADD]]-Build nahtlos an das [[Server|Server]]-Setup anknüpft.

== [[Flashen|Flashen]] des [[Images|Images]] ==
Wenn ein [[Image|Image]] gebaut wurde, ist der logische nächste Schritt das Einspielen des [[Images|Images]] in den [[Flash|Flash]] der Box. Hierfür ist entweder, das interaktive [[Flashen|Flashen]] innerhalb der [[GUI|GUI]] (Expertenfunktionen) zu benutzen, oder der ''dboxflasher'' zu verwenden. Der dboxflasher wird durch das [[Make|Make]]-Target
[[Make|make]] serversupport
erzeugt. Andere Möglichkeiten des Flashens werden [[Installation|hier]] beschrieben.

== Inkrementelle Builds ==
Im allgemeinen ist man nicht an einem einmaligen Build der [[Software|Software]] interessiert. Verbesserungen an den Quellen werden in das [[CVS|CVS]] täglich eingecheckt. Oft möchte man die [[Software|Software]] durch eigene Programmierung verbessern oder Patches anwenden. [[ES|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|make]] [target]
und [[Make|make]] wird [[ES|es]], falls notwendig, neu erzeugen.

[[ES|Es]] kann auch passieren, dass [[Make|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|es]] auch wünschenswert sein, ein erneutes Bauen einer Komponente zu erzwingen. Einige Komponenten werden in einem Distributionsfile zum Verzeichnis [[CDK|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|Installation]] eines bestimmten Pakets wird durch das Anlegen einer Markerdatei im Verzeichnis ''[[CDK|cdk]]/.deps'' vermerkt.
 
Falls gewünscht, kann solch eine Markiererdatei entfernt werden, um das Neuerzeugen der entsprechenden Komponetne zu erzwingen. [[ES|Es]] gibt hierfür auch entsprechende Targets, die "''Cleaning Targets''".

== Cleaning targets ==
[[ES|Es]] gibt mehrere unterschiedliche Aufräum-Targets:
 
[[Make|make]] distclean
Das drastischste Reinigungs-Target, (fast) alles löschend, was nicht vom [[CVS|CVS]] ausgecheckt wurde.
Dieses ist eher selten notwendig.
 
[[Make|make]] mostlyclean
Ein intelligenteres Target ist ''mostlyclean''. [[ES|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|Yadd]]-[[Installation|Installation]]), sowie die [[Tftp|TFTP]]-Files ([[Kernel|Kernel]] und [[U-boot|u-boot]]) werden nicht angefasst.
 
[[Make|make]] depsclean
Löscht alle Markerdateien im /[[CDK|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|make]] clean
Kombiniert ''mostlyclean'', ''depsclean'', und ''[[Flash|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|make]] bootstrap''.
 
[[Make|make]] [[Flash|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|make]] [[Flash|flash]]-mostlyclean
Zusätzlich zum ''[[Flash|flash]]-semiclean'' löscht dieses Target auch Bootfiles und die Kernbauverzeichnisse. Vollimages werden unberührt gelassen.
 
[[Make|make]] [[Flash|flash]]-clean
Dieses Target löscht Alles in $(flashprefix).
 
Einige Quellverzeichnisse können mit einem Befehl wie
[[Make|make]] -C /[[Tuxbox|tuxbox]]-[[CVS|cvs]]/apps/[[Tuxbox|tuxbox]]/[[Neutrino|neutrino]] clean
gesäubert werden.

== Aktualisierung des [[CVS|CVS]]-Quellcodes ==
Um die Quellen mit neueren Checkins zu aktualisieren, verwende diesen Befehl für das toplevel [[CVS|CVS]] Verzeichnis (oder von einem anderen Verzeichnis, wenn Ihr wisst, was ihr tut;-). Mögliche Fehler werden in das logfile [[CVS|cvs]].log geschrieben.

[[CVS|cvs]] up -f -r Newmake -dP > [[CVS|cvs]].log 2>&1

'''Tipp'''
 
Um mit dem [[CVS|CVS]] arbeiten zu können nimmt man für gewöhnlich die Konsole für Eingaben. [[ES|Es]] gibt aber auch verschiedene Frontendwerkzeuge wie z.B. [http://www.crossvc.com CrossVC] oder [http://cervisia.kde.org/ Cervisia] um nur einige zu nennen, die einen recht komfortablen Umgang mit den [[CVS|CVS]]-Daten ermöglichen. [[Bild:Crossvc.jpg|CrossVC als CVS Frontendlösung]] [[Bild:Cervisia.jpg|Cervisia als CVS Frontendlösung]] 
Auch einige [[IDE|IDE]]'s wie z.B. [[WP:Anjuta|Anjuta]] [[Bild:anjuta.jpg|Anjuta als IDE mit CVS-Anbindung]] bieten solche [[CVS|CVS]]-Schnittstellen an.

== [[Customization|Customization]] ==
Bisher lief immer alles darauf hinaus [[Images|Images]] oder Yadds zu bauen, die aus unveränderten [[CVS|CVS]]-Quellen gebaut wurden. 
[[Images|Images]] und die Yadds können aber auch angepasst ("customized") werden, ohne die [[Makefiles|Makefiles]] zu ändern.
 
Hier gibt [[ES|es]] verschiedene Möglichkeiten.

=== Konfigurationsoptionen ===
hier einige nützliche Optionen: 
Hiermit kann ein Verzeichniss angegeben werden, welches die [[Ucodes|Ucodes]] enthält, die im [[Image|Image]] enthalten sein sollen.
--with-ucodesdir=[DIR]
'''Hinweis:''' 
Ein [[Image|Image]], dass [[Ucodes|ucodes]] enthält, darf
nicht verbreitet werden! 
 
 
Mit der Option
--with-logosdir=[DIR]
kann ein Verzeichniss angegeben werden, das boot-logos (logo-[[LCD|lcd]] und logo-fb) enthält, die im [[Image|Image]] enthalten sein sollen.
 
 
Diese Option
--with-defaultlocale=[LOCALE]
sorgt dafür, dass die gewünschte Sprache schon beim bauen eingestellt wird.

=== Ändern der Partitionierung ===
Die Rootpartitionsgröße für [[Cramfs|cramfs]] und [[Squashfs|squashfs]] [[Images|Images]] kann mit der Configure-Option
--with-rootpartitionsize=[SIZE]
angegeben werden.
 
Die Größe der var-[[Partition|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|es]] wie bei der [[Jffs2|jffs2]]-Imageerstellung unsinnig wäre.

=== Variablen ===
==== Pfade ====
[[ES|Es]] sind noch weitere Benutzeranpassungen möglich. Dafür ist [[ES|es]] aber notwendig, etwas [[Wissen|Wissen]] ü[[BER|ber]] die innere Funktionsweise der [[Makefiles|Makefiles]] zu haben. 
In der Folge bezeichnet
$(flashprefix)
den Wert der Makefile Variablen '''flashprefix''' (mit Konfiguration wie oben '''/[[Dbox2|dbox2]]/cdkflash''')
$(targetprefix)
bezeichnet den Wert der Makefile Variablen '''targetprefix''' (mit Konfiguration wie oben '''/[[Dbox2|dbox2]]/cdkroot'''), und
$(buildprefix)
bezeichnet den Wert der Makefile Variablen '''buildprefix''' (mit der Konfiguration oben '''/[[Tuxbox|tuxbox]]-[[CVS|cvs]]/[[CDK|cdk]]''').
 
 
Um z.B. ein '''[[Neutrino|neutrino]]-[[Cramfs|cramfs]].img2x''' zu erzeugen, werden die folgenden Verzeichnisse erstellt: 
*'''$(flashprefix)/root''' (enthält [[Filesystem|Filesystem]]- und [[GUI|GUI]]-unabhängige Bestandteile)
*'''$(flashprefix)/root-[[Cramfs|cramfs]]''' (enthält den [[Kernel|Kernel]], für Root-[[Filesystem|Filesystem]] auf [[Cramfs|cramfs]] konfiguriert, zusammen mit seinen Treibern) und
*'''$(flashprefix)/root-[[Neutrino|neutrino]]''' (enthält die Neutrinoinstallation).
 
Aus diesen drei Verzeichnissen, werden das Rootfilesystemverzeichniss
*'''$(flashprefix)/root-[[Neutrino|neutrino]]-[[Cramfs|cramfs]]''' und das
var-filesystemverzeichnis
*'''$(flashprefix)/var-[[Neutrino|neutrino]]''' gebaut.
 
Hiermit ist [[ES|es]] möglich, einen Befehl wie
[[Make|make]] $(flashprefix)/root-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]
bzw. wenn man sich im Verzeichnis ''./[[Tuxbox|tuxbox]]-[[CVS|cvs]]/[[CDK|cdk]]'' befindet, den Befehl
[[Make|make]] root-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]
einzugeben, wobei man bei erster VAriante natürlich '''$(flashprefix)''' selbst durch den realen Pfad ersetzen muss, da '''$(flashprefix)''' nur eine [[Make|make]]-Variable ist, welche in unserem Beispiel den Pfad zu '''./[[Dbox2|dbox2]]/cdkflash''' darstellt. 
Man kann so manuell gewünschten Änderungen an '''$(flashprefix)/root-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]''' vornehmen, und dann, mit dem Befehl
[[Make|make]] [[Flash|flash]]-[[Neutrino|neutrino]]-[[Jffs2|jffs2]]-2x
den Imagebau abschließen, um ein [[Image|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|Customization]]-Scripte ===
Sofern diese Scripte vorhanden und ausführbar sind, werden innerhalb der wichtigsten Targets diese sogenannten ''[[Customization|Customization]]-Scripte'' automatisch aufgerufen bzw. ausgeführt.
Zum aktivieren diese Scripte müssen diese lediglich in ein dafür vorgesehenes Verzeichnis abgelegt werden und ausführbar sein. Dieses Verzeichnis ist standardmäßig der '''*/[[CDK|cdk]]'''-Ordner.
Bei Bedarf kann mit der Option
--with-customizationsdir=[DIR]
ein alternatives Verzeichnis für [[Customization|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|Shell]]-Scripts könnte dies z.B. ein kompiliertes C Programme, oder ein [[Perl|Perl]]-Script sein. 
Der Name eines [[Customization|Customization]] Scriptes besteht in der Regel aus dem Namen eines Targetverzeichnisses bzw. einem Target und dem angefügtem *'''-local.sh'''. 

==== Für [[Flash|Flash]]-Targets ====
Der Name der [[Customization|Customization]] Scripte für [[Images|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
*[[Neutrino|neutrino]]
*[[Enigma|enigma]]
*[[Lcars|lcars]]
*[[Radiobox|radiobox]]
 
"[[FS]]" zeigt an welches [[Filesystem|Filesystem]] gemeint ist.
*[[Cramfs|cramfs]]
*[[Squashfs|squashfs]]
*[[Jffs2|jffs2]]
 
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|neutrino]]-local.sh
root-[[Neutrino|neutrino]]-[[Squashfs|squashfs]]-local.sh
root-[[Squashfs|squashfs]]-local.sh
var-[[Neutrino|neutrino]]-local.sh

==== Für [[Yadd|Yadd]]-Targets ====
Für Yadds ist das Prinzip ähnlich, nur dass es hier quasi nur einen Ordner gibt. Dafür stellvertretend steht dann
*[[Yadd|yadd]]. 
Das "[[GUI]]" in Klammern bezeichnet auch hier die jeweilig betroffene Benutzeroberflche, also
*[[Neutrino|neutrino]]
*[[Enigma|enigma]]
*[[Lcars|lcars]]
*[[Radiobox|radiobox]]
 
so wäre die Bezeichnung der jeweiligen Scripte so aufgebaut.
*[[Yadd|yadd]]-[GUI]-local.sh
'''Beispiel:'''
[[Yadd|yadd]]-[[Neutrino|neutrino]]-local.sh

==== Andere [[Customization|Customization]] Scripte ====
Die bisher benannten [[Customization|Customization]] Scripte für [[Flash|Flash]]- u. [[Yadd|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|make]] hdparm
aus, wird beim Bauen das ausgeführt was im [[Customization|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: 
Während des [[Make|make]]-Durchlaufs werden einige Targets ausgeführt, welche die '''/.version'''-Files bei [[YADD]]
*'''version'''
bzw.
*'''[[Flash|flash]]-version'''
im [[Image]] erstellt.
 
Sofern eines dieser Scripte;
*'''version-local.sh'''
*'''[[Flash|flash]]-version-local.sh'''
vorhanden und ausführbar ist, wird es als Ersatz statt des originalen Targets ausgeführt, welches mit
[[Make|make]] version
bzw.
[[Make|make]] [[Flash|flash]]-version
angestoßen wird.

==== weitere Beispiele für Custiomization ====
Das Custiomizationscripting soll durch das folgende Beispiel noch mehr veranschaulicht werden.
Beispiel:

In einem [[Jffs2|jffs2]]-[[Image|Image]] wird dies gewünscht:

1. Eigene /etc/hosts benutzen,
2. Eigene [[Neutrino|neutrino]].conf, [[Bouquets|bouquets]].[[XML|xml]], services.[[XML|xml]] benutzen
3. einschließlich [[Lirc|lirc]]-Komponenten, zusammen mit eigenen [[Lirc|lirc]] Konfigurations-Dateien.

1. und 3. sind [[Erweiterungen|Erweiterungen]], die nach '''$(flashprefix)/root''' kommen sollten, während 2. [[Neutrino|Neutrino]]-regeln sind, welche nach sollten '''$(flashprefix)/root-[[Neutrino|neutrino]]-[[Jffs2|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|make]] flashlirc
cp -fr $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Lirc|lirc]] $newroot/var/[[Tuxbox|tuxbox]]/config

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

#!/bin/sh
# root-[[Neutrino|neutrino]]-local.sh
flashprefix=$1
buildprefix=$2
newroot=$flashprefix/root-[[Neutrino|neutrino]]
myfiles=/home/somewhere/dbox/myfiles
cp $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Neutrino|neutrino]].conf $newroot/var/[[Tuxbox|tuxbox]]/config
cp $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]/[[Bouquets|bouquets]].[[XML|xml]] $newroot/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]
cp $myfiles/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]/services.[[XML|xml]] $newroot/var/[[Tuxbox|tuxbox]]/config/[[Zapit|zapit]]

'''Bitte beachten:'''
Diese Scripte sollen als Beispiele dienen und können vermutlich nicht ohne Anpassung verwendet werden.

= 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|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|Customization]] Scripte für den eigenen Bedarf schreibt.

== Idempotens ==
[[ES|Es]] ist fast immer eine gute Idee zu versuchen, ein Installationsscript [[Wikipedia:Idempotent|idempotent]] zu schreiben. Dies bedeutet, dass das mehrmalige Ausführen den gleichen Effekt hat wie das einmalige Ausführen.
Benutze "[[Make|make]] install".
 
In der Vergangenheit hat das [[Tuxbox|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|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|es]] auch notwendig, das globale Makefile zu ändern.
 
 
[[ES|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|es]] durchaus sinnvoller, daß nach [[Make|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|gui]]-[[Filesystem|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|Es]] gibt kein Standardverfahren was zu tun wäre, wenn das Build misslingt. [[ES|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|es]] die Umgebung in einem [[Wikipedia:Inkonsistent|inkonsistenten]] Zustand versetzen. Dies gilt insbesondere für die Verzeichnisse in '''$(flashprefix)'''. Wenn der Bau solch eines [[Make|Make]]-Targets abbricht, besteht das Verzeichnis, ist entsprechend seiner Änderungszeit aktuell, und ein folgender [[Make|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|Br]]üche geht, '''dann lösche man [[ES|es]]''', bevor ein anderer [[Make|Make]] Befehl ausgeführt wird.
 
Bei "[[ES|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|Hilfe]] benötigt, siehe unten!.

=== Nach dem [[Flashen|Flashen]]: "Kein System" auf dem [[LCD|LCD]]/Was ist diese "bad magic byte" Zeugs? ===
Diese Frage kommt hoffentlich nicht... Die kurze Antwort ist: Man weiß [[ES|es]] nicht. Wir [[Wissen|wissen]] [[ES|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|Image]] "ist" in Ordnung, [[ES|es]] ist nur dass irgendwelche [[Firmware|Firmware]] in der dBox [[ES|es]] zurückweisen wird, weil [[ES|es]] einige "schlechte magische Bytes" auf bestimmten Adressen finden wird.
 
Das Programm [[checkImage]] aus dem [[CVS|CVS]], zu finden im Verzeichnis '''./hostapps/[[CheckImage|checkImage]]''' ermittelt diese "schlechten Bytes", aber ändert nichts daran, um diese zu beheben. Die Erfahrung zeigt, daß [[Images|Images]], die [[checkImage]] für gut findet, wirklich laufen. [[Cramfs|Cramfs]]-, oder [[Squashfs|squashfs]] [[Images|Images]], worü[[BER|ber]] sich [[CheckImage|checkImage]] beschwert, laufen im allgemeinen nicht, in einigen Ausnahmefällen läufen sie aber doch.
 
Auch bei [[Jffs2|jffs2]]-[[Images|Images]] ist dies manchmal der Fall, dass sich [[checkImage]] beschwert, die [[Images|Images]] laufen, aber eben nicht immer. Mit diesen empirischen Beobachtungen ist man nun sich selbst überlassen.
 
Newmake weiß, wie dieses Programm aufgerufen werden kann, um die erzeugten [[Images|Images]] automatisch zu überprüfen. Die Konfigurationsoption
--with-[[CheckImage|checkImage]]=[none,rename,warn]
wird hierfür verwendet. Falls '''warn''' gewählt ist, wird für jedes [[Image|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|Es]] muss erwähnt werden, daß die "schlechten magischen Bytes" in einem (oder mehreren!) der Partitionsteile sitzt, und werden nicht durch den abschließenden Schritt erzeugt (die *.img1x und/oder *.img2x Files bauen). [[ES|Es]] ist auch möglich, [[CheckImage|checkImage]] auf die Partitionsfiles anzuwenden *.[[Jffs2|jffs2]], *.[[Cramfs|cramfs]]
*.[[Squashfs|squashfs]]
*.flfs1x
*.flfs2x
Schließlich hat [[CheckImage|checkImage]] eine Debugoption, die nützlich sein kann.

== Ich habe ein Fehler gefunden! ==
Bugs, Unklarheiten, Verbesserungsvorschläge, etc. der [[Software|Software]] sollten vorzugsweise im [http://tuxbox-forum.dreambox-fan.de/forum/viewforum.php?f=7 Cross Development Kit - Forum] des [[Tuxbox|Tuxbox]]-Boards gepostet werden.

== Ich benötige [[Hilfe|Hilfe]]! ==
Supportanfragen können im [http://tuxbox-forum.dreambox-fan.de/forum/viewforum.php?f=7 Cross Development Kit - Forum] des [[Tuxbox|Tuxbox]]-Boards gepostet werden. Postings in deutsch oder englisch sind willkommen. Bitte nicht vergessen, die benutzten Konfigurationsoptionen zu erwähnen.

=Anhang=
==Einige nützliche [[Customization|Customization]] Script Snippets==
In diesem Anhang werden einige nützliche [[Customization|Customization]] Scripte gezeigt. Zwei Scripte sind bereits oben gezeigt worden.
 

'''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|es]] sei denn [[ES|es]] ist ungefährlich und Ihr versteht, wie sie funktionieren. [[ES|Es]] ist grundlegende Script-Erfahrung erfordelich.

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

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

=== /.version anpassen ===
Euere eigene ''/.version''-File herzustellen (anggezeigt von [[Neutrino|Neutrino]] durch dBox -> Services -> [[Image|Image]]-Version und cdkVcInfo beim Booten) ist sicher ein allgemeiner Wunsch.

*[[Flash|flash]]-version-local.sh

#/bin/sh
USER=$(whoami)
if [ $0 = $CDIR/flash-version-local.sh ] ; then
outfile=$FLASHDIR/root/.version
type="[[Image|Image]]"
else
outfile=$TARGETDIR/.version
type="[[Yadd|Yadd]]"
fi;
echo Creating $outfile ...
echo "version=`./mkversion -[[Snapshot|snapshot]] -version 200`" > $outfile
echo "creator=$USER" >> $outfile
echo "imagename=$USER-$type" >> $outfile
echo "homepage=[[HTTP|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|release]])
releasetype=0
;;
-[[Snapshot|snapshot]])
releasetype=1
;;
-internal)
releasetype=2
;;
-version)
versionnumber=$2
shift
;;
esac
shift
done
echo $releasetype$versionnumber$year$month$day$hour$minute

=== Archivierung der [[Images|Images]] ===
[[ES|Es]] ist eigentlich die Aufgabe des Buildprozesses, flashbare [[Images|Images]] zu erzeugen, und nicht sie zu archivieren. Jedoch kann die [[Customization|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]-[cramfs, squashfs,jffs2].[img1x, img2x]
haben. [[ES|Es]] benennt die Files entsprechend dem Tagesdatum um.

=Links=
*[http://www.gnu.org/software/make/manual/make.html GNU Make manual]
*[http://www.gnu.org/software/autoconf/manual/ Autoconf manual]
*[http://www.gnu.org/software/automake/manual/ Automake manual]
*[http://sources.redhat.com/autobook/ GNU Autoconf, Automake, and Libtool]
*[http://www.gnu.org/prep/standards/ GNU Coding standards]
*[http://cvsbook.red-bean.com/ Open Source Development with CVS, 3rd Edition]
*Barf's Homepage: [http://bengt-martensson.de/dbox2/ Barfs ][[Newmake]]-Dokumentation]

{{review}}

{{body}}