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

Adam Ford aford173 at gmail.com
Sat Nov 23 18:23:50 CET 2019


On Sat, Nov 23, 2019 at 7:50 AM H. Nikolaus Schaller <hns at goldelico.com> wrote:
>
>
> > Am 23.11.2019 um 14:38 schrieb Adam Ford <aford173 at gmail.com>:
> >
> > 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
>
> Looks good.
>
> >
> > 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.
>
> No problem. My script now uses these:
>
> git clone -b ti-img-sgx/1.14.3699939 git://git.ti.com/graphics/omap5-sgx-ddk-um-linux.git
>
> Then do
>
> export TARGET_PRODUCT=ti437x
> export DISCIMAGE=/
> make install
>
> ln -s libgbm.so.1 /usr/lib/arm-linux-gnueabihf/libgbm.so.2
> [ -f /usr/lib/libGLESv2.so.1 ] || ln -s libGLESv2.so.2 /usr/lib/libGLESv2.so.1
>
> pvrsrvctl --start --no-module

I am testing on the AM3517 just to try and catch it up.

>From what I can tell, AM3517 should have the same SGX core as the
OMAP34/35/36. Based on [1].

When I run the tool from above, I get the following:

# pvrsrvctl --start --no-module
[   52.163426] PVR_K: UM DDK-(3699939) and KM DDK-(3699939) match. [ OK ]
[   52.200303] PVR_K: (FAIL) SGXInit: Incompatible HW core rev (10201)
and SW core rev (10205).

10201 seems right to me for the AM35, so I wonder if I mis-installed
something.  I was hoping you might be able to point me to where I went
wrong.

[   52.209287] PVR_K:(Error): PVRSRVFinaliseSystem: Failed
PVRSRVDevInitCompatCheck call (device index: 0)
PVR:(Error): PVRSRVInitSrvDisconnect: KM returned 26 [0, ][
52.220258] PVR_K:(Error): BridgedDispatchKM: Initialisation failed.
Driver unusable.

PVR:(Error): PVRSRVBridgeCall: Failed to access device.  Function
ID:3223086862 (strerror returns no value.). [0, ]
PVR:(Error): SrvInit: PVRSRVInitSrvDisconnect failed (26). See srvkm
log for details. [0, ]
pvrsrvctl: SrvInit failed (already initialized?)
(err=PVRSRV_ERROR_BUILD_MISMATCH)


adam

[1] - http://processors.wiki.ti.com/index.php/GSG:_AM35x_and_OMAP35x_Rebuilding_the_Software#How_to_check_for_SGX_core_revision




>
> gles1test1
>
> >
> > 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
> > _______________________________________________
> > 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
>
> _______________________________________________
> 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