E2Pli Layer für Openembedded/Yocto

[plux7887]

In Graugans Project-Magpie gibt es einen für SH4 Boxen angepaßten E2Pli Layer, mit dem man Enigma2 unter Openembedded/Yocto bauen kann.
Es läßt sich schon fehlerfrei ein Image bauen.

Auf der Box hat dieses E2 allerdings noch ein paar kleine Macken:

1. Der Sendersuchlauf funktioniert noch nicht (es werden keine Sender gefunden). Wenn man die Bouquets aus einem aus einem anderen Image da reinkopiert, gehen die Sender. Scheint
also nur noch ein kleiner Bug im Suchlauf selber zu seien.
2. Das EPG funktioniert noch nicht. (Notwendig um Timer zu programmieren).
3. Die Fernbedienung ist zu empfindlich. (Es werden bei einem kurzen Tastendruck immer gleich mehrere Menüpunkte/Sender übersprungen.

Wer hat Ideen woran es liegt, wer kann helfen?

Das attraktive an der ganzen Sache ist, das man mit dem Yocto Buildsystem jetzt schon erfolgreich super Neutrino-HD2 und Neutrino-MP Images bauen kann. Wenn jetzt noch ein gut funktionierendes E2 hinzukommt, könnten wir endlich mal wieder ein Triple Image E2-Neutrino-HD2-Neutrino-MP analog zu Pinkys Evotriple bauen, da gibt es schon seit über einem dreivirtel Jahr keinen Fortschritt und keine Updates mehr.

[graugans]

Ich glaube e2 ist hier nicht so verbreitet. Falls jemand Interesse hat kann das nachzubauen kann er das wie folgt tun:

Code: Alles auswählen

git clone  https://github.com/project-magpie/setup-scripts.git project-magpie
cd project-magpie
git checkout -b dora-openpli
$ MACHINE=spark ./oebb.sh config spark
rm -f ~/.oe/environment-project-magpie
source ~/.oe/environment-project-magpie
bitbake enigma2-image

Das Ergebnis am Besten gleich auf einen USB-Stick schreiben und testen:
!!!! Achtung prüfen ob bei Euch der Stick unter /dev/sdc eingehängt wurde !!!!

Code: Alles auswählen

sudo umount /dev/sdc[1-2] 
sudo dd if=build/tmp-magpie/deploy/images/spark/enigma2-image-spark.spark71xx-usbimg of=/dev/sdc 
sync

Wie man die Box via USB booten kann steht im Wiki

Bei Fragen oder Problemen einfach melden.

[graugans]

Den Fehler mit der Kanalsuche habe ich gefixt.
https://github.com/project-magpie/enigm ... 012c06c494
Wer fixt den nächsten?

[mohousch]

fixen nicht ;( aber vielleicht ein Tipp

in max-clone ist der aktuallisierte enigma2-pli patch drin enthält alle notwendigen Patche für sh4 Platformen.

[graugans]

Danke, weißt Du vielleicht wozu evremote2 gut ist? Aktuell ist die Fernbedienung unter E2 und Neutrino-HD2 ziemlich crappy. Hast Du eine Idee woran das liegen könnte?

P.S: Den Patch kenne ich ich bin dabei den zu zerlegen und in kleine Portionen aufzuteilen.

Gesendet von meinem Nexus 4 mit Tapatalk

[mohousch]

Manche (oder fast alle glaube) front panel Treiber stellen kein event input device zur Verfügung sondern rc device, die evremote ist etwa auch wie die lircd die schleift die input fom front panel und stelle sie in den bekannten event input device und andere wie die rtc etc...
bei der Cuberevo (die ich hier habe) gab es erstmal auch ein NP fp global Treiber der alles koennte wie der fp Treiber der Dbox (event input, fp, rtc...etc...)damit überhaupt keine zusächtlichen Tool wie evremote und vfdstandby gebraucht hat um die event zu lesen und auch die timers einzulesen oder zu schreiben, warum konfetti und Co das über den vfd/front panel Treiber nicht gemacht haben und die event an die evremote serviert weiss leider genau auch nicht koennte sein an die unterschiedlichen Platformen liegen.

[seife]

Danke, weißt Du vielleicht wozu evremote2 gut ist?

IMHO für gar nichts. Lircd macht ja per uinput ein input-device und das besser und einfacher als dieser etwas "undurchsichtige" evremote code

[graugans]

Danke Stefan, wie ich vermutet hatte irgendwie hat sich mir der Sinn dieses Quellcodes nicht so richtig erschlossen.

[graugans]

Wie seife bereits erwähnt hatte, wird das evremote2 e2 aktuell nicht benötigt. Meiner Meinung nach verschlechtert es eher das Verhalten. Allerdings erkennt e2 die InputDevices nicht richt weil ein ioctl fehl schlägt.

Code: Alles auswählen

[iInputDevices] getInputDevices  <ERROR: ioctl(EVIOCGNAME): [Errno 22] Invalid argument >
[iInputDevices] getInputDevices  <ERROR: ioctl(EVIOCGNAME): [Errno 22] Invalid argument >

Als kleinen Workarround verwende ich aktuell den Gerätenamen unter e2 damit lässt die Wiederholverzögerung anpassen.
https://github.com/project-magpie/enigm ... f2ceee550e

Gruß
Christian

[seife]

Um das klar zu stellen: der evremote-Code ist ja schon recht alt und damals konnte wohl lircd das mit dem uinput device noch nicht, er könnte also durchaus mal eine Daseinsberechtigung gehabt haben.

Wegen dem IOCTL-Error: IMHO der einzige Weg, wie das im Kernel zu -EINVAL führen kann, ist:

if (_IOC_TYPE(cmd) != 'E')
return -EINVAL;

oder wenn das nicht stimmt:

if (_IOC_DIR(cmd) == _IOC_READ)

Aber dann wäre eher was im Python-Code seltsam, oder in der Python->lowlevel abstraktion, sprich der python-definition von EVIOCGNAME(). Ich finde das sowieso seltsam, sowas in Python zu machen, aber egal

Daß es am Kernel nicht liegt kannst du sehen, wenn du evtest baust (ist bei meinem buildsystem mit drin) und da funktioniert EVIOCGNAME nämlich wenn mich nicht alles täuscht.

[graugans]

Um das klar zu stellen: der evremote-Code ist ja schon recht alt und damals konnte wohl lircd das mit dem uinput device noch nicht, er könnte also durchaus mal eine Daseinsberechtigung gehabt haben..

Durchaus, ich finde es auch beachtlich was das TDT Projekt alles zustande gebracht hat. Für mich hat sich die Frage gestellt wo investiere ich meine Zeit. Versuche ich die Funktion von evremote2 zu verstehen um dort die Stellschrauben zu finden oder kann ich mich auf enigma konzentrieren. Ich gehe auch davon aus, dass ich evremote2 nicht optimal betrieben habe und somit kein optimales Ergebnis hatte

Wegen dem IOCTL-Error: IMHO der einzige Weg, wie das im Kernel zu -EINVAL führen kann, ist:

if (_IOC_TYPE(cmd) != 'E')
return -EINVAL;

oder wenn das nicht stimmt:

if (_IOC_DIR(cmd) == _IOC_READ)

Das eigentliche Problem sind die Makrodefinitionen
arch/sh/include/asm/ioctl.h -> include/asm-generic/ioctl.h

Definiert das folgende:

Code: Alles auswählen

#define _IOC_NRBITS	8
#define _IOC_TYPEBITS	8
# define _IOC_SIZEBITS	14
# define _IOC_DIRBITS	2
#define _IOC_NRSHIFT	0

Der Python Code beinhaltet folgende Definitionen:

Code: Alles auswählen

# asm-generic/ioctl.h
IOC_NRBITS = 8L
IOC_TYPEBITS = 8L
IOC_SIZEBITS = 13L
IOC_DIRBITS = 3L

Aber dann wäre eher was im Python-Code seltsam, oder in der Python->lowlevel abstraktion, sprich der python-definition von EVIOCGNAME(). Ich finde das sowieso seltsam, sowas in Python zu machen, aber egal

Siehe oben. Ja so etwas in python zu tun ist etwas ungeschickt Alleine schon die Tatsache, dass man die Definitionen aus dem Header in den Python Code kopieren muss sollte einen skeptisch stimmen.

Daß es am Kernel nicht liegt kannst du sehen, wenn du evtest baust (ist bei meinem buildsystem mit drin) und da funktioniert EVIOCGNAME nämlich wenn mich nicht alles täuscht.

Jupp, das war eine vorschnelle Vermutung. Zumal im aktuellen Kernel die ioctl Defintionen die selben sind wie im gut abgehangenen STM Code.

[seife]

hehe Alpha, SPARC, POWER und MIPS haben _IOC_SIZEBITS = 13, alle anderen 14.

Aus python raus wäre es wohl portabler, /proc/bus/input/devices zu parsen als dieses Gewurstel zu fixen.

[graugans]

Danke für den Tipp, werde das mal prüfen. Da stecken die selben Informationen wie im ioctl drin. Die Idee ist eigentlich genial.

Gesendet von meinem Nexus 4 mit Tapatalk

[seife]

Wobei ein echter Spaß ist das parsen auch nicht: erst kommt der Name, dann kommt bei "Handlers=" *auch* das eventdevice. Insofern -- nachdem du es jetzt gefixt hast => Mission accomplished

[graugans]

Hi,

ich habe mal wieder ein Frage. Aktuell stocher ich bezüglich Videoauflösung im Nebel.
Versuche ich ohne Änderungen am E2 Code eine Auflösung != 720p@50Hz auszuwählen sieht das Bild ziemlich bescheiden aus. Siehe Bild im Anhang.
Dann habe ich versucht den Speicher beim Laden des stmfb Moduls zu vergrößern. Das hat dann zu einem Kernel OOps geführt.

Code: Alles auswählen

-MEMSIZE=12m     # neutrino now needs 12m for FB scaling backbuffer
+MEMSIZE=15m     # enigma2 may needs 15m for FB scaling backbuffer

Die 15m habe ich aus irgendwelchen E2 TDT Startskripten herausgezogen.

Was nach einem reboot folgenden OOps erzeugt:

Code: Alles auswählen

[   20.636000] Found mode to set pal at 24
[   20.640000] Unable to handle kernel NULL pointer dereference at virtual address 0000000c
[   20.644000] pgd = 88867000
[   20.648000] [0000000c] *pgd=00000000
[   20.652000] Oops: 0000 [#1]
[   20.652000] last sysfs file: /sys/devices/virtual/stmcoredisplay/display0/hdmi0.0/hotplug
[   20.652000] Modules linked in: autofs4 smartcard bpamem silencegen platform stmalloc sth264pp player2 stmdvb stmsysfs stm_monitor pti stv090x pseudocard stmvbi stmvout stm_v4l2 p2div64 ksound mmelog avsm
[   20.652000] 
[   20.652000] Pid : 823, Comm:                 enigma2
[   20.652000] CPU : 0                  Not tainted  (2.6.32.59_stm24_0211 #1)
[   20.652000] 
[   20.652000] PC is at stmfb_decode_var+0x88/0x2a8 [stmfb]
[   20.652000] PR is at stmfb_decode_var+0x66/0x2a8 [stmfb]
[   20.652000] PC  : c11afbe8 SP  : 87e97cb4 SR  : 40008000 TEA : c125f448
[   20.652000] R0  : 00000040 R1  : 00000320 R2  : 0000026b R3  : 00000002
[   20.652000] R4  : 00000000 R5  : 000002d0 R6  : 0001215a R7  : 00000271
[   20.652000] R8  : 87e97e64 R9  : 87e97cf4 R10 : 87e97cec R11 : 87e97ea4
[   20.652000] R12 : c11b34a0 R13 : c11b379c R14 : 87e97cb4
[   20.652000] MACH: 00000004 MACL: d4a47f52 GBR : 29703470 PR  : c11afbc6
[   20.652000] 
[   20.652000] Call trace:
[   20.652000]  [<80812728>] free_task+0x2c/0x4c
[   20.652000]  [<c11add7a>] stmfb_check_var+0x32/0x88 [stmfb]
[   20.652000]  [<8083b214>] __rcu_process_callbacks+0x0/0x330
[   20.652000]  [<808190ac>] __do_softirq+0x64/0x104
[   20.652000]  [<808381ee>] handle_IRQ_event+0x3a/0xe4
[   20.652000]  [<8081917a>] do_softirq+0x2e/0x64
[   20.652000]  [<80a00b82>] fb_set_var+0xba/0x26c
[   20.652000]  [<80b656f2>] schedule+0x38a/0x440
[   20.652000]  [<80b658c8>] preempt_schedule+0x28/0x4c
[   20.652000]  [<80814810>] emit_log_char+0x0/0x6c
[   20.652000]  [<80b65368>] schedule+0x0/0x440
[   20.652000]  [<808155aa>] vprintk+0x2e2/0x318
[   20.652000]  [<80814810>] emit_log_char+0x0/0x6c
[   20.652000]  [<80872322>] inode_setattr+0x11e/0x154
[   20.652000]  [<80b62526>] printk+0x1a/0x2c
[   20.652000]  [<c13e5e96>] proc_video_videomode_write+0x262/0x34c [stmdvb]
[   20.652000]  [<80898bfe>] proc_file_write+0x76/0x98
[   20.652000]  [<80898b88>] proc_file_write+0x0/0x98
[   20.652000]  [<80872fa2>] alloc_fd+0x4e/0x104
[   20.652000]  [<80872b30>] expand_files+0x0/0x1a4
[   20.652000]  [<80894fd8>] proc_reg_write+0x78/0x9c
[   20.652000]  [<80898b88>] proc_file_write+0x0/0x98
[   20.652000]  [<8086b5d0>] do_fcntl+0xd4/0x3e4
[   20.652000]  [<8086035c>] vfs_write+0x68/0x110
[   20.652000]  [<8086b378>] sys_dup3+0x104/0x154
[   20.652000]  [<808605b4>] sys_write+0x34/0x6c
[   20.652000]  [<80808920>] syscall_call+0xa/0xe
[   20.652000]  [<80860580>] sys_write+0x0/0x6c
[   20.652000] 
[   20.652000] Process: enigma2 (pid: 823, stack limit = 87e96001)
[   20.652000] Stack: (0x87e97cb4 to 0x87e98000)
[   20.652000] 7ca0:                                              80812728 87e97cc0 87e8b500 
[   20.652000] 7cc0: 00000002 00cdfe6d 00000000 c11add7a 87e97cec c11b369c 00000100 c11b34a0 
[   20.652000] 7ce0: 87e97e64 c11b3728 87e97e64 00000102 00000001 80cf7f70 80cf7f20 8083b214 
[   20.652000] 7d00: 808190ac 87e97d0c 87e97d0c 808381ee 87e97d14 00000009 8081917a 87e97d38 
[   20.652000] 7d20: 80c822f0 80a00b82 87e97d40 00000100 87e97ea4 87e97e64 87e82000 c11b34a0 
[   20.652000] 7d40: 87e8a188 00010000 00000080 0000013c 87e8ae00 80c821c4 80b656f2 87e97d6c 
[   20.652000] 7d60: 80c81e08 87e8ba0c 87e8b880 40008100 80c8230c 80c822f8 00005133 ffffffff 
[   20.652000] 7d80: 0000fa71 00000000 00048f87 00000000 80b658c8 87e97db0 80c822f0 80814810 
[   20.652000] 7da0: 80cf7a94 0000002e 80b65368 10000000 808155aa 87e97dc0 00000000 00000000 
[   20.652000] 7dc0: 80814810 0000000f 87e97def 00000034 00000000 80cf7a94 00000014 00000000 
[   20.652000] 7de0: 2020205b 362e3032 30303633 00205d30 80cb5de8 89f0a300 80872322 87e97e08 
[   20.652000] 7e00: 87e97e70 000200d0 87e97e0c 00000000 00000000 80b62526 87e97e34 00000003 
[   20.652000] 7e20: 00000018 00000018 c11b34a0 c13e5e96 87e97e4c 00000003 000002d0 00000240 
[   20.652000] 7e40: c11b34a0 87e82000 00000004 fffffff4 00000600 87dff2a3 00000015 00000000 
[   20.652000] 7e60: 87dff2a0 000002d0 00000240 000002d0 00000240 00000000 00000000 00000020 
[   20.652000] 7e80: 00000000 00000010 00000008 00000000 00000008 00000008 00000000 00000000 
[   20.652000] 7ea0: 00000008 00000000 00000018 00000008 00000000 00000000 00000080 ffffffff 
[   20.652000] 7ec0: ffffffff 00000000 0001215a 00000044 0000000c 00000026 00000005 00000040 
[   20.652000] 7ee0: 00000006 00000000 00000201 00000000 00000000 00000000 00000000 00000000 
[   20.652000] 7f00: 00000000 80898bfe 87e97f24 296ff934 0000059c 00000000 004ec408 80898b88 
[   20.652000] 7f20: 89f0a060 80872fa2 87e97f44 80872b30 80894fd8 87e97f40 80898b88 89f0a060 
[   20.652000] 7f40: 0000000a 00000000 8086b5d0 87e97f68 8086035c 87e97f60 87e97f8c 87c1f780 
[   20.652000] 7f60: 87e97f64 8086b378 87e97f78 808605b4 87e97f84 00000000 00000071 004ec408 
[   20.652000] 7f80: 87c1f780 00000004 00000000 00000000 00000000 80808920 004f7d28 00000100 
[   20.652000] 7fa0: 80860580 00000000 00000470 0005c470 00000004 00000001 004ec408 00000004 
[   20.652000] 7fc0: 00000534 00000004 004ec408 296ff8f0 00000004 296ffc6c 296ff934 004f7d28 
[   20.652000] 7fe0: 7b9c95b8 29673394 29616f10 00008001 29703470 00000000 00000000 0000004c 

[   20.664000] ---[ end trace dbb86e11c987a652 ]---

P.S: Es sind keine Closed Source Module geladen.

Gruß
Christian

[seife]

es knallt in tdt-driver, stgfb/stmfb-3.1_stm24_0102/linux/kernel/drivers/video/stmfbvar.c, stmfb_decode_var

Zum einen kannst du versuchen, dir mit GDB den genauen platz rauszufinden, an dem es geknallt hast, es ist aber schon ewig her, daß ich das mal gemacht habe. Typischerweise baue ich einfach viele printk()'s ein um zu sehen, wo es dann knallt

[graugans]

Prinzipiell sollte das mit GDB gehen. Den Workflow habe ich in meinem Blog schon beschrieben.

http://project-magpie.github.io/2013/10 ... rnel-oops/

Bei Modulen muss man wohl noch die Startadresse angeben:

http://www.linux.com/learn/linux-traini ... g-with-gdb

Leider hatte ich vorhin das Problem, dass er die Symbole nicht finden konnte. Ich spiele da noch ein bisschen rum.

Hat jemand eine Idee wo das verschrobene Bild bei Enigma herkommen könnte?

Gesendet von meinem Nexus 4 mit Tapatalk

[mohousch]

@graugans

hast Du Dir mal den stlinux metalayer vom scp für openpli angeschaut?
der hat ja mipsel/arm/sh4 in einem für den openpli und baut auch alle 3 GUIs Neutrino-MP/Neutrino-HD2 und enigma2

[graugans]

@mohousch
Danke, den Layer von scp vergesse ich immer weil es dazu keinen git gibt

So langsam kreise ich den Fehler ein.

Code: Alles auswählen

root@spark:~# cd /sys/module/stmfb/sections                                                                                                                                                                   
root@spark:/sys/module/stmfb/sections# ls -A1
.bss
.data
.exit.text
.fixup
.gnu.linkonce.this_module
.init.text
.note.gnu.build-id
.rodata
.rodata.str1.4
.strtab
.symtab
.text                                                                                               (where the text section was loaded)
.text.unlikely
.undef.hash
__bug_table
__ex_table
__ksymtab
__ksymtab.htable
__ksymtab_strings
__param
root@spark:/sys/module/stmfb/sections# cat .text .data .bss             (the section addresses I care about)
0xc141d000                                                                                    (address of module's text section ...)
0xc1423408                                                                                    (... and data ...)
0xc1423738                                                                                    (... and BSS) 

Die Offests stimmen nicht überein, da sie von unterschiedlichen Läufen sind...

Code: Alles auswählen

(gdb) add-symbol-file /data/project-magpie/setup-scripts/build/tmp-magpie/work/spark-poky-linux/tdt-driver/0.2+gitAUTOINC+a187619dea-r2/git-7111/stgfb/stmfb-3.1_stm24_0102/stmfb.ko 0xc141d000 -s .data 0xc14233c8 -s  .bss 0xc14236f8 
add symbol table from file "/data/project-magpie/setup-scripts/build/tmp-magpie/work/spark-poky-linux/tdt-driver/0.2+gitAUTOINC+a187619dea-r2/git-7111/stgfb/stmfb-3.1_stm24_0102/stmfb.ko" at
	.text_addr = 0xc141d000
	.data_addr = 0xc14233c8
	.bss_addr = 0xc14236f8
(y or n) y
Reading symbols from /data/project-magpie/setup-scripts/build/tmp-magpie/work/spark-poky-linux/tdt-driver/0.2+gitAUTOINC+a187619dea-r2/git-7111/stgfb/stmfb-3.1_stm24_0102/stmfb.ko...done.
(gdb) list *(0xc141fc3c)
0xc141fc3c is in stmfb_decode_var (/data/project-magpie/setup-scripts/build/tmp-magpie/work/spark-poky-linux/tdt-driver/0.2+gitAUTOINC+a187619dea-r2/git-7111/include/stmfb/stmdisplayoutput.h:685).
680	 * not supported.
681	 *
682	 */
683	static inline const stm_mode_line_t* stm_display_output_find_display_mode(stm_display_output_t *o, ULONG xres, ULONG yres, ULONG minlines, ULONG minpixels, ULONG pixclock, stm_scan_type_t scan)
684	{
685	  return o->ops->FindDisplayMode(o,xres,yres,minlines,minpixels,pixclock,scan);
686	}
687	
688	
689	/*

[graugans]

Ich bin mittlerweile schon einen Schritt weiter gekommen. Leider hatte ich beim Booten eine Fehlermeldung übersehen:

Code: Alles auswählen

[    8.732000] Failed to allocate fb0 memory, requested size = 15728640
[    8.744000] stmcore-display: probe of stmcore-display.0 failed with error -12

Diese Fehlermeldung wird in der Datei <stgfb/stmfb-3.1_stm24_0102/linux/drivers/video/stmfb.c> geschmissen. Meine Vermutung ist nun die reservierte Größe von 18MB bigphysarea reicht nicht aus. Bei der 7162 werden 24MB reserviert. Ich habe mal die Werte von Pinky übernommen 32MB bigphysarea + 92 MB LMI_IO erscheint mir dann doch recht viel. --> Weitere Untersuchungen.

Code: Alles auswählen

  i->FBPart = bpa2_find_part ("bigphysarea");
  i->ulPFBBase = i->FBPart ? bpa2_alloc_pages (i->FBPart, nPages, 0, GFP_KERNEL)
                           : 0;
  if (!i->ulPFBBase)
  {
    printk(KERN_WARNING "Failed to allocate fb%d memory, requested size = %lu\n",display, i->ulFBSize);
    ret = -ENOMEM;
    goto failed0;
  }

  /* try to allocate memory from BPA2 as additional memory for graphics
     operations. Basically, this is not vital, but driver loading will still
     fail if an auxsize has been specified in the module parameters which can
     not be satisfied, either because no BPA2 partition 'gfx-memory' exists,
     or if it's not large enough for the given auxsize. */
  /* Please note that due to hardware limitations, this can actually be a bit
     complex (2 & 3):
     1) we look for partitions labelled 'gfx-memory-[0...x]', each of which
        should be 64MB in size and be aligned to a 64MB bank. This makes the
        process quite easy for us.
     2) Failing that, we try to use a partition labelled 'gfx-memory'. Now we
        have to make sure ourselves that each allocation does not cross a 64MB
        bank boundary.
     3) Failing that, too, or in case the 'gfx-memory' partition not being
        large enough to accomodate for the amount of gfx memory requested in
        the module options, we will do the same but this time use the
        'bigphysarea' partition. */
  /* So, either one can configure several 'gfx-memory-%d' partitions
     (preferred, to have maximum control over placement of gfx memory), just
     use one large 'gfx-memory' partition, or configure nothing at all and be
     limited to 'bigphysarea' memory.
     The combined memory of all the allocations will be made available to
     DirectFB. */

Damit ist der Oops behoben das ursprüngliche Problem noch offen. Da werde ich weiter die Patches durchforsten müssen...

Gruß
Christian