Schimmelreiter-Images für Vu+ Solo²-Clones (Sunray und Lonrisun)

bis jetzt schon die box steht aber nicht bei mir ;-)
habe aber 5-8x neugestartet alles eingerichtet und sie läuft!
alle neustarts gingen problemlos!

OpenATV:

Da OpenATV 6.0 nun im öffentlichen Beta-Test ist, sind auch die Downloads meiner clone-safe-Images

OpenATV 6.0

nun ohne Passwort erreichbar!

Genialer support hier von dir! Allein die Posts zu den Unterschieden zwischen den im Laufe der Zeit erschienen Boxen.

OpenHDF 6.0

zugefügt.

@baden: Gefällt Dir das nur "einfach so" oder benutzt Du OpenHDF auch?

Ich wüßte einfach gerne mal von jemandem, der die anderen Images länger nutzt, wie sie laufen.
Selbst wenn ich aus Jux mal OpenHDF bei mir draufwerfen würde, kann ich da nicht so viel sehen wie jemand, der das für den Alltag nutzt.

Ich habe auf einem solo2 se clone. das openatv versucht zu flashen. die box bootet, liefert jedoch kein bild ab. ssh zugang steht, hier kernel log. looking for help

dmesg


ps ax


lsusb && lspci:
root@vusolo2:~# lsusb && lspci
Bus 001 Device 001: ID 1d6b:0002
Bus 002 Device 001: ID 1d6b:0002
Bus 003 Device 001: ID 1d6b:0002
Bus 004 Device 001: ID 1d6b:0002
Bus 005 Device 001: ID 1d6b:0001
Bus 006 Device 001: ID 1d6b:0001
Bus 007 Device 001: ID 1d6b:0001
Bus 008 Device 001: ID 1d6b:0001
lspci: /sys/bus/pci/devices: No such file or directory

Update:
das openatv 6.0 von Lonrisun funktioniert.

@Schimmelreiter
Das OpenHDF habe ich testweise auf meine Solo2 se gespielt,läuft gut,keine Probleme.Will es jetzt noch ein wenig länger testen.
Ist zwar eine Lorinson,aber es es laufen alle Sunray-Images.

Das ist gut zu wissen. OpenHDF gibt es ja normal gar nicht für die Vu+ Solo2, also ist schon das Original ungetestet.
Das heißt aber wie man sieht nicht, daß es nicht doch funktioniert.

Gesendet von meinem Siemens C25 mit Tapatalk

derdigge schrieb:

Ich habe auf einem solo2 se clone. das openatv versucht zu flashen. die box bootet, liefert jedoch kein bild ab. ssh zugang steht, hier kernel log. looking for help

Zum Vergrößern anklicken....

derdigge schrieb:

Update:
das openatv 6.0 von Lonrisun funktioniert.

Zum Vergrößern anklicken....

Da gibt's leider nix dran zu tun: Nicht jede Lonrisun Solo² SE kann auch Sunray-Images nutzen, manche sind tatsächlich waschechte Lonrisuns und gehen dementsprechend auch nur mit Lonrisun/Dragonworth-Images.
Aber wie man sieht passiert nichts weiter als daß die Treiber nicht laden, man kann es daher immer zuerst mit einem Sunray-Image probieren.

Ich bin der Sache nicht weiter nachgegangen aber kann man die Module nicht wie in debuntu oder arch einfach on demand "hotpluggen". Denn daneben unterscheiden sich die Images ja nicht.

Somit modprobed das System Module entsprechend der vorliegenden Hardware




Gesendet von iPhone mit Tapatalk

derdigge schrieb:

Ich bin der Sache nicht weiter nachgegangen aber kann man die Module nicht wie in debuntu oder arch einfach on demand "hotpluggen". Denn daneben unterscheiden sich die Images ja nicht.
Somit modprobed das System Module entsprechend der vorliegenden Hardware

Zum Vergrößern anklicken....

Sowas in der Art habe ich in der Tat bereits überlegt, dann aber aus Zeitmangel wieder verworfen.

Es wäre in der Tat möglich, einfach Sunray-Images zu bauen, die sich selbst bedarfsweise zu Lonrisun- oder gar Dragonworth-Images herunterpatchen.

Der Aufwand ist aber etwas größer, als Du Dir das vorstellst:
Man benötigt drei verschiedene Kernel (Jeweils einen für Sunray, Lonrisun und Dragonworth), ja, drei.
Es gibt einen winzigen, aber entscheidenden Unterschied schon zwischen den Kerneln für Sunray und Lonrisun, der in der unterschiedlichen Art die Treiber zu laden begründet liegt.

Zusätzlich benötigt man - je nach Distro - auch noch zwei unterschiedliche Enigma2-Binaries, eine für Sunray und eine für Lonrisun und Dragonworth.
Sowohl Lonrisun als auch Dragonworth können kein gles (CI+ fehlt ja inzwischen in praktisch allen Images eh wieder), man muß also entweder die Enigma2-Binary durch eine ersetzen die kein gles laden möchte, ansonsten aber Solo²-konform gebaut wurde (Das mache ich), oder man müßte ein fake-vugles-Paket mit in die Images packen, das zwar keine gles-Unterstützung realisiert, aber E2 am Crashen hindert wenn E2 die Lib laden/entladen will.

Die Fake-gles-Library wäre der deutlich schönere Weg, wenn sich also jemand meldet, der Linux-Libs schreiben kann ...

Ich meine, ihr habt euch ein reduntantes rootfs auf dem flash gegönnt, warum dann nicht mehrer kernel.
Bzw. wenn man die Kernel nicht monolitisch sondern modular hält ist die Klippe mit 3 Kerneln schonmal umschifft. Einfach in der kconf die betreffenden module von y auf m. Kein Plan wie euer Buildenvironment den rest so regelt aber "it should just work".

Dann zieht sich das System während des boots die entsprechenden module. Den enigma2 start realisierts du dann mit einem if statement im init script:


Damit machste die enigma binary abhängig von den bereits geladenen Kernel modulen und schon ist die Wiese gemäht

Alternativ müsste man das im uboot_env regeln was nicht so öffentlichkeitstauglich ist. Da regenet es dann semibricked reciver bei ebay

derdigge schrieb:

Bzw. wenn man die Kernel nicht monolitisch sondern modular hält ist die Klippe mit 3 Kerneln schonmal umschifft.

Zum Vergrößern anklicken....

Es handelt sich erst einmal um zwei verschiedene Kernel-Versionen, 3.3.8 auf Dragonworth und 3.13.5 auf Sunray und Lonrisun.

Der Treiber für 3.3.8 macht ein paar kernel calls, die damals schon deprecated waren, aber erst in 3.10.x entfernt wurden.
Wenn das nicht wäre, würde der 3.3.8er Treiber auch unter 3.13.5 noch laden (Wenn man die VERMAGIC patcht).

Ich habe mal damit angefangen, die deprecated kernel calls wieder reinzupatchen (Das stört ja die neueren Treiber nicht, die sie gar nicht benutzen), aber das ist kaum über den Ansatz hinausgekommen.

derdigge schrieb:

Einfach in der kconf die betreffenden module von y auf m.
Kein Plan wie euer Buildenvironment den rest so regelt aber "it should just work".

Zum Vergrößern anklicken....

Du berücksichtigst eines nicht:
An je mehr Stellen ich den Startvorgang verändere, von desto mehr Paketen bin ich abhängig.

Der Sunray sind im Prinzip alle Updates egal, man kann die alle einspielen (Nur darf sich die Kernel-Version, also der Part "3.13.5", nicht ändern), solange die eine Treiber-Datei mit der Time-Bomb nicht ersetzt wird.
In Bezug auf die Sunray denke ich daher im Moment eher darüber nach, die Eingriffe zu reduzieren.

Bei der Lonrisun darf sich zusätzlich auch das Kernel-Image nicht ändern, denn das erhält - außer bei OpenPLi - einen Patch für die neueren "Proxy"-Treiber, aber ansonsten dürften sich auch dort alle anderen Kernel-Pakete (DVB-, WiFI-, Serial-, ... Treiber) ändern.

derdigge schrieb:

Den enigma2 start realisierts du dann mit einem if statement im init script:

Zum Vergrößern anklicken....

Viel zu aufwändig:
Wenn sich das System einmal auf einen Treiber eingestellt hat, kann die enigma2-Binary auch einfach passend gehalten werden.
Bei der Sunray passiert da auch gar nix, da ist die normale enigma2-Binary des Original-Images drauf, aber für Lonrisun und Dragonworth muß sie bei jedem Update neu ersetzt werden (Deshalb gibt es auch an manchen Tagen kein Image für Lonrisun: Dann waren die enigma2-Pakete für die Spender-Box und die Solo² nicht synchron).

Wie schon gesagt, eine fake-vugles-Library würde das eleganter lösen ... damit fiele der Grund für den Austausch nämlich weg.

zu den treibern der clones liegt kein sourcecode vor? Du hast nur statische module?