SH4, Enigma2 and git(s)

[Audioniek]

Hello everybody,

About two weeks ago the buildsystem-git maintained by Max Wiesel was stripped of the capability to build Enigma2 with it. Max has made a copy of that git as buildsystem_old which still can build E2. What Max's plans are with the buildsystem_old git is not clear to me at this point in time, the emphasis seems to shift from SH4 to ARM and from E2 towards Neutrino.

I start this thread to inform everybody that I plan to support the SH4-boxes and E2 for as long as this is feasable. In this respect it should be noted that STM (the chipmaker) has stopped development of SH4 some time ago, so new SH4-hardware is not likely to appear in the future. At some point in time it is quite possible that E2 (which is steadily developed further) cannot be made to work properly on SH4, due to technical limitations. Also keep in mind that the oldest SH4 HD-boxes (Topfield TF7700HDPVR and first generation Fortis models for instance) now have an age of over ten years and should be regarded as obsolete.

Meanwhile, Bonkel is switching over to my git to build the SH4 E2 images. I will try to keep the git updated for at least as long as HDMU needs it.

Regarding my git, I am contemplating to remove all ARM-stuff, making it a strict SH4-git again as it used to be.

Greetings,

Audioniek.

[max]

Die Antwort ist recht einfach, ich besitze seit Anfang des Jahres keine sh4 Box mehr und somit ist es nicht so einfach alles am laufen zu halten.
Schaut man sich die Comments, der letzten Änderungen im git an, wo dann Sachen bei E2 nicht mehr gingen und ich dann mangels Box das auch nicht
fixen kann, habe ich halt den Entschluss getroffen, E2 aus dem aktiven buildsystem heraus zunehmen, tut mir nach den ganzen Jahren auch leid, es
ist aber auch doof wenn man immer nur Einzelkämpfer ist, über die Jahre.
Wer weiß, was aus sh4 geworden wäre, wenn man es über die Jahre, nicht kontinuierlich aktualisiert hätte.

[rantanplan]

Hello Audioniek

Problem of stm was probably more the bankruptcy. But the stuff is still there.
sh4 even exists with Kernel 3 .., but there is a lot to be done in terms of boxing.
HDMU had very long problems because of forum software and then also images that are far from working.
Since a little credit was gambled away.
Now it is running again reasonably. But it stays closed and you can not help much.
That's too bad, because the image always ran very fast.

Your git ..
Thank you for your separate work.
Also the driver branch is to be particularly mentioned.
For sh4 I hope for a long time support :-)

As a self-building image hobbyist, there are a few ideas for improving sh4 boxes

- disable PIP and give it more free RAM (thanks @dboxoldie)
PIP arrives only in SD, therefore rather ineffective
- Reactivate Compcache (ramzwap) for e2 that's really good
- Try the gcc 4.9.4 In the build system is still the 4.8.4

A few thoughts on your excellent work.

greetings

[Audioniek]

@Max:

Dass mit den Boxen verstehe ich, und sieht es bei mir etwas besser aus: Ausser ein HS7420 besitze ich alle Fortis Modelle als Rebox, nur der HS7429 ist ein Octagon, drei unterschiedliche Spark7162, ein Spark, ein TF7700HDVR und ein UFS912. Testen kann ich also ziemlich viel, aber leider nicht alles.

@rantanplan: Kernel 3 fuer SH4 waere schoen, da man die Treiber dann nicht mehr umschreiben muss.

Gruesse,

Audioniek.

[rantanplan]

Das mit dem Kernel 3 wurde ja schon vor Jahren im aaf und auch Panther Forum diskutiert.
Da es ja offen ist und die Sachen bzgl Kernel ja alle noch auf dem stm archieve liegen hab ich da mal eine ganze Weile dran rum gespielt.
Aber insgesamt fehlt mir dann doch das Wissen.
Gebaut hat stm ja die Weiterentwicklung bei dem Kernel-Update für 7008 Boxen.
Die allerdings sind vom Grundgerüst den 7005 ähnlich und bestimmt ist dies dann auch weiter umzustricken.
Max kann da bestimmt mehr zu sagen.
Ob allerdings überhaupt Kernel-Update sein muss, weiß ich nicht.
Für viele Anwendungen die drum herum gebaut werden ist die gcc wegen e2 da eventuell wichtiger.
Daher hatte ich die 4.9.4 erwähnt.
Ist etwas schneller zu testen.

Grüße

[max]

Wegen 3 Kernel ganz so einfach ist es nicht, hatte damit auch schon mal gespielt, als das stlinux git noch da war, konnte man auch ein revert machen, damit man
auch die anderen Boxen wieder bauen konnte. Das Hauptproblem ist dann aber player2, da dort einiges geändert werden musste.

[rantanplan]

Dann bist du aber ja schon richtig weit gewesen.
Hab das lokal versucht mittel Anpassung der beiden Patche miteinander zu integrieren.
Also man nehme Patch zum Kernel 2.6... und den letzten Patch stm zum Kernel 3.4.
Dauert eine ganze Weile (jedenfalls bei mir) bis man es halbwegs versteht was da wozu gehört.
Allerdings blieb als Konstante ja die 7108 bestehen und von der könnte man einiges ableiten.
Es hat aber bei mir nie zum baufähigen Kernel gelangt.
Hab da auch viel zu wenig Ahnung von und war so ein wenig spielerischer Ehrgeiz.
Einfach ist es ganz bestimmt nicht.
Wobei wenn da so ein alter ex stm Developer drüber stolpert, dann könnte den das ja irgendwie in den Fingern jucken.

Klar bleiben die Boxen alt und sterben aus.
Aber für die Anwendungen eines Receiver reichen sie immer noch alle mal aus.
Ob nun e2 oder auch Neutrino.
Grüße

[DboxOldie]

Selbst wenn jemand die SH4 Hardware in den 3er Kernel wieder einbaut, player2 Module anpasst, etc.
Bedeutet es noch lange nicht, das es besser / schneller / stabiler läuft als mit Kernel 2.6.32.71

[rantanplan]

Das ist ja auch meine Vermutung.
Aber weiß man es?
Bei all den Spielereien die an den anderen Boxen so vorgenommen werden wundert mich da immer das es überhaupt was wird.
Die bekommen einen closed Treiber mit closed Firmware hingeschmissen und dann wird dort der Kernel verändert.
Da passt bei so mancher mipsel Box nix zusammen. So gesehen hat mich das Dilemma mit der Venton Unibox nie gewundert.
Aber gut das sind deren Geschäfte....
Vorteil der sh4 Boxen wäre da immer ein einheitlicher Bau mit gleicher Compiler Umgebung.

Grüße

[joeuser]

Selbst wenn jemand die SH4 Hardware in den 3er Kernel wieder einbaut, player2 Module anpasst, etc.
Bedeutet es noch lange nicht, das es besser / schneller / stabiler läuft als mit Kernel 2.6.32.71

I agree. Unless there is some driving need to change the kernel, I am not sure anyone has the free time for all the work required. Also there seems to be no interest from those using oe-alliance to upgrade either.

I gave up on the duckbox developers' build environment about a year ago and switched to using oe-alliance (Taapat and MastaGs' gits). But I still use the drivers from duckbox developers. There are advantages and disadvantages to both build environments and not being a developer, I have to heavily rely on work from others. A short time ago when I noticed the dropping of enigma2 from buildsystem-ddt, I started looking into using Audioniek's git, but have not had the time to do much. If Audioniek is dedicated to continuing, I would be happy to follow his git and contribute what I can. But I only have an alien2 (spark7162) to play with...

BTW -= I know MastaG has been testing with gcc 4.9.4, but I have not tried it yet.

[Audioniek]

But I still use the drivers from duckbox developers.

Please note that in the drivers section the greatest difference between my git that that of duckbox-developrers exist. For the Sparks and Fortis you will find many improvements. In somewhat lesser regard this is also true for the apps and flash gits.


There are advantages and disadvantages to both build environments
I agree. I spent some time with oe-alliance and abandoned it for the following reasons:

When building on the same machine a build with oe-alliance takes more than five times longer;
You need to learn a new "language": BitBake;
It is a lot of work to add SH4 boxes other than Sparks and I found the process cumbersome and not very logical;
For SH4, oe-alliance relies heavily on the gits also used by the buildsystem, so why complicate things and not use the source directly?;
After a build is complete, the oe-alliance system has created over a million files and needs quite a bit of diskspace.


Regards,

Audioniek.

[suchmich1983]

Die Antwort ist recht einfach, ich besitze seit Anfang des Jahres keine sh4 Box mehr und somit ist es nicht so einfach alles am laufen zu halten.
Schaut man sich die Comments, der letzten Änderungen im git an, wo dann Sachen bei E2 nicht mehr gingen und ich dann mangels Box das auch nicht
fixen kann, habe ich halt den Entschluss getroffen, E2 aus dem aktiven buildsystem heraus zunehmen, tut mir nach den ganzen Jahren auch leid, es
ist aber auch doof wenn man immer nur Einzelkämpfer ist, über die Jahre.
Wer weiß, was aus sh4 geworden wäre, wenn man es über die Jahre, nicht kontinuierlich aktualisiert hätte.
@max
Könnte dir mit z.B. einer SPARK Box aushelfen, wenn es denn helfen wird!?!