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

H. Nikolaus Schaller hns at goldelico.com
Sat Nov 23 13:47:12 CET 2019


> 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.

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



More information about the openpvrsgx-devgroup mailing list