VDR inkompatible DVB-API (inkomp. Treiber) auf SAT>IP Telestar Digibit R1 (idl4k; SH4 basierende Boxen)

  • Hallo,


    ich habe seit 3 Tagen einen Telestar Digibit R1. Der Hersteller schreibt in den technischen Details, dass die Box auf Linux basiert, liefert aber leider keinen Source. Das Firmware-Image ist total vermurckst. Die Rechte von Directories und Files sind unmöglich gesetzt. Das mitgelieferte Busybox kann fast nichts. Dank dem User "Portisch" hier im Forum war es für mich ganz leicht das Image zu zerlegen und wieder zusammenzufügen.


    Ich habe dann mit dem Projekt "duckbox" einen Crosscompiler und Umgebung für SH4 Boxen erstellt und VDR kompiliert. Der VDR versucht ungepatcht beim Start die DVBAPI-Version des Treibers zu ermitteln, was bei dem "axe"-Treiber der Box wohl nicht implementiert ist.


    Setze ich die Version fest im Code auf 0x0500, werden die Frontends erkannt:

    Code
    1. frontend 0/0 provides DVB-S with QPSK ("idl004-sat")


    Aber der Treiber meckert dann:

    Code
    1. ASSERT( !"UNKNOWN SIGNAL STANDARD" ) line 2633 in "...e/linux/fe_fta/fe/sat/demod900.c"


    Und das Kanäle sind weiter unavailable.


    Wer hat eine Idee? Die etwas ausführlicheren Logs sind in diesem Thread:
    http://www.vdr-portal.de/index.php?page=Thread&postID=1201475#post1201475


    Viele Grüße

  • Hallo du könntest ja zur Not den weg übers sat-ip plugin nehmen (nur auf localhost)
    cu Peje

    PCs
  • Ja, aber das ist ja blöd. Im Zweifel erzeugt das auch zu viel CPU-Last. Da kann ich die Box auch so lassen und auf meinem Server den VDR mit satip-Plugin laufen lassen (was dann nämlich auch meine Lösung sein wird, wenn die Treiber echt inkompatibel sind).


    Viele Grüße

  • Ok, ich habe heute doch noch ein bisschen herum gespielt und herausbekommen, dass ich beim Schalten auf n-tv (Kanal 4) ein anderes Verhalten bekomme:

    Code
    1. Dec 31 00:01:14 satip vdr: [839] switching to channel 4
    2. Dec 31 00:01:14 satip vdr: [843] SCR 0 assigned to device 1
    3. Dec 31 00:01:15 satip vdr: [839] ERROR (dvbdevice.c,1465): Operation not permitted
    4. Dec 31 00:01:15 satip vdr: [839] ERROR: can't set PID 169 on device 1
    5. Dec 31 00:01:15 satip vdr: [839] ERROR (dvbdevice.c,1470): Resource temporarily unavailable


    Danach wird die Kiste total träge und man kann praktisch kaum noch was machen. Der vdr lässt sich nicht mehr beenden, selbst mit "-9" nicht. dmesg sagt:

    Code
    1. ASSERT( !"DTV_ROLLOFF assumed always AUTO" ) line 845 in "...ules/fe/linux/fe_fta/fe_driver.c"
    2. STPTI_SignalWaitBuffer() failure stErr 0xD0038 /kdmx_id 0, signal_handle 0x00000000/
    3. STPTI_SignalWaitBuffer() failure stErr 0xD0038 /kdmx_id 3, signal_handle 0x00000000/
    4. STPTI_SignalWaitBuffer() failure stErr 0xD0038 /kdmx_id 1, signal_handle 0x00000000/
    5. STPTI_SignalWaitBuffer() failure stErr 0xD0038 /kdmx_id 2, signal_handle 0x00000000/
    6. STPTI_SignalWaitBuffer() failure stErr 0xD0038 /kdmx_id 2, signal_handle 0x00000000/
    7. STPTI_SignalWaitBuffer() failure stErr 0xD0038 /kdmx_id 0, signal_handle 0x00000000/
    8. STPTI_SignalWaitBuffer() failure stErr 0xD0038 /kdmx_id 3, signal_handle 0x00000000/
    9. STPTI_SignalWaitBuffer() failure stErr 0xD0038 /kdmx_id 1, signal_handle 0x00000000/


    usw. Gerade noch ein top hinbekommen:


    EDIT: Das liegt vermutlich daran, dass das DVB-S ist und nicht DVB-S2, also SD und nicht HD. Dieser "Signal Standard" heißt vermutlich gleich in dem Treiber und wird deshalb generell erstmal getunet. Dann kommt aber eben das nächste Problem.


    Kann das sein?


    Viele Grüße

  • EDIT: Das liegt vermutlich daran, dass das DVB-S ist und nicht DVB-S2, also SD und nicht HD. Dieser "Signal Standard" heißt vermutlich gleich in dem Treiber und wird deshalb generell erstmal getunet. Dann kommt aber eben das nächste Problem.

    Ich denke, das liegt daran, dass DVB-API 0x0500 nur DVB-S unterstützt.

    Code
    1. frontend 0/0 provides DVB-S with QPSK ("idl004-sat")


    Merkwürdig, da scheint nach dem Tunen noch was im Hintergrund zu passieren. Keine Ahnung was diese kdmx_X sind und warum die so viel Leistung ziehen?( .


    Auf der Box war afaik auch szap drauf. Du könntest mal versuchen damit einen Kanal zu tunen.
    Falls das klappt ist es eine angepasste Version und die Quellen dafür müssen verfügbar sein.


    Ein Tip zum Titel noch:
    Pack auch die Problemstellung mit der DVB-API rein um auch die Treiberspezialisten zu erreichen.
    "VDR inkompatible DVB-API auf Telestar Digibit R1?" ... oder so ähnlich.

    Gruss
    SHF


  • Ja, da ist dvbtune und dvbsnoop schon im Original drin. Ich habe aber leider Unicable an der Box. Soweit ich das googlen konnte, gehen die Commandline Tools mit Unicable nicht...


    Ich habe gestern noch die Erkennung gepatcht:



    Dann versucht er auch DVB-S2 zu tunen, hat dann aber dieselben Probleme, wie ohne Patch auf DVB-S.


    Mehr Ideen habe ich jetzt nicht mehr, außer die gefakte DVB-API Version noch zu permutieren.


    Viele Grüße

  • Ja, da ist dvbtune und dvbsnoop schon im Original drin. Ich habe aber leider Unicable an der Box. Soweit ich das googlen konnte, gehen die Commandline Tools mit Unicable nicht...

    Das macht die Sache nicht übersichtlicher.
    Mal kurz das ganze an einen Legacy-Port umklemmen geht nicht? Selbst wenn alle Tuner am gleichen Kabel bleiben, sollte sich auf einem der Bänder was tunen lassen.


    Mehr Ideen habe ich jetzt nicht mehr, außer die gefakte DVB-API Version noch zu permutieren.

    Ich hab die Quellen zum letzten ST-Linux (2.4) runter geladen, laut denen sollte die Version 0x0501 sein.
    Ich bin jetzt leider nicht genug informiert um zu sagen, was damit gehen sollte und was nicht.
    Mit welcher VDR-Version arbeitest denn du? Evtl. lohnt der Versuch mit einer älteren 2.0.x oder sogar 1.6.x.


    Da müsste aber eigentlich mehr sein als nur die Version. Das was da in den Quellen ist sieht für mich sehr normal aus.
    Du kannst ja mal eine Liste der geladenen Kernel-Module anhängen (lsmod), ich habe irgendwie den Verdacht, dass die völlig an dem DVB-System vorbei arbeiten.
    Und die Ausgabe von "uname -a", nicht dass ich im falschen Paket schaue.


    Zwei Ideen hätte ich noch:
    Mal bei den Enigma2 Jungs schauen, ob/was die da machen.
    Die Kommunikation zwischen dem SAT>IP Dämon und DVB-Device abhören. (Da bin ich aber nicht so sicher, ob das für Menschen lesbare Informationen sind.)

    Gruss
    SHF


  • Hey,


    ja das hätte ich vielleicht erwähnen sollen. Das Image enthält nur die wirklich benötigten Kernelmodule und die haben nichts mit OpenSource-Treibern zu tun. Die Treiber (bzw. die Devices) nennen sich Axe und das Image heißt auch "Inverto Digital Labs AXE-Linux Distribution".



    Angebunden sind die über den sog. Platform-Bus, da die Box kein PCI hat. Wenn man nach den Modulen googlet, findet man NICHTS. Die VDR-Version, die ich nehme ist die neueste (2.1.6). Alleine schon deshalb, weil einige Plugins nur noch mit der neuesten VDR-Version laufen.

  • Angebunden sind die über den sog. Platform-Bus, da die Box kein PCI hat.

    Ja, der
    STi7108 hat die Transportstream Interfaces schon eingebaut.


    Das ist aber auch auf den anderen Boxen, die diese CPU nutzen nicht anders. Und da muss man ja an die Daten ran kommen, sonst würde Enigma und Co ja nicht tun.


    Bei dem Enigma2 Code von Duckbox sieht das öffnen des Devices ähnlich aus. Da wird auch FE_GET_INFO verwendet, was hier nicht geht.

    Code
    1. if (::ioctl(m_fd, FE_GET_INFO, &fe_info) < 0)
    2. {
    3. eWarning("ioctl FE_GET_INFO failed");
    4. ::close(m_fd);
    5. m_fd = -1;
    6. return -1;

    Jetzt wäre ein Blick in ein Image, auf dem Enigma2 funktioniert interessant.


    Code
    1. # lsmod
    2. Module Size Used by
    3. axe_dmxts 163216 10
    4. axe_fp 1869 2
    5. axe_fe 133820 8

    Da scheint noch was auf die Module zuzugreifen. Das passiert auch ohne SAT>IP Dämon?


    Hast du mal versucht, ob "modinfo" bei den Modulen was bringt?

    Gruss
    SHF


  • Bei dem Enigma2 Code von Duckbox sieht das öffnen des Devices ähnlich aus. Da wird auch FE_GET_INFO verwendet, was hier nicht geht.

    Interessant. Dann muss das bei den anderen embedded Systemen tatsächlich anders sein.


    Da scheint noch was auf die Module zuzugreifen. Das passiert auch ohne SAT>IP Dämon?


    Hast du mal versucht, ob "modinfo" bei den Modulen was bringt?


    Entschuldige, ich habe Dir einfach ein lsmod geschickt, da war aber das Original-Zeug am Laufen. Ohne ist es dann so:


    Code
    1. # lsmod
    2. Module Size Used by
    3. axe_dmxts 163216 0
    4. axe_dmx 141919 0
    5. axe_fp 1869 0
    6. axe_fe 133820 0
    7. axe_i2c 8161 1 axe_fe
    8. stapi_ioctl 90090 2 axe_dmxts,axe_dmx
    9. stapi_core 700654 3 axe_dmxts,axe_dmx,stapi_ioctl


    modinfo funktioniert nicht, da wirklich nur die plain modules im Images sind, kein modules.dep o.ae.:



    Viele Grüße


    Tim

  • Entschuldige, ich habe Dir einfach ein lsmod geschickt, da war aber das Original-Zeug am Laufen. Ohne ist es dann so:

    Macht nichts.
    Aber das Ergebnis hatte ich beim beenden des Dämon erwartet.


    Zu den Modulen: Die ganzen Skripte und Textdateien geben wohl auch nichts her?



    Bei Duckbox hab ich noch etwas gestöbert und die scheinen die Treiber selber zu bauen: /tdt/cvs/driver/frontends
    Das Makefile ist ganz aufschlussreich, da wird für jede Box ein anderer Treiber gebaut.


    Die Treiber für die Tuner sind vorhanden, prinzipiell müsste man die zum laufen bringen können. Ob das sehr kompliziert ist das an die Hardware anzupassen kann ich aber nicht abschätzen.
    Ich denke du solltest dich mal in dem Bereich umsehen. Einer der Experten da wird dir sicher einschätzen können, ob man bei der Box was machen kann.


    BTW.:
    Nur so aus Neugierde:
    Der STi7108 soll auch zwei SATA-Ports haben. Hasst du davon irgendwas gesehen -Software mässig meine ich.

    Gruss
    SHF


  • Hi,


    Zu den Modulen: Die ganzen Skripte und Textdateien geben wohl auch nichts her?

    Nö, also die proben halt nur die Module. Da sehe ich jetzt nichts wirklich spannendes...

    Bei Duckbox hab ich noch etwas gestöbert und die scheinen die Treiber selber zu bauen: /tdt/cvs/driver/frontends
    Das Makefile ist ganz aufschlussreich, da wird für jede Box ein anderer Treiber gebaut.


    Die Treiber für die Tuner sind vorhanden, prinzipiell müsste man die zum laufen bringen können. Ob das sehr kompliziert ist das an die Hardware anzupassen kann ich aber nicht abschätzen.
    Ich denke du solltest dich mal in dem Bereich umsehen. Einer der Experten da wird dir sicher einschätzen können, ob man bei der Box was machen kann.

    ja also was mich wundert ist ja: Wir haben ein Board STi7108. Das ist soweit üblich. Die Demodulator sind 2 Dual STV0900B, soweit auch üblich und es existieren Linux-Treiber dafür (http://linuxtv.org/wiki/index.php/STMicroelectronics_STV0900).


    Der Tuner selbst ist noch unklar, könnte aber auch sowas wie STV6110A sein.


    Aber selbst wenn der Tuner ein anderer ist, warum programmiert einer einen komplett neuen Treiber, der nur ganz rudimentäre Befehle kann?

    BTW.:
    Nur so aus Neugierde:
    Der STi7108 soll auch zwei SATA-Ports haben. Hasst du davon irgendwas gesehen -Software mässig meine ich.

    Da sehe ich gar nichts, aber es gibt ja auch keine SATA-Kernel Module...


    Viele Grüße

  • Bei dem Enigma2 Code von Duckbox sieht das öffnen des Devices ähnlich aus. Da wird auch FE_GET_INFO verwendet, was hier nicht geht.

    Moment: FE_GET_INFO funktioniert! FE_GET_PROPERTY ist nicht implementiert.


    Start vom Original-Daemon, tuning auf Das Erste HD (open(/dev/ und ioctl):



    Vielleicht kann damit ja jemand sehen, wie das funktioniert?


    Viele Grüße

  • Aber selbst wenn der Tuner ein anderer ist, warum programmiert einer einen komplett neuen Treiber, der nur ganz rudimentäre Befehle kann?

    Ich denke der Treiber wird als so eine Art Baukasten bei der StAPI mit geliefert.
    Der wird also großteils von ST selbst stammen

    Vielleicht kann damit ja jemand sehen, wie das funktioniert?

    Das schau ich mir am WE mal an.

    Gruss
    SHF


  • Was man eindeutig sieht, ist dass es sich um eine älter DVB-API handelt. Also 3.x oder evtl. sogar noch älter.
    Offiziell geht also kein DVB-S2 damit, aber es gab mal Patches, sofern ich das noch recht erinnere.


    Interessant werden da jetzt die Header frontend.h und dmx.h von den Treibern. Die aus dem Kernel-Source-Paket von STlinux sind jedenfalls gepatcht und unterstützen auch DVB-S2. Das Problem lässt sich in den Griff bekommen.
    Ich würde mich für weitere Tests beim VDR erstmal auf DVB-S und API-Version < 5 beschränken, das sollte keinen Ärger machen.


    Was das Frontend angeht sieht der Log stimmig aus, soweit ich das beurteilen kann.


    Leider sieht man meist nicht, was an Daten übertragen wird, da es sich oft nur um Referenzen auf die Daten handelt.


    Code
    1. [pid 1128] open("/dev/axe/demuxts-1", O_RDONLY <unfinished ...>
    2. [pid 1128] ioctl(47, AUDIO_PAUSE or UBI_IOCRNVOL <unfinished ...>
    3. [pid 1128] <... ioctl resumed> , 0x310fea36) = 0
    4. [pid 1128] ioctl(47, AUDIO_STOP or UBI_IOCRMVOL, 0x310fea3a) = -1 EBUSY (Device or resource busy)
    5. [pid 1128] ioctl(47, AUDIO_STOP or UBI_IOCRMVOL, 0x310fea3a) = 0
    6. [pid 1128] ioctl(47, AUDIO_STOP or UBI_IOCRMVOL, 0x310fea3a) = 0
    7. [pid 1128] ioctl(47, AUDIO_STOP or UBI_IOCRMVOL, 0x310fea3a) = 0
    8. [pid 1128] ioctl(47, AUDIO_STOP or UBI_IOCRMVOL, 0x310fea3a) = 0
    9. [pid 1128] ioctl(47, AUDIO_STOP or UBI_IOCRMVOL, 0x310fea3a) = 0

    Aber das hier passt irgendwie nicht.
    "AUDIO_STOP" und "AUDIO_PAUSE" gehören nicht zum Demuxer sondern zum DVB Audio Device.
    Was da passiert ist mir nicht ganz klar. Ob das ein mutwilliger Fehler ist oder nur durch unpassende Header hervorgerufen wird oder ob das nur ein Anzeigefehler ist.
    Im ersten Fall könnte man versuchen, das im VDR mal zu ändern.


    Ich muss jetzt raten, aber AUDIO_STOP könnte DMX_SET_PES_FILTER sein. Das müsste eigentlich passen, da pro Kanal immer so ca. 4-6 PIDs benötigt werden.
    AUDIO_PAUSE könnte DMX_SET_FILTER entsprechen, da bin ich mir aber eher unsicher.

    Gruss
    SHF


  • Freut mich das sich noch wer mit der Box Beschäftigt!


    VDR direkt daruf laufen zu lassen wäre super!


    Frage hast du Telnet ans laufen bekommen?


    Ansonsten hätte ich ein fertiges Image mit Samba, lib_usb, usbserial, ftdi_sio, pl2303.
    Auch habe ich die Busybox auf 1.22.1 ausgetauscht und einen selbständigen Telnetd Server eingebaut.
    Soweit habe ich es zumindest geschafft oscam als Server mit USB-Kartenleser darauf laufen zu lassen.


    Muss aber erst noch einen Platz für das 18MB File finden...


    Wie das ganze mit der DVB_API abläuft habe ich auch noch nicht durchblickt.
    Das s2i.bin Binary ist die eigentliche SAT>IP Anwendung.


    Was ich über die ST-API rausgefunden habe:
    Es wird die STPTI5 verwendet. Die neuen ST CPUs haben einen NDS Security Prozessor (TANGO) drauf.
    Der ganze TS Stream läuft durch die CPU und dort könnte man auch PID Filter usw setzten.


    Leider scheint aber das Modul STTKD_CORE in der stapi_core_stripped zu fehlen.
    Mit diesem Modul wäre es möglich oscam direkt per dvb_api zu betreiben.
    (Also den TS stream über die Security CPU mit den CWs laufen zu lassen)


    Hardwaremässig ist ein Kartenleser vorgesehen (ist aber nicht verbaut).
    Darum wundert es mich warum gerade dieser Teil fehlt.


    Auch wegen SATA bin ich unsicher. Die CPU hatt's drauf aber auf den Board kann ich die Stecker nicht definieren.
    Einer ist für RS232, darunter sollte der JTAG Port sein.
    Über der CPU ist noch ein 10 PIN Header wobei ich aber keine Ahnung habe wofür.


    Eigentlich sollten mehrere Leute an der Box interresse haben, denn es gibt mindestens 3 Boards von verschiedenen Herstellern die mit der gleichen Firmware laufen:
    Digibit R1
    DSI 400 GSS.box
    IDL 400s


    EDIT:
    Als Basis habe ich diese ST-Linux Version genommen:
    stlinux24-STAPI-kernel-sh4-2.6.32.42_stm24_V4.1-208


    Aber den Kernel Namen habe ich manuell auf "idl4k" angepasst, da ansonsten die Kernel Module nicht geladen wurden.

  • Hi Portisch,



    Frage hast du Telnet ans laufen bekommen?


    ja, Du musst die Busybox austauschen. Die originale im Image ist beim telnetd kaputt. Ich habe einfach diese Busybox als Binary genommen:


    http://www.busybox.net/downloads/binaries/1.21.1/busybox-sh4


    Das war das einfachste, weil ich noch keine Toolchain hatte.


    Ich habe einfach einen USB-Stick genommen mit ext3-FS. Der wird automatisch unter "/media/sda1" gemountet. Dann habe ich den Symlink für telnetd halt auf /media/sda1/busybox gelegt.



    Ansonsten hätte ich ein fertiges Image mit Samba, lib_usb, usbserial, ftdi_sio, pl2303.
    Auch habe ich die Busybox auf 1.22.1 ausgetauscht und einen selbständigen Telnetd Server eingebaut.


    Sehr cool! Wie gesagt, ich habe mich bisher nicht darum gekümmert ein vernünftiges Image zu bauen, sondern habe alles rausgelinkt.



    Soweit habe ich es zumindest geschafft oscam als Server mit USB-Kartenleser darauf laufen zu lassen.


    Muss aber erst noch einen Platz für das 18MB File finden...


    Wie gesagt, ich schlage vor einen USB-Stick zu nehmen. Da kann man dann auch einen schönen sshd hinlegen. Da /media/sda1 nicht sofort beim Booten da ist, habe ich sowas in /etc/init.d/rcSBB gebaut:


    Code
    1. ( sleep 10; /sbin/syslogd -R 192.168.1.85; /usr/sbin/crond; /sbin/sysctl -p; LD_LIBRARY_PATH=/media/sda1/lib /media/sda1/cdkroot/usr/local/sbin/dropbear; /media/sda1/bin/runvdr ) < /dev/null > /dev/null &



    Wie das ganze mit der DVB_API abläuft habe ich auch noch nicht durchblickt.
    Das s2i.bin Binary ist die eigentliche SAT>IP Anwendung.


    Genau, aber die macht auch den Setup für Ethernet etc. Ist also die eierlegende Wollmilchsau von Telestar...



    Wow, das ist klasse. Hast Du funktionierende Kernel-Module kompilieren können? Meine funktionieren nicht. Ich habe das ähnlich gemacht wie Du, aber scheinbar habe ich nicht die richtige Kernel-Config hinbekommen, sodass die Module immer Fehler verursachen...


    Kannst Du mir mal Dein ".config" geben?


    Viele Grüße


    Tim

  • Ne, für das 18MB File habe ich einen Filehoster gemeint...


    Werde das Image noch wo Uploaden!


    Die USB-Serial Module habe ich vom ST-Linux Paket kompiliert. Wobei der ftdi_sio den sh4-Mod v0.06 drinnen hat. Ansonsten kamm es immer wieder zu Problemen.


    Ich bin kein Linux-Kenner und habe mir alles irgendwie zusammen gebastelt.
    Darum auch der "wilde" Patch damit das Kernelrelease stimmt...
    Die idl4k_7108_defconfig ist die gleiche wie die originale 7108 config.


    Das mit den AXE Modules habe ich noch nicht ganz raus,
    aber ich bin mir fast sicher das eigentlich ales über die ST-API läuft (STBuffer, STPTI5,..).
    Die 7108 CPU hat 4 TS Inputs. Gesteuert wird glaube ich über die "main_axe.out".

  • Quote

    Moment: FE_GET_INFO funktioniert! FE_GET_PROPERTY ist nicht implementiert.


    DTV_UNDEFINED Currently not implemented
    DTV_BANDWIDTH_HZ setting on Terrestrial FE expected
    DTV_DISEQC_MASTER Currently not implemented
    DTV_INNER_FEC setting on non Terrestrial FE expected
    DTV_VOLTAGE not implemented
    DTV_TONE not implemented
    DTV_PILOT assumed always AUTO
    DTV_ROLLOFF assumed always AUTO
    DTV_DISEQC_SLAVE_REPLY Currently not implemented
    DTV_FE_CAPABILITY_COUNT Currently not implemented
    DTV_FE_CAPABILITY Currently not implemented
    DTV_API_VERSION not implemented
    DTV_CODE_RATE_HP setting on Terrestrial FE expected
    DTV_CODE_RATE_LP setting on Terrestrial FE expected
    DTV_GUARD_INTERVAL setting on Terrestrial FE expected
    DTV_TRANSMISSION_MODE setting on Terrestrial FE expected
    DTV_HIERARCHY setting on Terrestrial FE expected



    Das FE_SET_PROPERTY sollte aber gehen...


    Inverto hat das Demux Zeug wahrscheinlich selber gemacht um in keine Lizenzprobleme zu kommen.
    Es taucht immer wieder das fe_fta (Free To Air) auf.


    Exports des axe_fe.ko:


    Was ich zusätzlich zur s2i.bin rausgefunden habe:
    Es ist eine Beta-PVR Funktion vorbereitet. Irgendwie über Dropbox.
    Aber wo man diese Einschaltet? Im Eeprom selber?
    Ausserdem gibt es Debug-Zeugs für die Tuner:
    http://<sat-ip-server>:<port>/oqc1w7x
    http://<sat-ip-server>:<port>/uc-oqc-wsc-3456
    http://<sat-ip-server>:<port>/quad-oqc-wsc-3456
    http://<sat-ip-server>:<port>/func.js


    Die Anwendung selber greift auf diese Frontend zu:
    /dev/axe/demuxts-0 bis 3
    /dev/axe/fp-0
    /dev/axe/frontend-0

  • Hi,



    1. make ARCH=sh CROSS_COMPILE=/opt/STM/STLinux-2.4/devkit/sh4/bin/sh4-linux- idl4k_7108_defconfig


    also ich habe das rpm:


    Code
    1. ftp://ftp.stlinux.com/pub/stlinux/2.4/updates/RPMS/host/stlinux24-host-kernel-source-sh4-2.6.32.42_stm24_0208-208.noarch.rpm


    genommen und mit


    Code
    1. CC=sh4-linux-gcc make ARCH=sh CROSS_COMPILE=/root/duckbox/tdt/tdt/tufsbox/devkit/sh4/bin/sh4-linux-


    ein "make config" und "make" gemacht. Das ist vermutlich dann falsch, weil ich kein arch/sh/configs/idl4k_7108_defconfig habe.


    Kannst Du mir erklären, wie Du das Build-Environment zusammenbekommen hast und aus welchem Paket Dein Kernel kommt? Bist Du einer Anleitung gefolgt?


    Viele Grüße


    Tim