Neutrino für SH4 Boxen "open-duckbox-project-sh4"

[prodigy7]

Sehe ich genauso wie du. Wenn ich es richtig in Erinnerung habe, gibts ja glaubich bereits configure-Optionen um bei Bedarf ein fertiges Toolchain zu nutzen oder?

[rhabarber1848]

gibts ja glaubich bereits configure-Optionen um bei Bedarf ein fertiges Toolchain zu nutzen oder?

Code: Alles auswählen

--with-toolchain=PATH   do not build a toolchain but use the one at PATH

Habe ich aber noch nie getestet, da ich anders arbeiten möchte.

[prodigy7]

Naja ... da ja beide Seiten (fertiger und gebauter Crosscompiler) her nutzbar sind, sollte ja jeder glücklich sein.

[pinky1981]

hallöle
ich bin en forum unabhängiger "entwickler"!!!!
aber ich geb auch ma meinen senf dazu bzgl kf forum dev git usw.
des git is vollkommen public
auch 90% der dinge im kf forum sind public!
was halt nich pub is sind test dinge die noch nich fertig sind um in en git zu wandern!
wenn des dann wirklich läuft wirds auch in en git pushed.
des is keine böse absicht nur was soll der DAU mit solchen art infos?
er würds nich verstehen, u.U sogar missverstehen und evtl anhänge einfach ma so ausprobieren und sein gerät sagt nix mehr!

des aaf dingens was hier angesprochen wurde is ne andere geschichte die ich nich beurteilen kann, darf, und möchte!!!!

ich bastel seit mehreren jahren an mei 910+922 ufs, bin von own build orig über e2 nun bei neutrino gelandet und als alt eingefleischter db2 user (10jahre benutzt und eigene img gebaut!) neutrino gewohnt.
des is auch in meinen augen des ideale os für ne ufs weil die bei weitem nich die hardware ner dream oder coolstream besitzt (16mbRAM usw.).

ich würde mich jedenfalls sehr freuen wenn man hier en konsens finden könnte das man zusammen vllt parallel db2+ufs entwickelt und vllt collstream noch hinzu nähme!
ideal wäre dann en git svn cvs whatever in dem alles vereinigt würde so wie bei z.b. freetz

des mit --with-toolchain=PATH liesse sich bestimmt auch umsetzen

hoffe des war nich mei letzter post hier
liebe grüsse
pinky

[Visitor]

Na super, der erste Entwickler ist also schon mal da

Du kannst den Leute hier sicher besser zeigen - sagen was Sache ist.
Ich bin ja nur ein DAU

[SoLaLa]

oh... ein neuer ... den ich als erstes mal bitten möchten ein klein wenig an seiner Ausdrucksweise zu arbeiten

[Visitor]

Oh und ein alter Entwickler
Sollte mich wohl mal zuerst besser umsehen bevor ich poste was SoLaLa

[dbt]

Also Interesse wäre schon mal da, aber keine HW, da mangelts noch... optimal wäre es, wenn man so 'nen Fuhrpark da stehen hätte, aber sowas is nicht mal so schnell finanziert.

[pinky1981]

also dienen kann ich mit
db2
ufs910
ufs922
was fehlt is coolstream (glaub aber des is dann eher zu vernachlässigen)
aber en coolstream besitzer lässt sich bestimmt auhc auftreiben

aber schön das es erstmal en generelles intresse an ner zusammenarbeit gibt!!!

prinzipiell gings ja denke ich erstmal darum alles in einem cvs git svn zu vereinigen.

ich seh mir des mit dem tufsbox cvs ma die tage an, versuche dann den path auf die toolchain für sh4 zu setzen und schaue was passiert

[SoLaLa]

also dienen kann ich mit
db2
ufs910
ufs922

mehr nich?

Sollte mich wohl mal zuerst besser umsehen bevor ich poste was SoLaLa

nö, aufpassen mußt du deshalb nicht... hast ja selber den link gepostet und ist ja auch gut so.
das duckbox git ist ja schon noch recht neu, Synergien seh ich eher bei seifes Projekt.

Den meisten membern hier (im tuxboxcvs) fehlt als allererstes mal die Entstehungsgeschichte des sh4-e2 und des sh4-neutrino:
die "Entwicklung" desselben hat weder im KF noch im aaf stattgefunden. In diesen beiden boards wurden nur images aus den zur Verfügung stehenden releases gemacht und dementsprechend verschiedene Richtungen eingeschlagen. Bei der Veröffentlichung seitens tdt war einzig und allein entscheidend daß das Projekt auf einem öffentlichen host liegen und möglichst schnell ein breites Publikum finden sollte und das tut es jetzt ja auch bei gitoriuos.org.

So ist niemand gehindert sich das git zu clonen (was für das tuxbox cvs evt. ein Ansatz wäre zunächst die Machbarkeit eines merges zu prüfen)
Hinderlich an der Stelle ist, daß die dbox architektur nur sehr wenig spielraum bzgl. der erstellten images zuläßt (8MB flash und 32MB Ram)
Auf der sh4-architektur ist wegen der vielfältigen Möglichkeiten (allein schon boot und mtd) das erstellen fertiger images direkt aus dem cvs heraus völliger Blödsinn. Ebenfalls ist die engstirnige Ausrichtung auf eine bereits abgekündigte UFS910 Blödsinn. Zeitgemäß und der vorhanden Palette an zur Auswahl stehenden Receivern angepaßt ist die git Lösung so wie sie jetzt ist. Gebaut wird dort eben _kein_ flashbares image sondern nur die Grundlage aus der flashbare images erstellt werden können. Die Hardware -Palette erstreckt sich momentan von 8 bis 32 MB flash und 64 bis 128MB RAM bei 64MB Videoram und 1 oder 2 Tunern, 1 oder 2 CIslots und 0 bis 2 Kartenlesern und bisher 3 verschiedenen Prozessoren bei etwa 8 cutsteps
Aus dieser Sicht müßte es einleuchtend sein, daß es kein "Universalimage" gibt und nicht geben wird.

[dogfather]

Moin zusammen .
Gebe in dieser Beziehung Solala recht fertige Neutrino Flash images anzubieten für alle boxen das können die Entsprecheneden Boards ja machen .
In einem Entwicklungsbereich sollte man nur die demenstprechenden Grundlagen zur verfügung stellen .

[rhabarber1848]

(alten thread wieder ausgegraben)

Wenn ich das richtig sehe, werden zum Kompilieren für SH4 rpm-Dateien genommen, um die toolchain bereitzustellen.

Hi,

basierend auf seifes buildsystem habe ich die cdk/configure-Option
--with-boxtype um "spark" erweitert, das ganze ist work-in-
progress, ein Bild bekommt man damit nicht auf den Fernseher.

Der Patch teilt sich in verschiedene Bestandteile auf:

cdk/make/bootstrap.mk ist schon unübersichtlich genug
EDIT: Patch ist im CVS

Der Patch für den neuen boxtype-Wert:
EDIT: Patch ist im CVS

Der eigentliche Patch für die spark-toolchain:
EDIT: Patch ist im CVS

To-Do
- Tuxtxt ist deaktiviert, da es nicht kompiliert
- Zusammenarbeit mit weiteren git-repos...

[Visitor]

Ist jetzt eine blöde Frage, und bitte nicht falsch verstehen!
Warum SH4 in das Buildsystem und nicht Seifes Neutrino ins SH4 Buildsystem?

Davon mal abgesehen dass es beim SH4 GIT schon sehr unübersichtlich ist.

Das Projekt interessiert mich jedenfalls, wenn auch nicht betreffend dem Pingulux oder wie auch immer die Baugleichen Geräte sich nennen.
Ich wäre da eher betreffend UFS910 und Atevio 7000 motiviert da ich die beiden besitze
Aber da bräuchte ich eigentlich nur die Kernel patches und eventuell ein paar andere Kleinigkeiten zu deinen diffs ändern wenn ich das richtig sehe.

[rhabarber1848]

Aber da bräuchte ich eigentlich nur die Kernel patches und eventuell ein paar andere Kleinigkeiten zu deinen diffs ändern wenn ich das richtig sehe.

Im Tuxbox CVS kann das von Dir gewünschte per Option --with-boxmodel
realisiert werden. Es ist nur die Frage, ob die weitere Nutzung des
Tuxbox CVS gewünscht ist... Die weitere Diskussion wird es zeigen

[Visitor]

Werde mir das jedenfalls mal näher anschauen.

EDIT:
Ahhh!
Habs mal ausgecheckt und gestartet.
Ich glaube ich bin begeistert.
Werde das mal mit PLATFORM=flash_ufs910 probieren.

[Visitor]

Seifes buildsystem hat ohne Probleme durchgebaut für spark wie hier beschrieben.
Kann es aber nicht testen, da ich keine Spark mehr habe.
Wenn mir einer von euch beisteht würde ich gerne mal versuchen mit dem tuxbox cvs für die UFS910 was zu bauen.

[rhabarber1848]

committed:

basierend auf seifes buildsystem habe ich die cdk/configure-Option
--with-boxtype um "spark" erweitert
[...]
bootstrap_generic.diff

http://article.gmane.org/gmane.comp.vid ... x.scm/3301
http://article.gmane.org/gmane.comp.vid ... x.scm/3302

Der Patch für den neuen boxtype-Wert:
boxtype_spark.diff

http://article.gmane.org/gmane.comp.vid ... x.scm/3303
http://article.gmane.org/gmane.comp.vid ... x.scm/3304
http://article.gmane.org/gmane.comp.vid ... x.scm/3305
http://article.gmane.org/gmane.comp.vid ... x.scm/3306

Der eigentliche Patch für die spark-toolchain:
spark.diff

http://article.gmane.org/gmane.comp.vid ... x.scm/3307
http://article.gmane.org/gmane.comp.vid ... x.scm/3308
http://article.gmane.org/gmane.comp.vid ... x.scm/3309
http://article.gmane.org/gmane.comp.vid ... x.scm/3310
http://article.gmane.org/gmane.comp.vid ... x.scm/3311
http://article.gmane.org/gmane.comp.vid ... x.scm/3312 (Freetype 2.3.9 ist noch nicht dran )