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

[Adam Ford]

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!
> Nikolaus
>
> _______________________________________________
> https://github.com/openpvrsgx-devgroup/linux_openpvrsgx
> openpvrsgx-devgroup mailing list
> openpvrsgx-devgroup at letux.org
> http://lists.goldelico.com/mailman/listinfo.cgi/openpvrsgx-devgroup