[Openpvrsgx-devgroup] trying to get SGX 1.14 running on DM3730 (SGX530)
H. Nikolaus Schaller
hns at goldelico.com
Sat Nov 23 18:59:16 CET 2019
> Am 23.11.2019 um 18:23 schrieb Adam Ford <aford173 at gmail.com>:
> On Sat, Nov 23, 2019 at 7:50 AM H. Nikolaus Schaller <hns at goldelico.com> wrote:
>> 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 .
> 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 ]
So far it looks good. This means it has started to access the sgx.
> [ 52.200303] PVR_K: (FAIL) SGXInit: Incompatible HW core rev (10201)
> and SW core rev (10205).
This is exactly the same I get on openpandora 600MHz with omap3530.
Looks like it does also have an sgx530, but a different revision (121) as the dm3730 (125).
So we have the same problem to solve like for the omap3530.
> 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
You weren't wrong... The sgv revision in the am35 is...
It seems as if the uKernel inside the DDK1.14 UM binaries is not compiled for the 121 revision but 125.
I have thought about ignoring differences between 121 and 125 for the moment (assuming that the same uKernel runs on both) and make the pvrsrvkm report that it runs on 125. Maybe faking the SGX_REV to be 125 as well?
So try to change drivers / gpu / drm / pvrsgx / Makefile
$(Q)SOC_VENDOR=ti SOC_FAMILY=omap SOC=omap3 SGX=sgx530 SGX_FLAG=SGX530 SGX_REV=121 AM_VERSION=3 TARGET_TYPE=$(CONFIG_SGX_OMAP) $(MAKE) $(build)=$(SOURCE)
$(Q)SOC_VENDOR=ti SOC_FAMILY=omap SOC=omap3 SGX=sgx530 SGX_FLAG=SGX530 SGX_REV=125 AM_VERSION=3 TARGET_TYPE=$(CONFIG_SGX_OMAP) $(MAKE) $(build)=$(SOURCE)
But AFAIR there are only a lot of errata depending on the SGX_REV respectively SGX_CORE_REV:
The version is also used by drivers/gpu/drm/pvrsgx/1.14.3699939//eurasia_km/services4/system/omap/sysinfo.h but only in one special case to switch clock frequencies.
But it does not seem to be used by some ioctl() callback to report the revision to user-space.
So it will likely still fail to work and still report a mismatch.
If you can prove that, we have to conclude that the -125 libsrv_um.so does something like  on its own and finds an -121 and fails.
It may be possible to locate this check in the binary and patch it by a noop.
It looks as if we really need someone from TI to build a version of the DDK1.14 UM (or newer) binaries for sgx530-121. Or we are stuck with an older DDK (1.9 or 1.10).
Sorry that I do not have a better answer yet.
> [ 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?)
>  - http://processors.wiki.ti.com/index.php/GSG:_AM35x_and_OMAP35x_Rebuilding_the_Software#How_to_check_for_SGX_core_revision
>>>>>> 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.
>>>> openpvrsgx-devgroup mailing list
>>>> openpvrsgx-devgroup at letux.org
>>> openpvrsgx-devgroup mailing list
>>> openpvrsgx-devgroup at letux.org
>> openpvrsgx-devgroup mailing list
>> openpvrsgx-devgroup at letux.org
> openpvrsgx-devgroup mailing list
> openpvrsgx-devgroup at letux.org
More information about the openpvrsgx-devgroup