[Openpvrsgx-devgroup] old am3517 version

Jeroen Hofstee jeroen at myspectrum.nl
Sat Dec 21 12:46:27 CET 2019

Hello Nikolaus,

On 12/20/19 10:29 PM, H. Nikolaus Schaller wrote:
>>> I think we have it as DDK 1.9 in our tree - but the glue code is missing.
>> I am aware of that, it is a different minor though.
>> I based mine on Graphics_SDK_4_09_00_01 / 1.9ED2188537,
> It seems as if I have 1.9.2253347.
> We could add and integrate yours as well. Is there some git repo to fetch it?
> At the moment my main goal is to get as many working setups together. Then
> we can better analyse commonalities and differences.

I will send you a pull request.. Assuming you don't want all the
code on the ML. I can push my own hackery to my own account,
since it is not working yet.

>> since it is the last tested release for the am3517.
> Ok. Do you have matching user-space code?

yes, but it is for the fb interface at the moment. And I am looking
at that since I am sure that used to work 5? years ago and the
X11 / drm didn't / wasn't tested. I would like to get a working version
first. I have a branch of your 1.14 version as well, but that fails on an
allocation failure if I recall correctly. So I decided to get a known
to work version first and thereafter look if DRM / different version
are possible.

>> Obviously I
>> have similar patches then in that branch. There is one thing I
>> purposely did different, and that is that I made the arm dma
>> internals available again instead of removing the implementation.
>> No idea if that maters.
> Shouldn't make a difference. But there may be subtle details.
>>>> + some patches and I don't reparent this one:
>>>> don't clk_set_parent(psSysSpecData->psSGX_FCK, psSysSpecData->psCORE_CK);
>>>> since it fails..
>>>> probing that module works now:
>>>> [29973.162880] pvrsrvkm: loading out-of-tree module taints kernel.
>>>> [29973.194943] PVR: PVRCore_Init
>>>> [29973.219580] PVR: PVRSRVDriverProbe(pDevice=51e8d31a)
>>>> [29973.220696] PVR: EnableSystemClocks: Enabling System Clocks
>>>> [29973.220989] PVR: Setting GPTIMER11 parent to System Clock
>>>> [29973.221369] PVR: GPTIMER11 clock is 13MHz
>>>> [29973.221460] PVR: Setting GPTIMER11 mode to posted (currently is non-posted)
>>>> [29973.236835] PVR: PVRCore_Init: major device 246
>>> Looks good.
>>>> Using it won't work:
>>>> root at ccgx:/opt/gfxlibraries/gfx_dbg_es3.x# pvrsrvctl --no-module --start
>>>> PVR:(Error): PVRSRVBridgeCall: Failed to access device.  Function ID:3223086916 (Bad address). [232, /pvr_bridge_u.c]
>>>> PVR:(Error): PVRSRVInitSrvConnect: BridgeCall failed [2479, /bridged_pvr_glue.c]
>>>> PVR:(Error): PVRSRVBridgeCall: Failed to access device.  Function ID:3223086861 (Bad address). [232, /pvr_bridge_u.c]
>>>> PVR:
>>>> PVR: Memory Stats
>>>> PVR: ------------
>>>> PVR:
>>>> PVR: High Water Mark = 0 bytes
>>>> PVR:(Error): SrvInit: PVRSRVInitSrvConnect failed (34) [37, /srvinit.c]
>>>> pvrsrvctl: SrvInit failed (already initialized?) (err=34)
>>>> trying to use it fails horribly:
>>>> [30004.141288] PVR_K:(Error): GetHandleStructure: Handle index out of range (463 >= 4) [736, home/jeroen/Graphics_SDK_4_09_00_01/GFX_Linux_KM/services4/srvkm/common/handle.c]
>>>> [30004.141339] ------------[ cut here ]------------
>>>> [30004.142073] WARNING: CPU: 0 PID: 17207 at /home/jeroen/Graphics_SDK_4_09_00_01/GFX_Linux_KM/services4/srvkm/common/handle.c:737 GetHandleStructure+0xa8/0x1a0 [pvrsrvkm]
>>>> [30004.142387] not good
>>>> [30004.142396] Modules linked in: pvrsrvkm(O) aes_generic cmac ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_tcpudp ip6table_filter ip6_tables xt_conntrack nf_conntrack nf_defrag_ipv6 libcrc32c nf_defrag_ipv4 iptable_filter ip_tables x_tables btusb btrtl btbcm btintel bluetooth ecdh_generic ecc rfkill libaes
>> For completeness, the error is the index out of range,
>> I added the "not good" warning, just to see how it got
>> there.
>>> I remember having seen similar messages which indicate incompatible ioctl() parameters.
>>> One thing makes me wonder: you use pvrsrvctl.
>>> AFAIR, the Graphics_SDK_4_09_00_01 is 'old style' and there was a different command (pvrsrvinit) to launch it?
>> It is old, but not the old style. Only pvrsrvctl is there.
> That is really interesting. Maybe someone had mangled to make it work.

I have no idea, I just downloaded what TI supplied.

>> Graphics_SDK_4_05_00_03 has pvrsrvinit e.g.
>> I double checked if the 4_09 is tested for the am3517,
>> and that seems so. The ti-sdk-am3517-evm- e.g. also
>> ships Graphics_SDK_setuplinux_4_09_00_01_hardfp_minimal_demos.bin.
>> Also the README contains:
>> "This release includes the Linux graphics drivers for the SGX530 family of chipsets AM35x/37xx, AM335x,
>> 387x(TI814x)/389x(TI816x).The Graphics SDK contains documentation, demo programs and tools.
> Ah, intersting. So this might support 387x and 389x as well. Although I do not know anyone who owns
> a device...

Well if the docs are correct, yes.

With kind regards,


More information about the openpvrsgx-devgroup mailing list