Digital Eliteboard - Das Digitale Technik Forum
Registriere dich noch heute kostenloses um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereiche, welche für Gäste verwehrt bleiben
Oscam Versuch V13/NDS
- Ersteller dirtyharry123
- Erstellt am
- oscam
- versuch
dirtyharry123
Freak
- Registriert
- 31. Juli 2012
- Beiträge
- 230
- Reaktionspunkte
- 129
- Punkte
- 103
AW: Oscam Versuch V13/NDS
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
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
AW: Oscam Versuch V13/NDS
@gompf & dirtyharry
zitat gompf:
Danke für eure Bemühungen!
kasimodo
@gompf & dirtyharry
zitat gompf:
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
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
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
AW: Oscam Versuch V13/NDS
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
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
Ist gelegentlich hier
- Registriert
- 27. August 2009
- Beiträge
- 36
- Reaktionspunkte
- 2
- Punkte
- 28
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:
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:
AW: Oscam Versuch V13/NDS
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
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
dirtyharry123
Freak
- Registriert
- 31. Juli 2012
- Beiträge
- 230
- Reaktionspunkte
- 129
- Punkte
- 103
AW: Oscam Versuch V13/NDS
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?
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
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?
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
Meister
- Registriert
- 14. November 2008
- Beiträge
- 719
- Reaktionspunkte
- 273
- Punkte
- 133
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?
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?
Zuletzt bearbeitet:
AW: Oscam Versuch V13/NDS
Hi,
wie sehen denn die Oscam Konfigurationen aus?
Grüße
Bombadil
Hi,
wie sehen denn die Oscam Konfigurationen aus?
Grüße
Bombadil
dirtyharry123
Freak
- Registriert
- 31. Juli 2012
- Beiträge
- 230
- Reaktionspunkte
- 129
- Punkte
- 103
AW: Oscam Versuch V13/NDS
Man könnte höchstens einen eigenen Treiber schreiben, was wie schon erwähnt mit viel Aufwand verbunden wäre.
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
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.
Selbst wenn das ginge, was soll das bringen?
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
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
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
Zuletzt bearbeitet:
dirtyharry123
Freak
- Registriert
- 31. Juli 2012
- Beiträge
- 230
- Reaktionspunkte
- 129
- Punkte
- 103
AW: Oscam Versuch V13/NDS
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).
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
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).
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
Ähnliche Themen
- Artikel
- Artikel
