Custom Firmware Octopus Net

Sorry dass ich den alten Thread wieder aufmache. Ich habe auch eine octonet-pro SX8 und habe es jetzt geschafft, die offiziellen github sourcen zu bauen und habe ein Binärimage. Im Zuge der octonet-Compile-Odyssee (dddvb und octonet Basis-System passen nicht mehr so ganz zusammen) habe ich es geschafft, mir einen SSH-Zugang auf dem aktuellen Receiver zu öffnen. Jetzt suche ich nach Gleichgesinnten die Interesse haben, die Software mit nützlichen Erweiterungen zu verschönern. Platz ist auf dem octonet genügend vorhanden...

Quote from M-Reimer

Was ich mir als Frage natürlich umgehend in den Sinn kommt: Könnte man denn dann auch ganz auf Proprietären Code verzichten und Minisatip drauf fahren?

Im Prinzip ja, man kann minisatip auch relativ einfach in die Build-Umgebung einbauen.

Ein kurzer Check hat gezeigt dass die benötigten Device-Nodes da sind:

# ls /dev/dvb/adapter0/ 
ca0        demux0     demux4     dvr0       dvr4       frontend0  frontend4  net0       net4       ns0        ns4        nsd0 
ca1        demux1     demux5     dvr1       dvr5       frontend1  frontend5  net1       net5       ns1        ns5 
ci0        demux2     demux6     dvr2       dvr6       frontend2  frontend6  net2       net6       ns2        ns6 
ci1        demux3     demux7     dvr3       dvr7       frontend3  frontend7  net3       net7       ns3        ns7

Ich habe nur noch nicht geprüft ob alle benötigten IOCTL's unterstützt werden.

bei den caX interfaces ist es z.B. so daß die CAMS initialisiert werden, aber die komplette Dekodierung rein im FPGA abläuft und man von dem Linux-Node keinen Zugriff darauf hat

kurzes Update: minisatip sollte bis Version 1.1.71 funktionieren. Die IOCTLs sind in der octopus.net vorhanden.

minisatip hat danach auf cmake umgestellt und compilerfeatures verwendet, den der originale gcc 4.5.4 in der octonet-Umgebung nicht unterstützt. Eventuell kann man ein statisch kompiliertes binary auf armv5 Architektur einbinden.

Update: Ich habe herausgefunden, daß die minimale GCC Verison die ich für minisatip benutzen muss gcc 4.8.4 ist. Ich werde es heute abend mit einem Compilerupdate versuchen und dann die aktuelle mini-Satip-Version bauen. Nebenher habe ich die octonet-Kernel auf 3.17.8 aktualisiert (das ist die Version, die in dem octonet image 2.2.0 verwendet wird, damit kann ich kompatible kernelmodule bauen, die auch in der octonet-box geladen werden). Ich habe digital devices bereits kontaktiert ob es eine aktuellere Version gibt, die den Stand der offiziellen Firmware 2.2.0 wiederspiegelt (die octonet sourcen sind noch basierend auf der alten 1.1.x Version mit Kernel 3.17.7 und telnet Zugang).

Hallo rjkm, vielen Dank für die Info, das spart mir einiges an Aufwand!

Ich habe mir die Sourcen von octoserve genauer angesehen. Die Steuerung der Tuner läuft über IOCTLs und die Standard Interfaces, deshalb bin ich davon ausgegangen, daß zumindest das Tuning und die Steuerung über Satip laufen sollte, der Datenstrom kommt dann direkt vom FPGA über Ethernet. Bei CI habe ich schon gesehen daß es dort nur eine Initialisierung des ENxxx stack gibt und das komplette handling vom FPGA intern übernommen wird.

Hat die Octopus.net dasselbe FPGA Image wie die anderen Digital-Devices Produkte oder sind das jeweils angepasste Versionen?

Hallo rjkm,

ich habe mir mal die Mühe gemacht, die Buildprobleme in den aktuellen octonet-Sourcen zu lösen:

1) dddvb-Version von 0.9.20 auf 0.9.38 angepasst damit die patches zu der dddvb-Version passen

2) Linux Kernel von 3.17.7 auf 3.17.8 angepasst (das ist jetzt dieselbe Kernelversion wie in den 2.2.0 binaries)

3) mk, mk.patch und mk.all angepasst, damit die (edit) von octonet benötigten sourcen aus dddvb an die richtige Stelle im Sourctree kommen

4) bug beim Bauen der toolchain behoben. Die tc-patches werden jetzt korrekt beim auschecken angewendet

5)Anpassung der buildroot von 2015.02-rc2 auf 2015.02 die in den Standard-repos verfügbar ist

6) Dowloadlinks von i2c-Tools und dvb-apps angepasst. Die DVB-Apps werden jetzt in der Version 1.1.1+rev1500 auf die Version dvb-apps-3d43b280298c39a67d1d889e01e173f52c12da35.tar.gz die erwartet wird gepatcht

7) Hinweis auf zu verwendendes Build-System. Ubuntu 16.04.7 LTS. Das harmoniert sehr gut mit der erwarteten Umgebung von octonet

Patches sind angehangen. Ich kann auch einen pullrequest machen, allerdings weiss ich nicht wie digital-devices darauf reagiert. Ich möchte nicht ausgebuht werden...

-> Die Sourcen aus dddvb werden unverändert übernommen und die einzige Änderung die ich vorgenommen habe ist die Anpassung von Kernel 3.17.7->3.17.8 die keine Konflikte mit den Treibern aus dddvb hervorgerufen hat

Eine Frage bleibt allerdings noch: Ist die dddvb-Version 0.9.38 die richtige für das octonet-Image oder kann man noch eine neuere nehmen?

Als nächstes vergleiche ich mal die aktuelle 2.2.0 software mit dem was im repo verfügbar ist, ich habe die Befürchtung daß die zwei Softwarestände nicht mehr viel miteinander gemeinsam haben. (allerdings sind die fpga-Images identisch, was schonmal ein Vorteil ist)

EDIT: Verwirrende beschreibung aufgrund fortgeschrittener Stunde korrigiert

Ich ziehe mal ein Zwischenfazit meiner Analyse

1) Die Octonet is voll darauf ausgelegt, alles bis auf die Steuerung der Streams über den FPGA abzuwickeln, d.h. im Idealfall fliessen keinerlei Daten über die CPU

2) das CAM kann zwar über das Standard-Interface initialisiert werden, man hat aber keinerlei Kontrolle über PID, ECM, EMM etc. das läuft alles in Hardware und es gibt keinen IOCTL um irgendwelche CA-basierten "Zwischenprodukte" einzispeisen

3) Die CPU ist ein ARM5tej mit 64MB RAM und zumindest fragwürdiger DMA Unterstützung

4) Die Octonet hat zwar einen Gigabit-Switch der direkt vom FPGA bedient wird, es kommen aber nur 100mbit bei der ARM core an und selbst die schafft der at91 nicht auszureizen

5) Das Linux-"Standard" DVB-Subsystem ist für Hardware-Unterstützung und Transponder Filterung ausgelegt um den Datenstrom zur CPU zu reduzieren, es ist aber nicht darauf ausgelegt, dass alles komplett in Hardware läuft und keine Daten in die CPU kommen

-> Deshalb hat DD die dvbapps und auch die Tuner-Treiber ziemlich stark "verbogen"

-> Minisatip kann zwar mit hardware-Filtering umgehen und hat gute Unterstützung für die dd-Karten, ist aber für den octonet-Fall "alles in HW" nicht ausgelegt und muss stark angepasst werden

-> Minisatip hat die Eigenschaft auf jeden neuen c++ Trend sofort aufzuspringen, das macht die Nutzung von älteren, gut abgehangenen Systemen extrem schwierig. Minisatip 2.x braucht mindestens GCC 12 während die DD-Sourcen bei 4.5.4 (antik!) rumdümpeln

6) Die dddvb Sourcen die von dem octonet-System verwendet werden sind sogar mit aktuellen 6.x Kernel kompatibel, ich gehe davon aus, daß man den Kernel Treiber "octonet.ko" relativ einfach auf Kernel 6.x heben kann (der verwendet simples memmap um Register und Konfigurationen mit dem FPGA auszutauschen); die Tuner-Treiber kann man dank der guten Abstraktion in dddvb höchstwahrscheinlich sogar 1:1 verwenden.

7) Die Userland-Apps sind eine ganz andere Geschichte. In der aktuellen 2.2.0 Software gibt es neben octoserve und octoscan noch octortsp (das "minisatip-pendant") was das Streaming über den FPGA koordiniert. Das ist nicht in den octonet-Sourcen enthalten. Hier müsste man einiges an reverse-Engineering reinstecken um octortsp durch minisatip zu ersetzen

Ich überlege ob ich mir mal den Spass gönne, octonet.ko auf einen 6.x kernel zu portieren. Ich habe schon ein dts File, die Anpassungen die ich bis jetzt gesehen habe sind nicht so komplex.

Um das ganze zu testen bräüchte ich zumindest einen debug-UART damit ich den kernel und das rootfs über tftp/nfs starten kann. Dazu habe ich noch nichts gefunden. Ausserdem würde mich interessieren, ob ich die USB-Schnittstelle, die im Kernel konfiguriert ist durch anlöten eines Steckers zum Leben erwecken kann..