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

Tony Lindgren tony at atomide.com
Thu Nov 21 16:39:50 CET 2019

* H. Nikolaus Schaller <hns at goldelico.com> [191121 15:24]:
> Hi Tomi,
> > Am 21.11.2019 um 16:13 schrieb Tomi Valkeinen <tomi.valkeinen at ti.com>:
> > 
> > On 21/11/2019 16:51, H. Nikolaus Schaller wrote:
> > 
> >> 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"?
> > 
> > Did you try ltrace? I haven't used it, but it should show what the parameters are.
> I have looked into what gdb shows in the disassembler window. And it seems my
> assumption about the algorithm isn't very wrong... open(), close(), snprintf(),
> drmGetVersion() and strcmp() are called. There is only one additional call to
> drmFreeVersion(). Otherwise one would have to decipher the ARM assembly.
> > I guess an option is to use LD_PRELOAD to catch the "bad" calls and modify them as needed.
> Yes, that could be a workaround which does not need patching the binary blobs.
> Another trick could be to tell omapdrm to report itself as "tilcdc". At least for
> verifying this idea.
> I assume you know where the name="omapdrm" or name="tilcdc" string is defined :)
> Or maybe the easiest thing to try in my setup is to make drmGetVersion() return
> "tilcdc" if it gets "omapdrm" from the ioctl..

Heh so maybe try with the ti437x binaries on omap3 instead?

That should be the same sgx530 with dispc instead of tilcd.

It would be silly if the name is the only reason for a pile of
different binary blobs..



More information about the openpvrsgx-devgroup mailing list