[Openpvrsgx-devgroup] [RFC][PATCH] pvrsrv: 1.17: pvr_linux_fence: Repace dma_resv_list by iterator

Anthoine Bourgeois anthoine.bourgeois at gmail.com
Tue Jul 12 21:28:17 CEST 2022


Hi Nikolaus,

On Mon, Jul 11, 2022 at 01:53:51PM +0200, H. Nikolaus Schaller wrote:
>Hi Anthoine,
>
>> 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
>>
>> https://git.ti.com/cgit/graphics/omap5-sgx-ddk-um-linux
>>
>> 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:
>
>	https://git.goldelico.com/?p=letux-rootfs.git;a=blob;f=packages/letux-pvrsgx-1.17/letux-pvrsgx-1.17.postinst
>
>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...
>

I agree.

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:
# gles2test1
--------------------- started ---------------------
'eglInitialize' returned egl error 'EGL_NOT_INITIALIZED' (0x3001)

Thanks,
Anthoine

>BR and thanks,
>Nikolaus
>
>
>>
>> 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.
>>
>> BR,
>> Nikolaus
>>
>>> 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,
>>> Nikolaus
>>
>


More information about the openpvrsgx-devgroup mailing list