[Openpvrsgx-devgroup] trying to get SGX 1.14 running on DM3730 (SGX530)
aford173 at gmail.com
Sat Nov 23 13:03:09 CET 2019
On Fri, Nov 22, 2019 at 2:11 PM H. Nikolaus Schaller <hns at goldelico.com> wrote:
> > Am 21.11.2019 um 16:39 schrieb Tony Lindgren <tony at atomide.com>:
> > * 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.
> Yes, that seems to work! Much easier than patching binaries of libsrv_um
> or modify libdrm2.
TI folks -
Any chance you could generate new binaries that can accept a variety
of strings? I assume it's TI to generated them in the past.
> So we need different rules for the TARGET_PRODUCT based on
> comatible strings:
> ti,am33xx -> TARGET_PRODUCT=ti335x
> ti,am43xx -> TARGET_PRODUCT=ti437x
> ti,omap3430 -> ?
> ti,omap3630 -> TARGET_PRODUCT=ti437x
I am going to try and get my DM3730 working this morning. If so, I'll
then try OMAP3530 which should cover 3430. Once I get those working,
I'll try it on an AM3517. I don't want to forget AM3517. :-)
> ti,omap4 -> ?
> ti,omap5 -> TARGET_PRODUCT=jacinto6evm
Instead of hacking the libdrm2 to return the proper strings, is there
any change we can modify the driver to return the name to DRM? I
don't fully understand how those layers work, so I am honestly now
sure if it's even possible.
> I will update the gpu-demo script accordingly.
I am using buildroot and I am installing some of the gles2 demos.
> And now it is time to focus on the patch series for sgx DT nodes,
> add some "tested by # device" and yaml bindings...
> BR and thanks for this idea!
> openpvrsgx-devgroup mailing list
> openpvrsgx-devgroup at letux.org
More information about the openpvrsgx-devgroup