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

[H. Nikolaus Schaller]

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.

But I think we should integrate them and in worst case put another patch on top...

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
>