<div dir="ltr"><div><div><div><div><div><div>Thanks for your reply...<br><br></div>Meanwhile, yesterday I was able to progress a bit with this... I have compiled mesa-17.2.4 with the etnaviv code replaced with the latest from mesa git repo, thus enabling OpenGL 2.1.<br><br></div>I was able to login into Ubuntu Desktop 17.10 with wayland, however the GUI is still to heavy for GC3000. I saw no notibceable performance improvement or degradation when comparing with the 2D unit and xf86-video-armada driver.<br><br></div>Regarding Xorg I found out that the graphical display is initialized, but no image can be seen because the imx-drm driver of mesa doesn't provide the DRI interface. It seems also possible to integrate VDPAU or VAAPI with imx-drm and the video acceleration unit of i.MX6. That would be pretty nice, but I think it would require lots of work. I also believe that the codec acceleration unit is not completely open-source... if it was, it was just a matter of creating a wrapper for the VDPAU API.<br><br></div>Xorg logs follow below.<br></div><div><br></div>Regards,<br></div>Luís<br><br><br>[    17.121] (II) xfree86: Adding drm device (/dev/dri/card0)<br>[    17.137] (II) xfree86: Adding drm device (/dev/dri/card1)<br>[    17.137] (II) no primary bus or device found<br>[    17.138]    falling back to /sys/devices/soc0/display-subsystem/drm/card0<br>[    17.138] (II) LoadModule: "glx"<br>[    17.156] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so<br>[    17.241] (II) Module glx: vendor="X.Org Foundation"<br>[    17.241]    compiled for 1.19.5, module version = 1.0.0<br>[    17.241]    ABI class: X.Org Server Extension, version 10.0<br>[    17.242] (==) Matched modesetting as autoconfigured driver 0<br>[    17.242] (==) Matched fbdev as autoconfigured driver 1<br>[    17.242] (==) Assigned the driver to the xf86ConfigLayout<br>[    17.242] (II) LoadModule: "modesetting"<br>[    17.244] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so<br>[    17.250] (II) Module modesetting: vendor="X.Org Foundation"<br>[    17.250]    compiled for 1.19.5, module version = 1.19.5<br>[    17.251]    Module class: X.Org Video Driver<br>[    17.251]    ABI class: X.Org Video Driver, version 23.0<br>[    17.251] (II) LoadModule: "fbdev"<br>[    17.252] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so<br>[    17.254] (II) Module fbdev: vendor="X.Org Foundation"<br>[    17.254]    compiled for 1.19.3, module version = 0.4.4<br>[    17.254]    Module class: X.Org Video Driver<br>[    17.254]    ABI class: X.Org Video Driver, version 23.0<br>[    17.255] (II) modesetting: Driver for Modesetting Kernel Drivers: kms<br>[    17.255] (II) FBDEV: driver for framebuffer: fbdev<br>[    17.285] (II) modeset(0): using drv /dev/dri/card0<br>[    17.285] (WW) Falling back to old probe method for fbdev<br>[    17.285] (II) Loading sub module "fbdevhw"<br>[    17.285] (II) LoadModule: "fbdevhw"<br>[    17.287] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so<br>[    17.289] (II) Module fbdevhw: vendor="X.Org Foundation"<br>[    17.290]    compiled for 1.19.5, module version = 0.0.2<br>[    17.290]    ABI class: X.Org Video Driver, version 23.0<br>[    17.293] (II) modeset(0): Creating default Display subsection in Screen section        "Default Screen Section" for depth/fbbpp 24/32<br>[    17.293] (==) modeset(0): Depth 24, (==) framebuffer bpp 32<br>[    17.293] (==) modeset(0): RGB weight 888<br>[    17.294] (==) modeset(0): Default visual is TrueColor<br>[    17.294] (II) Loading sub module "glamoregl"<br>[    17.294] (II) LoadModule: "glamoregl"<br>[    17.295] (II) Loading /usr/lib/xorg/modules/libglamoregl.so<br>[    17.352] (II) Module glamoregl: vendor="X.Org Foundation"<br>[    17.352]    compiled for 1.19.5, module version = 1.0.0<br>[    17.353]    ABI class: X.Org ANSI C Emulation, version 0.4<br>[    17.353] (II) glamor: OpenGL accelerated X.org driver based.<br>[    18.043] (II) glamor: EGL version 1.4 (DRI2):<br>[    18.075] (II) modeset(0): glamor initialized<br>[    18.077] (II) modeset(0): Output HDMI-1 has no monitor section<br>[    18.079] (II) modeset(0): EDID for output HDMI-1<br>[    18.079] (II) modeset(0): Printing probed modes for output HDMI-1<br>[    18.079] (II) modeset(0): Modeline "1024x768"x60.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz e)<br>[    18.079] (II) modeset(0): Modeline "800x600"x60.3   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz e)<br>[    18.080] (II) modeset(0): Modeline "800x600"x56.2   36.00  800 824 896 1024  600 601 603 625 +hsync +vsync (35.2 kHz e:<br>[    18.080] (II) modeset(0): Modeline "848x480"x60.0   33.75  848 864 976 1088  480 486 494 517 +hsync +vsync (31.0 kHz e)<br>[    18.080] (II) modeset(0): Modeline "640x480"x59.9   25.18  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz e)<br>[    18.080] (II) modeset(0): Output HDMI-1 connected<br>[    18.080] (II) modeset(0): Using exact sizes for initial modes<br>[    18.080] (II) modeset(0): Output HDMI-1 using initial mode 1024x768 +0+0<br>[    18.081] (==) modeset(0): Using gamma correction (1.0, 1.0, 1.0)<br>[    18.081] (==) modeset(0): DPI set to (96, 96)<br>[    18.081] (II) Loading sub module "fb"<br>[    18.081] (II) LoadModule: "fb"<br>[    18.088] (II) Loading /usr/lib/xorg/modules/libfb.so<br>[    18.092] (II) Module fb: vendor="X.Org Foundation"<br>[    18.092]    compiled for 1.19.5, module version = 1.0.0<br>[    18.092]    ABI class: X.Org ANSI C Emulation, version 0.4<br>[    18.092] (II) UnloadModule: "fbdev"<br>[    18.092] (II) Unloading fbdev<br>[    18.093] (II) UnloadSubModule: "fbdevhw"<br>[    18.093] (II) Unloading fbdevhw<br>[    18.093] (==) Depth 24 pixmap format is 32 bpp<br>[    18.326] (==) modeset(0): Backing store enabled<br>[    18.326] (==) modeset(0): Silken mouse enabled<br>[    18.330] (II) modeset(0): RandR 1.2 enabled, ignore the following RandR disabled message.<br>[    18.336] (==) modeset(0): DPMS enabled<br>[    18.337] (II) modeset(0): [DRI2] Setup complete<br>[    18.337] (II) modeset(0): [DRI2]   DRI driver: imx-drm<br>[    18.337] (II) modeset(0): [DRI2]   VDPAU driver: imx-drm<br>[    18.337] (--) RandR disabled<br>[    18.363] (II) SELinux: Disabled on system<br>[    18.366] (EE) AIGLX error: imx-drm does not export required DRI extension<br>[    18.366] (EE) AIGLX: reverting to software rendering<br>[    18.391] (II) IGLX: enabled GLX_MESA_copy_sub_buffer<br>[    18.395] (II) IGLX: Loaded and initialized swrast<br>[    18.396] (II) GLX: Initialized DRISWRAST GL provider for screen 0<br>[    18.405] (II) modeset(0): Damage tracking initialized<br>[    18.406] (II) modeset(0): Setting screen physical size to 270 x 203<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 1, 2017 at 1:52 PM, Lucas Stach <span dir="ltr"><<a href="mailto:l.stach@pengutronix.de" target="_blank">l.stach@pengutronix.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Am Dienstag, den 31.10.2017, 10:04 +0000 schrieb Russell King - ARM Linux:<br>
> On Tue, Oct 31, 2017 at 09:11:37AM +0000, Luís Mendes wrote:<br>
> > Hi,<br>
> ><br>
> > Russel: I believe that the video corruption I saw with copyNToN(...)<br>
> > function of xf86-video-armada is not the root cause of the problem, but<br>
> > rather a side effect of the MMU faults.<br>
> > Can you help me setup a debug environment where I can dump the client<br>
> > process stack from the etnaviv kernel module upon a MMU fault? I have<br>
> > enough space on my SSD drive to dump the memory images.<br>
><br>
> I haven't looked at the kernel etnaviv driver in detail for a while,<br>
> but I added support for devcoredump to the driver, which dumps all<br>
> buffers attached to the GPU.  This is rigged up to recover_worker().<br>
><br>
> When a MMU exception occurs, you'd need to call a worker to take<br>
> gpu->lock, and then call etnaviv_core_dump() in the same way<br>
> recover_worker() does.<br>
<br>
</span>With the current page table settings for MMUv2 any MMU fault will<br>
actually stall the GPU. This way faults will already trigger the<br>
generation of coredumps, as the GPU is hung at that point. You don't<br>
need to change anything in the kernel driver for this to work.<br>
<br>
Regards,<br>
Lucas<br>
<div class="HOEnZb"><div class="h5"><br>
> You'll need to clone and install<br>
><br>
>   git://<a href="http://git.armlinux.org.uk/~rmk/etna-gpu-tools.git/" rel="noreferrer" target="_blank">git.armlinux.org.uk/~<wbr>rmk/etna-gpu-tools.git/</a><br>
><br>
> which contains the udev rules to detect when an etnaviv coredump<br>
> happens, and automatically unpack it.  It'll want the etna_viv<br>
> source for some of the tools, and you'll need to edit the<br>
> Makefile to point it to that (it currently uses /shared/etna_viv).<br>
><br>
> The devcoredump files will be located (by default) in /var/crash,<br>
> named etnaviv-$date.bin, and the unpacked versions in<br>
> /tmp/etnaviv-$date.<br>
><br>
> Located in the package are tools to diff between two command<br>
> streams, detile etnaviv buffers, a replacement viv_info utility<br>
> for the DRM etnaviv version, and some scripts to help hexdump<br>
> the MMU and 3D GPU index buffers.<br>
><br>
> What I've omitted from it is the perl script I use to parse the<br>
> GPU command stream - I forget why, but probably because it was<br>
> rather dirty, and accessed memory via /dev/mem.  I also don't<br>
> think it had the bits for the 2D GPU.  I'll see if I can clean<br>
> it up at some point and include it in the above git tree.<br>
><br>
</div></div></blockquote></div><br></div>