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

H. Nikolaus Schaller hns at goldelico.com
Sat Nov 23 14:50:19 CET 2019


> 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

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



More information about the openpvrsgx-devgroup mailing list