Initial release of the satip-axe firmware is available (Minisatip for Digibit R1,DSI 400, IDL400s)

Quote from vdrdream

Bei mir startete der USB-Stick auch erst als die Box die Orginal Firmware 1.17.0.120 hatte.

ich hab auch die 1.17.0.120 drauf geht leider nicht
was für ein Stick hast du denn

Habe hier zwei relativ "alte" Sticks.
Einen Verbatim mit 512 MB und einen mit 2 GB.

Hi,

die Boxen sind Stick zicken, ich hatte auch erst nach drei Versuchen einen der booten wollte, also nicht aufgeben und eine kleine Sammlung zusammensuchen

Gruß X23

Hi,

Quote from Darkstar

Hi X23,
I think the CPU has by far not enough resources to run vdr or anythink like that. And for what? As recording server you need a fast hard disk interface (the box has only USB) and any other services (streamdev etc) need a client vdr anyway. So why not use satip-plugin or vtuner/satip? I am happy with the box as it is now, even with the original firmware. I will give the satip-axe alternative firmware a try and see if some of my issues goes away. Although I expect them to be on the client side, but who knows...

Darkstar.

that's wrong the cpu is fast enough to run TVH, if xvbapi would work (no driver support) and xxcam supports pti5 i don't see any argument against that, also there is no problem to record to a nas.
I have a running TVH Version for testing purposes.

Regards X23

Stick Nr 6 hat es gebracht minisatip läuft
ich nutze SatIP DVBViewer geht das auch mit VLC
wie sieht es mit ein webinterface aus

I tried to resolve all reported issues in build 9 - https://github.com/perexg/satip-axe/tree/beta/dist . Please, report any issues before I move it to the standard master branch.

- added [url]http://boxip:8080/axe-status.txt[/url] status page (shell parseable)
    - fixed ntpd start
    - added crond start / configuration
    - added customd start (custom daemon/service/setup - script) from sysinit
    - added nano text editor
    - updated o***m to 10663
    - added update-fw script for the internal flash upgrade without an USB stick

The final build 9 is released https://github.com/perexg/satip-axe/tree/master/dist . Added /etc/sysconfig/localtime file handling and /etc/sysconfig/profile support.

@ x23
If you have a working tvh server for testing purpose I could test it on my GSSBOX.

Never the less....what could be the benefit of tvh if a tvh server on this box could only do the same as minisatip (because of its limit on cpu power or ram could never serve many clients (e.g. 3 RPI openelec tvh-clients ...).

Maybe you could give me a hint ?

If the tvh server on the box should work as a "O*cam client" and then serving other tvh based clients...then I would understand why tvh on this box comes into the game.
But this szenario (o*cam, descrambling and then tvh would streaming) really would need to much power ?
without descrambling- functionaity in place the already running minisatip server on this box could do the same like tvh would. Or am I wrong ?

kind regards
arel

Little comments (if I understand things correctly):

- the CPU can descramble six streams in hardware (functionality through stapi v5 - closed API)
- o***m support stapi up to v4 using a closed source static library (so there's a chance that v5 will be supported in future)
- the Inverto drivers use only 4 descramblers (PTI) - one per demodulator, so only one service can be descrambled from a mux (transponder)

But maybe, I'm wrong with something above and it's out of scope of my interest. But anyone other might dig to it...

@perexg
just to confirm.

..as long as there are "closed source" code dependencies we can not built a tvh (or vdr) for this box which could "handle" multiple scrambled streams (like a dvb**api based vdr or a tvheadend server on a x68 machine can do nowadays).

If we build a tvh binary "without" the closed source parts (libs etc) the hardware related benfits you have mentionend could not be used...and the box cpu will not handle such workload "in software"...

the real benefit of having tvh on the box is that you could have a 24h running standalone TV Channel RECORDING-Machine (at around 10 - 20w with load of 4 tuner !) which is amazing !

Never the less the current Firmware-V9 is already running fine here wihile vheadend (or vdr incl satip-plugin) is running on " ARM based openelec clients" (former android based tv boxes with e.g. quadcore amlogic s805, amlogic s812 now on linux/openelec ).

Speed and switching of channels is great (hd 1080i incl. deinterlacing is no problem, channelswitching around 1s). "continuity errors" on the GSSBOX are very rare...in comparison to former releases. hope that INverto will give you finally all necessary informations to solve the last (few) problems...?..

Now I can recommend the combination of this cheap satip server (Inverto, Grundig or clone) in connection with vdr or tvh....if it would run (fulli hw supported) tvh on the box it would be "perfect" streaming (and recording !!) machine for kodi/xbmc/openelec clients....

My testing will go on, if I will find critical bugs I will report to git...and here

regards

arel

http://www.streamboard.tv/wbb2/thread.ph…1107#post541107

EDIT: It seems that multiple PMTs are passed to one PTI device - it seems that hw is capable to descramble multiple services from one mux (transponder)..

Dear perex,

could you explain it a bit more in detail? I am not so familiar with all the stapi things. I understood, that in the box there is a hardware descrambler (stapi v5), but the kernel module is missing for using it, right? So even with the posted development, we can't use the hardware in the box? Or am I wrong?

Thanks

The kernel modules are there (stapi_core/stapi_ioctl). These modules offer stapi devices - including /dev/stapi/stpti5_ioctl for communication with the PTI block in CPU which also does descrambling. Then we have static libraries (without sources) for o*c*m for stapi v5 which can allow o*c*m to set the descrambling keys through /dev/stapi/stpti5_ioctl device to hardware (in o*c*m - the dvba*i module does this job). So now, it's just about to put everything together (minisatip / o*c*m with stapi v5).

Unfortunately, I got a reply from Portisch (which is also the author of these libraries) that another "part" is missing in the inverto modules:

"Actualy there is no possibility to use the hardware descrambling.
The ST sttkd_ioctl module is missing.
This modul is controlling the secure co processor."

Dear perex,

that's what I had in mind, because Portisch told me at the very beginning examining the box. Maybe, if you got past the first contact of the developers at inverto, you could ask for the module, or maybe for the sources of all the modules...

Best

Is it possible to flash a new firmware over web interface with this new firmware?
If not I have to flash the firmware over RS232 what takes ~2h.

On my R1 the upper USB port is defekt.
Be careful by using this port! It doesn't have any electrical protection.
The data lines D+ and D- are going direct into the CPU.
Touch at first the case of the device before pluging in an USB device to this port.

And yes: using the hardware secure processor isn't possible without the kernel driver.
I don't understand why they didn't include the driver in the firmware!
A internal smart card reader is prepared for assembling. So the CPU have to be usable to do hardware descrambling:
Photo R1

thx for this new firmware!

Unfortunately, the original firmware for web has a little header which I've not analyzed, so you cannot flash the .fw file through the standard firmware, but if you flash the satip-axe firmware-v9 - there is upgrade-fw script which can do next upgrades without the USB flash.

Also, note that satip-axe modifies the uboot config in this way (look to last line):

https://github.com/perexg/satip-a…ot-flash.script

The fw2-nand0 mtd partition is used (original fw uses fw1-nand0).

Is it possible to add a tuner via USB? I think about buying a box, but I would not like to give up receiving additional channels via DVB-T.

perex
only the OTA firmware have a additional 16 byte header.
The standard download idl4k.bin does not have this header and is the same like the compiled uImage.gz.

A function to upgrade a satip-axe firmware over web would be nice.
A downgrade to the orignal firmware have to be done by USB or RS232 im my case.

Additional: lighttpd would be nice.
I use the R1 as o*s*am server with usb serial adapter and lighttpd as webserver.

EDIT:
And about replacing the axe_fe.ko:
This would be a lot of work. The kernel module isn't used much for the main app.
But it used by other kernel modules.

The module include functions like this:

But it doesn't include any STAPI SDK function. So may they will share the source?

EDIT2:
I just tried to compile the satip-axe firmware:

#make -C apps/dropbear-2015.67 PROGRAMS="dropbear dbclient dropbearkey dropbearconvert scp"
wget --no-verbose -O apps/dropbear-2015.67.tar.bz2 https://matt.ucc.asn.au/dropbear/dropbear-2015.67.tar.bz2
FEHLER: Kann das Zertifikat von »matt.ucc.asn.au« nicht prüfen, ausgestellt von.....
....
Verwenden Sie »--no-check-certificate«, um zu dem Server »matt.ucc.asn.au« eine nicht gesicherte Verbindung aufzubauen.
make: *** [apps/dropbear-2015.67/configure] Error 5

EDIT3:
On the first run the files are getting downloaded (like dropbear-2015.67.tar.bz2) and than the error above occurs.
On the second run the file exists and the compiling is working, stopping at the next download...

I suspect that a similar hardware is used in the gss.mux (you can buy this box for about 1200 Euros...). This box receives encrypted channels on 4 tuner, decrypts them with a CA module and modulates the encrypted channels into a new transponder that can be distributed via an existing SAT installation. If the box really uses similiar hardware then there should be the proper kernel modules and card reader software in the firmware.