[Openpvrsgx-devgroup] [RFC][PATCH] pvrsrv: 1.17: pvr_linux_fence: Repace dma_resv_list by iterator
H. Nikolaus Schaller
hns at goldelico.com
Mon Jul 11 13:53:51 CEST 2022
> 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.
But I think we should integrate them and in worst case put another patch on top...
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