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..

Hallo rjkm ,

weisst Du, wo ich einen Debug-UART an der octonet-pro anlöten kann? Es gab auf digitaldevices wohl mal eine Anleitung, die ist aber nicht mehr zugreifbar. Ich würde ausserdem gerne die USB-Ports der Octonet-Pro nutzen (die sind im Kernel aktiviert). Weisst Du wo man da den USB-Stecker anlöten muss?

Vielen Dank!! Ich habe mir die Stecker gerade bestellt. Ich werde heute Abend einen branch auf Github aufmachen, der meine letzten Patches zum Bauen des Originalsystems enthält (die drei die ich weiter oben angehangen habe). Hoffentlich sind die Kollegen von digitaldevices nicht zu streng zu mir....

Quote from rjkm

7.0er Kernel und aktuelles buildroot hab ich jetzt auch mal probiert.

Müßte man aber erst ausgiebig testen, ob wirklich alles wie vorher läuft ...

Würdest Du das Patchset mit mir teilen? Dann müssen wir beide nicht parallel dasselbe implementieren

Ich habe jetzt Zugriff auf das u-boot:

U-Boot 2014.07-00007-g7f66efe-dirty (Feb 24 2015 - 22:02:59)

CPU: AT91SAM9G45
Crystal frequency: 12 MHz
CPU clock : 400 MHz
Master clock : 133.333 MHz
DRAM: 64 MiB
WARNING: Caches not enabled
FPGA: HW=01010002, REG=0000001b
NAND: 256 MiB
*** Warning - bad CRC, using default environment

In: serial
Out: serial
Err: serial
Net: macb0
Hit any key to stop autoboot: 0
OctoNet> printenv
baudrate=115200
bootargs=ubi.mtd=2 root=ubi0:rootfs ro rootfstype=ubifs console=ttyS0,115200
bootcmd=dcache on; run recover; run ubiboot; run fallback
bootdelay=1
ethact=macb0
ethaddr=54:84:7b:00:90:a8
fallback=nand read 72000000 100000 800000; bootm
mtdids=nand0=nand_mtd
mtdparts=mtdparts=nand_mtd:0x2000000@0x000000(boot),0xe000000@0x2000000(ubi)
nandboot=dcache on; run recover; run ubiboot; run fallback
newbit=sf probe && tftp net.bit && sf erase 10000 a0000 && sf write 72000000 10000 a0000
newbs=tftp bsn.on; nand erase 0 20000; nand write 72000000 0 20000
newsbs=sf probe && tftp bs.on && sf erase 4000 2000 && sf write 72000000 4000 2000
newsub=sf probe && tftp ub.on && sf erase b0000 80000 && sf write 72000000 b0000 80000
newub=tftp ub.on && nand erase 20000 80000 && nand write 72000000 20000 80000
recover=if gpio input 64; then nand erase 2000000 e000000; fi
stderr=serial
stdin=serial
stdout=serial
ubiboot=ubi part ubi && ubifsmount ubi:rootfs && ubifsload 72000000 /boot/uImage && bootm

Environment size: 1047/131067 bytes


rjkm : Kann ich das uboot-Environment mit saveenv gefahrlos speichern oder mache ich da was kaputt?

Thanks tmn505! I confirmed the blocks were emtpy and I could save the environment without issue.

I did a little bit of progress by migrating the 3.17.8 kernel of the octonet pro to dts format (including the interesting quirks I found in the board init. This will make the migration to newer kernels much easier.

I found some interesting facts about the hardware:

- ethernet and debug uart share a pin which makes the pinctrl driver to complain but it still works (I'll leave that for now as there is little chance to resolve this cleanly with the old kernel)

- the nand driver freaks out when it finds an oob area bigger than 64 bytes. I could resolve this by patching the nand driver

- the octonet driver which gave me headaches in the initial port was extremely easy to convert to dt, the tuners even worked out of the box (but I had to change the octonet-init file which would require adaption in dddvb packages.

All drivers work as expected (nand, usb, ethernet, octonet, rtc, buttons)

-> I will clean up the patch files and upload if someone is interested:

Bootlog with dt enabled (the ubi init failed I also get when I boot the original image via tftp. It works fine when booting from nand

EDIT: Bootlog added

I managed to start firmware 2.2.0 with the new kernel with DTS. I figured out (and I am wondering why I didnt see that before) that digitaldevices heavily modernised userspace area

- Kernel config changed, iptables is now included

- webserver moved to tftpd

.....

- new tools added which are partly available in source (e.g. ddtest) but I dont know if the files are the latest version.

I also got feedback to my inquiry about updated source code in github but the response was not so encouraging. Apparently it is not planned to update the available sources to a newer version. Mind that the original 1.8.x firmware which is available only supports 4 tuners whereas 2.2.0 supports up to 8 tuners and 12 streams. The drivers we have in sourcecode also support 8 tuners and 12 streams so its just a matter of adapting the userspace software

my next step will be to recreate the 2.2.0 linux kernel configuration and let it run with the original userspace provided in latest firmware. If this is running smooth we can step-by-step replace the proprietary ui and apps (e.g. octortsp) with an open source variant like minisatip

The cool thing I saw is that the octonet contains a managed switch which can be configured by a userspace application and a kernel driver (dsa module for marvell switches). I'd enjoy to get this running and configurable. Unfortunately I could not read the markings of the ethernet chip and the photos I took do not show the switch clearly.

rjkm : Do you know what switch chip is inside the octonet-pro series? Is it Marvell or realtek? If I could place a bet i'd say its a realtek one in SX8 and it was marvell in former versions

Kurzer Zwischenstand:

Ich habe das Buildsystem jetzt so angepasst, daß dddvb als custom module innerhalb des buildroot systems gebaut wird. Damit brauchen wir keine Kopier-Orgie mehr in dem mk.patch Skript. Die Modulheader und -abhängigkeiten werden sauber aufgelöst, das löst auch das Problem, dass die Tuner nicht an den octonet-Treiber angebunden wurden. Ausserdem kann man jetzt einfach durch config-Änderung die passende dddvb-Version auswählen, was die Einbindung neuerer Kernels erleichtert und ich kann einfach einen octonet-spezifischen Patch in dddvb einbinden (z.B. Devicetree-Support für octonet.ko)

Ich habe das System bei mir über NFS am laufen; Tuning und Sendersuche läuft. Ich habe den alten pull-request gelöscht da outdated. Die neuen Anpassungen sind hier enthalten:

https://github.com/probutus/octonet.git

Parallel dazu habe ich jetzt auch die Umstellung auf device-Tree soweit daß das System mit DTS startet und auch die Tuner funktionieren. Das schöne daran ist, daß durch device-tree in Verbindung mit dem dddvb-build die Abhängigkeiten auf den Linux Kernel minimal sind und man einfacher auf neue Kernel/buildroot-Versionen gehen kann.

Mit DT gibt es nur noch drei Abhängigkeiten die in den Linux-Kernel gepatcht werden müssen

1) Board-Fixups (Bus-Prios, Externer Clock, RTC initialisierung)

2) Fix für NAND Treiber wegen grösserer OOB-Size -> wird in neuerm Kernel nicht mehr benötigt

3) Patch für Ethernet-Treiber wegen fixed-Phy konfiguration -> kann evtl. in neuerem Treiber auch raus wenn die DTS-Phy interface stabil funktioniert

-> Die DT patches werde ich die kommenden Tage auf den o.g. Branch pushen

Findings along the way:

- in DT Kernel: rtc0 kann konfiguriert aber im userspace nicht ausgelesen werden, das Thema analysiere ich gerade. Die clock-Register habe ich schon zwischen DT und Originalkernel verglichen (sieht identisch aus), evtl. ein Bug im 3.17.8 Kernel

- Allgemein: DSA interface um den Switch zu konfigurieren funktioniert nicht (MDIO interface ist nicht konfigurierbar wegen Konflikt DBGU/MDIO). Das funktioniert auch nicht in der Original-Software. Die switch-Konfiguration wird über den FPGA via ddtest-Tool gemacht