[Prototyp] Ausgabeplugin für Amlogic SoC (z.B. Wetek Play)

    Zitat von P3F

    Übrigens die Bereitstellung von der Größe des Framebuffers wird in der U-Bootdatei (DTD) gemacht.

    Ich habe den Device Tree von hier genommen.


    Zitat von P3F

    P.S: Danke reufer für das Ausgabeplugin, wir gehen heute noch tiefer an die Tests mit der MLD 5.0.0 aber das sieht alles sehr viel versprechend aus.

    Gut dass ihr das Plugin in die MLD integrieren könnt! Für viel mehr ist es momentan aber wirklich noch nicht gemacht - momentan bastle ich am A/V-Sync rum, mangels Dokumentation beschränkt sich das leider auf abschreiben und ausprobieren. Für SD klappt das aber schon ganz gut, Pro Sieben SD lief über Nacht jedenfalls durch und blieb synchron. Auch gegenüber dem Raspberry Pi, welches parallel im Dauertest läuft.


    Gruss
    Thomas

    Zitat von P3F

    wir hatten gestern ein gleiches Problem und ziemlich lange gesucht. Bei uns lag es daran das der Framebuffer (/dev/fb1) nicht groß genug war. Kannst Du bitte mal schauen, was die Ausgabe vom

    Code
    fbset --info --verbose --show -fb /dev/fb0


    und

    Code
    fbset --info --verbose --show -fb /dev/fb1


    ausgeben?


    Nachdem wir jedem Framebuffer 16MB spendierten, hatten wir auch ein Bild und das OSD in der MLD 5.0.0 (WeTek).


    Hier mal meine Ergebnisse.
    Gibt es eine Möglichkeit den Speicher mit fbset zu erhöhen?


    Edit: Zur Info: Es gab noch ein Fehler beim bauen des Plugins! Nachdem ich im Plugin Verzeichnis das po Verzeichnis angelegt hatte, konnte ich das Plugin bauen.


    Edit2: Habe mir jetzt u-boot neu gebaut nach der Anleitung hier: http://odroid.com/dokuwiki/doku.php?id=en:c1_building_u-boot
    Leider weiß ich nicht, wo ich hier die größe des fb0 sowie fb1 konfigurieren kann!? :(
    Hat jemand eine Idee?


    Edit3: habe hier was anderes gefunden. http://www.cnx-software.com/20…-board-has-been-released/
    Mal schauen, ob dies funktioniert.....

    3 Mal editiert, zuletzt von Uwe ()

    Kann mir jemand bitte kurz erklären, wie ich z.B. ein Gentoo auf die SD Karte bekommen? Ich habe mich bisher an Ubuntu von der Wetek Webseite versucht, und den Enigma-Kernel compiliert und installiert. Der lädt aber lediglich ein busybox-Minimalsystem.
    Das Ubuntu selbst hat erst einmal keine HDMI-Ausgabe, obwohl die 2 Framebuffer-Devices vorhanden sind...
    Auch mit dem amlogic kernel von codesnake steht im login nur welcome to Buildroot und ich komme nur in ein Minimalsystem.
    Ich bin für einen kurzen Tipp dankbar...


    Danke und Gruß,
    beta

    P3f - so sieht's bei mir aus:





    Der /dev/fb0 hat doch 16M?!? Wo in der wetek_play.dtd stellt man das ein?


    reufer - ich habe die Änderungen von wetek-enigma in meine wetek_play.dtd übernommen. Nach Start des neuen boot.img ist aber keine Änderung, VDR & Plugin kacheln immernoch ab.


    beta & Uwe - der Trick besteht darin die *.dtd so anzupassen, dass die root partition vom kernel gemountet wird - siehe link von reufer.


    Gruß, ollo



    Zitat von ollo

    Der /dev/fb0 hat doch 16M?!? Wo in der wetek_play.dtd stellt man das ein?


    reufer - ich habe die Änderungen von wetek-enigma in meine wetek_play.dtd übernommen. Nach Start des neuen boot.img ist aber keine Änderung, VDR & Plugin kacheln immernoch ab.

    Gemäss Patch als Kernel-Parameter - was meint denn bei dir /proc/cmdline dazu?


    Offenbar pappt da aber noch jemand zusätzliche Argumente dran, bei mir schaut's so aus:

    Code
    localhost amlhddevice # cat /proc/cmdlineroot=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait console=ttyS0,115200n8 logo=osd0,0x87100000,720p,full hdmimode=720p cvbsmode=576cvbs vmalloc=256m mem=1024m a9_clk_max=1200000000 vdachwswitch=component hdmitx= mac=e8:18:63:50:1a:4a vmalloc=300M init=/sbin/init root=/dev/nfs rw nfsroot=192.168.3.1:/mnt/wetekplay,v3 ip=192.168.3.2:192.168.3.1:192.168.3.1:255.255.255.0::eth0 BOOT_IMAGE=kernel.img console=tty0 consoleblank=0 scaling_governor=hotplug scaling_min_freq=200000 scaling_max_freq=1512000


    Das System bootet aber trotzdem per NFS, scheint also die voranstehenden Parameter zu ignorieren.


    Gruss
    Thomas

    reufer:
    Kannst Du mir bitte kurz sagen, wie Du das Gentoo für die Wetek installiert hast?
    Wenn ich alles so baue, wie von ollo beschrieben hängt mein Kernel hier:



    [ 6.694643@0] input: cec_input as /devices/virtual/input/input5
    [ 6.700711@0] hdmitx: cec: hdmitx_device->cec_init_ready:0x1
    [ 6.705761H[ 6.724265@0] Changing uart_ao_ttyS0: baud from 0 to 115200
    [ 6.744496@0] Freeing unused kernel memory: 208K (c0749000 - c077d000)
    mount: mounting tmpfs on /dev/shm failed: No such file or directory
    Starting logging: OK
    Initializing random number generator... done.
    Starting network...
    ip: RTNETLINK answers: File exists
    / #


    Gruß,
    beta

    Zitat von beta

    Kannst Du mir bitte kurz sagen, wie Du das Gentoo für die Wetek installiert hast?

    Ich habe mir das passende stage3-Archiv geholt und auf meinen Rechner kopiert. Die Wetek lädt das root-FS via NFS, so konnte ich neue Pakete entweder direkt am Host cross-emergen oder auf der Wetek mit distcc kompilieren. Ein Leitfaden für das Raspberry Pi findest du hier , das Prinzip ist das selbe.


    Gruss
    Thomas

    Vielen Dank, Thomas. Bleibt die Frage, woher ich die "Firmware" für die Wetek bekomme. Reicht hier ein selbst compiliertes boot.img, oder muss ich mir das z.B. aus openelec rausnehmen, oder nimmst Du das von Amlogic?


    Danke und Gruß,
    beta

    beta - ja, selber bauen! Das boot.img ist ja ein nur ein zusammengepackter blob aus kernel (uImage), initrd und device tree (.dtb). Im .dtb stecken die Parameter um root zu mounten und den init Prozess zu starten.


    reufer - meine cmdline sieht so aus - siehe unten - ich erkenne da keine fundamentalen Unterschiede?!? Oder sollte es tatsächlich am "vdachwswitch" liegen??



    Code
    root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait console=ttyS0,115200n8 logo=osd0,0x87100000,720p,full hdmimode=720p cvbsmode=576cvbs vmalloc=256m mem=1024m a9_clk_max=1200000000 vdachwswitch=cvbs hdmitx= mac=e8:18:63:50:23:ce



    P3f - was habt ihr für MLD unternommen um ein Bild zu bekommen?


    Gruß, ollo

    ollo, reufer: OK, das Problem ist erst einmal gelöst. Man sollte im mkbootimg schon das richtige initrd.img angeben und schon bootet die Wetek auch meinen Kernel ;)


    ollo: Bevor ich Dir mit dem Bild-Problem helfen kann, muss ich mir erst einmal ein neues wetekdvb.ko besorgen. Meines ist für den Kernel 3.10.61. Der linux-wetek 3.10.76 lädt es gar nicht, mein 3.10.61 (amlogic) beschwert sich über nicht gefundene Module.


    Edit: Mit einem aktuellen wetekdvb.ko geht's problemlos.


    Gruß
    beta

    Zitat von ollo

    meine cmdline sieht so aus - siehe unten - ich erkenne da keine fundamentalen Unterschiede?!? Oder sollte es tatsächlich am "vdachwswitch" liegen??

    Bei mir steht "vmalloc=300M", allerdings erst im hinteren Teil - keine Ahnung von wo die vorderen Parameter kommen. Das ist auch die Änderung des verlinkten Patches.


    Zitat von beta

    Man sollte im mkbootimg schon das richtige initrd.img angeben und schon bootet die Wetek auch meinen Kernel

    Ich habe mein Image ohne initrd gebaut, einfach "make uImage-dtb" und dann in boot.img umbenannt.


    Ansonsten kämpfe ich hier momentan mit dem A/V-Sync bei H264, bei MPEG2 passt er inzwischen. Leider ist mein direkter Kontakt zu Wetek abgebrochen, oder die entsprechende Person ist gerade im Urlaub.


    Gruss
    Thomas

    Hallo,


    das sind ja in der Tat grossartige Neuigkeiten! :]


    reufer: hast Du denn schon Ebuilds mit denen man ein Gentoo-Image mit VDR und Deinem neuen Plugin für Wetek Play / Odroid mit so wenig "von Hand bauen" wie möglich lauffähig cross-emergen kann?


    Viele Grüße,
    Lucian



    Gentoo overlay mit VDR (und nicht nur) ebuilds, vdrcm, GLCDprocDriver

    reufer
    Hallo Thomas,


    auf meiner Ubuntu-Distribution verhält sich das Plugin wie folgt: Ich sehe erst kurz das OSD (kleiner als 1920x1080), dann habe ich für ca. 25 s ein Bild (getestet auf ARD SD). Dann bleibt das Bild stehen. Den VDR kann ich danach nicht mal mehr killen:


    0 Z root 1797 1787 14 80 0 - 0 exit 20:07 tty1 00:01:09 [vdr] <defunct>


    Im Log steht u.a.:


    Aug 27 20:08:49 localhost vdr: message repeated 2 times: [ [1808] amlhddevice: failed to write codec data, ret=0xffffffff]
    Aug 27 20:08:49 localhost vdr: [1809] buffer usage: 90% (tid=1808)
    Aug 27 20:08:49 localhost vdr: [1808] amlhddevice: failed to write codec data, ret=0xffffffff
    Aug 27 20:08:49 localhost vdr: [1808] amlhddevice: failed to write codec data, ret=0xffffffff
    Aug 27 20:08:49 localhost vdr: [1809] buffer usage: 100% (tid=1808)
    Aug 27 20:08:49 localhost vdr: [1808] amlhddevice: failed to write codec dat
    Aug 27 20:09:00 localhost vdr: [1808] ERROR: TS packet not accepted in Transfer Mode
    Aug 27 20:09:00 localhost vdr: [1809] ERROR: driver buffer overflow on device 1a, ret=0xffffffff
    Aug 27 20:08:50 localhost kernel: [ 368.654377@0] dsp not working ............
    Aug 27 20:08:51 localhost kernel: [ 369.654388@0] dsp not working ............


    Irgendeine Idee?


    ollo
    Ich starte mein Ubuntu von SD-Karte. u-boot scheint im NAND zu sein (da ist auch das Android) und gibt automatisch Kernel-Parameter mit. Im Kernel-Config kann ich die überschreiben, das ändert aber nichts. Die Kernel-Parameter von wetekplay.dtd scheint das System zu ignorieren. Mein fb hat 24 MB.


    Gruß
    beta


    P.S.: Bei der neuen Version kommt das Bild für den Bruchteil einer Sekunde, dann crasht der Kernel:


    [ 61.929023@0] Unable to handle kernel NULL pointer dereference at virtual address 00000000
    [ 61.931689@0] pgd = eeba4000
    [ 61.934511@0] [00000000] *pgd=ae902831, *pte=00000000, *ppte=00000000
    [ 61.940939@0] Internal error: Oops: 17 [#1] SMP ARM
    [ 61.945790@0] Modules linked in: sha1_generic sha1_arm wetekdvb(PO) mali
    [ 61.952479@0] CPU: 0 PID: 1739 Comm: device 1 receiv Tainted: P O 3.10.76+ #4
    [ 61.960461@0] task: eeb39800 ti: eccf8000 task.ti: eccf8000
    [ 61.966027@0] PC is at strncmp+0x10/0x7c
    [ 61.969922@0] LR is at 0x1
    [ 61.972613@0] pc : [<c0277c64>] lr : [<00000001>] psr: 200f0013
    [ 61.972613@0] sp : eccf9e0c ip : 00000007 fp : ee98af08
    [ 61.984417@0] r10: 00000000 r9 : 00000000 r8 : c05b1280
    [ 61.989798@0] r7 : 00000000 r6 : 00000004 r5 : c06d96e4 r4 : c05b0c80
    [ 61.996482@0] r3 : c06d96e8 r2 : 00000004 r1 : 00000000 r0 : c06d96e4
    [ 62.003167@0] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
    [ 62.010457@0] Control: 10c5387d Table: aeba404a DAC: 00000015

    Zitat von beta

    Bei der neuen Version kommt das Bild für den Bruchteil einer Sekunde, dann crasht der Kernel:

    Versuch es mal ohne wetekdvb.ko zu laden. Zwar crasht bei mir nichts, aber das Wetek-Modul ändert wohl was bei der Demuxer-Zuteilung, so dass scheinbar keine Daten mehr zu den Decodern gelangen. Muss ich noch anschauen, aber mittlerweile habe ich wieder Kontakt mit Wetek - sollte also lösbar sein.


    Gruss
    Thomas

    Zitat von beta

    Danke für den Tipp, Thomas. Ich probiere es gleich heute Abend aus und melde mich dann.
    Wie haben die Jungs von MLD das denn gelöst?


    Gruß
    beta

    Hi beta,


    wir haben es auch noch nicht gelöst.


    Gruss
    Roland

    https://www.minidvblinux.de/forum/

    1x OctopusNet mit 8x DVB-C
    1x Raspberry 4 MLD 6.0 SATIP (softhddevice-drm )

    1x RockPi 4 MLD 6.0 SATIP (softhddevice-drm )

    1x Raspberry 3 als Client MLD 5.4

    1x Raspberry 2 als Client MLD 6.0

    1x Raspberry 1 (staubt gerade so vor sich hin) ;)
    1x Cubietruck

    1x MCC 100
    1x BananaPi

    1x Zotac CI327 MLD 6.0 SATIP (softhddevice)

    reufer


    Thomas, welche kernel-src verwendest Du und welche .config? Die kernel-src von OE oder von wetek-enigma?


    Und welche Version vom wetekdevb.ko?


    Ich denke, hier gibt es noch zu viele Variablen. Bei mir bootet z.B. ein "make uImage-dtb" nicht mein Ubuntu-Image auf SD.


    Ich verwende den kernel von OE und wetekdvb.ko vom Mai (auch OE). An der wetek_play.dtd habe ich rumgefummelt, brauche aber definitiv die initrd vom WeTek Ubuntu image.


    Gruß, ollo

    ollo


    Hallo,


    bei mir bootet das -dtb auch nicht. Es gibt aber eine Kernel-Option in der .config, die Boot-Parameter anhängt. Die Werte, die zuletzt gesetzt sind, gewinnen gegenüber den zuerst gesetzten. Das u-boot im NAND setzt die nämlich. So kann man z.B. den vmalloc default des NAND-u-boots überschreiben.
    Ich werde gleich testen, ob mein Image ohne wetekdvb.ko funktioniert. Ich kann das dann gerne zur Verfügung stellen. Ansonsten hat Copperhead sicherlich Recht und wir sollten das Image-Thema in einen neuen Thread auslagern. Beim Image kommt es auch darauf an, was im NAND ist. Eine OpenELEC Wetek verhält sich hier evtl. anders als eine Android-Box (anderes u-boot). Bei meiner Android-Wetek ist leider auch der Tastendruck nicht aktiv, sonst könnte man das u-boot anhalten und das environment entsprechend ändern. So muss ich jedesmal einen neunen Kernel compilieren :(


    Gruß
    beta


    Edit: Das Ergebnis ist leider ernüchternd. Mit streamdev-client bekomme ich einen Kernel-Crash (linux-wetek). OSD alleine funktioniert (streamdev-server nicht gestartet). Wir sollten uns vermutlich auf eine gemeinsame Test-Basis einigen, also ein neues Test-Image erzeugen. Die Wetek-Ubuntu-Version scheint hier nicht wirklich gut geeignet zu sein.


    Edit2: Mit linux-amlogic gibts einen segmentation fault beim VDR-Start. Also: Neues Image. Vielleicht ist Thomas ja so nett, und lädt seines hoch ;)
    Wenn nicht, schick mir eine pm, ollo, dann machen wir das gemeinsam.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden