linux-kernel - Re: [Letux-kernel] Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 14 Oct 2019 18:11:33 +0200
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Discussions about the Letux Kernel <letux-kernel@...nphoenux.org>
Cc:     Merlijn Wajer <merlijn@...zup.org>, Adam Ford <aford173@...il.com>,
        Tony Lindgren <tony@...mide.com>,
        Philipp Rossak <embed3d@...il.com>,
        Paweł Chmiel <pawel.mikolaj.chmiel@...il.com>,
        Tomi Valkeinen <tomi.valkeinen@...com>,
        Filip Matijević <filip.matijevic.pz@...il.com>,
        Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>,
        moaz korena <moaz@...ena.xyz>,
        James Hilliard <james.hilliard1@...il.com>,
        maemo-leste@...ts.dyne.org,
        linux-omap <linux-omap@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        kernel@...a-handheld.com, Robert Nelson <robertcnelson@...il.com>
Subject: Re: [Letux-kernel] Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

> Am 12.10.2019 um 15:09 schrieb H. Nikolaus Schaller <hns@...delico.com>:
> 
> Hi,
> 
>> Am 05.10.2019 um 18:58 schrieb H. Nikolaus Schaller <hns@...delico.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:

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