[Letux-kernel] sgx on pyra with newer kernels

[H. Nikolaus Schaller]

Great to hear that it works again!

I also noticed what I think may be a general slowdown of the Pyra with recent kernels but haven't analyzed.
Even sysbench was pretty slow. Maybe someone has turned off the processor caches by default...

As noted below I haven't managed to test pvrsrvctl with ddk 1.17. The reason is that pvrsrvctl links to a recent libc6 and libffi6.
This libc is only available in Bullseye while Bullseye recently removed libffi6 and replaced by libffi7.
So there is no standard-Debian system which provides the right libs :(

Maybe someone has an idea how to handle it (install Stretch/Buster-libffi6? Simply fake libffi6.so -> libffi7.so? compile libffi6 from sources on Bullseye?)

> Am 02.08.2021 um 22:17 schrieb aTc <atc at k-n-p.org>:
> 
> Just saw it appear in the changes list, and gave it a quick try with letux-5.10.55. (with DDK 1.14.3699939 (TI) and pyra userspace)
> 
> Everything loads fine now, unfortunately performance is really poor.
> 
> (about 10 fps max, where before it would easily do 60. glxgears (running through gl4es) for example went from 400fps to 9fps. Even mesa manages 40fps with the window maximized. )
> 
> I'll see if I can get a few more people to give it a try, and try to figure out where the performance issue comes from.
> 
> 
> On 7/31/21 9:10 AM, H. Nikolaus Schaller wrote:
>> Hi,
>> thanks for finding the "good" and "bad" points, so that I could restrict
>> to look in between.
>> Finally I could invest some time for this task and was able to exactly imitate your
>> bug report (had to install a Stretch image first; Jessie or Bullseye doesn't like my
>> DDK 1.14 setup and 1.17 requires libc6 >= 2.29 which is only available in Bullseye
>> but also libffi.so.6 which is no longer available on Bullseye - what a pity that we can
>> not build our own user-space packages).
>> There is already a partial fix in the tree, but with a functional change which
>> remained unnoticed.
>> The solution is a real hack since the driver wants to do something kernel developers
>> have decided that a driver should not (or no longer) do. I have no idea why the sgx
>> driver needs it done the way it is done and what it is good for, but simply ignoring
>> this difference ends up in the timeout.
>> The hack is to expose some lower level kernel API (which is normally hidden) to
>> driver modules and provide the old API which has been changed.
>> A real solution would be to rewrite bigger portions of the sgx driver to only use
>> modern and available API but I have not yet an idea how to do that. Would need
>> a lot of more time to find out...
>> So let's stick with my hackish solution until we run into problems with it. I can
>> now load the firmware without timeout reports on letux-5.10.y or letux-5.14-rc3