Oscam Versuch V13/NDS

[immergut]

AW: Oscam Versuch V13/NDS

Also das mit der Parity habe ich auch ausgelotet da ich da zunaechsteinmal auch den bisher einzigen wirklichen unterschied erkennen kann (S02 sendet ganze CWs also auch den gerade nicht gewechselten mit, waerend NDS nur das zu wechselnde halbe CW sended und das andere auf NULL gesetzt ist), ich sehe da nicht wirklich was (jedenfalls nicht im Moment) aber wie gesagt da liegt bisher auch der einzige wirkliche Unterschied bei einer V13/NDS Karte und einer S02/Nagra Karte.

Es wäre mal ein Versuch wert das S02 CW nachzubauen, also das CW zusammen zu setzen (oder passiert das eh schon?) und die Parity ein/raus zurechnen.

 

[dirtyharry123]

AW: Oscam Versuch V13/NDS

Aber ja ich kann es bestaetigigen, der Freez kommt immer dann wenn das CW geschrieben wir.

Das hört sich doch schonmal garnicht so schlecht an,
zumindest lässt es Hoffen, dass man da doch was von der oscam-seite retten kann (auch wenn es nicht oscams Schuld ist).
Würde aber eigentlich auch dafür sprechen, dass die CWs nicht zu spät kommen, sonst müssten ja die Freezer eigentlich schon einsetzen bevor diese geschrieben werden.
Jetzt ist halt die Frage, warum es bei der S02 keine Probleme gibt obwohl ja die CWs identisch sind...

dirtyharry123

 

[kasi45]

AW: Oscam Versuch V13/NDS

@gompf & dirtyharry

zitat gompf:

"das mcam ganz rauszuschmeissen und eine iso smartcard zu emulieren im oscam"

Bietet sich dies dann nicht doch als langfristiges alternatives Projekt an. Wie gompf geschrieben hat zwar ein riesiger Aufwand, aber dafür zukunftsorientiert! Vielleicht gibt es dann auch den ein oder anderen Interessierten der mit am Source coden kann. Vielleicht auch mal mit dem Ziel einer kompletten Firmware, in weiten Teilen unabhängig von dem was bisher von "Matrix?" kam.

Danke für eure Bemühungen!
kasimodo

 

[gompf]

AW: Oscam Versuch V13/NDS

Ich glaube das es ganz profan eine timing Sache ist.... So wie ich das sehe gibt es kein fixes timing in der OSCAM fuer das schreiben des CWs. An zu spaet glaub ich mittlerweile auch nicht mehr, da ist was anderes. Allerdings glaub ich auch nciht mehr das das MCA selbst kein NDS kann, denn das ist dem MCA ja auf der Ebene gar nicht bekannt.

/Gompf

 

[gompf]

AW: Oscam Versuch V13/NDS

Bietet sich dies dann nicht doch als langfristiges alternatives Projekt an. Wie gompf geschrieben hat zwar ein riesiger Aufwand, aber dafür zukunftsorientiert! Vielleicht gibt es dann auch den ein oder anderen Interessierten der mit am Source coden kann. Vielleicht auch mal mit dem Ziel einer kompletten Firmware, in weiten Teilen unabhängig von dem was bisher von "Matrix?" kam.

So sieht es aus, ja, man kann ja beim seasons stuff mal ein bischen peaken. Aber Ich denke das ist trotzdem ne ganze meange Arbeit bis das geht, aber langfristig sicher der bessere weg, denn dieses mcam geht auf den Wecker. Man muesste als erstes mal den spi treiber auseinander nehmen und einen trace einbauen was da ueberhaupt passiert, dann denke ich wirds auch mit dem CAM Menu klappen.

/Gompf

 

[vortex]

AW: Oscam Versuch V13/NDS

es gibt in der dvbapi einen eintrag delay, und an manchen TV's kann man die Taktrate modifizieren. Mein technisat hat niedrig und normal... Ich konnte nicht wirklich einen Unterschied feststellen..

:JC_hmmm:

 

[gompf]

AW: Oscam Versuch V13/NDS

es gibt in der dvbapi einen eintrag delay

Der Delay Eintrag duerfte in der gegenwaerigen MCA Implementierung keinen Effekt haben, da es with die AZBOX implementiert ist, und damit den Part im OSCAM umgeht, wenn ich das richtig sehe.

/Gompf

 

[60plus]

AW: Oscam Versuch V13/NDS

@gompf,

deine Anahme kann ch bestätigen, keine Veränderungen an den Zeiten und Verhalten.

mfg
60plus

 

[dirtyharry123]

AW: Oscam Versuch V13/NDS

Ich glaube das es ganz profan eine timing Sache ist.... So wie ich das sehe gibt es kein fixes timing in der OSCAM fuer das schreiben des CWs. An zu spaet glaub ich mittlerweile auch nicht mehr, da ist was anderes. Allerdings glaub ich auch nciht mehr das das MCA selbst kein NDS kann, denn das ist dem MCA ja auf der Ebene gar nicht bekannt.

/Gompf

Dann stellt sich aber die Frage, warum es nur bei NDS und nur beim MCA auftritt, bei der dbox/dreambox-dvbapi-Implementierung gibt es meines wissens auch kein fixes timing.
Vielleicht hilft es ja was mal ein fixes delay in oscam einzubauen, bzw dafür zu sorgen, dass das delay in der oscam.dvbapi nicht ignoriert wird?

So sieht es aus, ja, man kann ja beim seasons stuff mal ein bischen peaken. Aber Ich denke das ist trotzdem ne ganze meange Arbeit bis das geht, aber langfristig sicher der bessere weg, denn dieses mcam geht auf den Wecker. Man muesste als erstes mal den spi treiber auseinander nehmen und einen trace einbauen was da ueberhaupt passiert, dann denke ich wirds auch mit dem CAM Menu klappen.

/Gompf

Da stimme ich vollkommen zu, man könnte sowohl mio als auch mcam verbannen und eine echte OSS bauen.
Ich denke es könnte erfolgsversprechend sein mal zu reversen an welchen Pins der CPU das SC-Interface hängt (SPI, UART, GPIO... etc.).
Wenn man das wüsste könnte man einen eigenen Treiber für das Interface schreiben.

Übrigens nochmal zur Info was die Kommunikation angeht:
oscam kommuniziert über die fifos (/tmp/mdvbi, /tmp/mdesc, /tmp/mflt) mit mcam.
mcam wiederum kommuniziert über procfs (/proc/mio) mit dem kernel-treiber (mio.ko)
mio.ko kommuniziert dann über das SC-Interface mit dem CAM.

Wenn man jetzt /proc/mio anzapfen könnte um die Daten bidirektional abzufangen könnte man vielleicht was draus machen,
damit würde man aber dann nur den mcam ersetzen können und nicht mio.ko

dirtyharry123

 

[2predator]

AW: Oscam Versuch V13/NDS

Könnte man die Treiber neu kompilieren? vielleicht gibt es die Möglichkeit den Xilinx zu übertakten?


EDIT: @dirtyharry123

Woher glaubst du kommen die langen Umschaltzeiten? ist das Dig zu schwach auf der Brust oder ist der Nandflash zu langsam?

 

[bombadil]

AW: Oscam Versuch V13/NDS

Hi,

wie sehen denn die Oscam Konfigurationen aus?

Grüße
Bombadil

 

[dirtyharry123]

AW: Oscam Versuch V13/NDS

Könnte man die Treiber neu kompilieren?

Ohne Quellen kann man da nix neu kompilieren.
Man könnte höchstens einen eigenen Treiber schreiben, was wie schon erwähnt mit viel Aufwand verbunden wäre.

vielleicht gibt es die Möglichkeit den Xilinx zu übertakten?

Selbst wenn das ginge, was soll das bringen?

Woher glaubst du kommen die langen Umschaltzeiten? ist das Dig zu schwach auf der Brust oder ist der Nandflash zu langsam?

Die Ursache ist (höchstwahrscheinlich) die schlecht programmierte Software des MCA, es ist allerdings schwer zu sagen welcher Teil genau, bzw ob es am Zusammenspiel zwischen den einzelnen Teilen (CAM, mio.ko, mcam) liegt.
Zu Schwach ist das MCA meiner Ansicht nach nicht, auch wenn sie ruhig 64MB RAM anstelle von 32 hätten spendieren können.
Aber eigentlich hat das MCA ja nicht viel zu tun, die ganze Ver-/Ent-schlüsselung macht ja die Karte bzw der Server.
Und mit dem NAND hat das sicher nix zu tun, spätestens mit der NG-Firmware wird sowieso so viel wie möglich im RAMFS gemacht.

dirtyharry123

 

[2predator]

AW: Oscam Versuch V13/NDS

hatte mir auch schon überlegt den XC9536XL-10-VQ44+ gegen ein XC9536XL-5-VQ44+ zu tauschen.

 

[gompf]

AW: Oscam Versuch V13/NDS

Ich gehe davon aus das die Karte ueber den SPI gemacht wird, ist fuer mich aber auch kein problem das herauszufinden. Ich denke wenn sich ein paar leute finden die mitarbeiten bin ich mit denen bereit das Projekt Kickout mcam und mio in angriff zu nehmen. Egal was hier noch weiter heraus kommt.

Im moment mache ich ein OSCAM mit dem man mit dem delayer spielen kann um das zu testen, fixe delays sind zu viel arbeit fuer trial and error.

/Gompf

 

[dirtyharry123]

AW: Oscam Versuch V13/NDS

Ich gehe davon aus das die Karte ueber den SPI gemacht wird, ist fuer mich aber auch kein problem das herauszufinden. Ich denke wenn sich ein paar leute finden die mitarbeiten bin ich mit denenbereit das projekt Kickout mcam und mio in angriff zu nehmen. Egal was hier noch wieter hereaukommt.

Das wäre eine super Sache, die ich gerne soweit es die Zeit zulässt unterstützen werde.
Ich werde mich mal die Tage ranmachen und meine alten Sourcen säubern und ins git stellen (BTW @gompf, hat der Zugriff inzwischen geklappt?).
Wir waren damals bereits in der Lage einen eigenen Kernel auf dem MCA zum laufen zu bringen, da es aber Probleme mit den proprietären Teilen gab und die Zeit gefehlt hat, hab ich das damals nicht weiter verfolgt.
Den Apex (Bootloader) konnte ich ebenfalls schon erfolgreich aus den Quellen bauen, hier hat nur das memory-layout noch nicht ganz gepasst. (Hat mir aber dennoch damals geholfen ein totgeglaubes MCA wiederzubeleben)
Wenn wir also wissen, wie das SCI angebunden ist, dann könnte man durchaus ein komplett freies System für das MCA basteln (mit Ausnahme des CAMs selbst).

Im moment mache ich ein OSCAM mit dem man mit dem delayer spielen kann um das zu testen, fixe delays sind zu viel arbeit fuer trial and error.

Ich halte es auf jeden Fall für Sinnvoll auch diesen Weg weiterzugehen, bis wir da ne brauchbabe OSS haben wird es sicherlich noch ne ganze Weile dauern,
daher schadet es wohl nicht erstmal Zweigleisig zu fahren.

dirtyharry123