[Openpvrsgx-devgroup] old am3517 version

H. Nikolaus Schaller hns at goldelico.com
Thu Dec 19 18:10:46 CET 2019

> Am 19.12.2019 um 17:31 schrieb Tony Lindgren <tony at atomide.com>:
> * H. Nikolaus Schaller <hns at goldelico.com> [191219 15:46]:
>>> Am 19.12.2019 um 15:54 schrieb Tony Lindgren <tony at atomide.com>:
>>> 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.
> Have you tried downgrading the kernel version string and
> ignoring all the version errors in the kernel?

It appears to read the SGX version registers directly.
There was no ioctl or open/read/close involved

>>> 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.
> Yes it's possible that firmware needs to match the sgx530
> hardware revision too.

At least it is checked somewhere, but not in pvrsrvkm. Either in the
libs or pvrsrvctl or even the firmware.


More information about the openpvrsgx-devgroup mailing list