Download Pyra Debian OS (WIP)

Linux-SWAT

Hardcore Member
Joined
Feb 13, 2010
Messages
8,223
I just want to test if windows move faster ;^) .
Yes, SD access is soooo sloooow !
 

zmatt

Active Member
Joined
Oct 31, 2015
Messages
70
Location
Netherlands
modprobe etnaviv
=> [30257.923139] driver_register 'etnaviv-gpu'
=> [30257.928086] driver_register 'etnaviv'

What next? I didn't found any info for testing 2D part of this driver.
You normally almost never have to modprobe a module (unless you first removed it manually) since the kernel will automatically load it when it detects a compatible device. The reason is hasn't is probably that it's missing from Device Tree.

As far as I can tell it does look like the appropriate kernel module, and it should support the GC320, but that's just based on a very quick look.

May want to talk to @zmatt he's been doing a bit of work with it lately.
No I haven't.

I'm interested in this 'cause I'd like to see video acceleration soon, I'm sick of having a high cpu usage when watching.
How would the GC320 help with that? It's a blitting engine. If you want video decoding acceleration you need IVA-HD working, which is going to be non-trivial...
 

pyrat

Very Active Member
Joined
May 20, 2016
Messages
148
Ok, I don't really know much about this, but just my 2c (which might be false, but I take for true). I may be misinforming people, but I'll probably go on until someone tells me this is wrong. Maybe nobody knows until somebody tries it.

I think, slaeshjag is right, that the build in kernel module etnaviv is not the right kernel module for 2D.
I think etnaviv is the good module for GC320, but it might need user space software.
I've read in passing 2015-10-07 Linux Weekly News:
Russell King has gotten the xf86-video-armada driver working using libetnaviv on top of the Vivante kernel driver. That uses the 2D GPU and provides acceleration for some common operations.
In particular this January 2016 commit looks promising (for those using X11 on a GC320). From a quick browse it seems to split a package in two (one for etnaviv and one for the proprietary driver) and it seems
to use etnaviv to draw. It seems to check features so it might work on the OMAP 5432. But I think it's never been tried and might need changes. It comes from work for the Novena laptop.
That has a Freescale i.MX6 quad, with a GC320 (2D), but also a GC2000 (3D) and a GC355 (video??). The OMAP 5432 only has the GC320 so maybe the driver tries to use parts
that aren't there, I don't know. If you look for "3D" in the commit there are places that mentions it, so who knows?

I will check bltsville again, but i looked at before and found no samples/tools for it, so i checked alternatives.
I'm not sure, but maybe bltsville has two options: ticpu for software rendering and gcbv for the proprietary driver, so does not work with the free driver (Etnaviv)
 

Silent-Hunter

Hardcore Member
Joined
May 29, 2010
Messages
3,077
What is the URL for the Pyra's debian repo? I want to see if the packages for making and mounting exfat partitions are in there.
 

Linux-SWAT

Hardcore Member
Joined
Feb 13, 2010
Messages
8,223
CC drivers/gpu/drm/etnaviv/etnaviv.mod.o
LD [M] drivers/gpu/drm/etnaviv/etnaviv.ko
ld: cannot open output file drivers/gpu/drm/etnaviv/etnaviv.ko: Is a directory
scripts/Makefile.modpost:125: recipe for target 'drivers/gpu/drm/etnaviv/etnaviv.ko' failed
make[1]: *** [drivers/gpu/drm/etnaviv/etnaviv.ko] Error 1
Makefile:1169: recipe for target 'modules' failed
make: *** [modules] Error 2

---EDIT: removed the folder, it compiled.
 
Last edited:

KidPaddle

Member
Joined
May 14, 2006
Messages
382
Location
Germany
Strange, i got a compiled module,

LD [M] drivers/gpu/drm/etnaviv/etnaviv.o
Building modules, stage 2.
MODPOST 1 modules
CC drivers/gpu/drm/etnaviv/etnaviv.mod.o
LD [M] drivers/gpu/drm/etnaviv/etnaviv.ko

modinfo shows
filename: drivers/gpu/drm/etnaviv/etnaviv.ko
alias: platform:etnaviv
license: GPL v2
description: etnaviv DRM Driver
author: Lucas Stach <l.stach@pengutronix.de>
author: Russell King <rmk+kernel@arm.linux.org.uk>
author: Christian Gmeiner <christian.gmeiner@gmail.com>
srcversion: 60CD5791D2D39168D66DC02
alias: of:N*T*Cmarvell,dove-gpu-subsystemC*
alias: of:N*T*Cmarvell,dove-gpu-subsystem
alias: of:N*T*Cfsl,imx-gpu-subsystemC*
alias: of:N*T*Cfsl,imx-gpu-subsystem
depends: drm
intree: Y
vermagic: 4.7.0-rc6-letux+ SMP preempt mod_unload modversions ARMv7 p2v8
parm: dump_core:bool
parm: reglog:Enable register read/write logging (bool)


I compiled this module with
make -C /lib/modules/4.7.0-rc6-letux+/build M=drivers/gpu/drm/etnaviv modules

I'm using kernel 4.7-rc6.

Thomas
 

Linux-SWAT

Hardcore Member
Joined
Feb 13, 2010
Messages
8,223
I have it now, but unfortunately changes nothing, I don't even see it in Xorg log.
 

zmatt

Active Member
Joined
Oct 31, 2015
Messages
70
Location
Netherlands
I have it now, but unfortunately changes nothing, I don't even see it in Xorg log.
You can't just modprobe a kernel driver and have it magically work. The kernel will load it but it will have no idea what it is for and it is left unused. Unlike USB or PCI devices which can be detected and recognized based on standardized embedded identification, there is no standard way to even detect let alone identify a platform device. These need to be described in Device Tree:

alias: of:N*T*Cmarvell,dove-gpu-subsystem
alias: of:N*T*Cfsl,imx-gpu-subsystem
This shows the kernel will use this driver if it finds a DT node with compatible="marvell,dove-gpu-subsystem" or compatible="fsl,imx-gpu-subsystem". This immediately raises the question why the driver uses different identifiers for these two particular instances of a GC core (e.g. platform-specific quirks?) and whether a third one needs to be added for our use case. I have not inspected the driver but this will need to be done.

Next up is adding the DT node itself, which describes any address ranges, clocks, and interrupts that the driver needs to know about, along with the compatible-property referencing the driver, and any driver-specific properties it might need. It also needs a ti,hwmods property referencing module prcm data embedded in the kernel. This ensures that the power management framework knows how to power the module up/down and enable/disable its clocks, without which any access attempted by the driver will result in a bus error. This hwmod data itself might not yet be in mainline linux hence also needs to be added.

For an example of this, see the two patches here which add a DT node and hwmod data for SGX. This DT node actually looks really iffy to me since the register range declared does not match the address in the DT node name and does not cover the whole peripheral. It was however copied from some TI tree and apparently does work somehow. If you don't want to dig deeply into how DT and hwmod stuff works, scavenging existing linux trees for useful scraps is a good strategy.

If you get a kernel panic but aren't sure whether to blame the driver or the DT/hwmod data, you may be able to investigate by using the uio_pdrv_genirq driver (kernel config option CONFIG_UIO_PDRV_GENIRQ): Add the DT node but prevent the driver from loading (by changing/removing the compatible-property in DT or just making sure the kernel can't find the kernel module) so it'll show up in /sys/bus/platform/devices. Say it's named bb2d, then echo bb2d >/sys/bus/platform/drivers/uio_pdrv_genirq/bind should make it appear as /dev/uio0. If you open this device it will trigger the power management framework to enable the device. If this doesn't crash then you can try to mmap() the device and access some harmless register (e.g. the word at offset 0x20 should be equal to 0x320 indicating a GC320, see TRM). If all of this seems to work then the DT/hwmod data is probably okay and debugging can shift to the driver.

Once you have the driver loading and successfully recognizing the GC320, then you can start trying to experiment with libetnaviv and stuff that uses it.

What's wrong with TI's GStreamer implementation?
I'm not so much worried about the userspace part as I am about kernel components it will undoubtedly require to load firmware blobs onto and otherwise interact with the hardware subsystems. But who knows, maybe it turns out to be relatively painless :)
 
Last edited:

Letalis Sonus

Advanced Member
Joined
Mar 5, 2009
Messages
1,287
it will undoubtedly require to load firmware blobs onto and otherwise interact with the hardware subsystems. But who knows, maybe it turns out to be relatively painless :)
As far as I can see the code for everything is available under a custom (but quite open) license. It looks like they are using the M4s to manage IVA-HD, which of course requires some firmware (both available as source code and binaries).

However, it looks like it expects the firmware to be already loaded, which is kind of annoying if one wants to use the M4s for something else.
 

Silent-Hunter

Hardcore Member
Joined
May 29, 2010
Messages
3,077
As far as I can see the code for everything is available under a custom (but quite open) license. It looks like they are using the M4s to manage IVA-HD, which of course requires some firmware (both available as source code and binaries).

However, it looks like it expects the firmware to be already loaded, which is kind of annoying if one wants to use the M4s for something else.
Wow, so accelerated video is pretty much a given?
 
Top