Neutrino auf der IPBox

[rhabarber1848]

Hi,

wie bereits hier zu lesen, sind Bestrebungen im Gange, Support für IPbox-Receiver
in das Tuxbox-CVS einzubauen.

Für diejenigen, die nicht wissen, was eine IPBox ist:
http://www.dgstation-forum.org/wbb2/thr ... 5#post2495
Kurzglossar:
- DGS = DGStation = Abcom
- Relook400 = IPBox4xx
- CubeCaFe250 = IPBox250

Dazu eines vorweg: Im erstgenannten Thread kam es zu einer heftigen Auseinander-
setzung bzgl. der GPL. Ich möchte daher bitten, diesbezgl. Debatten dort fortzusetzen
und diesen Thread einzig und allein auf technische Aspekte zu begrenzen.

anubis_neutrino hat sich bereit erklärt, seinen Code für ein Neutrino-Image auf
der IPBox hier zu veröffentlichen, damit er ins Tuxbox-CVS wandern kann.
Ähnliche Bestrebungen für die Dreambox und die Tripledragon sind ebenfalls im
Gange, sodass nach (hoffentlich) erfolgreichem Abschluß der Arbeiten
cdk/configure --with-boxtype zu einer wichtigen Option wird.

Meinem Vorschlag, die bisher per PM zwischen anubis_neutrino und mir geführte
Korrespondenz in Zukunft im Forum öffentlich zu führen, hat er zugestimmt, deshalb
poste ich nun die wichtigsten Punkte.

PS: Einschränkend muss ich sagen, dass ich nur eine Dbox2 besitze und keine
der anderen aufgeführten Gerätschaften. Daher sind meine Testmöglichkeiten
eingeschränkt und beziehen sich auf die Kompilierbarkeit der Änderungen und
der Funktionsfähigkeit des Tuxbox-CVS auf Dbox2-Hardware.

[rhabarber1848]

Das folgende ist eine PM von anubis_neutrino als Antwort an mich:
=========================================================

Mein Vorschlag zur Reihenfolge:
CVS/cdk
- hier müssen evtl. neue Pakete hinzugefügt werden (kommst Du mit den vorhandenen Versionen aus oder müssen hier Unterscheidungen getroffen werden?)
- configure.ac-Anpassungen bzgl. Boxtyp(en), die dann auch z.B. an Neutrino configure weitergegeben werden können

Viele Versionen sind schon in Ordnung. Kernel (2.6.17) mit Patches, Kernelmodule, U-Boot (1.1.2 oder 1.2.0) mit Patches und noch kleinere Sachen musste ich hinzufügen.

CVS/driver
- Kernelmodule?
Ich habe schon mal grob http://www.relook.cwispy.com/SDK/dgs_en ... ll.tar.bz2
überflogen. Sind das Teile der Änderungen, die von Dir zu erwarten sind?

Das ist der unschöne Teil daran, da davon wohl nirgends Sourcen existieren und es gibt da auch ein paar Unterschiedliche Versionen. Ich hab die neuesten die ich gefunden habe verwendet und wollte die dann auch hier hernehmen. In dem Archiv von dir sind mit Sicherheit schon welche drin.

CVS/apps/tuxbox/neutrino
- Boxtyp-spezifische Anpassungen?

Ein paar Anpassungen waren schon nötig, viele von den Dreambox-spezifischen Sachen sind bei den IPBoxen auch nötig, aber die sind ja schon vorhanden.
Den Movieplayer habe ich neu geschrieben, damit man dort auch normal Vor- und Zurückspulen kann ....

CVS/hostapps und CVS/cdk
- flashimage erzeugen

Ein paar Hostapps und der ganze Rest steht ja dann eh in der Makefile.am ...

Besteht Deinerseits die Möglichkeit, die Anpassungen hier im Forum
öffentlich zu diskutieren? Ich möchte nicht alle Entscheidungen darüber
alleine treffen, die anderen aktiven Entwickler sollten zumindest die
Möglichkeit haben, den Prozess mitverfolgen zu können.

Natürlich, mach du einen Thread auf, dann ist es gleich da wo es hin sollte ;-)

Viele Grüße
Robert

[rhabarber1848]

Kernel (2.6.17) mit Patches

Das Tuxbox-CVS ist bei Kernel 2.6.26.8 angekommen, mehr wird wohl in
nächster Zeit nicht gehen, da die Architektur ppc mit powerpc verschmolzen
wurde und unsere Patches für die Dbox massiv überarbeitet werden müssten.
Funktionieren Deine Patches auch mit Kernel 2.6.26.8 oder muss
2.6.17 verwendet werden?

U-Boot (1.1.2 oder 1.2.0) mit Patches

Tuxbox-CVS verwendet U-Boot 1.2.0, boxspezifische Patches sind kein Problem.
Daher würde ich, sofern möglich, auf U-Boot 1.1.2 verzichten wollen.

CVS/driver
- Kernelmodule?
Ich habe schon mal grob http://www.relook.cwispy.com/SDK/dgs_en ... ll.tar.bz2
überflogen. Sind das Teile der Änderungen, die von Dir zu erwarten sind?

Das ist der unschöne Teil daran, da davon wohl nirgends Sourcen existieren

Wie kriegen wir das GPL-konform hin? Ich würde ungerne Binaries im CVS ablegen,
stattdessen schwebt mir eine Lösung a'la --with-ucodesdir vor. Der Imagebauer hält
die Binaries in einem lokalen Verzeichnis vor, diese werden beim Kompilieren in
das Image kopiert, sind aber nicht Bestandteil des CVS.

Den Movieplayer habe ich neu geschrieben, damit man dort auch normal Vor- und Zurückspulen kann ....

Hast Du schon den movieplayer2 von seife getestet?

Ein paar Hostapps und der ganze Rest steht ja dann eh in der Makefile.am ...

Richtig, allerdings wird oldmake nicht mehr gepflegt, daher keine Makefile.am...
Keine Sorge, mit newmake kenne ich mich gut aus Meine Schwächen liegen
eher im C/C++-Bereich, aber das ist ein anderes Thema...

Falls Du Deine Patches über unser ULC zur Verfügung stellen möchtest, kannst Du
bei CarstenW einen Account anfragen.

[rhabarber1848]

Eine allgemeine Frage @anubis-neutrino:
Für welche Boxtypen soll das Image am Ende funktionieren?
Wie soll die Unterscheidung funktionieren? Kann ein Image auf
verschiedenen Modellen laufen oder braucht jeder Boxtyp ein
getrennt kompiliertes Image, d.h. eine eigene --with-boxtype-
Option in cdk/configure?

Bei der Dbox2 läuft ein und dasselbe Image auf den Sat- und, sofern
vorhanden, den Kabel-Modellen von Nokia, Sagem und Philips.
Es gibt unterschiedlich ausgestattete Modelle der IPBox,
in wieweit werden diese von Deinem Image unterstützt?

Nicht zu vergessen wäre auch, dass am Ende aus dem
Tuxbox-CVS heraus auch Enigma-Images für die IPBox
kompilierbar sein sollten.

[anubis_neutrino]

... Funktionieren Deine Patches auch mit Kernel 2.6.26.8 oder muss 2.6.17 verwendet werden?

Der 2.6.17 muss verwendet werden, weil der Treiberteil (head.ko) nur für diese Kernelversion existiert.

Tuxbox-CVS verwendet U-Boot 1.2.0, boxspezifische Patches sind kein Problem. Daher würde ich, sofern möglich, auf U-Boot 1.1.2 verzichten wollen.

Perfekt, den 1.1.2 brauchen wir eh nicht, der 1.2.0 unterstützt dann mit diversen Tools auch das Flashen per TFTP.

Wie kriegen wir das GPL-konform hin? Ich würde ungerne Binaries im CVS ablegen, stattdessen schwebt mir eine Lösung a'la --with-ucodesdir vor. Der Imagebauer hält die Binaries in einem lokalen Verzeichnis vor, diese werden beim Kompilieren in das Image kopiert, sind aber nicht Bestandteil des CVS.

Das können wir meinentwegen schon so machen. Wie wollen wir die dann verteilen? Oder muss die jeder selber irgendwo herbekommen?
Den Movieplayer2 von Seife kannte ich nicht. Hab aber gerade mal kurz drüber geschaut. Mein Ansatz ist hier halt komplett in C++ geschrieben. Kann ich auch gerne bereit stellen wenn Bedarf besteht. Der Code sieht halt wesentlich "aufgeräumter" aus als C-Code....

Richtig, allerdings wird oldmake nicht mehr gepflegt, daher keine Makefile.am... Keine Sorge, mit newmake kenne ich mich gut aus Meine Schwächen liegen eher im C/C++-Bereich, aber das ist ein anderes Thema...

Ok, wusste ich noch nicht, aber dann habe ich da ja schon einen Ansprechpartner ;-)

Eine allgemeine Frage @anubis-neutrino:
Für welche Boxtypen soll das Image am Ende funktionieren? Wie soll die Unterscheidung funktionieren? Kann ein Image auf verschiedenen Modellen laufen oder braucht jeder Boxtyp ein getrennt kompiliertes Image, d.h. eine eigene --with-boxtype- Option in cdk/configure?

Hab ich bis jetzt so gemacht. Jede Box benutzt hier seine eigene head.ko. Die Fernbedienung von der kleinsten (IPBox 200) ist auch noch Unterschiedlich zu den Anderen weshalb da noch ein extra Define im Code drin ist (ich glaub das ist ähnlich wie bei der Dream 500). Bei der Dreambox gibt's doch auch mehrere Boxtypes?

Nicht zu vergessen wäre auch, dass am Ende aus dem Tuxbox-CVS heraus auch Enigma-Images für die IPBox kompilierbar sein sollten.

Vielleicht findet sich ja noch der eine oder andere der das dann mal testet. Sehe da aber kein Problem.
Also wenn's möglich ist würde ich gerne in das CVS Sachen einchecken. Oder ist das nicht üblich? Wer würde mir hierfür einen Account einrichten?

[dietmarw]

http://forum.tuxbox-cvs.sourceforge.net ... 8&p=364825

[dietmarw]

...
Den Movieplayer2 von Seife kannte ich nicht. Hab aber gerade mal kurz drüber geschaut. Mein Ansatz ist hier halt komplett in C++ geschrieben. Kann ich auch gerne bereit stellen wenn Bedarf besteht. Der Code sieht halt wesentlich "aufgeräumter" aus als C-Code...

evtl. könntest du dich ja da mal mit seife direkt kurzschließen?

[gugu]

Ich habe driver Sourcen für Relook von Sandali. Sind aber nicht die neuste.
http://www.zshare.net/download/589316420ec6c343/

[anubis_neutrino]

Ich habe driver Sourcen für Relook von Sandali. Sind aber nicht die neuste.
http://www.zshare.net/download/589316420ec6c343/

Interessant die kenne ich nicht. Hab mir die gerade gezogen die sind für die Relook 400 (also eine der Ältesten Kisten) und noch für Kernel 2.6.9 laut Readme. Vielleicht kann man die später mal als Basis für eine Quelloffene Entwicklung hernehmen, oder es finden sich noch neuere ....

[rhabarber1848]

Der 2.6.17 muss verwendet werden, weil der Treiberteil (head.ko) nur für diese Kernelversion existiert.

Sowas in der Art habe ich schon befürchtet, öffentlichen Sourcecode dafür
gibt es sicher nicht, oder? Die gleiche Situation scheint bei der Dreambox
zu existieren, in dem heute vorgeschlagenen Patch für den Dreambox-build-
Support wird head.ko, und viele weitere Sachen, von einem externen Server
beim build heruntergeladen.
Ob diese Methode den Beifall der anderen Entwickler findet, weiß ich nicht.
Ich habe dazu weder eine positive noch eine negative Meinung, begeistert
bin ich allerdings nicht. Sofern die Dateien nicht im CVS liegen, ist der
beim Dreambox-Patch beschrittene Weg jedoch eine Alternative im
Stile von --with-ucodesdir und könnte als Vorbild für den IPBox-Support
dienen, das kann und werde ich aber nicht alleine entscheiden.

Wie kriegen wir das GPL-konform hin? Ich würde ungerne Binaries im CVS ablegen, stattdessen schwebt mir eine Lösung a'la --with-ucodesdir vor. Der Imagebauer hält die Binaries in einem lokalen Verzeichnis vor, diese werden beim Kompilieren in das Image kopiert, sind aber nicht Bestandteil des CVS.

Das können wir meinentwegen schon so machen. Wie wollen wir die dann verteilen? Oder muss die jeder selber irgendwo herbekommen?

s.o.

Den Movieplayer2 von Seife kannte ich nicht. Hab aber gerade mal kurz drüber geschaut. Mein Ansatz ist hier halt komplett in C++ geschrieben. Kann ich auch gerne bereit stellen wenn Bedarf besteht. Der Code sieht halt wesentlich "aufgeräumter" aus als C-Code....

Diesen Punkt würde ich gerne erstmal aus diesem Thread ausklammern.
Du kannst Deinen Code gerne in einem neuen, eigenen Thread zur
Diskussion stellen.

Eine allgemeine Frage @anubis-neutrino:
Für welche Boxtypen soll das Image am Ende funktionieren? Wie soll die Unterscheidung funktionieren? Kann ein Image auf verschiedenen Modellen laufen oder braucht jeder Boxtyp ein getrennt kompiliertes Image, d.h. eine eigene --with-boxtype- Option in cdk/configure?

Hab ich bis jetzt so gemacht. Jede Box benutzt hier seine eigene head.ko. Die Fernbedienung von der kleinsten (IPBox 200) ist auch noch Unterschiedlich zu den Anderen weshalb da noch ein extra Define im Code drin ist (ich glaub das ist ähnlich wie bei der Dream 500). Bei der Dreambox gibt's doch auch mehrere Boxtypes?

Bei der Dbox wird beim Booten der Boxtyp (tuxinfo -e liefert das Ergebnis) ermittelt
und in Abhängigkeit davon die Kernelmodule geladen, somit läuft ein Image auf allen
Hardwaretypen. Bei der Dreambox sehe ich allerdings, dass head.ko ~300KB gross ist
und in drei Versionen existiert, diese in ein Image zu packen wird wohl etwas viel...

Also wenn's möglich ist würde ich gerne in das CVS Sachen einchecken. Oder ist das nicht üblich? Wer würde mir hierfür einen Account einrichten?

Den Link dazu hat dietmarw Dir schon gepostet, allerdings würde ich es vorziehen,
dass Du Deine Patches ins ULC hochlädst, damit die interessierten Leute sich diese
anschauen und kommentieren können, bevor sie ins CVS wandern. Das hat auch den
Hintergrund, dass CVS funktionsfähig zu halten, auch im Hinblick auf das Dir wohl
bisher nicht bekannte newmake. Wenn die Patches den Kompiliertest hier bestehen,
kann ich sie gerne ins CVS committen.

[JtG-Riker]

@rhabarber1848

Das mit der head.ko kann man leider nicht ändern, das liegt an den Lizenzbestimmungen von IBM soviel ich das
noch von damals weis, deswegen gibts da keinen Source von.

Und das dream den alten Kernel nimmt liegt am fehlenden devfs bei den aktuellen.

Wie es bei der ipbox ist weis ich nicht, die kenn ich nicht.


Gruß Riker

[anubis_neutrino]

Den Link dazu hat dietmarw Dir schon gepostet, allerdings würde ich es vorziehen, dass Du Deine Patches ins ULC hochlädst, damit die interessierten Leute sich diese anschauen und kommentieren können, bevor sie ins CVS wandern. Das hat auch den Hintergrund, dass CVS funktionsfähig zu halten, auch im Hinblick auf das Dir wohl bisher nicht bekannte newmake. Wenn die Patches den Kompiliertest hier bestehen, kann ich sie gerne ins CVS committen.

Kein Problem, dann hole ich mir einen ULC-Account und schieb da dann die Patches hoch. Werd mich mal ein bisschen ins newmake einlesen und mich dann an die Arbeit machen ....

[anubis_neutrino]

Kurze Frage:

Boxtype in die acinclude.m4?
Und der Rest in die aufgeteilten Makefiles im make - Verzeichnis?

[rhabarber1848]

Boxtype in die acinclude.m4?

Ja, ich habe hier schon ein wenig Vorarbeit geleistet:
http://forum.tuxbox-cvs.sourceforge.net ... 07#p367007

Und der Rest in die aufgeteilten Makefiles im make - Verzeichnis?

Ja, wenn Du es im oldmake-Format hast, kannst Du Deinen jetzigen
Patch aus as-is hochladen, ich komme schon damit klar

[anubis_neutrino]

Boxtype in die acinclude.m4?

Ja, ich habe hier schon ein wenig Vorarbeit geleistet:
http://forum.tuxbox-cvs.sourceforge.net ... 07#p367007

Sieht schick aus, dann sollten wir evtl noch den --with-boxmodel für die ipboxen (ipbox200, ipbox250, ipbox350) wie bei der dream einbauen.

Und der Rest in die aufgeteilten Makefiles im make - Verzeichnis?

Ja, wenn Du es im oldmake-Format hast, kannst Du Deinen jetzigen Patch aus as-is hochladen, ich komme schon damit klar

Das könnte ein Problem werden, da ich den ganzen Code in einem eigenen Repository habe und nicht mit Patches gearbeitet habe. Das erstellen von funktionierenden Patches wird deshalb auch schwierig sein. Aber ich schau mal was ich machen kann.

[dietmarw]

...--with-boxmodel für die ipboxen (ipbox200, ipbox250, ipbox350)...

auch wenn die 400er älter und ein doppeltuner modell ist,
es wäre schön wenn man sie nicht generell vernachlässigen würde
(auch wenn evtl. (erstmal) nur ein tuner angesprochen werden würde)

thx

edit: was für ein repository nutzt du denn? das mit den diffs sollte doch in den griff zu bekommen sein..

[Striper]

edit: was für ein repository nutzt du denn? das mit den diffs sollte doch in den griff zu bekommen sein..

Wenn er z.B. eine SVN-Repo nutzt und dort peu à peu die Änderungen eingeflossen sind ist es leider nicht ganz so einfach.

[dietmarw]

zugegebenerweise habe ich nicht wirklich sehr viel ahnung von den verwaltungssystemen,
aber das wäre eine vorgehensweise die jedes verwaltungssystem meiner meinung nach beherrschen sollte:

um beim beispiel svn zu bleiben:
-er hat sein lokales svn
-er importiert das tuxbox cvs in einen parallelen svn zweig (passt evtl. noch ein paar verzeichnisnamen/ebenen an)
-und difft das ganze?


edit:
was mich im endeffekt wieder zu dieser frage zurückbringt
http://forum.tuxbox-cvs.sourceforge.net ... =7&t=48489

[seife]

Wenn man alles in GIT konvertiert ist es supereinfach und komfortabel

Mach ich grad mit dem itgate-Zeugs.

[rhabarber1848]

evtl noch den --with-boxmodel für die ipboxen (ipbox200, ipbox250, ipbox350) wie bei der dream einbauen.

Erledigt: http://forum.tuxbox-cvs.sourceforge.net ... 31#p367031

Welcher Wert muss für die gcc-Option --with-cpu für die IPBox(en) gesetzt werden?

Das könnte ein Problem werden, da ich den ganzen Code in einem eigenen Repository habe und nicht mit Patches gearbeitet habe. Das erstellen von funktionierenden Patches wird deshalb auch schwierig sein. Aber ich schau mal was ich machen kann.

Ein tarball Deines Repos wäre natürlich auch willkommen

[anubis_neutrino]

Welcher Wert muss für die gcc-Option --with-cpu für die IPBox(en) gesetzt werden?

405

Ein tarball Deines Repos wäre natürlich auch willkommen

Wäre vermutlich für mich am einfachsten ;-). Dann lasse ich die Teile an denen ich nichts geändert habe (Enigma, Lcars ...) aber weg. Ich schaue mal, das ich heute Abend dazu komme, hab momentan in der Arbeit viel zu tun ...

EDIT: Ach ja, ich habe in der Tat einen SVN-Server

[anubis_neutrino]

Hat ein bisschen gedauert. Also ich hab jetzt mal das cdk gepackt und hochgeladen. das komplette repo war wohl für den ULC zu groß (gepackt so um die 70 mb, ich schau mal was ich noch weglassen hätte können).

cdk_thor.tar.bz2

[dietmarw]

danke erstmal..

nun hoffen wir mal, das das bald jemand analysieren und "einpflegen" kann
so das auch für den normal user eine startbare option dabei herauskommt.

[rhabarber1848]

nun hoffen wir mal, das das bald jemand analysieren und "einpflegen" kann

Wenn der Dreambox-Patch Teil 2 im CVS ist, setze ich mich dran.

[anubis_neutrino]

Ach ja noch was zu den Boxnamen im CDK

ipbox200 -> mutant200s
ipbox250 -> cubecafe
ipbox350 ->(cubecafe-)prime

Ich habe damals die orginalnamen von dgstation verwendet. in Deutschland werden die Boxen aber von Abcom als Ipbox geführt. Mittlerweile gefällt mir Ipbox auch besser ....