> Am 12.10.2019 um 15:09 schrieb H. Nikolaus Schaller <hns@xxxxxxxxxxxxx>: > > Hi, > >> Am 05.10.2019 um 18:58 schrieb H. Nikolaus Schaller <hns@xxxxxxxxxxxxx>: > > 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: https://youtu.be/jFCPR_EvtjY 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-pvr-soc-glue-v5 [2]: https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux/omap-sysc-prm-gfx [3]: https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux/latest-pvr
