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

H. Nikolaus Schaller hns at goldelico.com
Sun Jul 10 22:56:57 CEST 2022


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.

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