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

Adam Ford aford173 at gmail.com
Sat Nov 23 14:38:40 CET 2019


On Sat, Nov 23, 2019 at 6:47 AM H. Nikolaus Schaller <hns at goldelico.com> wrote:
>
>
> > Am 23.11.2019 um 13:03 schrieb Adam Ford <aford173 at gmail.com>:
> >
> > 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.
>
> Most likely yes (and not only in the past, see below).
>
> The model seems to be that IMG licenses the full DDK sources to TI, Intel,
> others and these groups do the integration into their SoC driver architecture
> and preferred operating systems.
>
> Therefore every chip and OS has a different DDK variant even if they are the
> same architecture...
>
> I think the complexity comes from the the same DDK source code is used
> but adapted for different Linux/Android flavors, iPhone and Windows. And
> this adaptation is what IMG does not want to do.
>
> Hm. Maybe we should create a non-profit foundation to license the DDK
> sources for Generic Linux... Well, there would be a strict NDA of course
> but those who have signed, can modify and publish adjusted binaries. But
> never work again on a free and open reverse engineered driver (unless
> the NDA has some time limit or whatever).
>
> >
> >>
> >> 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.
>
> For me it failed because some component (uKernel?) checks for sgx530-125
> and finds a sgx530-121.
>
> >  Once I get those working,
> > I'll try it on an AM3517.  I don't want to forget AM3517.  :-)
>
> Sure :) I just have no board which makes use of it. Same for am43xx...
>
> BTW: the most general repo for OMAP seems to be
>
> https://git.ti.com/cgit/graphics/omap5-sgx-ddk-um-linux/tree/targetfs?h=ti-img-sgx/thud/1.17.4948957
>
> There was even an upstream update 4 weeks ago.
>
> >
> >> 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.
>
> Well, these strings come somewhere from the drm subsystem and not from
> our driver since it is scanning for the display to be used.
>
> Our driver can only report that it is the pvr driver:
>
> name=pvr vs. name=tilcdc vs. name=omapdrm
>
> So our driver would have to tweak the panel drivers it is not even
> aware of.
>
> The next higher level is the libdrm2 which could make the panel drivers
> named differently.
>
> And the highest level is the closed libsrv_um.so.
>
> So technically we only have open source access in libdrm2.
>
> >
> >> I will update the gpu-demo script accordingly.
> >
> > I am using buildroot and I am installing some of the gles2 demos.
>
> Fine. The more different test setups we have, the better is the test
> coverage.
>

I am not quite as far as you, but on my DM3730, I can see the following:

# drmdevice
--- Checking the number of DRM device available ---
--- Devices reported 1 ---
--- Retrieving devices information (PCI device revision is ignored) ---
device[0]
+-> available_nodes 0x05
+-> nodes
|   +-> nodes[0] /dev/dri/card0
|   +-> nodes[2] /dev/dri/renderD128
+-> bustype 0002
|   +-> platform
|       +-> fullname /ocp at 68000000/target-module at 50000000/gpu at 0
+-> deviceinfo
    +-> platform
        +-> compatible
                    ti,omap3-sgx530-125
                    img,sgx530-125
                    img,sgx530

--- Opening device node /dev/dri/card0 ---
--- Retrieving device info, for node /dev/dri/card0 ---
device[0]
+-> available_nodes 0x05
+-> nodes
|   +-> nodes[0] /dev/dri/card0
|   +-> nodes[2] /dev/dri/renderD128
+-> bustype 0002
|   +-> platform
|       +-> fullname /ocp at 68000000/target-module at 50000000/gpu at 0
+-> deviceinfo
    +-> platform
        +-> compatible
                    ti,omap3-sgx530-125
                    img,sgx530-125
                    img,sgx530

--- Opening device node /dev/dri/renderD128 ---
--- Retrieving device info, for node /dev/dri/renderD128 ---
device[0]
+-> available_nodes 0x05
+-> nodes
|   +-> nodes[0] /dev/dri/card0
|   +-> nodes[2] /dev/dri/renderD128
+-> bustype 0002
|   +-> platform
|       +-> fullname /ocp at 68000000/target-module at 50000000/gpu at 0
+-> deviceinfo
    +-> platform
        +-> compatible
                    ti,omap3-sgx530-125
                    img,sgx530-125
                    img,sgx530


Maybe I missed the instructions somewhere, but where are the closed
source blobs that I should use located?  I built the kernel, but I
assume I need to install the binaries separately. Sorry it's taken so
long for me to catch up.

adam

> >>
> >> And now it is time to focus on the patch series for sgx DT nodes,
> >> add some "tested by # device" and yaml bindings...
>
> I think I have tamed YAML now... At least make dt_binding_check dtbs_check
> did pass with many warnings (in other files) and did not fail any more.
>
> So there will be a patch series for the sgx DT nodes soon.
>
> BR,
> 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


More information about the openpvrsgx-devgroup mailing list