Download Pyra Debian OS (WIP)


I just want to test if windows move faster ;^) .
Yes, SD access is soooo sloooow !
 
KidPaddle said:
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.
Click to expand...
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.

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

Linux-SWAT said:
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.
Click to expand...
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...
 
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.

KidPaddle said:
I think, slaeshjag is right, that the build in kernel module etnaviv is not the right kernel module for 2D.
Click to expand...
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.
Click to expand...

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.
Click to expand...

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)
 
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.
 
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:
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
 
I have it now, but unfortunately changes nothing, I don't even see it in Xorg log.
 
Linux-SWAT said:
I have it now, but unfortunately changes nothing, I don't even see it in Xorg log.
Click to expand...

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:

KidPaddle said:
alias: of:N*T*Cmarvell,dove-gpu-subsystem
alias: of:N*T*Cfsl,imx-gpu-subsystem
Click to expand...

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.

Letalis Sonus said:
What's wrong with TI's GStreamer implementation?
Click to expand...

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:
zmatt said:
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 :)
Click to expand...
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.
 
Letalis Sonus said:
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.
Click to expand...
Wow, so accelerated video is pretty much a given?
 
You must log in or register to reply here.

Similar threads

yeoldegrove
build pyra Debian
Replies
19
Views
5K
logen
L
hns
Running Pyra-OS on Pandora
Replies
18
Views
8K
rSl
rSl
L
Installing debian onto pyra
Replies
5
Views
2K
hns
hns
sebt3
  • Sticky
Pyra pyra-builder: Docker based toolchain for pyra
Replies
4
Views
7K
sebt3
sebt3
FBnil
Hardening the Pyra (by hardening systemd services). Intended audience: Linux intermediate
Replies
8
Views
2K
TrashyMG
TrashyMG
Back
Top