[Openpvrsgx-devgroup] [RFC][PATCH] pvrsrv: 1.17: pvr_linux_fence: Repace dma_resv_list by iterator
anthoine.bourgeois at gmail.com
Tue Jul 12 21:28:17 CEST 2022
On Mon, Jul 11, 2022 at 01:53:51PM +0200, H. Nikolaus Schaller wrote:
>> Am 10.07.2022 um 22:56 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>> Hi Anthoine,
>> I have found that my binary patch is no longer compatible to what I download from
>> So I have to experiment to find out which version did work.
>Apparently it was ce7b96b8 on branch ti-sgx544-um/ti-img-sgx/zeus/1.17.4948957
>which was recently updated to 551665bf.
>Checking out ce7b96b8 and then applying my patches:
>$LIBSRV_UM 0x8a3a 0x00 # d7 -> 00
>$LIBSRV_UM 0x8a3b 0xbf # d1 -> bf
>$LIBSRV_UM 0x89eb 0xe0 # d0 -> e0
>If you are interested, my full (Debian) .postinst script is here:
>This makes my pvrsrvctl work again:
>root at letux:~# uname -a
>Linux letux 5.19.0-rc5-letux-lpae+ #10020 SMP PREEMPT Sun Jul 10 09:51:36 CEST 2022 armv7l GNU/Linux
>root at letux:~# pvrsrvctl --start --no-module
>[12119.428932] PVR_K: UM DDK-(4948957) and KM DDK-(4948957) match. [ OK ]
>root at letux:~#
>Unfortunately this seems not to make use of any DMA... So I still can't test your patches.
Can't you run a gles2test1 demo here ?
>But I think we should integrate them and in worst case put another patch on top...
On my side, I fix my "/usr/bin/pvrsrvctl: No such file or directory" by
switching to a hardfloat image. I was in a softfp before.
Now I can run pvrsrvctl too, but got an error on EGL:
--------------------- started ---------------------
'eglInitialize' returned egl error 'EGL_NOT_INITIALIZED' (0x3001)
>BR and thanks,
>> I do not remember where the original patch instructions came from.
>> AFAIR, some Pyra-Handheld hacker had analysed the libsrv_um.so binary and assembler
>> code to disable the assembler instruction that really checks /sys/devices/soc0/machine.
>> This did lead to instructions like "patch byte at file offset 0x8a3b to 0xbf".
>> With a new version published by TI this obviously leads to a different file offset
>> to be patched and my existing patch does not allow OMAP5432.
>> Well, it would be kind and appreciated if someone at TI could simply add "OMAP5432"
>> to the compatibility table of the DDK1.17 ("jacinto6") plaform...
>> Then we would no longer have to patch a closed source binary lib.
>> But until they do (or if not) we have to patch the binary to not reject /sys/devices/soc0/machine = "OMAP5432".
>> Well, an alternative would be to make the kernel return "DRA712" or similar
>> But nobboy knows if /sys/devices/soc0/machine is used elsewhere.
>>> Am 07.07.2022 um 11:51 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>>> Hi Antoine,
>>> I could fix my setup a little by upgrading to Debian 11 (Bullseye) but adding a symlink to make libffi7.so be found as libffi6.so (which is baked into the closed source runtime binaries).
>>> Using this I can run pvrsrvctl but it fails with
>>> PVR:(Error): PVRSRVDetectPlaform: Unknown platform: OMAP5432
>>> Maybe the code to patch the binaries is broken on Bullseye by some script incompatibility.
>>> Anyways there is no kernel panic or similar so far.
>>> BR and thanks,
More information about the openpvrsgx-devgroup