HowTo - Vom Auschecken bis zum Image

Vorwort

Worum geht es hier?

Es geht darum, sich eine eigene Linux-Firmware für seinen Receiver zu bauen. Dabei sind einige Hürden zu überwinden. Viele Leute geben bereits an dieser Stelle auf, da ihnen die Hürden einfach zu hoch sind. Selbst bei hundertprozentiger Einhaltung diverser Kurzanleitungen, treten oft dennoch Fehler, oder irgendwelche unvorhersehbaren Situationen auf, bei denen die meisten Anleitungen nicht weiterhelfen. Und somit wird das simple Erstellen einer eigenen Firmware zum Höllentrip durch den unglaublich grossen Cyberspace, auf der Suche nach der richtigen Antwort zum entsprechenden Problem. Dieses HowTo ist darauf ausgelegt, dass (möglichst) alle Fragen vor, während und nach dem Firmware-Selbstbau beantwortet werden.

Das Projekt "Tuxbox" (Linux auf einem DVB-Receiver) basiert auf einem Open-Source-Projekt, bei dem es darum ging, DVB-Dienste unter Linux zum Laufen zu bringen. Pionierarbeit leisteten (u.a.) die Metzler-Brüder mit ihren API-Treibern. Irgendwann 2001/2002 schraubte ein User (tmbinc, ein Pionier beim Tuxbox-Projekt, und späterer Initiator von enigma) an seiner DBox2 herum, und brachte sie in den sogenannten Debugmodus. Der Bootloader von Betaresearch selber konnte bis heute noch nicht gehackt, und demnach auch nicht ausgetauscht werden, aber der BR-Bootloader sprang auf diverse Standard-Protokolle an, die auch Linux beherrscht. Darauf baute dann Stück- für Stück "Tuxbox" auf. Die DBox2, welche von 3 verschiedenen Herstellern angeboten wurde, wurde plötzlich zum äussert beliebten Objekt vieler Hobby-Liebhaber, da sie (gegenüber der Betanova-Firmware - nun durch Linux aufgemotzt) wesentlich schneller, und vor Allem auch selbst-gestaltbar wurde. Sie wird mittlerweile nicht mehr hergestellt. Einige Receiver-Hersteller waren bereits zuvor am Linux-Projekt interessiert, doch als das Projekt Tuxbox so langsam erwachsen wurde, setzten einige Firmen auf Tuxbox.

Prima, denn mittlerweile kann man (mithilfe von Tuxbox) seine eigene Firmware für mehrere Receiver selber erstellen. Zb. für die Dreambox, Triple-Dragon, Reelbox, usw. Einige Treiber von einigen Herstellern sind nicht Open-Source (sondern Copyrighted). Es müssen die Original-Treiber der Hersteller implemetiert werden, was aber auch keine grosse Hürde darstellt. In diesem HowTo wird also nicht nur die DBox2 angesprochen, sondern auch andere Receiver. Nähres dazu ist hier zu lesen!

Allgemeines zu Tuxbox CVS

Was ist eigentlich CVS?

Concurrent Version System! So ähnlich wie in diesem WIKI, können mehrere Autoren an diversen Source (hier Text)-Versionen rum-doktor'n. Hat sich ein Autor vertan, erzählt Unsinn, oder hat falsch geklickt, so kann man die vorige Version zurückholen. Denn vorige Verionen werden archiviert. Ist eine Änderung korrekt, und sinnvoll, bleibt sie solange im sogenannten Head bestehen, bis ein anderer seine neusten Änderungen uploaded.

Der Head ist bei der DBox2 vorzuziehen. Aber neben dem Head gibts auch noch Verzweigungen, namens Branch. Wer zB. für die Dreambox ein Image erstellen will, checkt den CVS-Stand des Dreambox-Branches aus. Hier vereinen sich Dreambox-spezifische Sourcen, mit denen vom aktuellen Head.

Was ist eigentlich CDK?

Cross Developement Kit! Wozu braucht man das? Tja, man besitzt idR. einen x86-PC. Aber die Prozessoren in den Receivern besitzen meist einen PowerPC (ppc). Die "normale" Compiler-Umgebung bietet keine Möglichkeit, Programme zu compileren, die auf dem ppc laufen. Das CDK baut dafür einen Crosscompiler (Kreuzübersetzer für C und C++ zwischen x86 und ppc). Alles was dann durch diesen Compiler gejagt wird, kann der ppc ausführen (sofern keine Fehler drin waren *g*)

Das CDK baut auch einen Crosscompiler für Assembler; und den Stripper, der die sich ständig wiederholenden Tags aus den Binaries zieht, damit sie abschliessendend kleiner werden. Der Stripper kann auch Libs verkleinern. Das CDK beherbergt aber auch noch andere, nette Features.

Das CDK ist also das Herzstück, bzw. der Schlüssel zur eigenen Firmware auf dem eigenen Receiver.

Vorbereitungen auf dem PC

Um sich das CDK (und letztendlich ein Image) zu erstellen, benötigt man bestimmte Tools in bestimmten Versionen.

root oder user ?

Antwort: User! Und zwar immer!

Ausnahme: Genau jetzt! Denn Tools- bzw. allgemein für-alle-User-geltende Software kann nur der root installieren. Für andere Dinge braucht man den root eigentlich nicht.

Wie werde ich root?

Es gibt mindestens vier Möglichkeiten

1. Beim Einloggen in das Betriebssystem als root anmelden
2. Als User die root-shell öffnen
3. Normale shell öffnen und sudo su, sudo oder su - (das "-" ist für die Umgebungsvariablen von "root") eingeben.
4. Root und User gleichzeitig und parallel sein.......

...... da es unter Linux mehrere virtuelle Konsolen, bzw. Desktops gibt, kann man auch gleichzeitig als user, wie als root angemeldet sein.

Unter einer grafischen Desktop-Umgebung, kann man mit der Tastenkombination

STRG+[F-Taste]

zwischen (meist) mindestens 4 grafischen Desktops F[1-4] umherschalten.

Mit der Tastenkombination

STRG+ALT+[F-Taste] 

kann man zwischen weiteren Text-Modus-Konsolen umherschalten. Meist ist F7 zurück in den grafischen Modus. Mithilfe dieser Text-Modus-Konsolen kann man auch diverse, grafische Oberflächen gleichzeitig starten. Denn es gibt ja noch andere, als nur KDE. Die Anzahl der Konsolen ist von der Distribution abhängig. (In der HowTo_-_Vom_Auschecken_bis_zum_Image#Streamboard VMWare Beta-Buildumgebung wechselt man die Konsolen mit ALT + F[1-6])

Zurück zum Geschäft:

Wenn die Tools installiert sind, beendet man sein root-Dasein wieder, und loggt sich wieder als User ein, oder wechselt eben wieder auf seine User-Ebene/Konsole/Oberfläche zurück. In unserem Fall sollte alle weiteren USER Aktionen unter dem USER "sb" passieren. Aber zunächst mal zu den Tools, und wie man sie als root installiert.....

Tools (Prerequisiten)

Prerequisiten? Was'n das? Man stelle sich vor, man will einen Starwars-Film drehen, und kein Schauspieler hat ein Laserschwert zur Verfügung. Damit der Film rockt, braucht jeder Starwars-Schauspieler auch die Requisite "Laserschwert".

So ähnlich ist es auch mit den Prerequisiten, die für Tuxbox benötigt werden. Fehlt dem eigenen Linux-System auf dem PC ein Tool, dann klappt das nicht mit dem Firmware-Selbstbau.

Laut [1] muss man folgende Prerequisten an Bord haben:

• cvs
• autoconf >= 2.57a
• automake >= 1.8
• libtool >= 1.4.2
• gettext >= 0.12.1
• make >= 3.79
• makeinfo (texinfo)
• tar
• bunzip2 (bzip2)
• gunzip (gzip)
• patch
• infocmp (ncurses-bin / ncurses-devel)
• gcc 2.95 or >= 3.0
• g++ 2.95 or >= 3.0
• flex
• bison
• pkg-config
• wget
• libpng2 or libpng3 (DirectFB)

Abweichend davon wird zudem noch folgendes benötigt:

• fakeroot
• mksquashfs >= 2.1
• mkcramfs
• mkfs.jffs2

Es gibt im Tuxbox-CVS den toolchecker (Bashskript), welcher die meisten dieser Versionsstände automatisch ermittelt. Man lädt sich das Skript auf den lokalen Rechner, ändert die Rechte auf ausführbar (chmod +x toolchecker.sh) und startet es. Dann vergleicht man einfach die ermittelten Versionen mit den hier gelisteten. Ist eine Prerequisite nicht vorhanden, oder hat eine kleinere Versionsnummer, muss man diese noch nachinstallieren/updaten. Wird keine Version angegeben: Nicht schlimm. Nur vorhanden sein muss es. Wer bereits das CVS ausgecheckt hat, hat den Toolchecker bereits auf seinem PC und kann ihn somit so ausführen

sb@build:# /tuxbox-cvs/hostapps/toolchecker/toolchecker.sh 

Sollte eine Prerequisite nicht vorhanden sein, so muss sie über die entsprechend in der Distribution vorhandenen Installationstools installiert werden. Die nachfolgenden Sektion behandelt die Vorgehensweise bei einigen dieser Distributionen.

Debian

Unter Debian http://www.debian.de gibt es das Toolset apt-* zur Verwaltung von Programmen. Mit apt-cache search kann ich z.B. nach Programmen suchen, mit apt-get install Programme installieren. Des Weiteren existiert mit dem Tool aptitude auch die Möglichkeit, Pakete über ein Menüsystem auszuwählen.

apt-setup

apt-setup dient zum Konfigurieren des Internetzugangs und der Protokolle für das Updaten der einzelnen Softwarepakete. In den meisten Fällen wurde diese Konfiguration bereits bei der Installation von Debian vorgenommen und muss somit nur dann erneut aufgerufen werden, wenn etwas nicht wie gewünscht funktioniert. Man kann generell zwischen cdrom, ftp, http oder einem Dateisystem als Downloadquelle auswählen. Wenn man eine Internetanbindung (xDSL) hat, sollte man sich entweder für ftp oder http entscheiden. Als nächstes wählt man das Land, in dem man sich befindet. Dadurch wird im nächsten Schritt dann ein Server aus deiner Nähe ausgewählt. Am Ende wird von diesem Server die aktuelle Paketliste geladen und lokal abgespeichert. Evtl. kann man noch zusätzliche Quellen angeben.

apt-update

Da sich bei den Softwarepaketen immer wieder was verändert und Neuerungen/Bugfixes hinzukommen, ändert sich auch die Version der einzelnen Pakete. Durch ein

root@build:~# apt-get update

wird von dem oben eingestellten Server die aktuelle Paketliste geladen. Diese wird dann im nächsten Schritt benötigt.

apt-upgrade

!!ACHTUNG!! Hier ist Vorsicht geboten. Dieser Befehl zieht alle installierten Pakete auf die aktuelle Version. Dies ist jedoch nicht immer gewünscht. Man wird jedoch gefragt, ob man dies wirklich machen möchte. Seht euch die Pakete an, die upgedatet werden, ihr könnt mit CTRL-C immer noch abbrechen! Überlegt euch diesen Schritt gut und führt möglichst ein Backup durch.

SuSE

Unter SuSE koennt ihr mit rpm -q <paketname> anhand o.a. Liste auch ohne toolchecker vergleichen welche Version des Pakets ihr installiert habt.

Yast

Ist ein Paket nicht installiert, am besten erstmal mit Yast schaun ob es überhaupt in der Distribution ist und ggf. nachinstallieren.

rpm

Mit dem Befehl

root@build:~# rpm -i <paketname> 

könnt ihr ggf. manuell aus dem Internet heruntergeladene Pakete nachinstallieren.

Andere Linux-Distributionen

Knoppix

KNOPPIX ist eine komplett von CD oder DVD lauffähige Zusammenstellung von GNU/Linux-Software mit automatischer Hardwareerkennung und Unterstützung für viele Grafikkarten, Soundkarten, SCSI- und USB-Geräte und sonstige Peripherie. KNOPPIX kann als produktives Linux-System for den Desktop, Schulungs-CD, Rescue-System oder als Plattform für kommerzielle Software-Produktdemos angepasst und eingesetzt werden. (Quelle: Knoppix-Homepage) Download auf der Knoppix-Homepage

Wie bekomme ich Knoppix auf meine Festplatte?

Grundsätzlich ist Knoppix für den Einsatz zum Erstellen eines Images geeignet; aufgrund der Tatsache, dass allerdings nicht alle benötigten Pakete enthalten sind und diese nach jedem Neustart wieder verlorengehen gehen wenn man sie nachinstalliert, ist eine Installation auf eine Festplatte mehr als empfehlenswert (außer für eventuelle Testzwecke).

• Knoppix von CD/DVD starten
• Shell öffnen

sb@build:# sudo knoppix-installer

oder

root@build:# knoppix-installer

eingeben und mit [Enter] bestätigen

• den Anweisungen folgen

Hier mal ein Hd Install HowTo aus dem Knoppix-Wiki (leider nur in Englisch) Hier noch ein Video zur HD-Istallation (auch Englisch)

Was ist typischerweise für Knoppix zu ändern um mit dem Compilieren loslegen zu können?

Man benötigt noch folgende Software die noch nicht in Knoppix5 enthalten ist:

• bison
• libpng2 or libpng3 (DirectFB)
• libtool >= 1.4.2
• makeinfo (texinfo)
• pkg-config
• flex

eventuell noch:

• mksquashfs
• mkfs.jffs2
• mkcramfs

Streamboard VMWare Beta-Buildumgebung

Es steht testweise eine Buildumgebung für VMWare bereit.

http://streamboard.gmc.to/wbb2/tut-pics/StreamboardVMware251020061933.exe (70MB)  

Diese basiert auf einem minimalen Debian-System und sollte bereits alle nötigen Pakete beinhalten. Es ist keine GUI installiert um die Downloadgröße gering zu halten. Diese kann aber mittels aptitude bzw. apt-get (vgl. Debian-Abschnitt) mit nur wenigen Befehlen nachinstalliert werden.

Die Installation unter Windows erfolgt sehr einfach:

1. Download und Installation des VMWare-Players (Freeware) oder VMWare Workstation (benötigt nach 30 Tagen eine Lizenz)
2. Entpacken der StreamboardVMware251020061933.exe in ein beliebiges Verzeichnis (auf ausreichend Speicherplatz achten! Später wird das Ganze ca. 2-3GB groß)
3. Mit einem Doppelklick auf die entpackte StreamboardBuildumgebung.vmx sollte der VMWare-Player bzw. Workstation starten und sich die Buildumgebung automatisch öffnen.
4. Nach dem Start von Debian kann man sich dann mittels dem Usernamen "sb" und Passwort "kalibo" einloggen. Das Passwort für den root-Zugang (nötig für die Installation weiterer Software) lautet "Streamboard". Diese Informationen werden auch beim Starten angezeigt.

Im Anschluss daran kann man mit dem Imagebau laut diesem Howto beginnen. Es sollten keine weiteren Vorbereitungen nötig sein und somit kann gleich hier angefangen werden!

In der Buildumgebung läuft bereits ein fertig eingerichteter SSH-Server (für einfacheres Copy-and-Paste zwischen eurem Windows-System und der Buildumgebung) sowie auch ein FTP-Server zum Datenaustausch. Zum Verbinden werden hierzu die normalen Benutzerdaten (siehe oben!) verwendet. Die IP wird dynamisch vergeben und beim Starten angezeigt; ihr erhaltet sie aber auch später indem ihr entweder

sb@build:~# sudo ifconfig

bzw. als root-User einfach nur

root@build:~# ifconfig

eingebt. Hierbei seht ihr auch schön die Funktion des Befehls sudo: Wenn ihr diesen vor ein Kommando stellt, so wird dieser Befehl als root ausgeführt. Ihr braucht euch also nicht umständlich erst als root anmelden bzw. mittels dem Befehl "su" zum root-Account wechseln falls hier im Wiki manche Befehle root-Rechte benötigen!

Unter Umständen ist es noch nötig, mittels Manage Virtual Networks (im Startmenü von VMWare enthalten) im Reiter NAT für das Netzwerkinterface ein entsprechendes Portforwarding einzurichten sowie Aktives FTP zu aktivieren. Im Allgemeinen ist dies allerdings nicht notwendig!

Das Streamboard-Team würde sich über Rückmeldungen im Forum sehr freuen! Es können durchaus noch Bugs enthalten sein, da das Paket noch nicht ausreichend getestet werden konnte.

(optional) VMWare Tools installieren

VMWare bietet unter dem Namen VMWare Tools für viele gängige Betriebssysteme spezielle Treiber an. Diese verbessern die Performance (z.B. des Netzwerks) oder bringen zusätzliche Features (z.B. direkte Integration von Ordnern des Hostbetriebssystems). Sie sind für den Betrieb nicht notwendig aber grundsätzlich ist die Installation empfehlenswert.

Zur Installation müssen zunächst die sogenannten "Kernel-Header" mittels folgendem Befehl installiert werden:

root@build:~# cd /usr/src
root@build:~# apt-get install kernel-headers-2.4.27-3-386

Anschließend benötigt ihr noch das eigentliche Treiberpaket. Hierfür gibt es 2 Möglichkeiten:

1. Ihr ladet unter Datei:VMwareTools.exe das Archiv herunter und extrahiert die TAR-Datei. Mit einem FTP Client könnt ihr diese dann in die Buildumgebung nach /usr/src hineinkopieren. Anschließend führt ihr folgende Befehle aus um die Dateien zu entpacken

root@build:~#  tar -zxf VMwareTools*.tar  

2. Ihr nutzt den in VMWare-Workstation integrierten Button unter dem Menüpunkt VM. Die Tools werden dann als virtuelle CD-Rom ins System eingebunden. Über folgende Befehle kann man diese dann entpacken:

root@build:~# mount /cdrom
root@build:~# tar -zxf /cdrom/VMWareTools*.tar.gz

Anschließend geht es an die eigentliche Installation.

root@build:~# cd vmware-tools-distrib
root@build:~# ./vmware-install.pl

Die entsprechenden Meldungen sind allesamt einfach nur mit [Enter] zu bestätigen bis die Frage nach den "C header files" gestellt wird. Hier muss dann /usr/src/kernel-headers-2.4.27-3-386/include angegeben werden. Der Rest sollte dann problemlos durchlaufen und spätestens nach einem Neustart sind die VMWare Tools aktiv.

Um nun einen Ordner zu integrieren, muss man diesen zur Konfigurationsdatei von VMWare erst hinzufügen. In VMware Workstation geht dies ganz einfach über die entsprechenden Menüs in den Einstellungen der StreamboardBuildumgebung. Für den VMWare-Player müssen in der Datei StreamboardBuildumgebung.vmx mit einem Texteditor folgende Zeilen manuell hinzugefügt werden, damit der gesamte Ordner C:\ unter Linux über den Ordner /mnt/hgfs/Festplatte verfügbar ist:

sharedFolder0.present = "TRUE"
sharedFolder0.enabled = "TRUE"
sharedFolder0.readAccess = "TRUE"
sharedFolder0.writeAccess = "TRUE"
sharedFolder0.hostPath = "C:\"
sharedFolder0.guestName = "Festplatte"
sharedFolder0.expiration = "never"
sharedFolder.maxNum = "1"

(optional) Mausunterstützung in der Konsole

Um auch in der Konsole mit Mausunterstützung arbeiten zu können, müsst ihr euch das Tool gpm installieren.

root@build:# apt-get install gpm

Bei den meisten Sytemen sieht die Konfigurationsdatei /etc/gpm.conf so aus.

#  /etc/gpm.conf - configuration file for gpm(1)
device=/dev/psaux
responsiveness=
repeat_type=none
type=imps2
append=
sample_rate=

Nach einem Neustart kann man innerhalb der Konsole von nun an recht einfach mittels Copy&Paste arbeiten.

Vorbereitungen zum Compilieren

Falls nicht schon geschehen, jetzt als User einloggen.

Anmerkung: Dieser Username erscheint auch später in Eurem Image

Ein paar Verzeichnisse anlegen (tuxbox-cvs, dbox2, etc)

sb@build:# mkdir /tuxbox-cvs
sb@build:# mkdir /dbox2

Auschecken

Solltet ihr einen Proxy vorgeschaltet haben, so ist folgendes in eurer Shell einzugeben:

sb@build:# export http_proxy="eure_proxy_ip_:_port"

Bei einigen Distributionen wie z.B. SuSE braucht man den Proxy nicht extra anzugeben, wenn er unter Yast schon angegeben wurde.

Im Anschluss daran laden wir das CVS vom Tuxboxserver herunter:

sb@build:# export CVS_RSH=ssh
sb@build:# cd /tuxbox-cvs
sb@build:# cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -P .

Wenn ihr das CVS bereits heruntergeladen habt, so müsst ihr es nicht komplett nochmal neu runterladen sondern könnt auch einfach nur die neuen Dateien holen:

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

Tarball erstellen

Bevor man jetzt irgendwas anderes tut, sollt man sich erstmal einen Tarball von den ganzen runtergeladenen Daten erstellen. Warum? Falls man beim Editieren irgendwelcher Dateien Mist gebaut hat, muss man dann nicht mehr neu auschecken.

sb@build:# cd /
sb@build:# tar -cvf tuxbox-cvs_backup.tar ./tuxbox-cvs ./dbox2

Das "./" sollte man jeweils mit eingeben, damit man den Tarball später an einem anderen Ort/Rechner problemlos entpacken kann. Der Dateiname des .tar-Files kann frei gewählt werden. Es ist zu empfehlen, im Dateiname noch das Datum mit hinzuzufügen. ZB. tuxbox-cvs_backup_200600912.tar

Tarball wiederherstellen

Damit werden die bestehenden Dateien wieder überschrieben.

sb@build:# cd /

oder

sb@build:# cd /wohin/auch/immer

sb@build:# tar xvf tuxbox-cvs_backup.tar

mklibs kopieren

Die Datei mklibs muss noch entsprechend nach /usr/bin kopiert werden (sofern noch nicht vorhanden; in der StreamboardBuildumgebung ist sie bereits vorhanden). Dazu gibt man folgendes ein:

sb@build:~# cp /tuxbox-cvs/hostapps/mklibs/mklibs.py /usr/bin/mklibs
sb@build:~# chmod 755 /usr/bin/mklibs

Konfigurieren

Im Anschluss daran fehlt noch:

sb@build:# cd cdk
sb@build:# ./autogen.sh
sb@build:# ./configure --prefix=/dbox2 --with-cvsdir=/tuxbox-cvs --enable-maintainer-mode --with-targetruleset=flash

Letzte Chance noch manuell ins Geschehen einzugreifen

Vor-Überlegung: Welche(s) FileSystem(e) nehmen?

Das, was alles später ins Image soll, ist bis zu 20MB gross. Aber wir haben nur 8MB im Flash der Dbox2 zur Verfügung. Deshalb gibt es komprimierte Dateisysteme ähnlich wie es komprimierte ZIP-Dateien gibt. Die Filesysteme, die sich am stärksten komprimieren lassen haben leider den Nachteil, dass sie nicht beschreibbar sind.

Wo liegen die Vor- und Nachteile der Filesysteme?

Die beiden am besten komprimierenden Filesysteme sind CRamFS und SquashFS.

• SquashFS mit LZMA-Unterstützung ist der Platzhirsch im wahrsten Sinne des Wortes. LZMA gibts aber nicht im Tuxbox-CVS und so muss man es sich selber reinpatchen. Weiterer Nachteil: Die DBox2 bootet langsamer, und alles wirkt etwas "hakelig", da der kleine Prozessor viel zu ackern hat, die Daten zu dekomprimieren (obwohl laut [2] LZMA im Vergleich zu ZLib nur 1/10 des Speichers benötigt zum Dekomprimieren). Auf der Dreambox, Triple-Dragon, usw. merkt man es nicht. Zudem ist es ein nur-lesbares Dateisystem.
• SquashFS mit der normalen ZLib-Komprimierung ist das gängigste Dateisystem. Der Betrieb unter der DBox2 ist dann auch von der Performance her akzeptabel. Allerdings komprimiert LZMA eben um die 10% stärker. Auch wieder nur-lesbar.
• CramFS war früher das gängigste FS, und wird auch heute noch viel für die Dreambox benutzt. Die Komprimierung ist schwächer als bei den SquashFS-Formaten und die Geschwindigkeit etwas besser. Aber auch nur-lesbar.
• JFFS2 ist das Filesystem, welches auch beschreibbar ist. Somit ist es der Gewinner unter allen Filesystemen, und man kann sich auch ein JFFS2-Only-Image bauen. Aber obwohl es zusätzlich noch eine Realtime-Compress-Engine besitzt, komprimiert es am schlechtesten. So ca. 14MB bekommt man ins JFFS2-Only rein. Es kann vorkommen, dass ein JFFS2-Image "platzt" (das Dateisystem lässt dann trotz Speicherplatz keine neuen Dateien oder Änderungen mehr zu) wenn es nahezu vollständig gefüllt ist. Dies ist allerdings durch diverse Verbesserungen und Patches in letzter Zeit relativ selten geworden.

Am besten ist also ein Mischsystem um die Vorteile der hohen Komprimierung und des schreibbaren Dateisystems zu kombinieren. Also eine Partition für die "grossen Brocken", die man eh nie ändert, und eine Partition mit JFFS2 für Konfigurationsdateien, Emus etc. Wenn man vor dem Partitionieren noch eine Menge nicht unbedingt benötigter Sachen rausschmeisst (Spiele, ungenutzte Skins, Hintergrundbilder, usw.), kann man (z.B.) die SquashFS-Partition kleiner ausfallen lassen. Dadurch kann man ein grösseres JFFS2 als zweite Partition anhängen.

Wenn man meint, ein gutes Gleichgewicht zwischen beiden Partitionen gefunden zu haben, so muss dazu zwingend der Kernel und das U-Boot angepasst werden (außer wenn man mit den Default-Einstellungen im CVS zufrieden ist)!

"make all" - Jetzt gehts los

Was ist ein YADD, und was gibt man hier ein?

Yadd steht für "yet another dbox distribution" und stellt eine Zusammenstellung aller Dateien dar, die auch in einem Image enthalten wären. Allerdings wird es nicht auf die Dbox geflasht sondern direkt über das Netzwerk gebootet. Insbesondere zum Testen ist ein YADD-Image daher sehr empfehlenswert da der Flashvorgang entfällt!

Auf der Fehlersuche

Zuvor erstellten Tarball nutzen, um was ver-sau-beuteltes nochmal neu zu starten

(Sourcen überkopieren; Datums/Zeit-Problematik bei Files)

siehe HowTo_-_Vom_Auschecken_bis_zum_Image#Tarball_wiederherstellen

Ich will nachträglich was im Source ändern, und z.B. Neutrino neu compilieren

Einfach im Source rumtippen. Anschliessen zurück zu /tuxbox-cvs/cdk wechseln, und zB. make neutrino eingeben. Aber evtl. hat man ja nicht nur die Neutrino-Sourcen geändert. Dann könnte man auch make all eintippen. Ein make all ist aber nur zu empfehlen, wenn man ganz zu Anfang (nach dem auschecken und dem autogen und dem configure) auch make all angebenen hatte. Wenn nicht, dann wird der ganze Rest des CVS-Standes compiliert, der bis dato noch nicht compiliert wurde, und der in den makefiles der ersten Ebene enthalten ist.

Doch was ist da los? Es tut sich nichts. Im Log steht, es gäbe nichts zu tun. Tja, es muss noch das .dep-File gelöscht werden.

Was ist ein .dep-File?

Ein depfile ist ein Indikator, der dem CDK vermittelt, das eine bestimmte Sache erledigt ist. Ist es vorhanden, denkt das CDK, es gäbe nichts zu tun, auch wenn inzwischen Sourcen geändert wurden.

HEAD:

Im obigen Beispiel liegt das .dep-File von Neutrino unter /home/tuxbox-verzeichnis/cdk/.deps/ Entweder man wechselt in das Verzeichnis hinein, tippt rm neutrino ein, wechselt wieder mit cd .. zurück, und gibt seine make Anweisung erneut ein, oder man tippt gleich rm -f .deps/neutrino ein, gefolgt von der make Anweisung.

Dreambox-Branch:

Wenn man für die Dreambox ausgecheckt hat, findet man das .deps Verzeichnis nicht. Die .deps liegen direkt im /home/tuxbox-verzeichnis/cdk/ Verzeichnis, und haben den Punkt vorne am Dateinamen. Hier wäre vor der make Anweisung rm -f .neutrino einzugeben.

Was ist ein diff ?

Zunächst einmal zur Abkürzung: diff steht für difference, also Unterschied. Ein diff-File ist also eine Unterschieds-Datei. Will man eine Source editieren, empfiehlt es sich immer ein Backup zu machen. Wer zB. an der enigma_main.cpp editiert, tippt zuvor noch ein:

sb@build:# cp enigma_main.cpp enigma_main_orig.cpp

Somit ist der Originalzustand gesichert, und es kann angstfrei editiert werden.

Wenn man fertig ist, möchte man evtl. noch nur die Änderungen zwischen dem neuen und dem alten Stand der Source sehen. Dazu gibt man ein:

sb@build:# diff -Naur enigma_main_orig.cpp enigma_main.cpp > enigma_main.cpp.diff

Fertig ist das diff-File.

Was ist ein Patch ?

Genau das Gegenteil vom diffen. Zuvor haben wir gedifft. Jetzt wollen wir patchen. Nehmen wir an, es wurde gerade ganz frisch das CVS neu ausgecheckt, und die Datei enigma_main.cpp ist noch im Originalzustand. Nun kopiert man das enigma_main.cpp.diff in dasselbe Verzeichnis, und tippt ein:

sb@build:# patch -p0 -b enigma_main.cpp enigma_main.cpp.diff

Der Parameter -b gibt an, dass noch ein Backup erstellt werden soll.

Datums/Uhrzeit-Problematik von Sourcen

Zum Zweck, falls man eine Source versehentlich kaputtrepariert hat, haben wir uns ja zuvor ein Backupfile angelegt. Dieses besitzt grundsätzlich ein älteres Datum. Wir wollen den Originalzustand wiederhaben, und denken wir sind schlau, überschreiben enigma_main.cpp mit dem Originalfile, und compilieren nochmal. Dann stellen wir fest, dass der kaputtreparierte Stand compiliert wurde. Wieso das?

Der Compiler denkt, dass die Source nix Neues zu bieten hat, weil sie älteren Datums ist. In diesem Fall einfach

touch enigma_main.cpp

und die Datei hat ein neues Datum bekommen.

Links

Tuxbox-Plattform: http://tuxbox.org/
CVS-Server: http://cvs.tuxbox.org/
Mailing-List: http://cvs.tuxbox.org/lists/
TuxboxWIKI: http://wiki.tuxbox.org/Hauptseite

Credits

Admin
horsti666
limette
martie
Nessus
...und ein paar Unbekannte, die nicht den Anmelden-Knopf gefunden haben

Viel Spass beim Image-Bau