[Openpvrsgx-devgroup] old am3517 version

H. Nikolaus Schaller hns at goldelico.com
Thu Dec 19 16:45:28 CET 2019

> Am 19.12.2019 um 15:54 schrieb Tony Lindgren <tony at atomide.com>:
> * H. Nikolaus Schaller <hns at goldelico.com> [191219 06:57]:
>>> Am 18.12.2019 um 22:14 schrieb Jeroen Hofstee <jeroen at myspectrum.nl>:
>>> I will have a look why, but perhaps this rings a bell?
>> 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?
> Yes the older ones need to use pvrsrvinit as the command numbering has
> changed. There's still a slight change we can make older sdks work by
> rewriting the commands, but also the command sequences have changed based
> on my experiments few weeks ago. And we have droid4 with sgx540 working
> with an older SDK patched up suing pvrsrvinit.
> The thing to try with am3517 is to try to blobs that work for omap36xx
> and am437x, and see if the sgx530 revision specific hardware echanges
> are limited to the kernel driver only. You could try this on any of
> omap34xx/omap35xx/am3517.. I guess Nikolaus already did some tests with
> omap35xx version of gta04 though?

Yes. Basically the key issue is the minor SGX version.
It appears that we need
* sgx530-121 for omap3430/3530/am3517
* sgx530-125 for omap3630/dm3730

Unfortunately this minor version is also somehow embossed into the
user-space libs and binaries (maybe even the uKernel) so that trying
to run the DDK 1.14 on omap3530 (e.g. OpenPandora 600 MHz) fails with
a warning that the SGX version does not match.

This is where the older DDKs should help, but I have not tested.
AFAIR the gfx sdk 5.x was available in both minor versions.

> In both rewriting commands and trying to use different version code, we
> may have a tricky problem if the hardware changes also affect the binary
> blobs.

Well, we can't exclude that the uKernel (= Firmware) must match the
specific hardware because it does some workarounds.

> Regards,
> Tony
> _______________________________________________
> 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