Oscam STAPI v5 support

[x23piracy]

Hi,

v5 support is available for oscam, so is it possible that you integrate the supported version? Direct descrambling would make a lot of sense ;)

Regards X23

[CvH]

look here, already discussed https://github.com/perexg/satip-axe/issues/5 the STAPI modules are missing at the current fw and no source are available

[x23piracy]

has anything changed here related to the latest firmware? @perexg do you have the missing sources?

[perexg]

No, the stapi kernel driver for the secure coprocessor is missing also in the updated inverto drivers.

[x23piracy]

Can we ask for it?

[perexg]

No response from Inverto - asked two times.

[perexg]

Descrambling speed for dvbcsa library on sh4 CPU used in idl4k:

# /tmp/benchdec 
* CSA decryption bench *
 benchmarking with 256 TS packets
 benchmarking with 512 TS packets
 benchmarking with 1024 TS packets
 benchmarking with 2048 TS packets
 benchmarking with 4096 TS packets
 benchmarking with 8192 TS packets
 benchmarking with 16384 TS packets
 benchmarking with 32768 TS packets
 - 65280 packets proceded, 3.8 Mbits/s

[perexg]

There might be a light for this, I received some source code which appearently can control the descrambler section in PTI CPU block.. Some thoughs:

• determine the PTI mapped addresses for STx7108 CPU
• we don't know the STAPI /dev/ syscalls/ioctls to emulate the secure device for oscam stapi5 library
• minisatip 0.5 can use network dvbapi - we can use the keys probably here using own API for PTI
• minisatip 0.5 - use standard dmxts devices (possible?) to avoid PSI tables decoding in minisatip

My problem is that I don't need to use the integrated descrambling, but if anyone can do modifications, I'll try to help. In other words - it's a low priority issue for me.

EDIT: The code I received won't help. It appears that's for older STAPI v4. We miss the secure co-processor support.

[schwa226]

You have a email contact? May I can help you with stapi v5. I have written the ioctl lib for oscam.

[x23piracy]

@schwa226 Hallo Konfetti ;)

[CvH]

@perexg I'm not sure if/how libdvbcsa is implemented or useable but I want to let you know that there is a patched libdvbcsa (propably usefull for Tvh too)

which is 2-3x faster than the original from videolan on both ARM and x86_64 platforms

More info about that https://github.com/OpenELEC/OpenELEC.tv/pull/4815, also why this is not upstream briefly summarized: official libdvbcsa is dead and nobody work on it

[perexg]

Thanks. But moving from 3.8Mbit/s to 11.3Mbit/s does not help much for satip-axe firmware. I'll do some more tests.

[glenvt18]

@perexg I'm sorry for intervening, but as you mentioned libdvbcsa I suggest you to run benchbitslice instead of benchdec. bench(enc|dec) benchmark the non-parallel implementation and are very slow. EDIT. Run it in series like that:

for i in `seq 20`; do ./benchbitslice; done

- let your CPU to boost its clock freq.

[fedecarnales]

@perexg would you be able to run the benchmark with benchbitslice? It's usually several times faster than benchdec and it's what minisatip uses for descrambling so it would give a more accurate idea of how much data can be descrambled in software.

For example I ran some tests on my PC, standard libdvbcsa with benchdec got 56.6Mbit/s, with benchbitslice got 253Mbit/s, and with the patched libdvbcsa posted above, benchbitslice got 747Mbit/s. That's 13 times faster than the standard benchdec. If we saw similar gains on the idl4k platform, it would get 50Mbit/s, which would be quite useful.

Thank you!

[perexg]

# /tmp/benchbitslice 
* DVBCSA bench *
 - Generating batch with 32 randomly sized packets
 - decrypting 4096 TS packets
 - decrypting 8192 TS packets
 - decrypting 16384 TS packets
 - decrypting 32768 TS packets
 - decrypting 65536 TS packets
 - decrypting 131072 TS packets
 - decrypting 262144 TS packets
 - 520192 packets proceded, 21.7 Mbits/s
 - encrypting 4096 TS packets
 - encrypting 8192 TS packets
 - encrypting 16384 TS packets
 - encrypting 32768 TS packets
 - encrypting 65536 TS packets
 - encrypting 131072 TS packets
 - encrypting 262144 TS packets
 - 520192 packets proceded, 20.8 Mbits/s
* Done *

[fedecarnales]

Not too shabby actually, it would be enough to decrypt one or two channels (maybe more if SD) at a time. Do you think it could be optionally supported in the next release of the firmware?

Also, is that with the official libdvbcsa code or with the patched version posted above?

[perexg]

It's version from https://github.com/glenvt18/libdvbcsa/ . But.. there are no sh4 optimizations.

[fedecarnales]

Ok, cool, so that's the best we can get for now (until the STAPI drivers are obtained). Do you have any plans to include libdvbcsa in satip-axe?

Thanks again :)

[perexg]

Something interesting, the STi7108 CPU has dual ST40 core with three ST231 coprocessors (which seems available in the used kernel):

# cat /proc/coprocessor 
Coprocessors: 3  st231
  CPU (dev)        Host addr.     Copr. addr.     Size
  -------------------------------------------------------------------
  /dev/st231-0    not allocated!
  /dev/st231-1    not allocated!
  /dev/st231-2    not allocated!

The question is the processing power available in these co-processors. Also, the second ST40 core is not used (it handles video in standard STB boxes, if I understand the purpose correctly).

ST40 tools are available at: http://ftp.stlinux.com/pub/tools/products/st40tools/ ST200 tools (for ST231) are available at: http://ftp.stlinux.com/pub/tools/products/st200tools/

Basic booting: http://www.stlinux.com/howto/multiple-CPUs/STb7100-ST231

[fedecarnales]

Very interesting. It seems there's great untapped potential in this SoC.

I looked up the Sti7108 datasheet at http://www.icpdf.com/STMICROELECTRONICS_datasheet/STI7108_pdf_7520846/

The second ST40 CPU "offloads a/v management and network protocols".

One of the ST231 is used to help the main ST40 "for multimedia processing and security/DRM in home networks". A second ST231 is used for video decoding. The third ST231 is used for audio decoding a processing.

It seems the ST231 co-processors are actually quite capable.

Do we currently have access to use the second ST40 or is it not enabled?

[catalinii]

Hi,

I am not sure if this applies here, but i have added support for local socket for oscam in minisatip in the last commit.

This enables oscam to use the STAPI (or STAPI5) api to descramble a channel in hw, however this requires latest oscam (or at least 1 year old).

For more details you can see: https://minisatip.org/forum/viewtopic.php?f=5&t=32&p=2323#p2321

The oscam from there is compiled with stapi (not stapi5)

Thanks