* 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