Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
Hi all, based on initial work by Moaz Korena [1] and with the help of Adam Ford and Tony Lindgren, I have worked for a while on a new SGX driver for OMAP.
Now, I finally managed to write a master-Makefile that allows to build multiple variants of the sgx driver without having to config the build for a specific single SoC and forces us to choose the SGX version at compile time. This allows to build MULTI_PLATFORM kernels.
This means we currently get three different kernel modules: /lib/modules/4.15.0-rc9-letux+/kernel/drivers/staging/pvr/omap3/pvr_omap3630_sgx530_125.ko /lib/modules/4.15.0-rc9-letux+/kernel/drivers/staging/pvr/omap3/pvr_omap3_sgx530_121.ko /lib/modules/4.15.0-rc9-letux+/kernel/drivers/staging/pvr/omap3/pvr_ti335x_sgx530_125.ko
They are for: - DM3730 based devices (e.g. Torpedo DM3730, BeagleBoard XM, GTA04, Pandora 1GHz) - OMAP3530 based device (e.g. OpenPandora 600MHz, BeagleBoard C) - AM335x based devices (e.g. BeagleBone, PocketBeagle)
So in combination with proper DT entries the correct driver variant is automatically modprobed during boot. At least for OMAP3.
OMAP4+5 driver code is also included but not yet integrated/fixed.
The DM3730 and AM33xx versions work (up to a certain point I will describe below). OMAP3530 does not properly set up clocks and SoC interconnects.
For the AM335x there is a hack to keep clock running after deasserting reset, but for the OMAP3530 we still have to find the root of the trouble.
What is still missing is the framebuffer backend so the SGX is not told how to write to a display. Traditionally, there was omaplfb but it seems no longer be working. There is also some DRM stuff, but I wasn't able to compile and set it up so far.
So, running the SGX ClipBlit test succeeds until it fails with:
FAIL - PVRSRV_ERROR_NO_DC_DEVICES_FOUND(134)
The latest code is rebased on top of v4.15-rc9 and it suffices to configure for SGX and SGX_OMAP. It can be found here (or in the latest Letux release [2]):
https://github.com/goldelico/gta04-kernel/commits/work/letux-base/hns/gpu/om...
It consists of two groups of commits (separated by a MAINTAINERS patch):
1. fixes for SoC glue (e.g. clock, hw-mods, pdata-qirks, DT) to get the SGX initialized and access - most of them are already good enough for upstream review
2. source code for pvrsrvkm from TI GFX SDK (one version for omap3+4 and one for omap4+5) combined with patches and new Makefiles to get it compiled on v4.15
There are also two shell-script tools (Letux/root/sgxdump and Letux/root/gpu-demo) for user-space. They are useful for debugging. A compatible Debian package with the (closed source!) microkernel for SGX, libs and demos for OMAP3-ARMHF can be found here:
http://download.goldelico.com/letux-debian-rootfs/debian/dists/jessie/main/b...
What is the goal of this effort?
In the end we should have a single, generic SGX driver for all OMAP SoC variants sitting in mainline drivers/gpu/pvr. So the goal is to end the era of out-of tree SGX drivers for a significant portion of OMAP processors.
Maybe it could become a driver that even IMG and TI want to support by providing newer (and open source) user-space libraries and tools.
My personal goal so far was to make it a working demonstrator that can be used as a "good" reference for running "git bisect" to identify regressions introduced by future modifications.
What has to be done to polish the code beyond "seems to work"?
I see these topics (but there may be more):
* fix power and clock management weakness * fix issues with omap3530 (e.g. OpenPandora) * make code finally completely independent of SoC variant so that all differences are deduced from device tree and a single kernel module serves them all * get rid of -DSGX530 #ifdef etc. * remove #if LINUX_VERSION_CODE (unless someone sees need to backport to stable) * fix backend (omaplfb and/or omapdrm) * make it work on omap4 / omap5 and sgx540 / sgx544 * fix dmac flush etc. in services4/srvkm/env/linux/osfunc.c * simplify code where possible * clean up the code (e.g. replace camel-case function and variable names) * merge drivers/subdirectories for omap3+4 and omap4+5 * move from drivers/staging/pvr to drivers/gpu/pcr * support for non-OMAP SoC with PVR/SGX inside
This is far too much work for just a handful of people so a broader community should be involved.
What will be the next steps?
Tony suggested to publish this initial work on LKML and ask for integration into the staging tree. The rationale is that the code needs a lot of polishing and cleanup until it is something good for drivers/gpu. And collaboration on LKML and kernel.org becomes easier than having a private mailing list and git(hub) repo only.
Yes, that would be be a good step and now I think the package is ready to go.
And if someone could provide a fix for the FB/DRM setup it would also be a big step because we then can even demonstrate it by screen movies.
We also need to define maintainers who take care of changes and new patches (since I can't do that alone).
BR, Nikolaus
[1]: https://github.com/korena/bbb-workshop [2]: http://projects.goldelico.com/p/gta04-kernel/
Hi,
On 23/01/18 15:38, H. Nikolaus Schaller wrote:
In the end we should have a single, generic SGX driver for all OMAP SoC variants sitting in mainline drivers/gpu/pvr. So the goal is to end the era of out-of tree SGX drivers for a significant portion of OMAP processors.
I don't think that will ever happen, because there is no open source userspace library for SGX. That library is the "real" driver here. At least the policy has been (I believe it still is) that you can't have a driver in the kernel which can only be used with a closed source userspace component.
Tomi
On Tue, Jan 23, 2018 at 7:48 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
Hi,
On 23/01/18 15:38, H. Nikolaus Schaller wrote:
In the end we should have a single, generic SGX driver for all OMAP SoC variants sitting in mainline drivers/gpu/pvr. So the goal is to end the era of out-of tree SGX drivers for a significant portion of OMAP processors.
I don't think that will ever happen, because there is no open source userspace library for SGX. That library is the "real" driver here. At least the policy has been (I believe it still is) that you can't have a driver in the kernel which can only be used with a closed source userspace component.
TI maintains some sort of SGX library on their git repo if I am not mistaken. If we as a community can get the kernel setup enough and provide TI with patches to make the SGX library work again with omap36 and OMAP35 processors, would TI accept patches to their library? With the changes so far, we're pretty close to getting the kernel the necessary infrastructure to setup/configure the hardware and provide the closed source blobs the necessary hooks to operate.
Secondly, Nikolaus and Tony have done a great job in trying to get the hwmods and reset stuff working (mostly) for the omap36 and to some extent the am33x. Would it be possible to get some TI assistance in determining what work is left to re-integrate compatibility into either the DRM of FB drivers? The SGX drivers appear to have been broken for years and mostly abandoned by TI. I know the OMAP3, OMAP4 and AM33 are older architectures, but having TI provide the remaining assistance would go a long way in showing they still care about their products.
Tomi
Thank you,
adam
-- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Hi Adam,
Am 23.01.2018 um 15:30 schrieb Adam Ford aford173@gmail.com:
On Tue, Jan 23, 2018 at 7:48 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
Hi,
On 23/01/18 15:38, H. Nikolaus Schaller wrote:
In the end we should have a single, generic SGX driver for all OMAP SoC variants sitting in mainline drivers/gpu/pvr. So the goal is to end the era of out-of tree SGX drivers for a significant portion of OMAP processors.
I don't think that will ever happen, because there is no open source userspace library for SGX. That library is the "real" driver here. At least the policy has been (I believe it still is) that you can't have a driver in the kernel which can only be used with a closed source userspace component.
TI maintains some sort of SGX library on their git repo if I am not mistaken.
Yes, there are some parts and I fetched the ompa4+5 tree from
git://git.ti.com/graphics/omap5-sgx-ddk-linux.git
but the last commit is 3 years old.
If we as a community can get the kernel setup enough and provide TI with patches to make the SGX library work again with omap36 and OMAP35 processors, would TI accept patches to their library?
It would be an alternative, but the key task is to get a team willing to fix, maintain and update things. The location of the git repo is a little arbitrary, although I'd prefer kernel.org to address the broadest public.
And to keep the big picture in mind, there are non-TI SoC using the same PVR/SGX which I hope will finally merge. This would become a little more difficult if the work is done on the TI git where it is probably not easy to get push access.
With the changes so far, we're pretty close to getting the kernel the necessary infrastructure to setup/configure the hardware and provide the closed source blobs the necessary hooks to operate.
Secondly, Nikolaus and Tony have done a great job in trying to get the hwmods and reset stuff working (mostly) for the omap36 and to some extent the am33x. Would it be possible to get some TI assistance in determining what work is left to re-integrate compatibility into either the DRM of FB drivers? The SGX drivers appear to have been broken for years and mostly abandoned by TI. I know the OMAP3, OMAP4 and AM33 are older architectures, but having TI provide the remaining assistance would go a long way in showing they still care about their products.
Indeed!
BR, Nikolaus
On 23/01/18 16:30, Adam Ford wrote:
On Tue, Jan 23, 2018 at 7:48 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
Hi,
On 23/01/18 15:38, H. Nikolaus Schaller wrote:
In the end we should have a single, generic SGX driver for all OMAP SoC variants sitting in mainline drivers/gpu/pvr. So the goal is to end the era of out-of tree SGX drivers for a significant portion of OMAP processors.
I don't think that will ever happen, because there is no open source userspace library for SGX. That library is the "real" driver here. At least the policy has been (I believe it still is) that you can't have a driver in the kernel which can only be used with a closed source userspace component.
TI maintains some sort of SGX library on their git repo if I am not mistaken. If we as a community can get the kernel setup enough and provide TI with patches to make the SGX library work again with omap36 and OMAP35 processors, would TI accept patches to their library? With the changes so far, we're pretty close to getting the kernel the necessary infrastructure to setup/configure the hardware and provide the closed source blobs the necessary hooks to operate.
TI has SGX kernel driver sources available and SGX library binary blobs available for the SoCs TI supports currently (I think that's AM5/DRA7/AM4/AM335x).
git://git.ti.com/graphics/omap5-sgx-ddk-linux.git ti-img-sgx/1.14.3699939/k4.9
git://git.ti.com/graphics/omap5-sgx-ddk-um-linux.git ti-img-sgx/1.14.3699939
The community cannot provide patches for the libraries as they are closed source.
Secondly, Nikolaus and Tony have done a great job in trying to get the hwmods and reset stuff working (mostly) for the omap36 and to some extent the am33x. Would it be possible to get some TI assistance in determining what work is left to re-integrate compatibility into either the DRM of FB drivers? The SGX drivers appear to have been broken for years and mostly abandoned by TI. I know the OMAP3, OMAP4 and AM33 are older architectures, but having TI provide the remaining assistance would go a long way in showing they still care about their products.
My guess is that the old SGX driver and libraries are quite incompatible with the latest ones, so (in my personal opinion) I doubt TI can give any support for the old ones.
Tomi
Hi Tomi,
Am 23.01.2018 um 16:22 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 23/01/18 16:30, Adam Ford wrote:
On Tue, Jan 23, 2018 at 7:48 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
Hi,
On 23/01/18 15:38, H. Nikolaus Schaller wrote:
In the end we should have a single, generic SGX driver for all OMAP SoC variants sitting in mainline drivers/gpu/pvr. So the goal is to end the era of out-of tree SGX drivers for a significant portion of OMAP processors.
I don't think that will ever happen, because there is no open source userspace library for SGX. That library is the "real" driver here. At least the policy has been (I believe it still is) that you can't have a driver in the kernel which can only be used with a closed source userspace component.
TI maintains some sort of SGX library on their git repo if I am not mistaken. If we as a community can get the kernel setup enough and provide TI with patches to make the SGX library work again with omap36 and OMAP35 processors, would TI accept patches to their library? With the changes so far, we're pretty close to getting the kernel the necessary infrastructure to setup/configure the hardware and provide the closed source blobs the necessary hooks to operate.
TI has SGX kernel driver sources available and SGX library binary blobs available for the SoCs TI supports currently (I think that's AM5/DRA7/AM4/AM335x).
git://git.ti.com/graphics/omap5-sgx-ddk-linux.git ti-img-sgx/1.14.3699939/k4.9
git://git.ti.com/graphics/omap5-sgx-ddk-um-linux.git ti-img-sgx/1.14.3699939
Yes, that is what I want this work be based on.
The community cannot provide patches for the libraries as they are closed source.
That is not the goal of the project.
Secondly, Nikolaus and Tony have done a great job in trying to get the hwmods and reset stuff working (mostly) for the omap36 and to some extent the am33x. Would it be possible to get some TI assistance in determining what work is left to re-integrate compatibility into either the DRM of FB drivers? The SGX drivers appear to have been broken for years and mostly abandoned by TI. I know the OMAP3, OMAP4 and AM33 are older architectures, but having TI provide the remaining assistance would go a long way in showing they still care about their products.
My guess is that the old SGX driver and libraries are quite incompatible with the latest ones, so (in my personal opinion) I doubt TI can give any support for the old ones.
The key problem is that it is more broken that it needs to be as the demonstrator patch set shows. There is only one piece missing to make blobs + kernel driver work on 4.15-rc9 again.
And if we don't do the first step, we will never be able to improve it.
BR, Nikolaus
On 23/01/18 18:18, H. Nikolaus Schaller wrote:
The community cannot provide patches for the libraries as they are closed source.
That is not the goal of the project.
Yep, I was replying to the above comment about "community providing patches to the SGX library" from Adam. Or maybe I misunderstood what he said.
Secondly, Nikolaus and Tony have done a great job in trying to get the hwmods and reset stuff working (mostly) for the omap36 and to some extent the am33x. Would it be possible to get some TI assistance in determining what work is left to re-integrate compatibility into either the DRM of FB drivers? The SGX drivers appear to have been broken for years and mostly abandoned by TI. I know the OMAP3, OMAP4 and AM33 are older architectures, but having TI provide the remaining assistance would go a long way in showing they still care about their products.
My guess is that the old SGX driver and libraries are quite incompatible with the latest ones, so (in my personal opinion) I doubt TI can give any support for the old ones.
The key problem is that it is more broken that it needs to be as the
Is something ever as broken as it needs to be? =)
demonstrator patch set shows. There is only one piece missing to make blobs + kernel driver work on 4.15-rc9 again.
And if we don't do the first step, we will never be able to improve it.
I'm not quite sure I understand what you're trying here. You said that you want this work based on the latest SGX kernel driver from TI. That driver is for the latest userspace libraries. I don't think it will ever work with the old libraries.
Tomi
Am 23.01.2018 um 17:41 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 23/01/18 18:18, H. Nikolaus Schaller wrote:
The community cannot provide patches for the libraries as they are closed source.
That is not the goal of the project.
Yep, I was replying to the above comment about "community providing patches to the SGX library" from Adam. Or maybe I misunderstood what he said.
Ah, ok. The confusion is that you see the library as the "real" driver here while we refer with "driver" to the kernel module only.
Secondly, Nikolaus and Tony have done a great job in trying to get the hwmods and reset stuff working (mostly) for the omap36 and to some extent the am33x. Would it be possible to get some TI assistance in determining what work is left to re-integrate compatibility into either the DRM of FB drivers? The SGX drivers appear to have been broken for years and mostly abandoned by TI. I know the OMAP3, OMAP4 and AM33 are older architectures, but having TI provide the remaining assistance would go a long way in showing they still care about their products.
My guess is that the old SGX driver and libraries are quite incompatible with the latest ones, so (in my personal opinion) I doubt TI can give any support for the old ones.
The key problem is that it is more broken that it needs to be as the
Is something ever as broken as it needs to be? =)
there was a typo
s/more broken that it needs/more broken than it needs/
demonstrator patch set shows. There is only one piece missing to make blobs + kernel driver work on 4.15-rc9 again.
And if we don't do the first step, we will never be able to improve it.
I'm not quite sure I understand what you're trying here. You said that you want this work based on the latest SGX kernel driver from TI. That driver is for the latest userspace libraries.
What is the problem of using the matching user space libraries?
I don't think it will ever work with the old libraries.
AFAIK, nobody wants to achieve that. It is about using the latest libs for each SoC. Those are not the same, but it appears according to my analyses that this does not influence the driver code. The older and newer driver versions are not very different. They just add more and more #ifdefs for kernel API changes and SGX errata.
As written in another mail, SGX firmware and user-space libs are sort of "application" for the SGX. Those must match of course. If you take old firmware and old libs they should work. If you take new libs and firmware they should work as well. With the same driver.
If in the future someone manages to reverse engineer the SGX and writes a new firmware + user-space that should also work with the same driver.
The kernel driver just makes sure that the user-space can communicate with the SGX, i.e. can load firmware and exchange shaders, images etc.
So to summarize: the sgx530 user-space binaries already run on dm3730 and am335x and the sgx544 should run on omap5.
BR, Nikolaus
On 23/01/18 19:15, H. Nikolaus Schaller wrote:
Am 23.01.2018 um 17:41 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 23/01/18 18:18, H. Nikolaus Schaller wrote:
The community cannot provide patches for the libraries as they are closed source.
That is not the goal of the project.
Yep, I was replying to the above comment about "community providing patches to the SGX library" from Adam. Or maybe I misunderstood what he said.
Ah, ok. The confusion is that you see the library as the "real" driver here while we refer with "driver" to the kernel module only.
Well, Adam said "library", and I don't think that means the kernel driver. Anyway, that's not important.
Yes, while kind of correct, I think it's slightly misleading to talk about SGX driver and refer only to the kernel part. I think "driver" is often taken to mean a piece of code that enables you to use a piece of HW. That's not the case here, as you can't do anything without the matching closed-source userspace libraries. You always need both, individually they are useless.
Talking about SGX driver is fine when it's clear from the context that it's about the kernel side, but I usually like to specify kernel or userspace when talking about SGX to avoid any unclarities.
demonstrator patch set shows. There is only one piece missing to make blobs + kernel driver work on 4.15-rc9 again.
And if we don't do the first step, we will never be able to improve it.
I'm not quite sure I understand what you're trying here. You said that you want this work based on the latest SGX kernel driver from TI. That driver is for the latest userspace libraries.
What is the problem of using the matching user space libraries?
Nothing, if they provide the features you need. But they only support SoCs that TI currently support, so no OMAP3 (as far as I know). If the latest SGX driver works for you, I very much recommend using it rather than the old one.
I don't think it will ever work with the old libraries.
AFAIK, nobody wants to achieve that. It is about using the latest libs for each SoC. Those are not the same, but it appears according to my analyses that this does not influence the driver code. The older and newer driver versions are not very different. They just add more and more #ifdefs for kernel API changes and SGX errata.
Ok, if that's the case, then it's very good. I was under the impression that there are big differences. If we can have a single kernel driver that supports different versions of userspace binaries, it will help things quite a bit.
As written in another mail, SGX firmware and user-space libs are sort of "application" for the SGX. Those must match of course. If you take old firmware and old libs they should work. If you take new libs and firmware they should work as well. With the same driver.
If in the future someone manages to reverse engineer the SGX and writes a new firmware + user-space that should also work with the same driver.
If someone manages to reverse engineer SGX, I would imagine that we would be better off with a totally new kernel side driver =).
The kernel driver just makes sure that the user-space can communicate with the SGX, i.e. can load firmware and exchange shaders, images etc.
So to summarize: the sgx530 user-space binaries already run on dm3730 and am335x and the sgx544 should run on omap5.
So you are using the old userspace binaries for dm3730, and the latest ones for am335x and omap5? Or that's still on the works?
Tomi
Hi Tomi,
Am 23.01.2018 um 14:48 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
Hi,
On 23/01/18 15:38, H. Nikolaus Schaller wrote:
In the end we should have a single, generic SGX driver for all OMAP SoC variants sitting in mainline drivers/gpu/pvr. So the goal is to end the era of out-of tree SGX drivers for a significant portion of OMAP processors.
I don't think that will ever happen, because there is no open source userspace library for SGX. That library is the "real" driver here.
Yes and no... It can be seen as application software for the SGX and consists of a microkernel and user-space libs to communicate with it. Both are unfortunately closed source but no kernel components and need no integration. Just data sent back and forth through open source drivers.
At least the policy has been (I believe it still is) that you can't have a driver in the kernel which can only be used with a closed source userspace component.
I see counter-examples, mainly in the WiFi area. There are drivers for Realtek, Marvell, TI WiFI chips and firmware is separate and required to make it useful.
Other examples may also exist.
A big question is if we want to wait forever until user-space becomes open of if we lay a foundation to make it easier to become open (reverse engineered open-source user-space for example).
BR, Nikolaus
On 23/01/18 16:41, H. Nikolaus Schaller wrote:
Hi Tomi,
Am 23.01.2018 um 14:48 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
Hi,
On 23/01/18 15:38, H. Nikolaus Schaller wrote:
In the end we should have a single, generic SGX driver for all OMAP SoC variants sitting in mainline drivers/gpu/pvr. So the goal is to end the era of out-of tree SGX drivers for a significant portion of OMAP processors.
I don't think that will ever happen, because there is no open source userspace library for SGX. That library is the "real" driver here.
Yes and no... It can be seen as application software for the SGX and consists of a microkernel and user-space libs to communicate with it. Both are unfortunately closed source but no kernel components and need no integration. Just data sent back and forth through open source drivers.
At least the policy has been (I believe it still is) that you can't have a driver in the kernel which can only be used with a closed source userspace component.
I see counter-examples, mainly in the WiFi area. There are drivers for Realtek, Marvell, TI WiFI chips and firmware is separate and required to make it useful.
Other examples may also exist.
Well, you can refer to
https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace...
Tomi
Am 23.01.2018 um 16:34 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 23/01/18 16:41, H. Nikolaus Schaller wrote:
Hi Tomi,
Am 23.01.2018 um 14:48 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
Hi,
On 23/01/18 15:38, H. Nikolaus Schaller wrote:
In the end we should have a single, generic SGX driver for all OMAP SoC variants sitting in mainline drivers/gpu/pvr. So the goal is to end the era of out-of tree SGX drivers for a significant portion of OMAP processors.
I don't think that will ever happen, because there is no open source userspace library for SGX. That library is the "real" driver here.
Yes and no... It can be seen as application software for the SGX and consists of a microkernel and user-space libs to communicate with it. Both are unfortunately closed source but no kernel components and need no integration. Just data sent back and forth through open source drivers.
At least the policy has been (I believe it still is) that you can't have a driver in the kernel which can only be used with a closed source userspace component.
I see counter-examples, mainly in the WiFi area. There are drivers for Realtek, Marvell, TI WiFI chips and firmware is separate and required to make it useful.
Other examples may also exist.
Well, you can refer to
https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace...
Interesting.
But I don't see how it is related to OMAP-SGX at all (except that it is about a GFX subsystem).
I understand that this is for the case we would plan to craft a proper DRM based solution so that DRM API and user space libs can be used.
This is obviously far beyond feasibility and maybe the fifth or tenth step.
But we want to do what can be done.
My idea is also to get it placed in drivers/staging/pvr and not drivers/gpu/drm.
BR, Nikolaus
On 23/01/18 18:22, H. Nikolaus Schaller wrote:
Well, you can refer to
https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace...
Interesting.
But I don't see how it is related to OMAP-SGX at all (except that it is about a GFX subsystem).
I understand that this is for the case we would plan to craft a proper DRM based solution so that DRM API and user space libs can be used.
At least the latest SGX driver is DRM based. But true, the old driver may not be. But if it's not, I think it's even more unlikely that it would be merged to mainline.
This is obviously far beyond feasibility and maybe the fifth or tenth step.
But we want to do what can be done.
My idea is also to get it placed in drivers/staging/pvr and not drivers/gpu/drm.
I don't think staging wants to merge something that's never going to be moved out from staging.
And note that I'm not trying dismiss the work you've done, I think it's great to clean up the old driver if people use it. I'm just trying to be realistic about the possible goals =).
Tomi
* Tomi Valkeinen tomi.valkeinen@ti.com [180123 16:47]:
On 23/01/18 18:22, H. Nikolaus Schaller wrote:
Well, you can refer to
https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace...
Interesting.
But I don't see how it is related to OMAP-SGX at all (except that it is about a GFX subsystem).
I understand that this is for the case we would plan to craft a proper DRM based solution so that DRM API and user space libs can be used.
At least the latest SGX driver is DRM based. But true, the old driver may not be. But if it's not, I think it's even more unlikely that it would be merged to mainline.
This is obviously far beyond feasibility and maybe the fifth or tenth step.
But we want to do what can be done.
My idea is also to get it placed in drivers/staging/pvr and not drivers/gpu/drm.
I don't think staging wants to merge something that's never going to be moved out from staging.
We really need some coordinated effort to get the driver kernel parts to usable state though. And considering the number of people involved I think staging is the best place to do it. Then what happens after that is of course up in the air as always. In the worst case it will get just dropped lik the TI dsp stuff based on zero effort :)
And there finally seems to some effort going on by the chromeos guys.
FYI again if it was not mentioned earlier, here's the thread for upstreaming Roque support?
"[POC 00/16] Chromebook R13 GPU driver port":
https://lists.freedesktop.org/archives/dri-devel/2017-November/157737.html
No idea how much of that will be usable for SGX though.
Regards,
Tony
On 23/01/18 19:56, Tony Lindgren wrote:
We really need some coordinated effort to get the driver kernel parts to usable state though. And considering the number of people involved I think staging is the best place to do it. Then what happens after that is of course up in the air as always. In the worst case it will get just dropped lik the TI dsp stuff based on zero effort :)
Yes, I have nothing against the idea. My fear is that it'll be difficult to have a single SGX kernel driver which works for all the SGX userspace binaries. As the kernel and userspace parts are always shipped as a pair, my guess is that there has never been any attempt to keep the UAPI stable. But I'm basing my guess on no actual knowledge, so I'm happy to be proven wrong =).
And there finally seems to some effort going on by the chromeos guys.
FYI again if it was not mentioned earlier, here's the thread for upstreaming Roque support?
"[POC 00/16] Chromebook R13 GPU driver port":
https://lists.freedesktop.org/archives/dri-devel/2017-November/157737.html
No idea how much of that will be usable for SGX though.
If I understood right, it's not about upstreaming. It was about getting the Rogue userspace binaries work on top of mainline, i.e. porting the kernel driver on top of mainline.
And, again, my understanding of the "DRM philosophy" is that having kernel drivers like these is explicitly forbidden in the mainline. Which is why e.g. there's no nvidia kernel driver.
Tomi
Hi,
Am 24.01.2018 um 08:45 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 23/01/18 19:56, Tony Lindgren wrote:
We really need some coordinated effort to get the driver kernel parts to usable state though. And considering the number of people involved I think staging is the best place to do it. Then what happens after that is of course up in the air as always. In the worst case it will get just dropped lik the TI dsp stuff based on zero effort :)
Yes, I have nothing against the idea. My fear is that it'll be difficult to have a single SGX kernel driver which works for all the SGX userspace binaries. As the kernel and userspace parts are always shipped as a pair,
This seems to have different reasons. As far as I can deduce from the code IMG provided a core (everyhing using the camel-case functions) matching different SGX versions. Newer versions seem to include more SGX support than older ones. I.e. SGX544 is only in the latest ones.
Now, TI did augment that with proper glue code for the SoC. This sits mainly in services4/system/$SOC_VERSION
This has been updated from time to time and more and more kernel API changes have been covered by conditional compiles.
This means that basically the latest code should still compile for/run for 2.6.32.
It may just have been far too much work to test every potential combination and therefore sgx user-space and kernel versions seem to be synced.
my guess is that there has never been any attempt to keep the UAPI stable. But I'm basing my guess on no actual knowledge, so I'm happy to be proven wrong =).
The other question is why this should depend on any other API?
As far as I understand there is a /proc/pvr device and a handful of ioctls for it. And mmap() is used to give the user-space libs access to the SGX. There is also some DMA stuff.
This basic principle seems not to have changed between all version. What must match is the microkernel version running on the SGX and the user-space library blob.
Because they define an IMG internal protocol to send images and shader commands around. But AFAIK the mechanism to communicate hasn't changed fundamentally.
But this microkernel is also part of user-spacecode (compiled into pvrsrvctl) and not any kernel code. Kernel only provides a communication mechanism like e.g. Ethernet. It is independent on which data you copy from one user-space to some "remote" device.
Well, I may have overlooked the one counter-example.
And there finally seems to some effort going on by the chromeos guys.
FYI again if it was not mentioned earlier, here's the thread for upstreaming Roque support?
"[POC 00/16] Chromebook R13 GPU driver port":
https://lists.freedesktop.org/archives/dri-devel/2017-November/157737.html
No idea how much of that will be usable for SGX though.
If I understood right, it's not about upstreaming. It was about getting the Rogue userspace binaries work on top of mainline, i.e. porting the kernel driver on top of mainline.
And, again, my understanding of the "DRM philosophy" is that having kernel drivers like these is explicitly forbidden in the mainline. Which is why e.g. there's no nvidia kernel driver.
Well, if the "DRM philosophy" requires to modify the communication protocols between the sgx libs and the sgx microkernel, then we have a problem.
BR, Nikolaus
Hi,
* H. Nikolaus Schaller hns@goldelico.com [180125 09:46]:
Am 24.01.2018 um 08:45 schrieb Tomi Valkeinen tomi.valkeinen@ti.com: And, again, my understanding of the "DRM philosophy" is that having kernel drivers like these is explicitly forbidden in the mainline. Which is why e.g. there's no nvidia kernel driver.
Well, if the "DRM philosophy" requires to modify the communication protocols between the sgx libs and the sgx microkernel, then we have a problem.
Well we already have minimal sgx540 2d acceleration in the mainline kernel in the intel driver drivers/gpu/drm/gma500. So we could share that code and do a drm sgx driver based on that.
Sure it won't be probably any faster, but still handles the hardware so then anybody who wants to can attempt to patch it further.
To see the sgx540 read and write access in the driver:
$ git grep [RW]SGX drivers/gpu/drm/gma500/
Then see drivers/gpu/drm/gma500/accel_2d.c for psbfb_copyarea() and psbfb_copyarea_accel().
Regards,
Tony
Am 23.01.2018 um 17:47 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 23/01/18 18:22, H. Nikolaus Schaller wrote:
Well, you can refer to
https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace...
Interesting.
But I don't see how it is related to OMAP-SGX at all (except that it is about a GFX subsystem).
I understand that this is for the case we would plan to craft a proper DRM based solution so that DRM API and user space libs can be used.
At least the latest SGX driver is DRM based.
Is it DRM based or does it "use" DRM for allocating the framebuffer?
I have studied the code a little but did not yet understand how to use it. Tony has recommended to make this project more public to get help for making this work because someone may be able to help fixing it.
But true, the old driver may not be.
At least it has a -DDRM compile option. Maybe the 5.0 drivers need a little help by backporting things from 6.0.
Or both can be merged by forward-porting sgx530 support into the 6.0 drivers.
The code structure of both drivers is the same, just diffs here and there.
For example services4/3rdparty/linux_drm/pvr_drm_stubs.c has just 4 diffs. Of course some files have been completely overhauled, but the structure has remained the same.
But if it's not, I think it's even more unlikely that it would be merged to mainline.
Yes, that might happen, but we don't know before we try.
And of course it depends on what the omap community wants to have and how intensive it asks for inclusion of such things.
This is why I appreciate Tony's idea to make it known to linux-omap@vger.kernel.org soon to get a broader set of opinions and hopefully support.
This is obviously far beyond feasibility and maybe the fifth or tenth step.
But we want to do what can be done.
My idea is also to get it placed in drivers/staging/pvr and not drivers/gpu/drm.
I don't think staging wants to merge something that's never going to be moved out from staging.
Yes, that can happen. But do we really know before?
And note that I'm not trying dismiss the work you've done, I think it's great to clean up the old driver if people use it. I'm just trying to be realistic about the possible goals =).
Well, I have myself been too many times "realistic" just to see others do exactly or almost the same. And succeed...
BR and thanks, Nikolaus
On 23/01/18 19:56, H. Nikolaus Schaller wrote:
Am 23.01.2018 um 17:47 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 23/01/18 18:22, H. Nikolaus Schaller wrote:
Well, you can refer to
https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace...
Interesting.
But I don't see how it is related to OMAP-SGX at all (except that it is about a GFX subsystem).
I understand that this is for the case we would plan to craft a proper DRM based solution so that DRM API and user space libs can be used.
At least the latest SGX driver is DRM based.
Is it DRM based or does it "use" DRM for allocating the framebuffer?
SGX appears as a DRM device, so yes, it is DRM based. To be more exact, I think the kernel driver supports different options on how to compile it. We configure it to be a DRM device.
I have studied the code a little but did not yet understand how to use it. Tony has recommended to make this project more public to get help for making this work because someone may be able to help fixing it.
But true, the old driver may not be.
At least it has a -DDRM compile option. Maybe the 5.0 drivers need a little help by backporting things from 6.0.
Or both can be merged by forward-porting sgx530 support into the 6.0 drivers.
Hmm, I'm not familiar with these versions... Those are TI graphics SDK versions, I presume? I think anything called "Graphics SDK" is quite old. The latest SGX DDK is 1.14 which is, afaik, available in TI's processor SDK or via the git branches I pointed to.
Tomi
Am 24.01.2018 um 08:57 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 23/01/18 19:56, H. Nikolaus Schaller wrote:
Am 23.01.2018 um 17:47 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 23/01/18 18:22, H. Nikolaus Schaller wrote:
Well, you can refer to
https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace...
Interesting.
But I don't see how it is related to OMAP-SGX at all (except that it is about a GFX subsystem).
I understand that this is for the case we would plan to craft a proper DRM based solution so that DRM API and user space libs can be used.
At least the latest SGX driver is DRM based.
Is it DRM based or does it "use" DRM for allocating the framebuffer?
SGX appears as a DRM device, so yes, it is DRM based. To be more exact, I think the kernel driver supports different options on how to compile it. We configure it to be a DRM device.
Yes, it has two: * omaplfb * DRM
neither of these currently compile with my code :(
So that is indeed the main working site.
I have studied the code a little but did not yet understand how to use it. Tony has recommended to make this project more public to get help for making this work because someone may be able to help fixing it.
But true, the old driver may not be.
At least it has a -DDRM compile option. Maybe the 5.0 drivers need a little help by backporting things from 6.0.
Or both can be merged by forward-porting sgx530 support into the 6.0 drivers.
Hmm, I'm not familiar with these versions... Those are TI graphics SDK versions, I presume? I think anything called "Graphics SDK" is quite old. The latest SGX DDK is 1.14 which is, afaik, available in TI's processor SDK or via the git branches I pointed to.
Yes, this also supports the am33xx:
https://e2e.ti.com/support/embedded/linux/f/354/p/567306/2080513
I think the version schemes by TI and IMG are mixed. IMG scheme is SGX DDK 1.9, 1.10, 1.14 etc. While TI has (had?) Graphics SDK 4, SDK5, SDK6 based on one of the IMG DDKs.
I currently have in use:
a) omap3/am33xx: Graphics_SDK_5_01_01_02
The software on the SGX identifies itself as
root@letux:~# cat /proc/pvr/version Version SGX_DDK_Linux_CustomerTI sgxddk 1.10@2359475 (release) omap_sgx System Version String: None root@letux:~#
So this is currently SGX DDK 1.10.
This runs unmodified on am3358 and dm3730 so I expect no problem of upgrading to SGX DDK 1.14 for both of them.
b) omap4/5 from git://git.ti.com/graphics/omap5-sgx-ddk-linux.git commit: 430673f78b79eccdf308a6bbfb524209b485d2cc
I don't have it running so that I don't know the exact version it reports.
One more observation: there is no major release step in SGX DDK, i.e. it just moved from 1.9 to 1.10 and apparently 1.14.
Interestingly, both the older and the newer Graphics_SDK claim to support omap4 which seems to confirm that there are only minor differences between SoC and kernel drivers.
IMHO the user-space libs are tied to a specific IMG DDK version while SoC support is tied to a Graphics_SDK version.
This is why I think it could be possible to backport/forward-port and mix omap3/4 driver with omap4/5 driver to get a single kernel driver module for all of them.
Anyways, I could live for a while with a situation where we have different drivers for omap3/4 and omap4/5.
BR, Nikolaus
Am 24.01.2018 um 08:57 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
old. The latest SGX DDK is 1.14 which is, afaik, available in TI's processor SDK or via the git branches I pointed to.
$ git for-each-ref --sort=-committerdate refs/remotes/ti-sgx544/ 0086977380d3320d70a3abc78b95fa0641427073 commit refs/remotes/ti-sgx544/ti-img-sgx/1.14.3699939/k4.9 fd47e44b18944cf7ade480ac67a9c0172619ff7e commit refs/remotes/ti-sgx544/ti-img-sgx/1.14.3699939/k4.4 877a45ba3797fecdadcae35cc09103e9bec72b0e commit refs/remotes/ti-sgx544/dra7/k3.14 fed0756f1b8b9d526da2821635c7d742989d47c3 commit refs/remotes/ti-sgx544/ti-img-sgx/1.14.3699939/k4.1 cb46ba4d0c900f89f7ec0284f9803d476bfa98de commit refs/remotes/ti-sgx544/img-sgx c53a5dfb9f4d5612c372ec8e252cb13a731c9c10 commit refs/remotes/ti-sgx544/dra7/k4.1 f7ae3f68dd6a05f67b15702b823ed15d2c03105d commit refs/remotes/ti-sgx544/am4/k4.1 8b71d01c7f2d8d1b00d9d5255536da66a8bdf790 commit refs/remotes/ti-sgx544/am4/k3.14 c5a0d8c31ac338c759163edb4c295883ea2adc35 commit refs/remotes/ti-sgx544/next a24ae6b2573b7eb1dc94473aa9953b964079b5c6 commit refs/remotes/ti-sgx544/dra7/experimental 430673f78b79eccdf308a6bbfb524209b485d2cc commit refs/remotes/ti-sgx544/master 0912e7542f34413b9a52119b22e807532221d461 commit refs/remotes/ti-sgx544/dra7/k3.12 ce8e788072e2f72aaf8c09bdd6a6436bec9ddfb6 commit refs/remotes/ti-sgx544/dra7/k3.8 $
It seems as if the ti-img-sgx/1.14.3699939/k4.9 is indeed the newest one. I'll look into it and compare.
BR, Nikolaus
Hi,
Am 25.01.2018 um 11:18 schrieb H. Nikolaus Schaller hns@goldelico.com:
Am 24.01.2018 um 08:57 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
old. The latest SGX DDK is 1.14 which is, afaik, available in TI's processor SDK or via the git branches I pointed to.
$ git for-each-ref --sort=-committerdate refs/remotes/ti-sgx544/ 0086977380d3320d70a3abc78b95fa0641427073 commit refs/remotes/ti-sgx544/ti-img-sgx/1.14.3699939/k4.9 fd47e44b18944cf7ade480ac67a9c0172619ff7e commit refs/remotes/ti-sgx544/ti-img-sgx/1.14.3699939/k4.4 877a45ba3797fecdadcae35cc09103e9bec72b0e commit refs/remotes/ti-sgx544/dra7/k3.14 fed0756f1b8b9d526da2821635c7d742989d47c3 commit refs/remotes/ti-sgx544/ti-img-sgx/1.14.3699939/k4.1 cb46ba4d0c900f89f7ec0284f9803d476bfa98de commit refs/remotes/ti-sgx544/img-sgx c53a5dfb9f4d5612c372ec8e252cb13a731c9c10 commit refs/remotes/ti-sgx544/dra7/k4.1 f7ae3f68dd6a05f67b15702b823ed15d2c03105d commit refs/remotes/ti-sgx544/am4/k4.1 8b71d01c7f2d8d1b00d9d5255536da66a8bdf790 commit refs/remotes/ti-sgx544/am4/k3.14 c5a0d8c31ac338c759163edb4c295883ea2adc35 commit refs/remotes/ti-sgx544/next a24ae6b2573b7eb1dc94473aa9953b964079b5c6 commit refs/remotes/ti-sgx544/dra7/experimental 430673f78b79eccdf308a6bbfb524209b485d2cc commit refs/remotes/ti-sgx544/master 0912e7542f34413b9a52119b22e807532221d461 commit refs/remotes/ti-sgx544/dra7/k3.12 ce8e788072e2f72aaf8c09bdd6a6436bec9ddfb6 commit refs/remotes/ti-sgx544/dra7/k3.8 $
It seems as if the ti-img-sgx/1.14.3699939/k4.9 is indeed the newest one. I'll look into it and compare.
I haven't found time to start experiments, but it looks as if *does* support a lot of different SoC, even some Non-TI:
$ ls omap5-sgx-ddk-linux/eurasia_km/services4/system cedarview_linux include omap omap4 omap5 poulsbo sgx_jz4780 sgx_nohw sgx_pc_i686_tc3 sunxi $
Which means that this is already a much more universal driver than I have expected. The 'omap' subdirectory should IMHO be for OMAP3 + AM335x.
All this indicates that there is (was?) already a project (at IMG?) with similar goals.
So it is worth to give it a try to take this code (plus matching user-space) and try to compile it for OMAP3. And fix what is needed for 4.15.
This does not make the previous for OMAP3/AM335x work useless - it is very useful to know what to expect and compare if something does not work with the new code.
In the long run I even more believe that the differences in eurasia_km/services4/system/* should and can be handled by DT and a generic backend driver for all systems.
Maybe I can invest some time into experiments after FOSDEM.
BR, Nikolaus
Hi,
On 23/01/2018 14:38, H. Nikolaus Schaller wrote:
Hi all, based on initial work by Moaz Korena [1] and with the help of Adam Ford and Tony Lindgren, I have worked for a while on a new SGX driver for OMAP.
Now, I finally managed to write a master-Makefile that allows to build multiple variants of the sgx driver without having to config the build for a specific single SoC and forces us to choose the SGX version at compile time. This allows to build MULTI_PLATFORM kernels.
This means we currently get three different kernel modules: /lib/modules/4.15.0-rc9-letux+/kernel/drivers/staging/pvr/omap3/pvr_omap3630_sgx530_125.ko /lib/modules/4.15.0-rc9-letux+/kernel/drivers/staging/pvr/omap3/pvr_omap3_sgx530_121.ko /lib/modules/4.15.0-rc9-letux+/kernel/drivers/staging/pvr/omap3/pvr_ti335x_sgx530_125.ko
They are for:
- DM3730 based devices (e.g. Torpedo DM3730, BeagleBoard XM, GTA04, Pandora 1GHz)
- OMAP3530 based device (e.g. OpenPandora 600MHz, BeagleBoard C)
- AM335x based devices (e.g. BeagleBone, PocketBeagle)
Regardless of if and how this could be upstreamed, is there a more recent version of this work? I think there is tremendous value in having a combined repo (and combined effort) to get PowerVR to work on top of mainline (even though it might never be merged into mainline).
I have a couple of devices that I'd like to try getting PowerVR to work on. We (Maemo Leste) have it working on the Nokia N900 (forward port of nemo mobile kernel+userspace), but X11 works with acceleration, although some issues remain.
But I would also like to try to get it to work on the Motorola Droid 4 (also omap). And Pawel (in CC) has exynos devices with PowerVR, and he's also trying to get something to work [1] [2]. I also have a Pandaboard ES specifically for this purpose.
Ideally we'd use drm+modesetting drivers with dri3wsegl [3], but I have yet to try to make that work. :)
Cheers, Merlijn
[1] https://github.com/PabloPL/linux/wiki [2] https://github.com/PabloPL/linux/issues/18 [3] https://github.com/TexasInstruments/dri3wsegl
So in combination with proper DT entries the correct driver variant is automatically modprobed during boot. At least for OMAP3.
OMAP4+5 driver code is also included but not yet integrated/fixed.
The DM3730 and AM33xx versions work (up to a certain point I will describe below). OMAP3530 does not properly set up clocks and SoC interconnects.
For the AM335x there is a hack to keep clock running after deasserting reset, but for the OMAP3530 we still have to find the root of the trouble.
What is still missing is the framebuffer backend so the SGX is not told how to write to a display. Traditionally, there was omaplfb but it seems no longer be working. There is also some DRM stuff, but I wasn't able to compile and set it up so far.
So, running the SGX ClipBlit test succeeds until it fails with:
FAIL - PVRSRV_ERROR_NO_DC_DEVICES_FOUND(134)
The latest code is rebased on top of v4.15-rc9 and it suffices to configure for SGX and SGX_OMAP. It can be found here (or in the latest Letux release [2]):
https://github.com/goldelico/gta04-kernel/commits/work/letux-base/hns/gpu/om...
It consists of two groups of commits (separated by a MAINTAINERS patch):
fixes for SoC glue (e.g. clock, hw-mods, pdata-qirks, DT) to get the SGX initialized and access - most of them are already good enough for upstream review
source code for pvrsrvkm from TI GFX SDK (one version for omap3+4 and one for omap4+5) combined with patches and new Makefiles to get it compiled on v4.15
There are also two shell-script tools (Letux/root/sgxdump and Letux/root/gpu-demo) for user-space. They are useful for debugging. A compatible Debian package with the (closed source!) microkernel for SGX, libs and demos for OMAP3-ARMHF can be found here:
http://download.goldelico.com/letux-debian-rootfs/debian/dists/jessie/main/b...
What is the goal of this effort?
In the end we should have a single, generic SGX driver for all OMAP SoC variants sitting in mainline drivers/gpu/pvr. So the goal is to end the era of out-of tree SGX drivers for a significant portion of OMAP processors.
Maybe it could become a driver that even IMG and TI want to support by providing newer (and open source) user-space libraries and tools.
My personal goal so far was to make it a working demonstrator that can be used as a "good" reference for running "git bisect" to identify regressions introduced by future modifications.
What has to be done to polish the code beyond "seems to work"?
I see these topics (but there may be more):
- fix power and clock management weakness
- fix issues with omap3530 (e.g. OpenPandora)
- make code finally completely independent of SoC variant so that all differences are deduced from device tree and a single kernel module serves them all
- get rid of -DSGX530 #ifdef etc.
- remove #if LINUX_VERSION_CODE (unless someone sees need to backport to stable)
- fix backend (omaplfb and/or omapdrm)
- make it work on omap4 / omap5 and sgx540 / sgx544
- fix dmac flush etc. in services4/srvkm/env/linux/osfunc.c
- simplify code where possible
- clean up the code (e.g. replace camel-case function and variable names)
- merge drivers/subdirectories for omap3+4 and omap4+5
- move from drivers/staging/pvr to drivers/gpu/pcr
- support for non-OMAP SoC with PVR/SGX inside
This is far too much work for just a handful of people so a broader community should be involved.
What will be the next steps?
Tony suggested to publish this initial work on LKML and ask for integration into the staging tree. The rationale is that the code needs a lot of polishing and cleanup until it is something good for drivers/gpu. And collaboration on LKML and kernel.org becomes easier than having a private mailing list and git(hub) repo only.
Yes, that would be be a good step and now I think the package is ready to go.
And if someone could provide a fix for the FB/DRM setup it would also be a big step because we then can even demonstrate it by screen movies.
We also need to define maintainers who take care of changes and new patches (since I can't do that alone).
BR, Nikolaus
Hi Merlijn,
Am 10.02.2019 um 17:14 schrieb Merlijn Wajer merlijn@wizzup.org:
Hi,
On 23/01/2018 14:38, H. Nikolaus Schaller wrote:
Hi all, based on initial work by Moaz Korena [1] and with the help of Adam Ford and Tony Lindgren, I have worked for a while on a new SGX driver for OMAP.
Now, I finally managed to write a master-Makefile that allows to build multiple variants of the sgx driver without having to config the build for a specific single SoC and forces us to choose the SGX version at compile time. This allows to build MULTI_PLATFORM kernels.
This means we currently get three different kernel modules: /lib/modules/4.15.0-rc9-letux+/kernel/drivers/staging/pvr/omap3/pvr_omap3630_sgx530_125.ko /lib/modules/4.15.0-rc9-letux+/kernel/drivers/staging/pvr/omap3/pvr_omap3_sgx530_121.ko /lib/modules/4.15.0-rc9-letux+/kernel/drivers/staging/pvr/omap3/pvr_ti335x_sgx530_125.ko
They are for:
- DM3730 based devices (e.g. Torpedo DM3730, BeagleBoard XM, GTA04, Pandora 1GHz)
- OMAP3530 based device (e.g. OpenPandora 600MHz, BeagleBoard C)
- AM335x based devices (e.g. BeagleBone, PocketBeagle)
Regardless of if and how this could be upstreamed, is there a more recent version of this work?
Yes, we are rebasing the OMAP3/AM335x (TI Graphics_SDK_5_01_01_02 for omap3/omap4, seems to be IMG DDK 1.10) regularly and are trying to track upstream API changes:
http://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/o...
But we are not using or testing (due to lack of working omaplfb framebuffer), so that I am not sure if it still works (at least to the level of successfully resetting and downloading firmware) or was harmed by recent upstream changes (e.g. clock framework, hwmods). But if it is no longer working, it should not be too difficult to find our why, since older and working versions are archived for comparison and we can find the upstream version which did break it.
We also carry along a patch set of the latest (we are aware of) SGX drivers for OMAP and other platforms (IMG DDK 1.14):
http://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/l...
but that tree is missing in-kernel Kconfig+Makefiles and SoC integration fixes. And I don't know where to find the matching firmware and library files.
I think there is tremendous value in having a combined repo (and combined effort) to get PowerVR to work on top of mainline (even though it might never be merged into mainline).
Indeed. The best would IMHO be if it were generally available in mainline/staging [1].
So if there is enough support by the community we could try to get these things pulled by Greg to drivers/staging/pvr for the benefit of everybody. And then we all could work on a single common basis for improvements using the standard tools like kernel git, LKML, linux-next, patchwork etc.
IMHO all these efforts so far were stopped because it is so difficult to pull together all the pieces and everyone was starting over from scratch.
I have a couple of devices that I'd like to try getting PowerVR to work on. We (Maemo Leste) have it working on the Nokia N900 (forward port of nemo mobile kernel+userspace),
Fine! That is much better than what we have on our omap3 devices (because we use omapdrm panel drivers). But N900 is sufficiently similar. So that comparing the diffs might end in a working solution for everyone.
but X11 works with acceleration, although some issues remain.
Cool.
But I would also like to try to get it to work on the Motorola Droid 4 (also omap). And Pawel (in CC) has exynos devices with PowerVR, and he's also trying to get something to work [1] [2]. I also have a Pandaboard ES specifically for this purpose.
Yes, I also have a Panda ES so I can at least offer testing.
Ideally we'd use drm+modesetting drivers with dri3wsegl [3], but I have yet to try to make that work. :)
Cheers, Merlijn
What would be the process to get something into staging? Who decides about staging generally? Should we just forward this discussion to Greg for comment?
BR and thanks for bringing up this topic again! Nikolaus
[1]: https://lwn.net/Articles/324279/
[1] https://github.com/PabloPL/linux/wiki [2] https://github.com/PabloPL/linux/issues/18 [3] https://github.com/TexasInstruments/dri3wsegl
So in combination with proper DT entries the correct driver variant is automatically modprobed during boot. At least for OMAP3.
OMAP4+5 driver code is also included but not yet integrated/fixed.
The DM3730 and AM33xx versions work (up to a certain point I will describe below). OMAP3530 does not properly set up clocks and SoC interconnects.
For the AM335x there is a hack to keep clock running after deasserting reset, but for the OMAP3530 we still have to find the root of the trouble.
What is still missing is the framebuffer backend so the SGX is not told how to write to a display. Traditionally, there was omaplfb but it seems no longer be working. There is also some DRM stuff, but I wasn't able to compile and set it up so far.
So, running the SGX ClipBlit test succeeds until it fails with:
FAIL - PVRSRV_ERROR_NO_DC_DEVICES_FOUND(134)
The latest code is rebased on top of v4.15-rc9 and it suffices to configure for SGX and SGX_OMAP. It can be found here (or in the latest Letux release [2]):
https://github.com/goldelico/gta04-kernel/commits/work/letux-base/hns/gpu/om...
It consists of two groups of commits (separated by a MAINTAINERS patch):
- fixes for SoC glue (e.g. clock, hw-mods, pdata-qirks, DT) to get the SGX initialized
and access - most of them are already good enough for upstream review
- source code for pvrsrvkm from TI GFX SDK (one version for omap3+4 and one for omap4+5)
combined with patches and new Makefiles to get it compiled on v4.15
There are also two shell-script tools (Letux/root/sgxdump and Letux/root/gpu-demo) for user-space. They are useful for debugging. A compatible Debian package with the (closed source!) microkernel for SGX, libs and demos for OMAP3-ARMHF can be found here:
http://download.goldelico.com/letux-debian-rootfs/debian/dists/jessie/main/b...
What is the goal of this effort?
In the end we should have a single, generic SGX driver for all OMAP SoC variants sitting in mainline drivers/gpu/pvr. So the goal is to end the era of out-of tree SGX drivers for a significant portion of OMAP processors.
Maybe it could become a driver that even IMG and TI want to support by providing newer (and open source) user-space libraries and tools.
My personal goal so far was to make it a working demonstrator that can be used as a "good" reference for running "git bisect" to identify regressions introduced by future modifications.
What has to be done to polish the code beyond "seems to work"?
I see these topics (but there may be more):
- fix power and clock management weakness
- fix issues with omap3530 (e.g. OpenPandora)
- make code finally completely independent of SoC variant so that all differences
are deduced from device tree and a single kernel module serves them all
- get rid of -DSGX530 #ifdef etc.
- remove #if LINUX_VERSION_CODE (unless someone sees need to backport to stable)
- fix backend (omaplfb and/or omapdrm)
- make it work on omap4 / omap5 and sgx540 / sgx544
- fix dmac flush etc. in services4/srvkm/env/linux/osfunc.c
- simplify code where possible
- clean up the code (e.g. replace camel-case function and variable names)
- merge drivers/subdirectories for omap3+4 and omap4+5
- move from drivers/staging/pvr to drivers/gpu/pcr
- support for non-OMAP SoC with PVR/SGX inside
This is far too much work for just a handful of people so a broader community should be involved.
What will be the next steps?
Tony suggested to publish this initial work on LKML and ask for integration into the staging tree. The rationale is that the code needs a lot of polishing and cleanup until it is something good for drivers/gpu. And collaboration on LKML and kernel.org becomes easier than having a private mailing list and git(hub) repo only.
Yes, that would be be a good step and now I think the package is ready to go.
And if someone could provide a fix for the FB/DRM setup it would also be a big step because we then can even demonstrate it by screen movies.
We also need to define maintainers who take care of changes and new patches (since I can't do that alone).
BR, Nikolaus
Am 11.02.2019 um 07:51 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi Merlijn,
Am 10.02.2019 um 17:14 schrieb Merlijn Wajer merlijn@wizzup.org:
Hi,
On 23/01/2018 14:38, H. Nikolaus Schaller wrote:
Hi all, based on initial work by Moaz Korena [1] and with the help of Adam Ford and Tony Lindgren, I have worked for a while on a new SGX driver for OMAP.
Now, I finally managed to write a master-Makefile that allows to build multiple variants of the sgx driver without having to config the build for a specific single SoC and forces us to choose the SGX version at compile time. This allows to build MULTI_PLATFORM kernels.
This means we currently get three different kernel modules: /lib/modules/4.15.0-rc9-letux+/kernel/drivers/staging/pvr/omap3/pvr_omap3630_sgx530_125.ko /lib/modules/4.15.0-rc9-letux+/kernel/drivers/staging/pvr/omap3/pvr_omap3_sgx530_121.ko /lib/modules/4.15.0-rc9-letux+/kernel/drivers/staging/pvr/omap3/pvr_ti335x_sgx530_125.ko
They are for:
- DM3730 based devices (e.g. Torpedo DM3730, BeagleBoard XM, GTA04, Pandora 1GHz)
- OMAP3530 based device (e.g. OpenPandora 600MHz, BeagleBoard C)
- AM335x based devices (e.g. BeagleBone, PocketBeagle)
Regardless of if and how this could be upstreamed, is there a more recent version of this work?
Yes, we are rebasing the OMAP3/AM335x (TI Graphics_SDK_5_01_01_02 for omap3/omap4, seems to be IMG DDK 1.10) regularly and are trying to track upstream API changes:
http://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/o...
But we are not using or testing (due to lack of working omaplfb framebuffer), so that I am not sure if it still works (at least to the level of successfully resetting and downloading firmware) or was harmed by recent upstream changes (e.g. clock framework, hwmods). But if it is no longer working, it should not be too difficult to find our why, since older and working versions are archived for comparison and we can find the upstream version which did break it.
We also carry along a patch set of the latest (we are aware of) SGX drivers for OMAP and other platforms (IMG DDK 1.14):
http://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/l...
but that tree is missing in-kernel Kconfig+Makefiles and SoC integration fixes. And I don't know where to find the matching firmware and library files.
I think there is tremendous value in having a combined repo (and combined effort) to get PowerVR to work on top of mainline (even though it might never be merged into mainline).
Indeed. The best would IMHO be if it were generally available in mainline/staging [1].
So if there is enough support by the community we could try to get these things pulled by Greg to drivers/staging/pvr for the benefit of everybody. And then we all could work on a single common basis for improvements using the standard tools like kernel git, LKML, linux-next, patchwork etc.
IMHO all these efforts so far were stopped because it is so difficult to pull together all the pieces and everyone was starting over from scratch.
I have a couple of devices that I'd like to try getting PowerVR to work on. We (Maemo Leste) have it working on the Nokia N900 (forward port of nemo mobile kernel+userspace),
Fine! That is much better than what we have on our omap3 devices (because we use omapdrm panel drivers). But N900 is sufficiently similar. So that comparing the diffs might end in a working solution for everyone.
but X11 works with acceleration, although some issues remain.
Cool.
But I would also like to try to get it to work on the Motorola Droid 4 (also omap). And Pawel (in CC) has exynos devices with PowerVR, and he's also trying to get something to work [1] [2]. I also have a Pandaboard ES specifically for this purpose.
Yes, I also have a Panda ES so I can at least offer testing.
Ideally we'd use drm+modesetting drivers with dri3wsegl [3], but I have yet to try to make that work. :)
Cheers, Merlijn
What would be the process to get something into staging? Who decides about staging generally? Should we just forward this discussion to Greg for comment?
One thing already got my attention: we need to prefix all commit messages with e.g. "staging: pvr: " so that they can be distinguished on LKML. I'll prepare that for the next version of our Letux tree.
BR and thanks for bringing up this topic again! Nikolaus
[1] https://github.com/PabloPL/linux/wiki [2] https://github.com/PabloPL/linux/issues/18 [3] https://github.com/TexasInstruments/dri3wsegl
So in combination with proper DT entries the correct driver variant is automatically modprobed during boot. At least for OMAP3.
OMAP4+5 driver code is also included but not yet integrated/fixed.
The DM3730 and AM33xx versions work (up to a certain point I will describe below). OMAP3530 does not properly set up clocks and SoC interconnects.
For the AM335x there is a hack to keep clock running after deasserting reset, but for the OMAP3530 we still have to find the root of the trouble.
What is still missing is the framebuffer backend so the SGX is not told how to write to a display. Traditionally, there was omaplfb but it seems no longer be working. There is also some DRM stuff, but I wasn't able to compile and set it up so far.
So, running the SGX ClipBlit test succeeds until it fails with:
FAIL - PVRSRV_ERROR_NO_DC_DEVICES_FOUND(134)
The latest code is rebased on top of v4.15-rc9 and it suffices to configure for SGX and SGX_OMAP. It can be found here (or in the latest Letux release [2]):
https://github.com/goldelico/gta04-kernel/commits/work/letux-base/hns/gpu/om...
It consists of two groups of commits (separated by a MAINTAINERS patch):
- fixes for SoC glue (e.g. clock, hw-mods, pdata-qirks, DT) to get the SGX initialized
and access - most of them are already good enough for upstream review
- source code for pvrsrvkm from TI GFX SDK (one version for omap3+4 and one for omap4+5)
combined with patches and new Makefiles to get it compiled on v4.15
There are also two shell-script tools (Letux/root/sgxdump and Letux/root/gpu-demo) for user-space. They are useful for debugging. A compatible Debian package with the (closed source!) microkernel for SGX, libs and demos for OMAP3-ARMHF can be found here:
http://download.goldelico.com/letux-debian-rootfs/debian/dists/jessie/main/b...
What is the goal of this effort?
In the end we should have a single, generic SGX driver for all OMAP SoC variants sitting in mainline drivers/gpu/pvr. So the goal is to end the era of out-of tree SGX drivers for a significant portion of OMAP processors.
Maybe it could become a driver that even IMG and TI want to support by providing newer (and open source) user-space libraries and tools.
My personal goal so far was to make it a working demonstrator that can be used as a "good" reference for running "git bisect" to identify regressions introduced by future modifications.
What has to be done to polish the code beyond "seems to work"?
I see these topics (but there may be more):
- fix power and clock management weakness
- fix issues with omap3530 (e.g. OpenPandora)
- make code finally completely independent of SoC variant so that all differences
are deduced from device tree and a single kernel module serves them all
- get rid of -DSGX530 #ifdef etc.
- remove #if LINUX_VERSION_CODE (unless someone sees need to backport to stable)
- fix backend (omaplfb and/or omapdrm)
- make it work on omap4 / omap5 and sgx540 / sgx544
- fix dmac flush etc. in services4/srvkm/env/linux/osfunc.c
- simplify code where possible
- clean up the code (e.g. replace camel-case function and variable names)
- merge drivers/subdirectories for omap3+4 and omap4+5
- move from drivers/staging/pvr to drivers/gpu/pcr
- support for non-OMAP SoC with PVR/SGX inside
This is far too much work for just a handful of people so a broader community should be involved.
What will be the next steps?
Tony suggested to publish this initial work on LKML and ask for integration into the staging tree. The rationale is that the code needs a lot of polishing and cleanup until it is something good for drivers/gpu. And collaboration on LKML and kernel.org becomes easier than having a private mailing list and git(hub) repo only.
Yes, that would be be a good step and now I think the package is ready to go.
And if someone could provide a fix for the FB/DRM setup it would also be a big step because we then can even demonstrate it by screen movies.
We also need to define maintainers who take care of changes and new patches (since I can't do that alone).
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Hi,
* H. Nikolaus Schaller hns@goldelico.com [190212 20:03]:
Am 11.02.2019 um 07:51 schrieb H. Nikolaus Schaller hns@goldelico.com: What would be the process to get something into staging? Who decides about staging generally? Should we just forward this discussion to Greg for comment?
One thing already got my attention: we need to prefix all commit messages with e.g. "staging: pvr: " so that they can be distinguished on LKML. I'll prepare that for the next version of our Letux tree.
After thinking about this a bit, I think a shared out-of-tree repo is the best place to start rather than try to stuff a pile of sgx and vendor specific hacks into staging. Currently we don't even know what all needs to be different for various SoCs for example.
And for upstream merging, a minimal generic accelerated 2d sgx driver that works across several SoCs is probably the best place to start. This would make the clock and interrupt handling generic with just SoC specific glue layer.
Regards,
Tony
Hey all,
On 12.02.19 21:51, Tony Lindgren wrote:
Hi,
- H. Nikolaus Schaller hns@goldelico.com [190212 20:03]:
Am 11.02.2019 um 07:51 schrieb H. Nikolaus Schaller hns@goldelico.com: What would be the process to get something into staging? Who decides about staging generally? Should we just forward this discussion to Greg for comment?
One thing already got my attention: we need to prefix all commit messages with e.g. "staging: pvr: " so that they can be distinguished on LKML. I'll prepare that for the next version of our Letux tree.
After thinking about this a bit, I think a shared out-of-tree repo is the best place to start rather than try to stuff a pile of sgx and vendor specific hacks into staging. Currently we don't even know what all needs to be different for various SoCs for example.
And for upstream merging, a minimal generic accelerated 2d sgx driver that works across several SoCs is probably the best place to start. This would make the clock and interrupt handling generic with just SoC specific glue layer.
Regards,
Tony
Thanks for adding me to that thread!
I'm looking now into that PVR SGX driver since a while. I already reworked that old "opensource" driver to work with a quite new kernel (4.16 or 4.17) [But that code got lost]. For the sunxi devices this was only a short coding session to get that running. For OMAP this might be easier/faster since the general linux situation is better.
I'm not sure if we are able to provide a generic driver since there are different userspace versions that are only compatible with their own kernel driver. Not all compile flags for the kernel driver work with all userspace lib versions, at least on sunxi. Be aware that there are also different versions of those GPU ip cores and all have different features and bug fixes.
If you reach a good state with that driver, I can try to port that to sunxi. Is there any good/cheap OMAP4/5 Devboard you can recommend?
Don't expect any support from TI or IMG. TI can't support a project like this, since they don't own the code and IMG is not willing to support.
An other big issue is the leaked SGX source code [1]. So I think it would be better to start a clean room reverse engineering project. I'm already working on that.
Regards,
Philipp
Hi,
* Philipp Rossak embed3d@gmail.com [190212 22:25]:
I'm looking now into that PVR SGX driver since a while. I already reworked that old "opensource" driver to work with a quite new kernel (4.16 or 4.17) [But that code got lost]. For the sunxi devices this was only a short coding session to get that running. For OMAP this might be easier/faster since the general linux situation is better.
So a git repo that works for omaps and sunxi would be a good start then :)
I'm not sure if we are able to provide a generic driver since there are different userspace versions that are only compatible with their own kernel driver. Not all compile flags for the kernel driver work with all userspace lib versions, at least on sunxi. Be aware that there are also different versions of those GPU ip cores and all have different features and bug fixes.
No doubt it's a mess.. I'm only suggesting a generic driver that manages standard Linux resources like regulators, clocks and interrupts and provides 2d acceleration for sgx540 based on what we already have at drivers/gpu/drm/gma500/accel_2d.c. The idea being that it might then also make dealing with the rest of the sgx blobs a bit easier hopefully.
If you reach a good state with that driver, I can try to port that to sunxi. Is there any good/cheap OMAP4/5 Devboard you can recommend?
Hmm so the n900 folks have the sgx blobs working with recent mainline kernels for sgx530 I believe, and Nikolaus is close to having the sgx blobs working for sgx540. I may not be aware of the current status though.
For a devboard with sgx540, you should be able to find one for few tens of units for a used pandaboard-es for example or somebody here might even have an old one to donate. If you feel like playing with a phone, droid 4 xt894 is somewhat usable with mainline kernels with pending patches for LCD and modem, no idea what the sgx540 status on it might be. Pyra handheld is not yet available except for prototypes. And then on beagleboard-x15 there's sgx544, and beaglebone has sgx530 FYI so that might not help if you need sgx540.
Don't expect any support from TI or IMG. TI can't support a project like this, since they don't own the code and IMG is not willing to support.
Yeah that we've seen already over past 10 or so years :)
An other big issue is the leaked SGX source code [1]. So I think it would be better to start a clean room reverse engineering project. I'm already working on that.
OK so we're discussing at least three projects then:
1. A git repo that allows sgx blobs to work for various SoCs with current mainline kernels
2. A generic 2d sgx540 driver based on existing mainline kernel drivers/gpu/drm/gma500/accel_2d.c
3. Your reverse engineering project that might help with figuring out how things are supposed to work
Regards,
Tony
Hi Tony,
Am 13.02.2019 um 01:41 schrieb Tony Lindgren tony@atomide.com:
Hi,
- Philipp Rossak embed3d@gmail.com [190212 22:25]:
I'm looking now into that PVR SGX driver since a while. I already reworked that old "opensource" driver to work with a quite new kernel (4.16 or 4.17) [But that code got lost]. For the sunxi devices this was only a short coding session to get that running. For OMAP this might be easier/faster since the general linux situation is better.
So a git repo that works for omaps and sunxi would be a good start then :)
I'm not sure if we are able to provide a generic driver since there are different userspace versions that are only compatible with their own kernel driver. Not all compile flags for the kernel driver work with all userspace lib versions, at least on sunxi. Be aware that there are also different versions of those GPU ip cores and all have different features and bug fixes.
No doubt it's a mess.. I'm only suggesting a generic driver that manages standard Linux resources like regulators, clocks and interrupts and provides 2d acceleration for sgx540 based on what we already have at drivers/gpu/drm/gma500/accel_2d.c. The idea being that it might then also make dealing with the rest of the sgx blobs a bit easier hopefully.
Well, ok.
So you suggest that we e.g. take the omap SoC support in
http://git.goldelico.com/?p=letux-kernel.git;a=tree;f=drivers/staging/pvr/1....
and make an "eurasia_km / services4 / system / generic" out of it using the 2d functions?
Please take a look into especially sysconfig.c and SysInitialise() which does the lion's share of initialization if it can be rewritten to become generic.
If you reach a good state with that driver, I can try to port that to sunxi. Is there any good/cheap OMAP4/5 Devboard you can recommend?
Hmm so the n900 folks have the sgx blobs working with recent mainline kernels for sgx530 I believe, and Nikolaus is close to having the sgx blobs working for sgx540.
Also for sgx530 with recent kernel. The blobs itself are working, it is just missing code to tell the SGX module where the framebuffer is located in virtual memory.
I may not be aware of the current status though.
For a devboard with sgx540, you should be able to find one for few tens of units for a used pandaboard-es for example or somebody here might even have an old one to donate. If you feel like playing with a phone, droid 4 xt894 is somewhat usable with mainline kernels with pending patches for LCD and modem, no idea what the sgx540 status on it might be. Pyra handheld is not yet available except for prototypes. And then on beagleboard-x15 there's sgx544, and beaglebone has sgx530 FYI so that might not help if you need sgx540.
Don't expect any support from TI or IMG. TI can't support a project like this, since they don't own the code and IMG is not willing to support.
Yeah that we've seen already over past 10 or so years :)
An other big issue is the leaked SGX source code [1]. So I think it would be better to start a clean room reverse engineering project. I'm already working on that.
OK so we're discussing at least three projects then:
- A git repo that allows sgx blobs to work for various
SoCs with current mainline kernels
Yes.
- A generic 2d sgx540 driver based on existing mainline
kernel drivers/gpu/drm/gma500/accel_2d.c
May be needed or not.
- Your reverse engineering project that might help
with figuring out how things are supposed to work
IMHO a completely separate project.
Basically there is a strict layering:
L4 user-space libraries L3 SGX firmware L2 SGX firmware loader L1 SoC glue (clock, reset, dma, virtual memory, ...)
I am mainly considering L1 here and fixing L2. L1 is SoC specific of course and L2 needs Linux-release specific patches.
L2-L4 depend on SGX version.
L2 contains a lot of #ifdef that depend on SGX530/540/544 and even more.
Reverse engineering addresses L3 and L4.
Of course if will be is successful it might become possible to improve the whole L1-L4 stack, but that is another 10 years in the future :)
Since it is such a big task, I would propose to start with something close to working (some TI/IMG DDK) and improve on that instead of starting with parts from scratch.
BR, Nikolaus
Hi all, thanks for adding my to this topic. I'm using Power SGX540 on my Samsung s5pv210 based device (Samsung Galaxy S - i9000 phone - i've added support for it to mainline). Do anyone has it (sgx540) working on mainline (5.0) kernel? Currently i've forward ported old driver, written by google ( https://android.googlesource.com/kernel/samsung/+/android-samsung-3.0-jb-mr0... ) to 5.0 kernel. I'm able to to gpu init (run pvrsrvinit), but when trying to run some sample code i'm getting 0 available egl configurations. I think i've fixed problems with framebuffer setup (by making framebuffer big like it was on old kernel - so it will allocate one framebuffer and 2 backbuffers in my case). After enabling debug code in driver i'm currently getting followin logs https://gist.github.com/PabloPL/c1e98f405e67d577afcf51c36228efdc (BTW it's android binaries running on ubuntu on that s5pv210 device).
śr., 13 lut 2019 o 07:36 H. Nikolaus Schaller hns@goldelico.com napisał(a):
Hi Tony,
Am 13.02.2019 um 01:41 schrieb Tony Lindgren tony@atomide.com:
Hi,
- Philipp Rossak embed3d@gmail.com [190212 22:25]:
I'm looking now into that PVR SGX driver since a while. I already
reworked
that old "opensource" driver to work with a quite new kernel (4.16 or
4.17)
[But that code got lost]. For the sunxi devices this was only a short coding session to get that running. For OMAP this might be easier/faster since the general linux situation is better.
So a git repo that works for omaps and sunxi would be a good start then :)
I'm not sure if we are able to provide a generic driver since there are different userspace versions that are only compatible with their own
kernel
driver. Not all compile flags for the kernel driver work with all
userspace
lib versions, at least on sunxi. Be aware that there are also different versions of those GPU ip cores and all have different features and bug fixes.
No doubt it's a mess.. I'm only suggesting a generic driver that manages standard Linux resources like regulators, clocks and interrupts and provides 2d acceleration for sgx540 based on what we already have at drivers/gpu/drm/gma500/accel_2d.c. The idea being that it might then also make dealing with the rest of the sgx blobs a bit easier hopefully.
Well, ok.
So you suggest that we e.g. take the omap SoC support in
http://git.goldelico.com/?p=letux-kernel.git;a=tree;f=drivers/staging/pvr/1....
and make an "eurasia_km / services4 / system / generic" out of it using the 2d functions?
Please take a look into especially sysconfig.c and SysInitialise() which does the lion's share of initialization if it can be rewritten to become generic.
If you reach a good state with that driver, I can try to port that to
sunxi.
Is there any good/cheap OMAP4/5 Devboard you can recommend?
Hmm so the n900 folks have the sgx blobs working with recent mainline kernels for sgx530 I believe, and Nikolaus is close to having the sgx blobs working for sgx540.
Also for sgx530 with recent kernel. The blobs itself are working, it is just missing code to tell the SGX module where the framebuffer is located in virtual memory.
I think setting CONFIG_DRM_FBDEV_OVERALLOC=700 in my case (like old kernel) this will make powervr driver allocate one framebuffer + 2 backbuffers and CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM it should make it working. On my device i had to use different "fix" https://github.com/PabloPL/linux/commit/d0b1df4067a724aa0b38d11c82fd3ff0958a... The physical address of fb is used in driver (and passed to userspace?). It's code is here for my device https://github.com/PabloPL/linux/blob/powervr/drivers/gpu/drm/powervr/s3c_lc... And here is simple devicetree entry which is read by driver (it was added by person which is also working on mainlining my device). https://github.com/PabloPL/linux/blob/powervr/arch/arm/boot/dts/s5pv210-arie...
But this still didn't allowed me to run egl code with that driver. Probably i'll need to get logs from old kernel.
All my code is currently (if someone is interested ) in https://github.com/PabloPL/linux/tree/powervr
I may not be aware of the current status though.
For a devboard with sgx540, you should be able to find one for few tens of units for a used pandaboard-es for example or somebody here might even have an old one to donate. If you feel like playing with a phone, droid 4 xt894 is somewhat usable with mainline kernels with pending patches for LCD and modem, no idea what the sgx540 status on it might be. Pyra handheld is not yet available except for prototypes. And then on beagleboard-x15 there's sgx544, and beaglebone has sgx530 FYI so that might not help if you need sgx540.
Don't expect any support from TI or IMG. TI can't support a project like this, since they don't own the code and IMG is not willing to support.
Yeah that we've seen already over past 10 or so years :)
An other big issue is the leaked SGX source code [1]. So I think it
would be
better to start a clean room reverse engineering project. I'm already working on that.
OK so we're discussing at least three projects then:
- A git repo that allows sgx blobs to work for various
SoCs with current mainline kernels
Yes.
- A generic 2d sgx540 driver based on existing mainline
kernel drivers/gpu/drm/gma500/accel_2d.c
May be needed or not.
- Your reverse engineering project that might help
with figuring out how things are supposed to work
IMHO a completely separate project.
Basically there is a strict layering:
L4 user-space libraries L3 SGX firmware L2 SGX firmware loader L1 SoC glue (clock, reset, dma, virtual memory, ...)
I am mainly considering L1 here and fixing L2. L1 is SoC specific of course and L2 needs Linux-release specific patches.
L2-L4 depend on SGX version.
L2 contains a lot of #ifdef that depend on SGX530/540/544 and even more.
Reverse engineering addresses L3 and L4.
Of course if will be is successful it might become possible to improve the whole L1-L4 stack, but that is another 10 years in the future :)
Since it is such a big task, I would propose to start with something close to working (some TI/IMG DDK) and improve on that instead of starting with parts from scratch.
BR, Nikolaus
Hi Pawel,
Am 13.02.2019 um 08:14 schrieb Paweł Chmiel pawel.mikolaj.chmiel@gmail.com:
Hi all, thanks for adding my to this topic. I'm using Power SGX540 on my Samsung s5pv210 based device (Samsung Galaxy S - i9000 phone - i've added support for it to mainline).
Great!
Do anyone has it (sgx540) working on mainline (5.0) kernel? Currently i've forward ported old driver, written by google (https://android.googlesource.com/kernel/samsung/+/android-samsung-3.0-jb-mr0... https://android.googlesource.com/kernel/samsung/+/android-samsung-3.0-jb-mr0/drivers/gpu/pvr) to 5.0 kernel.
Unfortunately no. I have not invested time into SGX540 (although there is code in my tree). Iworked on omap3/amm335x.
I'm able to to gpu init (run pvrsrvinit), but when trying to run some sample code i'm getting 0 available egl configurations. I think i've fixed problems with framebuffer setup (by making framebuffer big like it was on old kernel - so it will allocate one framebuffer and 2 backbuffers in my case).
Yes, that is almost the same state as I have for omap3. I can run pvrsrvinit but it does not find framebuffers. Because it tries to use omaplfb which is not DRM compatible. So I would have to rewrite that first.
After enabling debug code in driver i'm currently getting followin logs https://gist.github.com/PabloPL/c1e98f405e67d577afcf51c36228efdc https://gist.github.com/PabloPL/c1e98f405e67d577afcf51c36228efdc (BTW it's android binaries running on ubuntu on that s5pv210 device).
So it turns out that we have several initiatives by individuals that did start at different versions of the DDK&Linux-Glue and adjusted it to different SGX versions and some specific SoCs.
What I would propose then is that we check if the DDK 1.14 is really the latest existing one, install it in some common git repo and have us all work on this common basis to redo the integration we have done on our individual trees.
And someone rebases this DDK every week to the latest linus/master. This also reveals API changes we need to track in the glue code.
So we definitively need some common git to synchronize efforts. My proposal would still be kernel.org/drivers/staging http://kernel.org/drivers/staging/pvr, because it would be eliminate the need to rebase every week...
But what would be other options?
BR, Nikolaus
śr., 13 lut 2019 o 07:36 H. Nikolaus Schaller <hns@goldelico.com mailto:hns@goldelico.com> napisał(a): Hi Tony,
Am 13.02.2019 um 01:41 schrieb Tony Lindgren <tony@atomide.com mailto:tony@atomide.com>:
Hi,
- Philipp Rossak <embed3d@gmail.com mailto:embed3d@gmail.com> [190212 22:25]:
I'm looking now into that PVR SGX driver since a while. I already reworked that old "opensource" driver to work with a quite new kernel (4.16 or 4.17) [But that code got lost]. For the sunxi devices this was only a short coding session to get that running. For OMAP this might be easier/faster since the general linux situation is better.
So a git repo that works for omaps and sunxi would be a good start then :)
I'm not sure if we are able to provide a generic driver since there are different userspace versions that are only compatible with their own kernel driver. Not all compile flags for the kernel driver work with all userspace lib versions, at least on sunxi. Be aware that there are also different versions of those GPU ip cores and all have different features and bug fixes.
No doubt it's a mess.. I'm only suggesting a generic driver that manages standard Linux resources like regulators, clocks and interrupts and provides 2d acceleration for sgx540 based on what we already have at drivers/gpu/drm/gma500/accel_2d.c. The idea being that it might then also make dealing with the rest of the sgx blobs a bit easier hopefully.
Well, ok.
So you suggest that we e.g. take the omap SoC support in
http://git.goldelico.com/?p=letux-kernel.git;a=tree;f=drivers/staging/pvr/1.... http://git.goldelico.com/?p=letux-kernel.git;a=tree;f=drivers/staging/pvr/1.14.3699939/eurasia_km/services4/system/omap;h=09ff9c9112dd7e8f7316ba5f1e022dcb824c2ce4;hb=1d5b6a91eca80168c37ecb66157e675d28666652
and make an "eurasia_km / services4 / system / generic" out of it using the 2d functions?
Please take a look into especially sysconfig.c and SysInitialise() which does the lion's share of initialization if it can be rewritten to become generic.
If you reach a good state with that driver, I can try to port that to sunxi. Is there any good/cheap OMAP4/5 Devboard you can recommend?
Hmm so the n900 folks have the sgx blobs working with recent mainline kernels for sgx530 I believe, and Nikolaus is close to having the sgx blobs working for sgx540.
Also for sgx530 with recent kernel. The blobs itself are working, it is just missing code to tell the SGX module where the framebuffer is located in virtual memory. I think setting CONFIG_DRM_FBDEV_OVERALLOC=700 in my case (like old kernel) this will make powervr driver allocate one framebuffer + 2 backbuffers and CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM it should make it working. On my device i had to use different "fix" https://github.com/PabloPL/linux/commit/d0b1df4067a724aa0b38d11c82fd3ff0958a... https://github.com/PabloPL/linux/commit/d0b1df4067a724aa0b38d11c82fd3ff0958a45a6 The physical address of fb is used in driver (and passed to userspace?). It's code is here for my device https://github.com/PabloPL/linux/blob/powervr/drivers/gpu/drm/powervr/s3c_lc... https://github.com/PabloPL/linux/blob/powervr/drivers/gpu/drm/powervr/s3c_lcd/s3c_displayclass.c#L943 And here is simple devicetree entry which is read by driver (it was added by person which is also working on mainlining my device). https://github.com/PabloPL/linux/blob/powervr/arch/arm/boot/dts/s5pv210-arie... https://github.com/PabloPL/linux/blob/powervr/arch/arm/boot/dts/s5pv210-aries.dtsi#L325
But this still didn't allowed me to run egl code with that driver. Probably i'll need to get logs from old kernel.
All my code is currently (if someone is interested ) in https://github.com/PabloPL/linux/tree/powervr https://github.com/PabloPL/linux/tree/powervr
I may not be aware of the current status though.
For a devboard with sgx540, you should be able to find one for few tens of units for a used pandaboard-es for example or somebody here might even have an old one to donate. If you feel like playing with a phone, droid 4 xt894 is somewhat usable with mainline kernels with pending patches for LCD and modem, no idea what the sgx540 status on it might be. Pyra handheld is not yet available except for prototypes. And then on beagleboard-x15 there's sgx544, and beaglebone has sgx530 FYI so that might not help if you need sgx540.
Don't expect any support from TI or IMG. TI can't support a project like this, since they don't own the code and IMG is not willing to support.
Yeah that we've seen already over past 10 or so years :)
An other big issue is the leaked SGX source code [1]. So I think it would be better to start a clean room reverse engineering project. I'm already working on that.
OK so we're discussing at least three projects then:
- A git repo that allows sgx blobs to work for various
SoCs with current mainline kernels
Yes.
- A generic 2d sgx540 driver based on existing mainline
kernel drivers/gpu/drm/gma500/accel_2d.c
May be needed or not.
- Your reverse engineering project that might help
with figuring out how things are supposed to work
IMHO a completely separate project.
Basically there is a strict layering:
L4 user-space libraries L3 SGX firmware L2 SGX firmware loader L1 SoC glue (clock, reset, dma, virtual memory, ...)
I am mainly considering L1 here and fixing L2. L1 is SoC specific of course and L2 needs Linux-release specific patches.
L2-L4 depend on SGX version.
L2 contains a lot of #ifdef that depend on SGX530/540/544 and even more.
Reverse engineering addresses L3 and L4.
Of course if will be is successful it might become possible to improve the whole L1-L4 stack, but that is another 10 years in the future :)
Since it is such a big task, I would propose to start with something close to working (some TI/IMG DDK) and improve on that instead of starting with parts from scratch.
BR, Nikolaus
śr., 13 lut 2019 o 08:25 H. Nikolaus Schaller hns@goldelico.com napisał(a):
Hi Pawel,
Am 13.02.2019 um 08:14 schrieb Paweł Chmiel < pawel.mikolaj.chmiel@gmail.com>:
Hi all, thanks for adding my to this topic. I'm using Power SGX540 on my Samsung s5pv210 based device (Samsung Galaxy S - i9000 phone - i've added support for it to mainline).
Great!
Do anyone has it (sgx540) working on mainline (5.0) kernel? Currently i've forward ported old driver, written by google ( https://android.googlesource.com/kernel/samsung/+/android-samsung-3.0-jb-mr0... ) to 5.0 kernel.
Unfortunately no. I have not invested time into SGX540 (although there is code in my tree). Iworked on omap3/amm335x.
I'm able to to gpu init (run pvrsrvinit), but when trying to run some sample code i'm getting 0 available egl configurations. I think i've fixed problems with framebuffer setup (by making framebuffer big like it was on old kernel - so it will allocate one framebuffer and 2 backbuffers in my case).
Yes, that is almost the same state as I have for omap3. I can run pvrsrvinit but it does not find framebuffers. Because it tries to use omaplfb which is not DRM compatible. So I would have to rewrite that first.
I'm also using something similar to omaplfb (on my soc it is s3c_lcd code - https://github.com/PabloPL/linux/tree/powervr/drivers/gpu/drm/powervr/s3c_lc... - it's dirrectly writing to framebuffer) and i'm able to pass after this. I wanted to get running something which was working on old kernel (rather than trying to take driver from omap/etc and add support for my soc there) and then see how it works etc. Do You have strace of pvrsrvinit run ? They should be almost identical to one which i have. We could also write something like it was done for lima ( https://github.com/limadriver/lima/tree/master/wrap or https://github.com/yuq/mali-syscall-tracker), to capture ioctl and dump content of it. But first it would be nice to have some sample codes (there was some from img with their sdk for ti. need to search for it), which we could run and then compare logs.
After enabling debug code in driver i'm currently getting followin logs https://gist.github.com/PabloPL/c1e98f405e67d577afcf51c36228efdc (BTW it's android binaries running on ubuntu on that s5pv210 device).
So it turns out that we have several initiatives by individuals that did start at different versions of the DDK&Linux-Glue and adjusted it to different SGX versions and some specific SoCs.
What I would propose then is that we check if the DDK 1.14 is really the latest existing one, install it in some common git repo and have us all work on this common basis to redo the integration we have done on our individual trees.
And someone rebases this DDK every week to the latest linus/master. This also reveals API changes we need to track in the glue code.
So we definitively need some common git to synchronize efforts. My proposal would still be kernel.org/drivers/staging/pvr, because it would be eliminate the need to rebase every week...
But what would be other options?
Is DDK 1.14 for omap5 the same like for omap4 ? I have some copy of https://github.com/rcn-ee/ti-omap5-sgx-ddk-linux which i've fixed to build under 4.20 (should be also easy to build it under 5.0). But didn't added yet any soc specific code, just compile tested.
BR, Nikolaus
śr., 13 lut 2019 o 07:36 H. Nikolaus Schaller hns@goldelico.com napisał(a):
Hi Tony,
Am 13.02.2019 um 01:41 schrieb Tony Lindgren tony@atomide.com:
Hi,
- Philipp Rossak embed3d@gmail.com [190212 22:25]:
I'm looking now into that PVR SGX driver since a while. I already
reworked
that old "opensource" driver to work with a quite new kernel (4.16 or
4.17)
[But that code got lost]. For the sunxi devices this was only a short coding session to get that running. For OMAP this might be easier/faster since the general linux situation is better.
So a git repo that works for omaps and sunxi would be a good start then :)
I'm not sure if we are able to provide a generic driver since there are different userspace versions that are only compatible with their own
kernel
driver. Not all compile flags for the kernel driver work with all
userspace
lib versions, at least on sunxi. Be aware that there are also different versions of those GPU ip cores and all have different features and bug fixes.
No doubt it's a mess.. I'm only suggesting a generic driver that manages standard Linux resources like regulators, clocks and interrupts and provides 2d acceleration for sgx540 based on what we already have at drivers/gpu/drm/gma500/accel_2d.c. The idea being that it might then also make dealing with the rest of the sgx blobs a bit easier hopefully.
Well, ok.
So you suggest that we e.g. take the omap SoC support in
http://git.goldelico.com/?p=letux-kernel.git;a=tree;f=drivers/staging/pvr/1....
and make an "eurasia_km / services4 / system / generic" out of it using the 2d functions?
Please take a look into especially sysconfig.c and SysInitialise() which does the lion's share of initialization if it can be rewritten to become generic.
If you reach a good state with that driver, I can try to port that to
sunxi.
Is there any good/cheap OMAP4/5 Devboard you can recommend?
Hmm so the n900 folks have the sgx blobs working with recent mainline kernels for sgx530 I believe, and Nikolaus is close to having the sgx blobs working for sgx540.
Also for sgx530 with recent kernel. The blobs itself are working, it is just missing code to tell the SGX module where the framebuffer is located in virtual memory.
I think setting CONFIG_DRM_FBDEV_OVERALLOC=700 in my case (like old kernel) this will make powervr driver allocate one framebuffer + 2 backbuffers and CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM it should make it working. On my device i had to use different "fix"
https://github.com/PabloPL/linux/commit/d0b1df4067a724aa0b38d11c82fd3ff0958a... The physical address of fb is used in driver (and passed to userspace?). It's code is here for my device
https://github.com/PabloPL/linux/blob/powervr/drivers/gpu/drm/powervr/s3c_lc... And here is simple devicetree entry which is read by driver (it was added by person which is also working on mainlining my device).
https://github.com/PabloPL/linux/blob/powervr/arch/arm/boot/dts/s5pv210-arie...
But this still didn't allowed me to run egl code with that driver. Probably i'll need to get logs from old kernel.
All my code is currently (if someone is interested ) in https://github.com/PabloPL/linux/tree/powervr
I may not be aware of the current status though.
For a devboard with sgx540, you should be able to find one for few tens of units for a used pandaboard-es for example or somebody here might even have an old one to donate. If you feel like playing with a phone, droid 4 xt894 is somewhat usable with mainline kernels with pending patches for LCD and modem, no idea what the sgx540 status on it might be. Pyra handheld is not yet available except for prototypes. And then on beagleboard-x15 there's sgx544, and beaglebone has sgx530 FYI so that might not help if you need sgx540.
Don't expect any support from TI or IMG. TI can't support a project
like
this, since they don't own the code and IMG is not willing to support.
Yeah that we've seen already over past 10 or so years :)
An other big issue is the leaked SGX source code [1]. So I think it
would be
better to start a clean room reverse engineering project. I'm already working on that.
OK so we're discussing at least three projects then:
- A git repo that allows sgx blobs to work for various
SoCs with current mainline kernels
Yes.
- A generic 2d sgx540 driver based on existing mainline
kernel drivers/gpu/drm/gma500/accel_2d.c
May be needed or not.
- Your reverse engineering project that might help
with figuring out how things are supposed to work
IMHO a completely separate project.
Basically there is a strict layering:
L4 user-space libraries L3 SGX firmware L2 SGX firmware loader L1 SoC glue (clock, reset, dma, virtual memory, ...)
I am mainly considering L1 here and fixing L2. L1 is SoC specific of course and L2 needs Linux-release specific patches.
L2-L4 depend on SGX version.
L2 contains a lot of #ifdef that depend on SGX530/540/544 and even more.
Reverse engineering addresses L3 and L4.
Of course if will be is successful it might become possible to improve the whole L1-L4 stack, but that is another 10 years in the future :)
Since it is such a big task, I would propose to start with something close to working (some TI/IMG DDK) and improve on that instead of starting with parts from scratch.
BR, Nikolaus
Hi Pawel,
Am 13.02.2019 um 08:36 schrieb Paweł Chmiel pawel.mikolaj.chmiel@gmail.com:
śr., 13 lut 2019 o 08:25 H. Nikolaus Schaller hns@goldelico.com napisał(a): Hi Pawel,
Am 13.02.2019 um 08:14 schrieb Paweł Chmiel pawel.mikolaj.chmiel@gmail.com:
Hi all, thanks for adding my to this topic. I'm using Power SGX540 on my Samsung s5pv210 based device (Samsung Galaxy S - i9000 phone - i've added support for it to mainline).
Great!
Do anyone has it (sgx540) working on mainline (5.0) kernel? Currently i've forward ported old driver, written by google (https://android.googlesource.com/kernel/samsung/+/android-samsung-3.0-jb-mr0...) to 5.0 kernel.
Unfortunately no. I have not invested time into SGX540 (although there is code in my tree). Iworked on omap3/amm335x.
I'm able to to gpu init (run pvrsrvinit), but when trying to run some sample code i'm getting 0 available egl configurations. I think i've fixed problems with framebuffer setup (by making framebuffer big like it was on old kernel - so it will allocate one framebuffer and 2 backbuffers in my case).
Yes, that is almost the same state as I have for omap3. I can run pvrsrvinit but it does not find framebuffers. Because it tries to use omaplfb which is not DRM compatible. So I would have to rewrite that first.
I'm also using something similar to omaplfb (on my soc it is s3c_lcd code - https://github.com/PabloPL/linux/tree/powervr/drivers/gpu/drm/powervr/s3c_lc... - it's dirrectly writing to framebuffer) and i'm able to pass after this. I wanted to get running something which was working on old kernel (rather than trying to take driver from omap/etc and add support for my soc there) and then see how it works etc. Do You have strace of pvrsrvinit run ? They should be almost identical to one which i have.
Yes, I can make a test setup (I still have to check on which kernel versions it works since I am not sure if 5.0-rc is broken or not) and run an strace in the next days.
We could also write something like it was done for lima (https://github.com/limadriver/lima/tree/master/wrap or https://github.com/yuq/mali-syscall-tracker), to capture ioctl and dump content of it. But first it would be nice to have some sample codes (there was some from img with their sdk for ti. need to search for it), which we could run and then compare logs.
After enabling debug code in driver i'm currently getting followin logs https://gist.github.com/PabloPL/c1e98f405e67d577afcf51c36228efdc (BTW it's android binaries running on ubuntu on that s5pv210 device).
So it turns out that we have several initiatives by individuals that did start at different versions of the DDK&Linux-Glue and adjusted it to different SGX versions and some specific SoCs.
What I would propose then is that we check if the DDK 1.14 is really the latest existing one, install it in some common git repo and have us all work on this common basis to redo the integration we have done on our individual trees.
And someone rebases this DDK every week to the latest linus/master. This also reveals API changes we need to track in the glue code.
So we definitively need some common git to synchronize efforts. My proposal would still be kernel.org/drivers/staging/pvr, because it would be eliminate the need to rebase every week...
But what would be other options?
Is DDK 1.14 for omap5 the same like for omap4 ? I have some copy of https://github.com/rcn-ee/ti-omap5-sgx-ddk-linux which i've fixed to build under 4.20 (should be also easy to build it under 5.0).
In my understanding DDK 1.14 is not only for omap4 or 5 but supports a collection of devices (and a long list of SGX variants). See
http://git.goldelico.com/?p=letux-kernel.git;a=tree;f=drivers/staging/pvr/1....
There one finds * cedarview (some Intel Atom) * omap (probably means am335x/omap3/4/5) * poulsbo * jz4780 * pc_i686_tc3 * sunxi
And the list of supported SGX variants is inside this file:
http://git.goldelico.com/?p=letux-kernel.git;a=blob;f=drivers/staging/pvr/1....
So this tree appears to be already very broad and easy to modify to serve everybody.
BTW: I found that Android kernels usually use a reduced and flattened sgx source tree compared to the DDK trees.
BR, Nikolaus
BR, Nikolaus
śr., 13 lut 2019 o 07:36 H. Nikolaus Schaller hns@goldelico.com napisał(a): Hi Tony,
Am 13.02.2019 um 01:41 schrieb Tony Lindgren tony@atomide.com:
Hi,
- Philipp Rossak embed3d@gmail.com [190212 22:25]:
I'm looking now into that PVR SGX driver since a while. I already reworked that old "opensource" driver to work with a quite new kernel (4.16 or 4.17) [But that code got lost]. For the sunxi devices this was only a short coding session to get that running. For OMAP this might be easier/faster since the general linux situation is better.
So a git repo that works for omaps and sunxi would be a good start then :)
I'm not sure if we are able to provide a generic driver since there are different userspace versions that are only compatible with their own kernel driver. Not all compile flags for the kernel driver work with all userspace lib versions, at least on sunxi. Be aware that there are also different versions of those GPU ip cores and all have different features and bug fixes.
No doubt it's a mess.. I'm only suggesting a generic driver that manages standard Linux resources like regulators, clocks and interrupts and provides 2d acceleration for sgx540 based on what we already have at drivers/gpu/drm/gma500/accel_2d.c. The idea being that it might then also make dealing with the rest of the sgx blobs a bit easier hopefully.
Well, ok.
So you suggest that we e.g. take the omap SoC support in
http://git.goldelico.com/?p=letux-kernel.git;a=tree;f=drivers/staging/pvr/1....
and make an "eurasia_km / services4 / system / generic" out of it using the 2d functions?
Please take a look into especially sysconfig.c and SysInitialise() which does the lion's share of initialization if it can be rewritten to become generic.
If you reach a good state with that driver, I can try to port that to sunxi. Is there any good/cheap OMAP4/5 Devboard you can recommend?
Hmm so the n900 folks have the sgx blobs working with recent mainline kernels for sgx530 I believe, and Nikolaus is close to having the sgx blobs working for sgx540.
Also for sgx530 with recent kernel. The blobs itself are working, it is just missing code to tell the SGX module where the framebuffer is located in virtual memory. I think setting CONFIG_DRM_FBDEV_OVERALLOC=700 in my case (like old kernel) this will make powervr driver allocate one framebuffer + 2 backbuffers and CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM it should make it working. On my device i had to use different "fix" https://github.com/PabloPL/linux/commit/d0b1df4067a724aa0b38d11c82fd3ff0958a... The physical address of fb is used in driver (and passed to userspace?). It's code is here for my device https://github.com/PabloPL/linux/blob/powervr/drivers/gpu/drm/powervr/s3c_lc... And here is simple devicetree entry which is read by driver (it was added by person which is also working on mainlining my device). https://github.com/PabloPL/linux/blob/powervr/arch/arm/boot/dts/s5pv210-arie...
But this still didn't allowed me to run egl code with that driver. Probably i'll need to get logs from old kernel.
All my code is currently (if someone is interested ) in https://github.com/PabloPL/linux/tree/powervr
I may not be aware of the current status though.
For a devboard with sgx540, you should be able to find one for few tens of units for a used pandaboard-es for example or somebody here might even have an old one to donate. If you feel like playing with a phone, droid 4 xt894 is somewhat usable with mainline kernels with pending patches for LCD and modem, no idea what the sgx540 status on it might be. Pyra handheld is not yet available except for prototypes. And then on beagleboard-x15 there's sgx544, and beaglebone has sgx530 FYI so that might not help if you need sgx540.
Don't expect any support from TI or IMG. TI can't support a project like this, since they don't own the code and IMG is not willing to support.
Yeah that we've seen already over past 10 or so years :)
An other big issue is the leaked SGX source code [1]. So I think it would be better to start a clean room reverse engineering project. I'm already working on that.
OK so we're discussing at least three projects then:
- A git repo that allows sgx blobs to work for various
SoCs with current mainline kernels
Yes.
- A generic 2d sgx540 driver based on existing mainline
kernel drivers/gpu/drm/gma500/accel_2d.c
May be needed or not.
- Your reverse engineering project that might help
with figuring out how things are supposed to work
IMHO a completely separate project.
Basically there is a strict layering:
L4 user-space libraries L3 SGX firmware L2 SGX firmware loader L1 SoC glue (clock, reset, dma, virtual memory, ...)
I am mainly considering L1 here and fixing L2. L1 is SoC specific of course and L2 needs Linux-release specific patches.
L2-L4 depend on SGX version.
L2 contains a lot of #ifdef that depend on SGX530/540/544 and even more.
Reverse engineering addresses L3 and L4.
Of course if will be is successful it might become possible to improve the whole L1-L4 stack, but that is another 10 years in the future :)
Since it is such a big task, I would propose to start with something close to working (some TI/IMG DDK) and improve on that instead of starting with parts from scratch.
BR, Nikolaus
Do we have: - mailing list (now getting email that moderator needs to review each my reply)? - common repo (github/gitlab )? - more popular, so it should be much easier to collaborate for anyone
śr., 13 lut 2019 o 08:56 H. Nikolaus Schaller hns@goldelico.com napisał(a):
Hi Pawel,
Am 13.02.2019 um 08:36 schrieb Paweł Chmiel <
pawel.mikolaj.chmiel@gmail.com>:
śr., 13 lut 2019 o 08:25 H. Nikolaus Schaller hns@goldelico.com
napisał(a):
Hi Pawel,
Am 13.02.2019 um 08:14 schrieb Paweł Chmiel <
pawel.mikolaj.chmiel@gmail.com>:
Hi all, thanks for adding my to this topic. I'm using Power SGX540 on my Samsung s5pv210 based device (Samsung
Galaxy S - i9000 phone - i've added support for it to mainline).
Great!
Do anyone has it (sgx540) working on mainline (5.0) kernel? Currently
i've forward ported old driver, written by google ( https://android.googlesource.com/kernel/samsung/+/android-samsung-3.0-jb-mr0... )
to 5.0 kernel.
Unfortunately no. I have not invested time into SGX540 (although there
is code in my tree). Iworked on omap3/amm335x.
I'm able to to gpu init (run pvrsrvinit), but when trying to run some
sample code i'm getting 0 available egl configurations. I think i've fixed problems with framebuffer setup (by making framebuffer big like it was on old kernel - so it will allocate one framebuffer and 2 backbuffers in my case).
Yes, that is almost the same state as I have for omap3. I can run
pvrsrvinit but it does not find framebuffers. Because it tries to use omaplfb which is not DRM compatible. So I would have to rewrite that first.
I'm also using something similar to omaplfb (on my soc it is s3c_lcd
code - https://github.com/PabloPL/linux/tree/powervr/drivers/gpu/drm/powervr/s3c_lc...
- it's dirrectly writing to framebuffer) and i'm able to pass after this.
I wanted to get running something which was working on old kernel
(rather than trying to take driver from omap/etc and add support for my soc there) and then see how it works etc.
Do You have strace of pvrsrvinit run ? They should be almost identical
to one which i have.
Yes, I can make a test setup (I still have to check on which kernel versions it works since I am not sure if 5.0-rc is broken or not) and run an strace in the next days.
We could also write something like it was done for lima (
https://github.com/limadriver/lima/tree/master/wrap or https://github.com/yuq/mali-syscall-tracker), to capture ioctl and dump content of it.
But first it would be nice to have some sample codes (there was some
from img with their sdk for ti. need to search for it), which we could run and then compare logs.
After enabling debug code in driver i'm currently getting followin logs https://gist.github.com/PabloPL/c1e98f405e67d577afcf51c36228efdc (BTW
it's android binaries running on ubuntu on that s5pv210 device).
So it turns out that we have several initiatives by individuals that
did start at different versions of the DDK&Linux-Glue and adjusted it to different SGX versions and some specific SoCs.
What I would propose then is that we check if the DDK 1.14 is really
the latest existing one, install it in some common git repo and have us all work on this
common basis to redo the integration we have done on our individual
trees.
And someone rebases this DDK every week to the latest linus/master.
This also reveals API changes we need to track in the glue code.
So we definitively need some common git to synchronize efforts. My
proposal would still be kernel.org/drivers/staging/pvr, because it would be eliminate the need to rebase every week...
But what would be other options?
Is DDK 1.14 for omap5 the same like for omap4 ? I have some copy of
https://github.com/rcn-ee/ti-omap5-sgx-ddk-linux which i've fixed to build under 4.20 (should be also easy to build it under 5.0).
In my understanding DDK 1.14 is not only for omap4 or 5 but supports a collection of devices (and a long list of SGX variants). See
http://git.goldelico.com/?p=letux-kernel.git;a=tree;f=drivers/staging/pvr/1....
There one finds
- cedarview (some Intel Atom)
- omap (probably means am335x/omap3/4/5)
- poulsbo
- jz4780
- pc_i686_tc3
- sunxi
And the list of supported SGX variants is inside this file:
http://git.goldelico.com/?p=letux-kernel.git;a=blob;f=drivers/staging/pvr/1....
So this tree appears to be already very broad and easy to modify to serve everybody.
BTW: I found that Android kernels usually use a reduced and flattened sgx source tree compared to the DDK trees.
BR, Nikolaus
BR, Nikolaus
śr., 13 lut 2019 o 07:36 H. Nikolaus Schaller hns@goldelico.com
napisał(a):
Hi Tony,
Am 13.02.2019 um 01:41 schrieb Tony Lindgren tony@atomide.com:
Hi,
- Philipp Rossak embed3d@gmail.com [190212 22:25]:
I'm looking now into that PVR SGX driver since a while. I already
reworked
that old "opensource" driver to work with a quite new kernel (4.16
or 4.17)
[But that code got lost]. For the sunxi devices this was only a short coding session to get
that
running. For OMAP this might be easier/faster since the general linux situation is better.
So a git repo that works for omaps and sunxi would be a good start then :)
I'm not sure if we are able to provide a generic driver since there
are
different userspace versions that are only compatible with their own
kernel
driver. Not all compile flags for the kernel driver work with all
userspace
lib versions, at least on sunxi. Be aware that there are also
different
versions of those GPU ip cores and all have different features and
bug
fixes.
No doubt it's a mess.. I'm only suggesting a generic driver that manages standard Linux resources like regulators, clocks and interrupts and provides 2d acceleration for sgx540 based on what we already have at drivers/gpu/drm/gma500/accel_2d.c. The idea being that it might then also make dealing with the rest of the sgx blobs a bit easier hopefully.
Well, ok.
So you suggest that we e.g. take the omap SoC support in
http://git.goldelico.com/?p=letux-kernel.git;a=tree;f=drivers/staging/pvr/1....
and make an "eurasia_km / services4 / system / generic" out of it using the 2d functions?
Please take a look into especially sysconfig.c and SysInitialise() which does the lion's share of initialization if it can be rewritten to become generic.
If you reach a good state with that driver, I can try to port that
to sunxi.
Is there any good/cheap OMAP4/5 Devboard you can recommend?
Hmm so the n900 folks have the sgx blobs working with recent mainline kernels for sgx530 I believe, and Nikolaus is close to having the sgx blobs working for sgx540.
Also for sgx530 with recent kernel. The blobs itself are working, it is just missing code to tell the SGX module where the framebuffer is located in virtual memory. I think setting CONFIG_DRM_FBDEV_OVERALLOC=700 in my case (like old kernel) this will make powervr driver allocate one
framebuffer + 2 backbuffers
and CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM it should make it working. On my device i had to use different "fix"
https://github.com/PabloPL/linux/commit/d0b1df4067a724aa0b38d11c82fd3ff0958a...
The physical address of fb is used in driver (and passed to
userspace?). It's code is here for my device
https://github.com/PabloPL/linux/blob/powervr/drivers/gpu/drm/powervr/s3c_lc...
And here is simple devicetree entry which is read by driver (it was
added by person which is also working on mainlining my device).
https://github.com/PabloPL/linux/blob/powervr/arch/arm/boot/dts/s5pv210-arie...
But this still didn't allowed me to run egl code with that driver.
Probably i'll need to get logs from old kernel.
All my code is currently (if someone is interested ) in
https://github.com/PabloPL/linux/tree/powervr
I may not be aware of the current status though.
For a devboard with sgx540, you should be able to find one for few tens of units for a used pandaboard-es for example or somebody here might even have an old one to donate. If you feel like playing with a phone, droid 4 xt894 is somewhat usable with mainline kernels with pending patches for LCD and modem, no idea what the sgx540 status on it might be. Pyra handheld is not yet available except for prototypes. And then on beagleboard-x15 there's sgx544, and beaglebone has sgx530 FYI so that might not help if you need sgx540.
Don't expect any support from TI or IMG. TI can't support a project
like
this, since they don't own the code and IMG is not willing to
support.
Yeah that we've seen already over past 10 or so years :)
An other big issue is the leaked SGX source code [1]. So I think it
would be
better to start a clean room reverse engineering project. I'm already working on that.
OK so we're discussing at least three projects then:
- A git repo that allows sgx blobs to work for various
SoCs with current mainline kernels
Yes.
- A generic 2d sgx540 driver based on existing mainline
kernel drivers/gpu/drm/gma500/accel_2d.c
May be needed or not.
- Your reverse engineering project that might help
with figuring out how things are supposed to work
IMHO a completely separate project.
Basically there is a strict layering:
L4 user-space libraries L3 SGX firmware L2 SGX firmware loader L1 SoC glue (clock, reset, dma, virtual memory, ...)
I am mainly considering L1 here and fixing L2. L1 is SoC specific of course and L2 needs Linux-release specific patches.
L2-L4 depend on SGX version.
L2 contains a lot of #ifdef that depend on SGX530/540/544 and even more.
Reverse engineering addresses L3 and L4.
Of course if will be is successful it might become possible to improve the whole L1-L4 stack, but that is another 10 years in the future :)
Since it is such a big task, I would propose to start with something close to working (some TI/IMG DDK) and improve on that instead of starting with parts from scratch.
BR, Nikolaus
Hi Pawel,
Am 13.02.2019 um 08:36 schrieb Paweł Chmiel pawel.mikolaj.chmiel@gmail.com:
Do You have strace of pvrsrvinit run ? They should be almost identical to one which i have.
I have digged out a version where pvrsrvinit succeeds on our omap3530 based gta04 board (kernel 4.15.17).
oot@letux:~# strace pvrsrvctl --start --no-module execve("/usr/local/bin/pvrsrvctl", ["pvrsrvctl", "--start", "--no-module"], [/* 14 vars */]) = 0 brk(0) = 0x12000 uname({sys="Linux", node="letux", ...}) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6efd000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/tls/v7l/neon/vfp/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/tls/v7l/neon/vfp", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/tls/v7l/neon/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/tls/v7l/neon", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/tls/v7l/vfp/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/tls/v7l/vfp", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/tls/v7l/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/tls/v7l", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/tls/neon/vfp/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/tls/neon/vfp", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/tls/neon/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/tls/neon", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/tls/vfp/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/tls/vfp", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/tls/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/tls", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/v7l/neon/vfp/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/v7l/neon/vfp", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/v7l/neon/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/v7l/neon", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/v7l/vfp/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/v7l/vfp", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/v7l/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/v7l", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/neon/vfp/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/neon/vfp", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/neon/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/neon", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/vfp/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/vfp", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=45046, ...}) = 0 mmap2(NULL, 45046, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb6ef2000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libsrv_init.so", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0<\7\0\0004\0\0\0"..., 512) = 512 lseek(3, 94656, SEEK_SET) = 94656 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1040) = 1040 lseek(3, 94346, SEEK_SET) = 94346 read(3, "A6\0\0\0aeabi\0\1,\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\4\22"..., 55) = 55 fstat64(3, {st_mode=S_IFREG|0755, st_size=95696, ...}) = 0 mmap2(NULL, 127076, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6eb8000 mprotect(0xb6ecf000, 28672, PROT_NONE) = 0 mmap2(0xb6ed6000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16000) = 0xb6ed6000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/arm-linux-gnueabihf/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0Mw\1\0004\0\0\0"..., 512) = 512 lseek(3, 908188, SEEK_SET) = 908188 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 2880) = 2880 lseek(3, 904740, SEEK_SET) = 904740 read(3, "A4\0\0\0aeabi\0\1*\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\3\f"..., 53) = 53 fstat64(3, {st_mode=S_IFREG|0755, st_size=911068, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6ef1000 mmap2(NULL, 980392, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6dc8000 mprotect(0xb6ea3000, 61440, PROT_NONE) = 0 mmap2(0xb6eb2000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xda000) = 0xb6eb2000 mmap2(0xb6eb5000, 9640, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6eb5000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libsrv_um.so", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\340#\0\0004\0\0\0"..., 512) = 512 lseek(3, 168544, SEEK_SET) = 168544 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1120) = 1120 lseek(3, 168210, SEEK_SET) = 168210 read(3, "A6\0\0\0aeabi\0\1,\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\4\22"..., 55) = 55 fstat64(3, {st_mode=S_IFREG|0755, st_size=169664, ...}) = 0 mmap2(NULL, 200992, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6d96000 mprotect(0xb6dbe000, 28672, PROT_NONE) = 0 mmap2(0xb6dc5000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x27000) = 0xb6dc5000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/arm-linux-gnueabihf/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\240\t\0\0004\0\0\0"..., 512) = 512 lseek(3, 8664, SEEK_SET) = 8664 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1160) = 1160 lseek(3, 8328, SEEK_SET) = 8328 read(3, "A4\0\0\0aeabi\0\1*\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\4\22"..., 53) = 53 fstat64(3, {st_mode=S_IFREG|0644, st_size=9824, ...}) = 0 mmap2(NULL, 73912, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6d83000 mprotect(0xb6d85000, 61440, PROT_NONE) = 0 mmap2(0xb6d94000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0xb6d94000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/arm-linux-gnueabihf/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0EQ\0\0004\0\0\0"..., 512) = 512 lseek(3, 100684, SEEK_SET) = 100684 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1520) = 1520 lseek(3, 65940, SEEK_SET) = 65940 read(3, "A4\0\0\0aeabi\0\1*\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\4\22"..., 53) = 53 fstat64(3, {st_mode=S_IFREG|0755, st_size=102204, ...}) = 0 mmap2(NULL, 139836, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6d60000 mprotect(0xb6d70000, 61440, PROT_NONE) = 0 mmap2(0xb6d7f000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf000) = 0xb6d7f000 mmap2(0xb6d81000, 4668, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6d81000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/arm-linux-gnueabihf/librt.so.1", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0@\30\0\0004\0\0\0"..., 512) = 512 lseek(3, 21260, SEEK_SET) = 21260 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1320) = 1320 lseek(3, 20868, SEEK_SET) = 20868 read(3, "A4\0\0\0aeabi\0\1*\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\4\22"..., 53) = 53 fstat64(3, {st_mode=S_IFREG|0644, st_size=22580, ...}) = 0 mmap2(NULL, 86588, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6d4a000 mprotect(0xb6d4f000, 61440, PROT_NONE) = 0 mmap2(0xb6d5e000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4000) = 0xb6d5e000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/arm-linux-gnueabihf/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\230\321\0\0004\0\0\0"..., 512) = 512 lseek(3, 99900, SEEK_SET) = 99900 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1120) = 1120 lseek(3, 99568, SEEK_SET) = 99568 read(3, "A2\0\0\0aeabi\0\1(\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\4\22"..., 51) = 51 fstat64(3, {st_mode=S_IFREG|0644, st_size=101020, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6ef0000 mmap2(NULL, 165160, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6d21000 mprotect(0xb6d3a000, 61440, PROT_NONE) = 0 mmap2(0xb6d49000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x18000) = 0xb6d49000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6d20000 set_tls(0xb6d204c0, 0xb6f00058, 0xb6d20ba8, 0xb6d204c0, 0xb6f00058) = 0 mprotect(0xb6eb2000, 8192, PROT_READ) = 0 mprotect(0xb6d7f000, 4096, PROT_READ) = 0 mprotect(0xb6d5e000, 4096, PROT_READ) = 0 mprotect(0xb6d94000, 4096, PROT_READ) = 0 mprotect(0xb6dc5000, 8192, PROT_READ) = 0 mprotect(0xb6ed6000, 4096, PROT_READ) = 0 mprotect(0x10000, 4096, PROT_READ) = 0 mprotect(0xb6eff000, 4096, PROT_READ) = 0 munmap(0xb6ef2000, 45046) = 0 set_tid_address(0xb6d20068) = 2672 set_robust_list(0xb6d20070, 12) = 0 rt_sigaction(SIGRTMIN, {0xb6d64d9d, [], SA_RESTORER|SA_SIGINFO, 0xb6deeb01}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0xb6d64cbd, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0xb6deeb01}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 brk(0) = 0x12000 brk(0x33000) = 0x33000 open("/dev/pvrsrvkm", O_RDWR) = 3 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 ioctl(3, 0xc01c670c, 0xbeb3e9bc) = 0 ioctl(3, 0xc01c6744, 0xbeb3e9fc) = 0 ioctl(3, 0xc01c6700, 0xbeb3e8a4) = 0 ioctl(3, 0xc01c6701, 0xbeb3e90c) = 0 ioctl(3, 0xc01c6763, 0xbeb3e614) = 0 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000005000) = 0xb6efb000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000006000) = 0xb6efa000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000007000) = 0xb6ef9000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000008000) = 0xb6ef8000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000009000) = 0xb6ef7000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x8000000a000) = 0xb6ef6000 ioctl(3, 0xc01c6706, 0xbeb3e80c) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7cc) = 0 mmap2(NULL, 28672, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x8000000b000) = 0xb6d19000 open("/etc/powervr.ini", O_RDONLY) = -1 ENOENT (No such file or directory) open("powervr.ini", O_RDONLY) = -1 ENOENT (No such file or directory) ioctl(3, 0xc01c6706, 0xbeb3e80c) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7cc) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x8000000c000) = 0xb6ef5000 ioctl(3, 0xc01c6706, 0xbeb3e80c) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7cc) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x8000000d000) = 0xb6ef4000 ioctl(3, 0xc01c6706, 0xbeb3e7fc) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7bc) = 0 mmap2(NULL, 24576, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x8000000e000) = 0xb6d13000 ioctl(3, 0xc01c6706, 0xbeb3e7fc) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7bc) = 0 mmap2(NULL, 24576, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x8000000f000) = 0xb6d0d000 ioctl(3, 0xc01c6706, 0xbeb3e7fc) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7bc) = 0 mmap2(NULL, 20480, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000010000) = 0xb6d08000 ioctl(3, 0xc01c6706, 0xbeb3e7fc) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7bc) = 0 mmap2(NULL, 24576, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000011000) = 0xb6d02000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000012000) = 0xb6ef3000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000013000) = 0xb6ef2000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000014000) = 0xb6d01000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000015000) = 0xb6d00000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000016000) = 0xb6cff000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6efb000, 8192) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6efa000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6ef9000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6ef7000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6ef8000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6ef6000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6d19000, 28672) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6ef5000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6ef4000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6d13000, 24576) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6d0d000, 24576) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6d02000, 24576) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6d08000, 20480) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6ef3000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6ef2000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6d01000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6d00000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6cff000, 4096) = 0 ioctl(3, 0xc01c6764, 0xbeb3e91c) = 0 ioctl(3, 0xc01c6745, 0xbeb3e9ec) = 0 ioctl(3, 0xc01c670d, 0xbeb3e9c4) = 0 close(3) = 0 exit_group(0) = ? +++ exited with 0 +++ root@letux:~#
root@letux:~# ls -l /dev/pvrsrvkm crw------- 1 root root 240, 0 Jan 1 00:06 /dev/pvrsrvkm root@letux:~# uname -a Linux letux 4.15.17-letux+ #3337 SMP PREEMPT Wed Feb 13 16:56:27 CET 2019 armv7l GNU/Linux root@letux:~# ./gpu-demo autodetected driver package: omap3630-sgx530-125 compatible driver: omap3630_sgx530_125 System Version String: SGX revision = 125 ----------------- SGX CLipBlit test ----------------- ---------------------- Start ------------------------ Call PVRSRVConnect with a valid argument: OK Get number of devices from PVRSRVEnumerateDevices: OK .... Reported 1 devices .... Device Number | Device Type 0000 | PVRSRV_DEVICE_ID_SGX Attempt to acquire device 0: OK Getting SGX Client info OK .... ui32ProcessID:2691 Display Class API: enumerate devices OK PVRSRVEnumerateDeviceClass() returns 0 display device(s) FAIL - PVRSRV_ERROR_NO_DC_DEVICES_FOUND(134) ./gpu-demo: line 71: 2691 Aborted sgx_clipblit_test root@letux:~#
As you can see the firmware is loaded and connected successfully. Then it just fails to enumerate a display which is the missing/unfixed omaplfb.
Some newer kernels did fail with
rt_sigaction(SIGRTMIN, {0xb6e07d9d, [], SA_RESTORER|SA_SIGINFO, 0xb6e91b01}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0xb6e07cbd, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0xb6e91b01}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 brk(0) = 0x12000 brk(0x33000) = 0x33000 open("/dev/pvrsrvkm", O_RDWR) = -1 ENOMEM (Cannot allocate memory) write(2, "pvrsrvctl: SrvInit failed (alrea"..., 57pvrsrvctl: SrvInit failed (already initialized?) (err=4) ) = 57 exit_group(1) = ? +++ exited with 1 +++
So I have to check what did break in between. And when. Most likely something with memory allocation.
Hope this helps!
BR, Nikolaus
śr., 13 lut 2019 o 17:33 H. Nikolaus Schaller hns@goldelico.com napisał(a):
Hi Pawel,
Am 13.02.2019 um 08:36 schrieb Paweł Chmiel pawel.mikolaj.chmiel@gmail.com:
Do You have strace of pvrsrvinit run ? They should be almost identical to one which i have.
I have digged out a version where pvrsrvinit succeeds on our omap3530 based gta04 board (kernel 4.15.17).
oot@letux:~# strace pvrsrvctl --start --no-module execve("/usr/local/bin/pvrsrvctl", ["pvrsrvctl", "--start", "--no-module"], [/* 14 vars */]) = 0 brk(0) = 0x12000 uname({sys="Linux", node="letux", ...}) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6efd000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/tls/v7l/neon/vfp/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/tls/v7l/neon/vfp", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/tls/v7l/neon/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/tls/v7l/neon", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/tls/v7l/vfp/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/tls/v7l/vfp", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/tls/v7l/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/tls/v7l", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/tls/neon/vfp/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/tls/neon/vfp", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/tls/neon/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/tls/neon", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/tls/vfp/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/tls/vfp", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/tls/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/tls", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/v7l/neon/vfp/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/v7l/neon/vfp", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/v7l/neon/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/v7l/neon", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/v7l/vfp/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/v7l/vfp", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/v7l/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/v7l", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/neon/vfp/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/neon/vfp", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/neon/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/neon", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/vfp/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/vfp", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=45046, ...}) = 0 mmap2(NULL, 45046, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb6ef2000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libsrv_init.so", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0<\7\0\0004\0\0\0"..., 512) = 512 lseek(3, 94656, SEEK_SET) = 94656 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1040) = 1040 lseek(3, 94346, SEEK_SET) = 94346 read(3, "A6\0\0\0aeabi\0\1,\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\4\22"..., 55) = 55 fstat64(3, {st_mode=S_IFREG|0755, st_size=95696, ...}) = 0 mmap2(NULL, 127076, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6eb8000 mprotect(0xb6ecf000, 28672, PROT_NONE) = 0 mmap2(0xb6ed6000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16000) = 0xb6ed6000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/arm-linux-gnueabihf/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0Mw\1\0004\0\0\0"..., 512) = 512 lseek(3, 908188, SEEK_SET) = 908188 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 2880) = 2880 lseek(3, 904740, SEEK_SET) = 904740 read(3, "A4\0\0\0aeabi\0\1*\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\3\f"..., 53) = 53 fstat64(3, {st_mode=S_IFREG|0755, st_size=911068, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6ef1000 mmap2(NULL, 980392, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6dc8000 mprotect(0xb6ea3000, 61440, PROT_NONE) = 0 mmap2(0xb6eb2000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xda000) = 0xb6eb2000 mmap2(0xb6eb5000, 9640, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6eb5000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libsrv_um.so", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\340#\0\0004\0\0\0"..., 512) = 512 lseek(3, 168544, SEEK_SET) = 168544 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1120) = 1120 lseek(3, 168210, SEEK_SET) = 168210 read(3, "A6\0\0\0aeabi\0\1,\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\4\22"..., 55) = 55 fstat64(3, {st_mode=S_IFREG|0755, st_size=169664, ...}) = 0 mmap2(NULL, 200992, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6d96000 mprotect(0xb6dbe000, 28672, PROT_NONE) = 0 mmap2(0xb6dc5000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x27000) = 0xb6dc5000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/arm-linux-gnueabihf/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\240\t\0\0004\0\0\0"..., 512) = 512 lseek(3, 8664, SEEK_SET) = 8664 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1160) = 1160 lseek(3, 8328, SEEK_SET) = 8328 read(3, "A4\0\0\0aeabi\0\1*\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\4\22"..., 53) = 53 fstat64(3, {st_mode=S_IFREG|0644, st_size=9824, ...}) = 0 mmap2(NULL, 73912, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6d83000 mprotect(0xb6d85000, 61440, PROT_NONE) = 0 mmap2(0xb6d94000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0xb6d94000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/arm-linux-gnueabihf/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0EQ\0\0004\0\0\0"..., 512) = 512 lseek(3, 100684, SEEK_SET) = 100684 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1520) = 1520 lseek(3, 65940, SEEK_SET) = 65940 read(3, "A4\0\0\0aeabi\0\1*\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\4\22"..., 53) = 53 fstat64(3, {st_mode=S_IFREG|0755, st_size=102204, ...}) = 0 mmap2(NULL, 139836, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6d60000 mprotect(0xb6d70000, 61440, PROT_NONE) = 0 mmap2(0xb6d7f000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf000) = 0xb6d7f000 mmap2(0xb6d81000, 4668, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6d81000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/arm-linux-gnueabihf/librt.so.1", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0@\30\0\0004\0\0\0"..., 512) = 512 lseek(3, 21260, SEEK_SET) = 21260 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1320) = 1320 lseek(3, 20868, SEEK_SET) = 20868 read(3, "A4\0\0\0aeabi\0\1*\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\4\22"..., 53) = 53 fstat64(3, {st_mode=S_IFREG|0644, st_size=22580, ...}) = 0 mmap2(NULL, 86588, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6d4a000 mprotect(0xb6d4f000, 61440, PROT_NONE) = 0 mmap2(0xb6d5e000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4000) = 0xb6d5e000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/arm-linux-gnueabihf/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\230\321\0\0004\0\0\0"..., 512) = 512 lseek(3, 99900, SEEK_SET) = 99900 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1120) = 1120 lseek(3, 99568, SEEK_SET) = 99568 read(3, "A2\0\0\0aeabi\0\1(\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\4\22"..., 51) = 51 fstat64(3, {st_mode=S_IFREG|0644, st_size=101020, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6ef0000 mmap2(NULL, 165160, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6d21000 mprotect(0xb6d3a000, 61440, PROT_NONE) = 0 mmap2(0xb6d49000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x18000) = 0xb6d49000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6d20000 set_tls(0xb6d204c0, 0xb6f00058, 0xb6d20ba8, 0xb6d204c0, 0xb6f00058) = 0 mprotect(0xb6eb2000, 8192, PROT_READ) = 0 mprotect(0xb6d7f000, 4096, PROT_READ) = 0 mprotect(0xb6d5e000, 4096, PROT_READ) = 0 mprotect(0xb6d94000, 4096, PROT_READ) = 0 mprotect(0xb6dc5000, 8192, PROT_READ) = 0 mprotect(0xb6ed6000, 4096, PROT_READ) = 0 mprotect(0x10000, 4096, PROT_READ) = 0 mprotect(0xb6eff000, 4096, PROT_READ) = 0 munmap(0xb6ef2000, 45046) = 0 set_tid_address(0xb6d20068) = 2672 set_robust_list(0xb6d20070, 12) = 0 rt_sigaction(SIGRTMIN, {0xb6d64d9d, [], SA_RESTORER|SA_SIGINFO, 0xb6deeb01}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0xb6d64cbd, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0xb6deeb01}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 brk(0) = 0x12000 brk(0x33000) = 0x33000 open("/dev/pvrsrvkm", O_RDWR) = 3 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 ioctl(3, 0xc01c670c, 0xbeb3e9bc) = 0 ioctl(3, 0xc01c6744, 0xbeb3e9fc) = 0 ioctl(3, 0xc01c6700, 0xbeb3e8a4) = 0 ioctl(3, 0xc01c6701, 0xbeb3e90c) = 0 ioctl(3, 0xc01c6763, 0xbeb3e614) = 0 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000005000) = 0xb6efb000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000006000) = 0xb6efa000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000007000) = 0xb6ef9000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000008000) = 0xb6ef8000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000009000) = 0xb6ef7000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x8000000a000) = 0xb6ef6000 ioctl(3, 0xc01c6706, 0xbeb3e80c) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7cc) = 0 mmap2(NULL, 28672, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x8000000b000) = 0xb6d19000 open("/etc/powervr.ini", O_RDONLY) = -1 ENOENT (No such file or directory) open("powervr.ini", O_RDONLY) = -1 ENOENT (No such file or directory) ioctl(3, 0xc01c6706, 0xbeb3e80c) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7cc) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x8000000c000) = 0xb6ef5000 ioctl(3, 0xc01c6706, 0xbeb3e80c) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7cc) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x8000000d000) = 0xb6ef4000 ioctl(3, 0xc01c6706, 0xbeb3e7fc) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7bc) = 0 mmap2(NULL, 24576, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x8000000e000) = 0xb6d13000 ioctl(3, 0xc01c6706, 0xbeb3e7fc) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7bc) = 0 mmap2(NULL, 24576, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x8000000f000) = 0xb6d0d000 ioctl(3, 0xc01c6706, 0xbeb3e7fc) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7bc) = 0 mmap2(NULL, 20480, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000010000) = 0xb6d08000 ioctl(3, 0xc01c6706, 0xbeb3e7fc) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7bc) = 0 mmap2(NULL, 24576, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000011000) = 0xb6d02000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000012000) = 0xb6ef3000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000013000) = 0xb6ef2000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000014000) = 0xb6d01000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000015000) = 0xb6d00000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000016000) = 0xb6cff000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6efb000, 8192) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6efa000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6ef9000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6ef7000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6ef8000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6ef6000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6d19000, 28672) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6ef5000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6ef4000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6d13000, 24576) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6d0d000, 24576) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6d02000, 24576) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6d08000, 20480) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6ef3000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6ef2000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6d01000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6d00000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6cff000, 4096) = 0 ioctl(3, 0xc01c6764, 0xbeb3e91c) = 0 ioctl(3, 0xc01c6745, 0xbeb3e9ec) = 0 ioctl(3, 0xc01c670d, 0xbeb3e9c4) = 0 close(3) = 0 exit_group(0) = ? +++ exited with 0 +++ root@letux:~#
root@letux:~# ls -l /dev/pvrsrvkm crw------- 1 root root 240, 0 Jan 1 00:06 /dev/pvrsrvkm root@letux:~# uname -a Linux letux 4.15.17-letux+ #3337 SMP PREEMPT Wed Feb 13 16:56:27 CET 2019 armv7l GNU/Linux root@letux:~# ./gpu-demo autodetected driver package: omap3630-sgx530-125 compatible driver: omap3630_sgx530_125 System Version String: SGX revision = 125 ----------------- SGX CLipBlit test ----------------- ---------------------- Start ------------------------ Call PVRSRVConnect with a valid argument: OK Get number of devices from PVRSRVEnumerateDevices: OK .... Reported 1 devices .... Device Number | Device Type 0000 | PVRSRV_DEVICE_ID_SGX Attempt to acquire device 0: OK Getting SGX Client info OK .... ui32ProcessID:2691 Display Class API: enumerate devices OK PVRSRVEnumerateDeviceClass() returns 0 display device(s) FAIL - PVRSRV_ERROR_NO_DC_DEVICES_FOUND(134) ./gpu-demo: line 71: 2691 Aborted sgx_clipblit_test root@letux:~#
Where i could find that SGX_ClipBlit test (source or binary)?
As you can see the firmware is loaded and connected successfully. Then it just fails to enumerate a display which is the missing/unfixed omaplfb.
Some newer kernels did fail with
rt_sigaction(SIGRTMIN, {0xb6e07d9d, [], SA_RESTORER|SA_SIGINFO, 0xb6e91b01}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0xb6e07cbd, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0xb6e91b01}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 brk(0) = 0x12000 brk(0x33000) = 0x33000 open("/dev/pvrsrvkm", O_RDWR) = -1 ENOMEM (Cannot allocate memory) write(2, "pvrsrvctl: SrvInit failed (alrea"..., 57pvrsrvctl: SrvInit failed (already initialized?) (err=4) ) = 57 exit_group(1) = ? +++ exited with 1 +++
So I have to check what did break in between. And when. Most likely something with memory allocation.
For mainline You will probably need https://github.com/PabloPL/linux/commit/de0f7e299d94f5dfdcf15375ec2d3ace54ac... because powervr is using some strange pointers.
I'm building my kernel and will get strace output of pvrsrvinit on my device (where it's working) in few minutes. For me it fails when trying to use egl programs (egl configurations = 0). Of course on mainline (5.0-rc4).
Hope this helps!
BR, Nikolaus
śr., 13 lut 2019 o 17:45 Paweł Chmiel pawel.mikolaj.chmiel@gmail.com napisał(a):
śr., 13 lut 2019 o 17:33 H. Nikolaus Schaller hns@goldelico.com napisał(a):
Hi Pawel,
Am 13.02.2019 um 08:36 schrieb Paweł Chmiel pawel.mikolaj.chmiel@gmail.com:
Do You have strace of pvrsrvinit run ? They should be almost identical to one which i have.
I have digged out a version where pvrsrvinit succeeds on our omap3530 based gta04 board (kernel 4.15.17).
oot@letux:~# strace pvrsrvctl --start --no-module execve("/usr/local/bin/pvrsrvctl", ["pvrsrvctl", "--start", "--no-module"], [/* 14 vars */]) = 0 brk(0) = 0x12000 uname({sys="Linux", node="letux", ...}) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6efd000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/tls/v7l/neon/vfp/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/tls/v7l/neon/vfp", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/tls/v7l/neon/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/tls/v7l/neon", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/tls/v7l/vfp/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/tls/v7l/vfp", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/tls/v7l/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/tls/v7l", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/tls/neon/vfp/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/tls/neon/vfp", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/tls/neon/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/tls/neon", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/tls/vfp/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/tls/vfp", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/tls/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/tls", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/v7l/neon/vfp/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/v7l/neon/vfp", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/v7l/neon/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/v7l/neon", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/v7l/vfp/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/v7l/vfp", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/v7l/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/v7l", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/neon/vfp/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/neon/vfp", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/neon/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/neon", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/vfp/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib/vfp", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/usr/local/XSGX/lib/libsrv_init.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/local/XSGX/lib", 0xbeb3d420) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=45046, ...}) = 0 mmap2(NULL, 45046, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb6ef2000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libsrv_init.so", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0<\7\0\0004\0\0\0"..., 512) = 512 lseek(3, 94656, SEEK_SET) = 94656 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1040) = 1040 lseek(3, 94346, SEEK_SET) = 94346 read(3, "A6\0\0\0aeabi\0\1,\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\4\22"..., 55) = 55 fstat64(3, {st_mode=S_IFREG|0755, st_size=95696, ...}) = 0 mmap2(NULL, 127076, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6eb8000 mprotect(0xb6ecf000, 28672, PROT_NONE) = 0 mmap2(0xb6ed6000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16000) = 0xb6ed6000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/arm-linux-gnueabihf/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0Mw\1\0004\0\0\0"..., 512) = 512 lseek(3, 908188, SEEK_SET) = 908188 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 2880) = 2880 lseek(3, 904740, SEEK_SET) = 904740 read(3, "A4\0\0\0aeabi\0\1*\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\3\f"..., 53) = 53 fstat64(3, {st_mode=S_IFREG|0755, st_size=911068, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6ef1000 mmap2(NULL, 980392, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6dc8000 mprotect(0xb6ea3000, 61440, PROT_NONE) = 0 mmap2(0xb6eb2000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xda000) = 0xb6eb2000 mmap2(0xb6eb5000, 9640, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6eb5000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libsrv_um.so", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\340#\0\0004\0\0\0"..., 512) = 512 lseek(3, 168544, SEEK_SET) = 168544 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1120) = 1120 lseek(3, 168210, SEEK_SET) = 168210 read(3, "A6\0\0\0aeabi\0\1,\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\4\22"..., 55) = 55 fstat64(3, {st_mode=S_IFREG|0755, st_size=169664, ...}) = 0 mmap2(NULL, 200992, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6d96000 mprotect(0xb6dbe000, 28672, PROT_NONE) = 0 mmap2(0xb6dc5000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x27000) = 0xb6dc5000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/arm-linux-gnueabihf/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\240\t\0\0004\0\0\0"..., 512) = 512 lseek(3, 8664, SEEK_SET) = 8664 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1160) = 1160 lseek(3, 8328, SEEK_SET) = 8328 read(3, "A4\0\0\0aeabi\0\1*\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\4\22"..., 53) = 53 fstat64(3, {st_mode=S_IFREG|0644, st_size=9824, ...}) = 0 mmap2(NULL, 73912, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6d83000 mprotect(0xb6d85000, 61440, PROT_NONE) = 0 mmap2(0xb6d94000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0xb6d94000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/arm-linux-gnueabihf/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0EQ\0\0004\0\0\0"..., 512) = 512 lseek(3, 100684, SEEK_SET) = 100684 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1520) = 1520 lseek(3, 65940, SEEK_SET) = 65940 read(3, "A4\0\0\0aeabi\0\1*\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\4\22"..., 53) = 53 fstat64(3, {st_mode=S_IFREG|0755, st_size=102204, ...}) = 0 mmap2(NULL, 139836, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6d60000 mprotect(0xb6d70000, 61440, PROT_NONE) = 0 mmap2(0xb6d7f000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf000) = 0xb6d7f000 mmap2(0xb6d81000, 4668, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6d81000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/arm-linux-gnueabihf/librt.so.1", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0@\30\0\0004\0\0\0"..., 512) = 512 lseek(3, 21260, SEEK_SET) = 21260 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1320) = 1320 lseek(3, 20868, SEEK_SET) = 20868 read(3, "A4\0\0\0aeabi\0\1*\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\4\22"..., 53) = 53 fstat64(3, {st_mode=S_IFREG|0644, st_size=22580, ...}) = 0 mmap2(NULL, 86588, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6d4a000 mprotect(0xb6d4f000, 61440, PROT_NONE) = 0 mmap2(0xb6d5e000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4000) = 0xb6d5e000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/arm-linux-gnueabihf/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\230\321\0\0004\0\0\0"..., 512) = 512 lseek(3, 99900, SEEK_SET) = 99900 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1120) = 1120 lseek(3, 99568, SEEK_SET) = 99568 read(3, "A2\0\0\0aeabi\0\1(\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\4\22"..., 51) = 51 fstat64(3, {st_mode=S_IFREG|0644, st_size=101020, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6ef0000 mmap2(NULL, 165160, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6d21000 mprotect(0xb6d3a000, 61440, PROT_NONE) = 0 mmap2(0xb6d49000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x18000) = 0xb6d49000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6d20000 set_tls(0xb6d204c0, 0xb6f00058, 0xb6d20ba8, 0xb6d204c0, 0xb6f00058) = 0 mprotect(0xb6eb2000, 8192, PROT_READ) = 0 mprotect(0xb6d7f000, 4096, PROT_READ) = 0 mprotect(0xb6d5e000, 4096, PROT_READ) = 0 mprotect(0xb6d94000, 4096, PROT_READ) = 0 mprotect(0xb6dc5000, 8192, PROT_READ) = 0 mprotect(0xb6ed6000, 4096, PROT_READ) = 0 mprotect(0x10000, 4096, PROT_READ) = 0 mprotect(0xb6eff000, 4096, PROT_READ) = 0 munmap(0xb6ef2000, 45046) = 0 set_tid_address(0xb6d20068) = 2672 set_robust_list(0xb6d20070, 12) = 0 rt_sigaction(SIGRTMIN, {0xb6d64d9d, [], SA_RESTORER|SA_SIGINFO, 0xb6deeb01}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0xb6d64cbd, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0xb6deeb01}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 brk(0) = 0x12000 brk(0x33000) = 0x33000 open("/dev/pvrsrvkm", O_RDWR) = 3 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 ioctl(3, 0xc01c670c, 0xbeb3e9bc) = 0 ioctl(3, 0xc01c6744, 0xbeb3e9fc) = 0 ioctl(3, 0xc01c6700, 0xbeb3e8a4) = 0 ioctl(3, 0xc01c6701, 0xbeb3e90c) = 0 ioctl(3, 0xc01c6763, 0xbeb3e614) = 0 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000005000) = 0xb6efb000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000006000) = 0xb6efa000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000007000) = 0xb6ef9000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000008000) = 0xb6ef8000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000009000) = 0xb6ef7000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x8000000a000) = 0xb6ef6000 ioctl(3, 0xc01c6706, 0xbeb3e80c) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7cc) = 0 mmap2(NULL, 28672, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x8000000b000) = 0xb6d19000 open("/etc/powervr.ini", O_RDONLY) = -1 ENOENT (No such file or directory) open("powervr.ini", O_RDONLY) = -1 ENOENT (No such file or directory) ioctl(3, 0xc01c6706, 0xbeb3e80c) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7cc) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x8000000c000) = 0xb6ef5000 ioctl(3, 0xc01c6706, 0xbeb3e80c) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7cc) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x8000000d000) = 0xb6ef4000 ioctl(3, 0xc01c6706, 0xbeb3e7fc) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7bc) = 0 mmap2(NULL, 24576, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x8000000e000) = 0xb6d13000 ioctl(3, 0xc01c6706, 0xbeb3e7fc) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7bc) = 0 mmap2(NULL, 24576, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x8000000f000) = 0xb6d0d000 ioctl(3, 0xc01c6706, 0xbeb3e7fc) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7bc) = 0 mmap2(NULL, 20480, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000010000) = 0xb6d08000 ioctl(3, 0xc01c6706, 0xbeb3e7fc) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7bc) = 0 mmap2(NULL, 24576, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000011000) = 0xb6d02000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000012000) = 0xb6ef3000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000013000) = 0xb6ef2000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000014000) = 0xb6d01000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000015000) = 0xb6d00000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c670b, 0xbeb3e7e4) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000016000) = 0xb6cff000 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c6706, 0xbeb3e824) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6efb000, 8192) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6efa000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6ef9000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6ef7000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6ef8000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6ef6000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6d19000, 28672) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6ef5000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6ef4000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6d13000, 24576) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6d0d000, 24576) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6d02000, 24576) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6d08000, 20480) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6ef3000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6ef2000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6d01000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6d00000, 4096) = 0 ioctl(3, 0xc01c671b, 0xbeb3e8dc) = 0 munmap(0xb6cff000, 4096) = 0 ioctl(3, 0xc01c6764, 0xbeb3e91c) = 0 ioctl(3, 0xc01c6745, 0xbeb3e9ec) = 0 ioctl(3, 0xc01c670d, 0xbeb3e9c4) = 0 close(3) = 0 exit_group(0) = ? +++ exited with 0 +++ root@letux:~#
root@letux:~# ls -l /dev/pvrsrvkm crw------- 1 root root 240, 0 Jan 1 00:06 /dev/pvrsrvkm root@letux:~# uname -a Linux letux 4.15.17-letux+ #3337 SMP PREEMPT Wed Feb 13 16:56:27 CET 2019 armv7l GNU/Linux root@letux:~# ./gpu-demo autodetected driver package: omap3630-sgx530-125 compatible driver: omap3630_sgx530_125 System Version String: SGX revision = 125 ----------------- SGX CLipBlit test ----------------- ---------------------- Start ------------------------ Call PVRSRVConnect with a valid argument: OK Get number of devices from PVRSRVEnumerateDevices: OK .... Reported 1 devices .... Device Number | Device Type 0000 | PVRSRV_DEVICE_ID_SGX Attempt to acquire device 0: OK Getting SGX Client info OK .... ui32ProcessID:2691 Display Class API: enumerate devices OK PVRSRVEnumerateDeviceClass() returns 0 display device(s) FAIL - PVRSRV_ERROR_NO_DC_DEVICES_FOUND(134) ./gpu-demo: line 71: 2691 Aborted sgx_clipblit_test root@letux:~#
Where i could find that SGX_ClipBlit test (source or binary)?
As you can see the firmware is loaded and connected successfully. Then it just fails to enumerate a display which is the missing/unfixed omaplfb.
Some newer kernels did fail with
rt_sigaction(SIGRTMIN, {0xb6e07d9d, [], SA_RESTORER|SA_SIGINFO, 0xb6e91b01}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0xb6e07cbd, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0xb6e91b01}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 brk(0) = 0x12000 brk(0x33000) = 0x33000 open("/dev/pvrsrvkm", O_RDWR) = -1 ENOMEM (Cannot allocate memory) write(2, "pvrsrvctl: SrvInit failed (alrea"..., 57pvrsrvctl: SrvInit failed (already initialized?) (err=4) ) = 57 exit_group(1) = ? +++ exited with 1 +++
So I have to check what did break in between. And when. Most likely something with memory allocation.
For mainline You will probably need https://github.com/PabloPL/linux/commit/de0f7e299d94f5dfdcf15375ec2d3ace54ac... because powervr is using some strange pointers.
root@aries:~# uname -a Linux aries 5.0.0-rc4+ #246 PREEMPT Wed Feb 13 17:51:02 CET 2019 armv7l armv7l armv7l GNU/Linux root@aries:~# cat /proc/pvr/version Version CustomerGoogle_Android_ogles1_ogles2_GPL sgxddk 18 1.8.GOOGLENEXUS.ED945322@2112805 (debug) smdkc110_android System Version String: None root@aries:~# strace /system/bin/pvrsrvinit execve("/system/bin/pvrsrvinit", ["/system/bin/pvrsrvinit"], 0x7ecb26e0 /* 22 vars */) = 0 set_tls(0x76fc7584) = 0 set_tid_address(0x76fc753c) = 2931 mmap2(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76f5f000 madvise(0x76f5f000, 12288, MADV_MERGEABLE) = 0 mprotect(0x76f5f000, 4096, PROT_NONE) = 0 sigaltstack({ss_sp=0x76f60000, ss_flags=0, ss_size=8192}, NULL) = 0 prctl(PR_SET_VMA, 0, 0x76f60000, 0x2000, 0x76fb9c7d) = 0 prctl(PR_SET_VMA, 0, 0x76f5f000, 0x1000, 0x76fb9c91) = 0 mprotect(0x76fc1000, 8192, PROT_READ) = 0 mprotect(0x76fc6000, 4096, PROT_READ) = 0 mprotect(0x76fc6000, 4096, PROT_READ|PROT_WRITE) = 0 mprotect(0x76fc6000, 4096, PROT_READ) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76fc0000 madvise(0x76fc0000, 4096, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76fc0000, 0x1000, 0x76fb9bbb) = 0 mprotect(0x76fc0000, 4096, PROT_READ) = 0 mprotect(0x76fc0000, 4096, PROT_READ|PROT_WRITE) = 0 mprotect(0x76fc0000, 4096, PROT_READ) = 0 mprotect(0x76fc0000, 4096, PROT_READ|PROT_WRITE) = 0 mprotect(0x76fc0000, 4096, PROT_READ) = 0 mprotect(0x76fc0000, 4096, PROT_READ|PROT_WRITE) = 0 mprotect(0x76fc0000, 4096, PROT_READ) = 0 mprotect(0x76fc0000, 4096, PROT_READ|PROT_WRITE) = 0 mprotect(0x76fc0000, 4096, PROT_READ) = 0 mprotect(0x76fc0000, 4096, PROT_READ|PROT_WRITE) = 0 mprotect(0x76fc0000, 4096, PROT_READ) = 0 mprotect(0x76fc0000, 4096, PROT_READ|PROT_WRITE) = 0 mprotect(0x76fc0000, 4096, PROT_READ) = 0 mprotect(0x76fc0000, 4096, PROT_READ|PROT_WRITE) = 0 mprotect(0x76fc0000, 4096, PROT_READ) = 0 mprotect(0x76fc0000, 4096, PROT_READ|PROT_WRITE) = 0 mprotect(0x76fc0000, 4096, PROT_READ) = 0 openat(AT_FDCWD, "/dev/urandom", O_RDONLY|O_LARGEFILE|O_NOFOLLOW|O_CLOEXEC) = 3 fstat64(3, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0 ioctl(3, RNDGETENTCNT, 0x7ea723bc) = 0 read(3, "\357@~q\253\0344'/[#\214\31\231\277\340\320\20\243\1\1?\7\342-\210\207\224j2\310\231"..., 40) = 40 close(3) = 0 mmap2(NULL, 8, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76f5e000 madvise(0x76f5e000, 8, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f5e000, 0x8, 0x76fb9826) = 0 mmap2(NULL, 1088, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76f5d000 madvise(0x76f5d000, 1088, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f5d000, 0x440, 0x76fb983f) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f5c000 madvise(0x76f5c000, 4096, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f5c000, 0x1000, 0x76fb5ec9) = 0 mmap2(NULL, 12, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f5b000 madvise(0x76f5b000, 12, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f5b000, 0xc, 0x76fb5f6f) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f5a000 madvise(0x76f5a000, 4096, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f5a000, 0x1000, 0x76fb5ec9) = 0 mmap2(NULL, 12, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f59000 madvise(0x76f59000, 12, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f59000, 0xc, 0x76fb5f6f) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f58000 madvise(0x76f58000, 4096, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f58000, 0x1000, 0x76fb5f83) = 0 personality(0xffffffff) = 0x800000 (PER_LINUX|ADDR_LIMIT_32BIT) personality(PER_LINUX32|ADDR_LIMIT_32BIT) = 0x800000 (PER_LINUX|ADDR_LIMIT_32BIT) fstatat64(AT_FDCWD, "/dev/__properties__", 0x7ea71380, 0) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/dev/__properties__", O_RDONLY|O_LARGEFILE|O_NOFOLLOW|O_CLOEXEC) = -1 ENOENT (No such file or directory) sigaction(SIGABRT, {sa_handler=0x76f64805, sa_mask=[], sa_flags=SA_RESTORER|SA_ONSTACK|SA_RESTART|SA_SIGINFO, sa_restorer=0x76fa9c3c}, NULL) = 0 sigaction(SIGBUS, {sa_handler=0x76f64805, sa_mask=[], sa_flags=SA_RESTORER|SA_ONSTACK|SA_RESTART|SA_SIGINFO, sa_restorer=0x76fa9c3c}, NULL) = 0 sigaction(SIGFPE, {sa_handler=0x76f64805, sa_mask=[], sa_flags=SA_RESTORER|SA_ONSTACK|SA_RESTART|SA_SIGINFO, sa_restorer=0x76fa9c3c}, NULL) = 0 sigaction(SIGILL, {sa_handler=0x76f64805, sa_mask=[], sa_flags=SA_RESTORER|SA_ONSTACK|SA_RESTART|SA_SIGINFO, sa_restorer=0x76fa9c3c}, NULL) = 0 sigaction(SIGSEGV, {sa_handler=0x76f64805, sa_mask=[], sa_flags=SA_RESTORER|SA_ONSTACK|SA_RESTART|SA_SIGINFO, sa_restorer=0x76fa9c3c}, NULL) = 0 sigaction(SIGSTKFLT, {sa_handler=0x76f64805, sa_mask=[], sa_flags=SA_RESTORER|SA_ONSTACK|SA_RESTART|SA_SIGINFO, sa_restorer=0x76fa9c3c}, NULL) = 0 sigaction(SIGTRAP, {sa_handler=0x76f64805, sa_mask=[], sa_flags=SA_RESTORER|SA_ONSTACK|SA_RESTART|SA_SIGINFO, sa_restorer=0x76fa9c3c}, NULL) = 0 fstatat64(AT_FDCWD, "/proc/self/exe", {st_mode=S_IFREG|0755, st_size=13916, ...}, 0) = 0 mprotect(0x76fc0000, 4096, PROT_READ|PROT_WRITE) = 0 mprotect(0x76fc0000, 4096, PROT_READ) = 0 futex(0x76fc4778, FUTEX_WAKE_PRIVATE, 2147483647) = 0 readlinkat(AT_FDCWD, "/proc/self/exe", "/system/bin/pvrsrvinit", 4096) = 22 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f57000 madvise(0x76f57000, 4096, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f57000, 0x1000, 0x76fb5f83) = 0 fstatat64(AT_FDCWD, "/system", {st_mode=S_IFDIR|0755, st_size=4096, ...}, AT_SYMLINK_NOFOLLOW) = 0 fstatat64(AT_FDCWD, "/system/lib", {st_mode=S_IFDIR|0755, st_size=12288, ...}, AT_SYMLINK_NOFOLLOW) = 0 fstatat64(AT_FDCWD, "/vendor", 0x7ea6e368, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f56000 madvise(0x76f56000, 4096, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f56000, 0x1000, 0x76fb5f83) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f55000 madvise(0x76f55000, 4096, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f55000, 0x1000, 0x76fb5f83) = 0 openat(AT_FDCWD, "/system/lib/libc.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f53000 madvise(0x76f53000, 8192, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f53000, 0x2000, 0x76fb5ee4) = 0 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f51000 madvise(0x76f51000, 8192, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f51000, 0x2000, 0x76fb5ee4) = 0 readlinkat(AT_FDCWD, "/proc/self/fd/3", "/system/lib/libc.so", 4096) = 19 munmap(0x76f51000, 8192) = 0 munmap(0x76f53000, 8192) = 0 fstat64(3, {st_mode=S_IFREG|0644, st_size=761948, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f54000 madvise(0x76f54000, 4096, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f54000, 0x1000, 0x76fb5ec9) = 0 mmap2(NULL, 12, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f53000 madvise(0x76f53000, 12, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f53000, 0xc, 0x76fb5f6f) = 0 pread64(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\0\0\0\0004\0\0\0"..., 52, 0) = 52 mmap2(NULL, 424, PROT_READ, MAP_PRIVATE, 3, 0) = 0x76f52000 mmap2(NULL, 7016, PROT_READ, MAP_PRIVATE, 3, 0xb9000) = 0x76f50000 mmap2(NULL, 1920, PROT_READ, MAP_PRIVATE, 3, 0x83000) = 0x76f4f000 mmap2(NULL, 25140, PROT_READ, MAP_PRIVATE, 3, 0x5000) = 0x76f48000 openat(AT_FDCWD, "/system/lib/libcutils.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 4 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f46000 madvise(0x76f46000, 8192, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f46000, 0x2000, 0x76fb5ee4) = 0 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f44000 madvise(0x76f44000, 8192, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f44000, 0x2000, 0x76fb5ee4) = 0 readlinkat(AT_FDCWD, "/proc/self/fd/4", "/system/lib/libcutils.so", 4096) = 24 munmap(0x76f44000, 8192) = 0 munmap(0x76f46000, 8192) = 0 fstat64(4, {st_mode=S_IFREG|0644, st_size=100400, ...}) = 0 pread64(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\0\0\0\0004\0\0\0"..., 52, 0) = 52 mmap2(NULL, 424, PROT_READ, MAP_PRIVATE, 4, 0) = 0x76f47000 mmap2(NULL, 2992, PROT_READ, MAP_PRIVATE, 4, 0x18000) = 0x76f46000 mmap2(NULL, 5880, PROT_READ, MAP_PRIVATE, 4, 0x17000) = 0x76f44000 mmap2(NULL, 14500, PROT_READ, MAP_PRIVATE, 4, 0x1000) = 0x76f40000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f3f000 madvise(0x76f3f000, 4096, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f3f000, 0x1000, 0x76fb5ec9) = 0 mmap2(NULL, 12, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f3e000 madvise(0x76f3e000, 12, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f3e000, 0xc, 0x76fb5f6f) = 0 openat(AT_FDCWD, "/system/lib/libc++.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 5 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f3c000 madvise(0x76f3c000, 8192, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f3c000, 0x2000, 0x76fb5ee4) = 0 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f3a000 madvise(0x76f3a000, 8192, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f3a000, 0x2000, 0x76fb5ee4) = 0 readlinkat(AT_FDCWD, "/proc/self/fd/5", "/system/lib/libc++.so", 4096) = 21 munmap(0x76f3a000, 8192) = 0 munmap(0x76f3c000, 8192) = 0 fstat64(5, {st_mode=S_IFREG|0644, st_size=575132, ...}) = 0 pread64(5, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\0\0\0\0004\0\0\0"..., 52, 0) = 52 mmap2(NULL, 392, PROT_READ, MAP_PRIVATE, 5, 0) = 0x76f3d000 mmap2(NULL, 2224, PROT_READ, MAP_PRIVATE, 5, 0x8c000) = 0x76f3c000 mmap2(NULL, 6432, PROT_READ, MAP_PRIVATE, 5, 0x8a000) = 0x76f3a000 mmap2(NULL, 110556, PROT_READ, MAP_PRIVATE, 5, 0x9000) = 0x76f1f000 openat(AT_FDCWD, "/system/lib/libm.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 6 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f1d000 madvise(0x76f1d000, 8192, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f1d000, 0x2000, 0x76fb5ee4) = 0 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f1b000 madvise(0x76f1b000, 8192, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f1b000, 0x2000, 0x76fb5ee4) = 0 readlinkat(AT_FDCWD, "/proc/self/fd/6", "/system/lib/libm.so", 4096) = 19 munmap(0x76f1b000, 8192) = 0 munmap(0x76f1d000, 8192) = 0 fstat64(6, {st_mode=S_IFREG|0644, st_size=132884, ...}) = 0 pread64(6, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\0\0\0\0004\0\0\0"..., 52, 0) = 52 mmap2(NULL, 424, PROT_READ, MAP_PRIVATE, 6, 0) = 0x76f1e000 mmap2(NULL, 2424, PROT_READ, MAP_PRIVATE, 6, 0x20000) = 0x76f1d000 mmap2(NULL, 6600, PROT_READ, MAP_PRIVATE, 6, 0x1f000) = 0x76f1b000 mmap2(NULL, 8839, PROT_READ, MAP_PRIVATE, 6, 0x1000) = 0x76f18000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f17000 madvise(0x76f17000, 4096, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f17000, 0x1000, 0x76fb5ec9) = 0 mmap2(NULL, 12, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f16000 madvise(0x76f16000, 12, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f16000, 0xc, 0x76fb5f6f) = 0 openat(AT_FDCWD, "/system/lib/libsrv_init.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 7 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f14000 madvise(0x76f14000, 8192, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f14000, 0x2000, 0x76fb5ee4) = 0 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f12000 madvise(0x76f12000, 8192, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f12000, 0x2000, 0x76fb5ee4) = 0 readlinkat(AT_FDCWD, "/proc/self/fd/7", "/system/lib/libsrv_init.so", 4096) = 26 munmap(0x76f12000, 8192) = 0 munmap(0x76f14000, 8192) = 0 fstat64(7, {st_mode=S_IFREG|0644, st_size=106296, ...}) = 0 pread64(7, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\30\6\0\0004\0\0\0"..., 52, 0) = 52 mmap2(NULL, 232, PROT_READ, MAP_PRIVATE, 7, 0) = 0x76f15000 mmap2(NULL, 7232, PROT_READ, MAP_PRIVATE, 7, 0x19000) = 0x76f13000 mmap2(NULL, 5888, PROT_READ, MAP_PRIVATE, 7, 0x19000) = 0x76f11000 mmap2(NULL, 2074, PROT_READ, MAP_PRIVATE, 7, 0) = 0x76f10000 openat(AT_FDCWD, "/system/lib/libsrv_um.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 8 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f0e000 madvise(0x76f0e000, 8192, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f0e000, 0x2000, 0x76fb5ee4) = 0 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f0c000 madvise(0x76f0c000, 8192, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f0c000, 0x2000, 0x76fb5ee4) = 0 readlinkat(AT_FDCWD, "/proc/self/fd/8", "/system/lib/libsrv_um.so", 4096) = 24 munmap(0x76f0c000, 8192) = 0 munmap(0x76f0e000, 8192) = 0 fstat64(8, {st_mode=S_IFREG|0644, st_size=150024, ...}) = 0 pread64(8, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0T"\0\0004\0\0\0"..., 52, 0) = 52 mmap2(NULL, 232, PROT_READ, MAP_PRIVATE, 8, 0) = 0x76f0f000 mmap2(NULL, 4456, PROT_READ, MAP_PRIVATE, 8, 0x24000) = 0x76f0d000 mmap2(NULL, 2544, PROT_READ, MAP_PRIVATE, 8, 0x24000) = 0x76f0c000 mmap2(NULL, 2909, PROT_READ, MAP_PRIVATE, 8, 0x1000) = 0x76f0b000 openat(AT_FDCWD, "/system/lib/liblog.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 9 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f09000 madvise(0x76f09000, 8192, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f09000, 0x2000, 0x76fb5ee4) = 0 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f07000 madvise(0x76f07000, 8192, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f07000, 0x2000, 0x76fb5ee4) = 0 readlinkat(AT_FDCWD, "/proc/self/fd/9", "/system/lib/liblog.so", 4096) = 21 munmap(0x76f07000, 8192) = 0 munmap(0x76f09000, 8192) = 0 fstat64(9, {st_mode=S_IFREG|0644, st_size=63428, ...}) = 0 pread64(9, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\0\0\0\0004\0\0\0"..., 52, 0) = 52 mmap2(NULL, 392, PROT_READ, MAP_PRIVATE, 9, 0) = 0x76f0a000 mmap2(NULL, 2816, PROT_READ, MAP_PRIVATE, 9, 0xf000) = 0x76f09000 mmap2(NULL, 6504, PROT_READ, MAP_PRIVATE, 9, 0xe000) = 0x76f07000 mmap2(NULL, 6667, PROT_READ, MAP_PRIVATE, 9, 0x1000) = 0x76f05000 openat(AT_FDCWD, "/system/lib/libsrv_um.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 10 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f03000 madvise(0x76f03000, 8192, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f03000, 0x2000, 0x76fb5ee4) = 0 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f01000 madvise(0x76f01000, 8192, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f01000, 0x2000, 0x76fb5ee4) = 0 readlinkat(AT_FDCWD, "/proc/self/fd/10", "/system/lib/libsrv_um.so", 4096) = 24 munmap(0x76f01000, 8192) = 0 munmap(0x76f03000, 8192) = 0 fstat64(10, {st_mode=S_IFREG|0644, st_size=150024, ...}) = 0 openat(AT_FDCWD, "/system/lib/libhardware.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 11 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f03000 madvise(0x76f03000, 8192, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f03000, 0x2000, 0x76fb5ee4) = 0 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f01000 madvise(0x76f01000, 8192, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f01000, 0x2000, 0x76fb5ee4) = 0 readlinkat(AT_FDCWD, "/proc/self/fd/11", "/system/lib/libhardware.so", 4096) = 26 munmap(0x76f01000, 8192) = 0 munmap(0x76f03000, 8192) = 0 fstat64(11, {st_mode=S_IFREG|0644, st_size=13912, ...}) = 0 pread64(11, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\0\0\0\0004\0\0\0"..., 52, 0) = 52 mmap2(NULL, 392, PROT_READ, MAP_PRIVATE, 11, 0) = 0x76f04000 mmap2(NULL, 2128, PROT_READ, MAP_PRIVATE, 11, 0x3000) = 0x76f03000 mmap2(NULL, 7680, PROT_READ, MAP_PRIVATE, 11, 0x2000) = 0x76f01000 mmap2(NULL, 2144, PROT_READ, MAP_PRIVATE, 11, 0) = 0x76f00000 munmap(0x76f17000, 4096) = 0 mmap2(NULL, 139264, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76ede000 madvise(0x76ede000, 139264, MADV_MERGEABLE) = 0 mmap2(0x76ede000, 105251, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 7, 0) = 0x76ede000 mmap2(0x76eff000, 3104, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 7, 0x19000) = 0x76eff000 mmap2(NULL, 184320, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76eb1000 madvise(0x76eb1000, 184320, MADV_MERGEABLE) = 0 mmap2(0x76eb1000, 144748, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 8, 0) = 0x76eb1000 mmap2(0x76edc000, 5724, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 8, 0x23000) = 0x76edc000 mmap2(NULL, 585728, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76e22000 madvise(0x76e22000, 585728, MADV_MERGEABLE) = 0 mmap2(0x76e22000, 525924, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x76e22000 mmap2(0x76ea3000, 22952, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x80000) = 0x76ea3000 mmap2(0x76ea9000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x76ea9000 madvise(0x76ea9000, 32768, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76ea9000, 0x8000, 0x76fb677c) = 0 mmap2(NULL, 585728, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76d93000 madvise(0x76d93000, 585728, MADV_MERGEABLE) = 0 mmap2(0x76d93000, 557344, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 5, 0) = 0x76d93000 mmap2(0x76e1c000, 16409, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 5, 0x88000) = 0x76e1c000 mmap2(0x76e21000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x76e21000 madvise(0x76e21000, 4096, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76e21000, 0x1000, 0x76fb677c) = 0 mmap2(NULL, 20480, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76d8e000 madvise(0x76d8e000, 20480, MADV_MERGEABLE) = 0 mmap2(0x76d8e000, 11144, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 11, 0) = 0x76d8e000 mmap2(0x76d91000, 4100, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 11, 0x2000) = 0x76d91000 mmap2(NULL, 106496, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76d74000 madvise(0x76d74000, 106496, MADV_MERGEABLE) = 0 mmap2(0x76d74000, 90272, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0) = 0x76d74000 mmap2(0x76d8b000, 8564, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x16000) = 0x76d8b000 mmap2(NULL, 139264, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76d52000 madvise(0x76d52000, 139264, MADV_MERGEABLE) = 0 mmap2(0x76d52000, 127684, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 6, 0) = 0x76d52000 mmap2(0x76d72000, 4204, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 6, 0x1f000) = 0x76d72000 mmap2(NULL, 69632, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76d41000 madvise(0x76d41000, 69632, MADV_MERGEABLE) = 0 mmap2(0x76d41000, 56276, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 9, 0) = 0x76d41000 mmap2(0x76d50000, 4428, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 9, 0xe000) = 0x76d50000 socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 12 fcntl64(12, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 connect(12, {sa_family=AF_UNIX, sun_path="/dev/socket/logdw"}, 110) = -1 ENOENT (No such file or directory) close(12) = 0 openat(AT_FDCWD, "/dev/stderr", O_WRONLY|O_APPEND|O_LARGEFILE|O_CLOEXEC) = 12 writev(12, [{iov_base="linker", iov_len=6}, {iov_base=": ", iov_len=2}, {iov_base="/system/lib/libsrv_init.so: unus"..., iov_len=63}, {iov_base="\n", iov_len=1}], 4linker: /system/lib/libsrv_init.so: unused DT entry: type 0xf arg 0x1ae ) = 72 close(12) = 0 write(2, "WARNING: linker: ", 17WARNING: linker: ) = 17 write(2, "/system/lib/libsrv_init.so", 26/system/lib/libsrv_init.so) = 26 write(2, ": unused DT entry: type ", 24: unused DT entry: type ) = 24 write(2, "0xf", 30xf) = 3 write(2, " arg ", 5 arg ) = 5 write(2, "0x1ae", 50x1ae) = 5 write(2, "\n", 1 ) = 1 socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 12 fcntl64(12, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 connect(12, {sa_family=AF_UNIX, sun_path="/dev/socket/logdw"}, 110) = -1 ENOENT (No such file or directory) close(12) = 0 openat(AT_FDCWD, "/dev/stderr", O_WRONLY|O_APPEND|O_LARGEFILE|O_CLOEXEC) = 12 writev(12, [{iov_base="linker", iov_len=6}, {iov_base=": ", iov_len=2}, {iov_base="/system/lib/libsrv_um.so: unused"..., iov_len=61}, {iov_base="\n", iov_len=1}], 4linker: /system/lib/libsrv_um.so: unused DT entry: type 0xf arg 0xb31 ) = 70 close(12) = 0 write(2, "WARNING: linker: ", 17WARNING: linker: ) = 17 write(2, "/system/lib/libsrv_um.so", 24/system/lib/libsrv_um.so) = 24 write(2, ": unused DT entry: type ", 24: unused DT entry: type ) = 24 write(2, "0xf", 30xf) = 3 write(2, " arg ", 5 arg ) = 5 write(2, "0xb31", 50xb31) = 5 write(2, "\n", 1 ) = 1 socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 12 fcntl64(12, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 connect(12, {sa_family=AF_UNIX, sun_path="/dev/socket/logdw"}, 110) = -1 ENOENT (No such file or directory) close(12) = 0 openat(AT_FDCWD, "/dev/stderr", O_WRONLY|O_APPEND|O_LARGEFILE|O_CLOEXEC) = 12 writev(12, [{iov_base="linker", iov_len=6}, {iov_base=": ", iov_len=2}, {iov_base="/system/lib/libsrv_um.so: unused"..., iov_len=61}, {iov_base="\n", iov_len=1}], 4linker: /system/lib/libsrv_um.so: unused DT entry: type 0xf arg 0xb31 ) = 70 close(12) = 0 write(2, "WARNING: linker: ", 17WARNING: linker: ) = 17 write(2, "/system/lib/libsrv_um.so", 24/system/lib/libsrv_um.so) = 24 write(2, ": unused DT entry: type ", 24: unused DT entry: type ) = 24 write(2, "0xf", 30xf) = 3 write(2, " arg ", 5 arg ) = 5 write(2, "0xb31", 50xb31) = 5 write(2, "\n", 1 ) = 1 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f17000 madvise(0x76f17000, 4096, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f17000, 0x1000, 0x76fb5ec9) = 0 mprotect(0x4c7000, 4096, PROT_READ) = 0 munmap(0x76f17000, 4096) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f17000 madvise(0x76f17000, 4096, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f17000, 0x1000, 0x76fb5ec9) = 0 munmap(0x76f17000, 4096) = 0 mprotect(0x76ea3000, 16384, PROT_READ) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f17000 madvise(0x76f17000, 4096, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f17000, 0x1000, 0x76fb5ec9) = 0 mprotect(0x76d8b000, 8192, PROT_READ) = 0 munmap(0x76f17000, 4096) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f17000 madvise(0x76f17000, 4096, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f17000, 0x1000, 0x76fb5ec9) = 0 mprotect(0x76e1c000, 16384, PROT_READ) = 0 munmap(0x76f17000, 4096) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f17000 madvise(0x76f17000, 4096, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f17000, 0x1000, 0x76fb5ec9) = 0 mprotect(0x76d72000, 4096, PROT_READ) = 0 munmap(0x76f17000, 4096) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f17000 madvise(0x76f17000, 4096, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f17000, 0x1000, 0x76fb5ec9) = 0 mprotect(0x76d50000, 4096, PROT_READ) = 0 munmap(0x76f17000, 4096) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f17000 madvise(0x76f17000, 4096, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f17000, 0x1000, 0x76fb5ec9) = 0 mprotect(0x76d91000, 4096, PROT_READ) = 0 munmap(0x76f17000, 4096) = 0 close(3) = 0 close(4) = 0 close(5) = 0 close(6) = 0 close(7) = 0 close(8) = 0 close(9) = 0 close(10) = 0 close(11) = 0 munmap(0x76f05000, 6667) = 0 munmap(0x76f07000, 6504) = 0 munmap(0x76f09000, 2816) = 0 munmap(0x76f0a000, 392) = 0 munmap(0x76f00000, 2144) = 0 munmap(0x76f01000, 7680) = 0 munmap(0x76f03000, 2128) = 0 munmap(0x76f04000, 392) = 0 munmap(0x76f0b000, 2909) = 0 munmap(0x76f0c000, 2544) = 0 munmap(0x76f0d000, 4456) = 0 munmap(0x76f0f000, 232) = 0 munmap(0x76f18000, 8839) = 0 munmap(0x76f1b000, 6600) = 0 munmap(0x76f1d000, 2424) = 0 munmap(0x76f1e000, 424) = 0 munmap(0x76f1f000, 110556) = 0 munmap(0x76f3a000, 6432) = 0 munmap(0x76f3c000, 2224) = 0 munmap(0x76f3d000, 392) = 0 munmap(0x76f40000, 14500) = 0 munmap(0x76f44000, 5880) = 0 munmap(0x76f46000, 2992) = 0 munmap(0x76f47000, 424) = 0 munmap(0x76f10000, 2074) = 0 munmap(0x76f11000, 5888) = 0 munmap(0x76f13000, 7232) = 0 munmap(0x76f15000, 232) = 0 munmap(0x76f48000, 25140) = 0 munmap(0x76f4f000, 1920) = 0 munmap(0x76f50000, 7016) = 0 munmap(0x76f52000, 424) = 0 munmap(0x76f54000, 4096) = 0 mprotect(0x76f57000, 4096, PROT_READ|PROT_WRITE) = 0 mprotect(0x76f58000, 4096, PROT_READ|PROT_WRITE) = 0 mprotect(0x76eaa000, 4096, PROT_READ) = 0 mprotect(0x76eaa000, 4096, PROT_READ|PROT_WRITE) = 0 mprotect(0x76eaa000, 4096, PROT_READ) = 0 fstatat64(AT_FDCWD, "/dev/__properties__", 0x7ea712d8, 0) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/dev/__properties__", O_RDONLY|O_LARGEFILE|O_NOFOLLOW|O_CLOEXEC) = -1 ENOENT (No such file or directory) mprotect(0x76eaa000, 4096, PROT_READ|PROT_WRITE) = 0 mprotect(0x76eaa000, 4096, PROT_READ) = 0 openat(AT_FDCWD, "/system/lib/libnetd_client.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f51000 madvise(0x76f51000, 8192, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f51000, 0x2000, 0x76fb5ee4) = 0 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f4f000 madvise(0x76f4f000, 8192, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f4f000, 0x2000, 0x76fb5ee4) = 0 readlinkat(AT_FDCWD, "/proc/self/fd/3", "/system/lib/libnetd_client.so", 4096) = 29 munmap(0x76f4f000, 8192) = 0 munmap(0x76f51000, 8192) = 0 fstat64(3, {st_mode=S_IFREG|0644, st_size=18012, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f54000 madvise(0x76f54000, 4096, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f54000, 0x1000, 0x76fb5f83) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f52000 madvise(0x76f52000, 4096, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f52000, 0x1000, 0x76fb5ec9) = 0 pread64(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\0\0\0\0004\0\0\0"..., 52, 0) = 52 mmap2(NULL, 392, PROT_READ, MAP_PRIVATE, 3, 0) = 0x76f51000 mmap2(NULL, 2136, PROT_READ, MAP_PRIVATE, 3, 0x4000) = 0x76f50000 mmap2(NULL, 7624, PROT_READ, MAP_PRIVATE, 3, 0x3000) = 0x76f4e000 mmap2(NULL, 3829, PROT_READ, MAP_PRIVATE, 3, 0) = 0x76f4d000 mmap2(NULL, 24576, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76f47000 madvise(0x76f47000, 24576, MADV_MERGEABLE) = 0 mmap2(0x76f47000, 14616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x76f47000 mmap2(0x76f4b000, 4100, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x3000) = 0x76f4b000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x76f46000 madvise(0x76f46000, 4096, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f46000, 0x1000, 0x76fb5ec9) = 0 mprotect(0x76f4b000, 4096, PROT_READ) = 0 munmap(0x76f46000, 4096) = 0 close(3) = 0 munmap(0x76f4d000, 3829) = 0 munmap(0x76f4e000, 7624) = 0 munmap(0x76f50000, 2136) = 0 munmap(0x76f51000, 392) = 0 munmap(0x76f52000, 4096) = 0 futex(0x76e21a48, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x76e21a48, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x76e21a48, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x76e21a48, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x76e21a48, FUTEX_WAKE_PRIVATE, 2147483647) = 0 brk(NULL) = 0x4c9000 mmap2(NULL, 524288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76cc1000 madvise(0x76cc1000, 524288, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76cc1000, 0x80000, 0x76e9a71a) = 0 munmap(0x76cc1000, 524288) = 0 mmap2(NULL, 1044480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76c42000 madvise(0x76c42000, 1044480, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76c42000, 0xff000, 0x76e9a71a) = 0 munmap(0x76c42000, 253952) = 0 munmap(0x76d00000, 266240) = 0 clock_gettime(CLOCK_MONOTONIC, {tv_sec=165, tv_nsec=410878102}) = 0 openat(AT_FDCWD, "/sys/devices/system/cpu/online", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 mmap2(NULL, 524288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76c00000 madvise(0x76c00000, 524288, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76c00000, 0x80000, 0x76e9a71a) = 0 fstat64(3, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0 read(3, "0\n", 4096) = 2 clock_gettime(CLOCK_MONOTONIC, {tv_sec=165, tv_nsec=414485599}) = 0 close(3) = 0 clock_gettime(CLOCK_MONOTONIC, {tv_sec=165, tv_nsec=415226182}) = 0 futex(0x76e20234, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x76e21a48, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x76e21a48, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x76e21a48, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x76e21a48, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x76e21a48, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x76e21a48, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x76e21a48, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x76e21a48, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x76e21a48, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x76e21a48, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x76e21a48, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x76e21a48, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x76e21a48, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x76e21a48, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x76e21a48, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x76e21a48, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x76e21a48, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x76e21a48, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x76e21a48, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x76e21a48, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x76e21a48, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x76e21a48, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x76e21a48, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x76e20234, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x76e20234, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x76eab078, FUTEX_WAKE_PRIVATE, 2147483647) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76f52000 madvise(0x76f52000, 4096, MADV_MERGEABLE) = 0 prctl(PR_SET_VMA, 0, 0x76f52000, 0x1000, 0x76e9a0c9) = 0 mprotect(0x76f52000, 4096, PROT_READ) = 0 futex(0x76ea9018, FUTEX_WAKE_PRIVATE, 2147483647) = 0 mprotect(0x76f54000, 4096, PROT_READ) = 0 mprotect(0x76f57000, 4096, PROT_READ) = 0 mprotect(0x76f58000, 4096, PROT_READ) = 0 mprotect(0x76f52000, 4096, PROT_READ|PROT_WRITE) = 0 mprotect(0x76f52000, 4096, PROT_READ) = 0 openat(AT_FDCWD, "/dev/pvrsrvkm", O_RDWR|O_LARGEFILE) = 3 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0xc, 0x1c), 0x7ea724b4) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x44, 0x1c), 0x7ea724f4) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0, 0x1c), 0x7ea7239c) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x1, 0x1c), 0x7ea7242c) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x63, 0x1c), 0x7ea72134) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x6, 0x1c), 0x7ea7233c) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0xb, 0x1c), 0x7ea722fc) = 0 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000005000) = 0x76f50000 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x6, 0x1c), 0x7ea7233c) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0xb, 0x1c), 0x7ea722fc) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000006000) = 0x76f4f000 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x6, 0x1c), 0x7ea7233c) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0xb, 0x1c), 0x7ea722fc) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000007000) = 0x76f4e000 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x6, 0x1c), 0x7ea7233c) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0xb, 0x1c), 0x7ea722fc) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000008000) = 0x76f4d000 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x6, 0x1c), 0x7ea7233c) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0xb, 0x1c), 0x7ea722fc) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000009000) = 0x76f46000 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x6, 0x1c), 0x7ea7233c) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0xb, 0x1c), 0x7ea722fc) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x8000000a000) = 0x76f45000 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x6, 0x1c), 0x7ea72324) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0xb, 0x1c), 0x7ea722e4) = 0 mmap2(NULL, 12288, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x8000000b000) = 0x76f42000 openat(AT_FDCWD, "/etc/powervr.ini", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "powervr.ini", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x6, 0x1c), 0x7ea72324) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0xb, 0x1c), 0x7ea722e4) = 0 mmap2(NULL, 28672, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x8000000c000) = 0x76f37000 openat(AT_FDCWD, "/etc/powervr.ini", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "powervr.ini", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x6, 0x1c), 0x7ea72324) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0xb, 0x1c), 0x7ea722e4) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x8000000d000) = 0x76f41000 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x6, 0x1c), 0x7ea72324) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0xb, 0x1c), 0x7ea722e4) = 0 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x8000000e000) = 0x76f35000 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x6, 0x1c), 0x7ea72314) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0xb, 0x1c), 0x7ea722d4) = 0 mmap2(NULL, 28672, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x8000000f000) = 0x76f2e000 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x6, 0x1c), 0x7ea72314) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0xb, 0x1c), 0x7ea722d4) = 0 mmap2(NULL, 24576, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000010000) = 0x76f28000 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x6, 0x1c), 0x7ea72314) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0xb, 0x1c), 0x7ea722d4) = 0 mmap2(NULL, 24576, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000011000) = 0x76f22000 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x6, 0x1c), 0x7ea72314) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0xb, 0x1c), 0x7ea722d4) = 0 mmap2(NULL, 32768, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000012000) = 0x76f1a000 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x6, 0x1c), 0x7ea7233c) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0xb, 0x1c), 0x7ea722fc) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000013000) = 0x76f40000 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x6, 0x1c), 0x7ea7233c) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0xb, 0x1c), 0x7ea722fc) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000014000) = 0x76f19000 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x6, 0x1c), 0x7ea7233c) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0xb, 0x1c), 0x7ea722fc) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000015000) = 0x76f18000 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x6, 0x1c), 0x7ea7233c) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0xb, 0x1c), 0x7ea722fc) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000016000) = 0x76f17000 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x6, 0x1c), 0x7ea7233c) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0xb, 0x1c), 0x7ea722fc) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x80000017000) = 0x76f15000 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x1b, 0x1c), 0x7ea72404) = 0 munmap(0x76f50000, 8192) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x1b, 0x1c), 0x7ea72404) = 0 munmap(0x76f4f000, 4096) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x1b, 0x1c), 0x7ea72404) = 0 munmap(0x76f4e000, 4096) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x1b, 0x1c), 0x7ea72404) = 0 munmap(0x76f46000, 4096) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x1b, 0x1c), 0x7ea72404) = 0 munmap(0x76f4d000, 4096) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x1b, 0x1c), 0x7ea72404) = 0 munmap(0x76f45000, 4096) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x1b, 0x1c), 0x7ea72404) = 0 munmap(0x76f37000, 28672) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x1b, 0x1c), 0x7ea72404) = 0 munmap(0x76f41000, 4096) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x1b, 0x1c), 0x7ea72404) = 0 munmap(0x76f35000, 8192) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x1b, 0x1c), 0x7ea72404) = 0 munmap(0x76f42000, 12288) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x1b, 0x1c), 0x7ea72404) = 0 munmap(0x76f2e000, 28672) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x1b, 0x1c), 0x7ea72404) = 0 munmap(0x76f28000, 24576) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x1b, 0x1c), 0x7ea72404) = 0 munmap(0x76f1a000, 32768) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x1b, 0x1c), 0x7ea72404) = 0 munmap(0x76f22000, 24576) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x1b, 0x1c), 0x7ea72404) = 0 munmap(0x76f40000, 4096) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x1b, 0x1c), 0x7ea72404) = 0 munmap(0x76f19000, 4096) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x1b, 0x1c), 0x7ea72404) = 0 munmap(0x76f18000, 4096) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x1b, 0x1c), 0x7ea72404) = 0 munmap(0x76f17000, 4096) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x1b, 0x1c), 0x7ea72404) = 0 munmap(0x76f15000, 4096) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x64, 0x1c), 0x7ea7243c) = 0 clock_gettime(CLOCK_MONOTONIC, {tv_sec=166, tv_nsec=844604195}) = 0 clock_gettime(CLOCK_MONOTONIC, {tv_sec=166, tv_nsec=845206447}) = 0 clock_gettime(CLOCK_MONOTONIC, {tv_sec=166, tv_nsec=845971827}) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0x45, 0x1c), 0x7ea724e4) = 0 ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0x67, 0xd, 0x1c), 0x7ea724bc) = 0 close(3) = 0 clock_gettime(CLOCK_MONOTONIC, {tv_sec=166, tv_nsec=931130832}) = 0 mprotect(0x76f52000, 4096, PROT_READ|PROT_WRITE) = 0 mprotect(0x76f52000, 4096, PROT_READ) = 0 mprotect(0x76f52000, 4096, PROT_READ|PROT_WRITE) = 0 mprotect(0x76f52000, 4096, PROT_READ) = 0 munmap(0x76f52000, 4096) = 0 exit_group(0) = ?
I'm building my kernel and will get strace output of pvrsrvinit on my device (where it's working) in few minutes. For me it fails when trying to use egl programs (egl configurations = 0). Of course on mainline (5.0-rc4).
Hope this helps!
BR, Nikolaus
Log is a bit "strange" because i'm running android binaries (pvrsrvinit etc) under linux (ubuntu 18.04, booted from uboot), so there are references to android libs/properties/etc
Hi Pawel,
Am 13.02.2019 um 17:59 schrieb Paweł Chmiel pawel.mikolaj.chmiel@gmail.com:
Where i could find that SGX_ClipBlit test (source or binary)?
it is binary only and was part of the TI GFX-SDK for the omap3
http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/la...
I have repacked the files into so that our OS can easily install the correct ones
http://download.goldelico.com/letux-debian-rootfs/debian/dists/jessie/main/b...
There is also an sgx530-121 for omap3430. But usually the libs are tied closely to the release version number of the firmware so that they probably don't work with other DDK versions.
In the meantime I have tested my kernel versions a little and v4.15 strace works as expected. v4.16 ends in an EFAULT within some ioctl() and v4.19 and up to v5.0-rc in some ENOMEM. Looks as if I have lost/missed some fixes because i did only focus on compile conflicts...
BR, Nikolaus
On Wed, Feb 13, 2019 at 2:46 PM H. Nikolaus Schaller hns@goldelico.com wrote:
Hi Pawel,
Am 13.02.2019 um 17:59 schrieb Paweł Chmiel pawel.mikolaj.chmiel@gmail.com:
Where i could find that SGX_ClipBlit test (source or binary)?
it is binary only and was part of the TI GFX-SDK for the omap3
http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/la...
I have repacked the files into so that our OS can easily install the correct ones
http://download.goldelico.com/letux-debian-rootfs/debian/dists/jessie/main/b...
There is also an sgx530-121 for omap3430. But usually the libs are tied closely to the release version number of the firmware so that they probably don't work with other DDK versions.
In the meantime I have tested my kernel versions a little and v4.15 strace works as expected. v4.16 ends in an EFAULT within some ioctl() and v4.19 and up to v5.0-rc in some ENOMEM. Looks as if I have lost/missed some fixes because i did only focus on compile conflicts...
I am really glad to see this get some momentum. I'm lobbying to get my company to put some resources behind this as well, and some acceleration is better than none. I'll try to help where/how I can. Please keep me in copy and I'll sign up for the mailing list if/when that option is available.
adam
BR, Nikolaus
śr., 13 lut 2019 o 21:46 H. Nikolaus Schaller hns@goldelico.com napisał(a):
Hi Pawel,
Am 13.02.2019 um 17:59 schrieb Paweł Chmiel pawel.mikolaj.chmiel@gmail.com:
Where i could find that SGX_ClipBlit test (source or binary)?
it is binary only and was part of the TI GFX-SDK for the omap3
http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/la...
I have repacked the files into so that our OS can easily install the correct ones
http://download.goldelico.com/letux-debian-rootfs/debian/dists/jessie/main/b...
There is also an sgx530-121 for omap3430. But usually the libs are tied closely to the release version number of the firmware so that they probably don't work with other DDK versions.
In the meantime I have tested my kernel versions a little and v4.15 strace works as expected. v4.16 ends in an EFAULT within some ioctl() and v4.19 and up to v5.0-rc in some ENOMEM. Looks as if I have lost/missed some fixes because i did only focus on compile conflicts...
On 4.15 You have only pvrsrvinit working fine or also able to run some sample opengl code?
BR, Nikolaus
Am 13.02.2019 um 21:51 schrieb Paweł Chmiel pawel.mikolaj.chmiel@gmail.com:
śr., 13 lut 2019 o 21:46 H. Nikolaus Schaller hns@goldelico.com napisał(a):
Hi Pawel,
Am 13.02.2019 um 17:59 schrieb Paweł Chmiel pawel.mikolaj.chmiel@gmail.com:
Where i could find that SGX_ClipBlit test (source or binary)?
it is binary only and was part of the TI GFX-SDK for the omap3
http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/la...
I have repacked the files into so that our OS can easily install the correct ones
http://download.goldelico.com/letux-debian-rootfs/debian/dists/jessie/main/b...
There is also an sgx530-121 for omap3430. But usually the libs are tied closely to the release version number of the firmware so that they probably don't work with other DDK versions.
In the meantime I have tested my kernel versions a little and v4.15 strace works as expected. v4.16 ends in an EFAULT within some ioctl() and v4.19 and up to v5.0-rc in some ENOMEM. Looks as if I have lost/missed some fixes because i did only focus on compile conflicts...
On 4.15 You have only pvrsrvinit working fine or also able to run some sample opengl code?
No it refuses to start because it does not find the framebuffer. But we had that working on some 3.12 if I remember correctly. AFAIR there is a video on youtube...
Hi Pawel,
Am 13.02.2019 um 17:45 schrieb Paweł Chmiel pawel.mikolaj.chmiel@gmail.com:
So I have to check what did break in between. And when. Most likely something with memory allocation.
For mainline You will probably need https://github.com/PabloPL/linux/commit/de0f7e299d94f5dfdcf15375ec2d3ace54ac... because powervr is using some strange pointers.
Yes, thats it!
I found a backported version of be83bbf ("mmap: introduce sane default mmap limits") appear in v4.16.14 -> v4.16.15 as the only patch that did modify mm/mmap.c
Either reverting that or applying your recommended one fixes the issue for all kernels starting with 4.16.15 or 4.17-rc5 up to 5.0-rc6.
IMHO this is the first example where this collaboration of our group is already very helpful because we start to exchange knowledge about common problems.
For this patch, the key question is what a better solution will be. Most likely reworking the "pgoff << PAGE_SHIFT" stuff from which I remember that it is used quite a lot. But that should be done once for all and everybody on our future master branch.
So I now have back an (almost) working reference system on v5.0-rc6 for GTA04, BeagleBoard, BeagleBone, PocketBeagle and potentially OpenPanodra (which uses the omap3430/sgx121 variant).
At least I can download and start firmware. I just have to find a way to fix the omaplfb so that it works with our omapdrm based panels to runs the CLipBlit test [1] on modern kernels...
BR and thanks, Nikolaus
Hi,
On 15/02/2019 13:43, H. Nikolaus Schaller wrote:
IMHO this is the first example where this collaboration of our group is already very helpful because we start to exchange knowledge about common problems.
Yay!
For this patch, the key question is what a better solution will be. Most likely reworking the "pgoff << PAGE_SHIFT" stuff from which I remember that it is used quite a lot. But that should be done once for all and everybody on our future master branch.
So I now have back an (almost) working reference system on v5.0-rc6 for GTA04, BeagleBoard, BeagleBone, PocketBeagle and potentially OpenPanodra (which uses the omap3430/sgx121 variant).
And the OpenPandora is similar to the Nokia N900 (sgx121). If you have the userspace sgx driver that still supports X, you might be able to get accelerated 3D on X if you use the maemo leste ddx and userspace driver.
https://github.com/maemo-leste/n9xx-ti-omap3-sgx https://github.com/maemo-leste/n9xx-xf86-video-fbdev-sgx
(armhf known to work on n900, armel not)
I don't know how well older userspace works with the latest kernel interface, though.
At least I can download and start firmware. I just have to find a way to fix the omaplfb so that it works with our omapdrm based panels to runs the CLipBlit test [1] on modern kernels...
Maybe you can compare with what we have here: https://github.com/maemo-leste/n9xx-linux/tree/pvr-wip-4.15.7/drivers/gpu/pv...
Cheers, Merlijn
pt., 15 lut 2019 o 13:50 Merlijn Wajer merlijn@wizzup.org napisał(a):
Hi,
On 15/02/2019 13:43, H. Nikolaus Schaller wrote:
IMHO this is the first example where this collaboration of our group is already very helpful because we start to exchange knowledge about common problems.
Yay!
For this patch, the key question is what a better solution will be. Most likely reworking the "pgoff << PAGE_SHIFT" stuff from which I remember that it is used quite a lot. But that should be done once for all and everybody on our future master branch.
I hope that userspace is not checking those pointers also (like it's done for build flags). For now i leaved it as is and focused on getting it running. Then with something working i wanted to make changes/refactor/etc.
So I now have back an (almost) working reference system on v5.0-rc6 for GTA04, BeagleBoard, BeagleBone, PocketBeagle and potentially OpenPanodra (which uses the omap3430/sgx121 variant).
And the OpenPandora is similar to the Nokia N900 (sgx121). If you have the userspace sgx driver that still supports X, you might be able to get accelerated 3D on X if you use the maemo leste ddx and userspace driver.
https://github.com/maemo-leste/n9xx-ti-omap3-sgx https://github.com/maemo-leste/n9xx-xf86-video-fbdev-sgx
(armhf known to work on n900, armel not)
I don't know how well older userspace works with the latest kernel interface, though.
At least I can download and start firmware. I just have to find a way to fix the omaplfb so that it works with our omapdrm based panels to runs the CLipBlit test [1] on modern kernels...
So now You're in the same place as i'm currently. I'm able to download and start firmware, etc, but when tryint to use some egl code (note i'm using android binaries) there are problems (no errors, but like i wrote, 0 available egl configurations). Need to check framebuffer setup (on mainline i'm using drm driver for display, maybe there are differences between it and plain fb driver).
Maybe you can compare with what we have here: https://github.com/maemo-leste/n9xx-linux/tree/pvr-wip-4.15.7/drivers/gpu/pv...
Cheers, Merlijn
Hi,
Am 15.02.2019 um 13:52 schrieb Merlijn Wajer merlijn@wizzup.org:
Hi,
On 15/02/2019 13:43, H. Nikolaus Schaller wrote:
IMHO this is the first example where this collaboration of our group is already very helpful because we start to exchange knowledge about common problems.
Yay!
For this patch, the key question is what a better solution will be. Most likely reworking the "pgoff << PAGE_SHIFT" stuff from which I remember that it is used quite a lot. But that should be done once for all and everybody on our future master branch.
So I now have back an (almost) working reference system on v5.0-rc6 for GTA04, BeagleBoard, BeagleBone, PocketBeagle and potentially OpenPanodra (which uses the omap3430/sgx121 variant).
And the OpenPandora is similar to the Nokia N900 (sgx121). If you have the userspace sgx driver that still supports X, you might be able to get accelerated 3D on X if you use the maemo leste ddx and userspace driver.
https://github.com/maemo-leste/n9xx-ti-omap3-sgx https://github.com/maemo-leste/n9xx-xf86-video-fbdev-sgx
(armhf known to work on n900, armel not)
I don't know how well older userspace works with the latest kernel interface, though.
Yes, there are subtle dependencies.
At least I can download and start firmware. I just have to find a way to fix the omaplfb so that it works with our omapdrm based panels to runs the CLipBlit test [1] on modern kernels...
Maybe you can compare with what we have here: https://github.com/maemo-leste/n9xx-linux/tree/pvr-wip-4.15.7/drivers/gpu/pv...
I'll take a look into it especially how omaplfb is done.
First observation is that there is a "flat" tree while I am working on a structured one... But that is just a marginal difference (mainly significant for Makefile writers).
BR and thanks, Nikolaus
Hi,
On 15/02/2019 14:09, H. Nikolaus Schaller wrote:
At least I can download and start firmware. I just have to find a way to fix the omaplfb so that it works with our omapdrm based panels to runs the CLipBlit test [1] on modern kernels...
Maybe you can compare with what we have here: https://github.com/maemo-leste/n9xx-linux/tree/pvr-wip-4.15.7/drivers/gpu/pv...
I'll take a look into it especially how omaplfb is done.
First observation is that there is a "flat" tree while I am working on a structured one... But that is just a marginal difference (mainly significant for Makefile writers).
I've ported the Maemo Leste kernel + pvr to 5.0 and it seems to work: https://github.com/maemo-leste/n9xx-linux/commits/pvr-wip-5.0.y
Should I add this as maemo-leste-n900-5.0 branch (or something) to https://github.com/openpvrsgx-devgroup/linux_openpvrsgx ?
Cheers, Merlijn
PS: Would be nice if we can just get a ML with archives soon.
Am 10.03.2019 um 00:14 schrieb Merlijn Wajer merlijn@wizzup.org:
Hi,
On 15/02/2019 14:09, H. Nikolaus Schaller wrote:
At least I can download and start firmware. I just have to find a way to fix the omaplfb so that it works with our omapdrm based panels to runs the CLipBlit test [1] on modern kernels...
Maybe you can compare with what we have here: https://github.com/maemo-leste/n9xx-linux/tree/pvr-wip-4.15.7/drivers/gpu/pv...
I'll take a look into it especially how omaplfb is done.
First observation is that there is a "flat" tree while I am working on a structured one... But that is just a marginal difference (mainly significant for Makefile writers).
I've ported the Maemo Leste kernel + pvr to 5.0 and it seems to work: https://github.com/maemo-leste/n9xx-linux/commits/pvr-wip-5.0.y
Should I add this as maemo-leste-n900-5.0 branch (or something) to https://github.com/openpvrsgx-devgroup/linux_openpvrsgx ?
Yes, that would be nice to be able to easily compare stuff.
Cheers, Merlijn
PS: Would be nice if we can just get a ML with archives soon.
I'd suggest to use linux-omap (because most of us are working for omap). Then we have archives and patchwork.
BR, Nikolaus
Hi,
On 10/03/2019 08:07, H. Nikolaus Schaller wrote:
Am 10.03.2019 um 00:14 schrieb Merlijn Wajer merlijn@wizzup.org:
Hi,
On 15/02/2019 14:09, H. Nikolaus Schaller wrote:
At least I can download and start firmware. I just have to find a way to fix the omaplfb so that it works with our omapdrm based panels to runs the CLipBlit test [1] on modern kernels...
Maybe you can compare with what we have here: https://github.com/maemo-leste/n9xx-linux/tree/pvr-wip-4.15.7/drivers/gpu/pv...
I'll take a look into it especially how omaplfb is done.
First observation is that there is a "flat" tree while I am working on a structured one... But that is just a marginal difference (mainly significant for Makefile writers).
I've ported the Maemo Leste kernel + pvr to 5.0 and it seems to work: https://github.com/maemo-leste/n9xx-linux/commits/pvr-wip-5.0.y
Should I add this as maemo-leste-n900-5.0 branch (or something) to https://github.com/openpvrsgx-devgroup/linux_openpvrsgx ?
Yes, that would be nice to be able to easily compare stuff.
I've just pushed the Maemo Leste v5.1 branch + patches here:
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/n900/v5.1-patch
This works on N900 with X, but it doesn't use DRM yet. I'm wondering what a next logical step would be: to try and modules to load/probe on another device (I have a droid4 or a Pandaboard ES rev B1), or to try and get DRM PowerVR to work on the N900, with omapdrmfb and dri3wsegl.
For either path, I'll probably need some help. Any updates from anyone else? Maybe we should list things people can work - perhaps document progress in github issues. (Mailing list is also fine, BTW)
Cheers, Merlijn
Hi all,
Am 17.07.2019 um 12:51 schrieb Merlijn Wajer merlijn@wizzup.org:
Hi,
On 10/03/2019 08:07, H. Nikolaus Schaller wrote:
Am 10.03.2019 um 00:14 schrieb Merlijn Wajer merlijn@wizzup.org:
Hi,
On 15/02/2019 14:09, H. Nikolaus Schaller wrote:
At least I can download and start firmware. I just have to find a way to fix the omaplfb so that it works with our omapdrm based panels to runs the CLipBlit test [1] on modern kernels...
Maybe you can compare with what we have here: https://github.com/maemo-leste/n9xx-linux/tree/pvr-wip-4.15.7/drivers/gpu/pv...
I'll take a look into it especially how omaplfb is done.
First observation is that there is a "flat" tree while I am working on a structured one... But that is just a marginal difference (mainly significant for Makefile writers).
I've ported the Maemo Leste kernel + pvr to 5.0 and it seems to work: https://github.com/maemo-leste/n9xx-linux/commits/pvr-wip-5.0.y
Should I add this as maemo-leste-n900-5.0 branch (or something) to https://github.com/openpvrsgx-devgroup/linux_openpvrsgx ?
Yes, that would be nice to be able to easily compare stuff.
I've just pushed the Maemo Leste v5.1 branch + patches here:
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/n900/v5.1-patch
This works on N900 with X, but it doesn't use DRM yet. I'm wondering what a next logical step would be: to try and modules to load/probe on another device (I have a droid4 or a Pandaboard ES rev B1), or to try and get DRM PowerVR to work on the N900, with omapdrmfb and dri3wsegl.
For either path, I'll probably need some help. Any updates from anyone else? Maybe we should list things people can work - perhaps document progress in github issues. (Mailing list is also fine, BTW)
Cheers, Merlijn
I also have pushed good news to
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/letux-pvr
Thanks to the help from the Pyra community, I was able to get a (binary) reference implementation using DRM that works on Pyra/OMAP5. At least the gles1test1.
With that reference setup I was able to fix my Makefiles for the staging/pvr implementation.
I have tested that it works with v4.19.66 and v5.3-rc4 (LPAE build of the LetuxOS kernel tree) on the Pyra.
In which areas does this tree go beyond the TI SDK/IMG DDK 1.14?
* includes internal API fixes for kernels up to v5.3 * lives in drivers/staging/pvr/1.14.3699939 - so that we can ask for inclusion in linux-next * has Kconfig and Makefiles for in-kernel configuration (no separate build system) * builds separate kernel modules for omap3430, omap3630, am335x, omap4, omap5, dra7 etc. pvrsrvkm e.g. pvrsrvkm_omap_omap5_sgx544_116 * the correct kernel module is automatically probed by matching .compatible in device tree so that the code is multi-platform friendly * includes SoC integration for OMAP3/4/5 and has some preliminary bindings documentation * code base should also support JZ4780/CI20 and some Intel Atom processors (CedarView, Poulsbo) * has got a ToDo to describe what should be done during staging phase
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/letux/latest-pv...
My plans for the next steps are:
* do more testing (e.g. X11, kmscube) * check if and/or how it can run on am335x (BeagleBone) or OMAP3 (e.g. GTA04, OpenPandora) * try a JZ480/CI20 build (unfortuantely I have no HDMI there with mainline kernels and I am missing the user-space libraries for MIPS).
BR, Nikolaus
* H. Nikolaus Schaller hns@goldelico.com [190814 08:57]:
I also have pushed good news to
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/letux-pvr
Thanks to the help from the Pyra community, I was able to get a (binary) reference implementation using DRM that works on Pyra/OMAP5. At least the gles1test1.
With that reference setup I was able to fix my Makefiles for the staging/pvr implementation.
I have tested that it works with v4.19.66 and v5.3-rc4 (LPAE build of the LetuxOS kernel tree) on the Pyra.
In which areas does this tree go beyond the TI SDK/IMG DDK 1.14?
includes internal API fixes for kernels up to v5.3
lives in drivers/staging/pvr/1.14.3699939 - so that we can ask for inclusion in linux-next
has Kconfig and Makefiles for in-kernel configuration (no separate build system)
builds separate kernel modules for omap3430, omap3630, am335x, omap4, omap5, dra7 etc. pvrsrvkm e.g. pvrsrvkm_omap_omap5_sgx544_116
the correct kernel module is automatically probed by matching .compatible in device tree so that the code is multi-platform friendly
includes SoC integration for OMAP3/4/5 and has some preliminary bindings documentation
code base should also support JZ4780/CI20 and some Intel Atom processors (CedarView, Poulsbo)
has got a ToDo to describe what should be done during staging phase
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/letux/latest-pv...
My plans for the next steps are:
- do more testing (e.g. X11, kmscube)
- check if and/or how it can run on am335x (BeagleBone) or OMAP3 (e.g. GTA04, OpenPandora)
- try a JZ480/CI20 build (unfortuantely I have no HDMI there with mainline kernels and I am missing the user-space libraries for MIPS).
That sounds good to me, just one comment. Before getting these into staging, I'd like to have omap variants use proper interconnect target module in devicetree like we already have in omap4.dtsi as target-module@56000000. This should simplify things further as the module child device driver(s) can just enable things with runtime PM and we can leave out all the legacy hwmod platform data that sounds like you're still carrying.
I have patches here to add similar interconnect target modules for at least omap34xx, omap36xx, omap5, and am335x that I'll try to post later on today to play with. For am335x, things still depend on the recentely posted prm rstctrl patches. I'm not sure if I already did a dts patch for dra7 yet, need to check.
Regards,
Tony
Am 14.08.2019 um 11:47 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [190814 08:57]:
I also have pushed good news to
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/letux-pvr
Thanks to the help from the Pyra community, I was able to get a (binary) reference implementation using DRM that works on Pyra/OMAP5. At least the gles1test1.
With that reference setup I was able to fix my Makefiles for the staging/pvr implementation.
I have tested that it works with v4.19.66 and v5.3-rc4 (LPAE build of the LetuxOS kernel tree) on the Pyra.
In which areas does this tree go beyond the TI SDK/IMG DDK 1.14?
- includes internal API fixes for kernels up to v5.3
- lives in drivers/staging/pvr/1.14.3699939 - so that we can ask for inclusion in linux-next
- has Kconfig and Makefiles for in-kernel configuration (no separate build system)
- builds separate kernel modules for omap3430, omap3630, am335x, omap4, omap5, dra7 etc.
pvrsrvkm e.g. pvrsrvkm_omap_omap5_sgx544_116
- the correct kernel module is automatically probed by matching .compatible in device tree
so that the code is multi-platform friendly
includes SoC integration for OMAP3/4/5 and has some preliminary bindings documentation
code base should also support JZ4780/CI20 and some Intel Atom processors (CedarView, Poulsbo)
has got a ToDo to describe what should be done during staging phase
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/letux/latest-pv...
My plans for the next steps are:
- do more testing (e.g. X11, kmscube)
- check if and/or how it can run on am335x (BeagleBone) or OMAP3 (e.g. GTA04, OpenPandora)
- try a JZ480/CI20 build (unfortuantely I have no HDMI there with mainline kernels and I am
missing the user-space libraries for MIPS).
That sounds good to me, just one comment. Before getting these into staging, I'd like to have omap variants use proper interconnect target module in devicetree like we already have in omap4.dtsi as target-module@56000000. This should simplify things further as the module child device driver(s) can just enable things with runtime PM and we can leave out all the legacy hwmod platform data that sounds like you're still carrying.
Yes, there is still a lot of SoC-glue included:
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux/omap-p...
It would indeed be a good move to simplify and reduce the glue code and make it more maintainable / stable / identical on different platforms.
I have patches here to add similar interconnect target modules for at least omap34xx, omap36xx, omap5, and am335x that I'll try to post later on today to play with. For am335x, things still depend on the recentely posted prm rstctrl patches. I'm not sure if I already did a dts patch for dra7 yet, need to check.
I assume it is not yet in linux-next... So something for v5.5 or later.
BR and thanks, Nikolaus
* H. Nikolaus Schaller hns@goldelico.com [190814 10:34]:
Am 14.08.2019 um 11:47 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [190814 08:57]:
I also have pushed good news to
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/letux-pvr
Thanks to the help from the Pyra community, I was able to get a (binary) reference implementation using DRM that works on Pyra/OMAP5. At least the gles1test1.
With that reference setup I was able to fix my Makefiles for the staging/pvr implementation.
I have tested that it works with v4.19.66 and v5.3-rc4 (LPAE build of the LetuxOS kernel tree) on the Pyra.
In which areas does this tree go beyond the TI SDK/IMG DDK 1.14?
- includes internal API fixes for kernels up to v5.3
- lives in drivers/staging/pvr/1.14.3699939 - so that we can ask for inclusion in linux-next
- has Kconfig and Makefiles for in-kernel configuration (no separate build system)
- builds separate kernel modules for omap3430, omap3630, am335x, omap4, omap5, dra7 etc.
pvrsrvkm e.g. pvrsrvkm_omap_omap5_sgx544_116
- the correct kernel module is automatically probed by matching .compatible in device tree
so that the code is multi-platform friendly
includes SoC integration for OMAP3/4/5 and has some preliminary bindings documentation
code base should also support JZ4780/CI20 and some Intel Atom processors (CedarView, Poulsbo)
has got a ToDo to describe what should be done during staging phase
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/letux/latest-pv...
My plans for the next steps are:
- do more testing (e.g. X11, kmscube)
- check if and/or how it can run on am335x (BeagleBone) or OMAP3 (e.g. GTA04, OpenPandora)
- try a JZ480/CI20 build (unfortuantely I have no HDMI there with mainline kernels and I am
missing the user-space libraries for MIPS).
That sounds good to me, just one comment. Before getting these into staging, I'd like to have omap variants use proper interconnect target module in devicetree like we already have in omap4.dtsi as target-module@56000000. This should simplify things further as the module child device driver(s) can just enable things with runtime PM and we can leave out all the legacy hwmod platform data that sounds like you're still carrying.
Yes, there is still a lot of SoC-glue included:
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux/omap-p...
It would indeed be a good move to simplify and reduce the glue code and make it more maintainable / stable / identical on different platforms.
OK yeah all that should just disappear :)
I have patches here to add similar interconnect target modules for at least omap34xx, omap36xx, omap5, and am335x that I'll try to post later on today to play with. For am335x, things still depend on the recentely posted prm rstctrl patches. I'm not sure if I already did a dts patch for dra7 yet, need to check.
I assume it is not yet in linux-next... So something for v5.5 or later.
Well I just posted some sgx interconnect target module patches. We might still have them in v5.4 assuming people manage to review and test them.
Regards,
Tony
On Wed, Aug 14, 2019 at 8:16 AM Tony Lindgren tony@atomide.com wrote:
- H. Nikolaus Schaller hns@goldelico.com [190814 10:34]:
Am 14.08.2019 um 11:47 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [190814 08:57]:
I also have pushed good news to
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/letux-pvr
Thanks to the help from the Pyra community, I was able to get a (binary) reference implementation using DRM that works on Pyra/OMAP5. At least the gles1test1.
With that reference setup I was able to fix my Makefiles for the staging/pvr implementation.
I have tested that it works with v4.19.66 and v5.3-rc4 (LPAE build of the LetuxOS kernel tree) on the Pyra.
In which areas does this tree go beyond the TI SDK/IMG DDK 1.14?
- includes internal API fixes for kernels up to v5.3
- lives in drivers/staging/pvr/1.14.3699939 - so that we can ask for inclusion in linux-next
- has Kconfig and Makefiles for in-kernel configuration (no separate build system)
- builds separate kernel modules for omap3430, omap3630, am335x, omap4, omap5, dra7 etc.
pvrsrvkm e.g. pvrsrvkm_omap_omap5_sgx544_116
- the correct kernel module is automatically probed by matching .compatible in device tree
so that the code is multi-platform friendly
includes SoC integration for OMAP3/4/5 and has some preliminary bindings documentation
code base should also support JZ4780/CI20 and some Intel Atom processors (CedarView, Poulsbo)
has got a ToDo to describe what should be done during staging phase
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/letux/latest-pv...
My plans for the next steps are:
- do more testing (e.g. X11, kmscube)
- check if and/or how it can run on am335x (BeagleBone) or OMAP3 (e.g. GTA04, OpenPandora)
- try a JZ480/CI20 build (unfortuantely I have no HDMI there with mainline kernels and I am
missing the user-space libraries for MIPS).
That sounds good to me, just one comment. Before getting these into staging, I'd like to have omap variants use proper interconnect target module in devicetree like we already have in omap4.dtsi as target-module@56000000. This should simplify things further as the module child device driver(s) can just enable things with runtime PM and we can leave out all the legacy hwmod platform data that sounds like you're still carrying.
Yes, there is still a lot of SoC-glue included:
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux/omap-pvr-soc-glueIt would indeed be a good move to simplify and reduce the glue code and make it more maintainable / stable / identical on different platforms.
OK yeah all that should just disappear :)
I have patches here to add similar interconnect target modules for at least omap34xx, omap36xx, omap5, and am335x that I'll try to post later on today to play with. For am335x, things still depend on the recentely posted prm rstctrl patches. I'm not sure if I already did a dts patch for dra7 yet, need to check.
I assume it is not yet in linux-next... So something for v5.5 or later.
Well I just posted some sgx interconnect target module patches. We might still have them in v5.4 assuming people manage to review and test them.
Nikolaus,
I tested Tony's change and I can confirm that I can read the value when enabled. Should I apply his patches to your branch before I test, or is it go too to go as-is? I've got an AM3517, OMAP35 and a DM3730. I am not sure if the AM3517 is even on the radar, but it has an sgx530 as well.
adam
Regards,
Tony
* Adam Ford aford173@gmail.com [190816 23:02]:
On Wed, Aug 14, 2019 at 8:16 AM Tony Lindgren tony@atomide.com wrote:
Well I just posted some sgx interconnect target module patches. We might still have them in v5.4 assuming people manage to review and test them.
Nikolaus,
I tested Tony's change and I can confirm that I can read the value when enabled. Should I apply his patches to your branch before I test, or is it go too to go as-is? I've got an AM3517, OMAP35 and a DM3730. I am not sure if the AM3517 is even on the radar, but it has an sgx530 as well.
My estimate is am3517 is wired the same way as omap34xx with a 60% chance, then 30% chance it's wired the same way as omap36xx, and then 10% chance for similar wiring to am335x.. So hopefully that leaves 0% chance for yet something different for it's wiring :)
If you have a chance please give it a try. Also check the TRM for the sgx sysconfig register bits to see which of the above matches, and if 3517 has a related rstctrl register like am335x has.
Regards,
Tony
On Sat, Aug 17, 2019 at 2:03 AM Tony Lindgren tony@atomide.com wrote:
- Adam Ford aford173@gmail.com [190816 23:02]:
On Wed, Aug 14, 2019 at 8:16 AM Tony Lindgren tony@atomide.com wrote:
Well I just posted some sgx interconnect target module patches. We might still have them in v5.4 assuming people manage to review and test them.
Nikolaus,
I tested Tony's change and I can confirm that I can read the value when enabled. Should I apply his patches to your branch before I test, or is it go too to go as-is? I've got an AM3517, OMAP35 and a DM3730. I am not sure if the AM3517 is even on the radar, but it has an sgx530 as well.
My estimate is am3517 is wired the same way as omap34xx with a 60% chance, then 30% chance it's wired the same way as omap36xx, and then 10% chance for similar wiring to am335x.. So hopefully that leaves 0% chance for yet something different for it's wiring :)
Based on [1], I went under the assumption it was wired like the omap34xx. I applied your omap34 patches to the am3517.dtsi, and I was able to get the same response as I did for the omap3530. Do you want me to post the patches to the mailing list, or do you want to do it?
adam
[1] - http://processors.wiki.ti.com/index.php/GSG:_AM35x_and_OMAP35x_Rebuilding_th...
If you have a chance please give it a try. Also check the TRM for the sgx sysconfig register bits to see which of the above matches, and if 3517 has a related rstctrl register like am335x has.
Regards,
Tony
* Adam Ford aford173@gmail.com [190819 19:26]:
On Sat, Aug 17, 2019 at 2:03 AM Tony Lindgren tony@atomide.com wrote:
- Adam Ford aford173@gmail.com [190816 23:02]:
On Wed, Aug 14, 2019 at 8:16 AM Tony Lindgren tony@atomide.com wrote:
Well I just posted some sgx interconnect target module patches. We might still have them in v5.4 assuming people manage to review and test them.
Nikolaus,
I tested Tony's change and I can confirm that I can read the value when enabled. Should I apply his patches to your branch before I test, or is it go too to go as-is? I've got an AM3517, OMAP35 and a DM3730. I am not sure if the AM3517 is even on the radar, but it has an sgx530 as well.
My estimate is am3517 is wired the same way as omap34xx with a 60% chance, then 30% chance it's wired the same way as omap36xx, and then 10% chance for similar wiring to am335x.. So hopefully that leaves 0% chance for yet something different for it's wiring :)
Based on [1], I went under the assumption it was wired like the omap34xx. I applied your omap34 patches to the am3517.dtsi, and I was able to get the same response as I did for the omap3530. Do you want me to post the patches to the mailing list, or do you want to do it?
OK great, yeah please post patches :)
Thanks,
TOny
Hi Adam,
Am 17.08.2019 um 01:01 schrieb Adam Ford aford173@gmail.com:
Nikolaus,
I tested Tony's change and I can confirm that I can read the value when enabled. Should I apply his patches to your branch before I test, or is it go too to go as-is?
My branch is currently as-is and not aware of Tony's patches and based on v5.3-rc3. I think I will have to remove some glue code which tries to do the platform reset and enables clocks and replace by pm_runtime_get_sync() before it fits together. Then we can likely remove the omap-pvr-soc-glue branch at least partially and/or replace by Tony's patches before they arrive in mainline.
The current status of my branch is that it works on OMAP5/Pyra but a quick test on BeagleBone or GTA04 did show some reset/clock errors and it did not more than creating /proc/pvr. pvrsrvctl --start did fail.
Which means that the omap-pvr-soc-glue patches are currently broken with 5.3-rc3 anyways...
I'll look at it as soon as possible.
I've got an AM3517, OMAP35 and a DM3730. I am not sure if the AM3517 is even on the radar, but it has an sgx530 as well.
Good to know and keep in mind.
BR, Nikolaus
On Wed, Aug 14, 2019 at 3:56 AM H. Nikolaus Schaller hns@goldelico.com wrote:
Hi all,
Am 17.07.2019 um 12:51 schrieb Merlijn Wajer merlijn@wizzup.org:
Hi,
On 10/03/2019 08:07, H. Nikolaus Schaller wrote:
Am 10.03.2019 um 00:14 schrieb Merlijn Wajer merlijn@wizzup.org:
Hi,
On 15/02/2019 14:09, H. Nikolaus Schaller wrote:
> At least I can download and start firmware. I just have to find a way to fix the omaplfb so that it works > with our omapdrm based panels to runs the CLipBlit test [1] on modern kernels...
Maybe you can compare with what we have here: https://github.com/maemo-leste/n9xx-linux/tree/pvr-wip-4.15.7/drivers/gpu/pv...
I'll take a look into it especially how omaplfb is done.
First observation is that there is a "flat" tree while I am working on a structured one... But that is just a marginal difference (mainly significant for Makefile writers).
I've ported the Maemo Leste kernel + pvr to 5.0 and it seems to work: https://github.com/maemo-leste/n9xx-linux/commits/pvr-wip-5.0.y
Should I add this as maemo-leste-n900-5.0 branch (or something) to https://github.com/openpvrsgx-devgroup/linux_openpvrsgx ?
Yes, that would be nice to be able to easily compare stuff.
I've just pushed the Maemo Leste v5.1 branch + patches here:
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/n900/v5.1-patchThis works on N900 with X, but it doesn't use DRM yet. I'm wondering what a next logical step would be: to try and modules to load/probe on another device (I have a droid4 or a Pandaboard ES rev B1), or to try and get DRM PowerVR to work on the N900, with omapdrmfb and dri3wsegl.
For either path, I'll probably need some help. Any updates from anyone else? Maybe we should list things people can work - perhaps document progress in github issues. (Mailing list is also fine, BTW)
Cheers, Merlijn
I also have pushed good news to
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/letux-pvrThanks to the help from the Pyra community, I was able to get a (binary) reference implementation using DRM that works on Pyra/OMAP5. At least the gles1test1.
just a question,
If DRM is working, does that mean it works without needing the overhead of X?
adam
With that reference setup I was able to fix my Makefiles for the staging/pvr implementation.
I have tested that it works with v4.19.66 and v5.3-rc4 (LPAE build of the LetuxOS kernel tree) on the Pyra.
In which areas does this tree go beyond the TI SDK/IMG DDK 1.14?
includes internal API fixes for kernels up to v5.3
lives in drivers/staging/pvr/1.14.3699939 - so that we can ask for inclusion in linux-next
has Kconfig and Makefiles for in-kernel configuration (no separate build system)
builds separate kernel modules for omap3430, omap3630, am335x, omap4, omap5, dra7 etc. pvrsrvkm e.g. pvrsrvkm_omap_omap5_sgx544_116
the correct kernel module is automatically probed by matching .compatible in device tree so that the code is multi-platform friendly
includes SoC integration for OMAP3/4/5 and has some preliminary bindings documentation
code base should also support JZ4780/CI20 and some Intel Atom processors (CedarView, Poulsbo)
has got a ToDo to describe what should be done during staging phase
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/letux/latest-pvr/drivers/staging/pvr/TODOMy plans for the next steps are:
- do more testing (e.g. X11, kmscube)
- check if and/or how it can run on am335x (BeagleBone) or OMAP3 (e.g. GTA04, OpenPandora)
- try a JZ480/CI20 build (unfortuantely I have no HDMI there with mainline kernels and I am missing the user-space libraries for MIPS).
BR, Nikolaus
Am 19.08.2019 um 21:43 schrieb Adam Ford aford173@gmail.com:
Thanks to the help from the Pyra community, I was able to get a (binary) reference implementation using DRM that works on Pyra/OMAP5. At least the gles1test1.
just a question,
If DRM is working, does that mean it works without needing the overhead of X?
Yes, we have to kill X11 to successfully run the gles1test1. An interesting question will be how to mix both... E.g. have a 3D rendering in a window controlled by some window manager.
Hi,
On 20/08/2019 08:48, H. Nikolaus Schaller wrote:
Am 19.08.2019 um 21:43 schrieb Adam Ford aford173@gmail.com:
Thanks to the help from the Pyra community, I was able to get a (binary) reference implementation using DRM that works on Pyra/OMAP5. At least the gles1test1.
just a question,
If DRM is working, does that mean it works without needing the overhead of X?
Yes, we have to kill X11 to successfully run the gles1test1. An interesting question will be how to mix both... E.g. have a 3D rendering in a window controlled by some window manager.
This is probably what you want to look at / start with: https://github.com/TexasInstruments/dri3wsegl
Cheers, Merlijn
Hi all, with the arrival of v5.4-rc1 some of Tony's sysc patches have arrived upstream, so we do no longer need them here.
Therefore, I have rebased my drivers/staging/pvr driver [1] and fixed some more issues: * omap4 build only needs to distinguish between omap4420/30/60 and omap4470, because the latter has an sgx544 inside and the other sgx540 This is solved by creating a new omap4470.dts * I have added proper reg values and interrupts to the omap4 device tree node of the sgx (child node of the target-module) * some updates to my sgxdump and sgxdemo scripts (assuming simple Debian Stretch rootfs) * James Hilliard has contributed a fix for osfunc.c * omap2plus also needs to be configured for STAGING and PREEMPT to be able to compile the driver * I have added the __always_inline fix [2] which is needed for v5.4 with CONFIG_CC_OPTIMIZE_FOR_SIZE=y (which I are enabled on the Letux builds)
Unfortunately Tero's rstctrl patches did not yet make it upstream (or even linux-next) so I also have a copy in this branch.
Results of first testing are: * OMAP3530 (OpenPandora, BeagleBoard C): fails with [ 559.247558] PVR_K:(Error): SysLocateDevices: platform_get_resource failed
* DM3730 (GTA04, BeagleBoard XM): kernel module loads
* OMAP4460 (Pandaboard ES): kernel module loads
* AM335x (BeagleBoneBlack): reports a problem with omap_reset_deassert: [ 204.246706] omap_reset_deassert: timedout waiting for gfx:0
* OMAP5 (Pyra): fails to enable the clocks (did work with the previous version) [ 304.140363] clock-controller:clk:0000:0: failed to enable [ 304.147388] PVR_K:(Error): EnableSGXClocks: pm_runtime_get_sync failed (16)
* OMAP5 with omap2plus_defconfig: root@letux:~# echo on > $(find /sys -name control | grep /5600) [ 213.490926] clock-controller:clk:0000:0: failed to enable root@letux:~#
* pvrsrvctl --start --no-module: reports (where the kernel module loads) that the uKernel does not run
So I have several ideas what the reasons for the problems on the non-omap5 devices could be: * initial code may have some omap5 specific hack inside * or has omap5 specific magic constants * uKernel may "know" on which platform it runs and we would need differently patched user-space code for each one * omap5 has a dual core sgx544 while the other have single core * the register address translation is not yet correct and this inhibits communicating of the user-space libs with the uKernel
Maybe, if someone can point me to a complete and working BeagleBone source tree (any kernel release) which makes use of 1.14.3699939 SDK, I could compare code and address setup to find what makes the difference.
BR and thanks, Nikolaus
[1]: https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux-pvr [2]: https://lkml.org/lkml/2019/10/2/201
Hi,
* H. Nikolaus Schaller hns@goldelico.com [191005 16:59]:
Hi all, with the arrival of v5.4-rc1 some of Tony's sysc patches have arrived upstream, so we do no longer need them here.
Therefore, I have rebased my drivers/staging/pvr driver [1] and fixed some more issues:
- omap4 build only needs to distinguish between omap4420/30/60 and omap4470, because the latter has an sgx544 inside and the other sgx540 This is solved by creating a new omap4470.dts
- I have added proper reg values and interrupts to the omap4 device tree node of the sgx (child node of the target-module)
- some updates to my sgxdump and sgxdemo scripts (assuming simple Debian Stretch rootfs)
- James Hilliard has contributed a fix for osfunc.c
- omap2plus also needs to be configured for STAGING and PREEMPT to be able to compile the driver
- I have added the __always_inline fix [2] which is needed for v5.4 with CONFIG_CC_OPTIMIZE_FOR_SIZE=y (which I are enabled on the Letux builds)
Unfortunately Tero's rstctrl patches did not yet make it upstream (or even linux-next) so I also have a copy in this branch.
Results of first testing are:
- OMAP3530 (OpenPandora, BeagleBoard C): fails with
[ 559.247558] PVR_K:(Error): SysLocateDevices: platform_get_resource failed
DM3730 (GTA04, BeagleBoard XM): kernel module loads
OMAP4460 (Pandaboard ES): kernel module loads
AM335x (BeagleBoneBlack): reports a problem with omap_reset_deassert:
[ 204.246706] omap_reset_deassert: timedout waiting for gfx:0
Please try with Tero's current github branch at github.com/t-kristo/linux-pm.git 5.4-rc1-ipc from few days ago, the earlier versions had still issues.
- OMAP5 (Pyra): fails to enable the clocks (did work with the previous version)
[ 304.140363] clock-controller:clk:0000:0: failed to enable [ 304.147388] PVR_K:(Error): EnableSGXClocks: pm_runtime_get_sync failed (16)
Hmm no idea what might be up with this one. Did some clkctrl clock fixes maybe cause a regression here? Tero do you have any ideas?
- OMAP5 with omap2plus_defconfig:
root@letux:~# echo on > $(find /sys -name control | grep /5600) [ 213.490926] clock-controller:clk:0000:0: failed to enable root@letux:~#
- pvrsrvctl --start --no-module: reports (where the kernel module loads) that the uKernel does not run
So I have several ideas what the reasons for the problems on the non-omap5 devices could be:
- initial code may have some omap5 specific hack inside
- or has omap5 specific magic constants
- uKernel may "know" on which platform it runs and we would need differently patched user-space code for each one
- omap5 has a dual core sgx544 while the other have single core
- the register address translation is not yet correct and this inhibits communicating of the user-space libs with the uKernel
Maybe, if someone can point me to a complete and working BeagleBone source tree (any kernel release) which makes use of 1.14.3699939 SDK, I could compare code and address setup to find what makes the difference.
Regards,
Tony
Am 07.10.2019 um 17:52 schrieb Tony Lindgren tony@atomide.com:
Hi,
- H. Nikolaus Schaller hns@goldelico.com [191005 16:59]:
- AM335x (BeagleBoneBlack): reports a problem with omap_reset_deassert:
[ 204.246706] omap_reset_deassert: timedout waiting for gfx:0
Please try with Tero's current github branch at github.com/t-kristo/linux-pm.git 5.4-rc1-ipc from few days ago, the earlier versions had still issues.
I have seen there has been a new version today and I'll try that one asap.
- OMAP5 (Pyra): fails to enable the clocks (did work with the previous version)
[ 304.140363] clock-controller:clk:0000:0: failed to enable [ 304.147388] PVR_K:(Error): EnableSGXClocks: pm_runtime_get_sync failed (16)
Hmm no idea what might be up with this one. Did some clkctrl clock fixes maybe cause a regression here? Tero do you have any ideas?
BR and thanks, Nikolaus
On 07/10/2019 18:52, Tony Lindgren wrote:
Hi,
- H. Nikolaus Schaller hns@goldelico.com [191005 16:59]:
Hi all, with the arrival of v5.4-rc1 some of Tony's sysc patches have arrived upstream, so we do no longer need them here.
Therefore, I have rebased my drivers/staging/pvr driver [1] and fixed some more issues:
- omap4 build only needs to distinguish between omap4420/30/60 and omap4470, because the latter has an sgx544 inside and the other sgx540 This is solved by creating a new omap4470.dts
- I have added proper reg values and interrupts to the omap4 device tree node of the sgx (child node of the target-module)
- some updates to my sgxdump and sgxdemo scripts (assuming simple Debian Stretch rootfs)
- James Hilliard has contributed a fix for osfunc.c
- omap2plus also needs to be configured for STAGING and PREEMPT to be able to compile the driver
- I have added the __always_inline fix [2] which is needed for v5.4 with CONFIG_CC_OPTIMIZE_FOR_SIZE=y (which I are enabled on the Letux builds)
Unfortunately Tero's rstctrl patches did not yet make it upstream (or even linux-next) so I also have a copy in this branch.
Results of first testing are:
- OMAP3530 (OpenPandora, BeagleBoard C): fails with
[ 559.247558] PVR_K:(Error): SysLocateDevices: platform_get_resource failed
DM3730 (GTA04, BeagleBoard XM): kernel module loads
OMAP4460 (Pandaboard ES): kernel module loads
AM335x (BeagleBoneBlack): reports a problem with omap_reset_deassert:
[ 204.246706] omap_reset_deassert: timedout waiting for gfx:0
Please try with Tero's current github branch at github.com/t-kristo/linux-pm.git 5.4-rc1-ipc from few days ago, the earlier versions had still issues.
Yeah, this one should be fixed now.
- OMAP5 (Pyra): fails to enable the clocks (did work with the previous version)
[ 304.140363] clock-controller:clk:0000:0: failed to enable [ 304.147388] PVR_K:(Error): EnableSGXClocks: pm_runtime_get_sync failed (16)
Hmm no idea what might be up with this one. Did some clkctrl clock fixes maybe cause a regression here? Tero do you have any ideas?
So, this one I am not too sure, I haven't looked at omap5 graphics clocking. I don't think it has anything to do with reset handling though.
Is there some simple way to try this out on board; without PVR module that is?
-Tero
- OMAP5 with omap2plus_defconfig:
root@letux:~# echo on > $(find /sys -name control | grep /5600) [ 213.490926] clock-controller:clk:0000:0: failed to enable root@letux:~#
- pvrsrvctl --start --no-module: reports (where the kernel module loads) that the uKernel does not run
So I have several ideas what the reasons for the problems on the non-omap5 devices could be:
- initial code may have some omap5 specific hack inside
- or has omap5 specific magic constants
- uKernel may "know" on which platform it runs and we would need differently patched user-space code for each one
- omap5 has a dual core sgx544 while the other have single core
- the register address translation is not yet correct and this inhibits communicating of the user-space libs with the uKernel
Maybe, if someone can point me to a complete and working BeagleBone source tree (any kernel release) which makes use of 1.14.3699939 SDK, I could compare code and address setup to find what makes the difference.
Regards,
Tony
-- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Hi Tero,
Am 07.10.2019 um 21:18 schrieb Tero Kristo t-kristo@ti.com:
On 07/10/2019 18:52, Tony Lindgren wrote:
Hi,
- H. Nikolaus Schaller hns@goldelico.com [191005 16:59]:
Please try with Tero's current github branch at github.com/t-kristo/linux-pm.git 5.4-rc1-ipc from few days ago, the earlier versions had still issues.
Yeah, this one should be fixed now.
Ok! Will try asap.
- OMAP5 (Pyra): fails to enable the clocks (did work with the previous version)
[ 304.140363] clock-controller:clk:0000:0: failed to enable [ 304.147388] PVR_K:(Error): EnableSGXClocks: pm_runtime_get_sync failed (16)
Hmm no idea what might be up with this one. Did some clkctrl clock fixes maybe cause a regression here? Tero do you have any ideas?
So, this one I am not too sure, I haven't looked at omap5 graphics clocking. I don't think it has anything to do with reset handling though.
Is there some simple way to try this out on board; without PVR module that is?
Yes, I have also seen it when just running the commands in the original commit message [1]:
# echo on > $(find /sys -name control | grep /5600) # rwmem 0x5600fe00 # OCP Revision 0x5600fe00 = 0x40000000 # echo auto > $(find /sys -name control | grep /5600) # rwmem 0x5600fe10 # rwmem 0x56000024
But I have not yet tested with 5.4-rc2, just 5.4-rc1.
BR and thanks, Nikolaus
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h...
On 07/10/2019 22:24, H. Nikolaus Schaller wrote:
Hi Tero,
Am 07.10.2019 um 21:18 schrieb Tero Kristo t-kristo@ti.com:
On 07/10/2019 18:52, Tony Lindgren wrote:
Hi,
- H. Nikolaus Schaller hns@goldelico.com [191005 16:59]:
Please try with Tero's current github branch at github.com/t-kristo/linux-pm.git 5.4-rc1-ipc from few days ago, the earlier versions had still issues.
Yeah, this one should be fixed now.
Ok! Will try asap.
- OMAP5 (Pyra): fails to enable the clocks (did work with the previous version)
[ 304.140363] clock-controller:clk:0000:0: failed to enable [ 304.147388] PVR_K:(Error): EnableSGXClocks: pm_runtime_get_sync failed (16)
Hmm no idea what might be up with this one. Did some clkctrl clock fixes maybe cause a regression here? Tero do you have any ideas?
So, this one I am not too sure, I haven't looked at omap5 graphics clocking. I don't think it has anything to do with reset handling though.
Is there some simple way to try this out on board; without PVR module that is?
Yes, I have also seen it when just running the commands in the original commit message [1]:
# echo on > $(find /sys -name control | grep /5600) # rwmem 0x5600fe00 # OCP Revision 0x5600fe00 = 0x40000000 # echo auto > $(find /sys -name control | grep /5600) # rwmem 0x5600fe10 # rwmem 0x56000024
But I have not yet tested with 5.4-rc2, just 5.4-rc1.
Ok, there is a one liner DTS data fix for this issue, attached.
-Tero
-- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
* Tero Kristo t-kristo@ti.com [191008 08:01]:
On 07/10/2019 22:24, H. Nikolaus Schaller wrote:
Hi Tero,
Am 07.10.2019 um 21:18 schrieb Tero Kristo t-kristo@ti.com:
On 07/10/2019 18:52, Tony Lindgren wrote:
Hi,
- H. Nikolaus Schaller hns@goldelico.com [191005 16:59]:
Please try with Tero's current github branch at github.com/t-kristo/linux-pm.git 5.4-rc1-ipc from few days ago, the earlier versions had still issues.
Yeah, this one should be fixed now.
Ok! Will try asap.
- OMAP5 (Pyra): fails to enable the clocks (did work with the previous version)
[ 304.140363] clock-controller:clk:0000:0: failed to enable [ 304.147388] PVR_K:(Error): EnableSGXClocks: pm_runtime_get_sync failed (16)
Hmm no idea what might be up with this one. Did some clkctrl clock fixes maybe cause a regression here? Tero do you have any ideas?
So, this one I am not too sure, I haven't looked at omap5 graphics clocking. I don't think it has anything to do with reset handling though.
Is there some simple way to try this out on board; without PVR module that is?
Yes, I have also seen it when just running the commands in the original commit message [1]:
# echo on > $(find /sys -name control | grep /5600) # rwmem 0x5600fe00 # OCP Revision 0x5600fe00 = 0x40000000 # echo auto > $(find /sys -name control | grep /5600) # rwmem 0x5600fe10 # rwmem 0x56000024
But I have not yet tested with 5.4-rc2, just 5.4-rc1.
Ok, there is a one liner DTS data fix for this issue, attached.
Arhg OK that thing again.. I must have changed node name while cleaning up the patch or something. Thanks, will apply into fixes.
Then for v5.5, we should start using custom compatible properties for the clock controller instances. I'll be posting a patch for that. Otherwise scripts/checkpatch.pl --strict type clean-up will cause unexpected issues.
Regards,
Tony
From 57f9fecb167c0ef9f1ae2a1aa93a05ca8add52a2 Mon Sep 17 00:00:00 2001 From: Tero Kristo t-kristo@ti.com Date: Tue, 8 Oct 2019 10:56:42 +0300 Subject: [PATCH 1/1] ARM: dts: omap5: fix gpu_cm clock provider name
The clkctrl code searches for the parent clockdomain based on the name of the CM provider node. The introduction of SGX node for omap5 made the node name for the gpu_cm to be clock-controller. There is no clockdomain named like this, so the lookup fails. Fix by changing the node name properly.
Fixes: 394534cb07d8 ("ARM: dts: Configure sgx for omap5") Signed-off-by: Tero Kristo t-kristo@ti.com
arch/arm/boot/dts/omap54xx-clocks.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap54xx-clocks.dtsi b/arch/arm/boot/dts/omap54xx-clocks.dtsi index 939ec7dfc366..db9885103099 100644 --- a/arch/arm/boot/dts/omap54xx-clocks.dtsi +++ b/arch/arm/boot/dts/omap54xx-clocks.dtsi @@ -1160,7 +1160,7 @@ }; };
- gpu_cm: clock-controller@1500 {
- gpu_cm: gpu_cm@1500 { compatible = "ti,omap4-cm"; reg = <0x1500 0x100>; #address-cells = <1>;
-- 2.17.1
Am 08.10.2019 um 10:00 schrieb Tero Kristo t-kristo@ti.com:
On 07/10/2019 22:24, H. Nikolaus Schaller wrote:
Hi Tero,
Am 07.10.2019 um 21:18 schrieb Tero Kristo t-kristo@ti.com:
On 07/10/2019 18:52, Tony Lindgren wrote:
Hi,
- H. Nikolaus Schaller hns@goldelico.com [191005 16:59]:
Please try with Tero's current github branch at github.com/t-kristo/linux-pm.git 5.4-rc1-ipc from few days ago, the earlier versions had still issues.
Yeah, this one should be fixed now.
Ok! Will try asap.
- OMAP5 (Pyra): fails to enable the clocks (did work with the previous version)
[ 304.140363] clock-controller:clk:0000:0: failed to enable [ 304.147388] PVR_K:(Error): EnableSGXClocks: pm_runtime_get_sync failed (16)
Hmm no idea what might be up with this one. Did some clkctrl clock fixes maybe cause a regression here? Tero do you have any ideas?
So, this one I am not too sure, I haven't looked at omap5 graphics clocking. I don't think it has anything to do with reset handling though.
Is there some simple way to try this out on board; without PVR module that is?
Yes, I have also seen it when just running the commands in the original commit message [1]: # echo on > $(find /sys -name control | grep /5600) # rwmem 0x5600fe00 # OCP Revision 0x5600fe00 = 0x40000000 # echo auto > $(find /sys -name control | grep /5600) # rwmem 0x5600fe10 # rwmem 0x56000024 But I have not yet tested with 5.4-rc2, just 5.4-rc1.
Ok, there is a one liner DTS data fix for this issue, attached.
Yes, have tested and it fixes omap5. I have the 3D demo running again on the Pyra. Yay!
Together with the latest rstcrtl patches, am335x is now better. No omap_reset_deassert: timedout waiting for gfx:0 any more.
But I can't access the sgx registers and get memory faults. Maybe my script has a bug and is trying the wrong address. Have to check with some distance...
I have also tested omap3630 and omap4460 and they are not worse, but also not better. So I think the foundation for sgx clock and reset is now ok.
BR and thanks, Nikolaus
Am 08.10.2019 um 22:15 schrieb H. Nikolaus Schaller hns@goldelico.com:
Am 08.10.2019 um 10:00 schrieb Tero Kristo t-kristo@ti.com:
On 07/10/2019 22:24, H. Nikolaus Schaller wrote:
Hi Tero,
Am 07.10.2019 um 21:18 schrieb Tero Kristo t-kristo@ti.com:
On 07/10/2019 18:52, Tony Lindgren wrote:
Hi,
- H. Nikolaus Schaller hns@goldelico.com [191005 16:59]:
Please try with Tero's current github branch at github.com/t-kristo/linux-pm.git 5.4-rc1-ipc from few days ago, the earlier versions had still issues.
Yeah, this one should be fixed now.
Ok! Will try asap.
- OMAP5 (Pyra): fails to enable the clocks (did work with the previous version)
[ 304.140363] clock-controller:clk:0000:0: failed to enable [ 304.147388] PVR_K:(Error): EnableSGXClocks: pm_runtime_get_sync failed (16)
Hmm no idea what might be up with this one. Did some clkctrl clock fixes maybe cause a regression here? Tero do you have any ideas?
So, this one I am not too sure, I haven't looked at omap5 graphics clocking. I don't think it has anything to do with reset handling though.
Is there some simple way to try this out on board; without PVR module that is?
Yes, I have also seen it when just running the commands in the original commit message [1]: # echo on > $(find /sys -name control | grep /5600) # rwmem 0x5600fe00 # OCP Revision 0x5600fe00 = 0x40000000 # echo auto > $(find /sys -name control | grep /5600) # rwmem 0x5600fe10 # rwmem 0x56000024 But I have not yet tested with 5.4-rc2, just 5.4-rc1.
Ok, there is a one liner DTS data fix for this issue, attached.
Yes, have tested and it fixes omap5. I have the 3D demo running again on the Pyra. Yay!
Together with the latest rstcrtl patches, am335x is now better. No omap_reset_deassert: timedout waiting for gfx:0 any more.
But I can't access the sgx registers and get memory faults. Maybe my script has a bug and is trying the wrong address. Have to check with some distance...
Now I have done more tests on am335x. It is not my script but something else.
Trying to read 0x5600fe00 after doing
echo on > /sys/bus/platform/devices/5600fe00.target-module/power/control
gives page faults.
When trying to load the kernel driver, the omap_reset_deassert message has gone but the driver does no initialize:
root@letux:~# modprobe pvrsrvkm_omap_am335x_sgx530_125 [ 45.774712] pvrsrvkm_omap_am335x_sgx530_125: module is from the staging directory, the quality is unknown, you have been warned. root@letux:~#
Here is the CM/PM register dump after enabling power/control
*** SGX Register Dump *** 0x44E00900 00000301 CM_GFX_L3_CLKSTCTRL 0x44E00904 00050000 CM_GFX_GFX_CLKCTRL 0x44E0090c 00000002 CM_GFX_L4LS_GFX_CLKSTCTR 0x44E00910 00030000 CM_GFX_MMUCFG_CLKCTRL 0x44E00914 00030000 CM_GFX_MMUDATA_CLKCTRL 0x44E0052c 00000000 CM_DPLL.CLKSEL_GFX_FCLK 0x44E01100 00060047 PM_GFX_PWRSTCTRL 0x44E01104 00000001 RM_GFX_RSTCTRL 0x44E01110 00000037 PM_GFX_PWRSTST
BR, Nikolaus
On 09/10/2019 15:53, H. Nikolaus Schaller wrote:
Am 08.10.2019 um 22:15 schrieb H. Nikolaus Schaller hns@goldelico.com:
Am 08.10.2019 um 10:00 schrieb Tero Kristo t-kristo@ti.com:
On 07/10/2019 22:24, H. Nikolaus Schaller wrote:
Hi Tero,
Am 07.10.2019 um 21:18 schrieb Tero Kristo t-kristo@ti.com:
On 07/10/2019 18:52, Tony Lindgren wrote:
Hi,
- H. Nikolaus Schaller hns@goldelico.com [191005 16:59]:
Please try with Tero's current github branch at github.com/t-kristo/linux-pm.git 5.4-rc1-ipc from few days ago, the earlier versions had still issues.
Yeah, this one should be fixed now.
Ok! Will try asap.
> * OMAP5 (Pyra): fails to enable the clocks (did work with the previous version) > [ 304.140363] clock-controller:clk:0000:0: failed to enable > [ 304.147388] PVR_K:(Error): EnableSGXClocks: pm_runtime_get_sync failed (16) Hmm no idea what might be up with this one. Did some clkctrl clock fixes maybe cause a regression here? Tero do you have any ideas?
So, this one I am not too sure, I haven't looked at omap5 graphics clocking. I don't think it has anything to do with reset handling though.
Is there some simple way to try this out on board; without PVR module that is?
Yes, I have also seen it when just running the commands in the original commit message [1]: # echo on > $(find /sys -name control | grep /5600) # rwmem 0x5600fe00 # OCP Revision 0x5600fe00 = 0x40000000 # echo auto > $(find /sys -name control | grep /5600) # rwmem 0x5600fe10 # rwmem 0x56000024 But I have not yet tested with 5.4-rc2, just 5.4-rc1.
Ok, there is a one liner DTS data fix for this issue, attached.
Yes, have tested and it fixes omap5. I have the 3D demo running again on the Pyra. Yay!
Together with the latest rstcrtl patches, am335x is now better. No omap_reset_deassert: timedout waiting for gfx:0 any more.
But I can't access the sgx registers and get memory faults. Maybe my script has a bug and is trying the wrong address. Have to check with some distance...
Now I have done more tests on am335x. It is not my script but something else.
Trying to read 0x5600fe00 after doing
echo on > /sys/bus/platform/devices/5600fe00.target-module/power/control
gives page faults.
When trying to load the kernel driver, the omap_reset_deassert message has gone but the driver does no initialize:
root@letux:~# modprobe pvrsrvkm_omap_am335x_sgx530_125 [ 45.774712] pvrsrvkm_omap_am335x_sgx530_125: module is from the staging directory, the quality is unknown, you have been warned. root@letux:~#
Here is the CM/PM register dump after enabling power/control
*** SGX Register Dump *** 0x44E00900 00000301 CM_GFX_L3_CLKSTCTRL 0x44E00904 00050000 CM_GFX_GFX_CLKCTRL 0x44E0090c 00000002 CM_GFX_L4LS_GFX_CLKSTCTR 0x44E00910 00030000 CM_GFX_MMUCFG_CLKCTRL 0x44E00914 00030000 CM_GFX_MMUDATA_CLKCTRL 0x44E0052c 00000000 CM_DPLL.CLKSEL_GFX_FCLK 0x44E01100 00060047 PM_GFX_PWRSTCTRL 0x44E01104 00000001 RM_GFX_RSTCTRL 0x44E01110 00000037 PM_GFX_PWRSTST
Are you sure you have the graphics node properly applied in your kernel?
As you can see the RM_GFX_RSTCTRL is still asserted (it should be zero so that you can access the module) and the CM_GFX_GFX_CLKCTRL is also disabled (bits 0-1 are 0, should be 2 in the working case.)
It works for me with my branch + the single am33xx patch from Tony.
-Tero
BR, Nikolaus
-- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Am 09.10.2019 um 15:55 schrieb Tero Kristo t-kristo@ti.com:
On 09/10/2019 15:53, H. Nikolaus Schaller wrote:
Am 08.10.2019 um 22:15 schrieb H. Nikolaus Schaller hns@goldelico.com:
But I can't access the sgx registers and get memory faults. Maybe my script has a bug and is trying the wrong address. Have to check with some distance...
Now I have done more tests on am335x. It is not my script but something else. Trying to read 0x5600fe00 after doing echo on > /sys/bus/platform/devices/5600fe00.target-module/power/control gives page faults. When trying to load the kernel driver, the omap_reset_deassert message has gone but the driver does no initialize: root@letux:~# modprobe pvrsrvkm_omap_am335x_sgx530_125 [ 45.774712] pvrsrvkm_omap_am335x_sgx530_125: module is from the staging directory, the quality is unknown, you have been warned. root@letux:~# Here is the CM/PM register dump after enabling power/control *** SGX Register Dump *** 0x44E00900 00000301 CM_GFX_L3_CLKSTCTRL 0x44E00904 00050000 CM_GFX_GFX_CLKCTRL 0x44E0090c 00000002 CM_GFX_L4LS_GFX_CLKSTCTR 0x44E00910 00030000 CM_GFX_MMUCFG_CLKCTRL 0x44E00914 00030000 CM_GFX_MMUDATA_CLKCTRL 0x44E0052c 00000000 CM_DPLL.CLKSEL_GFX_FCLK 0x44E01100 00060047 PM_GFX_PWRSTCTRL 0x44E01104 00000001 RM_GFX_RSTCTRL 0x44E01110 00000037 PM_GFX_PWRSTST
Are you sure you have the graphics node properly applied in your kernel?
Not really... There are several patch sets which seem to be necessary (to support all omap variants) and I am not sure if I have them all and correctly.
I have collected these patches on top of v5.4-rc2:
272d7200c77a ARM: dts: omap5: fix gpu_cm clock provider name 96fa23010f2a dt-bindings: omap: add new binding for PRM instances a164172c1f40 soc: ti: add initial PRM driver with reset control support 42a5e4261993 soc: ti: omap-prm: poll for reset complete during de-assert 9237f39716be soc: ti: omap-prm: add support for denying idle for reset clockdomain bf2ae22e5bcf soc: ti: omap-prm: add omap4 PRM data be5cb64f10e0 soc: ti: omap-prm: add data for am33xx 86646d7d79be soc: ti: omap-prm: add dra7 PRM data c3b5455dfd65 soc: ti: omap-prm: add am4 PRM data e26d4ff7ad15 soc: ti: omap-prm: add omap5 PRM data 66369100d1fc clk: ti: am43xx: drop idlest polling from gfx clock d96899e143de bus: ti-sysc: re-order reset and main clock controls 45071446bd05 bus: ti-sysc: drop the extra hardreset during init 0da134c3aa9d bus: ti-sysc: avoid toggling power state of module during probe 17b70c96b539 ARM: OMAP2+: pdata-quirks: add PRM data for reset support af81a68c65d7 clk: ti: clkctrl: fix setting up clkctrl clocks d7dd7f44bce4 clk: ti: clkctrl: convert to use bit helper macros instead of bitops 42ee8270adfd clk: ti: clkctrl: add new exported API for checking standby info 218b39a8c851 dt-bindings: clk: add omap5 iva clkctrl definitions 41b6c466efde clk: ti: omap5: add IVA subsystem clkctrl data 38cfdebcc2f8 clk: ti: dra7xx: Drop idlest polling from IPU & DSP clkctrl clocks 39e827b0dfe5 clk: ti: omap4: Drop idlest polling from IPU & DSP clkctrl clocks f4584f1e5bff clk: ti: omap5: Drop idlest polling from IPU & DSP clkctrl clocks 1c7f5871e5a0 clk: ti: am43xx: drop idlest polling from pruss clkctrl clock 53363c4cfb3d clk: ti: am33xx: drop idlest polling from pruss clkctrl clock 1907994ee9ce ARM: dts: omap5: add IVA clkctrl nodes 8182f3f282de ARM: dts: dra7: add PRM nodes ff2880fb99c7 ARM: dts: omap4: add PRM nodes 4d49da48c458 ARM: dts: am33xx: Add PRM data 325cffda2b2d ARM: dts: am43xx: Add PRM data b6ceeb4c5b74 ARM: dts: omap5: Add PRM data 303b7b4bcc60 ARM: dts: dra7: convert IOMMUs to use ti-sysc d875126d92f7 ARM: dts: dra74x: convert IOMMUs to use ti-sysc 8f699534deb8 ARM: dts: omap4: convert IOMMUs to use ti-sysc b1ec9e25a686 ARM: dts: omap5: convert IOMMUs to use ti-sysc e90c0cc1e4a5 ARM: dts: Configure rstctrl reset for SGX
As you can see the RM_GFX_RSTCTRL is still asserted (it should be zero so that you can access the module) and the CM_GFX_GFX_CLKCTRL is also disabled (bits 0-1 are 0, should be 2 in the working case.)
Ok.
It works for me with my branch + the single am33xx patch from Tony.
Is there a link so that I can compare with the right version?
BR and thanks, Nikolaus
On 09/10/2019 17:23, H. Nikolaus Schaller wrote:
Am 09.10.2019 um 15:55 schrieb Tero Kristo t-kristo@ti.com:
On 09/10/2019 15:53, H. Nikolaus Schaller wrote:
Am 08.10.2019 um 22:15 schrieb H. Nikolaus Schaller hns@goldelico.com:
But I can't access the sgx registers and get memory faults. Maybe my script has a bug and is trying the wrong address. Have to check with some distance...
Now I have done more tests on am335x. It is not my script but something else. Trying to read 0x5600fe00 after doing echo on > /sys/bus/platform/devices/5600fe00.target-module/power/control gives page faults. When trying to load the kernel driver, the omap_reset_deassert message has gone but the driver does no initialize: root@letux:~# modprobe pvrsrvkm_omap_am335x_sgx530_125 [ 45.774712] pvrsrvkm_omap_am335x_sgx530_125: module is from the staging directory, the quality is unknown, you have been warned. root@letux:~# Here is the CM/PM register dump after enabling power/control *** SGX Register Dump *** 0x44E00900 00000301 CM_GFX_L3_CLKSTCTRL 0x44E00904 00050000 CM_GFX_GFX_CLKCTRL 0x44E0090c 00000002 CM_GFX_L4LS_GFX_CLKSTCTR 0x44E00910 00030000 CM_GFX_MMUCFG_CLKCTRL 0x44E00914 00030000 CM_GFX_MMUDATA_CLKCTRL 0x44E0052c 00000000 CM_DPLL.CLKSEL_GFX_FCLK 0x44E01100 00060047 PM_GFX_PWRSTCTRL 0x44E01104 00000001 RM_GFX_RSTCTRL 0x44E01110 00000037 PM_GFX_PWRSTST
Are you sure you have the graphics node properly applied in your kernel?
Not really... There are several patch sets which seem to be necessary (to support all omap variants) and I am not sure if I have them all and correctly.
I have collected these patches on top of v5.4-rc2:
272d7200c77a ARM: dts: omap5: fix gpu_cm clock provider name 96fa23010f2a dt-bindings: omap: add new binding for PRM instances a164172c1f40 soc: ti: add initial PRM driver with reset control support 42a5e4261993 soc: ti: omap-prm: poll for reset complete during de-assert 9237f39716be soc: ti: omap-prm: add support for denying idle for reset clockdomain bf2ae22e5bcf soc: ti: omap-prm: add omap4 PRM data be5cb64f10e0 soc: ti: omap-prm: add data for am33xx 86646d7d79be soc: ti: omap-prm: add dra7 PRM data c3b5455dfd65 soc: ti: omap-prm: add am4 PRM data e26d4ff7ad15 soc: ti: omap-prm: add omap5 PRM data 66369100d1fc clk: ti: am43xx: drop idlest polling from gfx clock
You should have similar patch as above for am33xx. Otherwise it will probably fail probing the ti-sysc, resulting in the failure you see.
-Tero
d96899e143de bus: ti-sysc: re-order reset and main clock controls 45071446bd05 bus: ti-sysc: drop the extra hardreset during init 0da134c3aa9d bus: ti-sysc: avoid toggling power state of module during probe 17b70c96b539 ARM: OMAP2+: pdata-quirks: add PRM data for reset support af81a68c65d7 clk: ti: clkctrl: fix setting up clkctrl clocks d7dd7f44bce4 clk: ti: clkctrl: convert to use bit helper macros instead of bitops 42ee8270adfd clk: ti: clkctrl: add new exported API for checking standby info 218b39a8c851 dt-bindings: clk: add omap5 iva clkctrl definitions 41b6c466efde clk: ti: omap5: add IVA subsystem clkctrl data 38cfdebcc2f8 clk: ti: dra7xx: Drop idlest polling from IPU & DSP clkctrl clocks 39e827b0dfe5 clk: ti: omap4: Drop idlest polling from IPU & DSP clkctrl clocks f4584f1e5bff clk: ti: omap5: Drop idlest polling from IPU & DSP clkctrl clocks 1c7f5871e5a0 clk: ti: am43xx: drop idlest polling from pruss clkctrl clock 53363c4cfb3d clk: ti: am33xx: drop idlest polling from pruss clkctrl clock 1907994ee9ce ARM: dts: omap5: add IVA clkctrl nodes 8182f3f282de ARM: dts: dra7: add PRM nodes ff2880fb99c7 ARM: dts: omap4: add PRM nodes 4d49da48c458 ARM: dts: am33xx: Add PRM data 325cffda2b2d ARM: dts: am43xx: Add PRM data b6ceeb4c5b74 ARM: dts: omap5: Add PRM data 303b7b4bcc60 ARM: dts: dra7: convert IOMMUs to use ti-sysc d875126d92f7 ARM: dts: dra74x: convert IOMMUs to use ti-sysc 8f699534deb8 ARM: dts: omap4: convert IOMMUs to use ti-sysc b1ec9e25a686 ARM: dts: omap5: convert IOMMUs to use ti-sysc e90c0cc1e4a5 ARM: dts: Configure rstctrl reset for SGX
As you can see the RM_GFX_RSTCTRL is still asserted (it should be zero so that you can access the module) and the CM_GFX_GFX_CLKCTRL is also disabled (bits 0-1 are 0, should be 2 in the working case.)
Ok.
It works for me with my branch + the single am33xx patch from Tony.
Is there a link so that I can compare with the right version?
BR and thanks, Nikolaus
-- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Am 09.10.2019 um 18:34 schrieb Tero Kristo t-kristo@ti.com:
On 09/10/2019 17:23, H. Nikolaus Schaller wrote:
Am 09.10.2019 um 15:55 schrieb Tero Kristo t-kristo@ti.com:
On 09/10/2019 15:53, H. Nikolaus Schaller wrote:
Am 08.10.2019 um 22:15 schrieb H. Nikolaus Schaller hns@goldelico.com:
But I can't access the sgx registers and get memory faults. Maybe my script has a bug and is trying the wrong address. Have to check with some distance...
Now I have done more tests on am335x. It is not my script but something else. Trying to read 0x5600fe00 after doing echo on > /sys/bus/platform/devices/5600fe00.target-module/power/control gives page faults. When trying to load the kernel driver, the omap_reset_deassert message has gone but the driver does no initialize: root@letux:~# modprobe pvrsrvkm_omap_am335x_sgx530_125 [ 45.774712] pvrsrvkm_omap_am335x_sgx530_125: module is from the staging directory, the quality is unknown, you have been warned. root@letux:~# Here is the CM/PM register dump after enabling power/control *** SGX Register Dump *** 0x44E00900 00000301 CM_GFX_L3_CLKSTCTRL 0x44E00904 00050000 CM_GFX_GFX_CLKCTRL 0x44E0090c 00000002 CM_GFX_L4LS_GFX_CLKSTCTR 0x44E00910 00030000 CM_GFX_MMUCFG_CLKCTRL 0x44E00914 00030000 CM_GFX_MMUDATA_CLKCTRL 0x44E0052c 00000000 CM_DPLL.CLKSEL_GFX_FCLK 0x44E01100 00060047 PM_GFX_PWRSTCTRL 0x44E01104 00000001 RM_GFX_RSTCTRL 0x44E01110 00000037 PM_GFX_PWRSTST
Are you sure you have the graphics node properly applied in your kernel?
Not really... There are several patch sets which seem to be necessary (to support all omap variants) and I am not sure if I have them all and correctly. I have collected these patches on top of v5.4-rc2: 272d7200c77a ARM: dts: omap5: fix gpu_cm clock provider name 96fa23010f2a dt-bindings: omap: add new binding for PRM instances a164172c1f40 soc: ti: add initial PRM driver with reset control support 42a5e4261993 soc: ti: omap-prm: poll for reset complete during de-assert 9237f39716be soc: ti: omap-prm: add support for denying idle for reset clockdomain bf2ae22e5bcf soc: ti: omap-prm: add omap4 PRM data be5cb64f10e0 soc: ti: omap-prm: add data for am33xx 86646d7d79be soc: ti: omap-prm: add dra7 PRM data c3b5455dfd65 soc: ti: omap-prm: add am4 PRM data e26d4ff7ad15 soc: ti: omap-prm: add omap5 PRM data 66369100d1fc clk: ti: am43xx: drop idlest polling from gfx clock
You should have similar patch as above for am33xx. Otherwise it will probably fail probing the ti-sysc, resulting in the failure you see.
-Tero
d96899e143de bus: ti-sysc: re-order reset and main clock controls 45071446bd05 bus: ti-sysc: drop the extra hardreset during init 0da134c3aa9d bus: ti-sysc: avoid toggling power state of module during probe 17b70c96b539 ARM: OMAP2+: pdata-quirks: add PRM data for reset support af81a68c65d7 clk: ti: clkctrl: fix setting up clkctrl clocks d7dd7f44bce4 clk: ti: clkctrl: convert to use bit helper macros instead of bitops 42ee8270adfd clk: ti: clkctrl: add new exported API for checking standby info 218b39a8c851 dt-bindings: clk: add omap5 iva clkctrl definitions 41b6c466efde clk: ti: omap5: add IVA subsystem clkctrl data 38cfdebcc2f8 clk: ti: dra7xx: Drop idlest polling from IPU & DSP clkctrl clocks 39e827b0dfe5 clk: ti: omap4: Drop idlest polling from IPU & DSP clkctrl clocks f4584f1e5bff clk: ti: omap5: Drop idlest polling from IPU & DSP clkctrl clocks 1c7f5871e5a0 clk: ti: am43xx: drop idlest polling from pruss clkctrl clock 53363c4cfb3d clk: ti: am33xx: drop idlest polling from pruss clkctrl clock
so the pattern of ^^^ but for gfx clock?
Yes, there seems to be
[PATCH 1/2] clk: ti: am33xx: drop idlest polling from gfx clock
which I am missing. Most likely, I accidentally did download from patchwork just a single patch (am43xx) and not the series...
With this patch added, I now have access to the sgx registers:
root@letux:~# ./sgxdump *** SGX Register Dump *** 0x44E00900 00000302 CM_GFX_L3_CLKSTCTRL 0x44E00904 00040002 CM_GFX_GFX_CLKCTRL 0x44E0090c 00000002 CM_GFX_L4LS_GFX_CLKSTCTR 0x44E00910 00030000 CM_GFX_MMUCFG_CLKCTRL 0x44E00914 00030000 CM_GFX_MMUDATA_CLKCTRL 0x44E0052c 00000000 CM_DPLL.CLKSEL_GFX_FCLK 0x44E01100 00060047 PM_GFX_PWRSTCTRL 0x44E01104 00000000 RM_GFX_RSTCTRL 0x44E01110 00000037 PM_GFX_PWRSTST 0x5600fe14 00000000 SGX_CORE_VERSION 0x5600fe00 40000000 OCP_REVISION 0x5600fe04 00000005 OCP_HWINFO 0x5600fe10 00000028 OCP_SYSCONFIG 0x5600fe24 00000000 OCP_IRQSTATUS_RA_0 0x5600fe28 00000000 OCP_IRQSTATUS_RA_1 0x5600fe2c 00000000 OCP_IRQSTATUS_RA_2 0x5600fe30 00000000 OCP_IRQSTATUS_0 0x5600fe34 00000000 OCP_IRQSTATUS_1 0x5600fe38 00000000 OCP_IRQSTATUS_2 0x5600fe3c 00000000 OCP_IRQENABLE_SET_0 0x5600fe40 00000000 OCP_IRQENABLE_SET_1 0x5600fe44 00000000 OCP_IRQENABLE_SET_2 0x5600fe48 00000000 OCP_IRQENABLE_CLR_0 0x5600fe4c 00000000 OCP_IRQENABLE_CLR_1 0x5600fe50 00000000 OCP_IRQENABLE_CLR_2 0x5600ff00 00000014 OCP_PAGE_CONFIG 0x5600ff04 00000000 OCP_INTERRUPT_EVENT 0x5600ff08 00000000 OCP_DEBUG_CONFIG 0x5600ff0c 023fe407 OCP_DEBUG_STATUS 0x56000010 01120000 SGX_CORE_VERSION 0x56000014 00010205 SGX_CORE_REVISION root@letux:~# root@letux:~# modprobe pvrsrvkm_omap_am335x_sgx530_125 [ 282.569941] pvrsrvkm_omap_am335x_sgx530_125: module is from the staging directory, the quality is unknown, you have been warned. [ 282.673908] [drm] Initialized pvr 1.14.3699939 20110701 for 56000000.sgx on minor 1 root@letux:~#
The 0112 of SGX_CORE_VERSION is sgx530 and 010205 is revision -125 as expected.
Starting pvr still reports that the ukernel can not be loaded, but that is somewhere in the pvrsrvkm code that my driver only likes the omap5+sgx544 at the moment.
Latest v5.4-rc2 code is here: [1]
Thanks and BR, Nikolaus
[1]: https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/letux-pvr
Hi,
Am 05.10.2019 um 18:58 schrieb H. Nikolaus Schaller hns@goldelico.com:
So I have several ideas what the reasons for the problems on the non-omap5 devices could be:
- initial code may have some omap5 specific hack inside
- or has omap5 specific magic constants
- uKernel may "know" on which platform it runs and
we would need differently patched user-space code for each one
- omap5 has a dual core sgx544 while the other
have single core
- the register address translation is not yet correct and
this inhibits communicating of the user-space libs with the uKernel
Maybe, if someone can point me to a complete and working BeagleBone source tree (any kernel release) which makes use of 1.14.3699939 SDK, I could compare code and address setup to find what makes the difference.
I have found the following description, followed all steps, and it works:
http://blog.0xpebbles.org/PowerVR-SGX-on-the-beaglebone-black-in-2019
So with this, I have got a working user-space setup for BeagleBone and some working pvrsrvkm.ko module (kernel 4.4.155-ti-r155) for evaluation.
Symbols of the kernel module are not stripped, so that I can indirectly compare some build/configure options.
root@arm:~# uname -a Linux arm 4.4.155-ti-r155 #1 SMP Thu May 23 06:00:18 UTC 2019 armv7l GNU/Linux root@arm:~# ls -l /lib/modules/4.4.155-ti-r155/extra/ti335x/pvrsrvkm.ko -rw-r--r-- 1 root root 408084 May 23 06:46 /lib/modules/4.4.155-ti-r155/extra/ti335x/pvrsrvkm.ko root@arm:~# dmesg|fgrep -i pvr [ 24.589384] pvrsrvkm: loading out-of-tree module taints kernel. [ 25.051602] [drm] Initialized pvr 1.14.3699939 20110701 on minor 1 root@arm:~# sudo /usr/bin/pvrsrvctl --start --no-module root@arm:~# cat /proc/pvr/version Version SGX_DDK sgxddk MAIN@3699939 (release) omap_linux System Version String: SGX revision = 125 root@arm:~#
For comparison, I have:
root@letux:~# uname -a Linux letux 5.4.0-rc2-letux+ #1161 SMP PREEMPT Wed Oct 9 19:05:21 CEST 2019 armv7l GNU/Linux root@letux:~# ls -l /lib/modules/5.4.0-rc2-letux+/kernel/drivers/staging/pvr/1.14.3699939/eurasia_km/pvrsrvkm_omap_am335x_sgx530_125.ko -rw-r--r-- 1 1002 root 4751504 Oct 9 17:09 /lib/modules/5.4.0-rc2-letux+/kernel/drivers/staging/pvr/1.14.3699939/eurasia_km/pvrsrvkm_omap_am335x_sgx530_125.ko root@letux:~# dmesg|fgrep -i pvr [ 119.376338] pvrsrvkm_omap_am335x_sgx530_125: module is from the staging directory, the quality is unknown, you have been warned. [ 119.478943] [drm] Initialized pvr 1.14.3699939 20110701 for 56000000.sgx on minor 1 root@letux:~# /usr/bin/pvrsrvctl --start --no-module [ 238.178801] PVR_K: UM DDK-(3699939) and KM DDK-(3699939) match. [ OK ] PVR:(Error): LoaduKernelProgram : SGX ukernel program Device Addr: 0xe400000 invalid alignment PVR:(Error): SetupuKernel : Failed to load uKernel program PVR:(Error): SrvInit: Initialisation for device of class 0, type 7, index 0, failed (1) [0, ] [ 238.667915] PVR_K:(Error): BridgedDispatchKM: Initialisation failed. Driver unusable. PVR:(Error): PVRSRVBridgeCall: Failed to access device. Function ID:3223086862 (strerror returns no value.). [0, ] /usr/bin/pvrsrvctl: SrvInit failed (already initialized?) (err=PVRSRV_ERROR_OUT_OF_MEMORY - Unable to allocate required memory) root@letux:~#
First observations: * pvrsrvkm.ko is a little smaller (may be a result of compiler and build options) * both taint the kernel, as expected * they are exactly the same DDK release 1.14.3699939 * my version is a little more verbose * but fails loading the uKernel
What I don't have yet is the full source code or build recipe for the specific 4.4.155-ti-r155 pvrsrvkm.ko from TI.
But even without having this yet, I can start experiments by replacing kernel and pvrsrvkm.ko with mine. This should allow to gain new insights.
BR, Nikolaus
Am 12.10.2019 um 15:09 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
Am 05.10.2019 um 18:58 schrieb H. Nikolaus Schaller hns@goldelico.com:
I have found the following description, followed all steps, and it works:
http://blog.0xpebbles.org/PowerVR-SGX-on-the-beaglebone-black-in-2019
So with this, I have got a working user-space setup for BeagleBone and some working pvrsrvkm.ko module (kernel 4.4.155-ti-r155) for evaluation.
What I don't have yet is the full source code or build recipe for the specific 4.4.155-ti-r155 pvrsrvkm.ko from TI.
But even without having this yet, I can start experiments by replacing kernel and pvrsrvkm.ko with mine. This should allow to gain new insights.
Good news:
after making a Hybrid SD image of the setup described above and replacing the 4.4.155-ti-r155 kernel with its pvrsrvkm.ko by my own 5.4-rc2 kernel and pvrsrvkm, I was able to start the pvrsrv uKernel. And run the gles1test1 on beaglebone (without LCD but also without errors).
With this knowledge I could adapt my user-space. There are indeed different non-free binaries for sgx530, sgx540, sgx544. And SGX needs enough coherent memory. So I could make a completely self-built kernel and rootfs (using the git clone from ti for the firmware + make install) run on BeagleBone.
Here is a quickly taken video:
With the same setup, I can now also load the kernel driver and run pvrsrvctl on DM3730 without errors, but the gles1test1 reports some error and fails to run. Maybe something in the video subsystem or memory mapping is still wrong.
Unfortunately, the same setup does not run on omap5. It looks like there are different releases for the non-free binaries and I have to pick the right one.
On BBB the version I could make running is branch ti-img-sgx/1.14.3699939_k4.4 from git://git.ti.com/graphics/omap5-sgx-ddk-um-linux.git. Target ti335x works while target jacinto6evm fails for OMAP5. A diff on the binaries for e.g. pvrsrvctl shows that they are different.
If you want to repeat this setup and my instructions are too imprecise, please ask.
So in summary this means: * the common foundation (clock, reset, power etc.) setup is working - thanks to Tero, Tony and others * I have added device tree nodes for each SoC type to define sgx registers, interrupts, compatible etc. * compiling SoC specific kernel module variants from single source tree works * the work can already be demoed on BBB and OMAP5 Pyra (using different user-space binaries)
Basically I am now ready to post an RFC for the sgx child device nodes together with a bindings document [1]. But I am not sure if I should better wait until really all underlaying prm+rtsctl+syscon+idlest-polling patches by Tero and Tony [2] have matured in linux-next and have arrived in v5.5-rc1. Would be short before Xmas.
Independent of low level patches, we all have to discuss how we want to get the GPLed kernel driver [3] into mainline drivers/staging. This likely needs more cleanup before it can be proposed.
BR, Nikolaus
[1]: https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux/omap-p... [2]: https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux/omap-s... [3]: https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux/latest...
* H. Nikolaus Schaller hns@goldelico.com [191014 09:12]:
Am 12.10.2019 um 15:09 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
Am 05.10.2019 um 18:58 schrieb H. Nikolaus Schaller hns@goldelico.com:
I have found the following description, followed all steps, and it works:
http://blog.0xpebbles.org/PowerVR-SGX-on-the-beaglebone-black-in-2019
So with this, I have got a working user-space setup for BeagleBone and some working pvrsrvkm.ko module (kernel 4.4.155-ti-r155) for evaluation.
What I don't have yet is the full source code or build recipe for the specific 4.4.155-ti-r155 pvrsrvkm.ko from TI.
But even without having this yet, I can start experiments by replacing kernel and pvrsrvkm.ko with mine. This should allow to gain new insights.
Good news:
after making a Hybrid SD image of the setup described above and replacing the 4.4.155-ti-r155 kernel with its pvrsrvkm.ko by my own 5.4-rc2 kernel and pvrsrvkm, I was able to start the pvrsrv uKernel. And run the gles1test1 on beaglebone (without LCD but also without errors).
With this knowledge I could adapt my user-space. There are indeed different non-free binaries for sgx530, sgx540, sgx544. And SGX needs enough coherent memory. So I could make a completely self-built kernel and rootfs (using the git clone from ti for the firmware + make install) run on BeagleBone.
Here is a quickly taken video:
Nice :)
With the same setup, I can now also load the kernel driver and run pvrsrvctl on DM3730 without errors, but the gles1test1 reports some error and fails to run. Maybe something in the video subsystem or memory mapping is still wrong.
Unfortunately, the same setup does not run on omap5. It looks like there are different releases for the non-free binaries and I have to pick the right one.
On BBB the version I could make running is branch ti-img-sgx/1.14.3699939_k4.4 from git://git.ti.com/graphics/omap5-sgx-ddk-um-linux.git. Target ti335x works while target jacinto6evm fails for OMAP5. A diff on the binaries for e.g. pvrsrvctl shows that they are different.
If you want to repeat this setup and my instructions are too imprecise, please ask.
So in summary this means:
- the common foundation (clock, reset, power etc.) setup is working - thanks to Tero, Tony and others
- I have added device tree nodes for each SoC type to define sgx registers, interrupts, compatible etc.
- compiling SoC specific kernel module variants from single source tree works
- the work can already be demoed on BBB and OMAP5 Pyra (using different user-space binaries)
Basically I am now ready to post an RFC for the sgx child device nodes together with a bindings document [1]. But I am not sure if I should better wait until really all underlaying prm+rtsctl+syscon+idlest-polling patches by Tero and Tony [2] have matured in linux-next and have arrived in v5.5-rc1. Would be short before Xmas.
I think you've already proven that we can have a generic binding for the sgx using standard properties :) So AFAIK, there's nothing stopping you from posting the binding and dts changes for review for v5.5.
Independent of low level patches, we all have to discuss how we want to get the GPLed kernel driver [3] into mainline drivers/staging. This likely needs more cleanup before it can be proposed.
You probably need a shell script using sed or something to get rid of the crazy directory path for the kernel driver :) Just make it something like:
drivers/staging/pvr
Then if you have a script doing the directory path conversion, you can still convert and diff against any other prv branches you may find.
And you can get rid of all the LINUX_VERSION_CODE stuff too for the mainline kernel.
Regards,
Tony
On 13.02.19 08:25, H. Nikolaus Schaller wrote:
Hi Pawel,
Am 13.02.2019 um 08:14 schrieb Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com mailto:pawel.mikolaj.chmiel@gmail.com>:
Hi all, thanks for adding my to this topic. I'm using Power SGX540 on my Samsung s5pv210 based device (Samsung Galaxy S - i9000 phone - i've added support for it to mainline).
Great!
Do anyone has it (sgx540) working on mainline (5.0) kernel? Currently i've forward ported old driver, written by google (https://android.googlesource.com/kernel/samsung/+/android-samsung-3.0-jb-mr0...) to 5.0 kernel.
Unfortunately no. I have not invested time into SGX540 (although there is code in my tree). Iworked on omap3/amm335x.
I'm able to to gpu init (run pvrsrvinit), but when trying to run some sample code i'm getting 0 available egl configurations. I think i've fixed problems with framebuffer setup (by making framebuffer big like it was on old kernel - so it will allocate one framebuffer and 2 backbuffers in my case).
Yes, that is almost the same state as I have for omap3. I can run pvrsrvinit but it does not find framebuffers. Because it tries to use omaplfb which is not DRM compatible. So I would have to rewrite that first.
After enabling debug code in driver i'm currently getting followin logs https://gist.github.com/PabloPL/c1e98f405e67d577afcf51c36228efdc (BTW it's android binaries running on ubuntu on that s5pv210 device).
So it turns out that we have several initiatives by individuals that did start at different versions of the DDK&Linux-Glue and adjusted it to different SGX versions and some specific SoCs.
What I would propose then is that we check if the DDK 1.14 is really the latest existing one, install it in some common git repo and have us all work on this common basis to redo the integration we have done on our individual trees.
Just can agree on this. Let's use the latest available driver.
And someone rebases this DDK every week to the latest linus/master. This also reveals API changes we need to track in the glue code.
So we definitively need some common git to synchronize efforts. My proposal would still be kernel.org/drivers/staging http://kernel.org/drivers/staging/pvr, because it would be eliminate the need to rebase every week...
I would not do a weekly rebase. I think after -rc1 or after a stable relase would be better.
But what would be other options?
BR, Nikolaus
śr., 13 lut 2019 o 07:36 H. Nikolaus Schaller <hns@goldelico.com mailto:hns@goldelico.com> napisał(a):
Hi Tony, > Am 13.02.2019 um 01:41 schrieb Tony Lindgren <tony@atomide.com <mailto:tony@atomide.com>>: > > Hi, > > * Philipp Rossak <embed3d@gmail.com <mailto:embed3d@gmail.com>> [190212 22:25]: >> I'm looking now into that PVR SGX driver since a while. I already reworked >> that old "opensource" driver to work with a quite new kernel (4.16 or 4.17) >> [But that code got lost]. >> For the sunxi devices this was only a short coding session to get that >> running. For OMAP this might be easier/faster since the general linux >> situation is better. > > So a git repo that works for omaps and sunxi would be a good > start then :) > >> I'm not sure if we are able to provide a generic driver since there are >> different userspace versions that are only compatible with their own kernel >> driver. Not all compile flags for the kernel driver work with all userspace >> lib versions, at least on sunxi. Be aware that there are also different >> versions of those GPU ip cores and all have different features and bug >> fixes. > > No doubt it's a mess.. I'm only suggesting a generic driver that > manages standard Linux resources like regulators, clocks and > interrupts and provides 2d acceleration for sgx540 based on what > we already have at drivers/gpu/drm/gma500/accel_2d.c. The idea > being that it might then also make dealing with the rest of the > sgx blobs a bit easier hopefully. Well, ok. So you suggest that we e.g. take the omap SoC support in http://git.goldelico.com/?p=letux-kernel.git;a=tree;f=drivers/staging/pvr/1.14.3699939/eurasia_km/services4/system/omap;h=09ff9c9112dd7e8f7316ba5f1e022dcb824c2ce4;hb=1d5b6a91eca80168c37ecb66157e675d28666652 and make an "eurasia_km / services4 / system / generic" out of it using the 2d functions? Please take a look into especially sysconfig.c and SysInitialise() which does the lion's share of initialization if it can be rewritten to become generic. > >> If you reach a good state with that driver, I can try to port that to sunxi. >> Is there any good/cheap OMAP4/5 Devboard you can recommend? > > Hmm so the n900 folks have the sgx blobs working with recent > mainline kernels for sgx530 I believe, and Nikolaus is close to > having the sgx blobs working for sgx540. Also for sgx530 with recent kernel. The blobs itself are working, it is just missing code to tell the SGX module where the framebuffer is located in virtual memory.I think setting CONFIG_DRM_FBDEV_OVERALLOC=700 in my case (like old kernel) this will make powervr driver allocate one framebuffer + 2 backbuffers and CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM it should make it working. On my device i had to use different "fix" https://github.com/PabloPL/linux/commit/d0b1df4067a724aa0b38d11c82fd3ff0958a... The physical address of fb is used in driver (and passed to userspace?). It's code is here for my device https://github.com/PabloPL/linux/blob/powervr/drivers/gpu/drm/powervr/s3c_lc... And here is simple devicetree entry which is read by driver (it was added by person which is also working on mainlining my device). https://github.com/PabloPL/linux/blob/powervr/arch/arm/boot/dts/s5pv210-arie...
But this still didn't allowed me to run egl code with that driver. Probably i'll need to get logs from old kernel.
All my code is currently (if someone is interested ) in https://github.com/PabloPL/linux/tree/powervr
> I may not be aware of > the current status though. > > For a devboard with sgx540, you should be able to find one for > few tens of units for a used pandaboard-es for example or > somebody here might even have an old one to donate. If you feel > like playing with a phone, droid 4 xt894 is somewhat usable > with mainline kernels with pending patches for LCD and modem, > no idea what the sgx540 status on it might be. Pyra handheld > is not yet available except for prototypes. And then on > beagleboard-x15 there's sgx544, and beaglebone has sgx530 > FYI so that might not help if you need sgx540. > >> Don't expect any support from TI or IMG. TI can't support a project like >> this, since they don't own the code and IMG is not willing to support. > > Yeah that we've seen already over past 10 or so years :) > >> An other big issue is the leaked SGX source code [1]. So I think it would be >> better to start a clean room reverse engineering project. I'm already >> working on that. > > OK so we're discussing at least three projects then: > > 1. A git repo that allows sgx blobs to work for various > SoCs with current mainline kernels Yes. > > 2. A generic 2d sgx540 driver based on existing mainline > kernel drivers/gpu/drm/gma500/accel_2d.c May be needed or not. > > 3. Your reverse engineering project that might help > with figuring out how things are supposed to work IMHO a completely separate project. Basically there is a strict layering: L4 user-space libraries L3 SGX firmware L2 SGX firmware loader L1 SoC glue (clock, reset, dma, virtual memory, ...) I am mainly considering L1 here and fixing L2. L1 is SoC specific of course and L2 needs Linux-release specific patches. L2-L4 depend on SGX version. L2 contains a lot of #ifdef that depend on SGX530/540/544 and even more. Reverse engineering addresses L3 and L4. Of course if will be is successful it might become possible to improve the whole L1-L4 stack, but that is another 10 years in the future :) Since it is such a big task, I would propose to start with something close to working (some TI/IMG DDK) and improve on that instead of starting with parts from scratch. BR, Nikolaus
Am 13.02.2019 um 21:03 schrieb Philipp Rossak embed3d@gmail.com:
On 13.02.19 08:25, H. Nikolaus Schaller wrote:
Hi Pawel,
Am 13.02.2019 um 08:14 schrieb Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com mailto:pawel.mikolaj.chmiel@gmail.com>:
Hi all, thanks for adding my to this topic. I'm using Power SGX540 on my Samsung s5pv210 based device (Samsung Galaxy S - i9000 phone - i've added support for it to mainline).
Great!
Do anyone has it (sgx540) working on mainline (5.0) kernel? Currently i've forward ported old driver, written by google (https://android.googlesource.com/kernel/samsung/+/android-samsung-3.0-jb-mr0...) to 5.0 kernel.
Unfortunately no. I have not invested time into SGX540 (although there is code in my tree). Iworked on omap3/amm335x.
I'm able to to gpu init (run pvrsrvinit), but when trying to run some sample code i'm getting 0 available egl configurations. I think i've fixed problems with framebuffer setup (by making framebuffer big like it was on old kernel - so it will allocate one framebuffer and 2 backbuffers in my case).
Yes, that is almost the same state as I have for omap3. I can run pvrsrvinit but it does not find framebuffers. Because it tries to use omaplfb which is not DRM compatible. So I would have to rewrite that first.
After enabling debug code in driver i'm currently getting followin logs https://gist.github.com/PabloPL/c1e98f405e67d577afcf51c36228efdc (BTW it's android binaries running on ubuntu on that s5pv210 device).
So it turns out that we have several initiatives by individuals that did start at different versions of the DDK&Linux-Glue and adjusted it to different SGX versions and some specific SoCs. What I would propose then is that we check if the DDK 1.14 is really the latest existing one, install it in some common git repo and have us all work on this common basis to redo the integration we have done on our individual trees.
Just can agree on this. Let's use the latest available driver.
And someone rebases this DDK every week to the latest linus/master. This also reveals API changes we need to track in the glue code. So we definitively need some common git to synchronize efforts. My proposal would still be kernel.org/drivers/staging http://kernel.org/drivers/staging/pvr, because it would be eliminate the need to rebase every week...
I would not do a weekly rebase. I think after -rc1 or after a stable relase would be better.
Yes, I have checked and changes have been required only by major releases in -rc1 or -rc2 by e.g. dropping a parameter of access_ok().
But what would be other options? BR, Nikolaus
śr., 13 lut 2019 o 07:36 H. Nikolaus Schaller <hns@goldelico.com mailto:hns@goldelico.com> napisał(a):
Hi Tony,
Am 13.02.2019 um 01:41 schrieb Tony Lindgren <tony@atomide.com
Hi,
- Philipp Rossak <embed3d@gmail.com mailto:embed3d@gmail.com>
[190212 22:25]:
I'm looking now into that PVR SGX driver since a while. I
already reworked
that old "opensource" driver to work with a quite new kernel
(4.16 or 4.17)
[But that code got lost]. For the sunxi devices this was only a short coding session to
get that
running. For OMAP this might be easier/faster since the general
linux
situation is better.
So a git repo that works for omaps and sunxi would be a good start then :)
I'm not sure if we are able to provide a generic driver since
there are
different userspace versions that are only compatible with
their own kernel
driver. Not all compile flags for the kernel driver work with
all userspace
lib versions, at least on sunxi. Be aware that there are also
different
versions of those GPU ip cores and all have different features
and bug
fixes.
No doubt it's a mess.. I'm only suggesting a generic driver that manages standard Linux resources like regulators, clocks and interrupts and provides 2d acceleration for sgx540 based on what we already have at drivers/gpu/drm/gma500/accel_2d.c. The idea being that it might then also make dealing with the rest of the sgx blobs a bit easier hopefully.
Well, ok.
So you suggest that we e.g. take the omap SoC support in
http://git.goldelico.com/?p=letux-kernel.git;a=tree;f=drivers/staging/pvr/1....
and make an "eurasia_km / services4 / system / generic" out of it using the 2d functions?
Please take a look into especially sysconfig.c and SysInitialise() which does the lion's share of initialization if it can be rewritten to become generic.
If you reach a good state with that driver, I can try to port
that to sunxi.
Is there any good/cheap OMAP4/5 Devboard you can recommend?
Hmm so the n900 folks have the sgx blobs working with recent mainline kernels for sgx530 I believe, and Nikolaus is close to having the sgx blobs working for sgx540.
Also for sgx530 with recent kernel. The blobs itself are working, it is just missing code to tell the SGX module where the framebuffer is located in virtual memory.
I think setting CONFIG_DRM_FBDEV_OVERALLOC=700 in my case (like old kernel) this will make powervr driver allocate one framebuffer + 2 backbuffers and CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM it should make it working. On my device i had to use different "fix" https://github.com/PabloPL/linux/commit/d0b1df4067a724aa0b38d11c82fd3ff0958a... The physical address of fb is used in driver (and passed to userspace?). It's code is here for my device https://github.com/PabloPL/linux/blob/powervr/drivers/gpu/drm/powervr/s3c_lc... And here is simple devicetree entry which is read by driver (it was added by person which is also working on mainlining my device). https://github.com/PabloPL/linux/blob/powervr/arch/arm/boot/dts/s5pv210-arie...
But this still didn't allowed me to run egl code with that driver. Probably i'll need to get logs from old kernel.
All my code is currently (if someone is interested ) in https://github.com/PabloPL/linux/tree/powervr
I may not be aware of the current status though.
For a devboard with sgx540, you should be able to find one for few tens of units for a used pandaboard-es for example or somebody here might even have an old one to donate. If you feel like playing with a phone, droid 4 xt894 is somewhat usable with mainline kernels with pending patches for LCD and modem, no idea what the sgx540 status on it might be. Pyra handheld is not yet available except for prototypes. And then on beagleboard-x15 there's sgx544, and beaglebone has sgx530 FYI so that might not help if you need sgx540.
Don't expect any support from TI or IMG. TI can't support a
project like
this, since they don't own the code and IMG is not willing to
support.
Yeah that we've seen already over past 10 or so years :)
An other big issue is the leaked SGX source code [1]. So I
think it would be
better to start a clean room reverse engineering project. I'm
already
working on that.
OK so we're discussing at least three projects then:
- A git repo that allows sgx blobs to work for various
SoCs with current mainline kernels
Yes.
- A generic 2d sgx540 driver based on existing mainline
kernel drivers/gpu/drm/gma500/accel_2d.c
May be needed or not.
- Your reverse engineering project that might help
with figuring out how things are supposed to work
IMHO a completely separate project.
Basically there is a strict layering:
L4 user-space libraries L3 SGX firmware L2 SGX firmware loader L1 SoC glue (clock, reset, dma, virtual memory, ...)
I am mainly considering L1 here and fixing L2. L1 is SoC specific of course and L2 needs Linux-release specific patches.
L2-L4 depend on SGX version.
L2 contains a lot of #ifdef that depend on SGX530/540/544 and even more.
Reverse engineering addresses L3 and L4.
Of course if will be is successful it might become possible to improve the whole L1-L4 stack, but that is another 10 years in the future :)
Since it is such a big task, I would propose to start with something close to working (some TI/IMG DDK) and improve on that instead of starting with parts from scratch.
BR, Nikolaus
* H. Nikolaus Schaller hns@goldelico.com [190213 06:36]:
Am 13.02.2019 um 01:41 schrieb Tony Lindgren tony@atomide.com: No doubt it's a mess.. I'm only suggesting a generic driver that manages standard Linux resources like regulators, clocks and interrupts and provides 2d acceleration for sgx540 based on what we already have at drivers/gpu/drm/gma500/accel_2d.c. The idea being that it might then also make dealing with the rest of the sgx blobs a bit easier hopefully.
Well, ok.
So you suggest that we e.g. take the omap SoC support in
http://git.goldelico.com/?p=letux-kernel.git;a=tree;f=drivers/staging/pvr/1....
and make an "eurasia_km / services4 / system / generic" out of it using the 2d functions?
So here's a copy of what I just suggested on the pyra mailing list thread for the device drivers needed for kernel:
1. SoC glue device (power, clocks, dma maybe) 2. SGX glue device for shared resources 3.1 2d accelerated driver 3.2 3d sgx blob driver
This is assuming the 2d and 3d parts are a separate device inside the sgx like you're saying.
Please take a look into especially sysconfig.c and SysInitialise() which does the lion's share of initialization if it can be rewritten to become generic.
OK yeah I have no idea about the sgx internals currently. But I can try to help with the SoC glue layer parts, how to organize the various device driver components, and the dts binding parts.
Regards,
Tony
- Your reverse engineering project that might help with figuring out how things are supposed to work
IMHO a completely separate project.
Basically there is a strict layering:
L4 user-space libraries L3 SGX firmware L2 SGX firmware loader L1 SoC glue (clock, reset, dma, virtual memory, ...)
I am mainly considering L1 here and fixing L2. L1 is SoC specific of course and L2 needs Linux-release specific patches.
L2-L4 depend on SGX version.
L2 contains a lot of #ifdef that depend on SGX530/540/544 and even more.
Reverse engineering addresses L3 and L4.
Of course if will be is successful it might become possible to improve the whole L1-L4 stack, but that is another 10 years in the future :)
Since it is such a big task, I would propose to start with something close to working (some TI/IMG DDK) and improve on that instead of starting with parts from scratch.
I just can agree on that . For good reverse engineering we need also a working reference system where we also can dump misc stuff, like it is done with lima.
BR, Nikolaus
Hi,
On 13/02/2019 01:41, Tony Lindgren wrote:
Hi,
- Philipp Rossak embed3d@gmail.com [190212 22:25]:
I'm looking now into that PVR SGX driver since a while. I already reworked that old "opensource" driver to work with a quite new kernel (4.16 or 4.17) [But that code got lost]. For the sunxi devices this was only a short coding session to get that running. For OMAP this might be easier/faster since the general linux situation is better.
So a git repo that works for omaps and sunxi would be a good start then :)
I'm not sure if we are able to provide a generic driver since there are different userspace versions that are only compatible with their own kernel driver. Not all compile flags for the kernel driver work with all userspace lib versions, at least on sunxi. Be aware that there are also different versions of those GPU ip cores and all have different features and bug fixes.
No doubt it's a mess.. I'm only suggesting a generic driver that manages standard Linux resources like regulators, clocks and interrupts and provides 2d acceleration for sgx540 based on what we already have at drivers/gpu/drm/gma500/accel_2d.c. The idea being that it might then also make dealing with the rest of the sgx blobs a bit easier hopefully.
If you reach a good state with that driver, I can try to port that to sunxi. Is there any good/cheap OMAP4/5 Devboard you can recommend?
Hmm so the n900 folks have the sgx blobs working with recent mainline kernels for sgx530 I believe, and Nikolaus is close to having the sgx blobs working for sgx540. I may not be aware of the current status though.
Right, we have OpenGL ES 2.0 working with an older driver.
For a devboard with sgx540, you should be able to find one for few tens of units for a used pandaboard-es for example or somebody here might even have an old one to donate. If you feel like playing with a phone, droid 4 xt894 is somewhat usable with mainline kernels with pending patches for LCD and modem, no idea what the sgx540 status on it might be. Pyra handheld is not yet available except for prototypes. And then on beagleboard-x15 there's sgx544, and beaglebone has sgx530 FYI so that might not help if you need sgx540.
Philip, I can offer to send a Droid4 your way if you're based in Europe. (If you're based in the US, it's probably cheaper to source one locally than to ship it -back- to the US). But I think the pandaboard ES should be a fine one too. (But I can recommend the droid4, it's fun)
- A git repo that allows sgx blobs to work for various SoCs with current mainline kernels
Given that I've at least personally struggled to make the 3D blobs work - at all- on devices, this is would be my first aim. Also, if we have various devices that are working with some older kernel (hopefully with the most recent blob, but at least some blob), we could see where the differences are and resolve them, rather than work towards a generic shared driver where no device works yet, and we don't quite yet know why it doesn't work.
Cheers, Merlijn
Am 12.02.2019 um 23:24 schrieb Philipp Rossak embed3d@gmail.com:
Hey all,
On 12.02.19 21:51, Tony Lindgren wrote:
Hi,
- H. Nikolaus Schaller hns@goldelico.com [190212 20:03]:
Am 11.02.2019 um 07:51 schrieb H. Nikolaus Schaller hns@goldelico.com: What would be the process to get something into staging? Who decides about staging generally? Should we just forward this discussion to Greg for comment?
One thing already got my attention: we need to prefix all commit messages with e.g. "staging: pvr: " so that they can be distinguished on LKML. I'll prepare that for the next version of our Letux tree.
After thinking about this a bit, I think a shared out-of-tree repo is the best place to start rather than try to stuff a pile of sgx and vendor specific hacks into staging. Currently we don't even know what all needs to be different for various SoCs for example. And for upstream merging, a minimal generic accelerated 2d sgx driver that works across several SoCs is probably the best place to start. This would make the clock and interrupt handling generic with just SoC specific glue layer. Regards, Tony
Thanks for adding me to that thread!
Welcome!
I'm looking now into that PVR SGX driver since a while. I already reworked that old "opensource" driver to work with a quite new kernel (4.16 or 4.17) [But that code got lost]. For the sunxi devices this was only a short coding session to get that running. For OMAP this might be easier/faster since the general linux situation is better.
I'm not sure if we are able to provide a generic driver since there are different userspace versions that are only compatible with their own kernel driver. Not all compile flags for the kernel driver work with all userspace lib versions, at least on sunxi. Be aware that there are also different versions of those GPU ip cores and all have different features and bug fixes.
Regarding that the DDK contains a lot of compile switches (#if for all bug fixes/errata). And different SoC and version glue are handled by code in different eurasia_km / services4 / system subdirectories.
If you reach a good state with that driver, I can try to port that to sunxi. Is there any good/cheap OMAP4/5 Devboard you can recommend?
Don't expect any support from TI or IMG. TI can't support a project like this, since they don't own the code and IMG is not willing to support.
An other big issue is the leaked SGX source code [1]. So I think it would be better to start a clean room reverse engineering project. I'm already working on that.
Yes, I remember that, but since it covers the user-space libs and firmware, we don't have to care about that for the kernel driver project. Aiming at a clean room implementation would be very useful of course.
BR, Nikolaus
Regards,
Philipp
Hi,
I'm looking now into that PVR SGX driver since a while. I already reworked that old "opensource" driver to work with a quite new kernel (4.16 or 4.17) [But that code got lost]. For the sunxi devices this was only a short coding session to get that running. For OMAP this might be easier/faster since the general linux situation is better.
I'm not sure if we are able to provide a generic driver since there are different userspace versions that are only compatible with their own kernel driver. Not all compile flags for the kernel driver work with all userspace lib versions, at least on sunxi. Be aware that there are also different versions of those GPU ip cores and all have different features and bug fixes.
Regarding that the DDK contains a lot of compile switches (#if for all bug fixes/errata). And different SoC and version glue are handled by code in different eurasia_km / services4 / system subdirectories.
Here are some hints which SGX versions and errata are supported by the TI/IMG kernel driver tree:
http://git.goldelico.com/?p=letux-kernel.git;a=blob;f=drivers/staging/pvr/om...
From that I see support of SGX520 SGX530 SGX531 SGX535 SGX540 SGX543 SGX544 SGX545 SGX554
Unfortunately this is handled by #ifdefs and therefore we can not (yet) build a single driver that fits al devices. Each one needs different CONFIG and emits a different binary kernel module.
But IMHO it could be possible to replace the #if defined(SGX540) by some dynamic call to check for the compatible value. And also refine enabling individual errata handlers like "#define FIX_HW_BRN_31671 /* workaround in uKernel */"
This will slow down code a little and make it grow, but would be more universal.
I have also checked the latest DDK. These errata just add more SGX versions (SGX5300), but the code structure is the same.
But his is some idea for future work. We need to really lay the common foundation first by agreeing how to work together.
BTW: what about a specific mailing list? There was one installed by FSF and there was a Wiki but they are dead now
https://libreplanet.org/wiki/Group:PowerVR_drivers
Fortunately we have the wayback machine: https://web.archive.org/web/20170923050320/http://powervr.gnu.org.ve/doku.ph...
BR, Nikolaus
Am 12.02.2019 um 21:51 schrieb Tony Lindgren tony@atomide.com:
Hi,
- H. Nikolaus Schaller hns@goldelico.com [190212 20:03]:
Am 11.02.2019 um 07:51 schrieb H. Nikolaus Schaller hns@goldelico.com: What would be the process to get something into staging? Who decides about staging generally? Should we just forward this discussion to Greg for comment?
One thing already got my attention: we need to prefix all commit messages with e.g. "staging: pvr: " so that they can be distinguished on LKML. I'll prepare that for the next version of our Letux tree.
After thinking about this a bit, I think a shared out-of-tree repo is the best place to start rather than try to stuff a pile of sgx and vendor specific hacks into staging.
Well, all drivers are vendor specific... And the driver is already GPL2 code. And it is not that badly structured as it initially looks.
But It would be ok for me for a shared out-of-tree repo.
Currently we don't even know what all needs to be different for various SoCs for example.
Well, the latest IMG DDK already has different wrappers for several SoC. They are to be found in
http://git.goldelico.com/?p=letux-kernel.git;a=tree;f=drivers/staging/pvr/1....
This also shows what is needed to change for different SoC.
And for upstream merging, a minimal generic accelerated 2d sgx driver that works across several SoCs is probably the best place to start.
Well, I have no need or experience with the 2D drivers at all so that I can not contribute to that.
This would make the clock and interrupt handling generic with just SoC specific glue layer.
The question is if it is easy or possible to stack the 3d code on top of that.
* H. Nikolaus Schaller hns@goldelico.com [190213 05:56]:
Am 12.02.2019 um 21:51 schrieb Tony Lindgren tony@atomide.com: This would make the clock and interrupt handling generic with just SoC specific glue layer.
The question is if it is easy or possible to stack the 3d code on top of that.
Yeah OK sounds like the 2d and 3d parts are separate and need a sgx core driver for the shared resources.
Regards,
Tony
On 13.02.19 15:46, Tony Lindgren wrote:
- H. Nikolaus Schaller hns@goldelico.com [190213 05:56]:
Am 12.02.2019 um 21:51 schrieb Tony Lindgren tony@atomide.com: This would make the clock and interrupt handling generic with just SoC specific glue layer.
The question is if it is easy or possible to stack the 3d code on top of that.
Yeah OK sounds like the 2d and 3d parts are separate and need a sgx core driver for the shared resources.
Regards,
Tony
From reverse engineering I know that those are two separate HW-Cores but that are not on all available. On some SGX version this is done by the 3d core.
Regards, Philipp
* Philipp Rossak embed3d@gmail.com [190213 20:25]:
On 13.02.19 15:46, Tony Lindgren wrote:
- H. Nikolaus Schaller hns@goldelico.com [190213 05:56]:
Am 12.02.2019 um 21:51 schrieb Tony Lindgren tony@atomide.com: This would make the clock and interrupt handling generic with just SoC specific glue layer.
The question is if it is easy or possible to stack the 3d code on top of that.
Yeah OK sounds like the 2d and 3d parts are separate and need a sgx core driver for the shared resources.
From reverse engineering I know that those are two separate HW-Cores but that are not on all available. On some SGX version this is done by the 3d core.
OK thanks. Hmm so is there some easy way to compare your docs of sgx registers against what we have already in mainline kernel file for drivers/gpu/drm/gma500/psb_reg.h?
Regards,
Tony
Hi,
Adding Philip to Cc too as the sunxi folks too are interested in getting sgx usable with mainline kernels.
* Merlijn Wajer merlijn@wizzup.org [190210 16:12]:
Hi,
On 23/01/2018 14:38, H. Nikolaus Schaller wrote:
Hi all, based on initial work by Moaz Korena [1] and with the help of Adam Ford and Tony Lindgren, I have worked for a while on a new SGX driver for OMAP.
Now, I finally managed to write a master-Makefile that allows to build multiple variants of the sgx driver without having to config the build for a specific single SoC and forces us to choose the SGX version at compile time. This allows to build MULTI_PLATFORM kernels.
This means we currently get three different kernel modules: /lib/modules/4.15.0-rc9-letux+/kernel/drivers/staging/pvr/omap3/pvr_omap3630_sgx530_125.ko /lib/modules/4.15.0-rc9-letux+/kernel/drivers/staging/pvr/omap3/pvr_omap3_sgx530_121.ko /lib/modules/4.15.0-rc9-letux+/kernel/drivers/staging/pvr/omap3/pvr_ti335x_sgx530_125.ko
They are for:
- DM3730 based devices (e.g. Torpedo DM3730, BeagleBoard XM, GTA04, Pandora 1GHz)
- OMAP3530 based device (e.g. OpenPandora 600MHz, BeagleBoard C)
- AM335x based devices (e.g. BeagleBone, PocketBeagle)
Regardless of if and how this could be upstreamed, is there a more recent version of this work? I think there is tremendous value in having a combined repo (and combined effort) to get PowerVR to work on top of mainline (even though it might never be merged into mainline).
I have a couple of devices that I'd like to try getting PowerVR to work on. We (Maemo Leste) have it working on the Nokia N900 (forward port of nemo mobile kernel+userspace), but X11 works with acceleration, although some issues remain.
But I would also like to try to get it to work on the Motorola Droid 4 (also omap). And Pawel (in CC) has exynos devices with PowerVR, and he's also trying to get something to work [1] [2]. I also have a Pandaboard ES specifically for this purpose.
Ideally we'd use drm+modesetting drivers with dri3wsegl [3], but I have yet to try to make that work. :)
And just to add some notes I've already mentioned before, there's nothing stopping us from having a generic mainline kernel module for slow 2d acceleration based on what we already have for sgx540 in drivers/gpu/drm/gma500/psb_drv.c.
If anybody is interested in that, grep for PSB_RSGX32 and PSB_WSGX32 in the mainline kernel tree. That way at least the generic parts for regulators, clocking, and interrupt handling could be upstreamed. I think only the SoC specific wrapper hardware is different, the SGX code should be generic.
Regards,
Tony
Cheers, Merlijn
[1] https://github.com/PabloPL/linux/wiki [2] https://github.com/PabloPL/linux/issues/18 [3] https://github.com/TexasInstruments/dri3wsegl
So in combination with proper DT entries the correct driver variant is automatically modprobed during boot. At least for OMAP3.
OMAP4+5 driver code is also included but not yet integrated/fixed.
The DM3730 and AM33xx versions work (up to a certain point I will describe below). OMAP3530 does not properly set up clocks and SoC interconnects.
For the AM335x there is a hack to keep clock running after deasserting reset, but for the OMAP3530 we still have to find the root of the trouble.
What is still missing is the framebuffer backend so the SGX is not told how to write to a display. Traditionally, there was omaplfb but it seems no longer be working. There is also some DRM stuff, but I wasn't able to compile and set it up so far.
So, running the SGX ClipBlit test succeeds until it fails with:
FAIL - PVRSRV_ERROR_NO_DC_DEVICES_FOUND(134)
The latest code is rebased on top of v4.15-rc9 and it suffices to configure for SGX and SGX_OMAP. It can be found here (or in the latest Letux release [2]):
https://github.com/goldelico/gta04-kernel/commits/work/letux-base/hns/gpu/om...
It consists of two groups of commits (separated by a MAINTAINERS patch):
fixes for SoC glue (e.g. clock, hw-mods, pdata-qirks, DT) to get the SGX initialized and access - most of them are already good enough for upstream review
source code for pvrsrvkm from TI GFX SDK (one version for omap3+4 and one for omap4+5) combined with patches and new Makefiles to get it compiled on v4.15
There are also two shell-script tools (Letux/root/sgxdump and Letux/root/gpu-demo) for user-space. They are useful for debugging. A compatible Debian package with the (closed source!) microkernel for SGX, libs and demos for OMAP3-ARMHF can be found here:
http://download.goldelico.com/letux-debian-rootfs/debian/dists/jessie/main/b...
What is the goal of this effort?
In the end we should have a single, generic SGX driver for all OMAP SoC variants sitting in mainline drivers/gpu/pvr. So the goal is to end the era of out-of tree SGX drivers for a significant portion of OMAP processors.
Maybe it could become a driver that even IMG and TI want to support by providing newer (and open source) user-space libraries and tools.
My personal goal so far was to make it a working demonstrator that can be used as a "good" reference for running "git bisect" to identify regressions introduced by future modifications.
What has to be done to polish the code beyond "seems to work"?
I see these topics (but there may be more):
- fix power and clock management weakness
- fix issues with omap3530 (e.g. OpenPandora)
- make code finally completely independent of SoC variant so that all differences are deduced from device tree and a single kernel module serves them all
- get rid of -DSGX530 #ifdef etc.
- remove #if LINUX_VERSION_CODE (unless someone sees need to backport to stable)
- fix backend (omaplfb and/or omapdrm)
- make it work on omap4 / omap5 and sgx540 / sgx544
- fix dmac flush etc. in services4/srvkm/env/linux/osfunc.c
- simplify code where possible
- clean up the code (e.g. replace camel-case function and variable names)
- merge drivers/subdirectories for omap3+4 and omap4+5
- move from drivers/staging/pvr to drivers/gpu/pcr
- support for non-OMAP SoC with PVR/SGX inside
This is far too much work for just a handful of people so a broader community should be involved.
What will be the next steps?
Tony suggested to publish this initial work on LKML and ask for integration into the staging tree. The rationale is that the code needs a lot of polishing and cleanup until it is something good for drivers/gpu. And collaboration on LKML and kernel.org becomes easier than having a private mailing list and git(hub) repo only.
Yes, that would be be a good step and now I think the package is ready to go.
And if someone could provide a fix for the FB/DRM setup it would also be a big step because we then can even demonstrate it by screen movies.
We also need to define maintainers who take care of changes and new patches (since I can't do that alone).
BR, Nikolaus
Hi Tony,
Am 11.02.2019 um 16:18 schrieb Tony Lindgren tony@atomide.com:
Hi,
Adding Philip to Cc too as the sunxi folks too are interested in getting sgx usable with mainline kernels.
- Merlijn Wajer merlijn@wizzup.org [190210 16:12]:
Hi,
On 23/01/2018 14:38, H. Nikolaus Schaller wrote:
Hi all, based on initial work by Moaz Korena [1] and with the help of Adam Ford and Tony Lindgren, I have worked for a while on a new SGX driver for OMAP.
Now, I finally managed to write a master-Makefile that allows to build multiple variants of the sgx driver without having to config the build for a specific single SoC and forces us to choose the SGX version at compile time. This allows to build MULTI_PLATFORM kernels.
This means we currently get three different kernel modules: /lib/modules/4.15.0-rc9-letux+/kernel/drivers/staging/pvr/omap3/pvr_omap3630_sgx530_125.ko /lib/modules/4.15.0-rc9-letux+/kernel/drivers/staging/pvr/omap3/pvr_omap3_sgx530_121.ko /lib/modules/4.15.0-rc9-letux+/kernel/drivers/staging/pvr/omap3/pvr_ti335x_sgx530_125.ko
They are for:
- DM3730 based devices (e.g. Torpedo DM3730, BeagleBoard XM, GTA04, Pandora 1GHz)
- OMAP3530 based device (e.g. OpenPandora 600MHz, BeagleBoard C)
- AM335x based devices (e.g. BeagleBone, PocketBeagle)
Regardless of if and how this could be upstreamed, is there a more recent version of this work? I think there is tremendous value in having a combined repo (and combined effort) to get PowerVR to work on top of mainline (even though it might never be merged into mainline).
I have a couple of devices that I'd like to try getting PowerVR to work on. We (Maemo Leste) have it working on the Nokia N900 (forward port of nemo mobile kernel+userspace), but X11 works with acceleration, although some issues remain.
But I would also like to try to get it to work on the Motorola Droid 4 (also omap). And Pawel (in CC) has exynos devices with PowerVR, and he's also trying to get something to work [1] [2]. I also have a Pandaboard ES specifically for this purpose.
Ideally we'd use drm+modesetting drivers with dri3wsegl [3], but I have yet to try to make that work. :)
And just to add some notes I've already mentioned before, there's nothing stopping us from having a generic mainline kernel module for slow 2d acceleration based on what we already have for sgx540 in drivers/gpu/drm/gma500/psb_drv.c.
If anybody is interested in that, grep for PSB_RSGX32 and PSB_WSGX32 in the mainline kernel tree. That way at least the generic parts for regulators, clocking, and interrupt handling could be upstreamed. I think only the SoC specific wrapper hardware is different, the SGX code should be generic.
Interesting. But to me it seems to be completely orthogonal to the SGX DDK. And since it is an Intel GMA, there is probably much different clock and register integration into an Intel processor than for OMAP or other SoC.
BR, Nikolaus
Regards,
Tony
Cheers, Merlijn
[1] https://github.com/PabloPL/linux/wiki [2] https://github.com/PabloPL/linux/issues/18 [3] https://github.com/TexasInstruments/dri3wsegl
So in combination with proper DT entries the correct driver variant is automatically modprobed during boot. At least for OMAP3.
OMAP4+5 driver code is also included but not yet integrated/fixed.
The DM3730 and AM33xx versions work (up to a certain point I will describe below). OMAP3530 does not properly set up clocks and SoC interconnects.
For the AM335x there is a hack to keep clock running after deasserting reset, but for the OMAP3530 we still have to find the root of the trouble.
What is still missing is the framebuffer backend so the SGX is not told how to write to a display. Traditionally, there was omaplfb but it seems no longer be working. There is also some DRM stuff, but I wasn't able to compile and set it up so far.
So, running the SGX ClipBlit test succeeds until it fails with:
FAIL - PVRSRV_ERROR_NO_DC_DEVICES_FOUND(134)
The latest code is rebased on top of v4.15-rc9 and it suffices to configure for SGX and SGX_OMAP. It can be found here (or in the latest Letux release [2]):
https://github.com/goldelico/gta04-kernel/commits/work/letux-base/hns/gpu/om...
It consists of two groups of commits (separated by a MAINTAINERS patch):
- fixes for SoC glue (e.g. clock, hw-mods, pdata-qirks, DT) to get the SGX initialized
and access - most of them are already good enough for upstream review
- source code for pvrsrvkm from TI GFX SDK (one version for omap3+4 and one for omap4+5)
combined with patches and new Makefiles to get it compiled on v4.15
There are also two shell-script tools (Letux/root/sgxdump and Letux/root/gpu-demo) for user-space. They are useful for debugging. A compatible Debian package with the (closed source!) microkernel for SGX, libs and demos for OMAP3-ARMHF can be found here:
http://download.goldelico.com/letux-debian-rootfs/debian/dists/jessie/main/b...
What is the goal of this effort?
In the end we should have a single, generic SGX driver for all OMAP SoC variants sitting in mainline drivers/gpu/pvr. So the goal is to end the era of out-of tree SGX drivers for a significant portion of OMAP processors.
Maybe it could become a driver that even IMG and TI want to support by providing newer (and open source) user-space libraries and tools.
My personal goal so far was to make it a working demonstrator that can be used as a "good" reference for running "git bisect" to identify regressions introduced by future modifications.
What has to be done to polish the code beyond "seems to work"?
I see these topics (but there may be more):
- fix power and clock management weakness
- fix issues with omap3530 (e.g. OpenPandora)
- make code finally completely independent of SoC variant so that all differences
are deduced from device tree and a single kernel module serves them all
- get rid of -DSGX530 #ifdef etc.
- remove #if LINUX_VERSION_CODE (unless someone sees need to backport to stable)
- fix backend (omaplfb and/or omapdrm)
- make it work on omap4 / omap5 and sgx540 / sgx544
- fix dmac flush etc. in services4/srvkm/env/linux/osfunc.c
- simplify code where possible
- clean up the code (e.g. replace camel-case function and variable names)
- merge drivers/subdirectories for omap3+4 and omap4+5
- move from drivers/staging/pvr to drivers/gpu/pcr
- support for non-OMAP SoC with PVR/SGX inside
This is far too much work for just a handful of people so a broader community should be involved.
What will be the next steps?
Tony suggested to publish this initial work on LKML and ask for integration into the staging tree. The rationale is that the code needs a lot of polishing and cleanup until it is something good for drivers/gpu. And collaboration on LKML and kernel.org becomes easier than having a private mailing list and git(hub) repo only.
Yes, that would be be a good step and now I think the package is ready to go.
And if someone could provide a fix for the FB/DRM setup it would also be a big step because we then can even demonstrate it by screen movies.
We also need to define maintainers who take care of changes and new patches (since I can't do that alone).
BR, Nikolaus
* H. Nikolaus Schaller hns@goldelico.com [190212 20:00]:
Am 11.02.2019 um 16:18 schrieb Tony Lindgren tony@atomide.com: And just to add some notes I've already mentioned before, there's nothing stopping us from having a generic mainline kernel module for slow 2d acceleration based on what we already have for sgx540 in drivers/gpu/drm/gma500/psb_drv.c.
If anybody is interested in that, grep for PSB_RSGX32 and PSB_WSGX32 in the mainline kernel tree. That way at least the generic parts for regulators, clocking, and interrupt handling could be upstreamed. I think only the SoC specific wrapper hardware is different, the SGX code should be generic.
Interesting. But to me it seems to be completely orthogonal to the SGX DDK. And since it is an Intel GMA, there is probably much different clock and register integration into an Intel processor than for OMAP or other SoC.
To me it seems just the wrapper IP is different. If you look at drivers/gpu/drm/gma500/accel_2d.c it seems to be only accessing the sgx registers based on a quick glance. So it's already quite generic.
Also there's the rule of thumb requirement Tomi mentioned earlier. That is the driver must provide actual hardware acceleration and not just a way of enabling out-of-tree binary blobs if I recall.
So from that point of view a generic sgx 2d acceleration driver to drivers/gpu is probably a better place to start upstreaming rather than try to stuff vendor specific hacks on top of imagination hacks into drivers staging :)
Sure it won't help with the 3d parts except we then have the clocks and interrupts etc handled in a generic way. And then the 3d parts in theory should become generic too and with much less of a diffstat..
Regards,
Tony
Am 12.02.2019 um 21:18 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [190212 20:00]:
Am 11.02.2019 um 16:18 schrieb Tony Lindgren tony@atomide.com: And just to add some notes I've already mentioned before, there's nothing stopping us from having a generic mainline kernel module for slow 2d acceleration based on what we already have for sgx540 in drivers/gpu/drm/gma500/psb_drv.c.
If anybody is interested in that, grep for PSB_RSGX32 and PSB_WSGX32 in the mainline kernel tree. That way at least the generic parts for regulators, clocking, and interrupt handling could be upstreamed. I think only the SoC specific wrapper hardware is different, the SGX code should be generic.
Interesting. But to me it seems to be completely orthogonal to the SGX DDK. And since it is an Intel GMA, there is probably much different clock and register integration into an Intel processor than for OMAP or other SoC.
To me it seems just the wrapper IP is different. If you look at drivers/gpu/drm/gma500/accel_2d.c it seems to be only accessing the sgx registers based on a quick glance. So it's already quite generic.
Hm. I have looked into it and it did not remain me of any bit of the 3D driver.
The 3D driver does not directly or obviously handle SGX registers. It provides a wrapper around Linux API into some generic calls doing dma setup, enabling clock, doing reset (not of SGX registers but making the specific SoC toggle the internal Reset line going to the SGX module).
Also there's the rule of thumb requirement Tomi mentioned earlier. That is the driver must provide actual hardware acceleration and not just a way of enabling out-of-tree binary blobs if I recall.
So I think we are talking about two drivers and projects...
So from that point of view a generic sgx 2d acceleration driver to drivers/gpu is probably a better place to start upstreaming rather than try to stuff vendor specific hacks on top of imagination hacks into drivers staging :)
Sure it won't help with the 3d parts except we then have the clocks and interrupts etc handled in a generic way.
That is what I do not yet see. Especially since there is no code for 2d for other SoC than Intel. But there is working code for OMAP3 and others. Basically we need to provide some hw-mods, pdata-quirks, the missing DT nodes for clocks.
If I remember correctly that are ca. 10 already existing kernel APIs which are just incomplete.
The patch set I have to get what seems to be needed is:
e0df0c9972d2 HACK: ARM: OMAP2+: omap_hwmod.c: keep am33xx+sgx CM_GFX_L3_CLKSTCTRL and CM_GFX_GFX_CLKCTRL enabled after deassert_reset. be04c998efc2 Add sgx544 to omap5 device tree v2 2a7f3b0d186f ARM: dts: am43x: Add node for SGX 58c78f83dd91 ARM: DTS: OMAP3: add gfx node for omap34xx and omap36xx gpu c401c3019d36 ARM: DTS: AM33xx: adjust gfx node for am33xx gpu 649de88b27c4 ARM: DTS: AM335x: Add SGX DT node c295a42d06d4 Add sgx to omap54xx hwmod tables d96b2e3eb15c ARM: OMAP2+: omap_hwmod_3xxx_data.c: we do not need the module_offs and module_bit f3ef939270e5 ARM: OMAP2+: omap_hwmod_3xxx_data.c: add hwmods to make sgx working c0a1c4f34c6b ARM: OMAP2+: pdata-quirks: add SGX support for OMAP3 and am33xx 15bf4d5f066b ARM: OMAP2+: pdata-quirks: add assert_reset to gfx for completeness 92c282f7db7e ARM: OMAP3: Clock: Add IDLEST definitions for SGX fc59993666c3 ARM: OMAP2+: Use pdata-quirks for sgx deassert_hardreset
and they affect these files:
arch/arm/boot/dts/am33xx.dtsi arch/arm/boot/dts/am4372.dtsi arch/arm/boot/dts/omap3.dtsi arch/arm/boot/dts/omap36xx.dtsi arch/arm/boot/dts/omap5.dtsi arch/arm/mach-omap2/cm-regbits-34xx.h arch/arm/mach-omap2/omap_hwmod.c arch/arm/mach-omap2/omap_hwmod_3xxx_data.c arch/arm/mach-omap2/omap_hwmod_54xx_data.c arch/arm/mach-omap2/pdata-quirks.c include/linux/platform_data/sgx-omap.h
So rewriting everything to sit on a not yet existing 2d setup seems to be a very long deviation (for 3d) and I expect a nightmare for debugging and getting it work.
And then the 3d parts in theory should become generic too and with much less of a diffstat..
So my proposal is to keep 2d and 3d separated. And start to merge only after we have both working - and better understand the code.
BR, Nikolaus
* H. Nikolaus Schaller hns@goldelico.com [190213 05:50]:
Am 12.02.2019 um 21:18 schrieb Tony Lindgren tony@atomide.com: To me it seems just the wrapper IP is different. If you look at drivers/gpu/drm/gma500/accel_2d.c it seems to be only accessing the sgx registers based on a quick glance. So it's already quite generic.
Hm. I have looked into it and it did not remain me of any bit of the 3D driver.
Hmm.
The 3D driver does not directly or obviously handle SGX registers. It provides a wrapper around Linux API into some generic calls doing dma setup, enabling clock, doing reset (not of SGX registers but making the specific SoC toggle the internal Reset line going to the SGX module).
So maybe we need the following hierarchy for the kernel driver:
1. SoC glue device (power, clocks, dma maybe) 2. SGX glue device for shared resources 3.1 2d accelerated driver 3.2 3d sgx blob driver
Also there's the rule of thumb requirement Tomi mentioned earlier. That is the driver must provide actual hardware acceleration and not just a way of enabling out-of-tree binary blobs if I recall.
So I think we are talking about two drivers and projects...
Well yeah :) We should concentrate first on parts #1, #2 and try to get a generic kernel driver into mergeable shape for various SoCs, right?
That is while keeping part #3.2 working.. But for merging stuff into the mainline kernel, it seems we should have parts #1, #2, and #3.1 working.
So from that point of view a generic sgx 2d acceleration driver to drivers/gpu is probably a better place to start upstreaming rather than try to stuff vendor specific hacks on top of imagination hacks into drivers staging :)
Sure it won't help with the 3d parts except we then have the clocks and interrupts etc handled in a generic way.
That is what I do not yet see. Especially since there is no code for 2d for other SoC than Intel. But there is working code for OMAP3 and others. Basically we need to provide some hw-mods, pdata-quirks, the missing DT nodes for clocks.
Right part #3.1 is missing :)
If I remember correctly that are ca. 10 already existing kernel APIs which are just incomplete.
The patch set I have to get what seems to be needed is:
e0df0c9972d2 HACK: ARM: OMAP2+: omap_hwmod.c: keep am33xx+sgx CM_GFX_L3_CLKSTCTRL and CM_GFX_GFX_CLKCTRL enabled after deassert_reset. be04c998efc2 Add sgx544 to omap5 device tree v2 2a7f3b0d186f ARM: dts: am43x: Add node for SGX 58c78f83dd91 ARM: DTS: OMAP3: add gfx node for omap34xx and omap36xx gpu c401c3019d36 ARM: DTS: AM33xx: adjust gfx node for am33xx gpu 649de88b27c4 ARM: DTS: AM335x: Add SGX DT node c295a42d06d4 Add sgx to omap54xx hwmod tables d96b2e3eb15c ARM: OMAP2+: omap_hwmod_3xxx_data.c: we do not need the module_offs and module_bit f3ef939270e5 ARM: OMAP2+: omap_hwmod_3xxx_data.c: add hwmods to make sgx working c0a1c4f34c6b ARM: OMAP2+: pdata-quirks: add SGX support for OMAP3 and am33xx 15bf4d5f066b ARM: OMAP2+: pdata-quirks: add assert_reset to gfx for completeness 92c282f7db7e ARM: OMAP3: Clock: Add IDLEST definitions for SGX fc59993666c3 ARM: OMAP2+: Use pdata-quirks for sgx deassert_hardreset
and they affect these files:
arch/arm/boot/dts/am33xx.dtsi arch/arm/boot/dts/am4372.dtsi arch/arm/boot/dts/omap3.dtsi arch/arm/boot/dts/omap36xx.dtsi arch/arm/boot/dts/omap5.dtsi arch/arm/mach-omap2/cm-regbits-34xx.h arch/arm/mach-omap2/omap_hwmod.c arch/arm/mach-omap2/omap_hwmod_3xxx_data.c arch/arm/mach-omap2/omap_hwmod_54xx_data.c arch/arm/mach-omap2/pdata-quirks.c include/linux/platform_data/sgx-omap.h
OK so that's part #1 SoC glue layer, this we can merge separately for sure. There is still a hwmod and padata-quirks dependency because of the reset driver parts missing and clockdomain autoidle blocking missing. But that can be changed later and will not affect the sgx driver parts.
Maybe you should start posting those SoC glue layer parts for review after v5.1-rc1?
So rewriting everything to sit on a not yet existing 2d setup seems to be a very long deviation (for 3d) and I expect a nightmare for debugging and getting it work.
Well let's try to keep things working :)
And then the 3d parts in theory should become generic too and with much less of a diffstat..
So my proposal is to keep 2d and 3d separated. And start to merge only after we have both working - and better understand the code.
OK sure. If the 2d parts are separate from the sgx core driver it makes sense.
Regards,
Tony
Hi,
Am 13.02.2019 um 15:35 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [190213 05:50]:
Am 12.02.2019 um 21:18 schrieb Tony Lindgren tony@atomide.com: To me it seems just the wrapper IP is different. If you look at drivers/gpu/drm/gma500/accel_2d.c it seems to be only accessing the sgx registers based on a quick glance. So it's already quite generic.
Hm. I have looked into it and it did not remain me of any bit of the 3D driver.
Hmm.
The 3D driver does not directly or obviously handle SGX registers. It provides a wrapper around Linux API into some generic calls doing dma setup, enabling clock, doing reset (not of SGX registers but making the specific SoC toggle the internal Reset line going to the SGX module).
So maybe we need the following hierarchy for the kernel driver:
- SoC glue device (power, clocks, dma maybe) 2. SGX glue device for shared resources 3.1 2d accelerated driver 3.2 3d sgx blob driver
Well, yes, but I am not sure if 2d and 3d have anything in common or need the same basis.
If we just take out #3.1 for the moment we have
#1 patches for arch/arm #2 the linux wrapper of the IMG/TI code in srvkm/env/linux and system/$DEVICE #3.2 the IMG driver core everything else in srvkm
Also there's the rule of thumb requirement Tomi mentioned earlier. That is the driver must provide actual hardware acceleration and not just a way of enabling out-of-tree binary blobs if I recall.
So I think we are talking about two drivers and projects...
Well yeah :) We should concentrate first on parts #1, #2 and try to get a generic kernel driver into mergeable shape for various SoCs, right?
I'd keep #2 and #3.2 together because they are compiled into a single driver.ko.
That is while keeping part #3.2 working.. But for merging stuff into the mainline kernel, it seems we should have parts #1, #2, and #3.1 working.
#2 already exists for 3d provided by TI and IMG. And the DDK 1.14 code supports other platforms in system/$DEVICE
So from that point of view a generic sgx 2d acceleration driver to drivers/gpu is probably a better place to start upstreaming rather than try to stuff vendor specific hacks on top of imagination hacks into drivers staging :)
Sure it won't help with the 3d parts except we then have the clocks and interrupts etc handled in a generic way.
That is what I do not yet see. Especially since there is no code for 2d for other SoC than Intel. But there is working code for OMAP3 and others. Basically we need to provide some hw-mods, pdata-quirks, the missing DT nodes for clocks.
Right part #3.1 is missing :)
If I remember correctly that are ca. 10 already existing kernel APIs which are just incomplete.
The patch set I have to get what seems to be needed is:
e0df0c9972d2 HACK: ARM: OMAP2+: omap_hwmod.c: keep am33xx+sgx CM_GFX_L3_CLKSTCTRL and CM_GFX_GFX_CLKCTRL enabled after deassert_reset. be04c998efc2 Add sgx544 to omap5 device tree v2 2a7f3b0d186f ARM: dts: am43x: Add node for SGX 58c78f83dd91 ARM: DTS: OMAP3: add gfx node for omap34xx and omap36xx gpu c401c3019d36 ARM: DTS: AM33xx: adjust gfx node for am33xx gpu 649de88b27c4 ARM: DTS: AM335x: Add SGX DT node c295a42d06d4 Add sgx to omap54xx hwmod tables d96b2e3eb15c ARM: OMAP2+: omap_hwmod_3xxx_data.c: we do not need the module_offs and module_bit f3ef939270e5 ARM: OMAP2+: omap_hwmod_3xxx_data.c: add hwmods to make sgx working c0a1c4f34c6b ARM: OMAP2+: pdata-quirks: add SGX support for OMAP3 and am33xx 15bf4d5f066b ARM: OMAP2+: pdata-quirks: add assert_reset to gfx for completeness 92c282f7db7e ARM: OMAP3: Clock: Add IDLEST definitions for SGX fc59993666c3 ARM: OMAP2+: Use pdata-quirks for sgx deassert_hardreset
and they affect these files:
arch/arm/boot/dts/am33xx.dtsi arch/arm/boot/dts/am4372.dtsi arch/arm/boot/dts/omap3.dtsi arch/arm/boot/dts/omap36xx.dtsi arch/arm/boot/dts/omap5.dtsi arch/arm/mach-omap2/cm-regbits-34xx.h arch/arm/mach-omap2/omap_hwmod.c arch/arm/mach-omap2/omap_hwmod_3xxx_data.c arch/arm/mach-omap2/omap_hwmod_54xx_data.c arch/arm/mach-omap2/pdata-quirks.c include/linux/platform_data/sgx-omap.h
OK so that's part #1 SoC glue layer, this we can merge separately for sure. There is still a hwmod and padata-quirks dependency because of the reset driver parts missing and clockdomain autoidle blocking missing. But that can be changed later and will not affect the sgx driver parts.
Maybe you should start posting those SoC glue layer parts for review after v5.1-rc1?
Yes, good idea. At least for the omap3 specific things I can do this.
So rewriting everything to sit on a not yet existing 2d setup seems to be a very long deviation (for 3d) and I expect a nightmare for debugging and getting it work.
Well let's try to keep things working :)
And then the 3d parts in theory should become generic too and with much less of a diffstat..
So my proposal is to keep 2d and 3d separated. And start to merge only after we have both working - and better understand the code.
OK sure. If the 2d parts are separate from the sgx core driver it makes sense.
As far asI know they are separate things. Maybe there is some connection when trying to use both.
BR, Nikolaus
* H. Nikolaus Schaller hns@goldelico.com [190213 14:52]:
Am 13.02.2019 um 15:35 schrieb Tony Lindgren tony@atomide.com: So maybe we need the following hierarchy for the kernel driver:
- SoC glue device (power, clocks, dma maybe) 2. SGX glue device for shared resources 3.1 2d accelerated driver 3.2 3d sgx blob driver
Well, yes, but I am not sure if 2d and 3d have anything in common or need the same basis.
OK
If we just take out #3.1 for the moment we have
#1 patches for arch/arm #2 the linux wrapper of the IMG/TI code in srvkm/env/linux and system/$DEVICE #3.2 the IMG driver core everything else in srvkm
...
I'd keep #2 and #3.2 together because they are compiled into a single driver.ko.
OK let's see what makes most sense.
Regards,
Tony
Hi Tony,
Am 13.02.2019 um 16:08 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [190213 14:52]:
Am 13.02.2019 um 15:35 schrieb Tony Lindgren tony@atomide.com: So maybe we need the following hierarchy for the kernel driver:
- SoC glue device (power, clocks, dma maybe)
- SGX glue device for shared resources 3.1 2d accelerated driver 3.2 3d sgx blob driver
Well, yes, but I am not sure if 2d and 3d have anything in common or need the same basis.
OK
If we just take out #3.1 for the moment we have
#1 patches for arch/arm #2 the linux wrapper of the IMG/TI code in srvkm/env/linux and system/$DEVICE #3.2 the IMG driver core everything else in srvkm
...
I'd keep #2 and #3.2 together because they are compiled into a single driver.ko.
OK let's see what makes most sense.
Yes, we will need a lot of more discussions about optimal solutions.
Do you have suggestions for a dedicated mailing list? Or a common git repo to use?
As said, I'd prefer kernel.org/staging and linux-omap (because we seem to be the largest group) because it would make things simpler.
And there is another aspect which came to my mind just now.
Having a separate ML + GIT needs activities to draw attention of other developers while sitting on kernel.org would automatically make use of the existing Linux announcement channels. Some 5.x-rc1 would simply include it. ELIXIR will cross-reference it. Patchwork will archive discussions. LKML will present patches to all potential developers. So we would make use of the existing communication machinery besides a ML.
Having it separated needs also some HOWTO for integration and getting it compiled.
So I see a lot of benefits.
But this would need to get Greg into the boat or at least accept what we are doing and providing resources. You likely know him better than me. How should we contact him?
Just add him to cc: or forward this (or a new mail)?
BR and thanks, Nikolaus
* H. Nikolaus Schaller hns@goldelico.com [190213 15:22]:
Do you have suggestions for a dedicated mailing list?
How about something like open-pvrsgx-devel@vger.kernel.org? I think all you have to do is email the vger.kernel.org postmaster and explain what this list is about.
Or a common git repo to use?
How about initially set up somethign at gitlab/github as suggested by Paweł?
And then also get a kernel.org account and start setting up a proper open-pvrsgx-devel git branch at git.kernel.org eventually for the mainline kernel module(s)?
As said, I'd prefer kernel.org/staging and linux-omap (because we seem to be the largest group) because it would make things simpler.
Sure, I'm just saying we should wait a bit until we have code ready for staging to avoid churning the Linux kernel pointlessly initially.
And there is another aspect which came to my mind just now.
Having a separate ML + GIT needs activities to draw attention of other developers while sitting on kernel.org would automatically make use of the existing Linux announcement channels. Some 5.x-rc1 would simply include it. ELIXIR will cross-reference it. Patchwork will archive discussions. LKML will present patches to all potential developers. So we would make use of the existing communication machinery besides a ML.
Yeah there's nothing stopping you from getting a kernel.org account and setting up something like open-pvrsgx-devel git tree there to start with. As we've discussed, these are already GPL components for the kernel although unusable in their current form.
Having it separated needs also some HOWTO for integration and getting it compiled.
So I see a lot of benefits.
But this would need to get Greg into the boat or at least accept what we are doing and providing resources. You likely know him better than me. How should we contact him?
I think we should just wait on the staging part a bit until we have something usable. There will most likely be a lot of churn initially.
Regards,
Tony
śr., 13 lut 2019 o 16:51 Tony Lindgren tony@atomide.com napisał(a):
- H. Nikolaus Schaller hns@goldelico.com [190213 15:22]:
Do you have suggestions for a dedicated mailing list?
How about something like open-pvrsgx-devel@vger.kernel.org? I think all you have to do is email the vger.kernel.org postmaster and explain what this list is about.
Or a common git repo to use?
How about initially set up somethign at gitlab/github as suggested by Paweł?
And then also get a kernel.org account and start setting up a proper open-pvrsgx-devel git branch at git.kernel.org eventually for the mainline kernel module(s)?
As said, I'd prefer kernel.org/staging and linux-omap (because we seem to be the largest group) because it would make things simpler.
Sure, I'm just saying we should wait a bit until we have code ready for staging to avoid churning the Linux kernel pointlessly initially.
And there is another aspect which came to my mind just now.
Having a separate ML + GIT needs activities to draw attention of other developers while sitting on kernel.org would automatically make use of the existing Linux announcement channels. Some 5.x-rc1 would simply include it. ELIXIR will cross-reference it. Patchwork will archive discussions. LKML will present patches to all potential developers. So we would make use of the existing communication machinery besides a ML.
Yeah there's nothing stopping you from getting a kernel.org account and setting up something like open-pvrsgx-devel git tree there to start with. As we've discussed, these are already GPL components for the kernel although unusable in their current form.
Having it separated needs also some HOWTO for integration and getting it compiled.
So I see a lot of benefits.
But this would need to get Greg into the boat or at least accept what we are doing and providing resources. You likely know him better than me. How should we contact him?
I think we should just wait on the staging part a bit until we have something usable. There will most likely be a lot of churn initially.
I also agree to this. In my opinion, we should at first try to get something working (it doesn't matter where it will be, we can easly move code it later - just make sure all have access). Also someone mentioned about adding some prefix to all commits - we can do this later when we'll be preparing patches for submision (for example formatting them according to kernel rules, squashing so we could send them for example with few commits - don't need to send whole history of changes from repo). For now we would just need to signoff patches.
Regards,
Tony
Am 13.02.2019 um 16:58 schrieb Paweł Chmiel pawel.mikolaj.chmiel@gmail.com:
śr., 13 lut 2019 o 16:51 Tony Lindgren tony@atomide.com napisał(a):
- H. Nikolaus Schaller hns@goldelico.com [190213 15:22]:
Do you have suggestions for a dedicated mailing list?
How about something like open-pvrsgx-devel@vger.kernel.org? I think all you have to do is email the vger.kernel.org postmaster and explain what this list is about.
Or a common git repo to use?
How about initially set up somethign at gitlab/github as suggested by Paweł?
And then also get a kernel.org account and start setting up a proper open-pvrsgx-devel git branch at git.kernel.org eventually for the mainline kernel module(s)?
As said, I'd prefer kernel.org/staging and linux-omap (because we seem to be the largest group) because it would make things simpler.
Sure, I'm just saying we should wait a bit until we have code ready for staging to avoid churning the Linux kernel pointlessly initially.
And there is another aspect which came to my mind just now.
Having a separate ML + GIT needs activities to draw attention of other developers while sitting on kernel.org would automatically make use of the existing Linux announcement channels. Some 5.x-rc1 would simply include it. ELIXIR will cross-reference it. Patchwork will archive discussions. LKML will present patches to all potential developers. So we would make use of the existing communication machinery besides a ML.
Yeah there's nothing stopping you from getting a kernel.org account and setting up something like open-pvrsgx-devel git tree there to start with. As we've discussed, these are already GPL components for the kernel although unusable in their current form.
Having it separated needs also some HOWTO for integration and getting it compiled.
So I see a lot of benefits.
But this would need to get Greg into the boat or at least accept what we are doing and providing resources. You likely know him better than me. How should we contact him?
I think we should just wait on the staging part a bit until we have something usable. There will most likely be a lot of churn initially.
I also agree to this. In my opinion, we should at first try to get something working (it doesn't matter where it will be, we can easly move code it later - just make sure all have access). Also someone mentioned about adding some prefix to all commits - we can do this later when we'll be preparing patches for submision (for example formatting them according to kernel rules, squashing so we could send them for example with few commits - don't need to send whole history of changes from repo). For now we would just need to signoff patches.
Yes, good!
BR, Nikolaus
On 13.02.19 16:58, Paweł Chmiel wrote:
śr., 13 lut 2019 o 16:51 Tony Lindgren tony@atomide.com napisał(a):
- H. Nikolaus Schaller hns@goldelico.com [190213 15:22]:
Do you have suggestions for a dedicated mailing list?
How about something like open-pvrsgx-devel@vger.kernel.org? I think all you have to do is email the vger.kernel.org postmaster and explain what this list is about.
Or a common git repo to use?
How about initially set up somethign at gitlab/github as suggested by Paweł?
And then also get a kernel.org account and start setting up a proper open-pvrsgx-devel git branch at git.kernel.org eventually for the mainline kernel module(s)?
As said, I'd prefer kernel.org/staging and linux-omap (because we seem to be the largest group) because it would make things simpler.
Sure, I'm just saying we should wait a bit until we have code ready for staging to avoid churning the Linux kernel pointlessly initially.
And there is another aspect which came to my mind just now.
Having a separate ML + GIT needs activities to draw attention of other developers while sitting on kernel.org would automatically make use of the existing Linux announcement channels. Some 5.x-rc1 would simply include it. ELIXIR will cross-reference it. Patchwork will archive discussions. LKML will present patches to all potential developers. So we would make use of the existing communication machinery besides a ML.
Yeah there's nothing stopping you from getting a kernel.org account and setting up something like open-pvrsgx-devel git tree there to start with. As we've discussed, these are already GPL components for the kernel although unusable in their current form.
Having it separated needs also some HOWTO for integration and getting it compiled.
So I see a lot of benefits.
But this would need to get Greg into the boat or at least accept what we are doing and providing resources. You likely know him better than me. How should we contact him?
I think we should just wait on the staging part a bit until we have something usable. There will most likely be a lot of churn initially.
I also agree to this. In my opinion, we should at first try to get something working (it doesn't matter where it will be, we can easly move code it later - just make sure all have access). Also someone mentioned about adding some prefix to all commits - we can do this later when we'll be preparing patches for submision (for example formatting them according to kernel rules, squashing so we could send them for example with few commits - don't need to send whole history of changes from repo). For now we would just need to signoff patches.
I just can agree on that. I think a github repo/project/group might be a good starting point.
Philipp
Hi Tony,
Am 13.02.2019 um 16:51 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [190213 15:22]:
Do you have suggestions for a dedicated mailing list?
How about something like open-pvrsgx-devel@vger.kernel.org? I think all you have to do is email the vger.kernel.org postmaster and explain what this list is about.
Yes, looks good!
Or a common git repo to use?
How about initially set up somethign at gitlab/github as suggested by Paweł?
And then also get a kernel.org account and start setting up a proper open-pvrsgx-devel git branch at git.kernel.org eventually for the mainline kernel module(s)?
Ok, so have a sub-git there. Feels right.
As said, I'd prefer kernel.org/staging and linux-omap (because we seem to be the largest group) because it would make things simpler.
Sure, I'm just saying we should wait a bit until we have code ready for staging to avoid churning the Linux kernel pointlessly initially.
Yes that makes sense as well.
And there is another aspect which came to my mind just now.
Having a separate ML + GIT needs activities to draw attention of other developers while sitting on kernel.org would automatically make use of the existing Linux announcement channels. Some 5.x-rc1 would simply include it. ELIXIR will cross-reference it. Patchwork will archive discussions. LKML will present patches to all potential developers. So we would make use of the existing communication machinery besides a ML.
Yeah there's nothing stopping you from getting a kernel.org account and setting up something like open-pvrsgx-devel git tree there to start with.
Ok, I could easily push the current letux/omap-pvr and letux/latest-pvr branches there since they are already based on linus/master and therefore not tied to the Letux OS.
As we've discussed, these are already GPL components for the kernel although unusable in their current form.
This raises the question who wants to take the maintainer's head (at least initially)...
I am not sure if I want to do it because I already spend too much voluntary time on Linux :) So if someone else would like to take this role, I'd step back.
Having it separated needs also some HOWTO for integration and getting it compiled.
So I see a lot of benefits.
But this would need to get Greg into the boat or at least accept what we are doing and providing resources. You likely know him better than me. How should we contact him?
I think we should just wait on the staging part a bit until we have something usable. There will most likely be a lot of churn initially.
Ah, ok.
Sounds like a good strategy. Have ML and separate GIT hosted at kernel.org for visibilty.
And then if work matures and becomes useable, we clean up the working branches and contact Greg and whoever else for official inclusion in linux-next. Then, development can continue in official staging.
BR and thanks, Nikolaus
* H. Nikolaus Schaller hns@goldelico.com [190213 16:01]:
This raises the question who wants to take the maintainer's head (at least initially)...
I am not sure if I want to do it because I already spend too much voluntary time on Linux :) So if someone else would like to take this role, I'd step back.
Well maybe try a shared maintainership model with one or two other people who have already done some patches? It seems at Paweł and Philip are potential candidates to help and have their own repos already :)
I think the n900 folks have their own repo too but I don't know who is active with that. Merlijn?
So I suggest you discuss with people interested. Or discuss it on the mailing list and see who end up being active.
Regards,
Tony
Am 13.02.2019 um 18:34 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [190213 16:01]:
This raises the question who wants to take the maintainer's head (at least initially)...
I am not sure if I want to do it because I already spend too much voluntary time on Linux :) So if someone else would like to take this role, I'd step back.
Well maybe try a shared maintainership model with one or two other people who have already done some patches?
Yes would be good if it technically works. I have not found if and how access permission to the kernel.org repos is controlled so that multiple users have push access.
At least there must be a single owner named. Requirements for getting an account:
https://korg.wiki.kernel.org/userdoc/accounts
Since I am not registered as maintainer and have no good PGP network with kernel developers it is probably better if someone who already has a kernel.org account creates the repo.
It seems at Paweł and Philip are potential candidates to help and have their own repos already :)
I think the n900 folks have their own repo too but I don't know who is active with that. Merlijn?
So I suggest you discuss with people interested. Or discuss it on the mailing list and see who end up being active.
Yes, to bring this topic forward, I have mailed the postmaster@vger to get a mailing list first. Then someone should create the kernel.org repo. And finally we can start filling it with patches.
BR and thanks, Nikolaus
On 13.02.19 18:34, Tony Lindgren wrote:
- H. Nikolaus Schaller hns@goldelico.com [190213 16:01]:
This raises the question who wants to take the maintainer's head (at least initially)...
I am not sure if I want to do it because I already spend too much voluntary time on Linux :) So if someone else would like to take this role, I'd step back.
Well maybe try a shared maintainership model with one or two other people who have already done some patches? It seems at Paweł and Philip are potential candidates to help and have their own repos already :)
I can help here, but I can start on this earliest in 2 weeks or a month, when I have Internet in my new flat...
Regards, Philipp
śr., 13 lut 2019 o 22:00 Philipp Rossak embed3d@gmail.com napisał(a):
On 13.02.19 18:34, Tony Lindgren wrote:
- H. Nikolaus Schaller hns@goldelico.com [190213 16:01]:
This raises the question who wants to take the maintainer's head (at least initially)...
I am not sure if I want to do it because I already spend too much voluntary time on Linux :) So if someone else would like to take this role, I'd step back.
Well maybe try a shared maintainership model with one or two other people who have already done some patches? It seems at Paweł and Philip are potential candidates to help and have their own repos already :)
I can help here, but I can start on this earliest in 2 weeks or a month, when I have Internet in my new flat...
In my opinion we shouldn't have single maintainer but a group ("organization" on github/gitlab/etc), so every one can contribute (of course with PR/code review/etc.
Regards, Philipp
Am 13.02.2019 um 22:09 schrieb Paweł Chmiel pawel.mikolaj.chmiel@gmail.com:
śr., 13 lut 2019 o 22:00 Philipp Rossak embed3d@gmail.com napisał(a):
On 13.02.19 18:34, Tony Lindgren wrote:
- H. Nikolaus Schaller hns@goldelico.com [190213 16:01]:
This raises the question who wants to take the maintainer's head (at least initially)...
I am not sure if I want to do it because I already spend too much voluntary time on Linux :) So if someone else would like to take this role, I'd step back.
Well maybe try a shared maintainership model with one or two other people who have already done some patches? It seems at Paweł and Philip are potential candidates to help and have their own repos already :)
I can help here, but I can start on this earliest in 2 weeks or a month, when I have Internet in my new flat...
In my opinion we shouldn't have single maintainer but a group ("organization" on github/gitlab/etc), so every one can contribute (of course with PR/code review/etc.
Yes, that could be techically easier, but I'd prefer to have it on the kernel.org repos... Which will make moving it to mainline at least look easier...
BR, Nikolaus
* H. Nikolaus Schaller hns@goldelico.com [190213 21:30]:
Am 13.02.2019 um 22:09 schrieb Paweł Chmiel pawel.mikolaj.chmiel@gmail.com: In my opinion we shouldn't have single maintainer but a group ("organization" on github/gitlab/etc), so every one can contribute (of course with PR/code review/etc.
Yes, that could be techically easier, but I'd prefer to have it on the kernel.org repos... Which will make moving it to mainline at least look easier...
It's probaby easier to set up a gitlab/github repo first. For a kernel.org git tree all the users need to be registered for group access. That can be always set up a bit later as that will take a while.
Regards,
Tony
On 13.02.19 22:53, Tony Lindgren wrote:
- H. Nikolaus Schaller hns@goldelico.com [190213 21:30]:
Am 13.02.2019 um 22:09 schrieb Paweł Chmiel pawel.mikolaj.chmiel@gmail.com: In my opinion we shouldn't have single maintainer but a group ("organization" on github/gitlab/etc), so every one can contribute (of course with PR/code review/etc.
Yes, that could be techically easier, but I'd prefer to have it on the kernel.org repos... Which will make moving it to mainline at least look easier...
It's probaby easier to set up a gitlab/github repo first. For a kernel.org git tree all the users need to be registered for group access. That can be always set up a bit later as that will take a while.
Regards,
Tony
Then let's create a github organisation first and do the inital work there?
Any Ideas about naming (requried at least for github organisation) ? What about "OpenSGX Driver Group"?
I think we could use also the already existing #powervr IRC channel on Freenode.
Regards, Philipp
Am 13.02.2019 um 23:18 schrieb Philipp Rossak embed3d@gmail.com:
On 13.02.19 22:53, Tony Lindgren wrote:
- H. Nikolaus Schaller hns@goldelico.com [190213 21:30]:
Am 13.02.2019 um 22:09 schrieb Paweł Chmiel pawel.mikolaj.chmiel@gmail.com: In my opinion we shouldn't have single maintainer but a group ("organization" on github/gitlab/etc), so every one can contribute (of course with PR/code review/etc.
Yes, that could be techically easier, but I'd prefer to have it on the kernel.org repos... Which will make moving it to mainline at least look easier...
It's probaby easier to set up a gitlab/github repo first. For a kernel.org git tree all the users need to be registered for group access. That can be always set up a bit later as that will take a while. Regards, Tony
Then let's create a github organisation first and do the inital work there?
Yes, as a temporary solution certainly the easiest approach. Do you take it?
Any Ideas about naming (requried at least for github organisation) ? What about "OpenSGX Driver Group"?
Yes, sounds good to me. Only one slight doubt if we should focus on "OpenSGX Linux Driver Group", because that is the main target.
I think we could use also the already existing #powervr IRC channel on Freenode.
Regards, Philipp
BR and thanks, Nikolaus
On 14.02.19 09:31, H. Nikolaus Schaller wrote:
Am 13.02.2019 um 23:18 schrieb Philipp Rossak embed3d@gmail.com:
On 13.02.19 22:53, Tony Lindgren wrote:
- H. Nikolaus Schaller hns@goldelico.com [190213 21:30]:
Am 13.02.2019 um 22:09 schrieb Paweł Chmiel pawel.mikolaj.chmiel@gmail.com: In my opinion we shouldn't have single maintainer but a group ("organization" on github/gitlab/etc), so every one can contribute (of course with PR/code review/etc.
Yes, that could be techically easier, but I'd prefer to have it on the kernel.org repos... Which will make moving it to mainline at least look easier...
It's probaby easier to set up a gitlab/github repo first. For a kernel.org git tree all the users need to be registered for group access. That can be always set up a bit later as that will take a while. Regards, Tony
Then let's create a github organisation first and do the inital work there?
Yes, as a temporary solution certainly the easiest approach. Do you take it?
I created the organization [1]. I'm not sure if you can request to join. If that doesn't work I can add users manually so write me a private mail with your github user name and/or registered github e-mail address.
Any Ideas about naming (requried at least for github organisation) ? What about "OpenSGX Driver Group"?
Yes, sounds good to me. Only one slight doubt if we should focus on "OpenSGX Linux Driver Group", because that is the main target.
I set the displayed name to "OpenSGX Linux Driver Group" but that can be changed later, if necessary.
I think we could use also the already existing #powervr IRC channel on Freenode.
Regards, Philipp
BR and thanks, Nikolaus
Regards, Philipp
* Philipp Rossak embed3d@gmail.com [190214 10:18]:
I set the displayed name to "OpenSGX Linux Driver Group" but that can be changed later, if necessary.
You might want to change it to something more specific like "OpenPVRSGX Linux Driver Group" :)
There is already non-graphics related Intel SGX "opensgx": https://github.com/sslab-gatech/opensgx
Regards,
Tony
On 14.02.19 19:28, Tony Lindgren wrote:
- Philipp Rossak embed3d@gmail.com [190214 10:18]:
I set the displayed name to "OpenSGX Linux Driver Group" but that can be changed later, if necessary.
You might want to change it to something more specific like "OpenPVRSGX Linux Driver Group" :)
There is already non-graphics related Intel SGX "opensgx": https://github.com/sslab-gatech/opensgx
Regards,
Tony
Thanks Tony!
I changed it and I also renamed the oranzation. So there is now a new link: https://github.com/openpvrsgx-devgroup
Regards, Philipp
Hi Philipp,
Am 14.02.2019 um 19:55 schrieb Philipp Rossak embed3d@gmail.com:
On 14.02.19 19:28, Tony Lindgren wrote:
- Philipp Rossak embed3d@gmail.com [190214 10:18]:
I set the displayed name to "OpenSGX Linux Driver Group" but that can be changed later, if necessary.
You might want to change it to something more specific like "OpenPVRSGX Linux Driver Group" :) There is already non-graphics related Intel SGX "opensgx": https://github.com/sslab-gatech/opensgx Regards, Tony
Thanks Tony!
I changed it and I also renamed the oranzation. So there is now a new link: https://github.com/openpvrsgx-devgroup
Fine!
I have tried to get in, but there seems to be no "request to join" button or something. So I'll send you my github user name by PM. Or if you can send a invitation by e-mails, just copy the list from this mail?
Next, I had asked postmaster@vger.kernel.org to get a mailing list for us, but they declined with only stating "it is not appropriate" because it is for kernel related topics. I asked again that we work for the Linux kernel and want to get it into staging, but that is still not appropriate. No further details, so that I do not know what really would be appropriate. Does it need Linus' approval or must be decided on some core developer meeting? But that is just my guess.
Finally, I have tested our omap3 version and it works fine in v4.15. But is broken in v4.16.17 and beyond. This problem did not get noticed in our automatic tests because they test only for module loading and /dev/pvrsrvkm existence and not for pvrsrvctl --start success.
Now, I found one bug in my patch set that prevented running v4.17 and later because the code was not compatible with CONFIG_RESET_CONTROLLER=y (which we do have enabled since v4.17). After fixing this, it still returns an EFAULT in some ioctl() during firmware download.
But I could reduce it to be introduced between v4.16.13 to v4.16.15. I am currently doing a bisect so that seems not to be far away from finding the problematic commit.
BR, NIkolaus
pt., 15 lut 2019 o 10:06 H. Nikolaus Schaller hns@goldelico.com napisał(a):
Hi Philipp,
Am 14.02.2019 um 19:55 schrieb Philipp Rossak embed3d@gmail.com:
On 14.02.19 19:28, Tony Lindgren wrote:
- Philipp Rossak embed3d@gmail.com [190214 10:18]:
I set the displayed name to "OpenSGX Linux Driver Group" but that can be changed later, if necessary.
You might want to change it to something more specific like "OpenPVRSGX Linux Driver Group" :) There is already non-graphics related Intel SGX "opensgx": https://github.com/sslab-gatech/opensgx Regards, Tony
Thanks Tony!
I changed it and I also renamed the oranzation. So there is now a new link: https://github.com/openpvrsgx-devgroup
Only Two people in organization ? And is there anyone on irc ?
Fine!
I have tried to get in, but there seems to be no "request to join" button or something. So I'll send you my github user name by PM. Or if you can send a invitation by e-mails, just copy the list from this mail?
Next, I had asked postmaster@vger.kernel.org to get a mailing list for us, but they declined with only stating "it is not appropriate" because it is for kernel related topics. I asked again that we work for the Linux kernel and want to get it into staging, but that is still not appropriate. No further details, so that I do not know what really would be appropriate. Does it need Linus' approval or must be decided on some core developer meeting? But that is just my guess.
Finally, I have tested our omap3 version and it works fine in v4.15. But is broken in v4.16.17 and beyond. This problem did not get noticed in our automatic tests because they test only for module loading and /dev/pvrsrvkm existence and not for pvrsrvctl --start success.
Now, I found one bug in my patch set that prevented running v4.17 and later because the code was not compatible with CONFIG_RESET_CONTROLLER=y (which we do have enabled since v4.17). After fixing this, it still returns an EFAULT in some ioctl() during firmware download.
But I could reduce it to be introduced between v4.16.13 to v4.16.15. I am currently doing a bisect so that seems not to be far away from finding the problematic commit.
BR, NIkolaus
* Paweł Chmiel pawel.mikolaj.chmiel@gmail.com [190215 12:58]:
pt., 15 lut 2019 o 10:06 H. Nikolaus Schaller hns@goldelico.com napisał(a):
Am 14.02.2019 um 19:55 schrieb Philipp Rossak embed3d@gmail.com: I changed it and I also renamed the oranzation. So there is now a new link: https://github.com/openpvrsgx-devgroup
Only Two people in organization ? And is there anyone on irc ?
Hmm what's the irc channel again? It was mentioned but I can't find it in the thread right now..
Some info and links would be maybe step #1 for the github page? :)
Next, I had asked postmaster@vger.kernel.org to get a mailing list for us, but they declined with only stating "it is not appropriate" because it is for kernel related topics. I asked again that we work for the Linux kernel and want to get it into staging, but that is still not appropriate. No further details, so that I do not know what really would be appropriate. Does it need Linus' approval or must be decided on some core developer meeting? But that is just my guess.
Well probably that's because this is just a single device driver, not a Linux subsystem.
What about the existing list that was mentioned, maybe we can start using that one? Or set up a new list on freedesktop.org or on infradead.org?
Regards,
Tony
pt., 15 lut 2019 o 16:40 Tony Lindgren tony@atomide.com napisał(a):>> * Paweł Chmiel pawel.mikolaj.chmiel@gmail.com [190215 12:58]:> > pt., 15 lut 2019 o 10:06 H. Nikolaus Schaller hns@goldelico.com napisał(a):> > > > Am 14.02.2019 um 19:55 schrieb Philipp Rossak embed3d@gmail.com:> > > > I changed it and I also renamed the oranzation. So there is now a new link: https://github.com/openpvrsgx-devgroup%3E > Only Two people in organization ? And is there anyone on irc ?>> Hmm what's the irc channel again? It was mentioned but> I can't find it in the thread right now..I saw information that there is already #powervr channel on freenode irc
Some info and links would be maybe step #1 for the github page? :)
Is there a possibility to allow updating github pages/wiki only by PR (after code review) ? So we don't have situation where someone just puts there some confidential info/documentation (like that mentioned by libv on his blog). That links should be checked by someone not creating any code here (so we don't see it by "mistake").
Next, I had asked postmaster@vger.kernel.org to get a mailing list for us, but they declined with only stating "it is not appropriate" because it is for kernel related topics. I asked again that we work for the Linux kernel and want to get it into staging, but that is still not appropriate. No further details, so that I do not know what really would be appropriate. Does it need Linus' approval or must be decided on some core developer meeting? But that is just my guess.
Well probably that's because this is just a single device driver, not a Linux subsystem.
What about the existing list that was mentioned, maybe we can start using that one? Or set up a new list on freedesktop.org or on infradead.org?
Regards,
Tony
On 15.02.19 13:58, Paweł Chmiel wrote:
pt., 15 lut 2019 o 10:06 H. Nikolaus Schaller hns@goldelico.com napisał(a):
Hi Philipp,
Am 14.02.2019 um 19:55 schrieb Philipp Rossak embed3d@gmail.com:
On 14.02.19 19:28, Tony Lindgren wrote:
- Philipp Rossak embed3d@gmail.com [190214 10:18]:
I set the displayed name to "OpenSGX Linux Driver Group" but that can be changed later, if necessary.
You might want to change it to something more specific like "OpenPVRSGX Linux Driver Group" :) There is already non-graphics related Intel SGX "opensgx": https://github.com/sslab-gatech/opensgx Regards, Tony
Thanks Tony!
I changed it and I also renamed the oranzation. So there is now a new link: https://github.com/openpvrsgx-devgroup
Only Two people in organization ? And is there anyone on irc ?
Sorry I was busy the whole day. All current group members have admin rights. So feel free to add others.
Fine!
I have tried to get in, but there seems to be no "request to join" button or something. So I'll send you my github user name by PM. Or if you can send a invitation by e-mails, just copy the list from this mail?
Next, I had asked postmaster@vger.kernel.org to get a mailing list for us, but they declined with only stating "it is not appropriate" because it is for kernel related topics. I asked again that we work for the Linux kernel and want to get it into staging, but that is still not appropriate. No further details, so that I do not know what really would be appropriate. Does it need Linus' approval or must be decided on some core developer meeting? But that is just my guess.
Finally, I have tested our omap3 version and it works fine in v4.15. But is broken in v4.16.17 and beyond. This problem did not get noticed in our automatic tests because they test only for module loading and /dev/pvrsrvkm existence and not for pvrsrvctl --start success.
Now, I found one bug in my patch set that prevented running v4.17 and later because the code was not compatible with CONFIG_RESET_CONTROLLER=y (which we do have enabled since v4.17). After fixing this, it still returns an EFAULT in some ioctl() during firmware download.
But I could reduce it to be introduced between v4.16.13 to v4.16.15. I am currently doing a bisect so that seems not to be far away from finding the problematic commit.
BR, NIkolaus
Regards, Philipp
Hi Philipp,
Am 16.02.2019 um 00:45 schrieb Philipp Rossak embed3d@gmail.com:
On 15.02.19 13:58, Paweł Chmiel wrote:
pt., 15 lut 2019 o 10:06 H. Nikolaus Schaller hns@goldelico.com napisał(a):
Hi Philipp,
Am 14.02.2019 um 19:55 schrieb Philipp Rossak embed3d@gmail.com:
I changed it and I also renamed the oranzation. So there is now a new link: https://github.com/openpvrsgx-devgroup
Only Two people in organization ? And is there anyone on irc ?
Sorry I was busy the whole day. All current group members have admin rights. So feel free to add others.
No problem. We did wait for years for such an initiative arrive, so that a day or two doesn't matter...
I have a different technical problem. When I go to https://github.com/openpvrsgx-devgroup/linux_openpvrsgx it just says "This repository is empty.". No link to clone or how to git remote add so that I can't start to contribute. Maybe I am not yet set for "admin" rights.
Regarding the mailing list: there seems to be a quite new "linux-sgx" list on vger with just 18 members but no archive. But I found out that this is a different "SGX" = "Software Guard eXtensions (SGX)". Archive: https://www.spinics.net/lists/linux-sgx
So maybe someone with more reputation within kernel.org than I have should lobby for a mailing list for us again.
Or if linux-omap members agree, we could use linux-omap (at least initially) as some of us are already subscribed there.
BR and thanks, Nikolaus
On 17.02.19 11:40, H. Nikolaus Schaller wrote:
Hi Philipp,
Am 16.02.2019 um 00:45 schrieb Philipp Rossak embed3d@gmail.com:
On 15.02.19 13:58, Paweł Chmiel wrote:
pt., 15 lut 2019 o 10:06 H. Nikolaus Schaller hns@goldelico.com napisał(a):
Hi Philipp,
Am 14.02.2019 um 19:55 schrieb Philipp Rossak embed3d@gmail.com:
I changed it and I also renamed the oranzation. So there is now a new link: https://github.com/openpvrsgx-devgroup
Only Two people in organization ? And is there anyone on irc ?
Sorry I was busy the whole day. All current group members have admin rights. So feel free to add others.
No problem. We did wait for years for such an initiative arrive, so that a day or two doesn't matter...
I have a different technical problem. When I go to https://github.com/openpvrsgx-devgroup/linux_openpvrsgx it just says "This repository is empty.". No link to clone or how to git remote add so that I can't start to contribute. Maybe I am not yet set for "admin" rights.
I fixed that. There was an additional setting for the repos that had to be set. Now you all should have admin rights also for the repos.
Currently I'm pushing the latest linux on that repo (linux_openpvrsgx) so there should appear something in the next few hours. And we can start with the work.
Regarding the mailing list: there seems to be a quite new "linux-sgx" list on vger with just 18 members but no archive. But I found out that this is a different "SGX" = "Software Guard eXtensions (SGX)". Archive: https://www.spinics.net/lists/linux-sgx
So maybe someone with more reputation within kernel.org than I have should lobby for a mailing list for us again.
Or if linux-omap members agree, we could use linux-omap (at least initially) as some of us are already subscribed there.
BR and thanks, Nikolaus
Hi,
Am 17.02.2019 um 14:32 schrieb Philipp Rossak embed3d@gmail.com:
On 17.02.19 11:40, H. Nikolaus Schaller wrote:
Hi Philipp,
Am 16.02.2019 um 00:45 schrieb Philipp Rossak embed3d@gmail.com:
On 15.02.19 13:58, Paweł Chmiel wrote:
pt., 15 lut 2019 o 10:06 H. Nikolaus Schaller hns@goldelico.com napisał(a):
Hi Philipp,
Am 14.02.2019 um 19:55 schrieb Philipp Rossak embed3d@gmail.com:
I changed it and I also renamed the oranzation. So there is now a new link: https://github.com/openpvrsgx-devgroup
Only Two people in organization ? And is there anyone on irc ?
Sorry I was busy the whole day. All current group members have admin rights. So feel free to add others.
No problem. We did wait for years for such an initiative arrive, so that a day or two doesn't matter... I have a different technical problem. When I go to https://github.com/openpvrsgx-devgroup/linux_openpvrsgx it just says "This repository is empty.". No link to clone or how to git remote add so that I can't start to contribute. Maybe I am not yet set for "admin" rights.
I fixed that. There was an additional setting for the repos that had to be set. Now you all should have admin rights also for the repos.
Is working now!
Currently I'm pushing the latest linux on that repo (linux_openpvrsgx) so there should appear something in the next few hours. And we can start with the work.
I have pushed these four branches:
letux/latest-pvr ddk1.14.3699939 from TI/IMG moved to drivers/staging/pvr rebased on v5.0-rc7
letux/omap-pvr-soc-glue my patch set for omap3/am335x infrastructure (clocks, resets, hwmods, DT nodes) rebased on v5.0-rc7
letux/omap-pvr ddk1.9/10 from TI moved to drivers/staging/pvr adjusted to compile in-kernel and work together with omap-pvr-soc-glue
letux/omap-pvr-demo some demo scripts
My plan is to git mirror those as our Letux kernel work is going on.
Generally I see it as a reservoir of ideas and patches that can be cherry-picked into our new master branch.
For example, if we agree to start work on ddk1.14.3699939 we can merge this into master.
Regarding the mailing list: there seems to be a quite new "linux-sgx" list on vger with just 18 members but no archive. But I found out that this is a different "SGX" = "Software Guard eXtensions (SGX)". Archive: https://www.spinics.net/lists/linux-sgx So maybe someone with more reputation within kernel.org than I have should lobby for a mailing list for us again. Or if linux-omap members agree, we could use linux-omap (at least initially) as some of us are already subscribed there. BR and thanks, Nikolaus
BR and thanks, Nikolaus
Hi,
Am 18.02.2019 um 10:29 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
I have pushed these four branches:
letux/latest-pvr ddk1.14.3699939 from TI/IMG moved to drivers/staging/pvr rebased on v5.0-rc7
letux/omap-pvr-soc-glue my patch set for omap3/am335x infrastructure (clocks, resets, hwmods, DT nodes) rebased on v5.0-rc7
letux/omap-pvr ddk1.9/10 from TI moved to drivers/staging/pvr adjusted to compile in-kernel and work together with omap-pvr-soc-glue
letux/omap-pvr-demo some demo scripts
My plan is to git mirror those as our Letux kernel work is going on.
Generally I see it as a reservoir of ideas and patches that can be cherry-picked into our new master branch.
For example, if we agree to start work on ddk1.14.3699939 we can merge this into master.
I have cross-ported and generalised the in-kernel-makefile magic (to produce multiple kernel modules from single tree) into the /latest-pvr tree. And I have cross-ported the kernel API fixes for ~v4.10..v5.0 (TI did alreadymigrate to v4.9).
Now it compiles for all the omap variants (omap3,4,5). Sunxi is missing some asm header file and jz4780 is missing some uaccess_kernel() function in an asm header. Should not be too difficult to find replacements or API changes. Compile for Intel is not tested.
I have not done significant functional tests or debugging, just compile tests. But I already get this (on omap3!):
root@letux:~# modprobe -c | fgrep pvr alias of:N*T*Cti,omap_am335x_sgx530_125 pvr_omap_am335x_sgx530_125 alias of:N*T*Cti,omap_am335x_sgx530_125C* pvr_omap_am335x_sgx530_125 alias of:N*T*Cti,omap_am43xx_sgx544_112 pvr_omap_am43xx_sgx544_112 alias of:N*T*Cti,omap_am43xx_sgx544_112C* pvr_omap_am43xx_sgx544_112 alias of:N*T*Cti,omap_am57xx_sgx544_116 pvr_omap_am57xx_sgx544_116 alias of:N*T*Cti,omap_am57xx_sgx544_116C* pvr_omap_am57xx_sgx544_116 alias of:N*T*Cti,omap_omap3630_sgx530_125 pvr_omap_omap3630_sgx530_125 alias of:N*T*Cti,omap_omap3630_sgx530_125C* pvr_omap_omap3630_sgx530_125 alias of:N*T*Cti,omap_omap3_sgx530_121 pvr_omap_omap3_sgx530_121 alias of:N*T*Cti,omap_omap3_sgx530_121C* pvr_omap_omap3_sgx530_121 alias of:N*T*Cti,omap_omap4430_sgx540_120 pvr_omap_omap4430_sgx540_120 alias of:N*T*Cti,omap_omap4430_sgx540_120C* pvr_omap_omap4430_sgx540_120 alias of:N*T*Cti,omap_omap4460_sgx540_120 pvr_omap_omap4460_sgx540_120 alias of:N*T*Cti,omap_omap4460_sgx540_120C* pvr_omap_omap4460_sgx540_120 alias of:N*T*Cti,omap_omap4470_sgx544_112 pvr_omap_omap4470_sgx544_112 alias of:N*T*Cti,omap_omap4470_sgx544_112C* pvr_omap_omap4470_sgx544_112 alias of:N*T*Cti,omap_omap5_sgx544_116 pvr_omap_omap5_sgx544_116 alias of:N*T*Cti,omap_omap5_sgx544_116C* pvr_omap_omap5_sgx544_116 alias symbol:PVRGetBufferClassJTable pvr_omap_omap5_sgx544_116 alias symbol:PVRGetDisplayClassJTable pvr_omap_omap5_sgx544_116 root@letux:~# modprobe pvr_omap_omap3630_sgx530_125 [14375.354827] pvr_omap_omap3630_sgx530_125: module is from the staging directory, the quality is unknown, you have been warned.
^^^ should be done by a proper compatible = "ti,omap_omap3630_sgx530_125" in the DT
root@letux:~# ls -l /proc/pvr total 0 -r--r--r-- 1 root root 0 Feb 24 17:39 nodes -r--r--r-- 1 root root 0 Feb 24 17:39 queue -r--r--r-- 1 root root 0 Feb 24 17:39 version rroot@letux:~# cat /proc/pvr/version Version SGX_DDK sgxddk MAIN@3699939 (release) omap_sgx System Version String: None root@letux:~# pvrsrvctl --start --no-module pvrsrvctl: SrvInit failed (already initialized?) (err=4) root@letux:~#
So it doesn't look completely broken. At least it does not trigger kernel panics or warnings for missing clocks or reset controllers.
For trying this tree, please check out (you may have to merge in the branch letux/omap-pvr-soc-glue)
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux/latest...
BTW: there was a slightly newer 1.14.3759903 tree (we have 1.14.3699939) at https://elinux.org/CI20-SGX_kernel_module but the files are no longer accessible. And there were links to user-space binaries for the jz4780. Maybe we can find a copy and someone with jz4780 hardware willing to contribute here.
Regarding the mailing list, how do we proceed?
I think this is very important since it seems as recipients have been lost in some replies.
So far I see these options:
a) use linux-omap@vger.kernel.org b) try again to get a dedicated list at vger.kernel.org c) use a different host c1) use the letux-kernel@openphoenux.org c2) I can create a new list at openphoenux.org c3) different proposal
What are your preferences or suggestions?
BR, Nikolaus
Hi,
On 25/02/2019 14:12, H. Nikolaus Schaller wrote:
a) use linux-omap@vger.kernel.org b) try again to get a dedicated list at vger.kernel.org c) use a different host c1) use the letux-kernel@openphoenux.org c2) I can create a new list at openphoenux.org c3) different proposal
What are your preferences or suggestions?
In order of preference:
2. 3c2 1.
Cheers, Merlijn
On 25.02.19 14:12, H. Nikolaus Schaller wrote:
Now it compiles for all the omap variants (omap3,4,5). Sunxi is missing some asm header file and jz4780 is missing some uaccess_kernel() function in an asm header. Should not be too difficult to find replacements or API changes. Compile for Intel is not tested.
I will have a look on the sunxi issue in the next days.
Regards, Philipp
Hi Phillipp and all,
Am 25.02.2019 um 21:42 schrieb Philipp Rossak embed3d@gmail.com:
On 25.02.19 14:12, H. Nikolaus Schaller wrote:
Now it compiles for all the omap variants (omap3,4,5). Sunxi is missing some asm header file and jz4780 is missing some uaccess_kernel() function in an asm header. Should not be too difficult to find replacements or API changes. Compile for Intel is not tested.
I will have a look on the sunxi issue in the next days.
do you already have done some test and got findings/patches/suggestions? Or something where I could help?
I have some progress to get the DDK1.14 on v5.0 running on omap3/4/5.
The main issue so far was that I did not have matching "compatible" entries in the device tree so that probing the module did not succeed. And I had to port the CONFIG_RESET_CONTROLLER setup for omap.
But then it started working.
Here on omap5:
root@letux:~# ./gpu-demo autodetected driver package: omap5-sgx544-116 compatible driver: omap_omap5_sgx544_116 module name: pvr_omap_omap5_sgx544_116 pvrsrvctl: symbol lookup error: /usr/local/omap5-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender System Version String: None Running gles1test1 gles1test1: symbol lookup error: /usr/local/omap5-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender Running gles2test1 --------------------- started --------------------- gles2test1: symbol lookup error: /usr/local/omap5-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender Running eglinfo eglinfo: symbol lookup error: /usr/local/omap5-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender root@letux:~#
And on omap3:
root@letux:~# ./gpu-demo autodetected driver package: omap3630-sgx530-125 compatible driver: omap_omap3630_sgx530_125 module name: pvr_omap_omap3630_sgx530_125 pvrsrvctl: symbol lookup error: /usr/local/omap3-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender System Version String: None Running sgx_clipblit_test ----------------- SGX CLipBlit test ----------------- ---------------------- Start ------------------------ Call PVRSRVConnect with a valid argument: sgx_clipblit_test: symbol lookup error: /usr/local/omap3-pvrsgx/lib/libsrv_um.so: undefined symbol: drmOpenRender Running gles1test1 gles1test1: symbol lookup error: /usr/local/omap3-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender Running gles2test1 --------------------- started --------------------- gles2test1: symbol lookup error: /usr/local/omap3-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender Running eglinfo eglinfo: symbol lookup error: /usr/local/omap3-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender root@letux:~#
I am not sure where the user-space library problems come from. I think I have the correct DDK1.14 user space for omap from
git://git.ti.com/graphics/omap5-sgx-ddk-um-linux.git
but you never know:
http://e2e.ti.com/support/legacy_forums/embedded/linux/f/354/p/567306/208168...
But maybe it is simply because the -D flags of my in-kernel Makefile are not yet exactly correct.
My old DDK1.9 user space (the one with the sgx_clipblit_test) is still installed on the omap3 machine in parallel, but obviously it is fundamentally incompatible.
The reason is that the ioctl command codes e.g. PVRSRV_BRIDGE_CORE_CMD_FIRST in pvr_bridge.h differ between DDK1.9 and DDK1.14.
This is important to remember that this can unfortunately not be considered a stable API between DDK versions. This might become a big problem for upstreaming, unless there is an independently developed user-space where we have control over such constants. IMHO we should try to avoid supporting multiple variations here.
Finally I have mirrored my latest code (letux/latest-pvr rebased to v5.0) into our common git repo and started to write a Wiki home page there:
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/wiki
Regards, Philipp
Best regards, Nikolaus
On Sat, 9 Mar 2019 21:48:28 +0100 H. Nikolaus Schaller hns@goldelico.com wrote:
Hi Phillipp and all,
Am 25.02.2019 um 21:42 schrieb Philipp Rossak embed3d@gmail.com:
On 25.02.19 14:12, H. Nikolaus Schaller wrote:
Now it compiles for all the omap variants (omap3,4,5). Sunxi is missing some asm header file and jz4780 is missing some uaccess_kernel() function in an asm header. Should not be too difficult to find replacements or API changes. Compile for Intel is not tested.
I will have a look on the sunxi issue in the next days.
do you already have done some test and got findings/patches/suggestions? Or something where I could help?
I have some progress to get the DDK1.14 on v5.0 running on omap3/4/5.
The main issue so far was that I did not have matching "compatible" entries in the device tree so that probing the module did not succeed. And I had to port the CONFIG_RESET_CONTROLLER setup for omap.
But then it started working.
Here on omap5:
root@letux:~# ./gpu-demo autodetected driver package: omap5-sgx544-116 compatible driver: omap_omap5_sgx544_116 module name: pvr_omap_omap5_sgx544_116 pvrsrvctl: symbol lookup error: /usr/local/omap5-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender System Version String: None Running gles1test1 gles1test1: symbol lookup error: /usr/local/omap5-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender Running gles2test1 --------------------- started --------------------- gles2test1: symbol lookup error: /usr/local/omap5-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender Running eglinfo eglinfo: symbol lookup error: /usr/local/omap5-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender root@letux:~#
And on omap3:
root@letux:~# ./gpu-demo autodetected driver package: omap3630-sgx530-125 compatible driver: omap_omap3630_sgx530_125 module name: pvr_omap_omap3630_sgx530_125 pvrsrvctl: symbol lookup error: /usr/local/omap3-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender System Version String: None Running sgx_clipblit_test ----------------- SGX CLipBlit test ----------------- ---------------------- Start ------------------------ Call PVRSRVConnect with a valid argument: sgx_clipblit_test: symbol lookup error: /usr/local/omap3-pvrsgx/lib/libsrv_um.so: undefined symbol: drmOpenRender Running gles1test1 gles1test1: symbol lookup error: /usr/local/omap3-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender Running gles2test1 --------------------- started --------------------- gles2test1: symbol lookup error: /usr/local/omap3-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender Running eglinfo eglinfo: symbol lookup error: /usr/local/omap3-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender root@letux:~#
I am not sure where the user-space library problems come from. I think I have the correct DDK1.14 user space for omap from
git://git.ti.com/graphics/omap5-sgx-ddk-um-linux.git
but you never know:
http://e2e.ti.com/support/legacy_forums/embedded/linux/f/354/p/567306/208168...
But maybe it is simply because the -D flags of my in-kernel Makefile are not yet exactly correct.
Hmm, usually this symbol comes from the standard libdrm.so. Maybe it is somehow not compatible/not found/whatever, or the libsrv_um.so.1 library is not linked against that, so the application has to.
Regards, Andreas
Am 09.03.2019 um 22:08 schrieb Andreas Kemnade andreas@kemnade.info:
On Sat, 9 Mar 2019 21:48:28 +0100 H. Nikolaus Schaller hns@goldelico.com wrote:
Hi Phillipp and all,
Am 25.02.2019 um 21:42 schrieb Philipp Rossak embed3d@gmail.com:
On 25.02.19 14:12, H. Nikolaus Schaller wrote:
Now it compiles for all the omap variants (omap3,4,5). Sunxi is missing some asm header file and jz4780 is missing some uaccess_kernel() function in an asm header. Should not be too difficult to find replacements or API changes. Compile for Intel is not tested.
I will have a look on the sunxi issue in the next days.
do you already have done some test and got findings/patches/suggestions? Or something where I could help?
I have some progress to get the DDK1.14 on v5.0 running on omap3/4/5.
The main issue so far was that I did not have matching "compatible" entries in the device tree so that probing the module did not succeed. And I had to port the CONFIG_RESET_CONTROLLER setup for omap.
But then it started working.
Here on omap5:
root@letux:~# ./gpu-demo autodetected driver package: omap5-sgx544-116 compatible driver: omap_omap5_sgx544_116 module name: pvr_omap_omap5_sgx544_116 pvrsrvctl: symbol lookup error: /usr/local/omap5-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender System Version String: None Running gles1test1 gles1test1: symbol lookup error: /usr/local/omap5-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender Running gles2test1 --------------------- started --------------------- gles2test1: symbol lookup error: /usr/local/omap5-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender Running eglinfo eglinfo: symbol lookup error: /usr/local/omap5-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender root@letux:~#
And on omap3:
root@letux:~# ./gpu-demo autodetected driver package: omap3630-sgx530-125 compatible driver: omap_omap3630_sgx530_125 module name: pvr_omap_omap3630_sgx530_125 pvrsrvctl: symbol lookup error: /usr/local/omap3-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender System Version String: None Running sgx_clipblit_test ----------------- SGX CLipBlit test ----------------- ---------------------- Start ------------------------ Call PVRSRVConnect with a valid argument: sgx_clipblit_test: symbol lookup error: /usr/local/omap3-pvrsgx/lib/libsrv_um.so: undefined symbol: drmOpenRender Running gles1test1 gles1test1: symbol lookup error: /usr/local/omap3-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender Running gles2test1 --------------------- started --------------------- gles2test1: symbol lookup error: /usr/local/omap3-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender Running eglinfo eglinfo: symbol lookup error: /usr/local/omap3-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender root@letux:~#
I am not sure where the user-space library problems come from. I think I have the correct DDK1.14 user space for omap from
git://git.ti.com/graphics/omap5-sgx-ddk-um-linux.git
but you never know:
http://e2e.ti.com/support/legacy_forums/embedded/linux/f/354/p/567306/208168...
But maybe it is simply because the -D flags of my in-kernel Makefile are not yet exactly correct.
Hmm, usually this symbol comes from the standard libdrm.so.
Yes, that is what I also was thinking. For some reason the libdrm.so on my Debian Jessie has all symbols stripped:
root@letux:~# nm /usr/lib/arm-linux-gnueabihf/libdrm.so nm: /usr/lib/arm-linux-gnueabihf/libdrm.so: no symbols root@letux:~# nm /usr/lib/arm-linux-gnueabihf/libdrm.so.2 nm: /usr/lib/arm-linux-gnueabihf/libdrm.so.2: no symbols root@letux:~# nm /usr/lib/arm-linux-gnueabihf/libdrm_omap.so nm: /usr/lib/arm-linux-gnueabihf/libdrm_omap.so: no symbols root@letux:~#
And the package libdrm-dbg does not provide a version with symbols.
Maybe it is somehow not compatible/not found/whatever, or the libsrv_um.so.1 library is not linked against that, so the application has to.
Ok, the application shows:
root@letux:~# ldd /usr/local/omap3-pvrsgx/bin/gles1test1 libdrm.so.2 => /usr/lib/arm-linux-gnueabihf/libdrm.so.2 (0xb6f82000) libgbm.so.2 => /usr/local/omap3-pvrsgx/lib/libgbm.so.2 (0xb6f68000) libudev.so.1 => /lib/arm-linux-gnueabihf/libudev.so.1 (0xb6f4e000) libwayland-server.so.0 => /usr/lib/arm-linux-gnueabihf/libwayland-server.so.0 (0xb6f34000) libdrm_omap.so.1 => /usr/lib/arm-linux-gnueabihf/libdrm_omap.so.1 (0xb6f21000) libffi.so.6 => /usr/lib/arm-linux-gnueabihf/libffi.so.6 (0xb6f0b000) libsrv_um.so.1 => /usr/local/omap3-pvrsgx/lib/libsrv_um.so.1 (0xb6ed4000) libdbm.so.1 => /usr/local/omap3-pvrsgx/lib/libdbm.so.1 (0xb6ec2000) libusc.so.1 => /usr/local/omap3-pvrsgx/lib/libusc.so.1 (0xb6e09000) libIMGegl.so.1 => /usr/local/omap3-pvrsgx/lib/libIMGegl.so.1 (0xb6de4000) libEGL.so.1 => /usr/local/omap3-pvrsgx/lib/libEGL.so.1 (0xb6dd2000) libGLES_CM.so.1 => /usr/local/omap3-pvrsgx/lib/libGLES_CM.so.1 (0xb6d69000) libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6c79000) /lib/ld-linux-armhf.so.3 (0xb6fb1000) libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb6c05000) libexpat.so.1 => /lib/arm-linux-gnueabihf/libexpat.so.1 (0xb6bdd000) libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6bca000) libwayland-client.so.0 => /usr/lib/arm-linux-gnueabihf/libwayland-client.so.0 (0xb6bb1000) libglapi.so.0 => /usr/lib/arm-linux-gnueabihf/libglapi.so.0 (0xb6b74000) libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6b51000) librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb6b3b000) libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb6b12000) root@letux:~#
Ah, maybe an strace reveals more.
BR and thanks, Nikolaus
On Sat, 9 Mar 2019 22:15:28 +0100 "H. Nikolaus Schaller" hns@goldelico.com wrote:
Am 09.03.2019 um 22:08 schrieb Andreas Kemnade andreas@kemnade.info:
On Sat, 9 Mar 2019 21:48:28 +0100 H. Nikolaus Schaller hns@goldelico.com wrote:
Hi Phillipp and all,
Am 25.02.2019 um 21:42 schrieb Philipp Rossak embed3d@gmail.com:
On 25.02.19 14:12, H. Nikolaus Schaller wrote:
Now it compiles for all the omap variants (omap3,4,5). Sunxi is missing some asm header file and jz4780 is missing some uaccess_kernel() function in an asm header. Should not be too difficult to find replacements or API changes. Compile for Intel is not tested.
I will have a look on the sunxi issue in the next days.
do you already have done some test and got findings/patches/suggestions? Or something where I could help?
I have some progress to get the DDK1.14 on v5.0 running on omap3/4/5.
The main issue so far was that I did not have matching "compatible" entries in the device tree so that probing the module did not succeed. And I had to port the CONFIG_RESET_CONTROLLER setup for omap.
But then it started working.
Here on omap5:
root@letux:~# ./gpu-demo autodetected driver package: omap5-sgx544-116 compatible driver: omap_omap5_sgx544_116 module name: pvr_omap_omap5_sgx544_116 pvrsrvctl: symbol lookup error: /usr/local/omap5-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender System Version String: None Running gles1test1 gles1test1: symbol lookup error: /usr/local/omap5-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender Running gles2test1 --------------------- started --------------------- gles2test1: symbol lookup error: /usr/local/omap5-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender Running eglinfo eglinfo: symbol lookup error: /usr/local/omap5-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender root@letux:~#
And on omap3:
root@letux:~# ./gpu-demo autodetected driver package: omap3630-sgx530-125 compatible driver: omap_omap3630_sgx530_125 module name: pvr_omap_omap3630_sgx530_125 pvrsrvctl: symbol lookup error: /usr/local/omap3-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender System Version String: None Running sgx_clipblit_test ----------------- SGX CLipBlit test ----------------- ---------------------- Start ------------------------ Call PVRSRVConnect with a valid argument: sgx_clipblit_test: symbol lookup error: /usr/local/omap3-pvrsgx/lib/libsrv_um.so: undefined symbol: drmOpenRender Running gles1test1 gles1test1: symbol lookup error: /usr/local/omap3-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender Running gles2test1 --------------------- started --------------------- gles2test1: symbol lookup error: /usr/local/omap3-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender Running eglinfo eglinfo: symbol lookup error: /usr/local/omap3-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender root@letux:~#
I am not sure where the user-space library problems come from. I think I have the correct DDK1.14 user space for omap from
git://git.ti.com/graphics/omap5-sgx-ddk-um-linux.git
but you never know:
http://e2e.ti.com/support/legacy_forums/embedded/linux/f/354/p/567306/208168...
But maybe it is simply because the -D flags of my in-kernel Makefile are not yet exactly correct.
Hmm, usually this symbol comes from the standard libdrm.so.
Yes, that is what I also was thinking. For some reason the libdrm.so on my Debian Jessie has all symbols stripped:
nm -D displays more.
root@letux:~# nm /usr/lib/arm-linux-gnueabihf/libdrm.so nm: /usr/lib/arm-linux-gnueabihf/libdrm.so: no symbols root@letux:~# nm /usr/lib/arm-linux-gnueabihf/libdrm.so.2 nm: /usr/lib/arm-linux-gnueabihf/libdrm.so.2: no symbols root@letux:~# nm /usr/lib/arm-linux-gnueabihf/libdrm_omap.so nm: /usr/lib/arm-linux-gnueabihf/libdrm_omap.so: no symbols root@letux:~#
Regards, Andreas
Am 09.03.2019 um 22:29 schrieb Andreas Kemnade andreas@kemnade.info:
Yes, that is what I also was thinking. For some reason the libdrm.so on my Debian Jessie has all symbols stripped:
nm -D displays more.
Ah, yes. I forgot that pure nm only shows internal symbols and not those exported by the library.
root@letux:~# nm -D /usr/lib/arm-linux-gnueabihf/libdrm.so | fgrep drmOpenRender root@letux:~#
So this means that the libdrm of Jessie is too old and I should try on stretch or newer.
BR, Nikolaus
Am 13.02.2019 um 21:56 schrieb Philipp Rossak embed3d@gmail.com:
On 13.02.19 18:34, Tony Lindgren wrote:
- H. Nikolaus Schaller hns@goldelico.com [190213 16:01]:
This raises the question who wants to take the maintainer's head (at least initially)...
I am not sure if I want to do it because I already spend too much voluntary time on Linux :) So if someone else would like to take this role, I'd step back.
Well maybe try a shared maintainership model with one or two other people who have already done some patches? It seems at Paweł and Philip are potential candidates to help and have their own repos already :)
I can help here, but I can start on this earliest in 2 weeks or a month, when I have Internet in my new flat...
Ok, would be fine! We all can prepare to provide our material during that time.
Maybe we should simply start to collect everything first in this single place. And then remove duplicates...
BR, Nikolaus
Hi,
(Sorry, catching up on mails - this all looks exciting!)
On 13/02/2019 18:34, Tony Lindgren wrote:
- H. Nikolaus Schaller hns@goldelico.com [190213 16:01]:
This raises the question who wants to take the maintainer's head (at least initially)...
I am not sure if I want to do it because I already spend too much voluntary time on Linux :) So if someone else would like to take this role, I'd step back.
Well maybe try a shared maintainership model with one or two other people who have already done some patches? It seems at Paweł and Philip are potential candidates to help and have their own repos already :)
I think the n900 folks have their own repo too but I don't know who is active with that. Merlijn?
Ivaylo (CC) did the legwork to port the Nemo Mobile kernel driver to (then mainline) 4.15. I'm also interested in helping out with code/testing/time, but I'm likely not a good fit as a maintainer right now.
Cheers, Merlijn
On 13/02/2019 16:35, Tony Lindgren wrote:
- H. Nikolaus Schaller hns@goldelico.com [190213 05:50]:
Am 12.02.2019 um 21:18 schrieb Tony Lindgren tony@atomide.com: To me it seems just the wrapper IP is different. If you look at drivers/gpu/drm/gma500/accel_2d.c it seems to be only accessing the sgx registers based on a quick glance. So it's already quite generic.
One thing I only now realized/remembered is that not all SGX versions have 2D HW. And I think there are two different 2D HW cores. The details are fuzzy to me, though.
Tomi
Am 13.02.2019 um 16:22 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 13/02/2019 16:35, Tony Lindgren wrote:
- H. Nikolaus Schaller hns@goldelico.com [190213 05:50]:
Am 12.02.2019 um 21:18 schrieb Tony Lindgren tony@atomide.com: To me it seems just the wrapper IP is different. If you look at drivers/gpu/drm/gma500/accel_2d.c it seems to be only accessing the sgx registers based on a quick glance. So it's already quite generic.
One thing I only now realized/remembered is that not all SGX versions have 2D HW. And I think there are two different 2D HW cores. The details are fuzzy to me, though.
I have looked into the OMAP3530 TRM and that one only talks about "the SGX subsystem" with 2d/3d capabilities. Which would probably mean a single unit - perhaps with different drivers. So it is questionable if they can be used in parallel.
So since this is confusing, I'd postpone it until we have a better understanding.
BR, Nikolaus
Hi,
On 10/02/2019 18:14, Merlijn Wajer wrote:
I have a couple of devices that I'd like to try getting PowerVR to work on. We (Maemo Leste) have it working on the Nokia N900 (forward port of nemo mobile kernel+userspace), but X11 works with acceleration, although some issues remain.
But I would also like to try to get it to work on the Motorola Droid 4 (also omap). And Pawel (in CC) has exynos devices with PowerVR, and he's also trying to get something to work [1] [2]. I also have a Pandaboard ES specifically for this purpose.
Ideally we'd use drm+modesetting drivers with dri3wsegl [3], but I have yet to try to make that work. :)
So what are people's targets on the environment where they want to use SGX?
- X11 - Wayland - KMS - fbdev
Or all? I hope at least fbdev can be forgotten, as it'll never work perfectly...
Tomi
Hi,
On 14/02/2019 09:26, Tomi Valkeinen wrote:
Hi,
On 10/02/2019 18:14, Merlijn Wajer wrote:
I have a couple of devices that I'd like to try getting PowerVR to work on. We (Maemo Leste) have it working on the Nokia N900 (forward port of nemo mobile kernel+userspace), but X11 works with acceleration, although some issues remain.
But I would also like to try to get it to work on the Motorola Droid 4 (also omap). And Pawel (in CC) has exynos devices with PowerVR, and he's also trying to get something to work [1] [2]. I also have a Pandaboard ES specifically for this purpose.
Ideally we'd use drm+modesetting drivers with dri3wsegl [3], but I have yet to try to make that work. :)
So what are people's targets on the environment where they want to use SGX?
- X11
- Wayland
- KMS
- fbdev
For me, that would definitely be X (which is likely also the most involved of those - except for perhaps fbdev). Before this thread started moving again my plan was to take the Pandaboard ES and/or N900 and try omapdrmfb, modesetting ddx and dri3wsegl with it, so we can stop using fb and this ddx [1].
Cheers, Merlijn
[1] https://github.com/maemo-leste/n9xx-xf86-video-fbdev-sgx
Or all? I hope at least fbdev can be forgotten, as it'll never work perfectly...
Tomi
* Merlijn Wajer merlijn@wizzup.org [190214 12:28]:
On 14/02/2019 09:26, Tomi Valkeinen wrote:
So what are people's targets on the environment where they want to use SGX?
- X11
- Wayland
- KMS
- fbdev
For me, that would definitely be X (which is likely also the most involved of those - except for perhaps fbdev). Before this thread started moving again my plan was to take the Pandaboard ES and/or N900 and try omapdrmfb, modesetting ddx and dri3wsegl with it, so we can stop using fb and this ddx [1].
Yeah it's X11 with drivers/gpu/drm for me too at least so far. Then maybe wayland at some point if it becomes usable.
My main motivation being that stellarium is pretty much unusable currently :)
Regards,
Tony
[1] https://github.com/maemo-leste/n9xx-xf86-video-fbdev-sgx
-
Adam Ford -
Andreas Kemnade -
H. Nikolaus Schaller -
Merlijn Wajer -
Paweł Chmiel -
Philipp Rossak -
Tero Kristo -
Tomi Valkeinen -
Tony Lindgren