[Openpvrsgx-devgroup] old am3517 version

H. Nikolaus Schaller hns at goldelico.com
Sat Dec 21 18:11:06 CET 2019


> Am 21.12.2019 um 12:46 schrieb Jeroen Hofstee <jeroen at myspectrum.nl>:
> 
> 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..

Fine.

> Assuming you don't want all the
> code on the ML.

Yes, that is probably too much...

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

I think the DRM versions did not work before DDK 1.14

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

Good strategy.

Best regards,
Nikolaus

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

So someone at TI did compile the matching pvrsrvctl.

> 
> 
>> 
>>> 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-06.00.00.00 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,
> 
> Jeroen
> 
> _______________________________________________
> 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