ICAM Patch oscam-emu

[el_malto]

Genau das sind die Flags die hier im Thread getestet wurden.
@icb hatte erst die Flags "-funroll-loops -fomit-frame-pointer -fno-tree-vectorize" getestet und in den Patch hinzugefügt was schon die CPU Last bei mipsel Boxen reduziert hat und später hat @hacker1 noch das Flag "-fno-schedule-insns" hinzugefügt was nochmal für eine geringere CPU Last sorgt.

 

[Gabberhead]

kann man die gleichen auch für arm benutzen? oder müssen das andere sein?

und dann noch. um streamrelay zu benutzen, muss ja emu support mit kompiliert werden. wenn ich das aktiviere und obwohl ich das module_newcamd beim kompilieren explizit auf disabled habe, wird es immer mit gebaut. wird das newcamd module beim emu support benötigt?

 

[el_malto]

Du kannst alle Flags einfach fürs bauen von Mipsel und ARM anwenden.
Für ARM CPUs wird NEON verwendet und für Mipsel die oben genannten Flags. Bei ARM hast man ja normalerweise keine Performance Probleme. Das betrifft ja eigentlich nur die alten Mipsel CPUs.
Welche Module genau fürn EMU support benötigt werden kann ich dir nicht sagen. Aber wenn man sich den EMU Patch mal ansieht, wird in Zeile 216 das MODULE_NEWCAMD aktiviert.

+    enabled WITH_EMU && enable_opt MODULE_NEWCAMD >/dev/null

 

[Gabberhead]

wenn ich für arm baue inl neon support, bekomme ich eine fehlermeldung kurz vor dem ende. ohne neon support, läufts durch:

Spoiler

[ 92%] Building C object cscrypt/CMakeFiles/cscrypt.dir/mdc2.c.o
[ 92%] Building C object cscrypt/CMakeFiles/cscrypt.dir/mem.c.o
[ 93%] Building C object cscrypt/CMakeFiles/cscrypt.dir/rc6.c.o
[ 94%] Building C object cscrypt/CMakeFiles/cscrypt.dir/sha1.c.o
[ 94%] Building C object cscrypt/CMakeFiles/cscrypt.dir/sha256.c.o
[ 95%] Linking C static library libcscrypt.a
[ 95%] Built target cscrypt
Scanning dependencies of target ffdecsa
[ 96%] Building C object ffdecsa/CMakeFiles/ffdecsa.dir/ffdecsa.c.o
In file included from /home/gabberhead/oscam/ffdecsa/parallel_128_neon.h:21,
                 from /home/gabberhead/oscam/ffdecsa/ffdecsa.c:121:
/home/gabberhead/oscam/ffdecsa/parallel_128_neon.h: In function 'XOR_BEST_BY':
/opt/broadcom/lib/gcc/arm-unknown-linux-gnueabihf/8.3.0/include/arm_neon.h:10998:1: error: inlining failed in call to always_inline 'vst1q_u64': target specific option mismatch
 vst1q_u64 (uint64_t * __a, uint64x2_t __b)
 ^~~~~~~~~
In file included from /home/gabberhead/oscam/ffdecsa/ffdecsa.c:121:
/home/gabberhead/oscam/ffdecsa/parallel_128_neon.h:78:2: note: called from here
  vst1q_u64((uint64_t*)d, vs1);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/gabberhead/oscam/ffdecsa/parallel_128_neon.h:21,
                 from /home/gabberhead/oscam/ffdecsa/ffdecsa.c:121:
/opt/broadcom/lib/gcc/arm-unknown-linux-gnueabihf/8.3.0/include/arm_neon.h:14065:1: error: inlining failed in call to always_inline 'veorq_u64': target specific option mismatch
 veorq_u64 (uint64x2_t __a, uint64x2_t __b)
 ^~~~~~~~~
In file included from /home/gabberhead/oscam/ffdecsa/ffdecsa.c:121:
/home/gabberhead/oscam/ffdecsa/parallel_128_neon.h:77:8: note: called from here
  vs1 = veorq_u64(vs1, vs2);
        ^~~~~~~~~~~~~~~~~~~
In file included from /home/gabberhead/oscam/ffdecsa/parallel_128_neon.h:21,
                 from /home/gabberhead/oscam/ffdecsa/ffdecsa.c:121:
/opt/broadcom/lib/gcc/arm-unknown-linux-gnueabihf/8.3.0/include/arm_neon.h:10420:1: error: inlining failed in call to always_inline 'vld1q_u64': target specific option mismatch
 vld1q_u64 (const uint64_t * __a)
 ^~~~~~~~~
In file included from /home/gabberhead/oscam/ffdecsa/ffdecsa.c:121:
/home/gabberhead/oscam/ffdecsa/parallel_128_neon.h:76:19: note: called from here
  uint64x2_t vs2 = vld1q_u64((uint64_t*)s2);
                   ^~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/gabberhead/oscam/ffdecsa/parallel_128_neon.h:21,
                 from /home/gabberhead/oscam/ffdecsa/ffdecsa.c:121:
/opt/broadcom/lib/gcc/arm-unknown-linux-gnueabihf/8.3.0/include/arm_neon.h:10420:1: error: inlining failed in call to always_inline 'vld1q_u64': target specific option mismatch
 vld1q_u64 (const uint64_t * __a)
 ^~~~~~~~~
In file included from /home/gabberhead/oscam/ffdecsa/ffdecsa.c:121:
/home/gabberhead/oscam/ffdecsa/parallel_128_neon.h:75:19: note: called from here
  uint64x2_t vs1 = vld1q_u64((uint64_t*)s1);
                   ^~~~~~~~~~~~~~~~~~~~~~~~
make[2]: *** [ffdecsa/CMakeFiles/ffdecsa.dir/build.make:82: ffdecsa/CMakeFiles/ffdecsa.dir/ffdecsa.c.o] Fehler 1
make[1]: *** [CMakeFiles/Makefile2:459: ffdecsa/CMakeFiles/ffdecsa.dir/all] Fehler 2
make: *** [Makefile:171: all] Fehler 2

 

[el_malto]

Kenne mich leider zu wenig mit compilieren aus. Bin da eher ein "Anwender". Aber hier gibt es ja noch andere User die fit sind.

 

[Azo]

Hi,

@Gabberhead
meine cmake Zeiten sind leider schon lang vorbei. Deshalb habe ich das nicht getestet.
Allerdings funktioniert das mit make bis auf die Warnings gut.
Deshalb meine Empfehlung:
Fehler eingrenzen durch Bauen mit make, oder neu auschecken und patchen, usw.

Tschau

Azo

 

[Gabberhead]

neu ausgecheckt habe ich schon. aber das gleiche. mit make habe ich das nie versucht. kam mit cmake immer gut klar. darum habe ich mich nie anderweitig beschäftigt funktioniert ja auch bei mipsel ohne probleme und bei arm auch, nur bei arm halt nicht mit neon. irgendwo müsste im patch ein fehler sein, der bei cmake den abbruch verursacht

 

[oottppxx]

I have already checked out. but the same. I've never tried that with make. always got along well with cmake. That's why I've never been busy with anything else. It also works with mipsel without any problems and with arm too, only with arm not with neon. there must be an error somewhere in the patch that is causing cmake to abort

Read the error message, it's telling you what's failing:
"
/opt/broadcom/lib/gcc/arm-unknown-linux-gnueabihf/8.3.0/include/arm_neon.h:10998:1: error: inlining failed in call to always_inline 'vst1q_u64': target specific option mismatch
vst1q_u64 (uint64_t * __a, uint64x2_t __b)
"

Google for "inline" and the "target specific option mismatch" and you'll get a bunch of explanations about incompatible compiler options being passed, you can even add "neon" to the search for more specific results, eg:

Sie müssen registriert sein, um Links zu sehen.

Sie müssen registriert sein, um Links zu sehen.

or (without neon, more general explanation for other non-arm architecture)

Sie müssen registriert sein, um Links zu sehen.

Have fun tweaking the options!

 

[Azo]

Hi,

@Gabberhead
Genau da drum geht es ja.
An den patches liegt es glaube ich nicht, weil es bei mir z.B. funktioniert.
Finde heraus, wo der Fehler liegt.
neu auschecken
patchen
./config.sh zeigt Dir alle Parameter an.

Tschau

Azo

PS
Um den Thread nicht zuzumüllen, kannst Du mich auch gern per PM anschreiben.
Die Lösung dann wieder hier.

 

[ghost0815]

Um den Thread nicht zuzumüllen, kannst Du mich auch gern per PM anschreiben.
Die Lösung dann wieder hier.

Macht doch eine eigenen Thread auf,......

 

[Gabberhead]

der kompiliert jetzt durch mit module_neon. das sind jetzt die compilerflags die ich für arm benutze. sind die gleichen, nur bei arm kommt dann noch -mfpu=neon dazu. mit -mfpu=neon funktionirt das auch unter arm, wenn module:neon aktiviert ist:

SET(CMAKE_C_FLAGS "-O3 -ggdb -pipe -ffunction-sections -fdata-sections -funroll-loops -fomit-frame-pointer -fno-tree-vectorize -fno-schedule-insns -mfpu=neon")

 

[meco83]

@meco83 steht hier im Thread. Bitte SuFu nutzen. Weitere Fragen ob es die Images einbauen kannst du dir hier im Board sparen. Bitte im entsprechenden Image Board fragen.

@Gabberhead das könnte an den Compiler Parametern liegen. Such mal nach v8-opt hier im Thread. Wurde ausführlich drüber geredet und auch viele Rückmeldungen gegeben.

Hab ich find aber leider nicht , hast du ein link vllt für mich ?

 

[loka]

@RiCoSatCracK
Punkt1: vielleicht solltest Du ersteinmal an deiner Wortwahl arbeiten - schliesslich möchtest Du die Hilfe haben!
Punkt2: du musst/solltest dir natürlich eine Oscam mit Neutrino-Support basteln!
Punkt3: wenn es im NI kein "ECM-Stream"-Support gibt, haste eh verloren ... (siehe DreamOS-User!)
(NI hat wohl genau diesen Schalter in der Dev.Edition wieder rausgenommen.)
Punkt4: ja, Neutrino (und auch ...-HD) haben auf Ihren Platformen einen gewissen Reiz, aber auf E2-Platformen bleiben es "Gehversuche".

Um den Quatsch nicht einfach so stehen zu lassen:
Punkt2: Falsch: Die Ocam Binaries für E2 und Neutrino sind identisch
Punkt3: Falsch. Habe letztes Nightly probiert. Alles vorhanden was man für Icam braucht. Dvbapi/Radegast
Punkt4: Totaler Quatsch. Auf den 4K STBs laufen uneingeschränkt sowohl Neutrino als auch E2.

 

[Gabberhead]

Du kannst alle Flags einfach fürs bauen von Mipsel und ARM anwenden.
Für ARM CPUs wird NEON verwendet und für Mipsel die oben genannten Flags. Bei ARM hast man ja normalerweise keine Performance Probleme. Das betrifft ja eigentlich nur die alten Mipsel CPUs.
Welche Module genau fürn EMU support benötigt werden kann ich dir nicht sagen. Aber wenn man sich den EMU Patch mal ansieht, wird in Zeile 216 das MODULE_NEWCAMD aktiviert.

+    enabled WITH_EMU && enable_opt MODULE_NEWCAMD >/dev/null

kann evtl jemand erklären warum newcamd benötigt wird, wenn emu aktiviert ist? gibts da ein bestimmten grund?

zeile 214 und 215:
+ enabled WITH_EMU && enable_opt READER_VIACCESS >/dev/null
+ enabled WITH_EMU && enable_opt MODULE_NEWCAMD >/dev/null

warum muss auch viaccess aktiv sein?

 

[icb]

@Gabberhead Gut das du das mit dem -mfpu=neon selber gefunden hast. Hätte man beispielsweise gut im eigentlich Patch nachschauen können. Da ist es im Makefile geändert worden.

+else ifneq (,$(findstring neon,$(TARGETHELP)))
+override CFLAGS += -fexpensive-optimizations -mfpu=neon

CMake benutze ich nicht deswegen hatte ich es nicht verändert.
Dazu werde ich gleich oder morgen nochmal was posten. Das kannst dann gerne mal testen.
Bitte keine Diskussionen hier im Thread zum Emu und warum da was angeschaltet ist oder nicht. Das gehört hier echt nicht hin. Mach bitte einen neuen Thread auf.

Edit:
@Gabberhead : Kannst das hier mal bitte ausprobieren? Ich hoffe das geht. Bin mir nicht ganz sicher, ob die obere Abfrage nach ARM so funktioniert.

Spoiler

diff --git a/CMakeLists.txt b/CMakeLists.txt
index dc19535..10d864e 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -675,8 +675,12 @@ add_definitions ("-D'CS_TARGET=\"${CS_TARGET}\"'")
 #enable sse2 on x86
 if (CMAKE_SYSTEM_PROCESSOR MATCHES "(x86)|(X86)|(amd64)|(AMD64)")
     set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -msse -msse2 -msse3")
+elseif (CMAKE_SYSTEM_PROCESSOR MATCHES "(arm)|(ARM)")
+    set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -mfpu=neon")
+    set (CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} -mfpu=neon")
 endif (CMAKE_SYSTEM_PROCESSOR MATCHES "(x86)|(X86)|(amd64)|(AMD64)")
 
+
 # disable warning about unused but set variables in gcc 4.6+
 if (CMAKE_COMPILER_IS_GNUCC)
        execute_process(COMMAND ${CMAKE_C_COMPILER} -dumpversion OUTPUT_VARIABLE GCC_VERSION)
@@ -684,7 +688,7 @@ if (CMAKE_COMPILER_IS_GNUCC)
        list(GET GCC_VERSION_COMPONENTS 0 GCC_MAJOR)
        list(GET GCC_VERSION_COMPONENTS 0 GCC_MINOR)
        add_definitions ("-W -Wall ")
-       set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wall -O2")
+       set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wall -O3 -pipe -ffunction-sections -fdata-sections -funroll-loops -fomit-frame-pointer -fno-tree-vectorize -fno-schedule-insns")
        set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -O2")
        set (CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} -O0 -ggdb")
        set (CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -O0 -ggdb")