Beiträge von Portisch

    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:

    Code
    #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...

    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!

    Zu dem Thema "modifizieren":


    Ich arbeite nun schon einige Zeit daran der originalen s2i.bin App eine o-cam Schnittstelle für die Entschlüsselung zu verpassen.
    Prinzipel läuft es, aber nun stehe ich vor einer Frage ob die Entschlüsselung der TS Pakete über Software auf dieser CPU überhaupt möglich ist.


    Bis jetzt ist fertig:
    Erkenung eines Kanalwechsels und Speicherung der PMT Daten die o-cam benötigt.
    Filter für ECM setzen und Daten an o-cam schicken.
    Die fertigen cw von o-cam empfangen..


    Der nächste Schritt ist die Entschlüsselung der Pakete:


    Es wird für jeden TV Kanal die FFdecsa verwendet. Jetzt habe ich FFdecsa_test mal probiert mit PARALLEL_32_INT:

    Code
    speed=18.325104 Mbit/s 
    speed=12449.119412 pkts/s


    Das scheint mir das maximum für diese CPU zu sein.


    Das ist nicht sehr berauschend wenn man bedenkt das HD Kanäle derzeit so ca. 10-15MBit/s haben.


    Es wird die "read" Funktion per LD_PRELOAD abgefangen.
    Mein Plan ist hier die Daten (es werden je 7 TS Pakete alle 100ms von der App gelesen) zu bearbeiten.


    Laut dem Speed von dem FFdecsa_test sollte die Etnschlüsselung bei ca. 12449 Pakete/s der 7 Pakete also ca. 0,6ms dauern.


    Ist das richtig so?
    Macht eine Weiterarbeit Sinn??

    Ich bin nun eigentlich mit dem ganzen durch!


    Es geht recht einfach sich einen Stream vom Tuner zu holen. Das ganze DVB-API Demux Zeug kann man sich sparen.
    Man gibt dem axe_dmxts.ko einfach die gewünschte PID und man erhält die TS-Pakete.


    Init:


    Parameter: Standard FE_GET_INFO & FE_SET_VOLTAGE


    Frontend Thread Reset:

    Code
    28.10.2014-18:01:31 : _IO, Size: 0, 0x6F, 0x5D, FD: 46 (/dev/axe/frontend-0): axe_fe - FRONTEND_RESET: value: 0x54


    Parameter: uint8
    Solange noch ein Tuner frei ist, ist der value 0x54. Sobald alle 4 Tuner belegt sind und noch ein Kanal eingestellt werden soll ist es 0x0A.
    Hat wahrscheinlich etwas mit Reset Complete/Fast zu tun. Genaueres kann ich nicht sagen.


    Frontend Thread Start:

    Code
    28.10.2014-17:54:52 : _IOW, Size: 1, 0x6F, 0x61, FD: 46 (/dev/axe/frontend-0): axe_fe - FRONTEND_THREAD_UP 
    28.10.2014-17:54:52 : FRONTEND_THREAD_UP: Start frontend tuner thread: 2 - Horizontal/Low


    Parameter: Pointer of uint8


    Set Tuner Parameter:


    Parameter: Standard FE_SET_PROPERTY


    Öffnen und setzen einer PID beim Demuxer:

    Code
    28.10.2014-17:54:52 : fopen64() file: /dev/axe/demuxts-0, mode: rb, FD: 50 
    28.10.2014-17:54:52 : _IOW, Size: 2, 0x6F, 0x01, 0x307ba49c, FD: 50 (/dev/axe/demuxts-0): axe_dmxts - STAPI: SlotAllocate, SlotLinkToBuffer, SlotSetPid 
    28.10.2014-17:54:52 : DEMUXTS: Set Slot for PID: 0x0000


    Parameter: Pointer to uint16


    Nun könnte man mit read() schon TS Pakete abholen...

    Code
    28.10.2014-17:54:52 : read() file: /dev/axe/demuxts-0, FD: 50, buffer: 0x5cc284, read bytes: 1316, got 1316 bytes


    Parameter: Pointer to Buffer, Size 7 * 188 = 1316 Bytes.
    Es werden also immer 7 TS Pakete abgeholt.


    Entfernen von PID beim Demuxer:

    Code
    28.10.2014-17:54:52 : _IOW, Size: 2, 0x6F, 0x02, 0x307ba47c, FD: 50 (/dev/axe/demuxts-0): axe_dmxts - STAPI: SlotClearPid, SlotUnLink, SlotDeallocate 
    28.10.2014-17:54:52 : DEMUXTS: Clear Slot for PID: 0x0000


    Parameter: Pointer to uint16


    FE_EVENT:

    Code
    28.10.2014-17:54:52 : _IOR, Size: 40, 0x6F, 0x4E, FD: 46 (/dev/axe/frontend-0): axe_fe - FE_GET_EVENT 
    28.10.2014-17:54:52 : FE_GET_EVENT: Status: 0, Frequency: 0x001A2750 (1714000), inversion: 2 - INVERSION_AUTO


    Parameter: Standard FE_EVENT


    FE_READ_SIGNAL_STRENGTH:

    Code
    28.10.2014-17:54:52 : _IOR, Size: 2, 0x6F, 0x47, FD: 46 (/dev/axe/frontend-0): axe_fe - FE_READ_SIGNAL_STRENGTH 
    28.10.2014-17:54:52 : FE_READ_SIGNAL_STRENGTH: 0x46F9


    Parameter: Standard FE_READ_SIGNAL_STRENGTH


    FE_READ_SNR:

    Code
    28.10.2014-17:54:52 : _IOR, Size: 2, 0x6F, 0x48, FD: 46 (/dev/axe/frontend-0): axe_fe - FE_READ_SNR 
    28.10.2014-17:54:52 : FE_READ_SNR: 0xE784


    Parameter: Standard FE_READ_SNR


    FE_READ_BER:

    Code
    28.10.2014-17:54:52 : _IOR, Size: 4, 0x6F, 0x46, FD: 46 (/dev/axe/frontend-0): axe_fe - FE_READ_BER 
    28.10.2014-17:54:52 : FE_READ_BER: 0x0000


    Parameter: Standard FE_READ_BER


    Dann eine komplett AXE eigene Status Funktion:
    Sie wird nur benutzt um den Tunerstatus abzufragen.
    Vielleicht auch dazu um bei einem zusätzliche Kanal den Tuner zu finden der bereits auf den Transponder eingestellt ist...

    Code
    28.10.2014-17:54:52 : _IOR, Size: 56, 0x6F, 0x60, FD: 46 (/dev/axe/frontend-0): axe_fe - FRONTEND_STATUS 
    28.10.2014-17:54:52 : FRONTEND_STATUS: val0 0x00000000, val1 0x00000001 
    28.10.2014-17:54:52 : FRONTEND_STATUS: val2 0x00000001, Modulation: 9 - PSK_8 
    28.10.2014-17:54:52 : FRONTEND_STATUS: val4 0x00000000, Frequency 0x001A2750 (1714000) 
    28.10.2014-17:54:52 : FRONTEND_STATUS: val6 0xFFFFFD44 (-700), val7 0x0000ABE0 
    28.10.2014-17:54:52 : FRONTEND_STATUS: Symbolrate 22000, val9 0x00000002 
    28.10.2014-17:54:52 : FRONTEND_STATUS: Coderate: 2 - FEC_2_3, RollOff 0.35 
    28.10.2014-17:54:52 : FRONTEND_STATUS: val12 0x00000001, val13 0x00000000


    Parameter: Pointer to struct of 14 * uint32.


    Alle Werte habe ich noch nicht aufgeschlüsselt. val1 ist wahrscheinlich noch "Kanal eingestellt == 1".


    Um nun den Kanal zu schließen:
    Alle PIDs mit Clear PID abräumen.


    Dann den Demuxer schließen:

    Code
    28.10.2014-17:55:04 : close() file: /dev/axe/demuxts-0, FD: 50


    Das war's!


    Nach dem SAT>IP Timeout von 60s schickt die Anwendung noch den Tunerthread zum Schlafen und dreht die LNB Spannung ab:

    Code
    28.10.2014-17:56:04 : _IO, Size: 0, 0x6F, 0x5D, FD: 46 (/dev/axe/frontend-0): axe_fe - FRONTEND_RESET: value: 0x54 
    28.10.2014-17:56:04 : _IOW, Size: 4, 0x6F, 0x5B, FD: 46 (/dev/axe/frontend-0): axe_fe - FRONTEND_SET_STANDBY: value: 0xFFFFFFFF (-1) 
    28.10.2014-17:56:04 : _IO, Size: 0, 0x6F, 0x43, FD: 46 (/dev/axe/frontend-0): axe_fe - FE_SET_VOLTAGE 
    28.10.2014-17:56:04 : FE_SET_VOLTAGE: 2 
    28.10.2014-17:56:04 : _IO, Size: 0, 0x6F, 0x43, FD: 47 (/dev/axe/frontend-1): axe_fe - FE_SET_VOLTAGE 
    28.10.2014-17:56:04 : FE_SET_VOLTAGE: 2 
    28.10.2014-17:56:04 : _IO, Size: 0, 0x6F, 0x43, FD: 48 (/dev/axe/frontend-2): axe_fe - FE_SET_VOLTAGE 
    28.10.2014-17:56:04 : FE_SET_VOLTAGE: 2 
    28.10.2014-17:56:04 : _IO, Size: 0, 0x6F, 0x43, FD: 49 (/dev/axe/frontend-3): axe_fe - FE_SET_VOLTAGE 
    28.10.2014-17:56:04 : FE_SET_VOLTAGE: 2


    FRONTEND_SET_STANDBY: Parameter: uint32


    Nun sollte es recht einfach sein eine eigene Anwendung für die idl4k Firmware zu erstellen.
    Da es durch die AXE Treiber recht einfach ist, ist vdr fast schon overkill.
    Besser wäre wahrscheinlich eine eigene SAT>IP Anwendung.


    Ich selber werde mich eher darauf konzentrieren ein DVB-API Plugin dafür zu entwickeln.


    Anbei noch ein paar Logs mit Kanalwechsel usw.


    mfg

    Also ich bin hier schon ein ganzes Stück weiter.
    Prinzipel läuft es so ab:
    Man tuned den Kanal per axe_fe.ko.
    Dann gibt man den axe_dmxts.ko die gewünschten PIDs per add/remove.


    Der axe_dmxts.ko hat dann einen 7*188 Byte Puffer für die TS Pakete.
    Das entspricht der SAT>IP Spec.


    Das "axe_fe.ko - frontend thread up" ist einfach nur die Frontend Nummer 0 bis 3.
    Das "axe_fe.ko - fe_map_fta_to_dvbapi" ist nur eine Status Abfrage vom aktuellen Thread ob der Kanal eingestellt wurde usw.



    Jedoch finde ich nicht raus wie sich die s2i.bin nun die Daten von diesem Puffer holt.
    Jeden Fall nicht per ioctl Kommand, oder ich übersehe da was.


    Wie funktioniert das bei normaler DVB API?


    Wie holt sich vdr die TS Daten vom Treiber?
    Kann mir da jemand einen Tipp geben wo ich da im vdr Source nachsehen muss!?

    Ich habe hier mal etwas weiter geforscht!


    Und zwar habe ich einen ioctl Dumper per LD_PRELOAD bei der s2i.bin reingehängt.
    Das scheint der Ablauf beim Tunen eines Kanals zu sein:


    Es ist jetzt kein Satsignal an der Box, daher konnte der Kanal nicht eingestellt werden. Der Ablauf ist aber der selbe.
    Ich habe etwas den Speicher bei ein paar ioctl Paramter gedumped - aber was sagt das?
    Bei Driver ID 6F, Funktion 01 und 02 sind mir die Parameter klar. Einfach die gewünschte PID.


    Bei der FE_SET_PROPERTY sind die Strukturen bekannt, also kann man die Daten abbilden.
    Bei "axe_fe.ko - frontend thread up" oder "axe_fe.ko - fe_map_fta_to_dvbapi" wird es schwieriger da die Strukturen unbekannt sind.


    So kann man die Speicherdaten z.B. aufschlüsseln:

    Code
    02C43A41005CFAFFFF010000002C594F0082CAF32A0840580028CEF32A484058001626000068290000060000000000000000000000844058000700000002000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000


    Was jetzt aber uint8, uint16 oder uint32 ist kann man nur schätzen.
    ACHTUNG: die Daten müssen wegen little Endian gedreht werden:


    Der Treiber axe_dmx.ko wird von der s2i.bin gar nicht angesprochen.
    Kann wer weiterhelfen??


    Zusätzlich gibt es noch das zum Debuggen:

    Also ich habe mal die System.map vom neu erstellten idl4k-Kernel mit der /proc/kallsyms Liste des originalen Images verglichen. Da scheinen ein paar Sachen zu fehlen. Was genau jetzt dafür verandwortlich ist, dass man keinen Stream bekommt weis ich noch nicht...


    Man müsste nun Stpck für Stück schauen welches Modul im Kernel welche Symbole exportiert und dann hinzufügen. (wenn alles open source ist)



    Also eine Kernel Config von Inverto würde hier viel weiterhelfen!

    Hi,



    ich bin leider etwas Ratlos. Kernelmodule Exportieren ja Symbole. Das sind soweit ich rausgefunden habe Pointer zu der Funktion im Kernel Modul selber.


    Wie kann ich diese in meinem eigenen Programm benützen?


    Einfach das Headerfile vom Kernel Modul mit einbeziehen? Kompiliert das dann mit gcc?



    Oder wie funktioniert das mit dem importieren einer Funktion?

    Ich schaffe es nicht einen Live Stream vom Digibit mit dem selbst erstellten Image zu bekommen.


    dmesg vom "original" was einen Stream liefert:


    dmesg von dem selbsterstellten:


    Die Kommandline des Kernel ist anders, das sollte aber kein Problem sein. Es ist im Webinterface jetzt halt nicht mehr das Telestar Logo sondern das Inverto Logo.


    Was mir eher Sorgen macht ist die Ausgabe der STAPI Module:
    Printbuffer beim funktionierenden:


    Beim neuen:


    Das "TANGO SP not mapped" und das die stptiTSHAL_TSInputStfeEnable und stptiTSHAL_StfeWritePIDBase fehlen machen mir Sorgen.
    Ich habe mal im Kernel Configmenü etwas von CoProcessor gelesen, bin mir aber nicht sicher ob dass das ist.


    Ich hoffe das hier nicht noch was für den Kernel fehlt...

    Läuft ohne Probleme!


    Man kann mit der idl4k.scr und der idl4k.bin auf einem USB stick direkt von uboot flashen.
    Aber nur auf dem oberen USB Port. Der ist bei mir schon defekt, da er elektrisch nicht abgesichert ist.
    Also nur an/ abstecken wenn die Box aus ist!


    Edit:
    Es ist auch möglich die Box über die rs232 mit kermit neu zu flashen wenn mal das webinterface nicht mehr erreichbar ist.
    Uboot ist aber auf hidden eingestellt, dass müsste man erst umstellen.

    Also ich habe mich mal hingesetzt und das Image mit dem GPL Sourcen nachgebaut!


    Das geht einfacher als man glaubt.


    Ich habe z.b. das verändert:
    shadow Datei angepasst (Passwörter geändert)
    Boot Console: console=ttyAS0,115200
    USB-Serial Module
    Busybox 1.21.1 mit allen Modulen
    Autostart von einem Script wenn es beim Mounten eines USB Sticks gefunden wird (Autostart).
    Samba Aktiviert.
    ramdisk wird anders gemounted und nicht mit der Begrenzung 6MB. minidlna hängt sich sonts auf bei einer großen Anzahl von Files da der Platz ausgeht.


    Was ich noch gerne geändert haben möchte:
    Den Ordner /var und /etc in einem Ordner mounten der auch nach dem Booten bestehen bleibt.
    Kann mir dazu jemand einen Tipp geben?


    1.
    Vorbereitungen: STLinux 2.4 installieren und kompilieren (Anleitungen sind im Netz zu finden)
    Bei mir zeigt der gcc Kompiler dann auf: /opt/STM/STLinux-2.4/devkit/sh4/bin/sh4-linux-gcc


    2.
    Ordner anlegen:

    Code
    /usr/idl4k 
    /usr/idl4k/build/kernel


    3.
    Man braucht die passenenden GPL idl4k Sourcen für die passende idlk4.bin Firmware. Derzeit ist das die 1.13.0.105:
    https://github.com/jollyjinx/idl4k (thx to jollyjinx)
    Die idl4k.bin Firmware 1.13.0.105


    4.
    Es muss der CPIO Teil aus der Firmware extracted werden.
    Die idl4k.bin in den Ordner /usr/idl4k kopieren.
    Zum entpacken kann man dieses Script mit dem Parameter extract benutzen:


    Nach dem Entpacken sollte man einen weiteren Ordner haben: (usr/idl4k/initramfs)


    5.
    Nun kann nach belieben das Image verändert/erweitert werden.


    6.
    Ist die Bearbeitung abgeschlossen wieder das script mit dem Parameter repack ausführen.
    Es sollte nun ein neues CPIO Archiv in /usr/idl4k/build/kernel zu finden sein.


    7.
    Den idl4k-master in /usr/idl4k entpacken und in den Ordner /usr/idl4k/idl4k-master/linux wechseln.
    Es muss im /usr/idl4k/idl4k-master/linux/Makefile das angepasst werden:

    Code
    -fno-delete-null-pointer-checks 
    # -Wno-error=unused-but-set-variable


    Abändern in:

    Code
    -fno-delete-null-pointer-checks \ 
    -Wno-error=unused-but-set-variable


    (8.)
    Standard Config für idl4k laden:

    Code
    make ARCH=sh CROSS_COMPILE=/opt/STM/STLinux-2.4/devkit/sh4/bin/sh4-linux- O=/usr/idl4k/build/kernel idl4k_defconfig


    9.
    Den Kernel Konfigurieren:

    Code
    make ARCH=sh CROSS_COMPILE=/opt/STM/STLinux-2.4/devkit/sh4/bin/sh4-linux- O=/usr/idl4k/build/kernel menuconfig


    Z.B. kann man unter den Bootoptionen: console=ttyAS0,115200 hinzufügen.


    (10.)
    Module erstellen falls benötigt:

    Code
    make ARCH=sh CROSS_COMPILE=/opt/STM/STLinux-2.4/devkit/sh4/bin/sh4-linux- O=/usr/idl4k/build/kernel modules


    (11.)
    Den Ordner /usr/idl4k/build/kernel nach *.ko durchsuchen und gegebenenfalls diese in das initramfs einbauen.
    Es muss nach der Bearbeitung Punkt 6 ausgeführt werden.


    12.
    Image erstellen:

    Code
    make ARCH=sh CROSS_COMPILE=/opt/STM/STLinux-2.4/devkit/sh4/bin/sh4-linux- O=/usr/idl4k/build/kernel uImage


    Nun sollte man in /usr/idl4k/build/kernel/arch/sh/boot die Datei uImage.gz zu finden sein.
    Diese Datei kann nun wenn man will in "idl4k.bin" umbenannt werden und per Webinterface auf das Gerät geladen werden.
    Sie muss aber nicht unbenannt werden...


    Mod.: Bitte lange Listings mit Spoiler maskieren, das verbessert die Lesbarkeit ungemein: Richtig zitieren und URLs posten ...

    Edit:
    Config für idl4k erstellen:

    Code
    root@ubuntu:/usr/idl4k/idl4k-master/linux# make ARCH=sh CROSS_COMPILE=/opt/STM/STLinux-2.4/devkit/sh4/bin/sh4-linux- O=/usr/idl4k/build/kernel idl4k_defconfig


    Modules erstellen:

    Code
    root@ubuntu:/usr/idl4k/idl4k-master/linux# make ARCH=sh CROSS_COMPILE=/opt/STM/STLinux-2.4/devkit/sh4/bin/sh4-linux- O=/usr/idl4k/build/kernel modules


    vmlinux erstellen:

    Code
    root@ubuntu:/usr/idl4k/idl4k-master/linux# make ARCH=sh CROSS_COMPILE=/opt/STM/STLinux-2.4/devkit/sh4/bin/sh4-linux- O=/usr/idl4k/build/kernel vmlinux


    berreinigen:

    Code
    root@ubuntu:/usr/idl4k/idl4k-master/linux# make ARCH=sh CROSS_COMPILE=/opt/STM/STLinux-2.4/devkit/sh4/bin/sh4-linux- O=/usr/idl4k/build/kernel mrproper


    Im Makefile habe ich aber "-Wno-error=unused-but-set-variable" aktivieren müssen, ansonsten blieb es stehen.


    Ein Nachbau eines fertigen Images würde echt super sein. Habe z.B. Kernel Module für Serial-Card Reader die ich nachträglich und umständlich im Image eingebaut habe. So könnte man ein fertiges Image selber zusammenbauen. Beim Zerlegen/Zusammenbauen des fertigen BIN-Images ist man ja leider auf die originale CPIO Dateigröße beschränkt!