Quantcast
Aktuelles
Digital Eliteboard - Das Digitale Technik Forum

Registriere dich noch heute kostenlos, 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 Bereichen, welche für Gäste verwehrt bleiben

Registriere dich noch heute kostenlos, 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 Bereichen, welche für Gäste verwehrt bleiben

Matrix Cam Air OSS Entwicklungsumgebung

Registriert
31. Juli 2012
Beiträge
230
Reaktionspunkte
129
Punkte
103
Hallo Liebe Community,

ich habe mich entschlossen meine Entwicklungsumgebung mal für die Allgemeinheit zu öffnen.
Möglicherweise können damit ja einige etwas anfangen.



Ich selbst habe mich in letzter Zeit auch mal wieder ein bisschen mit dem MCA befasst und die mio.ko etwas analysiert.
Am liebsten wäre es mir nämlich einen eigenen Treiber für das SC-Interface zu schreiben.
Hier mal die Infos die ich Sammeln konnte:

mio.ko fährt das SC-Protocoll per Bitbanging über GPIO:
Die folgenden GPIOs konnte ich zuordnen:
I/O = GPIO_GPIO11
Reset = GPIO_GPIO16
Das Timing scheint über TIMER2 zu laufen.
Das Modul sendet bei einem Reset den folgenden ATR: 3F 77 18 25 00 29 14 00 62 68 90 00 (Viaccess: )

Falls sich hier also jemand mit Bitbanging und Kernel-Modulen auskennt, es wäre super, wenn wir den mio durch was eigenes Ersetzen könnten.
Ich dachte da an etwas, was anstelle des procfs ein char-device bereitstellt.

LG

dirtyharry123
 
AW: Matrix Cam Air OSS Entwicklungsumgebung

Hallo,

habe etwas Zeit gefunden und mir die mio vorgenomenn und analysiert.
Kann Deine Analyse bestätigen:

- Datenleitung zum HW-CAM über GPIO11
- Reset zum HW-CAM über GPIO16

Für das Timing der Datenleitung ( GPIO11 ) wird der Timer2 verwendet. Baudrate der Datenleitung müßte 9600 sein.
Weitere GPIOs werden für die LED-Ansteuerung verwendet.

Gesendt wird mit einem 5 Byte Header und einer 4 Byte Checksum.
Header: -86, 18, -1, Länge ohne Header HByte, Länge ohne Header LByte

Das mio modul ist eigentlich nur die HW-Schnittstelle für das mcam. Im mcam ist die eigentliche Steuerung untergebracht.
mcam = senden der CWs, Steuern der LEDs, flashen der HW-CAM firmware, das HW-CAM menu ( OSD im Fernseher ), ...
Die Kommunikation der beiden Module ( mcam <-> mio ) wird über das procfs vorgenommen.

Hat sich schon jemand mit der mcam beschäftigt? Gibt es schon eine eigene Applikation?
Hast Du ein leeres image ohne Schnickschack. Also nur die mio, macm, oscam, ????

Ich habe auch schon daran gedacht statt des GPIO11 mit einer kleiner HW-Modifikation die serielle Schnittstelle mit all ihren Vorteilen zu verwenden.
Wir müßte dafür aber auf diese debug Funktionalität verzichten. :-(


Eine eigene mio zu schreiben ist in meinen Augen möglich, nur haben wir dann erst die halbe Miete.
Wir brauchen auch eine eigene mcam.

Ich vesuche mal das komplette Protokoll zwischen HW-CAM, MIO und MCAM zu analysieren.
 
AW: Matrix Cam Air OSS Entwicklungsumgebung

Hallo,
Das mio modul ist eigentlich nur die HW-Schnittstelle für das mcam. Im mcam ist die eigentliche Steuerung untergebracht.
mcam = senden der CWs, Steuern der LEDs, flashen der HW-CAM firmware, das HW-CAM menu ( OSD im Fernseher ), ...
Die Kommunikation der beiden Module ( mcam <-> mio ) wird über das procfs vorgenommen.
Ja so sehe ich das auch, meine Idee war allerdings den mcam komplett zu entsorgen.
Also mit dem neuen Treiber z.b ein /dev/sci Chardevice bereitstellen und dann die SC-Kommunikation direkt in Oscam machen.
Hier könnte man ja dann ein beliebiges SC-Protokoll verwenden, welches dann möglicherweise auch nicht mehr vom CAM abhängt.
Die verschiedenen Smartcard-Protokolle sind ja in Oscam bereits implementiert (allerdings von der Gegenseite).
Auf das CI-Menü könnte man auch verzichten, die Konfiguration von WLAN könnte man ähnlich wie beim Chromecast machen
oder einfach per Konfigurationsdatei auf der SD-Karte einspielen, der Rest ginge dann per Webinterface und SCP.

Hat sich schon jemand mit der mcam beschäftigt? Gibt es schon eine eigene Applikation?
Hast Du ein leeres image ohne Schnickschack. Also nur die mio, macm, oscam, ????
Wir hatten auch mit dem mcam schon mal etwas rumgespielt und unter Anderem verschiedene Menüeinträge und den versteckten sharing-client (tnet) rausgepatched und Delays verringert.
kasi45 hatte im git mal ein minimiertes rootfs angelegt (ROOTFS.min) alle weiteren Änderungen sollten über die Entwicklungsumgebung Problemlos möglich sein.

Ich habe auch schon daran gedacht statt des GPIO11 mit einer kleiner HW-Modifikation die serielle Schnittstelle mit all ihren Vorteilen zu verwenden.
Wir müßte dafür aber auf diese debug Funktionalität verzichten. :-(
Ich würde zum Einen ungern auf die Debug-Schnittstelle verzichten, zum Anderen wäre es in meinen Augen praktischer das bereits vorhandene Interface zu verwenden.
Eine Hardware-Modifikation wäre vermutlich für viele Nutzer ungünstig.

Ich vesuche mal das komplette Protokoll zwischen HW-CAM, MIO und MCAM zu analysieren.
Das wäre super, ich vermute (aufgrund des ATR) es handelt sich um irgendeine Abwandlung von Viaccess
zwischen HW-CAM und MIO/MCAM.

LG

dirtyharry123
 
AW: Matrix Cam Air OSS Entwicklungsumgebung

Hi,

auf das OSD vom HW-CAM würde ich nicht unbedingt verzichten. Finde es ein nettes "nice to have". Auch für Debugzwecke....
Würde das Menu dann aber eher über ein XML konfigurierbar machen. Aber das ist eher der zweite Schritt.

Schlage vor eine eigene mio mit OSD und LED interface zu implementieren und diese an die oscam anzubingen.
HW-CAM <=> eigene MIO <=> OSCAM
<=> OSD
<=> LED

oder die Struktur wie sie ist übernehmen:
HW-CAM <=> eigene MIO <=> eigene mcam <=> oscam ...

Oder aber die mio so lassen wie sie ist und sich das mcam vornehmen und hier ein /dev/sci interface bereitstellen. BTW: ich glaube das /dev/sci gibt es schon....
HW-CAM <=> alte mio.ko <=> eigene mcam <=> oscam ...

Bin noch unschlüssig ....

Das Protokoll zwischen HW-CAM und Mio ist in meinen Augen kein Viaccess. Der ATR wird nur für die Initialisierung zwischen HW-CAM und mio verwendet.
Ging wohl so am einfachsten. Die Kommandos zwischen mcam/mio und HW-CAM sind eigene. Die reine SC-Kommunikation ( CWs etc ) geht über das CMD 0x74
im Klartext. Also: 5 byte header 0x74 plus sub cmd CWs und zum Schluß 4 Byte checksumme.

BTW. Weißt Du wofür die mega_io.ko und das /usr/bin/caid verwendet wird. Ist das nur für Debugzwecke drin?
 
AW: Matrix Cam Air OSS Entwicklungsumgebung

Thread ist nun angepinnt. Danke an dirtyharry123 fürs veröffentlichen.
 
AW: Matrix Cam Air OSS Entwicklungsumgebung

Link ist nicht mehr aktiv. Please check your GitHub
 
Zuletzt bearbeitet:
AW: Matrix Cam Air OSS Entwicklungsumgebung

Link ist nicht mehr aktiv.

Here I attached script you asked me, I made the preservation of the user and also the change of ownership of the files to the root, yet still gives me problems.

First with my user
Code:
unbas@WaRMaChiNe:~/Programacion/mca$ ls -lha INITRAMFS/initramfs/
total 80K
drwx------ 16 unbas unbas 4,0K ene  1  1970 .
drwx------  3 unbas unbas 4,0K nov 11 21:52 ..
drwx------  2 unbas unbas 4,0K ene  1  1970 bin
drwx------  6 unbas unbas 4,0K ene  1  1970 dev
drwx------  4 unbas unbas 4,0K ene  1  1970 etc
drwx------  2 unbas unbas 4,0K ene  1  1970 include
-rwxr-xr-x  1 unbas unbas 8,1K ene  1  1970 init
drwx------  3 unbas unbas 4,0K ene  1  1970 lib
lrwxrwxrwx  1 unbas unbas   11 ene  1  1970 linuxrc -> bin/busybox
drwxrwxr-x  2 unbas unbas 4,0K ene  1  1970 man
-rwxr-xr-x  1 unbas unbas 1,4K nov 22 08:43 mca_default.ini
drwxrwxr-x  2 unbas unbas 4,0K ene  1  1970 mnt
drwxrwxr-x  2 unbas unbas 4,0K ene  1  1970 newroot
drwxrwxr-x  2 unbas unbas 4,0K ene  1  1970 proc
drwx------  2 unbas unbas 4,0K ene  1  1970 sbin
drwxrwxr-x  2 unbas unbas 4,0K ene  1  1970 sys
drwxrwxr-x  2 unbas unbas 4,0K ene  1  1970 tmp
drwx------  7 unbas unbas 4,0K ene  1  1970 usr
drwxrwxr-x  2 unbas unbas 4,0K ene  1  1970 var
  ##############################################################################
##############################################################################
  unbas@WaRMaChiNe:~/Programacion/mca$  ls -lha INITRAMFS/initramfs/dev/
total 24K
drwx------  6 unbas unbas 4,0K ene  1  1970 .
drwx------ 16 unbas unbas 4,0K ene  1  1970 ..
crw-------  1 root  root  5, 1 ene  1  1970 console
drwxrwxr-x  2 unbas unbas 4,0K ene  1  1970 input
lrwxrwxrwx  1 unbas unbas   12 ene  1  1970 log -> /var/tmp/log
lrwxrwxrwx  1 unbas unbas   12 ene  1  1970 mtab -> /proc/mounts
drwxrwxr-x  2 unbas unbas 4,0K ene  1  1970 net
crw-rw-rw-  1 root  root  1, 3 ene  1  1970 null
drwxrwxr-x  2 unbas unbas 4,0K ene  1  1970 pts
drwxrwxr-x  2 unbas unbas 4,0K ene  1  1970 shm

Changed for root onwer
Code:
root@WaRMaChiNe:/home/unbas/Programacion/mca-master# ls -lha INITRAMFS/initramfs/
total 80K
drwx------ 16 root root 4,0K ene  1  1970 .
drwx------  3 root root 4,0K nov 23 12:01 ..
drwx------  2 root root 4,0K ene  1  1970 bin
drwx------  6 root root 4,0K ene  1  1970 dev
drwx------  4 root root 4,0K ene  1  1970 etc
drwx------  2 root root 4,0K ene  1  1970 include
-rwxr-xr-x  1 root root 8,1K ene  1  1970 init
drwx------  3 root root 4,0K ene  1  1970 lib
lrwxrwxrwx  1 root root   11 ene  1  1970 linuxrc -> bin/busybox
drwxr-xr-x  2 root root 4,0K ene  1  1970 man
-rwxr-xr-x  1 root root 1,4K ene  1  1970 mca_default.ini
drwxr-xr-x  2 root root 4,0K ene  1  1970 mnt
drwxr-xr-x  2 root root 4,0K ene  1  1970 newroot
drwxr-xr-x  2 root root 4,0K ene  1  1970 proc
drwx------  2 root root 4,0K ene  1  1970 sbin
drwxr-xr-x  2 root root 4,0K ene  1  1970 sys
drwxr-xr-x  2 root root 4,0K ene  1  1970 tmp
drwx------  7 root root 4,0K ene  1  1970 usr
drwxr-xr-x  2 root root 4,0K ene  1  1970 var
root@WaRMaChiNe:/home/unbas/Programacion/mca-master# 
  root@WaRMaChiNe:/home/unbas/Programacion/mca-master#  ls -lha INITRAMFS/initramfs/dev/
total 24K
drwx------  6 root root 4,0K ene  1  1970 .
drwx------ 16 root root 4,0K ene  1  1970 ..
crw-------  1 root root 5, 1 ene  1  1970 console
drwxr-xr-x  2 root root 4,0K ene  1  1970 input
lrwxrwxrwx  1 root root   12 ene  1  1970 log -> /var/tmp/log
lrwxrwxrwx  1 root root   12 ene  1  1970 mtab -> /proc/mounts
drwxr-xr-x  2 root root 4,0K ene  1  1970 net
crw-rw-rw-  1 root root 1, 3 ene  1  1970 null
drwxr-xr-x  2 root root 4,0K ene  1  1970 pts
drwxr-xr-x  2 root root 4,0K ene  1  1970 shm
root@WaRMaChiNe:/home/unbas/Programacion/mca-master#

But there are more problems if a co svn also try a fault

Code:
A    mca/trunk/ORIG_339/ROOTFS/var/www/infocam/bin
svn: E155000: Failed to add directory '/home/unbas/Programacion/mca/trunk/ORIG_339/ROOTFS/var/www/infocam/bin/.svn': object of the same name as the administrative directory

Really the directory is not repeated nor there, I tried to delete the temporary files from my home / svn delete the previous downloads of mca, try on another system, but always this error is repeated in the svn.

If I download mca-master.zip I have to change the onwer correct?

I think not, but no longer occurs it can be, it is necessary to use binaries eldk to generate the img?
 
Zuletzt bearbeitet:
AW: Matrix Cam Air OSS Entwicklungsumgebung

The Initramfs looks fine so far.
What are you trying with SVN? The repository uses GIT, try checking it out using
Code:
git clone https://github.com/dirtyharry123/mca.git
Also the directory ORIG_339 isn't used during the build-process,
it merely contains the content of the original 339 Firmware NG is based on.

You said when you flashed the image it stayed in "Initializing System..." did the LEDs show anything?
Do you have a serial console attached by any chance?

dirtyharry123
 
AW: Matrix Cam Air OSS Entwicklungsumgebung

After flashing, it always keeps the static blue LED. Sometimes no LED shines, I have done many tests, which have different results, but the last are always blue LED still

I think some rs232 have, I'll try to git and get the results.

The 339 directory understand that is the original and unmodified, the only amending is the rootfs which is containing the changes, right?

I do not understand, is the fault, not genre changes affecting the system, I'm just adding a motd in /etc/ saying hello to start ssh

I do it by way of being established, it is the only difference.
 
Zuletzt bearbeitet:
AW: Matrix Cam Air OSS Entwicklungsumgebung

Gibt es schon was neues? :) Habe hier noch das Cam rumzuliegen, konnte es ja nie einsetzen wegen den Rucklern in Verbindung mit einer V13. Würde mich freuen, wenn man das Cam doch noch mal verwenden könnte.

MfG
 
AW: Matrix Cam Air OSS Entwicklungsumgebung

¿Puedes decirme situación del puerto UART en MCA?
 
AW: Matrix Cam Air OSS Entwicklungsumgebung

unbas schrieb:
the only amending is the rootfs which is containing the changes, right?
Mostly, as the name states this is the rootfs. Changes to the kernel and initramfs are done at different locations.

unbas schrieb:
I do not understand, is the fault, not genre changes affecting the system, I'm just adding a motd in /etc/ saying hello to start ssh
What happens when you try creating and flashing an unmodified Image?
What happens when you flash the original MCA-NG-0.2?

unbas schrieb:
¿Puedes decirme situación del puerto UART en MCA?
Check this post:
https://www.digital-eliteboard.com/...-firmware-mca_ng-0-1-339-a-6.html#post1579625
 
AW: Matrix Cam Air OSS Entwicklungsumgebung

Hi @Link ist nicht mehr aktiv.

I leave a to the log you asked me.

I think the fail is in this point:
Code:
BOOT ON MASTER
Empty flash at 0x006b3324 ends at 0x006bfffc
Init: /sbin/init
Move /mnt/sd to /newroot/mnt/sd
Move /var to /newroot/var
Move /sys to /newroot/sys
mount: mounting /sys on /newroot/sys failed: No such file or directory
Move /dev to /newroot/dev
Move /proc to /newroot/proc
Insert mio driver module ... hook:hook:64 hooked schedule_timeout

Starting IO

111 c0dd99a0 OK

222 00000000 OK

Starting IO OK

but in your firmware is:
Code:
BOOT ON MASTER 
Empty flash at 0x006b12c8 ends at 0x006bfffc 
Init: /sbin/init 
Move /mnt/sd to /newroot/mnt/sd 
Move /var to /newroot/var 
Move /sys to /newroot/sys 
Move /dev to /newroot/dev 
Move /proc to /newroot/proc 
Insert mio driver module ... hook:hook:64 hooked schedule_timeout 
 
Starting IO 
 
111 c142c9a0 OK 
 
222 00000000 OK 
 
Starting IO OK

you see in my .img /sys have problems for mount
 
Zuletzt bearbeitet:
I'll reassemble the image, creating just a motd to generate a difference between your firmware and this test.

I think if you've got the / sys / should not cause problems.

Git update my back and I'll tell you in a while.

Thanks for all. By the way, you could empty your private, I would like to talk to you about some things private.

OUHHHHHHHHHHHHHH YEEEEEEEEEEEEEEAAAAAAAAA

This version is OK, MCA Update and Run OK.

I Prepare the updates oscam and other functionalities, but before publication, I would like to talk to you privately in

attachment.php
Nappy08

User hat die Bearbeiten-Taste nicht genutzt.
 
Zuletzt bearbeitet von einem Moderator:
Zurück
Oben