[Openpvrsgx-devgroup] trying to get SGX 1.14 running on DM3730 (SGX530)

H. Nikolaus Schaller hns at goldelico.com
Thu Nov 21 15:51:24 CET 2019

> Am 21.11.2019 um 15:40 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>> Am 21.11.2019 um 14:28 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>> Hi Adam,
>>> Am 21.11.2019 um 14:15 schrieb Adam Ford <aford173 at gmail.com>:
>>> On Thu, Nov 21, 2019 at 5:58 AM H. Nikolaus Schaller <hns at goldelico.com> wrote:
>>> Above it closed card0 and started to open card1 indicating to me it
>>> didnt' find what it wanted.  Do you know what it wanted?
>> Not yet... This is what I try to find out next by adding printf to libdrm.
> Ok, I have new information. But no solution yet :(
> drmGetVersion() returns exactly what was passed by the kernel. So there is
> no bug in the ioctl() interface or our kernel module.
> drmGetVersion(fd=3) is called twice by PVRDRMOpenRender from libsrv_um.so.1
> and then called twice (fd=4) from PVRDRMOpenDisplay
> So the logic to scan through /dev/dri/card* for DRM_VERSION and the rules what
> it is looking for are hidden inside libsrv_um.so and most likely in the
> PVRDRMOpenDisplay function :(
> And even the open() system call for the second run. The first two seem to be
> drmOpenMinor("/dev/dri/renderD128") and drmOpenMinor("/dev/dri/renderD129");
> So at the moment I can only speculate that there is some code in libsrv_um.so
> which dynamically makes the search pattern different between running on am335x
> and dm3730.
> Well, we have something similar for the dra7/jacinto6/omap5432 case and have
> to patch the binary libsrv_um.so.1.14.3699939.
> But there the unpatched system explicitly says that it does not support the
> OMAP5432 unless we patch it (likely by reading out the machine DT property).
> Here the am335x version running on dm3730 simply fails to find displays.

Just after submitting this mail I got an idea what is going wrong and what
libsrv_um.so is looking for.

Firstly, it is PVRDRMOpenDisplay() which fails. I.e. looking for a display DRM
device. Not the SGX (which is found by PVRDRMOpenRender).

What if it does not look for maj=14 or min=0 but for name=tilcdc or even
desc="TI LCD Controller DRM"?

Then it will find:

> [   85.015917] drm_version: maj=1 min=0 patch=0 name=tilcdc date=20121205 desc=TI LCD Controller DRM

but of course not:

> [  275.910827] drm_version: maj=1 min=0 patch=0 name=omapdrm date=20110917 desc=OMAP DRM

So here we have the DRM difference between omap3 and am33xx.

A quick check seems to confirm my idea that it is looking for the name:

root at letux:~# fgrep 'TI LCD Controller DRM' /usr/lib/libsrv_um.so.1.14.3699939
root at letux:~# fgrep 'tilcdc' /usr/lib/libsrv_um.so.1.14.3699939
Binary file /usr/lib/libsrv_um.so.1.14.3699939 matches
root at letux:~# fgrep 'omapdrm' /usr/lib/libsrv_um.so.1.14.3699939
root at letux:~# 

What does the libsrv_um.so need to know the string "tilcdc" if not for matching
the display card?

So we either have to patch this string or strcmp() and hope that the lib isn't
doing anything which is tilcdc specific.

Unfortuantely the string "omapdrm" is one character longer so that we can't easily
replace it. An upgly approach would be to assume that we only have "omapdrm"
and "pvr" and can invert the comparison, i.e. everything which is not "pvr" is
a display...

> [   84.848381] drm_version: maj=1 min=14 patch=3699939 name=pvr date=20110701 desc=Imagination Technologies PVR DRM

Or we can modify the compare to check for min=0. Anyways this is quite a hack
in some binary blob...


More information about the openpvrsgx-devgroup mailing list